From nobody Fri Dec 1 06:47: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 EC9E2126B71 for ; Fri, 1 Dec 2017 06:47: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, 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 lNAiS0A4-ZQN for ; Fri, 1 Dec 2017 06:47:11 -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 6E815120725 for ; Fri, 1 Dec 2017 06:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9588; q=dns/txt; s=iport; t=1512139631; x=1513349231; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=WqAKvGKwzO59du3afEWOSRmVVo+J6wy4+r54wHtuI5k=; b=jVnCBD7UL90xdJWoXZNB/oRxIl9kdluB1yydyLVCJtVAT5Vthf6mda1s Fb4QwWbysebta+XKWmGhzXaB42RjOQ4eh9y4n9hedJ7QkvGt6h0wdNXKP 0hiyKwq56i9EBbSO7ISWNQJ+53xaGLHEvadGnMEr/63/lNvDMcX5pk2QS A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DVAADeaiFa/49dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKcmZuJweDeIogjnOBfZEyhUsUggEKI4UYAhqFDT8YAQEBAQE?= =?us-ascii?q?BAQEBayiFIgEBAQEDIwpcAgEIEQQBASgDAgICMBQJCAIEARIIiTZkEKcRgieKZ?= =?us-ascii?q?AEBAQEBAQEBAQEBAQEBAQEBAQEBARgFg0GCCoFWgWmDK4MygVdOgl+CYwWKS3y?= =?us-ascii?q?NboktAodyjRSTXox8iSACERkBgTkBHzkmgSdvFYJjCYRMeAGIboEUAQEB?= X-IronPort-AV: E=Sophos;i="5.45,344,1508803200"; d="scan'208,217";a="321131807" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Dec 2017 14:47:10 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vB1ElAZd007604 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Dec 2017 14:47:10 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; Fri, 1 Dec 2017 09:47: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; Fri, 1 Dec 2017 09:47:09 -0500 From: "Eric Voit (evoit)" To: Andy Bierman , Netconf Thread-Topic: [Netconf] yang-push issue: encoding Thread-Index: AQHTajt05ZrVedB6DU2McS+DNrSp4KMujS5g Date: Fri, 1 Dec 2017 14:47:09 +0000 Message-ID: <545e778dc7ed43b2a6031228e0ac16ee@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.86.245.99] Content-Type: multipart/alternative; boundary="_000_545e778dc7ed43b2a6031228e0ac16eeXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [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 14:47:13 -0000 --_000_545e778dc7ed43b2a6031228e0ac16eeXCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUuICBNYXJ0aW4gY2F1Z2h0IHRoaXMgdG9vLiAgVGhpcyBzZW50ZW5jZSBoYXMgYmVlbiBy ZW1vdmVkIGluIHRoZSB3b3JraW5nIGNvcHkgb2YgdGhlIGRyYWZ0Lg0KDQpFcmljDQoNCkZyb206 IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBB bmR5IEJpZXJtYW4NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAzMCwgMjAxNyA3OjI5IFBNDQpU bzogTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZz4NClN1YmplY3Q6IFtOZXRjb25mXSB5YW5nLXB1 c2ggaXNzdWU6IGVuY29kaW5nDQoNCkhpLA0KDQpJbiB5YW5nLXB1c2gtMTE6DQoNCjMuNTxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0xMSNz ZWN0aW9uLTMuNT4uICBEYXRhIEVuY29kaW5ncw0KDQoNCg0KDQoNCiAgIEEgcHVibGlzaGVyIE1V U1Qgc3VwcG9ydCBYTUwgZW5jb2RpbmcgYW5kIE1BWSBzdXBwb3J0IG90aGVyIGVuY29kaW5ncw0K DQogICBzdWNoIGFzIEpTT04gZW5jb2RpbmcuDQoNCg0KSSBkbyBub3QgdGhpbmsgdGhpcyBkcmFm dCBzaG91bGQgbWVudGlvbiBlbmNvZGluZy4NCkl0IGlzIHVwIHRvIHRoZSBwcm90b2NvbCB0byBz cGVjaWZ5IG1lc3NhZ2UgZW5jb2RpbmcgcnVsZXMuDQpUaGUgTkVUQ09ORiBwcm90b2NvbCBzdXBw b3J0cyBYTUwgb25seS4NClJFU1RDT05GIHVzZXMgQWNjZXB0IGFuZCBDb250ZW50LVR5cGUgaGVh ZGVycyB0byBkZXRlcm1pbmUgdGhlIGVuY29kaW5nLg0KQ29NSSB3aWxsIHVzZSBDQk9SIGZvciBZ QU5HLWVuY29kZWQgZGF0YS4NCg0KDQoNCkFuZHkNCg0K --_000_545e778dc7ed43b2a6031228e0ac16eeXCHRTP013ciscocom_ 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 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmgzDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1s aW5rOiJIZWFkaW5nIDMgQ2hhciI7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjEzLjVwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29u b3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0 ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN Cglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLmdtYWlsLWgzDQoJe21zby1zdHlsZS1uYW1l OmdtYWlsLWgzO30NCnNwYW4uSGVhZGluZzNDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5n IDMgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRp bmcgMyI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkgTGlnaHQiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzFGNEQ3ODt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkFncmVlLiZuYnNwOyBNYXJ0aW4gY2F1Z2h0IHRoaXMgdG9vLiZuYnNwOyBUaGlzIHNlbnRl bmNlIGhhcyBiZWVuIHJlbW92ZWQgaW4gdGhlIHdvcmtpbmcgY29weSBvZiB0aGUgZHJhZnQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxicj4NCkVyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBOZXRjb25mIFttYWlsdG86bmV0 Y29uZi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmR5IEJpZXJtYW48 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDMwLCAyMDE3IDc6MjkgUE08YnI+ DQo8Yj5Ubzo8L2I+IE5ldGNvbmYgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFtOZXRjb25mXSB5YW5nLXB1c2ggaXNzdWU6IGVuY29kaW5nPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4geWFuZy1wdXNoLTExOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8aDMgc3R5bGU9Im1zby1saW5lLWhlaWdodC1h bHQ6MHB0Ij48YSBuYW1lPSJzZWN0aW9uLTMuNSI+PC9hPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoLTExI3NlY3Rpb24tMy41 Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOiZxdW90O3NlY3Rpb24tM1wuNSZxdW90OyI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjMuNTwvc3Bhbj48L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6JnF1b3Q7c2VjdGlvbi0zXC41JnF1b3Q7Ij48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPi4mbmJzcDsNCiBEYXRhIEVuY29kaW5nczxvOnA+ PC9vOnA+PC9zcGFuPjwvaDM+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IEEgcHVibGlzaGVyIE1VU1Qgc3VwcG9ydCBYTUwgZW5jb2Rpbmcg YW5kIE1BWSBzdXBwb3J0IG90aGVyIGVuY29kaW5nczxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBzdWNoIGFzIEpTT04g ZW5jb2RpbmcuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBkbyBub3QgdGhpbmsgdGhpcyBkcmFmdCBzaG91bGQgbWVudGlv biBlbmNvZGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkl0IGlzIHVwIHRvIHRoZSBwcm90b2NvbCB0byBzcGVjaWZ5IG1lc3NhZ2UgZW5jb2Rp bmcgcnVsZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGUgTkVUQ09ORiBwcm90b2NvbCBzdXBwb3J0cyBYTUwgb25seS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJFU1RDT05GIHVzZXMgQWNj ZXB0IGFuZCBDb250ZW50LVR5cGUgaGVhZGVycyB0byBkZXRlcm1pbmUgdGhlIGVuY29kaW5nLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29NSSB3 aWxsIHVzZSBDQk9SIGZvciBZQU5HLWVuY29kZWQgZGF0YS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_545e778dc7ed43b2a6031228e0ac16eeXCHRTP013ciscocom_-- From nobody Fri Dec 1 06:47: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 D7533126B71 for ; Fri, 1 Dec 2017 06:47:37 -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 Pe46xQWDu1Yu for ; Fri, 1 Dec 2017 06:47:36 -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 7533C120725 for ; Fri, 1 Dec 2017 06:47:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17134; q=dns/txt; s=iport; t=1512139656; x=1513349256; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=FpERklIVgZwljIlvTS0upN6F/GHeEaN/F+/jyz0zeng=; b=MWOQJAMYiDqcmhsQp9Q6kF0waE2rvzPfqaox+qHPi7B7QFHxfJPU3gEo QSw4IcnaVd1ABw4CeKIqBe5eFXZ0JmPvlR+c3alqvXmQSiQNryBXFb3hS HlDtB8H+5EEUqs/NC3X0USij8Uux+wjKT+hBhnMHVuNiumWEtZ7UlT5YV g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DNBQAlayFa/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKcmZuJwEGg3iZE4F9fpA0hUuCFQojhRgCGoUNQRYBAQEBAQE?= =?us-ascii?q?BAQFrKIUiAQEBAQMjClwCAQgVEB0CAgIwJQIEARqJNmQQpxOCJ4pkAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBHYNBggqBVoFpgnU2gzEBgX2DB4JjBZk1iS0Ch3KNFIM?= =?us-ascii?q?CkFyMfIkgAhEZAYE5ASYIKiaBJ28VgmQIhEx4iG+BFAEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,344,1508803200"; d="scan'208,217";a="330930973" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Dec 2017 14:47:11 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vB1ElBc5026621 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Dec 2017 14:47:11 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, 1 Dec 2017 09:47: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; Fri, 1 Dec 2017 09:47:10 -0500 From: "Eric Voit (evoit)" To: Andy Bierman , Netconf Thread-Topic: [Netconf] yang-push issue: XPath filter Thread-Index: AQHTaj8rr+XXm3ATyEy5bODgDsbL/aMujaVg Date: Fri, 1 Dec 2017 14:47:10 +0000 Message-ID: <7c296634a2d44a4eb7ad3662f7a19365@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.86.245.99] Content-Type: multipart/alternative; boundary="_000_7c296634a2d44a4eb7ad3662f7a19365XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [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 14:47:38 -0000 --_000_7c296634a2d44a4eb7ad3662f7a19365XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KRnJvbTogQW5keSBCaWVybWFuLCBOb3ZlbWJlciAzMCwgMjAxNyA3OjU2IFBN DQoNCkhpLA0KDQpJbiBzZWMuIDMuNjoNCg0KDQoNCiAgIFRoZXNlIGZpbHRlcnMgYXJlIGludGVu ZGVkIHRvIGJlIHVzZWQgYXMgc2VsZWN0b3JzIHRoYXQgZGVmaW5lIHdoaWNoDQoNCiAgIG9iamVj dHMgYXJlIHdpdGhpbiB0aGUgc2NvcGUgb2YgYSBzdWJzY3JpcHRpb24uICBBIHB1Ymxpc2hlciBN VVNUDQoNCiAgIHN1cHBvcnQgYXQgbGVhc3Qgb25lIHR5cGUgb2Ygc2VsZWN0aW9uIGZpbHRlci4N Cg0KVGhpcyBpcyBpbmNvbnNpc3RlbnQgd2l0aCBORVRDT05GLCB3aGVyZSBzdWJ0cmVlIGZpbHRl cmluZyBpbiBtYW5kYXRvcnktdG8taW1wbGVtZW50DQphbmQgWFBhdGggZmlsdGVyaW5nIGlzIG9w dGlvbmFsIChpZi1mZWF0dXJlKS4NCg0KPEVyaWM+IFdlIGhhZCBzb21lIGlucHV0IGZyb20gSW9U IHBlb3BsZSB0aGF0IFhwYXRoIGFuZCBub3Qgc3VidHJlZSB3YXMgcHJlZmVycmVkIGluIHRoZWly IHVzZSBjYXNlcyBhbmQgdHJhbnNwb3J0Lg0KDQpPbmUgd2F5IHRvIGFkZHJlc3MgdGhpcyB3b3Vs ZCBiZSB0byBtYWtlIHN1YnRyZWUgZmlsdGVyaW5nIG1hbmRhdG9yeSB3aGVuIHRoZSB0cmFuc3Bv cnQgaXMgTkVUQ09ORiwgYW5kIHBsYWNlIHRoaXMgcmVxdWlyZW1lbnQgd2l0aGluDQpkcmFmdC1p ZXRmLW5ldGNvbmYtbmV0Y29uZi1ldmVudC1ub3RpZmljYXRpb25zDQp3b3VsZCB0aGF0IHdvcmsg Zm9yIHlvdT8NCg0KQSBjbGllbnQgZG9lcyBub3QgaGF2ZSBhbnkgd2F5IHRvIGtub3cgd2hhdCBh DQpwdWJsaXNoZXIgd2lsbCBzdXBwb3J0Lg0KDQo8RXJpYz4gU3VidHJlZSBhbmQgeHBhdGggZmls dGVyaW5nIGFyZSBpZi1mZWF0dXJlcyBkZWZpbmVkIHdpdGhpbiBzdWJzY3JpYmVkLW5vdGlmaWNh dGlvbnMsIGFuZCB0YWdnZWQgd2l0aGluIHRoZSBmaWx0ZXIgdHlwZXMgb2YgeWFuZy1wdXNoLiAg SSB3aWxsIGFkZCBhIG5vdGUgYWZ0ZXI6DQoNCg0KQSBwdWJsaXNoZXIgTVVTVCBzdXBwb3J0IGF0 IGxlYXN0IG9uZSB0eXBlIG9mIHNlbGVjdGlvbiBmaWx0ZXIuDQoNCg0KDQp0aGF0Og0KDQoNCg0K QSBzdWJzY3JpYmVyIGNhbiBkZXRlcm1pbmUgYXZhaWxhYmxlIHNlbGVjdGlvbiBmaWx0ZXIgb3B0 aW9ucyBieSBsb29raW5nIGZvciDigJxzdWJ0cmVl4oCdIGFuZCDigJx4cGF0aOKAnSBmZWF0dXJl IHN1cHBvcnQgd2l0aGluIOKAnGlldGYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25z4oCdLg0KDQoN Ckl0IHdvdWxkIGJlIGJldHRlciB0byBmb2xsb3cgTkVUQ09ORiBhbmQgYWRkIGFuIGlmLWZlYXR1 cmUgdG8gWFBhdGgsIGFuZCBkZWNsYXJlDQp0aGF0IHN1YnRyZWUgaXMgbWFuZGF0b3J5Lg0KDQpB bHNvLCB0aGUgZXhhbXBsZSBvbiBwZyAzNiBpcyB3cm9uZzoNCg0KT0xEOg0KDQoNCiAgICAgICA8 eXA6eHBhdGgtZmlsdGVyDQoNCiAgICAgICAgICAgIHhtbG5zOmV4PSJodHRwOi8vZXhhbXBsZS5j b20vc2FtcGxlLWRhdGEvMS4wIg0KDQogICAgICAgICAgICBzZWxlY3Q9Ii9leDpmb28iLz4NCg0K DQoNCk5FVzoNCg0KDQoNCiAgICAgICA8eXA6eHBhdGgtZmlsdGVyDQoNCiAgICAgICAgeG1sbnM6 ZXg9Imh0dHA6Ly9leGFtcGxlLmNvbS9zYW1wbGUtZGF0YS8xLjAiPi9leDpmb28NCg0KICAgICAg IDwveXA6eHBhdGgtZmlsdGVyPg0KDQoNCg0KDQoNCkZyb20gdGhlIFlBTkcgbW9kdWxlOg0KDQoN Cg0KICAgICAgbGVhZiB4cGF0aC1maWx0ZXIgew0KDQogICAgICAgIHR5cGUgeWFuZzp4cGF0aDEu MDsNCg0KICAgICAgICBkZXNjcmlwdGlvbg0KDQogICAgICAgICAgIlRoaXMgcGFyYW1ldGVyIGNv bnRhaW5zIGFuIFhQYXRoIGV4cHJlc3Npb24gaWRlbnRpZnlpbmcgdGhlDQoNCiAgICAgICAgICBw b3J0aW9ucyBvZiB0aGUgdGFyZ2V0IGRhdGFzdG9yZSB0byByZXRyaWV2ZS4iOw0KDQogICAgICAg IHJlZmVyZW5jZSAiaHR0cDovL3d3dy53My5vcmcvVFIvMTk5OS9SRUMteHBhdGgtMTk5OTExMTYi Ow0KDQogICAgICB9DQoNCg0KDQo8RXJpYz4gV2lsbCBmaXgsIHRoYW5rcyENCg0KRXJpYw0KDQoN Cg0KQW5keQ0KDQoNCg== --_000_7c296634a2d44a4eb7ad3662f7a19365XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAy IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29u b3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0 ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsN Cglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEFuZHksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbmR5IEJpZXJtYW4sIE5vdmVtYmVyIDMwLCAyMDE3 IDc6NTYgUE08YnI+DQo8YnI+DQo8L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4g c2VjLiAzLjY6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBUaGVzZSBmaWx0ZXJzIGFyZSBpbnRlbmRl ZCB0byBiZSB1c2VkIGFzIHNlbGVjdG9ycyB0aGF0IGRlZmluZSB3aGljaDxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBv YmplY3RzIGFyZSB3aXRoaW4gdGhlIHNjb3BlIG9mIGEgc3Vic2NyaXB0aW9uLiZuYnNwOyBBIHB1 Ymxpc2hlciBNVVNUPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHN1cHBvcnQgYXQgbGVhc3Qgb25lIHR5cGUgb2Ygc2Vs ZWN0aW9uIGZpbHRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBpbmNvbnNpc3RlbnQgd2l0aCBORVRDT05GLCB3 aGVyZSBzdWJ0cmVlIGZpbHRlcmluZyBpbiBtYW5kYXRvcnktdG8taW1wbGVtZW50PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQgWFBhdGggZmls dGVyaW5nIGlzIG9wdGlvbmFsIChpZi1mZWF0dXJlKS4mbmJzcDsgPHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bHQ7RXJpYyZndDsgV2UgaGFkIHNvbWUgaW5wdXQgZnJvbSBJb1QgcGVvcGxlIHRoYXQgWHBhdGgg YW5kIG5vdCBzdWJ0cmVlIHdhcyBwcmVmZXJyZWQgaW4gdGhlaXIgdXNlIGNhc2VzIGFuZCB0cmFu c3BvcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PbmUgd2F5 IHRvIGFkZHJlc3MgdGhpcyB3b3VsZCBiZSB0byBtYWtlIHN1YnRyZWUgZmlsdGVyaW5nIG1hbmRh dG9yeSB3aGVuIHRoZSB0cmFuc3BvcnQgaXMgTkVUQ09ORiwgYW5kIHBsYWNlIHRoaXMgcmVxdWly ZW1lbnQgd2l0aGluDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZHJhZnQtaWV0Zi1uZXRjb25mLW5ldGNv bmYtZXZlbnQtbm90aWZpY2F0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj53b3VsZCB0aGF0IHdvcmsg Zm9yIHlvdT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBjbGllbnQgZG9lcyBub3QgaGF2ZSBhbnkgd2F5IHRvIGtu b3cgd2hhdCBhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5wdWJsaXNoZXIgd2lsbCBzdXBwb3J0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbHQ7RXJpYyZndDsgU3VidHJlZSBhbmQgeHBhdGggZmlsdGVyaW5nIGFy ZSBpZi1mZWF0dXJlcyBkZWZpbmVkIHdpdGhpbiBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMsIGFu ZCB0YWdnZWQgd2l0aGluIHRoZSBmaWx0ZXIgdHlwZXMgb2YgeWFuZy1wdXNoLiZuYnNwOyBJIHdp bGwgYWRkIGEgbm90ZQ0KIGFmdGVyOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QSBwdWJsaXNoZXIg TVVTVCBzdXBwb3J0IGF0IGxlYXN0IG9uZSB0eXBlIG9mIHNlbGVjdGlvbiBmaWx0ZXIuPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj50aGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPkEgc3Vic2NyaWJlciBjYW4gZGV0ZXJtaW5lIGF2YWlsYWJsZSBzZWxl Y3Rpb24gZmlsdGVyIG9wdGlvbnMgYnkgbG9va2luZyBmb3Ig4oCcc3VidHJlZeKAnSBhbmQg4oCc eHBhdGjigJ0gZmVhdHVyZSBzdXBwb3J0IHdpdGhpbiDigJxpZXRmLXN1YnNjcmliZWQtbm90aWZp Y2F0aW9uc+KAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdvdWxkIGJlIGJl dHRlciB0byBmb2xsb3cgTkVUQ09ORiBhbmQgYWRkIGFuIGlmLWZlYXR1cmUgdG8gWFBhdGgsIGFu ZCBkZWNsYXJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj50aGF0IHN1YnRyZWUgaXMgbWFuZGF0b3J5LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvLCB0aGUgZXhhbXBsZSBvbiBw ZyAzNiBpcyB3cm9uZzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T0xEOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZsdDt5cDp4cGF0aC1maWx0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgeG1sbnM6ZXg9JnF1b3Q7PGEgaHJlZj0i aHR0cDovL2V4YW1wbGUuY29tL3NhbXBsZS1kYXRhLzEuMCI+aHR0cDovL2V4YW1wbGUuY29tL3Nh bXBsZS1kYXRhLzEuMDwvYT4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc2VsZWN0PSZxdW90Oy9leDpmb28mcXVv dDsvJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPk5FVzo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZsdDt5cDp4cGF0aC1maWx0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgeG1sbnM6ZXg9JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tL3Nh bXBsZS1kYXRhLzEuMCI+aHR0cDovL2V4YW1wbGUuY29tL3NhbXBsZS1kYXRhLzEuMDwvYT4mcXVv dDsmZ3Q7L2V4OmZvbzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7L3lw OnhwYXRoLWZpbHRlciZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tIHRoZSBZQU5HIG1vZHVsZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiB4cGF0aC1maWx0ZXIgezxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIHlhbmc6eHBhdGgxLjA7PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0aW9uPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O1Ro aXMgcGFyYW1ldGVyIGNvbnRhaW5zIGFuIFhQYXRoIGV4cHJlc3Npb24gaWRlbnRpZnlpbmcgdGhl PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHBv cnRpb25zIG9mIHRoZSB0YXJnZXQgZGF0YXN0b3JlIHRvIHJldHJpZXZlLiZxdW90Ozs8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVmZXJlbmNlICZxdW90OzxhIGhy ZWY9Imh0dHA6Ly93d3cudzMub3JnL1RSLzE5OTkvUkVDLXhwYXRoLTE5OTkxMTE2Ij5odHRwOi8v d3d3LnczLm9yZy9UUi8xOTk5L1JFQy14cGF0aC0xOTk5MTExNjwvYT4mcXVvdDs7PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmx0O0VyaWMmZ3Q7IFdpbGwgZml4 LCB0aGFua3MhPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48YnI+RXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7c296634a2d44a4eb7ad3662f7a19365XCHRTP013ciscocom_-- From nobody Fri Dec 1 07:51: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 E1D3B1242F7 for ; Fri, 1 Dec 2017 07:51: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, 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 De3RsPWTBPPJ for ; Fri, 1 Dec 2017 07:50:58 -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 5E806124B09 for ; Fri, 1 Dec 2017 07:50:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=77208; q=dns/txt; s=iport; t=1512143458; x=1513353058; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BiThBSFG0LoRkaaxZdS14gkbl8ssom0VPocRdLQzZTE=; b=DY+t/JzX4xd/e/ZBhc8ipqSqeDitw+EU9z/3DwksbB1ljQd914Y3xQNh wiVqEHivnfRLHdWkUg0UPSJYGJ4KhcW1Ph99TAsriKNLcwEgB0scE4rdL QPwkkGURCqU+21x/vks5ygWE+y7pLm22gM8pr5Mo4w+KAKWxg6qg9eBBk U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAgA9eSFa/5xdJa1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKcmZuJweDeJkTgX2WfRSBfgMKGAEKhElPAhqFEUEWAQEBAQE?= =?us-ascii?q?BAQEBayiFIgEBAQEDAQEYCQpBCxACAQYCEQQBAQ4ICwEGAwICAiULFAkIAgQOB?= =?us-ascii?q?QgTBIkfZBCJCJ1sgieKZAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFg0GCCoFWgWm?= =?us-ascii?q?DK4MygSofDwEdBwkfCYJWgmMFmTWJLQKLXYkpgh+RP4o7i2ECERkBgTkBJgcrJ?= =?us-ascii?q?oEnbxU6gimEVXiHPAEmA4EJgRQBAQE?= X-IronPort-AV: E=Sophos; i="5.45,344,1508803200"; d="scan'208,217"; a="38458600" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Dec 2017 15:50:57 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vB1FouJa010238 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Dec 2017 15:50:56 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, 1 Dec 2017 10:50:55 -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, 1 Dec 2017 10:50:55 -0500 From: "Eric Voit (evoit)" To: Rohit R Ranade CC: Netconf Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11 Thread-Index: AQHTaCzLQRPr9GM9Jka7UxKyCaa4a6MsMpiA//+ZgDCAAEyf8IAAV64AgABcfoCAABx9wIABTdwAgABhv1A= Date: Fri, 1 Dec 2017 15:50:55 +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> <991B70D8B4112A4699D5C00DDBBF878A6B15CFDD@DGGEMA502-MBX.china.huawei.com> <912c3dc57e404c7ea7fbce529a3eaf19@XCH-RTP-013.cisco.com> <991B70D8B4112A4699D5C00DDBBF878A6B15DB9A@DGGEMA502-MBX.china.huawei.com> In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6B15DB9A@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.86.244.179] Content-Type: multipart/alternative; boundary="_000_fe5996625ab448efa5f55af2f2a8089aXCHRTP013ciscocom_" 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: Fri, 01 Dec 2017 15:51:02 -0000 --_000_fe5996625ab448efa5f55af2f2a8089aXCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9oaXQsDQoNCkZyb206IFJvaGl0IFIgUmFuYWRlLCBOb3ZlbWJlciAzMCwgMjAxNyAxMTow NyBQTQ0KDQpIaSBFcmljLA0KDQpJbiB5b3VyIGNhc2UgLCB0aGVuIHRoZXJlIGlzIGEgY29ybmVy IGNhc2Ugd2hlcmUgaW4gaWYgdGhlIGRhbXBlbmluZyBwZXJpb2QgaXMgc2hvcnQsIHRoZSBkZXZp Y2UgbWF5IGhhdmUgc3RpbGwgbm90IGZpbmlzaGVkIHNlbmRpbmcgYWxsIGl0cyBub3RpZmljYXRp b24gZnJhZ21lbnRzIGFuZCB0aGUgbmV4dCB1cGRhdGUgcmVjb3JkIGlzIGFscmVhZHkgcmVhZHkg dG8gZ2V0IGFzc2VtYmxlZC4NCg0KPEVyaWM+IFllcywgdGhpcyBjb3JuZXIgY2FzZSBpcyBjb21t b24gYWNyb3NzIGFsbCBzb2x1dGlvbnMsIGluY2x1ZGluZyBwZXJpb2RpYyBzdWJzY3JpcHRpb25z LiAgIChFLmcuLCBXaGF0IGlmIGEgcm91dGluZyB0YWJsZSBnZXRzIGJpZ2dlciBhbGwgb2YgYSBz dWRkZW4/ICBXaGF0IGlmIGEga2V5IHB1Ymxpc2hlciBwcm9jZXNzIGlzIHRha2luZyBsb3RzIG9m IENQVT8pICAgVGhlIHF1ZXN0aW9uIGlzIHdoYXQgaXMgdGhlIGxldmVsIG9mIGV4cG9zdXJlIHRo ZSBhZG1pc3Npb24gY29udHJvbCBwcm9jZXNzIHBlcm1pdHMuDQoNCldoZXRoZXIgd2UgY2FuIGhh dmUgYSBsb3dlciBsaW1pdCBvbiB0aGUgZGFtcGVuaW5nIHBlcmlvZCBpbnRlcnZhbCB0byBhdm9p ZCBzdWNoIGEgc2NlbmFyaW8gPw0KDQo8RXJpYz4gWWVzLCBhIGxvd2VyIGxpbWl0IG9uIHRoZSBk YW1wZW5pbmcgcGVyaW9kIGlzIGEgcG90ZW50aWFsIHdheSB0byBhcHByb2FjaCB0aGlzLiAgQnV0 IEkgYmVsaWV2ZSB0aGVyZSB0byBiZSBhIGZldyBpc3N1ZXM6DQoNCsK3ICAgICAgICBUaGUgbWF4 aW11bSBsYXRlbmN5IGluIHNlZWluZyBhIGNoYW5nZSAoYXMgZGV0ZXJtaW5lZCBieSB3aGVuIGEg cHVzaC1jaGFuZ2UtdXBkYXRlIGlzIGFzc2VtYmxlZCkgd291bGQgbm90IGJlIGRldGVybWluaXN0 aWMgdG8gYXBwbGljYXRpb25zLiAgVGhpcyBwb3NzaWJpbGl0eSB3b3VsZCBoYXZlIHRvIGJlIGFj Y291bnRlZCBmb3Igd2hlbiBkZXNpZ25pbmcgYXBwbGljYXRpb24gYmVoYXZpb3IuDQoNCsK3ICAg ICAgICBJdCB3b3VsZCBub3QgYmUgZWFzeSBmb3IgYSByZWNlaXZlciBhcHBsaWNhdGlvbiB0byBk aXN0aW5ndWlzaCB3aGVuIGRhbXBlbmluZyBwZXJpb2RzIGFyZSBkZWdyYWRpbmcgbG9uZ2VyIGFu ZCBsb25nZXIuICBBbmQgdGhpcyB3aWxsIGxpa2VseSBiZSBkdWUgdG8gQ1BVL290aGVyIGltcGFj dHMgb24gdGhlIHB1Ymxpc2hlciB3aGljaCBhcmUgaW52aXNpYmxlIHRvIHRoZSByZWNlaXZlci4N Cg0KwrcgICAgICAgIEEgcGVyaW9kaWMgc3Vic2NyaXB0aW9uIG1pZ2h0IGFsc28gaGF2ZSB0aGUg ZGVsYXllZCBhc3NlbWJseSBwcm9ibGVtLCBhbmQgd2UgY2Fu4oCZdCBkZWxheSB0aG9zZSB1cGRh dGVzLiAgU28gdGhlIGFueSBzb2x1dGlvbiBhcHByb2FjaCBmb3IgYm90aCBvbi1jaGFuZ2UgJiBw ZXJpb2RpYyBjb3VsZG7igJl0IGJlIGNvbW1vbiBiZXR3ZWVuIHRoZSB0d28uDQoNCsK3ICAgICAg ICBBIGxvbmdlciBhbmQgbG9uZ2VyIGFzc2VtYmx5IHdpbmRvdyBtYWtlcyBpdCBoYXJkZXIgdG8g ZW5zdXJlIHRoZSBpbmNsdWRlZCBwYXRjaCBvcGVyYXRpb25zIGFsbCBjYW4gYmUgdGFnZ2VkIHdp dGggdGhlIHNhbWUgdGltZS1vZi11cGRhdGUuDQoNClRoZXJlIGFyZSBjdXJyZW50bHkgbWVjaGFu aXNtcyBpbiB0aGUgc29sdXRpb24gdG8gZGVhbCB3aXRoIHRoZSBjb3JuZXIgY2FzZS4NCg0Kwrcg ICAgICAgIOKAnHVwZGF0ZXMtbm90LXNlbnQgZmxhZ+KAnSwgd2hpY2ggaGFzIHRoZSBzYW1lIG1l YW5pbmcgZm9yIGJvdGggcHVzaC11cGRhdGVzIGFuZCBwdXNoLWNoYW5nZS11cGRhdGVzLiAgKEFu ZCB3aGljaCB3b3VsZCBzdGlsbCBiZSBuZWVkZWQgaWYgd2UgbWFkZSB0aGUgZGFtcGVuaW5nICBw ZXJpb2QgYSBsb3dlciBsaW1pdC4pDQoNCsK3ICAgICAgICBTdXNwZW5kaW5nIGEgc3Vic2NyaXB0 aW9uIHdpdGggdGhlIOKAnGRhdGF0cmVlLXNpemXigJ0gaWRlbnRpZmllZCBhcyBhbiBpc3N1ZSAo YWxzbyB0aGUgc2FtZSBmb3IgcGVyaW9kaWMgJiBvbi1jaGFuZ2UpDQoNCsK3ICAgICAgICBUaGUg cmVzeW5jaCBSUEMsIHdoaWNoIGNhbiBiZSBpbnZva2VkIGFzIG5lZWRlZC4NCg0KU28gYXMgdGhl cmUgYXJlIGludGVyZXN0aW5nIGFzcGVjdHMgdG8geW91ciDigJxsb3dlciBsaW1pdOKAnSBwcm9w b3NhbCwgYnV0IGl0IGhhcyB1bmV4cGxvcmVkIGltcGFjdHMgZnJvbSB0aGUgcG9pbnQgb2Ygdmll dyBvZiBleHBlY3RlZCBiZWhhdmlvciBhcyBzZWVuIGJ5IGFwcGxpY2F0aW9ucywgbXkgcmVjb21t ZW5kYXRpb24gd291bGQgYmUgdG8gbG9vayBhdCB0aGlzIGFzIHBvc3NpYmxlIGZvbGxvdy1vbiB3 b3JrLg0KDQpUaGFua3MsDQpFcmljDQoNCldpdGggUmVnYXJkcywNClJvaGl0IFINCg0KRnJvbTog RXJpYyBWb2l0IChldm9pdCkgW21haWx0bzpldm9pdEBjaXNjby5jb21dDQpTZW50OiAzMCBOb3Zl bWJlciAyMDE3IDIwOjMyDQpUbzogUm9oaXQgUiBSYW5hZGUgPHJvaGl0cnJhbmFkZUBodWF3ZWku Y29tPG1haWx0bzpyb2hpdHJyYW5hZGVAaHVhd2VpLmNvbT4+OyBBbGV4YW5kZXIgQ2xlbW0gPGFs ZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPG1haWx0bzphbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNv bT4+OyBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29y a3MuY29tPj47IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPG1haWx0bzptYmpAdGFp bC1mLmNvbT4+OyBrd2F0c2VuQGp1bmlwZXIubmV0PG1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0 PjsgUmFuZHkgUHJlc3VobiA8cmFuZHlfcHJlc3VobkBhbHVtbmkuc3RhbmZvcmQuZWR1PG1haWx0 bzpyYW5keV9wcmVzdWhuQGFsdW1uaS5zdGFuZm9yZC5lZHU+Pg0KQ2M6IE5ldGNvbmYgPG5ldGNv bmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IFtOZXRj b25mXSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0xMQ0KDQpIaSBSYW5k eSwNCkhpIFJvaGl0LA0KSGkgQWxleCwNCg0KVGhhbmtzIGZvciB0aGUgdGhvdWdodHMuDQoNClJh bmR5LCBvbiB5b3VyIHBvaW50OiBpdCBpcyB0cnVlIHByZXZpb3VzIHdvcmRpbmcgb2YgdGhlIFlB TkcgZGVzY3JpcHRpb24gY2FuIGJlIHRpZ2h0ZW5lZCB1cC4gIEFuZCB5b3VyIHBhcmFwaHJhc2lu ZyBmb3IgdGhlIFlBTkcgZGVzY3JpcHRpb24gcHJvdmlkZWQgZ29vZCBndWlkYW5jZS4gIEJlbG93 IEkgZ2l2ZSBhbiBhdHRlbXB0IHJlZnJhbWluZyB5YW5nIGRlc2NyaXB0aW9uLCBhbHNvIHRha2lu ZyBpbnRvIGFjY291bnQgQWxleCAmIFJvaGl04oCZcyBjb21tZW50cy4uLg0KDQpZQU5HIERlc2Ny aXB0aW9uDQoNClNwZWNpZmllcyB0aGUgbWluaW11bSBpbnRlcnZhbCBiZXR3ZWVuIHRoZSBhc3Nl bWJseSBvZiBzdWNjZXNzaXZlIHVwZGF0ZSByZWNvcmRzIGZvciBhIHNpbmdsZSByZWNlaXZlciBv ZiBhIHN1YnNjcmlwdGlvbi4gV2hlbmV2ZXIgc3Vic2NyaWJlZCBvYmplY3RzIGNoYW5nZSwgYW5k IGEgZGFtcGVuaW5nIHBlcmlvZCBpbnRlcnZhbCAod2hpY2ggbWF5IGJlIHplcm8pIGhhcyBlbGFw c2VkIHNpbmNlIHRoZSBwcmV2aW91cyB1cGRhdGUgcmVjb3JkIGNyZWF0aW9uIGZvciBhIHJlY2Vp dmVyLCB0aGVuIGFueSBzdWJzY3JpYmVkIG9iamVjdHMgYW5kIHByb3BlcnRpZXMgd2hpY2ggaGF2 ZSBjaGFuZ2VkIHNpbmNlIHRoZSBwcmV2aW91cyB1cGRhdGUgcmVjb3JkIHdpbGwgaGF2ZSB0aGVp ciBjdXJyZW50IHZhbHVlcyBtYXJzaGFsbGVkIGFuZCBwbGFjZWQgaW50byBhIG5ldyB1cGRhdGUg cmVjb3JkLg0KDQpSb2hpdCwgb24geW91ciBwb2ludDogdG8gY292ZXIgYW55IHN1Y2ggYSBwb3Nz aWJpbGl0eSwgaXQgbWlnaHQgYmUgYmV0dGVyIHRvIHJlc2V0IHRoZSBkYW1wZW5pbmcgcGVyaW9k IGFmdGVyIGEgc3BlY2lmaWMgdXBkYXRlIHJlY29yZCBpcyBhc3NlbWJsZWQuICAgVGhpcyB3YXkg YW55IGJ1bmRsaW5nIG9mIHVwZGF0ZXMgaW50byBub3RpZmljYXRpb24gbWVzc2FnZXMsIG9yIGZy YWdtZW50YXRpb24gZGVsYXlzIHdvbuKAmXQgcmVzdWx0IGluIGFuIGlycmVndWxhciBvciB1bnBy ZWRpY3RhYmxlIGRhbXBlbmluZyBwZXJpb2QuICAgTG9vayBiZWxvdyBhdCBteSBhdHRlbXB0IHRv IGZyYW1lIHRoaXMgd2l0aGluIFNlY3Rpb24gMy4xMCB0ZXh0Li4uDQoNCkFsZXgsIG9uIHlvdXIg cG9pbnQ6IHllcyB3ZSBuZWVkIHRvIGJlIGV4cGxpY2l0IGFib3V0IGp1c3QgdGhlIGxhc3QgdmFs dWUgYmVpbmcgc2VudC4gIEkgdHdlYWsgaXQgaW50byB0aGUgZGVzY3JpcHRpb24gaW4gdGhlIDMu MTAgYmVsb3cuICBJIHRoaW5rIEkgYWxzbyBjb3ZlcmVkIGluIGl0IHRoZSBZQU5HIGRlc2NyaXB0 aW9uIGFib3ZlLi4uDQoNClNlY3Rpb24gMy4xMA0KDQpEYW1wZW5pbmcgcGVyaW9kOiBJbiBhbiBv bi1jaGFuZ2Ugc3Vic2NyaXB0aW9uLCBkZXRlY3RlZCBvYmplY3QgY2hhbmdlcyBzaG91bGQgYmUg c2VudCBhcyBxdWlja2x5IGFzIHBvc3NpYmxlLiAgSG93ZXZlciBpdCBtYXkgYmUgdW5kZXNpcmFi bGUgdG8gc2VuZCBhIHJhcGlkIHNlcmllcyBvZiBvYmplY3QgY2hhbmdlcy4gIFN1Y2ggYmVoYXZp b3IgaGFzIHRoZSBwb3RlbnRpYWwgdG8gZXhoYXVzdCBvZiByZXNvdXJjZXMgaW4gdGhlIHB1Ymxp c2hlciBvciByZWNlaXZlci4gIEluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5zdCB0aGF0LCBhIGRh bXBlbmluZyBwZXJpb2QgTUFZIGJlIHVzZWQgdG8gc3BlY2lmeSB0aGUgaW50ZXJ2YWwgd2hpY2gg bXVzdCBwYXNzIGJlZm9yZSBzdWNjZXNzaXZlIHVwZGF0ZSByZWNvcmRzIGZvciB0aGUgc2FtZSBz dWJzY3JpcHRpb24gYXJlIGdlbmVyYXRlZCBmb3IgYSByZWNlaXZlci4gIFRoZSBkYW1wZW5pbmcg cGVyaW9kIGNvbGxlY3RpdmVseSBhcHBsaWVzIHRvIHRoZSBzZXQgb2YgYWxsIGRhdGEgbm9kZXMg c2VsZWN0ZWQgYnkgYSBzaW5nbGUgc3Vic2NyaXB0aW9uIGFuZCBzZW50IHRvIGEgc2luZ2xlIHJl Y2VpdmVyLiAgVGhpcyBtZWFucyB0aGF0IHdoZW4gdGhlcmUgaXMgYSBjaGFuZ2UgdG8gb25lIG9y IG1vcmUgc3Vic2NyaWJlZCBvYmplY3RzLCBhbiB1cGRhdGUgcmVjb3JkIGNvbnRhaW5pbmcgdGhv c2Ugb2JqZWN0cyBpcyBjcmVhdGVkIGVpdGhlciBpbW1lZGlhdGVseSB3aGVuIG5vIGRhbXBlbmlu ZyBwZXJpb2QgaXMgaW4gZWZmZWN0LCBvciBhdCB0aGUgZW5kIG9mIGEgZGFtcGVuaW5nIHBlcmlv ZC4gIElmIG11bHRpcGxlIGNoYW5nZXMgdG8gYSBzaW5nbGUgb2JqZWN0IG9jY3VyIGR1cmluZyBh IGRhbXBlbmluZyBwZXJpb2QsIG9ubHkgdGhlIHZhbHVlIHRoYXQgaXMgaW4gZWZmZWN0IGlzIGlu Y2x1ZGVkIGFzIHBhcnQgb2YgdGhlIHVwZGF0ZSByZWNvcmQuICBBIGRhbXBlbmluZyBwZXJpb2Qg aXMgcmVzZXQgZXZlcnkgdGltZSBhbiB1cGRhdGUgcmVjb3JkIGhhcyBjb21wbGV0ZWQgaXRzIGFz c2VtYmx5Lg0KDQoNCkVyaWMNCg0KRnJvbTogUm9oaXQgUiBSYW5hZGUsIE5vdmVtYmVyIDMwLCAy MDE3IDE6MzAgQU0NCkhpIEVyaWMsDQoNCldlIG5lZWQgYWxzbyBjb25zaWRlciB0aGF0IGNvbW1p dCBtYXliZSB2ZXJ5IGJpZyBvciBpbiB0aGUgZGFtcGVuaW5nIHRpbWUgc28gbWFueSByZWNvcmRz IGFyZSB1cGRhdGVkIHRoYXQgdGhlIDxub3RpZmljYXRpb24+IG1lc3NhZ2UgbWF5IG5lZWQgdG8g YmUgc3BsaXQgYWNyb3NzIGZyYWdtZW50cy4gIEkgc3VnZ2VzdCByZWZyYW1pbmcgb2YgdGhlIHNl bnRlbmNlIHRvDQoNCuKAnEEgZGFtcGVuaW5nIHBlcmlvZCBpcyByZXNldCBldmVyeSB0aW1lIHRo ZSBsYXN0IGZyYWdtZW50IG9mIGEgbmV3IG5vdGlmaWNhdGlvbiBtZXNzYWdlIGlzIHBhc3NlZCB0 byB0cmFuc3BvcnTigJ0NCg0KDQpXaXRoIFJlZ2FyZHMsDQpSb2hpdCBSDQoNCkZyb206IE5ldGNv bmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5k ZXIgQ2xlbW0NClNlbnQ6IDMwIE5vdmVtYmVyIDIwMTcgMDY6MjkNClRvOiBFcmljIFZvaXQgKGV2 b2l0KSA8ZXZvaXRAY2lzY28uY29tPG1haWx0bzpldm9pdEBjaXNjby5jb20+PjsgQW5keSBCaWVy bWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+OyBNYXJ0 aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+Pjsga3dh dHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4NCkNjOiBOZXRjb25m IDxuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPj4NClN1YmplY3Q6IFJl OiBbTmV0Y29uZl0gcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTENCg0K VGhpcyB3b3JrcyBmb3IgbWUuICBQZXJoYXBzIG9uZSBhZGRpdGlvbmFsIGl0ZW0gd2UgbWlnaHQg YWRkIChmb3IgY3J5c3RhbC1jbGVhciBjbGFyaWZpY2F0aW9uKSBpcyB0aGF0IHdoZW4gdGhlIG5v dGlmaWNhdGlvbiBtZXNzYWdlIGlzIHNlbnQsIGl0IGNvbnRhaW5zIHRoZSBtb3N0IHJlY2VudCB1 cGRhdGUgZm9yIHRoYXQgb2JqZWN0IChpLmUuIHRoZSB2YWx1ZSB0aGF0IGlzIGluIGVmZmVjdCB3 aGVuIHRoZSB1cGRhdGUgaXMgc2VudCkuICBJZiB0aGVyZSBhcmUgc29tZSBxdWlja2x5IG9zY2ls bGF0aW5nIHZhbHVlcyB3ZSBkb27igJl0IHNlbmQgdGhlIHdob2xlIHNlcXVlbmNlIG9mIHVwZGF0 ZXMvdmFsdWVzLg0KDQotLS0gQWxleA0KDQpGcm9tOiBFcmljIFZvaXQgKGV2b2l0KSBbbWFpbHRv OmV2b2l0QGNpc2NvLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjksIDIwMTcgNDo1 MSBQTQ0KVG86IEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb208bWFp bHRvOmFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPj47IEFuZHkgQmllcm1hbiA8YW5keUB5dW1h d29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+PjsgTWFydGluIEJqb3JrbHVuZCA8 bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj47IGt3YXRzZW5AanVuaXBlci5u ZXQ8bWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQ+DQpDYzogTmV0Y29uZiA8bmV0Y29uZkBpZXRm Lm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW05ldGNvbmZdIHJl dmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoLTExDQoNClRoZSBTZWN0aW9uIDMu MSB0ZXh0IEkgcHJvcG9zZWQgaW4gbXkgcmVzcG9uc2UgdG8gTWFydGluIG9uIHRoZSBkYW1wZW5p bmcgcXVlc3Rpb246DQoNCg0KRGFtcGVuaW5nIHBlcmlvZDogSW4gYW4gb24tY2hhbmdlIHN1YnNj cmlwdGlvbiwgZGV0ZWN0ZWQgb2JqZWN0IGNoYW5nZXMgc2hvdWxkIGJlIHNlbnQgYXMgcXVpY2ts eSBhcyBwb3NzaWJsZS4gIEhvd2V2ZXIgd2l0aG91dCBhZGVxdWF0ZSBwcm90ZWN0aW9ucywgYSBy YXBpZCBzZXJpZXMgb2Ygb2JqZWN0IGNoYW5nZXMgbWlnaHQgZXhoYXVzdCBvZiByZXNvdXJjZXMg aW4gdGhlIHB1Ymxpc2hlciBvciByZWNlaXZlci4gIEluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5z dCB0aGF0LCBhIGRhbXBlbmluZyBwZXJpb2QgTUFZIGJlIHVzZWQgdG8gc3BlY2lmeSB0aGUgaW50 ZXJ2YWwgd2hpY2ggbXVzdCBwYXNzIGJlZm9yZSBzdWNjZXNzaXZlIHVwZGF0ZSByZWNvcmRzIGZv ciB0aGUgc2FtZSBzdWJzY3JpcHRpb24gYXJlIGdlbmVyYXRlZCBmb3IgYSByZWNlaXZlci4gIFRo ZSBkYW1wZW5pbmcgcGVyaW9kIGNvbGxlY3RpdmVseSBhcHBsaWVzIHRvIHRoZSBzZXQgb2YgYWxs IGRhdGEgbm9kZXMgc2VsZWN0ZWQgYnkgYSBzaW5nbGUgc3Vic2NyaXB0aW9uIGFuZCBzZW50IHRv IGEgc2luZ2xlIHJlY2VpdmVyLiAgVGhpcyBtZWFucyB0aGF0IHdoZW4gdGhlcmUgaXMgYSBjaGFu Z2UgdG8gYSBzdWJzY3JpYmVkIG9iamVjdCwgYW4gdXBkYXRlIHJlY29yZCBjb250YWluaW5nIHRo YXQgb2JqZWN0IGlzIGNyZWF0ZWQgZWl0aGVyIGltbWVkaWF0ZWx5IHdoZW4gbm8gZGFtcGVuaW5n IHBlcmlvZCBpcyBpbiBlZmZlY3QsIG9yIGF0IHRoZSBlbmQgb2YgYSBkYW1wZW5pbmcgcGVyaW9k LiAgQSBkYW1wZW5pbmcgcGVyaW9kIGlzIHJlc2V0IGV2ZXJ5IHRpbWUgYSBuZXcgbm90aWZpY2F0 aW9uIG1lc3NhZ2UgaXMgcGFzc2VkIHRvIHRyYW5zcG9ydC4NCg0KDQoNCldpdGggdGhlIFlBTkcg ZGVzY3JpcHRpb24gb2Y6DQoNCg0KDQoiU3BlY2lmaWVzIHRoZSBpbnRlcnZhbCB3aGljaCBtdXN0 IHBhc3MgYmVmb3JlIHN1Y2Nlc3NpdmUgdXBkYXRlIHJlY29yZHMgZm9yIHRoZSBzYW1lIHN1YnNj cmlwdGlvbiBhcmUgZ2VuZXJhdGVkIGZvciBhIHJlY2VpdmVyLiAgVGhlIGRhbXBlbmluZyBwZXJp b2QgY29sbGVjdGl2ZWx5IGFwcGxpZXMgdG8gdGhlIHNldCBvZiBhbGwgZGF0YSBub2RlcyBzZWxl Y3RlZCBieSBhIHNpbmdsZSBzdWJzY3JpcHRpb24gYW5kIHNlbnQgdG8gYSBzaW5nbGUgcmVjZWl2 ZXIuICBUaGlzIG1lYW5zIHRoYXQgd2hlbiB0aGVyZSBpcyBhIGNoYW5nZSB0byBhIHN1YnNjcmli ZWQgb2JqZWN0LCBhbiB1cGRhdGUgcmVjb3JkIGNvbnRhaW5pbmcgdGhhdCBvYmplY3QgaXMgY3Jl YXRlZCBlaXRoZXIgaW1tZWRpYXRlbHkgd2hlbiBubyBkYW1wZW5pbmcgcGVyaW9kIGlzIGluIGVm ZmVjdCwgb3IgYXQgdGhlIGVuZCBvZiBhIGRhbXBlbmluZyBwZXJpb2QuICBBIGRhbXBlbmluZyBw ZXJpb2QgaXMgcmVzZXQgZXZlcnkgdGltZSBhIG5ldyBub3RpZmljYXRpb24gbWVzc2FnZSBpcyBw YXNzZWQgdG8gdHJhbnNwb3J0LiAgQSBkYW1wZW5pbmcgcGVyaW9kIGlzIHJlc2V0IGV2ZXJ5IHRp bWUgYSBuZXcgbm90aWZpY2F0aW9uIG1lc3NhZ2UgaXMgcGFzc2VkIHRvIHRyYW5zcG9ydC4gIEEg emVybyB2YWx1ZSBpbmRpY2F0ZXMgbm8gZGFtcGVuaW5nIHBlcmlvZCwgYW5kIGFsbCBzdWJzY3Jp YmVkIG9iamVjdCBjaGFuZ2VzIGFyZSBzZW50IGltbWVkaWF0ZWx5LiINCg0KDQoNCkRvZXMgdGhp cyB3b3JrIGZvciBldmVyeW9uZT8NCg0KRXJpYw0KDQoNCkZyb206IE5ldGNvbmYgW21haWx0bzpu ZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kZXIgQ2xlbW0NClNl bnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjksIDIwMTcgMzoxNyBQTQ0KVG86IEFuZHkgQmllcm1h biA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+PjsgTWFydGlu IEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj4NCkNjOiBO ZXRjb25mIDxuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPj4NClN1Ympl Y3Q6IFJlOiBbTmV0Y29uZl0gcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gt MTENCg0KSSB0aG91Z2h0IHdlIGRlY2lkZWQgdGhhdCB3ZSBoYXZlIGNvbWJpbmVkIGRhbXBlbmlu ZyBmb3IgYWxsIG9iamVjdHMgaW4gdGhlIHN1YnNjcmlwdGlvbi4gIEluIHRoaXMgY2FzZSwgd2Ug d291bGQgc2VuZCB1cGRhdGVzIGF0IDIsIDEyIChjb250YWluaW5nIDMsNCwxMSksIGFuZCAyMiAo Y29udGFpbmluZyAxMywgMTQsIDE1KS4NCg0KSWYgdGhlIHNjb3BlIG9mIHRoZSBzdWJzY3JpcHRp b24gYmVjb21lcyBzdWZmaWNpZW50bHkgbGFyZ2UsIHRoaXMgYWxtb3N0IHJldmVydHMgYmFjayB0 byBhIHBlcmlvZGljIHN1YnNjcmlwdGlvbiAoc2luY2UgdGhlcmUgaXMgYWx3YXlzIGdvaW5nIHRv IGJlIGEgY2hhbmdlIHNvbWV3aGVyZSkuICBUaGlzIGlzIHdoeSBJIG9yaWdpbmFsbHkgYXJndWVk IHRvIGhhdmUgaXQgaW5kZWVkIG9uIGEgcGVyLW9iamVjdCBiYXNpcywgYnV0IEkgbG9zdCB0aGF0 IGFyZ3VtZW50LiAgRm9yIHN1Y2ggZmluZS1ncmFpbmVkIHVwZGF0ZXMsIHdoZXJlIGEgY2xpZW50 IGlzIGluZGVlZCBpbnRlcmVzdCBpbiBnZXR0aW5nIGRlbGF5cyBvZiBpbmRpdmlkdWFsIG9iamVj dHMgd2l0aG91dCBkZWxheSwgIGEgY2xpZW50IGNvdWxkIHNpbXBseSBuZWVkIHRvIGVzdGFibGlz aCBtdWx0aXBsZSDigJxtaWNyb+KAnSBzdWJzY3JpcHRpb25zLg0KDQpUQ0FzIGluIFJNT04gYXJl IHNvbWV0aGluZyBkaWZmZXJlbnQgYWx0b2dldGhlci4gIFRoaXMgaXMgc29tZXRoaW5nIHdlIGFy ZSB0cnlpbmcgdG8gYWRkcmVzcyB3aXRoIHNtYXJ0IGZpbHRlcnMuDQoNCi0tLSBBbGV4DQoNCg0K RnJvbTogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEFuZHkgQmllcm1hbg0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyOSwgMjAxNyAxMDox OCBBTQ0KVG86IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPG1haWx0bzptYmpAdGFp bC1mLmNvbT4+DQpDYzogTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBp ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIHJldmlldyBvZiBkcmFmdC1pZXRmLW5l dGNvbmYteWFuZy1wdXNoLTExDQoNCg0KDQpPbiBUdWUsIE5vdiAyOCwgMjAxNyBhdCAxOjM3IEFN LCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+ PiB3cm90ZToNCkhpLA0KDQouLi4uDQoNCm8gIDMuMQ0KDQogIEknbSBub3Qgc3VyZSBJIHVuZGVy c3RhbmQgdGhlIGRhbXBlbmluZyBwZXJpb2QgY29uY2VwdC4gIExldCdzDQogIGFzc3VtZSB0aGF0 IHRoZSBkYW1wZW5pbmcgcGVyaW9kIGlzIDEwcy4gIFRoZW4gY2hhbmdlcyBoYXBwZW4gYXQNCiAg dGltZXM6DQoNCiAgICAyICAzICA0ICAxMSAgMTMgIDE0ICAxNQ0KDQogIEZyb20gdGhlIGRlc2Ny aXB0aW9uLCBpdCBzZWVtcyBJIHdvdWxkIHJlY2VpdmUgNCBub3RpZmljYXRpb25zLCBmcm9tDQog IHRpbWVzOg0KDQogICAgMiAgKGNvbnRhaW5pbmcgb25seSBjaGFuZ2UgZnJvbSAyKQ0KICAgIDEy IChjb250YWluaW5nIGNoYW5nZSBmcm9tIDMsNCwxMSkNCiAgICAxMyAoY29udGFpbmluZyBvbmx5 IGNoYW5nZSBmcm9tIDEzKQ0KICAgIDIzIChjb250YWluaW5nIGNoYW5nZXMgZnJvbSAxNCwxNSkN Cg0KICBJcyB0aGlzIGNvcnJlY3Q/DQoNCiAgSW4gYW55IGNhc2UsIEkgc3VnZ2VzdCB0aGUgZGVz Y3JpcHRpb24gaW4gdGhlIFlBTkcgbW9kdWxlIGlzDQogIGNsYXJpZmllZCAtIGN1cnJlbnRseSB0 aGUgUkZDIHRleHQgY29udGFpbnMgbW9yZSBkZXRhaWxzIHRoYW4gdGhlDQogIFlBTkcgbW9kdWxl Lg0KDQoNClNlZW1zIHRvIG1lIChmcm9tIGEgY2xpZW50IFBPVikgdGhhdCBJIHdhbnQgdGhlIGRh bXBlbmluZyB0byBhcHBseQ0KdG8gdGhlIGVudGlyZSBzdWJzY3JpcHRpb24sIG5vdCB0byBlYWNo IG5vZGUgd2l0aGluIHRoZSBzdWJzY3JpcHRpb24uDQpJIHdhbnQgImF0IG1vc3QsIDEgbm90aWZp Y2F0aW9uIHBlciBzZWNvbmQiLiAgSSBkb24ndCBzZWUgd2h5IEkgd291bGQgd2FudA0KdG8gYmUg dG9sZCBhYm91dCBhbiBpbmRpdmlkdWFsIGRhdGEgbm9kZSBvbmNlIHBlciBzZWNvbmQuICBJIGNv dWxkIHN0aWxsDQpnZXQgMTAsMDAwIGV2ZW50cy9zZWMgYnV0IGZvciBkaWZmZXJlbnQgZGF0YSBu b2Rlcy4gIFRoZSByZWNlaXZlciBkb2VzIG5vdA0KcmVhbGx5IGNhcmUgd2hldCBub2RlcyBhcmUg YmVpbmcgcmVwb3J0ZWQgaW4gZWFjaCBub3RpZmljYXRpb24uIFRoZSBnb2FsDQppcyB0byBzaW1w bHkgbGltaXQgdGhlIG5ldHdvcmsgYW5kIHByb2Nlc3NvciBsb2FkLg0KDQpGcm9tIGEgc2VydmVy IFBPViwgSSBkbyBub3Qgd2FudCBhIHRpbWVyIG9uIGV2ZXJ5IGRhdGEgbm9kZSBpbnN0YW5jZQ0K YW5kIGNvbXBsZXggY29kZSB0byBjb25zdHJ1Y3QgdGhlIG5leHQgb24tY2hhbmdlIG5vdGlmaWNh dGlvbi4NCg0KUk1PTiBoYW5kbGVzIGRhbXBlbmluZyB2ZXJ5IGRpZmZlcmVudGx5Lg0KVGhlIHJp c2luZyBhbmQgZmFsbGluZyB0aHJlc2hvbGRzIGFyZSB1c2VkIHRvIGFybSBhbmQgcmUtYXJtIGFu IGV2ZW50IHRyaWdnZXIuDQpUaGUgdGltZSBiZXR3ZWVuIGNoYW5nZXMgaXMgbm90IHVzZWQgYXQg YWxsIHRvIGRldGVybWluZSBob3cgbWFueSBldmVudHMgdG8gc2VuZC4NCihOb3Qgc3VnZ2VzdGlu ZyBhbGwgeWFuZy1wdXNoIHVzZS1jYXNlcyBhcmUgdGhyZXNob2xkLWJhc2VkLikNCg0KSU1PLCB0 aGUgb3BlcmF0b3Igc2hvdWxkIHB1dCBldmVudHMgdGhhdCByZXF1aXJlIGxvdy1sYXRlbmN5IGlu dG8gYSBzZXBhcmF0ZSBzdWJzY3JpcHRpb24sDQphbmQgdGhlIGRhbXBlbmluZyBwZXJpb2Qgc2hv dWxkIGFwcGx5IHRvIHRoZSBlbnRpcmUgc3Vic2NyaXB0aW9uLg0KDQogLi4uDQoNCg0KDQoNCi9t YXJ0aW4NCg0KDQpBbmR5DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnPG1haWx0 bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mDQoNCg== --_000_fe5996625ab448efa5f55af2f2a8089aXCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4 dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBh cmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0K CW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47 DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u UGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls U3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERl ZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNDQwMTgwOTQ0Ow0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNzYyNDI3OTk4IDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE1MTM2ODk4MzE7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi03NTMxMTM2ODAgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjQ0 LjBwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6ODAuMHB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJn aW4tbGVmdDoxMTYuMHB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE1Mi4wcHQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCW1hcmdpbi1sZWZ0OjE4OC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIy NC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjYwLjBwdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2lu LWxlZnQ6Mjk2LjBwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MzMyLjBwdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkhpIFJvaGl0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFJvaGl0IFIgUmFuYWRlLCBOb3Zl bWJlciAzMCwgMjAxNyAxMTowNyBQTTxicj4NCjxicj4NCjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+SGkgRXJpYyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPkluIHlvdXIgY2FzZSAsIHRoZW4gdGhlcmUgaXMgYSBjb3JuZXIgY2FzZSB3aGVyZSBpbiBp ZiB0aGUgZGFtcGVuaW5nIHBlcmlvZCBpcyBzaG9ydCwgdGhlIGRldmljZSBtYXkgaGF2ZSBzdGls bCBub3QgZmluaXNoZWQgc2VuZGluZw0KIGFsbCBpdHMgbm90aWZpY2F0aW9uIGZyYWdtZW50cyBh bmQgdGhlIG5leHQgdXBkYXRlIHJlY29yZCBpcyBhbHJlYWR5IHJlYWR5IHRvIGdldCBhc3NlbWJs ZWQuJm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+Jmx0O0VyaWMmZ3Q7IFllcywgdGhpcyBjb3JuZXIgY2FzZSBpcyBj b21tb24gYWNyb3NzIGFsbCBzb2x1dGlvbnMsIGluY2x1ZGluZyBwZXJpb2RpYyBzdWJzY3JpcHRp b25zLiZuYnNwOyAmbmJzcDsoRS5nLiwgV2hhdCBpZiBhIHJvdXRpbmcgdGFibGUgZ2V0cyBiaWdn ZXIgYWxsIG9mDQogYSBzdWRkZW4/Jm5ic3A7IFdoYXQgaWYgYSBrZXkgcHVibGlzaGVyIHByb2Nl c3MgaXMgdGFraW5nIGxvdHMgb2YgQ1BVPykmbmJzcDsgJm5ic3A7VGhlIHF1ZXN0aW9uIGlzIHdo YXQgaXMgdGhlIGxldmVsIG9mIGV4cG9zdXJlIHRoZSBhZG1pc3Npb24gY29udHJvbCBwcm9jZXNz IHBlcm1pdHMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5XaGV0aGVyIHdlIGNhbiBoYXZl IGEgbG93ZXIgbGltaXQgb24gdGhlIGRhbXBlbmluZyBwZXJpb2QgaW50ZXJ2YWwgdG8gYXZvaWQg c3VjaCBhIHNjZW5hcmlvID8gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZsdDtFcmljJmd0OyBZZXMsIGEg bG93ZXIgbGltaXQgb24gdGhlIGRhbXBlbmluZyBwZXJpb2QgaXMgYSBwb3RlbnRpYWwgd2F5IHRv IGFwcHJvYWNoIHRoaXMuJm5ic3A7IEJ1dCBJIGJlbGlldmUgdGhlcmUgdG8gYmUgYSBmZXcgaXNz dWVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6NDQuMHB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBs ZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoZSBtYXhpbXVtIGxhdGVuY3kgaW4gc2Vl aW5nIGEgY2hhbmdlIChhcyBkZXRlcm1pbmVkIGJ5IHdoZW4gYSBwdXNoLWNoYW5nZS11cGRhdGUg aXMgYXNzZW1ibGVkKSB3b3VsZCBub3QgYmUgZGV0ZXJtaW5pc3RpYyB0byBhcHBsaWNhdGlvbnMu Jm5ic3A7DQogVGhpcyBwb3NzaWJpbGl0eSB3b3VsZCBoYXZlIHRvIGJlIGFjY291bnRlZCBmb3Ig d2hlbiBkZXNpZ25pbmcgYXBwbGljYXRpb24gYmVoYXZpb3IuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo0NC4wcHQ7 dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJv bDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+SXQgd291bGQgbm90IGJlIGVhc3kgZm9yIGEgcmVjZWl2ZXIgYXBwbGljYXRpb24gdG8g ZGlzdGluZ3Vpc2ggd2hlbiBkYW1wZW5pbmcgcGVyaW9kcyBhcmUgZGVncmFkaW5nIGxvbmdlciBh bmQgbG9uZ2VyLiZuYnNwOyBBbmQgdGhpcyB3aWxsIGxpa2VseQ0KIGJlIGR1ZSB0byBDUFUvb3Ro ZXIgaW1wYWN0cyBvbiB0aGUgcHVibGlzaGVyIHdoaWNoIGFyZSBpbnZpc2libGUgdG8gdGhlIHJl Y2VpdmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NDQuMHB0O3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps MSBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkEgcGVyaW9kaWMgc3Vic2NyaXB0aW9u IG1pZ2h0IGFsc28gaGF2ZSB0aGUgZGVsYXllZCBhc3NlbWJseSBwcm9ibGVtLCBhbmQgd2UgY2Fu 4oCZdCBkZWxheSB0aG9zZSB1cGRhdGVzLiZuYnNwOyBTbyB0aGUgYW55IHNvbHV0aW9uIGFwcHJv YWNoIGZvcg0KIGJvdGggb24tY2hhbmdlICZhbXA7IHBlcmlvZGljIGNvdWxkbuKAmXQgYmUgY29t bW9uIGJldHdlZW4gdGhlIHR3by48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjQ0LjBwdDt0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5BIGxvbmdlciBh bmQgbG9uZ2VyIGFzc2VtYmx5IHdpbmRvdyBtYWtlcyBpdCBoYXJkZXIgdG8gZW5zdXJlIHRoZSBp bmNsdWRlZCBwYXRjaCBvcGVyYXRpb25zIGFsbCBjYW4gYmUgdGFnZ2VkIHdpdGggdGhlIHNhbWUg dGltZS1vZi11cGRhdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoZXJlIGFyZSBjdXJyZW50bHkgbWVjaGFuaXNt cyBpbiB0aGUgc29sdXRpb24gdG8gZGVhbCB3aXRoIHRoZSBjb3JuZXIgY2FzZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj7igJx1 cGRhdGVzLW5vdC1zZW50IGZsYWfigJ0sIHdoaWNoIGhhcyB0aGUgc2FtZSBtZWFuaW5nIGZvciBi b3RoIHB1c2gtdXBkYXRlcyBhbmQgcHVzaC1jaGFuZ2UtdXBkYXRlcy4mbmJzcDsgKEFuZCB3aGlj aCB3b3VsZCBzdGlsbCBiZSBuZWVkZWQgaWYNCiB3ZSBtYWRlIHRoZSBkYW1wZW5pbmcgJm5ic3A7 cGVyaW9kIGEgbG93ZXIgbGltaXQuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxl dmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpTeW1ib2w7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlN1c3BlbmRpbmcgYSBzdWJzY3JpcHRpb24gd2l0 aCB0aGUg4oCcZGF0YXRyZWUtc2l6ZeKAnSBpZGVudGlmaWVkIGFzIGFuIGlzc3VlIChhbHNvIHRo ZSBzYW1lIGZvciBwZXJpb2RpYyAmYW1wOyBvbi1jaGFuZ2UpPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+VGhlIHJlc3luY2ggUlBD LCB3aGljaCBjYW4gYmUgaW52b2tlZCBhcyBuZWVkZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlNvIGFzIHRoZXJl IGFyZSBpbnRlcmVzdGluZyBhc3BlY3RzIHRvIHlvdXIg4oCcbG93ZXIgbGltaXTigJ0gcHJvcG9z YWwsIGJ1dCBpdCBoYXMgdW5leHBsb3JlZCBpbXBhY3RzIGZyb20gdGhlIHBvaW50IG9mIHZpZXcg b2YgZXhwZWN0ZWQgYmVoYXZpb3IgYXMNCiBzZWVuIGJ5IGFwcGxpY2F0aW9ucywgbXkgcmVjb21t ZW5kYXRpb24gd291bGQgYmUgdG8gbG9vayBhdCB0aGlzIGFzIHBvc3NpYmxlIGZvbGxvdy1vbiB3 b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5F cmljPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+V2l0aCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Sb2hpdCBSPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiBFcmljIFZv aXQgKGV2b2l0KSBbPGEgaHJlZj0ibWFpbHRvOmV2b2l0QGNpc2NvLmNvbSI+bWFpbHRvOmV2b2l0 QGNpc2NvLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMzAgTm92ZW1iZXIgMjAxNyAyMDoz Mjxicj4NCjxiPlRvOjwvYj4gUm9oaXQgUiBSYW5hZGUgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2hp dHJyYW5hZGVAaHVhd2VpLmNvbSI+cm9oaXRycmFuYWRlQGh1YXdlaS5jb208L2E+Jmd0OzsgQWxl eGFuZGVyIENsZW1tICZsdDs8YSBocmVmPSJtYWlsdG86YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5j b20iPmFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPC9hPiZndDs7IEFuZHkgQmllcm1hbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSI+YW5keUB5dW1hd29ya3MuY29tPC9h PiZndDs7DQogTWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYu Y29tIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7OyA8YSBocmVmPSJtYWlsdG86a3dhdHNlbkBqdW5p cGVyLm5ldCI+DQprd2F0c2VuQGp1bmlwZXIubmV0PC9hPjsgUmFuZHkgUHJlc3VobiAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJhbmR5X3ByZXN1aG5AYWx1bW5pLnN0YW5mb3JkLmVkdSI+cmFuZHlfcHJl c3VobkBhbHVtbmkuc3RhbmZvcmQuZWR1PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IE5ldGNvbmYg Jmx0OzxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtOZXRjb25mXSByZXZpZXcgb2YgZHJhZnQt aWV0Zi1uZXRjb25mLXlhbmctcHVzaC0xMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5IaSBSYW5keSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+SGkgUm9oaXQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPkhpIEFsZXgsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGFu a3MgZm9yIHRoZSB0aG91Z2h0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPlJhbmR5LCBvbiB5b3VyIHBvaW50OiBpdCBpcyB0cnVlIHByZXZpb3VzIHdvcmRpbmcgb2Yg dGhlIFlBTkcgZGVzY3JpcHRpb24gY2FuIGJlIHRpZ2h0ZW5lZCB1cC4mbmJzcDsgQW5kIHlvdXIg cGFyYXBocmFzaW5nIGZvciB0aGUgWUFORw0KIGRlc2NyaXB0aW9uIHByb3ZpZGVkIGdvb2QgZ3Vp ZGFuY2UuJm5ic3A7IEJlbG93IEkgZ2l2ZSBhbiBhdHRlbXB0IHJlZnJhbWluZyB5YW5nIGRlc2Ny aXB0aW9uLCBhbHNvIHRha2luZyBpbnRvIGFjY291bnQgQWxleCAmYW1wOyBSb2hpdOKAmXMgY29t bWVudHMuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5i c3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LjVpbiI+PHU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5ZQU5HIERlc2NyaXB0aW9uPG86cD48L286cD48L3NwYW4+PC91PjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlNwZWNpZmllcyB0aGUgbWluaW11bSBpbnRlcnZh bCBiZXR3ZWVuIHRoZSBhc3NlbWJseSBvZiBzdWNjZXNzaXZlIHVwZGF0ZSByZWNvcmRzIGZvciBh IHNpbmdsZSByZWNlaXZlciBvZiBhIHN1YnNjcmlwdGlvbi4gV2hlbmV2ZXIgc3Vic2NyaWJlZCBv YmplY3RzIGNoYW5nZSwgYW5kIGEgZGFtcGVuaW5nDQogcGVyaW9kIGludGVydmFsICh3aGljaCBt YXkgYmUgemVybykgaGFzIGVsYXBzZWQgc2luY2UgdGhlIHByZXZpb3VzIHVwZGF0ZSByZWNvcmQg Y3JlYXRpb24gZm9yIGEgcmVjZWl2ZXIsIHRoZW4gYW55IHN1YnNjcmliZWQgb2JqZWN0cyBhbmQg cHJvcGVydGllcyB3aGljaCBoYXZlIGNoYW5nZWQgc2luY2UgdGhlIHByZXZpb3VzIHVwZGF0ZSBy ZWNvcmQgd2lsbCBoYXZlIHRoZWlyIGN1cnJlbnQgdmFsdWVzIG1hcnNoYWxsZWQgYW5kIHBsYWNl ZCBpbnRvDQogYSBuZXcgdXBkYXRlIHJlY29yZC48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Um9oaXQsIG9u IHlvdXIgcG9pbnQ6IHRvIGNvdmVyIGFueSBzdWNoIGEgcG9zc2liaWxpdHksIGl0IG1pZ2h0IGJl IGJldHRlciB0byByZXNldCB0aGUgZGFtcGVuaW5nIHBlcmlvZCBhZnRlciBhIHNwZWNpZmljIHVw ZGF0ZSByZWNvcmQNCiBpcyBhc3NlbWJsZWQuJm5ic3A7Jm5ic3A7IFRoaXMgd2F5IGFueSBidW5k bGluZyBvZiB1cGRhdGVzIGludG8gbm90aWZpY2F0aW9uIG1lc3NhZ2VzLCBvciBmcmFnbWVudGF0 aW9uIGRlbGF5cyB3b27igJl0IHJlc3VsdCBpbiBhbiBpcnJlZ3VsYXIgb3IgdW5wcmVkaWN0YWJs ZSBkYW1wZW5pbmcgcGVyaW9kLiZuYnNwOyZuYnNwOyBMb29rIGJlbG93IGF0IG15IGF0dGVtcHQg dG8gZnJhbWUgdGhpcyB3aXRoaW4gU2VjdGlvbiAzLjEwIHRleHQuLi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkFsZXgsIG9uIHlvdXIgcG9pbnQ6IHllcyB3ZSBuZWVk IHRvIGJlIGV4cGxpY2l0IGFib3V0IGp1c3QgdGhlIGxhc3QgdmFsdWUgYmVpbmcgc2VudC4mbmJz cDsgSSB0d2VhayBpdCBpbnRvIHRoZSBkZXNjcmlwdGlvbiBpbiB0aGUgMy4xMA0KIGJlbG93LiZu YnNwOyBJIHRoaW5rIEkgYWxzbyBjb3ZlcmVkIGluIGl0IHRoZSBZQU5HIGRlc2NyaXB0aW9uIGFi b3ZlLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48dT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPlNlY3Rpb24gMy4xMDxvOnA+PC9vOnA+PC9zcGFuPjwvdT48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj5EYW1wZW5pbmcgcGVyaW9kOiBJbiBhbiBvbi1jaGFuZ2Ugc3Vi c2NyaXB0aW9uLCBkZXRlY3RlZCBvYmplY3QgY2hhbmdlcyBzaG91bGQgYmUgc2VudCBhcyBxdWlj a2x5IGFzIHBvc3NpYmxlLiZuYnNwOyBIb3dldmVyIGl0IG1heSBiZSB1bmRlc2lyYWJsZSB0byBz ZW5kIGEgcmFwaWQgc2VyaWVzIG9mDQogb2JqZWN0IGNoYW5nZXMuJm5ic3A7IFN1Y2ggYmVoYXZp b3IgaGFzIHRoZSBwb3RlbnRpYWwgdG8gZXhoYXVzdCBvZiByZXNvdXJjZXMgaW4gdGhlIHB1Ymxp c2hlciBvciByZWNlaXZlci4mbmJzcDsgSW4gb3JkZXIgdG8gcHJvdGVjdCBhZ2FpbnN0IHRoYXQs IGEgZGFtcGVuaW5nIHBlcmlvZCBNQVkgYmUgdXNlZCB0byBzcGVjaWZ5IHRoZSBpbnRlcnZhbCB3 aGljaCBtdXN0IHBhc3MgYmVmb3JlIHN1Y2Nlc3NpdmUgdXBkYXRlIHJlY29yZHMgZm9yIHRoZSBz YW1lIHN1YnNjcmlwdGlvbg0KIGFyZSBnZW5lcmF0ZWQgZm9yIGEgcmVjZWl2ZXIuJm5ic3A7IFRo ZSBkYW1wZW5pbmcgcGVyaW9kIGNvbGxlY3RpdmVseSBhcHBsaWVzIHRvIHRoZSBzZXQgb2YgYWxs IGRhdGEgbm9kZXMgc2VsZWN0ZWQgYnkgYSBzaW5nbGUgc3Vic2NyaXB0aW9uIGFuZCBzZW50IHRv IGEgc2luZ2xlIHJlY2VpdmVyLiZuYnNwOyBUaGlzIG1lYW5zIHRoYXQgd2hlbiB0aGVyZSBpcyBh IGNoYW5nZSB0byBvbmUgb3IgbW9yZSBzdWJzY3JpYmVkIG9iamVjdHMsIGFuIHVwZGF0ZSByZWNv cmQNCiBjb250YWluaW5nIHRob3NlIG9iamVjdHMgaXMgY3JlYXRlZCBlaXRoZXIgaW1tZWRpYXRl bHkgd2hlbiBubyBkYW1wZW5pbmcgcGVyaW9kIGlzIGluIGVmZmVjdCwgb3IgYXQgdGhlIGVuZCBv ZiBhIGRhbXBlbmluZyBwZXJpb2QuJm5ic3A7IElmIG11bHRpcGxlIGNoYW5nZXMgdG8gYSBzaW5n bGUgb2JqZWN0IG9jY3VyIGR1cmluZyBhIGRhbXBlbmluZyBwZXJpb2QsIG9ubHkgdGhlIHZhbHVl IHRoYXQgaXMgaW4gZWZmZWN0IGlzIGluY2x1ZGVkIGFzIHBhcnQNCiBvZiB0aGUgdXBkYXRlIHJl Y29yZC4mbmJzcDsgQSBkYW1wZW5pbmcgcGVyaW9kIGlzIHJlc2V0IGV2ZXJ5IHRpbWUgYW4gdXBk YXRlIHJlY29yZCBoYXMgY29tcGxldGVkIGl0cyBhc3NlbWJseS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj5FcmljPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiBSb2hpdA0KIFIgUmFuYWRlLCBOb3ZlbWJlciAz MCwgMjAxNyAxOjMwIEFNPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj5IaSBFcmljLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+V2UgbmVlZCBhbHNvIGNvbnNpZGVyIHRoYXQgY29tbWl0IG1heWJlIHZlcnkg YmlnIG9yIGluIHRoZSBkYW1wZW5pbmcgdGltZSBzbyBtYW55IHJlY29yZHMgYXJlIHVwZGF0ZWQg dGhhdCB0aGUgJmx0O25vdGlmaWNhdGlvbiZndDsgbWVzc2FnZQ0KIG1heSBuZWVkIHRvIGJlIHNw bGl0IGFjcm9zcyBmcmFnbWVudHMuICZuYnNwO0kgc3VnZ2VzdCByZWZyYW1pbmcgb2YgdGhlIHNl bnRlbmNlIHRvIDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+4oCcQSBkYW1wZW5pbmcgcGVyaW9k IGlzIHJlc2V0IGV2ZXJ5IHRpbWUgdGhlIGxhc3QgZnJhZ21lbnQgb2YgYSBuZXcgbm90aWZpY2F0 aW9uIG1lc3NhZ2UgaXMgcGFzc2VkIHRvIHRyYW5zcG9ydOKAnSZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+V2l0aCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Sb2hpdCBSPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiBOZXRjb25m IFs8YSBocmVmPSJtYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86bmV0Y29u Zi1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWxleGFuZGVyIENs ZW1tPGJyPg0KPGI+U2VudDo8L2I+IDMwIE5vdmVtYmVyIDIwMTcgMDY6Mjk8YnI+DQo8Yj5Ubzo8 L2I+IEVyaWMgVm9pdCAoZXZvaXQpICZsdDs8YSBocmVmPSJtYWlsdG86ZXZvaXRAY2lzY28uY29t Ij5ldm9pdEBjaXNjby5jb208L2E+Jmd0OzsgQW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWls dG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0OzsgTWFydGlu IEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIj5tYmpAdGFpbC1m LmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQiPmt3YXRz ZW5AanVuaXBlci5uZXQ8L2E+PGJyPg0KPGI+Q2M6PC9iPiBOZXRjb25mICZsdDs8YSBocmVmPSJt YWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi15 YW5nLXB1c2gtMTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+VGhpcyB3 b3JrcyBmb3IgbWUuJm5ic3A7IFBlcmhhcHMgb25lIGFkZGl0aW9uYWwgaXRlbSB3ZSBtaWdodCBh ZGQgKGZvciBjcnlzdGFsLWNsZWFyIGNsYXJpZmljYXRpb24pIGlzIHRoYXQgd2hlbiB0aGUgbm90 aWZpY2F0aW9uIG1lc3NhZ2UNCiBpcyBzZW50LCBpdCBjb250YWlucyB0aGUgbW9zdCByZWNlbnQg dXBkYXRlIGZvciB0aGF0IG9iamVjdCAoaS5lLiB0aGUgdmFsdWUgdGhhdCBpcyBpbiBlZmZlY3Qg d2hlbiB0aGUgdXBkYXRlIGlzIHNlbnQpLiZuYnNwOyBJZiB0aGVyZSBhcmUgc29tZSBxdWlja2x5 IG9zY2lsbGF0aW5nIHZhbHVlcyB3ZSBkb27igJl0IHNlbmQgdGhlIHdob2xlIHNlcXVlbmNlIG9m IHVwZGF0ZXMvdmFsdWVzLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj4tLS0gQWxleA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4gRXJp YyBWb2l0IChldm9pdCkgWzxhIGhyZWY9Im1haWx0bzpldm9pdEBjaXNjby5jb20iPm1haWx0bzpl dm9pdEBjaXNjby5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTm92ZW1i ZXIgMjksIDIwMTcgNDo1MSBQTTxicj4NCjxiPlRvOjwvYj4gQWxleGFuZGVyIENsZW1tICZsdDs8 YSBocmVmPSJtYWlsdG86YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20iPmFsZXhhbmRlci5jbGVt bUBodWF3ZWkuY29tPC9hPiZndDs7IEFuZHkgQmllcm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFu ZHlAeXVtYXdvcmtzLmNvbSI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZndDs7IE1hcnRpbiBCam9y a2x1bmQgJmx0OzxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSI+bWJqQHRhaWwtZi5jb208 L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0Ij5rd2F0c2VuQGp1 bmlwZXIubmV0PC9hPjxicj4NCjxiPkNjOjwvYj4gTmV0Y29uZiAmbHQ7PGEgaHJlZj0ibWFpbHRv Om5ldGNvbmZAaWV0Zi5vcmciPm5ldGNvbmZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSRTogW05ldGNvbmZdIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1w dXNoLTExPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoZSBTZWN0aW9u IDMuMSB0ZXh0IEkgcHJvcG9zZWQgaW4gbXkgcmVzcG9uc2UgdG8gTWFydGluIG9uIHRoZSBkYW1w ZW5pbmcgcXVlc3Rpb246PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RGFtcGVuaW5nIHBlcmlv ZDogSW4gYW4gb24tY2hhbmdlIHN1YnNjcmlwdGlvbiwgZGV0ZWN0ZWQgb2JqZWN0IGNoYW5nZXMg c2hvdWxkIGJlIHNlbnQgYXMgcXVpY2tseSBhcyBwb3NzaWJsZS4mbmJzcDsgSG93ZXZlciB3aXRo b3V0IGFkZXF1YXRlIHByb3RlY3Rpb25zLCBhIHJhcGlkIHNlcmllcyBvZiBvYmplY3QgY2hhbmdl cyBtaWdodCBleGhhdXN0DQogb2YgcmVzb3VyY2VzIGluIHRoZSBwdWJsaXNoZXIgb3IgcmVjZWl2 ZXIuJm5ic3A7IEluIG9yZGVyIHRvIHByb3RlY3QgYWdhaW5zdCB0aGF0LCBhIGRhbXBlbmluZyBw ZXJpb2QgTUFZIGJlIHVzZWQgdG8gc3BlY2lmeSB0aGUgaW50ZXJ2YWwgd2hpY2ggbXVzdCBwYXNz IGJlZm9yZSBzdWNjZXNzaXZlIHVwZGF0ZSByZWNvcmRzIGZvciB0aGUgc2FtZSBzdWJzY3JpcHRp b24gYXJlIGdlbmVyYXRlZCBmb3IgYSByZWNlaXZlci4mbmJzcDsgVGhlIGRhbXBlbmluZyBwZXJp b2QNCiBjb2xsZWN0aXZlbHkgYXBwbGllcyB0byB0aGUgc2V0IG9mIGFsbCBkYXRhIG5vZGVzIHNl bGVjdGVkIGJ5IGEgc2luZ2xlIHN1YnNjcmlwdGlvbiBhbmQgc2VudCB0byBhIHNpbmdsZSByZWNl aXZlci4mbmJzcDsgVGhpcyBtZWFucyB0aGF0IHdoZW4gdGhlcmUgaXMgYSBjaGFuZ2UgdG8gYSBz dWJzY3JpYmVkIG9iamVjdCwgYW4gdXBkYXRlIHJlY29yZCBjb250YWluaW5nIHRoYXQgb2JqZWN0 IGlzIGNyZWF0ZWQgZWl0aGVyIGltbWVkaWF0ZWx5IHdoZW4gbm8NCiBkYW1wZW5pbmcgcGVyaW9k IGlzIGluIGVmZmVjdCwgb3IgYXQgdGhlIGVuZCBvZiBhIGRhbXBlbmluZyBwZXJpb2QuJm5ic3A7 IEEgZGFtcGVuaW5nIHBlcmlvZCBpcyByZXNldCBldmVyeSB0aW1lIGEgbmV3IG5vdGlmaWNhdGlv biBtZXNzYWdlIGlzIHBhc3NlZCB0byB0cmFuc3BvcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj5XaXRoIHRoZSBZQU5HIGRlc2NyaXB0aW9uIG9mOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij4mcXVvdDtTcGVjaWZpZXMgdGhlIGludGVydmFsIHdoaWNoIG11c3QgcGFzcyBiZWZvcmUgc3Vj Y2Vzc2l2ZSB1cGRhdGUgcmVjb3JkcyBmb3IgdGhlIHNhbWUgc3Vic2NyaXB0aW9uIGFyZSBnZW5l cmF0ZWQgZm9yIGEgcmVjZWl2ZXIuJm5ic3A7IFRoZSBkYW1wZW5pbmcgcGVyaW9kIGNvbGxlY3Rp dmVseSBhcHBsaWVzIHRvIHRoZSBzZXQgb2YgYWxsIGRhdGENCiBub2RlcyBzZWxlY3RlZCBieSBh IHNpbmdsZSBzdWJzY3JpcHRpb24gYW5kIHNlbnQgdG8gYSBzaW5nbGUgcmVjZWl2ZXIuJm5ic3A7 IFRoaXMgbWVhbnMgdGhhdCB3aGVuIHRoZXJlIGlzIGEgY2hhbmdlIHRvIGEgc3Vic2NyaWJlZCBv YmplY3QsIGFuIHVwZGF0ZSByZWNvcmQgY29udGFpbmluZyB0aGF0IG9iamVjdCBpcyBjcmVhdGVk IGVpdGhlciBpbW1lZGlhdGVseSB3aGVuIG5vIGRhbXBlbmluZyBwZXJpb2QgaXMgaW4gZWZmZWN0 LCBvciBhdCB0aGUgZW5kDQogb2YgYSBkYW1wZW5pbmcgcGVyaW9kLiZuYnNwOyBBIGRhbXBlbmlu ZyBwZXJpb2QgaXMgcmVzZXQgZXZlcnkgdGltZSBhIG5ldyBub3RpZmljYXRpb24gbWVzc2FnZSBp cyBwYXNzZWQgdG8gdHJhbnNwb3J0LiZuYnNwOyBBIGRhbXBlbmluZyBwZXJpb2QgaXMgcmVzZXQg ZXZlcnkgdGltZSBhIG5ldyBub3RpZmljYXRpb24gbWVzc2FnZSBpcyBwYXNzZWQgdG8gdHJhbnNw b3J0LiZuYnNwOyBBIHplcm8gdmFsdWUgaW5kaWNhdGVzIG5vIGRhbXBlbmluZyBwZXJpb2QsIGFu ZCBhbGwNCiBzdWJzY3JpYmVkIG9iamVjdCBjaGFuZ2VzIGFyZSBzZW50IGltbWVkaWF0ZWx5LiZx dW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkRvZXMgdGhpcyB3b3JrIGZvciBldmVyeW9u ZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PGJyPg0KRXJp YzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiBOZXRjb25mIFs8YSBocmVmPSJtYWlsdG86 bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QWxleGFuZGVyIENsZW1tPGJyPg0KPGI+U2VudDo8 L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgMjksIDIwMTcgMzoxNyBQTTxicj4NCjxiPlRvOjwvYj4g QW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5 QHl1bWF3b3Jrcy5jb208L2E+Jmd0OzsgTWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1iakB0YWlsLWYuY29tIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBOZXRjb25mICZsdDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBp ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0Y29uZl0gcmV2aWV3 IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+SSB0aG91Z2h0IHdlIGRlY2lkZWQgdGhhdCB3ZSBoYXZlIGNvbWJp bmVkIGRhbXBlbmluZyBmb3IgYWxsIG9iamVjdHMgaW4gdGhlIHN1YnNjcmlwdGlvbi4mbmJzcDsg SW4gdGhpcyBjYXNlLCB3ZSB3b3VsZCBzZW5kIHVwZGF0ZXMgYXQgMiwNCiAxMiAoY29udGFpbmlu ZyAzLDQsMTEpLCBhbmQgMjIgKGNvbnRhaW5pbmcgMTMsIDE0LCAxNSkuIDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SWYgdGhlIHNjb3BlIG9mIHRoZSBzdWJzY3JpcHRp b24gYmVjb21lcyBzdWZmaWNpZW50bHkgbGFyZ2UsIHRoaXMgYWxtb3N0IHJldmVydHMgYmFjayB0 byBhIHBlcmlvZGljIHN1YnNjcmlwdGlvbiAoc2luY2UgdGhlcmUgaXMgYWx3YXlzDQogZ29pbmcg dG8gYmUgYSBjaGFuZ2Ugc29tZXdoZXJlKS4mbmJzcDsgVGhpcyBpcyB3aHkgSSBvcmlnaW5hbGx5 IGFyZ3VlZCB0byBoYXZlIGl0IGluZGVlZCBvbiBhIHBlci1vYmplY3QgYmFzaXMsIGJ1dCBJIGxv c3QgdGhhdCBhcmd1bWVudC4mbmJzcDsgRm9yIHN1Y2ggZmluZS1ncmFpbmVkIHVwZGF0ZXMsIHdo ZXJlIGEgY2xpZW50IGlzIGluZGVlZCBpbnRlcmVzdCBpbiBnZXR0aW5nIGRlbGF5cyBvZiBpbmRp dmlkdWFsIG9iamVjdHMgd2l0aG91dCBkZWxheSwgJm5ic3A7YQ0KIGNsaWVudCBjb3VsZCBzaW1w bHkgbmVlZCB0byBlc3RhYmxpc2ggbXVsdGlwbGUg4oCcbWljcm/igJ0gc3Vic2NyaXB0aW9ucy4m bmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UQ0FzIGluIFJN T04gYXJlIHNvbWV0aGluZyBkaWZmZXJlbnQgYWx0b2dldGhlci4mbmJzcDsgVGhpcyBpcyBzb21l dGhpbmcgd2UgYXJlIHRyeWluZyB0byBhZGRyZXNzIHdpdGggc21hcnQgZmlsdGVycy4mbmJzcDsN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+LS0tIEFsZXg8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj4gTmV0Y29uZiBbPGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYt Ym91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHkgQmllcm1hbjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNk YXksIE5vdmVtYmVyIDI5LCAyMDE3IDEwOjE4IEFNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gQmpv cmtsdW5kICZsdDs8YSBocmVmPSJtYWlsdG86bWJqQHRhaWwtZi5jb20iPm1iakB0YWlsLWYuY29t PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IE5ldGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRj b25mQGlldGYub3JnIj5uZXRjb25mQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtOZXRjb25mXSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0x MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i Pk9uIFR1ZSwgTm92IDI4LCAyMDE3IGF0IDE6MzcgQU0sIE1hcnRpbiBCam9ya2x1bmQgJmx0Ozxh IGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1iakB0YWlsLWYu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+SGksPGJyPg0KPGJyPg0KLi4uLjxicj4NCjxicj4NCm8mbmJzcDsgMy4xPGJy Pg0KPGJyPg0KJm5ic3A7IEknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhlIGRhbXBlbmluZyBw ZXJpb2QgY29uY2VwdC4mbmJzcDsgTGV0J3M8YnI+DQombmJzcDsgYXNzdW1lIHRoYXQgdGhlIGRh bXBlbmluZyBwZXJpb2QgaXMgMTBzLiZuYnNwOyBUaGVuIGNoYW5nZXMgaGFwcGVuIGF0PGJyPg0K Jm5ic3A7IHRpbWVzOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgMiZuYnNwOyAzJm5ic3A7IDQm bmJzcDsgMTEmbmJzcDsgMTMmbmJzcDsgMTQmbmJzcDsgMTU8YnI+DQo8YnI+DQombmJzcDsgRnJv bSB0aGUgZGVzY3JpcHRpb24sIGl0IHNlZW1zIEkgd291bGQgcmVjZWl2ZSA0IG5vdGlmaWNhdGlv bnMsIGZyb208YnI+DQombmJzcDsgdGltZXM6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAyJm5i c3A7IChjb250YWluaW5nIG9ubHkgY2hhbmdlIGZyb20gMik8YnI+DQombmJzcDsgJm5ic3A7IDEy IChjb250YWluaW5nIGNoYW5nZSBmcm9tIDMsNCwxMSk8YnI+DQombmJzcDsgJm5ic3A7IDEzIChj b250YWluaW5nIG9ubHkgY2hhbmdlIGZyb20gMTMpPGJyPg0KJm5ic3A7ICZuYnNwOyAyMyAoY29u dGFpbmluZyBjaGFuZ2VzIGZyb20gMTQsMTUpPGJyPg0KPGJyPg0KJm5ic3A7IElzIHRoaXMgY29y cmVjdD88YnI+DQo8YnI+DQombmJzcDsgSW4gYW55IGNhc2UsIEkgc3VnZ2VzdCB0aGUgZGVzY3Jp cHRpb24gaW4gdGhlIFlBTkcgbW9kdWxlIGlzPGJyPg0KJm5ic3A7IGNsYXJpZmllZCAtIGN1cnJl bnRseSB0aGUgUkZDIHRleHQgY29udGFpbnMgbW9yZSBkZXRhaWxzIHRoYW4gdGhlPGJyPg0KJm5i c3A7IFlBTkcgbW9kdWxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5TZWVt cyB0byBtZSAoZnJvbSBhIGNsaWVudCBQT1YpIHRoYXQgSSB3YW50IHRoZSBkYW1wZW5pbmcgdG8g YXBwbHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPnRvIHRoZSBl bnRpcmUgc3Vic2NyaXB0aW9uLCBub3QgdG8gZWFjaCBub2RlIHdpdGhpbiB0aGUgc3Vic2NyaXB0 aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SSB3YW50ICZx dW90O2F0IG1vc3QsIDEgbm90aWZpY2F0aW9uIHBlciBzZWNvbmQmcXVvdDsuJm5ic3A7IEkgZG9u J3Qgc2VlIHdoeSBJIHdvdWxkIHdhbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPnRvIGJlIHRvbGQgYWJvdXQgYW4gaW5kaXZpZHVhbCBkYXRhIG5vZGUgb25jZSBw ZXIgc2Vjb25kLiZuYnNwOyBJIGNvdWxkIHN0aWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj5nZXQgMTAsMDAwIGV2ZW50cy9zZWMgYnV0IGZvciBkaWZmZXJlbnQg ZGF0YSBub2Rlcy4mbmJzcDsgVGhlIHJlY2VpdmVyIGRvZXMgbm90PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5yZWFsbHkgY2FyZSB3aGV0IG5vZGVzIGFyZSBiZWlu ZyByZXBvcnRlZCBpbiBlYWNoIG5vdGlmaWNhdGlvbi4gVGhlIGdvYWw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPmlzIHRvIHNpbXBseSBsaW1pdCB0aGUgbmV0d29y ayBhbmQgcHJvY2Vzc29yIGxvYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PkZyb20gYSBzZXJ2ZXIgUE9WLCBJIGRvIG5vdCB3YW50IGEgdGltZXIgb24gZXZlcnkgZGF0YSBu b2RlIGluc3RhbmNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5h bmQgY29tcGxleCBjb2RlIHRvIGNvbnN0cnVjdCB0aGUgbmV4dCBvbi1jaGFuZ2Ugbm90aWZpY2F0 aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5STU9OIGhhbmRsZXMgZGFt cGVuaW5nIHZlcnkgZGlmZmVyZW50bHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj5UaGUgcmlzaW5nIGFuZCBmYWxsaW5nIHRocmVzaG9sZHMgYXJlIHVzZWQgdG8g YXJtIGFuZCByZS1hcm0gYW4gZXZlbnQgdHJpZ2dlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPlRoZSB0aW1lIGJldHdlZW4gY2hhbmdlcyBpcyBub3QgdXNlZCBh dCBhbGwgdG8gZGV0ZXJtaW5lIGhvdyBtYW55IGV2ZW50cyB0byBzZW5kLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+KE5vdCBzdWdnZXN0aW5nIGFsbCB5YW5nLXB1 c2ggdXNlLWNhc2VzIGFyZSB0aHJlc2hvbGQtYmFzZWQuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj5JTU8sIHRoZSBvcGVyYXRvciBzaG91bGQgcHV0IGV2ZW50cyB0aGF0IHJl cXVpcmUgbG93LWxhdGVuY3kgaW50byBhIHNlcGFyYXRlIHN1YnNjcmlwdGlvbiw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPmFuZCB0aGUgZGFtcGVuaW5nIHBlcmlv ZCBzaG91bGQgYXBwbHkgdG8gdGhlIGVudGlyZSBzdWJzY3JpcHRpb24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOy4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPjxicj4NCjxicj4NCi9tYXJ0aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5BbmR5 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk5ldGNv bmYgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciPk5l dGNvbmZAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRjb25mIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_fe5996625ab448efa5f55af2f2a8089aXCHRTP013ciscocom_-- From nobody Fri Dec 1 07:51: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 0726E1242F7 for ; Fri, 1 Dec 2017 07:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 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_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 lsgcYDhYjaVD for ; Fri, 1 Dec 2017 07:51:35 -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 52358124B09 for ; Fri, 1 Dec 2017 07:51:35 -0800 (PST) X-AuditID: c1b4fb25-385ff70000000151-92-5a217a856a90 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 00.10.00337.58A712A5; Fri, 1 Dec 2017 16:51:33 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.84) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 1 Dec 2017 16:51:33 +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=KrFR0zymX188xtiBq5EY+l07fZOQbJ8X7O2Bdsi/wo4=; b=Jd1hQUxhvpfI8y4D0C6HTsLfWCbbBBC27Z45jiJMHCJvMLRH3KhmUXyEPpOl2ehD9ZnZ+5Bf5xNkye8FYzgJYKMCTg/swQugRCfz5J2oxvCPx2VFP6LKbJdKXLGYr7SGA1k+FAhiLFDz1+5t/8HqEEJG4cpIrB3atCCWbtIcInE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.197.209] (91.82.100.59) by VI1PR07MB3437.eurprd07.prod.outlook.com (2603:10a6:802:24::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Fri, 1 Dec 2017 15:51:31 +0000 To: Andy Bierman , Martin Bjorklund CC: Netconf References: <20171128.093725.744666943599041192.mbj@tail-f.com> From: Balazs Lengyel Message-ID: <8f1fc630-15c7-1097-a544-6dd5b5f6d8c1@ericsson.com> Date: Fri, 1 Dec 2017 16:51:23 +0100 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/html; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: HE1PR0902CA0010.eurprd09.prod.outlook.com (2603:10a6:3:e5::20) To VI1PR07MB3437.eurprd07.prod.outlook.com (2603:10a6:802:24::11) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8ebeb064-58c8-4c1a-765f-08d538d36453 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:VI1PR07MB3437; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3437; 3:dcqYHi+rsZ4Y0Be23AgiuvhaHkbMEhUBYKisgmaxpcXp/vQvs+wpDfixK3z4qBMhzgNHwkDdKtxLLwEK1/0nq34VkOGLFHHsERdBIy43DP6afbglnP44uQ9jgoxKOME8wIM3e4A0KtMiCv3OSRwKEUIXMG7xRqFdzALRj20tM0CBODra/KyZU3Ot0Qm+gzWzXGilrVFOnRIk37aGXzvP6o5zx8PnyIv0uqxVWrS6lfX1T2agPHes4LqI08v8faFA; 25:HbbaQ9D9eXUUv3ZIWY4dkpyLByg/ltJZFYXeL0tintyZlkWrYluwx2uSd6xsleZzeNUeBRYkIXv9yWqdU4ju6YejwQo19HRK6hoBIJyax0g5g4x+igkc89UzXkSmfGnvghYFtl128J+xGXE6GWKoYCXNGdtSltnwM0O/n2SiHN7YoEtAHl8ZgI6e+H2q5VBIx8yAf4cMuAbdE5c+vEBSMgjPiAskteyf854Zts7ubWZfYT2Pb8tcFYZFBKxjRySMLWWDv77MALEziG0DQ3j1FbogXaA7v6hIGw7F6+Xm6QwAcnYCN5+qweDk1CbAatzmOYZj31csKuFYzZIjJqYJWw==; 31:cFNpeukV3tbI44/IxxmG+tuSL1+e9iibVMrHojbMidLLetd0ANq8vLfKeyt+mWfon+Dyj7G8NWXNc+U5dLbT+cE4hdMmA6vG1H7Q7wsGAvWwhXH55g4gGnocCB3Y7sKi9IbbcbDXozsRmn0ZJst7tiHP2/I8eX0WUAeH1QxR43ywdpNnkjk+fxS/qh/OXSVaEKyiqtH+4hJFJ2tPh96WuLInOxYcHIVNgU3QbOMBaFk= X-MS-TrafficTypeDiagnostic: VI1PR07MB3437: X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3437; 20:6UPM2i5t6JEJaq9N8QCoDD+prXg/QE2h133bANaE3smpdnxKvarsNbrhfVaZ9h3dRWV/VCNTvUBrihxxkQwE8ytEQKWEX6emSOrwY5sIMEcEq+KyEn7Ui0XA/OFU1/SlCcV8Y4NoOTBC7It/jKUApNjsL7vquZshXgbeTlDVElKgP3G6oyg7dKkH2tdHAOnC5gcsML0QPfoY2eNhJGdQZ+v2jK47Q6dNKD9yprB8VPT4WQmMngZlx1pp/SsYitj8uuNbMRo9jT+5loMLRSnL6j9tqq9yF1aKxN5w+ZQDXXWu35FA/y0j7j68rZmbSdnlg0nzTx+jceZyKzzDB8+ydM1KsBJ1XA0NIl29DdhDQaQLdbVcwyz08tRjoqdUZ4jCbj6dMkwCZFMJHvtaaTEKXX2o0XCb+zOlQUAIceag/HlXmBfw4TxUb/gP72b1aP6UQWdP2MwYAbf3K8NYHqNIE+Uhm6s+Jjvgt9PQK+7JnLUDPhY0JsqKOHcXiYnzQITr; 4:+FC96AN1r4ZdKYyRaa+AdwsfuOP/njkutFxrXrO6XomYrA6PtQuvrMDw6Tm6dHC93TbIa8esQhQG1O0OqCx3FPhg0mL6pQp36nlOu/sVWZ1fdlUM5bar2RpOyrIK+p10VsitLDyi+0ZGGjy30yrTjlswc/PEKoLCBUWRXmRVxkUabP7I306NNZtTSKn7LcofUKP0w5BMm1JpvcuvE3heSm3JSfqWaKHC1yBV+p5z+TEM4ogCsSy+U3p0Dqvu/flwXJQiDnGrJS44e2TwmLbfgOvCvwexklm+QcqSlIog3tXM8y+0MochyspOK2heDVT1 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231022)(10201501046)(3002001)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(6072148)(201708071742011); SRVR:VI1PR07MB3437; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR07MB3437; X-Forefront-PRVS: 05087F0C24 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(346002)(376002)(39860400002)(366004)(252514010)(377424004)(189002)(199003)(24454002)(101416001)(33646002)(6246003)(2870700001)(23846002)(106356001)(105586002)(2906002)(6116002)(229853002)(25786009)(68736007)(478600001)(83506002)(49976008)(966005)(31686004)(189998001)(8936002)(4326008)(3846002)(65806001)(65956001)(6486002)(54356011)(58126008)(16576012)(36756003)(8676002)(6306002)(81156014)(81166006)(64126003)(606006)(53936002)(65826007)(54896002)(7736002)(236005)(5660300001)(52146003)(2950100002)(97736004)(4001150100001)(86362001)(31696002)(23676004)(50466002)(110136005)(16526018)(52116002)(316002)(53546010)(2486003)(6666003)(66066001)(76176011)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3437; H:[159.107.197.209]; 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) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3TUIzNDM3OzIzOi9XZHN5MjQ4MHhCYzJ1c0k2TDNxMTNzaWFw?= =?utf-8?B?Z3k2cmtFSjBDbHVUN1BpNXZLR0RScnRjdm03VkFOeUtwZEs0d0FFc3V5ODF4?= =?utf-8?B?RElsdjhWTlowQ3RLNnlJcEs3N2luVlNxK0tVSjA2d1NrL0lib3pYcU9lRCsv?= =?utf-8?B?cm9IeXl0RGx4OTIzRmpBbmtxSWp3Mkt4c2VIMTFGRTdUZHA1OGVaWTZNUDhJ?= =?utf-8?B?MkxNNk1nb29qbS9qNnFIRDZ6QzBUbTZBVEhXamdWbG53dmcwN044QUV3WUxT?= =?utf-8?B?Tms0aDNLQW9aUUk0QksvUXdVdVhLY3g2NFBWVXVtMHFYc1Z0empkZnpxV0lB?= =?utf-8?B?aVNkSVdUaHExYkREVCtaNUcyaTZ4WU0xZ2sxVlVoVHE0c0pzT1BqVE9ibVYv?= =?utf-8?B?eEIvNHU0K25XTnQ2NDE1ckJjc2FIQWdNQm9iQWxQa0V6K1BGbjR1WUU4M0Ro?= =?utf-8?B?dnQrMzZ3Q2luaGsxVjBXREgrTEJmTFlyRkl5bUZiQ0hTRzR6YmpJUm16QUhm?= =?utf-8?B?ZmovSHc4L0lPKzN3MUE2ejBFejh3dS9nMHFqcDZNYTFCOW1sS1RxYndiZEJn?= =?utf-8?B?NG9Ia1IzTUx2WkJpWnBVaEM5dStyc3Y2SEc2WndjT1RoY1dyWXQxUVJMU0F1?= =?utf-8?B?L0VZRGVKbEl4dHBMbHFJUGFJcHZ1OXZjSlpRa2Y5L2hoaWxIK1dHL3lVN1lv?= =?utf-8?B?SHJzUHdjR1JFa3l3U3NBUXFETXFOcEMxUlFJaDRvSzNZNXg5WCsrZTZrYTlU?= =?utf-8?B?MEwzdGxSbUhtZE1XdG5kWmFCRVVkbFM0bTBQdHlPb0ZPUXpWTWI1Zm5mU3pX?= =?utf-8?B?Mmp4MHpTRE5zNTFHblY0UytxdFM4MThsZlhTai9HWUhGYjBVK2NpNjU5cTh6?= =?utf-8?B?Nnp5d1g5NDlTMzRWLzNrOWpRNkNweHNIaDg3RlVKTlJaUmcreEJhRmk0M2RH?= =?utf-8?B?VC9veFRCNHAyUGZtVXp5MlJmWjNvVkNRZUNBN2J1RjhhUW1mMnhNcWVnV2ZR?= =?utf-8?B?Z3ljNXg5ZXZWQ1dXOVd1N1FXQkZGZFVLQStENmtWN09iejIzVHhhTmpvTCtD?= =?utf-8?B?R0M5UzQ3d29OMjRqN21kOXpLSzdYVlFzQy9NRFFaUjNwRGJVME1KSTBkL014?= =?utf-8?B?blJYWlFJMC9sVnZ0Vzg5eVJ2c1J2YjFDR3ZseFdCZ0g3SzlVNXBlZDdmeWlT?= =?utf-8?B?SW9wVEpiTEJ3MWFPRTRHTzYxdXFnK0JWbDhOUGhCZVBDL1VyWWE4OHVvQTJw?= =?utf-8?B?QmRJWTNVU3Y5ZGIvc3oyRXkydGhoQ2l2MUVQdHN6MlduZVB3Q1FoempnU25o?= =?utf-8?B?WXJiMmFPdlB4Zm9zdUlzdy9melNndTVsU0hjKzV6Z2tjRDYrRTdCVjhlN3Uy?= =?utf-8?B?eFZrWDRIWkttTHpFOGxwSHkxR1Y4SzRPVVRLSWZhUElSUVBheTE5UHFCYnBF?= =?utf-8?B?VldaSU80bXhBLzRJOWpYQnd4NkdaZzNFSW1BRytZZFJsWEdqQjg1ZnBXcWZ1?= =?utf-8?B?RXRHT0dlT1p6WFBpREJxSGhIbEVLRDZPRFdkR1VkNndtLzNBQURvWHp6Yy9P?= =?utf-8?B?Y0JMU2RZN29xanJmSmdYZVVqT3NVOEsrUTRZUjBTb3EzeTNTTXFURkE0Wnor?= =?utf-8?B?SnJWbHh4N2R5NXVwRDJoZGZoRlE1MHlXd2Zwalc1Zm02RHRwd0ZiVDIxVzNl?= =?utf-8?B?WXdwZG1WWjhsejBKOXNqY0drdmttMzRrd1NxYkw4Mm0zeXdka2JCWkhDKzhL?= =?utf-8?B?aFIvL0lzcEpBRUE5ZFpQMy9BWUFnMENyY244eDBpWFIzOEFseHhQQ04wK2tu?= =?utf-8?B?d3NOektaQysrejd5OUx5TWkxd1BEL2dmOFJmK1hVa2l3TkptSXhXYVpNd0lP?= =?utf-8?B?T2E3T0Y4aDRPdXJhRENUakxtU24reXNQaVpnaTNXcDVGaEtTYktaZWlCS1Bs?= =?utf-8?B?K2ZzUHplUUlBTEpHMWNvWTFiMU5nUHNYNzJaaVp4NWhxVGtwdit3K1VNMVd6?= =?utf-8?B?aGE4dkNYeDFOa1RwamJrczFIb3p6cVIyZkVpNGdON1UwYWE3b0VORERUNW1w?= =?utf-8?B?Sm00K1JnV0VXZU9TQ2U3eXNkYmgvNkVOblBNQ3pEcnpDUm1oK0RNNVpyVVBw?= =?utf-8?B?N3c9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3437; 6:HQmmY3yX1kGVUs3u3bZE4zwWkEzEURP465PXEKPU+Isla9CzQGJlKmkHT+CT47gOHWOmnX/B6DzOaIfa42RhMzYpPUma5bPSObBmAfglJowmTNIJ6+rVzmrZ3NBR/ROYwrb/BQOiY3AupNmaaIoKvgJNCTp34hvtJz1Z0IxLNa66HSPvfeYSNdIKM2Zj0fJRM4yPjJd38tmzO3wnIY2AMB9SlNxfNfBvdgY2oak5kv92jRdv4KgTU+DCwhwoVdoBvCm/1Y+eyIy2XRAplUwjAgQXlJDPL1WdiQH6EkutKSLOkcEcEqKy6xxsHTGDmy8EmbJBPufvoDTlr71DR2+SYKlK8cPPwfjF67LAXj9JaeA=; 5:oPGrXbe7we4FcJz6Dnda3ID0hTphqtO63pPctv9e0hQr2Si+EQ6S9ROJW3p1LLk5CeSB6JOtSv3zQaYxlnQLkIWLWlL81T52cO3mvqoe8tbo3E+89Ikg4FsdyEXW2iMY19vLGUjuBHISgjR7ptjz7q9TlhSyx7FygtoRv6VyL38=; 24:G+kEt3vEQffaX+IlgWr2B0vtdAwX47FWLvTKL7bIyYoJL1QJJ6fFXu5R949xDeMowLpl8HqD+1vuNno27TA9OdY2j5tKzlfja4diTY27Ro0=; 7:uR1VKr0eZtuLZ2onucplKp9sglynXbm835AHtLlcEdlars86awf770m7e2uh9u+xkJAsN5JXsOMBki1da/TNilHxTG9S2UWwRPYYnoeKYwwpoDB5fMaxxvY7lVWvFxUxKhF/lhnjuKFJsyQq/6ofNQQBwlJXi4JjJAEBpXZVYHZhSGi9Cd4JRb4Esfcosmv6DpTa4Lqd6I4mljnPVX1KEkeIGjEu8R9Od4PNgtMAn1UVqJhGb8LoFuX+9faq++Zu SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2017 15:51:31.0864 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8ebeb064-58c8-4c1a-765f-08d538d36453 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3437 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42KZGbE9RLe1SjHKYM9zNYsHR2axW3R3P2O3 mLrpNqsDs8eSJT+ZPDb+Wszi0dJ/kSWAOYrLJiU1J7MstUjfLoEro3VlG3PBZbWKn+u+sTcw rpLoYuTgkBAwkTj+JK2LkYtDSOAwo8Tisx1MEM5xRomf/X9Zuxg5OVgEepkl5q9JALEZBeIk dq5ZyApR1M4k8efEaXaQhLCAhsSSYx+ZQKaKCHhIrJnjBhJmFpCTWPyjhwnEFhJoY5T4My0Y xGYTMJKY2n+eBcTmFbCXuNb7nBFil4rE4UeLwfaKCsRITHxwkRGiRlDi5MwnYPWcAoESc+/9 ZoeYryHROmculC0ucevJfCYIW16ieetsZhBbQkBB4vrm6ywgN0sITGeU6FiynR3iIA2Jhxcg npQQkJU4enYOC4TtKzFvxhQmiIYljBL7bu9jhnAa2CWuXTvHCFGlJbHo3kNGiMQPNom9G05D JbIlpt6ZA7XbSuL1r+9QRQuYJXoOL2KCSMhI/Hm5i2UCo84sJP/NQvLTLCQ/zULy0wJGllWM osWpxUm56UbGeqlFmcnFxfl5enmpJZsYgcnk4JbfqjsYL79xPMQowMGoxMM7M00xSog1say4 MvcQowQHs5IIb1YJUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvSU/eKCGB9MSS1OzU1ILUIpgs EwenVANjx4mle/aaGJ470uzxvpFZofPMrQmsDvsn7nslmjhty5+0GacWJ/ZHbjK9GG/j2sSv e95/R4y7XPfLt0Yxy3OOFrJO9C6ed/jFxMY5B1vmLn1h+z52Z56Hp9KGjtfhkocLZ0x/wNEq vy3rptCx+x0FyTr6tzYZNXSuX6izu+ZQsc950ff9R1mslFiKMxINtZiLihMBTqcr3yIDAAA= 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: Fri, 01 Dec 2017 15:51:38 -0000

I strongly  support adding a depth leaf to <get-data>

Balazs


On 2017-11-28 22:30, Andy Bierman wrote:
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 are
identified in Andy's old
draft-bierman-netconf-efficiency-extensions-00.  That draft also
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
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



_______________________________________________
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 Fri Dec 1 07:59: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 9DD97127011 for ; Fri, 1 Dec 2017 07:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 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_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 lKieD0ujYgCL for ; Fri, 1 Dec 2017 07:59:22 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53B4124B09 for ; Fri, 1 Dec 2017 07:59:21 -0800 (PST) X-AuditID: c1b4fb2d-d6fff700000036aa-54-5a217c5720af Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 99.5E.13994.75C712A5; Fri, 1 Dec 2017 16:59:20 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 1 Dec 2017 16:59:19 +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=yfwGN9XknMVnvr7LMUIC4nrFn8+3m9zQSydWe7IT/t0=; b=WlhlCy7DGAanJRErlXCIM7VdrDqv9gEdfZ6mM16Fs4vlTzxjQENiHQt8CJEfi/dv+n9IjvDrpLDxH+fljzLMr57KsiJrjsTeXKHF1SqqRMejaf5P1iZDimOn96BoQE265rvhJArUgRNzxWg7/bBD03xw6Vrau/aXONxZnnud564= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.197.209] (91.82.100.59) by HE1PR07MB3434.eurprd07.prod.outlook.com (2603:10a6:7:2c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Fri, 1 Dec 2017 15:59:18 +0000 To: "netconf@ietf.org" From: Balazs Lengyel Message-ID: <9bb0bcb9-d53b-c06f-d2c2-d5cde6d7316c@ericsson.com> Date: Fri, 1 Dec 2017 16:59:13 +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: text/html; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: HE1P195CA0010.EURP195.PROD.OUTLOOK.COM (2603:10a6:3:fd::20) To HE1PR07MB3434.eurprd07.prod.outlook.com (2603:10a6:7:2c::13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5f074acf-04ba-4d85-19ef-08d538d47ae4 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:HE1PR07MB3434; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3434; 3:lfW8mUtPUlkF0Mmipxdlvo1iL2ZCZRL5T3L0amhRTUuXIOzFE7f/utvCE5Jj7CRfx4N72PMYpHC4sttlX9+0vkW4ZQpOscGD2V3b9wxS4FZ9KoP1VOWiIbZlMtUavUzXxQFjfTQKKll8IbZbm5BF0BZOIFjgC0w3gHKlog9L0/OSIoypspVUUpw7FfWC8snsNzBMUPslYy9myChXLc5VdczIC4lips5yKs3EGcPNyTO+puxKcl6jJW/iODoI1A/A; 25:NxUPgQgRH9lTaq+Sp9Zucg2odRBfCLTtFkWFr15YZI/aZlhePL09LAlsa+IQjLLjmb46PuR4y1Zwu7NBWlk5j4uOjZwKJYXPfE2zJqMUhRh3K1qxI2H6hfiOzBGo4OkCsRYPA1A6Luo6CzfrvO6WkXGDbVKa7egK5cvgYFtKIE0axkYzhU3njPnXZ4ycnDkbpbF58yR4EiBC5eENDnGxvftf0nHI/uuhOz1dxwxQuO6+hZPTo5yGrKxRaTccIfHLXPCs9oe/+bsNcFaUBHHXz7YqjlL264eJ4lXnOHRPAiH22HVli0LYSOVRtGxU9G8LM6OwXksj96iNYU13Vy826w==; 31:pPl/rR8TIwhUb1BVYfVUr6UNthSUhT7RU/bL6TVJOyDmCPMpIUMAGpk7G/B4WKOELV+7cuWQN3KyfIOvZqEs0J/Hz0LhNN5aAcY0vW/RMrwnLGe6LaHhUw5KXEU8xzI/mxuP3sIEkeNcQOYKLynCK9hzxnNmNhV6SBPOGQHIq8CWSSy6OVudBumJanSN1jb9DPJkbmp1+ZTKnLGS5NSKftxL103+ZOJgmbFSx2C5Fg8= X-MS-TrafficTypeDiagnostic: HE1PR07MB3434: X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3434; 20:HQ/I66IB65IPRQU75XDzW98KffH/veE03VQg+syWp1QzOn0Z3Dwyzi8tO/pk2/a+zwmZO5XWIQasZIUOBvaD+/tm0e4S2aDpWQzs2omOnl0zNlykAC2kaGcGNJTDaHnl7vwq8VFsae6gsyK/l96vbMJ1jIb0qlqBmdAeCwTUKuFR71b0xRtU/kZ+8kvkekDEaA1nTTs/pEpfPMjp05CUZnyWVvxXAte61FjlPEk1jLwrUUvoAOQzBRYHZ55bbkFCNNDg4yAS5SmmLhbywxEhiPuY+J90Ab3/qeKCrMIPbX4fK0AcrVF5+X1pdZGWLvE3m3xiO06ChPZa1OKKTfpaCDauhAqQEad9I9STAkPLEvtL1+PPSrI9qyAM9DQzO9Ayn21Q7Q41M5x8N3Hw28g39IxKNC0W3+2gWNtLBwsnBX45baGriWdvHK5juz6kd9fp0TwEOBc0VWkfqKIrLDZdOQcpsAOb/Fyce1fmkdtLkjoBHn4hfABm8fBj2/iBpLGH; 4:KkES63TAA+0qzQNZeNRAmub88qnxYMZqJl1Z6Qzlh2EWKK+WA6sKlBQsfka0OyysOwljPVf0unw5BL/Z3lC/AnS0b1AgfsVbMIQj8+hmX6U98KZLR6XfS1Oi9J13KqSafuO/Dt98TOdUd2K+QnLDqZ4LpKw2gRNTDgZmu8DRoLhv9/98fyLx9G5Q+0a2b8J0e5ix7I/A2RGUi27hxdlflgYyFrH29Iu0ErnNSPJeD5LNdg2T6tQbVhz5Ij9VyYClblOuxGNiW226ihP485x+0DtxXVO00kbcu8bsS7GFIY8ibozlHsLcX7PDOGb6Co4U X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231022)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(6072148)(201708071742011); SRVR:HE1PR07MB3434; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR07MB3434; X-Forefront-PRVS: 05087F0C24 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(39860400002)(366004)(376002)(346002)(199003)(189002)(252514010)(101416001)(1730700003)(2906002)(478600001)(8676002)(3846002)(81166006)(81156014)(105586002)(106356001)(31686004)(2351001)(230783001)(49976008)(6116002)(33646002)(2870700001)(50466002)(6486002)(606006)(83506002)(5640700003)(68736007)(65806001)(66066001)(189998001)(316002)(64126003)(5660300001)(65826007)(23846002)(58126008)(97736004)(36756003)(16526018)(6306002)(54896002)(53936002)(7736002)(86362001)(23676004)(52146003)(2486003)(16576012)(52116002)(236005)(31696002)(54356011)(2501003)(6916009)(8936002)(6666003)(65956001)(25786009)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3434; H:[159.107.197.209]; 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: =?utf-8?B?MTtIRTFQUjA3TUIzNDM0OzIzOk1rQWtFWXpKLzNCaUpKZEZta1hTN2FBdDE0?= =?utf-8?B?WVVFUllZZlNlb3FCbmxPWlE5aS9Ha0UvK0ZBdlJNWWUyektGN3kyK3NKME5x?= =?utf-8?B?QjJBcE5vRTMxREx6d1V6OGNJN3lYandhaVg4WlArb0xURm1lZDlIemNialpZ?= =?utf-8?B?VldBMzlwVlNyMnZhZVdua1NqZVdlTzgrQ1d6WGhWNEE4bkdmMExzbTgxY282?= =?utf-8?B?aWVVQ3dXaU05R3A2SXpnZjZuWm8wMTJLUS9RS09KNjU1ZnloZ1B6bkRlMHAy?= =?utf-8?B?czJSckttZjh1QUFJUXBPYk55RHd1VUtDNDFjdlQzMVl3andWYkZxUmJ4aFhu?= =?utf-8?B?ekQ1NjhKdU9FemE4cHF0b0RHN2IvM0pBZExUWDZ6UzlhY1NaWXJEcldJRjlE?= =?utf-8?B?WCtGK3hrVGI4THBHUnFwakp5Sk0wdXRFdWNWeDNqdzkzVmZtQkJqZFlMQjgv?= =?utf-8?B?TXYxSFE4M3dmR09jTi90S0c0OHkvbmdpSCtHWDFYOFk4WVh6SS9JL29aT3FM?= =?utf-8?B?VFhmSnd0My9pWnJLd1dhN2dCd1FDcEhDbWxjem5tLzMvZzdIYlRZYkgyVGhC?= =?utf-8?B?emZqcnFpdkx4aEU0TmdYMmZ6aHRTSEExaHRDNjVySFl2K0x0OTVuWlBMNklT?= =?utf-8?B?bDdMTnhzM29CSENWUUtXY1hrZlU3NE50Ymk0YnExQXZQZ29XbDVjcDNScGtq?= =?utf-8?B?RjFUUHNMbnBpZmQ3Z25wSk1YellpL095SzVXakdUSU1SR0thUGQzMTRkWGJj?= =?utf-8?B?M2QyRWE2dEZzZzFyQjRrY284RThOTU1tbWdEcWR6eEJONEp3NFZtVVdCMlRt?= =?utf-8?B?VHh1bGN0VGxObzBJYmZRaTNkdENiMDNOWE4vOGZOcFBzcm5WekhyWmRHY2Qr?= =?utf-8?B?MTU4M3UvcURZS1Bvei8wNzd4VUpCN04wLzRtN2MwY1FsTitDQ2tGa2hZeDli?= =?utf-8?B?a0ZCVUo4RkNSMG5LcDNGcVVrS05FbWVUeVYvMWVlblh5c3dsdnJQaTFMcnlR?= =?utf-8?B?citnNWNrNHVSYmpmTGtSdVFUcm9PWkFnSVB5dHNIOEhxc2FHb0xyYUlyRGNO?= =?utf-8?B?OUFsZFFGdmp5dHVaS0JReEY3Z29KM0Qvcyt6c1dnWGR0SUpBQlFJSTVHNTdR?= =?utf-8?B?QW11MmxxbnRDaUlxc3I5Rjl1ZTc4d01zQlQyMW9XaVp3RkNIUFd0eVcrRjBN?= =?utf-8?B?ejR6MmpUR1Y1R2ttMGFTQmQ2eU5pM2RmbTRPaWJ6b3FZUmVKZHdsdGVFcXY3?= =?utf-8?B?UXd5RmltUUE4UUp0T013NFBRYUJRRVJKQWhabGYwd2hxczUwd3NnSmZkdkcz?= =?utf-8?B?cFRSTk1ONGtaWHlrVmtRYmxHbkFXV1lLVUIvYmJOMVhzaTJzWE50dmpnTzNj?= =?utf-8?B?THd6RzVmQ2w0MkFVWmxveFdkN0ZHVHVxUnZoNnlLeUlNdGw4V3I1LytLaGRP?= =?utf-8?B?RW4zVWFqRjRISEJCUFNCSTV4d0xDRzNmRnNiTU1mYVd4QXVBVEFEdWswYUhC?= =?utf-8?B?VE5NWmt0Z0wyZGpuYkVpYmFId3dFUFFMc3FSeURFbmgrRW9uWVc4bG85UlVB?= =?utf-8?B?UVA5RlY3T0xpVGxJNXVMdjBlR0gyTVE5RXF0cmdDd0ZjaGZ1K3JXRHg1RnJP?= =?utf-8?B?THpGWGVPMFE3RHZyOW9SSEE4RGdiVThZZnNIeUw4M0daNHlrV1NRK2Q1akpI?= =?utf-8?B?dndjMjhmemxiV3pyQkwvODdaUkRnWWhXUVdWY2lkSE9RTWpLempHYkZQV1lm?= =?utf-8?B?SXA1RkhIQ3RTSURuWTlKd1o4WEdnK0NBYzMwMU9HV1IvOGdEVTVRQlM2NkFE?= =?utf-8?B?Y1dkYVRsR0R1TXNWK3krelNxK00rY3FMbDNXazhrODB1QkhwellqN1JxbUpC?= =?utf-8?B?QnAyYzRoUTdFb2ttTFVDWE5tU1ZidmlNcWp5aFdzUHJReXF5c0lkTGdiRFFq?= =?utf-8?Q?nxuGQk2pC1/TtwKPP9yCQSFMHSwVEY=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3434; 6:E4FBnXpEoD9IWjsRh0W5jUqn3Jg3+9H1ARtX5hVdBvHPoN4JkuxJppmQDbKS2SQ1139An0AcFlHUy+QzM+kbngfmY/f8fNmEeWtwQg5zW2ln3Yd7F1BsqWCPm05dG/Zeb3+iKoQ9Bikqc6x58qRSxh8g+zAnlWh14sopRTIlh8aKHDHj0Y4uH9v8otoTh+gEZ3bex+wX2RYvWWlTV7RXcavokDIID2okuMtGRadTWkhtV1vmBuH5liBdMvWJBoTlkNw2rQtpp2MkXxPE9DIXd7Mh53sP2NgUGBBiCUj/3B1hrvt1bI0pjG+mXGsQCa2lSqdvXipMr1M/VOZMgBYL04v9FwkNaRAe7RJr2zts58c=; 5:jIhEwqgvU8HSS6Q2aRRIAgTrGmjzuK/AQIX5Rfuhnjxoru+I4olQwZZYJmlEZHOkZX6wIiPEW6Ov1dMhqcZvPc2ES8YJBKiArhbz0VJInvWsXyt6lWHe1TMV93m+VyIB19G8FwUD9DElHlTT/YAm9EnnLY1BjOmGQ1Sj5krIiY8=; 24:+KbZ/mRyAE+1tT+eIk3NKR43hjkCCr89+Sa0eC/D8VkbV+tPBdWj3Kz5z4+kzu1Ys78t2ZfHUAiI5FnIyR3AvgCeaY2ANuHJXa8sZmUwx+I=; 7:0EotokhR4cS6A5uDUkNAlLk0vw9E/Ck84tZgc5h6e1o3w2m0+mxfmWXd48VsD4BOOz5ry1q6n5TJ0kYk5g6WryNT5qgyfAhjKGvyaUUzV9s6qxg8Z0K6LYtxvANCP8GsOjxybAuJQuXSmwkt3IQk+RTgpDjylfen4Ix9y0iodEbQ4FJpsuiPF+d3b9RCqkebjeF+GWtU3jIL+EQormzeQiOMKasf/f2FB8s24M9Ua7qtmrsn81pHggkLYvO6fChT SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2017 15:59:18.6597 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5f074acf-04ba-4d85-19ef-08d538d47ae4 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3434 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUyM2K7sW5EjWKUwaXfXBZTN91mdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqUz5QW/2Co2L13P0sC4m7WLkZNDQsBEYtWr70A2F4eQwGFG iRcrVjJCOMcZJbpWXWcBcVgEepkl9u77zwLSwigQJ7FzzUKollYmiVfTr7OBJEQENCUaZ30A m8smYCQxtf88WIOwgLnEn3s9TCA2r4C9xMFnf8DiLAIqEj33l4PFRQViJCY+uMgIUSMocXLm E7AaZgENidY5c9khbHGJW0/mM0HY8hLNW2czQ/ygIHF983UWCHsCo0TDGW0QWwio9+GFv1B/ ykocPTsHqsZX4t237ewgD0gILGGUePjnLhOE08AucaTjEtRULYk/l25Cdf9gk/g5OayLkQPI zpY499gRImwl8frXd0aI3gXMEpcffYPaICPx5+UuFohEH5vEyp+vmSBOSpXYcqOFDSKxXlii Z9lt9gmMmrOQvD0LyduzkLw9C8nbCxhZVjGKFqcWF+emGxnrpRZlJhcX5+fp5aWWbGIEpomD W37r7mBc/drxEKMAB6MSD69GhmKUEGtiWXFl7iFGCQ5mJRHerBKgEG9KYmVValF+fFFpTmrx IUZpDhYlcd6TnrxRQgLpiSWp2ampBalFMFkmDk6pBsYcHdUvq2RSorf9y9kal8fsszvuSo9h 3cLYI3VTtX9l/98kd1nfm4+pWXbWCeWltbMt5H9x+vSl9RYFh1469veTQx7bsXhFu7VK31Vv /O8O3zRPZY/xwQyWs2v5uu4oOVw6WHWGYffBr4E+Sbz7F0n2LZHXS9R6eErfa9Zmm8dmoQGm 380+7FViKc5INNRiLipOBAA8+ng/DwMAAA== Archived-At: Subject: [Netconf] copy-config in draft-ietf-netconf-nmda-netconf 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 15:59:28 -0000

Hello,

copy-config is mentioned in chapter  of the draft-ietf-netconf-nmda-netconf draft but missing from the YANG model (YAM). Will it also be updated for nmda?

copy-confg to URL is a welcome bit of functionality that is not providedby get-data.

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Fri Dec 1 08:11: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 0DB5B127286 for ; Fri, 1 Dec 2017 08:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 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_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 g2D5Uth2Jnma for ; Fri, 1 Dec 2017 08:11:43 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52AF4126C2F for ; Fri, 1 Dec 2017 08:11:43 -0800 (PST) X-AuditID: c1b4fb2d-139999c0000036aa-47-5a217f3dd354 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id EA.60.13994.D3F712A5; Fri, 1 Dec 2017 17:11:41 +0100 (CET) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 1 Dec 2017 17:11:05 +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=ygya0y6G9J7+GTG+/ul5wV92oyJk4n8+J02U8f4xSD0=; b=COdyUu/hU9VjH9/eUlQilihKC5jk187pXmFfQhwh2vu2OKxQq28xM1JYbBVZRZcl1JbTd0DWDd4OrJrX93D3jyl7HwoofiSplQY9JEjpLp3LFC3E4age81h2yCWlGg0CilgXYm5lIJ9C5jVmAS554YeFnOoF3o5JWDh1o8ydtV0= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.197.209] (91.82.100.59) by VI1PR07MB3438.eurprd07.prod.outlook.com (2603:10a6:802:24::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Fri, 1 Dec 2017 16:11:04 +0000 From: Balazs Lengyel To: "netconf@ietf.org" Message-ID: <6247d70c-a1d0-1a85-e73a-081a9c6f47cc@ericsson.com> Date: Fri, 1 Dec 2017 17:10:58 +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: text/html; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: DB6PR0902CA0013.eurprd09.prod.outlook.com (2603:10a6:6:2::26) To VI1PR07MB3438.eurprd07.prod.outlook.com (2603:10a6:802:24::12) X-MS-Office365-Filtering-Correlation-Id: ed0614d1-571a-401a-b7fe-08d538d61f57 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603286); SRVR:VI1PR07MB3438; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3438; 3:ydv7rOgJCm3c2HE3+SRZnqGnOcEn3hQtkvG7fAuGJYVpzq7aGz+v/qKzfaKgfC0XsD+yhBxTG08TxA1BGdBDCWee3N8mW9ChhaRRDGbUgQSW/GN3pWdWJ5tpS+8dg9/gxvDhNBH6E3fYqDOeTNDj0GGo8jcNcwFB/NniOhri5f/jounQJFEJg3oTx4lbQQR5khxbLFteGEmNLy2YDB8lHQnylI6OTtaCQ88KkyiUcjqzUmBiKMGADM2aOxpPZlq5; 25:tyQnxIVC2rnXNp/FSUo+aLBD5RsRVHaW9lmtH1XX5D8eRKnRe2lqPHac2QaNnA+6v9eFG+IJzZCioDWsVWIrbWLj54VOgWWiyrVur++yAPbvpXYYjzfV25r0OGXLv/lHmYcltX4Y2x6xR2jfneIkJnZ3IZSIsUCU7PyQqkwU6S4ThT0cyLx/tTn8G+D/LXmwtYIuKbfFIX0asjGT8ChgKl+q9LC7MDp7fVtO23enF3V2TgcFrbjRgE1LlOePtxD3BaerCuzBngFs22xI6iOT0nWTfoM3pLR8/1sLnokJ30QIBWuLemhuJCbkY4gbc9JUlEZkLUxtlKNMARmyvmrkuA==; 31:OzSSCgQZfQr19xiNmdKycqmjZ9ZAPsfMiZRD+WpSVSfWuYcxtgSeRJ4cDsRGtFd/RzHjitCB5TeW0DQWK9BxT0Ph7ldKAacEElDNXZOkxQykRbbNsKcopX0GdjQ3cpX31MfqievROGTuhtRpmNho8/BIqbzRJjY89ZkN/J3IVJvGlsFiaA/UJ2miHaNxroL89w+XYklvzZJFm2fY/dxRzGY6oIIkVheJQwP6w89VYvw= X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VI1PR07MB3438: X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3438; 20:s8cJW5DZsFExyacLPCSjvkbZ1oYxPcuFTIiZ0/xu/SJhwH6bU4yWBTwkxFxVrm+zkXVfNH+WKKO9RcpdbhHTxPvry3lx1VXtwaNwPc8jW69BfqPH641osY4k4PsipQoOGIx+FreX9pMUgBzi+JVjzLAUjDw0+KRXvwvhKZi5iuJflTRJfmMnfH6SEWt70YpGIqrAFyADL1YS67F25jMLwVlgA3zyvLI2o+QRCP22Za/wwvDRbQBDsXVys68MvIUAJaTcsqzW4hnAGF0zwYJL6Mf4mNCTzOcOVjG+CMNWhNO2KrziPmYuC4cJSkcO5beueDrpwTWBXAteIHKKFV9qdKU658KczZK27FhU1JfN6X69qBcRKsEh6QPny/fRxaHH2nBZv1qInb/hpjFD0TDegJkPOavq2yG0DpA5yv2a48A3xrNbpfAjuqsVVq5OmYRl3CU/lBEGdaGVyjmRZLGa+S1AW+H1Sl+janvhiuCg7zIn/qWgN6apPE8Jgihcduhd; 4:WBKo/aIKJ9vsuXsEq0BUUv9cjGS5oq9Io8voY7FzDxZgACbZcv6t5+H86CMzKeQPqTgj2WhVjouqr3fb7Y5+KgaIGb2etkvPvHMAFO9DK/PA6xptrZ1SVmpGMvWyr6zMQc8NA4AlDoxCml1vYyw7KYregfYzHvuul3w6Fx/DROWRegz2KnQTxRy3o+4s74ZNOrXk/9g/OfXwy4EOkVqd5PEEhwqbgMJeLNuWbXvXiIq2cAix4AAyJWlwJPq3KWKaDUGzZ2wKnjW3aMoQkp+PRnm6CtugZpS9pqPt0dwr4utlfM5yJYflEJ9bmUVO/hXE X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231022)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR07MB3438; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR07MB3438; X-Forefront-PRVS: 05087F0C24 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(346002)(366004)(39860400002)(376002)(252514010)(189002)(199003)(86362001)(31696002)(52116002)(81166006)(50466002)(2906002)(68736007)(97736004)(189998001)(106356001)(36756003)(23676004)(2486003)(52146003)(33646002)(53936002)(83506002)(2351001)(236005)(15650500001)(54896002)(8936002)(6916009)(8676002)(25786009)(66066001)(49976008)(5640700003)(3846002)(478600001)(64126003)(5660300001)(6666003)(16526018)(65826007)(65956001)(6116002)(6486002)(65806001)(101416001)(81156014)(2501003)(1730700003)(316002)(58126008)(105586002)(7736002)(2870700001)(23846002)(16576012)(54356011)(31686004)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3438; H:[159.107.197.209]; 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) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3TUIzNDM4OzIzOmdPcXA4aVAvckZwazJjTHJNS3Z1QlZxMWNQ?= =?utf-8?B?dGE5V1FDS09wU1RhMWlYRHJ1NGp1WGxpK3E5a3VVZjFJVitlZmJxNEVaS1Ix?= =?utf-8?B?QlFMSDFuTGt0YXluWjhwTFh5ajg4UmNQbTljSWNEYS90TXdzcGZabCsvL1g3?= =?utf-8?B?YmQ5WnNNZVpqdWxNUktKcEMzSW1GandtMjRFYmU5K1dKQ0xXV1lvS0tRM1NG?= =?utf-8?B?cCtqcFY0Mzh5MjdpYmk2cTR0cFRJaElnSk5taWV4MjdrNUtkOGt4MFg5RW0y?= =?utf-8?B?RlhzV2p1bjdSVzVhTGZOcTVOTUlKSURxbDM5Qi9PNmdlYnB6cDZ6ekZhOU92?= =?utf-8?B?V0hzVm1Ib0d5WlRoMnE4bVVibEFpbENRRWVlV01vY3QwSzN1bVlzcWRKRkt0?= =?utf-8?B?N05JSTRQTDZjUzcraFhoaERsY1lFK2lXRXJKRFZpZjZ6NHQ4Z1hGUzlrcEkz?= =?utf-8?B?dTNVU01YaWM3OXFSRFZ1eUVlc0ZuTC9vTUdTanY4NnoxK3ZsRFU2eGdVckxB?= =?utf-8?B?VWV2bjY3ZGlrd3AzaGsxYW1WQ2x5ZVM1VmlaTVhkclBkeGVzZStMQWFBWUZm?= =?utf-8?B?ZmNSdWgzOWFTdzFkY2lJYUNlK3dRbWp5N2VUMmpWOWtxd2pwV0FPd2hleGdY?= =?utf-8?B?K3lYRmZ3MEVnb2xXNkNYTkRBcDBUS3pGREcySmhmd1BrV2dFOFlpRkJGWjQ1?= =?utf-8?B?dmFLdUhpYnVxUGlLMnUrbUcranRHdG5VSTUyb2NzbkdBWjVQYTVkZnN0WnhF?= =?utf-8?B?ZjkzQm1mUnN3VUUzaW1CbFdWMFVMeFFjOUlGdUJjb2FBWSsycTd5U0gyUmFx?= =?utf-8?B?L1hjTFY3ZUJKUXMxTjR3c0xvRUkzcEw3S2I5dXpMb0s5dkVETHFpN2ZvWkRE?= =?utf-8?B?bCtpWUhDRnN0SUFna0VtbWJUcldZaTRJZFZxSEc1aVUwVEhzeTJEN3FvWElG?= =?utf-8?B?Q3hHc3JKcGNQVXN5T0RGVnRnb1AvMkZzV0hyZ1JWUHk1RGVWaGNxOWVjWG5R?= =?utf-8?B?UmNNWUQxNU9JMHpQSkJnckk1K1I0WERIZUh0aCtlWWdzWm4wUTBCcHVKdzc0?= =?utf-8?B?ZURocU52NlFmbVBYSm02Ymd6SGNsUzdENGdBN1JQU2Z4ZDV5M3pKRW5wRmRn?= =?utf-8?B?R1BxYzhqOCtaY2VMVVMvWkRYVmJqYnlDQlFIYkNNc0ZuTzkreWZrNjgzQXVQ?= =?utf-8?B?d1lMOHdCdHFXSHU5cURONHh5N2pWcGpCVCtFVEt1M0k2N1NIblY3ZE9saW1y?= =?utf-8?B?TmNRNWMwSjBWUUhzRTMwYW1rN0E2ZEtRQ21qSVRzRXZ5d3hHOWZEendDazZJ?= =?utf-8?B?RGh1WG5zdERJRmJPRHViMUphWFJRTWZrcHlIZEhRdjBySDhYV1Z4VTdNbEZ4?= =?utf-8?B?TjZZQWRYTE05U0tkL2hqVzFUanROZWp4VGVnOGJGOXh4WEFEUlMxMHdWcFdW?= =?utf-8?B?QXhQZlByUmxnMmE3S1M4WVo0TDgrdXdadmdFYUd3Kzk4emxGeFVKa0lLaDVB?= =?utf-8?B?M1pRMVAvbmJSOXZ0Q2czejhMTnNwSlZTSEZJTk0ycDl1NXZHT25OSXYyaVJn?= =?utf-8?B?c2JNU2NJb2I4NEEzdlUvWHFud1I0dTFReVdnZnRwUmxKZDNVOXRjaHhrWWk0?= =?utf-8?B?dnV2MW1rZGJyTXgyNS8xU1hHSlkrZGpEMDQ3MmxVWXpLRnBRU0drak1NTzBZ?= =?utf-8?B?SnVFZTJKcmVmYjZDSEIrVWQ3ZTBnZzlVR3lIYzJGYlJYMEtRUkN0a0VtZ2Rq?= =?utf-8?B?bU5URFlacVVWOTNLeEo5enQvYjA2WVJIN3ZoWW5HT1VQYjRwbFIzN1lSbytW?= =?utf-8?B?QUx1NHRUS094ZDBVbmFEaVo4Qi8vVmdtK29LVFE2bmJmMXBQUU9MTDB4VTVD?= =?utf-8?Q?dfbgkqs3+omzXepqQpxSdWIkp5S9dppb?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3438; 6:1mB3Bv/AspClxYL89CHWHc3BF0fgndeJ9jsH7Tb6H8TldvOhMGCn26I9WDX9jCyuv4wDrStfXQscPVs5KeJRztfDIADmDXkOCDnP03ke6Om4CyYdHe8f1pPP0hL39RJJq1O2Y1ljaDgH7bqjrHEw0DTcfPyypSqLfAb8/YyGQ4nBxKHDT1fQFG2RjByyzpCRsEtG7ArDoo2l8cEZ154/MC1uCTpsN+uk/CULLTJ4RSPr6vvJDmqfP+5LEGz4i7n+IGz5s/KWVWOA3ftI0Qu8JgminFWe8S16kRyy1V8MyPhce95juz9OJQnZ18rfKJ2aXghU57a8J4nI6Ez9QajcDkHRgmgSwJB1x+GPyTlOokM=; 5:QuSs0x7sbL1aY7D8HwbgAkM4m8wxqEs2o+S+J+A3Ws7ELS6QlRadxS3/rwvwyGBce7FKBRQTGFALHlQCVg4W1oC95NpksiCBfLC/hCL0sXB5xsu9+FBB2lpVdsr8IvsthL7tzgp67ktry98eZx936JeSbswj1iY87RQFUlYmt8w=; 24:lossr5ErMIWUWM7ot4S/fWn6uugbn85GLvrxoMFOG5pKNd13KNevP2Ayd2D0OOkxafZYe6oHyvUpdn6E5ORk0vGYi4eek7T9PQgTJbmoOwg=; 7:GYR55W9iSHIzD0Mawc4lSC+mQykzj6QxyABg1ygTwec/QF5z+LjDUsISKOTBPgQpjLSGoW9BoZ9n1gNfyWcg6TOJV8sEOrHC/EzUM+R3iybiLcwrDohq8NW9Z0liUsQlhGVhnwoWLK4xWEwN3H+gyMKKUkJgPEHa2c5BLbuO6/hy0QW27tHzxTTU2IeVNSfkfC89oNvDCU0VGwmvbNUKdA1PzDBxc4jB9GUOrYyQ33Lp/x/KtMGPzkTXurh8Gb97 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Dec 2017 16:11:04.0292 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ed0614d1-571a-401a-b7fe-08d538d61f57 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3438 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUyM2K7iq5tvWKUwYJmLYupm26zOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4+iWB2wFj7gr7r4/zdLAeIuji5GTQ0LAROJh+1rWLkYuDiGB w4wSn37NZ4FwjjNKnJrRwQ5SxSLQyyyx5bQXiM0oECexc81CqI52JonPfZdYQRJsAkYSU/vP s4DYwgLhEusXPGUEsUUENCUaZ30Aq+EVsJdY8/IIC8RQFYmv7w4yg9iiAjESEx9cZISoEZQ4 OfMJWA2zgIZE65y57BC2uMStJ/OZIGx5ieats5khXlCQuL75OtjVEgLTGCXWLZkOlhACan54 4S8rRJGvxKPZd1khipYwSqyZe4gJwmlgl3h4vJEdokpW4ujZOSwQtpbE+bnXGCGKfrBJzJm8 ihEikS0xYfZ2JgjbSuL1r+9QRQuYJVZt3wrVLSPx5+UuqKP+s0o8b73OBHFUqsSWGy1sEEWP hSQOvHGewKg5C8njs5A8PgvJ47OQPL6AkWUVo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmCq OLjlt+4OxtWvHQ8xCnAwKvHwetcqRgmxJpYVV+YeYpTgYFYS4c0qAQrxpiRWVqUW5ccXleak Fh9ilOZgURLnPenJGyUkkJ5YkpqdmlqQWgSTZeLglGpgrIlgmZJS+k9ScL9MeWjhjvPKHrs3 3Xv49qVMhWCDa1LRiZTyL9PNZjdJ9bLMe7NW4vsKo2yG/w65Ru9nKnjV+YkqCzrdPP02wpJ1 S4D8zedK2cHdad/fbF4qIPVma3qorng49wrVm5zHLKp0ruyJ3X9e4vmLjQ5sf4y+fUxfUxP1 MNLm7I8XSizFGYmGWsxFxYkAVdsyphEDAAA= Archived-At: Subject: [Netconf] Subscription modified for RPC based subsscription [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: Fri, 01 Dec 2017 16:11:45 -0000

Hello,

If a subscription uses a stored filter by-reference it is possible for another party to maliciously or accidentally modify the content of the stored filter. In this case the RPC-based subscription is effectively modified without the subscriber noticing it, which is a problem. To avoid this I would like

  • the subscriber to get a modified-subscription notification. It is not clear in chapter "8.2.  subscription-modified"  whether a notification would be sent in such a case for configured subscriptions. However it is stated that no such notification is sent for  for rpc-based subscriptions.  IMHO a notification is needed in this case both for rpc-based and for configured subscriptions.

or

  • it should be impossible to modify a filter if it is used by an established subscription

Regards Balazs
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Fri Dec 1 10:50: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 A3377126CB6 for ; Fri, 1 Dec 2017 10:50:54 -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 dgiFeZqM41Cu for ; Fri, 1 Dec 2017 10:50:51 -0800 (PST) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::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 95D7E120726 for ; Fri, 1 Dec 2017 10:50:51 -0800 (PST) Received: by mail-pl0-x22f.google.com with SMTP id 1so6759892pla.7 for ; Fri, 01 Dec 2017 10:50:51 -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=mSVVaUMImv3roMB7HGX7kG7AfKYadL0S3UYKcpnNkJQ=; b=cmzmVeBdvMhFwmej+UlJD2ZckyEC/Cc/IErIfxgFFXt0Tj/vbjkZevUvKJEgvtEOiu cjmHt6tr5kZVqp3VWJioT+zH1hR3VrGYUI07fu/sgR8qmmZRzDMKefaRQEdJoiGE5AV6 A/lBFyML2qdgjqvNl4lkkZWc0IrhFLqaibcQDlblhL++stuvAMu5cUenI3c52hJXD8rO Z3T3/KoqcB38pLYVxMEb/dbS14gcydKLRavM8XkTpbvUi4ludOoq8npdYbs8nqP6Hwm6 j/DGRVYN9uK5IYXkvbL0o/zjT4X0rW+8AET7i5nk/1upBr7oPDb6CHlHNFHqr0+Jl0Yk p+Gw== 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=mSVVaUMImv3roMB7HGX7kG7AfKYadL0S3UYKcpnNkJQ=; b=CvX63xhKoTXs0HqcmPoQFlKX+lwttm5zpjs5Uymn3iBXRUJHAlclNqvd+GTKbdhXDj M8KmlOMp55mueuz4yZ0D+akebaucBIqxW2tI9LlaGnpDfkcMEZOfEMJ5YoTC6c7s3Wje nCfTAzCX+5yH3jLk88d4HI6F+QlIYo5HqSa26Shcrwa2gnMCYJbufZiPKHRNV9Dn2OXM 3oDAgCfH/J7P7MhujfBZYOuyA80NV/yHzqXhg60OobXuUdqTV4RQ0iBsIEowWUh7kGh3 LYimVJj8UhrapPjeZ0zsbJp8vIRSGnb0xtplx1VyykffwcPmwrVIfLrWMu4jwIdXb7gX NBTg== X-Gm-Message-State: AJaThX7x4H3dG0MQ7XEWwgZl1iWv2b3nnfO+7MJtxL/tnToFRTtuRREY 1/lfF/yXvFnGYI4C6KIRwNg= X-Google-Smtp-Source: AGs4zMakd1/VIusN1VXmLQWFd6BGSlafFXloHOKYFh5mkuj+uX/L+GMeXx0cxv4EdjQKBtPn+m/T4A== X-Received: by 10.84.248.148 with SMTP id q20mr7227381pll.110.1512154250836; Fri, 01 Dec 2017 10:50:50 -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 r62sm14089756pfi.184.2017.12.01.10.50.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 01 Dec 2017 10:50:49 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_1DE20A08-D0A4-46F6-ABCC-3EA0223DBC11" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <20171129085745.uklljn2v4i7uijxc@elstar.local> Date: Fri, 1 Dec 2017 10:50:44 -0800 Cc: Henk Birkholz , netconf@ietf.org Message-Id: <1E43CFC7-2406-49A8-9409-21A0ACD9D7D7@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> <39F2AA7E-EC42-4C30-A8BE-53A40A521DC3@gmail.com> <20171129085745.uklljn2v4i7uijxc@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: Fri, 01 Dec 2017 18:50:54 -0000 --Apple-Mail=_1DE20A08-D0A4-46F6-ABCC-3EA0223DBC11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Juergen, I want to separate the question of whether YANG Library should address = anything beyond supporting NMDA from the discussion on feature requests = made in the meeting. Focusing on the latter for now. > On Nov 29, 2017, at 12:57 AM, Juergen Schoenwaelder = wrote: >=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. Yes, this is about YANG Library. >=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. The proposal (as Andy also suggested) would be to have an additional = flag that indicates the ability to support or not support a module. = Since YANG Library announces the capability of the server, this = additional flag could indicated whether the module (even though = announced) is =E2=80=9Cnot-supportable=E2=80=9D for whatever reason. The = license module could set the flag to indicate that the module is = =E2=80=9Cnot-supportable=E2=80=9D if the license for a particular module = is required but missing, or the infra manager could set it because the = line card is missing. At the minimum, it takes the guess work out of the = client for whether a particular configuration will work on not. >=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. This puts the onus on the client and for the client to figure out = whether the necessary hardware is present. For that to happen, the = client has to figure out which modules are impacted by the = presence/absence of which hardware - no easy feat with the plethora of = devices and the different pieces of hardware in them. The server on the = other hand is in a better position to provide that information. >=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. Restarting the NC/RC server every time the YANG Library content changes, = is certainly an option. It will mean that existing sessions will be = reset every time the server restarts. The other option I was considering = was for the server to support the =E2=80=98kill HUP=E2=80=99 option, = which forces it to re-read the YANG Library contents. Its downside is = that, currently, there is no mechanism in place to announce a new set of = capabilities. >=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. I would like discuss the solution before deciding whether the solution = should be part of the YANG Library draft, or an augmentation of the YANG = Library module. Thanks. >=20 > /js >=20 > On Tue, Nov 28, 2017 at 11:02:55AM -0800, Mahesh Jethanandani wrote: >>=20 >>> 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 >>=20 >> 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= >>=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. >>=20 >> 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? >>=20 >>> - semantic versioning should be part of the YANG Library >>=20 >> 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 >>>=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. >>=20 >> 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. >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf = >=20 >=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 --Apple-Mail=_1DE20A08-D0A4-46F6-ABCC-3EA0223DBC11 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Juergen,

I = want to separate the question of whether YANG Library should address = anything beyond supporting NMDA from the discussion on feature requests = made in the meeting. Focusing on the latter for now.

On Nov 29, 2017, at 12:57 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> 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.

Yes, this is = about YANG Library.


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.

The proposal (as Andy also suggested) would be to have = an additional flag that indicates the ability to support or not support = a module. Since YANG Library announces the capability of the server, = this additional flag could indicated whether the module (even though = announced) is =E2=80=9Cnot-supportable=E2=80=9D for whatever reason. The = license module could set the flag to indicate that the module is = =E2=80=9Cnot-supportable=E2=80=9D if the license for a particular module = is required but missing, or the infra manager could set it because the = line card is missing. At the minimum, it takes the guess work out of the = client for whether a particular configuration will work on = not.


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.

This puts the = onus on the client and for the client to figure out whether the = necessary hardware is present. For that to happen, the client has to = figure out which modules are impacted by the presence/absence of which = hardware - no easy feat with the plethora of devices and the different = pieces of hardware in them. The server on the other hand is in a better = position to provide that information.


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.

Restarting = the NC/RC server every time the YANG Library content changes, is = certainly an option. It will mean that existing sessions will be reset = every time the server restarts. The other option I was considering was = for the server to support the =E2=80=98kill HUP=E2=80=99 option, which = forces it to re-read the YANG Library contents. Its downside is that, = currently, there is no mechanism in place to announce a new set of = capabilities.


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.

I would = like discuss the solution before deciding whether the solution should be = part of the YANG Library draft, or an augmentation of the YANG Library = module.

Thanks.


/js

On Tue, Nov 28, 2017 at 11:02:55AM -0800, = Mahesh Jethanandani wrote:

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 <https://www.ietf.org/audio/ietf100/> 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 =         <http://www.jacobs-university.de/>

Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_1DE20A08-D0A4-46F6-ABCC-3EA0223DBC11-- From nobody Fri Dec 1 11:25: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 EAE46127599 for ; Fri, 1 Dec 2017 11:25:53 -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 VAOfqQjwrY-p for ; Fri, 1 Dec 2017 11:25:51 -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 BD1A1126CB6 for ; Fri, 1 Dec 2017 11:25:50 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 88CF3E91; Fri, 1 Dec 2017 20:25:49 +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 ofiiiP993tdC; Fri, 1 Dec 2017 20:25:48 +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; Fri, 1 Dec 2017 20:25:49 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 54C9720128; Fri, 1 Dec 2017 20:25:49 +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 lYrahy5N5mRV; Fri, 1 Dec 2017 20:25:47 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C51020126; Fri, 1 Dec 2017 20:25:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EA3054188B6C; Fri, 1 Dec 2017 20:24:18 +0100 (CET) Date: Fri, 1 Dec 2017 20:24:18 +0100 From: Juergen Schoenwaelder To: Mahesh Jethanandani Cc: Henk Birkholz , netconf@ietf.org Message-ID: <20171201192418.sbzizvhgvscxhklg@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Mahesh Jethanandani , Henk Birkholz , netconf@ietf.org 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: <1E43CFC7-2406-49A8-9409-21A0ACD9D7D7@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: Fri, 01 Dec 2017 19:25:54 -0000 On Fri, Dec 01, 2017 at 10:50:44AM -0800, Mahesh Jethanandani wrote: > > > > 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. > > The proposal (as Andy also suggested) would be to have an additional flag that indicates the ability to support or not support a module. Since YANG Library announces the capability of the server, this additional flag could indicated whether the module (even though announced) is “not-supportable†for whatever reason. The license module could set the flag to indicate that the module is “not-supportable†if the license for a particular module is required but missing, or the infra manager could set it because the line card is missing. At the minimum, it takes the guess work out of the client for whether a particular configuration will work on not. > As explained, for interfaces we explicitely do support the configuration of interfaces that are not currently present. > > 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. > > This puts the onus on the client and for the client to figure out whether the necessary hardware is present. For that to happen, the client has to figure out which modules are impacted by the presence/absence of which hardware - no easy feat with the plethora of devices and the different pieces of hardware in them. The server on the other hand is in a better position to provide that information. > NMDA makes this relatively easy since it exposes the difference between intended and applied config. Something configured for hardware not present won't show up in applied config. Hot plugable hardware comes and goes asynchronously. Do you expect that removal of the last linecard of type X removes all _configuration_ for linecards of type X? If I plug it back everything is lost? I think the NETCONF approach is that the config is maintained on the device (not the linecard) and that you can expect the config to be applied again is a linecard of type X is inserted into the same slot again. > > 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. > > Restarting the NC/RC server every time the YANG Library content changes, is certainly an option. It will mean that existing sessions will be reset every time the server restarts. The other option I was considering was for the server to support the ‘kill HUP’ option, which forces it to re-read the YANG Library contents. Its downside is that, currently, there is no mechanism in place to announce a new set of capabilities. > I did not suggest to restart the server every time YANG library changes. All I said is that the content of YANG library can change, i.e., it is not necessarily static throughout the lifetime of a server. (I also assume that a 1:1 mapping of server features that can be enabled/disabled or hardware resources that can be present or absent to modules is not necessarily likely. I consider it somewhat likely that enabling a server features cause changes in several modules and their announced features and even deviations. > > 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. > > I would like discuss the solution before deciding whether the solution should be part of the YANG Library draft, or an augmentation of the YANG Library module. > Someone to write up a solution proposal and then we have something to discuss. But in general, the default should be to focus on extensible (augmentable) core models and not to always hold of core models because there is yet one more feature to add. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Dec 1 11:33: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 2F9981286B2 for ; Fri, 1 Dec 2017 11:33:13 -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 wdcj1M2l4Nvg for ; Fri, 1 Dec 2017 11:33:11 -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 13B30126CB6 for ; Fri, 1 Dec 2017 11:33:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22382; q=dns/txt; s=iport; t=1512156791; x=1513366391; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=s7yEibyGSOiSE4610lUT3wHUL5U4iU9SIysKTThehPE=; b=eVSR0Fb0ZuQnhUaI3F7AWKacLccNHs07iADh0Xh2JcT0NGJ6pa5Gdj6B 0ErABKsGaNJkJ0sA3u21Bus3YCMSXXkrN0BPil8MkyTXtQj+IInJv+T9o bk7isXEN+LEtTrkYe71zSavbi+hztXKK+Q8Y6KmQgURGgsbS7YAh26tSz I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAgAUrSFa/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKcmZuJweDeJkWgX2WfRSCAQqFOwIahRFAFwEBAQEBAQEBAWs?= =?us-ascii?q?ohSIBAQEEIwpKEgIBCBEEAQEOGgMCAgIwFAkIAgQBEgiJNmSnF4InJooyAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBHYVLgVaBaYMrgzKBPAESATYfgl+CYwWKSZgZAot?= =?us-ascii?q?diSmEHI9ClhwCERkBgTkBIQI1YWxvFYJjglIcGYFOeId0gSSBFAEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,346,1508803200"; d="scan'208,217";a="327414966" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Dec 2017 19:33:09 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vB1JX9Zi009036 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Dec 2017 19:33:09 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; Fri, 1 Dec 2017 14:33:08 -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, 1 Dec 2017 14:33:08 -0500 From: "Eric Voit (evoit)" To: Balazs Lengyel , "netconf@ietf.org" Thread-Topic: [Netconf] Subscription modified for RPC based subsscription [subscribed-notifications] Thread-Index: AQHTar8dX9MvL+PG7EWy9Gto4vh9U6Muty7w Date: Fri, 1 Dec 2017 19:33:08 +0000 Message-ID: <2dfe34d73ea34a7cb34e00101f2e287a@XCH-RTP-013.cisco.com> References: <6247d70c-a1d0-1a85-e73a-081a9c6f47cc@ericsson.com> In-Reply-To: <6247d70c-a1d0-1a85-e73a-081a9c6f47cc@ericsson.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.86.244.179] Content-Type: multipart/alternative; boundary="_000_2dfe34d73ea34a7cb34e00101f2e287aXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Subscription modified for RPC based subsscription [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: Fri, 01 Dec 2017 19:33:13 -0000 --_000_2dfe34d73ea34a7cb34e00101f2e287aXCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmFsYXpzLA0KDQpXaGF0IGRvIHlvdSB0aGluayBhYm91dCB0aGUgZm9sbG93aW5nIG9wdGlv bnM6DQoNCigxKSBBIGZpbHRlciByZXRyaWV2ZWQgdmlhIHRoZSBsZWFmcmVmIGZvciBhIGR5bmFt aWMgc3Vic2NyaXB0aW9uIGlzIGFwcGxpZWQgZm9yIHRoZSBsaWZlY3ljbGUgb2YgdGhlIHN1YnNj cmlwdGlvbiAodW5sZXNzIG1vZGlmaWVkIHZpYSBhIHNwZWNpZmljIG1vZGlmeS1zdWJzY3JpcHRp b24gUlBDIHJlcXVlc3QgZHJpdmVuIGZyb20gdGhlIHN1YnNjcmliZXIuKSAgICAgSWYgYW4gZW50 cnkgaW4gdGhlIOKAnGZpbHRlcnPigJ0gY29udGFpbmVyIGlzIG1vZGlmaWVkIHZpYSBjb25maWd1 cmF0aW9uIG9wZXJhdGlvbnMsIHRoaXMgaGFzIG5vIGVmZmVjdCBvbiBhbnkgZXhpc3RpbmcgZHlu YW1pYyBzdWJzY3JpcHRpb25zLiAgSXQgaXMgdXAgdG8gdGhlIHN1YnNjcmliZXIgdG8ga25vdy9y ZXRhaW4gdGhlIG1lYW5pbmcgb2YgYSBmaWx0ZXIgZnJvbSB0aGUgdGltZSBvZiBzdWJzY3JpcHRp b24uDQoNCigyKSBJdCBpcyBub3QgYWxsb3dlZCB0byBtb2RpZnkgYW4gZW50cnkgaW4gY29udGFp bmVyIOKAnGZpbHRlcnPigJ0gd2hlcmV2ZXIgYSBzcGVjaWZpYyBpZGVudGlmaWVyIGlzIHVzZWQg YXMgYSBsZWFmcmVmIGJ5IGEgZHluYW1pYyBzdWJzY3JpcHRpb24gLiAgIChJLmUuLCB5b3VyIHNl Y29uZCBvcHRpb24gYmVsb3cuKQ0KDQooMykgQSBkeW5hbWljIHN1YnNjcmlwdGlvbiByZWNlaXZl ciBtdXN0IGxpc3RlbiBmb3Ig4oCcU3Vic2NyaXB0aW9uLW1vZGlmaWVk4oCdIGluIGNhc2Ugb2Yg YSBjb25maWd1cmF0aW9uIGNoYW5nZSBvZiBhIGZpbHRlciBwcm92aWRlZCBieSBsZWFmcmVmLiAg IChJLmUuLCB5b3VyIGZpcnN0IG9wdGlvbiBiZWxvdy4pDQoNCkkgbGlrZSAoMSksICgyKSwgYW5k ICgzKSBpbiB0aGF0IG9yZGVyLiAgTm90ZTogVGhlIG1haW4gcmVhc29uIEkgYW0gaGVzaXRhbnQg YWJvdXQgKDMpIGlzIGJlY2F1c2UgKGEpIGEgZHluYW1pYyBzdWJzY3JpYmVyIGlzIHN1cHBvc2Vk IHRvIGJlIGZ1bGx5IGluIGNoYXJnZSBvZiB0aGUgc3Vic2NyaXB0aW9uIHBvbGljaWVzLCBhbmQg bG9jYWwgYXBwbGljYXRpb25zIHNob3VsZCBub3QgaGF2ZSB0byByZWFjdCB0byBtaWQtc3RyZWFt IHBvbGljeSBjaGFuZ2VzIHRoZXkgZGlkbuKAmXQgaW5pdGlhdGUsIGFuZCAoYikgdGhlcmUgaXMg bW9yZSBjb21wbGV4aXR5IGluIHNldmVyYWwgYXNwZWN0cy4NCg0KRXJpYw0KDQpQLlMuOiBJbmRl cGVuZGVudCBvZiB0aGlzIGlzc3VlIGZvciBkeW5hbWljIHN1YnNjcmlwdGlvbiwgZm9yIGNvbmZp Z3VyZWQgc3Vic2NyaXB0aW9ucyBpdCBpcyBwcm9iYWJseSBnb29kIHRvIGluY2x1ZGUgdGhlIGFj dHVhbCBmaWx0ZXIgcmVmZXJlbmNlZCBmcm9tIHRoZSBmaWx0ZXIgY29udGFpbmVyIHdpdGhpbiB0 aGUgc3Vic2NyaXB0aW9uLXN0YXJ0ZWQgb3Igc3Vic2NyaXB0aW9uLW1vZGlmaWVkLiAgUmlnaHQg bm93LCBqdXN0IGEgbGVhZnJlZiBpcyBwcm92aWRlZCBpbiB0aG9zZSB0d28gbm90aWZpY2F0aW9u LiAgQW5kIHBlciB5b3VyIHBvaW50LCBhIHN1YnNlcXVlbnQgZ2V0IG9uIHRoYXQgZmlsdGVyIGJ5 LXJlZmVyZW5jZSBjb3VsZCBoYXZlIGJlZW4gY2hhbmdlZC4NCg0KRnJvbTogTmV0Y29uZiBbbWFp bHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJhbGF6cyBMZW5neWVs DQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDEsIDIwMTcgMTE6MTEgQU0NClRvOiBuZXRjb25mQGll dGYub3JnDQpTdWJqZWN0OiBbTmV0Y29uZl0gU3Vic2NyaXB0aW9uIG1vZGlmaWVkIGZvciBSUEMg YmFzZWQgc3Vic3NjcmlwdGlvbiBbc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zXQ0KDQoNCkhlbGxv LA0KDQpJZiBhIHN1YnNjcmlwdGlvbiB1c2VzIGEgc3RvcmVkIGZpbHRlciBieS1yZWZlcmVuY2Ug aXQgaXMgcG9zc2libGUgZm9yIGFub3RoZXIgcGFydHkgdG8gbWFsaWNpb3VzbHkgb3IgYWNjaWRl bnRhbGx5IG1vZGlmeSB0aGUgY29udGVudCBvZiB0aGUgc3RvcmVkIGZpbHRlci4gSW4gdGhpcyBj YXNlIHRoZSBSUEMtYmFzZWQgc3Vic2NyaXB0aW9uIGlzIGVmZmVjdGl2ZWx5IG1vZGlmaWVkIHdp dGhvdXQgdGhlIHN1YnNjcmliZXIgbm90aWNpbmcgaXQsIHdoaWNoIGlzIGEgcHJvYmxlbS4gVG8g YXZvaWQgdGhpcyBJIHdvdWxkIGxpa2UNCg0KICAqICAgdGhlIHN1YnNjcmliZXIgdG8gZ2V0IGEg bW9kaWZpZWQtc3Vic2NyaXB0aW9uIG5vdGlmaWNhdGlvbi4gSXQgaXMgbm90IGNsZWFyIGluIGNo YXB0ZXIgIjguMi4gIHN1YnNjcmlwdGlvbi1tb2RpZmllZCIgIHdoZXRoZXIgYSBub3RpZmljYXRp b24gd291bGQgYmUgc2VudCBpbiBzdWNoIGEgY2FzZSBmb3IgY29uZmlndXJlZCBzdWJzY3JpcHRp b25zLiBIb3dldmVyIGl0IGlzIHN0YXRlZCB0aGF0IG5vIHN1Y2ggbm90aWZpY2F0aW9uIGlzIHNl bnQgZm9yICBmb3IgcnBjLWJhc2VkIHN1YnNjcmlwdGlvbnMuICBJTUhPIGEgbm90aWZpY2F0aW9u IGlzIG5lZWRlZCBpbiB0aGlzIGNhc2UgYm90aCBmb3IgcnBjLWJhc2VkIGFuZCBmb3IgY29uZmln dXJlZCBzdWJzY3JpcHRpb25zLg0KDQpvcg0KDQogICogICBpdCBzaG91bGQgYmUgaW1wb3NzaWJs ZSB0byBtb2RpZnkgYSBmaWx0ZXIgaWYgaXQgaXMgdXNlZCBieSBhbiBlc3RhYmxpc2hlZCBzdWJz Y3JpcHRpb24NCg0KUmVnYXJkcyBCYWxhenMNCg0KDQotLQ0KDQpCYWxhenMgTGVuZ3llbCAgICAg ICAgICAgICAgICAgICAgICAgRXJpY3Nzb24gSHVuZ2FyeSBMdGQuDQoNClNlbmlvciBTcGVjaWFs aXN0DQoNCk1vYmlsZTogKzM2LTcwLTMzMC03OTA5ICAgICAgICAgICAgICBlbWFpbDogQmFsYXpz Lkxlbmd5ZWxAZXJpY3Nzb24uY29tPG1haWx0bzpCYWxhenMuTGVuZ3llbEBlcmljc3Nvbi5jb20+ DQo= --_000_2dfe34d73ea34a7cb34e00101f2e287aXCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2Ut MToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29s b3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxp c3QtaWQ6MTY0NzUxNjUwNzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTcwMzYwNTY5ODt9DQpA bGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTY2MDExMjg5NzsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTM5MjQxNTE4Njt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQmFsYXpzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQg dGhlIGZvbGxvd2luZyBvcHRpb25zOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+KDEpIEEgZmlsdGVyIHJldHJpZXZlZCB2aWEgdGhlIGxlYWZyZWYgZm9yIGEgZHlu YW1pYyBzdWJzY3JpcHRpb24gaXMgYXBwbGllZCBmb3IgdGhlIGxpZmVjeWNsZSBvZiB0aGUgc3Vi c2NyaXB0aW9uICh1bmxlc3MgbW9kaWZpZWQgdmlhIGEgc3BlY2lmaWMgbW9kaWZ5LXN1YnNjcmlw dGlvbg0KIFJQQyByZXF1ZXN0IGRyaXZlbiBmcm9tIHRoZSBzdWJzY3JpYmVyLikgJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7SWYgYW4gZW50cnkgaW4gdGhlIOKAnGZpbHRlcnPigJ0gY29udGFpbmVy IGlzIG1vZGlmaWVkIHZpYSBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMsIHRoaXMgaGFzIG5vIGVm ZmVjdCBvbiBhbnkgZXhpc3RpbmcgZHluYW1pYyBzdWJzY3JpcHRpb25zLiZuYnNwOyBJdCBpcyB1 cCB0byB0aGUgc3Vic2NyaWJlciB0byBrbm93L3JldGFpbiB0aGUgbWVhbmluZyBvZiBhIGZpbHRl ciBmcm9tDQogdGhlIHRpbWUgb2Ygc3Vic2NyaXB0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+KDIpIEl0IGlzIG5vdCBhbGxvd2VkIHRvIG1vZGlmeSBhbiBl bnRyeSBpbiBjb250YWluZXIg4oCcZmlsdGVyc+KAnSB3aGVyZXZlciBhIHNwZWNpZmljIGlkZW50 aWZpZXIgaXMgdXNlZCBhcyBhIGxlYWZyZWYgYnkgYSBkeW5hbWljIHN1YnNjcmlwdGlvbiAuJm5i c3A7Jm5ic3A7IChJLmUuLCB5b3VyDQogc2Vjb25kIG9wdGlvbiBiZWxvdy4pPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4oMykgQSBkeW5hbWljIHN1YnNjcmlwdGlv biByZWNlaXZlciBtdXN0IGxpc3RlbiBmb3Ig4oCcU3Vic2NyaXB0aW9uLW1vZGlmaWVk4oCdIGlu IGNhc2Ugb2YgYSBjb25maWd1cmF0aW9uIGNoYW5nZSBvZiBhIGZpbHRlciBwcm92aWRlZCBieSBs ZWFmcmVmLiZuYnNwOyZuYnNwOyAoSS5lLiwgeW91ciBmaXJzdA0KIG9wdGlvbiBiZWxvdy4pICZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBsaWtlICgx KSwgKDIpLCBhbmQgKDMpIGluIHRoYXQgb3JkZXIuJm5ic3A7IE5vdGU6IFRoZSBtYWluIHJlYXNv biBJIGFtIGhlc2l0YW50IGFib3V0ICgzKSBpcyBiZWNhdXNlIChhKSBhIGR5bmFtaWMgc3Vic2Ny aWJlciBpcyBzdXBwb3NlZCB0byBiZSBmdWxseSBpbiBjaGFyZ2Ugb2YNCiB0aGUgc3Vic2NyaXB0 aW9uIHBvbGljaWVzLCBhbmQgbG9jYWwgYXBwbGljYXRpb25zIHNob3VsZCBub3QgaGF2ZSB0byBy ZWFjdCB0byBtaWQtc3RyZWFtIHBvbGljeSBjaGFuZ2VzIHRoZXkgZGlkbuKAmXQgaW5pdGlhdGUs IGFuZCAoYikgdGhlcmUgaXMgbW9yZSBjb21wbGV4aXR5IGluIHNldmVyYWwgYXNwZWN0cy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkVyaWM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlAuUy46IEluZGVwZW5kZW50IG9mIHRoaXMg aXNzdWUgZm9yIGR5bmFtaWMgc3Vic2NyaXB0aW9uLCBmb3IgY29uZmlndXJlZCBzdWJzY3JpcHRp b25zIGl0IGlzIHByb2JhYmx5IGdvb2QgdG8gaW5jbHVkZSB0aGUgYWN0dWFsIGZpbHRlciByZWZl cmVuY2VkIGZyb20gdGhlIGZpbHRlcg0KIGNvbnRhaW5lciB3aXRoaW4gdGhlIHN1YnNjcmlwdGlv bi1zdGFydGVkIG9yIHN1YnNjcmlwdGlvbi1tb2RpZmllZC4mbmJzcDsgUmlnaHQgbm93LCBqdXN0 IGEgbGVhZnJlZiBpcyBwcm92aWRlZCBpbiB0aG9zZSB0d28gbm90aWZpY2F0aW9uLiZuYnNwOyBB bmQgcGVyIHlvdXIgcG9pbnQsIGEgc3Vic2VxdWVudCBnZXQgb24gdGhhdCBmaWx0ZXIgYnktcmVm ZXJlbmNlIGNvdWxkIGhhdmUgYmVlbiBjaGFuZ2VkLiZuYnNwOw0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJhbGF6cyBMZW5neWVsPGJyPg0KPGI+ U2VudDo8L2I+IEZyaWRheSwgRGVjZW1iZXIgMSwgMjAxNyAxMToxMSBBTTxicj4NCjxiPlRvOjwv Yj4gbmV0Y29uZkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbTmV0Y29uZl0gU3Vic2Ny aXB0aW9uIG1vZGlmaWVkIGZvciBSUEMgYmFzZWQgc3Vic3NjcmlwdGlvbiBbc3Vic2NyaWJlZC1u b3RpZmljYXRpb25zXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPkhlbGxvLDxvOnA+PC9v OnA+PC9wPg0KPHA+SWYgYSBzdWJzY3JpcHRpb24gdXNlcyBhIHN0b3JlZCBmaWx0ZXIgYnktcmVm ZXJlbmNlIGl0IGlzIHBvc3NpYmxlIGZvciBhbm90aGVyIHBhcnR5IHRvIG1hbGljaW91c2x5IG9y IGFjY2lkZW50YWxseSBtb2RpZnkgdGhlIGNvbnRlbnQgb2YgdGhlIHN0b3JlZCBmaWx0ZXIuIElu IHRoaXMgY2FzZSB0aGUgUlBDLWJhc2VkIHN1YnNjcmlwdGlvbiBpcyBlZmZlY3RpdmVseSBtb2Rp ZmllZCB3aXRob3V0IHRoZSBzdWJzY3JpYmVyIG5vdGljaW5nIGl0LA0KIHdoaWNoIGlzIGEgcHJv YmxlbS4gVG8gYXZvaWQgdGhpcyBJIHdvdWxkIGxpa2U8bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBl PSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi Pg0KdGhlIHN1YnNjcmliZXIgdG8gZ2V0IGEgbW9kaWZpZWQtc3Vic2NyaXB0aW9uIG5vdGlmaWNh dGlvbi4gSXQgaXMgbm90IGNsZWFyIGluIGNoYXB0ZXIgJnF1b3Q7OC4yLiZuYnNwOyBzdWJzY3Jp cHRpb24tbW9kaWZpZWQmcXVvdDsmbmJzcDsgd2hldGhlciBhIG5vdGlmaWNhdGlvbiB3b3VsZCBi ZSBzZW50IGluIHN1Y2ggYSBjYXNlIGZvciBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMuIEhvd2V2 ZXIgaXQgaXMgc3RhdGVkIHRoYXQgbm8gc3VjaCBub3RpZmljYXRpb24gaXMgc2VudCBmb3ImbmJz cDsNCiBmb3IgcnBjLWJhc2VkIHN1YnNjcmlwdGlvbnMuJm5ic3A7IElNSE8gYSBub3RpZmljYXRp b24gaXMgbmVlZGVkIGluIHRoaXMgY2FzZSBib3RoIGZvciBycGMtYmFzZWQgYW5kIGZvciBjb25m aWd1cmVkIHN1YnNjcmlwdGlvbnMuDQo8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwPm9yPG86cD48 L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwxIGxldmVsMSBsZm8yIj4NCml0IHNob3VsZCBiZSBpbXBvc3NpYmxlIHRvIG1vZGlmeSBh IGZpbHRlciBpZiBpdCBpcyB1c2VkIGJ5IGFuIGVzdGFibGlzaGVkIHN1YnNjcmlwdGlvbjxvOnA+ PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KUmVnYXJkcyBCYWxh enM8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+LS0gPG86cD48L286cD48L3ByZT4N CjxwcmU+QmFsYXpzIExlbmd5ZWwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7RXJpY3Nzb24gSHVuZ2FyeSBM dGQuPG86cD48L286cD48L3ByZT4NCjxwcmU+U2VuaW9yIFNwZWNpYWxpc3Q8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5Nb2JpbGU6ICYjNDM7MzYtNzAtMzMwLTc5MDkmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgZW1haWw6IDxhIGhyZWY9Im1haWx0bzpCYWxhenMuTGVuZ3llbEBlcmljc3Nvbi5jb20iPkJh bGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbTwvYT4gPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2dfe34d73ea34a7cb34e00101f2e287aXCHRTP013ciscocom_-- From nobody Fri Dec 1 11:49: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 D1E48126CB6 for ; Fri, 1 Dec 2017 11:49:23 -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 CSm8NEo09LbV for ; Fri, 1 Dec 2017 11:49:22 -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 E1FAC124D85 for ; Fri, 1 Dec 2017 11:49:21 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A78C3676; Fri, 1 Dec 2017 20:49:20 +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 OwAEWSuYBGnw; Fri, 1 Dec 2017 20:49:19 +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; Fri, 1 Dec 2017 20:49:20 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7088D20128; Fri, 1 Dec 2017 20:49:20 +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 uX-imsyA36mk; Fri, 1 Dec 2017 20:49:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D520220126; Fri, 1 Dec 2017 20:49:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CDAEB4188C5D; Fri, 1 Dec 2017 20:47:50 +0100 (CET) Date: Fri, 1 Dec 2017 20:47:50 +0100 From: Juergen Schoenwaelder To: "Eric Voit (evoit)" Cc: Balazs Lengyel , "netconf@ietf.org" Message-ID: <20171201194750.nb7ayuxvu5oiw2mz@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Eric Voit (evoit)" , Balazs Lengyel , "netconf@ietf.org" References: <6247d70c-a1d0-1a85-e73a-081a9c6f47cc@ericsson.com> <2dfe34d73ea34a7cb34e00101f2e287a@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: <2dfe34d73ea34a7cb34e00101f2e287a@XCH-RTP-013.cisco.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Netconf] Subscription modified for RPC based subsscription [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: Fri, 01 Dec 2017 19:49:24 -0000 What about this option: (0) Do not allow dynamic subscriptions to use configured filters. /js On Fri, Dec 01, 2017 at 07:33:08PM +0000, Eric Voit (evoit) wrote: > Hi Balazs, > > What do you think about the following options: > > (1) A filter retrieved via the leafref for a dynamic subscription is applied for the lifecycle of the subscription (unless modified via a specific modify-subscription RPC request driven from the subscriber.) If an entry in the “filters†container is modified via configuration operations, this has no effect on any existing dynamic subscriptions. It is up to the subscriber to know/retain the meaning of a filter from the time of subscription. > > (2) It is not allowed to modify an entry in container “filters†wherever a specific identifier is used as a leafref by a dynamic subscription . (I.e., your second option below.) > > (3) A dynamic subscription receiver must listen for “Subscription-modified†in case of a configuration change of a filter provided by leafref. (I.e., your first option below.) > > I like (1), (2), and (3) in that order. Note: The main reason I am hesitant about (3) is because (a) a dynamic subscriber is supposed to be fully in charge of the subscription policies, and local applications should not have to react to mid-stream policy changes they didn’t initiate, and (b) there is more complexity in several aspects. > > Eric > > P.S.: Independent of this issue for dynamic subscription, for configured subscriptions it is probably good to include the actual filter referenced from the filter container within the subscription-started or subscription-modified. Right now, just a leafref is provided in those two notification. And per your point, a subsequent get on that filter by-reference could have been changed. > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Balazs Lengyel > Sent: Friday, December 1, 2017 11:11 AM > To: netconf@ietf.org > Subject: [Netconf] Subscription modified for RPC based subsscription [subscribed-notifications] > > > Hello, > > If a subscription uses a stored filter by-reference it is possible for another party to maliciously or accidentally modify the content of the stored filter. In this case the RPC-based subscription is effectively modified without the subscriber noticing it, which is a problem. To avoid this I would like > > * the subscriber to get a modified-subscription notification. It is not clear in chapter "8.2. subscription-modified" whether a notification would be sent in such a case for configured subscriptions. However it is stated that no such notification is sent for for rpc-based subscriptions. IMHO a notification is needed in this case both for rpc-based and for configured subscriptions. > > or > > * it should be impossible to modify a filter if it is used by an established subscription > > 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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Dec 1 12:10: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 6AE10129423 for ; Fri, 1 Dec 2017 12:10:09 -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 S0fQ0cTpOxdf for ; Fri, 1 Dec 2017 12:10:05 -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 37705129408 for ; Fri, 1 Dec 2017 12:09:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5588; q=dns/txt; s=iport; t=1512158999; x=1513368599; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mwFKnsLC5k/mOp/kj0BFfcS+f3uNVw0btmwGltzBRg8=; b=gK1v9F0aXly3BlmaeAFi+cGAGi8o34c4VJr85ftGfQyZ7ShhqyDdQf90 tqaHH+hkClb2L0uU3jrBfydfIbF6TlNrfUfqiDVigsR7r78xdNm7LgKxr IJ6wtq5Jl7Nev76qWD2cf7TeI4CI8UiaJ4lWbiy2fInYxKt30i3+7uLxY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgCMtiFa/5RdJa1ZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDPGZuJweDeJkWgX2XEYIBChgLhElPAhqFEUIVAQEBAQEBAQE?= =?us-ascii?q?BayiFIgEBAQMBAQEhEToJAgUJAgIBCA4CAQQBAQECAgkaAwICAhkMCxQBCAgCB?= =?us-ascii?q?A4FCIoSCBCnDIInilgBAQEBAQEBAQEBAQEBAQEBAQEBAQEdBYEKhDyBVoFpgyu?= =?us-ascii?q?DMoE8ARIBNgomgk6CYwWiYgKLXYkpk16WHAIRGQGBOQE1I2FsbxU6gikJgkkcG?= =?us-ascii?q?YFOeId0gSSBFAEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,346,1508803200"; d="scan'208";a="39093857" 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; 01 Dec 2017 20:09:58 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vB1K9w51020593 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Dec 2017 20:09:58 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; Fri, 1 Dec 2017 15:09:57 -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, 1 Dec 2017 15:09:57 -0500 From: "Eric Voit (evoit)" To: Juergen Schoenwaelder CC: Balazs Lengyel , "netconf@ietf.org" Thread-Topic: [Netconf] Subscription modified for RPC based subsscription [subscribed-notifications] Thread-Index: AQHTar8dX9MvL+PG7EWy9Gto4vh9U6Muty7wgACBrwD//7Bj8A== Date: Fri, 1 Dec 2017 20:09:57 +0000 Message-ID: <2d1387b402c746669522665f3c0abc0c@XCH-RTP-013.cisco.com> References: <6247d70c-a1d0-1a85-e73a-081a9c6f47cc@ericsson.com> <2dfe34d73ea34a7cb34e00101f2e287a@XCH-RTP-013.cisco.com> <20171201194750.nb7ayuxvu5oiw2mz@elstar.local> In-Reply-To: <20171201194750.nb7ayuxvu5oiw2mz@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.86.244.179] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Subscription modified for RPC based subsscription [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: Fri, 01 Dec 2017 20:10:09 -0000 SGkgSnVlcmdlbiwNCg0KPiBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIsIERlY2VtYmVyIDEs IDIwMTcgMjo0OCBQTQ0KPiANCj4gV2hhdCBhYm91dCB0aGlzIG9wdGlvbjoNCj4gDQo+ICgwKSBE byBub3QgYWxsb3cgZHluYW1pYyBzdWJzY3JpcHRpb25zIHRvIHVzZSBjb25maWd1cmVkIGZpbHRl cnMuDQoNClllcyB0aGlzIGlzIHBvc3NpYmxlLiAgSG93ZXZlciBzb21lIHBlb3BsZSBoYXZlIGV4 cHJlc3NlZCBhIGRlc2lyZSB0byBwcmUtcXVhbGlmeSBmaWx0ZXJzIHNvIHRoYXQgaXQgaXMga25v d24gdXAtZnJvbnQgdGhhdCBpdCB3b24ndCBiZSB0b28gY29tcHV0YXRpb25hbGx5IGV4cGVuc2l2 ZS4gIFN1Y2ggcHJlLXF1YWxpZnlpbmcgcmVkdWNlcyBwb3RlbnRpYWwgZmlsdGVyIGVycm9ycywg YW5kIHJlZHVjZXMgdGhlIG5lZWQgZm9yIGNvbXBsZXggcnVuLXRpbWUgZmlsdGVyIGV2YWx1YXRp b25zLg0KDQpFcmljDQoNCiANCj4gL2pzDQo+IA0KPiBPbiBGcmksIERlYyAwMSwgMjAxNyBhdCAw NzozMzowOFBNICswMDAwLCBFcmljIFZvaXQgKGV2b2l0KSB3cm90ZToNCj4gPiBIaSBCYWxhenMs DQo+ID4NCj4gPiBXaGF0IGRvIHlvdSB0aGluayBhYm91dCB0aGUgZm9sbG93aW5nIG9wdGlvbnM6 DQo+ID4NCj4gPiAoMSkgQSBmaWx0ZXIgcmV0cmlldmVkIHZpYSB0aGUgbGVhZnJlZiBmb3IgYSBk eW5hbWljIHN1YnNjcmlwdGlvbiBpcyBhcHBsaWVkDQo+IGZvciB0aGUgbGlmZWN5Y2xlIG9mIHRo ZSBzdWJzY3JpcHRpb24gKHVubGVzcyBtb2RpZmllZCB2aWEgYSBzcGVjaWZpYyBtb2RpZnktDQo+ IHN1YnNjcmlwdGlvbiBSUEMgcmVxdWVzdCBkcml2ZW4gZnJvbSB0aGUgc3Vic2NyaWJlci4pICAg ICBJZiBhbiBlbnRyeSBpbiB0aGUNCj4g4oCcZmlsdGVyc+KAnSBjb250YWluZXIgaXMgbW9kaWZp ZWQgdmlhIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucywgdGhpcyBoYXMgbm8NCj4gZWZmZWN0IG9u IGFueSBleGlzdGluZyBkeW5hbWljIHN1YnNjcmlwdGlvbnMuICBJdCBpcyB1cCB0byB0aGUgc3Vi c2NyaWJlciB0bw0KPiBrbm93L3JldGFpbiB0aGUgbWVhbmluZyBvZiBhIGZpbHRlciBmcm9tIHRo ZSB0aW1lIG9mIHN1YnNjcmlwdGlvbi4NCj4gPg0KPiA+ICgyKSBJdCBpcyBub3QgYWxsb3dlZCB0 byBtb2RpZnkgYW4gZW50cnkgaW4gY29udGFpbmVyIOKAnGZpbHRlcnPigJ0gd2hlcmV2ZXIgYQ0K PiBzcGVjaWZpYyBpZGVudGlmaWVyIGlzIHVzZWQgYXMgYSBsZWFmcmVmIGJ5IGEgZHluYW1pYyBz dWJzY3JpcHRpb24gLiAgIChJLmUuLCB5b3VyDQo+IHNlY29uZCBvcHRpb24gYmVsb3cuKQ0KPiA+ DQo+ID4gKDMpIEEgZHluYW1pYyBzdWJzY3JpcHRpb24gcmVjZWl2ZXIgbXVzdCBsaXN0ZW4gZm9y IOKAnFN1YnNjcmlwdGlvbi0NCj4gbW9kaWZpZWTigJ0gaW4gY2FzZSBvZiBhIGNvbmZpZ3VyYXRp b24gY2hhbmdlIG9mIGEgZmlsdGVyIHByb3ZpZGVkIGJ5IGxlYWZyZWYuDQo+IChJLmUuLCB5b3Vy IGZpcnN0IG9wdGlvbiBiZWxvdy4pDQo+ID4NCj4gPiBJIGxpa2UgKDEpLCAoMiksIGFuZCAoMykg aW4gdGhhdCBvcmRlci4gIE5vdGU6IFRoZSBtYWluIHJlYXNvbiBJIGFtIGhlc2l0YW50DQo+IGFi b3V0ICgzKSBpcyBiZWNhdXNlIChhKSBhIGR5bmFtaWMgc3Vic2NyaWJlciBpcyBzdXBwb3NlZCB0 byBiZSBmdWxseSBpbg0KPiBjaGFyZ2Ugb2YgdGhlIHN1YnNjcmlwdGlvbiBwb2xpY2llcywgYW5k IGxvY2FsIGFwcGxpY2F0aW9ucyBzaG91bGQgbm90IGhhdmUNCj4gdG8gcmVhY3QgdG8gbWlkLXN0 cmVhbSBwb2xpY3kgY2hhbmdlcyB0aGV5IGRpZG7igJl0IGluaXRpYXRlLCBhbmQgKGIpIHRoZXJl IGlzDQo+IG1vcmUgY29tcGxleGl0eSBpbiBzZXZlcmFsIGFzcGVjdHMuDQo+ID4NCj4gPiBFcmlj DQo+ID4NCj4gPiBQLlMuOiBJbmRlcGVuZGVudCBvZiB0aGlzIGlzc3VlIGZvciBkeW5hbWljIHN1 YnNjcmlwdGlvbiwgZm9yIGNvbmZpZ3VyZWQNCj4gc3Vic2NyaXB0aW9ucyBpdCBpcyBwcm9iYWJs eSBnb29kIHRvIGluY2x1ZGUgdGhlIGFjdHVhbCBmaWx0ZXIgcmVmZXJlbmNlZCBmcm9tDQo+IHRo ZSBmaWx0ZXIgY29udGFpbmVyIHdpdGhpbiB0aGUgc3Vic2NyaXB0aW9uLXN0YXJ0ZWQgb3Igc3Vi c2NyaXB0aW9uLQ0KPiBtb2RpZmllZC4gIFJpZ2h0IG5vdywganVzdCBhIGxlYWZyZWYgaXMgcHJv dmlkZWQgaW4gdGhvc2UgdHdvIG5vdGlmaWNhdGlvbi4NCj4gQW5kIHBlciB5b3VyIHBvaW50LCBh IHN1YnNlcXVlbnQgZ2V0IG9uIHRoYXQgZmlsdGVyIGJ5LXJlZmVyZW5jZSBjb3VsZCBoYXZlDQo+ IGJlZW4gY2hhbmdlZC4NCj4gPg0KPiA+IEZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCYWxhenMNCj4gTGVuZ3llbA0KPiA+IFNlbnQ6 IEZyaWRheSwgRGVjZW1iZXIgMSwgMjAxNyAxMToxMSBBTQ0KPiA+IFRvOiBuZXRjb25mQGlldGYu b3JnDQo+ID4gU3ViamVjdDogW05ldGNvbmZdIFN1YnNjcmlwdGlvbiBtb2RpZmllZCBmb3IgUlBD IGJhc2VkIHN1YnNzY3JpcHRpb24NCj4gW3N1YnNjcmliZWQtbm90aWZpY2F0aW9uc10NCj4gPg0K PiA+DQo+ID4gSGVsbG8sDQo+ID4NCj4gPiBJZiBhIHN1YnNjcmlwdGlvbiB1c2VzIGEgc3RvcmVk IGZpbHRlciBieS1yZWZlcmVuY2UgaXQgaXMgcG9zc2libGUgZm9yIGFub3RoZXINCj4gcGFydHkg dG8gbWFsaWNpb3VzbHkgb3IgYWNjaWRlbnRhbGx5IG1vZGlmeSB0aGUgY29udGVudCBvZiB0aGUg c3RvcmVkIGZpbHRlci4NCj4gSW4gdGhpcyBjYXNlIHRoZSBSUEMtYmFzZWQgc3Vic2NyaXB0aW9u IGlzIGVmZmVjdGl2ZWx5IG1vZGlmaWVkIHdpdGhvdXQgdGhlDQo+IHN1YnNjcmliZXIgbm90aWNp bmcgaXQsIHdoaWNoIGlzIGEgcHJvYmxlbS4gVG8gYXZvaWQgdGhpcyBJIHdvdWxkIGxpa2UNCj4g Pg0KPiA+ICAgKiAgIHRoZSBzdWJzY3JpYmVyIHRvIGdldCBhIG1vZGlmaWVkLXN1YnNjcmlwdGlv biBub3RpZmljYXRpb24uIEl0IGlzIG5vdA0KPiBjbGVhciBpbiBjaGFwdGVyICI4LjIuICBzdWJz Y3JpcHRpb24tbW9kaWZpZWQiICB3aGV0aGVyIGEgbm90aWZpY2F0aW9uIHdvdWxkDQo+IGJlIHNl bnQgaW4gc3VjaCBhIGNhc2UgZm9yIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucy4gSG93ZXZlciBp dCBpcyBzdGF0ZWQgdGhhdA0KPiBubyBzdWNoIG5vdGlmaWNhdGlvbiBpcyBzZW50IGZvciAgZm9y IHJwYy1iYXNlZCBzdWJzY3JpcHRpb25zLiAgSU1ITyBhDQo+IG5vdGlmaWNhdGlvbiBpcyBuZWVk ZWQgaW4gdGhpcyBjYXNlIGJvdGggZm9yIHJwYy1iYXNlZCBhbmQgZm9yIGNvbmZpZ3VyZWQNCj4g c3Vic2NyaXB0aW9ucy4NCj4gPg0KPiA+IG9yDQo+ID4NCj4gPiAgICogICBpdCBzaG91bGQgYmUg aW1wb3NzaWJsZSB0byBtb2RpZnkgYSBmaWx0ZXIgaWYgaXQgaXMgdXNlZCBieSBhbiBlc3RhYmxp c2hlZA0KPiBzdWJzY3JpcHRpb24NCj4gPg0KPiA+IFJlZ2FyZHMgQmFsYXpzDQo+ID4NCj4gPg0K PiA+IC0tDQo+ID4NCj4gPiBCYWxhenMgTGVuZ3llbCAgICAgICAgICAgICAgICAgICAgICAgRXJp Y3Nzb24gSHVuZ2FyeSBMdGQuDQo+ID4NCj4gPiBTZW5pb3IgU3BlY2lhbGlzdA0KPiA+DQo+ID4g TW9iaWxlOiArMzYtNzAtMzMwLTc5MDkgICAgICAgICAgICAgIGVtYWlsOg0KPiBCYWxhenMuTGVu Z3llbEBlcmljc3Nvbi5jb208bWFpbHRvOkJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbT4NCj4g DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gDQo+IA0KPiAtLQ0KPiBK dWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBn R21iSA0KPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAy ODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAg PGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K From nobody Fri Dec 1 12:55: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 E8A5D124B17 for ; Fri, 1 Dec 2017 12:55: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, 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 1oIgPFO4n1Ub for ; Fri, 1 Dec 2017 12:55:08 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7FE12420B for ; Fri, 1 Dec 2017 12:55:08 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 5871F60; Fri, 1 Dec 2017 21:55:06 +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 rLMfQDy9fwz0; Fri, 1 Dec 2017 21:55:05 +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; Fri, 1 Dec 2017 21:55:06 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43A8E20128; Fri, 1 Dec 2017 21:55:06 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NbB8D2dViN4J; Fri, 1 Dec 2017 21:55:05 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E38C920126; Fri, 1 Dec 2017 21:55:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5B78C4188D7F; Fri, 1 Dec 2017 21:53:37 +0100 (CET) Date: Fri, 1 Dec 2017 21:53:37 +0100 From: Juergen Schoenwaelder To: "Eric Voit (evoit)" Cc: Balazs Lengyel , "netconf@ietf.org" Message-ID: <20171201205337.vqlw4fdsqarwdh63@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Eric Voit (evoit)" , Balazs Lengyel , "netconf@ietf.org" References: <6247d70c-a1d0-1a85-e73a-081a9c6f47cc@ericsson.com> <2dfe34d73ea34a7cb34e00101f2e287a@XCH-RTP-013.cisco.com> <20171201194750.nb7ayuxvu5oiw2mz@elstar.local> <2d1387b402c746669522665f3c0abc0c@XCH-RTP-013.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2d1387b402c746669522665f3c0abc0c@XCH-RTP-013.cisco.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Netconf] Subscription modified for RPC based subsscription [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: Fri, 01 Dec 2017 20:55:10 -0000 On Fri, Dec 01, 2017 at 08:09:57PM +0000, Eric Voit (evoit) wrote: > Hi Juergen, > > > From: Juergen Schoenwaelder, December 1, 2017 2:48 PM > > > > What about this option: > > > > (0) Do not allow dynamic subscriptions to use configured filters. > > Yes this is possible. However some people have expressed a desire to pre-qualify filters so that it is known up-front that it won't be too computationally expensive. Such pre-qualifying reduces potential filter errors, and reduces the need for complex run-time filter evaluations. > I am not sure I understand. If these filters are _config_, then they will be as efficient as any filter set as part of a dynamic stream registration - both can be changed anytimeq. If they are hard-wired filter, well, then they may be more efficient but then they are not _config_ and likely not changeable via config. So the third option is different entities configure filters and clients use them (without actually understanding them), i.e., a split of responsibilities. In that case, we may be asking for trouble unless there is strong coordination between the entities configuring filters and clients using the configured filters. I do not see the performance gain, I do see a chance to introduce complexity and brittleness. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Dec 1 12:55: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 F198112420B for ; Fri, 1 Dec 2017 12:55: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=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 yNFJtRzrAv3W for ; Fri, 1 Dec 2017 12:55:25 -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 30AD3128BB6 for ; Fri, 1 Dec 2017 12:55:23 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id x20so13112581lff.1 for ; Fri, 01 Dec 2017 12:55:23 -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=HBas0SYCp9xdtFfvAjY3quTxbY+fAut7Sxiv7r7mXpA=; b=RnExBNVnK3fKzipVEKvXVTdhbIJ8Kdo0crpQ/RpSZPUgCeG2jWFdS5IbcCRM2PhJ4f AyB9WS+aWf5b4xoLEpXTPelk3dTD32PdO0HpBcB/nfustDgN7NoNesx39yWwqKOYjUMx CWJtWnb6RjGtrse1ZdFpNAGU4O1R6cPXyE5dQcMzH6mzMLxYVTqdd5d/yNQQ/G+Wshuq Gj12XLZ0MdotMiVqWG1dA5jShJkFG39aquvMT9ABQ/WidTYrd9H2JIXffD8Ttok35lFA 5hwvyC5mx7bmqp8T9Qxk2m0FpS68drjlyNbhIK0lTgkR0zW5+0T51i5H6AQZr2JQS50g y3Zg== 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=HBas0SYCp9xdtFfvAjY3quTxbY+fAut7Sxiv7r7mXpA=; b=XZEn8iQQSNJznXBEPQ1eta7+0W0u9I/WdM/R4Pv9tmy35x/vf+yZfkcduh9Hyuck4E /+vgFeTiipgmePIJ9OR3UtPA49c/E9Qtk2Y/oeGHwERz1wcByjmUO3Tdcy2Wh1yWhNzI dHa18sjTorHHIPdG8qqqU1+GivrmQQe/la/PjtC1PSNgglN6Oh8KJefk+MPwrsWfv7r5 BUgJYBLROdSBjph4I/XmNCiVWrYpCE6Hms+iTYBCDUP839E1P3QUyP1MI9M5dm3C8ovr GgnhcrQU66gudK5NDx6orfwjYpYIfeYxFJdcgJqpBnMvzulQ1L5bfkhoWfbx6FdHBSD3 SA1w== X-Gm-Message-State: AJaThX4HVHLDGDhFew4L9CgvHyRED5ncObSxVTnqwpYc/2L0SWNbY35W W6htaJbZutm+FHIuZpOT5WGpNofor1u4AfU/g5z9/Tq8 X-Google-Smtp-Source: AGs4zMbjELFG+lWYH7zBnNuBNcVpmIaru2OAAkdQaFNR08M1CVPR58Pfr9XjqWL9JaucJ/alQ+j5OX+TfnxEcgeCodE= X-Received: by 10.46.4.149 with SMTP id a21mr5282898ljf.153.1512161721213; Fri, 01 Dec 2017 12:55:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Fri, 1 Dec 2017 12:55:20 -0800 (PST) From: Andy Bierman Date: Fri, 1 Dec 2017 12:55:20 -0800 Message-ID: To: Netconf Content-Type: multipart/alternative; boundary="94eb2c1ab6763c779f055f4d96a0" Archived-At: Subject: [Netconf] yang-push issue: error handling 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 20:55:27 -0000 --94eb2c1ab6763c779f055f4d96a0 Content-Type: text/plain; charset="UTF-8" Hi, IMO the special error handling in YANG Push is not acceptable because it violates NETCONF and RESTCONF error handling procedures. NETCONF says if the operation does not work for any reason an element SHOULD be returned. The returns data even on error. Instead of the common error-tag, error-info, and other fields, there is a subscription-result leaf. If any client (or even server) functionality uses the NETCONF and RESTCONF standard error handling, then subscription-result will not be sent or expected as an error response. Depending on the server implementation, the code that knows about establish-subscription may not get called because common error handling code has already determined there is an to send instead of a data response. Expect that some servers are never going to send data on an operation failure, and will only send instead. >From sec. 3.8: For instance, for the following request: operational 500 Figure 3: Establish-Subscription example the publisher might return: yp:period-unsupported 2000 Figure 4: Error response example BTW, all the filter examples seem to be wrong, including the one above OLD: NEW: Andy --94eb2c1ab6763c779f055f4d96a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

IMO the special error handling in Y= ANG Push is not acceptable
because it violates NETCONF and RESTCO= NF error handling procedures.
NETCONF says if the operation does = not work for any reason an <rpc-error>
element SHOULD be re= turned.

The <establish-subscription> returns= data even on error.
Instead of the common error-tag, error-info,= and other fields,
there is a subscription-result leaf.

If any client (or even server) functionality uses the NETCO= NF and
RESTCONF standard error handling, then subscription-result= will not be
sent or expected as an error response. Depending on = the server
implementation, the code that knows about establish-su= bscription
may not get called because common error handling code = has
already determined there is an <rpc-error> to send inst= ead of a data response.

Expect that some servers a= re never going to send data on an operation
failure, and will onl= y send <rpc-error> instead.


F= rom sec. 3.8:

=
   For instance, for the following request:

<netconf:rpc message-id=3D"101"
   xmlns:netconf=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
   <establish-subscription
       xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed-notificati=
ons"
       xmlns:yp=3D"urn:ietf:params:xml:ns:yang:ietf-yang-push">=
;
      <yp:datastore>
        <yp:source xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-datast=
ores">
          operational
        </yp:source>
        <yp:subtree-filter netconf:type=3D"xpath"
            xmlns:ex=3D"http://example.com/sample-data/1.0"
            select=3D"/ex:foo"/>
      </yp:datastore>
      <yp:period>500</yp:period>
   </establish-subscription>
</netconf:rpc>

                 Figure 3: Establish-Subscription example

   the publisher might return:


<rpc-reply message-id=3D"10=
1"
     xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
   <subscription-result
       xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed-notificati=
ons"
       xmlns:yp=3D"urn:ietf:params:xml:ns:yang:ietf-yang-push">=
;
     yp:period-unsupported
   </subscription-result>
   <period-hint xmlns:"urn:ietf:params:xml:ns:yang:ietf-yang-push&q=
uot;>
      2000
   </period-hint>
</rpc-reply>

                     Figure 4: Error response example


BTW, all the filter examples seem to be wron= g, including the one above

OLD:
        <yp:subtree-filter netconf:type=3D"xpa=
th"
            xmlns:ex=3D"http://example.com/sample-data/1.0"
            select=3D"/ex:foo"/>

NEW:

 =
       <yp:subtree-filter>
           <ex:foo xmlns:ex=3D"http://example.com/sample-data/1.0" />
        </yp:subtree-filter>


Andy

--94eb2c1ab6763c779f055f4d96a0-- From nobody Fri Dec 1 14:01: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 2BB83126557 for ; Fri, 1 Dec 2017 14:01:19 -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 mUbf0kVgMMGl for ; Fri, 1 Dec 2017 14:01:17 -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 3EAD41204DA for ; Fri, 1 Dec 2017 14:01:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3201; q=dns/txt; s=iport; t=1512165677; x=1513375277; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BLubazMAnSs95bLOOTXCTyy3/+vMlhiOVPXuY/wGPoc=; b=fIVYkNX1ntX4+mSMWb2wY5Rw8IQqVAaUtYwUxbTuc0N1MVLsOEncTeBH rK33hh5KAUuN+28pJT1d/QlAO0/GjZsvuvwtTxFOEWhFk7N3rqG+1225c Ajq+YZJV/hlph5fKuxi+428XhN0/6+yG07ve16zZuOtY7xBN4Ia1Lobxo g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgBb0CFa/5tdJa1ZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDPGZuLp0OgX2ZEgofgWKDOgKFK0MUAQEBAQEBAQEBayiFIgE?= =?us-ascii?q?BAQMBOjIKAQIFCQICAQgOAgUDDREQGxclAgQODYoSCKlPilgBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEdBYVGgVaFFIMyghAmhTEFomICi12JKZNelhwCERkBgTkBNiK?= =?us-ascii?q?BTW8VgmQIgn6BTooQgRQBAQE?= X-IronPort-AV: E=Sophos;i="5.45,347,1508803200"; d="scan'208";a="39132890" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Dec 2017 22:01:16 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vB1M1Gbx002833 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Dec 2017 22:01:16 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; Fri, 1 Dec 2017 17:01:15 -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, 1 Dec 2017 17:01:15 -0500 From: "Eric Voit (evoit)" To: Juergen Schoenwaelder CC: Balazs Lengyel , "netconf@ietf.org" Thread-Topic: [Netconf] Subscription modified for RPC based subsscription [subscribed-notifications] Thread-Index: AQHTar8dX9MvL+PG7EWy9Gto4vh9U6Muty7wgACBrwD//7Bj8IAAYf6A//+tPpA= Date: Fri, 1 Dec 2017 22:01:15 +0000 Message-ID: <1d3a52e31e234c3b894401331ac887cd@XCH-RTP-013.cisco.com> References: <6247d70c-a1d0-1a85-e73a-081a9c6f47cc@ericsson.com> <2dfe34d73ea34a7cb34e00101f2e287a@XCH-RTP-013.cisco.com> <20171201194750.nb7ayuxvu5oiw2mz@elstar.local> <2d1387b402c746669522665f3c0abc0c@XCH-RTP-013.cisco.com> <20171201205337.vqlw4fdsqarwdh63@elstar.local> In-Reply-To: <20171201205337.vqlw4fdsqarwdh63@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.86.244.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Subscription modified for RPC based subsscription [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: Fri, 01 Dec 2017 22:01:19 -0000 > From: Juergen Schoenwaelder, December 1, 2017 3:54 PM >=20 > On Fri, Dec 01, 2017 at 08:09:57PM +0000, Eric Voit (evoit) wrote: > > Hi Juergen, > > > > > From: Juergen Schoenwaelder, December 1, 2017 2:48 PM > > > > > > What about this option: > > > > > > (0) Do not allow dynamic subscriptions to use configured filters. > > > > Yes this is possible. However some people have expressed a desire to p= re- > qualify filters so that it is known up-front that it won't be too > computationally expensive. Such pre-qualifying reduces potential filter > errors, and reduces the need for complex run-time filter evaluations. > > >=20 > I am not sure I understand. If these filters are _config_, then they will= be as > efficient as any filter set as part of a dynamic stream registration - bo= th can > be changed anytimeq. Agree. A filter provided by reference, and a filter pre-configured by an o= perator will be equally efficient. > If they are hard-wired filter, well, then they may be > more efficient but then they are not _config_ and likely not changeable v= ia > config. It is possible for a vendor to make hard-wired filters. But as far as I kn= ow, this has not been deeply considered at this point. =20 > So the third option is different entities configure filters and clients u= se them > (without actually understanding them), i.e., a split of responsibilities.= In that > case, we may be asking for trouble unless there is strong coordination > between the entities configuring filters and clients using the configured > filters. I do not see the performance gain, I do see a chance to introduc= e > complexity and brittleness. The benefit is not from the performance gain. The benefit is from pre-qual= ification and pre-testing on the part of an operator -- i.e., the operator = pre-determined that the performance profile of this particular configured f= ilter makes it safe for this particular filter to be exposed for subscripti= on. As an example think of an interfaces container which is populated wi= th physical and logical interfaces. The operator might choose to default r= eject any dynamic subscriptions which refer to interfaces *except* where th= ey have pre-tested the filter, and the filter has been proven to only selec= t physical interface status. There is also some benefit for abstracting platform specific variations. F= or example a pre-configured filter-id of "physical-interface-status" could = be made available for subscription. The actual contents of this filter cou= ld be customized and pre-positioned for a platform+release. This lets new = interfaces be populated, and the filters enhanced without the applications/= subscribers from also having to tweak their requests in order to stay in co= ncert with each publisher software upgrade. The publisher (which knows mor= e about its data structures) has the option of what to expose. Eric > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Fri Dec 1 14:52: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 C82AF126BF6 for ; Fri, 1 Dec 2017 14:52:33 -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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 858MDWqLerCI for ; Fri, 1 Dec 2017 14:52:30 -0800 (PST) Received: from mail-pf0-f178.google.com (mail-pf0-f178.google.com [209.85.192.178]) (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 DB3E712426E for ; Fri, 1 Dec 2017 14:52:29 -0800 (PST) Received: by mail-pf0-f178.google.com with SMTP id e3so5255386pfi.10 for ; Fri, 01 Dec 2017 14:52:29 -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=paQbuhS0FrF3sILJDVK0ZbfFm+vUxeEFNxoSUwRMFWY=; b=Kc4MWuBafJjBzJ9j2OtL6Pn3fusmsPf5rpWUDorw50Hb30nSocRxBUjeE8pq5RHmfT CBZUS1NeYdcTeDH1aenlRxy0widsA3o+ABKMY2ICjipfeSMLepBTdL/cGtJqms4Q8/71 TemhtUZaFkoTe9wlzoZ2SednaKyWPje8Tgs/CuQPG5mpj9tTxTX0cpe6mxDMG0bi+ADO FDv8y0hzGZi/XkPnugSH2NqdPqBuvGol4PuiC2gixCUBS7EK2Mx0cffzYdL4WobKbRuJ 2eJN/o3tZydoXu8BG1geDNgruUyMoTzA3rsaFO3R6XjrJil38Qhr/UlckdVuZnQaWhTj 5Uyw== X-Gm-Message-State: AJaThX4y1/c8PSdXXnrGP1TGiFU7gSfaJRDdEx9lyoKy+oQKJVvrq2Bi OQNEKi0EzQGPMhzu9TcsNNCTR6p7/NA= X-Google-Smtp-Source: AGs4zMbw1kJU36zzENGncrF5Q54D70i9oBNoFZLY0wIUER77iOOzLvbPXky5OfKe6xLGu+yJSjbOyg== X-Received: by 10.99.149.65 with SMTP id t1mr7501716pgn.101.1512168748962; Fri, 01 Dec 2017 14:52:28 -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 x6sm14050454pff.55.2017.12.01.14.52.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Dec 2017 14:52:28 -0800 (PST) To: netconf@ietf.org References: <6247d70c-a1d0-1a85-e73a-081a9c6f47cc@ericsson.com> <2dfe34d73ea34a7cb34e00101f2e287a@XCH-RTP-013.cisco.com> From: Randy Presuhn Message-ID: Date: Fri, 1 Dec 2017 14:52:26 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <2dfe34d73ea34a7cb34e00101f2e287a@XCH-RTP-013.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Netconf] Subscription modified for RPC based subsscription [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: Fri, 01 Dec 2017 22:52:34 -0000 Hi - On 12/1/2017 11:33 AM, Eric Voit (evoit) wrote: > Hi Balazs, > > What do you think about the following options: > > (1) A filter retrieved via the leafref for a dynamic subscription is > applied for the lifecycle of the subscription (unless modified via a > specific modify-subscription RPC request driven from the subscriber.) >     If an entry in the “filters†container is modified via > configuration operations, this has no effect on any existing dynamic > subscriptions.  It is up to the subscriber to know/retain the meaning of > a filter from the time of subscription. I hate this, but if this is the preferred approach, it should be aligned with NMDA to reflect the configuration/operational split. > (2) It is not allowed to modify an entry in container “filters†wherever > a specific identifier is used as a leafref by a dynamic subscription . > (I.e., your second option below.) Awful. How does the administrator who needs to update a filter figure out which subscriptions need to be killed before he/she can do the update? > (3) A dynamic subscription receiver must listen for > “Subscription-modified†in case of a configuration change of a filter > provided by leafref.   (I.e., your first option below.) Cleaner, but I'd question the need for "must" here. A subscriber's use of pre-configured filters presumes a trust relationship between the subscriber and all who have the ability to modify those filters. If there is no such relationship (i.e., the filter might be changed in ways incompatible with the subscriber's goals) then the use of the pre-configured filter is inappropriate. > I like (1), (2), and (3) in that order.  Note: The main reason I am > hesitant about (3) is because (a) a dynamic subscriber is supposed to be > fully in charge of the subscription policies, and local applications > should not have to react to mid-stream policy changes they didn’t > initiate, and (b) there is more complexity in several aspects. > > Eric ... Randy From nobody Fri Dec 1 15:52: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 7D0D5124234 for ; Fri, 1 Dec 2017 15:52:51 -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 y8hEBv1gC_bj for ; Fri, 1 Dec 2017 15:52:49 -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 A189D12009C for ; Fri, 1 Dec 2017 15:52:48 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id x20so13464605lff.1 for ; Fri, 01 Dec 2017 15:52: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 :cc; bh=GlqCR875XzeADLvqcca+eHMhZZncqBRfepc3dQ/BSQc=; b=f3VGirvB8nDt4EdM1KbsxsxYw0HP4VDdVV9S/Gq/hx9VvJQDGvXCiNrRKuLPFJy2By U2KN7puoAxFtAQU2pMx1BrGjnYhwJ0lFQpD6ItYe7LhJCcr+r1v9ZMe57jl3OQIDPs1q o1lPhbrhquP/7ysNd4nAZDuwF/Q+m+Sh27YyrcpWCNa6eyTLrp9DaRkKo0r+3P5re04K sdfsfny+JpKQQ7sqtRV8QkFEvEu+juFys0dSORNMyvJXUIjh8ATfQkbqD39jYCMn9YpO 9yHEivhXgL6uIPULyVJX4OUgrl65HWzw5KMwm5vBvapWuwZk7SkPSXDZOSlj26pnyihV VsFw== 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=GlqCR875XzeADLvqcca+eHMhZZncqBRfepc3dQ/BSQc=; b=aJKlUIyVlbnrTRMiD/LY6xOwIzJNViaiykMLhLCILEsgWRmajiRGUrIDA6flUAS72k u71a7Fmoo+osCOoB3iVUvSdHdaihR5dnfK2Ce7vYRPmzJgBPQZtp6+ubZfK4ixWrQnSc gUZFIo5x7gpMd19bSX705zOSaj3LHtyspZsWRulzieNvXe1IZHEwMTOvtvl5c0A+suSg 7zvoOIkUrsEU8OnCLTnIVsK8vvhEy56rlcJ7kqoQSf5Wb1fsRXZxHhvJjHt+64xfM3Yf 0ObYL6E/sDV4ew4G1suZYCNFtt6ns+aRcnR8vGK39gOUp9/wFEJRWn/sMgR6bZTIfIhU wcqQ== X-Gm-Message-State: AJaThX5L2IDEz430nVoJYvzi+8LxWRQpNSy4JoARqrZHeKQu1+ntg4tf KY6Nbs4V8yKas/I8eBeHpF26SQLGIrKW5ED10AeCtw== X-Google-Smtp-Source: AGs4zMYf6VP+V6RhaTTi8EAgfO8/pNSqkIBz/hk/z+jGN5rWeLI700gadI9LqHg+NUXSbL4WO6reOMlr2BFy+gkjiTM= X-Received: by 10.25.147.23 with SMTP id v23mr4701727lfd.120.1512172366856; Fri, 01 Dec 2017 15:52:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Fri, 1 Dec 2017 15:52:46 -0800 (PST) In-Reply-To: References: <6247d70c-a1d0-1a85-e73a-081a9c6f47cc@ericsson.com> <2dfe34d73ea34a7cb34e00101f2e287a@XCH-RTP-013.cisco.com> From: Andy Bierman Date: Fri, 1 Dec 2017 15:52:46 -0800 Message-ID: To: Randy Presuhn Cc: Netconf Content-Type: multipart/alternative; boundary="f403045ce2d6c417e0055f50102b" Archived-At: Subject: Re: [Netconf] Subscription modified for RPC based subsscription [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: Fri, 01 Dec 2017 23:52:51 -0000 --f403045ce2d6c417e0055f50102b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Why would a filter-ref be any different for a dynamic vs. configured subscription? The draft needs to state whether it means by reference or by value. If by reference, then any change in a configured filter is immediately applied to all subscriptions using this filter. If by value, then how does a configured subscription ever get changed? If by value, then a could be required for dynamic subscriptions. Does that mean would be required to modify a configured subscription? Seems to me the only interpretation that makes sense is that a filter-ref i= s by reference to a shared filter. If the filter is deleted, then all subscriptions behave as if that filter-ref is disabled and ignored. Andy On Fri, Dec 1, 2017 at 2:52 PM, Randy Presuhn < randy_presuhn@alumni.stanford.edu> wrote: > Hi - > > On 12/1/2017 11:33 AM, Eric Voit (evoit) wrote: > >> Hi Balazs, >> >> What do you think about the following options: >> >> (1) A filter retrieved via the leafref for a dynamic subscription is >> applied for the lifecycle of the subscription (unless modified via a >> specific modify-subscription RPC request driven from the subscriber.) >> If an entry in the =E2=80=9Cfilters=E2=80=9D container is modified v= ia configuration >> operations, this has no effect on any existing dynamic subscriptions. I= t >> is up to the subscriber to know/retain the meaning of a filter from the >> time of subscription. >> > > I hate this, but if this is the preferred approach, it should be > aligned with NMDA to reflect the configuration/operational split. > > (2) It is not allowed to modify an entry in container =E2=80=9Cfilters=E2= =80=9D wherever a >> specific identifier is used as a leafref by a dynamic subscription . >> (I.e., your second option below.) >> > > Awful. How does the administrator who needs to update a filter figure > out which subscriptions need to be killed before he/she can do the > update? > > (3) A dynamic subscription receiver must listen for >> =E2=80=9CSubscription-modified=E2=80=9D in case of a configuration chang= e of a filter >> provided by leafref. (I.e., your first option below.) >> > > > Cleaner, but I'd question the need for "must" here. A subscriber's > use of pre-configured filters presumes a trust relationship between > the subscriber and all who have the ability to modify those filters. > If there is no such relationship (i.e., the filter might be changed > in ways incompatible with the subscriber's goals) then the use of > the pre-configured filter is inappropriate. > > I like (1), (2), and (3) in that order. Note: The main reason I am >> hesitant about (3) is because (a) a dynamic subscriber is supposed to be >> fully in charge of the subscription policies, and local applications sho= uld >> not have to react to mid-stream policy changes they didn=E2=80=99t initi= ate, and >> (b) there is more complexity in several aspects. >> >> Eric >> > ... > > Randy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --f403045ce2d6c417e0055f50102b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Why would a filter-ref be any diffe= rent for a dynamic vs. configured subscription?
The draft needs t= o state whether it means by reference or by value.

If by reference, then any change in a configured filter is immediately app= lied to all
subscriptions using this filter.=C2=A0 If by value, t= hen how does a configured subscription
ever get changed? If by va= lue, then a <modify-subscription> could be required
for dyn= amic subscriptions. Does that mean <edit-config> would be required
to modify a configured subscription?

Seems= to me the only interpretation that makes sense is that a filter-ref is
by reference to a shared filter. If the filter is deleted, then all = subscriptions behave
as if that filter-ref is disabled and ignore= d.


Andy


On F= ri, Dec 1, 2017 at 2:52 PM, Randy Presuhn <randy_presuhn@a= lumni.stanford.edu> wrote:
= Hi -

On 12/1/2017 11:33 AM, Eric Voit (evoit) wrote:
Hi Balazs,

What do you think about the following options:

(1) A filter retrieved via the leafref for a dynamic subscription is applie= d for the lifecycle of the subscription (unless modified via a specific mod= ify-subscription RPC request driven from the subscriber.)=C2=A0 =C2=A0=C2= =A0=C2=A0=C2=A0If an entry in the =E2=80=9Cfilters=E2=80=9D container is mo= dified via configuration operations, this has no effect on any existing dyn= amic subscriptions.=C2=A0 It is up to the subscriber to know/retain the mea= ning of a filter from the time of subscription.

I hate this, but if this is the preferred approach, it should be
aligned with NMDA to reflect the configuration/operational split.

(2) It is not allowed to modify an entry in container =E2=80=9Cfilters=E2= =80=9D wherever a specific identifier is used as a leafref by a dynamic sub= scription .=C2=A0 =C2=A0(I.e., your second option below.)

Awful.=C2=A0 How does the administrator who needs to update a filter figure=
out which subscriptions need to be killed before he/she can do the
update?

(3) A dynamic subscription receiver must listen for =E2=80=9CSubscription-m= odified=E2=80=9D in case of a configuration change of a filter provided by = leafref.=C2=A0=C2=A0 (I.e., your first option below.)


Cleaner, but I'd question the need for "must" here.=C2=A0 A s= ubscriber's
use of pre-configured filters presumes a trust relationship between
the subscriber and all who have the ability to modify those filters.
If there is no such relationship (i.e., the filter might be changed
in ways incompatible with the subscriber's goals) then the use of
the pre-configured filter is inappropriate.

I like (1), (2), and (3) in that order.=C2=A0 Note: The main reason I am he= sitant about (3) is because (a) a dynamic subscriber is supposed to be full= y in charge of the subscription policies, and local applications should not= have to react to mid-stream policy changes they didn=E2=80=99t initiate, a= nd (b) there is more complexity in several aspects.

Eric
...

Randy

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

--f403045ce2d6c417e0055f50102b-- From nobody Fri Dec 1 16:56: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 EB2E9126DC2 for ; Fri, 1 Dec 2017 16:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9B_VAesFh3H9 for ; Fri, 1 Dec 2017 16:56:55 -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 9D81B126C26 for ; Fri, 1 Dec 2017 16:56:55 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id e14so5182414pgr.9 for ; Fri, 01 Dec 2017 16:56:55 -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:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cBFGn6UfPxQuyR9+j85wW7EEB1Dp3F+Gc/n03WydmGM=; b=rCVuVyOkFzwPq9IFEUjXaFP3YWmPcWqcmMIivzYsoGjOOUnvpR6dBWPcv7uCzsBiJv FEAFwLfBMNx/LzF0CeG1bcgfj1amm7bsxLCZ6vsUEI60Q2LqcJuh2BGBxL0h//msrmTS 1H5oRkc0ctfnaMZDFoYnguZEqIa8Q9f4CJK+4p7foZC/jBEWUdlK5ldj02LWLx031xIa lzlOEXGrlMm78fJLibJZpDw47xRm/EPVXnNSmbdFskg4frVpU/YL27T9Sgp7W9KN6PTv oZMRmeYyu/2LDz97qdzSST/ELjaI69knHtR4bTjYlSTXTkJ8BVjF2HzG6D4soHyFCsFy guTw== X-Gm-Message-State: AJaThX4ev+ST2EwpYMs6m+YFU0P9/HHyh/pjMVrtico8URGMHVeKxlA+ ibtPkhrg/EE2Xyq42bVso6nmTp0lwas= X-Google-Smtp-Source: AGs4zMYxNzTejTrnyB0DvjcMZDX2UBfzmpqgRdlS1MhMRE/JUhBfJjnUVa4wmI7DyAqVEQbCwlcU1Q== X-Received: by 10.99.109.193 with SMTP id i184mr7503768pgc.187.1512176154793; Fri, 01 Dec 2017 16:55:54 -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 c8sm1284883pfm.92.2017.12.01.16.55.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Dec 2017 16:55:54 -0800 (PST) Cc: Netconf References: <6247d70c-a1d0-1a85-e73a-081a9c6f47cc@ericsson.com> <2dfe34d73ea34a7cb34e00101f2e287a@XCH-RTP-013.cisco.com> From: Randy Presuhn Message-ID: <0d87fb9c-b4bb-b973-447d-eee5e0ba0413@alumni.stanford.edu> Date: Fri, 1 Dec 2017 16:55:51 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Thunderbird/52.5.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] Subscription modified for RPC based subsscription [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: Sat, 02 Dec 2017 00:56:57 -0000 Hi - On 12/1/2017 3:52 PM, Andy Bierman wrote: > Why would a filter-ref be any different for a dynamic vs. configured > subscription? I see no reason to treat them differently. > The draft needs to state whether it means by reference or by value. Reference makes sense to me; I was rather taken aback by option (1) which would effectively treat as call-by-value. > If by reference, then any change in a configured filter is immediately > applied to all > subscriptions using this filter. Makes total sense to me. It's also reasonable because the decision to refer to a filter presumes a trust relationship between the filter's user and whatever has the authority to change that filter. > If by value, then how does a > configured subscription > ever get changed? If by value, then a could be > required > for dynamic subscriptions. Does that mean would be required > to modify a configured subscription? Agree, the "call-by-value" approach seems to me to be fraught with complications that do not improve the overall manageability of the system. > Seems to me the only interpretation that makes sense is that a filter-ref is > by reference to a shared filter. If the filter is deleted, then all > subscriptions behave > as if that filter-ref is disabled and ignored. Seems very sensible to me. > Andy You pretty much summed up my thinking behind my "hate this" reaction to option (1). Randy From nobody Sat Dec 2 12:02: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 B496D120726 for ; Sat, 2 Dec 2017 12:02:16 -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 ZK2AQzfBKdv8 for ; Sat, 2 Dec 2017 12:02:15 -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 C0642120724 for ; Sat, 2 Dec 2017 12:02:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17176; q=dns/txt; s=iport; t=1512244934; x=1513454534; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6KHfJcXCA2aaX23nOWg9Ob6ZzojCZAI/+81TrkbaZwY=; b=JlMMiHIaXtLDgnC2wCLgnwSCgtAIWCoBYVNmeM5n4Sha0+ab17izCtLK xoqA3euNgPOVXs2WduQPJJYgTX2bRlj2Eo3iWJivwqL6ILzfpnpzx+n8x 0LEUp4KhzmyUXHeYZmwp984no+3bL9z7+eR1LIg78oGUKnm8h0Pd8fNqR c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCAQAeBiNa/4gNJK1bDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCSnJmbicHg3iKII52gX2RNoVLghUKGAEKhElPAhqFET8YAQE?= =?us-ascii?q?BAQEBAQEBayiFIgEBAQEDAQEhCkEEBQIQAgEIFRAaAwICAiULFBECBAENBQiJN?= =?us-ascii?q?mQQpymCJ4pbAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWFS4FWgWmDK4IlgxMfgl+?= =?us-ascii?q?CYwWibAKLXYkpgh+RQIo8i2QCERkBgTkBHzkmgSdvFTqCKYJNBRwZgQ8/eIkJg?= =?us-ascii?q?RQBAQE?= X-IronPort-AV: E=Sophos;i="5.45,349,1508803200"; d="scan'208,217";a="325888545" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Dec 2017 20:02:13 +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 vB2K2Dae004263 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 2 Dec 2017 20:02: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; Sat, 2 Dec 2017 15:02: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; Sat, 2 Dec 2017 15:02:12 -0500 From: "Eric Voit (evoit)" To: Andy Bierman , Randy Presuhn , "Balazs Lengyel (balazs.lengyel@ericsson.com)" CC: Netconf Thread-Topic: [Netconf] Subscription modified for RPC based subsscription [subscribed-notifications] Thread-Index: AQHTar8dX9MvL+PG7EWy9Gto4vh9U6Muty7wgAC1QgCAABDcAIAA+ccw Date: Sat, 2 Dec 2017 20:02:12 +0000 Message-ID: References: <6247d70c-a1d0-1a85-e73a-081a9c6f47cc@ericsson.com> <2dfe34d73ea34a7cb34e00101f2e287a@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.86.250.94] Content-Type: multipart/alternative; boundary="_000_ff9f04f18d054695b3418eddfecbe976XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Subscription modified for RPC based subsscription [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: Sat, 02 Dec 2017 20:02:16 -0000 --_000_ff9f04f18d054695b3418eddfecbe976XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgdGFrZSBvbiB0aGUgZXhjaGFuZ2UgaXMgdGhhdCBSYW5keSwgQmFsYXpzLCBhbmQgQW5keSBh bGwgd291bGQgcHJlZmVyIHRoYXQgYSBtb2RpZnktc3Vic2NyaXB0aW9uIG5vdGlmaWNhdGlvbiBi ZSBhbGxvd2VkIGZvciBhIGR5bmFtaWMgc3Vic2NyaXB0aW9uIHdoZXJlIHRoZXJlIGlzIGEgc2hh cmVkIGZpbHRlci4gIFRoaXMgd291bGQgYWxsb3cgYSBjaGFuZ2Ugb2YgYSByZWZlcmVuY2VkIGZp bHRlciBpZGVudGlmaWVyIHRvIGJlIGRyaXZlbiB0aHJvdWdoIGFsbCBzdWJzY3JpcHRpb25zIGlk ZW50aWNhbGx5LiAgICBJIHdpbGwgbWFrZSB0aGUgY2hhbmdlLg0KDQpFcmljDQoNCkZyb206IEFu ZHkgQmllcm1hbiwgRGVjZW1iZXIgMSwgMjAxNyA2OjUzIFBNDQoNCkhpLA0KDQpXaHkgd291bGQg YSBmaWx0ZXItcmVmIGJlIGFueSBkaWZmZXJlbnQgZm9yIGEgZHluYW1pYyB2cy4gY29uZmlndXJl ZCBzdWJzY3JpcHRpb24/DQpUaGUgZHJhZnQgbmVlZHMgdG8gc3RhdGUgd2hldGhlciBpdCBtZWFu cyBieSByZWZlcmVuY2Ugb3IgYnkgdmFsdWUuDQoNCklmIGJ5IHJlZmVyZW5jZSwgdGhlbiBhbnkg Y2hhbmdlIGluIGEgY29uZmlndXJlZCBmaWx0ZXIgaXMgaW1tZWRpYXRlbHkgYXBwbGllZCB0byBh bGwNCnN1YnNjcmlwdGlvbnMgdXNpbmcgdGhpcyBmaWx0ZXIuICBJZiBieSB2YWx1ZSwgdGhlbiBo b3cgZG9lcyBhIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uDQpldmVyIGdldCBjaGFuZ2VkPyBJZiBi eSB2YWx1ZSwgdGhlbiBhIDxtb2RpZnktc3Vic2NyaXB0aW9uPiBjb3VsZCBiZSByZXF1aXJlZA0K Zm9yIGR5bmFtaWMgc3Vic2NyaXB0aW9ucy4gRG9lcyB0aGF0IG1lYW4gPGVkaXQtY29uZmlnPiB3 b3VsZCBiZSByZXF1aXJlZA0KdG8gbW9kaWZ5IGEgY29uZmlndXJlZCBzdWJzY3JpcHRpb24/DQoN ClNlZW1zIHRvIG1lIHRoZSBvbmx5IGludGVycHJldGF0aW9uIHRoYXQgbWFrZXMgc2Vuc2UgaXMg dGhhdCBhIGZpbHRlci1yZWYgaXMNCmJ5IHJlZmVyZW5jZSB0byBhIHNoYXJlZCBmaWx0ZXIuIElm IHRoZSBmaWx0ZXIgaXMgZGVsZXRlZCwgdGhlbiBhbGwgc3Vic2NyaXB0aW9ucyBiZWhhdmUNCmFz IGlmIHRoYXQgZmlsdGVyLXJlZiBpcyBkaXNhYmxlZCBhbmQgaWdub3JlZC4NCg0KDQpBbmR5DQoN Cg0KDQpPbiBGcmksIERlYyAxLCAyMDE3IGF0IDI6NTIgUE0sIFJhbmR5IFByZXN1aG4gPHJhbmR5 X3ByZXN1aG5AYWx1bW5pLnN0YW5mb3JkLmVkdTxtYWlsdG86cmFuZHlfcHJlc3VobkBhbHVtbmku c3RhbmZvcmQuZWR1Pj4gd3JvdGU6DQpIaSAtDQoNCk9uIDEyLzEvMjAxNyAxMTozMyBBTSwgRXJp YyBWb2l0IChldm9pdCkgd3JvdGU6DQpIaSBCYWxhenMsDQoNCldoYXQgZG8geW91IHRoaW5rIGFi b3V0IHRoZSBmb2xsb3dpbmcgb3B0aW9uczoNCg0KKDEpIEEgZmlsdGVyIHJldHJpZXZlZCB2aWEg dGhlIGxlYWZyZWYgZm9yIGEgZHluYW1pYyBzdWJzY3JpcHRpb24gaXMgYXBwbGllZCBmb3IgdGhl IGxpZmVjeWNsZSBvZiB0aGUgc3Vic2NyaXB0aW9uICh1bmxlc3MgbW9kaWZpZWQgdmlhIGEgc3Bl Y2lmaWMgbW9kaWZ5LXN1YnNjcmlwdGlvbiBSUEMgcmVxdWVzdCBkcml2ZW4gZnJvbSB0aGUgc3Vi c2NyaWJlci4pICAgICAgSWYgYW4gZW50cnkgaW4gdGhlIOKAnGZpbHRlcnPigJ0gY29udGFpbmVy IGlzIG1vZGlmaWVkIHZpYSBjb25maWd1cmF0aW9uIG9wZXJhdGlvbnMsIHRoaXMgaGFzIG5vIGVm ZmVjdCBvbiBhbnkgZXhpc3RpbmcgZHluYW1pYyBzdWJzY3JpcHRpb25zLiAgSXQgaXMgdXAgdG8g dGhlIHN1YnNjcmliZXIgdG8ga25vdy9yZXRhaW4gdGhlIG1lYW5pbmcgb2YgYSBmaWx0ZXIgZnJv bSB0aGUgdGltZSBvZiBzdWJzY3JpcHRpb24uDQoNCkkgaGF0ZSB0aGlzLCBidXQgaWYgdGhpcyBp cyB0aGUgcHJlZmVycmVkIGFwcHJvYWNoLCBpdCBzaG91bGQgYmUNCmFsaWduZWQgd2l0aCBOTURB IHRvIHJlZmxlY3QgdGhlIGNvbmZpZ3VyYXRpb24vb3BlcmF0aW9uYWwgc3BsaXQuDQooMikgSXQg aXMgbm90IGFsbG93ZWQgdG8gbW9kaWZ5IGFuIGVudHJ5IGluIGNvbnRhaW5lciDigJxmaWx0ZXJz 4oCdIHdoZXJldmVyIGEgc3BlY2lmaWMgaWRlbnRpZmllciBpcyB1c2VkIGFzIGEgbGVhZnJlZiBi eSBhIGR5bmFtaWMgc3Vic2NyaXB0aW9uIC4gICAoSS5lLiwgeW91ciBzZWNvbmQgb3B0aW9uIGJl bG93LikNCg0KQXdmdWwuICBIb3cgZG9lcyB0aGUgYWRtaW5pc3RyYXRvciB3aG8gbmVlZHMgdG8g dXBkYXRlIGEgZmlsdGVyIGZpZ3VyZQ0Kb3V0IHdoaWNoIHN1YnNjcmlwdGlvbnMgbmVlZCB0byBi ZSBraWxsZWQgYmVmb3JlIGhlL3NoZSBjYW4gZG8gdGhlDQp1cGRhdGU/DQooMykgQSBkeW5hbWlj IHN1YnNjcmlwdGlvbiByZWNlaXZlciBtdXN0IGxpc3RlbiBmb3Ig4oCcU3Vic2NyaXB0aW9uLW1v ZGlmaWVk4oCdIGluIGNhc2Ugb2YgYSBjb25maWd1cmF0aW9uIGNoYW5nZSBvZiBhIGZpbHRlciBw cm92aWRlZCBieSBsZWFmcmVmLiAgIChJLmUuLCB5b3VyIGZpcnN0IG9wdGlvbiBiZWxvdy4pDQoN Cg0KQ2xlYW5lciwgYnV0IEknZCBxdWVzdGlvbiB0aGUgbmVlZCBmb3IgIm11c3QiIGhlcmUuICBB IHN1YnNjcmliZXIncw0KdXNlIG9mIHByZS1jb25maWd1cmVkIGZpbHRlcnMgcHJlc3VtZXMgYSB0 cnVzdCByZWxhdGlvbnNoaXAgYmV0d2Vlbg0KdGhlIHN1YnNjcmliZXIgYW5kIGFsbCB3aG8gaGF2 ZSB0aGUgYWJpbGl0eSB0byBtb2RpZnkgdGhvc2UgZmlsdGVycy4NCklmIHRoZXJlIGlzIG5vIHN1 Y2ggcmVsYXRpb25zaGlwIChpLmUuLCB0aGUgZmlsdGVyIG1pZ2h0IGJlIGNoYW5nZWQNCmluIHdh eXMgaW5jb21wYXRpYmxlIHdpdGggdGhlIHN1YnNjcmliZXIncyBnb2FscykgdGhlbiB0aGUgdXNl IG9mDQp0aGUgcHJlLWNvbmZpZ3VyZWQgZmlsdGVyIGlzIGluYXBwcm9wcmlhdGUuDQpJIGxpa2Ug KDEpLCAoMiksIGFuZCAoMykgaW4gdGhhdCBvcmRlci4gIE5vdGU6IFRoZSBtYWluIHJlYXNvbiBJ IGFtIGhlc2l0YW50IGFib3V0ICgzKSBpcyBiZWNhdXNlIChhKSBhIGR5bmFtaWMgc3Vic2NyaWJl ciBpcyBzdXBwb3NlZCB0byBiZSBmdWxseSBpbiBjaGFyZ2Ugb2YgdGhlIHN1YnNjcmlwdGlvbiBw b2xpY2llcywgYW5kIGxvY2FsIGFwcGxpY2F0aW9ucyBzaG91bGQgbm90IGhhdmUgdG8gcmVhY3Qg dG8gbWlkLXN0cmVhbSBwb2xpY3kgY2hhbmdlcyB0aGV5IGRpZG7igJl0IGluaXRpYXRlLCBhbmQg KGIpIHRoZXJlIGlzIG1vcmUgY29tcGxleGl0eSBpbiBzZXZlcmFsIGFzcGVjdHMuDQoNCkVyaWMN Ci4uLg0KDQpSYW5keQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5l dGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dGNvbmYNCg0K --_000_ff9f04f18d054695b3418eddfecbe976XCHRTP013ciscocom_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TXkgdGFrZSBvbiB0aGUgZXhjaGFuZ2Ug aXMgdGhhdCBSYW5keSwgQmFsYXpzLCBhbmQgQW5keSBhbGwgd291bGQgcHJlZmVyIHRoYXQgYSBt b2RpZnktc3Vic2NyaXB0aW9uIG5vdGlmaWNhdGlvbiBiZSBhbGxvd2VkIGZvciBhIGR5bmFtaWMg c3Vic2NyaXB0aW9uIHdoZXJlIHRoZXJlDQogaXMgYSBzaGFyZWQgZmlsdGVyLiZuYnNwOyBUaGlz IHdvdWxkIGFsbG93IGEgY2hhbmdlIG9mIGEgcmVmZXJlbmNlZCBmaWx0ZXIgaWRlbnRpZmllciB0 byBiZSBkcml2ZW4gdGhyb3VnaCBhbGwgc3Vic2NyaXB0aW9ucyBpZGVudGljYWxseS4gJm5ic3A7 Jm5ic3A7Jm5ic3A7SSB3aWxsIG1ha2UgdGhlIGNoYW5nZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkVyaWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbmR5IEJpZXJtYW4sIERlY2Vt YmVyIDEsIDIwMTcgNjo1MyBQTTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaHkgd291bGQgYSBmaWx0ZXItcmVm IGJlIGFueSBkaWZmZXJlbnQgZm9yIGEgZHluYW1pYyB2cy4gY29uZmlndXJlZCBzdWJzY3JpcHRp b24/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGUgZHJhZnQgbmVlZHMgdG8gc3RhdGUgd2hldGhlciBpdCBtZWFucyBieSByZWZlcmVuY2Ugb3Ig YnkgdmFsdWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPklmIGJ5IHJlZmVyZW5jZSwgdGhlbiBhbnkgY2hhbmdlIGluIGEgY29uZmlndXJlZCBm aWx0ZXIgaXMgaW1tZWRpYXRlbHkgYXBwbGllZCB0byBhbGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnN1YnNjcmlwdGlvbnMgdXNpbmcgdGhpcyBm aWx0ZXIuJm5ic3A7IElmIGJ5IHZhbHVlLCB0aGVuIGhvdyBkb2VzIGEgY29uZmlndXJlZCBzdWJz Y3JpcHRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPmV2ZXIgZ2V0IGNoYW5nZWQ/IElmIGJ5IHZhbHVlLCB0aGVuIGEgJmx0O21vZGlmeS1zdWJz Y3JpcHRpb24mZ3Q7IGNvdWxkIGJlIHJlcXVpcmVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5mb3IgZHluYW1pYyBzdWJzY3JpcHRpb25zLiBEb2Vz IHRoYXQgbWVhbiAmbHQ7ZWRpdC1jb25maWcmZ3Q7IHdvdWxkIGJlIHJlcXVpcmVkPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50byBtb2RpZnkgYSBj b25maWd1cmVkIHN1YnNjcmlwdGlvbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VlbXMgdG8gbWUgdGhlIG9ubHkgaW50ZXJwcmV0YXRpb24g dGhhdCBtYWtlcyBzZW5zZSBpcyB0aGF0IGEgZmlsdGVyLXJlZiBpczxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YnkgcmVmZXJlbmNlIHRvIGEgc2hh cmVkIGZpbHRlci4gSWYgdGhlIGZpbHRlciBpcyBkZWxldGVkLCB0aGVuIGFsbCBzdWJzY3JpcHRp b25zIGJlaGF2ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+YXMgaWYgdGhhdCBmaWx0ZXItcmVmIGlzIGRpc2FibGVkIGFuZCBpZ25vcmVkLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gRnJpLCBEZWMgMSwgMjAxNyBhdCAyOjUyIFBNLCBSYW5keSBQcmVzdWhuICZsdDs8YSBocmVm PSJtYWlsdG86cmFuZHlfcHJlc3VobkBhbHVtbmkuc3RhbmZvcmQuZWR1IiB0YXJnZXQ9Il9ibGFu ayI+cmFuZHlfcHJlc3VobkBhbHVtbmkuc3RhbmZvcmQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgLTxicj4NCjxi cj4NCk9uIDEyLzEvMjAxNyAxMTozMyBBTSwgRXJpYyBWb2l0IChldm9pdCkgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQmFsYXpzLDxi cj4NCjxicj4NCldoYXQgZG8geW91IHRoaW5rIGFib3V0IHRoZSBmb2xsb3dpbmcgb3B0aW9uczo8 YnI+DQo8YnI+DQooMSkgQSBmaWx0ZXIgcmV0cmlldmVkIHZpYSB0aGUgbGVhZnJlZiBmb3IgYSBk eW5hbWljIHN1YnNjcmlwdGlvbiBpcyBhcHBsaWVkIGZvciB0aGUgbGlmZWN5Y2xlIG9mIHRoZSBz dWJzY3JpcHRpb24gKHVubGVzcyBtb2RpZmllZCB2aWEgYSBzcGVjaWZpYyBtb2RpZnktc3Vic2Ny aXB0aW9uIFJQQyByZXF1ZXN0IGRyaXZlbiBmcm9tIHRoZSBzdWJzY3JpYmVyLikmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SWYgYW4gZW50cnkgaW4gdGhlIOKAnGZpbHRlcnPigJ0gY29u dGFpbmVyIGlzIG1vZGlmaWVkDQogdmlhIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucywgdGhpcyBo YXMgbm8gZWZmZWN0IG9uIGFueSBleGlzdGluZyBkeW5hbWljIHN1YnNjcmlwdGlvbnMuJm5ic3A7 IEl0IGlzIHVwIHRvIHRoZSBzdWJzY3JpYmVyIHRvIGtub3cvcmV0YWluIHRoZSBtZWFuaW5nIG9m IGEgZmlsdGVyIGZyb20gdGhlIHRpbWUgb2Ygc3Vic2NyaXB0aW9uLjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQpJIGhhdGUgdGhpcywgYnV0IGlmIHRoaXMgaXMgdGhlIHByZWZlcnJlZCBh cHByb2FjaCwgaXQgc2hvdWxkIGJlPGJyPg0KYWxpZ25lZCB3aXRoIE5NREEgdG8gcmVmbGVjdCB0 aGUgY29uZmlndXJhdGlvbi9vcGVyYXRpb25hbCBzcGxpdC48bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oMikgSXQgaXMgbm90IGFsbG93ZWQgdG8gbW9k aWZ5IGFuIGVudHJ5IGluIGNvbnRhaW5lciDigJxmaWx0ZXJz4oCdIHdoZXJldmVyIGEgc3BlY2lm aWMgaWRlbnRpZmllciBpcyB1c2VkIGFzIGEgbGVhZnJlZiBieSBhIGR5bmFtaWMgc3Vic2NyaXB0 aW9uIC4mbmJzcDsgJm5ic3A7KEkuZS4sIHlvdXIgc2Vjb25kIG9wdGlvbiBiZWxvdy4pPG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkF3ZnVsLiZuYnNwOyBIb3cgZG9lcyB0aGUgYWRtaW5p c3RyYXRvciB3aG8gbmVlZHMgdG8gdXBkYXRlIGEgZmlsdGVyIGZpZ3VyZTxicj4NCm91dCB3aGlj aCBzdWJzY3JpcHRpb25zIG5lZWQgdG8gYmUga2lsbGVkIGJlZm9yZSBoZS9zaGUgY2FuIGRvIHRo ZTxicj4NCnVwZGF0ZT88bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4oMykgQSBkeW5hbWljIHN1YnNjcmlwdGlvbiByZWNlaXZlciBtdXN0IGxpc3RlbiBm b3Ig4oCcU3Vic2NyaXB0aW9uLW1vZGlmaWVk4oCdIGluIGNhc2Ugb2YgYSBjb25maWd1cmF0aW9u IGNoYW5nZSBvZiBhIGZpbHRlciBwcm92aWRlZCBieSBsZWFmcmVmLiZuYnNwOyZuYnNwOyAoSS5l LiwgeW91ciBmaXJzdCBvcHRpb24gYmVsb3cuKTxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQo8YnI+DQpDbGVhbmVyLCBidXQgSSdkIHF1ZXN0aW9uIHRoZSBuZWVkIGZvciAmcXVvdDttdXN0 JnF1b3Q7IGhlcmUuJm5ic3A7IEEgc3Vic2NyaWJlcidzPGJyPg0KdXNlIG9mIHByZS1jb25maWd1 cmVkIGZpbHRlcnMgcHJlc3VtZXMgYSB0cnVzdCByZWxhdGlvbnNoaXAgYmV0d2Vlbjxicj4NCnRo ZSBzdWJzY3JpYmVyIGFuZCBhbGwgd2hvIGhhdmUgdGhlIGFiaWxpdHkgdG8gbW9kaWZ5IHRob3Nl IGZpbHRlcnMuPGJyPg0KSWYgdGhlcmUgaXMgbm8gc3VjaCByZWxhdGlvbnNoaXAgKGkuZS4sIHRo ZSBmaWx0ZXIgbWlnaHQgYmUgY2hhbmdlZDxicj4NCmluIHdheXMgaW5jb21wYXRpYmxlIHdpdGgg dGhlIHN1YnNjcmliZXIncyBnb2FscykgdGhlbiB0aGUgdXNlIG9mPGJyPg0KdGhlIHByZS1jb25m aWd1cmVkIGZpbHRlciBpcyBpbmFwcHJvcHJpYXRlLjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgbGlrZSAoMSksICgyKSwgYW5kICgzKSBpbiB0aGF0 IG9yZGVyLiZuYnNwOyBOb3RlOiBUaGUgbWFpbiByZWFzb24gSSBhbSBoZXNpdGFudCBhYm91dCAo MykgaXMgYmVjYXVzZSAoYSkgYSBkeW5hbWljIHN1YnNjcmliZXIgaXMgc3VwcG9zZWQgdG8gYmUg ZnVsbHkgaW4gY2hhcmdlIG9mIHRoZSBzdWJzY3JpcHRpb24gcG9saWNpZXMsIGFuZCBsb2NhbCBh cHBsaWNhdGlvbnMgc2hvdWxkIG5vdCBoYXZlIHRvIHJlYWN0IHRvDQogbWlkLXN0cmVhbSBwb2xp Y3kgY2hhbmdlcyB0aGV5IGRpZG7igJl0IGluaXRpYXRlLCBhbmQgKGIpIHRoZXJlIGlzIG1vcmUg Y29tcGxleGl0eSBpbiBzZXZlcmFsIGFzcGVjdHMuPGJyPg0KPGJyPg0KRXJpYzxvOnA+PC9vOnA+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Li4uPGJyPg0KPGJyPg0K UmFuZHk8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCk5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk5l dGNvbmZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5OZXRjb25mQGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZiIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0 Y29uZjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_ff9f04f18d054695b3418eddfecbe976XCHRTP013ciscocom_-- From nobody Sun Dec 3 01:32:48 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 E3F24124239 for ; Sun, 3 Dec 2017 01:32:46 -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 uERo64bvddq4 for ; Sun, 3 Dec 2017 01:32:44 -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 315931201F2 for ; Sun, 3 Dec 2017 01:32:43 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 7EDBE6A2; Sun, 3 Dec 2017 10:32:41 +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 8-RxlhvI1Mnf; Sun, 3 Dec 2017 10:32:39 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sun, 3 Dec 2017 10:32:41 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A16E20128; Sun, 3 Dec 2017 10:32:41 +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 Xu8xZx4EQotk; Sun, 3 Dec 2017 10:32:40 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B00BE20126; Sun, 3 Dec 2017 10:32:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D8E7F4189F81; Sun, 3 Dec 2017 10:31:11 +0100 (CET) Date: Sun, 3 Dec 2017 10:31:11 +0100 From: Juergen Schoenwaelder To: "Eric Voit (evoit)" Cc: Balazs Lengyel , "netconf@ietf.org" Message-ID: <20171203093111.ea3upmuyjcecmlks@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Eric Voit (evoit)" , Balazs Lengyel , "netconf@ietf.org" References: <6247d70c-a1d0-1a85-e73a-081a9c6f47cc@ericsson.com> <2dfe34d73ea34a7cb34e00101f2e287a@XCH-RTP-013.cisco.com> <20171201194750.nb7ayuxvu5oiw2mz@elstar.local> <2d1387b402c746669522665f3c0abc0c@XCH-RTP-013.cisco.com> <20171201205337.vqlw4fdsqarwdh63@elstar.local> <1d3a52e31e234c3b894401331ac887cd@XCH-RTP-013.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1d3a52e31e234c3b894401331ac887cd@XCH-RTP-013.cisco.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Netconf] Subscription modified for RPC based subsscription [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: Sun, 03 Dec 2017 09:32:47 -0000 On Fri, Dec 01, 2017 at 10:01:15PM +0000, Eric Voit (evoit) wrote: > > The benefit is not from the performance gain. The benefit is from pre-qualification and pre-testing on the part of an operator -- i.e., the operator pre-determined that the performance profile of this particular configured filter makes it safe for this particular filter to be exposed for subscription. As an example think of an interfaces container which is populated with physical and logical interfaces. The operator might choose to default reject any dynamic subscriptions which refer to interfaces *except* where they have pre-tested the filter, and the filter has been proven to only select physical interface status. > This means that the client has to trust the filter to be meaningful and that the entity configuring the filter understands the impact of filter changes on all clients. This can lead to interesting surprises. I have no clue whether operators run networks this way. How does a client select the right filter for its purpose? By a 'well-known' name? Or by reading all filters and analyzing the xpath whether one of them matches its requirements? I doubt the later, so you likely have a more or less fragile name binding. I assume things are simpler and more robust if clients set the filters they need instead of relying on a third party. > There is also some benefit for abstracting platform specific variations. For example a pre-configured filter-id of "physical-interface-status" could be made available for subscription. The actual contents of this filter could be customized and pre-positioned for a platform+release. This lets new interfaces be populated, and the filters enhanced without the applications/subscribers from also having to tweak their requests in order to stay in concert with each publisher software upgrade. The publisher (which knows more about its data structures) has the option of what to expose. You seem to assume that such a filter would have to list all physical interfaces and hence some (manual?) adoption would be needed whenever a linecard is inserted/removed. Would it not be simpler and more robust if an app interested in physical layer interface status changes simply sends the correct filter it needs (which would test that the if:lower-layer-if leaflist is empty in this case)? Perhaps I am just too much a fan of loose coupling, I would not write clients to rely on filters provided by 3rd parties. As long as that can be done, I do not care so much how tight coupling fans deal with the consequences of their designs. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Dec 3 06:49: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 2EB531243FE for ; Sun, 3 Dec 2017 06:49:43 -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 ArKulrnVy8xO for ; Sun, 3 Dec 2017 06:49:40 -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 A7A931205F1 for ; Sun, 3 Dec 2017 06:49:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4528; q=dns/txt; s=iport; t=1512312580; x=1513522180; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CqrvQybyJZtOBiTmY1MgGbKQNOj9vb9De5DYasewlYA=; b=eLkZf8N+RxpwOFxwy3WOUDFR6rt7LsoocQ9LOwyUrmGdarj1u33A7/Hx FdrgSe4mJAFAEs8kCOdjeqdRuIteZOmkVuVTi59IInrLoml7cdXykH8Rt fNg6r/3XxbMYDYMI+GdSIymyG9sbtziKMeLlR995zoK//WBsp7xCRoSh9 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgDADiRa/4gNJK1YAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDPGZuLp0NgX2XFYIBCh+BYoM6AoUrQxQBAQEBAQEBAQFrKIU?= =?us-ascii?q?iAQEBAwE6MgoBAgUJAgIBCA4CBQMNERAbFyUCBA4NihIIqlGKVQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR0FhUaBVoUUhQkCCS4mhTEBBJIGkGYCi12JKZNfliACERk?= =?us-ascii?q?BgTkBNiKBTW8VOoIqCIJ+gU6IUoExgRQBAQE?= X-IronPort-AV: E=Sophos;i="5.45,353,1508803200"; d="scan'208";a="39772918" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Dec 2017 14:49:29 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vB3EnTVb013095 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 3 Dec 2017 14:49:29 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; Sun, 3 Dec 2017 09:49: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; Sun, 3 Dec 2017 09:49:28 -0500 From: "Eric Voit (evoit)" To: Juergen Schoenwaelder CC: Balazs Lengyel , "netconf@ietf.org" Thread-Topic: [Netconf] Subscription modified for RPC based subsscription [subscribed-notifications] Thread-Index: AQHTar8dX9MvL+PG7EWy9Gto4vh9U6Muty7wgACBrwD//7Bj8IAAYf6A//+tPpCAArjAgP//8r5Q Date: Sun, 3 Dec 2017 14:49:28 +0000 Message-ID: References: <6247d70c-a1d0-1a85-e73a-081a9c6f47cc@ericsson.com> <2dfe34d73ea34a7cb34e00101f2e287a@XCH-RTP-013.cisco.com> <20171201194750.nb7ayuxvu5oiw2mz@elstar.local> <2d1387b402c746669522665f3c0abc0c@XCH-RTP-013.cisco.com> <20171201205337.vqlw4fdsqarwdh63@elstar.local> <1d3a52e31e234c3b894401331ac887cd@XCH-RTP-013.cisco.com> <20171203093111.ea3upmuyjcecmlks@elstar.local> In-Reply-To: <20171203093111.ea3upmuyjcecmlks@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.86.250.94] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Subscription modified for RPC based subsscription [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: Sun, 03 Dec 2017 14:49:43 -0000 > From: Juergen Schoenwaelder, December 3, 2017 4:31 AM >=20 > On Fri, Dec 01, 2017 at 10:01:15PM +0000, Eric Voit (evoit) wrote: > > > > The benefit is not from the performance gain. The benefit is from pre- > qualification and pre-testing on the part of an operator -- i.e., the ope= rator > pre-determined that the performance profile of this particular configured > filter makes it safe for this particular filter to be exposed for subscri= ption. > As an example think of an interfaces container which is populated with > physical and logical interfaces. The operator might choose to default re= ject > any dynamic subscriptions which refer to interfaces *except* where they > have pre-tested the filter, and the filter has been proven to only select > physical interface status. > > >=20 > This means that the client has to trust the filter to be meaningful and t= hat > the entity configuring the filter understands the impact of filter change= s on > all clients. This can lead to interesting surprises. Yes, surprises can certainly happen in this case. In the end for a parti= cular type of resource intensive filter an operator will face the choice of= either: (a) allowing an RPC which chooses a pre-configured, pre-tested filter, or (b) not allowing an RPC which is providing its own filter because its CPU i= mpacts cannot be adequately ascertained at run-time.=20 > I have no clue whether operators run networks this way. How does a client > select the right filter for its purpose? By a 'well-known' > name?=20 Yes, this way. I see some parallels in this with SNMP traps -- in that t= hey both include pre-defined logic which can be selected/invoked at runtime= . A big difference from SNMP traps however is that an Operator has the opt= ion of developing, testing, and pre-positioning this logic. > Or by reading all filters and analyzing the xpath whether one of them > matches its requirements? I doubt the later, so you likely have a more or > less fragile name binding.=20 Agree. I don't think this will be likely. > I assume things are simpler and more robust if > clients set the filters they need instead of relying on a third party. Yes, this is simpler. And in no way is this option being prohibited. =20 > > There is also some benefit for abstracting platform specific variations= . For > example a pre-configured filter-id of "physical-interface-status" could b= e > made available for subscription. The actual contents of this filter coul= d be > customized and pre-positioned for a platform+release. This lets new > interfaces be populated, and the filters enhanced without the > applications/subscribers from also having to tweak their requests in orde= r > to stay in concert with each publisher software upgrade. The publisher > (which knows more about its data structures) has the option of what to > expose. >=20 > You seem to assume that such a filter would have to list all physical > interfaces and hence some (manual?) adoption would be needed whenever > a linecard is inserted/removed. Would it not be simpler and more robust i= f > an app interested in physical layer interface status changes simply sends > the correct filter it needs (which would test that the if:lower-layer-if = leaflist > is empty in this case)? Yes, this would be simpler. =20 One thing in the back of my mind though is that the definition of correct m= ight change without the client knowing. This has the potential of leaving c= lients more susceptible to server upgrades where new object instances are e= xposed, and these objects are suddenly and mistakenly selected. This could of course also happen with pre-positioned filters. But many of = these errors may be caught as part of publisher testing.=20 =20 > Perhaps I am just too much a fan of loose coupling, I would not write cli= ents > to rely on filters provided by 3rd parties. As long as that can be done, = I do > not care so much how tight coupling fans deal with the consequences of > their designs. ;-) Thanks, and I do appreciate this discussion. As nothing being proposed is = stopping filters from being provided dynamically in the RPC, loose coupling= options are there. Eric =20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Mon Dec 4 01:08: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 D9C92124207 for ; Mon, 4 Dec 2017 01:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 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] 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 cKI3o58yJlRo for ; Mon, 4 Dec 2017 01:08:20 -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 88BAF1201FA for ; Mon, 4 Dec 2017 01:08:19 -0800 (PST) X-AuditID: c1b4fb3a-7b5619c000003538-42-5a25108168a8 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 11.AC.13624.180152A5; Mon, 4 Dec 2017 10:08:17 +0100 (CET) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 4 Dec 2017 10:08:16 +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=9penfPTBLx0Z/Y3V34KvBdndHjuPXKWQX83HT0Zkwn8=; b=LZE2DcBaN2ZMWOUOFCiSnB0WJmI9PqitzV/xS7LJ8T2QDtsrLMMo+9o7vkcXPwfajaoV0u5I7yE8LqSgGH63XcvNbsBqe6ROfRIwRYlfxrDm5gou/evagrY6OShwzHOuAdcoTat5J72fMFb80MdRnS44/Rh969p620lm+yeJDNU= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.197.144] (91.82.100.59) by VI1PR07MB3440.eurprd07.prod.outlook.com (2603:10a6:802:24::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Mon, 4 Dec 2017 09:08:15 +0000 To: "Eric Voit (evoit)" , Andy Bierman , Randy Presuhn CC: Netconf References: <6247d70c-a1d0-1a85-e73a-081a9c6f47cc@ericsson.com> <2dfe34d73ea34a7cb34e00101f2e287a@XCH-RTP-013.cisco.com> From: Balazs Lengyel Message-ID: <0feb01bc-ed92-9fed-2ded-5cd6c956a2e1@ericsson.com> Date: Mon, 4 Dec 2017 10:07:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: CWXP265CA0047.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:2d::35) To VI1PR07MB3440.eurprd07.prod.outlook.com (2603:10a6:802:24::14) X-MS-Office365-Filtering-Correlation-Id: 2aa327f6-5f92-47df-4b88-08d53af68dc2 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:VI1PR07MB3440; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3440; 3:Y8XM/5Td2YqrcbN69ta+sl2WpvjeWtywymd4K/XsPDq/Z9xd5zg7Q7nlfvtzmDV20qf0kq/lidyVsye4l/WXcuHIkPhIGWkZVNXhQyWZL5lr1UhUHO3SUIu5U+WU7P1HpU/cUNcWAywKRSnLvvcSx11u9lFdeSSDkiX0ab+V/zK28c46J5wWSuWYE4pWmVhD0b9cXkltEIncGmtttc3A6xNSQeGRuduOuPj87/T1fjy37SlJtMCAGI2oFrYAKh0d; 25:GPa/awuGGHXKCgZL+PVv7fotCtWCc2qd9zq5QGkieLDuSImdnZVtzPqQDjiUm+H/yFUnXfrVwplQOynF3Pgvi/TvEGkf9/f0HqXXmtbLoHfHbDckiJhwBef37e9oYGfEGA+wEsVCZDWurbRfpzkz0NJRyk++i1kfyqwtlfMZyS5dKXwxLe4GwhVWdrkVHRUB3rNgJLw4l0QEkcNmc7wRLf1EQ7534l3ey7nLlY+6BHcBRKXlwsKGoy/7uFreOT7Ck9iSPG5VpTny2uMMp6ZidSAt2y/g/vrUufzOX1GuC8jpV0cOoZmd/12HUC3MoYIiOKzh5gD0jOwW8/2Qmlz0Qg==; 31:bEd0vh+sK+JRjZxX9N/B3eQ2/L5MSx0CKYO+hwwGe3G63x2OP/vGBagHHXoqzVzE8y+X/H0qbJddTj9Byb23gnUNRywQKHYnFSwhBoRQbKn2RjW2iONubmG2rIMh1wEBaV+jCDhaY9UZmpEtGBw8rzQsn9nafXvYdT85AOctUJ7Lzg/FLJ5KOYK4aoqth1wRAa78pjUeLUptuHqao12weT1DsENWp03A8PhqNCURBG8= X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VI1PR07MB3440: X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3440; 20:QkDLkL5KKusDDcHIFquJFNRMJIpIg0w+K74xjXFmVj2038rVRNFxfFYn43ryesuVTIBLunu4dPcZ7dBmNwXfA5U2BY+QXef3RggVw5VkCscw3Qmlok+CMVtcbtHBAsFJwmj+odOwFApP49olZEr9sulUya0laPR68ZHh9s5U1DHSxrmtVVslEKvVg2oRNwbp6+O3MUcHhjq+17mxbg4wj7wWJLyPcmzSZCg3rgT6r3UmmrLi0vuQgPKgMyLw1APKXTGEVBna35cpvfUtgsGVBQ/btHBAV62iUpVKNK4NfJaXHN2YfakHMEoikZ3tt9ydr/1EsxSmZm+isxuDJQpsBO6w6UAriZ9/in46CUNaB2uzBzk3vS15OgO8ekBq5htHTyVdFf982mN5NWjTbXqrjnTcH9o5wJ8P3JJwP1hk7TLxl130I0OSVVptt9g4EjTxmeSplQJqNeF0GlnsFNnacYumgutT5hwwe71t/XhCuh7HMqMEWx3jvdZcQ/sR8cKV; 4:KGC3JqXTSLHJJyTHlMmG3OknA2WGOT+kzwWiC5o4O5vt850s0KcW6hVcAdGgPIfVI6DWFbmoIxaFsCaAdkTyjiv9gUSlHjk5bxzkPGo1r4RKsS1bA7Is3qL6+/0PeKNo/Coq53xbQnpPaFLR1Y1qLnjG/Vz4XpSlFcNX4m4dK1v9ki9wZAUzAcQsRcsOxfLJwUjFeYzOrF3TvDxMWaA8ZASfV7r+ss3zABLKyw/Shb3yd9andPnpBN8VvvaAljh3zx0PiJ6vp9UCEZN/vktQOidTlZ2EcrJ5HnzgpbqiXehOuyFVUZ1fqR8xfxM9JCFFjWiKmXWsyKHHOE/ePLaL0J8+8mLX6ibmwKfBC1XWs75p+5TPNW5DYVGftHM3t7am X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(278428928389397)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231022)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148)(201708071742011); SRVR:VI1PR07MB3440; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR07MB3440; X-Forefront-PRVS: 051158ECBB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(346002)(376002)(366004)(39860400002)(252514010)(199003)(24454002)(377424004)(76104003)(189002)(49976008)(33646002)(966005)(65806001)(478600001)(4326008)(105586002)(8936002)(81156014)(36756003)(81166006)(15650500001)(6666003)(2171002)(7736002)(25786009)(83506002)(52116002)(189998001)(86362001)(54356011)(2486003)(23676004)(52146003)(76176011)(68736007)(2950100002)(31696002)(54896002)(23846002)(6306002)(106356001)(8676002)(6246003)(53936002)(236005)(64126003)(6486002)(110136005)(316002)(5660300001)(93886005)(50466002)(66066001)(53546010)(2906002)(606006)(65956001)(97736004)(790700001)(229853002)(6116002)(65826007)(2870700001)(16526018)(16576012)(58126008)(31686004)(3846002)(101416001)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3440; H:[159.107.197.144]; 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: =?utf-8?B?MTtWSTFQUjA3TUIzNDQwOzIzOmxJUk1QN1ZtSmcydXVwU2RwdHAzajZhY1N3?= =?utf-8?B?dThTSlpzZW9zMVd6dXhwMmxhSFdRRGsxT2FNOWUyd05rR2pkanNtc2pMY3Y4?= =?utf-8?B?c01lcnpZdk5raEFrdHlTYU9WaTRUQVFOQkJPNW9GZ1M1aHNoc2RRenRGcnNx?= =?utf-8?B?MngxdHZDeVg3T1NMZmJxZVRUTE8wU3UzdkYvMVhkS3Z5RlhjSUNtS0ZMYXJo?= =?utf-8?B?R3pJWFVuMW9wcWVZNU5ScVFvN0c0c0s2TnE2Q0cydThKOHNkWjlYdnFxc2tU?= =?utf-8?B?WVIrV2toWlM0M3dRWEVRWjJYckFncmQ4VDZ5NkdJb0Z6TE9HU1FkNUVUclJs?= =?utf-8?B?UlRneHluazZIL1VneFdmalFITGVJSk8yWGpxSXJsL283ZDNBTkJja1haamVa?= =?utf-8?B?SVB6QnczNlZnQ2M0dEUyTWRacTloWitDamxFMWh1VlEvYjlKTm9RdlZ4TXFl?= =?utf-8?B?WmpwNXIrS1UvMm1pRWZmYjdVVGhGY1Q4c0NKaWZEbEtORklFeS9OOXVJQjNH?= =?utf-8?B?RFowY2h6V1R3UFp4dS8yUGR6YmltNFpSZ2lkd09mSHp6LzVEZ3hVcW1yZkFs?= =?utf-8?B?WGltUVY1akVVMGpqbXVpVWRwcTZ2OUIxcW5NcUxjYUJnZHNvNXRyZUFKMURa?= =?utf-8?B?TllhTHAxQXpab0pEK0dncDRUZUhQV3pDSjI3bDNHd3M0dmREL3RHcUpPWWJZ?= =?utf-8?B?bFA1RTYvTWhXcFZvQ1JJRms1alJiUUE2QkpRMndON1Jwd3ZFd3doSnVWY0pX?= =?utf-8?B?d3FiYWVRUVl6clFzcitwSU9lam90bGFDend0K0pVdkNWbzJkVUZidFRSdktC?= =?utf-8?B?ckQ3MExVc28weHJreS8zaXYvN2l3ZGxURDRKYmd6Q1dRS2RmNmpDTklnajV2?= =?utf-8?B?WW42a0NmZDlBak9neTBLQlZBeVAyREhBS2RrbEluVnRMSzJ2UFpScjMyQ1Vi?= =?utf-8?B?eEtrUXBKZlZTSkJkcmRDRDl1UjFrdEdLQzZ0b2VoRkRJUllycytXWEpFMWk2?= =?utf-8?B?ZVdBWTNmdVJIQk5OaUV0bU1IMDNTSUNxVUtpODh1aEpUZU1CcXZxUTBOSnJV?= =?utf-8?B?Qkg5OWMrdkhsR1pveG83Tnk0QVJVVnVZeUFlQy81ZXgxek1ZVVNZbUl3c0tO?= =?utf-8?B?R0U1cVIzMHRSaGVUa2MzY3hocnh2c2F6N3RLY1VsTWtEbzlGdWZpUE5vWm8z?= =?utf-8?B?cXI2S05iZTdIbjN2RXFOMUtXbDZDNkNUNlRZRnlFYVB5WUlCQS9TbjE4eld3?= =?utf-8?B?LzJmOWY5OUtvVFJHWUtjeXErSDNMdHdXRDBKeXdIalJuRERoK0R2emliSXc2?= =?utf-8?B?a0M2UFc3T2dLYXRtaGJ0WlltOXNFUWNlREtFTVBBU3lod3h2VTQvWm0zaGJa?= =?utf-8?B?RyszWnhBOEJRNnpaMUtIcEZiMVhRc2xWRUhBNS8ybEFsMEVTeFgyZ0lUNlMy?= =?utf-8?B?U2hpYlBGaVRCTDZKTUwxVkxWWFhvTXVZTDJkT25IRGNxaXZsS0MyWnJwWTFC?= =?utf-8?B?QXdsZThKVTQ4K3BGa3JjUU9ueVRmeEhoUVMxRk5yRlhkeTU3a0pHVytjYXJM?= =?utf-8?B?NlZLRjFLU1Fka2I5OTJQUEp0cldpOGpFSThmWkp1WnJXT3lMSW1vYk50bWFr?= =?utf-8?B?MThMaE1VN2lMR3ZlZXFoc3BPVXB4alVuUmd5aHI3UTFLVjY1NzcreVd5L1VE?= =?utf-8?B?dTdRWU5TT3VWN3h1dE5JS0VkTEZydlpLQm9oYTFaSEcwcFJmYmlXZEh2Nnpn?= =?utf-8?B?ZUgrYm1NbU44amYrcEgrN0tBM1A3bVhMVWtxZGJ0OHVRQVBzSko5MnF4RlZ1?= =?utf-8?B?Y2czem4wcHY3Unl4QVF5NUFnbms4b0ZiS2NhR043TDZwdDJ6Rjc4REViMXU1?= =?utf-8?B?bThWR0JJdGtaMHNiWjl1YkIvUjlZcWxmdlYrT1FCZmJPUGkySzg3eDlMeE9C?= =?utf-8?B?UFYxSnZYRE9NeXZRcWRPSEt1S3htblhxR1NwaWZIcW5GYjVkRjNzeE5zcytQ?= =?utf-8?B?eHIwOXN2dTNVZSt2TG8wVnpiSHNlb3ZGTStZbGVoMzc5Ynlsa1F2QVE4cTBo?= =?utf-8?B?MmRSeU00R3JibERmMHZzUWhWVngzbDgrTHJWMjNXTHZQcUdNQXUzRWx1ZWdJ?= =?utf-8?B?OXBWWGlUMWZIVU42L09Hemk4MVk5RFFVMmo3M0ZJTjh4K081UVZ3eExOQTNy?= =?utf-8?Q?VnGWsq3EPoWl4gYczEmVX7H7gwMqkLObo1dfXpAbeM=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3440; 6:SAkI4DdYAGDc42d6ZpePmSBYufu13NWYfyVWd/S0+/t+hMmqgB1UqE31YmiOKJzl8ZJ6urQ0KxAn+ni2uS8JxQc65F46svhRJ+j0I55hOYzNNGGwZmCfxEKDvICoES4EYNy32KdYuizQL0DTRryhHcT7EpuYYc6+RUiIQ7RInqUKlvSagWOB5gKHE9vtuWIFwAcWiY9Z3vlI+BVIYDt4kZX5j1b2FkLQ/NIefJDntH754mS79SMQVTqbw7Jlrd6U0Sp54ignpGrh+CakLKGPJJ3npXY2JZBgYVuQfiQSEybXQnsKSOf6DQ6h0O1hOQ0MOy0DSAEw7OtYRbgs/H69up9pQ2Db/fyg6MVvhIe5b/o=; 5:FXqJhnZ2Jm9Lwa3sG2aIyEMxNlQkase0bRRmF/kY2aYKxCy92Pnur5fPUag8F4UZb1irJARFDL9WevltBPAHZKsPZr7n/gUd16fLe8ydXG+sMKBuY+JPsElaimjXkeWHuBo0WY/YN6/PZJ+0CBgOeGbhcETh7MLFiasrXEj6JBw=; 24:vlkI46t9XztTi2X+8tcEsLNqd20OPFGC4UyF6xqhgcjwvoXCtxaDFM8jAoQTLUWw8v4gRjmgdoxbd2V15QcvKVk8y51m8eIx+JMi3CjGZyI=; 7:5a6vGq3l6mcF69c4tyBL2lrlQ1PN0JezslxBx5KXgldksDdRcCC6jhEIMome4JS2ycUfam8j7guGotCoSpyKTuqgOc3RkwPiq2pP2Um4q6StEixc6Igt+/YlbeaYBbP++GJz2z0m0vZ+kyMYU/G0bCt+tm3lzSJTUvkiBiO2wk9J6nT5XEgZy/noA/Qi0oC+F9V5SvhlRxaX4Tnm/K1Kj9iWX0+eOnpTHRS2RkK7XV406JHkYkzIcDkxaURDwnYa SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2017 09:08:15.3104 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2aa327f6-5f92-47df-4b88-08d53af68dc2 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3440 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUyM2K7mW6jgGqUwe8HUhYPjsxit3ixejWT xdRNt1kt+s6vY3dg8fh4+BKLx5TfG1k9liz5yeTR0n+RJYAlissmJTUnsyy1SN8ugStj9rWN TAUXUyt+7BZoYNzg0MXIySEhYCJxpOMvE4gtJHCYUWJJY14XIxeQfZxRYtLys2wgCRaBXmaJ llmMIDajQJzEzjULWSGK2pkknr7awwqSEBZIlXi64TobSEJEoJFR4tGk6+wgCWYBOYnFP3qY IDp2Mkm0T10Nto9NwEhiav95FhCbV8BeYs3uH6wQ61QkWo7NBouLCsRIHO6ZzgpRIyhxcuYT sDingKvEpzM/oRZoSLTOmQtli0vcejKfCcKWl2jeOpsZ4k8Fieubr7OAHCEhMI1R4unRU6wQ T2tIPLzwlxWiyFdiXdthNoiiJYwSy/99gXIa2CUerToHNUpW4ujZOSwQtpbE6wu/oIp2sEss uTQFKpEt0bjwKDuEHS1xZ/tbqN0LmCUWPD3MBJGQkZh7bgXLBEadWUj+m4Xkp1lIfpqF5KcF jCyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQKTzMEtv612MB587niIUYCDUYmHl51ZNUqI NbGsuDL3EKMEB7OSCK8DA1CINyWxsiq1KD++qDQntfgQozQHi5I470lP3ighgfTEktTs1NSC 1CKYLBMHp1QDozqPv9obmRzHN6Zsl/9t2PGiNWrVefln6cYcXVmlt1c0nDC01GfYEDO1ZyX3 nLfvZpzZs/u16JK/8pFKptL3DE5uW7J/TbqSRcehu8efvg79U6a57oXu9ccvS9123WXZsuSA Fc8+Dy2vioTGgG7WrXJvVop/uXVmeeNNVaOiuIm75n2+Jl+/uUiJpTgj0VCLuag4EQDzAQi0 LgMAAA== Archived-At: Subject: Re: [Netconf] Subscription modified for RPC based subsscription [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, 04 Dec 2017 09:08:23 -0000

Hello Eric,

Yes my preferred solution is a modify-subscription notification even for a dynamic subscription.

I assume the client will not have to separately subscribe to this notification as it is a trivial need.

regards Balazs


On 2017-12-02 21:02, Eric Voit (evoit) wrote:

My take on the exchange is that Randy, Balazs, and Andy all would prefer that a modify-subscription notification be allowed for a dynamic subscription where there is a shared filter.  This would allow a change of a referenced filter identifier to be driven through all subscriptions identically.    I will make the change.

 

Eric

 

From: Andy Bierman, December 1, 2017 6:53 PM

Hi,

 

Why would a filter-ref be any different for a dynamic vs. configured subscription?

The draft needs to state whether it means by reference or by value.

 

If by reference, then any change in a configured filter is immediately applied to all

subscriptions using this filter.  If by value, then how does a configured subscription

ever get changed? If by value, then a <modify-subscription> could be required

for dynamic subscriptions. Does that mean <edit-config> would be required

to modify a configured subscription?

 

Seems to me the only interpretation that makes sense is that a filter-ref is

by reference to a shared filter. If the filter is deleted, then all subscriptions behave

as if that filter-ref is disabled and ignored.

 

 

Andy

 

 

 

On Fri, Dec 1, 2017 at 2:52 PM, Randy Presuhn <randy_presuhn@alumni.stanford.edu> wrote:

Hi -

On 12/1/2017 11:33 AM, Eric Voit (evoit) wrote:

Hi Balazs,

What do you think about the following options:

(1) A filter retrieved via the leafref for a dynamic subscription is applied for the lifecycle of the subscription (unless modified via a specific modify-subscription RPC request driven from the subscriber.)      If an entry in the “filters†container is modified via configuration operations, this has no effect on any existing dynamic subscriptions.  It is up to the subscriber to know/retain the meaning of a filter from the time of subscription.


I hate this, but if this is the preferred approach, it should be
aligned with NMDA to reflect the configuration/operational split.

(2) It is not allowed to modify an entry in container “filters†wherever a specific identifier is used as a leafref by a dynamic subscription .   (I.e., your second option below.)


Awful.  How does the administrator who needs to update a filter figure
out which subscriptions need to be killed before he/she can do the
update?

(3) A dynamic subscription receiver must listen for “Subscription-modified†in case of a configuration change of a filter provided by leafref.   (I.e., your first option below.)



Cleaner, but I'd question the need for "must" here.  A subscriber's
use of pre-configured filters presumes a trust relationship between
the subscriber and all who have the ability to modify those filters.
If there is no such relationship (i.e., the filter might be changed
in ways incompatible with the subscriber's goals) then the use of
the pre-configured filter is inappropriate.

I like (1), (2), and (3) in that order.  Note: The main reason I am hesitant about (3) is because (a) a dynamic subscriber is supposed to be fully in charge of the subscription policies, and local applications should not have to react to mid-stream policy changes they didn’t initiate, and (b) there is more complexity in several aspects.

Eric

...

Randy

_______________________________________________
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 Mon Dec 4 03:41: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 07D8D120721 for ; Mon, 4 Dec 2017 03:41:28 -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 yNX3Wg--tKU8 for ; Mon, 4 Dec 2017 03:41:24 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 556391201FA for ; Mon, 4 Dec 2017 03:41:24 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id DA3AF1AE0399; Mon, 4 Dec 2017 12:41:21 +0100 (CET) Date: Mon, 04 Dec 2017 12:40:01 +0100 (CET) Message-Id: <20171204.124001.1188267155929301700.mbj@tail-f.com> To: evoit@cisco.com Cc: netconf@ietf.org, balazs.lengyel@ericsson.com, andy@yumaworks.com From: Martin Bjorklund In-Reply-To: <4c2303ac1eff4b0db2dae056d56c9285@XCH-RTP-013.cisco.com> References: <20171128.103735.1654378548309425095.mbj@tail-f.com> <4c2303ac1eff4b0db2dae056d56c9285@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] 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: Mon, 04 Dec 2017 11:41:28 -0000 Hi, "Eric Voit (evoit)" wrote: > 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. Yes. > 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. Agreed. See also my reply to Alex. > 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. Ok. > 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. Ok. > > 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. Ok. > > > > 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. I understand what you want to achieve, but I don't think the text is quite correct. I'll think about this some more to see if I can come up with a better wording. > > 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. This last sentence occurs twice. > 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. Ok. > > 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. Or maybe In a periodic subscription, the data included as part of an update corresponds to data that could have been read using a retrieval operation over that subscription's transport. (no need for MUST here) > > (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". Hmm, that paragraph is: It is not expected that implementations will support comprehensive filter syntax and boundless complexity. It will be up to implementations to describe what is viable, but the goal is to provide equivalent capabilities to what is available with a GET. What is a "comprehensive filter syntax"? Maybe this paragraph can be removed. > > 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: My problem with this style is that it seems to indicate that the selection filter is only used for this use case ("replication of a subset..."), but that would be a mistake. I think you should explain what these filters are first, and then (maybe) give examples of how they can be used. The title "Datastore selection filter" is also misleading; in fact the best solution might be to keep the original text but change the title of the section to "Subscription Policy". > > 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." The text for subtree filters use the words "When specified, updates will only come from the data nodes of selected YANG subtree(s)." If you use the same words here, the text is consistent and easier to understand. Maybe: NEW: o xpath: An xpath selection filter is an XPath expression that returns a node set. When specified, updates will only come from the selected data nodes. > > 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. But you are constraining the entire solution to support just this use case, when a simpler unconstrained solution just as easily supports this use case, *plus other use cases* - if a client does not want these "fake deletes", they can simply construct filters based on keys only, which they would in the current solution anyway. Note also that b/c of the last paragraph in section 3.9, a client must deal with such deletes anyway, even if it specificied only keys. But I do understand your point. This is also related to my comment below about when a filter is evaluated. Based on you reply to that comment, I think the conceptual algorithm is like this: Just before a change, evaluate the filter and any access control rules. The result is a set "A" of nodes (including subnodes). Just after a change, evaluate the filter and any (possibly new) access control rules. The result is a set "B" of nodes (including subnodes). Construct a YANG patch record for going from A to B. If the record is non-empty, send it to the subscriber. (this is conceptual, an implementation can do lots of optimizations to avoid evaluating filters on un-related changes) > 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 What about this one: /interfaces/interface[contains(name, //name)] it also filters on a key is it ok? [if the answer is "yes" we have a problem; and if it is "no", we need to tighten the text] All this makes me wonder if it is correct to have "subtree" and "xpath" filters at all. If they only can match on keys, they become severely constrained. An alternative could be to specify filters as "nacm:node-instance-identifier" instead; these are instance-identitifiers that allow missing keys. For example: /if:interfaces/if:interface/if:oper-status This would be easier to understand and probably easier to optimize for in the server code. > > 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. Maybe "patch-id" could be a sequential number, starting from 1 when the first patch is sent? Or simply any string that the server finds appropriate. In any case, "null" looks odd in the example. > 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"> > > > > > > > > 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. Ok, but the error code is used as a return value for "establish-subscription". So if a server can't detect it at "establish-subscription" it mean it will never be used. Hence I suggest you remove the text about "authorization privileges". BTW, does this imply that I cannot create a filter for a currently non-existing interface? If this is true, my conceptual filter evaluation algorithm above is not correct... > > 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.) Aha, ok. But then it looks really weird to have "scubscription-id" in the notifications defined in this module. It will be redundant. Or do you suggest that *all* YANG modules that publish notifications must have a leaf "subscription-id", until the notification header document is done? If not, why is this document special? > > 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. Ok. So this means that when we have these new headers, "time-of-update" is no longer needed, right? But actually, currently we have "eventTime". And since "notification-time" is equivalent to "eventTime", and "time-of-update" is "notification-time", it follows that "time-of-update" is redundant and not needed today either. Correct? > 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" I suggest you remove the sentence instead, and some more redundant words to get: OLD: An "updates-not-sent" object, which indicates that the update record is incomplete. If the application detects an informational discontinuity in either notification, the notification message MUST include "updates-not-sent". This object indicates that not all changes which have occurred since the last update are actually included with this update. NEW: An "updates-not-sent" object. This object indicates that not all changes which have occurred since the last update are actually included with this 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. No. See RFC7950, section 8.3.1, bullet 4. And compare with all other modules that use if-feature; no other module has invented such error codes. > 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. Ok; i.e., the text should explain that it is used if the client asks for an obejct that does not support on-change. The if-feature case is already handled as described above. > > 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 But in this case the error will be "on-change-unsupported", right? > ). 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 Huh? What does *that* mean? > > 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 It will use ds:datastore as base. If we need some other generic base from which custom datastores are derived, that identity should be defined in a generic place (ietf-datastores probably), and not here. > , 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. Yes. (At least from this document.) > > 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."; You didn't reply to this. My point is > > > > 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. I think there's some confusion here. How would the "excluded-change" leaf-list be used in this case? (the typedef we're discussing is only used in "excluded-change") If an application needs to know *every* change, it probably shouldn't use a dampening period. > (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" Well, yes this certainly needs to be described. I will have to think about the implications of this change. > > 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. So then that has to be explained. Otherwise, one might think that the filter is evaluated once, and then changes are reported whenever any node in the selected subtrees are changed. See also my conceptual algorithm above. > 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. I think it is important to try to design a standard so that it is useful for more than one current use case. In this case, it seems to me that the qos parameters logically belong to the subscribed notifications layer, and thus should be defined there. > > 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. Ok. > > 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". Ok. > > 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 From nobody Mon Dec 4 04:57: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 2362B124BAC for ; Mon, 4 Dec 2017 04:57:03 -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 joig7HdOBR4S for ; Mon, 4 Dec 2017 04:57:01 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 158D21200C5 for ; Mon, 4 Dec 2017 04:57:01 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 5D1281AE0399; Mon, 4 Dec 2017 13:56:59 +0100 (CET) Date: Mon, 04 Dec 2017 13:55:39 +0100 (CET) Message-Id: <20171204.135539.1530792967351325058.mbj@tail-f.com> To: andy@yumaworks.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=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] yang-push issue: error handling 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, 04 Dec 2017 12:57:03 -0000 Andy Bierman wrote: > Hi, > > IMO the special error handling in YANG Push is not acceptable > because it violates NETCONF and RESTCONF error handling procedures. > NETCONF says if the operation does not work for any reason an > element SHOULD be returned. I fully agree, and I have pointed this out several times in my reviews. The problem is actually in subscribed notifications, and I think Eric is tracking that issue. Trying to be constructive, I think that the existing mechanisms in YANG can be used to achieve the same functionality that these drafts try to achieve. Specifically: 1. Use identities just like the ones you have ("unsupportable-volume", "filter-unavailable" etc), but add text that explains that these identities are sent as "error-app-tag" in "rpc-error", encoded to a string as :. This works for both NETCONF and RESTCONF. 2. For the "hints" extra info that you return, define a "yang-data" structure with the hints, and explain in text that this structure is returned in "error-info". This works for both NETCONF and RESTCONF. As an alternative to 1, you can put the error identitiyref in the "yang-data" structure, and send both the identitiyref and hints in "error-info". /martin > The returns data even on error. > Instead of the common error-tag, error-info, and other fields, > there is a subscription-result leaf. > > If any client (or even server) functionality uses the NETCONF and > RESTCONF standard error handling, then subscription-result will not be > sent or expected as an error response. Depending on the server > implementation, the code that knows about establish-subscription > may not get called because common error handling code has > already determined there is an to send instead of a data > response. > > Expect that some servers are never going to send data on an operation > failure, and will only send instead. > > > >From sec. 3.8: > > For instance, for the following request: > > xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> > xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications" > xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push"> > > > operational > > xmlns:ex="http://example.com/sample-data/1.0" > select="/ex:foo"/> > > 500 > > > > Figure 3: Establish-Subscription example > > the publisher might return: > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications" > xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push"> > yp:period-unsupported > > > 2000 > > > > Figure 4: Error response example > > > > BTW, all the filter examples seem to be wrong, including the one above > > > OLD: > > xmlns:ex="http://example.com/sample-data/1.0" > select="/ex:foo"/> > > > NEW: > > > > > > > > > Andy From nobody Mon Dec 4 06:13: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 29EB41273E2 for ; Mon, 4 Dec 2017 06:13:01 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ssGQ5RKa_WId for ; Mon, 4 Dec 2017 06:12:59 -0800 (PST) Received: from outbound-ss-1812.hostmonster.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 A83EA127369 for ; Mon, 4 Dec 2017 06:12:59 -0800 (PST) Received: from cmgw2 (cmgw3 [10.0.90.83]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 91213175FA5 for ; Mon, 4 Dec 2017 07:12:58 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id hqCv1w00E2SSUrH01qCy5C; Mon, 04 Dec 2017 07:12:58 -0700 X-Authority-Analysis: v=2.2 cv=dZfw5Tfe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=9zQTPJkFb-_w1wndIycA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG: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:MIME-Version:Date: Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=BG1SL3nIUk/G3KPtj80YsqsXvE65lXpXMKZk53Fhqb4=; b=XGdbc3qZTv7LRyHA3xlPxaTkK8 BVyuPEkrnJKjX37N/tYYXuo5W+v+JUKpCQGAX7OITdLjAypMnZGyjihdIAuXudgNXYACk77+67Erc sm5NSi1DbNKm04E6MAGGxTzcj; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:34174 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eLrUN-003wQK-Bs; Mon, 04 Dec 2017 07:12:55 -0700 To: draft-ietf-netconf-rfc7895bis@ietf.org, NetConf WG From: Lou Berger Message-ID: <74f7ed03-6ee3-aa44-a093-53aad4323b62@labn.net> Date: Mon, 4 Dec 2017 09:12:54 -0500 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 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: 1eLrUN-003wQK-Bs 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]:34174 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [Netconf] some comments on draft-ietf-netconf-rfc7895bis 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, 04 Dec 2017 14:13:01 -0000 Hi,     I have two comments on draft-ietf-netconf-rfc7895bis: 1) In general it seems that NetMod and NetConf WGs have been making good strides at formally separating previously conflated YANG language, module, and protocol related definitions and mechanisms.  From this perspective, I think it important that rfc7895bis not to  even make any normative references to any  protocol.  I think just small changes are needed in the document to make references to 6241 and 8040 informative.  These include:     a) section 1.1,  delete reference to 6241 and combine with list under 7950     b) In case the section isn't deleted: Section 1.3, Paragraph 2, s/MUST/are required/ in both occurrences.     c) Update section 4 to match https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines 2) From reading the document, notably section 2, it is unclear which datastore(s) will contain the library module.  While we may all assume that the answer is obvious, IMO it is important for this to be specified. We may even find that we have different answers to this (apparently obvious) question. Cheers, Lou From nobody Mon Dec 4 06:44: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 A18EC1273B1 for ; Mon, 4 Dec 2017 06:44:14 -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 v4ILGuM3ogN8 for ; Mon, 4 Dec 2017 06:44:12 -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 CF2C112751F for ; Mon, 4 Dec 2017 06:44:11 -0800 (PST) Received: from birdie16 (unknown [IPv6:2001:1488:fffe:6:3c1a:2aff:fe4c:5e30]) by mail.nic.cz (Postfix) with ESMTPSA id E9C3363BA4 for ; Mon, 4 Dec 2017 15:44:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1512398649; bh=cnh2kJvd2i8756xhwtOHoQaQfTz4dlhg/zaEfwGUXSY=; h=From:To:Date; b=grSju1+oetTxv3oDw7GQVVlqpJVjDd117zTfeGAYjYnHlfvD6//7r4cCEvjMXM/74 MAlfy/CfLDsEPccgBW5w1sF4V+Q9LNCIFC3ZFInMRF9KIOK1tWStfabek1lihO5O+O RSY3zvgkvrHXVtwKmWJjqqO1prMPM2xUYCzStCAQ= Message-ID: <1512398649.1422.9.camel@nic.cz> From: Ladislav Lhotka To: netconf@ietf.org Date: Mon, 04 Dec 2017 15:44:09 +0100 In-Reply-To: <74f7ed03-6ee3-aa44-a093-53aad4323b62@labn.net> References: <74f7ed03-6ee3-aa44-a093-53aad4323b62@labn.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] some comments on draft-ietf-netconf-rfc7895bis 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, 04 Dec 2017 14:44:15 -0000 On Mon, 2017-12-04 at 09:12 -0500, Lou Berger wrote: > Hi, > > I have two comments on draft-ietf-netconf-rfc7895bis: > > 1) In general it seems that NetMod and NetConf WGs have been making good > strides at formally separating previously conflated YANG language, > module, and protocol related definitions and mechanisms. From this > perspective, I think it important that rfc7895bis not to even make any > normative references to any protocol. I think just small changes are +1 > needed in the document to make references to 6241 and 8040 informative. > These include: > a) section 1.1, delete reference to 6241 and combine with list > under 7950 > b) In case the section isn't deleted: Section 1.3, Paragraph 2, > s/MUST/are required/ in both occurrences. > c) Update section 4 to match > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines > > 2) From reading the document, notably section 2, it is unclear which > datastore(s) will contain the library module. While we may all assume > that the answer is obvious, IMO it is important for this to be > specified. We may even find that we have different answers to this > (apparently obvious) question. YANG library data (and, for that matter, "schema-mounts" data) is no regular data but metadata decribing the available datastores and their schemas. Therefore, the appropriate place for this information is clearly *outside* the datastores. In RESTCONF, for example, this would simply mean a special resource for this mandatory info. Lada > > Cheers, > Lou > > _______________________________________________ > 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 Dec 4 08:15: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 08CE6127868 for ; Mon, 4 Dec 2017 08:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 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_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 hfxE8iKHv8Ms for ; Mon, 4 Dec 2017 08:14:58 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A233127866 for ; Mon, 4 Dec 2017 08:14:58 -0800 (PST) X-AuditID: c1b4fb30-cc1ff700000029e3-85-5a25747f9f0b Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D2.89.10723.F74752A5; Mon, 4 Dec 2017 17:14:56 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.57) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 4 Dec 2017 17:14:56 +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=lmMrPi82wogM3S/SgpgYEw563Qj6SOHKhAEJFvnVJOg=; b=OU/nQ+zeANd94LHRlYmwK/jw8A6gMZ/K21Si3LtawBPfAl3UAhTwZ9JNTfZKT26hI2h0J0v6nlfBVMNHNqWK/xWjAMawJ+corO0ougfOgUarXFXT9Z64W46KYT6aDOJg/AbHomoKln1RPMpZhO8ALgCW8M/NSjg4QmUgtxpwImY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.197.144] (91.82.100.59) by AM4PR07MB3425.eurprd07.prod.outlook.com (2603:10a6:205:b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.2; Mon, 4 Dec 2017 16:14:54 +0000 To: "netconf@ietf.org" From: Balazs Lengyel Message-ID: <1da803f0-206e-a00b-f62c-48659947c51b@ericsson.com> Date: Mon, 4 Dec 2017 17:14:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: HE1P192CA0008.EURP192.PROD.OUTLOOK.COM (2603:10a6:3:fe::18) To AM4PR07MB3425.eurprd07.prod.outlook.com (2603:10a6:205:b::10) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b0846a3e-6d28-4dce-d28b-08d53b3227a8 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:AM4PR07MB3425; X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3425; 3:fI28S/C0Ctt6dm7vhfEThRKwokBrUco+JnRNw1Zc20WaeOAXX4FVl1NxHnhIti7VCEUNy5uG1BKUNWv5Qe4tm65h8lStEuk6ax1LYKCeccBfKTzPq75956qyQ5MDXz3+XowH7Y0fyxF9Rk9j5jaAgRuePVf0nFr7ANXyUTe+2Dez7oI5paKRkQLNItdyvwCc1jWjh5h9Ob0mzjTI39iqZaesjsTqz/1/v4f0NDbn8lT42hshkPP9nep5dxvpUBIO; 25:cOqXdWxT+CtSrMX4OAA7vExbbjvYWDcC2U8ghzxm6Tgf+NNkjOK+lQ8gPpYNskI3y1QeUH1pDt3OjPk3b1vs6uRGveHTKXE4j+W1tsgjIZiL+MYGOxWx/AWRA6332Djphwtipw9S9WbC4DAofFUhQWDRZgXgsYrJqiqSEbQD5dQxrLLTSGVY2QWd1wBxJ487dCovBdMOxor8eoYShRuZejD0fi2e4kAnbIUAEsqIqYxvmo/vs15dsBMHRxeudgundMsLUeclwYQZIcR49yr2Tz6byDFbOTdBxgm+JG8BH2aD3M93A7eehfOeIYei4svg6Xq9qM9hcdXcaarEM6/28w==; 31:jB18aOiitnOayeeOxayfi4lqTkWF3UpF9IWjJNg+bnt2gn6cxiEAOx06PHpgsPUd7UzxBo0iIf3C5aJGWCe/Dnb0lybj8f/ur2kyRgTMawnKt5xWGMWDJZ62zF9Ke9R39FaGMDyYE4fj9fsKcbuxMgWXehn3ep4E6SCu20TAbbCBC05v4mEOyEPP0XD+/WOIBIlWf2G6xyEmfwBBTNvKOP7OnxUuGMao5L+pGLkcV3E= X-MS-TrafficTypeDiagnostic: AM4PR07MB3425: X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3425; 20:ygJbn73ne9MkfTjjzz7/sQOQ7EiLrZ6M1uOzbv4dH7DLOPCHxfvfSOpxRRDj/sAQxQ5TG4kcKZi5p0+BytvOz9HLGShFGNZ5HoiKuiEV6hdVgCug1hO4z8xd0PtT5U0ucJuuwQWcGCTGgOhLnzb13+ahpOMrGVv0uaVki3ahmJaFD1sz/9Ma6EZvmAsBviUqQRRPwBPFqiydBPpV6kerpnQQIoHYsI2sJBnsnmPfXDnR5ncgK+ibStsqpZ68VE7cZfh4j+lE68OoJp4ASmfQWmnIG8TasMm9anNOAZLwsit5c/VjCRWEekn2RoNJyc41yxW48cWBAzSDJr12IGl99lpV9QjEsp8n+M2On6diXKFAUqb9ULY7ozdnoQi8RFo0/GpWR73BFVbxp95bgIjCYuZvN4olQ/lbSKkDPkuiZU2Cs6MCzJwpADzgUTyoLOsBSjhQSowRR0EACqF9AflIWkKSny2htySghimRu44c8gg06u8bpOpD80AUl5sVP4Ht; 4:EwGcxgYT2XmWDs2+dqXLLfsQ1IKTSdLvvQSEFLbZH+arnxr7D5awJm9Q8NVKPI/+eF4yzA4c4k9S8QW62C55ktTBroI3LJNvSzbClN5sYppFAQWtT8sXAoJPj8b2S17XtJMMeiSDE+wF+0z2U5Pa+L7vRpiCuvtrlXn5JrvaofYbeid2DWlBKzEnpZ6OzemT7mfBcQc2J8XXJxd2yEifDu8ve/hSVTWrJy0UoKmwZAEbwW/r58YERo0Vh01RzhS0zqIgbUsPocNXeGFO0M+8d21VTnXFQ1/qJVNnCPVJUGB6GQR14PZR4MYiLGv/sUDN X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231022)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(6072148)(201708071742011); SRVR:AM4PR07MB3425; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR07MB3425; X-Forefront-PRVS: 051158ECBB X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(346002)(39860400002)(366004)(376002)(199003)(189002)(252514010)(54356011)(16526018)(7736002)(6486002)(2906002)(5640700003)(97736004)(8936002)(236005)(101416001)(230783001)(83506002)(54896002)(58126008)(2486003)(15650500001)(23676004)(52116002)(52146003)(189998001)(31696002)(49976008)(65806001)(478600001)(50466002)(86362001)(31686004)(316002)(16576012)(68736007)(2501003)(8676002)(105586002)(2870700001)(66066001)(65956001)(106356001)(81156014)(33646002)(23846002)(64126003)(25786009)(81166006)(3846002)(65826007)(53936002)(36756003)(6916009)(6116002)(6666003)(2351001)(5660300001)(1730700003)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3425; H:[159.107.197.144]; 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: =?utf-8?B?MTtBTTRQUjA3TUIzNDI1OzIzOjlJZzJwcjI1N2dCdzhJV2J5TGtvTzUwU0Z4?= =?utf-8?B?aXZiOTF4eFNyTkliODJYaHN5Qm1YbHQ5WXhLbmZrTktwTnQvbWNzS05BMkZq?= =?utf-8?B?cGZiMXZxajkzWWZ2SXRBeUZ4TFFDNjBEYTQ1ZEZ2Q0ZhWnhibXFvK1NxWjQ0?= =?utf-8?B?TWtod0xpQ2xmZW4vUC9jQXp5ZThjK1I1T3dITkxsMUxsSTBKY2FiZWNVMmRS?= =?utf-8?B?U3VIeE9TUVQrRTdFYWhpL1dWbGJYeEdVbGVGcXpzM25CR1QvelhRNlFuTVcv?= =?utf-8?B?K21UckZYTzBObzY2ekF3a1Q4dWNOSDF2Y2plblpsZWIyMXQwWVAvays1VGJK?= =?utf-8?B?RFVFbThKTHRSZ0xwSWxRRzR1ajlJWHgzTkc1d2lIR092RmxabmZRMHdGTVFk?= =?utf-8?B?Y3JmVGloZ3FPVTgvTnd0NVJ5MkMwdHB3NDcvVklqaHV6NG5Lbzl2eXJ2UjVG?= =?utf-8?B?bUdhd0RpZ2t0dTlwa0txT1JEL1I2UjVINEZZemw5bVZma3h5RmpERGlra1VH?= =?utf-8?B?bU5kWC9PUFRqN2cxU3BNcmQyOXhoTFlJM3R2c21Wc0hwbldhUVh3YUpjdFls?= =?utf-8?B?aHFlMFFNOEVuQmRYeTRpQSt0YkVLNGp2aFg3Y1I2ZDVZZ0FpcmI5eXJVSlNR?= =?utf-8?B?RDlpRWxQeTNmZWhiRlZFU2JlaFp4eFJmb2t4MEZyek45U24rSlFSSzFxQ3ZS?= =?utf-8?B?QXBuTDR4cnowOVVKSDdqYnlSU0FSMGJMWmpKTTh2bmxGVHlmaDdqVzRVK1hW?= =?utf-8?B?L1dUQXN1emtzdzBjamRzemFVUTZKWHBuNm5Kc3VCc2NnZjBUV1h2SHVqbGVr?= =?utf-8?B?c1RFc3lRWkNpbHJlYzc0YmlmL3pPL1hXcVN3TVdNTURFandwb0FJUTNQbEhF?= =?utf-8?B?bWNULzFTenpsTldGQnNDSzNYWTNnUmQ3aFdKbkw1b3RKT1VpcTlweDJDbXo3?= =?utf-8?B?K0VOWWtxaWVzTkRuTGVZMWJvdkpWWm1VWnQzNFc0d3gySG53UEZwMHdldDZQ?= =?utf-8?B?MUdWT1A4K3pzOEhLSE5oYlRJK0FBcXo1TE9JbTQ0cHJiTjFvWEY3QVM5QTZp?= =?utf-8?B?cnliVWZIUzJxdVVpdS81Z1ZocVpENFRvU1N1Z2JWMHR0d1FRdzV1dHFUTEY3?= =?utf-8?B?dkFybkVTNVA1TyszOUNEbGlQTTArYnVUclVqaEJ5dmN0Y05TMkVxVnBjczhH?= =?utf-8?B?aWxyZHIyTWQrUjRQYTEzR0ttRmVldjJzZFRuZ0tyMUM4b2R5ZS9lRFdVT2VQ?= =?utf-8?B?b2Vpb25WUG44eXdiZk14eGxBcTdXdy8rOFpDYlV2bDlTM2FXYTVQVk1kRGxu?= =?utf-8?B?c09yZFg3RDFpVWJabnh5WFgvU1diRExXOTdPQWNyajRBZmZwazdXMTJMWi9M?= =?utf-8?B?cUdJTVZ3ZnRXU2dQYjBzQjNLSTk0UXhkbmxPMEpVOVZZTW9adTFJSXZwUmRz?= =?utf-8?B?b01FMlJFMVhaWUc3ZUFXS0YyaUFpcjlCYWFyendpRExoYlV0OU1sM2dCNmFM?= =?utf-8?B?VVQxUVNkQjZydGE2bmc3M2JlMFFtTXp1VVJzaFFYYnNHTDlaa0p5alM3TURB?= =?utf-8?B?WnZhdHNLbzBUeEpjVWRZek9OcFhjVEsrRTlHTnZHRnNjRlFZYkp4OEJmeEFy?= =?utf-8?B?bkxTNUtEOWRMV2dzRll6Z1VZSEUybzg1WXJGbzYxNlN4bWFWSzNNMmxlaXZk?= =?utf-8?B?QUQ1TUQyMDhlcTlvMzFmV1ZHUzE3dzVKUDcrWG53WHhaNktxVkIxak5XYS8y?= =?utf-8?B?NEs1cHNRZGp5eFJ2S0NUYVZCejBsWk94aEtlNDJvNDBrcEJZUUlJTk92NThl?= =?utf-8?B?c2l5Y20zcmZ2Rk5CZXRsMVB6eVBPeUlVRG16dmY3T250VksycUMralBLaUdj?= =?utf-8?B?dS9sQWIzRjRlV0ZkYkNuVEg1N3lqbHkwN0RBR3p1eTdFS1M0a2VTb01EQWIz?= =?utf-8?B?UGtlUEZCNm93PT0=?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3425; 6:7gJ8W4aGoRLRlPeUaHWrSUjOK+gJjrSkOgaf5xvGVUhobXBAdtRIeTkX6mburXs0QlP7Rpj8JVHY2ZApBErVU87rsSb9MxmY2+wPSqp+HRbRvB7ZuQt4EWCiBFSeUGCL6695MKJ5/LNukwX4yne+Vz+gv7vHg+tx+Xz9eEuVH0nCHh6k2sDbBH7/uWCYPcNz4/5EXrxMnhvyJJwPYvEvEBdZLC+NkUUFjtZ5uK/queelscN5TgobY9fTMQcBBV2mUiKAXR8jilmuk2qBT/uo3I3aQFGzUb72q/uEUVL9baZ5X1EZX2j7NxoqAhQIc1ULAGKhB5TLZJp3khTwCD/O2skzERcmASHLEQgZJJ9GAhk=; 5:6mhQ/9JxP4sFUSzwnGFwk1drG0uNJb16i8IbdOOozdgC3KvwjRv6JXzRFE+AOHj39dSFOBVRZ7x+ZHXXXhSrGmQCUFkKqWJnnhdcyv4Eo6SpFeVI4cg+dITteN1AXpLdk7MUsKnzM2WX1XaS6IOIduiBZyl7U7mi/7jyQli5zos=; 24:cW1vbXr6Hod7m1bXA9JlOrtWheS3Vd2DLrwQ8PiPmiV/2sK2sLRH6i5B+NwiSEhMKBlfWukmTKfqh3FQqksreu6PKfiQkzIwGk7Rr6MeMSQ=; 7:qPgpkchxSnRFR/LYO77EF6bUdT8CoPWtywwgn+0hmQPFUYSrYg/mHGwZ76gkrO3OcN/UlEJh6UjK1CaGUhKNvcuZlgi+S49/Pn9N+lSy31QBAKYi1A+rW3gYDhCLg58bwCtf/csFUhWAAvLiSlXwjxRwIfnaof/U9Gv97gZZz5SlzY5kxjVXUxaJ/yjq9Ji+eZXk+0BXs59EJeTAa3xdEhZcojviyTKIIQbet/YqlOaA36r4D7Fbj6kD1o24dFzJ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2017 16:14:54.0072 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b0846a3e-6d28-4dce-d28b-08d53b3227a8 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3425 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUyM2K7pW5DiWqUwf+XPBZTN91mdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqczB1kKfqpVTDx8hrWB8Yh8FyMnh4SAicS6I4eYQWwhgcOM Etu2O3cxcgHZxxklVs66xQ7isAj0Mkt8n/STFaSKUSBOYueahawQVW1MEk+m9rCAJEQENCUa Z30AK2ITMJKY2n8eLC4s4CzRPvkCmM0rYC/x4+FDRhCbRUBFYsvW30wgtqhAjMThnumsEDWC EidnPgGrZxbQkGidM5cdwhaXuPVkPhOELS/RvHU2M8QLChLXN19nATlIQmAio8Te+Q2sEP9o SDy88JcVokhW4ujZOSwQtq/Etu/TGSEaljBKdPc0s0E4DewS0z/PYYeo0pKYcWQZVOIHm0Tr h0VQo7Il/r85CjXKSuL1r+9QoxYwS5xY1AtVJCMx99wKqKO62CR2/3jEAnFUqsSWGy1sEEXz hCWeXK+fwKg5C8njs5A8PgvJ47OQPL6AkWUVo2hxanFSbrqRkV5qUWZycXF+nl5easkmRmCq OLjlt8EOxpfPHQ8xCnAwKvHwRuSpRgmxJpYVV+YeYpTgYFYS4e1IBwrxpiRWVqUW5ccXleak Fh9ilOZgURLnPenJGyUkkJ5YkpqdmlqQWgSTZeLglGpg9Hq4PzGokW1R8ibJ7AXPdDkOF773 lAuYtszPaWKflVTaZwVu48BAo09e2zwu1u2OudtWzx4pYf+N/xBnmHnNr4Nviu1tztUKrZRY tuLeuU/WM1YEtr3zOKclGqS9oeS27i2rS//UzHMTNi0UFXFgnrfcOjtQ8/blexl/5WMzu6JF LFue3n2vxFKckWioxVxUnAgA24Rc6hEDAAA= Archived-At: Subject: [Netconf] Comments on draft-ietf-netconf-subscribed-notifications-07 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, 04 Dec 2017 16:15:02 -0000

Hello,

Sorry if some of the comments are already resolved. I did not have time to scan through all the mails.

1.3)

Should we formally state some transport requirements? This chapter seems to assume:
- transport is either connection-oriented and reliable
- or connectionless/stateless, but has acknowledgement for the notifications
so the publisher can determine whether the receiver actually got the notification or not.

"The lifetime of a configured  subscription is driven by relevant
configuration being present on the running configuration."
Is it really the "running" config? IMHO it should be the operational. 

"Dynamic subscriptions can only be modified via an RPC request 
made upon the original subscribing transport session."
How does this work in case of Restconf? The transport session can be very brief. 
Shouldn't we discuss restconf and "same transport session" generally somewhere?

2.2)
"A subset of information is never stripped from within the event record." 
I don't fully understand this. Maybe reword it to
"A filter always removes a complete event record; a subset of 
information is never stripped from an event record. "

If a filter removes 2 out of 3 event records will the notification still be sent? Is that a realistic situation?

2.3)
Figure 1) IMHO a state transition from suspended to suspended on modify-subscription is missing.

The state diagram for configured subscriptions is not really clear. 
- does the subscription have a state/state-machine or the individual receivers? 
The model suggest its the receivers.
- the described states do not correspond to the states defined in 
/sn:subscriptions/sn:subscription/sn:receivers/sn:receiver/sn:status
- buffer overflow is mentioned. Is it an overflow at the receiver or the publisher?

4.1.1) s/a event/an event/

4.4) s/associated the transport/associated with the transport/

5) 3rd sentence reword!

5.1) 
here it is written that:
"Note that is possible to configure replay on a configured subscription."
In  4.1.1 it is written that
"Replay is only viable for dynamic subscriptions."
One of the two statements must be changed!

5.3) merge with chapter 6

8.4, 8.5) 
Suspensions are notified to the subscriber (...) and all receivers ...
Already described in chapter 8. Remove

10)
anydata subtree-filter) event-filter: Is this applied against the full 
notification or against an event-record? It is not clear! A notification may contain multiple event records. 
In the two cases the top level element should be different. 
If against the event records, is it the full notification or only the 
individual event record that is not sent? If all event records are not sent the notifications shall not be sent.
IMHO this would deserve a few sentences somewhere. The same question is valid for XPath. Which is the correct format?
- /notification/myNotification/eventRecord[type='typeA']    or
- /eventRecord[type='typeA']

stop-time) "If replay-start-time doesn't exist, stop-time must be for a future time." 
This may be required at subscription establishment, but later when the 
subscription state becomes concluded, this will become false.

dependency  both substrees) shouldn't this be a leafref with require-instance=false?
/subscription-config/subscription/sn:stream and
/subscriptions/subscription/sn:stream and 
/establish-subscription/input/sn:stream) shouldn't these be a leafrefs 

11)
s/or nor subscribed/or subscribed/ 

11.2)
"A publisher MUST NOT include any content in a notification message
   for which the user has not been authorized."
Clarify if the user is the subscriber or the receiver.

"Subscribers that do not want notification messages need only terminate or refuse
any transport sessions from the publisher."
IMHO the first word should be receivers. 
Also in the case of a configured subscription can we get into a cycle? 
- publisher tries to send a notification
- receiver receives a notification it does not want
- receiver closes transport session
- start from the top

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Mon Dec 4 09:14: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 2BEB5124B0A for ; Mon, 4 Dec 2017 09:14: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 yD3StzY_RWgR for ; Mon, 4 Dec 2017 09:14:54 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83FE1242EA for ; Mon, 4 Dec 2017 09:14:53 -0800 (PST) Received: by mail-lf0-x22d.google.com with SMTP id 94so20005248lfy.10 for ; Mon, 04 Dec 2017 09:14:53 -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=zcGOHOJQuExHB8eg9DkkuLSdzR/C2OftsMh5D59RYwc=; b=BBQc2og7uw4tx/FduxF6U+iSjsguS/Z5dhiEuQPU9ZYV2apcYl4I0mHmNtbJOg7YBT ft7EclueSlKYaxzG4VXOOnlsYUXujJwGX1GlM93pcF5zkb17ICOya/ki1t8Np5Lp2eUq ZcyTGUEUzhPtKj3NQzYEzWNngCVJXcit9y9XDQcQyDLZXNAO8f1LYtDM0rJtWTL2zVa1 Hr+n9NKn/cYDk3ScxGKh/P0YM3nTToFgqxPx4IlEs6QriKsRhusi2NjJs22wtH2ndx54 BapwK4+T9aUd7MsIDHTAGc2n+nHFDSu1CXcQmA/WTLBX/jeVqv4B8l4OV7bIWRrIY10X GOyg== 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=zcGOHOJQuExHB8eg9DkkuLSdzR/C2OftsMh5D59RYwc=; b=LCH6xAnYTR1twRYcD+mdbdYpg7Z7jgI3IJ3NzuP2U8SHFeL9MiDHI1kTvX+r77dQL6 Xn1DIr3i4Mr+XYZOihrC6yNLnsWsO67O3lVWslwwtWr+rOEHPKmFnrzzAItV0JdAf++W 9C1RBpJ5Ftj475+/rhLKuBjkfBAcVb0ecJapSbvXq9WrXankF7fW0soz3ukIfdVpn+ZT BgrM83ItOc9j0bwALkrWGuMVTedld2FZy5jA8EKmmyF6FEFWLw9Dsk7hM+J3Y2vAnKPz 4JdjwsXhORybSuuUScYZ4U9BphZPxAq1Ps30f4OKNi100kA9fBhkD7oQWBX/D8KeG9Er LWtw== X-Gm-Message-State: AJaThX4H63ALdIZB6htZ2K6Bmy75M1rIZl/vhF/FmfTaQWZrhn+id5Hh kSbLoKyC5KtE/so2WAdQMAgA+U54FG+nrSdYzG0SrA== X-Google-Smtp-Source: AGs4zMa+yNTuSXHaSrKbsLUWi2NzWriRS6zmWPXUqnXtzQ+OiA/xwCDlLwWaXblENvm5NDrpNNYgKSgGPGow7hGBBQs= X-Received: by 10.25.147.23 with SMTP id v23mr7590433lfd.120.1512407691934; Mon, 04 Dec 2017 09:14:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Mon, 4 Dec 2017 09:14:51 -0800 (PST) In-Reply-To: <20171204.135539.1530792967351325058.mbj@tail-f.com> References: <20171204.135539.1530792967351325058.mbj@tail-f.com> From: Andy Bierman Date: Mon, 4 Dec 2017 09:14:51 -0800 Message-ID: To: Martin Bjorklund Cc: Netconf Content-Type: multipart/alternative; boundary="f403045ce2d63bd7fa055f86dbe9" Archived-At: Subject: Re: [Netconf] yang-push issue: error handling 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, 04 Dec 2017 17:14:56 -0000 --f403045ce2d63bd7fa055f86dbe9 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 4, 2017 at 4:55 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > IMO the special error handling in YANG Push is not acceptable > > because it violates NETCONF and RESTCONF error handling procedures. > > NETCONF says if the operation does not work for any reason an > > element SHOULD be returned. > > I fully agree, and I have pointed this out several times in my > reviews. The problem is actually in subscribed notifications, and I > think Eric is tracking that issue. > > Trying to be constructive, I think that the existing mechanisms in > YANG can be used to achieve the same functionality that these drafts > try to achieve. Specifically: > > 1. Use identities just like the ones you have > ("unsupportable-volume", "filter-unavailable" etc), but add text > that explains that these identities are sent as "error-app-tag" > in "rpc-error", encoded to a string as :. This > works for both NETCONF and RESTCONF. > > 2. For the "hints" extra info that you return, define a "yang-data" > structure with the hints, and explain in text that this structure > is returned in "error-info". This works for both NETCONF and > RESTCONF. > > +1 If the error handling was done correctly then the same procedures could be applied to failures for configured subscriptions. > > As an alternative to 1, you can put the error identitiyref in the > "yang-data" structure, and send both the identitiyref and hints in > "error-info". > > > /martin > > Andy > > > > > The returns data even on error. > > Instead of the common error-tag, error-info, and other fields, > > there is a subscription-result leaf. > > > > If any client (or even server) functionality uses the NETCONF and > > RESTCONF standard error handling, then subscription-result will not be > > sent or expected as an error response. Depending on the server > > implementation, the code that knows about establish-subscription > > may not get called because common error handling code has > > already determined there is an to send instead of a data > > response. > > > > Expect that some servers are never going to send data on an operation > > failure, and will only send instead. > > > > > > >From sec. 3.8: > > > > For instance, for the following request: > > > > > xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications" > > xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push"> > > > > > > operational > > > > > xmlns:ex="http://example.com/sample-data/1.0" > > select="/ex:foo"/> > > > > 500 > > > > > > > > Figure 3: Establish-Subscription example > > > > the publisher might return: > > > > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > xmlns="urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications" > > xmlns:yp="urn:ietf:params:xml:ns:yang:ietf-yang-push"> > > yp:period-unsupported > > > > > > 2000 > > > > > > > > Figure 4: Error response example > > > > > > > > BTW, all the filter examples seem to be wrong, including the one above > > > > > > OLD: > > > > > xmlns:ex="http://example.com/sample-data/1.0" > > select="/ex:foo"/> > > > > > > NEW: > > > > > > > > > > > > > > > > > > Andy > --f403045ce2d63bd7fa055f86dbe9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Dec 4, 2017 at 4:55 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> IMO the special error handling in YANG Push is not acceptable
> because it violates NETCONF and RESTCONF error handling procedures. > NETCONF says if the operation does not work for any reason an <rpc-= error>
> element SHOULD be returned.

I fully agree, and I have pointed this out several times in my
reviews.=C2=A0 The problem is actually in subscribed notifications, and I think Eric is tracking that issue.

Trying to be constructive, I think that the existing mechanisms in
YANG can be used to achieve the same functionality that these drafts
try to achieve.=C2=A0 Specifically:

=C2=A0 1. Use identities just like the ones you have
=C2=A0 =C2=A0 =C2=A0("unsupportable-volume", "filter-unavail= able" etc), but add text
=C2=A0 =C2=A0 =C2=A0that explains that these identities are sent as "e= rror-app-tag"
=C2=A0 =C2=A0 =C2=A0in "rpc-error", encoded to a string as <mo= dule>:<identity>.=C2=A0 This
=C2=A0 =C2=A0 =C2=A0works for both NETCONF and RESTCONF.

=C2=A0 2. For the "hints" extra info that you return, define a &q= uot;yang-data"
=C2=A0 =C2=A0 =C2=A0structure with the hints, and explain in text that this= structure
=C2=A0 =C2=A0 =C2=A0is returned in "error-info".=C2=A0 This works= for both NETCONF and
=C2=A0 =C2=A0 =C2=A0RESTCONF.



+1

=
If the error handling was done correctly then the same procedures coul= d be
applied to <edit-config> failures for configured subsc= riptions.

=C2=A0

As an alternative to 1, you can put the error identitiyref in the
"yang-data" structure, and send both the identitiyref and hints i= n
"error-info".


/martin



Andy
=C2=A0



> The <establish-subscription> returns data even on error.
> Instead of the common error-tag, error-info, and other fields,
> there is a subscription-result leaf.
>
> If any client (or even server) functionality uses the NETCONF and
> RESTCONF standard error handling, then subscription-result will not be=
> sent or expected as an error response. Depending on the server
> implementation, the code that knows about establish-subscription
> may not get called because common error handling code has
> already determined there is an <rpc-error> to send instead of a = data
> response.
>
> Expect that some servers are never going to send data on an operation<= br> > failure, and will only send <rpc-error> instead.
>
>
> >From sec. 3.8:
>
>=C2=A0 =C2=A0 For instance, for the following request:
>
> <netconf:rpc message-id=3D"101"
>=C2=A0 =C2=A0 xmlns:netconf=3D"urn:ietf:params:xml:ns:netconf= :base:1.0">
>=C2=A0 =C2=A0 <establish-subscription
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:y= ang:ietf-subscribed-notifications"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:yp=3D"urn:ietf:params:xml:n= s:yang:ietf-yang-push">
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:datastore>
>=C2=A0 =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 =C2=A0operational
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</yp:source>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:subtree-filter netconf:type=3D= "xpath"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns:ex=3D"http://example.com/sample-data/1.0"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0select=3D"/ex:foo&= quot;/>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0</yp:datastore>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:period>500</yp:period>
>=C2=A0 =C2=A0 </establish-subscription>
> </netconf:rpc>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 3= : Establish-Subscription example
>
>=C2=A0 =C2=A0 the publisher might return:
>
>
> <rpc-reply message-id=3D"101"
>=C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:= base:1.0">
>=C2=A0 =C2=A0 <subscription-result
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:y= ang:ietf-subscribed-notifications"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:yp=3D"urn:ietf:params:xml:n= s:yang:ietf-yang-push">
>=C2=A0 =C2=A0 =C2=A0 yp:period-unsupported
>=C2=A0 =C2=A0 </subscription-result>
>=C2=A0 =C2=A0 <period-hint xmlns:"urn:ietf:params:xml:ns:y= ang:ietf-yang-push">
>=C2=A0 =C2=A0 =C2=A0 =C2=A02000
>=C2=A0 =C2=A0 </period-hint>
> </rpc-reply>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Figure 4: Error response example
>
>
>
> BTW, all the filter examples seem to be wrong, including the one above=
>
>
> OLD:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:subtree-filter netconf:type=3D= "xpath"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns:ex=3D"http://example.com/sample-data/1.0"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0select=3D"/ex:foo&= quot;/>
>
>
> NEW:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:subtree-filter>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <ex:foo xmlns:ex=3D"<= a href=3D"http://example.com/sample-data/1.0" rel=3D"noreferrer" target=3D"= _blank">http://example.com/sample-data/1.0" />
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</yp:subtree-filter>
>
>
> Andy

--f403045ce2d63bd7fa055f86dbe9-- From nobody Mon Dec 4 19:02: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 5E2E4120046 for ; Mon, 4 Dec 2017 19:02:41 -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 Lyv10l8r0p8F for ; Mon, 4 Dec 2017 19:02:36 -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 8AFB21201F2 for ; Mon, 4 Dec 2017 19:02:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34917; q=dns/txt; s=iport; t=1512442956; x=1513652556; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UbbWJM2fFYs5YiJbbIVgv8QovKD+2zRfiPRUy6SixB8=; b=d+OduUZ897or+K1z4emZdnbaC53gGlUVdtc8wFv3etHdhK5MHu7Peeqn YPS9SRLORPVBnJYQw/wR+HMQSHcFFHXAAN1ml0xbNo1c2Um9Wih3NfIFr r4PCvzjUvYCC+iNuVSyPHD2G/99VzGKlN/LPeQbHs22NocNdAKbfXNnYG s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQBQA1CyZa/5ldJa1SAQIHGQEBAQEBA?= =?us-ascii?q?QEBAQEBAQcBAQEBAYMOLoEfNS6dEoF9fpYXggEKhTsChTRDFAEBAQEBAQEBAWs?= =?us-ascii?q?ohSIBAQEBAgEaAR8/BQsCAQgOFxEQMiUCBA4DChOJfwiqQYphAQEBAQEBBAEBA?= =?us-ascii?q?QEBAQEBAR+DR4IKgVaBaYIdWDaEagwBEgEBA4YLBYo9h0mBcoVCiTICixJLiSm?= =?us-ascii?q?CH4YRhAiHJ4o8i2QCERkBgTkBNiKBTW8VFiSCKoJRHIFnRYdYKoEJgRQBAQE?= X-IronPort-AV: E=Sophos;i="5.45,362,1508803200"; d="scan'208";a="39764448" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2017 03:02:35 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vB532YOg026963 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Dec 2017 03:02:34 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; Mon, 4 Dec 2017 22:02: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; Mon, 4 Dec 2017 22:02:33 -0500 From: "Eric Voit (evoit)" To: Martin Bjorklund CC: "netconf@ietf.org" , "balazs.lengyel@ericsson.com" , "andy@yumaworks.com" , Alexander Clemm Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11 Thread-Index: AQHTaCy/QRPr9GM9Jka7UxKyCaa4a6MpyuqggAmhy4D///elMA== Date: Tue, 5 Dec 2017 03:02:33 +0000 Message-ID: <16ea77c9d7944aeea09a0b1971ab02a0@XCH-RTP-013.cisco.com> References: <20171128.103735.1654378548309425095.mbj@tail-f.com> <4c2303ac1eff4b0db2dae056d56c9285@XCH-RTP-013.cisco.com> <20171204.124001.1188267155929301700.mbj@tail-f.com> In-Reply-To: <20171204.124001.1188267155929301700.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.86.240.2] 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: Tue, 05 Dec 2017 03:02:41 -0000 Hi Martin, Reducing to the open items... > > + Dampening period: In an on-change subscription, detected obj= ect > > changes should be sent as quickly as possible. However withou= t > > adequate protections, a rapid series of object changes might e= xhaust > > of resources in the publisher or receiver. In order to protec= t > > against that, a dampening period MAY be used to specify the in= terval > > which must pass before successive update records for the same > > subscription are generated for a receiver. The dampening peri= od > > 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 recor= d > > containing that object is created either immediately when no > > dampening period is in effect, or at the end of a dampening pe= riod. > > A dampening period is reset every time a new notification mess= age > is > > passed to transport. >=20 > I understand what you want to achieve, but I don't think the text is quit= e > correct. I'll think about this some more to see if I can come up with a = better > wording. After the latest interactions on the mailer, text reads: Dampening period: In an on-change subscription, detected object changes sho= uld be sent as quickly as possible. However it may be undesirable to send = a rapid series of object changes. Such behavior has the potential to exhau= st 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 pas= s before successive update records for the same subscription are generated = for a receiver. The dampening period collectively applies to the set of al= l datastore nodes selected by a single subscription and sent to a single re= ceiver. This means that when there is a change to one or more subscribed o= bjects, an update record containing those objects is created either immedia= tely when no dampening period is in effect, or at the end of a dampening pe= riod. If multiple changes to a single object occur during a dampening peri= od, only the value that is in effect is included as part of the update reco= rd. A dampening period is reset every time an update record has completed = its assembly. > > 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. >=20 > Or maybe >=20 > In a periodic subscription, the data included as part of an update > corresponds to data that could have been read using a retrieval > operation over that subscription's transport. >=20 > (no need for MUST here) Text updated as you proposed. > > > (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". >=20 > Hmm, that paragraph is: >=20 > It is not expected that implementations will support comprehensive > filter syntax and boundless complexity. It will be up to > implementations to describe what is viable, but the goal is to > provide equivalent capabilities to what is available with a GET. >=20 > What is a "comprehensive filter syntax"? Maybe this paragraph can be > removed. Paragraph removed. =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 main= tain > > > an extract of the publisher's datastore. > > > > > > It seems this paragraph defines the term "Subscription policy". Bu= t > > > 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: >=20 > My problem with this style is that it seems to indicate that the selectio= n > filter is only used for this use case ("replication of a subset..."), but= that > would be a mistake. I think you should explain what these filters are fi= rst, > and then (maybe) give examples of how they can be used. >=20 > The title "Datastore selection filter" is also misleading;=20 I have made the title "Datastore selection", as the section doesn't hit all= the items of subscription policy (such as periods). > in fact the best > solution might be to keep the original text but change the title of the > section to "Subscription Policy". I have returned the text to something closer to the original text. It now = is: "A subscription must specify both the selection filters and the datastore a= gainst which these selection filters will be applied. This information is = needed to choose and subsequently push the information necessary to remotel= y maintain an extract of the publisher's datastore." If you have other examples of how the info might be used, what would you wa= nt to add? (One thing is possible is to simply monitor a datastore for a s= pecific event, like the creation of a node, but not its deletion. More on= this within the excluded change discussion further below.) > > > 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." >=20 > The text for subtree filters use the words "When specified, updates will = only > come from the data nodes of selected YANG subtree(s)." If you use the > same words here, the text is consistent and easier to understand. Maybe: >=20 > NEW: >=20 > o xpath: An xpath selection filter is an XPath expression that > returns a node set. When specified, updates will only come from > the selected data nodes. updated =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 filte= r > > > 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. >=20 > But you are constraining the entire solution to support just this use cas= e, > when a simpler unconstrained solution just as easily supports this use ca= se, > *plus other use cases* - if a client does not want these "fake deletes", = they > can simply construct filters based on keys only, which they would in the > current solution anyway. This is true. > Note also that b/c of the last paragraph in section 3.9, a client must de= al > with such deletes anyway, even if it specificied only keys. This is true. > But I do understand your point. This is also related to my comment below > about when a filter is evaluated. Based on you reply to that comment, I > think the conceptual algorithm is like this: >=20 > Just before a change, evaluate the filter and any access control > rules. The result is a set "A" of nodes (including subnodes). >=20 > Just after a change, evaluate the filter and any (possibly new) > access control rules. The result is a set "B" of nodes (including > subnodes). >=20 > Construct a YANG patch record for going from A to B. If the record > is non-empty, send it to the subscriber. >=20 > (this is conceptual, an implementation can do lots of optimizations to av= oid > evaluating filters on un-related changes) Yes, this is it. The only tweak I would make is to add the dampening peri= od. As a result, I have added the following text at the end of the "On-Cha= nge Considerations" section "Putting it all together, following is the conceptual process for creating = an push-change-update notification: =09 1.Just before a change, or at the start of a dampening period, evaluate a= ny filtering and any access control rules. The result is a set "A" of data= store nodes and subtrees. 2.Just after a change, or at the end of a dampening period, evaluate any = filtering and any (possibly new) access control rules. The result is a set= "B" of datastore nodes and subtrees. 3. Construct a YANG patch record for going from A to B. If the record i= s non-empty, send it to the receiver." =20 > > 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 >=20 > What about this one: >=20 > /interfaces/interface[contains(name, //name)] >=20 > it also filters on a key is it ok? >=20 > [if the answer is "yes" we have a problem; and if it is "no", we need to > tighten the text] >=20 >=20 > All this makes me wonder if it is correct to have "subtree" and "xpath" > filters at all. If they only can match on keys, they become severely > constrained. >=20 > An alternative could be to specify filters as "nacm:node-instance-identif= ier" > instead; these are instance-identitifiers that allow missing keys. For > example: >=20 > /if:interfaces/if:interface/if:oper-status >=20 > This would be easier to understand and probably easier to optimize for in > the server code. I want to generalize this "only-keys?" issue for the full WG. It is too i= mportant to handle this deep in the thread. Look for me to open an issue s= hortly. =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. > > > > 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. >=20 > Maybe "patch-id" could be a sequential number, starting from 1 when the > first patch is sent? Or simply any string that the server finds appropri= ate. > In any case, "null" looks odd in the example. Agree "null" looks odd. =20 Does *anyone* have an issue if I make an implementation recommendation that= the definition the incremental number of the push-change-update for a part= icular subscription? That would at least make the required field useful? > > > 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 cou= rse > > > of the subscription. > > > > > > But how can a server know this when "establish-subscription" is sen= t? > > > > 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. >=20 > Ok, but the error code is used as a return value for "establish-subscript= ion". > So if a server can't detect it at "establish-subscription" it mean it wil= l never > be used. Hence I suggest you remove the text about "authorization > privileges". A publisher could choose to allow a subscription to an empty location where= there might plausibly be objects someday. (E.g., maybe where an interfac= e might appear; even if there is no such interface currently existing.) Likewise a publisher could choose to reject a subscription because it is ob= vious that a subscriber will never have access to the requested data. (E.= g., maybe always disallow subscription to YANG model which controls the con= figuration of private keys.) Pretending they might have access someday and allowing the subscription wil= l just waste resources. So I think the error is useful for such situations= . > BTW, does this imply that I cannot create a filter for a currently > non-existing interface? If this is true, my conceptual filter > evaluation algorithm above is not correct... It is ok to create a filter for a non-existent interface. This is supporte= d in Cisco's XE implementation. > > > 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.) >=20 > Aha, ok. But then it looks really weird to have "scubscription-id" > in the notifications defined in this module. It will be redundant. It isn't redundant *until* we have notification-messages available. And th= is will take some time. After that, it need not be populated where the new= subscribed-notifications header is available. So the logic to avoid per-u= pdate header redundancy is straight-forward. =20 > Or do you suggest that *all* YANG modules that publish notifications must > have a leaf "subscription-id", until the notification header document is > done? If not, why is this document special? No, I am not suggesting all notifications need to define this leaf. It is= often the case that a single application can prove the need for common inf= rastructure. In this case yang-push has pointed the way for a generalizati= on of subscription-id across all notifications. =20 =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? > > > > 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. >=20 > Ok. So this means that when we have these new headers, "time-of-update" > is no longer needed, right? Yes. =20 > But actually, currently we have "eventTime". And since "notification-tim= e" > is equivalent to "eventTime", and "time-of-update" > is "notification-time", it follows that "time-of-update" is redundant and= not > needed today either. Correct? I would be ok with that. And yes several of us have talked about it. One = person on this thread has argued the other way on this before based on thei= r implementation logic. But if they don't chime in now, I am fine with get= ting rid of "time-of-update" (which already is optional for this very reaso= n). > > 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 place= d > > into a "push-update" or "push-change-update" >=20 > I suggest you remove the sentence instead, and some more redundant > words to get: >=20 > OLD: >=20 > An "updates-not-sent" object, which indicates that the update record > is incomplete. If the application detects an informational > discontinuity in either notification, the notification message MUST > include "updates-not-sent". This object indicates that not all > changes which have occurred since the last update are actually > included with this update. >=20 > NEW: >=20 > An "updates-not-sent" object. This object indicates that not all > changes which have occurred since the last update are actually > included with this update. Ok, updated. > > > 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. >=20 > No. See RFC7950, section 8.3.1, bullet 4. And compare with all other > modules that use if-feature; no other module has invented such error > codes. Let's handle this on the separate errors thread. The question of legitima= te negotiation interactions which are not actually errors is a conversation= needing more WG internalization. And without this, we need to figure out = how to send errors as part things like subscription-suspended notifications= . =20 > > 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. >=20 > Ok; i.e., the text should explain that it is used if the client asks for = an obejct > that does not support on-change. The if-feature case is already handled = as > described above. Have changed the definition to:=20 "On-change is not supportable for any objects which may be provided through= the selection filter."; =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? > > > > 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 >=20 > But in this case the error will be "on-change-unsupported", right? I mean to say "except for" rather that e.g. My bad. > > ). Will enhance the > > definition. Current text is now: "Neither synch on start nor resynchonization are supported for this subscri= ption. This error will be used for two reasons. First if an 'establish-sub= scription' RPC doesn't include 'no-synch-on-start', yet the publisher can'= t support sending a 'push update' for this subscription for reasons other = that 'on-change-unsupported' or 'result-too-big'. And second, if the 'resy= nch-subscription' RPC is invoked either for an existing periodic subscripti= on, or for an on-change subscription which can't support resynchronization.= "; > > (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 >=20 > Huh? What does *that* mean? As an extreme example: if someone tries to provide a character for a key th= at only accepts integer. =20 Definition is now: "Mismatch between selection filter key provided and the datatype of t= he referenced YANG datatree node."; You might say this *should* be placed under normal error conditions, per th= e larger error condition thread. And perhaps this is the case. But there = still is the case where a subscription is abnormally terminated or suspende= d because someone modifies a configured subscription to a non-viable filter= which causes this error to pop up. Such an option needs to be reported = to a subscriber, and existing error mechanisms don't do this AFAIK.=20 > > > identity datatree-size { > > > > > > 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 >=20 > It will use ds:datastore as base. If we need some other generic base fro= m > which custom datastores are derived, that identity should be defined in a > generic place (ietf-datastores probably), and not here. Will you put it in that document then? That makes it very easy to delete = from here. =20 > > , 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. >=20 > Yes. (At least from this document.) >=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."; >=20 > You didn't reply to this. My point is I took the definitions straight from rfc8072, with the tweak about how to h= andle the dampening period as discussed previously. > > > > > > 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. >=20 > I think there's some confusion here. How would the "excluded-change" > leaf-list be used in this case? (the typedef we're discussing is only us= ed in > "excluded-change") The typedef matches up to the types of elements which may be returned in a = YANG patch operation. If an entry appears in this list, it is excluded fr= om the allowed list of patch operations which may be sent for that subscrip= tion. While this is not interesting for receivers which are trying to maintain an= extract of a datastore, it may be interesting for applications which are s= imply looking for specific types of datastore events. I will add some text= in the type definition. =20 > If an application needs to know *every* change, it probably shouldn't use= a > dampening period. Exactly =20 > > (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" >=20 > Well, yes this certainly needs to be described. I will have to think abo= ut the > implications of this change. What I ended up doing is adding not a new section, but instead a new paragr= aph within "on Change considerations" section. The paragraph now reads: However a patch must be able to do more than just describe the delta from t= he previous state to the current state. As per , it must also be able to identify if transient changes have occurred on a= n object during a dampening period. To support this, it is valid to encode= a YANG patch operation so that its application would result in a no change= between the previous and current state. This indicates that some churn ha= s occurred on the object. An example of this would be a patch that does a = "create" operation for a datastore node where the receiver believes one alr= eady exists, or a "merge" operation which replaces a previous value with th= e same value. =20 > > > o 5 - selection filter > > > > > > The XPath expression is not properly defined. > > > > > > OLD: > > > > > > "This parameter contains an XPath expression identifying th= e > > > portions of the target datastore to retrieve."; > > > > > > NEW: > > > > > > "This parameter contains an XPath expression identifying th= e > > > 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, an= d > > > 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. >=20 > So then that has to be explained. Otherwise, one might think that the fi= lter > is evaluated once, and then changes are reported whenever any node in the > selected subtrees are changed. >=20 > See also my conceptual algorithm above. I have explicitly added your (slightly tweaked) algorithm to the on-change = considerations section. So this should be covered. > > > 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. I forgot the reason why I had mandatory true. It is so that the leaf damp= ening-period is explicitly there in the RPC to identify this subscription a= s explicitly on-change. Without the leaf, you need to infer "on-change" t= hrough the absence of the "period" leaf. And such a design leaves open a g= reater chance of unnecessary errors. > > > 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. >=20 > I think it is important to try to design a standard so that it is useful = for > more than one current use case. In this case, it seems to me that the qo= s > parameters logically belong to the subscribed notifications layer, and th= us > should be defined there. I am fine either way. Will open an issue and start a thread with the large= r WG. Eric >=20 > /martin From nobody Tue Dec 5 00:44: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 110D2126D73; Tue, 5 Dec 2017 00:44:23 -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 Zah6BHzDuH_N; Tue, 5 Dec 2017 00:44: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 26846126C26; Tue, 5 Dec 2017 00:44:21 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id ECB9A1AE0144; Tue, 5 Dec 2017 09:44:18 +0100 (CET) Date: Tue, 05 Dec 2017 09:42:59 +0100 (CET) Message-Id: <20171205.094259.1741033872792646443.mbj@tail-f.com> To: lberger@labn.net Cc: draft-ietf-netconf-rfc7895bis@ietf.org, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <74f7ed03-6ee3-aa44-a093-53aad4323b62@labn.net> References: <74f7ed03-6ee3-aa44-a093-53aad4323b62@labn.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Netconf] some comments on draft-ietf-netconf-rfc7895bis 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, 05 Dec 2017 08:44:23 -0000 Lou Berger wrote: > Hi, > = > =A0=A0=A0 I have two comments on draft-ietf-netconf-rfc7895bis: > = > 1) In general it seems that NetMod and NetConf WGs have been making g= ood > strides at formally separating previously conflated YANG language, > module, and protocol related definitions and mechanisms.=A0 From this= > perspective, I think it important that rfc7895bis not to=A0 even make= any > normative references to any=A0 protocol. Note that https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines says that the references to 6241, 8040 etc must be normative. > I think just small changes are > needed in the document to make references to 6241 and 8040 informativ= e.=A0 > These include: > =A0=A0=A0 a) section 1.1,=A0 delete reference to 6241 and combine wit= h list > under 7950 Agreed, fixed in my local copy. > =A0=A0=A0 b) In case the section isn't deleted: Section 1.3, Paragrap= h 2, > s/MUST/are required/ in both occurrences. Ok. > =A0=A0=A0 c) Update section 4 to match > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines Ok. > 2) From reading the document, notably section 2, it is unclear which > datastore(s) will contain the library module.=A0 While we may all ass= ume > that the answer is obvious, IMO it is important for this to be > specified. We may even find that we have different answers to this > (apparently obvious) question. Ok, I'll add: All data nodes in "ietf-yang-library" are "config false", and thus accessible in the operational datastore. /martin From nobody Tue Dec 5 02:04: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 E035C1286B1 for ; Tue, 5 Dec 2017 02:04:21 -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 4R2faaAgCp-B for ; Tue, 5 Dec 2017 02:04:18 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A0AFA124205 for ; Tue, 5 Dec 2017 02:04:17 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 176961AE0144; Tue, 5 Dec 2017 11:04:16 +0100 (CET) Date: Tue, 05 Dec 2017 11:02:55 +0100 (CET) Message-Id: <20171205.110255.1069937786544957099.mbj@tail-f.com> To: evoit@cisco.com Cc: netconf@ietf.org, balazs.lengyel@ericsson.com, andy@yumaworks.com, alexander.clemm@huawei.com From: Martin Bjorklund In-Reply-To: <16ea77c9d7944aeea09a0b1971ab02a0@XCH-RTP-013.cisco.com> References: <4c2303ac1eff4b0db2dae056d56c9285@XCH-RTP-013.cisco.com> <20171204.124001.1188267155929301700.mbj@tail-f.com> <16ea77c9d7944aeea09a0b1971ab02a0@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] 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, 05 Dec 2017 10:04:22 -0000 Hi, "Eric Voit (evoit)" wrote: > Hi Martin, > > Reducing to the open items... > > > > + 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. > > > > I understand what you want to achieve, but I don't think the text is > > quite > > correct. I'll think about this some more to see if I can come up with > > a better > > wording. > > After the latest interactions on the mailer, text reads: > > Dampening period: In an on-change subscription, detected object > changes should be sent as quickly as possible. However it may be > undesirable to send a rapid series of object changes. Such behavior > has the potential to 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 datastore > nodes selected by a single subscription and sent to a single receiver. > This means that when there is a change to one or more subscribed > objects, an update record containing those objects is created either > immediately when no dampening period is in effect, or at the end of a > dampening period. If multiple changes to a single object occur during > a dampening period, only the value that is in effect is included as > part of the update record. A dampening period is reset every time an > update record has completed its assembly. What if you delete the last sentence? It is not clear to me what it means to reset a period. > > > 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. > > > > Or maybe > > > > In a periodic subscription, the data included as part of an update > > corresponds to data that could have been read using a retrieval > > operation over that subscription's transport. > > > > (no need for MUST here) > > Text updated as you proposed. > > > > > (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". > > > > Hmm, that paragraph is: > > > > It is not expected that implementations will support comprehensive > > filter syntax and boundless complexity. It will be up to > > implementations to describe what is viable, but the goal is to > > provide equivalent capabilities to what is available with a GET. > > > > What is a "comprehensive filter syntax"? Maybe this paragraph can be > > removed. > > Paragraph removed. > > > > > 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: > > > > My problem with this style is that it seems to indicate that the > > selection > > filter is only used for this use case ("replication of a subset..."), > > but that > > would be a mistake. I think you should explain what these filters are > > first, > > and then (maybe) give examples of how they can be used. > > > > The title "Datastore selection filter" is also misleading; > > I have made the title "Datastore selection", as the section doesn't > hit all the items of subscription policy (such as periods). > > > in fact the best > > solution might be to keep the original text but change the title of > > the > > section to "Subscription Policy". > > I have returned the text to something closer to the original text. It > now is: > > "A subscription must specify both the selection filters and the > datastore against which these selection filters will be applied. This > information is needed to choose and subsequently push the information > necessary to remotely maintain an extract of the publisher's > datastore." I prefer text that describes *how* this is used rather than *why*. So maybe change the last sentence above to: This information is used to choose and subsequently push data from the publisher's datastore to the receivers. > If you have other examples of how the info might be used, what would > you want to add? (One thing is possible is to simply monitor a > datastore for a specific event, like the creation of a node, but not > its deletion. More on this within the excluded change discussion > further below.) See above; I don't think these examples are needed at this point in the document. > > > > 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." > > > > The text for subtree filters use the words "When specified, updates > > will only > > come from the data nodes of selected YANG subtree(s)." If you use the > > same words here, the text is consistent and easier to understand. > > Maybe: > > > > NEW: > > > > o xpath: An xpath selection filter is an XPath expression that > > returns a node set. When specified, updates will only come from > > the selected data nodes. > > updated > > > > > 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. > > > > But you are constraining the entire solution to support just this use > > case, > > when a simpler unconstrained solution just as easily supports this use > > case, > > *plus other use cases* - if a client does not want these "fake > > *deletes", they > > can simply construct filters based on keys only, which they would in > > the > > current solution anyway. > > This is true. > > > Note also that b/c of the last paragraph in section 3.9, a client must > > deal > > with such deletes anyway, even if it specificied only keys. > > This is true. > > > But I do understand your point. This is also related to my comment > > below > > about when a filter is evaluated. Based on you reply to that comment, > > I > > think the conceptual algorithm is like this: > > > > Just before a change, evaluate the filter and any access control > > rules. The result is a set "A" of nodes (including subnodes). > > > > Just after a change, evaluate the filter and any (possibly new) > > access control rules. The result is a set "B" of nodes (including > > subnodes). > > > > Construct a YANG patch record for going from A to B. If the record > > is non-empty, send it to the subscriber. > > > > (this is conceptual, an implementation can do lots of optimizations to > > avoid > > evaluating filters on un-related changes) > > Yes, this is it. The only tweak I would make is to add the dampening > period. As a result, I have added the following text at the end of > the "On-Change Considerations" section > > "Putting it all together, following is the conceptual process for > creating an push-change-update notification: > > 1.Just before a change, or at the start of a dampening period, > evaluate any filtering and any access control rules. The result is a > set "A" of datastore nodes and subtrees. > > 2.Just after a change, or at the end of a dampening period, evaluate > any filtering and any (possibly new) access control rules. The result > is a set "B" of datastore nodes and subtrees. > > 3. Construct a YANG patch record for going from A to B. If the record > is non-empty, send it to the receiver." > > > > 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 > > > > What about this one: > > > > /interfaces/interface[contains(name, //name)] > > > > it also filters on a key is it ok? > > > > [if the answer is "yes" we have a problem; and if it is "no", we need > > to > > tighten the text] > > > > > > All this makes me wonder if it is correct to have "subtree" and > > "xpath" > > filters at all. If they only can match on keys, they become severely > > constrained. > > > > An alternative could be to specify filters as > > "nacm:node-instance-identifier" > > instead; these are instance-identitifiers that allow missing keys. > > For > > example: > > > > /if:interfaces/if:interface/if:oper-status > > > > This would be easier to understand and probably easier to optimize for > > in > > the server code. > > I want to generalize this "only-keys?" issue for the full WG. It is > too important to handle this deep in the thread. Look for me to open > an issue shortly. Ok! > > > > 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. > > > > Maybe "patch-id" could be a sequential number, starting from 1 when > > the > > first patch is sent? Or simply any string that the server finds > > appropriate. > > In any case, "null" looks odd in the example. > > Agree "null" looks odd. > > Does *anyone* have an issue if I make an implementation recommendation > that the definition the incremental number of the push-change-update > for a particular subscription? That would at least make the required > field useful? > > > > > 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. > > > > Ok, but the error code is used as a return value for > > "establish-subscription". > > So if a server can't detect it at "establish-subscription" it mean it > > will never > > be used. Hence I suggest you remove the text about "authorization > > privileges". > > A publisher could choose to allow a subscription to an empty location > where there might plausibly be objects someday. (E.g., maybe where an > interface might appear; even if there is no such interface currently > existing.) I think the spec needs to be clear if servers are required to allow filters to cover non-existing nodes or not (I think it should). Hence, selecting a non-existing node should not be an error. NOTE: we may want to handle the case that the client asks for a node that can *never* exist (e.g. a node in a non-implemented module or a misspelled node name) differently than the case that an instance doesn't exist. > Likewise a publisher could choose to reject a subscription because it > is obvious that a subscriber will never have access to the requested > data. (E.g., maybe always disallow subscription to YANG model which > controls the configuration of private keys.) > > Pretending they might have access someday and allowing the > subscription will just waste resources. So I think the error is > useful for such situations. This is fine, but not what the current description says. The text in 3.9 and the YANG module don't match. Also, in the normal case, I don't think the server will know if a client will *never* have access to some object. > > BTW, does this imply that I cannot create a filter for a currently > > non-existing interface? If this is true, my conceptual filter > > evaluation algorithm above is not correct... > > It is ok to create a filter for a non-existent interface. This is > supported in Cisco's XE implementation. Good. See above. > > > > 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.) > > > > Aha, ok. But then it looks really weird to have "scubscription-id" > > in the notifications defined in this module. It will be redundant. > > It isn't redundant *until* we have notification-messages available. > And this will take some time. After that, it need not be populated > where the new subscribed-notifications header is available. So the > logic to avoid per-update header redundancy is straight-forward. > > > Or do you suggest that *all* YANG modules that publish notifications > > must > > have a leaf "subscription-id", until the notification header document > > is > > done? If not, why is this document special? > > No, I am not suggesting all notifications need to define this leaf. > It is often the case that a single application can prove the need for > common infrastructure. In this case yang-push has pointed the way for > a generalization of subscription-id across all notifications. This is fine. But this doesn't mean that "subscription-id" should be treated differently in this draft compared to others. > > > > 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. > > > > Ok. So this means that when we have these new headers, > > "time-of-update" > > is no longer needed, right? > > Yes. > > > But actually, currently we have "eventTime". And since > > "notification-time" > > is equivalent to "eventTime", and "time-of-update" > > is "notification-time", it follows that "time-of-update" is redundant > > and not > > needed today either. Correct? > > I would be ok with that. And yes several of us have talked about it. > One person on this thread has argued the other way on this before > based on their implementation logic. But if they don't chime in now, > I am fine with getting rid of "time-of-update" (which already is > optional for this very reason). > > > > 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" > > > > I suggest you remove the sentence instead, and some more redundant > > words to get: > > > > OLD: > > > > An "updates-not-sent" object, which indicates that the update record > > is incomplete. If the application detects an informational > > discontinuity in either notification, the notification message MUST > > include "updates-not-sent". This object indicates that not all > > changes which have occurred since the last update are actually > > included with this update. > > > > NEW: > > > > An "updates-not-sent" object. This object indicates that not all > > changes which have occurred since the last update are actually > > included with this update. > > Ok, updated. > > > > > 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. > > > > No. See RFC7950, section 8.3.1, bullet 4. And compare with all other > > modules that use if-feature; no other module has invented such error > > codes. > > Let's handle this on the separate errors thread. The question of > legitimate negotiation interactions which are not actually errors is a > conversation needing more WG internalization. And without this, we > need to figure out how to send errors as part things like > subscription-suspended notifications. I don't think this notification has to change. > > > 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. > > > > Ok; i.e., the text should explain that it is used if the client asks > > for an obejct > > that does not support on-change. The if-feature case is already > > handled as > > described above. > > Have changed the definition to: > "On-change is not supportable for any objects which may be provided > through the selection filter."; s/any/all/ ? > > > > 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 > > > > But in this case the error will be "on-change-unsupported", right? > > I mean to say "except for" rather that e.g. My bad. > > > > ). Will enhance the > > > definition. > > Current text is now: > "Neither synch on start nor resynchonization are supported for this > subscription. This error will be used for two reasons. First if an > 'establish-subscription' RPC doesn't include 'no-synch-on-start', yet > the publisher can't support sending a 'push update' for this > subscription for reasons other that 'on-change-unsupported' or > 'result-too-big'. What would that reason be? I think that if the idea is that a server may or may not support sync on start, you should make a feature for it and call the leaf "sync-on-start" instead. And OTOH, if the default is sync on start (as it is now), it should be required to support it. > And second, if the 'resynch-subscription' RPC is > invoked either for an existing periodic subscription, or for an > on-change subscription which can't support resynchronization."; What would a leagal reason be for the latter case? > > > (2) The resynch RPC is invoked on a periodic subscription-id Ok. > > > , 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 > > > > Huh? What does *that* mean? > > As an extreme example: if someone tries to provide a character for a > key that only accepts integer. Note that both subtree filter and xpath allows this and will just return an empty node set. I really don't think we should change how XPath or subtree filter works. So I propose you remove this error. > Definition is now: > "Mismatch between selection filter key provided and the datatype of > the referenced YANG datatree node."; > > You might say this *should* be placed under normal error conditions, > per the larger error condition thread. And perhaps this is the case. > But there still is the case where a subscription is abnormally > terminated or suspended because someone modifies a configured > subscription to a non-viable filter which causes this error to pop up. > Such an option needs to be reported to a subscriber, and existing > error mechanisms don't do this AFAIK. > > > > > > identity datatree-size { > > > > > > > > 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 > > > > It will use ds:datastore as base. If we need some other generic base > > from > > which custom datastores are derived, that identity should be defined > > in a > > generic place (ietf-datastores probably), and not here. > > Will you put it in that document then? That makes it very easy to > delete from here. That's a discussion for the nmda document, but personally I don't see the need for such an identity. In any case, it should be removed from this document. > > > , 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. > > > > Yes. (At least from this document.) > > > > > > 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."; > > > > You didn't reply to this. My point is > > I took the definitions straight from rfc8072, with the tweak about how > to handle the dampening period as discussed previously. > > > > > > > > > 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. > > > > I think there's some confusion here. How would the "excluded-change" > > leaf-list be used in this case? (the typedef we're discussing is only > > used in > > "excluded-change") > > The typedef matches up to the types of elements which may be returned > in a YANG patch operation. If an entry appears in this list, it is > excluded from the allowed list of patch operations which may be sent > for that subscription. > > While this is not interesting for receivers which are trying to > maintain an extract of a datastore, it may be interesting for > applications which are simply looking for specific types of datastore > events. I will add some text in the type definition. > > > If an application needs to know *every* change, it probably shouldn't > > use a > > dampening period. > > Exactly > > > > (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" > > > > Well, yes this certainly needs to be described. I will have to think > > about the > > implications of this change. > > What I ended up doing is adding not a new section, but instead a new > paragraph within "on Change considerations" section. The paragraph > now reads: > > However a patch must be able to do more than just describe the delta > from the previous state to the current state. As per target="on-change"/>, it must also be able to identify if transient > changes have occurred on an object during a dampening period. To > support this, it is valid to encode a YANG patch operation so that its > application would result in a no change between the previous and > current state. This indicates that some churn has occurred on the > object. An example of this would be a patch that does a "create" > operation for a datastore node where the receiver believes one already > exists, or a "merge" operation which replaces a previous value with > the same value. Hmm, I think that this is a very strange way to indicate "churn", it is very implicit. Is it really necessary to be able to indicate this "churn"? It seems quite complex on both the server and client side. If a client needs to know this information, it can just not specify a 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. > > > > So then that has to be explained. Otherwise, one might think that the > > filter > > is evaluated once, and then changes are reported whenever any node in > > the > > selected subtrees are changed. > > > > See also my conceptual algorithm above. > > I have explicitly added your (slightly tweaked) algorithm to the > on-change considerations section. So this should be covered. > > > > > 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. > > I forgot the reason why I had mandatory true. It is so that the leaf > dampening-period is explicitly there in the RPC to identify this > subscription as explicitly on-change. Without the leaf, you need to > infer "on-change" through the absence of the "period" leaf. And such > a design leaves open a greater chance of unnecessary errors. I think the current data model has some other problems as well. Specifically, the "update-trigger" choice is optional - what does it mean if it no case is specified in this choice? Here's a proposal for a more explicit datamodel: choice update-trigger { when "../target/datastore/source"; (*) mandatory true; case periodic { container periodic { presence "indicates a periodic subscription"; leaf period { ... } leaf anchor-time { ... } } } case on-change { container on-change { presence "indicates an on-change subscription"; leaf dampening-period { type yang:timeticks; default "0"; // or mandatory if you prefer that the client // must be explicit } leaf no-sync-on-start { ... } leaf-list excluded-change { ... } } } } (*) this path shows another issue with the data model - in the "target" you have a "source". I think you should rename "source" to "datastore"; so in the case "datastore" there's a leaf "datastore". Also, it shows that it is not clear if the proper name in establish-subscription is "target" or "source" - or something else. > > > > 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. > > > > I think it is important to try to design a standard so that it is > > useful for > > more than one current use case. In this case, it seems to me that the > > qos > > parameters logically belong to the subscribed notifications layer, and > > thus > > should be defined there. > > I am fine either way. Will open an issue and start a thread with the > larger WG. Ok. /martin From nobody Tue Dec 5 07:29: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 146A9129541 for ; Tue, 5 Dec 2017 07:29:32 -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_H3=-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 7STp2ctUJyn6 for ; Tue, 5 Dec 2017 07:29:29 -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 0C142129536 for ; Tue, 5 Dec 2017 07:29:28 -0800 (PST) X-AuditID: c1b4fb25-7527a9c000000151-f1-5a26bb56772f Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C0.03.00337.65BB62A5; Tue, 5 Dec 2017 16:29:27 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 5 Dec 2017 16:28:37 +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=AqQfUFBE8VQ7/LyOQqcLKEP4ARjmryLcefNfLObaYm0=; b=dZesfDAHjxN/xLxFnUysd42kPO1bHboH6R1Z8I7pODeyIh0xhx4fuUxiFPL+uw7ZP34ZsXHJGcysoHUuj9hO4K8Z0f0GUiBG1olM9i3qv57z+aw24Ine9xiueSDq3f0chMbgOEtcUq47FWOS0+VFK4NvI2D6Y3ROwaOE3WJPLWM= Received: from [159.107.197.124] (91.82.100.59) by AM4PR07MB3427.eurprd07.prod.outlook.com (2603:10a6:205:b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.2; Tue, 5 Dec 2017 15:28:34 +0000 To: Andy Bierman , Martin Bjorklund CC: Netconf References: <20171128.103735.1654378548309425095.mbj@tail-f.com> From: Balazs Lengyel Message-ID: <81f49c62-e1fe-4a90-a93f-c7fd55229100@ericsson.com> Date: Tue, 5 Dec 2017 16:28:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: HE1PR05CA0137.eurprd05.prod.outlook.com (2603:10a6:7:28::24) To AM4PR07MB3427.eurprd07.prod.outlook.com (2603:10a6:205:b::12) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4baa3f1f-eeac-450e-4525-08d53bf4d958 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:AM4PR07MB3427; X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3427; 3:VDzfu/TlrrcTohRsci5vaVk939tRIXXso1BXjeJKEV0m1NVMwKkXLBdygrZMTPFQ6n3Hd43MOtjQRwxksT4bx0TyBRAESwH9HbTGOddjKXF1xU8klB5nNdR0W1i5EKJ62/MCfraY4txeouN96ZM1oD0o6LDQJcM/uG14s0NXR/acHQILi8L0sfbbGlA5iPk4/YOpaf4GeWN6ZDgFATy57XfvsbhfQF7XVFfjmapsov7fm+x9otgc/CUrBNOPbik7; 25:PPFDgyBMxgKPOtvcRQnsBp+RYBgBTGvGfTk7ztbNNe+5ya56J60LF5/U2v79xDCO60+W0/PTpcCVtEd+yfv93U4q8/F7hMHB+VrX1T8NctSYjYcBWlJEWhUBRAgP+Mr/bv557ug4g1J3BB69O0si85BJGDbMbnPSQrOssiuY6DbmfWgXJPNNEBkC3cL4/S5NfWUSiVZAnhCWbPsXoTP3w5ijnNuLv/xTUWAOpDMKaMH6tK792ceEjUXb5Vb+pY78+Vx9cJ5l2OWnFZB6YqgC1pkjxaulQvcccN+rhZ9XkxXzUQbII71hj33uVqxlLp6meYbEUbQAyWAqWQLIACoC9g==; 31:0/OHxD9Atk8+kFpurP9H2EZfLSYt7Tb8ssbhjaVm6ZmIAc9qw+BSdowYR1su4JG18/a7HW7Fieut37xjvXG910YAmPOATtGCDJzDW9EuZt/8+T7bpx21iDWKZi95Rxm0JgVOJmSvmWZSY44f43PAJ+z+asztr0wvzQiIQBMfzgt00m//ttbtwmBl85Ve4P+v+E3geLTiYnQn6V1CCDuK0FCZjdKXZNR1BhHfLfi/hkc= X-MS-TrafficTypeDiagnostic: AM4PR07MB3427: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3427; 20:T1Y7+sl4+8P4nE7pN7gAadmb2POHm0rN1se7Qgohdf3B+ph+7ApFW19o3XpWmfP10PvMMIrxgCqjnIZK/qOw9CTbxhA7PsC4x2zGiQHDm1kvHUD5N2iqLCkGyjxBtJ6dwYoZ19wPDM3eK2jhcib9ftNXIs2NtWy2yu5Zedhn8RoFXnnwjWWhvALeAdFgSoEzEeYGXaSc3glsWRGYw3075K2Z3onLGnDwsVfP4G1fo8d7bWIiaT+d1TfxWDnzidlMaW867dsgE/rxTTH644Sl5dGcUK02xmRxxC1rYtv+j4qMIRqincgonZoPHsQCASTB60r76S2gcBRtTrcfvwZxMM72LkhRr57pVXWIz4i+rqlvAG4BeDGioFfF9OFHjHdVNGQtyBHDnauJbkyqjBm7Bdzt6N9R4mjlNK5JeNHIxAfbZSYYBpc4FzJdKF1m874vt4TgC2M3+ECztE1+aRBauAR71BB7j0Dj2w/NY0eK+1Jw94NjJAlhfM7Zxv4ZAWRY; 4:pNYpBO27x5eH7NsHZo4XuB6Tf88Nb8SkVBiSkficGPGghiQfoa9KWxe2edYfNCv1FOBbeAEg6+ApX1FpJLzdp8tSvdX2n4JeUOQakw3xDeawBFZNdIcqHjutFgi+kbkb58q2ImsVVlLKi6KRSm/o+6uXT6UoetvDeYkrTo6Ue6GTU1Nr7lZY735ViN6UQBr8ny33De1Tqr4spnrnWg4YVlCf2vj6IgjFhMKDjSJuXwJD+DONuoNj0c0f9CCQbvBsDdl/27l1im1O+OHUo/UQlf6F61htWeTvzxOo2xoI+9p4DEVFFepB8Z5oF+D15VrJ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(3231022)(10201501046)(93006095)(93001095)(6041248)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123562025)(6072148)(201708071742011); SRVR:AM4PR07MB3427; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR07MB3427; X-Forefront-PRVS: 0512CC5201 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(366004)(346002)(376002)(39860400002)(252514010)(24454002)(377424004)(189002)(199003)(6116002)(3846002)(81166006)(236005)(230783001)(25786009)(36756003)(54896002)(2906002)(2870700001)(189998001)(64126003)(53546010)(31696002)(68736007)(6486002)(110136005)(50466002)(97736004)(23846002)(8936002)(4001150100001)(16526018)(478600001)(105586002)(33646002)(316002)(106356001)(31686004)(16576012)(66066001)(7736002)(49976008)(5660300001)(65826007)(76176011)(65956001)(53936002)(65806001)(4326008)(54356011)(52116002)(86362001)(83506002)(101416001)(8676002)(2950100002)(2486003)(81156014)(58126008)(23676004)(6666003)(52146003)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3427; H:[159.107.197.124]; 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) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTRQUjA3TUIzNDI3OzIzOmNlaFlHWDd5S2U4cFFLd1d2eDBwQm1UL1g4?= =?utf-8?B?QUVkK2Jnb1VEQ1JEM29LOE5Zci96bUZaUFNuUUs3OC8wbHcvam9kMmgvYkhD?= =?utf-8?B?ZEJ3TFl4Q2xoQjEvQlEvb3IvemhPZk5IalNIVzdsNi9PbTVINUhxc3IrcnZU?= =?utf-8?B?NTlxbDlHSHJGUFlWSDVDQi9EYlNnNGs1R2lLemhGM2dmcktWQlQ0L2x3Y2RZ?= =?utf-8?B?ai9WbHRJS0xlRHkrZGV4RVpBM1lnN0NhRkROZkhieklHWHI4NktXTkl3SDVl?= =?utf-8?B?L3l0QmtWSktBc295MDZNT2tNMjJtRys4alY4cDVkMk9FTUx5Y0JzSlgrZFVp?= =?utf-8?B?T2xndXIzRFBmRmFiaGRNU2hzYm1aSG96ZXFKZkFqdkJXS1V2Tnp1UGNuU3dT?= =?utf-8?B?QzVGbWxGVXd0TnFKbXdpcytBODBxQ2tEZloyM0pVcjVnTW16dWduZlZHR29U?= =?utf-8?B?RzFKZjdyMTR5aDlnVDFxM0wydkpicjhiSmlGRVNtaTdZczNnSlJkQVlXU0xM?= =?utf-8?B?b3IyVU02RTRmU0VncmkrbkFMaU1YWWxPUTAzSEpBdFk2bEVZd0VrNm5qQ2ZV?= =?utf-8?B?MFB6ZlF6RFhuTEFjVWhqOEFxRnVESWwrNk1uWjZxaXNrMnFVR1NycFBaMldh?= =?utf-8?B?OE1ubXRlMkJkSzYrUVRFVi9jT00rcnhvMkpKZW5BNjFQRXoraFZ0VEp3dCs3?= =?utf-8?B?ZVc3YU82U0lpTmdETmg0dm5OZ0pkWE5mcVVRYmlaTUkzWHNINGVFSGFLbENJ?= =?utf-8?B?Tk95M0tReERZZFlxQkx3RThqcTVRMmJxM3MzelB3V0dOZXZXUFoyWCtLRFdP?= =?utf-8?B?YksrK2UwcUFjQVpQdVdxL3NUL3F3ZUFiQnVwUnNpYm9uZFZFeFJsQSs4Z05n?= =?utf-8?B?YzhYbi9GYS82WEY3SGZ0UHFINzNRcXNuM25TeTAyUk12cHZweTYwTVZjRFk1?= =?utf-8?B?TklDVWlPaEh0ZmlIWWRKT3NVYnlLaGpEMzlzLzhhb283MHRXOGRoVm02RGJr?= =?utf-8?B?Q1hSUTlNdWljNkR1ZXR2YXZVYTRWRDNZeHMraThzYW02c09xSVhENkExZnEr?= =?utf-8?B?bDJoeWpHMlBYL3lQdTk1dHJGUEJIVnpjWE96TWw2ZWNpUi9qVmFjS3lQNmk0?= =?utf-8?B?bFhBWGFTRFpNQVBFWFBuN093aDR3dUFFelpNNERSRHJqTnYxMkNsQ2tWdHAz?= =?utf-8?B?YmYyT3lCaWUzVTdQbEF4ME12OWJUMnlzVEo1TUQwT2M5cGY1NXhMT2VXL05N?= =?utf-8?B?WXlsdGxHVm03TlVHVmM0Y25XaDdkcU1aTzNBMlJ4YXU5UEtjQXhVUHBNdVJF?= =?utf-8?B?VWhrU2p6QUtSN1prRzZ2RmRNdFhvakU4RDVjSytoT1VqMTlJZ2pGUUlCUkVB?= =?utf-8?B?NXBXSkhua2xyaHplVDI4ejdjRDRFL0IrSVRzM1hiUXdwbGw3L0hFUVVjKzN1?= =?utf-8?B?eEdXc0JtZnY2ZGdoT01HQ1c0a3dFV0ZveTZ6VldWWHdFTVhXRUdSQU1zRWcr?= =?utf-8?B?VXBWejdDZk5DNVZpbHowUTZ6T0lGak5LOUU2WGlFQ0NyaVlyZDVvZHdpNytS?= =?utf-8?B?ckdWUGU2NkxEV2tBdGtCZ3NLZDU4bWR1elpkYWh4dS9yRUxIcCtMM1o4K0Zr?= =?utf-8?B?WWpJVzgzNlBuaW83NE5YS1VHQXByZ3U5UHk0dGNEQzZ3N1daMkxzaitJNE5Z?= =?utf-8?B?eXBqVGlhSmNHd3lGeDdhUmpiVUFJNDlqSFN6V2xyc1JpalljTXhqZDBVWVpV?= =?utf-8?B?REp5bDFwYW5QMHBub3BzNGdsaEE3aDRyWU5tRG52R08xdzNybmhzUVJyeEdu?= =?utf-8?B?VGVaYXJYTS9lKzZrSnVZL092UUQvenFRalRIUmlsc2Nxa3ZRdmthZ2pZdzlh?= =?utf-8?B?L0VLa1pZWm4yYW5zNFoxTzRjWGNCV0tQNnhNYnNML08va3NmSHN3cFlRck1X?= =?utf-8?B?UWtrb0szemxsMEY2WFJoOThqOWZCZ3MxWStQNFhaQXpDUHMxMVJ6YmlaK053?= =?utf-8?B?ZU1CU2ZGUzg2c1VLRGJ5clFVRHRQNGhndkE4QT09?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3427; 6:iWYNg81+6zl14BGbNQRpUt5xuqXbOZiIWExkcv0KpX239tyldsxpuJh3KNvdG4J9Dyw+foQUUDEX6ygaGlN9ygW92HTOrE7c84/pG/NaeQYz5cyxlo8NjOxPyljCrx7cTPZKaBnDME7b9Y/cvl//hjVVrYb1hrpYqWZamShB4J1/deja8akT2UVADjemMmo8k4f0tlkvgjGBwdpwf0EFkOWdb/BRJxiZhE9N+90BjSau+UKYv1fx17FEwOW4SuyUNxV1ODD6uynYkntXtIpXJx0dYmctjaL4sbcvuMbJHrXfRo6DyOb0FaQ4j3kwuC9M5RFh4QmrCfLY9MS7PUDIEo2AUya9ww2uUFgd1m2bOFY=; 5:kXDo8F3DxvyhgPlnMWfDsLtm3UF5/u/YhRp9FebBW/tn9xm3URj7JHUoTycsIz5IIAzn58nnQrtkQgvie49hXh73XNPJ4ZOBY9AGIPDvZ0m1xrw5YOo5RY5NkfJkT5rJ3xy8yhvYiPFuOvJRefXuIjTdNhQF6vbPg8oRTMyZVVE=; 24:+JG0ZbMKmlyCU1crYSL1djt5OS3yrmfuzoVK1GSyrosOm7ktB+jgFMi4yudIvv2ykf9hOicd6YJ3cWaW+viul/6wYHejl6KEYdxAfmFjuNM=; 7:8EVgb0ONabSHJHmFKr331w12733pRtajrGlasb8xphrjx30Te4mnXr9bkUy1qKErhu8kskFLLRtNb56TSGrd77MyEcawP2TrjU6DFLyYv7bpx+ExkgXhWAxQEpa1TnOKEke+dz17nVZl2wtyoj7Bc7fFhcQoGnL+nnGo5MxHHF/wbdLBGiPpraQqn5e61+d1TXsk4s0NQ/EyhTXDsJ1Sm30Bhb58CMnSAGX+zOBKXfSdEuneIacXatQHvdRPysgZ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2017 15:28:34.2917 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4baa3f1f-eeac-450e-4525-08d53bf4d958 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3427 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUyM2K7vW74brUog2M72SweHJnFbtHd/Yzd Yuqm26wOzB5Llvxk8tj4azGLR0v/RZYA5igum5TUnMyy1CJ9uwSujJ17/rEUvNGqeNh1haWB cb90FyMnh4SAiUTbxFbmLkYuDiGBw4wSU/+dgHKOM0qc33meEcRhEehllli2eQkLRKaNSeL5 sTmMIP3CAgkS1//dB7I5OEQEPCTWzHEDCTMLyEks/tHDBFHfzihx9GQfO0iCTcBIYmr/eRYQ m1fAXmLb2hlMIDaLgIrE3av/WEFsUYEYicM901khagQlTs58AlbPKRAocff7OmaIBRoSrXPm skPY4hK3nsxngrDlJZq3zmaG+E1B4vrm62BHSwhMAXpnWhNYgxBQ88MLf1khimQljp6dwwLy gISAr0TfIQ+I+iWMEjferGaHcBrYJZaeWcwO0aAlse/YBLDvGQXiJHauWcgKUfSDTWLj0ndQ U7MlPt3YxQhhW0m8/vUdyl7ALDH/sxaELSNx/uoilgmMOrOQfDoLyXezkHw3C8l3CxhZVjGK FqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIEppODW36r7mC8/MbxEKMAB6MSD6/XBLUoIdbEsuLK 3EOMEhzMSiK8cVuBQrwpiZVVqUX58UWlOanFhxilOViUxHlPevJGCQmkJ5akZqemFqQWwWSZ ODilGhjb7CbZek5Qzf+9tTtfU/v+2sTElnkLWWOfLP8c7dtd7VQssrb8WKtT1ya+z9vDDyT/ dqpr5z9naaxeln7S9+WVJE9vx9eqmkufvQr80nxf7OyWntXO5YdOJVcI5VVazZXXbJj55d2r 46oGvRP3+srsvvpoxxqTOllXV5lu30mdO8LLKhafOa3EUpyRaKjFXFScCACcAGOHIwMAAA== Archived-At: Subject: [Netconf] "notifiable-on-change" [was: Re: 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, 05 Dec 2017 15:29:32 -0000

I very strongly object to excluding the issue.  There is a strong and immediate need to be able to specify in vendor design time for which data nodes will there be on-change notification be generated.

When a vendor release a product they know which nodes will emit on-change notifications in design time. System integrators need to know this. Providing the same information in run-time as instance data is not a good solution either as you would need to get a real node to read the data from.

IMHO ignoring this need would just force the vendors (including ericsson) to create an own solution.

Andy wrote: "I agree this is an implementation property, and not a data model property."

I always thought that one of the main purposes of YANG was to document vendor's implementation. That is exactly what a deviation or  feature also does. They are both part of YANG.

regards Balazs


On 2017-11-28 18:10, Andy Bierman wrote:


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.  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:

   <entry>
     <path>/sys:system/sys:system-time<path>
     <notifiable-on-change>false</notifiable-on-change>
   </entry>
   <entry>
     <path>/sys:system<path>
     <notifiable-on-change>true</notifiable-on-change>
   </entry>

  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



-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Tue Dec 5 08:56: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 ECC8512946B for ; Tue, 5 Dec 2017 08:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec7UUFzQp4pa for ; Tue, 5 Dec 2017 08:56:55 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 973A51294C4 for ; Tue, 5 Dec 2017 08:56:55 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id vB5GuYsh020221 for ; Tue, 5 Dec 2017 11:56:54 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 2enxx09du8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 05 Dec 2017 11:56:53 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id vB5Guqp5014036 for ; Tue, 5 Dec 2017 11:56:52 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id vB5GujhY013929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 5 Dec 2017 11:56:48 -0500 Received: from gbcdccas02.intl.att.com (gbcdccas02.intl.att.com [135.76.180.10]) by mlpi409.sfdc.sbc.com (RSA Interceptor) for ; Tue, 5 Dec 2017 16:56:32 GMT Received: from GBCDCMBX03.intl.att.com ([135.76.31.134]) by gbcdccas02.intl.att.com ([135.76.180.10]) with mapi id 14.03.0361.001; Tue, 5 Dec 2017 16:56:30 +0000 From: "Ivory, William" To: "'netconf@ietf.org'" Thread-Topic: Query about scope of NETCONF get-schema on module vs submodule Thread-Index: AdNt6dAKY7lyhZbFTOWmlTp5SFH6lA== Date: Tue, 5 Dec 2017 16:55:28 +0000 Deferred-Delivery: Tue, 5 Dec 2017 16:56:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.160.174.32] Content-Type: multipart/alternative; boundary="_000_E3378E0605547F4E854DEE0CB1116AB029EA7Cgbcdcmbx03intlatt_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-05_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1031 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712050244 Archived-At: Subject: [Netconf] Query about scope of NETCONF get-schema on module vs submodule 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, 05 Dec 2017 16:56:57 -0000 --_000_E3378E0605547F4E854DEE0CB1116AB029EA7Cgbcdcmbx03intlatt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Would appreciate clarification of the scope of the NETCONF get-schema RPC w= hen called for a module which has submodules. RFC 6022 suggests that you c= an specify either module or submodule name in the get-schema request, but d= oesn't specify whether requesting a module should return all submodule sche= mas for that module or only the schema within the module yang file. Thanks, William --_000_E3378E0605547F4E854DEE0CB1116AB029EA7Cgbcdcmbx03intlatt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Would appreciate clarification of the scope of the N= ETCONF get-schema RPC when called for a module which has submodules.  = RFC 6022 suggests that you can specify either module or submodule name in t= he get-schema request, but doesn’t specify whether requesting a module should return all submodule schemas for that m= odule or only the schema within the module yang file.

 

Thanks,

 

William

 

--_000_E3378E0605547F4E854DEE0CB1116AB029EA7Cgbcdcmbx03intlatt_-- From nobody Tue Dec 5 12:03:46 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 442631270A7 for ; Tue, 5 Dec 2017 12:03:43 -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 ELQEk0ZnxAQd for ; Tue, 5 Dec 2017 12:03:40 -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 0123512025C for ; Tue, 5 Dec 2017 12:03:39 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 3EDA81312247C for ; Tue, 5 Dec 2017 20:03:35 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 5 Dec 2017 20:03:36 +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; Tue, 5 Dec 2017 12:03:26 -0800 From: Alexander Clemm To: Andy Bierman , Martin Bjorklund CC: Netconf Thread-Topic: [Netconf] yang-push issue: error handling Thread-Index: AQHTaubADOTUW5LGwkKD+sraYMgQfKMzrq2AgABIa4CAATJtIA== Date: Tue, 5 Dec 2017 20:03:25 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD10E9@sjceml521-mbx.china.huawei.com> References: <20171204.135539.1530792967351325058.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.169] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD10E9sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Netconf] yang-push issue: error handling 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, 05 Dec 2017 20:03:43 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD10E9sjceml521mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldoaWxlIHBvc3NpYmxlLCB0aGUgc29sdXRpb24gb2YgaGF2aW5nIHRvIHJldHVybiBy cGMtZXJyb3IgZXRjIGRvZXMgc3RyaWtlIG1lIGFzIHNvbWV3aGF0IGNsdW5reS4gIFdoaWxlIGl0 IGlzIHBvc3NpYmxlIHRvIGFkZCBhbiBlcnJvci1hcHAtdGFnLCBhbmQgbmVnb3RpYXRpb24gc3R1 ZmYgYXMgZXJyb3ItaW5mbyAoYW5kIEkgYXBwcmVjaWF0ZSB0aGUgc3VnZ2VzdGlvbiksIHRoYXQg c29sdXRpb24gd291bGQgbmVlZCB0byBiZSBkZXNjcmliZWQgdXNpbmcgYSBsb3Qgb2YgcHJvc2Ug aW4gZGVzY3JpcHRpb24gc3RhdGVtZW50cyBhIGxhIFNNSXYyIChwcmVzdW1hYmx5IGFzIHBhcnQg b2YgdGhlIFJQQyBkZXNjcmlwdGlvbiwgbm90IGFzIHBhcnQgb2YgZS5nLiB0aGUgaWRlbnRpdGll cywgd2hpY2ggbWlnaHQgYmUgdXNlZCBpbiBhIG51bWJlciBvZiBwbGFjZXMsIG5vdCBqdXN0IHRo ZSBlcnJvci1hcHAtdGFnKS4gICBJIGFtIG5vdCBzdXJlIHdoeSB0aGF0IHdvdWxkIG1ha2UgYW4g UlBDIGFueSBlYXNpZXIgdG8gaW1wbGVtZW50LiAgVGhlIHNhbWUgY2hlY2tzIHN0aWxsIGhhdmUg dG8gYmUgbWFkZS4NCg0KV2h5IHdvdWxkIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBub3QgYWNjZXB0 YWJsZT8gICBJZGVhbGx5IFlBTkcgd291bGQgcHJvdmlkZSBiZXR0ZXIgc3VwcG9ydCB0byBmb3Jt YWxseSBkZWZpbmUgYXBwbGljYXRpb24vUlBDLXNwZWNpZmljIHJldHVybiBjb2RlcyBhbmQgY29y bmVyIGNvbmRpdGlvbnMgZXRjLiBTaG9ydCBvZiB0aGF0LCB0aGUgcHJvcG9zZWQgc29sdXRpb24g b2YgYWRkaW5nIFJQQyBvdXRwdXQgcGFyYW1ldGVycyB0aGF0IGFyZSB1c2VkIGZvciB0aGUgcHVy cG9zZSBvZiBpbmRpY2F0aW5nIHdoYXQgaXMgZ29pbmcgb24gYXQgdGhlIGFwcGxpY2F0aW9uIGxl dmVsIHNpbXBseSBtYWtlcyB0aGVtIHBhcnQgb2YgdGhlIHNlbWFudGljcyBvZiB0aGUgc3BlY2lm aWMgUlBDIGl0c2VsZi4gIEl0IGlzIG5vdCBOZXRjb25m4oCZcyByb2xlIHRvIGRlZmluZSB3aGF0 IGFuIFJQQyBjYW4gb3IgY2Fubm90IGRvLCBqdXN0IGxpa2UgaXQgY2Fubm90IGRlZmluZSB3aGF0 IGEgcGFydGljdWxhciBsZWFmIG1heSBvciBtYXkgbm90IHJlcHJlc2VudC4gIFRoYXQgaXMgcGFy dCBvZiB0aGUgUlBDIGRlZmluaXRpb24uDQoNCkJhc2ljYWxseSwgd2hhdCB3ZSBhcmUgZGlzY3Vz c2luZyBoZXJlIGlzIGJlaGF2aW9yIG9mIHN1YnNjcmlwdGlvbiBjb25maWd1cmF0aW9uIHVuZGVy IGNvcm5lciBjb25kaXRpb25zLiAgVGhlIGZhY3QgdGhhdCBubyBzdWJzY3JpcHRpb24gaXMgY3Jl YXRlZCBiZWNhdXNlIGl0IHdvdWxkIHJlc3VsdCBpbiBhbiB1bmFjY2VwdGFibGUgdm9sdW1lIG9m IHVwZGF0ZXMgZm9yIGEgc3BlY2lmaWMgaW1wbGVtZW50YXRpb24gaXMgZGlmZmVyZW50IGZyb20g YW4gZXJyb3IgY29uZGl0aW9uIHN1Y2ggYXMgYSBtYWxmb3JtZWQgbWVzc2FnZSB0aGF0IGlzIG1p c3NpbmcgYSByZXF1aXJlZCBtZXNzYWdlLWlkLCBvciB3aGVyZSBhIHZhbHVlIHZpb2xhdGVzIGEg Y29uc3RyYWludCBzcGVjaWZpZWQgaW4gYSBNVVNULWNvbmRpdGlvbi4gIEluIG91ciBjYXNlLCB3 aGF0IGlzIGJlaW5nIGRlc2NyaWJlZCBhcmUgc3BlY2lmaWMgY29uZGl0aW9ucyBhdCB0aGUgYXBw bGljYXRpb24gbGF5ZXIsIGFib3ZlIHRoZSBOZXRjb25mL1Jlc3Rjb25mIGdlbmVyaWMgdmFsaWRh dGlvbiBpbmZyYXN0cnVjdHVyZS4gICBUaGUgb3BlcmF0aW9uIGRvZXMgbm90IOKAnHdvcmvigJ0g aW4gdGhlIHNlbnNlIHRoYXQgaXQgZG9lcyBub3QgcmVzdWx0IGluIGFuIGFjdGl2ZSBzdWJzY3Jp cHRpb24sIGJ1dCBpdCBkb2VzIHdvcmsgaW4gdGhlIHNlbnNlIHRoYXQgdGhlIGJlaGF2aW9yIGlz IHZlcnkgd2VsbCBkZWZpbmVkIGluIHRlcm1zIG9mIHRoZSBlZmZlY3QgdGhhdCB0aGUgUlBDIGhh cyAoaS5lLiB0aGUgZWZmZWN0IGlzIHRoYXQgaXQgcmVzdWx0IGluIGNyZWF0aW9uIG9mIGEgc3Vi c2NyaXB0aW9uLCBpZiBjZXJ0YWluIGNvbmRpdGlvbnMgYXJlIG1ldCwgYW5kIGl0IGRvZXMgbm90 IHJlc3VsdCBpbiBjcmVhdGlvbiBvZiBhIHN1YnNjcmlwdGlvbiBpbiBjYXNlIGNlcnRhaW4gY29u ZGl0aW9ucyBhcmUgbm90IG1ldCkuICBXaHkgc2hvdWxkIE5ldGNvbmYgcmVzdHJpY3Qgd2hhdCBh biBSUEMgY2FuIG9yIGNhbm5vdCBkbz8gIFRoaXMgaXMgYWxsIGFwcGxpY2F0aW9uLXNwZWNpZmlj Lg0KDQotLS0gQWxleA0KDQoNCkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmR5IEJpZXJtYW4NClNlbnQ6IE1vbmRheSwgRGVjZW1i ZXIgMDQsIDIwMTcgOToxNSBBTQ0KVG86IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29t Pg0KQ2M6IE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW05ldGNvbmZd IHlhbmctcHVzaCBpc3N1ZTogZXJyb3IgaGFuZGxpbmcNCg0KDQoNCk9uIE1vbiwgRGVjIDQsIDIw MTcgYXQgNDo1NSBBTSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1i akB0YWlsLWYuY29tPj4gd3JvdGU6DQpBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxt YWlsdG86YW5keUB5dW1hd29ya3MuY29tPj4gd3JvdGU6DQo+IEhpLA0KPg0KPiBJTU8gdGhlIHNw ZWNpYWwgZXJyb3IgaGFuZGxpbmcgaW4gWUFORyBQdXNoIGlzIG5vdCBhY2NlcHRhYmxlDQo+IGJl Y2F1c2UgaXQgdmlvbGF0ZXMgTkVUQ09ORiBhbmQgUkVTVENPTkYgZXJyb3IgaGFuZGxpbmcgcHJv Y2VkdXJlcy4NCj4gTkVUQ09ORiBzYXlzIGlmIHRoZSBvcGVyYXRpb24gZG9lcyBub3Qgd29yayBm b3IgYW55IHJlYXNvbiBhbiA8cnBjLWVycm9yPg0KPiBlbGVtZW50IFNIT1VMRCBiZSByZXR1cm5l ZC4NCg0KSSBmdWxseSBhZ3JlZSwgYW5kIEkgaGF2ZSBwb2ludGVkIHRoaXMgb3V0IHNldmVyYWwg dGltZXMgaW4gbXkNCnJldmlld3MuICBUaGUgcHJvYmxlbSBpcyBhY3R1YWxseSBpbiBzdWJzY3Jp YmVkIG5vdGlmaWNhdGlvbnMsIGFuZCBJDQp0aGluayBFcmljIGlzIHRyYWNraW5nIHRoYXQgaXNz dWUuDQoNClRyeWluZyB0byBiZSBjb25zdHJ1Y3RpdmUsIEkgdGhpbmsgdGhhdCB0aGUgZXhpc3Rp bmcgbWVjaGFuaXNtcyBpbg0KWUFORyBjYW4gYmUgdXNlZCB0byBhY2hpZXZlIHRoZSBzYW1lIGZ1 bmN0aW9uYWxpdHkgdGhhdCB0aGVzZSBkcmFmdHMNCnRyeSB0byBhY2hpZXZlLiAgU3BlY2lmaWNh bGx5Og0KDQogIDEuIFVzZSBpZGVudGl0aWVzIGp1c3QgbGlrZSB0aGUgb25lcyB5b3UgaGF2ZQ0K ICAgICAoInVuc3VwcG9ydGFibGUtdm9sdW1lIiwgImZpbHRlci11bmF2YWlsYWJsZSIgZXRjKSwg YnV0IGFkZCB0ZXh0DQogICAgIHRoYXQgZXhwbGFpbnMgdGhhdCB0aGVzZSBpZGVudGl0aWVzIGFy ZSBzZW50IGFzICJlcnJvci1hcHAtdGFnIg0KICAgICBpbiAicnBjLWVycm9yIiwgZW5jb2RlZCB0 byBhIHN0cmluZyBhcyA8bW9kdWxlPjo8aWRlbnRpdHk+LiAgVGhpcw0KICAgICB3b3JrcyBmb3Ig Ym90aCBORVRDT05GIGFuZCBSRVNUQ09ORi4NCg0KICAyLiBGb3IgdGhlICJoaW50cyIgZXh0cmEg aW5mbyB0aGF0IHlvdSByZXR1cm4sIGRlZmluZSBhICJ5YW5nLWRhdGEiDQogICAgIHN0cnVjdHVy ZSB3aXRoIHRoZSBoaW50cywgYW5kIGV4cGxhaW4gaW4gdGV4dCB0aGF0IHRoaXMgc3RydWN0dXJl DQogICAgIGlzIHJldHVybmVkIGluICJlcnJvci1pbmZvIi4gIFRoaXMgd29ya3MgZm9yIGJvdGgg TkVUQ09ORiBhbmQNCiAgICAgUkVTVENPTkYuDQoNCg0KKzENCg0KSWYgdGhlIGVycm9yIGhhbmRs aW5nIHdhcyBkb25lIGNvcnJlY3RseSB0aGVuIHRoZSBzYW1lIHByb2NlZHVyZXMgY291bGQgYmUN CmFwcGxpZWQgdG8gPGVkaXQtY29uZmlnPiBmYWlsdXJlcyBmb3IgY29uZmlndXJlZCBzdWJzY3Jp cHRpb25zLg0KDQoNCg0KQXMgYW4gYWx0ZXJuYXRpdmUgdG8gMSwgeW91IGNhbiBwdXQgdGhlIGVy cm9yIGlkZW50aXRpeXJlZiBpbiB0aGUNCiJ5YW5nLWRhdGEiIHN0cnVjdHVyZSwgYW5kIHNlbmQg Ym90aCB0aGUgaWRlbnRpdGl5cmVmIGFuZCBoaW50cyBpbg0KImVycm9yLWluZm8iLg0KDQoNCi9t YXJ0aW4NCg0KDQpBbmR5DQoNCg0KDQoNCj4gVGhlIDxlc3RhYmxpc2gtc3Vic2NyaXB0aW9uPiBy ZXR1cm5zIGRhdGEgZXZlbiBvbiBlcnJvci4NCj4gSW5zdGVhZCBvZiB0aGUgY29tbW9uIGVycm9y LXRhZywgZXJyb3ItaW5mbywgYW5kIG90aGVyIGZpZWxkcywNCj4gdGhlcmUgaXMgYSBzdWJzY3Jp cHRpb24tcmVzdWx0IGxlYWYuDQo+DQo+IElmIGFueSBjbGllbnQgKG9yIGV2ZW4gc2VydmVyKSBm dW5jdGlvbmFsaXR5IHVzZXMgdGhlIE5FVENPTkYgYW5kDQo+IFJFU1RDT05GIHN0YW5kYXJkIGVy cm9yIGhhbmRsaW5nLCB0aGVuIHN1YnNjcmlwdGlvbi1yZXN1bHQgd2lsbCBub3QgYmUNCj4gc2Vu dCBvciBleHBlY3RlZCBhcyBhbiBlcnJvciByZXNwb25zZS4gRGVwZW5kaW5nIG9uIHRoZSBzZXJ2 ZXINCj4gaW1wbGVtZW50YXRpb24sIHRoZSBjb2RlIHRoYXQga25vd3MgYWJvdXQgZXN0YWJsaXNo LXN1YnNjcmlwdGlvbg0KPiBtYXkgbm90IGdldCBjYWxsZWQgYmVjYXVzZSBjb21tb24gZXJyb3Ig aGFuZGxpbmcgY29kZSBoYXMNCj4gYWxyZWFkeSBkZXRlcm1pbmVkIHRoZXJlIGlzIGFuIDxycGMt ZXJyb3I+IHRvIHNlbmQgaW5zdGVhZCBvZiBhIGRhdGENCj4gcmVzcG9uc2UuDQo+DQo+IEV4cGVj dCB0aGF0IHNvbWUgc2VydmVycyBhcmUgbmV2ZXIgZ29pbmcgdG8gc2VuZCBkYXRhIG9uIGFuIG9w ZXJhdGlvbg0KPiBmYWlsdXJlLCBhbmQgd2lsbCBvbmx5IHNlbmQgPHJwYy1lcnJvcj4gaW5zdGVh ZC4NCj4NCj4NCj4gPkZyb20gc2VjLiAzLjg6DQo+DQo+ICAgIEZvciBpbnN0YW5jZSwgZm9yIHRo ZSBmb2xsb3dpbmcgcmVxdWVzdDoNCj4NCj4gPG5ldGNvbmY6cnBjIG1lc3NhZ2UtaWQ9IjEwMSIN Cj4gICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6 MS4wIj4NCj4gICAgPGVzdGFibGlzaC1zdWJzY3JpcHRpb24NCj4gICAgICAgIHhtbG5zPSJ1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMiDQo+ ICAgICAgICB4bWxuczp5cD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYteWFuZy1w dXNoIj4NCj4gICAgICAgPHlwOmRhdGFzdG9yZT4NCj4gICAgICAgICA8eXA6c291cmNlIHhtbG5z PSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1kYXRhc3RvcmVzIj4NCj4gICAgICAg ICAgIG9wZXJhdGlvbmFsDQo+ICAgICAgICAgPC95cDpzb3VyY2U+DQo+ICAgICAgICAgPHlwOnN1 YnRyZWUtZmlsdGVyIG5ldGNvbmY6dHlwZT0ieHBhdGgiDQo+ICAgICAgICAgICAgIHhtbG5zOmV4 PSJodHRwOi8vZXhhbXBsZS5jb20vc2FtcGxlLWRhdGEvMS4wIg0KPiAgICAgICAgICAgICBzZWxl Y3Q9Ii9leDpmb28iLz4NCj4gICAgICAgPC95cDpkYXRhc3RvcmU+DQo+ICAgICAgIDx5cDpwZXJp b2Q+NTAwPC95cDpwZXJpb2Q+DQo+ICAgIDwvZXN0YWJsaXNoLXN1YnNjcmlwdGlvbj4NCj4gPC9u ZXRjb25mOnJwYz4NCj4NCj4gICAgICAgICAgICAgICAgICBGaWd1cmUgMzogRXN0YWJsaXNoLVN1 YnNjcmlwdGlvbiBleGFtcGxlDQo+DQo+ICAgIHRoZSBwdWJsaXNoZXIgbWlnaHQgcmV0dXJuOg0K Pg0KPg0KPiA8cnBjLXJlcGx5IG1lc3NhZ2UtaWQ9IjEwMSINCj4gICAgICB4bWxucz0idXJuOmll dGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4NCj4gICAgPHN1YnNjcmlwdGlvbi1y ZXN1bHQNCj4gICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1z dWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMiDQo+ICAgICAgICB4bWxuczp5cD0idXJuOmlldGY6cGFy YW1zOnhtbDpuczp5YW5nOmlldGYteWFuZy1wdXNoIj4NCj4gICAgICB5cDpwZXJpb2QtdW5zdXBw b3J0ZWQNCj4gICAgPC9zdWJzY3JpcHRpb24tcmVzdWx0Pg0KPiAgICA8cGVyaW9kLWhpbnQgeG1s bnM6InVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLXlhbmctcHVzaCI+DQo+ICAgICAg IDIwMDANCj4gICAgPC9wZXJpb2QtaGludD4NCj4gPC9ycGMtcmVwbHk+DQo+DQo+ICAgICAgICAg ICAgICAgICAgICAgIEZpZ3VyZSA0OiBFcnJvciByZXNwb25zZSBleGFtcGxlDQo+DQo+DQo+DQo+ IEJUVywgYWxsIHRoZSBmaWx0ZXIgZXhhbXBsZXMgc2VlbSB0byBiZSB3cm9uZywgaW5jbHVkaW5n IHRoZSBvbmUgYWJvdmUNCj4NCj4NCj4gT0xEOg0KPg0KPiAgICAgICAgIDx5cDpzdWJ0cmVlLWZp bHRlciBuZXRjb25mOnR5cGU9InhwYXRoIg0KPiAgICAgICAgICAgICB4bWxuczpleD0iaHR0cDov L2V4YW1wbGUuY29tL3NhbXBsZS1kYXRhLzEuMCINCj4gICAgICAgICAgICAgc2VsZWN0PSIvZXg6 Zm9vIi8+DQo+DQo+DQo+IE5FVzoNCj4NCj4NCj4gICAgICAgICA8eXA6c3VidHJlZS1maWx0ZXI+ DQo+ICAgICAgICAgICAgPGV4OmZvbyB4bWxuczpleD0iaHR0cDovL2V4YW1wbGUuY29tL3NhbXBs ZS1kYXRhLzEuMCIgLz4NCj4NCj4gICAgICAgICA8L3lwOnN1YnRyZWUtZmlsdGVyPg0KPg0KPg0K PiBBbmR5DQoNCg== --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD10E9sjceml521mbxchi_ 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 cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPldoaWxlIHBvc3NpYmxlLCB0aGUgc29sdXRpb24gb2YgaGF2aW5nIHRvIHJl dHVybiBycGMtZXJyb3IgZXRjIGRvZXMgc3RyaWtlIG1lIGFzIHNvbWV3aGF0IGNsdW5reS4gJm5i c3A7V2hpbGUgaXQgaXMgcG9zc2libGUgdG8gYWRkIGFuIGVycm9yLWFwcC10YWcsIGFuZCBuZWdv dGlhdGlvbg0KIHN0dWZmIGFzIGVycm9yLWluZm8gKGFuZCBJIGFwcHJlY2lhdGUgdGhlIHN1Z2dl c3Rpb24pLCB0aGF0IHNvbHV0aW9uIHdvdWxkIG5lZWQgdG8gYmUgZGVzY3JpYmVkIHVzaW5nIGEg bG90IG9mIHByb3NlIGluIGRlc2NyaXB0aW9uIHN0YXRlbWVudHMgYSBsYSBTTUl2MiAocHJlc3Vt YWJseSBhcyBwYXJ0IG9mIHRoZSBSUEMgZGVzY3JpcHRpb24sIG5vdCBhcyBwYXJ0IG9mIGUuZy4g dGhlIGlkZW50aXRpZXMsIHdoaWNoIG1pZ2h0IGJlIHVzZWQgaW4NCiBhIG51bWJlciBvZiBwbGFj ZXMsIG5vdCBqdXN0IHRoZSBlcnJvci1hcHAtdGFnKS4mbmJzcDsgJm5ic3A7SSBhbSBub3Qgc3Vy ZSB3aHkgdGhhdCB3b3VsZCBtYWtlIGFuIFJQQyBhbnkgZWFzaWVyIHRvIGltcGxlbWVudC4mbmJz cDsgVGhlIHNhbWUgY2hlY2tzIHN0aWxsIGhhdmUgdG8gYmUgbWFkZS4mbmJzcDsNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2h5IHdvdWxkIHRoZSBwcm9wb3Nl ZCBzb2x1dGlvbiBub3QgYWNjZXB0YWJsZT8mbmJzcDsgJm5ic3A7SWRlYWxseSBZQU5HIHdvdWxk IHByb3ZpZGUgYmV0dGVyIHN1cHBvcnQgdG8gZm9ybWFsbHkgZGVmaW5lIGFwcGxpY2F0aW9uL1JQ Qy1zcGVjaWZpYyByZXR1cm4gY29kZXMgYW5kIGNvcm5lcg0KIGNvbmRpdGlvbnMgZXRjLiBTaG9y dCBvZiB0aGF0LCB0aGUgcHJvcG9zZWQgc29sdXRpb24gb2YgYWRkaW5nIFJQQyBvdXRwdXQgcGFy YW1ldGVycyB0aGF0IGFyZSB1c2VkIGZvciB0aGUgcHVycG9zZSBvZiBpbmRpY2F0aW5nIHdoYXQg aXMgZ29pbmcgb24gYXQgdGhlIGFwcGxpY2F0aW9uIGxldmVsIHNpbXBseSBtYWtlcyB0aGVtIHBh cnQgb2YgdGhlIHNlbWFudGljcyBvZiB0aGUgc3BlY2lmaWMgUlBDIGl0c2VsZi4mbmJzcDsgSXQg aXMgbm90IE5ldGNvbmbigJlzDQogcm9sZSB0byBkZWZpbmUgd2hhdCBhbiBSUEMgY2FuIG9yIGNh bm5vdCBkbywganVzdCBsaWtlIGl0IGNhbm5vdCBkZWZpbmUgd2hhdCBhIHBhcnRpY3VsYXIgbGVh ZiBtYXkgb3IgbWF5IG5vdCByZXByZXNlbnQuJm5ic3A7IFRoYXQgaXMgcGFydCBvZiB0aGUgUlBD IGRlZmluaXRpb24uJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkJhc2ljYWxseSwgd2hhdCB3ZSBhcmUgZGlzY3Vzc2luZyBoZXJlIGlzIGJlaGF2aW9y IG9mIHN1YnNjcmlwdGlvbiBjb25maWd1cmF0aW9uIHVuZGVyIGNvcm5lciBjb25kaXRpb25zLiZu YnNwOyBUaGUgZmFjdCB0aGF0IG5vIHN1YnNjcmlwdGlvbiBpcyBjcmVhdGVkIGJlY2F1c2UgaXQN CiB3b3VsZCByZXN1bHQgaW4gYW4gdW5hY2NlcHRhYmxlIHZvbHVtZSBvZiB1cGRhdGVzIGZvciBh IHNwZWNpZmljIGltcGxlbWVudGF0aW9uIGlzIGRpZmZlcmVudCBmcm9tIGFuIGVycm9yIGNvbmRp dGlvbiBzdWNoIGFzIGEgbWFsZm9ybWVkIG1lc3NhZ2UgdGhhdCBpcyBtaXNzaW5nIGEgcmVxdWly ZWQgbWVzc2FnZS1pZCwgb3Igd2hlcmUgYSB2YWx1ZSB2aW9sYXRlcyBhIGNvbnN0cmFpbnQgc3Bl Y2lmaWVkIGluIGEgTVVTVC1jb25kaXRpb24uICZuYnNwO0luDQogb3VyIGNhc2UsIHdoYXQgaXMg YmVpbmcgZGVzY3JpYmVkIGFyZSBzcGVjaWZpYyBjb25kaXRpb25zIGF0IHRoZSBhcHBsaWNhdGlv biBsYXllciwgYWJvdmUgdGhlIE5ldGNvbmYvUmVzdGNvbmYgZ2VuZXJpYyB2YWxpZGF0aW9uIGlu ZnJhc3RydWN0dXJlLiZuYnNwOyAmbmJzcDtUaGUgb3BlcmF0aW9uIGRvZXMgbm90IOKAnHdvcmvi gJ0gaW4gdGhlIHNlbnNlIHRoYXQgaXQgZG9lcyBub3QgcmVzdWx0IGluIGFuIGFjdGl2ZSBzdWJz Y3JpcHRpb24sIGJ1dCBpdCBkb2VzIHdvcmsNCiBpbiB0aGUgc2Vuc2UgdGhhdCB0aGUgYmVoYXZp b3IgaXMgdmVyeSB3ZWxsIGRlZmluZWQgaW4gdGVybXMgb2YgdGhlIGVmZmVjdCB0aGF0IHRoZSBS UEMgaGFzIChpLmUuIHRoZSBlZmZlY3QgaXMgdGhhdCBpdCByZXN1bHQgaW4gY3JlYXRpb24gb2Yg YSBzdWJzY3JpcHRpb24sIGlmIGNlcnRhaW4gY29uZGl0aW9ucyBhcmUgbWV0LCBhbmQgaXQgZG9l cyBub3QgcmVzdWx0IGluIGNyZWF0aW9uIG9mIGEgc3Vic2NyaXB0aW9uIGluIGNhc2UgY2VydGFp bg0KIGNvbmRpdGlvbnMgYXJlIG5vdCBtZXQpLiZuYnNwOyBXaHkgc2hvdWxkIE5ldGNvbmYgcmVz dHJpY3Qgd2hhdCBhbiBSUEMgY2FuIG9yIGNhbm5vdCBkbz8mbmJzcDsgVGhpcyBpcyBhbGwgYXBw bGljYXRpb24tc3BlY2lmaWMuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPi0tLSBBbGV4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkFuZHkgQmllcm1hbjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIERlY2VtYmVyIDA0 LCAyMDE3IDk6MTUgQU08YnI+DQo8Yj5Ubzo8L2I+IE1hcnRpbiBCam9ya2x1bmQgJmx0O21iakB0 YWlsLWYuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTmV0Y29uZiAmbHQ7bmV0Y29uZkBpZXRmLm9y ZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtOZXRjb25mXSB5YW5nLXB1c2ggaXNzdWU6 IGVycm9yIGhhbmRsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIE1vbiwgRGVjIDQsIDIwMTcgYXQgNDo1NSBBTSwgTWFydGluIEJqb3JrbHVuZCAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWJqQHRhaWwtZi5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkFuZHkgQmllcm1hbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSI+YW5keUB5dW1hd29ya3MuY29tPC9h PiZndDsgd3JvdGU6PGJyPg0KJmd0OyBIaSw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJTU8gdGhlIHNw ZWNpYWwgZXJyb3IgaGFuZGxpbmcgaW4gWUFORyBQdXNoIGlzIG5vdCBhY2NlcHRhYmxlPGJyPg0K Jmd0OyBiZWNhdXNlIGl0IHZpb2xhdGVzIE5FVENPTkYgYW5kIFJFU1RDT05GIGVycm9yIGhhbmRs aW5nIHByb2NlZHVyZXMuPGJyPg0KJmd0OyBORVRDT05GIHNheXMgaWYgdGhlIG9wZXJhdGlvbiBk b2VzIG5vdCB3b3JrIGZvciBhbnkgcmVhc29uIGFuICZsdDtycGMtZXJyb3ImZ3Q7PGJyPg0KJmd0 OyBlbGVtZW50IFNIT1VMRCBiZSByZXR1cm5lZC48YnI+DQo8YnI+DQpJIGZ1bGx5IGFncmVlLCBh bmQgSSBoYXZlIHBvaW50ZWQgdGhpcyBvdXQgc2V2ZXJhbCB0aW1lcyBpbiBteTxicj4NCnJldmll d3MuJm5ic3A7IFRoZSBwcm9ibGVtIGlzIGFjdHVhbGx5IGluIHN1YnNjcmliZWQgbm90aWZpY2F0 aW9ucywgYW5kIEk8YnI+DQp0aGluayBFcmljIGlzIHRyYWNraW5nIHRoYXQgaXNzdWUuPGJyPg0K PGJyPg0KVHJ5aW5nIHRvIGJlIGNvbnN0cnVjdGl2ZSwgSSB0aGluayB0aGF0IHRoZSBleGlzdGlu ZyBtZWNoYW5pc21zIGluPGJyPg0KWUFORyBjYW4gYmUgdXNlZCB0byBhY2hpZXZlIHRoZSBzYW1l IGZ1bmN0aW9uYWxpdHkgdGhhdCB0aGVzZSBkcmFmdHM8YnI+DQp0cnkgdG8gYWNoaWV2ZS4mbmJz cDsgU3BlY2lmaWNhbGx5Ojxicj4NCjxicj4NCiZuYnNwOyAxLiBVc2UgaWRlbnRpdGllcyBqdXN0 IGxpa2UgdGhlIG9uZXMgeW91IGhhdmU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOygmcXVvdDt1 bnN1cHBvcnRhYmxlLXZvbHVtZSZxdW90OywgJnF1b3Q7ZmlsdGVyLXVuYXZhaWxhYmxlJnF1b3Q7 IGV0YyksIGJ1dCBhZGQgdGV4dDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7dGhhdCBleHBsYWlu cyB0aGF0IHRoZXNlIGlkZW50aXRpZXMgYXJlIHNlbnQgYXMgJnF1b3Q7ZXJyb3ItYXBwLXRhZyZx dW90Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7aW4gJnF1b3Q7cnBjLWVycm9yJnF1b3Q7LCBl bmNvZGVkIHRvIGEgc3RyaW5nIGFzICZsdDttb2R1bGUmZ3Q7OiZsdDtpZGVudGl0eSZndDsuJm5i c3A7IFRoaXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO3dvcmtzIGZvciBib3RoIE5FVENPTkYg YW5kIFJFU1RDT05GLjxicj4NCjxicj4NCiZuYnNwOyAyLiBGb3IgdGhlICZxdW90O2hpbnRzJnF1 b3Q7IGV4dHJhIGluZm8gdGhhdCB5b3UgcmV0dXJuLCBkZWZpbmUgYSAmcXVvdDt5YW5nLWRhdGEm cXVvdDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO3N0cnVjdHVyZSB3aXRoIHRoZSBoaW50cywg YW5kIGV4cGxhaW4gaW4gdGV4dCB0aGF0IHRoaXMgc3RydWN0dXJlPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDtpcyByZXR1cm5lZCBpbiAmcXVvdDtlcnJvci1pbmZvJnF1b3Q7LiZuYnNwOyBUaGlz IHdvcmtzIGZvciBib3RoIE5FVENPTkYgYW5kPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtSRVNU Q09ORi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+JiM0MzsxPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPklmIHRoZSBlcnJvciBoYW5kbGluZyB3YXMgZG9uZSBjb3JyZWN0bHkg dGhlbiB0aGUgc2FtZSBwcm9jZWR1cmVzIGNvdWxkIGJlPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hcHBsaWVkIHRvICZsdDtlZGl0LWNvbmZpZyZn dDsgZmFpbHVyZXMgZm9yIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkFzIGFuIGFsdGVybmF0aXZlIHRvIDEsIHlvdSBjYW4g cHV0IHRoZSBlcnJvciBpZGVudGl0aXlyZWYgaW4gdGhlPGJyPg0KJnF1b3Q7eWFuZy1kYXRhJnF1 b3Q7IHN0cnVjdHVyZSwgYW5kIHNlbmQgYm90aCB0aGUgaWRlbnRpdGl5cmVmIGFuZCBoaW50cyBp bjxicj4NCiZxdW90O2Vycm9yLWluZm8mcXVvdDsuPGJyPg0KPGJyPg0KPGJyPg0KL21hcnRpbjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCiZndDsgVGhlICZsdDtlc3RhYmxpc2gtc3Vi c2NyaXB0aW9uJmd0OyByZXR1cm5zIGRhdGEgZXZlbiBvbiBlcnJvci48YnI+DQomZ3Q7IEluc3Rl YWQgb2YgdGhlIGNvbW1vbiBlcnJvci10YWcsIGVycm9yLWluZm8sIGFuZCBvdGhlciBmaWVsZHMs PGJyPg0KJmd0OyB0aGVyZSBpcyBhIHN1YnNjcmlwdGlvbi1yZXN1bHQgbGVhZi48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBJZiBhbnkgY2xpZW50IChvciBldmVuIHNlcnZlcikgZnVuY3Rpb25hbGl0eSB1 c2VzIHRoZSBORVRDT05GIGFuZDxicj4NCiZndDsgUkVTVENPTkYgc3RhbmRhcmQgZXJyb3IgaGFu ZGxpbmcsIHRoZW4gc3Vic2NyaXB0aW9uLXJlc3VsdCB3aWxsIG5vdCBiZTxicj4NCiZndDsgc2Vu dCBvciBleHBlY3RlZCBhcyBhbiBlcnJvciByZXNwb25zZS4gRGVwZW5kaW5nIG9uIHRoZSBzZXJ2 ZXI8YnI+DQomZ3Q7IGltcGxlbWVudGF0aW9uLCB0aGUgY29kZSB0aGF0IGtub3dzIGFib3V0IGVz dGFibGlzaC1zdWJzY3JpcHRpb248YnI+DQomZ3Q7IG1heSBub3QgZ2V0IGNhbGxlZCBiZWNhdXNl IGNvbW1vbiBlcnJvciBoYW5kbGluZyBjb2RlIGhhczxicj4NCiZndDsgYWxyZWFkeSBkZXRlcm1p bmVkIHRoZXJlIGlzIGFuICZsdDtycGMtZXJyb3ImZ3Q7IHRvIHNlbmQgaW5zdGVhZCBvZiBhIGRh dGE8YnI+DQomZ3Q7IHJlc3BvbnNlLjxicj4NCiZndDs8YnI+DQomZ3Q7IEV4cGVjdCB0aGF0IHNv bWUgc2VydmVycyBhcmUgbmV2ZXIgZ29pbmcgdG8gc2VuZCBkYXRhIG9uIGFuIG9wZXJhdGlvbjxi cj4NCiZndDsgZmFpbHVyZSwgYW5kIHdpbGwgb25seSBzZW5kICZsdDtycGMtZXJyb3ImZ3Q7IGlu c3RlYWQuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDtGcm9tIHNlYy4gMy44Ojxi cj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBGb3IgaW5zdGFuY2UsIGZvciB0aGUgZm9s bG93aW5nIHJlcXVlc3Q6PGJyPg0KJmd0Ozxicj4NCiZndDsgJmx0O25ldGNvbmY6cnBjIG1lc3Nh Z2UtaWQ9JnF1b3Q7MTAxJnF1b3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgeG1sbnM6bmV0Y29u Zj0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAmcXVvdDsmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJmx0O2VzdGFibGlzaC1zdWJzY3JpcHRpb248YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHhtbG5zPSZxdW90O3VybjppZXRmOnBhcmFt czp4bWw6bnM6eWFuZzppZXRmLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyZxdW90Ozxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgeG1sbnM6eXA9JnF1b3Q7dXJuOmlldGY6cGFy YW1zOnhtbDpuczp5YW5nOmlldGYteWFuZy1wdXNoJnF1b3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7eXA6ZGF0YXN0b3JlJmd0Ozxicj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3lwOnNvdXJjZSB4bWxucz0mcXVvdDt1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1kYXRhc3RvcmVzJnF1b3Q7Jmd0Ozxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29wZXJhdGlvbmFsPGJy Pg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7L3lwOnNvdXJjZSZn dDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDt5cDpzdWJ0 cmVlLWZpbHRlciBuZXRjb25mOnR5cGU9JnF1b3Q7eHBhdGgmcXVvdDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7eG1sbnM6ZXg9JnF1b3Q7 PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tL3NhbXBsZS1kYXRhLzEuMCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHA6Ly9leGFtcGxlLmNvbS9zYW1wbGUtZGF0YS8xLjA8L2E+JnF1b3Q7PGJyPg0KJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NlbGVjdD0m cXVvdDsvZXg6Zm9vJnF1b3Q7LyZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7Jmx0Oy95cDpkYXRhc3RvcmUmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZsdDt5cDpwZXJpb2QmZ3Q7NTAwJmx0Oy95cDpwZXJpb2QmZ3Q7PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJmx0Oy9lc3RhYmxpc2gtc3Vic2NyaXB0aW9uJmd0Ozxicj4NCiZndDsgJmx0Oy9u ZXRjb25mOnJwYyZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpZ3VyZSAzOiBFc3RhYmxp c2gtU3Vic2NyaXB0aW9uIGV4YW1wbGU8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsg dGhlIHB1Ymxpc2hlciBtaWdodCByZXR1cm46PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 ICZsdDtycGMtcmVwbHkgbWVzc2FnZS1pZD0mcXVvdDsxMDEmcXVvdDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgeG1sbnM9JnF1b3Q7dXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25m OmJhc2U6MS4wJnF1b3Q7Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZsdDtzdWJzY3JpcHRp b24tcmVzdWx0PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB4bWxucz0mcXVv dDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlv bnMmcXVvdDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHhtbG5zOnlwPSZx dW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLXlhbmctcHVzaCZxdW90OyZndDs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgeXA6cGVyaW9kLXVuc3VwcG9ydGVkPGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJmx0Oy9zdWJzY3JpcHRpb24tcmVzdWx0Jmd0Ozxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZsdDtwZXJpb2QtaGludCB4bWxuczomcXVvdDt1cm46aWV0ZjpwYXJhbXM6 eG1sOm5zOnlhbmc6aWV0Zi15YW5nLXB1c2gmcXVvdDsmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzIwMDA8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbHQ7L3BlcmlvZC1o aW50Jmd0Ozxicj4NCiZndDsgJmx0Oy9ycGMtcmVwbHkmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IEZpZ3VyZSA0OiBFcnJvciByZXNwb25zZSBleGFtcGxlPGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBCVFcsIGFsbCB0aGUgZmlsdGVyIGV4 YW1wbGVzIHNlZW0gdG8gYmUgd3JvbmcsIGluY2x1ZGluZyB0aGUgb25lIGFib3ZlPGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE9MRDo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7eXA6c3VidHJlZS1maWx0ZXIgbmV0Y29uZjp0eXBl PSZxdW90O3hwYXRoJnF1b3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO3htbG5zOmV4PSZxdW90OzxhIGhyZWY9Imh0dHA6Ly9leGFtcGxl LmNvbS9zYW1wbGUtZGF0YS8xLjAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZXhhbXBsZS5jb20v c2FtcGxlLWRhdGEvMS4wPC9hPiZxdW90Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZWxlY3Q9JnF1b3Q7L2V4OmZvbyZxdW90Oy8mZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IE5FVzo8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3lwOnN1YnRyZWUt ZmlsdGVyJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbHQ7ZXg6Zm9vIHhtbG5zOmV4PSZxdW90OzxhIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNv bS9zYW1wbGUtZGF0YS8xLjAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZXhhbXBsZS5jb20vc2Ft cGxlLWRhdGEvMS4wPC9hPiZxdW90OyAvJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsveXA6c3VidHJlZS1maWx0ZXImZ3Q7PGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD10E9sjceml521mbxchi_-- From nobody Tue Dec 5 12:11: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 C24101270AC for ; Tue, 5 Dec 2017 12:11:03 -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 LLlDshyN2d4s for ; Tue, 5 Dec 2017 12:11:00 -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 B92701270B4 for ; Tue, 5 Dec 2017 12:10:59 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id 74so1743083lfs.0 for ; Tue, 05 Dec 2017 12:10:59 -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=i+Hhaf7s8NmChN/maj15E3ihBvVRkN7BbL6Eu8Sn83w=; b=ykAUNTtJZh11GZ1974FXwKuhzsYGPLIPtlDzr/5p2ltDRONtuAjNk73xFAMa4/y+1r ONfJB5yN2KAB717PPabgISu9nylbApzrwDCSM0wcEBwNzW26SrzU8OeFGhy2uFlNWC50 76uDjdBMCCkuOSWESSsGNWvDGtgeaQmsCvhhCxBmItCb+0PmB6vOojYF1ci8yLn4FpBk 1VA4b4lGZ/dP/20OLx6CISJXb3gCqNQbV7reRU6W5eLCt34rU2TvCnqxmV7zWR7hCOKw pA71Fqbb6xBlGZtS+s5G+7CTdTN9ylpi2HBovDV1mnd8DHLw5SEJl0HS/ZmRFBGk9tT9 c7yA== 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=i+Hhaf7s8NmChN/maj15E3ihBvVRkN7BbL6Eu8Sn83w=; b=MjdCwmGkEREyVy9j4MOTns01AnVxYZdiBcr6j5TDTW12boSTm8RnlnEMyIpqnLywcA gaTDiRU7PkNEK8byknuYOpZte9MLiXQ4ssN56ZkxgQTSbz6aMAgQO9PbCxLSpBrb8Nzb 2n2HwyI34/Woc5fi2lUIODxKW7dTf7skALZEaPhXE0EgHYRz5tf/s/u9CbfGUkO0Wc0m Cm1oGFdwQ9BZM1hO7PXKe0TYjbJftfBeVTd8jxV7SxjlvKO9PjGgwm/z5mVugFyRTkHS P2ivBHYAJaCIIfrXq3dxDKOWH605iADkJlwEOHh7vHiOwyjKy3FoS0zng5IU2N117ADZ dLTA== X-Gm-Message-State: AJaThX7zPs32HwEF3Lg5a2SK59+p9w7NVvj2SlmUBn3jZfpgUYf//dYG 2YBAqovfoI1yuKMbBywUgyYPMVwFEkPJ01cOXf+8Wg== X-Google-Smtp-Source: AGs4zMa/GfoF4XJ7KXQl5hfYFYJ5zIZTVn9UGhWZrWYyYI5LUs12RlnogqskCULSrO6evPXAdnhg6JdR0XGkMXhhQGI= X-Received: by 10.25.147.23 with SMTP id v23mr9408482lfd.120.1512504657995; Tue, 05 Dec 2017 12:10:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Tue, 5 Dec 2017 12:10:57 -0800 (PST) In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD10E9@sjceml521-mbx.china.huawei.com> References: <20171204.135539.1530792967351325058.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD10E9@sjceml521-mbx.china.huawei.com> From: Andy Bierman Date: Tue, 5 Dec 2017 12:10:57 -0800 Message-ID: To: Alexander Clemm Cc: Martin Bjorklund , Netconf Content-Type: multipart/alternative; boundary="f403045ce2d6dcf385055f9d6e40" Archived-At: Subject: Re: [Netconf] yang-push issue: error handling 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, 05 Dec 2017 20:11:04 -0000 --f403045ce2d6dcf385055f9d6e40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, The protocol defines how error handling is done, not the individual operations. If the request fails, then clients expect an and servers are designed to send an when a client request fails. IMO, a separate error handling procedure for each RPC is more clunky than error-info. Andy On Tue, Dec 5, 2017 at 12:03 PM, Alexander Clemm wrote: > Hi, > > > > While possible, the solution of having to return rpc-error etc does strik= e > me as somewhat clunky. While it is possible to add an error-app-tag, and > negotiation stuff as error-info (and I appreciate the suggestion), that > solution would need to be described using a lot of prose in description > statements a la SMIv2 (presumably as part of the RPC description, not as > part of e.g. the identities, which might be used in a number of places, n= ot > just the error-app-tag). I am not sure why that would make an RPC any > easier to implement. The same checks still have to be made. > > > > Why would the proposed solution not acceptable? Ideally YANG would > provide better support to formally define application/RPC-specific return > codes and corner conditions etc. Short of that, the proposed solution of > adding RPC output parameters that are used for the purpose of indicating > what is going on at the application level simply makes them part of the > semantics of the specific RPC itself. It is not Netconf=E2=80=99s role t= o define > what an RPC can or cannot do, just like it cannot define what a particula= r > leaf may or may not represent. That is part of the RPC definition. > > > > Basically, what we are discussing here is behavior of subscription > configuration under corner conditions. The fact that no subscription is > created because it would result in an unacceptable volume of updates for = a > specific implementation is different from an error condition such as a > malformed message that is missing a required message-id, or where a value > violates a constraint specified in a MUST-condition. In our case, what i= s > being described are specific conditions at the application layer, above t= he > Netconf/Restconf generic validation infrastructure. The operation does > not =E2=80=9Cwork=E2=80=9D in the sense that it does not result in an act= ive subscription, > but it does work in the sense that the behavior is very well defined in > terms of the effect that the RPC has (i.e. the effect is that it result i= n > creation of a subscription, if certain conditions are met, and it does no= t > result in creation of a subscription in case certain conditions are not > met). Why should Netconf restrict what an RPC can or cannot do? This is > all application-specific. > > > > --- Alex > > > > > > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy > Bierman > *Sent:* Monday, December 04, 2017 9:15 AM > *To:* Martin Bjorklund > *Cc:* Netconf > *Subject:* Re: [Netconf] yang-push issue: error handling > > > > > > > > On Mon, Dec 4, 2017 at 4:55 AM, Martin Bjorklund wrote: > > Andy Bierman wrote: > > Hi, > > > > IMO the special error handling in YANG Push is not acceptable > > because it violates NETCONF and RESTCONF error handling procedures. > > NETCONF says if the operation does not work for any reason an > > element SHOULD be returned. > > I fully agree, and I have pointed this out several times in my > reviews. The problem is actually in subscribed notifications, and I > think Eric is tracking that issue. > > Trying to be constructive, I think that the existing mechanisms in > YANG can be used to achieve the same functionality that these drafts > try to achieve. Specifically: > > 1. Use identities just like the ones you have > ("unsupportable-volume", "filter-unavailable" etc), but add text > that explains that these identities are sent as "error-app-tag" > in "rpc-error", encoded to a string as :. This > works for both NETCONF and RESTCONF. > > 2. For the "hints" extra info that you return, define a "yang-data" > structure with the hints, and explain in text that this structure > is returned in "error-info". This works for both NETCONF and > RESTCONF. > > > > > > +1 > > > > If the error handling was done correctly then the same procedures could b= e > > applied to failures for configured subscriptions. > > > > > > > As an alternative to 1, you can put the error identitiyref in the > "yang-data" structure, and send both the identitiyref and hints in > "error-info". > > > /martin > > > > > > Andy > > > > > > > > The returns data even on error. > > Instead of the common error-tag, error-info, and other fields, > > there is a subscription-result leaf. > > > > If any client (or even server) functionality uses the NETCONF and > > RESTCONF standard error handling, then subscription-result will not be > > sent or expected as an error response. Depending on the server > > implementation, the code that knows about establish-subscription > > may not get called because common error handling code has > > already determined there is an to send instead of a data > > response. > > > > Expect that some servers are never going to send data on an operation > > failure, and will only send instead. > > > > > > >From sec. 3.8: > > > > For instance, for the following request: > > > > > xmlns:netconf=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed-notificatio= ns" > > xmlns:yp=3D"urn:ietf:params:xml:ns:yang:ietf-yang-push"> > > > > > > operational > > > > > xmlns:ex=3D"http://example.com/sample-data/1.0" > > select=3D"/ex:foo"/> > > > > 500 > > > > > > > > Figure 3: Establish-Subscription example > > > > the publisher might return: > > > > > > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed-notificatio= ns" > > xmlns:yp=3D"urn:ietf:params:xml:ns:yang:ietf-yang-push"> > > yp:period-unsupported > > > > > > 2000 > > > > > > > > Figure 4: Error response example > > > > > > > > BTW, all the filter examples seem to be wrong, including the one above > > > > > > OLD: > > > > > xmlns:ex=3D"http://example.com/sample-data/1.0" > > select=3D"/ex:foo"/> > > > > > > NEW: > > > > > > > > > > > > > > > > > > Andy > > > --f403045ce2d6dcf385055f9d6e40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The protocol defines how error hand= ling is done, not the individual operations.
If the request fails= , then clients expect an <rpc-error> and servers are designed
to send an <rpc-error> when a client request fails.

=
IMO, a separate error handling procedure for each RPC is more cl= unky than error-info.

Andy


On Tue, Dec 5,= 2017 at 12:03 PM, Alexander Clemm <alexander.clemm@huawei.com> wrote:

Hi,

=C2=A0

While possible, the solution of havin= g to return rpc-error etc does strike me as somewhat clunky.=C2=A0 While it= is possible to add an error-app-tag, and negotiation stuff as error-info (and I appreciate the suggestion), that solution would= need to be described using a lot of prose in description statements a la S= MIv2 (presumably as part of the RPC description, not as part of e.g. the id= entities, which might be used in a number of places, not just the error-app-tag).=C2=A0 =C2=A0I am not sure= why that would make an RPC any easier to implement.=C2=A0 The same checks = still have to be made.=C2=A0

=C2=A0

Why would the proposed solution not a= cceptable?=C2=A0 =C2=A0Ideally YANG would provide better support to formall= y define application/RPC-specific return codes and corner conditions etc. Short of that, the proposed solution of adding RPC output = parameters that are used for the purpose of indicating what is going on at = the application level simply makes them part of the semantics of the specif= ic RPC itself.=C2=A0 It is not Netconf=E2=80=99s role to define what an RPC can or cannot do, just like it cannot define wh= at a particular leaf may or may not represent.=C2=A0 That is part of the RP= C definition.=C2=A0

=C2=A0

Basically, what we are discussing her= e is behavior of subscription configuration under corner conditions.=C2=A0 = The fact that no subscription is created because it would result in an unacceptable volume of updates for a specific implement= ation is different from an error condition such as a malformed message that= is missing a required message-id, or where a value violates a constraint s= pecified in a MUST-condition.=C2=A0 In our case, what is being described are specific conditions at the applicati= on layer, above the Netconf/Restconf generic validation infrastructure.=C2= =A0 =C2=A0The operation does not =E2=80=9Cwork=E2=80=9D in the sense that i= t does not result in an active subscription, but it does work in the sense that the behavior is very well defined in terms of the effect= that the RPC has (i.e. the effect is that it result in creation of a subsc= ription, if certain conditions are met, and it does not result in creation = of a subscription in case certain conditions are not met).=C2=A0 Why should Netconf restrict what an RPC can= or cannot do?=C2=A0 This is all application-specific.=C2=A0

=C2=A0

--- Alex

=C2=A0

=C2=A0

From: Netconf [mailto:netconf-bounces@ietf.o= rg] On Behalf Of Andy Bierman
Sent: Monday, December 04, 2017 9:15 AM
To: Martin Bjorklund <mbj@tail-f.com>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] yang-push issue: error handling=

=C2=A0

=C2=A0

=C2=A0

On Mon, Dec 4, 2017 at 4:55 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:

Andy Bierman <andy@yumaworks.com&= gt; wrote:
> Hi,
>
> IMO the special error handling in YANG Push is not acceptable
> because it violates NETCONF and RESTCONF error handling procedures. > NETCONF says if the operation does not work for any reason an <rpc-= error>
> element SHOULD be returned.

I fully agree, and I have pointed this out several times in my
reviews.=C2=A0 The problem is actually in subscribed notifications, and I think Eric is tracking that issue.

Trying to be constructive, I think that the existing mechanisms in
YANG can be used to achieve the same functionality that these drafts
try to achieve.=C2=A0 Specifically:

=C2=A0 1. Use identities just like the ones you have
=C2=A0 =C2=A0 =C2=A0("unsupportable-volume", "filter-unavail= able" etc), but add text
=C2=A0 =C2=A0 =C2=A0that explains that these identities are sent as "e= rror-app-tag"
=C2=A0 =C2=A0 =C2=A0in "rpc-error", encoded to a string as <mo= dule>:<identity>.=C2=A0 This
=C2=A0 =C2=A0 =C2=A0works for both NETCONF and RESTCONF.

=C2=A0 2. For the "hints" extra info that you return, define a &q= uot;yang-data"
=C2=A0 =C2=A0 =C2=A0structure with the hints, and explain in text that this= structure
=C2=A0 =C2=A0 =C2=A0is returned in "error-info".=C2=A0 This works= for both NETCONF and
=C2=A0 =C2=A0 =C2=A0RESTCONF.

=C2=A0

=C2=A0

+1

=C2=A0

If the error handling was done correctly then the sa= me procedures could be

applied to <edit-config> failures for configur= ed subscriptions.

=C2=A0

=C2=A0


As an alternative to 1, you can put the error identitiyref in the
"yang-data" structure, and send both the identitiyref and hints i= n
"error-info".


/martin

=C2=A0

=C2=A0

Andy

=C2=A0




> The <establish-subscription> returns data even on error.
> Instead of the common error-tag, error-info, and other fields,
> there is a subscription-result leaf.
>
> If any client (or even server) functionality uses the NETCONF and
> RESTCONF standard error handling, then subscription-result will not be=
> sent or expected as an error response. Depending on the server
> implementation, the code that knows about establish-subscription
> may not get called because common error handling code has
> already determined there is an <rpc-error> to send instead of a = data
> response.
>
> Expect that some servers are never going to send data on an operation<= br> > failure, and will only send <rpc-error> instead.
>
>
> >From sec. 3.8:
>
>=C2=A0 =C2=A0 For instance, for the following request:
>
> <netconf:rpc message-id=3D"101"
>=C2=A0 =C2=A0 xmlns:netconf=3D"urn:ietf:params:xml:ns:netconf= :base:1.0">
>=C2=A0 =C2=A0 <establish-subscription
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:y= ang:ietf-subscribed-notifications"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:yp=3D"urn:ietf:params:xml:n= s:yang:ietf-yang-push">
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:datastore>
>=C2=A0 =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 =C2=A0operational
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</yp:source>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:subtree-filter netconf:type=3D= "xpath"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns:ex=3D"http://example.c= om/sample-data/1.0"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0select=3D"/ex:foo&= quot;/>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0</yp:datastore>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:period>500</yp:period>
>=C2=A0 =C2=A0 </establish-subscription>
> </netconf:rpc>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 3= : Establish-Subscription example
>
>=C2=A0 =C2=A0 the publisher might return:
>
>
> <rpc-reply message-id=3D"101"
>=C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:= base:1.0">
>=C2=A0 =C2=A0 <subscription-result
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:y= ang:ietf-subscribed-notifications"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:yp=3D"urn:ietf:params:xml:n= s:yang:ietf-yang-push">
>=C2=A0 =C2=A0 =C2=A0 yp:period-unsupported
>=C2=A0 =C2=A0 </subscription-result>
>=C2=A0 =C2=A0 <period-hint xmlns:"urn:ietf:params:xml:ns:y= ang:ietf-yang-push">
>=C2=A0 =C2=A0 =C2=A0 =C2=A02000
>=C2=A0 =C2=A0 </period-hint>
> </rpc-reply>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Figure 4: Error response example
>
>
>
> BTW, all the filter examples seem to be wrong, including the one above=
>
>
> OLD:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:subtree-filter netconf:type=3D= "xpath"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns:ex=3D"http://example.c= om/sample-data/1.0"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0select=3D"/ex:foo&= quot;/>
>
>
> NEW:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:subtree-filter>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <ex:foo xmlns:ex=3D"<= a href=3D"http://example.com/sample-data/1.0" target=3D"_blank">http://exam= ple.com/sample-data/1.0" />
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</yp:subtree-filter>
>
>
> Andy

=C2=A0


--f403045ce2d6dcf385055f9d6e40-- From nobody Tue Dec 5 12:17: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 98F6E127978 for ; Tue, 5 Dec 2017 12:17:55 -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 VNYmX6CxgZGa for ; Tue, 5 Dec 2017 12:17:53 -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 B75AA127869 for ; Tue, 5 Dec 2017 12:17:52 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 759F178FADCC1; Tue, 5 Dec 2017 20:17:49 +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; Tue, 5 Dec 2017 20:17:50 +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; Tue, 5 Dec 2017 12:17:43 -0800 From: Alexander Clemm To: Balazs Lengyel , Andy Bierman , Martin Bjorklund CC: Netconf Thread-Topic: [Netconf] "notifiable-on-change" [was: Re: review of draft-ietf-netconf-yang-push-11] Thread-Index: AQHTbd3q49pLFjQIXkuyeuDLPwg6q6M1LOzg Date: Tue, 5 Dec 2017 20:17:43 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1119@sjceml521-mbx.china.huawei.com> References: <20171128.103735.1654378548309425095.mbj@tail-f.com> <81f49c62-e1fe-4a90-a93f-c7fd55229100@ericsson.com> In-Reply-To: <81f49c62-e1fe-4a90-a93f-c7fd55229100@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.209.216.169] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1119sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Netconf] "notifiable-on-change" [was: Re: 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, 05 Dec 2017 20:17:55 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1119sjceml521mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgcHJlZmVyZW5jZSBpcyB0byBrZWVwIHRoZSBzb2x1dGlvbiBhcy1pcywgcGVyIHRoZSBjdXJy ZW50IHNvbHV0aW9uIHdpdGggdGhlIGV4dGVuc2lvbiB3ZSBoYXZlIGRlZmluZWQuDQoNClRoYXQg c2FpZCwgSSBoYXZlIHR3byBjb21tZW50cyByZWxhdGVkIHRvIGhvdyB3ZSBjYW4gZ2V0IGNsb3N1 cmU/DQoNCg0KLSAgICAgICAgICBJZiB3ZSBjYW5ub3QgZ2V0IGFncmVlbWVudCBvbiB0aGlzLCBJ IHdvdWxkIG5vdCB3YW50IHRvIGRlbGF5IFlBTkctUHVzaCBvdmVyIGl0IChsaWtlIE1hcnRpbiBo YXMgaW5kaWNhdGVkIGFzIHdlbGwpLiBJbiB0aGF0IGNhc2UsIEkgd291bGQgc3VnZ2VzdCB3ZSBh ZGQgYW4gaW5mb3JtYXRpb25hbCBzZWN0aW9uIHRoYXQgZXhwbGFpbnMgdGhlIGlzc3VlLCBhbmQg b3V0bGluZXMgd2hhdCBhIChwcm9wcmlldGFyeSkgc29sdXRpb24gbWlnaHQgbG9vayBsaWtlLiAg T2YgY291cnNlLCB1bmZvcnR1bmF0ZWx5IHRoaXMgd2lsbCBkZS1mYWN0byBtZWFuIHZlbmRvci1w cm9wcmlldGFyeSBzb2x1dGlvbnMgYXQgdGhpcyBwb2ludCBhcyB0aGlzIGFzcGVjdCB3aWxsIG5l ZWQgdG8gYmUgYWRkcmVzc2VkIOKAkyBJIHdvdWxkIGZ1bGx5IGV4cGVjdCB0aGF0IEVyaWNzc29u IGluIHRoYXQgY2FzZSB3aWxsIGRlZmluZSB0aGUgc2FtZSBzb2x1dGlvbiBhcyBhbiBFcmljc3Nv bi1wcm9wcmlldGFyeSBtb2R1bGUgd2l0aCBhbiBFcmljc3Nvbi1wcm9wcmlldGFyeSBleHRlbnNp b24gKGFzIG9wcG9zZWQgdG8gaGF2ZSBhIHN0YW5kYXJkIHNvbHV0aW9uKS4NCg0KLSAgICAgICAg ICBJIGRvIHRoaW5rIHRoZXJlIGlzIG1lcml0IHRvIGFsc28gaW5jbHVkZSB0aGUgaW5mb3JtYXRp b24gb2Ygd2hhdCBpcyBub3RpZmlhYmxlIGFzIHBhcnQgb2YgdGhlIFlBTkctbGlicmFyeS4gIFRo aXMgY291bGQgYmUgcGFydCBvZiB0aGUgcGVybWFuZW50IHNvbHV0aW9uIChhbHRob3VnaCBpdCBk b2VzIG5vdCBhZGRyZXNzIHRoZSBhc3BlY3Qgb2YgaG93IHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUg bGlicmFyeSB3b3VsZCBiZSBwb3B1bGF0ZWQsIEJhbGF6cyBwZXIgeW91ciBjb21tZW50KS4gVGhp cyBzcGVjaWZpYyBkaXNjdXNzaW9uIHNob3VsZCBwcm9iYWJseSBtb3ZlZCB0byB0aGUgWUFORy1s aWJyYXJ5IGRpc2N1c3Npb24sIG5vdCB0aGUgb25lIGhlcmUuDQoNCi0tLSBBbGV4DQoNCkZyb206 IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBC YWxhenMgTGVuZ3llbA0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDUsIDIwMTcgNzoyOCBBTQ0K VG86IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPjsgTWFydGluIEJqb3JrbHVuZCA8 bWJqQHRhaWwtZi5jb20+DQpDYzogTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZz4NClN1YmplY3Q6 IFtOZXRjb25mXSAibm90aWZpYWJsZS1vbi1jaGFuZ2UiIFt3YXM6IFJlOiByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0xMV0NCg0KDQpJIHZlcnkgc3Ryb25nbHkgb2JqZWN0 IHRvIGV4Y2x1ZGluZyB0aGUgaXNzdWUuICBUaGVyZSBpcyBhIHN0cm9uZyBhbmQgaW1tZWRpYXRl IG5lZWQgdG8gYmUgYWJsZSB0byBzcGVjaWZ5IGluIHZlbmRvciBkZXNpZ24gdGltZSBmb3Igd2hp Y2ggZGF0YSBub2RlcyB3aWxsIHRoZXJlIGJlIG9uLWNoYW5nZSBub3RpZmljYXRpb24gYmUgZ2Vu ZXJhdGVkLg0KDQpXaGVuIGEgdmVuZG9yIHJlbGVhc2UgYSBwcm9kdWN0IHRoZXkga25vdyB3aGlj aCBub2RlcyB3aWxsIGVtaXQgb24tY2hhbmdlIG5vdGlmaWNhdGlvbnMgaW4gZGVzaWduIHRpbWUu IFN5c3RlbSBpbnRlZ3JhdG9ycyBuZWVkIHRvIGtub3cgdGhpcy4gUHJvdmlkaW5nIHRoZSBzYW1l IGluZm9ybWF0aW9uIGluIHJ1bi10aW1lIGFzIGluc3RhbmNlIGRhdGEgaXMgbm90IGEgZ29vZCBz b2x1dGlvbiBlaXRoZXIgYXMgeW91IHdvdWxkIG5lZWQgdG8gZ2V0IGEgcmVhbCBub2RlIHRvIHJl YWQgdGhlIGRhdGEgZnJvbS4NCg0KSU1ITyBpZ25vcmluZyB0aGlzIG5lZWQgd291bGQganVzdCBm b3JjZSB0aGUgdmVuZG9ycyAoaW5jbHVkaW5nIGVyaWNzc29uKSB0byBjcmVhdGUgYW4gb3duIHNv bHV0aW9uLg0KDQpBbmR5IHdyb3RlOiAiSSBhZ3JlZSB0aGlzIGlzIGFuIGltcGxlbWVudGF0aW9u IHByb3BlcnR5LCBhbmQgbm90IGEgZGF0YSBtb2RlbCBwcm9wZXJ0eS4iDQoNCkkgYWx3YXlzIHRo b3VnaHQgdGhhdCBvbmUgb2YgdGhlIG1haW4gcHVycG9zZXMgb2YgWUFORyB3YXMgdG8gZG9jdW1l bnQgdmVuZG9yJ3MgaW1wbGVtZW50YXRpb24uIFRoYXQgaXMgZXhhY3RseSB3aGF0IGEgZGV2aWF0 aW9uIG9yICBmZWF0dXJlIGFsc28gZG9lcy4gVGhleSBhcmUgYm90aCBwYXJ0IG9mIFlBTkcuDQoN CnJlZ2FyZHMgQmFsYXpzDQoNCk9uIDIwMTctMTEtMjggMTg6MTAsIEFuZHkgQmllcm1hbiB3cm90 ZToNCg0KDQpPbiBUdWUsIE5vdiAyOCwgMjAxNyBhdCAxOjM3IEFNLCBNYXJ0aW4gQmpvcmtsdW5k IDxtYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+PiB3cm90ZToNCkhpLA0KDQoN CkkgaGF2ZSBub3cgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0xMS4gIEkg aGF2ZSBvbmUNCnNvbWV3aGF0IG1vcmUgaW1wb3J0YW50IGNvbW1lbnQsIGFuZCBzZXZlcmFsIG90 aGVycy4NCg0KSW1wb3J0YW50IGlzc3VlOg0KDQpvICAzLjEwDQoNCiAgSSBkb24ndCB0aGluayB0 aGUgcHJvcG9zZWQgWUFORyBleHRlbnNpb24gaXMgdGhlIGNvcnJlY3Qgc29sdXRpb24gdG8NCiAg dGhlIHN0YXRlZCBwcm9ibGVtLCBmb3Igc2V2ZXJhbCByZWFzb25zOg0KDQogICAgMS4gIEluIG1v c3QgY2FzZXMsIHRoaXMgaXMgbm90IGEgcHJvcGVydHkgb2YgdGhlIGRhdGEgbW9kZWwsIGJ1dA0K ICAgICAgICBvZiB0aGUgaW1wbGVtZW50YXRpb24sIGFuZCBwb3NzaWJseSBldmVuIHRoZSBkZXBs b3ltZW50LiAgU28NCiAgICAgICAgaGF2aW5nIGEgWUFORyBleHRlbnNpb24gc3RhdGVtZW50IGlz IG5vdCBhIGdvb2Qgc29sdXRpb24uDQoNCiAgICAyLiAgV2l0aCBORE1BLCB0aGUgc2FtZSBzY2hl bWEgbm9kZSBpcyBwcmVzZW50IGluIGRpZmZlcmVudA0KICAgICAgICBkYXRhc3RvcmVzLiAgSXQg bWlnaHQgYmUgdGhlIGNhc2UgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbg0KICAgICAgICBzdXBwb3J0 cyBvbi1jaGFuZ2UgZm9yIHRoZSBub2RlIGluIGEgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUsDQog ICAgICAgIGJ1dCBub3QgaW4gb3BlcmF0aW9uYWwuICBBZ2FpbiwgbWFya2luZyBhIG5vZGUgaW4g dGhlIHNjaGVtYQ0KICAgICAgICBpcyBub3QgYSBnb29kIHNvbHV0aW9uLg0KDQogICAgMy4gIFNp bmNlIHRoZSBvbi1jaGFuZ2UgcHJvcGVydHkgaXMgaW1wbGVtZW50YXRpb24gZGVwZW5kZW50LCBp dA0KICAgICAgICBtZWFucyB0aGUgaW5mb3JtYXRpb24gd2lsbCBiZSBhdmFpbGFibGUgdG8gY2xp ZW50cyBvbmx5IGluDQogICAgICAgIGRldmlhdGlvbiBtb2R1bGVzLiAgVGhpcyBpcyBxdWl0ZSBh biBleHBlbnNpdmUgYW5kIGNvbXBsaWNhdGVkDQogICAgICAgIHdheSB0byBwYXNzIHRoZSBpbmZv cm1hdGlvbiB0byB0aGUgY2xpZW50cy4NCg0KDQogIEFuIGFsdGVybmF0aXZlIHNvbHV0aW9uIGNv dWxkIGJlIHRvIGhhdmUgYW4gb3JkZXJlZCBsaXN0IG9mDQogIGluc3RhbmNlLWlkZW50aWZpZXJz IHRoYXQgbGlzdCB0aGlzIHByb3BlcnR5LCBwZXIgZGF0YXN0b3JlLCBmb3INCiAgZXhhbXBsZToN Cg0KICAgPGVudHJ5Pg0KICAgICA8cGF0aD4vc3lzOnN5c3RlbS9zeXM6c3lzdGVtLXRpbWU8cGF0 aD4NCiAgICAgPG5vdGlmaWFibGUtb24tY2hhbmdlPmZhbHNlPC9ub3RpZmlhYmxlLW9uLWNoYW5n ZT4NCiAgIDwvZW50cnk+DQogICA8ZW50cnk+DQogICAgIDxwYXRoPi9zeXM6c3lzdGVtPHBhdGg+ DQogICAgIDxub3RpZmlhYmxlLW9uLWNoYW5nZT50cnVlPC9ub3RpZmlhYmxlLW9uLWNoYW5nZT4N CiAgIDwvZW50cnk+DQoNCiAgWWV0IGFub3RoZXIgYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gbGVh dmUgdGhpcyB0byBmdXR1cmUgd29yay4NCg0KDQpJIHdvdWxkIHByZWZlciB0byBsZWF2ZSB0aGlz IHRvIGZ1dHVyZSB3b3JrLg0KSSBhZ3JlZSB0aGlzIGlzIGFuIGltcGxlbWVudGF0aW9uIHByb3Bl cnR5LCBhbmQgbm90IGEgZGF0YSBtb2RlbCBwcm9wZXJ0eS4NCg0KQW5keQ0KDQoNCg0KDQoNCi0t DQoNCkJhbGF6cyBMZW5neWVsICAgICAgICAgICAgICAgICAgICAgICBFcmljc3NvbiBIdW5nYXJ5 IEx0ZC4NCg0KU2VuaW9yIFNwZWNpYWxpc3QNCg0KTW9iaWxlOiArMzYtNzAtMzMwLTc5MDkgICAg ICAgICAgICAgIGVtYWlsOiBCYWxhenMuTGVuZ3llbEBlcmljc3Nvbi5jb208bWFpbHRvOkJhbGF6 cy5MZW5neWVsQGVyaWNzc29uLmNvbT4NCg== --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1119sjceml521mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7 fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBh cmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFByZWZv cm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy MQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyog TGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NjA2NjE3ODQzOw0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNDkxNzc5MDU0 IC00NTQwMTMzMTIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZl bC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5NeSBwcmVmZXJlbmNlIGlzIHRvIGtlZXAgdGhlIHNvbHV0aW9uIGFzLWlzLCBwZXIgdGhlIGN1 cnJlbnQgc29sdXRpb24gd2l0aCB0aGUgZXh0ZW5zaW9uIHdlIGhhdmUgZGVmaW5lZC4mbmJzcDsN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhdCBzYWlkLCBJ IGhhdmUgdHdvIGNvbW1lbnRzIHJlbGF0ZWQgdG8gaG93IHdlIGNhbiBnZXQgY2xvc3VyZT8NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiB3ZSBjYW5ub3QgZ2V0IGFn cmVlbWVudCBvbiB0aGlzLCBJIHdvdWxkIG5vdCB3YW50IHRvIGRlbGF5IFlBTkctUHVzaCBvdmVy IGl0IChsaWtlIE1hcnRpbiBoYXMgaW5kaWNhdGVkIGFzIHdlbGwpLiBJbiB0aGF0IGNhc2UsIEkg d291bGQgc3VnZ2VzdCB3ZQ0KIGFkZCBhbiBpbmZvcm1hdGlvbmFsIHNlY3Rpb24gdGhhdCBleHBs YWlucyB0aGUgaXNzdWUsIGFuZCBvdXRsaW5lcyB3aGF0IGEgKHByb3ByaWV0YXJ5KSBzb2x1dGlv biBtaWdodCBsb29rIGxpa2UuJm5ic3A7IE9mIGNvdXJzZSwgdW5mb3J0dW5hdGVseSB0aGlzIHdp bGwgZGUtZmFjdG8gbWVhbiB2ZW5kb3ItcHJvcHJpZXRhcnkgc29sdXRpb25zIGF0IHRoaXMgcG9p bnQgYXMgdGhpcyBhc3BlY3Qgd2lsbCBuZWVkIHRvIGJlIGFkZHJlc3NlZCDigJMgSSB3b3VsZA0K IGZ1bGx5IGV4cGVjdCB0aGF0IEVyaWNzc29uIGluIHRoYXQgY2FzZSB3aWxsIGRlZmluZSB0aGUg c2FtZSBzb2x1dGlvbiBhcyBhbiBFcmljc3Nvbi1wcm9wcmlldGFyeSBtb2R1bGUgd2l0aCBhbiBF cmljc3Nvbi1wcm9wcmlldGFyeSBleHRlbnNpb24gKGFzIG9wcG9zZWQgdG8gaGF2ZSBhIHN0YW5k YXJkIHNvbHV0aW9uKS4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2 ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBkbyB0aGluayB0aGVyZSBpcyBt ZXJpdCB0byBhbHNvIGluY2x1ZGUgdGhlIGluZm9ybWF0aW9uIG9mIHdoYXQgaXMgbm90aWZpYWJs ZSBhcyBwYXJ0IG9mIHRoZSBZQU5HLWxpYnJhcnkuJm5ic3A7IFRoaXMgY291bGQgYmUgcGFydCBv ZiB0aGUgcGVybWFuZW50IHNvbHV0aW9uDQogKGFsdGhvdWdoIGl0IGRvZXMgbm90IGFkZHJlc3Mg dGhlIGFzcGVjdCBvZiBob3cgdGhlIGluZm9ybWF0aW9uIGluIHRoZSBsaWJyYXJ5IHdvdWxkIGJl IHBvcHVsYXRlZCwgQmFsYXpzIHBlciB5b3VyIGNvbW1lbnQpLiBUaGlzIHNwZWNpZmljIGRpc2N1 c3Npb24gc2hvdWxkIHByb2JhYmx5IG1vdmVkIHRvIHRoZSBZQU5HLWxpYnJhcnkgZGlzY3Vzc2lv biwgbm90IHRoZSBvbmUgaGVyZS4mbmJzcDsgJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4tLS0gQWxleDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOndpbmRvd3RleHQiPiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CYWxhenMgTGVuZ3llbDxicj4NCjxiPlNlbnQ6PC9iPiBU dWVzZGF5LCBEZWNlbWJlciAwNSwgMjAxNyA3OjI4IEFNPGJyPg0KPGI+VG86PC9iPiBBbmR5IEJp ZXJtYW4gJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDs7IE1hcnRpbiBCam9ya2x1bmQgJmx0O21i akB0YWlsLWYuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTmV0Y29uZiAmbHQ7bmV0Y29uZkBpZXRm Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW05ldGNvbmZdICZxdW90O25vdGlmaWFibGUt b24tY2hhbmdlJnF1b3Q7IFt3YXM6IFJlOiByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25mLXlh bmctcHVzaC0xMV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5JIHZlcnkgc3Ryb25nbHkg b2JqZWN0IHRvIGV4Y2x1ZGluZyB0aGUgaXNzdWUuJm5ic3A7IFRoZXJlIGlzIGEgc3Ryb25nIGFu ZCBpbW1lZGlhdGUgbmVlZCB0byBiZSBhYmxlIHRvIHNwZWNpZnkgaW4gdmVuZG9yIGRlc2lnbiB0 aW1lIGZvciB3aGljaCBkYXRhIG5vZGVzIHdpbGwgdGhlcmUgYmUgb24tY2hhbmdlIG5vdGlmaWNh dGlvbiBiZSBnZW5lcmF0ZWQuPG86cD48L286cD48L3A+DQo8cD5XaGVuIGEgdmVuZG9yIHJlbGVh c2UgYSBwcm9kdWN0IHRoZXkga25vdyB3aGljaCBub2RlcyB3aWxsIGVtaXQgb24tY2hhbmdlIG5v dGlmaWNhdGlvbnMgaW4gZGVzaWduIHRpbWUuIFN5c3RlbSBpbnRlZ3JhdG9ycyBuZWVkIHRvIGtu b3cgdGhpcy4gUHJvdmlkaW5nIHRoZSBzYW1lIGluZm9ybWF0aW9uIGluIHJ1bi10aW1lIGFzIGlu c3RhbmNlIGRhdGEgaXMgbm90IGEgZ29vZCBzb2x1dGlvbiBlaXRoZXIgYXMgeW91IHdvdWxkIG5l ZWQgdG8gZ2V0DQogYSByZWFsIG5vZGUgdG8gcmVhZCB0aGUgZGF0YSBmcm9tLjxvOnA+PC9vOnA+ PC9wPg0KPHA+SU1ITyBpZ25vcmluZyB0aGlzIG5lZWQgd291bGQganVzdCBmb3JjZSB0aGUgdmVu ZG9ycyAoaW5jbHVkaW5nIGVyaWNzc29uKSB0byBjcmVhdGUgYW4gb3duIHNvbHV0aW9uLg0KPG86 cD48L286cD48L3A+DQo8cD5BbmR5IHdyb3RlOiAmcXVvdDtJIGFncmVlIHRoaXMgaXMgYW4gaW1w bGVtZW50YXRpb24gcHJvcGVydHksIGFuZCBub3QgYSBkYXRhIG1vZGVsIHByb3BlcnR5LiZxdW90 OzxvOnA+PC9vOnA+PC9wPg0KPHA+SSBhbHdheXMgdGhvdWdodCB0aGF0IG9uZSBvZiB0aGUgbWFp biBwdXJwb3NlcyBvZiBZQU5HIHdhcyB0byBkb2N1bWVudCB2ZW5kb3IncyBpbXBsZW1lbnRhdGlv bi4gVGhhdCBpcyBleGFjdGx5IHdoYXQgYSBkZXZpYXRpb24gb3ImbmJzcDsgZmVhdHVyZSBhbHNv IGRvZXMuIFRoZXkgYXJlIGJvdGggcGFydCBvZiBZQU5HLjxvOnA+PC9vOnA+PC9wPg0KPHA+cmVn YXJkcyBCYWxhenM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIwMTctMTEtMjgg MTg6MTAsIEFuZHkgQmllcm1hbiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gVHVlLCBOb3YgMjgsIDIwMTcgYXQgMTozNyBBTSwgTWFydGluIEJqb3Jr bHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIiB0YXJnZXQ9Il9ibGFuayI+ bWJqQHRhaWwtZi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpLDxi cj4NCjxicj4NCjxicj4NCkkgaGF2ZSBub3cgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1uZXRjb25mLXlh bmctcHVzaC0xMS4mbmJzcDsgSSBoYXZlIG9uZTxicj4NCnNvbWV3aGF0IG1vcmUgaW1wb3J0YW50 IGNvbW1lbnQsIGFuZCBzZXZlcmFsIG90aGVycy48YnI+DQo8YnI+DQpJbXBvcnRhbnQgaXNzdWU6 PGJyPg0KPGJyPg0KbyZuYnNwOyAzLjEwPGJyPg0KPGJyPg0KJm5ic3A7IEkgZG9uJ3QgdGhpbmsg dGhlIHByb3Bvc2VkIFlBTkcgZXh0ZW5zaW9uIGlzIHRoZSBjb3JyZWN0IHNvbHV0aW9uIHRvPGJy Pg0KJm5ic3A7IHRoZSBzdGF0ZWQgcHJvYmxlbSwgZm9yIHNldmVyYWwgcmVhc29uczo8YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7IDEuJm5ic3A7IEluIG1vc3QgY2FzZXMsIHRoaXMgaXMgbm90IGEg cHJvcGVydHkgb2YgdGhlIGRhdGEgbW9kZWwsIGJ1dDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBvZiB0aGUgaW1wbGVtZW50YXRpb24sIGFuZCBwb3NzaWJseSBldmVuIHRoZSBkZXBs b3ltZW50LiZuYnNwOyBTbzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBoYXZpbmcg YSBZQU5HIGV4dGVuc2lvbiBzdGF0ZW1lbnQgaXMgbm90IGEgZ29vZCBzb2x1dGlvbi48YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7IDIuJm5ic3A7IFdpdGggTkRNQSwgdGhlIHNhbWUgc2NoZW1hIG5v ZGUgaXMgcHJlc2VudCBpbiBkaWZmZXJlbnQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgZGF0YXN0b3Jlcy4mbmJzcDsgSXQgbWlnaHQgYmUgdGhlIGNhc2UgdGhhdCBhbiBpbXBsZW1l bnRhdGlvbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzdXBwb3J0cyBvbi1jaGFu Z2UgZm9yIHRoZSBub2RlIGluIGEgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUsPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJ1dCBub3QgaW4gb3BlcmF0aW9uYWwuJm5ic3A7IEFnYWlu LCBtYXJraW5nIGEgbm9kZSBpbiB0aGUgc2NoZW1hPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IGlzIG5vdCBhIGdvb2Qgc29sdXRpb24uPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAz LiZuYnNwOyBTaW5jZSB0aGUgb24tY2hhbmdlIHByb3BlcnR5IGlzIGltcGxlbWVudGF0aW9uIGRl cGVuZGVudCwgaXQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbWVhbnMgdGhlIGlu Zm9ybWF0aW9uIHdpbGwgYmUgYXZhaWxhYmxlIHRvIGNsaWVudHMgb25seSBpbjxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkZXZpYXRpb24gbW9kdWxlcy4mbmJzcDsgVGhpcyBpcyBx dWl0ZSBhbiBleHBlbnNpdmUgYW5kIGNvbXBsaWNhdGVkPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHdheSB0byBwYXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgY2xpZW50cy48YnI+ DQo8YnI+DQo8YnI+DQombmJzcDsgQW4gYWx0ZXJuYXRpdmUgc29sdXRpb24gY291bGQgYmUgdG8g aGF2ZSBhbiBvcmRlcmVkIGxpc3Qgb2Y8YnI+DQombmJzcDsgaW5zdGFuY2UtaWRlbnRpZmllcnMg dGhhdCBsaXN0IHRoaXMgcHJvcGVydHksIHBlciBkYXRhc3RvcmUsIGZvcjxicj4NCiZuYnNwOyBl eGFtcGxlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsmbHQ7ZW50cnkmZ3Q7PGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsmbHQ7cGF0aCZndDsvc3lzOnN5c3RlbS9zeXM6c3lzdGVtLXRpbWUmbHQ7 cGF0aCZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtub3RpZmlhYmxlLW9uLWNoYW5n ZSZndDtmYWxzZSZsdDsvbm90aWZpYWJsZS1vbi1jaGFuZ2UmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNw OyZsdDsvZW50cnkmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyZsdDtlbnRyeSZndDs8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyZsdDtwYXRoJmd0Oy9zeXM6c3lzdGVtJmx0O3BhdGgmZ3Q7PGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7bm90aWZpYWJsZS1vbi1jaGFuZ2UmZ3Q7dHJ1ZSZsdDsv bm90aWZpYWJsZS1vbi1jaGFuZ2UmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyZsdDsvZW50cnkmZ3Q7 PGJyPg0KPGJyPg0KJm5ic3A7IFlldCBhbm90aGVyIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRvIGxl YXZlIHRoaXMgdG8gZnV0dXJlIHdvcmsuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgcHJlZmVyIHRvIGxlYXZlIHRo aXMgdG8gZnV0dXJlIHdvcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGFncmVlIHRoaXMgaXMgYW4gaW1wbGVtZW50YXRpb24gcHJvcGVydHks IGFuZCBub3QgYSBkYXRhIG1vZGVsIHByb3BlcnR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwcmU+LS0gPG86cD48L286cD48L3ByZT4NCjxwcmU+QmFs YXpzIExlbmd5ZWwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRXJpY3Nzb24gSHVuZ2FyeSBMdGQuPG86cD48 L286cD48L3ByZT4NCjxwcmU+U2VuaW9yIFNwZWNpYWxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5Nb2JpbGU6ICYjNDM7MzYtNzAtMzMwLTc5MDkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW1haWw6 IDxhIGhyZWY9Im1haWx0bzpCYWxhenMuTGVuZ3llbEBlcmljc3Nvbi5jb20iPkJhbGF6cy5MZW5n eWVsQGVyaWNzc29uLmNvbTwvYT4gPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1119sjceml521mbxchi_-- From nobody Tue Dec 5 12:24: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 0781A127B5A for ; Tue, 5 Dec 2017 12:24:47 -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 5Qz2hmPU22xp for ; Tue, 5 Dec 2017 12:24:44 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3DC12025C for ; Tue, 5 Dec 2017 12:24:44 -0800 (PST) Received: from localhost (h-12-197.A165.priv.bahnhof.se [155.4.12.197]) by mail.tail-f.com (Postfix) with ESMTPSA id 7D68F1AE0144; Tue, 5 Dec 2017 21:24:43 +0100 (CET) Date: Tue, 05 Dec 2017 21:24:43 +0100 (CET) Message-Id: <20171205.212443.660483858000758249.mbj@tail-f.com> To: andy@yumaworks.com Cc: alexander.clemm@huawei.com, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD10E9@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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Netconf] yang-push issue: error handling 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, 05 Dec 2017 20:24:47 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBIaSwNCj4gDQo+IFRo ZSBwcm90b2NvbCBkZWZpbmVzIGhvdyBlcnJvciBoYW5kbGluZyBpcyBkb25lLCBub3QgdGhlIGlu ZGl2aWR1YWwNCj4gb3BlcmF0aW9ucy4NCj4gSWYgdGhlIHJlcXVlc3QgZmFpbHMsIHRoZW4gY2xp ZW50cyBleHBlY3QgYW4gPHJwYy1lcnJvcj4gYW5kIHNlcnZlcnMgYXJlDQo+IGRlc2lnbmVkDQo+ IHRvIHNlbmQgYW4gPHJwYy1lcnJvcj4gd2hlbiBhIGNsaWVudCByZXF1ZXN0IGZhaWxzLg0KDQpB Z3JlZWQsIGFuZCBmb3IgUkVTVENPTkYsIHRoZSBIVFRQIGVycm9yIGNvZGVzIGFyZSB1c2VkLiAg QW4gSFRUUA0KcmVxdWVzdCB0aGF0IGZhaWxzIGRvZXMgbm90IHJldHVybiAyMDAgb2sgd2l0aCBh IGJvZHkgdGhhdCBleHBsYWlucw0KdGhhdCBpdCBhY3R1YWxseSB3YXMgYW4gZXJyb3IuDQoNCj4g SU1PLCBhIHNlcGFyYXRlIGVycm9yIGhhbmRsaW5nIHByb2NlZHVyZSBmb3IgZWFjaCBSUEMgaXMg bW9yZSBjbHVua3kgdGhhbg0KPiBlcnJvci1pbmZvLg0KDQorMQ0KDQpTb21lIGFkZGl0aW9uYWwg Y29tbWVudHMgaW5saW5lLg0KDQoNCj4gPiBXaGlsZSBwb3NzaWJsZSwgdGhlIHNvbHV0aW9uIG9m IGhhdmluZyB0byByZXR1cm4gcnBjLWVycm9yIGV0YyBkb2VzIHN0cmlrZQ0KPiA+IG1lIGFzIHNv bWV3aGF0IGNsdW5reS4gIFdoaWxlIGl0IGlzIHBvc3NpYmxlIHRvIGFkZCBhbiBlcnJvci1hcHAt dGFnLCBhbmQNCj4gPiBuZWdvdGlhdGlvbiBzdHVmZiBhcyBlcnJvci1pbmZvIChhbmQgSSBhcHBy ZWNpYXRlIHRoZSBzdWdnZXN0aW9uKSwgdGhhdA0KPiA+IHNvbHV0aW9uIHdvdWxkIG5lZWQgdG8g YmUgZGVzY3JpYmVkIHVzaW5nIGEgbG90IG9mIHByb3NlIGluIGRlc2NyaXB0aW9uDQo+ID4gc3Rh dGVtZW50cyBhIGxhIFNNSXYyIChwcmVzdW1hYmx5IGFzIHBhcnQgb2YgdGhlIFJQQyBkZXNjcmlw dGlvbiwgbm90IGFzDQo+ID4gcGFydCBvZiBlLmcuIHRoZSBpZGVudGl0aWVzLCB3aGljaCBtaWdo dCBiZSB1c2VkIGluIGEgbnVtYmVyIG9mIHBsYWNlcywgbm90DQo+ID4ganVzdCB0aGUgZXJyb3It YXBwLXRhZykuDQoNCklmIGJvdGggdGhlIGVycm9yIGNvZGUgYW5kIGhpbnQgaXMgZGVmaW5lZCBp biBhIHlhbmctZGF0YSAoaS5lLiwgbm90DQp1c2luZyB0aGUgZXJyb3ItYXBwLXRhZyksIHlvdSB3 b3VsZCBkbzoNCg0KICB5eDp5YW5nLWRhdGEgc3Vic2NyaXB0aW9uLWVycm9yIHsNCiAgICBjb250 YWluZXIgc3Vic2NyaXB0aW9uLWVycm9yIHsNCiAgICAgIGxlYWYgZXJyb3ItY29kZSB7DQogICAg ICAgIHR5cGUgaWRlbnRpdHkgew0KICAgICAgICAgIGJhc2UgZXJyb3I7DQogICAgICAgIH0NCiAg ICAgIH0NCiAgICAgIGNvbnRhaW5lciBoaW50cyB7IC4uLiB9DQogICAgfQ0KICB9DQoNClRoZW4g eW91IGFyZSByaWdodCwgeW91IGhhdmUgdG8gZGVzY3JpYmUgaW4gcHJvc2UgdGhhdCB0aGlzIHlh bmctZGF0YQ0Kc3RydWN0dXJlIGNhbiBiZSBzZW50IGFzIGVycm9yLWluZm8uDQoNCg0KPiA+IEkg YW0gbm90IHN1cmUgd2h5IHRoYXQgd291bGQgbWFrZSBhbiBSUEMgYW55DQo+ID4gZWFzaWVyIHRv IGltcGxlbWVudC4gIFRoZSBzYW1lIGNoZWNrcyBzdGlsbCBoYXZlIHRvIGJlIG1hZGUuDQoNCkFn cmVlZC4NCg0KPiA+IFdoeSB3b3VsZCB0aGUgcHJvcG9zZWQgc29sdXRpb24gbm90IGFjY2VwdGFi bGU/ICAgSWRlYWxseSBZQU5HIHdvdWxkDQo+ID4gcHJvdmlkZSBiZXR0ZXIgc3VwcG9ydCB0byBm b3JtYWxseSBkZWZpbmUgYXBwbGljYXRpb24vUlBDLXNwZWNpZmljIHJldHVybg0KPiA+IGNvZGVz IGFuZCBjb3JuZXIgY29uZGl0aW9ucyBldGMuDQoNCkFsc28gYWdyZWVkLiAgQnV0IG9uY2Ugd2Ug aGF2ZSB0aGF0LCBzdWNoIGEgc29sdXRpb24gd291bGQgbWFrZSB1c2Ugb2YNCnRoZSBycGMtZXJy b3Igd2UgaGF2ZSAoZm9yIGJvdGggTkVUQ09ORiBhbmQgUkVTVENPTkYpLg0KDQoNCi9tYXJ0aW4N Cg0KDQo+ID4gU2hvcnQgb2YgdGhhdCwgdGhlIHByb3Bvc2VkIHNvbHV0aW9uIG9mDQo+ID4gYWRk aW5nIFJQQyBvdXRwdXQgcGFyYW1ldGVycyB0aGF0IGFyZSB1c2VkIGZvciB0aGUgcHVycG9zZSBv ZiBpbmRpY2F0aW5nDQo+ID4gd2hhdCBpcyBnb2luZyBvbiBhdCB0aGUgYXBwbGljYXRpb24gbGV2 ZWwgc2ltcGx5IG1ha2VzIHRoZW0gcGFydCBvZiB0aGUNCj4gPiBzZW1hbnRpY3Mgb2YgdGhlIHNw ZWNpZmljIFJQQyBpdHNlbGYuICBJdCBpcyBub3QgTmV0Y29uZuKAmXMgcm9sZSB0byBkZWZpbmUN Cj4gPiB3aGF0IGFuIFJQQyBjYW4gb3IgY2Fubm90IGRvLCBqdXN0IGxpa2UgaXQgY2Fubm90IGRl ZmluZSB3aGF0IGEgcGFydGljdWxhcg0KPiA+IGxlYWYgbWF5IG9yIG1heSBub3QgcmVwcmVzZW50 LiAgVGhhdCBpcyBwYXJ0IG9mIHRoZSBSUEMgZGVmaW5pdGlvbi4NCj4gPg0KPiA+DQo+ID4NCj4g PiBCYXNpY2FsbHksIHdoYXQgd2UgYXJlIGRpc2N1c3NpbmcgaGVyZSBpcyBiZWhhdmlvciBvZiBz dWJzY3JpcHRpb24NCj4gPiBjb25maWd1cmF0aW9uIHVuZGVyIGNvcm5lciBjb25kaXRpb25zLiAg VGhlIGZhY3QgdGhhdCBubyBzdWJzY3JpcHRpb24gaXMNCj4gPiBjcmVhdGVkIGJlY2F1c2UgaXQg d291bGQgcmVzdWx0IGluIGFuIHVuYWNjZXB0YWJsZSB2b2x1bWUgb2YgdXBkYXRlcyBmb3IgYQ0K PiA+IHNwZWNpZmljIGltcGxlbWVudGF0aW9uIGlzIGRpZmZlcmVudCBmcm9tIGFuIGVycm9yIGNv bmRpdGlvbiBzdWNoIGFzIGENCj4gPiBtYWxmb3JtZWQgbWVzc2FnZSB0aGF0IGlzIG1pc3Npbmcg YSByZXF1aXJlZCBtZXNzYWdlLWlkLCBvciB3aGVyZSBhIHZhbHVlDQo+ID4gdmlvbGF0ZXMgYSBj b25zdHJhaW50IHNwZWNpZmllZCBpbiBhIE1VU1QtY29uZGl0aW9uLiAgSW4gb3VyIGNhc2UsIHdo YXQgaXMNCj4gPiBiZWluZyBkZXNjcmliZWQgYXJlIHNwZWNpZmljIGNvbmRpdGlvbnMgYXQgdGhl IGFwcGxpY2F0aW9uIGxheWVyLCBhYm92ZSB0aGUNCj4gPiBOZXRjb25mL1Jlc3Rjb25mIGdlbmVy aWMgdmFsaWRhdGlvbiBpbmZyYXN0cnVjdHVyZS4gICBUaGUgb3BlcmF0aW9uIGRvZXMNCj4gPiBu b3Qg4oCcd29ya+KAnSBpbiB0aGUgc2Vuc2UgdGhhdCBpdCBkb2VzIG5vdCByZXN1bHQgaW4gYW4g YWN0aXZlIHN1YnNjcmlwdGlvbiwNCj4gPiBidXQgaXQgZG9lcyB3b3JrIGluIHRoZSBzZW5zZSB0 aGF0IHRoZSBiZWhhdmlvciBpcyB2ZXJ5IHdlbGwgZGVmaW5lZCBpbg0KPiA+IHRlcm1zIG9mIHRo ZSBlZmZlY3QgdGhhdCB0aGUgUlBDIGhhcyAoaS5lLiB0aGUgZWZmZWN0IGlzIHRoYXQgaXQgcmVz dWx0IGluDQo+ID4gY3JlYXRpb24gb2YgYSBzdWJzY3JpcHRpb24sIGlmIGNlcnRhaW4gY29uZGl0 aW9ucyBhcmUgbWV0LCBhbmQgaXQgZG9lcyBub3QNCj4gPiByZXN1bHQgaW4gY3JlYXRpb24gb2Yg YSBzdWJzY3JpcHRpb24gaW4gY2FzZSBjZXJ0YWluIGNvbmRpdGlvbnMgYXJlIG5vdA0KPiA+IG1l dCkuICBXaHkgc2hvdWxkIE5ldGNvbmYgcmVzdHJpY3Qgd2hhdCBhbiBSUEMgY2FuIG9yIGNhbm5v dCBkbz8gIFRoaXMgaXMNCj4gPiBhbGwgYXBwbGljYXRpb24tc3BlY2lmaWMuDQo+ID4NCj4gPg0K PiA+DQo+ID4gLS0tIEFsZXgNCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gKkZyb206KiBO ZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpB bmR5DQo+ID4gQmllcm1hbg0KPiA+ICpTZW50OiogTW9uZGF5LCBEZWNlbWJlciAwNCwgMjAxNyA5 OjE1IEFNDQo+ID4gKlRvOiogTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+DQo+ID4g KkNjOiogTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZz4NCj4gPiAqU3ViamVjdDoqIFJlOiBbTmV0 Y29uZl0geWFuZy1wdXNoIGlzc3VlOiBlcnJvciBoYW5kbGluZw0KPiA+DQo+ID4NCj4gPg0KPiA+ DQo+ID4NCj4gPg0KPiA+DQo+ID4gT24gTW9uLCBEZWMgNCwgMjAxNyBhdCA0OjU1IEFNLCBNYXJ0 aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBBbmR5IEJpZXJt YW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6DQo+ID4gPiBIaSwNCj4gPiA+DQo+ID4gPiBJ TU8gdGhlIHNwZWNpYWwgZXJyb3IgaGFuZGxpbmcgaW4gWUFORyBQdXNoIGlzIG5vdCBhY2NlcHRh YmxlDQo+ID4gPiBiZWNhdXNlIGl0IHZpb2xhdGVzIE5FVENPTkYgYW5kIFJFU1RDT05GIGVycm9y IGhhbmRsaW5nIHByb2NlZHVyZXMuDQo+ID4gPiBORVRDT05GIHNheXMgaWYgdGhlIG9wZXJhdGlv biBkb2VzIG5vdCB3b3JrIGZvciBhbnkgcmVhc29uIGFuIDxycGMtZXJyb3I+DQo+ID4gPiBlbGVt ZW50IFNIT1VMRCBiZSByZXR1cm5lZC4NCj4gPg0KPiA+IEkgZnVsbHkgYWdyZWUsIGFuZCBJIGhh dmUgcG9pbnRlZCB0aGlzIG91dCBzZXZlcmFsIHRpbWVzIGluIG15DQo+ID4gcmV2aWV3cy4gIFRo ZSBwcm9ibGVtIGlzIGFjdHVhbGx5IGluIHN1YnNjcmliZWQgbm90aWZpY2F0aW9ucywgYW5kIEkN Cj4gPiB0aGluayBFcmljIGlzIHRyYWNraW5nIHRoYXQgaXNzdWUuDQo+ID4NCj4gPiBUcnlpbmcg dG8gYmUgY29uc3RydWN0aXZlLCBJIHRoaW5rIHRoYXQgdGhlIGV4aXN0aW5nIG1lY2hhbmlzbXMg aW4NCj4gPiBZQU5HIGNhbiBiZSB1c2VkIHRvIGFjaGlldmUgdGhlIHNhbWUgZnVuY3Rpb25hbGl0 eSB0aGF0IHRoZXNlIGRyYWZ0cw0KPiA+IHRyeSB0byBhY2hpZXZlLiAgU3BlY2lmaWNhbGx5Og0K PiA+DQo+ID4gICAxLiBVc2UgaWRlbnRpdGllcyBqdXN0IGxpa2UgdGhlIG9uZXMgeW91IGhhdmUN Cj4gPiAgICAgICgidW5zdXBwb3J0YWJsZS12b2x1bWUiLCAiZmlsdGVyLXVuYXZhaWxhYmxlIiBl dGMpLCBidXQgYWRkIHRleHQNCj4gPiAgICAgIHRoYXQgZXhwbGFpbnMgdGhhdCB0aGVzZSBpZGVu dGl0aWVzIGFyZSBzZW50IGFzICJlcnJvci1hcHAtdGFnIg0KPiA+ICAgICAgaW4gInJwYy1lcnJv ciIsIGVuY29kZWQgdG8gYSBzdHJpbmcgYXMgPG1vZHVsZT46PGlkZW50aXR5Pi4gIFRoaXMNCj4g PiAgICAgIHdvcmtzIGZvciBib3RoIE5FVENPTkYgYW5kIFJFU1RDT05GLg0KPiA+DQo+ID4gICAy LiBGb3IgdGhlICJoaW50cyIgZXh0cmEgaW5mbyB0aGF0IHlvdSByZXR1cm4sIGRlZmluZSBhICJ5 YW5nLWRhdGEiDQo+ID4gICAgICBzdHJ1Y3R1cmUgd2l0aCB0aGUgaGludHMsIGFuZCBleHBsYWlu IGluIHRleHQgdGhhdCB0aGlzIHN0cnVjdHVyZQ0KPiA+ICAgICAgaXMgcmV0dXJuZWQgaW4gImVy cm9yLWluZm8iLiAgVGhpcyB3b3JrcyBmb3IgYm90aCBORVRDT05GIGFuZA0KPiA+ICAgICAgUkVT VENPTkYuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+ICsxDQo+ID4NCj4gPg0KPiA+DQo+ ID4gSWYgdGhlIGVycm9yIGhhbmRsaW5nIHdhcyBkb25lIGNvcnJlY3RseSB0aGVuIHRoZSBzYW1l IHByb2NlZHVyZXMgY291bGQgYmUNCj4gPg0KPiA+IGFwcGxpZWQgdG8gPGVkaXQtY29uZmlnPiBm YWlsdXJlcyBmb3IgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zLg0KPiA+DQo+ID4NCj4gPg0KPiA+ DQo+ID4NCj4gPg0KPiA+IEFzIGFuIGFsdGVybmF0aXZlIHRvIDEsIHlvdSBjYW4gcHV0IHRoZSBl cnJvciBpZGVudGl0aXlyZWYgaW4gdGhlDQo+ID4gInlhbmctZGF0YSIgc3RydWN0dXJlLCBhbmQg c2VuZCBib3RoIHRoZSBpZGVudGl0aXlyZWYgYW5kIGhpbnRzIGluDQo+ID4gImVycm9yLWluZm8i Lg0KPiA+DQo+ID4NCj4gPiAvbWFydGluDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IEFu ZHkNCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiA+IFRoZSA8ZXN0YWJsaXNoLXN1 YnNjcmlwdGlvbj4gcmV0dXJucyBkYXRhIGV2ZW4gb24gZXJyb3IuDQo+ID4gPiBJbnN0ZWFkIG9m IHRoZSBjb21tb24gZXJyb3ItdGFnLCBlcnJvci1pbmZvLCBhbmQgb3RoZXIgZmllbGRzLA0KPiA+ ID4gdGhlcmUgaXMgYSBzdWJzY3JpcHRpb24tcmVzdWx0IGxlYWYuDQo+ID4gPg0KPiA+ID4gSWYg YW55IGNsaWVudCAob3IgZXZlbiBzZXJ2ZXIpIGZ1bmN0aW9uYWxpdHkgdXNlcyB0aGUgTkVUQ09O RiBhbmQNCj4gPiA+IFJFU1RDT05GIHN0YW5kYXJkIGVycm9yIGhhbmRsaW5nLCB0aGVuIHN1YnNj cmlwdGlvbi1yZXN1bHQgd2lsbCBub3QgYmUNCj4gPiA+IHNlbnQgb3IgZXhwZWN0ZWQgYXMgYW4g ZXJyb3IgcmVzcG9uc2UuIERlcGVuZGluZyBvbiB0aGUgc2VydmVyDQo+ID4gPiBpbXBsZW1lbnRh dGlvbiwgdGhlIGNvZGUgdGhhdCBrbm93cyBhYm91dCBlc3RhYmxpc2gtc3Vic2NyaXB0aW9uDQo+ ID4gPiBtYXkgbm90IGdldCBjYWxsZWQgYmVjYXVzZSBjb21tb24gZXJyb3IgaGFuZGxpbmcgY29k ZSBoYXMNCj4gPiA+IGFscmVhZHkgZGV0ZXJtaW5lZCB0aGVyZSBpcyBhbiA8cnBjLWVycm9yPiB0 byBzZW5kIGluc3RlYWQgb2YgYSBkYXRhDQo+ID4gPiByZXNwb25zZS4NCj4gPiA+DQo+ID4gPiBF eHBlY3QgdGhhdCBzb21lIHNlcnZlcnMgYXJlIG5ldmVyIGdvaW5nIHRvIHNlbmQgZGF0YSBvbiBh biBvcGVyYXRpb24NCj4gPiA+IGZhaWx1cmUsIGFuZCB3aWxsIG9ubHkgc2VuZCA8cnBjLWVycm9y PiBpbnN0ZWFkLg0KPiA+ID4NCj4gPiA+DQo+ID4gPiA+RnJvbSBzZWMuIDMuODoNCj4gPiA+DQo+ ID4gPiAgICBGb3IgaW5zdGFuY2UsIGZvciB0aGUgZm9sbG93aW5nIHJlcXVlc3Q6DQo+ID4gPg0K PiA+ID4gPG5ldGNvbmY6cnBjIG1lc3NhZ2UtaWQ9IjEwMSINCj4gPiA+ICAgIHhtbG5zOm5ldGNv bmY9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQo+ID4gPiAgICA8 ZXN0YWJsaXNoLXN1YnNjcmlwdGlvbg0KPiA+ID4gICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJh bXM6eG1sOm5zOnlhbmc6aWV0Zi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMiDQo+ID4gPiAgICAg ICAgeG1sbnM6eXA9InVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLXlhbmctcHVzaCI+ DQo+ID4gPiAgICAgICA8eXA6ZGF0YXN0b3JlPg0KPiA+ID4gICAgICAgICA8eXA6c291cmNlIHht bG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1kYXRhc3RvcmVzIj4NCj4gPiA+ ICAgICAgICAgICBvcGVyYXRpb25hbA0KPiA+ID4gICAgICAgICA8L3lwOnNvdXJjZT4NCj4gPiA+ ICAgICAgICAgPHlwOnN1YnRyZWUtZmlsdGVyIG5ldGNvbmY6dHlwZT0ieHBhdGgiDQo+ID4gPiAg ICAgICAgICAgICB4bWxuczpleD0iaHR0cDovL2V4YW1wbGUuY29tL3NhbXBsZS1kYXRhLzEuMCIN Cj4gPiA+ICAgICAgICAgICAgIHNlbGVjdD0iL2V4OmZvbyIvPg0KPiA+ID4gICAgICAgPC95cDpk YXRhc3RvcmU+DQo+ID4gPiAgICAgICA8eXA6cGVyaW9kPjUwMDwveXA6cGVyaW9kPg0KPiA+ID4g ICAgPC9lc3RhYmxpc2gtc3Vic2NyaXB0aW9uPg0KPiA+ID4gPC9uZXRjb25mOnJwYz4NCj4gPiA+ DQo+ID4gPiAgICAgICAgICAgICAgICAgIEZpZ3VyZSAzOiBFc3RhYmxpc2gtU3Vic2NyaXB0aW9u IGV4YW1wbGUNCj4gPiA+DQo+ID4gPiAgICB0aGUgcHVibGlzaGVyIG1pZ2h0IHJldHVybjoNCj4g PiA+DQo+ID4gPg0KPiA+ID4gPHJwYy1yZXBseSBtZXNzYWdlLWlkPSIxMDEiDQo+ID4gPiAgICAg IHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiPg0KPiA+ID4g ICAgPHN1YnNjcmlwdGlvbi1yZXN1bHQNCj4gPiA+ICAgICAgICB4bWxucz0idXJuOmlldGY6cGFy YW1zOnhtbDpuczp5YW5nOmlldGYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIg0KPiA+ID4gICAg ICAgIHhtbG5zOnlwPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi15YW5nLXB1c2gi Pg0KPiA+ID4gICAgICB5cDpwZXJpb2QtdW5zdXBwb3J0ZWQNCj4gPiA+ICAgIDwvc3Vic2NyaXB0 aW9uLXJlc3VsdD4NCj4gPiA+ICAgIDxwZXJpb2QtaGludCB4bWxuczoidXJuOmlldGY6cGFyYW1z OnhtbDpuczp5YW5nOmlldGYteWFuZy1wdXNoIj4NCj4gPiA+ICAgICAgIDIwMDANCj4gPiA+ICAg IDwvcGVyaW9kLWhpbnQ+DQo+ID4gPiA8L3JwYy1yZXBseT4NCj4gPiA+DQo+ID4gPiAgICAgICAg ICAgICAgICAgICAgICBGaWd1cmUgNDogRXJyb3IgcmVzcG9uc2UgZXhhbXBsZQ0KPiA+ID4NCj4g PiA+DQo+ID4gPg0KPiA+ID4gQlRXLCBhbGwgdGhlIGZpbHRlciBleGFtcGxlcyBzZWVtIHRvIGJl IHdyb25nLCBpbmNsdWRpbmcgdGhlIG9uZSBhYm92ZQ0KPiA+ID4NCj4gPiA+DQo+ID4gPiBPTEQ6 DQo+ID4gPg0KPiA+ID4gICAgICAgICA8eXA6c3VidHJlZS1maWx0ZXIgbmV0Y29uZjp0eXBlPSJ4 cGF0aCINCj4gPiA+ICAgICAgICAgICAgIHhtbG5zOmV4PSJodHRwOi8vZXhhbXBsZS5jb20vc2Ft cGxlLWRhdGEvMS4wIg0KPiA+ID4gICAgICAgICAgICAgc2VsZWN0PSIvZXg6Zm9vIi8+DQo+ID4g Pg0KPiA+ID4NCj4gPiA+IE5FVzoNCj4gPiA+DQo+ID4gPg0KPiA+ID4gICAgICAgICA8eXA6c3Vi dHJlZS1maWx0ZXI+DQo+ID4gPiAgICAgICAgICAgIDxleDpmb28geG1sbnM6ZXg9Imh0dHA6Ly9l eGFtcGxlLmNvbS9zYW1wbGUtZGF0YS8xLjAiIC8+DQo+ID4gPg0KPiA+ID4gICAgICAgICA8L3lw OnN1YnRyZWUtZmlsdGVyPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBBbmR5DQo+ID4NCj4gPg0KPiA+ DQo= From nobody Tue Dec 5 12:25: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 BB8D2128796 for ; Tue, 5 Dec 2017 12:25:02 -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 SB_zBk315jMJ for ; Tue, 5 Dec 2017 12:24:54 -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 C94A8127B73 for ; Tue, 5 Dec 2017 12:24:53 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 8929F3D787D03 for ; Tue, 5 Dec 2017 20:24:50 +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; Tue, 5 Dec 2017 20:24:51 +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; Tue, 5 Dec 2017 12:24:45 -0800 From: Alexander Clemm To: "Eric Voit (evoit)" , Andy Bierman , Netconf Thread-Topic: [Netconf] yang-push issue: XPath filter Thread-Index: AQHTaj8zlFxAPDk8o0KnD5kONQva2KMvGCYAgAYf2BA= Date: Tue, 5 Dec 2017 20:24:45 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1139@sjceml521-mbx.china.huawei.com> References: <7c296634a2d44a4eb7ad3662f7a19365@XCH-RTP-013.cisco.com> In-Reply-To: <7c296634a2d44a4eb7ad3662f7a19365@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.169] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1139sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [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: Tue, 05 Dec 2017 20:25:03 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1139sjceml521mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdCBjb21pbmcgYmFjayB0byB0aGlzIG9sZGVyIHRocmVhZCBhcyBJIGFtIG5vdCBzdXJlIHdl IGhhdmUgY2xvc3VyZToNCkp1c3QgdG8gYmUgY2xlYXIsIHdpdGggWFBhdGggZmlsdGVyaW5nIHdl IHdvdWxkIGxvb2sgdG8gc2VsZWN0IHdoaWNoIG5vZGVzIHRvIHVwZGF0ZSBvbi4gIEhvd2V2ZXIs IHdlIHdvdWxkIG5vdCBmaWx0ZXIgb24gbm9kZSB2YWx1ZXMuICBDb3JyZWN0Pw0KDQpSZWdhcmRp bmcgbWFraW5nIHN1YnRyZWUgZmlsdGVyaW5nIGZyb20gbWFuZGF0b3J5IHRvIGNvbmRpdGlvbmFs LW1hbmRhdG9yeSwgdGhpcyB3b3VsZCBzZWVtIHRvIG1ha2Ugc2Vuc2UgdG8gbWUuICBJdCBhcmd1 YWJseSB3b3VsZCBhbHNvIGJlIG9uZSBtb3JlIHN0ZXAgdG8gZGlzZW50YW5nbGUgZGF0YSBtb2Rl bCBhbmQgdHJhbnNwb3J0IChvciByZWFsbHksIGRhdGEgbW9kZWwgYW5kIHN1cHBvcnQgZnVuY3Rp b25zIHRpZWQgdG8gc3BlY2lmaWMgdHJhbnNwb3J0cykuDQotLS0gQWxleA0KDQpGcm9tOiBOZXRj b25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBW b2l0IChldm9pdCkNClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDEsIDIwMTcgNjo0NyBBTQ0KVG86 IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPjsgTmV0Y29uZiA8bmV0Y29uZkBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0geWFuZy1wdXNoIGlzc3VlOiBYUGF0aCBmaWx0 ZXINCg0KSGkgQW5keSwNCg0KRnJvbTogQW5keSBCaWVybWFuLCBOb3ZlbWJlciAzMCwgMjAxNyA3 OjU2IFBNDQpIaSwNCg0KSW4gc2VjLiAzLjY6DQoNCg0KDQogICBUaGVzZSBmaWx0ZXJzIGFyZSBp bnRlbmRlZCB0byBiZSB1c2VkIGFzIHNlbGVjdG9ycyB0aGF0IGRlZmluZSB3aGljaA0KDQogICBv YmplY3RzIGFyZSB3aXRoaW4gdGhlIHNjb3BlIG9mIGEgc3Vic2NyaXB0aW9uLiAgQSBwdWJsaXNo ZXIgTVVTVA0KDQogICBzdXBwb3J0IGF0IGxlYXN0IG9uZSB0eXBlIG9mIHNlbGVjdGlvbiBmaWx0 ZXIuDQoNClRoaXMgaXMgaW5jb25zaXN0ZW50IHdpdGggTkVUQ09ORiwgd2hlcmUgc3VidHJlZSBm aWx0ZXJpbmcgaW4gbWFuZGF0b3J5LXRvLWltcGxlbWVudA0KYW5kIFhQYXRoIGZpbHRlcmluZyBp cyBvcHRpb25hbCAoaWYtZmVhdHVyZSkuDQoNCjxFcmljPiBXZSBoYWQgc29tZSBpbnB1dCBmcm9t IElvVCBwZW9wbGUgdGhhdCBYcGF0aCBhbmQgbm90IHN1YnRyZWUgd2FzIHByZWZlcnJlZCBpbiB0 aGVpciB1c2UgY2FzZXMgYW5kIHRyYW5zcG9ydC4NCg0KT25lIHdheSB0byBhZGRyZXNzIHRoaXMg d291bGQgYmUgdG8gbWFrZSBzdWJ0cmVlIGZpbHRlcmluZyBtYW5kYXRvcnkgd2hlbiB0aGUgdHJh bnNwb3J0IGlzIE5FVENPTkYsIGFuZCBwbGFjZSB0aGlzIHJlcXVpcmVtZW50IHdpdGhpbg0KZHJh ZnQtaWV0Zi1uZXRjb25mLW5ldGNvbmYtZXZlbnQtbm90aWZpY2F0aW9ucw0Kd291bGQgdGhhdCB3 b3JrIGZvciB5b3U/DQoNCkEgY2xpZW50IGRvZXMgbm90IGhhdmUgYW55IHdheSB0byBrbm93IHdo YXQgYQ0KcHVibGlzaGVyIHdpbGwgc3VwcG9ydC4NCg0KPEVyaWM+IFN1YnRyZWUgYW5kIHhwYXRo IGZpbHRlcmluZyBhcmUgaWYtZmVhdHVyZXMgZGVmaW5lZCB3aXRoaW4gc3Vic2NyaWJlZC1ub3Rp ZmljYXRpb25zLCBhbmQgdGFnZ2VkIHdpdGhpbiB0aGUgZmlsdGVyIHR5cGVzIG9mIHlhbmctcHVz aC4gIEkgd2lsbCBhZGQgYSBub3RlIGFmdGVyOg0KDQoNCkEgcHVibGlzaGVyIE1VU1Qgc3VwcG9y dCBhdCBsZWFzdCBvbmUgdHlwZSBvZiBzZWxlY3Rpb24gZmlsdGVyLg0KDQoNCg0KdGhhdDoNCg0K DQoNCkEgc3Vic2NyaWJlciBjYW4gZGV0ZXJtaW5lIGF2YWlsYWJsZSBzZWxlY3Rpb24gZmlsdGVy IG9wdGlvbnMgYnkgbG9va2luZyBmb3Ig4oCcc3VidHJlZeKAnSBhbmQg4oCceHBhdGjigJ0gZmVh dHVyZSBzdXBwb3J0IHdpdGhpbiDigJxpZXRmLXN1YnNjcmliZWQtbm90aWZpY2F0aW9uc+KAnS4N Cg0KDQpJdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZm9sbG93IE5FVENPTkYgYW5kIGFkZCBhbiBpZi1m ZWF0dXJlIHRvIFhQYXRoLCBhbmQgZGVjbGFyZQ0KdGhhdCBzdWJ0cmVlIGlzIG1hbmRhdG9yeS4N Cg0KQWxzbywgdGhlIGV4YW1wbGUgb24gcGcgMzYgaXMgd3Jvbmc6DQoNCk9MRDoNCg0KDQogICAg ICAgPHlwOnhwYXRoLWZpbHRlcg0KDQogICAgICAgICAgICB4bWxuczpleD0iaHR0cDovL2V4YW1w bGUuY29tL3NhbXBsZS1kYXRhLzEuMCINCg0KICAgICAgICAgICAgc2VsZWN0PSIvZXg6Zm9vIi8+ DQoNCg0KDQpORVc6DQoNCg0KDQogICAgICAgPHlwOnhwYXRoLWZpbHRlcg0KDQogICAgICAgIHht bG5zOmV4PSJodHRwOi8vZXhhbXBsZS5jb20vc2FtcGxlLWRhdGEvMS4wIj4vZXg6Zm9vDQoNCiAg ICAgICA8L3lwOnhwYXRoLWZpbHRlcj4NCg0KDQoNCg0KDQpGcm9tIHRoZSBZQU5HIG1vZHVsZToN Cg0KDQoNCiAgICAgIGxlYWYgeHBhdGgtZmlsdGVyIHsNCg0KICAgICAgICB0eXBlIHlhbmc6eHBh dGgxLjA7DQoNCiAgICAgICAgZGVzY3JpcHRpb24NCg0KICAgICAgICAgICJUaGlzIHBhcmFtZXRl ciBjb250YWlucyBhbiBYUGF0aCBleHByZXNzaW9uIGlkZW50aWZ5aW5nIHRoZQ0KDQogICAgICAg ICAgcG9ydGlvbnMgb2YgdGhlIHRhcmdldCBkYXRhc3RvcmUgdG8gcmV0cmlldmUuIjsNCg0KICAg ICAgICByZWZlcmVuY2UgImh0dHA6Ly93d3cudzMub3JnL1RSLzE5OTkvUkVDLXhwYXRoLTE5OTkx MTE2IjsNCg0KICAgICAgfQ0KDQoNCg0KPEVyaWM+IFdpbGwgZml4LCB0aGFua3MhDQoNCkVyaWMN Cg0KDQoNCkFuZHkNCg0KDQo= --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1139sjceml521mbxchi_ 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 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1h bDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21w b3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KdXN0IGNvbWlu ZyBiYWNrIHRvIHRoaXMgb2xkZXIgdGhyZWFkIGFzIEkgYW0gbm90IHN1cmUgd2UgaGF2ZSBjbG9z dXJlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KdXN0IHRvIGJlIGNsZWFyLCB3aXRoIFhQYXRoIGZpbHRl cmluZyB3ZSB3b3VsZCBsb29rIHRvIHNlbGVjdCB3aGljaCBub2RlcyB0byB1cGRhdGUgb24uJm5i c3A7IEhvd2V2ZXIsIHdlIHdvdWxkIG5vdCBmaWx0ZXIgb24gbm9kZSB2YWx1ZXMuJm5ic3A7IENv cnJlY3Q/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRp bmcgbWFraW5nIHN1YnRyZWUgZmlsdGVyaW5nIGZyb20gbWFuZGF0b3J5IHRvIGNvbmRpdGlvbmFs LW1hbmRhdG9yeSwgdGhpcyB3b3VsZCBzZWVtIHRvIG1ha2Ugc2Vuc2UgdG8gbWUuJm5ic3A7IEl0 IGFyZ3VhYmx5IHdvdWxkIGFsc28gYmUgb25lIG1vcmUgc3RlcCB0byBkaXNlbnRhbmdsZQ0KIGRh dGEgbW9kZWwgYW5kIHRyYW5zcG9ydCAob3IgcmVhbGx5LCBkYXRhIG1vZGVsIGFuZCBzdXBwb3J0 IGZ1bmN0aW9ucyB0aWVkIHRvIHNwZWNpZmljIHRyYW5zcG9ydHMpLiZuYnNwOyAmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+LS0tIEFsZXg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBOZXRjb25mIFttYWlsdG86bmV0Y29u Zi1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5FcmljIFZvaXQgKGV2b2l0 KTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIERlY2VtYmVyIDAxLCAyMDE3IDY6NDcgQU08YnI+ DQo8Yj5Ubzo8L2I+IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OzsgTmV0 Y29uZiAmbHQ7bmV0Y29uZkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtO ZXRjb25mXSB5YW5nLXB1c2ggaXNzdWU6IFhQYXRoIGZpbHRlcjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5IaSBBbmR5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBBbmR5IEJpZXJtYW4sIE5vdmVtYmVyIDMwLCAyMDE3IDc6NTYgUE08 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBzZWMuIDMuNjo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRoZXNlIGZpbHRlcnMgYXJlIGludGVuZGVkIHRvIGJlIHVz ZWQgYXMgc2VsZWN0b3JzIHRoYXQgZGVmaW5lIHdoaWNoPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG9iamVjdHMgYXJl IHdpdGhpbiB0aGUgc2NvcGUgb2YgYSBzdWJzY3JpcHRpb24uJm5ic3A7IEEgcHVibGlzaGVyIE1V U1Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsgc3VwcG9ydCBhdCBsZWFzdCBvbmUgdHlwZSBvZiBzZWxlY3Rpb24gZmls dGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGlzIGlzIGluY29uc2lzdGVudCB3aXRoIE5FVENPTkYsIHdoZXJlIHN1YnRy ZWUgZmlsdGVyaW5nIGluIG1hbmRhdG9yeS10by1pbXBsZW1lbnQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCBYUGF0aCBmaWx0ZXJpbmcgaXMg b3B0aW9uYWwgKGlmLWZlYXR1cmUpLiZuYnNwOyA8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZsdDtFcmljJmd0 OyBXZSBoYWQgc29tZSBpbnB1dCBmcm9tIElvVCBwZW9wbGUgdGhhdCBYcGF0aCBhbmQgbm90IHN1 YnRyZWUgd2FzIHByZWZlcnJlZCBpbiB0aGVpciB1c2UgY2FzZXMgYW5kIHRyYW5zcG9ydC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9uZSB3YXkgdG8gYWRkcmVz cyB0aGlzIHdvdWxkIGJlIHRvIG1ha2Ugc3VidHJlZSBmaWx0ZXJpbmcgbWFuZGF0b3J5IHdoZW4g dGhlIHRyYW5zcG9ydCBpcyBORVRDT05GLCBhbmQgcGxhY2UgdGhpcyByZXF1aXJlbWVudCB3aXRo aW4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5kcmFmdC1pZXRmLW5ldGNvbmYtbmV0Y29uZi1ldmVudC1u b3RpZmljYXRpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPndvdWxkIHRoYXQgd29yayBmb3IgeW91Pzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BIGNsaWVudCBkb2VzIG5vdCBoYXZlIGFueSB3YXkgdG8ga25vdyB3aGF0IGE8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnB1Ymxp c2hlciB3aWxsIHN1cHBvcnQuJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZsdDtFcmljJmd0OyBTdWJ0cmVlIGFuZCB4cGF0aCBmaWx0ZXJpbmcgYXJlIGlmLWZlYXR1 cmVzIGRlZmluZWQgd2l0aGluIHN1YnNjcmliZWQtbm90aWZpY2F0aW9ucywgYW5kIHRhZ2dlZCB3 aXRoaW4gdGhlIGZpbHRlciB0eXBlcyBvZiB5YW5nLXB1c2guJm5ic3A7IEkgd2lsbCBhZGQgYSBu b3RlDQogYWZ0ZXI6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BIHB1Ymxpc2hlciBNVVNUIHN1cHBv cnQgYXQgbGVhc3Qgb25lIHR5cGUgb2Ygc2VsZWN0aW9uIGZpbHRlci48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRoYXQ6 PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+QSBzdWJzY3JpYmVyIGNhbiBkZXRlcm1pbmUgYXZhaWxhYmxlIHNlbGVjdGlvbiBmaWx0 ZXIgb3B0aW9ucyBieSBsb29raW5nIGZvciDigJxzdWJ0cmVl4oCdIGFuZCDigJx4cGF0aOKAnSBm ZWF0dXJlIHN1cHBvcnQgd2l0aGluIOKAnGlldGYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25z4oCd LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgd291bGQgYmUgYmV0dGVyIHRvIGZv bGxvdyBORVRDT05GIGFuZCBhZGQgYW4gaWYtZmVhdHVyZSB0byBYUGF0aCwgYW5kIGRlY2xhcmU8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYXQg c3VidHJlZSBpcyBtYW5kYXRvcnkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28sIHRoZSBleGFtcGxlIG9uIHBnIDM2IGlzIHdy b25nOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PTEQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmU+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3lw OnhwYXRoLWZpbHRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB4bWxuczpleD0mcXVvdDs8YSBocmVmPSJodHRwOi8vZXhh bXBsZS5jb20vc2FtcGxlLWRhdGEvMS4wIj5odHRwOi8vZXhhbXBsZS5jb20vc2FtcGxlLWRhdGEv MS4wPC9hPiZxdW90OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZWxlY3Q9JnF1b3Q7L2V4OmZvbyZxdW90Oy8mZ3Q7PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+TkVXOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0 O3lwOnhwYXRoLWZpbHRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB4bWxuczpleD0mcXVvdDs8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vc2FtcGxlLWRhdGEv MS4wIj5odHRwOi8vZXhhbXBsZS5jb20vc2FtcGxlLWRhdGEvMS4wPC9hPiZxdW90OyZndDsvZXg6 Zm9vPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsveXA6eHBhdGgtZmls dGVyJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPkZyb20gdGhlIFlBTkcgbW9kdWxlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIHhwYXRoLWZpbHRlciB7PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgeWFuZzp4cGF0aDEuMDs8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb248bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7VGhpcyBwYXJhbWV0 ZXIgY29udGFpbnMgYW4gWFBhdGggZXhwcmVzc2lvbiBpZGVudGlmeWluZyB0aGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcG9ydGlvbnMgb2Yg dGhlIHRhcmdldCBkYXRhc3RvcmUgdG8gcmV0cmlldmUuJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZWZlcmVuY2UgJnF1b3Q7PGEgaHJlZj0iaHR0cDov L3d3dy53My5vcmcvVFIvMTk5OS9SRUMteHBhdGgtMTk5OTExMTYiPmh0dHA6Ly93d3cudzMub3Jn L1RSLzE5OTkvUkVDLXhwYXRoLTE5OTkxMTE2PC9hPiZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbHQ7RXJpYyZndDsgV2lsbCBmaXgsIHRoYW5rcyE8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxicj5FcmljPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+QW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1139sjceml521mbxchi_-- From nobody Tue Dec 5 12:35: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 5920C126DFF for ; Tue, 5 Dec 2017 12:35:17 -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 bp0yajN3U9DX for ; Tue, 5 Dec 2017 12:35:14 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6901C12025C for ; Tue, 5 Dec 2017 12:35:14 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D0F35A5DB8B95 for ; Tue, 5 Dec 2017 20:35:10 +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; Tue, 5 Dec 2017 20:35:12 +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; Tue, 5 Dec 2017 12:35:03 -0800 From: Alexander Clemm To: Martin Bjorklund , "andy@yumaworks.com" CC: "netconf@ietf.org" Thread-Topic: [Netconf] yang-push issue: error handling Thread-Index: AQHTaubADOTUW5LGwkKD+sraYMgQfKMzrq2AgABIa4CAATJtIIAAkRyAgAAD2ID//3rSEA== Date: Tue, 5 Dec 2017 20:35:03 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1165@sjceml521-mbx.china.huawei.com> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD10E9@sjceml521-mbx.china.huawei.com> <20171205.212443.660483858000758249.mbj@tail-f.com> In-Reply-To: <20171205.212443.660483858000758249.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.216.169] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Netconf] yang-push issue: error handling 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, 05 Dec 2017 20:35:17 -0000 SGkgTWFydGluLA0KDQpTdXJlLCB0aGUgZXZlbnR1YWwgc29sdXRpb24gbWF5IG1ha2UgdXNlIG9m IHJwYy1lcnJvciBhZ2Fpbi4gIEJ1dCB1bnRpbCB3ZSBnZXQgdGhlcmUsIHRoZSBjdXJyZW50bHkg cHJvcG9zZWQgc29sdXRpb24gc2VlbXMgdG8gbWFrZSBzZW5zZSB0byBtZS4gIEkgZG9uJ3QgdGhp bmsgd2UgaGF2ZSBhbiBpc3N1ZSB0b2RheSB3aXRoIGxvdHMgb2YgUlBDcyBlYWNoIGRlZmluaW5n IHRoZWlyIG93biB3YXkgb2YgZGVhbGluZyB3aXRoIGNvcm5lciBjb25kaXRpb25zIC0gZGVmaW5p dGlvbiBvZiBSUENzIGlzIHNvbWV0aGluZyB0aGF0IGhhcyBzbyBmYXIgb25seSByYXJlbHkgYmVl biBleGVyY2lzZWQgd2l0aCBZQU5HIG1vZGVscy4gIE9uY2UgdGhpcyBiZWNvbWVzIG1vcmUgY29t bW9uLCBJIGFtIHN1cmUgd2Ugd2lsbCBmaW5kIGEgbW9yZSBnZW5lcmFsIHNvbHV0aW9uLCBidXQg SSBkb24ndCB0aGluayB3ZSBhcmUgYXQgdGhhdCBwb2ludC4gDQoNCi0tLSBBbGV4IA0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hcnRpbiBCam9ya2x1bmQgW21haWx0 bzptYmpAdGFpbC1mLmNvbV0NCj4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDUsIDIwMTcgMTI6 MjUgUE0NCj4gVG86IGFuZHlAeXVtYXdvcmtzLmNvbQ0KPiBDYzogQWxleGFuZGVyIENsZW1tIDxh bGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbT47IG5ldGNvbmZAaWV0Zi5vcmcNCj4gU3ViamVjdDog UmU6IFtOZXRjb25mXSB5YW5nLXB1c2ggaXNzdWU6IGVycm9yIGhhbmRsaW5nDQo+IA0KPiBBbmR5 IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6DQo+ID4gSGksDQo+ID4NCj4gPiBU aGUgcHJvdG9jb2wgZGVmaW5lcyBob3cgZXJyb3IgaGFuZGxpbmcgaXMgZG9uZSwgbm90IHRoZSBp bmRpdmlkdWFsDQo+ID4gb3BlcmF0aW9ucy4NCj4gPiBJZiB0aGUgcmVxdWVzdCBmYWlscywgdGhl biBjbGllbnRzIGV4cGVjdCBhbiA8cnBjLWVycm9yPiBhbmQgc2VydmVycw0KPiA+IGFyZSBkZXNp Z25lZCB0byBzZW5kIGFuIDxycGMtZXJyb3I+IHdoZW4gYSBjbGllbnQgcmVxdWVzdCBmYWlscy4N Cj4gDQo+IEFncmVlZCwgYW5kIGZvciBSRVNUQ09ORiwgdGhlIEhUVFAgZXJyb3IgY29kZXMgYXJl IHVzZWQuICBBbiBIVFRQIHJlcXVlc3QNCj4gdGhhdCBmYWlscyBkb2VzIG5vdCByZXR1cm4gMjAw IG9rIHdpdGggYSBib2R5IHRoYXQgZXhwbGFpbnMgdGhhdCBpdCBhY3R1YWxseSB3YXMNCj4gYW4g ZXJyb3IuDQo+IA0KPiA+IElNTywgYSBzZXBhcmF0ZSBlcnJvciBoYW5kbGluZyBwcm9jZWR1cmUg Zm9yIGVhY2ggUlBDIGlzIG1vcmUgY2x1bmt5DQo+ID4gdGhhbiBlcnJvci1pbmZvLg0KPiANCj4g KzENCj4gDQo+IFNvbWUgYWRkaXRpb25hbCBjb21tZW50cyBpbmxpbmUuDQo+IA0KPiANCj4gPiA+ IFdoaWxlIHBvc3NpYmxlLCB0aGUgc29sdXRpb24gb2YgaGF2aW5nIHRvIHJldHVybiBycGMtZXJy b3IgZXRjIGRvZXMNCj4gPiA+IHN0cmlrZSBtZSBhcyBzb21ld2hhdCBjbHVua3kuICBXaGlsZSBp dCBpcyBwb3NzaWJsZSB0byBhZGQgYW4NCj4gPiA+IGVycm9yLWFwcC10YWcsIGFuZCBuZWdvdGlh dGlvbiBzdHVmZiBhcyBlcnJvci1pbmZvIChhbmQgSSBhcHByZWNpYXRlDQo+ID4gPiB0aGUgc3Vn Z2VzdGlvbiksIHRoYXQgc29sdXRpb24gd291bGQgbmVlZCB0byBiZSBkZXNjcmliZWQgdXNpbmcg YQ0KPiA+ID4gbG90IG9mIHByb3NlIGluIGRlc2NyaXB0aW9uIHN0YXRlbWVudHMgYSBsYSBTTUl2 MiAocHJlc3VtYWJseSBhcw0KPiA+ID4gcGFydCBvZiB0aGUgUlBDIGRlc2NyaXB0aW9uLCBub3Qg YXMgcGFydCBvZiBlLmcuIHRoZSBpZGVudGl0aWVzLA0KPiA+ID4gd2hpY2ggbWlnaHQgYmUgdXNl ZCBpbiBhIG51bWJlciBvZiBwbGFjZXMsIG5vdCBqdXN0IHRoZSBlcnJvci1hcHAtdGFnKS4NCj4g DQo+IElmIGJvdGggdGhlIGVycm9yIGNvZGUgYW5kIGhpbnQgaXMgZGVmaW5lZCBpbiBhIHlhbmct ZGF0YSAoaS5lLiwgbm90IHVzaW5nIHRoZQ0KPiBlcnJvci1hcHAtdGFnKSwgeW91IHdvdWxkIGRv Og0KPiANCj4gICB5eDp5YW5nLWRhdGEgc3Vic2NyaXB0aW9uLWVycm9yIHsNCj4gICAgIGNvbnRh aW5lciBzdWJzY3JpcHRpb24tZXJyb3Igew0KPiAgICAgICBsZWFmIGVycm9yLWNvZGUgew0KPiAg ICAgICAgIHR5cGUgaWRlbnRpdHkgew0KPiAgICAgICAgICAgYmFzZSBlcnJvcjsNCj4gICAgICAg ICB9DQo+ICAgICAgIH0NCj4gICAgICAgY29udGFpbmVyIGhpbnRzIHsgLi4uIH0NCj4gICAgIH0N Cj4gICB9DQo+IA0KPiBUaGVuIHlvdSBhcmUgcmlnaHQsIHlvdSBoYXZlIHRvIGRlc2NyaWJlIGlu IHByb3NlIHRoYXQgdGhpcyB5YW5nLWRhdGENCj4gc3RydWN0dXJlIGNhbiBiZSBzZW50IGFzIGVy cm9yLWluZm8uDQo+IA0KPiANCj4gPiA+IEkgYW0gbm90IHN1cmUgd2h5IHRoYXQgd291bGQgbWFr ZSBhbiBSUEMgYW55IGVhc2llciB0byBpbXBsZW1lbnQuDQo+ID4gPiBUaGUgc2FtZSBjaGVja3Mg c3RpbGwgaGF2ZSB0byBiZSBtYWRlLg0KPiANCj4gQWdyZWVkLg0KPiANCj4gPiA+IFdoeSB3b3Vs ZCB0aGUgcHJvcG9zZWQgc29sdXRpb24gbm90IGFjY2VwdGFibGU/ICAgSWRlYWxseSBZQU5HIHdv dWxkDQo+ID4gPiBwcm92aWRlIGJldHRlciBzdXBwb3J0IHRvIGZvcm1hbGx5IGRlZmluZSBhcHBs aWNhdGlvbi9SUEMtc3BlY2lmaWMNCj4gPiA+IHJldHVybiBjb2RlcyBhbmQgY29ybmVyIGNvbmRp dGlvbnMgZXRjLg0KPiANCj4gQWxzbyBhZ3JlZWQuICBCdXQgb25jZSB3ZSBoYXZlIHRoYXQsIHN1 Y2ggYSBzb2x1dGlvbiB3b3VsZCBtYWtlIHVzZSBvZiB0aGUNCj4gcnBjLWVycm9yIHdlIGhhdmUg KGZvciBib3RoIE5FVENPTkYgYW5kIFJFU1RDT05GKS4NCj4gDQo+IA0KPiAvbWFydGluDQo+IA0K PiANCj4gPiA+IFNob3J0IG9mIHRoYXQsIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBvZiBhZGRpbmcg UlBDIG91dHB1dCBwYXJhbWV0ZXJzDQo+ID4gPiB0aGF0IGFyZSB1c2VkIGZvciB0aGUgcHVycG9z ZSBvZiBpbmRpY2F0aW5nIHdoYXQgaXMgZ29pbmcgb24gYXQgdGhlDQo+ID4gPiBhcHBsaWNhdGlv biBsZXZlbCBzaW1wbHkgbWFrZXMgdGhlbSBwYXJ0IG9mIHRoZSBzZW1hbnRpY3Mgb2YgdGhlDQo+ ID4gPiBzcGVjaWZpYyBSUEMgaXRzZWxmLiAgSXQgaXMgbm90IE5ldGNvbmbigJlzIHJvbGUgdG8g ZGVmaW5lIHdoYXQgYW4gUlBDDQo+ID4gPiBjYW4gb3IgY2Fubm90IGRvLCBqdXN0IGxpa2UgaXQg Y2Fubm90IGRlZmluZSB3aGF0IGEgcGFydGljdWxhciBsZWFmDQo+ID4gPiBtYXkgb3IgbWF5IG5v dCByZXByZXNlbnQuICBUaGF0IGlzIHBhcnQgb2YgdGhlIFJQQyBkZWZpbml0aW9uLg0KPiA+ID4N Cj4gPiA+DQo+ID4gPg0KPiA+ID4gQmFzaWNhbGx5LCB3aGF0IHdlIGFyZSBkaXNjdXNzaW5nIGhl cmUgaXMgYmVoYXZpb3Igb2Ygc3Vic2NyaXB0aW9uDQo+ID4gPiBjb25maWd1cmF0aW9uIHVuZGVy IGNvcm5lciBjb25kaXRpb25zLiAgVGhlIGZhY3QgdGhhdCBubw0KPiA+ID4gc3Vic2NyaXB0aW9u IGlzIGNyZWF0ZWQgYmVjYXVzZSBpdCB3b3VsZCByZXN1bHQgaW4gYW4gdW5hY2NlcHRhYmxlDQo+ ID4gPiB2b2x1bWUgb2YgdXBkYXRlcyBmb3IgYSBzcGVjaWZpYyBpbXBsZW1lbnRhdGlvbiBpcyBk aWZmZXJlbnQgZnJvbSBhbg0KPiA+ID4gZXJyb3IgY29uZGl0aW9uIHN1Y2ggYXMgYSBtYWxmb3Jt ZWQgbWVzc2FnZSB0aGF0IGlzIG1pc3NpbmcgYQ0KPiA+ID4gcmVxdWlyZWQgbWVzc2FnZS1pZCwg b3Igd2hlcmUgYSB2YWx1ZSB2aW9sYXRlcyBhIGNvbnN0cmFpbnQNCj4gPiA+IHNwZWNpZmllZCBp biBhIE1VU1QtY29uZGl0aW9uLiAgSW4gb3VyIGNhc2UsIHdoYXQgaXMgYmVpbmcgZGVzY3JpYmVk IGFyZQ0KPiBzcGVjaWZpYyBjb25kaXRpb25zIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciwgYWJv dmUgdGhlDQo+ID4gPiBOZXRjb25mL1Jlc3Rjb25mIGdlbmVyaWMgdmFsaWRhdGlvbiBpbmZyYXN0 cnVjdHVyZS4gICBUaGUgb3BlcmF0aW9uIGRvZXMNCj4gPiA+IG5vdCDigJx3b3Jr4oCdIGluIHRo ZSBzZW5zZSB0aGF0IGl0IGRvZXMgbm90IHJlc3VsdCBpbiBhbiBhY3RpdmUNCj4gPiA+IHN1YnNj cmlwdGlvbiwgYnV0IGl0IGRvZXMgd29yayBpbiB0aGUgc2Vuc2UgdGhhdCB0aGUgYmVoYXZpb3Ig aXMNCj4gPiA+IHZlcnkgd2VsbCBkZWZpbmVkIGluIHRlcm1zIG9mIHRoZSBlZmZlY3QgdGhhdCB0 aGUgUlBDIGhhcyAoaS5lLiB0aGUNCj4gPiA+IGVmZmVjdCBpcyB0aGF0IGl0IHJlc3VsdCBpbiBj cmVhdGlvbiBvZiBhIHN1YnNjcmlwdGlvbiwgaWYgY2VydGFpbg0KPiA+ID4gY29uZGl0aW9ucyBh cmUgbWV0LCBhbmQgaXQgZG9lcyBub3QgcmVzdWx0IGluIGNyZWF0aW9uIG9mIGENCj4gPiA+IHN1 YnNjcmlwdGlvbiBpbiBjYXNlIGNlcnRhaW4gY29uZGl0aW9ucyBhcmUgbm90IG1ldCkuICBXaHkg c2hvdWxkDQo+ID4gPiBOZXRjb25mIHJlc3RyaWN0IHdoYXQgYW4gUlBDIGNhbiBvciBjYW5ub3Qg ZG8/ICBUaGlzIGlzIGFsbCBhcHBsaWNhdGlvbi0NCj4gc3BlY2lmaWMuDQo+ID4gPg0KPiA+ID4N Cj4gPiA+DQo+ID4gPiAtLS0gQWxleA0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+ DQo+ID4gPiAqRnJvbToqIE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmdd ICpPbiBCZWhhbGYgT2YNCj4gPiA+ICpBbmR5IEJpZXJtYW4NCj4gPiA+ICpTZW50OiogTW9uZGF5 LCBEZWNlbWJlciAwNCwgMjAxNyA5OjE1IEFNDQo+ID4gPiAqVG86KiBNYXJ0aW4gQmpvcmtsdW5k IDxtYmpAdGFpbC1mLmNvbT4NCj4gPiA+ICpDYzoqIE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc+ DQo+ID4gPiAqU3ViamVjdDoqIFJlOiBbTmV0Y29uZl0geWFuZy1wdXNoIGlzc3VlOiBlcnJvciBo YW5kbGluZw0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4N Cj4gPiA+IE9uIE1vbiwgRGVjIDQsIDIwMTcgYXQgNDo1NSBBTSwgTWFydGluIEJqb3JrbHVuZCA8 bWJqQHRhaWwtZi5jb20+DQo+IHdyb3RlOg0KPiA+ID4NCj4gPiA+IEFuZHkgQmllcm1hbiA8YW5k eUB5dW1hd29ya3MuY29tPiB3cm90ZToNCj4gPiA+ID4gSGksDQo+ID4gPiA+DQo+ID4gPiA+IElN TyB0aGUgc3BlY2lhbCBlcnJvciBoYW5kbGluZyBpbiBZQU5HIFB1c2ggaXMgbm90IGFjY2VwdGFi bGUNCj4gPiA+ID4gYmVjYXVzZSBpdCB2aW9sYXRlcyBORVRDT05GIGFuZCBSRVNUQ09ORiBlcnJv ciBoYW5kbGluZyBwcm9jZWR1cmVzLg0KPiA+ID4gPiBORVRDT05GIHNheXMgaWYgdGhlIG9wZXJh dGlvbiBkb2VzIG5vdCB3b3JrIGZvciBhbnkgcmVhc29uIGFuDQo+ID4gPiA+IDxycGMtZXJyb3I+ IGVsZW1lbnQgU0hPVUxEIGJlIHJldHVybmVkLg0KPiA+ID4NCj4gPiA+IEkgZnVsbHkgYWdyZWUs IGFuZCBJIGhhdmUgcG9pbnRlZCB0aGlzIG91dCBzZXZlcmFsIHRpbWVzIGluIG15DQo+ID4gPiBy ZXZpZXdzLiAgVGhlIHByb2JsZW0gaXMgYWN0dWFsbHkgaW4gc3Vic2NyaWJlZCBub3RpZmljYXRp b25zLCBhbmQgSQ0KPiA+ID4gdGhpbmsgRXJpYyBpcyB0cmFja2luZyB0aGF0IGlzc3VlLg0KPiA+ ID4NCj4gPiA+IFRyeWluZyB0byBiZSBjb25zdHJ1Y3RpdmUsIEkgdGhpbmsgdGhhdCB0aGUgZXhp c3RpbmcgbWVjaGFuaXNtcyBpbg0KPiA+ID4gWUFORyBjYW4gYmUgdXNlZCB0byBhY2hpZXZlIHRo ZSBzYW1lIGZ1bmN0aW9uYWxpdHkgdGhhdCB0aGVzZSBkcmFmdHMNCj4gPiA+IHRyeSB0byBhY2hp ZXZlLiAgU3BlY2lmaWNhbGx5Og0KPiA+ID4NCj4gPiA+ICAgMS4gVXNlIGlkZW50aXRpZXMganVz dCBsaWtlIHRoZSBvbmVzIHlvdSBoYXZlDQo+ID4gPiAgICAgICgidW5zdXBwb3J0YWJsZS12b2x1 bWUiLCAiZmlsdGVyLXVuYXZhaWxhYmxlIiBldGMpLCBidXQgYWRkIHRleHQNCj4gPiA+ICAgICAg dGhhdCBleHBsYWlucyB0aGF0IHRoZXNlIGlkZW50aXRpZXMgYXJlIHNlbnQgYXMgImVycm9yLWFw cC10YWciDQo+ID4gPiAgICAgIGluICJycGMtZXJyb3IiLCBlbmNvZGVkIHRvIGEgc3RyaW5nIGFz IDxtb2R1bGU+OjxpZGVudGl0eT4uICBUaGlzDQo+ID4gPiAgICAgIHdvcmtzIGZvciBib3RoIE5F VENPTkYgYW5kIFJFU1RDT05GLg0KPiA+ID4NCj4gPiA+ICAgMi4gRm9yIHRoZSAiaGludHMiIGV4 dHJhIGluZm8gdGhhdCB5b3UgcmV0dXJuLCBkZWZpbmUgYSAieWFuZy1kYXRhIg0KPiA+ID4gICAg ICBzdHJ1Y3R1cmUgd2l0aCB0aGUgaGludHMsIGFuZCBleHBsYWluIGluIHRleHQgdGhhdCB0aGlz IHN0cnVjdHVyZQ0KPiA+ID4gICAgICBpcyByZXR1cm5lZCBpbiAiZXJyb3ItaW5mbyIuICBUaGlz IHdvcmtzIGZvciBib3RoIE5FVENPTkYgYW5kDQo+ID4gPiAgICAgIFJFU1RDT05GLg0KPiA+ID4N Cj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiArMQ0KPiA+ID4NCj4gPiA+DQo+ID4g Pg0KPiA+ID4gSWYgdGhlIGVycm9yIGhhbmRsaW5nIHdhcyBkb25lIGNvcnJlY3RseSB0aGVuIHRo ZSBzYW1lIHByb2NlZHVyZXMNCj4gPiA+IGNvdWxkIGJlDQo+ID4gPg0KPiA+ID4gYXBwbGllZCB0 byA8ZWRpdC1jb25maWc+IGZhaWx1cmVzIGZvciBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMuDQo+ ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBBcyBhbiBhbHRl cm5hdGl2ZSB0byAxLCB5b3UgY2FuIHB1dCB0aGUgZXJyb3IgaWRlbnRpdGl5cmVmIGluIHRoZQ0K PiA+ID4gInlhbmctZGF0YSIgc3RydWN0dXJlLCBhbmQgc2VuZCBib3RoIHRoZSBpZGVudGl0aXly ZWYgYW5kIGhpbnRzIGluDQo+ID4gPiAiZXJyb3ItaW5mbyIuDQo+ID4gPg0KPiA+ID4NCj4gPiA+ IC9tYXJ0aW4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gQW5keQ0K PiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gPiBUaGUgPGVz dGFibGlzaC1zdWJzY3JpcHRpb24+IHJldHVybnMgZGF0YSBldmVuIG9uIGVycm9yLg0KPiA+ID4g PiBJbnN0ZWFkIG9mIHRoZSBjb21tb24gZXJyb3ItdGFnLCBlcnJvci1pbmZvLCBhbmQgb3RoZXIg ZmllbGRzLA0KPiA+ID4gPiB0aGVyZSBpcyBhIHN1YnNjcmlwdGlvbi1yZXN1bHQgbGVhZi4NCj4g PiA+ID4NCj4gPiA+ID4gSWYgYW55IGNsaWVudCAob3IgZXZlbiBzZXJ2ZXIpIGZ1bmN0aW9uYWxp dHkgdXNlcyB0aGUgTkVUQ09ORiBhbmQNCj4gPiA+ID4gUkVTVENPTkYgc3RhbmRhcmQgZXJyb3Ig aGFuZGxpbmcsIHRoZW4gc3Vic2NyaXB0aW9uLXJlc3VsdCB3aWxsDQo+ID4gPiA+IG5vdCBiZSBz ZW50IG9yIGV4cGVjdGVkIGFzIGFuIGVycm9yIHJlc3BvbnNlLiBEZXBlbmRpbmcgb24gdGhlDQo+ ID4gPiA+IHNlcnZlciBpbXBsZW1lbnRhdGlvbiwgdGhlIGNvZGUgdGhhdCBrbm93cyBhYm91dA0K PiA+ID4gPiBlc3RhYmxpc2gtc3Vic2NyaXB0aW9uIG1heSBub3QgZ2V0IGNhbGxlZCBiZWNhdXNl IGNvbW1vbiBlcnJvcg0KPiA+ID4gPiBoYW5kbGluZyBjb2RlIGhhcyBhbHJlYWR5IGRldGVybWlu ZWQgdGhlcmUgaXMgYW4gPHJwYy1lcnJvcj4gdG8NCj4gPiA+ID4gc2VuZCBpbnN0ZWFkIG9mIGEg ZGF0YSByZXNwb25zZS4NCj4gPiA+ID4NCj4gPiA+ID4gRXhwZWN0IHRoYXQgc29tZSBzZXJ2ZXJz IGFyZSBuZXZlciBnb2luZyB0byBzZW5kIGRhdGEgb24gYW4NCj4gPiA+ID4gb3BlcmF0aW9uIGZh aWx1cmUsIGFuZCB3aWxsIG9ubHkgc2VuZCA8cnBjLWVycm9yPiBpbnN0ZWFkLg0KPiA+ID4gPg0K PiA+ID4gPg0KPiA+ID4gPiA+RnJvbSBzZWMuIDMuODoNCj4gPiA+ID4NCj4gPiA+ID4gICAgRm9y IGluc3RhbmNlLCBmb3IgdGhlIGZvbGxvd2luZyByZXF1ZXN0Og0KPiA+ID4gPg0KPiA+ID4gPiA8 bmV0Y29uZjpycGMgbWVzc2FnZS1pZD0iMTAxIg0KPiA+ID4gPiAgICB4bWxuczpuZXRjb25mPSJ1 cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiPg0KPiA+ID4gPiAgICA8ZXN0 YWJsaXNoLXN1YnNjcmlwdGlvbg0KPiA+ID4gPiAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFt czp4bWw6bnM6eWFuZzppZXRmLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyINCj4gPiA+ID4gICAg ICAgIHhtbG5zOnlwPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi15YW5nLXB1c2gi Pg0KPiA+ID4gPiAgICAgICA8eXA6ZGF0YXN0b3JlPg0KPiA+ID4gPiAgICAgICAgIDx5cDpzb3Vy Y2UgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLWRhdGFzdG9yZXMiPg0K PiA+ID4gPiAgICAgICAgICAgb3BlcmF0aW9uYWwNCj4gPiA+ID4gICAgICAgICA8L3lwOnNvdXJj ZT4NCj4gPiA+ID4gICAgICAgICA8eXA6c3VidHJlZS1maWx0ZXIgbmV0Y29uZjp0eXBlPSJ4cGF0 aCINCj4gPiA+ID4gICAgICAgICAgICAgeG1sbnM6ZXg9Imh0dHA6Ly9leGFtcGxlLmNvbS9zYW1w bGUtZGF0YS8xLjAiDQo+ID4gPiA+ICAgICAgICAgICAgIHNlbGVjdD0iL2V4OmZvbyIvPg0KPiA+ ID4gPiAgICAgICA8L3lwOmRhdGFzdG9yZT4NCj4gPiA+ID4gICAgICAgPHlwOnBlcmlvZD41MDA8 L3lwOnBlcmlvZD4NCj4gPiA+ID4gICAgPC9lc3RhYmxpc2gtc3Vic2NyaXB0aW9uPg0KPiA+ID4g PiA8L25ldGNvbmY6cnBjPg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgICAgICAgICAgICAgIEZpZ3Vy ZSAzOiBFc3RhYmxpc2gtU3Vic2NyaXB0aW9uIGV4YW1wbGUNCj4gPiA+ID4NCj4gPiA+ID4gICAg dGhlIHB1Ymxpc2hlciBtaWdodCByZXR1cm46DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IDxy cGMtcmVwbHkgbWVzc2FnZS1pZD0iMTAxIg0KPiA+ID4gPiAgICAgIHhtbG5zPSJ1cm46aWV0Zjpw YXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiPg0KPiA+ID4gPiAgICA8c3Vic2NyaXB0aW9u LXJlc3VsdA0KPiA+ID4gPiAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFu ZzppZXRmLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyINCj4gPiA+ID4gICAgICAgIHhtbG5zOnlw PSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi15YW5nLXB1c2giPg0KPiA+ID4gPiAg ICAgIHlwOnBlcmlvZC11bnN1cHBvcnRlZA0KPiA+ID4gPiAgICA8L3N1YnNjcmlwdGlvbi1yZXN1 bHQ+DQo+ID4gPiA+ICAgIDxwZXJpb2QtaGludCB4bWxuczoidXJuOmlldGY6cGFyYW1zOnhtbDpu czp5YW5nOmlldGYteWFuZy1wdXNoIj4NCj4gPiA+ID4gICAgICAgMjAwMA0KPiA+ID4gPiAgICA8 L3BlcmlvZC1oaW50Pg0KPiA+ID4gPiA8L3JwYy1yZXBseT4NCj4gPiA+ID4NCj4gPiA+ID4gICAg ICAgICAgICAgICAgICAgICAgRmlndXJlIDQ6IEVycm9yIHJlc3BvbnNlIGV4YW1wbGUNCj4gPiA+ ID4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gQlRXLCBhbGwgdGhlIGZpbHRlciBleGFtcGxl cyBzZWVtIHRvIGJlIHdyb25nLCBpbmNsdWRpbmcgdGhlIG9uZQ0KPiA+ID4gPiBhYm92ZQ0KPiA+ ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBPTEQ6DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAgPHlw OnN1YnRyZWUtZmlsdGVyIG5ldGNvbmY6dHlwZT0ieHBhdGgiDQo+ID4gPiA+ICAgICAgICAgICAg IHhtbG5zOmV4PSJodHRwOi8vZXhhbXBsZS5jb20vc2FtcGxlLWRhdGEvMS4wIg0KPiA+ID4gPiAg ICAgICAgICAgICBzZWxlY3Q9Ii9leDpmb28iLz4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4g TkVXOg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgICAgIDx5cDpzdWJ0cmVlLWZpbHRl cj4NCj4gPiA+ID4gICAgICAgICAgICA8ZXg6Zm9vIHhtbG5zOmV4PSJodHRwOi8vZXhhbXBsZS5j b20vc2FtcGxlLWRhdGEvMS4wIg0KPiA+ID4gPiAvPg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgICAg IDwveXA6c3VidHJlZS1maWx0ZXI+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IEFuZHkNCj4g PiA+DQo+ID4gPg0KPiA+ID4NCg== From nobody Tue Dec 5 12:56: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 0D8221270AE for ; Tue, 5 Dec 2017 12:56:05 -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 cjW1ve69J8DK for ; Tue, 5 Dec 2017 12:55:59 -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 C5D0A126DCA for ; Tue, 5 Dec 2017 12:55:58 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id 74so1876018lfs.0 for ; Tue, 05 Dec 2017 12:55: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=iBHVkYxY82notby0v2fPl+vEmAj7/1cfMEU+qltXjHA=; b=ZABO7Zyt2ARCZk68Xy+jz3pQOfRmjmBqaLi0xsHekMYvdUpASNHT3XB6cmmDk4K3ch 90Pd1ZiD7OO+nIEeMpNjspJB3DDwq6yvzEzx6O5QP4PhoSw+rbaHM8JaqF+lw4Cj8qsp TvUVVC7kdCbWCXXaBRor+Qs9/Wy0hRKDStjXZP/xylbxhekHILbjk+vEP/WsFT2hrs20 lNuE/oeDOqvaIMTu8vWVVQECwHWMY0fGd4by8oVhOQ3Rf6Rps64sra17V3dLQh693rAj pLjBzzzPhm3vOZYrUdhXjP+Aq/wqHItczkBYtbGmyijmtcGfpPt4kUkVD6dJGS4L3Yiy UM+g== 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=iBHVkYxY82notby0v2fPl+vEmAj7/1cfMEU+qltXjHA=; b=XWzhz40cP5PCeFmJXF9CSQqHk/O+yB0wE3MGm18WQncM2oflfZOVQRtvxUj4+HUES6 i4Jek3OKM5itpCspRRZR0gv3oNXQg7agtz3ShhqzqX3hjuAfz4w2kVMXwwv+K+D+F6/4 y94TYxcuQCed3Yfkys1ldykKkARyhxHQx4F0Rv1+3eHdHNPO2y8F8x0vRiqlB7SJjS7q bGh3GC704UQC8enKAbQdNgucx2HtKu7/Ke+rfbY4dHp7di8d/ZDR4rBF6ElcSTIxG/rq ZZQ6AkHtVxxAe6YHCpeX0wx3IepNRgUxZcX39was8fz2ZM1DdFRJJyH5WanYjYmajRHg 915w== X-Gm-Message-State: AJaThX6BB1HZUx1TFPT7SUi0E1VOcjqgS5h6FidZjc2NTs8MeSbftiot 3a0dcMEZJTE2oUkpKTjjTupRJUGYDjd0JnEbcyQRwA== X-Google-Smtp-Source: AGs4zMaRycv0kw3iLJVkyyVMoEQIBn+bNdXFJvF4icXHKVUVdDbDLH6CkqAA/rxEAOp8ijqoTRNwAW/9xPcQIqQPZ6I= X-Received: by 10.25.78.91 with SMTP id c88mr9840583lfb.4.1512507357015; Tue, 05 Dec 2017 12:55:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Tue, 5 Dec 2017 12:55:56 -0800 (PST) In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1165@sjceml521-mbx.china.huawei.com> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD10E9@sjceml521-mbx.china.huawei.com> <20171205.212443.660483858000758249.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1165@sjceml521-mbx.china.huawei.com> From: Andy Bierman Date: Tue, 5 Dec 2017 12:55:56 -0800 Message-ID: To: Alexander Clemm Cc: Martin Bjorklund , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1cdbb6bc4886055f9e0f06" Archived-At: Subject: Re: [Netconf] yang-push issue: error handling 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, 05 Dec 2017 20:56:05 -0000 --94eb2c1cdbb6bc4886055f9e0f06 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Dec 5, 2017 at 12:35 PM, Alexander Clemm wrote: > Hi Martin, > > Sure, the eventual solution may make use of rpc-error again. But until w= e > get there, the currently proposed solution seems to make sense to me. I > don't think we have an issue today with lots of RPCs each defining their > own way of dealing with corner conditions - definition of RPCs is somethi= ng > that has so far only rarely been exercised with YANG models. Once this > becomes more common, I am sure we will find a more general solution, but = I > don't think we are at that point. > > It is not an issue because all the other YANG modules follow the rule that data is only returned from an RPC or action if the request worked. NETCONF and RESTCONF indicate errors in a specific manner which can be done with common code because the protocol level (not the application level) defines the error handling procedures. > --- Alex > Andy > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Tuesday, December 05, 2017 12:25 PM > > To: andy@yumaworks.com > > Cc: Alexander Clemm ; netconf@ietf.org > > Subject: Re: [Netconf] yang-push issue: error handling > > > > Andy Bierman wrote: > > > Hi, > > > > > > The protocol defines how error handling is done, not the individual > > > operations. > > > If the request fails, then clients expect an and servers > > > are designed to send an when a client request fails. > > > > Agreed, and for RESTCONF, the HTTP error codes are used. An HTTP reque= st > > that fails does not return 200 ok with a body that explains that it > actually was > > an error. > > > > > IMO, a separate error handling procedure for each RPC is more clunky > > > than error-info. > > > > +1 > > > > Some additional comments inline. > > > > > > > > While possible, the solution of having to return rpc-error etc does > > > > strike me as somewhat clunky. While it is possible to add an > > > > error-app-tag, and negotiation stuff as error-info (and I appreciat= e > > > > the suggestion), that solution would need to be described using a > > > > lot of prose in description statements a la SMIv2 (presumably as > > > > part of the RPC description, not as part of e.g. the identities, > > > > which might be used in a number of places, not just the > error-app-tag). > > > > If both the error code and hint is defined in a yang-data (i.e., not > using the > > error-app-tag), you would do: > > > > yx:yang-data subscription-error { > > container subscription-error { > > leaf error-code { > > type identity { > > base error; > > } > > } > > container hints { ... } > > } > > } > > > > Then you are right, you have to describe in prose that this yang-data > > structure can be sent as error-info. > > > > > > > > I am not sure why that would make an RPC any easier to implement. > > > > The same checks still have to be made. > > > > Agreed. > > > > > > Why would the proposed solution not acceptable? Ideally YANG woul= d > > > > provide better support to formally define application/RPC-specific > > > > return codes and corner conditions etc. > > > > Also agreed. But once we have that, such a solution would make use of > the > > rpc-error we have (for both NETCONF and RESTCONF). > > > > > > /martin > > > > > > > > Short of that, the proposed solution of adding RPC output parameter= s > > > > that are used for the purpose of indicating what is going on at the > > > > application level simply makes them part of the semantics of the > > > > specific RPC itself. It is not Netconf=E2=80=99s role to define wh= at an RPC > > > > can or cannot do, just like it cannot define what a particular leaf > > > > may or may not represent. That is part of the RPC definition. > > > > > > > > > > > > > > > > Basically, what we are discussing here is behavior of subscription > > > > configuration under corner conditions. The fact that no > > > > subscription is created because it would result in an unacceptable > > > > volume of updates for a specific implementation is different from a= n > > > > error condition such as a malformed message that is missing a > > > > required message-id, or where a value violates a constraint > > > > specified in a MUST-condition. In our case, what is being describe= d > are > > specific conditions at the application layer, above the > > > > Netconf/Restconf generic validation infrastructure. The operation > does > > > > not =E2=80=9Cwork=E2=80=9D in the sense that it does not result in = an active > > > > subscription, but it does work in the sense that the behavior is > > > > very well defined in terms of the effect that the RPC has (i.e. the > > > > effect is that it result in creation of a subscription, if certain > > > > conditions are met, and it does not result in creation of a > > > > subscription in case certain conditions are not met). Why should > > > > Netconf restrict what an RPC can or cannot do? This is all > application- > > specific. > > > > > > > > > > > > > > > > --- Alex > > > > > > > > > > > > > > > > > > > > > > > > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of > > > > *Andy Bierman > > > > *Sent:* Monday, December 04, 2017 9:15 AM > > > > *To:* Martin Bjorklund > > > > *Cc:* Netconf > > > > *Subject:* Re: [Netconf] yang-push issue: error handling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Dec 4, 2017 at 4:55 AM, Martin Bjorklund > > wrote: > > > > > > > > Andy Bierman wrote: > > > > > Hi, > > > > > > > > > > IMO the special error handling in YANG Push is not acceptable > > > > > because it violates NETCONF and RESTCONF error handling procedure= s. > > > > > NETCONF says if the operation does not work for any reason an > > > > > element SHOULD be returned. > > > > > > > > I fully agree, and I have pointed this out several times in my > > > > reviews. The problem is actually in subscribed notifications, and = I > > > > think Eric is tracking that issue. > > > > > > > > Trying to be constructive, I think that the existing mechanisms in > > > > YANG can be used to achieve the same functionality that these draft= s > > > > try to achieve. Specifically: > > > > > > > > 1. Use identities just like the ones you have > > > > ("unsupportable-volume", "filter-unavailable" etc), but add te= xt > > > > that explains that these identities are sent as "error-app-tag= " > > > > in "rpc-error", encoded to a string as :. > This > > > > works for both NETCONF and RESTCONF. > > > > > > > > 2. For the "hints" extra info that you return, define a "yang-dat= a" > > > > structure with the hints, and explain in text that this > structure > > > > is returned in "error-info". This works for both NETCONF and > > > > RESTCONF. > > > > > > > > > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > > > If the error handling was done correctly then the same procedures > > > > could be > > > > > > > > applied to failures for configured subscriptions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > As an alternative to 1, you can put the error identitiyref in the > > > > "yang-data" structure, and send both the identitiyref and hints in > > > > "error-info". > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The returns data even on error. > > > > > Instead of the common error-tag, error-info, and other fields, > > > > > there is a subscription-result leaf. > > > > > > > > > > If any client (or even server) functionality uses the NETCONF and > > > > > RESTCONF standard error handling, then subscription-result will > > > > > not be sent or expected as an error response. Depending on the > > > > > server implementation, the code that knows about > > > > > establish-subscription may not get called because common error > > > > > handling code has already determined there is an to > > > > > send instead of a data response. > > > > > > > > > > Expect that some servers are never going to send data on an > > > > > operation failure, and will only send instead. > > > > > > > > > > > > > > > >From sec. 3.8: > > > > > > > > > > For instance, for the following request: > > > > > > > > > > > > > > xmlns:netconf=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed- > notifications" > > > > > xmlns:yp=3D"urn:ietf:params:xml:ns:yang:ietf-yang-push"> > > > > > > > > > > yang:ietf-datastores"> > > > > > operational > > > > > > > > > > > > > > xmlns:ex=3D"http://example.com/sample-data/1.0" > > > > > select=3D"/ex:foo"/> > > > > > > > > > > 500 > > > > > > > > > > > > > > > > > > > > Figure 3: Establish-Subscription example > > > > > > > > > > the publisher might return: > > > > > > > > > > > > > > > > > > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed- > notifications" > > > > > xmlns:yp=3D"urn:ietf:params:xml:ns:yang:ietf-yang-push"> > > > > > yp:period-unsupported > > > > > > > > > > yang:ietf-yang-push"> > > > > > 2000 > > > > > > > > > > > > > > > > > > > > Figure 4: Error response example > > > > > > > > > > > > > > > > > > > > BTW, all the filter examples seem to be wrong, including the one > > > > > above > > > > > > > > > > > > > > > OLD: > > > > > > > > > > > > > > xmlns:ex=3D"http://example.com/sample-data/1.0" > > > > > select=3D"/ex:foo"/> > > > > > > > > > > > > > > > NEW: > > > > > > > > > > > > > > > > > > > > > > > > /> > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > --94eb2c1cdbb6bc4886055f9e0f06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Dec 5, 2017 at 12:35 PM, Alexander Clemm <= alexander.c= lemm@huawei.com> wrote:
Hi = Martin,

Sure, the eventual solution may make use of rpc-error again.=C2=A0 But unti= l we get there, the currently proposed solution seems to make sense to me.= =C2=A0 I don't think we have an issue today with lots of RPCs each defi= ning their own way of dealing with corner conditions - definition of RPCs i= s something that has so far only rarely been exercised with YANG models.=C2= =A0 Once this becomes more common, I am sure we will find a more general so= lution, but I don't think we are at that point.


It is not an issue because all the oth= er YANG modules follow the rule that
data is only returned from a= n RPC or action if the request worked.
NETCONF and RESTCONF indic= ate errors in a specific manner which
can be done with common cod= e because the protocol level (not the application level)
defines = the error handling procedures.

=C2=A0
--- Alex

Andy
=C2=A0

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@t= ail-f.com]
> Sent: Tuesday, December 05, 2017 12:25 PM
> To: andy@yumaworks.com
> Cc: Alexander Clemm <= alexander.clemm@huawei.com>; net= conf@ietf.org
> Subject: Re: [Netconf] yang-push issue: error handling
>
> Andy Bierman <andy@yumaworks.= com> wrote:
> > Hi,
> >
> > The protocol defines how error handling is done, not the individu= al
> > operations.
> > If the request fails, then clients expect an <rpc-error> an= d servers
> > are designed to send an <rpc-error> when a client request f= ails.
>
> Agreed, and for RESTCONF, the HTTP error codes are used.=C2=A0 An HTTP= request
> that fails does not return 200 ok with a body that explains that it ac= tually was
> an error.
>
> > IMO, a separate error handling procedure for each RPC is more clu= nky
> > than error-info.
>
> +1
>
> Some additional comments inline.
>
>
> > > While possible, the solution of having to return rpc-error e= tc does
> > > strike me as somewhat clunky.=C2=A0 While it is possible to = add an
> > > error-app-tag, and negotiation stuff as error-info (and I ap= preciate
> > > the suggestion), that solution would need to be described us= ing a
> > > lot of prose in description statements a la SMIv2 (presumabl= y as
> > > part of the RPC description, not as part of e.g. the identit= ies,
> > > which might be used in a number of places, not just the erro= r-app-tag).
>
> If both the error code and hint is defined in a yang-data (i.e., not u= sing the
> error-app-tag), you would do:
>
>=C2=A0 =C2=A0yx:yang-data subscription-error {
>=C2=A0 =C2=A0 =C2=A0container subscription-error {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf error-code {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type identity {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0base error;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0container hints { ... }
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
>
> Then you are right, you have to describe in prose that this yang-data<= br> > structure can be sent as error-info.
>
>
> > > I am not sure why that would make an RPC any easier to imple= ment.
> > > The same checks still have to be made.
>
> Agreed.
>
> > > Why would the proposed solution not acceptable?=C2=A0 =C2=A0= Ideally YANG would
> > > provide better support to formally define application/RPC-sp= ecific
> > > return codes and corner conditions etc.
>
> Also agreed.=C2=A0 But once we have that, such a solution would make u= se of the
> rpc-error we have (for both NETCONF and RESTCONF).
>
>
> /martin
>
>
> > > Short of that, the proposed solution of adding RPC output pa= rameters
> > > that are used for the purpose of indicating what is going on= at the
> > > application level simply makes them part of the semantics of= the
> > > specific RPC itself.=C2=A0 It is not Netconf=E2=80=99s role = to define what an RPC
> > > can or cannot do, just like it cannot define what a particul= ar leaf
> > > may or may not represent.=C2=A0 That is part of the RPC defi= nition.
> > >
> > >
> > >
> > > Basically, what we are discussing here is behavior of subscr= iption
> > > configuration under corner conditions.=C2=A0 The fact that n= o
> > > subscription is created because it would result in an unacce= ptable
> > > volume of updates for a specific implementation is different= from an
> > > error condition such as a malformed message that is missing = a
> > > required message-id, or where a value violates a constraint<= br> > > > specified in a MUST-condition.=C2=A0 In our case, what is be= ing described are
> specific conditions at the application layer, above the
> > > Netconf/Restconf generic validation infrastructure.=C2=A0 = =C2=A0The operation does
> > > not =E2=80=9Cwork=E2=80=9D in the sense that it does not res= ult in an active
> > > subscription, but it does work in the sense that the behavio= r is
> > > very well defined in terms of the effect that the RPC has (i= .e. the
> > > effect is that it result in creation of a subscription, if c= ertain
> > > conditions are met, and it does not result in creation of a<= br> > > > subscription in case certain conditions are not met).=C2=A0 = Why should
> > > Netconf restrict what an RPC can or cannot do?=C2=A0 This is= all application-
> specific.
> > >
> > >
> > >
> > > --- Alex
> > >
> > >
> > >
> > >
> > >
> > > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of
> > > *Andy Bierman
> > > *Sent:* Monday, December 04, 2017 9:15 AM
> > > *To:* Martin Bjorklund <mbj@tail-f.com>
> > > *Cc:* Netconf <netcon= f@ietf.org>
> > > *Subject:* Re: [Netconf] yang-push issue: error handling
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Dec 4, 2017 at 4:55 AM, Martin Bjorklund <mbj@tail-f.com>
> wrote:
> > >
> > > Andy Bierman <andy@= yumaworks.com> wrote:
> > > > Hi,
> > > >
> > > > IMO the special error handling in YANG Push is not acce= ptable
> > > > because it violates NETCONF and RESTCONF error handling= procedures.
> > > > NETCONF says if the operation does not work for any rea= son an
> > > > <rpc-error> element SHOULD be returned.
> > >
> > > I fully agree, and I have pointed this out several times in = my
> > > reviews.=C2=A0 The problem is actually in subscribed notific= ations, and I
> > > think Eric is tracking that issue.
> > >
> > > Trying to be constructive, I think that the existing mechani= sms in
> > > YANG can be used to achieve the same functionality that thes= e drafts
> > > try to achieve.=C2=A0 Specifically:
> > >
> > >=C2=A0 =C2=A01. Use identities just like the ones you have > > >=C2=A0 =C2=A0 =C2=A0 ("unsupportable-volume", "= ;filter-unavailable" etc), but add text
> > >=C2=A0 =C2=A0 =C2=A0 that explains that these identities are = sent as "error-app-tag"
> > >=C2=A0 =C2=A0 =C2=A0 in "rpc-error", encoded to a s= tring as <module>:<identity>.=C2=A0 This
> > >=C2=A0 =C2=A0 =C2=A0 works for both NETCONF and RESTCONF.
> > >
> > >=C2=A0 =C2=A02. For the "hints" extra info that you= return, define a "yang-data"
> > >=C2=A0 =C2=A0 =C2=A0 structure with the hints, and explain in= text that this structure
> > >=C2=A0 =C2=A0 =C2=A0 is returned in "error-info".= =C2=A0 This works for both NETCONF and
> > >=C2=A0 =C2=A0 =C2=A0 RESTCONF.
> > >
> > >
> > >
> > >
> > >
> > > +1
> > >
> > >
> > >
> > > If the error handling was done correctly then the same proce= dures
> > > could be
> > >
> > > applied to <edit-config> failures for configured subsc= riptions.
> > >
> > >
> > >
> > >
> > >
> > >
> > > As an alternative to 1, you can put the error identitiyref i= n the
> > > "yang-data" structure, and send both the identitiy= ref and hints in
> > > "error-info".
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > >
> > >
> > > Andy
> > >
> > >
> > >
> > >
> > >
> > >
> > > > The <establish-subscription> returns data even on= error.
> > > > Instead of the common error-tag, error-info, and other = fields,
> > > > there is a subscription-result leaf.
> > > >
> > > > If any client (or even server) functionality uses the N= ETCONF and
> > > > RESTCONF standard error handling, then subscription-res= ult will
> > > > not be sent or expected as an error response. Depending= on the
> > > > server implementation, the code that knows about
> > > > establish-subscription may not get called because commo= n error
> > > > handling code has already determined there is an <rp= c-error> to
> > > > send instead of a data response.
> > > >
> > > > Expect that some servers are never going to send data o= n an
> > > > operation failure, and will only send <rpc-error>= instead.
> > > >
> > > >
> > > > >From sec. 3.8:
> > > >
> > > >=C2=A0 =C2=A0 For instance, for the following request: > > > >
> > > > <netconf:rpc message-id=3D"101"
> > > >=C2=A0 =C2=A0 xmlns:netconf=3D"urn:ietf:params= :xml:ns:netconf:base:1.0">
> > > >=C2=A0 =C2=A0 <establish-subscription
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:param= s:xml:ns:yang:ietf-subscribed-notifications"
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:yp=3D"urn:ietf:pa= rams:xml:ns:yang:ietf-yang-push">
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:datastore>
> > > >=C2=A0 =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 =C2=A0operational
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</yp:source>
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:subtree-filter = netconf:type=3D"xpath"
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns:ex= =3D"http://example.com/sample-data/1.0"
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0select= =3D"/ex:foo"/>
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0</yp:datastore>
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:period>500</yp:p= eriod>
> > > >=C2=A0 =C2=A0 </establish-subscription>
> > > > </netconf:rpc>
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Figure 3: Establish-Subscription example
> > > >
> > > >=C2=A0 =C2=A0 the publisher might return:
> > > >
> > > >
> > > > <rpc-reply message-id=3D"101"
> > > >=C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:n= s:netconf:base:1.0">
> > > >=C2=A0 =C2=A0 <subscription-result
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:param= s:xml:ns:yang:ietf-subscribed-notifications"
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:yp=3D"urn:ietf:pa= rams:xml:ns:yang:ietf-yang-push">
> > > >=C2=A0 =C2=A0 =C2=A0 yp:period-unsupported
> > > >=C2=A0 =C2=A0 </subscription-result>
> > > >=C2=A0 =C2=A0 <period-hint xmlns:"urn:ietf:param= s:xml:ns:yang:ietf-yang-push">
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A02000
> > > >=C2=A0 =C2=A0 </period-hint>
> > > > </rpc-reply>
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Figure 4: Error response example
> > > >
> > > >
> > > >
> > > > BTW, all the filter examples seem to be wrong, includin= g the one
> > > > above
> > > >
> > > >
> > > > OLD:
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:subtree-filter = netconf:type=3D"xpath"
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns:ex= =3D"http://example.com/sample-data/1.0"
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0select= =3D"/ex:foo"/>
> > > >
> > > >
> > > > NEW:
> > > >
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:subtree-filter&= gt;
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <ex:foo xml= ns:ex=3D"http://example.com/sample-data/1.0" > > > > />
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</yp:subtree-filter= >
> > > >
> > > >
> > > > Andy
> > >
> > >
> > >

--94eb2c1cdbb6bc4886055f9e0f06-- From nobody Tue Dec 5 14:19: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 531DB128854 for ; Tue, 5 Dec 2017 14:19:53 -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 bLV1FE0LMVy9 for ; Tue, 5 Dec 2017 14:19:49 -0800 (PST) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A427126B6D for ; Tue, 5 Dec 2017 14:19:49 -0800 (PST) Received: by mail-lf0-x22d.google.com with SMTP id f13so2055026lff.12 for ; Tue, 05 Dec 2017 14:19: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=gRqUYU1Ey9sDRf8XXXb1BCAADW1Rf6/zfC08bXAsITM=; b=OgMB7JcrGJk0t4z2uV5f1R2hUJrVZpygeSK5uCt45Hma21sciOR7r6bSMizFCnw10J kfHzzq7TaWCv0q6/3HqbwQSHD4JzCqE4FBfccWLFAZT9sC+TF/50c/Z2BUNQ+orhwp9S B/M/v/Om7o/SAOAjkdSHzkNqU0wqTsCCtcT/DQoZwVEVF3oniKN3ozSoWEYlPeKdaaTn nAf7QpaYNzr0cOha6HAcS/TuBr09i1JjJs7lCdxFtXVJuE9hSCQ/kURws0sKZJ6x8Tc2 9iIeh2pYIO6qnMf0UKnnltNFOJJCweov/nZMQwZwogI4SNtE96PNfiaz/BQZzmT7+1UX ekJg== 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=gRqUYU1Ey9sDRf8XXXb1BCAADW1Rf6/zfC08bXAsITM=; b=p55MZfwejfq8zVTzviav3kiKSo6qhMtnHRanXOXHC++876jwJs65KLGjEDX5DAwxn6 D1U6BgsQqOpQzGzgsAg8KKLCPwhXqOOJETPiq+VPE+ShwA3JmsiWi4GZ6l7UHCPZZxMW 6Z+ZnS9KCbBeaqhdTMziuWL4t6yCvM0WngYltcjXrGviJ/Xmeen9rnvz1apSHANZWoqO AhzpglzvlDR/NlhbntMvnl6UelKwKB5IjqTQ0hIpqEjuEo6/eC/9EilTCobVVAQNy+A1 M4xRQK+9+vGc+4xrFEolOhc2HMIb4RJSX25tNnJiLf9K13t4VJzi7yPAEkmRPpmxNgBF B/Tw== X-Gm-Message-State: AJaThX5N9Fw3CzSy/VPgNxEiimimCPot6c82kMHhfTJaKtuc2TkBcI5O 3pRftibpfwaJ0JD0HOuRtQAuYdoYrSycnEAZFNwCJg== X-Google-Smtp-Source: AGs4zMYuy3B5bC2CkyCQ3Y7jqAmeNhMkw1Vkc7cxIDyqhDj9Mi/AxjW44bfnHJ82ycKtTRuH0nhYP+dKeviZhI4lGMk= X-Received: by 10.46.17.153 with SMTP id 25mr12085161ljr.36.1512512387379; Tue, 05 Dec 2017 14:19:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Tue, 5 Dec 2017 14:19:46 -0800 (PST) In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1165@sjceml521-mbx.china.huawei.com> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD10E9@sjceml521-mbx.china.huawei.com> <20171205.212443.660483858000758249.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1165@sjceml521-mbx.china.huawei.com> From: Andy Bierman Date: Tue, 5 Dec 2017 14:19:46 -0800 Message-ID: To: Alexander Clemm Cc: Martin Bjorklund , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1a615e918612055f9f3b1e" Archived-At: Subject: Re: [Netconf] yang-push issue: error handling 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, 05 Dec 2017 22:19:53 -0000 --94eb2c1a615e918612055f9f3b1e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Here is the problem with the YANG Push error handling. The response is a MUST, not a SHOULD: 4.3. Element The element is sent in messages if an error occurs during the processing of an request. If a server encounters multiple errors during the processing of an request, the MAY contain multiple elements. However, a server is not required to detect or report more than one element, if a request contains multiple errors. A server is not required to check for particular error conditions in a specific sequence. *A server MUST return an element if any error conditions occur during processing.* Andy On Tue, Dec 5, 2017 at 12:35 PM, Alexander Clemm wrote: > Hi Martin, > > Sure, the eventual solution may make use of rpc-error again. But until w= e > get there, the currently proposed solution seems to make sense to me. I > don't think we have an issue today with lots of RPCs each defining their > own way of dealing with corner conditions - definition of RPCs is somethi= ng > that has so far only rarely been exercised with YANG models. Once this > becomes more common, I am sure we will find a more general solution, but = I > don't think we are at that point. > > --- Alex > > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com] > > Sent: Tuesday, December 05, 2017 12:25 PM > > To: andy@yumaworks.com > > Cc: Alexander Clemm ; netconf@ietf.org > > Subject: Re: [Netconf] yang-push issue: error handling > > > > Andy Bierman wrote: > > > Hi, > > > > > > The protocol defines how error handling is done, not the individual > > > operations. > > > If the request fails, then clients expect an and servers > > > are designed to send an when a client request fails. > > > > Agreed, and for RESTCONF, the HTTP error codes are used. An HTTP reque= st > > that fails does not return 200 ok with a body that explains that it > actually was > > an error. > > > > > IMO, a separate error handling procedure for each RPC is more clunky > > > than error-info. > > > > +1 > > > > Some additional comments inline. > > > > > > > > While possible, the solution of having to return rpc-error etc does > > > > strike me as somewhat clunky. While it is possible to add an > > > > error-app-tag, and negotiation stuff as error-info (and I appreciat= e > > > > the suggestion), that solution would need to be described using a > > > > lot of prose in description statements a la SMIv2 (presumably as > > > > part of the RPC description, not as part of e.g. the identities, > > > > which might be used in a number of places, not just the > error-app-tag). > > > > If both the error code and hint is defined in a yang-data (i.e., not > using the > > error-app-tag), you would do: > > > > yx:yang-data subscription-error { > > container subscription-error { > > leaf error-code { > > type identity { > > base error; > > } > > } > > container hints { ... } > > } > > } > > > > Then you are right, you have to describe in prose that this yang-data > > structure can be sent as error-info. > > > > > > > > I am not sure why that would make an RPC any easier to implement. > > > > The same checks still have to be made. > > > > Agreed. > > > > > > Why would the proposed solution not acceptable? Ideally YANG woul= d > > > > provide better support to formally define application/RPC-specific > > > > return codes and corner conditions etc. > > > > Also agreed. But once we have that, such a solution would make use of > the > > rpc-error we have (for both NETCONF and RESTCONF). > > > > > > /martin > > > > > > > > Short of that, the proposed solution of adding RPC output parameter= s > > > > that are used for the purpose of indicating what is going on at the > > > > application level simply makes them part of the semantics of the > > > > specific RPC itself. It is not Netconf=E2=80=99s role to define wh= at an RPC > > > > can or cannot do, just like it cannot define what a particular leaf > > > > may or may not represent. That is part of the RPC definition. > > > > > > > > > > > > > > > > Basically, what we are discussing here is behavior of subscription > > > > configuration under corner conditions. The fact that no > > > > subscription is created because it would result in an unacceptable > > > > volume of updates for a specific implementation is different from a= n > > > > error condition such as a malformed message that is missing a > > > > required message-id, or where a value violates a constraint > > > > specified in a MUST-condition. In our case, what is being describe= d > are > > specific conditions at the application layer, above the > > > > Netconf/Restconf generic validation infrastructure. The operation > does > > > > not =E2=80=9Cwork=E2=80=9D in the sense that it does not result in = an active > > > > subscription, but it does work in the sense that the behavior is > > > > very well defined in terms of the effect that the RPC has (i.e. the > > > > effect is that it result in creation of a subscription, if certain > > > > conditions are met, and it does not result in creation of a > > > > subscription in case certain conditions are not met). Why should > > > > Netconf restrict what an RPC can or cannot do? This is all > application- > > specific. > > > > > > > > > > > > > > > > --- Alex > > > > > > > > > > > > > > > > > > > > > > > > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of > > > > *Andy Bierman > > > > *Sent:* Monday, December 04, 2017 9:15 AM > > > > *To:* Martin Bjorklund > > > > *Cc:* Netconf > > > > *Subject:* Re: [Netconf] yang-push issue: error handling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Dec 4, 2017 at 4:55 AM, Martin Bjorklund > > wrote: > > > > > > > > Andy Bierman wrote: > > > > > Hi, > > > > > > > > > > IMO the special error handling in YANG Push is not acceptable > > > > > because it violates NETCONF and RESTCONF error handling procedure= s. > > > > > NETCONF says if the operation does not work for any reason an > > > > > element SHOULD be returned. > > > > > > > > I fully agree, and I have pointed this out several times in my > > > > reviews. The problem is actually in subscribed notifications, and = I > > > > think Eric is tracking that issue. > > > > > > > > Trying to be constructive, I think that the existing mechanisms in > > > > YANG can be used to achieve the same functionality that these draft= s > > > > try to achieve. Specifically: > > > > > > > > 1. Use identities just like the ones you have > > > > ("unsupportable-volume", "filter-unavailable" etc), but add te= xt > > > > that explains that these identities are sent as "error-app-tag= " > > > > in "rpc-error", encoded to a string as :. > This > > > > works for both NETCONF and RESTCONF. > > > > > > > > 2. For the "hints" extra info that you return, define a "yang-dat= a" > > > > structure with the hints, and explain in text that this > structure > > > > is returned in "error-info". This works for both NETCONF and > > > > RESTCONF. > > > > > > > > > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > > > If the error handling was done correctly then the same procedures > > > > could be > > > > > > > > applied to failures for configured subscriptions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > As an alternative to 1, you can put the error identitiyref in the > > > > "yang-data" structure, and send both the identitiyref and hints in > > > > "error-info". > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The returns data even on error. > > > > > Instead of the common error-tag, error-info, and other fields, > > > > > there is a subscription-result leaf. > > > > > > > > > > If any client (or even server) functionality uses the NETCONF and > > > > > RESTCONF standard error handling, then subscription-result will > > > > > not be sent or expected as an error response. Depending on the > > > > > server implementation, the code that knows about > > > > > establish-subscription may not get called because common error > > > > > handling code has already determined there is an to > > > > > send instead of a data response. > > > > > > > > > > Expect that some servers are never going to send data on an > > > > > operation failure, and will only send instead. > > > > > > > > > > > > > > > >From sec. 3.8: > > > > > > > > > > For instance, for the following request: > > > > > > > > > > > > > > xmlns:netconf=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed- > notifications" > > > > > xmlns:yp=3D"urn:ietf:params:xml:ns:yang:ietf-yang-push"> > > > > > > > > > > yang:ietf-datastores"> > > > > > operational > > > > > > > > > > > > > > xmlns:ex=3D"http://example.com/sample-data/1.0" > > > > > select=3D"/ex:foo"/> > > > > > > > > > > 500 > > > > > > > > > > > > > > > > > > > > Figure 3: Establish-Subscription example > > > > > > > > > > the publisher might return: > > > > > > > > > > > > > > > > > > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed- > notifications" > > > > > xmlns:yp=3D"urn:ietf:params:xml:ns:yang:ietf-yang-push"> > > > > > yp:period-unsupported > > > > > > > > > > yang:ietf-yang-push"> > > > > > 2000 > > > > > > > > > > > > > > > > > > > > Figure 4: Error response example > > > > > > > > > > > > > > > > > > > > BTW, all the filter examples seem to be wrong, including the one > > > > > above > > > > > > > > > > > > > > > OLD: > > > > > > > > > > > > > > xmlns:ex=3D"http://example.com/sample-data/1.0" > > > > > select=3D"/ex:foo"/> > > > > > > > > > > > > > > > NEW: > > > > > > > > > > > > > > > > > > > > > > > > /> > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > --94eb2c1a615e918612055f9f3b1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Here is the problem with the YANG P= ush error handling.
The <rpc-error> response is a MUST, not= a SHOULD:

4.3.  <rpc-error> Element

   The <rpc-error> element is sent in <rpc-reply> messages if a=
n error
   occurs during the processing of an <rpc> request.

   If a server encounters multiple errors during the processing of an
   <rpc> request, the <rpc-reply> MAY contain multiple <rpc-=
error>
   elements.  However, a server is not required to detect or report more
   than one <rpc-error> element, if a request contains multiple error=
s.
   A server is not required to check for particular error conditions in
   a specific sequence.  A server MUST return an <rpc-error> eleme=
nt if
   any error conditions occur during processing.

<= pre style=3D"color:rgb(0,0,0);word-wrap:break-word;white-space:pre-wrap">
Andy

On Tue, Dec 5, 2017 at 12:35 PM, Alexander Clem= m <alexander.clemm@huawei.com> wrote:
Hi Martin,

Sure, the eventual solution may make use of rpc-error again.=C2=A0 But unti= l we get there, the currently proposed solution seems to make sense to me.= =C2=A0 I don't think we have an issue today with lots of RPCs each defi= ning their own way of dealing with corner conditions - definition of RPCs i= s something that has so far only rarely been exercised with YANG models.=C2= =A0 Once this becomes more common, I am sure we will find a more general so= lution, but I don't think we are at that point.

--- Alex

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@t= ail-f.com]
> Sent: Tuesday, December 05, 2017 12:25 PM
> To: andy@yumaworks.com
> Cc: Alexander Clemm <= alexander.clemm@huawei.com>; net= conf@ietf.org
> Subject: Re: [Netconf] yang-push issue: error handling
>
> Andy Bierman <andy@yumaworks.= com> wrote:
> > Hi,
> >
> > The protocol defines how error handling is done, not the individu= al
> > operations.
> > If the request fails, then clients expect an <rpc-error> an= d servers
> > are designed to send an <rpc-error> when a client request f= ails.
>
> Agreed, and for RESTCONF, the HTTP error codes are used.=C2=A0 An HTTP= request
> that fails does not return 200 ok with a body that explains that it ac= tually was
> an error.
>
> > IMO, a separate error handling procedure for each RPC is more clu= nky
> > than error-info.
>
> +1
>
> Some additional comments inline.
>
>
> > > While possible, the solution of having to return rpc-error e= tc does
> > > strike me as somewhat clunky.=C2=A0 While it is possible to = add an
> > > error-app-tag, and negotiation stuff as error-info (and I ap= preciate
> > > the suggestion), that solution would need to be described us= ing a
> > > lot of prose in description statements a la SMIv2 (presumabl= y as
> > > part of the RPC description, not as part of e.g. the identit= ies,
> > > which might be used in a number of places, not just the erro= r-app-tag).
>
> If both the error code and hint is defined in a yang-data (i.e., not u= sing the
> error-app-tag), you would do:
>
>=C2=A0 =C2=A0yx:yang-data subscription-error {
>=C2=A0 =C2=A0 =C2=A0container subscription-error {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf error-code {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type identity {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0base error;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0container hints { ... }
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
>
> Then you are right, you have to describe in prose that this yang-data<= br> > structure can be sent as error-info.
>
>
> > > I am not sure why that would make an RPC any easier to imple= ment.
> > > The same checks still have to be made.
>
> Agreed.
>
> > > Why would the proposed solution not acceptable?=C2=A0 =C2=A0= Ideally YANG would
> > > provide better support to formally define application/RPC-sp= ecific
> > > return codes and corner conditions etc.
>
> Also agreed.=C2=A0 But once we have that, such a solution would make u= se of the
> rpc-error we have (for both NETCONF and RESTCONF).
>
>
> /martin
>
>
> > > Short of that, the proposed solution of adding RPC output pa= rameters
> > > that are used for the purpose of indicating what is going on= at the
> > > application level simply makes them part of the semantics of= the
> > > specific RPC itself.=C2=A0 It is not Netconf=E2=80=99s role = to define what an RPC
> > > can or cannot do, just like it cannot define what a particul= ar leaf
> > > may or may not represent.=C2=A0 That is part of the RPC defi= nition.
> > >
> > >
> > >
> > > Basically, what we are discussing here is behavior of subscr= iption
> > > configuration under corner conditions.=C2=A0 The fact that n= o
> > > subscription is created because it would result in an unacce= ptable
> > > volume of updates for a specific implementation is different= from an
> > > error condition such as a malformed message that is missing = a
> > > required message-id, or where a value violates a constraint<= br> > > > specified in a MUST-condition.=C2=A0 In our case, what is be= ing described are
> specific conditions at the application layer, above the
> > > Netconf/Restconf generic validation infrastructure.=C2=A0 = =C2=A0The operation does
> > > not =E2=80=9Cwork=E2=80=9D in the sense that it does not res= ult in an active
> > > subscription, but it does work in the sense that the behavio= r is
> > > very well defined in terms of the effect that the RPC has (i= .e. the
> > > effect is that it result in creation of a subscription, if c= ertain
> > > conditions are met, and it does not result in creation of a<= br> > > > subscription in case certain conditions are not met).=C2=A0 = Why should
> > > Netconf restrict what an RPC can or cannot do?=C2=A0 This is= all application-
> specific.
> > >
> > >
> > >
> > > --- Alex
> > >
> > >
> > >
> > >
> > >
> > > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of
> > > *Andy Bierman
> > > *Sent:* Monday, December 04, 2017 9:15 AM
> > > *To:* Martin Bjorklund <mbj@tail-f.com>
> > > *Cc:* Netconf <netcon= f@ietf.org>
> > > *Subject:* Re: [Netconf] yang-push issue: error handling
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Mon, Dec 4, 2017 at 4:55 AM, Martin Bjorklund <mbj@tail-f.com>
> wrote:
> > >
> > > Andy Bierman <andy@= yumaworks.com> wrote:
> > > > Hi,
> > > >
> > > > IMO the special error handling in YANG Push is not acce= ptable
> > > > because it violates NETCONF and RESTCONF error handling= procedures.
> > > > NETCONF says if the operation does not work for any rea= son an
> > > > <rpc-error> element SHOULD be returned.
> > >
> > > I fully agree, and I have pointed this out several times in = my
> > > reviews.=C2=A0 The problem is actually in subscribed notific= ations, and I
> > > think Eric is tracking that issue.
> > >
> > > Trying to be constructive, I think that the existing mechani= sms in
> > > YANG can be used to achieve the same functionality that thes= e drafts
> > > try to achieve.=C2=A0 Specifically:
> > >
> > >=C2=A0 =C2=A01. Use identities just like the ones you have > > >=C2=A0 =C2=A0 =C2=A0 ("unsupportable-volume", "= ;filter-unavailable" etc), but add text
> > >=C2=A0 =C2=A0 =C2=A0 that explains that these identities are = sent as "error-app-tag"
> > >=C2=A0 =C2=A0 =C2=A0 in "rpc-error", encoded to a s= tring as <module>:<identity>.=C2=A0 This
> > >=C2=A0 =C2=A0 =C2=A0 works for both NETCONF and RESTCONF.
> > >
> > >=C2=A0 =C2=A02. For the "hints" extra info that you= return, define a "yang-data"
> > >=C2=A0 =C2=A0 =C2=A0 structure with the hints, and explain in= text that this structure
> > >=C2=A0 =C2=A0 =C2=A0 is returned in "error-info".= =C2=A0 This works for both NETCONF and
> > >=C2=A0 =C2=A0 =C2=A0 RESTCONF.
> > >
> > >
> > >
> > >
> > >
> > > +1
> > >
> > >
> > >
> > > If the error handling was done correctly then the same proce= dures
> > > could be
> > >
> > > applied to <edit-config> failures for configured subsc= riptions.
> > >
> > >
> > >
> > >
> > >
> > >
> > > As an alternative to 1, you can put the error identitiyref i= n the
> > > "yang-data" structure, and send both the identitiy= ref and hints in
> > > "error-info".
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > >
> > >
> > > Andy
> > >
> > >
> > >
> > >
> > >
> > >
> > > > The <establish-subscription> returns data even on= error.
> > > > Instead of the common error-tag, error-info, and other = fields,
> > > > there is a subscription-result leaf.
> > > >
> > > > If any client (or even server) functionality uses the N= ETCONF and
> > > > RESTCONF standard error handling, then subscription-res= ult will
> > > > not be sent or expected as an error response. Depending= on the
> > > > server implementation, the code that knows about
> > > > establish-subscription may not get called because commo= n error
> > > > handling code has already determined there is an <rp= c-error> to
> > > > send instead of a data response.
> > > >
> > > > Expect that some servers are never going to send data o= n an
> > > > operation failure, and will only send <rpc-error>= instead.
> > > >
> > > >
> > > > >From sec. 3.8:
> > > >
> > > >=C2=A0 =C2=A0 For instance, for the following request: > > > >
> > > > <netconf:rpc message-id=3D"101"
> > > >=C2=A0 =C2=A0 xmlns:netconf=3D"urn:ietf:params= :xml:ns:netconf:base:1.0">
> > > >=C2=A0 =C2=A0 <establish-subscription
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:param= s:xml:ns:yang:ietf-subscribed-notifications"
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:yp=3D"urn:ietf:pa= rams:xml:ns:yang:ietf-yang-push">
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:datastore>
> > > >=C2=A0 =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 =C2=A0operational
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</yp:source>
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:subtree-filter = netconf:type=3D"xpath"
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns:ex= =3D"http://example.com/sample-data/1.0"
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0select= =3D"/ex:foo"/>
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0</yp:datastore>
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:period>500</yp:p= eriod>
> > > >=C2=A0 =C2=A0 </establish-subscription>
> > > > </netconf:rpc>
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Figure 3: Establish-Subscription example
> > > >
> > > >=C2=A0 =C2=A0 the publisher might return:
> > > >
> > > >
> > > > <rpc-reply message-id=3D"101"
> > > >=C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:n= s:netconf:base:1.0">
> > > >=C2=A0 =C2=A0 <subscription-result
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:param= s:xml:ns:yang:ietf-subscribed-notifications"
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns:yp=3D"urn:ietf:pa= rams:xml:ns:yang:ietf-yang-push">
> > > >=C2=A0 =C2=A0 =C2=A0 yp:period-unsupported
> > > >=C2=A0 =C2=A0 </subscription-result>
> > > >=C2=A0 =C2=A0 <period-hint xmlns:"urn:ietf:param= s:xml:ns:yang:ietf-yang-push">
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A02000
> > > >=C2=A0 =C2=A0 </period-hint>
> > > > </rpc-reply>
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Figure 4: Error response example
> > > >
> > > >
> > > >
> > > > BTW, all the filter examples seem to be wrong, includin= g the one
> > > > above
> > > >
> > > >
> > > > OLD:
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:subtree-filter = netconf:type=3D"xpath"
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0xmlns:ex= =3D"http://example.com/sample-data/1.0"
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0select= =3D"/ex:foo"/>
> > > >
> > > >
> > > > NEW:
> > > >
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<yp:subtree-filter&= gt;
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <ex:foo xml= ns:ex=3D"http://example.com/sample-data/1.0" > > > > />
> > > >
> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</yp:subtree-filter= >
> > > >
> > > >
> > > > Andy
> > >
> > >
> > >

--94eb2c1a615e918612055f9f3b1e-- From nobody Tue Dec 5 17:35: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 ABBEE12426E for ; Tue, 5 Dec 2017 17:35: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 VMO-pF9_Y203 for ; Tue, 5 Dec 2017 17:35:53 -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 52A76124217 for ; Tue, 5 Dec 2017 17:35:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23933; q=dns/txt; s=iport; t=1512524153; x=1513733753; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=N7/l972A9+SiaNoXUEnV0nhmXW7MeruZFd15FWJUADc=; b=I+vwRkq6PCec4kdqXRRhoHYvNC5phcT9+4yDbS8B2s1qMJOEN+kU4pFl 6VXlcOjR8fjE6eXTrIEAyA5cycaGktGn77e2L7miXSVKgjQCJMO2/zq9m Q2DLn+025nJHM4/duTxJIY+ak2vGg67zGjq5JluktX45vN99r+zyv3gtu E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAgDsSCda/4oNJK1TAQIHGQEBAQEBA?= =?us-ascii?q?QEBAQEBAQcBAQEBAYM9gR81JwedF4F9fpYYggEKhTsChUhDFAEBAQEBAQEBAWs?= =?us-ascii?q?ohSIBAQEDARogPwULAgEIDgcDDREQMiUCBA4DAggTigAIrCGKVQEBAQEBAQQBA?= =?us-ascii?q?QEBAQEBAQEfg0qCCoFWgWmCHVg2hGoMARIBAQOGCwWKPYdJgXKFRIk6AotfiSm?= =?us-ascii?q?CH4YRizGKPotmAhEZAYE5ATYigU1vFRYkgimEVUUzh1sqgQmBFAEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,366,1508803200"; d="scan'208";a="40796698" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Dec 2017 01:35:51 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id vB61ZpYr013587 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Dec 2017 01:35:51 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, 5 Dec 2017 20:35: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, 5 Dec 2017 20:35:50 -0500 From: "Eric Voit (evoit)" To: Martin Bjorklund CC: "netconf@ietf.org" , "balazs.lengyel@ericsson.com" , "andy@yumaworks.com" , "alexander.clemm@huawei.com" Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11 Thread-Index: AQHTaCy/QRPr9GM9Jka7UxKyCaa4a6MpyuqggAmhy4D///elMIABf46AgAB7+cA= Date: Wed, 6 Dec 2017 01:35:50 +0000 Message-ID: <422b669242674349975651d2ef7c436e@XCH-RTP-013.cisco.com> References: <4c2303ac1eff4b0db2dae056d56c9285@XCH-RTP-013.cisco.com> <20171204.124001.1188267155929301700.mbj@tail-f.com> <16ea77c9d7944aeea09a0b1971ab02a0@XCH-RTP-013.cisco.com> <20171205.110255.1069937786544957099.mbj@tail-f.com> In-Reply-To: <20171205.110255.1069937786544957099.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.86.244.103] 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, 06 Dec 2017 01:35:57 -0000 Hi Martin, > From: Martin Bjorklund, December 5, 2017 5:03 AM >=20 > Hi, >=20 > "Eric Voit (evoit)" wrote: > > Hi Martin, > > > > Reducing to the open items... > > > > > > + Dampening period: In an on-change subscription, detected > object > > > > changes should be sent as quickly as possible. However wi= thout > > > > adequate protections, a rapid series of object changes mig= ht > > > > exhaust > > > > of resources in the publisher or receiver. In order to pr= otect > > > > against that, a dampening period MAY be used to specify th= e > > > > interval > > > > which must pass before successive update records for the s= ame > > > > 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 m= eans > > > > that > > > > when there is a change to a subscribed object, an update r= ecord > > > > containing that object is created either immediately when = no > > > > dampening period is in effect, or at the end of a dampenin= g > > > > period. > > > > A dampening period is reset every time a new notification > > > > message > > > is > > > > passed to transport. > > > > > > I understand what you want to achieve, but I don't think the text is > > > quite correct. I'll think about this some more to see if I can come > > > up with a better wording. > > > > After the latest interactions on the mailer, text reads: > > > > Dampening period: In an on-change subscription, detected object > > changes should be sent as quickly as possible. However it may be > > undesirable to send a rapid series of object changes. Such behavior > > has the potential to 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 datastore > > nodes selected by a single subscription and sent to a single receiver. > > This means that when there is a change to one or more subscribed > > objects, an update record containing those objects is created either > > immediately when no dampening period is in effect, or at the end of a > > dampening period. If multiple changes to a single object occur during > > a dampening period, only the value that is in effect is included as > > part of the update record. A dampening period is reset every time an > > update record has completed its assembly. >=20 > What if you delete the last sentence? It is not clear to me what it mean= s to > reset a period. The last sentence is important (per the comments with Rohit R .) I will = clarify it to: "The dampening period goes into effect every time an update record complete= s assembly." =20 > > > > > o 3.6 > > > > > > > > > > Subscription policy specifies both the selection filters and= the > > > > > datastores against which these selection filters will be app= lied. > > > > > 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: > > > > > > My problem with this style is that it seems to indicate that the > > > selection filter is only used for this use case ("replication of a > > > subset..."), but that would be a mistake. I think you should > > > explain what these filters are first, and then (maybe) give examples > > > of how they can be used. > > > > > > The title "Datastore selection filter" is also misleading; > > > > I have made the title "Datastore selection", as the section doesn't > > hit all the items of subscription policy (such as periods). > > > > > in fact the best > > > solution might be to keep the original text but change the title of > > > the section to "Subscription Policy". > > > > I have returned the text to something closer to the original text. It > > now is: > > > > "A subscription must specify both the selection filters and the > > datastore against which these selection filters will be applied. This > > information is needed to choose and subsequently push the information > > necessary to remotely maintain an extract of the publisher's > > datastore." >=20 > I prefer text that describes *how* this is used rather than *why*. So > maybe change the last sentence above to: >=20 > This information is used to choose and subsequently push data from > the publisher's datastore to the receivers. Updated. > > If you have other examples of how the info might be used, what would > > you want to add? (One thing is possible is to simply monitor a > > datastore for a specific event, like the creation of a node, but not > > its deletion. More on this within the excluded change discussion > > further below.) >=20 > See above; I don't think these examples are needed at this point in the > document. Ok. No change needed beyond text change above. > > > > > 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 menti= on > > > > > 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. > > > > > > Maybe "patch-id" could be a sequential number, starting from 1 when > > > the first patch is sent? Or simply any string that the server finds > > > appropriate. > > > In any case, "null" looks odd in the example. > > > > Agree "null" looks odd. > > > > Does *anyone* have an issue if I make an implementation > recommendation > > that the definition the incremental number of the push-change-update > > for a particular subscription? That would at least make the required > > field useful? I have added the text: " Of Note in the above example is the 'patch-id' with a value of '1'. Per = [RFC8072], the 'patch-id' is an arbitrary string. With YANG Push, the publ= isher SHOULD put into the 'patch-id' a counter starting at '1' which increm= ents with every 'push-change-update' generated for a subscription. If used = as a counter, this counter MUST be reset to '1' anytime a resynchronization= occurs (i.e., with the sending of a 'push-update'). Also if used as a co= unter, the counter MUST be reset to '1' the after passing a maximum value o= f '99999'. Such a mechanism allows easy identification of lost or out-of-se= quence update records. " > > > > > 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. > > > > > > Ok, but the error code is used as a return value for > > > "establish-subscription". > > > So if a server can't detect it at "establish-subscription" it mean > > > it will never be used. Hence I suggest you remove the text about > > > "authorization privileges". The subscription-terminated notification is valid for dynamically establish= ed subscriptions. This is a valid error code for that situation. > > A publisher could choose to allow a subscription to an empty location > > where there might plausibly be objects someday. (E.g., maybe where an > > interface might appear; even if there is no such interface currently > > existing.) >=20 > I think the spec needs to be clear if servers are required to allow filte= rs to > cover non-existing nodes or not (I think it should). > Hence, selecting a non-existing node should not be an error. Agree. The " Receiver Authorization" section now has a clarified sentence= : " A publisher MAY allow subscriptions which select non-existent or access-p= rotected data." =20 > NOTE: we may want to handle the case that the client asks for a node that > can *never* exist (e.g. a node in a non-implemented module or a misspelle= d > node name) differently than the case that an instance doesn't exist. Agree. Such determination is up to the publisher. =20 > > Likewise a publisher could choose to reject a subscription because it > > is obvious that a subscriber will never have access to the requested > > data. (E.g., maybe always disallow subscription to YANG model which > > controls the configuration of private keys.) > > > > Pretending they might have access someday and allowing the > > subscription will just waste resources. So I think the error is > > useful for such situations. >=20 > This is fine, but not what the current description says. The text in > 3.9 and the YANG module don't match. on-change-unsupported definition now is: "On-change is not supported for any objects which are likely to be provided= through the selection filter." > Also, in the normal case, I don't think the server will know if a client = will > *never* have access to some object. It will be interesting to see how different publishers optimize for this si= tuation. =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 o= f > > > > > 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. > > > > > > No. See RFC7950, section 8.3.1, bullet 4. And compare with all > > > other modules that use if-feature; no other module has invented such > > > error codes. > > > > Let's handle this on the separate errors thread. The question of > > legitimate negotiation interactions which are not actually errors is a > > conversation needing more WG internalization. And without this, we > > need to figure out how to send errors as part things like > > subscription-suspended notifications. >=20 > I don't think this notification has to change. Excellent. Alex will be providing some suggestions on what to do with err= or interactions on a parallel thread. =20 > > > > 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. > > > > > > Ok; i.e., the text should explain that it is used if the client asks > > > for an obejct that does not support on-change. The if-feature case > > > is already handled as described above. > > > > Have changed the definition to: > > "On-change is not supportable for any objects which may be provided > > through the selection filter."; >=20 > s/any/all/ ? Any. Because this includes any objects which might come into existence und= er a subscribed subtree. Tweaked the definition to: "On-change is not supported for any objects which are likely to be provided= through the selection filter." > > > > > 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 > > > > > > But in this case the error will be "on-change-unsupported", right? > > > > I mean to say "except for" rather that e.g. My bad. > > > > > > ). Will enhance the > > > > definition. > > > > Current text is now: > > "Neither synch on start nor resynchonization are supported for this > > subscription. This error will be used for two reasons. First if an > > 'establish-subscription' RPC doesn't include 'no-synch-on-start', yet > > the publisher can't support sending a 'push update' for this > > subscription for reasons other that 'on-change-unsupported' or > > 'result-too-big'. >=20 > What would that reason be?=20 One example might be the CPU capacity is prohibitively low at that immediat= e time. Or there are too many subscriptions pulling counters or routing ta= bles or MAC addresses from a specific line card. Or other platform wide is= sues which shouldn't fall under 'result-too-big' because making the result = smaller still won't result in the subscription being allowed to push the st= ate of current nodes. > I think that if the idea is that a server may or > may not support sync on start, you should make a feature for it and call = the > leaf "sync-on-start" instead. And OTOH, if the default is sync on start = (as it > is now), it should be required to support it. >=20 > > And second, if the 'resynch-subscription' RPC is invoked either for an > > existing periodic subscription, or for an on-change subscription which > > can't support resynchronization."; >=20 > What would a leagal reason be for the latter case? The first case of the RPC being invoked for the periodic case seems enough = for this identity. For an on-change, see the other reasons above. Having = a catch all error code which doesn't futilely drive a subscriber to attempt= smaller subscriptions is worthwhile. =20 > > > > (2) The resynch RPC is invoked on a periodic subscription-id >=20 > Ok. >=20 > > > > , 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 > > > > > > Huh? What does *that* mean? > > > > As an extreme example: if someone tries to provide a character for a > > key that only accepts integer. >=20 > Note that both subtree filter and xpath allows this and will just return = an > empty node set. I really don't think we should change how XPath or > subtree filter works. So I propose you remove this error. Ok. Removed. =20 > > Definition is now: > > "Mismatch between selection filter key provided and the datatype = of > > the referenced YANG datatree node."; > > > > You might say this *should* be placed under normal error conditions, > > per the larger error condition thread. And perhaps this is the case. > > But there still is the case where a subscription is abnormally > > terminated or suspended because someone modifies a configured > > subscription to a non-viable filter which causes this error to pop up. > > Such an option needs to be reported to a subscriber, and existing > > error mechanisms don't do this AFAIK. > > > > > > > > > identity datatree-size { > > > > > > > > > > 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 > > > > > > It will use ds:datastore as base. If we need some other generic > > > base from which custom datastores are derived, that identity should > > > be defined in a generic place (ietf-datastores probably), and not > > > here. > > > > Will you put it in that document then? That makes it very easy to > > delete from here. >=20 > That's a discussion for the nmda document, but personally I don't see > the need for such an identity. In any case, it should be removed > from this document. Removed. I will think about making the request to NMDA. =20 > > However a patch must be able to do more than just describe the delta > > from the previous state to the current state. As per > target=3D"on-change"/>, it must also be able to identify if transient > > changes have occurred on an object during a dampening period. To > > support this, it is valid to encode a YANG patch operation so that its > > application would result in a no change between the previous and > > current state. This indicates that some churn has occurred on the > > object. An example of this would be a patch that does a "create" > > operation for a datastore node where the receiver believes one already > > exists, or a "merge" operation which replaces a previous value with > > the same value. >=20 > Hmm, I think that this is a very strange way to indicate "churn", it is v= ery > implicit. Is it really necessary to be able to indicate this "churn"? I= t seems > quite complex on both the server and client side. > If a client needs to know this information, it can just not specify a > dampening period. Churn indication is an absolute *must* for security applications. Both the= SACM and I2NSF WGs have indicated need. It is also highly useful for Netw= ork Management applications which simply cannot get a continuous stream of = interface flaps. This is a highly advantageous capability and I have quit= e a few customer requests for this. =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. > > > > > > > > I like it, will update. > > > > I forgot the reason why I had mandatory true. It is so that the leaf > > dampening-period is explicitly there in the RPC to identify this > > subscription as explicitly on-change. Without the leaf, you need to > > infer "on-change" through the absence of the "period" leaf. And such > > a design leaves open a greater chance of unnecessary errors. >=20 > I think the current data model has some other problems as well. > Specifically, the "update-trigger" choice is optional - what does it > mean if it no case is specified in this choice? Here's a proposal > for a more explicit datamodel: >=20 > choice update-trigger { > when "../target/datastore/source"; (*) > mandatory true; I have integrated the when & mandatory. > case periodic { > container periodic { > presence "indicates a periodic subscription"; > leaf period { ... } > leaf anchor-time { ... } > } > } > case on-change { > container on-change { > presence "indicates an on-change subscription"; > leaf dampening-period { > type yang:timeticks; > default "0"; // or mandatory if you prefer that the client > // must be explicit > } > leaf no-sync-on-start { ... } > leaf-list excluded-change { ... } > } > } > } I included this as well. Honestly the containers are mostly redundant at t= his point the information can be gleaned by the available objects. But I c= an imagine future triggers which re-use some of the same object names. Thi= s prepares for this time. > (*) this path shows another issue with the data model - in the "target" y= ou > have a "source". I think you should rename "source" to "datastore"; so i= n > the case "datastore" there's a leaf "datastore". > Also, it shows that it is not clear if the proper name in establish- > subscription is "target" or "source" - or something else. I have renamed source to datastore. Eric > /martin From nobody Tue Dec 5 18:01: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 6C908127863 for ; Tue, 5 Dec 2017 18:01:14 -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 OY2YHG_NTA9Q for ; Tue, 5 Dec 2017 18:01:10 -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 2C512126CF6 for ; Tue, 5 Dec 2017 18:01:10 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0B756136E025C for ; Wed, 6 Dec 2017 02:01:07 +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; Wed, 6 Dec 2017 02:01:07 +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; Tue, 5 Dec 2017 18:01:05 -0800 From: Alexander Clemm To: Andy Bierman CC: Martin Bjorklund , "netconf@ietf.org" Thread-Topic: [Netconf] yang-push issue: error handling Thread-Index: AQHTaubADOTUW5LGwkKD+sraYMgQfKMzrq2AgABIa4CAATJtIIAAkRyAgAAD2ID//3rSEIAApVMA//+1c+A= Date: Wed, 6 Dec 2017 02:01:03 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD12B7@sjceml521-mbx.china.huawei.com> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD10E9@sjceml521-mbx.china.huawei.com> <20171205.212443.660483858000758249.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1165@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.209.216.169] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD12B7sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Netconf] yang-push issue: error handling 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, 06 Dec 2017 02:01:14 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD12B7sjceml521mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdGlsbCBmaW5kIHRoaXMgYSBiaXQgY2x1bmt5IChhbmQgSSBzdGlsbCB3b25kZXIgaWYgd2Ug Y291bGQgZGVmaW5lIOKAnGNvcm5lciBiZWhhdmlvcuKAnSBpbnN0ZWFkIG9mIGVycm9yIGNvbmRp dGlvbnMpLCBidXQgT0ssIGxldOKAmXMgZ28gd2l0aCB0aGUgcHJvcG9zZWQgYXMgb3V0bGluZWQg YnkgTWFydGluLg0KDQpMZXTigJlzIGNsb3NlIHRoaXM7IHdlIHdpbGwgdXBkYXRlIHRoZSBSUENz IGFjY29yZGluZ2x5Lg0KDQpUaGFua3MNCi0tLSBBbGV4DQoNCkZyb206IEFuZHkgQmllcm1hbiBb bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NClNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDA1LCAy MDE3IDI6MjAgUE0NClRvOiBBbGV4YW5kZXIgQ2xlbW0gPGFsZXhhbmRlci5jbGVtbUBodWF3ZWku Y29tPg0KQ2M6IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPjsgbmV0Y29uZkBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtOZXRjb25mXSB5YW5nLXB1c2ggaXNzdWU6IGVycm9yIGhhbmRs aW5nDQoNCkhpLA0KDQpIZXJlIGlzIHRoZSBwcm9ibGVtIHdpdGggdGhlIFlBTkcgUHVzaCBlcnJv ciBoYW5kbGluZy4NClRoZSA8cnBjLWVycm9yPiByZXNwb25zZSBpcyBhIE1VU1QsIG5vdCBhIFNI T1VMRDoNCg0KDQo0LjMuICA8cnBjLWVycm9yPiBFbGVtZW50DQoNCg0KDQogICBUaGUgPHJwYy1l cnJvcj4gZWxlbWVudCBpcyBzZW50IGluIDxycGMtcmVwbHk+IG1lc3NhZ2VzIGlmIGFuIGVycm9y DQoNCiAgIG9jY3VycyBkdXJpbmcgdGhlIHByb2Nlc3Npbmcgb2YgYW4gPHJwYz4gcmVxdWVzdC4N Cg0KDQoNCiAgIElmIGEgc2VydmVyIGVuY291bnRlcnMgbXVsdGlwbGUgZXJyb3JzIGR1cmluZyB0 aGUgcHJvY2Vzc2luZyBvZiBhbg0KDQogICA8cnBjPiByZXF1ZXN0LCB0aGUgPHJwYy1yZXBseT4g TUFZIGNvbnRhaW4gbXVsdGlwbGUgPHJwYy1lcnJvcj4NCg0KICAgZWxlbWVudHMuICBIb3dldmVy LCBhIHNlcnZlciBpcyBub3QgcmVxdWlyZWQgdG8gZGV0ZWN0IG9yIHJlcG9ydCBtb3JlDQoNCiAg IHRoYW4gb25lIDxycGMtZXJyb3I+IGVsZW1lbnQsIGlmIGEgcmVxdWVzdCBjb250YWlucyBtdWx0 aXBsZSBlcnJvcnMuDQoNCiAgIEEgc2VydmVyIGlzIG5vdCByZXF1aXJlZCB0byBjaGVjayBmb3Ig cGFydGljdWxhciBlcnJvciBjb25kaXRpb25zIGluDQoNCiAgIGEgc3BlY2lmaWMgc2VxdWVuY2Uu ICBBIHNlcnZlciBNVVNUIHJldHVybiBhbiA8cnBjLWVycm9yPiBlbGVtZW50IGlmDQoNCiAgIGFu eSBlcnJvciBjb25kaXRpb25zIG9jY3VyIGR1cmluZyBwcm9jZXNzaW5nLg0KDQoNCg0KDQoNCkFu ZHkNCg0KDQoNCk9uIFR1ZSwgRGVjIDUsIDIwMTcgYXQgMTI6MzUgUE0sIEFsZXhhbmRlciBDbGVt bSA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb208bWFpbHRvOmFsZXhhbmRlci5jbGVtbUBodWF3 ZWkuY29tPj4gd3JvdGU6DQpIaSBNYXJ0aW4sDQoNClN1cmUsIHRoZSBldmVudHVhbCBzb2x1dGlv biBtYXkgbWFrZSB1c2Ugb2YgcnBjLWVycm9yIGFnYWluLiAgQnV0IHVudGlsIHdlIGdldCB0aGVy ZSwgdGhlIGN1cnJlbnRseSBwcm9wb3NlZCBzb2x1dGlvbiBzZWVtcyB0byBtYWtlIHNlbnNlIHRv IG1lLiAgSSBkb24ndCB0aGluayB3ZSBoYXZlIGFuIGlzc3VlIHRvZGF5IHdpdGggbG90cyBvZiBS UENzIGVhY2ggZGVmaW5pbmcgdGhlaXIgb3duIHdheSBvZiBkZWFsaW5nIHdpdGggY29ybmVyIGNv bmRpdGlvbnMgLSBkZWZpbml0aW9uIG9mIFJQQ3MgaXMgc29tZXRoaW5nIHRoYXQgaGFzIHNvIGZh ciBvbmx5IHJhcmVseSBiZWVuIGV4ZXJjaXNlZCB3aXRoIFlBTkcgbW9kZWxzLiAgT25jZSB0aGlz IGJlY29tZXMgbW9yZSBjb21tb24sIEkgYW0gc3VyZSB3ZSB3aWxsIGZpbmQgYSBtb3JlIGdlbmVy YWwgc29sdXRpb24sIGJ1dCBJIGRvbid0IHRoaW5rIHdlIGFyZSBhdCB0aGF0IHBvaW50Lg0KDQot LS0gQWxleA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1hcnRpbiBC am9ya2x1bmQgW21haWx0bzptYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+XQ0K PiBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAwNSwgMjAxNyAxMjoyNSBQTQ0KPiBUbzogYW5keUB5 dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+DQo+IENjOiBBbGV4YW5kZXIg Q2xlbW0gPGFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPG1haWx0bzphbGV4YW5kZXIuY2xlbW1A aHVhd2VpLmNvbT4+OyBuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0K PiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIHlhbmctcHVzaCBpc3N1ZTogZXJyb3IgaGFuZGxpbmcN Cj4NCj4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdv cmtzLmNvbT4+IHdyb3RlOg0KPiA+IEhpLA0KPiA+DQo+ID4gVGhlIHByb3RvY29sIGRlZmluZXMg aG93IGVycm9yIGhhbmRsaW5nIGlzIGRvbmUsIG5vdCB0aGUgaW5kaXZpZHVhbA0KPiA+IG9wZXJh dGlvbnMuDQo+ID4gSWYgdGhlIHJlcXVlc3QgZmFpbHMsIHRoZW4gY2xpZW50cyBleHBlY3QgYW4g PHJwYy1lcnJvcj4gYW5kIHNlcnZlcnMNCj4gPiBhcmUgZGVzaWduZWQgdG8gc2VuZCBhbiA8cnBj LWVycm9yPiB3aGVuIGEgY2xpZW50IHJlcXVlc3QgZmFpbHMuDQo+DQo+IEFncmVlZCwgYW5kIGZv ciBSRVNUQ09ORiwgdGhlIEhUVFAgZXJyb3IgY29kZXMgYXJlIHVzZWQuICBBbiBIVFRQIHJlcXVl c3QNCj4gdGhhdCBmYWlscyBkb2VzIG5vdCByZXR1cm4gMjAwIG9rIHdpdGggYSBib2R5IHRoYXQg ZXhwbGFpbnMgdGhhdCBpdCBhY3R1YWxseSB3YXMNCj4gYW4gZXJyb3IuDQo+DQo+ID4gSU1PLCBh IHNlcGFyYXRlIGVycm9yIGhhbmRsaW5nIHByb2NlZHVyZSBmb3IgZWFjaCBSUEMgaXMgbW9yZSBj bHVua3kNCj4gPiB0aGFuIGVycm9yLWluZm8uDQo+DQo+ICsxDQo+DQo+IFNvbWUgYWRkaXRpb25h bCBjb21tZW50cyBpbmxpbmUuDQo+DQo+DQo+ID4gPiBXaGlsZSBwb3NzaWJsZSwgdGhlIHNvbHV0 aW9uIG9mIGhhdmluZyB0byByZXR1cm4gcnBjLWVycm9yIGV0YyBkb2VzDQo+ID4gPiBzdHJpa2Ug bWUgYXMgc29tZXdoYXQgY2x1bmt5LiAgV2hpbGUgaXQgaXMgcG9zc2libGUgdG8gYWRkIGFuDQo+ ID4gPiBlcnJvci1hcHAtdGFnLCBhbmQgbmVnb3RpYXRpb24gc3R1ZmYgYXMgZXJyb3ItaW5mbyAo YW5kIEkgYXBwcmVjaWF0ZQ0KPiA+ID4gdGhlIHN1Z2dlc3Rpb24pLCB0aGF0IHNvbHV0aW9uIHdv dWxkIG5lZWQgdG8gYmUgZGVzY3JpYmVkIHVzaW5nIGENCj4gPiA+IGxvdCBvZiBwcm9zZSBpbiBk ZXNjcmlwdGlvbiBzdGF0ZW1lbnRzIGEgbGEgU01JdjIgKHByZXN1bWFibHkgYXMNCj4gPiA+IHBh cnQgb2YgdGhlIFJQQyBkZXNjcmlwdGlvbiwgbm90IGFzIHBhcnQgb2YgZS5nLiB0aGUgaWRlbnRp dGllcywNCj4gPiA+IHdoaWNoIG1pZ2h0IGJlIHVzZWQgaW4gYSBudW1iZXIgb2YgcGxhY2VzLCBu b3QganVzdCB0aGUgZXJyb3ItYXBwLXRhZykuDQo+DQo+IElmIGJvdGggdGhlIGVycm9yIGNvZGUg YW5kIGhpbnQgaXMgZGVmaW5lZCBpbiBhIHlhbmctZGF0YSAoaS5lLiwgbm90IHVzaW5nIHRoZQ0K PiBlcnJvci1hcHAtdGFnKSwgeW91IHdvdWxkIGRvOg0KPg0KPiAgIHl4OnlhbmctZGF0YSBzdWJz Y3JpcHRpb24tZXJyb3Igew0KPiAgICAgY29udGFpbmVyIHN1YnNjcmlwdGlvbi1lcnJvciB7DQo+ ICAgICAgIGxlYWYgZXJyb3ItY29kZSB7DQo+ICAgICAgICAgdHlwZSBpZGVudGl0eSB7DQo+ICAg ICAgICAgICBiYXNlIGVycm9yOw0KPiAgICAgICAgIH0NCj4gICAgICAgfQ0KPiAgICAgICBjb250 YWluZXIgaGludHMgeyAuLi4gfQ0KPiAgICAgfQ0KPiAgIH0NCj4NCj4gVGhlbiB5b3UgYXJlIHJp Z2h0LCB5b3UgaGF2ZSB0byBkZXNjcmliZSBpbiBwcm9zZSB0aGF0IHRoaXMgeWFuZy1kYXRhDQo+ IHN0cnVjdHVyZSBjYW4gYmUgc2VudCBhcyBlcnJvci1pbmZvLg0KPg0KPg0KPiA+ID4gSSBhbSBu b3Qgc3VyZSB3aHkgdGhhdCB3b3VsZCBtYWtlIGFuIFJQQyBhbnkgZWFzaWVyIHRvIGltcGxlbWVu dC4NCj4gPiA+IFRoZSBzYW1lIGNoZWNrcyBzdGlsbCBoYXZlIHRvIGJlIG1hZGUuDQo+DQo+IEFn cmVlZC4NCj4NCj4gPiA+IFdoeSB3b3VsZCB0aGUgcHJvcG9zZWQgc29sdXRpb24gbm90IGFjY2Vw dGFibGU/ICAgSWRlYWxseSBZQU5HIHdvdWxkDQo+ID4gPiBwcm92aWRlIGJldHRlciBzdXBwb3J0 IHRvIGZvcm1hbGx5IGRlZmluZSBhcHBsaWNhdGlvbi9SUEMtc3BlY2lmaWMNCj4gPiA+IHJldHVy biBjb2RlcyBhbmQgY29ybmVyIGNvbmRpdGlvbnMgZXRjLg0KPg0KPiBBbHNvIGFncmVlZC4gIEJ1 dCBvbmNlIHdlIGhhdmUgdGhhdCwgc3VjaCBhIHNvbHV0aW9uIHdvdWxkIG1ha2UgdXNlIG9mIHRo ZQ0KPiBycGMtZXJyb3Igd2UgaGF2ZSAoZm9yIGJvdGggTkVUQ09ORiBhbmQgUkVTVENPTkYpLg0K Pg0KPg0KPiAvbWFydGluDQo+DQo+DQo+ID4gPiBTaG9ydCBvZiB0aGF0LCB0aGUgcHJvcG9zZWQg c29sdXRpb24gb2YgYWRkaW5nIFJQQyBvdXRwdXQgcGFyYW1ldGVycw0KPiA+ID4gdGhhdCBhcmUg dXNlZCBmb3IgdGhlIHB1cnBvc2Ugb2YgaW5kaWNhdGluZyB3aGF0IGlzIGdvaW5nIG9uIGF0IHRo ZQ0KPiA+ID4gYXBwbGljYXRpb24gbGV2ZWwgc2ltcGx5IG1ha2VzIHRoZW0gcGFydCBvZiB0aGUg c2VtYW50aWNzIG9mIHRoZQ0KPiA+ID4gc3BlY2lmaWMgUlBDIGl0c2VsZi4gIEl0IGlzIG5vdCBO ZXRjb25m4oCZcyByb2xlIHRvIGRlZmluZSB3aGF0IGFuIFJQQw0KPiA+ID4gY2FuIG9yIGNhbm5v dCBkbywganVzdCBsaWtlIGl0IGNhbm5vdCBkZWZpbmUgd2hhdCBhIHBhcnRpY3VsYXIgbGVhZg0K PiA+ID4gbWF5IG9yIG1heSBub3QgcmVwcmVzZW50LiAgVGhhdCBpcyBwYXJ0IG9mIHRoZSBSUEMg ZGVmaW5pdGlvbi4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IEJhc2ljYWxseSwgd2hhdCB3 ZSBhcmUgZGlzY3Vzc2luZyBoZXJlIGlzIGJlaGF2aW9yIG9mIHN1YnNjcmlwdGlvbg0KPiA+ID4g Y29uZmlndXJhdGlvbiB1bmRlciBjb3JuZXIgY29uZGl0aW9ucy4gIFRoZSBmYWN0IHRoYXQgbm8N Cj4gPiA+IHN1YnNjcmlwdGlvbiBpcyBjcmVhdGVkIGJlY2F1c2UgaXQgd291bGQgcmVzdWx0IGlu IGFuIHVuYWNjZXB0YWJsZQ0KPiA+ID4gdm9sdW1lIG9mIHVwZGF0ZXMgZm9yIGEgc3BlY2lmaWMg aW1wbGVtZW50YXRpb24gaXMgZGlmZmVyZW50IGZyb20gYW4NCj4gPiA+IGVycm9yIGNvbmRpdGlv biBzdWNoIGFzIGEgbWFsZm9ybWVkIG1lc3NhZ2UgdGhhdCBpcyBtaXNzaW5nIGENCj4gPiA+IHJl cXVpcmVkIG1lc3NhZ2UtaWQsIG9yIHdoZXJlIGEgdmFsdWUgdmlvbGF0ZXMgYSBjb25zdHJhaW50 DQo+ID4gPiBzcGVjaWZpZWQgaW4gYSBNVVNULWNvbmRpdGlvbi4gIEluIG91ciBjYXNlLCB3aGF0 IGlzIGJlaW5nIGRlc2NyaWJlZCBhcmUNCj4gc3BlY2lmaWMgY29uZGl0aW9ucyBhdCB0aGUgYXBw bGljYXRpb24gbGF5ZXIsIGFib3ZlIHRoZQ0KPiA+ID4gTmV0Y29uZi9SZXN0Y29uZiBnZW5lcmlj IHZhbGlkYXRpb24gaW5mcmFzdHJ1Y3R1cmUuICAgVGhlIG9wZXJhdGlvbiBkb2VzDQo+ID4gPiBu b3Qg4oCcd29ya+KAnSBpbiB0aGUgc2Vuc2UgdGhhdCBpdCBkb2VzIG5vdCByZXN1bHQgaW4gYW4g YWN0aXZlDQo+ID4gPiBzdWJzY3JpcHRpb24sIGJ1dCBpdCBkb2VzIHdvcmsgaW4gdGhlIHNlbnNl IHRoYXQgdGhlIGJlaGF2aW9yIGlzDQo+ID4gPiB2ZXJ5IHdlbGwgZGVmaW5lZCBpbiB0ZXJtcyBv ZiB0aGUgZWZmZWN0IHRoYXQgdGhlIFJQQyBoYXMgKGkuZS4gdGhlDQo+ID4gPiBlZmZlY3QgaXMg dGhhdCBpdCByZXN1bHQgaW4gY3JlYXRpb24gb2YgYSBzdWJzY3JpcHRpb24sIGlmIGNlcnRhaW4N Cj4gPiA+IGNvbmRpdGlvbnMgYXJlIG1ldCwgYW5kIGl0IGRvZXMgbm90IHJlc3VsdCBpbiBjcmVh dGlvbiBvZiBhDQo+ID4gPiBzdWJzY3JpcHRpb24gaW4gY2FzZSBjZXJ0YWluIGNvbmRpdGlvbnMg YXJlIG5vdCBtZXQpLiAgV2h5IHNob3VsZA0KPiA+ID4gTmV0Y29uZiByZXN0cmljdCB3aGF0IGFu IFJQQyBjYW4gb3IgY2Fubm90IGRvPyAgVGhpcyBpcyBhbGwgYXBwbGljYXRpb24tDQo+IHNwZWNp ZmljLg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gLS0tIEFsZXgNCj4gPiA+DQo+ID4gPg0K PiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gKkZyb206KiBOZXRjb25mIFttYWlsdG86bmV0Y29u Zi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+XSAqT24g QmVoYWxmIE9mDQo+ID4gPiAqQW5keSBCaWVybWFuDQo+ID4gPiAqU2VudDoqIE1vbmRheSwgRGVj ZW1iZXIgMDQsIDIwMTcgOToxNSBBTQ0KPiA+ID4gKlRvOiogTWFydGluIEJqb3JrbHVuZCA8bWJq QHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj4NCj4gPiA+ICpDYzoqIE5ldGNvbmYg PG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+Pg0KPiA+ID4gKlN1Ympl Y3Q6KiBSZTogW05ldGNvbmZdIHlhbmctcHVzaCBpc3N1ZTogZXJyb3IgaGFuZGxpbmcNCj4gPiA+ DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBPbiBNb24s IERlYyA0LCAyMDE3IGF0IDQ6NTUgQU0sIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29t PG1haWx0bzptYmpAdGFpbC1mLmNvbT4+DQo+IHdyb3RlOg0KPiA+ID4NCj4gPiA+IEFuZHkgQmll cm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+PiB3cm90 ZToNCj4gPiA+ID4gSGksDQo+ID4gPiA+DQo+ID4gPiA+IElNTyB0aGUgc3BlY2lhbCBlcnJvciBo YW5kbGluZyBpbiBZQU5HIFB1c2ggaXMgbm90IGFjY2VwdGFibGUNCj4gPiA+ID4gYmVjYXVzZSBp dCB2aW9sYXRlcyBORVRDT05GIGFuZCBSRVNUQ09ORiBlcnJvciBoYW5kbGluZyBwcm9jZWR1cmVz Lg0KPiA+ID4gPiBORVRDT05GIHNheXMgaWYgdGhlIG9wZXJhdGlvbiBkb2VzIG5vdCB3b3JrIGZv ciBhbnkgcmVhc29uIGFuDQo+ID4gPiA+IDxycGMtZXJyb3I+IGVsZW1lbnQgU0hPVUxEIGJlIHJl dHVybmVkLg0KPiA+ID4NCj4gPiA+IEkgZnVsbHkgYWdyZWUsIGFuZCBJIGhhdmUgcG9pbnRlZCB0 aGlzIG91dCBzZXZlcmFsIHRpbWVzIGluIG15DQo+ID4gPiByZXZpZXdzLiAgVGhlIHByb2JsZW0g aXMgYWN0dWFsbHkgaW4gc3Vic2NyaWJlZCBub3RpZmljYXRpb25zLCBhbmQgSQ0KPiA+ID4gdGhp bmsgRXJpYyBpcyB0cmFja2luZyB0aGF0IGlzc3VlLg0KPiA+ID4NCj4gPiA+IFRyeWluZyB0byBi ZSBjb25zdHJ1Y3RpdmUsIEkgdGhpbmsgdGhhdCB0aGUgZXhpc3RpbmcgbWVjaGFuaXNtcyBpbg0K PiA+ID4gWUFORyBjYW4gYmUgdXNlZCB0byBhY2hpZXZlIHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHkg dGhhdCB0aGVzZSBkcmFmdHMNCj4gPiA+IHRyeSB0byBhY2hpZXZlLiAgU3BlY2lmaWNhbGx5Og0K PiA+ID4NCj4gPiA+ICAgMS4gVXNlIGlkZW50aXRpZXMganVzdCBsaWtlIHRoZSBvbmVzIHlvdSBo YXZlDQo+ID4gPiAgICAgICgidW5zdXBwb3J0YWJsZS12b2x1bWUiLCAiZmlsdGVyLXVuYXZhaWxh YmxlIiBldGMpLCBidXQgYWRkIHRleHQNCj4gPiA+ICAgICAgdGhhdCBleHBsYWlucyB0aGF0IHRo ZXNlIGlkZW50aXRpZXMgYXJlIHNlbnQgYXMgImVycm9yLWFwcC10YWciDQo+ID4gPiAgICAgIGlu ICJycGMtZXJyb3IiLCBlbmNvZGVkIHRvIGEgc3RyaW5nIGFzIDxtb2R1bGU+OjxpZGVudGl0eT4u ICBUaGlzDQo+ID4gPiAgICAgIHdvcmtzIGZvciBib3RoIE5FVENPTkYgYW5kIFJFU1RDT05GLg0K PiA+ID4NCj4gPiA+ICAgMi4gRm9yIHRoZSAiaGludHMiIGV4dHJhIGluZm8gdGhhdCB5b3UgcmV0 dXJuLCBkZWZpbmUgYSAieWFuZy1kYXRhIg0KPiA+ID4gICAgICBzdHJ1Y3R1cmUgd2l0aCB0aGUg aGludHMsIGFuZCBleHBsYWluIGluIHRleHQgdGhhdCB0aGlzIHN0cnVjdHVyZQ0KPiA+ID4gICAg ICBpcyByZXR1cm5lZCBpbiAiZXJyb3ItaW5mbyIuICBUaGlzIHdvcmtzIGZvciBib3RoIE5FVENP TkYgYW5kDQo+ID4gPiAgICAgIFJFU1RDT05GLg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4N Cj4gPiA+DQo+ID4gPiArMQ0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gSWYgdGhlIGVycm9y IGhhbmRsaW5nIHdhcyBkb25lIGNvcnJlY3RseSB0aGVuIHRoZSBzYW1lIHByb2NlZHVyZXMNCj4g PiA+IGNvdWxkIGJlDQo+ID4gPg0KPiA+ID4gYXBwbGllZCB0byA8ZWRpdC1jb25maWc+IGZhaWx1 cmVzIGZvciBjb25maWd1cmVkIHN1YnNjcmlwdGlvbnMuDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBBcyBhbiBhbHRlcm5hdGl2ZSB0byAxLCB5b3UgY2Fu IHB1dCB0aGUgZXJyb3IgaWRlbnRpdGl5cmVmIGluIHRoZQ0KPiA+ID4gInlhbmctZGF0YSIgc3Ry dWN0dXJlLCBhbmQgc2VuZCBib3RoIHRoZSBpZGVudGl0aXlyZWYgYW5kIGhpbnRzIGluDQo+ID4g PiAiZXJyb3ItaW5mbyIuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IC9tYXJ0aW4NCj4gPiA+DQo+ID4g Pg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gQW5keQ0KPiA+ID4NCj4gPiA+DQo+ID4gPg0K PiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gPiBUaGUgPGVzdGFibGlzaC1zdWJzY3JpcHRpb24+ IHJldHVybnMgZGF0YSBldmVuIG9uIGVycm9yLg0KPiA+ID4gPiBJbnN0ZWFkIG9mIHRoZSBjb21t b24gZXJyb3ItdGFnLCBlcnJvci1pbmZvLCBhbmQgb3RoZXIgZmllbGRzLA0KPiA+ID4gPiB0aGVy ZSBpcyBhIHN1YnNjcmlwdGlvbi1yZXN1bHQgbGVhZi4NCj4gPiA+ID4NCj4gPiA+ID4gSWYgYW55 IGNsaWVudCAob3IgZXZlbiBzZXJ2ZXIpIGZ1bmN0aW9uYWxpdHkgdXNlcyB0aGUgTkVUQ09ORiBh bmQNCj4gPiA+ID4gUkVTVENPTkYgc3RhbmRhcmQgZXJyb3IgaGFuZGxpbmcsIHRoZW4gc3Vic2Ny aXB0aW9uLXJlc3VsdCB3aWxsDQo+ID4gPiA+IG5vdCBiZSBzZW50IG9yIGV4cGVjdGVkIGFzIGFu IGVycm9yIHJlc3BvbnNlLiBEZXBlbmRpbmcgb24gdGhlDQo+ID4gPiA+IHNlcnZlciBpbXBsZW1l bnRhdGlvbiwgdGhlIGNvZGUgdGhhdCBrbm93cyBhYm91dA0KPiA+ID4gPiBlc3RhYmxpc2gtc3Vi c2NyaXB0aW9uIG1heSBub3QgZ2V0IGNhbGxlZCBiZWNhdXNlIGNvbW1vbiBlcnJvcg0KPiA+ID4g PiBoYW5kbGluZyBjb2RlIGhhcyBhbHJlYWR5IGRldGVybWluZWQgdGhlcmUgaXMgYW4gPHJwYy1l cnJvcj4gdG8NCj4gPiA+ID4gc2VuZCBpbnN0ZWFkIG9mIGEgZGF0YSByZXNwb25zZS4NCj4gPiA+ ID4NCj4gPiA+ID4gRXhwZWN0IHRoYXQgc29tZSBzZXJ2ZXJzIGFyZSBuZXZlciBnb2luZyB0byBz ZW5kIGRhdGEgb24gYW4NCj4gPiA+ID4gb3BlcmF0aW9uIGZhaWx1cmUsIGFuZCB3aWxsIG9ubHkg c2VuZCA8cnBjLWVycm9yPiBpbnN0ZWFkLg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiA+RnJv bSBzZWMuIDMuODoNCj4gPiA+ID4NCj4gPiA+ID4gICAgRm9yIGluc3RhbmNlLCBmb3IgdGhlIGZv bGxvd2luZyByZXF1ZXN0Og0KPiA+ID4gPg0KPiA+ID4gPiA8bmV0Y29uZjpycGMgbWVzc2FnZS1p ZD0iMTAxIg0KPiA+ID4gPiAgICB4bWxuczpuZXRjb25mPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5z Om5ldGNvbmY6YmFzZToxLjAiPg0KPiA+ID4gPiAgICA8ZXN0YWJsaXNoLXN1YnNjcmlwdGlvbg0K PiA+ID4gPiAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLXN1 YnNjcmliZWQtbm90aWZpY2F0aW9ucyINCj4gPiA+ID4gICAgICAgIHhtbG5zOnlwPSJ1cm46aWV0 ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi15YW5nLXB1c2giPg0KPiA+ID4gPiAgICAgICA8eXA6 ZGF0YXN0b3JlPg0KPiA+ID4gPiAgICAgICAgIDx5cDpzb3VyY2UgeG1sbnM9InVybjppZXRmOnBh cmFtczp4bWw6bnM6eWFuZzppZXRmLWRhdGFzdG9yZXMiPg0KPiA+ID4gPiAgICAgICAgICAgb3Bl cmF0aW9uYWwNCj4gPiA+ID4gICAgICAgICA8L3lwOnNvdXJjZT4NCj4gPiA+ID4gICAgICAgICA8 eXA6c3VidHJlZS1maWx0ZXIgbmV0Y29uZjp0eXBlPSJ4cGF0aCINCj4gPiA+ID4gICAgICAgICAg ICAgeG1sbnM6ZXg9Imh0dHA6Ly9leGFtcGxlLmNvbS9zYW1wbGUtZGF0YS8xLjAiDQo+ID4gPiA+ ICAgICAgICAgICAgIHNlbGVjdD0iL2V4OmZvbyIvPg0KPiA+ID4gPiAgICAgICA8L3lwOmRhdGFz dG9yZT4NCj4gPiA+ID4gICAgICAgPHlwOnBlcmlvZD41MDA8L3lwOnBlcmlvZD4NCj4gPiA+ID4g ICAgPC9lc3RhYmxpc2gtc3Vic2NyaXB0aW9uPg0KPiA+ID4gPiA8L25ldGNvbmY6cnBjPg0KPiA+ ID4gPg0KPiA+ID4gPiAgICAgICAgICAgICAgICAgIEZpZ3VyZSAzOiBFc3RhYmxpc2gtU3Vic2Ny aXB0aW9uIGV4YW1wbGUNCj4gPiA+ID4NCj4gPiA+ID4gICAgdGhlIHB1Ymxpc2hlciBtaWdodCBy ZXR1cm46DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IDxycGMtcmVwbHkgbWVzc2FnZS1pZD0i MTAxIg0KPiA+ID4gPiAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6 YmFzZToxLjAiPg0KPiA+ID4gPiAgICA8c3Vic2NyaXB0aW9uLXJlc3VsdA0KPiA+ID4gPiAgICAg ICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLXN1YnNjcmliZWQtbm90 aWZpY2F0aW9ucyINCj4gPiA+ID4gICAgICAgIHhtbG5zOnlwPSJ1cm46aWV0ZjpwYXJhbXM6eG1s Om5zOnlhbmc6aWV0Zi15YW5nLXB1c2giPg0KPiA+ID4gPiAgICAgIHlwOnBlcmlvZC11bnN1cHBv cnRlZA0KPiA+ID4gPiAgICA8L3N1YnNjcmlwdGlvbi1yZXN1bHQ+DQo+ID4gPiA+ICAgIDxwZXJp b2QtaGludCB4bWxuczoidXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYteWFuZy1wdXNo Ij4NCj4gPiA+ID4gICAgICAgMjAwMA0KPiA+ID4gPiAgICA8L3BlcmlvZC1oaW50Pg0KPiA+ID4g PiA8L3JwYy1yZXBseT4NCj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICAgICAgICAgICAgICAgRmln dXJlIDQ6IEVycm9yIHJlc3BvbnNlIGV4YW1wbGUNCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4N Cj4gPiA+ID4gQlRXLCBhbGwgdGhlIGZpbHRlciBleGFtcGxlcyBzZWVtIHRvIGJlIHdyb25nLCBp bmNsdWRpbmcgdGhlIG9uZQ0KPiA+ID4gPiBhYm92ZQ0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4g PiBPTEQ6DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAgPHlwOnN1YnRyZWUtZmlsdGVyIG5ldGNv bmY6dHlwZT0ieHBhdGgiDQo+ID4gPiA+ICAgICAgICAgICAgIHhtbG5zOmV4PSJodHRwOi8vZXhh bXBsZS5jb20vc2FtcGxlLWRhdGEvMS4wIg0KPiA+ID4gPiAgICAgICAgICAgICBzZWxlY3Q9Ii9l eDpmb28iLz4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gTkVXOg0KPiA+ID4gPg0KPiA+ID4g Pg0KPiA+ID4gPiAgICAgICAgIDx5cDpzdWJ0cmVlLWZpbHRlcj4NCj4gPiA+ID4gICAgICAgICAg ICA8ZXg6Zm9vIHhtbG5zOmV4PSJodHRwOi8vZXhhbXBsZS5jb20vc2FtcGxlLWRhdGEvMS4wIg0K PiA+ID4gPiAvPg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgICAgIDwveXA6c3VidHJlZS1maWx0ZXI+ DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IEFuZHkNCj4gPiA+DQo+ID4gPg0KPiA+ID4NCg0K --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD12B7sjceml521mbxchi_ 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 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5JIHN0aWxsIGZpbmQgdGhpcyBhIGJpdCBjbHVua3kgKGFuZCBJIHN0 aWxsIHdvbmRlciBpZiB3ZSBjb3VsZCBkZWZpbmUg4oCcY29ybmVyIGJlaGF2aW9y4oCdIGluc3Rl YWQgb2YgZXJyb3IgY29uZGl0aW9ucyksIGJ1dCBPSywgbGV04oCZcyBnbyB3aXRoIHRoZSBwcm9w b3NlZCBhcyBvdXRsaW5lZA0KIGJ5IE1hcnRpbi4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5MZXTigJlzIGNsb3NlIHRoaXM7IHdlIHdpbGwgdXBkYXRl IHRoZSBSUENzIGFjY29yZGluZ2x5LiZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tLS0gQWxleDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbmR5IEJpZXJtYW4gW21haWx0bzph bmR5QHl1bWF3b3Jrcy5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRGVjZW1iZXIg MDUsIDIwMTcgMjoyMCBQTTxicj4NCjxiPlRvOjwvYj4gQWxleGFuZGVyIENsZW1tICZsdDthbGV4 YW5kZXIuY2xlbW1AaHVhd2VpLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE1hcnRpbiBCam9ya2x1 bmQgJmx0O21iakB0YWlsLWYuY29tJmd0OzsgbmV0Y29uZkBpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW05ldGNvbmZdIHlhbmctcHVzaCBpc3N1ZTogZXJyb3IgaGFuZGxpbmc8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlIGlzIHRoZSBw cm9ibGVtIHdpdGggdGhlIFlBTkcgUHVzaCBlcnJvciBoYW5kbGluZy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSAmbHQ7cnBjLWVycm9yJmd0 OyByZXNwb25zZSBpcyBhIE1VU1QsIG5vdCBhIFNIT1VMRDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6 cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+NC4zLiZuYnNwOyAmbHQ7cnBjLWVy cm9yJmd0OyBFbGVtZW50PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRoZSAmbHQ7cnBjLWVycm9yJmd0OyBl bGVtZW50IGlzIHNlbnQgaW4gJmx0O3JwYy1yZXBseSZndDsgbWVzc2FnZXMgaWYgYW4gZXJyb3I8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgb2NjdXJzIGR1cmluZyB0aGUgcHJvY2Vzc2luZyBvZiBhbiAmbHQ7cnBjJmd0 OyByZXF1ZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBJZiBhIHNlcnZlciBlbmNvdW50ZXJzIG11bHRp cGxlIGVycm9ycyBkdXJpbmcgdGhlIHByb2Nlc3Npbmcgb2YgYW48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgJmx0O3Jw YyZndDsgcmVxdWVzdCwgdGhlICZsdDtycGMtcmVwbHkmZ3Q7IE1BWSBjb250YWluIG11bHRpcGxl ICZsdDtycGMtZXJyb3ImZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGVsZW1lbnRzLiZuYnNwOyBIb3dldmVyLCBh IHNlcnZlciBpcyBub3QgcmVxdWlyZWQgdG8gZGV0ZWN0IG9yIHJlcG9ydCBtb3JlPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IHRoYW4gb25lICZsdDtycGMtZXJyb3ImZ3Q7IGVsZW1lbnQsIGlmIGEgcmVxdWVzdCBjb250 YWlucyBtdWx0aXBsZSBlcnJvcnMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEEgc2VydmVyIGlzIG5vdCByZXF1aXJl ZCB0byBjaGVjayBmb3IgcGFydGljdWxhciBlcnJvciBjb25kaXRpb25zIGluPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IGEgc3BlY2lmaWMgc2VxdWVuY2UuJm5ic3A7IDxiPkEgc2VydmVyIE1VU1QgcmV0dXJuIGFuICZs dDtycGMtZXJyb3ImZ3Q7IGVsZW1lbnQgaWY8bzpwPjwvbzpwPjwvYj48L3NwYW4+PC9wcmU+DQo8 cHJlPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFueSBlcnJvciBj b25kaXRpb25zIG9jY3VyIGR1cmluZyBwcm9jZXNzaW5nLjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQt d3JhcDpicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC13 cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdy YXA6YnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5BbmR5PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6 YnJlYWstd29yZDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gVHVlLCBEZWMgNSwgMjAxNyBhdCAxMjozNSBQTSwgQWxleGFuZGVy IENsZW1tICZsdDs8YSBocmVmPSJtYWlsdG86YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20iIHRh cmdldD0iX2JsYW5rIj5hbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIE1hcnRp biw8YnI+DQo8YnI+DQpTdXJlLCB0aGUgZXZlbnR1YWwgc29sdXRpb24gbWF5IG1ha2UgdXNlIG9m IHJwYy1lcnJvciBhZ2Fpbi4mbmJzcDsgQnV0IHVudGlsIHdlIGdldCB0aGVyZSwgdGhlIGN1cnJl bnRseSBwcm9wb3NlZCBzb2x1dGlvbiBzZWVtcyB0byBtYWtlIHNlbnNlIHRvIG1lLiZuYnNwOyBJ IGRvbid0IHRoaW5rIHdlIGhhdmUgYW4gaXNzdWUgdG9kYXkgd2l0aCBsb3RzIG9mIFJQQ3MgZWFj aCBkZWZpbmluZyB0aGVpciBvd24gd2F5IG9mIGRlYWxpbmcgd2l0aCBjb3JuZXIgY29uZGl0aW9u cw0KIC0gZGVmaW5pdGlvbiBvZiBSUENzIGlzIHNvbWV0aGluZyB0aGF0IGhhcyBzbyBmYXIgb25s eSByYXJlbHkgYmVlbiBleGVyY2lzZWQgd2l0aCBZQU5HIG1vZGVscy4mbmJzcDsgT25jZSB0aGlz IGJlY29tZXMgbW9yZSBjb21tb24sIEkgYW0gc3VyZSB3ZSB3aWxsIGZpbmQgYSBtb3JlIGdlbmVy YWwgc29sdXRpb24sIGJ1dCBJIGRvbid0IHRoaW5rIHdlIGFyZSBhdCB0aGF0IHBvaW50Ljxicj4N Cjxicj4NCi0tLSBBbGV4PGJyPg0KPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCiZndDsgRnJvbTogTWFydGluIEJqb3JrbHVuZCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzptYmpAdGFpbC1mLmNvbSI+bWJqQHRhaWwtZi5jb208L2E+XTxicj4NCiZndDsgU2VudDogVHVl c2RheSwgRGVjZW1iZXIgMDUsIDIwMTcgMTI6MjUgUE08YnI+DQomZ3Q7IFRvOiA8YSBocmVmPSJt YWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+PGJyPg0KJmd0 OyBDYzogQWxleGFuZGVyIENsZW1tICZsdDs8YSBocmVmPSJtYWlsdG86YWxleGFuZGVyLmNsZW1t QGh1YXdlaS5jb20iPmFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPC9hPiZndDs7DQo8YSBocmVm PSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7 IFN1YmplY3Q6IFJlOiBbTmV0Y29uZl0geWFuZy1wdXNoIGlzc3VlOiBlcnJvciBoYW5kbGluZzxi cj4NCiZndDs8YnI+DQomZ3Q7IEFuZHkgQmllcm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlA eXVtYXdvcmtzLmNvbSI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0 OyAmZ3Q7IEhpLDxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGUgcHJvdG9jb2wgZGVm aW5lcyBob3cgZXJyb3IgaGFuZGxpbmcgaXMgZG9uZSwgbm90IHRoZSBpbmRpdmlkdWFsPGJyPg0K Jmd0OyAmZ3Q7IG9wZXJhdGlvbnMuPGJyPg0KJmd0OyAmZ3Q7IElmIHRoZSByZXF1ZXN0IGZhaWxz LCB0aGVuIGNsaWVudHMgZXhwZWN0IGFuICZsdDtycGMtZXJyb3ImZ3Q7IGFuZCBzZXJ2ZXJzPGJy Pg0KJmd0OyAmZ3Q7IGFyZSBkZXNpZ25lZCB0byBzZW5kIGFuICZsdDtycGMtZXJyb3ImZ3Q7IHdo ZW4gYSBjbGllbnQgcmVxdWVzdCBmYWlscy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBBZ3JlZWQsIGFu ZCBmb3IgUkVTVENPTkYsIHRoZSBIVFRQIGVycm9yIGNvZGVzIGFyZSB1c2VkLiZuYnNwOyBBbiBI VFRQIHJlcXVlc3Q8YnI+DQomZ3Q7IHRoYXQgZmFpbHMgZG9lcyBub3QgcmV0dXJuIDIwMCBvayB3 aXRoIGEgYm9keSB0aGF0IGV4cGxhaW5zIHRoYXQgaXQgYWN0dWFsbHkgd2FzPGJyPg0KJmd0OyBh biBlcnJvci48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IElNTywgYSBzZXBhcmF0ZSBlcnJvciBo YW5kbGluZyBwcm9jZWR1cmUgZm9yIGVhY2ggUlBDIGlzIG1vcmUgY2x1bmt5PGJyPg0KJmd0OyAm Z3Q7IHRoYW4gZXJyb3ItaW5mby48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmIzQzOzE8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBTb21lIGFkZGl0aW9uYWwgY29tbWVudHMgaW5saW5lLjxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgV2hpbGUgcG9zc2libGUsIHRoZSBzb2x1dGlvbiBv ZiBoYXZpbmcgdG8gcmV0dXJuIHJwYy1lcnJvciBldGMgZG9lczxicj4NCiZndDsgJmd0OyAmZ3Q7 IHN0cmlrZSBtZSBhcyBzb21ld2hhdCBjbHVua3kuJm5ic3A7IFdoaWxlIGl0IGlzIHBvc3NpYmxl IHRvIGFkZCBhbjxicj4NCiZndDsgJmd0OyAmZ3Q7IGVycm9yLWFwcC10YWcsIGFuZCBuZWdvdGlh dGlvbiBzdHVmZiBhcyBlcnJvci1pbmZvIChhbmQgSSBhcHByZWNpYXRlPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgdGhlIHN1Z2dlc3Rpb24pLCB0aGF0IHNvbHV0aW9uIHdvdWxkIG5lZWQgdG8gYmUgZGVz Y3JpYmVkIHVzaW5nIGE8YnI+DQomZ3Q7ICZndDsgJmd0OyBsb3Qgb2YgcHJvc2UgaW4gZGVzY3Jp cHRpb24gc3RhdGVtZW50cyBhIGxhIFNNSXYyIChwcmVzdW1hYmx5IGFzPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgcGFydCBvZiB0aGUgUlBDIGRlc2NyaXB0aW9uLCBub3QgYXMgcGFydCBvZiBlLmcuIHRo ZSBpZGVudGl0aWVzLDxicj4NCiZndDsgJmd0OyAmZ3Q7IHdoaWNoIG1pZ2h0IGJlIHVzZWQgaW4g YSBudW1iZXIgb2YgcGxhY2VzLCBub3QganVzdCB0aGUgZXJyb3ItYXBwLXRhZykuPGJyPg0KJmd0 Ozxicj4NCiZndDsgSWYgYm90aCB0aGUgZXJyb3IgY29kZSBhbmQgaGludCBpcyBkZWZpbmVkIGlu IGEgeWFuZy1kYXRhIChpLmUuLCBub3QgdXNpbmcgdGhlPGJyPg0KJmd0OyBlcnJvci1hcHAtdGFn KSwgeW91IHdvdWxkIGRvOjxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO3l4Onlhbmct ZGF0YSBzdWJzY3JpcHRpb24tZXJyb3Igezxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO2Nv bnRhaW5lciBzdWJzY3JpcHRpb24tZXJyb3Igezxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtsZWFmIGVycm9yLWNvZGUgezxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7dHlwZSBpZGVudGl0eSB7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmFzZSBlcnJvcjs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 fTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb250YWluZXIgaGludHMgeyAu Li4gfTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7Jm5ic3A7ICZuYnNw O308YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGVuIHlvdSBhcmUgcmlnaHQsIHlvdSBoYXZlIHRvIGRl c2NyaWJlIGluIHByb3NlIHRoYXQgdGhpcyB5YW5nLWRhdGE8YnI+DQomZ3Q7IHN0cnVjdHVyZSBj YW4gYmUgc2VudCBhcyBlcnJvci1pbmZvLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgSSBhbSBub3Qgc3VyZSB3aHkgdGhhdCB3b3VsZCBtYWtlIGFuIFJQQyBhbnkgZWFz aWVyIHRvIGltcGxlbWVudC48YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGUgc2FtZSBjaGVja3Mgc3Rp bGwgaGF2ZSB0byBiZSBtYWRlLjxicj4NCiZndDs8YnI+DQomZ3Q7IEFncmVlZC48YnI+DQomZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgV2h5IHdvdWxkIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBub3Qg YWNjZXB0YWJsZT8mbmJzcDsgJm5ic3A7SWRlYWxseSBZQU5HIHdvdWxkPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgcHJvdmlkZSBiZXR0ZXIgc3VwcG9ydCB0byBmb3JtYWxseSBkZWZpbmUgYXBwbGljYXRp b24vUlBDLXNwZWNpZmljPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcmV0dXJuIGNvZGVzIGFuZCBjb3Ju ZXIgY29uZGl0aW9ucyBldGMuPGJyPg0KJmd0Ozxicj4NCiZndDsgQWxzbyBhZ3JlZWQuJm5ic3A7 IEJ1dCBvbmNlIHdlIGhhdmUgdGhhdCwgc3VjaCBhIHNvbHV0aW9uIHdvdWxkIG1ha2UgdXNlIG9m IHRoZTxicj4NCiZndDsgcnBjLWVycm9yIHdlIGhhdmUgKGZvciBib3RoIE5FVENPTkYgYW5kIFJF U1RDT05GKS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgL21hcnRpbjxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgU2hvcnQgb2YgdGhhdCwgdGhlIHByb3Bvc2Vk IHNvbHV0aW9uIG9mIGFkZGluZyBSUEMgb3V0cHV0IHBhcmFtZXRlcnM8YnI+DQomZ3Q7ICZndDsg Jmd0OyB0aGF0IGFyZSB1c2VkIGZvciB0aGUgcHVycG9zZSBvZiBpbmRpY2F0aW5nIHdoYXQgaXMg Z29pbmcgb24gYXQgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgYXBwbGljYXRpb24gbGV2ZWwgc2lt cGx5IG1ha2VzIHRoZW0gcGFydCBvZiB0aGUgc2VtYW50aWNzIG9mIHRoZTxicj4NCiZndDsgJmd0 OyAmZ3Q7IHNwZWNpZmljIFJQQyBpdHNlbGYuJm5ic3A7IEl0IGlzIG5vdCBOZXRjb25m4oCZcyBy b2xlIHRvIGRlZmluZSB3aGF0IGFuIFJQQzxicj4NCiZndDsgJmd0OyAmZ3Q7IGNhbiBvciBjYW5u b3QgZG8sIGp1c3QgbGlrZSBpdCBjYW5ub3QgZGVmaW5lIHdoYXQgYSBwYXJ0aWN1bGFyIGxlYWY8 YnI+DQomZ3Q7ICZndDsgJmd0OyBtYXkgb3IgbWF5IG5vdCByZXByZXNlbnQuJm5ic3A7IFRoYXQg aXMgcGFydCBvZiB0aGUgUlBDIGRlZmluaXRpb24uPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQmFz aWNhbGx5LCB3aGF0IHdlIGFyZSBkaXNjdXNzaW5nIGhlcmUgaXMgYmVoYXZpb3Igb2Ygc3Vic2Ny aXB0aW9uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY29uZmlndXJhdGlvbiB1bmRlciBjb3JuZXIgY29u ZGl0aW9ucy4mbmJzcDsgVGhlIGZhY3QgdGhhdCBubzxicj4NCiZndDsgJmd0OyAmZ3Q7IHN1YnNj cmlwdGlvbiBpcyBjcmVhdGVkIGJlY2F1c2UgaXQgd291bGQgcmVzdWx0IGluIGFuIHVuYWNjZXB0 YWJsZTxicj4NCiZndDsgJmd0OyAmZ3Q7IHZvbHVtZSBvZiB1cGRhdGVzIGZvciBhIHNwZWNpZmlj IGltcGxlbWVudGF0aW9uIGlzIGRpZmZlcmVudCBmcm9tIGFuPGJyPg0KJmd0OyAmZ3Q7ICZndDsg ZXJyb3IgY29uZGl0aW9uIHN1Y2ggYXMgYSBtYWxmb3JtZWQgbWVzc2FnZSB0aGF0IGlzIG1pc3Np bmcgYTxicj4NCiZndDsgJmd0OyAmZ3Q7IHJlcXVpcmVkIG1lc3NhZ2UtaWQsIG9yIHdoZXJlIGEg dmFsdWUgdmlvbGF0ZXMgYSBjb25zdHJhaW50PGJyPg0KJmd0OyAmZ3Q7ICZndDsgc3BlY2lmaWVk IGluIGEgTVVTVC1jb25kaXRpb24uJm5ic3A7IEluIG91ciBjYXNlLCB3aGF0IGlzIGJlaW5nIGRl c2NyaWJlZCBhcmU8YnI+DQomZ3Q7IHNwZWNpZmljIGNvbmRpdGlvbnMgYXQgdGhlIGFwcGxpY2F0 aW9uIGxheWVyLCBhYm92ZSB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyBOZXRjb25mL1Jlc3Rjb25m IGdlbmVyaWMgdmFsaWRhdGlvbiBpbmZyYXN0cnVjdHVyZS4mbmJzcDsgJm5ic3A7VGhlIG9wZXJh dGlvbiBkb2VzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgbm90IOKAnHdvcmvigJ0gaW4gdGhlIHNlbnNl IHRoYXQgaXQgZG9lcyBub3QgcmVzdWx0IGluIGFuIGFjdGl2ZTxicj4NCiZndDsgJmd0OyAmZ3Q7 IHN1YnNjcmlwdGlvbiwgYnV0IGl0IGRvZXMgd29yayBpbiB0aGUgc2Vuc2UgdGhhdCB0aGUgYmVo YXZpb3IgaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyB2ZXJ5IHdlbGwgZGVmaW5lZCBpbiB0ZXJtcyBv ZiB0aGUgZWZmZWN0IHRoYXQgdGhlIFJQQyBoYXMgKGkuZS4gdGhlPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgZWZmZWN0IGlzIHRoYXQgaXQgcmVzdWx0IGluIGNyZWF0aW9uIG9mIGEgc3Vic2NyaXB0aW9u LCBpZiBjZXJ0YWluPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY29uZGl0aW9ucyBhcmUgbWV0LCBhbmQg aXQgZG9lcyBub3QgcmVzdWx0IGluIGNyZWF0aW9uIG9mIGE8YnI+DQomZ3Q7ICZndDsgJmd0OyBz dWJzY3JpcHRpb24gaW4gY2FzZSBjZXJ0YWluIGNvbmRpdGlvbnMgYXJlIG5vdCBtZXQpLiZuYnNw OyBXaHkgc2hvdWxkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgTmV0Y29uZiByZXN0cmljdCB3aGF0IGFu IFJQQyBjYW4gb3IgY2Fubm90IGRvPyZuYnNwOyBUaGlzIGlzIGFsbCBhcHBsaWNhdGlvbi08YnI+ DQomZ3Q7IHNwZWNpZmljLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IC0tLSBBbGV4PGJyPg0KJmd0 OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICpG cm9tOiogTmV0Y29uZiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0 Zi5vcmciPm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvYT5dICpPbiBCZWhhbGYgT2Y8YnI+DQom Z3Q7ICZndDsgJmd0OyAqQW5keSBCaWVybWFuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgKlNlbnQ6KiBN b25kYXksIERlY2VtYmVyIDA0LCAyMDE3IDk6MTUgQU08YnI+DQomZ3Q7ICZndDsgJmd0OyAqVG86 KiBNYXJ0aW4gQmpvcmtsdW5kICZsdDs8YSBocmVmPSJtYWlsdG86bWJqQHRhaWwtZi5jb20iPm1i akB0YWlsLWYuY29tPC9hPiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAqQ2M6KiBOZXRjb25mICZs dDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgKlN1YmplY3Q6KiBSZTogW05ldGNvbmZdIHlhbmctcHVz aCBpc3N1ZTogZXJyb3IgaGFuZGxpbmc8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7IE9uIE1vbiwgRGVjIDQsIDIwMTcgYXQgNDo1NSBBTSwgTWFydGluIEJqb3Jr bHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIj5tYmpAdGFpbC1mLmNvbTwv YT4mZ3Q7PGJyPg0KJmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7IEFuZHkgQmllcm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNv bSI+YW5keUB5dW1hd29ya3MuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyBIaSw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyBJTU8gdGhlIHNwZWNpYWwgZXJyb3IgaGFuZGxpbmcgaW4gWUFORyBQdXNoIGlzIG5vdCBhY2Nl cHRhYmxlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBiZWNhdXNlIGl0IHZpb2xhdGVzIE5FVENP TkYgYW5kIFJFU1RDT05GIGVycm9yIGhhbmRsaW5nIHByb2NlZHVyZXMuPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBORVRDT05GIHNheXMgaWYgdGhlIG9wZXJhdGlvbiBkb2VzIG5vdCB3b3JrIGZv ciBhbnkgcmVhc29uIGFuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7cnBjLWVycm9yJmd0 OyBlbGVtZW50IFNIT1VMRCBiZSByZXR1cm5lZC48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7IEkgZnVsbHkgYWdyZWUsIGFuZCBJIGhhdmUgcG9pbnRlZCB0aGlzIG91dCBz ZXZlcmFsIHRpbWVzIGluIG15PGJyPg0KJmd0OyAmZ3Q7ICZndDsgcmV2aWV3cy4mbmJzcDsgVGhl IHByb2JsZW0gaXMgYWN0dWFsbHkgaW4gc3Vic2NyaWJlZCBub3RpZmljYXRpb25zLCBhbmQgSTxi cj4NCiZndDsgJmd0OyAmZ3Q7IHRoaW5rIEVyaWMgaXMgdHJhY2tpbmcgdGhhdCBpc3N1ZS48YnI+ DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFRyeWluZyB0byBiZSBjb25zdHJ1 Y3RpdmUsIEkgdGhpbmsgdGhhdCB0aGUgZXhpc3RpbmcgbWVjaGFuaXNtcyBpbjxicj4NCiZndDsg Jmd0OyAmZ3Q7IFlBTkcgY2FuIGJlIHVzZWQgdG8gYWNoaWV2ZSB0aGUgc2FtZSBmdW5jdGlvbmFs aXR5IHRoYXQgdGhlc2UgZHJhZnRzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdHJ5IHRvIGFjaGlldmUu Jm5ic3A7IFNwZWNpZmljYWxseTo8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOzEuIFVzZSBpZGVudGl0aWVzIGp1c3QgbGlrZSB0aGUgb25lcyB5b3Ug aGF2ZTxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgKCZxdW90O3Vuc3Vw cG9ydGFibGUtdm9sdW1lJnF1b3Q7LCAmcXVvdDtmaWx0ZXItdW5hdmFpbGFibGUmcXVvdDsgZXRj KSwgYnV0IGFkZCB0ZXh0PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyB0 aGF0IGV4cGxhaW5zIHRoYXQgdGhlc2UgaWRlbnRpdGllcyBhcmUgc2VudCBhcyAmcXVvdDtlcnJv ci1hcHAtdGFnJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBp biAmcXVvdDtycGMtZXJyb3ImcXVvdDssIGVuY29kZWQgdG8gYSBzdHJpbmcgYXMgJmx0O21vZHVs ZSZndDs6Jmx0O2lkZW50aXR5Jmd0Oy4mbmJzcDsgVGhpczxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgd29ya3MgZm9yIGJvdGggTkVUQ09ORiBhbmQgUkVTVENPTkYuPGJy Pg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsyLiBGb3Ig dGhlICZxdW90O2hpbnRzJnF1b3Q7IGV4dHJhIGluZm8gdGhhdCB5b3UgcmV0dXJuLCBkZWZpbmUg YSAmcXVvdDt5YW5nLWRhdGEmcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7IHN0cnVjdHVyZSB3aXRoIHRoZSBoaW50cywgYW5kIGV4cGxhaW4gaW4gdGV4dCB0aGF0 IHRoaXMgc3RydWN0dXJlPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBp cyByZXR1cm5lZCBpbiAmcXVvdDtlcnJvci1pbmZvJnF1b3Q7LiZuYnNwOyBUaGlzIHdvcmtzIGZv ciBib3RoIE5FVENPTkYgYW5kPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyBSRVNUQ09ORi48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJiM0MzsxPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSWYgdGhlIGVy cm9yIGhhbmRsaW5nIHdhcyBkb25lIGNvcnJlY3RseSB0aGVuIHRoZSBzYW1lIHByb2NlZHVyZXM8 YnI+DQomZ3Q7ICZndDsgJmd0OyBjb3VsZCBiZTxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgYXBwbGllZCB0byAmbHQ7ZWRpdC1jb25maWcmZ3Q7IGZhaWx1cmVzIGZvciBj b25maWd1cmVkIHN1YnNjcmlwdGlvbnMuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQXMgYW4g YWx0ZXJuYXRpdmUgdG8gMSwgeW91IGNhbiBwdXQgdGhlIGVycm9yIGlkZW50aXRpeXJlZiBpbiB0 aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmcXVvdDt5YW5nLWRhdGEmcXVvdDsgc3RydWN0dXJlLCBh bmQgc2VuZCBib3RoIHRoZSBpZGVudGl0aXlyZWYgYW5kIGhpbnRzIGluPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJnF1b3Q7ZXJyb3ItaW5mbyZxdW90Oy48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgL21hcnRpbjxicj4NCiZndDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBBbmR5PGJyPg0K Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgJmx0O2VzdGFibGlzaC1zdWJzY3JpcHRpb24m Z3Q7IHJldHVybnMgZGF0YSBldmVuIG9uIGVycm9yLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg SW5zdGVhZCBvZiB0aGUgY29tbW9uIGVycm9yLXRhZywgZXJyb3ItaW5mbywgYW5kIG90aGVyIGZp ZWxkcyw8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZXJlIGlzIGEgc3Vic2NyaXB0aW9uLXJl c3VsdCBsZWFmLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IElmIGFueSBjbGllbnQgKG9yIGV2ZW4gc2VydmVyKSBmdW5jdGlvbmFsaXR5IHVzZXMgdGhl IE5FVENPTkYgYW5kPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBSRVNUQ09ORiBzdGFuZGFyZCBl cnJvciBoYW5kbGluZywgdGhlbiBzdWJzY3JpcHRpb24tcmVzdWx0IHdpbGw8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IG5vdCBiZSBzZW50IG9yIGV4cGVjdGVkIGFzIGFuIGVycm9yIHJlc3BvbnNl LiBEZXBlbmRpbmcgb24gdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBzZXJ2ZXIgaW1wbGVt ZW50YXRpb24sIHRoZSBjb2RlIHRoYXQga25vd3MgYWJvdXQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IGVzdGFibGlzaC1zdWJzY3JpcHRpb24gbWF5IG5vdCBnZXQgY2FsbGVkIGJlY2F1c2UgY29t bW9uIGVycm9yPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBoYW5kbGluZyBjb2RlIGhhcyBhbHJl YWR5IGRldGVybWluZWQgdGhlcmUgaXMgYW4gJmx0O3JwYy1lcnJvciZndDsgdG88YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IHNlbmQgaW5zdGVhZCBvZiBhIGRhdGEgcmVzcG9uc2UuPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgRXhwZWN0IHRoYXQgc29t ZSBzZXJ2ZXJzIGFyZSBuZXZlciBnb2luZyB0byBzZW5kIGRhdGEgb24gYW48YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7IG9wZXJhdGlvbiBmYWlsdXJlLCBhbmQgd2lsbCBvbmx5IHNlbmQgJmx0O3Jw Yy1lcnJvciZndDsgaW5zdGVhZC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0O0Zyb20gc2VjLiAzLjg6 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsg Jm5ic3A7IEZvciBpbnN0YW5jZSwgZm9yIHRoZSBmb2xsb3dpbmcgcmVxdWVzdDo8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7bmV0Y29uZjpycGMg bWVzc2FnZS1pZD0mcXVvdDsxMDEmcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7 ICZuYnNwOyB4bWxuczpuZXRjb25mPSZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29u ZjpiYXNlOjEuMCZxdW90OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbHQ7ZXN0YWJsaXNoLXN1YnNjcmlwdGlvbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgeG1sbnM9JnF1b3Q7dXJuOmlldGY6cGFyYW1zOnhtbDpu czp5YW5nOmlldGYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB4bWxuczp5cD0mcXVvdDt1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi15YW5nLXB1c2gmcXVvdDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDt5cDpkYXRhc3Rv cmUmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmbHQ7eXA6c291cmNlIHhtbG5zPSZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6 eWFuZzppZXRmLWRhdGFzdG9yZXMmcXVvdDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b3BlcmF0aW9uYWw8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsv eXA6c291cmNlJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Jmx0O3lwOnN1YnRyZWUtZmlsdGVyIG5ldGNvbmY6dHlwZT0mcXVvdDt4 cGF0aCZxdW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt4bWxuczpleD0mcXVvdDs8YSBocmVmPSJodHRwOi8v ZXhhbXBsZS5jb20vc2FtcGxlLWRhdGEvMS4wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2V4YW1w bGUuY29tL3NhbXBsZS1kYXRhLzEuMDwvYT4mcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2VsZWN0PSZx dW90Oy9leDpmb28mcXVvdDsvJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmbHQ7L3lwOmRhdGFzdG9yZSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3lwOnBlcmlvZCZndDs1MDAmbHQ7 L3lwOnBlcmlvZCZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbHQ7 L2VzdGFibGlzaC1zdWJzY3JpcHRpb24mZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7 L25ldGNvbmY6cnBjJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgRmlndXJlIDM6IEVzdGFibGlzaC1TdWJzY3JpcHRpb24gZXhhbXBsZTxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyB0aGUgcHVibGlzaGVyIG1pZ2h0IHJldHVybjo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0O3Jw Yy1yZXBseSBtZXNzYWdlLWlkPSZxdW90OzEwMSZxdW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyB4bWxucz0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5z Om5ldGNvbmY6YmFzZToxLjAmcXVvdDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNw OyAmbmJzcDsgJmx0O3N1YnNjcmlwdGlvbi1yZXN1bHQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHhtbG5zPSZxdW90O3VybjppZXRmOnBhcmFtczp4 bWw6bnM6eWFuZzppZXRmLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyZxdW90Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgeG1sbnM6eXA9JnF1b3Q7 dXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYteWFuZy1wdXNoJnF1b3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyB5cDpwZXJpb2QtdW5zdXBw b3J0ZWQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbHQ7L3N1YnNjcmlw dGlvbi1yZXN1bHQmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJmx0 O3BlcmlvZC1oaW50IHhtbG5zOiZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRm LXlhbmctcHVzaCZxdW90OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7MjAwMDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7 ICZsdDsvcGVyaW9kLWhpbnQmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7L3JwYy1y ZXBseSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgRmlndXJlIDQ6IEVycm9yIHJlc3BvbnNlIGV4YW1wbGU8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEJUVywgYWxsIHRoZSBmaWx0 ZXIgZXhhbXBsZXMgc2VlbSB0byBiZSB3cm9uZywgaW5jbHVkaW5nIHRoZSBvbmU8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IGFib3ZlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IE9MRDo8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmbHQ7eXA6c3VidHJlZS1maWx0ZXIgbmV0Y29uZjp0eXBlPSZxdW90O3hw YXRoJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3htbG5zOmV4PSZxdW90OzxhIGhyZWY9Imh0dHA6Ly9l eGFtcGxlLmNvbS9zYW1wbGUtZGF0YS8xLjAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZXhhbXBs ZS5jb20vc2FtcGxlLWRhdGEvMS4wPC9hPiZxdW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZWxlY3Q9JnF1 b3Q7L2V4OmZvbyZxdW90Oy8mZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IE5FVzo8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3lwOnN1YnRyZWUtZmls dGVyJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbHQ7ZXg6Zm9vIHhtbG5zOmV4PSZxdW90OzxhIGhyZWY9Imh0dHA6 Ly9leGFtcGxlLmNvbS9zYW1wbGUtZGF0YS8xLjAiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZXhh bXBsZS5jb20vc2FtcGxlLWRhdGEvMS4wPC9hPiZxdW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgLyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7L3lwOnN1YnRyZWUtZmlsdGVy Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBBbmR5PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAD12B7sjceml521mbxchi_-- From nobody Tue Dec 5 18:09: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 99249128C82 for ; Tue, 5 Dec 2017 18:09:17 -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 hXM3tEGssKpr for ; Tue, 5 Dec 2017 18:09:14 -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 16590126CF6 for ; Tue, 5 Dec 2017 18:09:14 -0800 (PST) Received: by mail-pl0-x231.google.com with SMTP id 1so53633pla.7 for ; Tue, 05 Dec 2017 18:09:14 -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=wqiZdeYAnGhjrOFvzkxTLpJBmndDLQle7vb6JjHYSN8=; b=I+KCfqAf+NZgmCYe3S2PHsjOyvo4acP7O7XfBrDN5jV2ng2E+PnpkPywSxtOnLWJUt 2keysSTF5eVVjJgdt607xxbxkzMXFmQK+0PWO34sRtVm9FkLa1+0NSAPyFzT6xg32ZJk koLji5MokQAOZPSvCQBPgo6R0eoZj1jeDaWBq9SwEKnlZ7AhZbedvU7iZ/SlkuDP/6XO Ei1lc5Dpt14O/GFHk60Bau4qOat2GX0Dd0cypyrRx/mGZVajxxvx/Dg/C0zL7pIw3Dd6 EvguS2ZWsiEeOQmBWHq9F2jCPQiDWf8VJ8FcxJCM5M1Ol7GRv3JZw/wJzxvU09Ff+me4 17uA== 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=wqiZdeYAnGhjrOFvzkxTLpJBmndDLQle7vb6JjHYSN8=; b=JqrUhKjyUj/YEkAOumS2Wyty1iq54fWyxeWy4kRKyfv86s9gSnPlxUKnbgO3fKIvCk OeHRKcxj18QLu+TaU8aM/sD3ID+smLSTTIGXuGKi4Q8czjOdjniJyte5iuAJcAQBENEs e1cJYIGvLcAJS2Fk0wS2i35sO0ZFsNrks5V2nC1Q/O7OJ56h3jm45qsToQF7oScGpbP2 LE5+pYfydx15UQI0r2wOT0o58H7NrlkYwhLSQ4t8fU2KyzXHCZfMeeUFASczBwS7t3sR DFHUSi8mF2blPw/bWsPH4egreqz1LzBxB+j9R8oeIMP5ydfK5LkxbX7SXL9PA8o6IQPs vrng== X-Gm-Message-State: AJaThX5mfiUzLtiWoXUbJn+VvyBnjVFX6oe4Rr2Twedd1fZ8aYVoqPYU LvgPvUgL3WSZ3itawrm7daM= X-Google-Smtp-Source: AGs4zMYHZpVvg8/O8mUW6KpT4Co7oVfXIiRR3+85xVzrE3/99ofcQos1ZS+sFaqFlCeH3OYr8zm+Qg== X-Received: by 10.159.194.197 with SMTP id u5mr19213715plz.448.1512526153354; Tue, 05 Dec 2017 18:09:13 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:9837:a310:fafb:a3a2]) by smtp.gmail.com with ESMTPSA id k63sm1945698pfk.172.2017.12.05.18.09.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Dec 2017 18:09:12 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_B6C1765C-32E7-4075-A4A1-6DDC5AA054C9" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD12B7@sjceml521-mbx.china.huawei.com> Date: Tue, 5 Dec 2017 18:09:00 -0800 Cc: Andy Bierman , "netconf@ietf.org" Message-Id: <94D948B3-0165-4DA0-B6EB-7911BDB6D4B1@gmail.com> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD10E9@sjceml521-mbx.china.huawei.com> <20171205.212443.660483858000758249.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1165@sjceml521-mbx.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD12B7@sjceml521-mbx.china.huawei.com> To: Alexander Clemm X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Netconf] yang-push issue: error handling 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, 06 Dec 2017 02:09:17 -0000 --Apple-Mail=_B6C1765C-32E7-4075-A4A1-6DDC5AA054C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [Speaking as a contributor] For the record, I agree with Martin and Andy on the use of = as the way to communicate the error. Otherwise, we just create = inconsistencies in implementations that decide their own way of = communicating an error. > On Dec 5, 2017, at 6:01 PM, Alexander Clemm = wrote: >=20 > I still find this a bit clunky (and I still wonder if we could define = =E2=80=9Ccorner behavior=E2=80=9D instead of error conditions), but OK, = let=E2=80=99s go with the proposed as outlined by Martin. =20 > =20 [Speaking as chair] > Let=E2=80=99s close this; we will update the RPCs accordingly. =20 Thanks. > =20 > Thanks > --- Alex=20 > =20 > From: Andy Bierman [mailto:andy@yumaworks.com]=20 > Sent: Tuesday, December 05, 2017 2:20 PM > To: Alexander Clemm > Cc: Martin Bjorklund ; netconf@ietf.org > Subject: Re: [Netconf] yang-push issue: error handling > =20 > Hi, > =20 > Here is the problem with the YANG Push error handling. > The response is a MUST, not a SHOULD: > =20 > 4.3. Element > =20 > The element is sent in messages if an error > occurs during the processing of an request. > =20 > If a server encounters multiple errors during the processing of an > request, the MAY contain multiple > elements. However, a server is not required to detect or report = more > than one element, if a request contains multiple = errors. > A server is not required to check for particular error conditions = in > a specific sequence. A server MUST return an element = if > any error conditions occur during processing. > =20 > =20 > Andy > =20 > =20 > On Tue, Dec 5, 2017 at 12:35 PM, Alexander Clemm = > wrote: > Hi Martin, >=20 > Sure, the eventual solution may make use of rpc-error again. But = until we get there, the currently proposed solution seems to make sense = to me. I don't think we have an issue today with lots of RPCs each = defining their own way of dealing with corner conditions - definition of = RPCs is something that has so far only rarely been exercised with YANG = models. Once this becomes more common, I am sure we will find a more = general solution, but I don't think we are at that point. >=20 > --- Alex >=20 > > -----Original Message----- > > From: Martin Bjorklund [mailto:mbj@tail-f.com = ] > > Sent: Tuesday, December 05, 2017 12:25 PM > > To: andy@yumaworks.com > > Cc: Alexander Clemm >; netconf@ietf.org = > > Subject: Re: [Netconf] yang-push issue: error handling > > > > Andy Bierman > wrote: > > > Hi, > > > > > > The protocol defines how error handling is done, not the = individual > > > operations. > > > If the request fails, then clients expect an and = servers > > > are designed to send an when a client request fails. > > > > Agreed, and for RESTCONF, the HTTP error codes are used. An HTTP = request > > that fails does not return 200 ok with a body that explains that it = actually was > > an error. > > > > > IMO, a separate error handling procedure for each RPC is more = clunky > > > than error-info. > > > > +1 > > > > Some additional comments inline. > > > > > > > > While possible, the solution of having to return rpc-error etc = does > > > > strike me as somewhat clunky. While it is possible to add an > > > > error-app-tag, and negotiation stuff as error-info (and I = appreciate > > > > the suggestion), that solution would need to be described using = a > > > > lot of prose in description statements a la SMIv2 (presumably as > > > > part of the RPC description, not as part of e.g. the identities, > > > > which might be used in a number of places, not just the = error-app-tag). > > > > If both the error code and hint is defined in a yang-data (i.e., not = using the > > error-app-tag), you would do: > > > > yx:yang-data subscription-error { > > container subscription-error { > > leaf error-code { > > type identity { > > base error; > > } > > } > > container hints { ... } > > } > > } > > > > Then you are right, you have to describe in prose that this = yang-data > > structure can be sent as error-info. > > > > > > > > I am not sure why that would make an RPC any easier to = implement. > > > > The same checks still have to be made. > > > > Agreed. > > > > > > Why would the proposed solution not acceptable? Ideally YANG = would > > > > provide better support to formally define = application/RPC-specific > > > > return codes and corner conditions etc. > > > > Also agreed. But once we have that, such a solution would make use = of the > > rpc-error we have (for both NETCONF and RESTCONF). > > > > > > /martin > > > > > > > > Short of that, the proposed solution of adding RPC output = parameters > > > > that are used for the purpose of indicating what is going on at = the > > > > application level simply makes them part of the semantics of the > > > > specific RPC itself. It is not Netconf=E2=80=99s role to define = what an RPC > > > > can or cannot do, just like it cannot define what a particular = leaf > > > > may or may not represent. That is part of the RPC definition. > > > > > > > > > > > > > > > > Basically, what we are discussing here is behavior of = subscription > > > > configuration under corner conditions. The fact that no > > > > subscription is created because it would result in an = unacceptable > > > > volume of updates for a specific implementation is different = from an > > > > error condition such as a malformed message that is missing a > > > > required message-id, or where a value violates a constraint > > > > specified in a MUST-condition. In our case, what is being = described are > > specific conditions at the application layer, above the > > > > Netconf/Restconf generic validation infrastructure. The = operation does > > > > not =E2=80=9Cwork=E2=80=9D in the sense that it does not result = in an active > > > > subscription, but it does work in the sense that the behavior is > > > > very well defined in terms of the effect that the RPC has (i.e. = the > > > > effect is that it result in creation of a subscription, if = certain > > > > conditions are met, and it does not result in creation of a > > > > subscription in case certain conditions are not met). Why = should > > > > Netconf restrict what an RPC can or cannot do? This is all = application- > > specific. > > > > > > > > > > > > > > > > --- Alex > > > > > > > > > > > > > > > > > > > > > > > > *From:* Netconf [mailto:netconf-bounces@ietf.org = ] *On Behalf Of > > > > *Andy Bierman > > > > *Sent:* Monday, December 04, 2017 9:15 AM > > > > *To:* Martin Bjorklund > > > > > *Cc:* Netconf > > > > > *Subject:* Re: [Netconf] yang-push issue: error handling > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Dec 4, 2017 at 4:55 AM, Martin Bjorklund > > > wrote: > > > > > > > > Andy Bierman > = wrote: > > > > > Hi, > > > > > > > > > > IMO the special error handling in YANG Push is not acceptable > > > > > because it violates NETCONF and RESTCONF error handling = procedures. > > > > > NETCONF says if the operation does not work for any reason an > > > > > element SHOULD be returned. > > > > > > > > I fully agree, and I have pointed this out several times in my > > > > reviews. The problem is actually in subscribed notifications, = and I > > > > think Eric is tracking that issue. > > > > > > > > Trying to be constructive, I think that the existing mechanisms = in > > > > YANG can be used to achieve the same functionality that these = drafts > > > > try to achieve. Specifically: > > > > > > > > 1. Use identities just like the ones you have > > > > ("unsupportable-volume", "filter-unavailable" etc), but add = text > > > > that explains that these identities are sent as = "error-app-tag" > > > > in "rpc-error", encoded to a string as :. = This > > > > works for both NETCONF and RESTCONF. > > > > > > > > 2. For the "hints" extra info that you return, define a = "yang-data" > > > > structure with the hints, and explain in text that this = structure > > > > is returned in "error-info". This works for both NETCONF = and > > > > RESTCONF. > > > > > > > > > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > > > If the error handling was done correctly then the same = procedures > > > > could be > > > > > > > > applied to failures for configured subscriptions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > As an alternative to 1, you can put the error identitiyref in = the > > > > "yang-data" structure, and send both the identitiyref and hints = in > > > > "error-info". > > > > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The returns data even on error. > > > > > Instead of the common error-tag, error-info, and other fields, > > > > > there is a subscription-result leaf. > > > > > > > > > > If any client (or even server) functionality uses the NETCONF = and > > > > > RESTCONF standard error handling, then subscription-result = will > > > > > not be sent or expected as an error response. Depending on the > > > > > server implementation, the code that knows about > > > > > establish-subscription may not get called because common error > > > > > handling code has already determined there is an = to > > > > > send instead of a data response. > > > > > > > > > > Expect that some servers are never going to send data on an > > > > > operation failure, and will only send instead. > > > > > > > > > > > > > > > >=46rom sec. 3.8: > > > > > > > > > > For instance, for the following request: > > > > > > > > > > > > > > xmlns:netconf=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > = xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications" > > > > > xmlns:yp=3D"urn:ietf:params:xml:ns:yang:ietf-yang-push"> > > > > > > > > > > > > > > > operational > > > > > > > > > > > > > > xmlns:ex=3D"http://example.com/sample-data/1.0 = " > > > > > select=3D"/ex:foo"/> > > > > > > > > > > 500 > > > > > > > > > > > > > > > > > > > > Figure 3: Establish-Subscription example > > > > > > > > > > the publisher might return: > > > > > > > > > > > > > > > > > > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > > > = xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications" > > > > > xmlns:yp=3D"urn:ietf:params:xml:ns:yang:ietf-yang-push"> > > > > > yp:period-unsupported > > > > > > > > > > > > > > > 2000 > > > > > > > > > > > > > > > > > > > > Figure 4: Error response example > > > > > > > > > > > > > > > > > > > > BTW, all the filter examples seem to be wrong, including the = one > > > > > above > > > > > > > > > > > > > > > OLD: > > > > > > > > > > > > > > xmlns:ex=3D"http://example.com/sample-data/1.0 = " > > > > > select=3D"/ex:foo"/> > > > > > > > > > > > > > > > NEW: > > > > > > > > > > > > > > > > > > > > " > > > > > /> > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > =20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_B6C1765C-32E7-4075-A4A1-6DDC5AA054C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 [Speaking as a contributor]

For the record, I agree with Martin and = Andy on the use of <rpc-error> as the way to communicate the = error. Otherwise, we just create inconsistencies in implementations that = decide their own way of communicating an error.

On Dec 5, 2017, at 6:01 PM, Alexander Clemm = <alexander.clemm@huawei.com> wrote:

I still find this a bit clunky (and I = still wonder if we could define =E2=80=9Ccorner behavior=E2=80=9D = instead of error conditions), but OK, let=E2=80=99s go with the proposed = as outlined by Martin.  

 
[Speakin= g as chair]

Let=E2=80=99s close = this; we will update the RPCs accordingly.  =  

Thanks.

 
Thanks
--- Alex 
 
From: Andy = Bierman [mailto:andy@yumaworks.com] 
Sent: Tuesday, December 05, 2017 = 2:20 PM
To: Alexander Clemm <alexander.clemm@huawei.com>
Cc: Martin Bjorklund <mbj@tail-f.com>; netconf@ietf.org
Subject: Re: [Netconf] yang-push = issue: error handling
 
Hi,
 
Here is the problem with the YANG Push = error handling.
The <rpc-error> response is a MUST, = not a SHOULD:
 
4.3.  <rpc-error> Element
 
   The =
<rpc-error> element is sent in <rpc-reply> messages if an =
error
   occurs during the processing of an =
<rpc> request.
 
   If a server encounters multiple =
errors during the processing of an
   =
<rpc> request, the <rpc-reply> MAY contain multiple =
<rpc-error>
   elements.  =
However, a server is not required to detect or report more
   than one <rpc-error> element, if a request =
contains multiple errors.
   A =
server is not required to check for particular error conditions in
   a specific sequence.  A =
server MUST return an <rpc-error> element if
   any error conditions =
occur during processing.
 
 
Andy
 
 
On Tue, Dec 5, 2017 at 12:35 PM, Alexander Clemm <alexander.clemm@huawei.com> wrote:
Hi Martin,

Sure, the eventual solution may make use of = rpc-error again.  But until we get there, the currently proposed = solution seems to make sense to me.  I don't think we have an issue = today with lots of RPCs each defining their own way of dealing with = corner conditions - definition of RPCs is something that has so far only = rarely been exercised with YANG models.  Once this becomes more = common, I am sure we will find a more general solution, but I don't = think we are at that point.

--- Alex

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: = Tuesday, December 05, 2017 12:25 PM
> To: andy@yumaworks.com
> Cc: Alexander Clemm <alexander.clemm@huawei.com>; netconf@ietf.org
> Subject: Re: [Netconf] yang-push issue: error = handling
>
> Andy Bierman <andy@yumaworks.com> = wrote:
> > Hi,
> >
> > The protocol defines how error handling is done, = not the individual
> > operations.
> = > If the request fails, then clients expect an <rpc-error> and = servers
> > are designed to send an = <rpc-error> when a client request fails.
>
> Agreed, and for RESTCONF, the HTTP error codes are = used.  An HTTP request
> that fails does not = return 200 ok with a body that explains that it actually was
> an error.
>
> > = IMO, a separate error handling procedure for each RPC is more clunky
> > than error-info.
>
> +1
>
> Some additional = comments inline.
>
>
> = > > While possible, the solution of having to return rpc-error etc = does
> > > strike me as somewhat clunky.  = While it is possible to add an
> > > = error-app-tag, and negotiation stuff as error-info (and I appreciate
> > > the suggestion), that solution would need to = be described using a
> > > lot of prose in = description statements a la SMIv2 (presumably as
> > = > part of the RPC description, not as part of e.g. the identities,
> > > which might be used in a number of places, not = just the error-app-tag).
>
> If both = the error code and hint is defined in a yang-data (i.e., not using = the
> error-app-tag), you would do:
>>   yx:yang-data subscription-error {
>     container subscription-error {
>       leaf error-code {
>         type identity {
>           base error;
>         }
>       }
>  =      container hints { ... }
>  =    }
>   }
>
> Then you are right, you have to describe in prose that = this yang-data
> structure can be sent as = error-info.
>
>
> = > > I am not sure why that would make an RPC any easier to = implement.
> > > The same checks still have to be = made.
>
> Agreed.
>
> > > Why would the proposed solution not = acceptable?   Ideally YANG would
> > > = provide better support to formally define application/RPC-specific
> > > return codes and corner conditions etc.
>
> Also agreed.  But once we have = that, such a solution would make use of the
> rpc-error = we have (for both NETCONF and RESTCONF).
>
>
> /martin
>
>
> > > Short of that, the proposed = solution of adding RPC output parameters
> > > = that are used for the purpose of indicating what is going on at the
> > > application level simply makes them part of = the semantics of the
> > > specific RPC = itself.  It is not Netconf=E2=80=99s role to define what an RPC
> > > can or cannot do, just like it cannot define = what a particular leaf
> > > may or may not = represent.  That is part of the RPC definition.
> = > >
> > >
> > >
> > > Basically, what we are discussing here is = behavior of subscription
> > > configuration = under corner conditions.  The fact that no
> > = > subscription is created because it would result in an = unacceptable
> > > volume of updates for a = specific implementation is different from an
> > = > error condition such as a malformed message that is missing a
> > > required message-id, or where a value violates = a constraint
> > > specified in a = MUST-condition.  In our case, what is being described are
> specific conditions at the application layer, above = the
> > > Netconf/Restconf generic validation = infrastructure.   The operation does
> > = > not =E2=80=9Cwork=E2=80=9D in the sense that it does not result in = an active
> > > subscription, but it does work in = the sense that the behavior is
> > > very well = defined in terms of the effect that the RPC has (i.e. the
> > > effect is that it result in creation of a = subscription, if certain
> > > conditions are = met, and it does not result in creation of a
> > = > subscription in case certain conditions are not met).  Why = should
> > > Netconf restrict what an RPC can or = cannot do?  This is all application-
> = specific.
> > >
> > >
> > >
> > > --- Alex
> > >
> > >
> = > >
> > >
> > >
> > > *From:* Netconf [mailto:netconf-bounces@ietf.org] = *On Behalf Of
> > > *Andy Bierman
> > > *Sent:* Monday, December 04, 2017 9:15 AM
> > > *To:* Martin Bjorklund <mbj@tail-f.com>
> > = > *Cc:* Netconf <netconf@ietf.org>
> > > = *Subject:* Re: [Netconf] yang-push issue: error handling
> > >
> > >
> = > >
> > >
> > >
> > >
> > >
> = > > On Mon, Dec 4, 2017 at 4:55 AM, Martin Bjorklund <mbj@tail-f.com>
> = wrote:
> > >
> > > Andy = Bierman <andy@yumaworks.com>= wrote:
> > > > Hi,
> > = > >
> > > > IMO the special error = handling in YANG Push is not acceptable
> > > = > because it violates NETCONF and RESTCONF error handling = procedures.
> > > > NETCONF says if the = operation does not work for any reason an
> > > = > <rpc-error> element SHOULD be returned.
> = > >
> > > I fully agree, and I have pointed = this out several times in my
> > > reviews.  = The problem is actually in subscribed notifications, and I
> > > think Eric is tracking that issue.
> > >
> > > Trying to be = constructive, I think that the existing mechanisms in
> = > > YANG can be used to achieve the same functionality that these = drafts
> > > try to achieve.  = Specifically:
> > >
> > = >   1. Use identities just like the ones you have
> > >      ("unsupportable-volume", = "filter-unavailable" etc), but add text
> > = >      that explains that these identities are sent as = "error-app-tag"
> > >      in = "rpc-error", encoded to a string as = <module>:<identity>.  This
> > = >      works for both NETCONF and RESTCONF.
> > >
> > >   2. = For the "hints" extra info that you return, define a "yang-data"
> > >      structure with the hints, = and explain in text that this structure
> > = >      is returned in "error-info".  This works = for both NETCONF and
> > >      = RESTCONF.
> > >
> > >
> > >
> > >
> = > >
> > > +1
> > = >
> > >
> > >
> > > If the error handling was done correctly then = the same procedures
> > > could be
> > >
> > > applied to = <edit-config> failures for configured subscriptions.
> > >
> > >
> = > >
> > >
> > >
> > >
> > > As an alternative = to 1, you can put the error identitiyref in the
> > = > "yang-data" structure, and send both the identitiyref and hints = in
> > > "error-info".
> > = >
> > >
> > > = /martin
> > >
> > >
> > >
> > >
> = > >
> > > Andy
> > = >
> > >
> > >
> > >
> > >
> = > >
> > > > The = <establish-subscription> returns data even on error.
> > > > Instead of the common error-tag, = error-info, and other fields,
> > > > there is = a subscription-result leaf.
> > > >
> > > > If any client (or even server) = functionality uses the NETCONF and
> > > > = RESTCONF standard error handling, then subscription-result will
> > > > not be sent or expected as an error = response. Depending on the
> > > > server = implementation, the code that knows about
> > > = > establish-subscription may not get called because common error
> > > > handling code has already determined = there is an <rpc-error> to
> > > > send = instead of a data response.
> > > >
> > > > Expect that some servers are never going = to send data on an
> > > > operation failure, = and will only send <rpc-error> instead.
> > = > >
> > > >
> > > = > >=46rom sec. 3.8:
> > > >
> > > >    For instance, for the = following request:
> > > >
> = > > > <netconf:rpc message-id=3D"101"
> = > > >    = xmlns:netconf=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
> > > >    = <establish-subscription
> > > >  =       = xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
> > > >        = xmlns:yp=3D"urn:ietf:params:xml:ns:yang:ietf-yang-push">
> > > >      =  <yp:datastore>
> > > >  =        <yp:source = xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-datastores">
> > > >          =  operational
> > > >      =    </yp:source>
> > > >  =        <yp:subtree-filter netconf:type=3D"xpath"> > > >            =  xmlns:ex=3D"http://example.com/sample-data/1.0"
> = > > >            =  select=3D"/ex:foo"/>
> > > >  =      </yp:datastore>
> > > = >       <yp:period>500</yp:period>
> > > >    = </establish-subscription>
> > > > = </netconf:rpc>
> > > >
> = > > >                =   Figure 3: Establish-Subscription example
> > = > >
> > > >    the publisher = might return:
> > > >
> > = > >
> > > > <rpc-reply = message-id=3D"101"
> > > >      = xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
> = > > >    <subscription-result
> = > > >        = xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications"
> > > >        = xmlns:yp=3D"urn:ietf:params:xml:ns:yang:ietf-yang-push">
> > > >      = yp:period-unsupported
> > > >    = </subscription-result>
> > > >  =   <period-hint = xmlns:"urn:ietf:params:xml:ns:yang:ietf-yang-push">
> = > > >       2000
> > = > >    </period-hint>
> > > = > </rpc-reply>
> > > >
> > > >            =           Figure 4: Error response example
> > > >
> > > >
> > > >
> > > > BTW, = all the filter examples seem to be wrong, including the one
> > > > above
> > > = >
> > > >
> > > > = OLD:
> > > >
> > > = >         <yp:subtree-filter = netconf:type=3D"xpath"
> > > >    =          xmlns:ex=3D"http://example.com/sample-data/1.0"
> = > > >            =  select=3D"/ex:foo"/>
> > > >
> > > >
> > > > NEW:
> > > >
> > > >
> > > >        =  <yp:subtree-filter>
> > > >  =           <ex:foo xmlns:ex=3D"http://example.com/sample-data/1.0"
> = > > > />
> > > >
> = > > >        =  </yp:subtree-filter>
> > > >
> > > >
> > > > Andy
> > >
> > >
> = > >
 
_______________________________________________
Netconf mailing = list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
<= /blockquote>

Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_B6C1765C-32E7-4075-A4A1-6DDC5AA054C9-- From nobody Tue Dec 5 19:33: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 2586C128DE5; Tue, 5 Dec 2017 19:33: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 CY_-lJBcYQxc; Tue, 5 Dec 2017 19:33:21 -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 73FDA126DED; Tue, 5 Dec 2017 19:33:21 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 26249DEA78885; Wed, 6 Dec 2017 03:33:18 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 6 Dec 2017 03:33:19 +0000 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.57]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Wed, 6 Dec 2017 11:33:13 +0800 From: Tianran Zhou To: "draft-bryskin-netconf-automation-framework@ietf.org" , "draft-sambo-netmod-yang-fsm@ietf.org" CC: "netconf@ietf.org" Thread-Topic: Apply FSM model to the YANG PUSH Based Automation Framework Thread-Index: AdNuQu+iVJi2e224RZ+BqibTaZn06g== Date: Wed, 6 Dec 2017 03:33:12 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Netconf] Apply FSM model to the YANG PUSH Based Automation Framework 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, 06 Dec 2017 03:33:23 -0000 Hi, During the NETMOD meeting in Singapore, there were a lot of interesting dis= cussions on the Finite State Machine(FSM) data model presentation. https://tools.ietf.org/html/draft-sambo-netmod-yang-fsm-00 Especially the connection to the proposal on "YANG PUSH Based Generalized N= etwork Control Automation Problem Statement" in NETCONF. https://datatracker.ietf.org/doc/draft-bryskin-netconf-automation-framework= / While the PS proposed to use "event-condition-action" to describe the autom= ation logic, we believe the ECA could be a sub-case of the FSM. Especially = for stateful cases, the FSM is optimal. Here I would like to brainstorm the idea and see your opinion on applying F= SM model to the YANG PUSH Based Automation Framework. Regards, Tianran From nobody Wed Dec 6 00:41: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 A7BFA126C83 for ; Wed, 6 Dec 2017 00:41:35 -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 TeQwJFPgdr5H for ; Wed, 6 Dec 2017 00:41:32 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 398181241FC for ; Wed, 6 Dec 2017 00:41:32 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 724AC1AE0141; Wed, 6 Dec 2017 09:41:29 +0100 (CET) Date: Wed, 06 Dec 2017 09:40:09 +0100 (CET) Message-Id: <20171206.094009.1934958524737452117.mbj@tail-f.com> To: evoit@cisco.com Cc: netconf@ietf.org, balazs.lengyel@ericsson.com, andy@yumaworks.com, alexander.clemm@huawei.com From: Martin Bjorklund In-Reply-To: <422b669242674349975651d2ef7c436e@XCH-RTP-013.cisco.com> References: <16ea77c9d7944aeea09a0b1971ab02a0@XCH-RTP-013.cisco.com> <20171205.110255.1069937786544957099.mbj@tail-f.com> <422b669242674349975651d2ef7c436e@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] 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, 06 Dec 2017 08:41:36 -0000 Hi, "Eric Voit (evoit)" wrote: > Hi Martin, > > > From: Martin Bjorklund, December 5, 2017 5:03 AM > > > > Hi, > > > > "Eric Voit (evoit)" wrote: > > > Hi Martin, > > > > > > Reducing to the open items... [...] > > > > > > 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. > > > > > > > > Maybe "patch-id" could be a sequential number, starting from 1 when > > > > the first patch is sent? Or simply any string that the server finds > > > > appropriate. > > > > In any case, "null" looks odd in the example. > > > > > > Agree "null" looks odd. > > > > > > Does *anyone* have an issue if I make an implementation > > recommendation > > > that the definition the incremental number of the push-change-update > > > for a particular subscription? That would at least make the required > > > field useful? > > I have added the text: > " Of Note in the above example is the 'patch-id' with a value of '1'. > Per [RFC8072], the 'patch-id' is an arbitrary string. With YANG Push, > the publisher SHOULD put into the 'patch-id' a counter starting at '1' > which increments with every 'push-change-update' generated for a > subscription. If used as a counter, this counter MUST be reset to '1' > anytime a resynchronization occurs (i.e., with the sending of a > 'push-update'). Also if used as a counter, the counter MUST be reset > to '1' the after passing a maximum value of '99999'. Such a mechanism > allows easy identification of lost or out-of-sequence update > records. " > > > > > > > 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. > > > > > > > > Ok, but the error code is used as a return value for > > > > "establish-subscription". > > > > So if a server can't detect it at "establish-subscription" it mean > > > > it will never be used. Hence I suggest you remove the text about > > > > "authorization privileges". > > The subscription-terminated notification is valid for dynamically > established subscriptions. This is a valid error code for that > situation. > > > > A publisher could choose to allow a subscription to an empty location > > > where there might plausibly be objects someday. (E.g., maybe where an > > > interface might appear; even if there is no such interface currently > > > existing.) > > > > I think the spec needs to be clear if servers are required to allow > > filters to > > cover non-existing nodes or not (I think it should). > > Hence, selecting a non-existing node should not be an error. > > Agree. The " Receiver Authorization" section now has a clarified > sentence: > " A publisher MAY allow subscriptions which select non-existent or > access-protected data." So it seems you *didn't* agree with what I wrote :) With the selection filter algorithm you have chosen, I think the server MUST allow subscriptions that select non-existing instances. At time t0 the filter might return a node set with a node. Then at time t1 the node set might be empty, this is then reported. Then at time t2 the node set contains a node again, this is then reported. Etc. > > NOTE: we may want to handle the case that the client asks for a node > > that > > can *never* exist (e.g. a node in a non-implemented module or a > > misspelled > > node name) differently than the case that an instance doesn't exist. > > Agree. Such determination is up to the publisher. > > > > Likewise a publisher could choose to reject a subscription because it > > > is obvious that a subscriber will never have access to the requested > > > data. (E.g., maybe always disallow subscription to YANG model which > > > controls the configuration of private keys.) > > > > > > Pretending they might have access someday and allowing the > > > subscription will just waste resources. So I think the error is > > > useful for such situations. > > > > This is fine, but not what the current description says. The text in > > 3.9 and the YANG module don't match. > > on-change-unsupported definition now is: > "On-change is not supported for any objects which are likely to be > provided through the selection filter." See below. > > Also, in the normal case, I don't think the server will know if a > > client will > > *never* have access to some object. > > It will be interesting to see how different publishers optimize for > this situation. > > > > > > > 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. > > > > > > > > No. See RFC7950, section 8.3.1, bullet 4. And compare with all > > > > other modules that use if-feature; no other module has invented such > > > > error codes. > > > > > > Let's handle this on the separate errors thread. The question of > > > legitimate negotiation interactions which are not actually errors is a > > > conversation needing more WG internalization. And without this, we > > > need to figure out how to send errors as part things like > > > subscription-suspended notifications. > > > > I don't think this notification has to change. > > Excellent. Alex will be providing some suggestions on what to do with > error interactions on a parallel thread. > > > > > > 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. > > > > > > > > Ok; i.e., the text should explain that it is used if the client asks > > > > for an obejct that does not support on-change. The if-feature case > > > > is already handled as described above. > > > > > > Have changed the definition to: > > > "On-change is not supportable for any objects which may be provided > > > through the selection filter."; > > > > s/any/all/ ? > > Any. Because this includes any objects which might come into > existence under a subscribed subtree. Logically, "not for all" means that there exists one for which it it false. "not for any" is a bit unclear... Compare: "not all integers in the range 1..10 are even" with: "any integer in the range 1..10 is not even" How about: "This value means that on change is not supported for some node that may be selected by the given filter." > Tweaked the definition to: > "On-change is not supported for any objects which are likely to be > provided through the selection filter." "likely to be provided" is a bit confusing. > > > > > > 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 > > > > > > > > But in this case the error will be "on-change-unsupported", right? > > > > > > I mean to say "except for" rather that e.g. My bad. > > > > > > > > ). Will enhance the > > > > > definition. > > > > > > Current text is now: > > > "Neither synch on start nor resynchonization are supported for this > > > subscription. This error will be used for two reasons. First if an > > > 'establish-subscription' RPC doesn't include 'no-synch-on-start', yet > > > the publisher can't support sending a 'push update' for this > > > subscription for reasons other that 'on-change-unsupported' or > > > 'result-too-big'. > > > > What would that reason be? > > One example might be the CPU capacity is prohibitively low at that > immediate time. Or there are too many subscriptions pulling counters > or routing tables or MAC addresses from a specific line card. Or > other platform wide issues which shouldn't fall under 'result-too-big' > because making the result smaller still won't result in the > subscription being allowed to push the state of current nodes. > > > I think that if the idea is that a server may or > > may not support sync on start, you should make a feature for it and > > call the > > leaf "sync-on-start" instead. And OTOH, if the default is sync on > > start (as it > > is now), it should be required to support it. You didn't reply to this comment. > > > And second, if the 'resynch-subscription' RPC is invoked either for an > > > existing periodic subscription, or for an on-change subscription which > > > can't support resynchronization."; > > > > What would a leagal reason be for the latter case? > > The first case of the RPC being invoked for the periodic case seems > enough for this identity. For an on-change, see the other reasons > above. Having a catch all error code which doesn't futilely drive a > subscriber to attempt smaller subscriptions is worthwhile. > > > > > > (2) The resynch RPC is invoked on a periodic subscription-id > > > > Ok. > > > > > > > , 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 > > > > > > > > Huh? What does *that* mean? > > > > > > As an extreme example: if someone tries to provide a character for a > > > key that only accepts integer. > > > > Note that both subtree filter and xpath allows this and will just > > return an > > empty node set. I really don't think we should change how XPath or > > subtree filter works. So I propose you remove this error. > > Ok. Removed. > > > > Definition is now: > > > "Mismatch between selection filter key provided and the datatype of > > > the referenced YANG datatree node."; > > > > > > You might say this *should* be placed under normal error conditions, > > > per the larger error condition thread. And perhaps this is the case. > > > But there still is the case where a subscription is abnormally > > > terminated or suspended because someone modifies a configured > > > subscription to a non-viable filter which causes this error to pop up. > > > Such an option needs to be reported to a subscriber, and existing > > > error mechanisms don't do this AFAIK. > > > > > > > > > > > > identity datatree-size { > > > > > > > > > > > > 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 > > > > > > > > It will use ds:datastore as base. If we need some other generic > > > > base from which custom datastores are derived, that identity should > > > > be defined in a generic place (ietf-datastores probably), and not > > > > here. > > > > > > Will you put it in that document then? That makes it very easy to > > > delete from here. > > > > That's a discussion for the nmda document, but personally I don't see > > the need for such an identity. In any case, it should be removed > > from this document. > > Removed. I will think about making the request to NMDA. > > > > However a patch must be able to do more than just describe the delta > > > from the previous state to the current state. As per > > target="on-change"/>, it must also be able to identify if transient > > > changes have occurred on an object during a dampening period. To > > > support this, it is valid to encode a YANG patch operation so that its > > > application would result in a no change between the previous and > > > current state. This indicates that some churn has occurred on the > > > object. An example of this would be a patch that does a "create" > > > operation for a datastore node where the receiver believes one already > > > exists, or a "merge" operation which replaces a previous value with > > > the same value. > > > > Hmm, I think that this is a very strange way to indicate "churn", it > > is very > > implicit. Is it really necessary to be able to indicate this "churn"? > > It seems > > quite complex on both the server and client side. > > If a client needs to know this information, it can just not specify a > > dampening period. > > Churn indication is an absolute *must* for security applications. > Both the SACM and I2NSF WGs have indicated need. It is also highly > useful for Network Management applications which simply cannot get a > continuous stream of interface flaps. This is a highly advantageous > capability and I have quite a few customer requests for this. Ok. (so what do you do if you know that churn has happend, but you have no idea what the churn was?) Depending on the outcome of the filter issue (full XPath/subtree filter vs. node-instance-identifier (BTW, will you crete a separate thread for that discussion?)), I will have to come back to this issue. It seems awfully expensive to implement correctly. > > > > > > 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. > > > > > > I forgot the reason why I had mandatory true. It is so that the leaf > > > dampening-period is explicitly there in the RPC to identify this > > > subscription as explicitly on-change. Without the leaf, you need to > > > infer "on-change" through the absence of the "period" leaf. And such > > > a design leaves open a greater chance of unnecessary errors. > > > > I think the current data model has some other problems as well. > > Specifically, the "update-trigger" choice is optional - what does it > > mean if it no case is specified in this choice? Here's a proposal > > for a more explicit datamodel: > > > > choice update-trigger { > > when "../target/datastore/source"; (*) > > mandatory true; > > I have integrated the when & mandatory. > > > case periodic { > > container periodic { > > presence "indicates a periodic subscription"; > > leaf period { ... } > > leaf anchor-time { ... } > > } > > } > > case on-change { > > container on-change { > > presence "indicates an on-change subscription"; > > leaf dampening-period { > > type yang:timeticks; > > default "0"; // or mandatory if you prefer that the client > > // must be explicit > > } > > leaf no-sync-on-start { ... } > > leaf-list excluded-change { ... } > > } > > } > > } > > I included this as well. Honestly the containers are mostly redundant > at this point the information can be gleaned by the available objects. > But I can imagine future triggers which re-use some of the same object > names. This prepares for this time. > > > (*) this path shows another issue with the data model - in the > > "target" you > > have a "source". I think you should rename "source" to "datastore"; > > so in > > the case "datastore" there's a leaf "datastore". > > Also, it shows that it is not clear if the proper name in establish- > > subscription is "target" or "source" - or something else. > > I have renamed source to datastore. /martin From nobody Wed Dec 6 00:47: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 784AE1241FC for ; Wed, 6 Dec 2017 00:47:17 -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 n5C2CC4wmim6 for ; Wed, 6 Dec 2017 00:47: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 70DD8120454 for ; Wed, 6 Dec 2017 00:47:15 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 794231AE0141; Wed, 6 Dec 2017 09:47:14 +0100 (CET) Date: Wed, 06 Dec 2017 09:45:53 +0100 (CET) Message-Id: <20171206.094553.551482340077535543.mbj@tail-f.com> To: alexander.clemm@huawei.com Cc: balazs.lengyel@ericsson.com, andy@yumaworks.com, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1119@sjceml521-mbx.china.huawei.com> References: <81f49c62-e1fe-4a90-a93f-c7fd55229100@ericsson.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1119@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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Netconf] "notifiable-on-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, 06 Dec 2017 08:47:17 -0000 SGksDQoNCkFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+IHdyb3Rl Og0KPiBNeSBwcmVmZXJlbmNlIGlzIHRvIGtlZXAgdGhlIHNvbHV0aW9uIGFzLWlzLCBwZXIgdGhl IGN1cnJlbnQNCj4gc29sdXRpb24gd2l0aCB0aGUgZXh0ZW5zaW9uIHdlIGhhdmUgZGVmaW5lZC4N Cj4gDQo+IFRoYXQgc2FpZCwgSSBoYXZlIHR3byBjb21tZW50cyByZWxhdGVkIHRvIGhvdyB3ZSBj YW4gZ2V0IGNsb3N1cmU/DQo+IA0KPiANCj4gLSAgICAgICAgICBJZiB3ZSBjYW5ub3QgZ2V0IGFn cmVlbWVudCBvbiB0aGlzLCBJIHdvdWxkIG5vdCB3YW50IHRvDQo+IGRlbGF5IFlBTkctUHVzaCBv dmVyIGl0IChsaWtlIE1hcnRpbiBoYXMgaW5kaWNhdGVkIGFzIHdlbGwpLiBJbiB0aGF0DQo+IGNh c2UsIEkgd291bGQgc3VnZ2VzdCB3ZSBhZGQgYW4gaW5mb3JtYXRpb25hbCBzZWN0aW9uIHRoYXQg ZXhwbGFpbnMNCj4gdGhlIGlzc3VlLCBhbmQgb3V0bGluZXMgd2hhdCBhIChwcm9wcmlldGFyeSkg c29sdXRpb24gbWlnaHQgbG9vaw0KPiBsaWtlLg0KDQpTaW5jZSBJIGRvbid0IHRoaW5rIHRoYXQg YSBZQU5HIGV4dGVuc2lvbiBpcyB0aGUgcmlnaHQgc29sdXRpb24gdG8NCnRoaXMgcHJvYmxlbSAo YW5kIG90aGVycyBoYXZlIGluZGljYXRlZCB0aGlzIGFzIHdlbGwpLCBJIGRvIG5vdCB0aGluaw0K dGhhdCB3ZSBzaG91bGQgcmVjb21tZW5kIGFueW9uZSB0byBkbyB0aGF0IGV2ZW4gYXMgYSBwcm9w cmlldGFyeQ0Kc29sdXRpb24sIGFuZCBub3QgZXZlbiBpbiBhbiBpbmZvcm1hdGl2ZSBhcHBlbmRp eC4NCg0KSSB0aGluayB0aGF0IGVpdGhlciB3ZSBzcGVuZCB0aW1lIG9uIGZpZ3VyaW5nIG91dCBh biBhY2NlcHRhYmxlDQpzb2x1dGlvbiB0byB0aGUgV0cgYW5kIGluY2x1ZGUgaXQgaW4gdGhlIGRv Y3VtZW50LCBvciBlbHNlIHdlIHdyaXRlIGENCnNpbXBsZSBzdGF0ZW1lbnQgdGhhdCB0aGlzIGlz IG91dCBvZiBzY29wZSBhbmQgbGVmdCBmb3IgYSBmdXR1cmUNCnNwZWNpZmljYXRpb24uDQoNCg0K DQovbWFydGluDQoNCg0KPiBPZiBjb3Vyc2UsIHVuZm9ydHVuYXRlbHkgdGhpcyB3aWxsIGRlLWZh Y3RvIG1lYW4gdmVuZG9yLXByb3ByaWV0YXJ5IHNvbHV0aW9ucyBhdCB0aGlzIHBvaW50IGFzIHRo aXMgYXNwZWN0IHdpbGwgbmVlZCB0byBiZSBhZGRyZXNzZWQg4oCTIEkgd291bGQgZnVsbHkgZXhw ZWN0IHRoYXQgRXJpY3Nzb24gaW4gdGhhdCBjYXNlIHdpbGwgZGVmaW5lIHRoZSBzYW1lIHNvbHV0 aW9uIGFzIGFuIEVyaWNzc29uLXByb3ByaWV0YXJ5IG1vZHVsZSB3aXRoIGFuIEVyaWNzc29uLXBy b3ByaWV0YXJ5IGV4dGVuc2lvbiAoYXMgb3Bwb3NlZCB0byBoYXZlIGEgc3RhbmRhcmQgc29sdXRp b24pLg0KPiANCj4gLSAgICAgICAgICBJIGRvIHRoaW5rIHRoZXJlIGlzIG1lcml0IHRvIGFsc28g aW5jbHVkZSB0aGUgaW5mb3JtYXRpb24gb2Ygd2hhdCBpcyBub3RpZmlhYmxlIGFzIHBhcnQgb2Yg dGhlIFlBTkctbGlicmFyeS4gIFRoaXMgY291bGQgYmUgcGFydCBvZiB0aGUgcGVybWFuZW50IHNv bHV0aW9uIChhbHRob3VnaCBpdCBkb2VzIG5vdCBhZGRyZXNzIHRoZSBhc3BlY3Qgb2YgaG93IHRo ZSBpbmZvcm1hdGlvbiBpbiB0aGUgbGlicmFyeSB3b3VsZCBiZSBwb3B1bGF0ZWQsIEJhbGF6cyBw ZXIgeW91ciBjb21tZW50KS4gVGhpcyBzcGVjaWZpYyBkaXNjdXNzaW9uIHNob3VsZCBwcm9iYWJs eSBtb3ZlZCB0byB0aGUgWUFORy1saWJyYXJ5IGRpc2N1c3Npb24sIG5vdCB0aGUgb25lIGhlcmUu DQo+IA0KPiAtLS0gQWxleA0KPiANCj4gRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJhbGF6cyBMZW5neWVsDQo+IFNlbnQ6IFR1ZXNk YXksIERlY2VtYmVyIDA1LCAyMDE3IDc6MjggQU0NCj4gVG86IEFuZHkgQmllcm1hbiA8YW5keUB5 dW1hd29ya3MuY29tPjsgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+DQo+IENjOiBO ZXRjb25mIDxuZXRjb25mQGlldGYub3JnPg0KPiBTdWJqZWN0OiBbTmV0Y29uZl0gIm5vdGlmaWFi bGUtb24tY2hhbmdlIiBbd2FzOiBSZTogcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5n LXB1c2gtMTFdDQo+IA0KPiANCj4gSSB2ZXJ5IHN0cm9uZ2x5IG9iamVjdCB0byBleGNsdWRpbmcg dGhlIGlzc3VlLiAgVGhlcmUgaXMgYSBzdHJvbmcgYW5kIGltbWVkaWF0ZSBuZWVkIHRvIGJlIGFi bGUgdG8gc3BlY2lmeSBpbiB2ZW5kb3IgZGVzaWduIHRpbWUgZm9yIHdoaWNoIGRhdGEgbm9kZXMg d2lsbCB0aGVyZSBiZSBvbi1jaGFuZ2Ugbm90aWZpY2F0aW9uIGJlIGdlbmVyYXRlZC4NCj4gDQo+ IFdoZW4gYSB2ZW5kb3IgcmVsZWFzZSBhIHByb2R1Y3QgdGhleSBrbm93IHdoaWNoIG5vZGVzIHdp bGwgZW1pdCBvbi1jaGFuZ2Ugbm90aWZpY2F0aW9ucyBpbiBkZXNpZ24gdGltZS4gU3lzdGVtIGlu dGVncmF0b3JzIG5lZWQgdG8ga25vdyB0aGlzLiBQcm92aWRpbmcgdGhlIHNhbWUgaW5mb3JtYXRp b24gaW4gcnVuLXRpbWUgYXMgaW5zdGFuY2UgZGF0YSBpcyBub3QgYSBnb29kIHNvbHV0aW9uIGVp dGhlciBhcyB5b3Ugd291bGQgbmVlZCB0byBnZXQgYSByZWFsIG5vZGUgdG8gcmVhZCB0aGUgZGF0 YSBmcm9tLg0KPiANCj4gSU1ITyBpZ25vcmluZyB0aGlzIG5lZWQgd291bGQganVzdCBmb3JjZSB0 aGUgdmVuZG9ycyAoaW5jbHVkaW5nIGVyaWNzc29uKSB0byBjcmVhdGUgYW4gb3duIHNvbHV0aW9u Lg0KPiANCj4gQW5keSB3cm90ZTogIkkgYWdyZWUgdGhpcyBpcyBhbiBpbXBsZW1lbnRhdGlvbiBw cm9wZXJ0eSwgYW5kIG5vdCBhIGRhdGEgbW9kZWwgcHJvcGVydHkuIg0KPiANCj4gSSBhbHdheXMg dGhvdWdodCB0aGF0IG9uZSBvZiB0aGUgbWFpbiBwdXJwb3NlcyBvZiBZQU5HIHdhcyB0byBkb2N1 bWVudCB2ZW5kb3IncyBpbXBsZW1lbnRhdGlvbi4gVGhhdCBpcyBleGFjdGx5IHdoYXQgYSBkZXZp YXRpb24gb3IgIGZlYXR1cmUgYWxzbyBkb2VzLiBUaGV5IGFyZSBib3RoIHBhcnQgb2YgWUFORy4N Cj4gDQo+IHJlZ2FyZHMgQmFsYXpzDQo+IA0KPiBPbiAyMDE3LTExLTI4IDE4OjEwLCBBbmR5IEJp ZXJtYW4gd3JvdGU6DQo+IA0KPiANCj4gT24gVHVlLCBOb3YgMjgsIDIwMTcgYXQgMTozNyBBTSwg TWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj4g d3JvdGU6DQo+IEhpLA0KPiANCj4gDQo+IEkgaGF2ZSBub3cgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1u ZXRjb25mLXlhbmctcHVzaC0xMS4gIEkgaGF2ZSBvbmUNCj4gc29tZXdoYXQgbW9yZSBpbXBvcnRh bnQgY29tbWVudCwgYW5kIHNldmVyYWwgb3RoZXJzLg0KPiANCj4gSW1wb3J0YW50IGlzc3VlOg0K PiANCj4gbyAgMy4xMA0KPiANCj4gICBJIGRvbid0IHRoaW5rIHRoZSBwcm9wb3NlZCBZQU5HIGV4 dGVuc2lvbiBpcyB0aGUgY29ycmVjdCBzb2x1dGlvbiB0bw0KPiAgIHRoZSBzdGF0ZWQgcHJvYmxl bSwgZm9yIHNldmVyYWwgcmVhc29uczoNCj4gDQo+ICAgICAxLiAgSW4gbW9zdCBjYXNlcywgdGhp cyBpcyBub3QgYSBwcm9wZXJ0eSBvZiB0aGUgZGF0YSBtb2RlbCwgYnV0DQo+ICAgICAgICAgb2Yg dGhlIGltcGxlbWVudGF0aW9uLCBhbmQgcG9zc2libHkgZXZlbiB0aGUgZGVwbG95bWVudC4gIFNv DQo+ICAgICAgICAgaGF2aW5nIGEgWUFORyBleHRlbnNpb24gc3RhdGVtZW50IGlzIG5vdCBhIGdv b2Qgc29sdXRpb24uDQo+IA0KPiAgICAgMi4gIFdpdGggTkRNQSwgdGhlIHNhbWUgc2NoZW1hIG5v ZGUgaXMgcHJlc2VudCBpbiBkaWZmZXJlbnQNCj4gICAgICAgICBkYXRhc3RvcmVzLiAgSXQgbWln aHQgYmUgdGhlIGNhc2UgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbg0KPiAgICAgICAgIHN1cHBvcnRz IG9uLWNoYW5nZSBmb3IgdGhlIG5vZGUgaW4gYSBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSwNCj4g ICAgICAgICBidXQgbm90IGluIG9wZXJhdGlvbmFsLiAgQWdhaW4sIG1hcmtpbmcgYSBub2RlIGlu IHRoZSBzY2hlbWENCj4gICAgICAgICBpcyBub3QgYSBnb29kIHNvbHV0aW9uLg0KPiANCj4gICAg IDMuICBTaW5jZSB0aGUgb24tY2hhbmdlIHByb3BlcnR5IGlzIGltcGxlbWVudGF0aW9uIGRlcGVu ZGVudCwgaXQNCj4gICAgICAgICBtZWFucyB0aGUgaW5mb3JtYXRpb24gd2lsbCBiZSBhdmFpbGFi bGUgdG8gY2xpZW50cyBvbmx5IGluDQo+ICAgICAgICAgZGV2aWF0aW9uIG1vZHVsZXMuICBUaGlz IGlzIHF1aXRlIGFuIGV4cGVuc2l2ZSBhbmQgY29tcGxpY2F0ZWQNCj4gICAgICAgICB3YXkgdG8g cGFzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIGNsaWVudHMuDQo+IA0KPiANCj4gICBBbiBhbHRl cm5hdGl2ZSBzb2x1dGlvbiBjb3VsZCBiZSB0byBoYXZlIGFuIG9yZGVyZWQgbGlzdCBvZg0KPiAg IGluc3RhbmNlLWlkZW50aWZpZXJzIHRoYXQgbGlzdCB0aGlzIHByb3BlcnR5LCBwZXIgZGF0YXN0 b3JlLCBmb3INCj4gICBleGFtcGxlOg0KPiANCj4gICAgPGVudHJ5Pg0KPiAgICAgIDxwYXRoPi9z eXM6c3lzdGVtL3N5czpzeXN0ZW0tdGltZTxwYXRoPg0KPiAgICAgIDxub3RpZmlhYmxlLW9uLWNo YW5nZT5mYWxzZTwvbm90aWZpYWJsZS1vbi1jaGFuZ2U+DQo+ICAgIDwvZW50cnk+DQo+ICAgIDxl bnRyeT4NCj4gICAgICA8cGF0aD4vc3lzOnN5c3RlbTxwYXRoPg0KPiAgICAgIDxub3RpZmlhYmxl LW9uLWNoYW5nZT50cnVlPC9ub3RpZmlhYmxlLW9uLWNoYW5nZT4NCj4gICAgPC9lbnRyeT4NCj4g DQo+ICAgWWV0IGFub3RoZXIgYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gbGVhdmUgdGhpcyB0byBm dXR1cmUgd29yay4NCj4gDQo+IA0KPiBJIHdvdWxkIHByZWZlciB0byBsZWF2ZSB0aGlzIHRvIGZ1 dHVyZSB3b3JrLg0KPiBJIGFncmVlIHRoaXMgaXMgYW4gaW1wbGVtZW50YXRpb24gcHJvcGVydHks IGFuZCBub3QgYSBkYXRhIG1vZGVsIHByb3BlcnR5Lg0KPiANCj4gQW5keQ0KPiANCj4gDQo+IA0K PiANCj4gDQo+IC0tDQo+IA0KPiBCYWxhenMgTGVuZ3llbCAgICAgICAgICAgICAgICAgICAgICAg RXJpY3Nzb24gSHVuZ2FyeSBMdGQuDQo+IA0KPiBTZW5pb3IgU3BlY2lhbGlzdA0KPiANCj4gTW9i aWxlOiArMzYtNzAtMzMwLTc5MDkgICAgICAgICAgICAgIGVtYWlsOiBCYWxhenMuTGVuZ3llbEBl cmljc3Nvbi5jb208bWFpbHRvOkJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbT4NCg== From nobody Wed Dec 6 01:02: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 1BB46127078 for ; Wed, 6 Dec 2017 01:02:36 -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 2MAZT4VPSwmt for ; Wed, 6 Dec 2017 01:02:33 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 31859127010 for ; Wed, 6 Dec 2017 01:02:33 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 5031E1AE0141; Wed, 6 Dec 2017 10:02:32 +0100 (CET) Date: Wed, 06 Dec 2017 10:01:12 +0100 (CET) Message-Id: <20171206.100112.298803456348365967.mbj@tail-f.com> To: balazs.lengyel@ericsson.com Cc: andy@yumaworks.com, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <81f49c62-e1fe-4a90-a93f-c7fd55229100@ericsson.com> References: <20171128.103735.1654378548309425095.mbj@tail-f.com> <81f49c62-e1fe-4a90-a93f-c7fd55229100@ericsson.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] "notifiable-on-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, 06 Dec 2017 09:02:36 -0000 Balazs Lengyel wrote: > I very strongly object to excluding the issue. There is a strong and > immediate need to be able to specify in vendor design time for which > data nodes will there be on-change notification be generated. > > When a vendor release a product they know which nodes will emit > on-change notifications in design time. System integrators need to > know this. Providing the same information in run-time as instance data > is not a good solution either as you would need to get a real node to > read the data from. The same argument applies to which YANG modules, features and deviations a product supports. In SMIv2 we had AGENT-CAPABILITIES which was an off-line document with this information. The experience seems to be that it was rarely used by managers. In YANG we provide this information on-line with the YANG library (and at least our experience so far is that this *is* used by clients). It would probably be a good idea to combine these two approaches. I think that this would be fairly straight-forward. As a first approximation, suppose we had a standard file format for a "server-capabilities" document. It could be something like this: // this identifier must also be available on the device, so that // a client can match the capability document with the device. some unique identifier // meta-data goes here ... ... ... // the contents of yang-library from this product // with modules, features, deviations // ... and possibly on-change info Now, this won't be useful for all systems, for example if the server is very dynamic and support dynamic loading of packages etc. /martin > IMHO ignoring this need would just force the vendors (including > ericsson) to create an own solution. > > Andy wrote: "I agree this is an implementation property, and not a > data model property." > > I always thought that one of the main purposes of YANG was to document > vendor's implementation. That is exactly what a deviation or feature > also does. They are both part of YANG. > > regards Balazs > > On 2017-11-28 18:10, Andy Bierman wrote: > > > > > > 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 > > > > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Wed Dec 6 02:11: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 6271912944A for ; Wed, 6 Dec 2017 02:11:51 -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_H4=-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 HY4IKOFHnjw5 for ; Wed, 6 Dec 2017 02:11:49 -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 44CED129443 for ; Wed, 6 Dec 2017 02:11:49 -0800 (PST) X-AuditID: c1b4fb3a-3edff70000003538-e1-5a27c263586c Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B8.7E.13624.362C72A5; Wed, 6 Dec 2017 11:11:47 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.72) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 6 Dec 2017 11:11:47 +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=KCENT3KZxifHxiG1sdr8T4tKVGYONiKDrni/eUIT8DQ=; b=caf10jfkb9ZbxN0XIIU2CcnMr4KkfDfabMAEFEcNJNnasM9C0zFJ1b7/PROnECL1dm2zy/vukufz8I+xn2D1gKdmSG0k2bUrRjxbE3GZpb5+3vJLySjwuh+yjHcmYTmUS4ACjxL5Wfu4yi2VvEoYSc70+sO/6yiJRx4pTU4UCLM= Received: from [159.107.197.108] (91.82.100.59) by HE1PR07MB3435.eurprd07.prod.outlook.com (2603:10a6:7:2c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.2; Wed, 6 Dec 2017 10:11:44 +0000 To: Martin Bjorklund CC: , References: <20171128.103735.1654378548309425095.mbj@tail-f.com> <81f49c62-e1fe-4a90-a93f-c7fd55229100@ericsson.com> <20171206.100112.298803456348365967.mbj@tail-f.com> From: Balazs Lengyel Message-ID: Date: Wed, 6 Dec 2017 11:11:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171206.100112.298803456348365967.mbj@tail-f.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: HE1P195CA0018.EURP195.PROD.OUTLOOK.COM (2603:10a6:3:fd::28) To HE1PR07MB3435.eurprd07.prod.outlook.com (2603:10a6:7:2c::14) X-MS-Office365-Filtering-Correlation-Id: a0e8312d-68bb-49b8-2354-08d53c91c106 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:HE1PR07MB3435; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3435; 3:ABciVEk2X0Tr5gIyYWJQDtTfCwobTVSerCmHJwnrHVzhlEEWWQ11SJQBlIbm46WQl0ToQixS5vkUQD3q8zJ46WPNSTIRpb/M3wJrZJ7CEnwetQDSmkXJBnij/Gu4jwfzAwGK8BrWk0NWGOzqFFasSSVq98yUR4OeJmWsJuk/CF5Rx9Ioc95vfviP/jX/WADjTlF+C1eyvB1ickzM7TK85MHlEv9WXjaHwEuYlAoLN+fe4yxPNGqky/ve+tR+dziF; 25:O08BiQ2lmORO1jSq2gl0M5Rlf6E00f7G/S+2Ts8WdNiUqKnjS5NbbGnDzl+7krn/m6lseouDiZSjPN4C4JTjG8a7E9aX417QNDfGr8gJyqlN4TpbBvFC/mNUJwbC4Is+Z0FpdxYFKqKm17c76rZkKTV0tgF/B9bZD2MKYh85gEzv9FhF4iT53Qh2RxIRhnvObzDMstHHt1fnyKs20ppAit/b410OLihOdU7SO0VmojyjIAgUmrJ0gjjg4ZNilSMuemGDXkZ5Wgq0iPtMItohJONHuPsvlBH9ZlkMR8sOR2bsVxglNadykYS+4hr6+CdrriSbcPXUoEVdRgbtVLU1ew==; 31:fMvV0u7iVsc9C8ce3TVI4Z2lS9b6u5Sxf3rccNIcQ+uk2Nfn2v+cAptVMhagRW1IG863ySvojXbjFdWU15SJlXq2+4i2p6imUocNRm3c5VbntfzMjc30Gm5qGG3oOmGTvCZXFs6gCvqszwVz0DMude+xEiQ3MR083uMAFdpDdc0m4ztYdW4eAvyeIjuTKzTh52z9ZZynKdTwfzbde5YTqW4bdwtyBjR2jirhIkbxxH0= X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: HE1PR07MB3435: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3435; 20:lSzT7yB3NL9PB7wCy/3s78fIk1km7Fyc5xhdBJrT1yML+iummdl2zYf2Wcbd9ZEwzWyve54rgu71KTjTYI8WPT1zrsDglthTbfUR2E8MHAsKp5drjKddaGu8vQPpl/YB7KfD6ONIoeHbWE/moTgBeIbqmxLssHrxOWTYDPq47v1GQdB4LKgFFSlnw00yCx6epfsEMXq77Y51kEY660YDAAUCaLzSV73IL4RYzpKw7LbgAHVQrHryZoxgHHjUUGwfMxjc80kiIHJKq0y7TCzQsSMWbfXJLJy8haZzrt8frKjH5ptRN8VTIk2yog5mvVG+YvwvClw/YRIn9TH+T7u0liCZK2ek2X0Xbz1n4iJ3t90HMUHE0soNJwVm3F3a0bMcJpavsTG+zTLv2h5NsHCbu0RODNzWEWCC8Bmk7O3UOyycVZTgbkAvHs8CflTvnWaT5d0pVHJmlSGLAl62dGYETGuujQtlDiRM+HLtIabjJZ+2ZjW5Jwb4QQg5dq7+bDfF; 4:79CU1Nmw/z1JGM62uAvs5WlljYnYuAHVKT1z1P0Zdag0V7xRKL1to1RzLTFMuOu59/SM+/iJhPIbhUSWoTkXWznRVXpvGZaP8X1FhcvlhNVYpNqSMzMi6CBcRtHcsBJC+vB43PNwrd4Js0cYTwIiKIPLr5Ez9+bsQN6MLuJsY4zVtPztrtO9rg8FONQU60lYT5Te+aa9l302ytq+UEtqAQAFSVEFgcAKS2BsHY/w8DQ511XLHPjM6tvbF3yLcOh5ano2fmmky1/xyIxQXa7jdp/3Jd0YWDlYXqpH4P75rTEuMXbN2qY2OFe8pXAlFpwJ2WCNGApeotNlVjcCfZH8XuAbI+vUYSGxakA1UTZK974= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231022)(93006095)(93001095)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(6072148)(201708071742011); SRVR:HE1PR07MB3435; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR07MB3435; X-Forefront-PRVS: 05134F8B4F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(39860400002)(376002)(366004)(346002)(252514010)(199004)(189003)(68736007)(67846002)(65826007)(36756003)(58126008)(105586002)(5660300001)(50466002)(2906002)(6666003)(31696002)(6246003)(86362001)(81166006)(6916009)(53936002)(25786009)(2870700001)(81156014)(8676002)(6486002)(305945005)(7736002)(93886005)(561944003)(52146003)(2950100002)(76176011)(31686004)(106356001)(64126003)(3846002)(8936002)(52116002)(6116002)(97736004)(16576012)(230783001)(316002)(47776003)(23676004)(2486003)(83506002)(101416001)(478600001)(4326008)(65806001)(16526018)(66066001)(65956001)(33646002)(49976008)(229853002)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3435; H:[159.107.197.108]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:3; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIzNDM1OzIzOlR0aWxlWkdGTXBmcEVBZnN0K3djbVJWVXlt?= =?utf-8?B?b0FZRXlUM1preS9CZktMdEp0eTBGWlR0eUx5TFdEQmNmS0U2NzNzQ053RzEv?= =?utf-8?B?VWwrNXBvbHRtZStaWFJxYkVrbFVmQkF6akt0ZkpHN1FSbnh3Z1JvbGFwTVd4?= =?utf-8?B?T0czU0xXVmlDSmo0V0cvYXhhMTUyaGZIM1lFVFFHZ3VSODE1aEFnNGlHS2Yy?= =?utf-8?B?ZzQ3WTlYWmtoeVdWZWljZDd5Q0JqcFg5aENsejAxWnJJaDdsdDVsdk9Ob1ZB?= =?utf-8?B?ZDdZSHZ4T0ZPU1FkV0NncENxNklzaU1NMzJ2Rlp2NWJoZGtMSktxcStmblp5?= =?utf-8?B?VTJlZ2JUTkM3ZkJobHdYUlh0YUxOLy9nc1ZUbzNvTS9iU0pUYXJFcGp0UVFG?= =?utf-8?B?YTFob3ZES3N1akxQeXdPaGNEdEo3djZRazdmNmVzbVFNTVpCZWlPbnJwSnhx?= =?utf-8?B?UnkrdnpCeHhRQjBuNWcxYnV3SWRsanVkb0Y2U1ZmelZ4NjhiV2g3ZWo2eEky?= =?utf-8?B?a1FLOEM1YU4zUy85M1kwUUl0aTMrb1Y4bUZFRm05ZWwrc2gxZHVmWnRTbnhz?= =?utf-8?B?ZEk3dGl2Sm03RERTUmhldWZnNFlqbmxESnY4QnVVOFJnY1Rka1NLeUIxdlFR?= =?utf-8?B?cTdESWIyczVlNUUzRUFzRXpIeFJGL1BDakt0a1JOdjRDTk84NG9Lckc5R0tI?= =?utf-8?B?TXBhSDVmNC9qOUp6THpjN2VFekhsL3hIanEzTW8yQjQ0OUY4VGpIQ2hsbW92?= =?utf-8?B?Z2tQUXNlSStQVnJ6cFBTQWxYU0J3OGE5c2o0MnYwemhDYlNrWFYwZGN6NW9F?= =?utf-8?B?RVk1R1RjMG1IYitLZHJCSFR0dElncEIzRTJNbUR6QzFCWmxPeFJRejVCWnM2?= =?utf-8?B?bHF1VWdZd01PeklZZ1lvMHViSDczN3A0T25NWWRrUXZMSmhKRXg2V2hjeGVr?= =?utf-8?B?bW1OcXBkc2lFWDk1ZzhNTnp4TmFnT05jUE9VTFZmNk9oYmtUTitsTnlGdkF3?= =?utf-8?B?dWRxYW5lRmN3cXFDall4cWkvTzdsL3dzSzhPNU5PQVRkdkJTWUpaUnZlZW0r?= =?utf-8?B?L25OR3k5QU1xTlJuSFp1WXduT3JmTGVac3didEpxK0FaMVRKcXVEdS9WelRT?= =?utf-8?B?czJEb1RFVjN3Y1owSnZJajZwU1ZIdWMyQmZwUkJTUHNlcEFSeitWbUwwZVds?= =?utf-8?B?OHhSM1p1QzBRalZiRmgvendRVXE5clJBcXFuNWIyclJzcHZFWkRiSThKSmlq?= =?utf-8?B?NXpNelpsSUpIZkQ2VWVWRjBPcVRxUG5vWm4zb0krSDVubkd6ZVM2ZFFZSUNi?= =?utf-8?B?SmtINCsycHBVeVBoZVZyTkZDeHVBbThPM0doVm5mVWIxTlJWSytVLzRsTXVm?= =?utf-8?B?amEwQVRrNFYvOTE2YzhzL0ljanNqRXAyMVh6WVBXU2NJbU9vVmVnVlNwR0VK?= =?utf-8?B?ODZGY29vSWZ4WFJCOU1vTDZmcnk3NDJod1pnQm5kZmc0d0U0cTFsc1Erb2NE?= =?utf-8?B?Mm5tZVlKajhSZXBDV3QxUjhYQThxTytjazFZRm5tL0RMTjVQa1JDcTh2Qy96?= =?utf-8?B?SHJSb2ZKQnFkSkREMEh4czVSaURBNFNyTzJMcXFlWjFVR1BDQytzMW4rZVRT?= =?utf-8?B?WFcxREE1VlBNQUdBdW00ZnVTTWhxT050U1EvYzBNQlpaS0hlRUVNWUU4S3Nw?= =?utf-8?B?ei8yek8xcTdDMjNxSXI2YWI0ZXBSWExKNDE0SEFWdnZFbG0yOURoaE9tcm96?= =?utf-8?B?UEFSeVo5R2QwQ1VaWVRwVWpkRnIvMGZ0bFRkRUdWM2o3UnM0THhPbERRem5T?= =?utf-8?B?T2VPWkl6RVFkVjNIRTZMVmdqMkR0cmpQeGF5RzduWnRvM2lFazBEbWd1Y1pa?= =?utf-8?B?TXBCZE4wc20vZTdjOStvWnR5Wm44NU50NGFqTGlFTGNDQXc5YVducW1paTdl?= =?utf-8?B?cmlYdGF6VU1BPT0=?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3435; 6:CFHZ/BB2JXpDNmrBljopt17fiKpAkcDrQm5ws9QiaIPqzNEbqbeVUdu0XVyLpTTTqkk+ack5JFg3J2nTdXzkVhnPNsKYH+IekMZ0zxQSNWQ+NdLHBnDjPHGcH19QzrkouiF75GHsJnVHibVtFORb5kTr9Cefb0+o1HGcfJEgZnxDnWaEMZLT2y63fuqjsPQtvq8z66wrT/PKMhYxq6br/0DWIlPgcBXHhATlzaKqBuarCQLcmPWRwvcsW21KAcDLXbrZwGtMK0gMYqZZRHfaQAySFX6QrNrUNcw9YDdooKelgcWrfgytVQfZiotMy0ba44h0+SsCk5WaMlYCDqW2l79DEhwwK4FA55aXPHN0x9A=; 5:qMqEi3VR4UZLxWCTO5qmowiGyVCv5CILIDvbx9E/0BQzO0SSD7dCp9IEcwct1mQ4WMY03/ja7cXAXEgFLsgsj5h/1PY6C7Yuagu4aUANfO/+51L0sBW4WIkrsUxVqdZhjEK73Rd0ToIN/BbNE8Dao72B4GVbRsqLbReyYgFtzLg=; 24:WXECtJS2kuLbk1J399EdBlNAxXpCba+zM23X1BDANqew51gOcZvzBJlc8cRg4Zv50Df/81nCur2F4PgweHH3kCFA80HISU01Fh+nADZaWTQ=; 7:5DVUPam7czDV8OVmlgnJzNamRLP3b/A9SvqIsWyafq7N6D0q0kMXGXbczus0HwT+xmzE4QxV09N0nczS0N5knn2Q6dMYoPRoynGcmj/s0j6FpgRw9qVjkqVcwLM3IPuiPrqu0g8s/ju97wsLxAFS4rTF6QV/ZZxuynVN11q0xhVVQf4Mv5LwjAz16SNP8b3amjCfHyXdV3ETpP6iPLsYH8UZ39sstiRoAgCldTBPaDA6ygRSmpUA49tgPTSJSw/0 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Dec 2017 10:11:44.6622 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a0e8312d-68bb-49b8-2354-08d53c91c106 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3435 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRiGeXfO2Y7D1dt0+WCKYyqK+FGisKJSIWohZj9rRLb0oKZO2THT fi3Uss1UiFVOS8NpYGrkB2YUbrMUzdRlpVliwrBcsqJJaSbkdgz27+K9r+fhueGlCXEdFUjn qosZjVqVL+MLyfpT/YqYTGuEcu/Eskz++YVRINfrlwRyQ/dHKplQmEzrPMXjPy2koqLWRp4k lMKDWUx+bgmjiTt8Tpgz1eXgF9l2l65Md/G0qEmsQz404ASYsN4idUhIi/EQgvn1QZ47EOMR BMNzpe6AxDcI6Gxp5XNWJQ/GdGuE2/LDobBebfZM+ONwsA90km4mcDTca+gguE0uBFpnpJv5 OB4MtZMeR4SToN31yMMkDoNvqw8oN0vwGRiqvk1xzi4Yrbd7HB+cDM97fwu4/XKob5pEHIdA eV8DwXEAzNmbeFw1Kcz0zHiqAa5D0Hinn+IOioTFqU2Kk9Jg1fkecWxCoB88xg1oBVDRuLa9 KRhevm4kOY6CtrFfnisQPgsDHfcpbsAkAJupi89JefDWUb7NqXBtaVrASc0E1Bhmt4Mg+LS5 SNShaKNXVaNXPaNXPaNXvWZEtiMJy7BsQXZ8fCyjyc1k2UJ1rJop7kZb/8TSu3HgCbJ8SbEi TCOZr+jVwwilmFKVsGUFVgQ0IfMXYcvWkyhLVXaZ0RRmaC7mM6wV7aFJWYBo9LhIKcbZqmIm j2GKGM3/lEf7BGpRK0l+H66af3dklrGn17zp6Wsr8duI2Z9qPJFTGrPz7qWIq75B5om8p1E2 zXnjiP6ZxNJmXwhO3JGaeCGlMy3JUeMKX5FU0guxfdajp8eZcdqZ/uNQ6DiZkPFB+tNRtbEc plu74ioz/5WGfEUGpVRlDusYXo27ed1qSjYWgFNGsjmqfVGEhlX9A0a9x2UjAwAA Archived-At: Subject: Re: [Netconf] "notifiable-on-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, 06 Dec 2017 10:11:51 -0000 Re: "notifiable-on-change" -------------------------- We have an immediate strong use-case where we need to know for which data nodes will the server emit push-change-update notifications. Without a clean standard proposal the yang-push solution is incomplete, not ready. As noted by others too, servers will not send push-change-updates for every data node. The usual reasons for not sending push-change-updates is: - value of the data node changes frequently (e.g. in-octets counter) - small changes are frequent and meaningless (e.g., a temperature gauge changing 0.1 degrees), - the implementation is not capable of on-change notification for a particular object (specially relevant for state data) All the above reasons are known in design time when the _vendor_ defines the product.  All are related to a particular model or schema part. There may be other reasons, in which case please list them and propose a solution covering them! Often when you release a network node you also release an associated NMS (network management system) with it. The NMS depends on receiving push-change-update notifications. I can't write an algorithm that may or my not receive data. During NMS implementation the information about push-change-updates is needed. If the information about push-change-updates is not available early in some document, but only as instance data from the network node, the NMS implementation will be delayed, because it has to wait for the network node to be ready. Also assuming that all NMS implementors will have a correctly configured network node available to retrieve data from, is very expensive. (An NMS may handle dozens of node types.) Beside NMS implementors, system integrators and many others also need the same information early.  Model driven testing, generating documentation comes to my mind immediately. The currently proposed notifiable-on-change extension is a simple solution that solves a real problem. It does not preclude a later definition of a YANG model about the same information. It is not the only possible solution, but a reasonable one. During the work-group phase a number of other solutions were discussed and not selected. You write: "The same argument applies to which YANG modules, features and deviations a product supports." Yes, however this does not mean that the use-case is invalid, it only means that YANG does not handle it well. Do we want to make a bad situation worse. Do we care about NMS developers? Yes you could document all this in plain English or vendor solutions, but IMHO the IETF's task, our task is to create standardized, formal solutions for the common use-cases. -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Wed Dec 6 02:32:48 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 13CEB12957C for ; Wed, 6 Dec 2017 02:32:47 -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 46Hm1UeYuyMy for ; Wed, 6 Dec 2017 02:32:45 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72C7128799 for ; Wed, 6 Dec 2017 02:32:44 -0800 (PST) X-AuditID: c1b4fb2d-139999c0000036aa-8a-5a27c74aa156 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 78.E9.13994.A47C72A5; Wed, 6 Dec 2017 11:32:42 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.87) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 6 Dec 2017 11:32:41 +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=oHjLWKMCvUR7mklAazGw2kJPNecL3jecmYotdEBvyA0=; b=dwcpjR4OXONVpiv+MdLMXKmmcTWf4sYtADydkAtAh0xnKm3jmppuKSXdTFUQIEN00H1TdGFyDGzhHY04YDkmDytOg1JFHMWtkn9ttn8m19UR1zQ0jIRL9frSX/Meqv5ZrZgG+u1qf2R0czSXVDHI8RVkG98v8TWd3ApqaiPFxWs= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.197.108] (91.82.100.59) by VI1PR07MB3437.eurprd07.prod.outlook.com (2603:10a6:802:24::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.2; Wed, 6 Dec 2017 10:32:39 +0000 To: Martin Bjorklund CC: , References: <20171128.103735.1654378548309425095.mbj@tail-f.com> <81f49c62-e1fe-4a90-a93f-c7fd55229100@ericsson.com> <20171206.100112.298803456348365967.mbj@tail-f.com> From: Balazs Lengyel Message-ID: <4aacc669-5470-bef5-a3e7-fd9047c72562@ericsson.com> Date: Wed, 6 Dec 2017 11:32:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171206.100112.298803456348365967.mbj@tail-f.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: DB6PR07CA0132.eurprd07.prod.outlook.com (2603:10a6:6:16::25) To VI1PR07MB3437.eurprd07.prod.outlook.com (2603:10a6:802:24::11) X-MS-Office365-Filtering-Correlation-Id: 50be428c-d686-42ce-efc2-08d53c94ad53 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:VI1PR07MB3437; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3437; 3:P0uhck0NX/x1l0u0wTtOKTsN2CsoQthC+Q8gtKfVanI+dMbMLge+zmhVIyt+7o3XbNUTIYS2pwsJCd1B70XOtwB6IymQpHhGrKvlyfKPUz+WuZsAMRaupz2avUxI7KIbur0IXzl7+VJANvbq3phV4I8kWZvcS7pDRKnVTq6oLAcDbN2yD6iyifXzq5Rk4o89WUAhCHls6IEI9TfkptZMGS+cIbF8uTk6Uj22S3D5V0pmdKXQZ+4OxRvUIFslBAEc; 25:Y8w+BE3Zw0gh97swqLS/N21sx7rIDihMWnerukg7ODSeP/IBdpEW2uqZciqyv9axlMaA8lUsbTfWd/rWM5osWzTFoz9B/wNkOXOH6JxiQxxlnYnZVSqsjZy3iriAtXbz2n6ibseCxCmot8iSXREOTJscrlnSkmQ2A+3pu4M8qmIgKqKyUciL2YoKFOPKKPX7WL5QaSoNMTfSol0pIBDbKe7ZJ1DhNTic8ZXCM2wh4KKb9EnXgd4aDsOmotGhx2qZGJc0/l04/yA666ZkPt3uTlayEL3P9C+68uwngypvpk/m+TGrv5/oc6bTg/sIP5qJU0WV8/XMxQQhbhcJWk3R9Q==; 31:e5ViklQDx7eNeDG154xwB7DZbSQQU2XxQUGfUJmjR9o7ZpItBSg4RxJAnfuMkleQ6+94Hw9YxTrLjTmXaK6Eiyu/BGjgpE30UBPHOh6kuellH0EYyMsVfDNOlgf/gD2KFPdWNZK7NZj9nT6FHNfq1G4z+yMboV6nZj+nxUTe3tn5NaeBU9AmBGOlpLghB6yK40Q/RrszayLsYqgAQmzG28Nr5OvIwtzdmdYq6l14I2Q= X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: VI1PR07MB3437: X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3437; 20:O+p8GFUoVQkrm2/1Vu6cJSgfYLZIjTwsCRiiR+ATiY3/2ruf4nA2oS1+Ll4hHDS7SFvFtGiWL7KDiR6xEv43lD3pAtRJB/UIgOQC8akEepc2pMlVbJQAFa4gt3E57cFxEN8AppLp00QvRjU+s00MJZkt2HJcOrES6vUXD4oBETR3nLV+05oNk0Cl5g7hpgLYdFveUhQrUALgSV5ZeqZXWd88+fdG9HJqgr0b1FXq8T4hswprX7zyC9MTCNCrH9OntoCrxG+e0MT5Vx9ciGXM8onEp2/YErOb5KufdMhvmaMT+LMpzZq9/gUMd7GLnxazOrvUFLAb/PACQRyAy9Ks9eDuKztgt5KSVotBzn6uGfAljyCGkmTu5OB/esrhuXTbzovn+A2j6Z3MYHUbA4KsVpblbp5IKNT1wKoFLtrkVWq6UEXTf8dhVv1SUGQssU8bobkNP0ovtgrIkUY2j+gvH/23nEAENdn1iz8gCuvhcT/y7CKje469Ns+82gQlbGZe; 4:AJrij53+QW+FlluJzXy7taaJQC/ibQUuR56ffjzrYqU0wO8bMYY0pbzcXbWikXLU0uKTD7zDWc+7j04qbQOvCdgjU2K5Jt9mvXIpNqGWjfVw6m6i3/rqGW9RmmBrrRukZBy0ug4G826vGQDBrgP6HRlxJGqxza12S5dqrDrq74kh0ANFbP8vS9SYj10pgL9+ys7VjIe+59mpvFRmM/pyTgJYLYDPoECe4ixbKQQe09Zixn39JW9iNvei1TmZyZhPvlR1LrEhOBjOwlpuHbdAkBmLIo8v2aFK5KI/aewZiIa08G46x/q93BW46Xgj+JgZhfAdQs5OERZrf/wG5yna13KA2LL9SGWEdSS1a96f5EA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3231022)(10201501046)(3002001)(93006095)(93001095)(6041248)(20161123558100)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011); SRVR:VI1PR07MB3437; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:VI1PR07MB3437; X-Forefront-PRVS: 05134F8B4F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(366004)(39860400002)(376002)(346002)(377424004)(51444003)(252514010)(24454002)(189003)(199004)(64126003)(83506002)(230783001)(53546010)(36756003)(49976008)(2870700001)(4326008)(16526018)(478600001)(68736007)(50466002)(6116002)(31686004)(33646002)(6246003)(105586002)(25786009)(53936002)(106356001)(3846002)(8936002)(7736002)(81166006)(47776003)(6666003)(65826007)(81156014)(52146003)(305945005)(52116002)(31696002)(6486002)(316002)(101416001)(2950100002)(65956001)(66066001)(97736004)(23676004)(76176011)(16576012)(58126008)(2486003)(2906002)(67846002)(93886005)(86362001)(5660300001)(65806001)(229853002)(6916009)(8676002)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3437; H:[159.107.197.108]; 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) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3TUIzNDM3OzIzOmZiOUhNcWoyTHZQdnF2VWpyK2ROTldWMVNv?= =?utf-8?B?Y0p6TUZaZDhUMkZJcGZsbkJ0MDVaSCtETU5rSlpxbDNRc0pxU0Rzd3ljM1Fk?= =?utf-8?B?SnhOVGQ2aW44dWhqdUdHSlNhV0FtZEM3NWZBaDQrRGs4N1Z1RmgxTE4zRnVL?= =?utf-8?B?S0d1RkxyRjZKODFhWUE2eGp3Z1lXODhtZ3dPZTg3bWV0NytDU0dNVEo1RzVu?= =?utf-8?B?RktDQUpHVHZyVFI5clJaZVJjNTBySnhXTGNNdUM0NVhRc3FxRWJ1VXc1eHI0?= =?utf-8?B?M1lYNzljTjFGRTZKNVE2U3ZvZDR2eWIyTW5RdDVhcktCNlBJeWI5ZkxPTkpo?= =?utf-8?B?KzFOaWZ1dVBiNmpOamd5WUd4ZmNMU1lVWk5ZbnpJdEFkSFlhdDdZK04vcEJh?= =?utf-8?B?MXYrT3dCRUxVd3NINHl2eFhzMXVvOXZoWHFyTjU5eWZpNHdiZElvYzZUWG9Y?= =?utf-8?B?U2pFdkpCdVIza1hKYm0zcmN3R2lQWlRDSG1hSS92aEFBWFRvaDNGcm12MThv?= =?utf-8?B?WmhKZU9QNENRNUFITG5aeHlWdEplMk02VXpHZlZ4YVBpbHY4Tm92cHNXMVk0?= =?utf-8?B?ZndhdTJ5T1lhUW80ZmRCMmR6ZjVBMFprSWtIK2pOUGxhVXRzS3NGNkFDS2dK?= =?utf-8?B?UytFZmQrcnVFRE9PVDZlQTdiTDBEK0Q5R0p2Z3ZGeGVZakszR0puUStyanRK?= =?utf-8?B?cU5hT2I0eFRPelNDNlovcXF3bmY4ODBJZWxtSVZXSTg2VENyT0ZJbzhnZ2o1?= =?utf-8?B?R3k4VjZnaThZMXkyZVE0N3g2YUUxQnFBSTRCVGpsODNIYzkwTjBIOE8va1V6?= =?utf-8?B?SzB1Q2VWOG14ZERZTkdpZy9CUXVYOERxeFZDNXBMc2dvUzdObDRJbFROSURx?= =?utf-8?B?emFYQkxxcmtMZmJESnI0NXNFTUl0UmFLaGVwVlRoSnpTQWV1aG5zNmZldklh?= =?utf-8?B?MERWTm5TUmhmb1pSMjZIaWd1Q3hkQTlJTW9UeDRXVFozWjJaZGtZUkFhcjFW?= =?utf-8?B?UkJacHBDczE1RTNXb0tPd1dyQ3pzaWhOd1hVenJ6MXQ4ZzAxYktobTVmR0Z3?= =?utf-8?B?VG1YaUEzY2ladUFOLzhyaC9YbjBnMEQ0d2R3b1d1MkpzTmQzNVJ0UDRrdXNo?= =?utf-8?B?UjRjbTlDeTlvN1dYd2VJSmppcWRIdDhSRWdUckdkVlUyS3BnU21OWi8zZXlo?= =?utf-8?B?Kzh2N25Fc2xpVTNCaGh0YVpaT1M0eS8waXJtckhRTzZBUlZtc21xeVZzenNn?= =?utf-8?B?dFNzdnZtZ0NPRUY3ODNPU21jN1RqaG5JRXVpSXV4RFVvUWE3UVNEUCtReFB1?= =?utf-8?B?TVBIbG1vVkdEelc0cTFXWlhZNFBKeXhQdjhrTlZSNElqNWY5RUlSaml4SXBO?= =?utf-8?B?TXJ2MlkvNXE3Nm9QQ0pMcXFjTXc5N282bkNzTndhbkhhck1PbS81STVQZUVE?= =?utf-8?B?VE5PNEtKTlBOMURQQmI5ZUJpMFAvMTNGR3JKYXZjUGNCYm8xYTVqalR2Z2ht?= =?utf-8?B?WE9vV2ZOdmRlZ21ZRGJyUXptTEovVmoxcUhhaEMybXdEZkJIdFczQ0FEYWN1?= =?utf-8?B?bk45Qm4wUTMydnhaUWhYUGJYdnVkc0FpV2xJMWxxeHFndFN2ckNGejc5RTF5?= =?utf-8?B?elYyTS9SdS9QT29IVnYveGtCY09UR2hCbExpZzROOVVnbVNHNkd3L0NUdm9N?= =?utf-8?B?NkNxeDV6V3Jxa2RGZkdBcmFTd3JQMjAwQ0pIUy9oWmViNnJtS3JFSDlvejBQ?= =?utf-8?B?UzYvaEhvQVZkaWxpM0xQQVB2WjBRR3MxZnBjMlRCTTNUNmx1L2FGV2ROVGI3?= =?utf-8?B?eVFuSFJLcVhpbnJHYXBaZlBJc0d6WUR5dUNWNHJURWxUSGVIeGhuZzhQNDd2?= =?utf-8?B?TWNCcHpKUmdPd09SM3liZmQzcm91bGNhaWJHZjlXbjJ1dnVwZ1J4cnRDRmFk?= =?utf-8?B?QkhjbUczc2hJbUdHT1cyK2NMd1BqVStBWlZPRVd5c1ROOU5YZzRYZlhjcEh0?= =?utf-8?B?cGFzSzlUQU9XNE1WbC9ENkU5bkxPZU1hZWJFZz09?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3437; 6:Ajcymi3c73VeWpRNvsNqeiZfwxyCv115kJw8jzR/bS5aV5uSbpwPOFMrQVhab7dWf8ECCh9eHO/jxGWHbOWqBMAbTVYOm+IDDPU66T3xPJZcTlTQytlqMqJ+Pg4e1HIl3cLOang9DXMCvK6zXtAVv+M9PPkB6MPw5hQVqFRklSZSltgxH2XDoo84ycQMEPoYOOQG0ItaiuwRY4VifAvLOIXwjBAIu4wb5GT6hMEbf4i3a6krUvvGX2GcOK8hIDSZlWBO+FQ0txBgd7Lb1bmQluEEDiWRQVtUbG7qkhwIgLzKA/EUMzQR79peOo18Rzg22K47Ki52GA6hG9NirDhGzyy/klHFoUPvmzIoe2Lj4/w=; 5:ILJkvrUnhf+TcBTU5fSAx8EdGQj/v3kQzvg8k+7cenjMj3+gfiXxcWZjrc03jSFH4bHE5xc/WSpW7rVMJkytofPsCWWuXzM1VTjpL8Xtd7MNDziGhV1NLxsT+DPklVfavyNJGQILYPQOjVKL9G9anBxmVv2UcWQOlqaLvmcd2/A=; 24:s0LSUDnD/8214ECncy5hoQK50rU+BPWhQhHPYLXszpM52+lLAPaie8Q9l3h7OTneGS0m9SU5lLd7+jSgDxsxGhOjfj7O0GhKUtuJqRcmZ+k=; 7:hGMqw7ceSWi+VDIzJcKXDYyc6nyYPx/pz8805Zk1KJ0xXd4mymgvRNhXDeHosHy6Zz8mYZko0M5kDCfuBf3Wf0UsBhVfMFRmqLZfBzXQxSCt5ifMfyWxRDJUiaLvaUSR9pICml4oze+19by95G6pF3pxd+Ags8nlwUyvtTionLhj0S1lrAcp305rRu0ewdTo9EaN2dmAH0zbfRTPmsYqA0qlMIqwOIWO/jQp0wxLp5lB54PZpsbS0OLJEgO7+bOP SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Dec 2017 10:32:39.8734 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 50be428c-d686-42ce-efc2-08d53c94ad53 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3437 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHeXbvdXfW4HEqnqaWrBdF5koNWlC+9CEsS4o+GCPToRcVdcq9 UzQIVknG1FzIEKem+YJQCqWmCWU6FZ0hvkUTJ26jOYSRFQphIuR2E/z2O8//dw7nwEMTEgMl pfM1WobVqAtlfv5k492h9JjrU5Gqc4tbSqVjwiRUVle7hUpjn41KIlI6O3cEKe/+dpAplXUL 5C1C5X8phynML2PYswlZ/nnd05NkieFYuWVHrkPLgXpE04DPw7iN0yN/WoLHEQx6pgR8MYVg pv4x5S1IXEuAs37AT49ENML3YbjnFcVbVQLYHZpD3iAQn4SdmlGBl4PwaXAN95JeJrAcXjb1 EF6W4C0Eus0oL/vhODDWzfkcMU6Err0qXy+JT8Hnyh8+Dsb3YLymgeKdALA0uny+CCfBp4E/ Qn6+Ehpb+R0IfAKevG8ieA6BFVerbw7gCLD2W0nv0oCNCBYm3lL8QlHgnN+jeOkm6D8+QrzU iWDENkLwhU4I1pl1krfCYXK2+T9HQ/ua86BDCPZv04gPCmChzyzkORWq3EtCXmojoN/2lOCD MFjdcxIGJDcdus906CbToZtMh25qQ+RrFMwxHFeUGxevYNj8bI4r1ig0jLYP7f+TsYHdmA/o jSfZjDCNZEfF3GSkSkKpy7iKIjMCmpAFifHY/pM4R13xgGGLM9nSQoYzo1CalIWILdfEKgnO VWuZAoYpYdiDVECLpDqkkBZvyyN0y8TKGbpXKRJb0rQbjheKrxZj7TNPVtf3NXd77O+LHWxT 6PHEdBSQwf68UJ6WlRyWkG5dUt4eTb1SrbMlbw97HHPZLbPhd75sXd6Md1xdLXWtGjTzN2zu oqCNI/ZBe7e+J/Ohg4pphkVrRoesMczeIn3eELn+S0ZyeerYaILl1P8A3HgQGCMDAAA= Archived-At: Subject: Re: [Netconf] "notifiable-on-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, 06 Dec 2017 10:32:47 -0000 On 2017-12-06 10:01, Martin Bjorklund wrote: > Balazs Lengyel wrote: >> I very strongly object to excluding the issue. There is a strong and >> immediate need to be able to specify in vendor design time for which >> data nodes will there be on-change notification be generated. >> >> When a vendor release a product they know which nodes will emit >> on-change notifications in design time. System integrators need to >> know this. Providing the same information in run-time as instance data >> is not a good solution either as you would need to get a real node to >> read the data from. > The same argument applies to which YANG modules, features and > deviations a product supports. In SMIv2 we had AGENT-CAPABILITIES > which was an off-line document with this information. The experience > seems to be that it was rarely used by managers. In YANG we provide > this information on-line with the YANG library (and at least our > experience so far is that this *is* used by clients). BALAZS: I agree that yang-library is good. I am not arguing against it. Just it is not enough, because it is only available in run-time, too late. > It would probably be a good idea to combine these two approaches. BALAZS: I agree. Early documentation and on-line documentation combined would be a good solution. IMHO the 2 could use the same format. E.g. - Put all server-capabilities into yang-library (possibly augmenting it where needed) - define an off-line format for YANG Instance data     e.g. the data section of a reply This way you don't even have to define a real new format - declare that off-line instance data from yanglib is the format to define server capabilities > > I think that this would be fairly straight-forward. As a first > approximation, suppose we had a standard file format for a > "server-capabilities" document. It could be something like this: > > > // this identifier must also be available on the device, so that > // a client can match the capability document with the device. > some unique identifier > > // meta-data goes here > ... > ... > ... > > > // the contents of yang-library from this product > // with modules, features, deviations > // ... and possibly on-change info > > > > Now, this won't be useful for all systems, for example if the server > is very dynamic and support dynamic loading of packages etc. BALAZS: I would put server-capabilities in 3 bags: 1) capabilities that change only at upgrade 2) capabilities that change rarely (e.g. due to licensing) 3) capabilities that change frequently (???) IMHO 1) covers 70% of the cases 2) covers 20% 3) is < 10%. Many network nodes only have type 1) or type 1+2) capabilities. So our main focus should be on stable capabilities -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Wed Dec 6 02:52: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 A09D91296CF for ; Wed, 6 Dec 2017 02:52:05 -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 gN8wlUBKgY73 for ; Wed, 6 Dec 2017 02:52:02 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23F84129687 for ; Wed, 6 Dec 2017 02:52:01 -0800 (PST) X-AuditID: c1b4fb2d-139999c0000036aa-8b-5a27cbcf19df Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F7.FD.13994.FCBC72A5; Wed, 6 Dec 2017 11:52:00 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.84) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 6 Dec 2017 11:51:59 +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=sn/KFim/G22N/BzsIMAvC3Ijd8mA8xDhMPkEIID/jJo=; b=HaBry73P6CWLte40JvgevuoJtwKu+aMrjKvRGN1mKQXUqkqJ113DKFaYKW9ssSg4pXDLNmlwlMveio1tkA01eSquU9/Bv2CcHjYJoioPvaTfoiDQvl9oXydg6TFKiTKNOant6uZNuaCYXSWGrUTNoAx8VU9kGDDauPQKFliTeWE= Received: from [159.107.197.108] (91.82.100.59) by AM4PR07MB3428.eurprd07.prod.outlook.com (2603:10a6:205:b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.2; Wed, 6 Dec 2017 10:51:57 +0000 To: "Eric Voit (evoit)" , Henk Birkholz CC: "netconf@ietf.org" 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> From: Balazs Lengyel Message-ID: Date: Wed, 6 Dec 2017 11:51:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.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 X-Originating-IP: [91.82.100.59] X-ClientProxiedBy: VI1PR0502CA0004.eurprd05.prod.outlook.com (2603:10a6:803:1::17) To AM4PR07MB3428.eurprd07.prod.outlook.com (2603:10a6:205:b::13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 8d34d0b7-2520-49fc-b9af-08d53c975f3f X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603286); SRVR:AM4PR07MB3428; X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3428; 3:GNRp/ZJQGn873r+nIUGpzWTaKhhyUHYIZuRGCHXomZd1vtlJpoSAh8tEMzM4NCX7rDYvCLR+H3pbb6goNobDKZxkHSUM7F48jOaGhsdxYJgJgQnsf2u4CtuIKHXF1gac+p4aEEKCWtoOREptrgwk3wmaDOl2/cv2H3XKeubKJDkjyYA4JtD0sVkbII8pQwW2ONDrmQCurdXwRoyJbKU+/qW49R5FmQnGvbqAUQe9t5w7zjbhxzxtb23Av0PqjHXk; 25:NOrjqZG7hEy6pi8Y/LsC1Kprmfy1FMzCfzD/olpggGfVToi2n4k1N0N9Qq2THaJi79FU1h8vPjJOuJlJsGzW9Ako8KfciUeHCuEtyzEXjd644WpAI7rz8/AflAejTv9WQYp88O5hFwP9XaKWXtm3Q962pHmdUqiGACfCDhUPeWiPRcbCOJhWxnZpPeH+j05w1pKpgdIxJ8CnU67MiC5bNtoxjfZD8SjLE/qlM+vWFHPvMf6YtjgMkwhSSGxJZ1j/beYaRPcK0bk3MQfynTztRhQuJhomjHcDrhhfoxQFGW8J3oyAsNqmvCR8BJjgbM0jKhBtN0p21vQOdPCJ7ANYhQ==; 31:A/vUHdPqXzewRM42jDmaodesYkdTqXtaQkOeLUSOVqBnp/nbe/m+CMFfjWzjziOcL8ef1Qrl8nOF74nD0+qj/gtAxo7R0p4id2+hHTgDEqSA3m4KOETFPnRONBLI5RlCT3lQoWboBOnMm0gMQO6ra+nYluB0n9ghtgLF3JazLKn1qTE/UyAtb+lDen5kYAFnI4qkpJ8OtQToEV5hlKhGFgJHhlHbt+XUvS2+UWqPsX0= X-MS-TrafficTypeDiagnostic: AM4PR07MB3428: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3428; 20:XoHnick1RHS2ADdGSN9djvcollPlS1JHZas9Hj63hr7Ns6jlU8fzuVxYjI4IxI4KfqUW1RUqv7MUul8x2HW3+NFbRDV7oXiYtUDuB49/9fL2Wcv/d4Gn6kF15jwqmjBnBgHnjWFWt6WoTb6AU0xz1dJjIlg4ezmPI7JxeLzwBs3+ITNBleeSeG9jaRWoED7ZkF12wMW5ukp2K7qXnAYiyfSa+oPiYyfZ02TXR9udnyoV03aii4+GRC/Blra8bicTR+Ey9nMy/u3f//O2KfW4Ii36f47bcEuGpyf40kGa3uyyZHWdNhOZdUlPtnHcQTXYbcXjbDDxclsWmflKP+vg1TRd+bCTtcidu7+Jzwi9oqdZzS9czT+aOPaizwYuMZWYa/OQN0vmlKIIliF7e9fuLeGWS2lWw41mXPp8yszVJRL9DGlV1dQc1wdlH/1+35OFt4gQtV7AmDI7t2DfauBll4UT9TevdlJt+mc8Io6sP9K09m4amfR3kBxyWmUHK98Q X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863)(278428928389397)(192374486261705)(50582790962513)(95692535739014)(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231022)(93006095)(93001095)(6041248)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM4PR07MB3428; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:AM4PR07MB3428; X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3428; 4:3kp6zvvbbQXe35ieIQMf6LkWthFJe1cokw56RcrV3W2De38FQy449BVP8m1wWBj2zH7C53MRRh/awZ47+fKBS6ineOqlekt+tettx04lECiwvPL40jxu87Xh8HAM1XF3hM/onG6hAiihQh5NwVOTlmz6HcOB6C0NxtEVs5DqJajuKS7XPhCRXSFlJnEnlhDPxaizArkr9VKiHdzB0P5LtZcpaZdkxdrxK1OiIoNRRChzBL0cZdqLpGp6TFLM5YGi9oZzI+SPLTvh/jgeSd8kIDCngN4VTA7QHM4b3/0ZQUs9OGyDVXdFxmt9hhbI+0gZmDjLfh8FySGfvR3xsCN8DWncEtedLPuR81ABLx9vmPyKOvdbQ6w+SXvaxS0hO4IjZxJIPQknOP2hVMSiBZh/4R+KMFEOtu3KMYuXzxGfq87gnKWLZ1u1N5MopLEi130LlLc6mTUdo0dOWfJAU5PJGsELHm4BhXZgSO5NHhsVdNIcqzboQQ3zCi2XOTisBO7qiF6J9REflvgkRzv0TkbLZg== X-Forefront-PRVS: 05134F8B4F X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(346002)(376002)(39860400002)(366004)(377424004)(199004)(189003)(252514010)(53754006)(24454002)(52116002)(101416001)(67846002)(65806001)(31686004)(6666003)(6116002)(229853002)(6306002)(3846002)(83506002)(105586002)(2870700001)(8936002)(50466002)(52146003)(6246003)(106356001)(53936002)(2906002)(66066001)(76176011)(6486002)(33646002)(23676004)(2486003)(58126008)(5660300001)(305945005)(65826007)(110136005)(7736002)(64126003)(53546010)(316002)(16576012)(68736007)(230783001)(4326008)(93886005)(16526018)(478600001)(47776003)(65956001)(49976008)(8676002)(966005)(4001150100001)(81156014)(86362001)(25786009)(81166006)(97736004)(36756003)(31696002)(2950100002)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3428; H:[159.107.197.108]; 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: =?utf-8?B?MTtBTTRQUjA3TUIzNDI4OzIzOmpXNy9OSXdoeTdRT0FyZDN6RlRkZGkvYW0v?= =?utf-8?B?TmVzcEFSa3VXVTA1TjFsMTJMMlJkQ3ZpYW5HYURuMnllWWZBVDA3U2cxOVJZ?= =?utf-8?B?M24zazV0R1JkNXBtdXcxQWoxRFV6c25iYzVDNGZpZzE3NThsMzBGZFFGRndM?= =?utf-8?B?a1JkSjhGekhDWURPcm5hZG14SUNXM1ZHMStoNis3ekJRc2FidVNaazZNR0xY?= =?utf-8?B?MmdoLzlQWXVtRFFVV1crcUJxWkVib09TSm5IRUJxT2k5QnBLdGYwc2dSTVdD?= =?utf-8?B?UEV4NTJhK3pQb2JKamdreHdKZXZSUHI5WGtzcHM3Qm9YUW5TN3B4SWtBQVRR?= =?utf-8?B?LzZKRkNBMGwrTmMzUFVuc0l2Tm44aXJaUW5qL29vNS9oNllhRVlDV2Z5L2RX?= =?utf-8?B?aldGclNlbG9VSElDNUNIdGRDUE83K2pPV3lCbDZrM2ZNSzRUSFAvVVk5MnEz?= =?utf-8?B?TFZ3QmkxeWo3aFdZL1VEYUpENHdGeFVFb3FydjByVDN6MDBIdUI5bU9SQW1z?= =?utf-8?B?dU5jeHJMM2JwVDRkUmdTODRtcGdRZHhDY0VPVTZzR3B5eGF0azhpTUdNWGg2?= =?utf-8?B?WWorU2tkZGtxQzUzanNwVzdEWEpxN2ZuVW1EZlJONmxoVjRrSFhWdngreTZO?= =?utf-8?B?U0E5a1o1dFBJbXpzQjltMUFkdm9STWlqOXBDMXE0Vm1aeFkydStITmhZelVQ?= =?utf-8?B?cVVVYk51UmZOQnFtQU80M0dCdUFZZnFjZERvemZ2NzBIcDcxUGFSMVVwQkVR?= =?utf-8?B?V0Z5UjA3ekEzeHZZYndQc2NMQWxEODBBSXBqcnk0ZThMeVN3UVdCeHpNUHl1?= =?utf-8?B?d3ZTTDNpWGpHOUdNVnUyVW9jRDBkeXNJY2RaczFHTncvbzJCVVFHSjU2dlVq?= =?utf-8?B?L2pKdmdEd01Qc09PdTVvc1czUm55VGFIcEd0YVFzUkVCSlVrTUV0RS9mSU84?= =?utf-8?B?ZGR2Q1pUY3FoNUpXakNMN3Q5d1o0VHRBekFUdDl1ZVJJYTRwT3NjZU9obU5N?= =?utf-8?B?OUJVTllXK09XRlFpMUQvR1MxWmUrRG9tbUN5UzZKd1d5RG1kTkMwZTVuZktr?= =?utf-8?B?YUJiMyszWHV4SzFJREdTZW1MYWpWWmVhdWRYN0pPQUVwM3pJR0JSSGpjL2RG?= =?utf-8?B?eTRUaS9QOWIwMEVLc21pVFJUZE0rb2w5WjVzWUFjOG5aUU1tQ1kvZnc2dVFS?= =?utf-8?B?YTVLL1IyQTRJak1TSTVjY2JRUm50eVpiLzY0Y3hTcllNT0VmclNiTzF3dUlW?= =?utf-8?B?ZnUwK3NxcEhEY2Fmd09aa1RYUWFMNWpQZG55ZUtJNlBHOVB0YnpNR3k2bENx?= =?utf-8?B?eGJlSFpWSzlGQXkrVEJsc2RsMHBXQU1INm1YdG0zbFVIVmZiSXFJcnpyKzNB?= =?utf-8?B?OGlDc01xd3dyUkpOeGEvcnY0cXhXTk8rWG8rYUx3SEhhTFFDektTRHU5ZDJp?= =?utf-8?B?UURzVHIrV09wclVnRnRTY1dyQzVPdXdKbmdPS3RHTFZ2UnJLMGkxTzVyZjVB?= =?utf-8?B?SzU1MWFESTQyYm02ak1SNi81cmU4WG9kd1ZzZVJjMHFyanI0Vkc2dzJtdENM?= =?utf-8?B?MzQ2dTZTTUNqV3k4aXhUSjVDNzhmc2RabVdhS2hjV2UrQVloczY1QWpwbkV0?= =?utf-8?B?RHFRaWxGNkFmTk9CRXVGOWhiZVUvbFZzM2thdHZPK3hXd24yS0R4YUlpRjl4?= =?utf-8?B?QlBGRzdHbVZiZkVYcGZ6ZUxFZk11ZStiaHd2RG5wQU5vTjNCY3NSWkxybEN4?= =?utf-8?B?SVE4L0V0YUxlYTRaZ1RUZmFkWE80MjBRN2VDM1lzWC95MlVpRllPOU96dTV1?= =?utf-8?B?OEZDbC8vNm5udFMyTTlVbm5MM1RGZ3k4aVdZRlh3SVlIOVY1Y0Y1YlFSR0Ji?= =?utf-8?B?YjdQSWlsUTRwR29KQjkyVUw4blVGc0p6VHliWXAybFYrdkwyL2dQdHkxU1Fz?= =?utf-8?B?MTdYU2gzanI5cFU2L2dDRXRxaGZ1V2Y4dlo1T3JmNTVjMFRwRlExUS8yOXJw?= =?utf-8?B?dXNZK09NU3lxS0ZLYmFpWGMzRndZR1lOdkw2cFJxUFZTSFNvT2xSOFRlVjhB?= =?utf-8?B?czV3Y21ZbmlrSEJhWE1vWGQvVVhhWjhEa3N3YXlqNE1PR1ROQW12akpQaGcy?= =?utf-8?B?c2c9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3428; 6:co22IuHUJCqc3o5cGIdXvmz8/VVvaOHG+8M1N82NhTYCgJaC9ABMQp1a8Nc4yDpD7U9DFZ23aVp5eHTj5QZkLEPtEX2LKlSGl8A+ZA3EBV24Uq0KOmm2z/hRnAiI/N3zeKlGCujVvzDL/KxE/ym8cFhVKiDr4XvklZiQPFILUeEIYSwF4cwIua7IHxhlkQn/McSWBZy+8s/5JZ3eF0c5Nil0UCEbUT8BJ6CnZlFlfcJvh+qABkonzDW00EcxNZ9B1IDUj7ZDM+QbLwpP07hnggUyBFDe617OGG/N8NTh4IqSJDKytLUFYvOdan2aO3l//7mJl/xJjqa8fiUsTO/iiXhIwTTkjpsqv7UHNtGvvIA=; 5:mhVFGJEOyG/4zdHCV66lwBDdxUiqrpgQ+NofRhRFFvkTEDSYPho4FL2F+hSlhbs2h0iKY7lyjorPl8y5B6Fc3zJJ8j9KGJM3Be04iEHA7epOtPSrptPHkNhmthVteXcUKXw65++oTEZtxmhct+AdOkPDxUx/V3YIqNkBELOAQWU=; 24:NdChfqOL5mil59OqJNMmYJjCYAtNml4OHR1/uJG1oz5XmhUt0k+5TAW7Q9on4ngh62HhxUP/Nakn+DFccqEIBGHJzsVrRwC1T3BIQme6IZg=; 7:dnJgCSgHHjIubP9W5of1IexoCotT6fra3C7HP9W2lyU5RXcySHPq11MVOiRGGjBV8GD/di7/zdE7oXMjYoXH/6MWCkT0JzndjO/YboThjSJ1R6POuitpPjcdQtcMYk8OFFJnrtZVj8ZDWX46Io7d95i4/l1EIDNUcyhHEsX5nKQE0eZwc+6bGeUJWeBtgVKVL9weAGLC9rhbt1jHIrtvRwRidTYdS8eMPMVTL32uAM1OX7lB/ggKDrMIkJ3bA7hc SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Dec 2017 10:51:57.6189 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8d34d0b7-2520-49fc-b9af-08d53c975f3f X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3428 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUyM2J7iO6F0+pRBhe+MVq8WL2ayaLh319W i6mbbrM6MHtM+b2R1WPJkp9MHh0PbjAGMEdx2aSk5mSWpRbp2yVwZZz6NIG9YFlwxfF1f9kb GBc4dzFycEgImEicWmbRxcjFISRwmFHi6uJNrF2MnEDOcUaJ+VuFQBIsAr3MEgdv72GDqGpj kpjdchasSljAQeLFjQNsILaIQIzE9KfHWEBsZgFNibV/PzJDNFxglrj97QMTSIJNwEhiav95 sCJeAXuJ1Z9OsYPYLAIqEo1Tf4LZokCDDvdMZ4WoEZQ4OfMJWD2ngKvEz98rWCEWWEjMnH+e EcKWl2jeOpsZwhaXuPVkPtguCQEFieubr7OAHCEhMJ1R4lX7eTaI3zQkHl74ywpRJCtx9Owc FgjbV+L36lNQ9hJGibbrkRDNDewSv19ug0poSXRM3wC2mVEgTmLnmoWsEEVbWST2nT7MCFGU LfH7zzeo1fMYJc58fwjlLGCW2LJ6AhOEc4ZFYsG8JqYJjLqzkDw7C8mDs5A8OAvJgwsYWVYx ihanFhfnphsZ66UWZSYXF+fn6eWllmxiBKaUg1t+6+5gXP3a8RCjAAejEg9v8VH1KCHWxLLi ytxDjBIczEoivAIHgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5T3ryRgkJpCeWpGanphakFsFk mTg4pRoY597qW3Q7UMHnYcA+Met24foM8yvsM28qnJlxeKZQ1m4xlaDs/Vpf7TapbPpszuDQ cbXMSVlP/pA4k7dReYHdzs2Z7QvvyXp9LLvyuyTDsOKQ5eTkTu+6romxs6aWuG9fczd64/8X iQfTyxZHrNJyFlBg2/m8z2vdU6V5+aJ9+k9+nb+uMuWeEktxRqKhFnNRcSIAITppcSUDAAA= 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, 06 Dec 2017 10:52:06 -0000 Hello, You could use a longer dampening period for detecting churn and later switch to a very short dampening period with a narrow filter.  Getting the information in two steps  sometimes maybe a problem. regards Balazs On 2017-11-30 23:16, Eric Voit (evoit) wrote: > Hi Henk, > > YANG Push does identify that churn has occurred, but not how much churn has occurred during a dampening period. This allows things like security applications to know things like temporary ACL changes. Or things like network management systems knowing that there are transient outages on an interface. > > At this point, the thinking is that an application always has the option of going to Publisher to get the details of the churn. Perhaps new drafts could also push the quantity of changes which occurred, or a histogram or changes, or some other metric. At this point that topic is unexplored. But there is no reason that such information couldn't be augmented into some header associated with the push-change-update record. > > Eric > >> From: Henk Birkholz, November 30, 2017 4:48 PM >> >> 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 >>> >> _______________________________________________ >> 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 -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Wed Dec 6 07:00: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 4E2A0126DC2 for ; Wed, 6 Dec 2017 07:00:46 -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 UM-3gI2pPo8Z for ; Wed, 6 Dec 2017 07:00:42 -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 4E73A120725 for ; Wed, 6 Dec 2017 07:00:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10353; q=dns/txt; s=iport; t=1512572442; x=1513782042; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4DCuECjSCdseL82+Ea+FzMP7/AXgUCWbSX2rq1++wkU=; b=i1Jz9Rgq9XGI0p9pz+uCswtttvC+ge9WzGayQBvSBFcXVppasjf83KOd GR8VSCNs4EPoU3zRzmrKTOjdLV8CZI6/xWTpNOHDptV9N+/RRoJrycRtK st8ykleOUFXTN7prNqlOK4WdvJlvvhXUC1aDspshoXjfQxJG496stvPkR s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AzBgB9BSha/51dJa1TAQkZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgz1mOTUunRiBfX6WG4IBCiOFGAKFU0MUAQEBAQEBAQEBayi?= =?us-ascii?q?FIgEBAQMBOj8FCwIBCA4HDwEREDIlAgQOAwqKEwgQqz2KUwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFhVyBVoFpgnU2hHYBEgKGDgWSCJB1Aod0jRqCH5FFij6CQ4k?= =?us-ascii?q?lAhEZAYE5ATYigU5vFYJTAQEPhFRFiQmBFQEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,368,1508803200"; d="scan'208";a="41192472" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2017 15:00:41 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vB6F0ed5018040 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Dec 2017 15:00:41 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, 6 Dec 2017 10:00:40 -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, 6 Dec 2017 10:00:40 -0500 From: "Eric Voit (evoit)" To: Martin Bjorklund CC: "netconf@ietf.org" , "balazs.lengyel@ericsson.com" , "andy@yumaworks.com" , "alexander.clemm@huawei.com" Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11 Thread-Index: AQHTaCy/QRPr9GM9Jka7UxKyCaa4a6MpyuqggAmhy4D///elMIABf46AgAB7+cCAAP88gIAACbyA Date: Wed, 6 Dec 2017 15:00:40 +0000 Message-ID: <905820dba0e24c0ca3d1b15849cd4961@XCH-RTP-013.cisco.com> References: <16ea77c9d7944aeea09a0b1971ab02a0@XCH-RTP-013.cisco.com> <20171205.110255.1069937786544957099.mbj@tail-f.com> <422b669242674349975651d2ef7c436e@XCH-RTP-013.cisco.com> <20171206.094009.1934958524737452117.mbj@tail-f.com> In-Reply-To: <20171206.094009.1934958524737452117.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.86.244.103] 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, 06 Dec 2017 15:00:46 -0000 Hi Martin, > From: Martin Bjorklund, December 6, 2017 3:40 AM >=20 > Hi, >=20 >=20 > > > > > > > o 3.9 > > > > A publisher could choose to allow a subscription to an empty > > > > location where there might plausibly be objects someday. (E.g., > > > > maybe where an interface might appear; even if there is no such > > > > interface currently > > > > existing.) > > > > > > I think the spec needs to be clear if servers are required to allow > > > filters to cover non-existing nodes or not (I think it should). > > > Hence, selecting a non-existing node should not be an error. > > > > Agree. The " Receiver Authorization" section now has a clarified > > sentence: > > " A publisher MAY allow subscriptions which select non-existent or > > access-protected data." >=20 > So it seems you *didn't* agree with what I wrote :) >=20 > With the selection filter algorithm you have chosen, I think the server M= UST > allow subscriptions that select non-existing instances. MUST forces a subscription to be accepted (even with other issues). MAY g= ives the publisher the option of accepting a subscription (something it has= the right to do with any subscription). > At time t0 the filter might return a node set with a node. Then at time = t1 > the node set might be empty, this is then reported. Then at time t2 the > node set contains a node again, this is then reported. > Etc. Agree. This is a valid case where a publisher chose allowed a subscription= which might include empty node sets.=20 =20 > > > NOTE: we may want to handle the case that the client asks for a node > > > that can *never* exist (e.g. a node in a non-implemented module or a > > > misspelled node name) differently than the case that an instance > > > doesn't exist. > > > > Agree. Such determination is up to the publisher. > > > > > > Likewise a publisher could choose to reject a subscription because > > > > it is obvious that a subscriber will never have access to the > > > > requested data. (E.g., maybe always disallow subscription to YANG > > > > model which controls the configuration of private keys.) > > > > > > > > Pretending they might have access someday and allowing the > > > > subscription will just waste resources. So I think the error is > > > > useful for such situations. > > > > > > This is fine, but not what the current description says. The text > > > in > > > 3.9 and the YANG module don't match. > > > > on-change-unsupported definition now is: > > "On-change is not supported for any objects which are likely to be > > provided through the selection filter." >=20 > See below. Any is correct. Reasoning is also below. > > > > > > 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 featur= e > > > > > > > "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. > > > > > > > > > > Ok; i.e., the text should explain that it is used if the client > > > > > asks for an obejct that does not support on-change. The > > > > > if-feature case is already handled as described above. > > > > > > > > Have changed the definition to: > > > > "On-change is not supportable for any objects which may be > > > > provided through the selection filter."; > > > > > > s/any/all/ ? > > > > Any. Because this includes any objects which might come into > > existence under a subscribed subtree. >=20 > Logically, "not for all" means that there exists one for which it it fals= e. "not > for any" is a bit unclear... >=20 > Compare: >=20 > "not all integers in the range 1..10 are even" >=20 > with: >=20 > "any integer in the range 1..10 is not even" >=20 >=20 > How about: >=20 > "This value means that on change is not supported for some node that > may be selected by the given filter." A selection filter need not be designed to explicitly remove nodes which ar= e not-notifiable-on-change. These are automatically removed without any kn= owledge of the filter, and need not be considered by the designer of the fi= lter. (I.e., you can on-change subscribe to interfaces, and will never see= any counters.) An on-change subscription should not be allow if it is unlikely there will = be any on-change nodes ever within its domain of selection.=20 =20 > > Tweaked the definition to: > > "On-change is not supported for any objects which are likely to be > > provided through the selection filter." >=20 > "likely to be provided" is a bit confusing. "Likely to be provided" covers the case of nodes which don't exist as the t= ime of subscription, yet appear later. The "Likely to" is better than "Ne= ver will" since it is theoretically possible for a system to add a lightly = protected node deep in a tree. > > > > > > > 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 s= ync 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 > > > > > > > > > > But in this case the error will be "on-change-unsupported", right= ? > > > > > > > > I mean to say "except for" rather that e.g. My bad. > > > > > > > > > > ). Will enhance the > > > > > > definition. > > > > > > > > Current text is now: > > > > "Neither synch on start nor resynchonization are supported for > > > > this subscription. This error will be used for two reasons. First > > > > if an 'establish-subscription' RPC doesn't include > > > > 'no-synch-on-start', yet the publisher can't support sending a > > > > 'push update' for this subscription for reasons other that > > > > 'on-change-unsupported' or 'result-too-big'. > > > > > > What would that reason be? > > > > One example might be the CPU capacity is prohibitively low at that > > immediate time. Or there are too many subscriptions pulling counters > > or routing tables or MAC addresses from a specific line card. Or > > other platform wide issues which shouldn't fall under 'result-too-big' > > because making the result smaller still won't result in the > > subscription being allowed to push the state of current nodes. > > > > > I think that if the idea is that a server may or may not support > > > sync on start, you should make a feature for it and call the leaf > > > "sync-on-start" instead. And OTOH, if the default is sync on start > > > (as it is now), it should be required to support it. >=20 > You didn't reply to this comment. Synch-on-start should be the default, and should be required for a platform= to implement. =20 > > > > However a patch must be able to do more than just describe the > > > > delta from the previous state to the current state. As per > > > target=3D"on-change"/>, it must also be able to identify if > > > > transient changes have occurred on an object during a dampening > > > > period. To support this, it is valid to encode a YANG patch > > > > operation so that its application would result in a no change > > > > between the previous and current state. This indicates that some > > > > churn has occurred on the object. An example of this would be a > patch that does a "create" > > > > operation for a datastore node where the receiver believes one > > > > already exists, or a "merge" operation which replaces a previous > > > > value with the same value. > > > > > > Hmm, I think that this is a very strange way to indicate "churn", it > > > is very implicit. Is it really necessary to be able to indicate > > > this "churn"? > > > It seems > > > quite complex on both the server and client side. > > > If a client needs to know this information, it can just not specify > > > a dampening period. > > > > Churn indication is an absolute *must* for security applications. > > Both the SACM and I2NSF WGs have indicated need. It is also highly > > useful for Network Management applications which simply cannot get a > > continuous stream of interface flaps. This is a highly advantageous > > capability and I have quite a few customer requests for this. >=20 > Ok. (so what do you do if you know that churn has happend, but you have > no idea what the churn was?) You will know the node has churned. You will know the latest change. If = you need to find out more, about the current datastore you can do a get. = If you need to know more about each change, you could check the log. Appli= cations never could get this type of information efficiently before. > Depending on the outcome of the filter issue (full XPath/subtree filter v= s. > node-instance-identifier (BTW, will you crete a separate thread for that > discussion?)),=20 If you means Balazs discussion, then yes. > I will have to come back to this issue. It seems awfully > expensive to implement correctly. For a good view of why this is essential, see slides 29 & 30 of the IETF 96= presentation on subscriptions at: https://datatracker.ietf.org/meeting/96/materials/slides-96-netconf-5/ > /martin From nobody Wed Dec 6 09:04: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 63D8A12871F for ; Wed, 6 Dec 2017 09:04:53 -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 8mCPk1uWZ8wl for ; Wed, 6 Dec 2017 09:04:46 -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 ABF8B1275F4 for ; Wed, 6 Dec 2017 09:04:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4300; q=dns/txt; s=iport; t=1512579886; x=1513789486; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kU+fF86ZPI9JKREBQRRL4kubPkplP8WxORDaYiL8In4=; b=DyXeMHstcmq94z+x6O+kIXIxCdeR/Q7+C7HBctrcNFNmMm4ls2G7/c0h kRkDStN3RFWgsCi3+mMMiqbkGVDFKNssox0SCa1WAcSDyNCVX8M5Qce5I hbNiy4e2q4RMwRzfJtxmPS1rqH4KRXqH55Y0WN0GgvU04ET6aT4g3o9oQ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfAQD7ISha/5JdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM9Zm4nB50XgX2XGYIBChgLhElPAoVUQhUBAQEBAQEBAQFrKIU?= =?us-ascii?q?iAQEBAwEBATg0CwULAgEIGB4QJwslAgQBDQUbigAIEKsfilQBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYNSggqDPymDAoRuARIBCRaDRoIyBZIIkHUClRcMggqKGoc?= =?us-ascii?q?rkxCDFgIRGQGBOQE1I2FtbxU6KgGBfj+EFniHMoEkgRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,368,1508803200"; d="scan'208";a="332239807" 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; 06 Dec 2017 17:04:45 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vB6H4jIQ014648 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Dec 2017 17:04:45 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Dec 2017 12:04:44 -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, 6 Dec 2017 12:04:44 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Balazs Lengyel , Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: [Netconf] "notifiable-on-change" Thread-Index: AQHTbnD+9I2b119a1UiTPWuIbdyqC6M2cf+AgABtkwA= Date: Wed, 6 Dec 2017 17:04:44 +0000 Message-ID: References: <20171128.103735.1654378548309425095.mbj@tail-f.com> <81f49c62-e1fe-4a90-a93f-c7fd55229100@ericsson.com> <20171206.100112.298803456348365967.mbj@tail-f.com> <4aacc669-5470-bef5-a3e7-fd9047c72562@ericsson.com> In-Reply-To: <4aacc669-5470-bef5-a3e7-fd9047c72562@ericsson.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.160.20] Content-Type: text/plain; charset="us-ascii" Content-ID: <39C98053758CE94381CE19E72B8103FB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] "notifiable-on-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, 06 Dec 2017 17:04:53 -0000 I agree with Balazs that we really want this issue to be nailed right form = the start. I would be happy with defining an augmentation to ietf-yang-library to allo= w devices to return the data on what content is notifiable -on-change not t= his specific device at the specific time the data was retrieved. For offline consumption, we should define that an XML document conforming t= o the XML schema defined by ietf-yang-library + augmentations is an appropr= iate format. This XML document would have at its root the element ietf-yang= -library:modules-state. How this XML document is provided is out of scope. = It may be a flat file, it could come from a URL, whatever. Is this and acceptable approach? Cheers, Einar > On 6 Dec 2017, at 10:32, Balazs Lengyel wro= te: >=20 >=20 > On 2017-12-06 10:01, Martin Bjorklund wrote: >> Balazs Lengyel wrote: >>> I very strongly object to excluding the issue. There is a strong and >>> immediate need to be able to specify in vendor design time for which >>> data nodes will there be on-change notification be generated. >>>=20 >>> When a vendor release a product they know which nodes will emit >>> on-change notifications in design time. System integrators need to >>> know this. Providing the same information in run-time as instance data >>> is not a good solution either as you would need to get a real node to >>> read the data from. >> The same argument applies to which YANG modules, features and >> deviations a product supports. In SMIv2 we had AGENT-CAPABILITIES >> which was an off-line document with this information. The experience >> seems to be that it was rarely used by managers. In YANG we provide >> this information on-line with the YANG library (and at least our >> experience so far is that this *is* used by clients). > BALAZS: I agree that yang-library is good. I am not arguing against it. J= ust it is > not enough, because it is only available in run-time, too late. >> It would probably be a good idea to combine these two approaches. > BALAZS: I agree. Early documentation and on-line documentation > combined would be a good solution. > IMHO the 2 could use the same format. E.g. > - Put all server-capabilities into yang-library (possibly augmenting it w= here needed) > - define an off-line format for YANG Instance data > e.g. the data section of a reply This way you don't even have t= o define a real new format > - declare that off-line instance data from yanglib is the format to defin= e server capabilities >>=20 >> I think that this would be fairly straight-forward. As a first >> approximation, suppose we had a standard file format for a >> "server-capabilities" document. It could be something like this: >>=20 >> >> // this identifier must also be available on the device, so that >> // a client can match the capability document with the device. >> some unique identifier >>=20 >> // meta-data goes here >> ... >> ... >> ... >>=20 >> >> // the contents of yang-library from this product >> // with modules, features, deviations >> // ... and possibly on-change info >> >> >>=20 >> Now, this won't be useful for all systems, for example if the server >> is very dynamic and support dynamic loading of packages etc. > BALAZS: I would put server-capabilities in 3 bags: > 1) capabilities that change only at upgrade > 2) capabilities that change rarely (e.g. due to licensing) > 3) capabilities that change frequently (???) > IMHO 1) covers 70% of the cases 2) covers 20% 3) is < 10%. > Many network nodes only have type 1) or type 1+2) capabilities. > So our main focus should be on stable capabilities >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Wed Dec 6 09:14: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 D43F91275FD for ; Wed, 6 Dec 2017 09:14:41 -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 unWAjB6L0Nx2 for ; Wed, 6 Dec 2017 09:14:38 -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 C1FCF1275F4 for ; Wed, 6 Dec 2017 09:14:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=64646; q=dns/txt; s=iport; t=1512580477; x=1513790077; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MRC8fQ1Bmio5FU+1bq3rdxxTxKI14HMtipUXLZVwEeU=; b=VSGHk7+h71q1hCtdsOkRPjOAwHsBFP38G7Q7E4ofOW4EjspXI+OnXxpl KhfVFAKkSTYYsUA9mLeACbJQnBL8JRQ5wPr0ePhW8u6plTE+bsSeLR8Sc o/uzVdzpaEuBR8E+B+yK4cCZGz1lZguYhOzFy06kk804mVTT/AozlSfCH 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6AAD6JCha/4wNJK1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCSnNmbicHg3uKII58gX1+lgeCEgMKGAEKhElPAhqFOj8YAQE?= =?us-ascii?q?BAQEBAQEBayiFIgEBAQMBAQEYCUsLDAQCAQgRBAEBAQ0TAQYDAgICJQsUCQgCB?= =?us-ascii?q?AENBRsEiSBcCBCofoInilQBAQEBAQEBAQEBAQEBAQEBAQEBAQEdg1KCCoM/KYJ?= =?us-ascii?q?MNoR3FBUYH4JfMYIyBYo+iTyPAwKHdI0jghZjkGKKPoJDhg+DFgIRGQGBOQEfO?= =?us-ascii?q?SaBKG8VOioBgX4JNoQWeIclLIEFgRUBAQE?= X-IronPort-AV: E=Sophos; i="5.45,369,1508803200"; d="scan'208,217"; a="41253909" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Dec 2017 17:14:36 +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 vB6HEZ7v009429 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Dec 2017 17:14:35 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Dec 2017 12:14:34 -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, 6 Dec 2017 12:14:34 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Alexander Clemm , Andy Bierman , Martin Bjorklund CC: "netconf@ietf.org" Thread-Topic: [Netconf] yang-push issue: error handling Thread-Index: AQHTaua8q3kE2DL9UEKuApHuiLNzxKMzfGKAgABIbICAAcFtgIAAAhuAgAAD2YCAAALjgIAAHUIAgAA904CAAP89gA== Date: Wed, 6 Dec 2017 17:14:34 +0000 Message-ID: References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD10E9@sjceml521-mbx.china.huawei.com> <20171205.212443.660483858000758249.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1165@sjceml521-mbx.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD12B7@sjceml521-mbx.china.huawei.com> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD12B7@sjceml521-mbx.china.huawei.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.160.20] Content-Type: multipart/alternative; boundary="_000_C4707D28EAE245E8AAC8E05602A2A39Cciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] yang-push issue: error handling 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, 06 Dec 2017 17:14:42 -0000 --_000_C4707D28EAE245E8AAC8E05602A2A39Cciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 dGw7ZHIg4oCUIEkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgY2xvc2UgdGhpcyBhbmQgdXNlIGEgeWFu Zy1kYXRhIGRlY2xhcmF0aW9uIHRvIGRlZmluZSB3aGF0IGdvZXMgaW50byB0aGUg4oCcZXJyb3It aW5mb+KAnS4gTGV04oCZcyBtYWtlIHByb2dyZXNzLg0KDQoNCkhvd2V2ZXIsIEkgYWxzbyBhZ3Jl ZSB3aXRoIEFsZXggdGhhdCB0aGUgc29sdXRpb24gcHJvcG9zZWQgaXMgY2x1bmt5LCBhbmQgSSBk b27igJl0IHRoaW5rIGl0IGFjdHVhbGx5IHByb21vdGVzIHN0YW5kYXJkaXNlZCBlcnJvciBoYW5k bGluZyBhcyB0aGUgY29uZGl0aW9ucyB3ZSBhcmUgZGVhbGluZyB3aXRoIGhlcmUgYXJlIGp1c3Qg bm90IGFzIHNpbXBsZSBhcyDigJxzb3JyeSwgaXQgZGlkbuKAmXQgd29ya+KAnS4gVGhlIFJQQyB3 aWxsIGhhdmUgd29ya2VkIGV4YWN0bHkgYXMgaW50ZW5kZWQsIGFuZCBtYXkgaGF2ZSBwcm92aWRl ZCB5b3Ugd2l0aCBpbmZvcm1hdGlvbiByZWxhdGluZyB0bywgZm9yIGV4YW1wbGUsIGhvdyB0byBj cmVhdGUgYSBzdWJzY3JpcHRpb24gcmVxdWVzdCB0aGF0IHdpbGwgd29yay4gSXQganVzdCB3b27i gJl0IG5lY2Vzc2FyaWx5IGhhdmUgZXN0YWJsaXNoZWQgdGhlIHN1YnNjcmlwdGlvbiBleGFjdGx5 IGFzIHlvdSB3YW50ZWQuIFRoZSBSUEMgaXRzZWxmIGV4ZWN1dGVkIGNvbXBsZXRlbHkgY29ycmVj dGx5LCBhbmQgdGh1cyDigJxycGMtZXJyb3LigJ0gc2VlbXMgbGlrZSBhbiBpbmNvcnJlY3QgcmVz cG9uc2UuIFdoYXQgd2UgYXJlIGRvaW5nIGhlcmUgaXMgc2ltcGx5IG5vdCB0aGUgc2FtZSBhcywg Zm9yIGV4YW1wbGUsIGFuIGVkaXQgY29uZmlnIHRoYXQgZmFpbGVkIGR1ZSB0byBpbnZhbGlkIGRh dGEgYW5kIGxlZnQgdGhlIHN5c3RlbSBjb25maWd1cmF0aW9uIHN0YXRlIHVuY2hhbmdlZC4NCg0K QnV0IGFueXdheSwgbGV04oCZcyBtYWtlIHByb2dyZXNzLiBNYWNoaW5lIHJlYWRhYmxlIGVycm9y LWluZm8gd2l0aCB5YW5nLWRhdGEgaXMgYSBzdGVwIGluIHRoZSByaWdodCBkaXJlY3Rpb24sIGJ1 dCBiZWNhdXNlIG9mIHRoYXQgc3RhbmRhcmRpc2VkIGVycm9yIGhhbmRsaW5nIGp1c3QgaXNu4oCZ dCBwbGF1c2libGUuIElmIHdl4oCZZCByZXNlcnZlZCDigJxycGMtZXJyb3LigJ0gZm9yIHRoaW5n cyB0aGF0IGp1c3QgZGlkbuKAmXQgd29yaywgdGhhdCB3b3VsZCBwcm92aWRlIGNsZWFuZXIgc2Vt YW50aWNzLg0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCg0KT24gNiBEZWMgMjAxNywgYXQgMDI6MDEs IEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb208bWFpbHRvOmFsZXhh bmRlci5jbGVtbUBodWF3ZWkuY29tPj4gd3JvdGU6DQoNCkkgc3RpbGwgZmluZCB0aGlzIGEgYml0 IGNsdW5reSAoYW5kIEkgc3RpbGwgd29uZGVyIGlmIHdlIGNvdWxkIGRlZmluZSDigJxjb3JuZXIg YmVoYXZpb3LigJ0gaW5zdGVhZCBvZiBlcnJvciBjb25kaXRpb25zKSwgYnV0IE9LLCBsZXTigJlz IGdvIHdpdGggdGhlIHByb3Bvc2VkIGFzIG91dGxpbmVkIGJ5IE1hcnRpbi4NCg0KTGV04oCZcyBj bG9zZSB0aGlzOyB3ZSB3aWxsIHVwZGF0ZSB0aGUgUlBDcyBhY2NvcmRpbmdseS4NCg0KVGhhbmtz DQotLS0gQWxleA0KDQpGcm9tOiBBbmR5IEJpZXJtYW4gW21haWx0bzphbmR5QHl1bWF3b3Jrcy5j b21dDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAwNSwgMjAxNyAyOjIwIFBNDQpUbzogQWxleGFu ZGVyIENsZW1tIDxhbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbTxtYWlsdG86YWxleGFuZGVyLmNs ZW1tQGh1YXdlaS5jb20+Pg0KQ2M6IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPG1h aWx0bzptYmpAdGFpbC1mLmNvbT4+OyBuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSB5YW5nLXB1c2ggaXNzdWU6IGVycm9yIGhh bmRsaW5nDQoNCkhpLA0KDQpIZXJlIGlzIHRoZSBwcm9ibGVtIHdpdGggdGhlIFlBTkcgUHVzaCBl cnJvciBoYW5kbGluZy4NClRoZSA8cnBjLWVycm9yPiByZXNwb25zZSBpcyBhIE1VU1QsIG5vdCBh IFNIT1VMRDoNCg0KDQo0LjMuICA8cnBjLWVycm9yPiBFbGVtZW50DQoNCg0KDQogICBUaGUgPHJw Yy1lcnJvcj4gZWxlbWVudCBpcyBzZW50IGluIDxycGMtcmVwbHk+IG1lc3NhZ2VzIGlmIGFuIGVy cm9yDQoNCiAgIG9jY3VycyBkdXJpbmcgdGhlIHByb2Nlc3Npbmcgb2YgYW4gPHJwYz4gcmVxdWVz dC4NCg0KDQoNCiAgIElmIGEgc2VydmVyIGVuY291bnRlcnMgbXVsdGlwbGUgZXJyb3JzIGR1cmlu ZyB0aGUgcHJvY2Vzc2luZyBvZiBhbg0KDQogICA8cnBjPiByZXF1ZXN0LCB0aGUgPHJwYy1yZXBs eT4gTUFZIGNvbnRhaW4gbXVsdGlwbGUgPHJwYy1lcnJvcj4NCg0KICAgZWxlbWVudHMuICBIb3dl dmVyLCBhIHNlcnZlciBpcyBub3QgcmVxdWlyZWQgdG8gZGV0ZWN0IG9yIHJlcG9ydCBtb3JlDQoN CiAgIHRoYW4gb25lIDxycGMtZXJyb3I+IGVsZW1lbnQsIGlmIGEgcmVxdWVzdCBjb250YWlucyBt dWx0aXBsZSBlcnJvcnMuDQoNCiAgIEEgc2VydmVyIGlzIG5vdCByZXF1aXJlZCB0byBjaGVjayBm b3IgcGFydGljdWxhciBlcnJvciBjb25kaXRpb25zIGluDQoNCiAgIGEgc3BlY2lmaWMgc2VxdWVu Y2UuICBBIHNlcnZlciBNVVNUIHJldHVybiBhbiA8cnBjLWVycm9yPiBlbGVtZW50IGlmDQoNCiAg IGFueSBlcnJvciBjb25kaXRpb25zIG9jY3VyIGR1cmluZyBwcm9jZXNzaW5nLg0KDQoNCg0KDQoN CkFuZHkNCg0KDQoNCg0KT24gVHVlLCBEZWMgNSwgMjAxNyBhdCAxMjozNSBQTSwgQWxleGFuZGVy IENsZW1tIDxhbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbTxtYWlsdG86YWxleGFuZGVyLmNsZW1t QGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIE1hcnRpbiwNCg0KU3VyZSwgdGhlIGV2ZW50dWFsIHNv bHV0aW9uIG1heSBtYWtlIHVzZSBvZiBycGMtZXJyb3IgYWdhaW4uICBCdXQgdW50aWwgd2UgZ2V0 IHRoZXJlLCB0aGUgY3VycmVudGx5IHByb3Bvc2VkIHNvbHV0aW9uIHNlZW1zIHRvIG1ha2Ugc2Vu c2UgdG8gbWUuICBJIGRvbid0IHRoaW5rIHdlIGhhdmUgYW4gaXNzdWUgdG9kYXkgd2l0aCBsb3Rz IG9mIFJQQ3MgZWFjaCBkZWZpbmluZyB0aGVpciBvd24gd2F5IG9mIGRlYWxpbmcgd2l0aCBjb3Ju ZXIgY29uZGl0aW9ucyAtIGRlZmluaXRpb24gb2YgUlBDcyBpcyBzb21ldGhpbmcgdGhhdCBoYXMg c28gZmFyIG9ubHkgcmFyZWx5IGJlZW4gZXhlcmNpc2VkIHdpdGggWUFORyBtb2RlbHMuICBPbmNl IHRoaXMgYmVjb21lcyBtb3JlIGNvbW1vbiwgSSBhbSBzdXJlIHdlIHdpbGwgZmluZCBhIG1vcmUg Z2VuZXJhbCBzb2x1dGlvbiwgYnV0IEkgZG9uJ3QgdGhpbmsgd2UgYXJlIGF0IHRoYXQgcG9pbnQu DQoNCi0tLSBBbGV4DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFy dGluIEJqb3JrbHVuZCBbbWFpbHRvOm1iakB0YWlsLWYuY29tPG1haWx0bzptYmpAdGFpbC1mLmNv bT5dDQo+IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDA1LCAyMDE3IDEyOjI1IFBNDQo+IFRvOiBh bmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4NCj4gQ2M6IEFsZXhh bmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb208bWFpbHRvOmFsZXhhbmRlci5j bGVtbUBodWF3ZWkuY29tPj47IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5v cmc+DQo+IFN1YmplY3Q6IFJlOiBbTmV0Y29uZl0geWFuZy1wdXNoIGlzc3VlOiBlcnJvciBoYW5k bGluZw0KPg0KPiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5 dW1hd29ya3MuY29tPj4gd3JvdGU6DQo+ID4gSGksDQo+ID4NCj4gPiBUaGUgcHJvdG9jb2wgZGVm aW5lcyBob3cgZXJyb3IgaGFuZGxpbmcgaXMgZG9uZSwgbm90IHRoZSBpbmRpdmlkdWFsDQo+ID4g b3BlcmF0aW9ucy4NCj4gPiBJZiB0aGUgcmVxdWVzdCBmYWlscywgdGhlbiBjbGllbnRzIGV4cGVj dCBhbiA8cnBjLWVycm9yPiBhbmQgc2VydmVycw0KPiA+IGFyZSBkZXNpZ25lZCB0byBzZW5kIGFu IDxycGMtZXJyb3I+IHdoZW4gYSBjbGllbnQgcmVxdWVzdCBmYWlscy4NCj4NCj4gQWdyZWVkLCBh bmQgZm9yIFJFU1RDT05GLCB0aGUgSFRUUCBlcnJvciBjb2RlcyBhcmUgdXNlZC4gIEFuIEhUVFAg cmVxdWVzdA0KPiB0aGF0IGZhaWxzIGRvZXMgbm90IHJldHVybiAyMDAgb2sgd2l0aCBhIGJvZHkg dGhhdCBleHBsYWlucyB0aGF0IGl0IGFjdHVhbGx5IHdhcw0KPiBhbiBlcnJvci4NCj4NCj4gPiBJ TU8sIGEgc2VwYXJhdGUgZXJyb3IgaGFuZGxpbmcgcHJvY2VkdXJlIGZvciBlYWNoIFJQQyBpcyBt b3JlIGNsdW5reQ0KPiA+IHRoYW4gZXJyb3ItaW5mby4NCj4NCj4gKzENCj4NCj4gU29tZSBhZGRp dGlvbmFsIGNvbW1lbnRzIGlubGluZS4NCj4NCj4NCj4gPiA+IFdoaWxlIHBvc3NpYmxlLCB0aGUg c29sdXRpb24gb2YgaGF2aW5nIHRvIHJldHVybiBycGMtZXJyb3IgZXRjIGRvZXMNCj4gPiA+IHN0 cmlrZSBtZSBhcyBzb21ld2hhdCBjbHVua3kuICBXaGlsZSBpdCBpcyBwb3NzaWJsZSB0byBhZGQg YW4NCj4gPiA+IGVycm9yLWFwcC10YWcsIGFuZCBuZWdvdGlhdGlvbiBzdHVmZiBhcyBlcnJvci1p bmZvIChhbmQgSSBhcHByZWNpYXRlDQo+ID4gPiB0aGUgc3VnZ2VzdGlvbiksIHRoYXQgc29sdXRp b24gd291bGQgbmVlZCB0byBiZSBkZXNjcmliZWQgdXNpbmcgYQ0KPiA+ID4gbG90IG9mIHByb3Nl IGluIGRlc2NyaXB0aW9uIHN0YXRlbWVudHMgYSBsYSBTTUl2MiAocHJlc3VtYWJseSBhcw0KPiA+ ID4gcGFydCBvZiB0aGUgUlBDIGRlc2NyaXB0aW9uLCBub3QgYXMgcGFydCBvZiBlLmcuIHRoZSBp ZGVudGl0aWVzLA0KPiA+ID4gd2hpY2ggbWlnaHQgYmUgdXNlZCBpbiBhIG51bWJlciBvZiBwbGFj ZXMsIG5vdCBqdXN0IHRoZSBlcnJvci1hcHAtdGFnKS4NCj4NCj4gSWYgYm90aCB0aGUgZXJyb3Ig Y29kZSBhbmQgaGludCBpcyBkZWZpbmVkIGluIGEgeWFuZy1kYXRhIChpLmUuLCBub3QgdXNpbmcg dGhlDQo+IGVycm9yLWFwcC10YWcpLCB5b3Ugd291bGQgZG86DQo+DQo+ICAgeXg6eWFuZy1kYXRh IHN1YnNjcmlwdGlvbi1lcnJvciB7DQo+ICAgICBjb250YWluZXIgc3Vic2NyaXB0aW9uLWVycm9y IHsNCj4gICAgICAgbGVhZiBlcnJvci1jb2RlIHsNCj4gICAgICAgICB0eXBlIGlkZW50aXR5IHsN Cj4gICAgICAgICAgIGJhc2UgZXJyb3I7DQo+ICAgICAgICAgfQ0KPiAgICAgICB9DQo+ICAgICAg IGNvbnRhaW5lciBoaW50cyB7IC4uLiB9DQo+ICAgICB9DQo+ICAgfQ0KPg0KPiBUaGVuIHlvdSBh cmUgcmlnaHQsIHlvdSBoYXZlIHRvIGRlc2NyaWJlIGluIHByb3NlIHRoYXQgdGhpcyB5YW5nLWRh dGENCj4gc3RydWN0dXJlIGNhbiBiZSBzZW50IGFzIGVycm9yLWluZm8uDQo+DQo+DQo+ID4gPiBJ IGFtIG5vdCBzdXJlIHdoeSB0aGF0IHdvdWxkIG1ha2UgYW4gUlBDIGFueSBlYXNpZXIgdG8gaW1w bGVtZW50Lg0KPiA+ID4gVGhlIHNhbWUgY2hlY2tzIHN0aWxsIGhhdmUgdG8gYmUgbWFkZS4NCj4N Cj4gQWdyZWVkLg0KPg0KPiA+ID4gV2h5IHdvdWxkIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBub3Qg YWNjZXB0YWJsZT8gICBJZGVhbGx5IFlBTkcgd291bGQNCj4gPiA+IHByb3ZpZGUgYmV0dGVyIHN1 cHBvcnQgdG8gZm9ybWFsbHkgZGVmaW5lIGFwcGxpY2F0aW9uL1JQQy1zcGVjaWZpYw0KPiA+ID4g cmV0dXJuIGNvZGVzIGFuZCBjb3JuZXIgY29uZGl0aW9ucyBldGMuDQo+DQo+IEFsc28gYWdyZWVk LiAgQnV0IG9uY2Ugd2UgaGF2ZSB0aGF0LCBzdWNoIGEgc29sdXRpb24gd291bGQgbWFrZSB1c2Ug b2YgdGhlDQo+IHJwYy1lcnJvciB3ZSBoYXZlIChmb3IgYm90aCBORVRDT05GIGFuZCBSRVNUQ09O RikuDQo+DQo+DQo+IC9tYXJ0aW4NCj4NCj4NCj4gPiA+IFNob3J0IG9mIHRoYXQsIHRoZSBwcm9w b3NlZCBzb2x1dGlvbiBvZiBhZGRpbmcgUlBDIG91dHB1dCBwYXJhbWV0ZXJzDQo+ID4gPiB0aGF0 IGFyZSB1c2VkIGZvciB0aGUgcHVycG9zZSBvZiBpbmRpY2F0aW5nIHdoYXQgaXMgZ29pbmcgb24g YXQgdGhlDQo+ID4gPiBhcHBsaWNhdGlvbiBsZXZlbCBzaW1wbHkgbWFrZXMgdGhlbSBwYXJ0IG9m IHRoZSBzZW1hbnRpY3Mgb2YgdGhlDQo+ID4gPiBzcGVjaWZpYyBSUEMgaXRzZWxmLiAgSXQgaXMg bm90IE5ldGNvbmbigJlzIHJvbGUgdG8gZGVmaW5lIHdoYXQgYW4gUlBDDQo+ID4gPiBjYW4gb3Ig Y2Fubm90IGRvLCBqdXN0IGxpa2UgaXQgY2Fubm90IGRlZmluZSB3aGF0IGEgcGFydGljdWxhciBs ZWFmDQo+ID4gPiBtYXkgb3IgbWF5IG5vdCByZXByZXNlbnQuICBUaGF0IGlzIHBhcnQgb2YgdGhl IFJQQyBkZWZpbml0aW9uLg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gQmFzaWNhbGx5LCB3 aGF0IHdlIGFyZSBkaXNjdXNzaW5nIGhlcmUgaXMgYmVoYXZpb3Igb2Ygc3Vic2NyaXB0aW9uDQo+ ID4gPiBjb25maWd1cmF0aW9uIHVuZGVyIGNvcm5lciBjb25kaXRpb25zLiAgVGhlIGZhY3QgdGhh dCBubw0KPiA+ID4gc3Vic2NyaXB0aW9uIGlzIGNyZWF0ZWQgYmVjYXVzZSBpdCB3b3VsZCByZXN1 bHQgaW4gYW4gdW5hY2NlcHRhYmxlDQo+ID4gPiB2b2x1bWUgb2YgdXBkYXRlcyBmb3IgYSBzcGVj aWZpYyBpbXBsZW1lbnRhdGlvbiBpcyBkaWZmZXJlbnQgZnJvbSBhbg0KPiA+ID4gZXJyb3IgY29u ZGl0aW9uIHN1Y2ggYXMgYSBtYWxmb3JtZWQgbWVzc2FnZSB0aGF0IGlzIG1pc3NpbmcgYQ0KPiA+ ID4gcmVxdWlyZWQgbWVzc2FnZS1pZCwgb3Igd2hlcmUgYSB2YWx1ZSB2aW9sYXRlcyBhIGNvbnN0 cmFpbnQNCj4gPiA+IHNwZWNpZmllZCBpbiBhIE1VU1QtY29uZGl0aW9uLiAgSW4gb3VyIGNhc2Us IHdoYXQgaXMgYmVpbmcgZGVzY3JpYmVkIGFyZQ0KPiBzcGVjaWZpYyBjb25kaXRpb25zIGF0IHRo ZSBhcHBsaWNhdGlvbiBsYXllciwgYWJvdmUgdGhlDQo+ID4gPiBOZXRjb25mL1Jlc3Rjb25mIGdl bmVyaWMgdmFsaWRhdGlvbiBpbmZyYXN0cnVjdHVyZS4gICBUaGUgb3BlcmF0aW9uIGRvZXMNCj4g PiA+IG5vdCDigJx3b3Jr4oCdIGluIHRoZSBzZW5zZSB0aGF0IGl0IGRvZXMgbm90IHJlc3VsdCBp biBhbiBhY3RpdmUNCj4gPiA+IHN1YnNjcmlwdGlvbiwgYnV0IGl0IGRvZXMgd29yayBpbiB0aGUg c2Vuc2UgdGhhdCB0aGUgYmVoYXZpb3IgaXMNCj4gPiA+IHZlcnkgd2VsbCBkZWZpbmVkIGluIHRl cm1zIG9mIHRoZSBlZmZlY3QgdGhhdCB0aGUgUlBDIGhhcyAoaS5lLiB0aGUNCj4gPiA+IGVmZmVj dCBpcyB0aGF0IGl0IHJlc3VsdCBpbiBjcmVhdGlvbiBvZiBhIHN1YnNjcmlwdGlvbiwgaWYgY2Vy dGFpbg0KPiA+ID4gY29uZGl0aW9ucyBhcmUgbWV0LCBhbmQgaXQgZG9lcyBub3QgcmVzdWx0IGlu IGNyZWF0aW9uIG9mIGENCj4gPiA+IHN1YnNjcmlwdGlvbiBpbiBjYXNlIGNlcnRhaW4gY29uZGl0 aW9ucyBhcmUgbm90IG1ldCkuICBXaHkgc2hvdWxkDQo+ID4gPiBOZXRjb25mIHJlc3RyaWN0IHdo YXQgYW4gUlBDIGNhbiBvciBjYW5ub3QgZG8/ICBUaGlzIGlzIGFsbCBhcHBsaWNhdGlvbi0NCj4g c3BlY2lmaWMuDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiAtLS0gQWxleA0KPiA+ID4NCj4g PiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiAqRnJvbToqIE5ldGNvbmYgW21haWx0bzpu ZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz5d ICpPbiBCZWhhbGYgT2YNCj4gPiA+ICpBbmR5IEJpZXJtYW4NCj4gPiA+ICpTZW50OiogTW9uZGF5 LCBEZWNlbWJlciAwNCwgMjAxNyA5OjE1IEFNDQo+ID4gPiAqVG86KiBNYXJ0aW4gQmpvcmtsdW5k IDxtYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+Pg0KPiA+ID4gKkNjOiogTmV0 Y29uZiA8bmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4+DQo+ID4gPiAq U3ViamVjdDoqIFJlOiBbTmV0Y29uZl0geWFuZy1wdXNoIGlzc3VlOiBlcnJvciBoYW5kbGluZw0K PiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IE9u IE1vbiwgRGVjIDQsIDIwMTcgYXQgNDo1NSBBTSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwt Zi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj4NCj4gd3JvdGU6DQo+ID4gPg0KPiA+ID4gQW5k eSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+ IHdyb3RlOg0KPiA+ID4gPiBIaSwNCj4gPiA+ID4NCj4gPiA+ID4gSU1PIHRoZSBzcGVjaWFsIGVy cm9yIGhhbmRsaW5nIGluIFlBTkcgUHVzaCBpcyBub3QgYWNjZXB0YWJsZQ0KPiA+ID4gPiBiZWNh dXNlIGl0IHZpb2xhdGVzIE5FVENPTkYgYW5kIFJFU1RDT05GIGVycm9yIGhhbmRsaW5nIHByb2Nl ZHVyZXMuDQo+ID4gPiA+IE5FVENPTkYgc2F5cyBpZiB0aGUgb3BlcmF0aW9uIGRvZXMgbm90IHdv cmsgZm9yIGFueSByZWFzb24gYW4NCj4gPiA+ID4gPHJwYy1lcnJvcj4gZWxlbWVudCBTSE9VTEQg YmUgcmV0dXJuZWQuDQo+ID4gPg0KPiA+ID4gSSBmdWxseSBhZ3JlZSwgYW5kIEkgaGF2ZSBwb2lu dGVkIHRoaXMgb3V0IHNldmVyYWwgdGltZXMgaW4gbXkNCj4gPiA+IHJldmlld3MuICBUaGUgcHJv YmxlbSBpcyBhY3R1YWxseSBpbiBzdWJzY3JpYmVkIG5vdGlmaWNhdGlvbnMsIGFuZCBJDQo+ID4g PiB0aGluayBFcmljIGlzIHRyYWNraW5nIHRoYXQgaXNzdWUuDQo+ID4gPg0KPiA+ID4gVHJ5aW5n IHRvIGJlIGNvbnN0cnVjdGl2ZSwgSSB0aGluayB0aGF0IHRoZSBleGlzdGluZyBtZWNoYW5pc21z IGluDQo+ID4gPiBZQU5HIGNhbiBiZSB1c2VkIHRvIGFjaGlldmUgdGhlIHNhbWUgZnVuY3Rpb25h bGl0eSB0aGF0IHRoZXNlIGRyYWZ0cw0KPiA+ID4gdHJ5IHRvIGFjaGlldmUuICBTcGVjaWZpY2Fs bHk6DQo+ID4gPg0KPiA+ID4gICAxLiBVc2UgaWRlbnRpdGllcyBqdXN0IGxpa2UgdGhlIG9uZXMg eW91IGhhdmUNCj4gPiA+ICAgICAgKCJ1bnN1cHBvcnRhYmxlLXZvbHVtZSIsICJmaWx0ZXItdW5h dmFpbGFibGUiIGV0YyksIGJ1dCBhZGQgdGV4dA0KPiA+ID4gICAgICB0aGF0IGV4cGxhaW5zIHRo YXQgdGhlc2UgaWRlbnRpdGllcyBhcmUgc2VudCBhcyAiZXJyb3ItYXBwLXRhZyINCj4gPiA+ICAg ICAgaW4gInJwYy1lcnJvciIsIGVuY29kZWQgdG8gYSBzdHJpbmcgYXMgPG1vZHVsZT46PGlkZW50 aXR5Pi4gIFRoaXMNCj4gPiA+ICAgICAgd29ya3MgZm9yIGJvdGggTkVUQ09ORiBhbmQgUkVTVENP TkYuDQo+ID4gPg0KPiA+ID4gICAyLiBGb3IgdGhlICJoaW50cyIgZXh0cmEgaW5mbyB0aGF0IHlv dSByZXR1cm4sIGRlZmluZSBhICJ5YW5nLWRhdGEiDQo+ID4gPiAgICAgIHN0cnVjdHVyZSB3aXRo IHRoZSBoaW50cywgYW5kIGV4cGxhaW4gaW4gdGV4dCB0aGF0IHRoaXMgc3RydWN0dXJlDQo+ID4g PiAgICAgIGlzIHJldHVybmVkIGluICJlcnJvci1pbmZvIi4gIFRoaXMgd29ya3MgZm9yIGJvdGgg TkVUQ09ORiBhbmQNCj4gPiA+ICAgICAgUkVTVENPTkYuDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ ID4gPg0KPiA+ID4NCj4gPiA+ICsxDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBJZiB0aGUg ZXJyb3IgaGFuZGxpbmcgd2FzIGRvbmUgY29ycmVjdGx5IHRoZW4gdGhlIHNhbWUgcHJvY2VkdXJl cw0KPiA+ID4gY291bGQgYmUNCj4gPiA+DQo+ID4gPiBhcHBsaWVkIHRvIDxlZGl0LWNvbmZpZz4g ZmFpbHVyZXMgZm9yIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucy4NCj4gPiA+DQo+ID4gPg0KPiA+ ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IEFzIGFuIGFsdGVybmF0aXZlIHRvIDEsIHlv dSBjYW4gcHV0IHRoZSBlcnJvciBpZGVudGl0aXlyZWYgaW4gdGhlDQo+ID4gPiAieWFuZy1kYXRh IiBzdHJ1Y3R1cmUsIGFuZCBzZW5kIGJvdGggdGhlIGlkZW50aXRpeXJlZiBhbmQgaGludHMgaW4N Cj4gPiA+ICJlcnJvci1pbmZvIi4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gL21hcnRpbg0KPiA+ID4N Cj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBBbmR5DQo+ID4gPg0KPiA+ID4NCj4g PiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiA+IFRoZSA8ZXN0YWJsaXNoLXN1YnNjcmlw dGlvbj4gcmV0dXJucyBkYXRhIGV2ZW4gb24gZXJyb3IuDQo+ID4gPiA+IEluc3RlYWQgb2YgdGhl IGNvbW1vbiBlcnJvci10YWcsIGVycm9yLWluZm8sIGFuZCBvdGhlciBmaWVsZHMsDQo+ID4gPiA+ IHRoZXJlIGlzIGEgc3Vic2NyaXB0aW9uLXJlc3VsdCBsZWFmLg0KPiA+ID4gPg0KPiA+ID4gPiBJ ZiBhbnkgY2xpZW50IChvciBldmVuIHNlcnZlcikgZnVuY3Rpb25hbGl0eSB1c2VzIHRoZSBORVRD T05GIGFuZA0KPiA+ID4gPiBSRVNUQ09ORiBzdGFuZGFyZCBlcnJvciBoYW5kbGluZywgdGhlbiBz dWJzY3JpcHRpb24tcmVzdWx0IHdpbGwNCj4gPiA+ID4gbm90IGJlIHNlbnQgb3IgZXhwZWN0ZWQg YXMgYW4gZXJyb3IgcmVzcG9uc2UuIERlcGVuZGluZyBvbiB0aGUNCj4gPiA+ID4gc2VydmVyIGlt cGxlbWVudGF0aW9uLCB0aGUgY29kZSB0aGF0IGtub3dzIGFib3V0DQo+ID4gPiA+IGVzdGFibGlz aC1zdWJzY3JpcHRpb24gbWF5IG5vdCBnZXQgY2FsbGVkIGJlY2F1c2UgY29tbW9uIGVycm9yDQo+ ID4gPiA+IGhhbmRsaW5nIGNvZGUgaGFzIGFscmVhZHkgZGV0ZXJtaW5lZCB0aGVyZSBpcyBhbiA8 cnBjLWVycm9yPiB0bw0KPiA+ID4gPiBzZW5kIGluc3RlYWQgb2YgYSBkYXRhIHJlc3BvbnNlLg0K PiA+ID4gPg0KPiA+ID4gPiBFeHBlY3QgdGhhdCBzb21lIHNlcnZlcnMgYXJlIG5ldmVyIGdvaW5n IHRvIHNlbmQgZGF0YSBvbiBhbg0KPiA+ID4gPiBvcGVyYXRpb24gZmFpbHVyZSwgYW5kIHdpbGwg b25seSBzZW5kIDxycGMtZXJyb3I+IGluc3RlYWQuDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ ID5Gcm9tIHNlYy4gMy44Og0KPiA+ID4gPg0KPiA+ID4gPiAgICBGb3IgaW5zdGFuY2UsIGZvciB0 aGUgZm9sbG93aW5nIHJlcXVlc3Q6DQo+ID4gPiA+DQo+ID4gPiA+IDxuZXRjb25mOnJwYyBtZXNz YWdlLWlkPSIxMDEiDQo+ID4gPiA+ICAgIHhtbG5zOm5ldGNvbmY9InVybjppZXRmOnBhcmFtczp4 bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQo+ID4gPiA+ICAgIDxlc3RhYmxpc2gtc3Vic2NyaXB0 aW9uDQo+ID4gPiA+ICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmll dGYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIg0KPiA+ID4gPiAgICAgICAgeG1sbnM6eXA9InVy bjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLXlhbmctcHVzaCI+DQo+ID4gPiA+ICAgICAg IDx5cDpkYXRhc3RvcmU+DQo+ID4gPiA+ICAgICAgICAgPHlwOnNvdXJjZSB4bWxucz0idXJuOmll dGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtZGF0YXN0b3JlcyI+DQo+ID4gPiA+ICAgICAgICAg ICBvcGVyYXRpb25hbA0KPiA+ID4gPiAgICAgICAgIDwveXA6c291cmNlPg0KPiA+ID4gPiAgICAg ICAgIDx5cDpzdWJ0cmVlLWZpbHRlciBuZXRjb25mOnR5cGU9InhwYXRoIg0KPiA+ID4gPiAgICAg ICAgICAgICB4bWxuczpleD0iaHR0cDovL2V4YW1wbGUuY29tL3NhbXBsZS1kYXRhLzEuMCINCj4g PiA+ID4gICAgICAgICAgICAgc2VsZWN0PSIvZXg6Zm9vIi8+DQo+ID4gPiA+ICAgICAgIDwveXA6 ZGF0YXN0b3JlPg0KPiA+ID4gPiAgICAgICA8eXA6cGVyaW9kPjUwMDwveXA6cGVyaW9kPg0KPiA+ ID4gPiAgICA8L2VzdGFibGlzaC1zdWJzY3JpcHRpb24+DQo+ID4gPiA+IDwvbmV0Y29uZjpycGM+ DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAgICAgICAgICAgRmlndXJlIDM6IEVzdGFibGlzaC1T dWJzY3JpcHRpb24gZXhhbXBsZQ0KPiA+ID4gPg0KPiA+ID4gPiAgICB0aGUgcHVibGlzaGVyIG1p Z2h0IHJldHVybjoNCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gPHJwYy1yZXBseSBtZXNzYWdl LWlkPSIxMDEiDQo+ID4gPiA+ICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0 Y29uZjpiYXNlOjEuMCI+DQo+ID4gPiA+ICAgIDxzdWJzY3JpcHRpb24tcmVzdWx0DQo+ID4gPiA+ ICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtc3Vic2NyaWJl ZC1ub3RpZmljYXRpb25zIg0KPiA+ID4gPiAgICAgICAgeG1sbnM6eXA9InVybjppZXRmOnBhcmFt czp4bWw6bnM6eWFuZzppZXRmLXlhbmctcHVzaCI+DQo+ID4gPiA+ICAgICAgeXA6cGVyaW9kLXVu c3VwcG9ydGVkDQo+ID4gPiA+ICAgIDwvc3Vic2NyaXB0aW9uLXJlc3VsdD4NCj4gPiA+ID4gICAg PHBlcmlvZC1oaW50IHhtbG5zOiJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi15YW5n LXB1c2giPg0KPiA+ID4gPiAgICAgICAyMDAwDQo+ID4gPiA+ICAgIDwvcGVyaW9kLWhpbnQ+DQo+ ID4gPiA+IDwvcnBjLXJlcGx5Pg0KPiA+ID4gPg0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAg ICBGaWd1cmUgNDogRXJyb3IgcmVzcG9uc2UgZXhhbXBsZQ0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ ID4gPg0KPiA+ID4gPiBCVFcsIGFsbCB0aGUgZmlsdGVyIGV4YW1wbGVzIHNlZW0gdG8gYmUgd3Jv bmcsIGluY2x1ZGluZyB0aGUgb25lDQo+ID4gPiA+IGFib3ZlDQo+ID4gPiA+DQo+ID4gPiA+DQo+ ID4gPiA+IE9MRDoNCj4gPiA+ID4NCj4gPiA+ID4gICAgICAgICA8eXA6c3VidHJlZS1maWx0ZXIg bmV0Y29uZjp0eXBlPSJ4cGF0aCINCj4gPiA+ID4gICAgICAgICAgICAgeG1sbnM6ZXg9Imh0dHA6 Ly9leGFtcGxlLmNvbS9zYW1wbGUtZGF0YS8xLjAiDQo+ID4gPiA+ICAgICAgICAgICAgIHNlbGVj dD0iL2V4OmZvbyIvPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBORVc6DQo+ID4gPiA+DQo+ ID4gPiA+DQo+ID4gPiA+ICAgICAgICAgPHlwOnN1YnRyZWUtZmlsdGVyPg0KPiA+ID4gPiAgICAg ICAgICAgIDxleDpmb28geG1sbnM6ZXg9Imh0dHA6Ly9leGFtcGxlLmNvbS9zYW1wbGUtZGF0YS8x LjAiDQo+ID4gPiA+IC8+DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAgPC95cDpzdWJ0cmVlLWZp bHRlcj4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gQW5keQ0KPiA+ID4NCj4gPiA+DQo+ID4g Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0 Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5ldGNvbmZAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0K --_000_C4707D28EAE245E8AAC8E05602A2A39Cciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <3C5585D67F8AE4408B5AB9819C95D7F4@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+dGw7ZHIg4oCUIEkgYWdy ZWUgdGhhdCB3ZSBzaG91bGQgY2xvc2UgdGhpcyBhbmQgdXNlIGEgeWFuZy1kYXRhIGRlY2xhcmF0 aW9uIHRvIGRlZmluZSB3aGF0IGdvZXMgaW50byB0aGUg4oCcZXJyb3ItaW5mb+KAnS4gTGV04oCZ cyBtYWtlIHByb2dyZXNzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkhv d2V2ZXIsIEkgYWxzbyBhZ3JlZSB3aXRoIEFsZXggdGhhdCB0aGUgc29sdXRpb24gcHJvcG9zZWQg aXMgY2x1bmt5LCBhbmQgSSBkb27igJl0IHRoaW5rIGl0IGFjdHVhbGx5IHByb21vdGVzIHN0YW5k YXJkaXNlZCBlcnJvciBoYW5kbGluZyBhcyB0aGUgY29uZGl0aW9ucyB3ZSBhcmUgZGVhbGluZyB3 aXRoIGhlcmUgYXJlIGp1c3Qgbm90IGFzIHNpbXBsZSBhcyDigJxzb3JyeSwgaXQgZGlkbuKAmXQg d29ya+KAnS4gVGhlIFJQQyB3aWxsDQogaGF2ZSB3b3JrZWQgZXhhY3RseSBhcyBpbnRlbmRlZCwg YW5kIG1heSBoYXZlIHByb3ZpZGVkIHlvdSB3aXRoIGluZm9ybWF0aW9uIHJlbGF0aW5nIHRvLCBm b3IgZXhhbXBsZSwgaG93IHRvIGNyZWF0ZSBhIHN1YnNjcmlwdGlvbiByZXF1ZXN0IHRoYXQgd2ls bCB3b3JrLiBJdCBqdXN0IHdvbuKAmXQgbmVjZXNzYXJpbHkgaGF2ZSBlc3RhYmxpc2hlZCB0aGUg c3Vic2NyaXB0aW9uDQo8YiBjbGFzcz0iIj5leGFjdGx5PC9iPiZuYnNwO2FzIHlvdSB3YW50ZWQu IFRoZSBSUEMgaXRzZWxmIGV4ZWN1dGVkIGNvbXBsZXRlbHkgY29ycmVjdGx5LCBhbmQgdGh1cyDi gJxycGMtZXJyb3LigJ0gc2VlbXMgbGlrZSBhbiBpbmNvcnJlY3QgcmVzcG9uc2UuIFdoYXQgd2Ug YXJlIGRvaW5nIGhlcmUgaXMgc2ltcGx5IG5vdCB0aGUgc2FtZSBhcywgZm9yIGV4YW1wbGUsIGFu IGVkaXQgY29uZmlnIHRoYXQgZmFpbGVkIGR1ZSB0byBpbnZhbGlkIGRhdGEgYW5kIGxlZnQNCiB0 aGUgc3lzdGVtIGNvbmZpZ3VyYXRpb24gc3RhdGUgdW5jaGFuZ2VkLjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QnV0IGFueXdheSwgbGV0 4oCZcyBtYWtlIHByb2dyZXNzLiBNYWNoaW5lIHJlYWRhYmxlIGVycm9yLWluZm8gd2l0aCB5YW5n LWRhdGEgaXMgYSBzdGVwIGluIHRoZSByaWdodCBkaXJlY3Rpb24sIGJ1dCBiZWNhdXNlIG9mIHRo YXQgc3RhbmRhcmRpc2VkIGVycm9yIGhhbmRsaW5nIGp1c3QgaXNu4oCZdCBwbGF1c2libGUuIElm IHdl4oCZZCByZXNlcnZlZCDigJxycGMtZXJyb3LigJ0gZm9yIHRoaW5ncyB0aGF0IGp1c3QgZGlk buKAmXQgd29yaywNCiB0aGF0IHdvdWxkIHByb3ZpZGUgY2xlYW5lciBzZW1hbnRpY3MuPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+Q2hlZXJzLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RWluYXI8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIDYgRGVjIDIwMTcsIGF0IDAyOjAx LCBBbGV4YW5kZXIgQ2xlbW0gJmx0OzxhIGhyZWY9Im1haWx0bzphbGV4YW5kZXIuY2xlbW1AaHVh d2VpLmNvbSIgY2xhc3M9IiI+YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90 ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rp b24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPkkgc3RpbGwgZmluZCB0aGlzIGEgYml0IGNs dW5reSAoYW5kIEkgc3RpbGwgd29uZGVyIGlmIHdlIGNvdWxkIGRlZmluZSDigJxjb3JuZXIgYmVo YXZpb3LigJ0gaW5zdGVhZCBvZiBlcnJvciBjb25kaXRpb25zKSwgYnV0IE9LLCBsZXTigJlzIGdv IHdpdGggdGhlIHByb3Bvc2VkIGFzIG91dGxpbmVkDQogYnkgTWFydGluLiAmbmJzcDs8bzpwIGNs YXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPkxldOKAmXMgY2xvc2Ug dGhpczsgd2Ugd2lsbCB1cGRhdGUgdGhlIFJQQ3MgYWNjb3JkaW5nbHkuJm5ic3A7ICZuYnNwOzxv OnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNz PSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+VGhhbmtzPG86 cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiIGNsYXNzPSIiPi0tLSBBbGV4PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJz cDs8L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IG5vbmUgbm9u ZSBub25lIHNvbGlkOyBib3JkZXItbGVmdC13aWR0aDogMS41cHQ7IGJvcmRlci1sZWZ0LWNvbG9y OiBibHVlOyBwYWRkaW5nOiAwaW4gMGluIDBpbiA0cHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLXRv cC13aWR0aDogMXB0OyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMjI1LCAyMjUsIDIyNSk7IHBhZGRp bmc6IDNwdCAwaW4gMGluOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkFuZHkgQmllcm1hbiBbPGEgaHJlZj0ibWFpbHRv OmFuZHlAeXVtYXdvcmtzLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlv bjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbTwvYT5dPHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0i Ij4NCjxiIGNsYXNzPSIiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5UdWVzZGF5LCBEZWNlbWJlciAwNSwgMjAxNyAyOjIwIFBNPGJyIGNs YXNzPSIiPg0KPGIgY2xhc3M9IiI+VG86PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5BbGV4YW5kZXIgQ2xlbW0gJmx0OzxhIGhyZWY9Im1haWx0bzph bGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVj b3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb208 L2E+Jmd0OzxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkNjOjwvYj48c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TWFydGluIEJqb3JrbHVuZCAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1k ZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5tYmpAdGFpbC1mLmNvbTwvYT4mZ3Q7Ozxz cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJt YWlsdG86bmV0Y29uZkBpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3Jh dGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+bmV0Y29uZkBpZXRmLm9yZzwvYT48YnIgY2xhc3M9 IiI+DQo8YiBjbGFzcz0iIj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtOZXRjb25mXSB5YW5nLXB1c2ggaXNzdWU6IGVycm9y IGhhbmRsaW5nPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9 IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0K SGksPG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xh c3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NCkhlcmUg aXMgdGhlIHByb2JsZW0gd2l0aCB0aGUgWUFORyBQdXNoIGVycm9yIGhhbmRsaW5nLjxvOnAgY2xh c3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFzcz0iIj4NClRoZSAmbHQ7cnBj LWVycm9yJmd0OyByZXNwb25zZSBpcyBhIE1VU1QsIG5vdCBhIFNIT1VMRDo8bzpwIGNsYXNzPSIi PjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZu YnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPHByZSBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAmcXVv dDtDb3VyaWVyIE5ldyZxdW90Ozsgd29yZC13cmFwOiBicmVhay13b3JkOyB3aGl0ZS1zcGFjZTog cHJlLXdyYXA7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iIiBjbGFzcz0iIj40LjMuJm5ic3A7ICZs dDtycGMtZXJyb3ImZ3Q7IEVsZW1lbnQ8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBm b250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IiBjbGFzcz0iIj48c3BhbiBzdHls ZT0iIiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250 LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0i IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgVGhlICZsdDtycGMtZXJyb3ImZ3Q7IGVsZW1lbnQgaXMg c2VudCBpbiAmbHQ7cnBjLXJlcGx5Jmd0OyBtZXNzYWdlcyBpZiBhbiBlcnJvcjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90 OzsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSIiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBvY2N1cnMg ZHVyaW5nIHRoZSBwcm9jZXNzaW5nIG9mIGFuICZsdDtycGMmZ3Q7IHJlcXVlc3QuPG86cCBjbGFz cz0iIj48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7OyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJz cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 OyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9IiIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7IElmIGEgc2Vy dmVyIGVuY291bnRlcnMgbXVsdGlwbGUgZXJyb3JzIGR1cmluZyB0aGUgcHJvY2Vzc2luZyBvZiBh bjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3Vy aWVyIE5ldyZxdW90OzsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSIiIGNsYXNzPSIiPiZuYnNwOyZu YnNwOyAmbHQ7cnBjJmd0OyByZXF1ZXN0LCB0aGUgJmx0O3JwYy1yZXBseSZndDsgTUFZIGNvbnRh aW4gbXVsdGlwbGUgJmx0O3JwYy1lcnJvciZndDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MHB0OyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IiBjbGFzcz0iIj48c3Bh biBzdHlsZT0iIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgZWxlbWVudHMuJm5ic3A7IEhvd2V2ZXIs IGEgc2VydmVyIGlzIG5vdCByZXF1aXJlZCB0byBkZXRlY3Qgb3IgcmVwb3J0IG1vcmU8bzpwIGNs YXNzPSIiPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcm cXVvdDs7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgdGhh biBvbmUgJmx0O3JwYy1lcnJvciZndDsgZWxlbWVudCwgaWYgYSByZXF1ZXN0IGNvbnRhaW5zIG11 bHRpcGxlIGVycm9ycy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iIiBjbGFz cz0iIj4mbmJzcDsmbmJzcDsgQSBzZXJ2ZXIgaXMgbm90IHJlcXVpcmVkIHRvIGNoZWNrIGZvciBw YXJ0aWN1bGFyIGVycm9yIGNvbmRpdGlvbnMgaW48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MHB0OyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IiBjbGFzcz0iIj48c3Bh biBzdHlsZT0iIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgYSBzcGVjaWZpYyBzZXF1ZW5jZS4mbmJz cDsgPGIgY2xhc3M9IiI+QSBzZXJ2ZXIgTVVTVCByZXR1cm4gYW4gJmx0O3JwYy1lcnJvciZndDsg ZWxlbWVudCBpZjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9iPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWls eTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IiBjbGFzcz0iIj48YiBjbGFzcz0iIj48c3BhbiBz dHlsZT0iIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgYW55IGVycm9yIGNvbmRpdGlvbnMgb2NjdXIg ZHVyaW5nIHByb2Nlc3NpbmcuPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iIiBjbGFzcz0iIj48bzpw IGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyIg Y2xhc3M9IiI+PHNwYW4gc3R5bGU9IiIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj4mbmJzcDs8L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyB3b3Jk LXdyYXA6IGJyZWFrLXdvcmQ7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsiIGNsYXNzPSIiPjxzcGFu IHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozsgd29yZC13cmFwOiBicmVhay13 b3JkOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iIiBjbGFz cz0iIj5BbmR5PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IHdoaXRlLXNwYWNl OiBwcmUtd3JhcDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSIiIGNsYXNzPSIiPjxvOnAgY2xhc3M9 IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywgc2VyaWY7IiBjbGFz cz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssIHNlcmlmOyIgY2xhc3M9IiI+ DQpPbiBUdWUsIERlYyA1LCAyMDE3IGF0IDEyOjM1IFBNLCBBbGV4YW5kZXIgQ2xlbW0gJmx0Ozxh IGhyZWY9Im1haWx0bzphbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsi IHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNz PSIiPmFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cCBjbGFzcz0i Ij48L286cD48L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXItc3R5bGU6IG5vbmUgbm9u ZSBub25lIHNvbGlkOyBib3JkZXItbGVmdC13aWR0aDogMXB0OyBib3JkZXItbGVmdC1jb2xvcjog cmdiKDIwNCwgMjA0LCAyMDQpOyBwYWRkaW5nOiAwaW4gMGluIDBpbiA2cHQ7IG1hcmdpbi1sZWZ0 OiA0LjhwdDsgbWFyZ2luLXJpZ2h0OiAwaW47IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KSGkgTWFydGluLDxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClN1cmUsIHRoZSBldmVudHVhbCBzb2x1dGlvbiBtYXkg bWFrZSB1c2Ugb2YgcnBjLWVycm9yIGFnYWluLiZuYnNwOyBCdXQgdW50aWwgd2UgZ2V0IHRoZXJl LCB0aGUgY3VycmVudGx5IHByb3Bvc2VkIHNvbHV0aW9uIHNlZW1zIHRvIG1ha2Ugc2Vuc2UgdG8g bWUuJm5ic3A7IEkgZG9uJ3QgdGhpbmsgd2UgaGF2ZSBhbiBpc3N1ZSB0b2RheSB3aXRoIGxvdHMg b2YgUlBDcyBlYWNoIGRlZmluaW5nIHRoZWlyIG93biB3YXkgb2YgZGVhbGluZyB3aXRoIGNvcm5l ciBjb25kaXRpb25zDQogLSBkZWZpbml0aW9uIG9mIFJQQ3MgaXMgc29tZXRoaW5nIHRoYXQgaGFz IHNvIGZhciBvbmx5IHJhcmVseSBiZWVuIGV4ZXJjaXNlZCB3aXRoIFlBTkcgbW9kZWxzLiZuYnNw OyBPbmNlIHRoaXMgYmVjb21lcyBtb3JlIGNvbW1vbiwgSSBhbSBzdXJlIHdlIHdpbGwgZmluZCBh IG1vcmUgZ2VuZXJhbCBzb2x1dGlvbiwgYnV0IEkgZG9uJ3QgdGhpbmsgd2UgYXJlIGF0IHRoYXQg cG9pbnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS0tIEFsZXg8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyIGNsYXNz PSIiPg0KJmd0OyBGcm9tOiBNYXJ0aW4gQmpvcmtsdW5kIFttYWlsdG86PGEgaHJlZj0ibWFpbHRv Om1iakB0YWlsLWYuY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1 bmRlcmxpbmU7IiBjbGFzcz0iIj5tYmpAdGFpbC1mLmNvbTwvYT5dPGJyIGNsYXNzPSIiPg0KJmd0 OyBTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAwNSwgMjAxNyAxMjoyNSBQTTxiciBjbGFzcz0iIj4N CiZndDsgVG86PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxl OyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmFuZHlAeXVtYXdvcmtzLmNv bTwvYT48YnIgY2xhc3M9IiI+DQomZ3Q7IENjOiBBbGV4YW5kZXIgQ2xlbW0gJmx0OzxhIGhyZWY9 Im1haWx0bzphbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7 IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+YWxleGFuZGVyLmNsZW1tQGh1 YXdlaS5jb208L2E+Jmd0Ozs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjog cHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPm5ldGNvbmZAaWV0 Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KJmd0OyBTdWJqZWN0OiBSZTogW05ldGNvbmZdIHlhbmct cHVzaCBpc3N1ZTogZXJyb3IgaGFuZGxpbmc8YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIi Pg0KJmd0OyBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5j b20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNs YXNzPSIiPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCiZn dDsgJmd0OyBIaSw8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZn dDsgVGhlIHByb3RvY29sIGRlZmluZXMgaG93IGVycm9yIGhhbmRsaW5nIGlzIGRvbmUsIG5vdCB0 aGUgaW5kaXZpZHVhbDxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyBvcGVyYXRpb25zLjxiciBjbGFz cz0iIj4NCiZndDsgJmd0OyBJZiB0aGUgcmVxdWVzdCBmYWlscywgdGhlbiBjbGllbnRzIGV4cGVj dCBhbiAmbHQ7cnBjLWVycm9yJmd0OyBhbmQgc2VydmVyczxiciBjbGFzcz0iIj4NCiZndDsgJmd0 OyBhcmUgZGVzaWduZWQgdG8gc2VuZCBhbiAmbHQ7cnBjLWVycm9yJmd0OyB3aGVuIGEgY2xpZW50 IHJlcXVlc3QgZmFpbHMuPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgQWdy ZWVkLCBhbmQgZm9yIFJFU1RDT05GLCB0aGUgSFRUUCBlcnJvciBjb2RlcyBhcmUgdXNlZC4mbmJz cDsgQW4gSFRUUCByZXF1ZXN0PGJyIGNsYXNzPSIiPg0KJmd0OyB0aGF0IGZhaWxzIGRvZXMgbm90 IHJldHVybiAyMDAgb2sgd2l0aCBhIGJvZHkgdGhhdCBleHBsYWlucyB0aGF0IGl0IGFjdHVhbGx5 IHdhczxiciBjbGFzcz0iIj4NCiZndDsgYW4gZXJyb3IuPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBj bGFzcz0iIj4NCiZndDsgJmd0OyBJTU8sIGEgc2VwYXJhdGUgZXJyb3IgaGFuZGxpbmcgcHJvY2Vk dXJlIGZvciBlYWNoIFJQQyBpcyBtb3JlIGNsdW5reTxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyB0 aGFuIGVycm9yLWluZm8uPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJiM0 MzsxPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgU29tZSBhZGRpdGlvbmFs IGNvbW1lbnRzIGlubGluZS48YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0Ozxi ciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7IFdoaWxlIHBvc3NpYmxlLCB0aGUgc29sdXRpb24g b2YgaGF2aW5nIHRvIHJldHVybiBycGMtZXJyb3IgZXRjIGRvZXM8YnIgY2xhc3M9IiI+DQomZ3Q7 ICZndDsgJmd0OyBzdHJpa2UgbWUgYXMgc29tZXdoYXQgY2x1bmt5LiZuYnNwOyBXaGlsZSBpdCBp cyBwb3NzaWJsZSB0byBhZGQgYW48YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyBlcnJvci1h cHAtdGFnLCBhbmQgbmVnb3RpYXRpb24gc3R1ZmYgYXMgZXJyb3ItaW5mbyAoYW5kIEkgYXBwcmVj aWF0ZTxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7IHRoZSBzdWdnZXN0aW9uKSwgdGhhdCBz b2x1dGlvbiB3b3VsZCBuZWVkIHRvIGJlIGRlc2NyaWJlZCB1c2luZyBhPGJyIGNsYXNzPSIiPg0K Jmd0OyAmZ3Q7ICZndDsgbG90IG9mIHByb3NlIGluIGRlc2NyaXB0aW9uIHN0YXRlbWVudHMgYSBs YSBTTUl2MiAocHJlc3VtYWJseSBhczxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7IHBhcnQg b2YgdGhlIFJQQyBkZXNjcmlwdGlvbiwgbm90IGFzIHBhcnQgb2YgZS5nLiB0aGUgaWRlbnRpdGll cyw8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyB3aGljaCBtaWdodCBiZSB1c2VkIGluIGEg bnVtYmVyIG9mIHBsYWNlcywgbm90IGp1c3QgdGhlIGVycm9yLWFwcC10YWcpLjxiciBjbGFzcz0i Ij4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IElmIGJvdGggdGhlIGVycm9yIGNvZGUgYW5kIGhp bnQgaXMgZGVmaW5lZCBpbiBhIHlhbmctZGF0YSAoaS5lLiwgbm90IHVzaW5nIHRoZTxiciBjbGFz cz0iIj4NCiZndDsgZXJyb3ItYXBwLXRhZyksIHlvdSB3b3VsZCBkbzo8YnIgY2xhc3M9IiI+DQom Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDt5eDp5YW5nLWRhdGEgc3Vic2NyaXB0 aW9uLWVycm9yIHs8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDtjb250YWlu ZXIgc3Vic2NyaXB0aW9uLWVycm9yIHs8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7bGVhZiBlcnJvci1jb2RlIHs8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3R5cGUgaWRlbnRpdHkgezxiciBjbGFzcz0iIj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Jhc2UgZXJyb3I7PGJy IGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt9PGJyIGNs YXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308YnIgY2xhc3M9IiI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Y29udGFpbmVyIGhpbnRzIHsgLi4uIH08YnIg Y2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt9PGJyIGNsYXNzPSIiPg0KJmd0OyZu YnNwOyAmbmJzcDt9PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgVGhlbiB5 b3UgYXJlIHJpZ2h0LCB5b3UgaGF2ZSB0byBkZXNjcmliZSBpbiBwcm9zZSB0aGF0IHRoaXMgeWFu Zy1kYXRhPGJyIGNsYXNzPSIiPg0KJmd0OyBzdHJ1Y3R1cmUgY2FuIGJlIHNlbnQgYXMgZXJyb3It aW5mby48YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4N CiZndDsgJmd0OyAmZ3Q7IEkgYW0gbm90IHN1cmUgd2h5IHRoYXQgd291bGQgbWFrZSBhbiBSUEMg YW55IGVhc2llciB0byBpbXBsZW1lbnQuPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgVGhl IHNhbWUgY2hlY2tzIHN0aWxsIGhhdmUgdG8gYmUgbWFkZS48YnIgY2xhc3M9IiI+DQomZ3Q7PGJy IGNsYXNzPSIiPg0KJmd0OyBBZ3JlZWQuPGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4N CiZndDsgJmd0OyAmZ3Q7IFdoeSB3b3VsZCB0aGUgcHJvcG9zZWQgc29sdXRpb24gbm90IGFjY2Vw dGFibGU/Jm5ic3A7ICZuYnNwO0lkZWFsbHkgWUFORyB3b3VsZDxiciBjbGFzcz0iIj4NCiZndDsg Jmd0OyAmZ3Q7IHByb3ZpZGUgYmV0dGVyIHN1cHBvcnQgdG8gZm9ybWFsbHkgZGVmaW5lIGFwcGxp Y2F0aW9uL1JQQy1zcGVjaWZpYzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7IHJldHVybiBj b2RlcyBhbmQgY29ybmVyIGNvbmRpdGlvbnMgZXRjLjxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7IEFsc28gYWdyZWVkLiZuYnNwOyBCdXQgb25jZSB3ZSBoYXZlIHRoYXQsIHN1 Y2ggYSBzb2x1dGlvbiB3b3VsZCBtYWtlIHVzZSBvZiB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7IHJw Yy1lcnJvciB3ZSBoYXZlIChmb3IgYm90aCBORVRDT05GIGFuZCBSRVNUQ09ORikuPGJyIGNsYXNz PSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IC9tYXJ0aW48 YnIgY2xhc3M9IiI+DQomZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OzxiciBjbGFzcz0iIj4NCiZndDsg Jmd0OyAmZ3Q7IFNob3J0IG9mIHRoYXQsIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBvZiBhZGRpbmcg UlBDIG91dHB1dCBwYXJhbWV0ZXJzPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgdGhhdCBh cmUgdXNlZCBmb3IgdGhlIHB1cnBvc2Ugb2YgaW5kaWNhdGluZyB3aGF0IGlzIGdvaW5nIG9uIGF0 IHRoZTxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7IGFwcGxpY2F0aW9uIGxldmVsIHNpbXBs eSBtYWtlcyB0aGVtIHBhcnQgb2YgdGhlIHNlbWFudGljcyBvZiB0aGU8YnIgY2xhc3M9IiI+DQom Z3Q7ICZndDsgJmd0OyBzcGVjaWZpYyBSUEMgaXRzZWxmLiZuYnNwOyBJdCBpcyBub3QgTmV0Y29u ZuKAmXMgcm9sZSB0byBkZWZpbmUgd2hhdCBhbiBSUEM8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsg Jmd0OyBjYW4gb3IgY2Fubm90IGRvLCBqdXN0IGxpa2UgaXQgY2Fubm90IGRlZmluZSB3aGF0IGEg cGFydGljdWxhciBsZWFmPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgbWF5IG9yIG1heSBu b3QgcmVwcmVzZW50LiZuYnNwOyBUaGF0IGlzIHBhcnQgb2YgdGhlIFJQQyBkZWZpbml0aW9uLjxi ciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDs8 YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7 IEJhc2ljYWxseSwgd2hhdCB3ZSBhcmUgZGlzY3Vzc2luZyBoZXJlIGlzIGJlaGF2aW9yIG9mIHN1 YnNjcmlwdGlvbjxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7IGNvbmZpZ3VyYXRpb24gdW5k ZXIgY29ybmVyIGNvbmRpdGlvbnMuJm5ic3A7IFRoZSBmYWN0IHRoYXQgbm88YnIgY2xhc3M9IiI+ DQomZ3Q7ICZndDsgJmd0OyBzdWJzY3JpcHRpb24gaXMgY3JlYXRlZCBiZWNhdXNlIGl0IHdvdWxk IHJlc3VsdCBpbiBhbiB1bmFjY2VwdGFibGU8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyB2 b2x1bWUgb2YgdXBkYXRlcyBmb3IgYSBzcGVjaWZpYyBpbXBsZW1lbnRhdGlvbiBpcyBkaWZmZXJl bnQgZnJvbSBhbjxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7IGVycm9yIGNvbmRpdGlvbiBz dWNoIGFzIGEgbWFsZm9ybWVkIG1lc3NhZ2UgdGhhdCBpcyBtaXNzaW5nIGE8YnIgY2xhc3M9IiI+ DQomZ3Q7ICZndDsgJmd0OyByZXF1aXJlZCBtZXNzYWdlLWlkLCBvciB3aGVyZSBhIHZhbHVlIHZp b2xhdGVzIGEgY29uc3RyYWludDxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7IHNwZWNpZmll ZCBpbiBhIE1VU1QtY29uZGl0aW9uLiZuYnNwOyBJbiBvdXIgY2FzZSwgd2hhdCBpcyBiZWluZyBk ZXNjcmliZWQgYXJlPGJyIGNsYXNzPSIiPg0KJmd0OyBzcGVjaWZpYyBjb25kaXRpb25zIGF0IHRo ZSBhcHBsaWNhdGlvbiBsYXllciwgYWJvdmUgdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZn dDsgTmV0Y29uZi9SZXN0Y29uZiBnZW5lcmljIHZhbGlkYXRpb24gaW5mcmFzdHJ1Y3R1cmUuJm5i c3A7ICZuYnNwO1RoZSBvcGVyYXRpb24gZG9lczxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7 IG5vdCDigJx3b3Jr4oCdIGluIHRoZSBzZW5zZSB0aGF0IGl0IGRvZXMgbm90IHJlc3VsdCBpbiBh biBhY3RpdmU8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyBzdWJzY3JpcHRpb24sIGJ1dCBp dCBkb2VzIHdvcmsgaW4gdGhlIHNlbnNlIHRoYXQgdGhlIGJlaGF2aW9yIGlzPGJyIGNsYXNzPSIi Pg0KJmd0OyAmZ3Q7ICZndDsgdmVyeSB3ZWxsIGRlZmluZWQgaW4gdGVybXMgb2YgdGhlIGVmZmVj dCB0aGF0IHRoZSBSUEMgaGFzIChpLmUuIHRoZTxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7 IGVmZmVjdCBpcyB0aGF0IGl0IHJlc3VsdCBpbiBjcmVhdGlvbiBvZiBhIHN1YnNjcmlwdGlvbiwg aWYgY2VydGFpbjxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7IGNvbmRpdGlvbnMgYXJlIG1l dCwgYW5kIGl0IGRvZXMgbm90IHJlc3VsdCBpbiBjcmVhdGlvbiBvZiBhPGJyIGNsYXNzPSIiPg0K Jmd0OyAmZ3Q7ICZndDsgc3Vic2NyaXB0aW9uIGluIGNhc2UgY2VydGFpbiBjb25kaXRpb25zIGFy ZSBub3QgbWV0KS4mbmJzcDsgV2h5IHNob3VsZDxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7 IE5ldGNvbmYgcmVzdHJpY3Qgd2hhdCBhbiBSUEMgY2FuIG9yIGNhbm5vdCBkbz8mbmJzcDsgVGhp cyBpcyBhbGwgYXBwbGljYXRpb24tPGJyIGNsYXNzPSIiPg0KJmd0OyBzcGVjaWZpYy48YnIgY2xh c3M9IiI+DQomZ3Q7ICZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7PGJyIGNs YXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyAtLS0g QWxleDxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7 ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0 OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZn dDsgJmd0OyAqRnJvbToqIE5ldGNvbmYgW21haWx0bzo8YSBocmVmPSJtYWlsdG86bmV0Y29uZi1i b3VuY2VzQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1 bmRlcmxpbmU7IiBjbGFzcz0iIj5uZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSAqT24gQmVo YWxmIE9mPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgKkFuZHkgQmllcm1hbjxiciBjbGFz cz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICpTZW50OiogTW9uZGF5LCBEZWNlbWJlciAwNCwgMjAxNyA5 OjE1IEFNPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgKlRvOiogTWFydGluIEJqb3JrbHVu ZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIiBzdHlsZT0iY29sb3I6IHB1cnBs ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5tYmpAdGFpbC1mLmNvbTwv YT4mZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgKkNjOiogTmV0Y29uZiAmbHQ7PGEg aHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0 LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPm5ldGNvbmZAaWV0Zi5vcmc8L2E+Jmd0 OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICpTdWJqZWN0OiogUmU6IFtOZXRjb25mXSB5 YW5nLXB1c2ggaXNzdWU6IGVycm9yIGhhbmRsaW5nPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZn dDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAm Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsg Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7 ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyBPbiBNb24sIERlYyA0LCAyMDE3IGF0 IDQ6NTUgQU0sIE1hcnRpbiBCam9ya2x1bmQgJmx0OzxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1m LmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIg Y2xhc3M9IiI+bWJqQHRhaWwtZi5jb208L2E+Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgd3JvdGU6 PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0 OyBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iIHN0 eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIi PmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsgSGksPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OzxiciBjbGFz cz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSU1PIHRoZSBzcGVjaWFsIGVycm9yIGhhbmRsaW5n IGluIFlBTkcgUHVzaCBpcyBub3QgYWNjZXB0YWJsZTxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgYmVjYXVzZSBpdCB2aW9sYXRlcyBORVRDT05GIGFuZCBSRVNUQ09ORiBlcnJvciBo YW5kbGluZyBwcm9jZWR1cmVzLjxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgTkVU Q09ORiBzYXlzIGlmIHRoZSBvcGVyYXRpb24gZG9lcyBub3Qgd29yayBmb3IgYW55IHJlYXNvbiBh bjxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0O3JwYy1lcnJvciZndDsgZWxl bWVudCBTSE9VTEQgYmUgcmV0dXJuZWQuPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDs8YnIg Y2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyBJIGZ1bGx5IGFncmVlLCBhbmQgSSBoYXZlIHBvaW50 ZWQgdGhpcyBvdXQgc2V2ZXJhbCB0aW1lcyBpbiBteTxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAm Z3Q7IHJldmlld3MuJm5ic3A7IFRoZSBwcm9ibGVtIGlzIGFjdHVhbGx5IGluIHN1YnNjcmliZWQg bm90aWZpY2F0aW9ucywgYW5kIEk8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyB0aGluayBF cmljIGlzIHRyYWNraW5nIHRoYXQgaXNzdWUuPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDs8 YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyBUcnlpbmcgdG8gYmUgY29uc3RydWN0aXZlLCBJ IHRoaW5rIHRoYXQgdGhlIGV4aXN0aW5nIG1lY2hhbmlzbXMgaW48YnIgY2xhc3M9IiI+DQomZ3Q7 ICZndDsgJmd0OyBZQU5HIGNhbiBiZSB1c2VkIHRvIGFjaGlldmUgdGhlIHNhbWUgZnVuY3Rpb25h bGl0eSB0aGF0IHRoZXNlIGRyYWZ0czxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7IHRyeSB0 byBhY2hpZXZlLiZuYnNwOyBTcGVjaWZpY2FsbHk6PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZn dDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsxLiBVc2UgaWRlbnRp dGllcyBqdXN0IGxpa2UgdGhlIG9uZXMgeW91IGhhdmU8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsg Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICgmcXVvdDt1bnN1cHBvcnRhYmxlLXZvbHVtZSZxdW90 OywgJnF1b3Q7ZmlsdGVyLXVuYXZhaWxhYmxlJnF1b3Q7IGV0YyksIGJ1dCBhZGQgdGV4dDxiciBj bGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhhdCBleHBsYWlu cyB0aGF0IHRoZXNlIGlkZW50aXRpZXMgYXJlIHNlbnQgYXMgJnF1b3Q7ZXJyb3ItYXBwLXRhZyZx dW90OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgaW4g JnF1b3Q7cnBjLWVycm9yJnF1b3Q7LCBlbmNvZGVkIHRvIGEgc3RyaW5nIGFzICZsdDttb2R1bGUm Z3Q7OiZsdDtpZGVudGl0eSZndDsuJm5ic3A7IFRoaXM8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsg Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IHdvcmtzIGZvciBib3RoIE5FVENPTkYgYW5kIFJFU1RD T05GLjxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7Mi4gRm9yIHRoZSAmcXVvdDtoaW50cyZxdW90OyBleHRyYSBpbmZv IHRoYXQgeW91IHJldHVybiwgZGVmaW5lIGEgJnF1b3Q7eWFuZy1kYXRhJnF1b3Q7PGJyIGNsYXNz PSIiPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBzdHJ1Y3R1cmUgd2l0aCB0 aGUgaGludHMsIGFuZCBleHBsYWluIGluIHRleHQgdGhhdCB0aGlzIHN0cnVjdHVyZTxiciBjbGFz cz0iIj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgaXMgcmV0dXJuZWQgaW4g JnF1b3Q7ZXJyb3ItaW5mbyZxdW90Oy4mbmJzcDsgVGhpcyB3b3JrcyBmb3IgYm90aCBORVRDT05G IGFuZDxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgUkVT VENPTkYuPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZn dDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAm Z3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsg Jmd0OyAmZ3Q7ICYjNDM7MTxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7PGJyIGNsYXNzPSIi Pg0KJmd0OyAmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OzxiciBjbGFzcz0i Ij4NCiZndDsgJmd0OyAmZ3Q7IElmIHRoZSBlcnJvciBoYW5kbGluZyB3YXMgZG9uZSBjb3JyZWN0 bHkgdGhlbiB0aGUgc2FtZSBwcm9jZWR1cmVzPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsg Y291bGQgYmU8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsg Jmd0OyAmZ3Q7IGFwcGxpZWQgdG8gJmx0O2VkaXQtY29uZmlnJmd0OyBmYWlsdXJlcyBmb3IgY29u ZmlndXJlZCBzdWJzY3JpcHRpb25zLjxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7PGJyIGNs YXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OzxiciBj bGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDs8YnIg Y2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7IEFz IGFuIGFsdGVybmF0aXZlIHRvIDEsIHlvdSBjYW4gcHV0IHRoZSBlcnJvciBpZGVudGl0aXlyZWYg aW4gdGhlPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgJnF1b3Q7eWFuZy1kYXRhJnF1b3Q7 IHN0cnVjdHVyZSwgYW5kIHNlbmQgYm90aCB0aGUgaWRlbnRpdGl5cmVmIGFuZCBoaW50cyBpbjxi ciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZxdW90O2Vycm9yLWluZm8mcXVvdDsuPGJyIGNs YXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OzxiciBj bGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7IC9tYXJ0aW48YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsg Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7 ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0 OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgQW5keTxiciBjbGFzcz0iIj4NCiZn dDsgJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQom Z3Q7ICZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0K Jmd0OyAmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OzxiciBjbGFzcz0iIj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlICZsdDtlc3RhYmxpc2gtc3Vic2NyaXB0aW9uJmd0OyBy ZXR1cm5zIGRhdGEgZXZlbiBvbiBlcnJvci48YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IEluc3RlYWQgb2YgdGhlIGNvbW1vbiBlcnJvci10YWcsIGVycm9yLWluZm8sIGFuZCBvdGhl ciBmaWVsZHMsPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGVyZSBpcyBhIHN1 YnNjcmlwdGlvbi1yZXN1bHQgbGVhZi48YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBJZiBhbnkgY2xpZW50IChvciBldmVu IHNlcnZlcikgZnVuY3Rpb25hbGl0eSB1c2VzIHRoZSBORVRDT05GIGFuZDxiciBjbGFzcz0iIj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgUkVTVENPTkYgc3RhbmRhcmQgZXJyb3IgaGFuZGxpbmcsIHRo ZW4gc3Vic2NyaXB0aW9uLXJlc3VsdCB3aWxsPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyBub3QgYmUgc2VudCBvciBleHBlY3RlZCBhcyBhbiBlcnJvciByZXNwb25zZS4gRGVwZW5k aW5nIG9uIHRoZTxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgc2VydmVyIGltcGxl bWVudGF0aW9uLCB0aGUgY29kZSB0aGF0IGtub3dzIGFib3V0PGJyIGNsYXNzPSIiPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyBlc3RhYmxpc2gtc3Vic2NyaXB0aW9uIG1heSBub3QgZ2V0IGNhbGxlZCBi ZWNhdXNlIGNvbW1vbiBlcnJvcjxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgaGFu ZGxpbmcgY29kZSBoYXMgYWxyZWFkeSBkZXRlcm1pbmVkIHRoZXJlIGlzIGFuICZsdDtycGMtZXJy b3ImZ3Q7IHRvPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBzZW5kIGluc3RlYWQg b2YgYSBkYXRhIHJlc3BvbnNlLjxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnIg Y2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEV4cGVjdCB0aGF0IHNvbWUgc2VydmVycyBh cmUgbmV2ZXIgZ29pbmcgdG8gc2VuZCBkYXRhIG9uIGFuPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyBvcGVyYXRpb24gZmFpbHVyZSwgYW5kIHdpbGwgb25seSBzZW5kICZsdDtycGMt ZXJyb3ImZ3Q7IGluc3RlYWQuPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OzxiciBj bGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDtGcm9tIHNlYy4gMy44OjxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBGb3IgaW5z dGFuY2UsIGZvciB0aGUgZm9sbG93aW5nIHJlcXVlc3Q6PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0O25ldGNvbmY6 cnBjIG1lc3NhZ2UtaWQ9JnF1b3Q7MTAxJnF1b3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyZuYnNwOyAmbmJzcDsgeG1sbnM6bmV0Y29uZj0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6 eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAmcXVvdDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJmx0O2VzdGFibGlzaC1zdWJzY3JpcHRpb248YnIgY2xh c3M9IiI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHht bG5zPSZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLXN1YnNjcmliZWQtbm90 aWZpY2F0aW9ucyZxdW90OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgeG1sbnM6eXA9JnF1b3Q7dXJuOmlldGY6cGFyYW1zOnhtbDpu czp5YW5nOmlldGYteWFuZy1wdXNoJnF1b3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7eXA6ZGF0YXN0b3JlJmd0Ozxi ciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmx0O3lwOnNvdXJjZSB4bWxucz0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5z Onlhbmc6aWV0Zi1kYXRhc3RvcmVzJnF1b3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29wZXJhdGlv bmFsPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmbHQ7L3lwOnNvdXJjZSZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDt5cDpzdWJ0cmVl LWZpbHRlciBuZXRjb25mOnR5cGU9JnF1b3Q7eHBhdGgmcXVvdDs8YnIgY2xhc3M9IiI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7eG1sbnM6ZXg9JnF1b3Q7PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tL3NhbXBsZS1k YXRhLzEuMCIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29y YXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmh0dHA6Ly9leGFtcGxlLmNvbS9zYW1wbGUtZGF0 YS8xLjA8L2E+JnF1b3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3NlbGVjdD0mcXVvdDsvZXg6 Zm9vJnF1b3Q7LyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy95cDpkYXRhc3RvcmUmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDt5cDpwZXJpb2Qm Z3Q7NTAwJmx0Oy95cDpwZXJpb2QmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgJmx0Oy9lc3RhYmxpc2gtc3Vic2NyaXB0aW9uJmd0OzxiciBjbGFzcz0i Ij4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0Oy9uZXRjb25mOnJwYyZndDs8YnIgY2xhc3M9IiI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IEZpZ3VyZSAzOiBFc3RhYmxpc2gtU3Vic2NyaXB0aW9uIGV4YW1wbGU8YnIgY2xhc3M9IiI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZu YnNwOyAmbmJzcDsgdGhlIHB1Ymxpc2hlciBtaWdodCByZXR1cm46PGJyIGNsYXNzPSIiPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZsdDtycGMtcmVwbHkgbWVzc2FnZS1pZD0mcXVv dDsxMDEmcXVvdDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgeG1sbnM9JnF1b3Q7dXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6 MS4wJnF1b3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5i c3A7ICZsdDtzdWJzY3JpcHRpb24tcmVzdWx0PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB4bWxucz0mcXVvdDt1cm46aWV0ZjpwYXJh bXM6eG1sOm5zOnlhbmc6aWV0Zi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMmcXVvdDs8YnIgY2xh c3M9IiI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHht bG5zOnlwPSZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLXlhbmctcHVzaCZx dW90OyZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgeXA6cGVyaW9kLXVuc3VwcG9ydGVkPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyZuYnNwOyAmbmJzcDsgJmx0Oy9zdWJzY3JpcHRpb24tcmVzdWx0Jmd0OzxiciBjbGFzcz0i Ij4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZsdDtwZXJpb2QtaGludCB4bWxu czomcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi15YW5nLXB1c2gmcXVvdDsm Z3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOzIwMDA8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbHQ7L3BlcmlvZC1oaW50Jmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmx0Oy9ycGMtcmVwbHkmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OzxiciBj bGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEZpZ3VyZSA0 OiBFcnJvciByZXNwb25zZSBleGFtcGxlPGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBCVFcsIGFsbCB0 aGUgZmlsdGVyIGV4YW1wbGVzIHNlZW0gdG8gYmUgd3JvbmcsIGluY2x1ZGluZyB0aGUgb25lPGJy IGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBhYm92ZTxiciBjbGFzcz0iIj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyIGNsYXNz PSIiPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBPTEQ6PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3lwOnN1YnRyZWUtZmlsdGVyIG5ldGNvbmY6dHlwZT0mcXVv dDt4cGF0aCZxdW90OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt4bWxuczpleD0mcXVvdDs8YSBo cmVmPSJodHRwOi8vZXhhbXBsZS5jb20vc2FtcGxlLWRhdGEvMS4wIiB0YXJnZXQ9Il9ibGFuayIg c3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9 IiI+aHR0cDovL2V4YW1wbGUuY29tL3NhbXBsZS1kYXRhLzEuMDwvYT4mcXVvdDs8YnIgY2xhc3M9 IiI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7c2VsZWN0PSZxdW90Oy9leDpmb28mcXVvdDsvJmd0OzxiciBjbGFzcz0i Ij4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBORVc6PGJyIGNsYXNzPSIiPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnIgY2xh c3M9IiI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyZsdDt5cDpzdWJ0cmVlLWZpbHRlciZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O2V4OmZv byB4bWxuczpleD0mcXVvdDs8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vc2FtcGxlLWRhdGEv MS4wIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlv bjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aHR0cDovL2V4YW1wbGUuY29tL3NhbXBsZS1kYXRhLzEu MDwvYT4mcXVvdDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IC8mZ3Q7PGJyIGNs YXNzPSIiPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy95cDpzdWJ0cmVlLWZp bHRlciZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OzxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQW5k eTxiciBjbGFzcz0iIj4NCiZndDsgJmd0OyAmZ3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyAmZ3Q7ICZn dDs8YnIgY2xhc3M9IiI+DQomZ3Q7ICZndDsgJmd0OzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRh bnQ7IiBjbGFzcz0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5O ZXRjb25mDQogbWFpbGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0 Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsg Zm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0 OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5OZXRjb25m QGlldGYub3JnPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRjb25mIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRl cmxpbmU7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXpl LWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C4707D28EAE245E8AAC8E05602A2A39Cciscocom_-- From nobody Wed Dec 6 09:26: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 E79B61275F4 for ; Wed, 6 Dec 2017 09:26:08 -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 KGJKmYc2znwh for ; Wed, 6 Dec 2017 09:26:06 -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 AEBF612717E for ; Wed, 6 Dec 2017 09:26: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 B0ACE673; Wed, 6 Dec 2017 18:26:03 +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 IUUPWHCchSnJ; Wed, 6 Dec 2017 18:26:02 +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, 6 Dec 2017 18:26:03 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9B8922012E; Wed, 6 Dec 2017 18:26:03 +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 Cg4NE48hwhLU; Wed, 6 Dec 2017 18:26:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A5D9C20129; Wed, 6 Dec 2017 18:26:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7E731418E37B; Wed, 6 Dec 2017 18:24:33 +0100 (CET) Date: Wed, 6 Dec 2017 18:24:33 +0100 From: Juergen Schoenwaelder To: "Einar Nilsen-Nygaard (einarnn)" Cc: Balazs Lengyel , Martin Bjorklund , "netconf@ietf.org" Message-ID: <20171206172433.aeysedjtcm3u7rf3@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Einar Nilsen-Nygaard (einarnn)" , Balazs Lengyel , Martin Bjorklund , "netconf@ietf.org" References: <20171128.103735.1654378548309425095.mbj@tail-f.com> <81f49c62-e1fe-4a90-a93f-c7fd55229100@ericsson.com> <20171206.100112.298803456348365967.mbj@tail-f.com> <4aacc669-5470-bef5-a3e7-fd9047c72562@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Netconf] "notifiable-on-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, 06 Dec 2017 17:26:09 -0000 It probably makes sense to write a document that defines how datastore content (or subsets of datastore content) in general can be stored in a file. With that in place, we know how to store ietf-yang-library content and as a side effect we know how to store datastore content used as examples for YANG data models and likely several other purposes. The root of the XML document would like be the datastore identity name in the YANG module namespace defining the identity Right now, it seems I have to feed instance data in slightly different formats into tools. It would be nice if tools could actually converge to common formats. [I am particularly interested in validations of examples.] /js On Wed, Dec 06, 2017 at 05:04:44PM +0000, Einar Nilsen-Nygaard (einarnn) wrote: > I agree with Balazs that we really want this issue to be nailed right form the start. > > I would be happy with defining an augmentation to ietf-yang-library to allow devices to return the data on what content is notifiable -on-change not this specific device at the specific time the data was retrieved. > > For offline consumption, we should define that an XML document conforming to the XML schema defined by ietf-yang-library + augmentations is an appropriate format. This XML document would have at its root the element ietf-yang-library:modules-state. How this XML document is provided is out of scope. It may be a flat file, it could come from a URL, whatever. > > Is this and acceptable approach? > > Cheers, > > Einar > > > > On 6 Dec 2017, at 10:32, Balazs Lengyel wrote: > > > > > > On 2017-12-06 10:01, Martin Bjorklund wrote: > >> Balazs Lengyel wrote: > >>> I very strongly object to excluding the issue. There is a strong and > >>> immediate need to be able to specify in vendor design time for which > >>> data nodes will there be on-change notification be generated. > >>> > >>> When a vendor release a product they know which nodes will emit > >>> on-change notifications in design time. System integrators need to > >>> know this. Providing the same information in run-time as instance data > >>> is not a good solution either as you would need to get a real node to > >>> read the data from. > >> The same argument applies to which YANG modules, features and > >> deviations a product supports. In SMIv2 we had AGENT-CAPABILITIES > >> which was an off-line document with this information. The experience > >> seems to be that it was rarely used by managers. In YANG we provide > >> this information on-line with the YANG library (and at least our > >> experience so far is that this *is* used by clients). > > BALAZS: I agree that yang-library is good. I am not arguing against it. Just it is > > not enough, because it is only available in run-time, too late. > >> It would probably be a good idea to combine these two approaches. > > BALAZS: I agree. Early documentation and on-line documentation > > combined would be a good solution. > > IMHO the 2 could use the same format. E.g. > > - Put all server-capabilities into yang-library (possibly augmenting it where needed) > > - define an off-line format for YANG Instance data > > e.g. the data section of a reply This way you don't even have to define a real new format > > - declare that off-line instance data from yanglib is the format to define server capabilities > >> > >> I think that this would be fairly straight-forward. As a first > >> approximation, suppose we had a standard file format for a > >> "server-capabilities" document. It could be something like this: > >> > >> > >> // this identifier must also be available on the device, so that > >> // a client can match the capability document with the device. > >> some unique identifier > >> > >> // meta-data goes here > >> ... > >> ... > >> ... > >> > >> > >> // the contents of yang-library from this product > >> // with modules, features, deviations > >> // ... and possibly on-change info > >> > >> > >> > >> Now, this won't be useful for all systems, for example if the server > >> is very dynamic and support dynamic loading of packages etc. > > BALAZS: I would put server-capabilities in 3 bags: > > 1) capabilities that change only at upgrade > > 2) capabilities that change rarely (e.g. due to licensing) > > 3) capabilities that change frequently (???) > > IMHO 1) covers 70% of the cases 2) covers 20% 3) is < 10%. > > Many network nodes only have type 1) or type 1+2) capabilities. > > So our main focus should be on stable capabilities > > > > -- > > 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 > > _______________________________________________ > 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 Dec 6 09:44: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 007FA1275FD for ; Wed, 6 Dec 2017 09:44:32 -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 butnLN4Ur2HN for ; Wed, 6 Dec 2017 09:44: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 8EC271272E1 for ; Wed, 6 Dec 2017 09:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56762; q=dns/txt; s=iport; t=1512582268; x=1513791868; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0PctohLLFmAsdWAmSdffjTXRR7We1H8QVxPb0e+0p88=; b=EioEofM5gfXU1TfdnVV2p3OySK/eaiqaL7dRMdqRzHWeKimIwhBh53gy 4IlNJZ8VmKn6tj8ZG8sXrLQsAGCkW2h3ufxtgkEy9RnbiAWVwTsF9HdwE uMG+UbiyNjusGdlCIFlp0CpQ7Q9GWQOxtLaRTIB7JZzVGVNa86Llz+vf8 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C6AAALKyha/5RdJa1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCSnNmbicHg3uKII58gX1+lgeCEgMKGAEKhElPAhqFOj8YAQE?= =?us-ascii?q?BAQEBAQEBayiFIgEBAQMBAQEYCQpBCwwEAgEIEQQBAQENEwEGAwICAiULFAkIA?= =?us-ascii?q?gQBDQUIEwSJIFwIEKkFgieKVAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2FXIFWgWm?= =?us-ascii?q?CdTaEdxQdBwkfAoJdgmMFij6JPI8DAod0jRqCH2OQYoo+gkOJJQIRGQGBOQEfO?= =?us-ascii?q?SaBKG8VOoIpCYRMeIclLIEFgRUBAQE?= X-IronPort-AV: E=Sophos; i="5.45,369,1508803200"; d="scan'208,217"; a="40600057" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2017 17:44:27 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id vB6HiQ5X032386 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Dec 2017 17:44:26 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, 6 Dec 2017 12:44: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, 6 Dec 2017 12:44:25 -0500 From: "Eric Voit (evoit)" To: "Einar Nilsen-Nygaard (einarnn)" , Alexander Clemm , Andy Bierman , "Martin Bjorklund" CC: "netconf@ietf.org" Thread-Topic: [Netconf] yang-push issue: error handling Thread-Index: AQHTaua8DOTUW5LGwkKD+sraYMgQfKMzfGKAgABIbICAAcFtgIAAAhuAgAAD2YCAAALjgIAAHUIAgAA904CAAP89gP//sx6g Date: Wed, 6 Dec 2017 17:44:25 +0000 Message-ID: <765779b15f1f4edc9b27891fb94b3f15@XCH-RTP-013.cisco.com> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD10E9@sjceml521-mbx.china.huawei.com> <20171205.212443.660483858000758249.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1165@sjceml521-mbx.china.huawei.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD12B7@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-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.244.103] Content-Type: multipart/alternative; boundary="_000_765779b15f1f4edc9b27891fb94b3f15XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] yang-push issue: error handling 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, 06 Dec 2017 17:44:32 -0000 --_000_765779b15f1f4edc9b27891fb94b3f15XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogRWluYXIgTmlsc2VuLU55Z2FhcmQsIERlY2VtYmVyIDYsIDIwMTcgMTI6MTUgUE0NCg0K dGw7ZHIg4oCUIEkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgY2xvc2UgdGhpcyBhbmQgdXNlIGEgeWFu Zy1kYXRhIGRlY2xhcmF0aW9uIHRvIGRlZmluZSB3aGF0IGdvZXMgaW50byB0aGUg4oCcZXJyb3It aW5mb+KAnS4gTGV04oCZcyBtYWtlIHByb2dyZXNzLg0KDQoNCkhvd2V2ZXIsIEkgYWxzbyBhZ3Jl ZSB3aXRoIEFsZXggdGhhdCB0aGUgc29sdXRpb24gcHJvcG9zZWQgaXMgY2x1bmt5LCBhbmQgSSBk b27igJl0IHRoaW5rIGl0IGFjdHVhbGx5IHByb21vdGVzIHN0YW5kYXJkaXNlZCBlcnJvciBoYW5k bGluZyBhcyB0aGUgY29uZGl0aW9ucyB3ZSBhcmUgZGVhbGluZyB3aXRoIGhlcmUgYXJlIGp1c3Qg bm90IGFzIHNpbXBsZSBhcyDigJxzb3JyeSwgaXQgZGlkbuKAmXQgd29ya+KAnS4gVGhlIFJQQyB3 aWxsIGhhdmUgd29ya2VkIGV4YWN0bHkgYXMgaW50ZW5kZWQsIGFuZCBtYXkgaGF2ZSBwcm92aWRl ZCB5b3Ugd2l0aCBpbmZvcm1hdGlvbiByZWxhdGluZyB0bywgZm9yIGV4YW1wbGUsIGhvdyB0byBj cmVhdGUgYSBzdWJzY3JpcHRpb24gcmVxdWVzdCB0aGF0IHdpbGwgd29yay4gSXQganVzdCB3b27i gJl0IG5lY2Vzc2FyaWx5IGhhdmUgZXN0YWJsaXNoZWQgdGhlIHN1YnNjcmlwdGlvbiBleGFjdGx5 IGFzIHlvdSB3YW50ZWQuIFRoZSBSUEMgaXRzZWxmIGV4ZWN1dGVkIGNvbXBsZXRlbHkgY29ycmVj dGx5LCBhbmQgdGh1cyDigJxycGMtZXJyb3LigJ0gc2VlbXMgbGlrZSBhbiBpbmNvcnJlY3QgcmVz cG9uc2UuIFdoYXQgd2UgYXJlIGRvaW5nIGhlcmUgaXMgc2ltcGx5IG5vdCB0aGUgc2FtZSBhcywg Zm9yIGV4YW1wbGUsIGFuIGVkaXQgY29uZmlnIHRoYXQgZmFpbGVkIGR1ZSB0byBpbnZhbGlkIGRh dGEgYW5kIGxlZnQgdGhlIHN5c3RlbSBjb25maWd1cmF0aW9uIHN0YXRlIHVuY2hhbmdlZC4NCg0K QnV0IGFueXdheSwgbGV04oCZcyBtYWtlIHByb2dyZXNzLiBNYWNoaW5lIHJlYWRhYmxlIGVycm9y LWluZm8gd2l0aCB5YW5nLWRhdGEgaXMgYSBzdGVwIGluIHRoZSByaWdodCBkaXJlY3Rpb24sIGJ1 dCBiZWNhdXNlIG9mIHRoYXQgc3RhbmRhcmRpc2VkIGVycm9yIGhhbmRsaW5nIGp1c3QgaXNu4oCZ dCBwbGF1c2libGUuIElmIHdl4oCZZCByZXNlcnZlZCDigJxycGMtZXJyb3LigJ0gZm9yIHRoaW5n cyB0aGF0IGp1c3QgZGlkbuKAmXQgd29yaywgdGhhdCB3b3VsZCBwcm92aWRlIGNsZWFuZXIgc2Vt YW50aWNzLg0KDQo8RXJpYz4gQWdyZWUuICBXZSBpbml0aWFsbHkgZGlkbuKAmXQgdXNlIGV4aXN0 aW5nIGVycm9yIGNvbnN0cnVjdHMgYmVjYXVzZSBtYW55IG9mIHRoZSBpbnRlcmFjdGlvbnMgYXJl IG5vdCBlcnJvcnMuICAgVG8gbWFrZSB0aGlzIGVhc2llciBmb3IgZXhpc3RpbmcgaW1wbGVtZW50 YXRpb25zIHRvIHN1cHBvcnQsIEkgYW0gZmluZSB3aXRoIHBpZ2d5YmFja2luZyBvbiB0aGUgY3Vy cmVudCBlcnJvciBjb25zdHJ1Y3RzIHRob3VnaC4NCg0KRXJpYw0KDQpDaGVlcnMsDQoNCkVpbmFy DQoNCg0KDQpPbiA2IERlYyAyMDE3LCBhdCAwMjowMSwgQWxleGFuZGVyIENsZW1tIDxhbGV4YW5k ZXIuY2xlbW1AaHVhd2VpLmNvbTxtYWlsdG86YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+PiB3 cm90ZToNCg0KSSBzdGlsbCBmaW5kIHRoaXMgYSBiaXQgY2x1bmt5IChhbmQgSSBzdGlsbCB3b25k ZXIgaWYgd2UgY291bGQgZGVmaW5lIOKAnGNvcm5lciBiZWhhdmlvcuKAnSBpbnN0ZWFkIG9mIGVy cm9yIGNvbmRpdGlvbnMpLCBidXQgT0ssIGxldOKAmXMgZ28gd2l0aCB0aGUgcHJvcG9zZWQgYXMg b3V0bGluZWQgYnkgTWFydGluLg0KDQpMZXTigJlzIGNsb3NlIHRoaXM7IHdlIHdpbGwgdXBkYXRl IHRoZSBSUENzIGFjY29yZGluZ2x5Lg0KDQpUaGFua3MNCi0tLSBBbGV4DQoNCkZyb206IEFuZHkg Qmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbV0NClNlbnQ6IFR1ZXNkYXksIERlY2Vt YmVyIDA1LCAyMDE3IDI6MjAgUE0NClRvOiBBbGV4YW5kZXIgQ2xlbW0gPGFsZXhhbmRlci5jbGVt bUBodWF3ZWkuY29tPG1haWx0bzphbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbT4+DQpDYzogTWFy dGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj47IG5l dGNvbmZAaWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW05l dGNvbmZdIHlhbmctcHVzaCBpc3N1ZTogZXJyb3IgaGFuZGxpbmcNCg0KSGksDQoNCkhlcmUgaXMg dGhlIHByb2JsZW0gd2l0aCB0aGUgWUFORyBQdXNoIGVycm9yIGhhbmRsaW5nLg0KVGhlIDxycGMt ZXJyb3I+IHJlc3BvbnNlIGlzIGEgTVVTVCwgbm90IGEgU0hPVUxEOg0KDQoNCjQuMy4gIDxycGMt ZXJyb3I+IEVsZW1lbnQNCg0KDQoNCiAgIFRoZSA8cnBjLWVycm9yPiBlbGVtZW50IGlzIHNlbnQg aW4gPHJwYy1yZXBseT4gbWVzc2FnZXMgaWYgYW4gZXJyb3INCg0KICAgb2NjdXJzIGR1cmluZyB0 aGUgcHJvY2Vzc2luZyBvZiBhbiA8cnBjPiByZXF1ZXN0Lg0KDQoNCg0KICAgSWYgYSBzZXJ2ZXIg ZW5jb3VudGVycyBtdWx0aXBsZSBlcnJvcnMgZHVyaW5nIHRoZSBwcm9jZXNzaW5nIG9mIGFuDQoN CiAgIDxycGM+IHJlcXVlc3QsIHRoZSA8cnBjLXJlcGx5PiBNQVkgY29udGFpbiBtdWx0aXBsZSA8 cnBjLWVycm9yPg0KDQogICBlbGVtZW50cy4gIEhvd2V2ZXIsIGEgc2VydmVyIGlzIG5vdCByZXF1 aXJlZCB0byBkZXRlY3Qgb3IgcmVwb3J0IG1vcmUNCg0KICAgdGhhbiBvbmUgPHJwYy1lcnJvcj4g ZWxlbWVudCwgaWYgYSByZXF1ZXN0IGNvbnRhaW5zIG11bHRpcGxlIGVycm9ycy4NCg0KICAgQSBz ZXJ2ZXIgaXMgbm90IHJlcXVpcmVkIHRvIGNoZWNrIGZvciBwYXJ0aWN1bGFyIGVycm9yIGNvbmRp dGlvbnMgaW4NCg0KICAgYSBzcGVjaWZpYyBzZXF1ZW5jZS4gIEEgc2VydmVyIE1VU1QgcmV0dXJu IGFuIDxycGMtZXJyb3I+IGVsZW1lbnQgaWYNCg0KICAgYW55IGVycm9yIGNvbmRpdGlvbnMgb2Nj dXIgZHVyaW5nIHByb2Nlc3NpbmcuDQoNCg0KDQoNCg0KQW5keQ0KDQoNCg0KT24gVHVlLCBEZWMg NSwgMjAxNyBhdCAxMjozNSBQTSwgQWxleGFuZGVyIENsZW1tIDxhbGV4YW5kZXIuY2xlbW1AaHVh d2VpLmNvbTxtYWlsdG86YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIE1h cnRpbiwNCg0KU3VyZSwgdGhlIGV2ZW50dWFsIHNvbHV0aW9uIG1heSBtYWtlIHVzZSBvZiBycGMt ZXJyb3IgYWdhaW4uICBCdXQgdW50aWwgd2UgZ2V0IHRoZXJlLCB0aGUgY3VycmVudGx5IHByb3Bv c2VkIHNvbHV0aW9uIHNlZW1zIHRvIG1ha2Ugc2Vuc2UgdG8gbWUuICBJIGRvbid0IHRoaW5rIHdl IGhhdmUgYW4gaXNzdWUgdG9kYXkgd2l0aCBsb3RzIG9mIFJQQ3MgZWFjaCBkZWZpbmluZyB0aGVp ciBvd24gd2F5IG9mIGRlYWxpbmcgd2l0aCBjb3JuZXIgY29uZGl0aW9ucyAtIGRlZmluaXRpb24g b2YgUlBDcyBpcyBzb21ldGhpbmcgdGhhdCBoYXMgc28gZmFyIG9ubHkgcmFyZWx5IGJlZW4gZXhl cmNpc2VkIHdpdGggWUFORyBtb2RlbHMuICBPbmNlIHRoaXMgYmVjb21lcyBtb3JlIGNvbW1vbiwg SSBhbSBzdXJlIHdlIHdpbGwgZmluZCBhIG1vcmUgZ2VuZXJhbCBzb2x1dGlvbiwgYnV0IEkgZG9u J3QgdGhpbmsgd2UgYXJlIGF0IHRoYXQgcG9pbnQuDQoNCi0tLSBBbGV4DQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFydGluIEJqb3JrbHVuZCBbbWFpbHRvOm1iakB0 YWlsLWYuY29tPG1haWx0bzptYmpAdGFpbC1mLmNvbT5dDQo+IFNlbnQ6IFR1ZXNkYXksIERlY2Vt YmVyIDA1LCAyMDE3IDEyOjI1IFBNDQo+IFRvOiBhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFu ZHlAeXVtYXdvcmtzLmNvbT4NCj4gQ2M6IEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1t QGh1YXdlaS5jb208bWFpbHRvOmFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPj47IG5ldGNvbmZA aWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbTmV0Y29u Zl0geWFuZy1wdXNoIGlzc3VlOiBlcnJvciBoYW5kbGluZw0KPg0KPiBBbmR5IEJpZXJtYW4gPGFu ZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPj4gd3JvdGU6DQo+ID4g SGksDQo+ID4NCj4gPiBUaGUgcHJvdG9jb2wgZGVmaW5lcyBob3cgZXJyb3IgaGFuZGxpbmcgaXMg ZG9uZSwgbm90IHRoZSBpbmRpdmlkdWFsDQo+ID4gb3BlcmF0aW9ucy4NCj4gPiBJZiB0aGUgcmVx dWVzdCBmYWlscywgdGhlbiBjbGllbnRzIGV4cGVjdCBhbiA8cnBjLWVycm9yPiBhbmQgc2VydmVy cw0KPiA+IGFyZSBkZXNpZ25lZCB0byBzZW5kIGFuIDxycGMtZXJyb3I+IHdoZW4gYSBjbGllbnQg cmVxdWVzdCBmYWlscy4NCj4NCj4gQWdyZWVkLCBhbmQgZm9yIFJFU1RDT05GLCB0aGUgSFRUUCBl cnJvciBjb2RlcyBhcmUgdXNlZC4gIEFuIEhUVFAgcmVxdWVzdA0KPiB0aGF0IGZhaWxzIGRvZXMg bm90IHJldHVybiAyMDAgb2sgd2l0aCBhIGJvZHkgdGhhdCBleHBsYWlucyB0aGF0IGl0IGFjdHVh bGx5IHdhcw0KPiBhbiBlcnJvci4NCj4NCj4gPiBJTU8sIGEgc2VwYXJhdGUgZXJyb3IgaGFuZGxp bmcgcHJvY2VkdXJlIGZvciBlYWNoIFJQQyBpcyBtb3JlIGNsdW5reQ0KPiA+IHRoYW4gZXJyb3It aW5mby4NCj4NCj4gKzENCj4NCj4gU29tZSBhZGRpdGlvbmFsIGNvbW1lbnRzIGlubGluZS4NCj4N Cj4NCj4gPiA+IFdoaWxlIHBvc3NpYmxlLCB0aGUgc29sdXRpb24gb2YgaGF2aW5nIHRvIHJldHVy biBycGMtZXJyb3IgZXRjIGRvZXMNCj4gPiA+IHN0cmlrZSBtZSBhcyBzb21ld2hhdCBjbHVua3ku ICBXaGlsZSBpdCBpcyBwb3NzaWJsZSB0byBhZGQgYW4NCj4gPiA+IGVycm9yLWFwcC10YWcsIGFu ZCBuZWdvdGlhdGlvbiBzdHVmZiBhcyBlcnJvci1pbmZvIChhbmQgSSBhcHByZWNpYXRlDQo+ID4g PiB0aGUgc3VnZ2VzdGlvbiksIHRoYXQgc29sdXRpb24gd291bGQgbmVlZCB0byBiZSBkZXNjcmli ZWQgdXNpbmcgYQ0KPiA+ID4gbG90IG9mIHByb3NlIGluIGRlc2NyaXB0aW9uIHN0YXRlbWVudHMg YSBsYSBTTUl2MiAocHJlc3VtYWJseSBhcw0KPiA+ID4gcGFydCBvZiB0aGUgUlBDIGRlc2NyaXB0 aW9uLCBub3QgYXMgcGFydCBvZiBlLmcuIHRoZSBpZGVudGl0aWVzLA0KPiA+ID4gd2hpY2ggbWln aHQgYmUgdXNlZCBpbiBhIG51bWJlciBvZiBwbGFjZXMsIG5vdCBqdXN0IHRoZSBlcnJvci1hcHAt dGFnKS4NCj4NCj4gSWYgYm90aCB0aGUgZXJyb3IgY29kZSBhbmQgaGludCBpcyBkZWZpbmVkIGlu IGEgeWFuZy1kYXRhIChpLmUuLCBub3QgdXNpbmcgdGhlDQo+IGVycm9yLWFwcC10YWcpLCB5b3Ug d291bGQgZG86DQo+DQo+ICAgeXg6eWFuZy1kYXRhIHN1YnNjcmlwdGlvbi1lcnJvciB7DQo+ICAg ICBjb250YWluZXIgc3Vic2NyaXB0aW9uLWVycm9yIHsNCj4gICAgICAgbGVhZiBlcnJvci1jb2Rl IHsNCj4gICAgICAgICB0eXBlIGlkZW50aXR5IHsNCj4gICAgICAgICAgIGJhc2UgZXJyb3I7DQo+ ICAgICAgICAgfQ0KPiAgICAgICB9DQo+ICAgICAgIGNvbnRhaW5lciBoaW50cyB7IC4uLiB9DQo+ ICAgICB9DQo+ICAgfQ0KPg0KPiBUaGVuIHlvdSBhcmUgcmlnaHQsIHlvdSBoYXZlIHRvIGRlc2Ny aWJlIGluIHByb3NlIHRoYXQgdGhpcyB5YW5nLWRhdGENCj4gc3RydWN0dXJlIGNhbiBiZSBzZW50 IGFzIGVycm9yLWluZm8uDQo+DQo+DQo+ID4gPiBJIGFtIG5vdCBzdXJlIHdoeSB0aGF0IHdvdWxk IG1ha2UgYW4gUlBDIGFueSBlYXNpZXIgdG8gaW1wbGVtZW50Lg0KPiA+ID4gVGhlIHNhbWUgY2hl Y2tzIHN0aWxsIGhhdmUgdG8gYmUgbWFkZS4NCj4NCj4gQWdyZWVkLg0KPg0KPiA+ID4gV2h5IHdv dWxkIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBub3QgYWNjZXB0YWJsZT8gICBJZGVhbGx5IFlBTkcg d291bGQNCj4gPiA+IHByb3ZpZGUgYmV0dGVyIHN1cHBvcnQgdG8gZm9ybWFsbHkgZGVmaW5lIGFw cGxpY2F0aW9uL1JQQy1zcGVjaWZpYw0KPiA+ID4gcmV0dXJuIGNvZGVzIGFuZCBjb3JuZXIgY29u ZGl0aW9ucyBldGMuDQo+DQo+IEFsc28gYWdyZWVkLiAgQnV0IG9uY2Ugd2UgaGF2ZSB0aGF0LCBz dWNoIGEgc29sdXRpb24gd291bGQgbWFrZSB1c2Ugb2YgdGhlDQo+IHJwYy1lcnJvciB3ZSBoYXZl IChmb3IgYm90aCBORVRDT05GIGFuZCBSRVNUQ09ORikuDQo+DQo+DQo+IC9tYXJ0aW4NCj4NCj4N Cj4gPiA+IFNob3J0IG9mIHRoYXQsIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBvZiBhZGRpbmcgUlBD IG91dHB1dCBwYXJhbWV0ZXJzDQo+ID4gPiB0aGF0IGFyZSB1c2VkIGZvciB0aGUgcHVycG9zZSBv ZiBpbmRpY2F0aW5nIHdoYXQgaXMgZ29pbmcgb24gYXQgdGhlDQo+ID4gPiBhcHBsaWNhdGlvbiBs ZXZlbCBzaW1wbHkgbWFrZXMgdGhlbSBwYXJ0IG9mIHRoZSBzZW1hbnRpY3Mgb2YgdGhlDQo+ID4g PiBzcGVjaWZpYyBSUEMgaXRzZWxmLiAgSXQgaXMgbm90IE5ldGNvbmbigJlzIHJvbGUgdG8gZGVm aW5lIHdoYXQgYW4gUlBDDQo+ID4gPiBjYW4gb3IgY2Fubm90IGRvLCBqdXN0IGxpa2UgaXQgY2Fu bm90IGRlZmluZSB3aGF0IGEgcGFydGljdWxhciBsZWFmDQo+ID4gPiBtYXkgb3IgbWF5IG5vdCBy ZXByZXNlbnQuICBUaGF0IGlzIHBhcnQgb2YgdGhlIFJQQyBkZWZpbml0aW9uLg0KPiA+ID4NCj4g PiA+DQo+ID4gPg0KPiA+ID4gQmFzaWNhbGx5LCB3aGF0IHdlIGFyZSBkaXNjdXNzaW5nIGhlcmUg aXMgYmVoYXZpb3Igb2Ygc3Vic2NyaXB0aW9uDQo+ID4gPiBjb25maWd1cmF0aW9uIHVuZGVyIGNv cm5lciBjb25kaXRpb25zLiAgVGhlIGZhY3QgdGhhdCBubw0KPiA+ID4gc3Vic2NyaXB0aW9uIGlz IGNyZWF0ZWQgYmVjYXVzZSBpdCB3b3VsZCByZXN1bHQgaW4gYW4gdW5hY2NlcHRhYmxlDQo+ID4g PiB2b2x1bWUgb2YgdXBkYXRlcyBmb3IgYSBzcGVjaWZpYyBpbXBsZW1lbnRhdGlvbiBpcyBkaWZm ZXJlbnQgZnJvbSBhbg0KPiA+ID4gZXJyb3IgY29uZGl0aW9uIHN1Y2ggYXMgYSBtYWxmb3JtZWQg bWVzc2FnZSB0aGF0IGlzIG1pc3NpbmcgYQ0KPiA+ID4gcmVxdWlyZWQgbWVzc2FnZS1pZCwgb3Ig d2hlcmUgYSB2YWx1ZSB2aW9sYXRlcyBhIGNvbnN0cmFpbnQNCj4gPiA+IHNwZWNpZmllZCBpbiBh IE1VU1QtY29uZGl0aW9uLiAgSW4gb3VyIGNhc2UsIHdoYXQgaXMgYmVpbmcgZGVzY3JpYmVkIGFy ZQ0KPiBzcGVjaWZpYyBjb25kaXRpb25zIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciwgYWJvdmUg dGhlDQo+ID4gPiBOZXRjb25mL1Jlc3Rjb25mIGdlbmVyaWMgdmFsaWRhdGlvbiBpbmZyYXN0cnVj dHVyZS4gICBUaGUgb3BlcmF0aW9uIGRvZXMNCj4gPiA+IG5vdCDigJx3b3Jr4oCdIGluIHRoZSBz ZW5zZSB0aGF0IGl0IGRvZXMgbm90IHJlc3VsdCBpbiBhbiBhY3RpdmUNCj4gPiA+IHN1YnNjcmlw dGlvbiwgYnV0IGl0IGRvZXMgd29yayBpbiB0aGUgc2Vuc2UgdGhhdCB0aGUgYmVoYXZpb3IgaXMN Cj4gPiA+IHZlcnkgd2VsbCBkZWZpbmVkIGluIHRlcm1zIG9mIHRoZSBlZmZlY3QgdGhhdCB0aGUg UlBDIGhhcyAoaS5lLiB0aGUNCj4gPiA+IGVmZmVjdCBpcyB0aGF0IGl0IHJlc3VsdCBpbiBjcmVh dGlvbiBvZiBhIHN1YnNjcmlwdGlvbiwgaWYgY2VydGFpbg0KPiA+ID4gY29uZGl0aW9ucyBhcmUg bWV0LCBhbmQgaXQgZG9lcyBub3QgcmVzdWx0IGluIGNyZWF0aW9uIG9mIGENCj4gPiA+IHN1YnNj cmlwdGlvbiBpbiBjYXNlIGNlcnRhaW4gY29uZGl0aW9ucyBhcmUgbm90IG1ldCkuICBXaHkgc2hv dWxkDQo+ID4gPiBOZXRjb25mIHJlc3RyaWN0IHdoYXQgYW4gUlBDIGNhbiBvciBjYW5ub3QgZG8/ ICBUaGlzIGlzIGFsbCBhcHBsaWNhdGlvbi0NCj4gc3BlY2lmaWMuDQo+ID4gPg0KPiA+ID4NCj4g PiA+DQo+ID4gPiAtLS0gQWxleA0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ ID4gPiAqRnJvbToqIE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz5dICpPbiBCZWhhbGYgT2YNCj4gPiA+ICpBbmR5 IEJpZXJtYW4NCj4gPiA+ICpTZW50OiogTW9uZGF5LCBEZWNlbWJlciAwNCwgMjAxNyA5OjE1IEFN DQo+ID4gPiAqVG86KiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJq QHRhaWwtZi5jb20+Pg0KPiA+ID4gKkNjOiogTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9yZzxtYWls dG86bmV0Y29uZkBpZXRmLm9yZz4+DQo+ID4gPiAqU3ViamVjdDoqIFJlOiBbTmV0Y29uZl0geWFu Zy1wdXNoIGlzc3VlOiBlcnJvciBoYW5kbGluZw0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4N Cj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IE9uIE1vbiwgRGVjIDQsIDIwMTcgYXQgNDo1NSBB TSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29t Pj4NCj4gd3JvdGU6DQo+ID4gPg0KPiA+ID4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5j b208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+IHdyb3RlOg0KPiA+ID4gPiBIaSwNCj4gPiA+ ID4NCj4gPiA+ID4gSU1PIHRoZSBzcGVjaWFsIGVycm9yIGhhbmRsaW5nIGluIFlBTkcgUHVzaCBp cyBub3QgYWNjZXB0YWJsZQ0KPiA+ID4gPiBiZWNhdXNlIGl0IHZpb2xhdGVzIE5FVENPTkYgYW5k IFJFU1RDT05GIGVycm9yIGhhbmRsaW5nIHByb2NlZHVyZXMuDQo+ID4gPiA+IE5FVENPTkYgc2F5 cyBpZiB0aGUgb3BlcmF0aW9uIGRvZXMgbm90IHdvcmsgZm9yIGFueSByZWFzb24gYW4NCj4gPiA+ ID4gPHJwYy1lcnJvcj4gZWxlbWVudCBTSE9VTEQgYmUgcmV0dXJuZWQuDQo+ID4gPg0KPiA+ID4g SSBmdWxseSBhZ3JlZSwgYW5kIEkgaGF2ZSBwb2ludGVkIHRoaXMgb3V0IHNldmVyYWwgdGltZXMg aW4gbXkNCj4gPiA+IHJldmlld3MuICBUaGUgcHJvYmxlbSBpcyBhY3R1YWxseSBpbiBzdWJzY3Jp YmVkIG5vdGlmaWNhdGlvbnMsIGFuZCBJDQo+ID4gPiB0aGluayBFcmljIGlzIHRyYWNraW5nIHRo YXQgaXNzdWUuDQo+ID4gPg0KPiA+ID4gVHJ5aW5nIHRvIGJlIGNvbnN0cnVjdGl2ZSwgSSB0aGlu ayB0aGF0IHRoZSBleGlzdGluZyBtZWNoYW5pc21zIGluDQo+ID4gPiBZQU5HIGNhbiBiZSB1c2Vk IHRvIGFjaGlldmUgdGhlIHNhbWUgZnVuY3Rpb25hbGl0eSB0aGF0IHRoZXNlIGRyYWZ0cw0KPiA+ ID4gdHJ5IHRvIGFjaGlldmUuICBTcGVjaWZpY2FsbHk6DQo+ID4gPg0KPiA+ID4gICAxLiBVc2Ug aWRlbnRpdGllcyBqdXN0IGxpa2UgdGhlIG9uZXMgeW91IGhhdmUNCj4gPiA+ICAgICAgKCJ1bnN1 cHBvcnRhYmxlLXZvbHVtZSIsICJmaWx0ZXItdW5hdmFpbGFibGUiIGV0YyksIGJ1dCBhZGQgdGV4 dA0KPiA+ID4gICAgICB0aGF0IGV4cGxhaW5zIHRoYXQgdGhlc2UgaWRlbnRpdGllcyBhcmUgc2Vu dCBhcyAiZXJyb3ItYXBwLXRhZyINCj4gPiA+ICAgICAgaW4gInJwYy1lcnJvciIsIGVuY29kZWQg dG8gYSBzdHJpbmcgYXMgPG1vZHVsZT46PGlkZW50aXR5Pi4gIFRoaXMNCj4gPiA+ICAgICAgd29y a3MgZm9yIGJvdGggTkVUQ09ORiBhbmQgUkVTVENPTkYuDQo+ID4gPg0KPiA+ID4gICAyLiBGb3Ig dGhlICJoaW50cyIgZXh0cmEgaW5mbyB0aGF0IHlvdSByZXR1cm4sIGRlZmluZSBhICJ5YW5nLWRh dGEiDQo+ID4gPiAgICAgIHN0cnVjdHVyZSB3aXRoIHRoZSBoaW50cywgYW5kIGV4cGxhaW4gaW4g dGV4dCB0aGF0IHRoaXMgc3RydWN0dXJlDQo+ID4gPiAgICAgIGlzIHJldHVybmVkIGluICJlcnJv ci1pbmZvIi4gIFRoaXMgd29ya3MgZm9yIGJvdGggTkVUQ09ORiBhbmQNCj4gPiA+ICAgICAgUkVT VENPTkYuDQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+ICsxDQo+ID4g Pg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBJZiB0aGUgZXJyb3IgaGFuZGxpbmcgd2FzIGRvbmUgY29y cmVjdGx5IHRoZW4gdGhlIHNhbWUgcHJvY2VkdXJlcw0KPiA+ID4gY291bGQgYmUNCj4gPiA+DQo+ ID4gPiBhcHBsaWVkIHRvIDxlZGl0LWNvbmZpZz4gZmFpbHVyZXMgZm9yIGNvbmZpZ3VyZWQgc3Vi c2NyaXB0aW9ucy4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4g PiA+IEFzIGFuIGFsdGVybmF0aXZlIHRvIDEsIHlvdSBjYW4gcHV0IHRoZSBlcnJvciBpZGVudGl0 aXlyZWYgaW4gdGhlDQo+ID4gPiAieWFuZy1kYXRhIiBzdHJ1Y3R1cmUsIGFuZCBzZW5kIGJvdGgg dGhlIGlkZW50aXRpeXJlZiBhbmQgaGludHMgaW4NCj4gPiA+ICJlcnJvci1pbmZvIi4NCj4gPiA+ DQo+ID4gPg0KPiA+ID4gL21hcnRpbg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+ DQo+ID4gPiBBbmR5DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ ID4gPiA+IFRoZSA8ZXN0YWJsaXNoLXN1YnNjcmlwdGlvbj4gcmV0dXJucyBkYXRhIGV2ZW4gb24g ZXJyb3IuDQo+ID4gPiA+IEluc3RlYWQgb2YgdGhlIGNvbW1vbiBlcnJvci10YWcsIGVycm9yLWlu Zm8sIGFuZCBvdGhlciBmaWVsZHMsDQo+ID4gPiA+IHRoZXJlIGlzIGEgc3Vic2NyaXB0aW9uLXJl c3VsdCBsZWFmLg0KPiA+ID4gPg0KPiA+ID4gPiBJZiBhbnkgY2xpZW50IChvciBldmVuIHNlcnZl cikgZnVuY3Rpb25hbGl0eSB1c2VzIHRoZSBORVRDT05GIGFuZA0KPiA+ID4gPiBSRVNUQ09ORiBz dGFuZGFyZCBlcnJvciBoYW5kbGluZywgdGhlbiBzdWJzY3JpcHRpb24tcmVzdWx0IHdpbGwNCj4g PiA+ID4gbm90IGJlIHNlbnQgb3IgZXhwZWN0ZWQgYXMgYW4gZXJyb3IgcmVzcG9uc2UuIERlcGVu ZGluZyBvbiB0aGUNCj4gPiA+ID4gc2VydmVyIGltcGxlbWVudGF0aW9uLCB0aGUgY29kZSB0aGF0 IGtub3dzIGFib3V0DQo+ID4gPiA+IGVzdGFibGlzaC1zdWJzY3JpcHRpb24gbWF5IG5vdCBnZXQg Y2FsbGVkIGJlY2F1c2UgY29tbW9uIGVycm9yDQo+ID4gPiA+IGhhbmRsaW5nIGNvZGUgaGFzIGFs cmVhZHkgZGV0ZXJtaW5lZCB0aGVyZSBpcyBhbiA8cnBjLWVycm9yPiB0bw0KPiA+ID4gPiBzZW5k IGluc3RlYWQgb2YgYSBkYXRhIHJlc3BvbnNlLg0KPiA+ID4gPg0KPiA+ID4gPiBFeHBlY3QgdGhh dCBzb21lIHNlcnZlcnMgYXJlIG5ldmVyIGdvaW5nIHRvIHNlbmQgZGF0YSBvbiBhbg0KPiA+ID4g PiBvcGVyYXRpb24gZmFpbHVyZSwgYW5kIHdpbGwgb25seSBzZW5kIDxycGMtZXJyb3I+IGluc3Rl YWQuDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ID5Gcm9tIHNlYy4gMy44Og0KPiA+ID4gPg0K PiA+ID4gPiAgICBGb3IgaW5zdGFuY2UsIGZvciB0aGUgZm9sbG93aW5nIHJlcXVlc3Q6DQo+ID4g PiA+DQo+ID4gPiA+IDxuZXRjb25mOnJwYyBtZXNzYWdlLWlkPSIxMDEiDQo+ID4gPiA+ICAgIHht bG5zOm5ldGNvbmY9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQo+ ID4gPiA+ICAgIDxlc3RhYmxpc2gtc3Vic2NyaXB0aW9uDQo+ID4gPiA+ICAgICAgICB4bWxucz0i dXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25z Ig0KPiA+ID4gPiAgICAgICAgeG1sbnM6eXA9InVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzpp ZXRmLXlhbmctcHVzaCI+DQo+ID4gPiA+ICAgICAgIDx5cDpkYXRhc3RvcmU+DQo+ID4gPiA+ICAg ICAgICAgPHlwOnNvdXJjZSB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYt ZGF0YXN0b3JlcyI+DQo+ID4gPiA+ICAgICAgICAgICBvcGVyYXRpb25hbA0KPiA+ID4gPiAgICAg ICAgIDwveXA6c291cmNlPg0KPiA+ID4gPiAgICAgICAgIDx5cDpzdWJ0cmVlLWZpbHRlciBuZXRj b25mOnR5cGU9InhwYXRoIg0KPiA+ID4gPiAgICAgICAgICAgICB4bWxuczpleD0iaHR0cDovL2V4 YW1wbGUuY29tL3NhbXBsZS1kYXRhLzEuMCINCj4gPiA+ID4gICAgICAgICAgICAgc2VsZWN0PSIv ZXg6Zm9vIi8+DQo+ID4gPiA+ICAgICAgIDwveXA6ZGF0YXN0b3JlPg0KPiA+ID4gPiAgICAgICA8 eXA6cGVyaW9kPjUwMDwveXA6cGVyaW9kPg0KPiA+ID4gPiAgICA8L2VzdGFibGlzaC1zdWJzY3Jp cHRpb24+DQo+ID4gPiA+IDwvbmV0Y29uZjpycGM+DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAg ICAgICAgICAgRmlndXJlIDM6IEVzdGFibGlzaC1TdWJzY3JpcHRpb24gZXhhbXBsZQ0KPiA+ID4g Pg0KPiA+ID4gPiAgICB0aGUgcHVibGlzaGVyIG1pZ2h0IHJldHVybjoNCj4gPiA+ID4NCj4gPiA+ ID4NCj4gPiA+ID4gPHJwYy1yZXBseSBtZXNzYWdlLWlkPSIxMDEiDQo+ID4gPiA+ICAgICAgeG1s bnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQo+ID4gPiA+ICAg IDxzdWJzY3JpcHRpb24tcmVzdWx0DQo+ID4gPiA+ICAgICAgICB4bWxucz0idXJuOmlldGY6cGFy YW1zOnhtbDpuczp5YW5nOmlldGYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIg0KPiA+ID4gPiAg ICAgICAgeG1sbnM6eXA9InVybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLXlhbmctcHVz aCI+DQo+ID4gPiA+ICAgICAgeXA6cGVyaW9kLXVuc3VwcG9ydGVkDQo+ID4gPiA+ICAgIDwvc3Vi c2NyaXB0aW9uLXJlc3VsdD4NCj4gPiA+ID4gICAgPHBlcmlvZC1oaW50IHhtbG5zOiJ1cm46aWV0 ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi15YW5nLXB1c2giPg0KPiA+ID4gPiAgICAgICAyMDAw DQo+ID4gPiA+ICAgIDwvcGVyaW9kLWhpbnQ+DQo+ID4gPiA+IDwvcnBjLXJlcGx5Pg0KPiA+ID4g Pg0KPiA+ID4gPiAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgNDogRXJyb3IgcmVzcG9uc2Ug ZXhhbXBsZQ0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBCVFcsIGFsbCB0aGUg ZmlsdGVyIGV4YW1wbGVzIHNlZW0gdG8gYmUgd3JvbmcsIGluY2x1ZGluZyB0aGUgb25lDQo+ID4g PiA+IGFib3ZlDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IE9MRDoNCj4gPiA+ID4NCj4gPiA+ ID4gICAgICAgICA8eXA6c3VidHJlZS1maWx0ZXIgbmV0Y29uZjp0eXBlPSJ4cGF0aCINCj4gPiA+ ID4gICAgICAgICAgICAgeG1sbnM6ZXg9Imh0dHA6Ly9leGFtcGxlLmNvbS9zYW1wbGUtZGF0YS8x LjAiDQo+ID4gPiA+ICAgICAgICAgICAgIHNlbGVjdD0iL2V4OmZvbyIvPg0KPiA+ID4gPg0KPiA+ ID4gPg0KPiA+ID4gPiBORVc6DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ICAgICAgICAgPHlw OnN1YnRyZWUtZmlsdGVyPg0KPiA+ID4gPiAgICAgICAgICAgIDxleDpmb28geG1sbnM6ZXg9Imh0 dHA6Ly9leGFtcGxlLmNvbS9zYW1wbGUtZGF0YS8xLjAiDQo+ID4gPiA+IC8+DQo+ID4gPiA+DQo+ ID4gPiA+ICAgICAgICAgPC95cDpzdWJ0cmVlLWZpbHRlcj4NCj4gPiA+ID4NCj4gPiA+ID4NCj4g PiA+ID4gQW5keQ0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZA aWV0Zi5vcmc8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0K --_000_765779b15f1f4edc9b27891fb94b3f15XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNv bnZlcnRlZC1zcGFjZTt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xh czt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBFaW5hciBOaWxzZW4tTnlnYWFyZCwgRGVjZW1iZXIgNiwgMjAxNyAxMjoxNSBQTTxicj4N Cjxicj4NCjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGw7ZHIg4oCU IEkgYWdyZWUgdGhhdCB3ZSBzaG91bGQgY2xvc2UgdGhpcyBhbmQgdXNlIGEgeWFuZy1kYXRhIGRl Y2xhcmF0aW9uIHRvIGRlZmluZSB3aGF0IGdvZXMgaW50byB0aGUg4oCcZXJyb3ItaW5mb+KAnS4g TGV04oCZcyBtYWtlIHByb2dyZXNzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIEkgYWxzbyBhZ3JlZSB3aXRoIEFsZXggdGhh dCB0aGUgc29sdXRpb24gcHJvcG9zZWQgaXMgY2x1bmt5LCBhbmQgSSBkb27igJl0IHRoaW5rIGl0 IGFjdHVhbGx5IHByb21vdGVzIHN0YW5kYXJkaXNlZCBlcnJvciBoYW5kbGluZyBhcyB0aGUgY29u ZGl0aW9ucyB3ZSBhcmUgZGVhbGluZyB3aXRoIGhlcmUgYXJlIGp1c3Qgbm90IGFzIHNpbXBsZSBh cyDigJxzb3JyeSwgaXQgZGlkbuKAmXQgd29ya+KAnS4gVGhlIFJQQw0KIHdpbGwgaGF2ZSB3b3Jr ZWQgZXhhY3RseSBhcyBpbnRlbmRlZCwgYW5kIG1heSBoYXZlIHByb3ZpZGVkIHlvdSB3aXRoIGlu Zm9ybWF0aW9uIHJlbGF0aW5nIHRvLCBmb3IgZXhhbXBsZSwgaG93IHRvIGNyZWF0ZSBhIHN1YnNj cmlwdGlvbiByZXF1ZXN0IHRoYXQgd2lsbCB3b3JrLiBJdCBqdXN0IHdvbuKAmXQgbmVjZXNzYXJp bHkgaGF2ZSBlc3RhYmxpc2hlZCB0aGUgc3Vic2NyaXB0aW9uDQo8Yj5leGFjdGx5PC9iPiZuYnNw O2FzIHlvdSB3YW50ZWQuIFRoZSBSUEMgaXRzZWxmIGV4ZWN1dGVkIGNvbXBsZXRlbHkgY29ycmVj dGx5LCBhbmQgdGh1cyDigJxycGMtZXJyb3LigJ0gc2VlbXMgbGlrZSBhbiBpbmNvcnJlY3QgcmVz cG9uc2UuIFdoYXQgd2UgYXJlIGRvaW5nIGhlcmUgaXMgc2ltcGx5IG5vdCB0aGUgc2FtZSBhcywg Zm9yIGV4YW1wbGUsIGFuIGVkaXQgY29uZmlnIHRoYXQgZmFpbGVkIGR1ZSB0byBpbnZhbGlkIGRh dGEgYW5kIGxlZnQgdGhlIHN5c3RlbQ0KIGNvbmZpZ3VyYXRpb24gc3RhdGUgdW5jaGFuZ2VkLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQg YW55d2F5LCBsZXTigJlzIG1ha2UgcHJvZ3Jlc3MuIE1hY2hpbmUgcmVhZGFibGUgZXJyb3ItaW5m byB3aXRoIHlhbmctZGF0YSBpcyBhIHN0ZXAgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbiwgYnV0IGJl Y2F1c2Ugb2YgdGhhdCBzdGFuZGFyZGlzZWQgZXJyb3IgaGFuZGxpbmcganVzdCBpc27igJl0IHBs YXVzaWJsZS4gSWYgd2XigJlkIHJlc2VydmVkIOKAnHJwYy1lcnJvcuKAnSBmb3IgdGhpbmdzIHRo YXQganVzdCBkaWRu4oCZdA0KIHdvcmssIHRoYXQgd291bGQgcHJvdmlkZSBjbGVhbmVyIHNlbWFu dGljcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmx0O0VyaWMmZ3Q7IEFn cmVlLiZuYnNwOyBXZSBpbml0aWFsbHkgZGlkbuKAmXQgdXNlIGV4aXN0aW5nIGVycm9yIGNvbnN0 cnVjdHMgYmVjYXVzZSBtYW55IG9mIHRoZSBpbnRlcmFjdGlvbnMgYXJlIG5vdCBlcnJvcnMuJm5i c3A7Jm5ic3A7IFRvIG1ha2UgdGhpcyBlYXNpZXIgZm9yIGV4aXN0aW5nIGltcGxlbWVudGF0aW9u cw0KIHRvIHN1cHBvcnQsIEkgYW0gZmluZSB3aXRoIHBpZ2d5YmFja2luZyBvbiB0aGUgY3VycmVu dCBlcnJvciBjb25zdHJ1Y3RzIHRob3VnaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PGJyPg0KRXJpYzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RWluYXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDYgRGVjIDIwMTcsIGF0IDAyOjAxLCBBbGV4 YW5kZXIgQ2xlbW0gJmx0OzxhIGhyZWY9Im1haWx0bzphbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNv bSI+YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JIHN0aWxsIGZpbmQgdGhpcyBhIGJpdCBjbHVua3kgKGFuZCBJIHN0aWxsIHdvbmRl ciBpZiB3ZSBjb3VsZCBkZWZpbmUg4oCcY29ybmVyIGJlaGF2aW9y4oCdIGluc3RlYWQgb2YgZXJy b3IgY29uZGl0aW9ucyksIGJ1dCBPSywgbGV04oCZcyBnbyB3aXRoIHRoZSBwcm9wb3NlZCBhcyBv dXRsaW5lZA0KIGJ5IE1hcnRpbi4gJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5MZXTigJlzIGNsb3Nl IHRoaXM7IHdlIHdpbGwgdXBkYXRlIHRoZSBSUENzIGFjY29yZGluZ2x5LiZuYnNwOyAmbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoYW5rczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4t LS0gQWxleCZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkFuZHkNCiBCaWVybWFuIFs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29y a3MuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86YW5keUB5dW1hd29ya3Mu Y29tPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5UdWVzZGF5LCBEZWNlbWJlciAwNSwgMjAxNyAyOjIwIFBNPGJyPg0K PGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5BbGV4YW5kZXIgQ2xlbW0gJmx0OzxhIGhyZWY9Im1haWx0bzphbGV4YW5kZXIuY2xlbW1AaHVh d2VpLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YWxleGFuZGVyLmNsZW1tQGh1YXdl aS5jb208L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1hcnRpbiBCam9ya2x1bmQgJmx0OzxhIGhyZWY9 Im1haWx0bzptYmpAdGFpbC1mLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWJqQHRh aWwtZi5jb208L3NwYW4+PC9hPiZndDs7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5uZXRjb25mQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5T dWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+UmU6IFtOZXRjb25mXSB5YW5nLXB1c2ggaXNzdWU6IGVycm9yIGhhbmRsaW5nPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVyZSBpcyB0aGUgcHJv YmxlbSB3aXRoIHRoZSBZQU5HIFB1c2ggZXJyb3IgaGFuZGxpbmcuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgJmx0 O3JwYy1lcnJvciZndDsgcmVzcG9uc2UgaXMgYSBNVVNULCBub3QgYSBTSE9VTEQ6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHls ZT0id29yZC13cmFwOiBicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFwIj40LjMuJm5ic3A7 ICZsdDtycGMtZXJyb3ImZ3Q7IEVsZW1lbnQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgVGhlICZsdDtycGMtZXJyb3ImZ3Q7 IGVsZW1lbnQgaXMgc2VudCBpbiAmbHQ7cnBjLXJlcGx5Jmd0OyBtZXNzYWdlcyBpZiBhbiBlcnJv cjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBvY2N1cnMgZHVyaW5nIHRoZSBw cm9jZXNzaW5nIG9mIGFuICZsdDtycGMmZ3Q7IHJlcXVlc3QuPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IElmIGEgc2VydmVy IGVuY291bnRlcnMgbXVsdGlwbGUgZXJyb3JzIGR1cmluZyB0aGUgcHJvY2Vzc2luZyBvZiBhbjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyAmbHQ7cnBjJmd0OyByZXF1ZXN0LCB0 aGUgJmx0O3JwYy1yZXBseSZndDsgTUFZIGNvbnRhaW4gbXVsdGlwbGUgJmx0O3JwYy1lcnJvciZn dDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZWxlbWVudHMuJm5ic3A7IEhv d2V2ZXIsIGEgc2VydmVyIGlzIG5vdCByZXF1aXJlZCB0byBkZXRlY3Qgb3IgcmVwb3J0IG1vcmU8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgdGhhbiBvbmUgJmx0O3JwYy1lcnJv ciZndDsgZWxlbWVudCwgaWYgYSByZXF1ZXN0IGNvbnRhaW5zIG11bHRpcGxlIGVycm9ycy48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgQSBzZXJ2ZXIgaXMgbm90IHJlcXVpcmVk IHRvIGNoZWNrIGZvciBwYXJ0aWN1bGFyIGVycm9yIGNvbmRpdGlvbnMgaW48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYSBzcGVjaWZpYyBzZXF1ZW5jZS4mbmJzcDsgPGI+QSBz ZXJ2ZXIgTVVTVCByZXR1cm4gYW4gJmx0O3JwYy1lcnJvciZndDsgZWxlbWVudCBpZjwvYj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48Yj4mbmJzcDsmbmJzcDsgYW55IGVycm9yIGNvbmRpdGlvbnMg b2NjdXIgZHVyaW5nIHByb2Nlc3NpbmcuPC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7d2hpdGUtc3Bh Y2U6cHJlLXdyYXAiPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6cHJlLXdyYXAiPkFuZHk8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkO3doaXRlLXNwYWNlOnByZS13cmFw Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBEZWMgNSwgMjAxNyBhdCAxMjoz NSBQTSwgQWxleGFuZGVyIENsZW1tICZsdDs8YSBocmVmPSJtYWlsdG86YWxleGFuZGVyLmNsZW1t QGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5h bGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgTWFydGluLDxicj4NCjxicj4N ClN1cmUsIHRoZSBldmVudHVhbCBzb2x1dGlvbiBtYXkgbWFrZSB1c2Ugb2YgcnBjLWVycm9yIGFn YWluLiZuYnNwOyBCdXQgdW50aWwgd2UgZ2V0IHRoZXJlLCB0aGUgY3VycmVudGx5IHByb3Bvc2Vk IHNvbHV0aW9uIHNlZW1zIHRvIG1ha2Ugc2Vuc2UgdG8gbWUuJm5ic3A7IEkgZG9uJ3QgdGhpbmsg d2UgaGF2ZSBhbiBpc3N1ZSB0b2RheSB3aXRoIGxvdHMgb2YgUlBDcyBlYWNoIGRlZmluaW5nIHRo ZWlyIG93biB3YXkgb2YgZGVhbGluZyB3aXRoIGNvcm5lciBjb25kaXRpb25zDQogLSBkZWZpbml0 aW9uIG9mIFJQQ3MgaXMgc29tZXRoaW5nIHRoYXQgaGFzIHNvIGZhciBvbmx5IHJhcmVseSBiZWVu IGV4ZXJjaXNlZCB3aXRoIFlBTkcgbW9kZWxzLiZuYnNwOyBPbmNlIHRoaXMgYmVjb21lcyBtb3Jl IGNvbW1vbiwgSSBhbSBzdXJlIHdlIHdpbGwgZmluZCBhIG1vcmUgZ2VuZXJhbCBzb2x1dGlvbiwg YnV0IEkgZG9uJ3QgdGhpbmsgd2UgYXJlIGF0IHRoYXQgcG9pbnQuPGJyPg0KPGJyPg0KLS0tIEFs ZXg8YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBG cm9tOiBNYXJ0aW4gQmpvcmtsdW5kIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYu Y29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYmpAdGFpbC1mLmNvbTwvc3Bhbj48L2E+ XTxicj4NCiZndDsgU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDUsIDIwMTcgMTI6MjUgUE08YnI+ DQomZ3Q7IFRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5hbmR5QHl1bWF3b3Jrcy5jb208L3NwYW4+PC9hPjxicj4NCiZndDsgQ2M6IEFsZXhh bmRlciBDbGVtbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29t Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbTwv c3Bhbj48L2E+Jmd0Ozs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPm5ldGNvbmZAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCiZndDsgU3ViamVjdDog UmU6IFtOZXRjb25mXSB5YW5nLXB1c2ggaXNzdWU6IGVycm9yIGhhbmRsaW5nPGJyPg0KJmd0Ozxi cj4NCiZndDsgQW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3Mu Y29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hbmR5QHl1bWF3b3Jrcy5jb208L3NwYW4+ PC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IEhpLDxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBUaGUgcHJvdG9jb2wgZGVmaW5lcyBob3cgZXJyb3IgaGFuZGxpbmcgaXMgZG9uZSwg bm90IHRoZSBpbmRpdmlkdWFsPGJyPg0KJmd0OyAmZ3Q7IG9wZXJhdGlvbnMuPGJyPg0KJmd0OyAm Z3Q7IElmIHRoZSByZXF1ZXN0IGZhaWxzLCB0aGVuIGNsaWVudHMgZXhwZWN0IGFuICZsdDtycGMt ZXJyb3ImZ3Q7IGFuZCBzZXJ2ZXJzPGJyPg0KJmd0OyAmZ3Q7IGFyZSBkZXNpZ25lZCB0byBzZW5k IGFuICZsdDtycGMtZXJyb3ImZ3Q7IHdoZW4gYSBjbGllbnQgcmVxdWVzdCBmYWlscy48YnI+DQom Z3Q7PGJyPg0KJmd0OyBBZ3JlZWQsIGFuZCBmb3IgUkVTVENPTkYsIHRoZSBIVFRQIGVycm9yIGNv ZGVzIGFyZSB1c2VkLiZuYnNwOyBBbiBIVFRQIHJlcXVlc3Q8YnI+DQomZ3Q7IHRoYXQgZmFpbHMg ZG9lcyBub3QgcmV0dXJuIDIwMCBvayB3aXRoIGEgYm9keSB0aGF0IGV4cGxhaW5zIHRoYXQgaXQg YWN0dWFsbHkgd2FzPGJyPg0KJmd0OyBhbiBlcnJvci48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IElNTywgYSBzZXBhcmF0ZSBlcnJvciBoYW5kbGluZyBwcm9jZWR1cmUgZm9yIGVhY2ggUlBDIGlz IG1vcmUgY2x1bmt5PGJyPg0KJmd0OyAmZ3Q7IHRoYW4gZXJyb3ItaW5mby48YnI+DQomZ3Q7PGJy Pg0KJmd0OyAmIzQzOzE8YnI+DQomZ3Q7PGJyPg0KJmd0OyBTb21lIGFkZGl0aW9uYWwgY29tbWVu dHMgaW5saW5lLjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgV2hpbGUg cG9zc2libGUsIHRoZSBzb2x1dGlvbiBvZiBoYXZpbmcgdG8gcmV0dXJuIHJwYy1lcnJvciBldGMg ZG9lczxicj4NCiZndDsgJmd0OyAmZ3Q7IHN0cmlrZSBtZSBhcyBzb21ld2hhdCBjbHVua3kuJm5i c3A7IFdoaWxlIGl0IGlzIHBvc3NpYmxlIHRvIGFkZCBhbjxicj4NCiZndDsgJmd0OyAmZ3Q7IGVy cm9yLWFwcC10YWcsIGFuZCBuZWdvdGlhdGlvbiBzdHVmZiBhcyBlcnJvci1pbmZvIChhbmQgSSBh cHByZWNpYXRlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhlIHN1Z2dlc3Rpb24pLCB0aGF0IHNvbHV0 aW9uIHdvdWxkIG5lZWQgdG8gYmUgZGVzY3JpYmVkIHVzaW5nIGE8YnI+DQomZ3Q7ICZndDsgJmd0 OyBsb3Qgb2YgcHJvc2UgaW4gZGVzY3JpcHRpb24gc3RhdGVtZW50cyBhIGxhIFNNSXYyIChwcmVz dW1hYmx5IGFzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcGFydCBvZiB0aGUgUlBDIGRlc2NyaXB0aW9u LCBub3QgYXMgcGFydCBvZiBlLmcuIHRoZSBpZGVudGl0aWVzLDxicj4NCiZndDsgJmd0OyAmZ3Q7 IHdoaWNoIG1pZ2h0IGJlIHVzZWQgaW4gYSBudW1iZXIgb2YgcGxhY2VzLCBub3QganVzdCB0aGUg ZXJyb3ItYXBwLXRhZykuPGJyPg0KJmd0Ozxicj4NCiZndDsgSWYgYm90aCB0aGUgZXJyb3IgY29k ZSBhbmQgaGludCBpcyBkZWZpbmVkIGluIGEgeWFuZy1kYXRhIChpLmUuLCBub3QgdXNpbmcgdGhl PGJyPg0KJmd0OyBlcnJvci1hcHAtdGFnKSwgeW91IHdvdWxkIGRvOjxicj4NCiZndDs8YnI+DQom Z3Q7Jm5ic3A7ICZuYnNwO3l4OnlhbmctZGF0YSBzdWJzY3JpcHRpb24tZXJyb3Igezxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbnRhaW5lciBzdWJzY3JpcHRpb24tZXJyb3Igezxicj4N CiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsZWFmIGVycm9yLWNvZGUgezxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dHlwZSBpZGVudGl0eSB7PGJyPg0K Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmFzZSBlcnJvcjs8 YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtjb250YWluZXIgaGludHMgeyAuLi4gfTxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw O308YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO308YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGVuIHlvdSBh cmUgcmlnaHQsIHlvdSBoYXZlIHRvIGRlc2NyaWJlIGluIHByb3NlIHRoYXQgdGhpcyB5YW5nLWRh dGE8YnI+DQomZ3Q7IHN0cnVjdHVyZSBjYW4gYmUgc2VudCBhcyBlcnJvci1pbmZvLjxicj4NCiZn dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSSBhbSBub3Qgc3VyZSB3aHkgdGhhdCB3 b3VsZCBtYWtlIGFuIFJQQyBhbnkgZWFzaWVyIHRvIGltcGxlbWVudC48YnI+DQomZ3Q7ICZndDsg Jmd0OyBUaGUgc2FtZSBjaGVja3Mgc3RpbGwgaGF2ZSB0byBiZSBtYWRlLjxicj4NCiZndDs8YnI+ DQomZ3Q7IEFncmVlZC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgV2h5IHdvdWxkIHRo ZSBwcm9wb3NlZCBzb2x1dGlvbiBub3QgYWNjZXB0YWJsZT8mbmJzcDsgJm5ic3A7SWRlYWxseSBZ QU5HIHdvdWxkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcHJvdmlkZSBiZXR0ZXIgc3VwcG9ydCB0byBm b3JtYWxseSBkZWZpbmUgYXBwbGljYXRpb24vUlBDLXNwZWNpZmljPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgcmV0dXJuIGNvZGVzIGFuZCBjb3JuZXIgY29uZGl0aW9ucyBldGMuPGJyPg0KJmd0Ozxicj4N CiZndDsgQWxzbyBhZ3JlZWQuJm5ic3A7IEJ1dCBvbmNlIHdlIGhhdmUgdGhhdCwgc3VjaCBhIHNv bHV0aW9uIHdvdWxkIG1ha2UgdXNlIG9mIHRoZTxicj4NCiZndDsgcnBjLWVycm9yIHdlIGhhdmUg KGZvciBib3RoIE5FVENPTkYgYW5kIFJFU1RDT05GKS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDsgL21hcnRpbjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgU2hv cnQgb2YgdGhhdCwgdGhlIHByb3Bvc2VkIHNvbHV0aW9uIG9mIGFkZGluZyBSUEMgb3V0cHV0IHBh cmFtZXRlcnM8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGF0IGFyZSB1c2VkIGZvciB0aGUgcHVycG9z ZSBvZiBpbmRpY2F0aW5nIHdoYXQgaXMgZ29pbmcgb24gYXQgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgYXBwbGljYXRpb24gbGV2ZWwgc2ltcGx5IG1ha2VzIHRoZW0gcGFydCBvZiB0aGUgc2VtYW50 aWNzIG9mIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7IHNwZWNpZmljIFJQQyBpdHNlbGYuJm5ic3A7 IEl0IGlzIG5vdCBOZXRjb25m4oCZcyByb2xlIHRvIGRlZmluZSB3aGF0IGFuIFJQQzxicj4NCiZn dDsgJmd0OyAmZ3Q7IGNhbiBvciBjYW5ub3QgZG8sIGp1c3QgbGlrZSBpdCBjYW5ub3QgZGVmaW5l IHdoYXQgYSBwYXJ0aWN1bGFyIGxlYWY8YnI+DQomZ3Q7ICZndDsgJmd0OyBtYXkgb3IgbWF5IG5v dCByZXByZXNlbnQuJm5ic3A7IFRoYXQgaXMgcGFydCBvZiB0aGUgUlBDIGRlZmluaXRpb24uPGJy Pg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQmFzaWNhbGx5LCB3aGF0IHdlIGFyZSBkaXNjdXNzaW5nIGhl cmUgaXMgYmVoYXZpb3Igb2Ygc3Vic2NyaXB0aW9uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY29uZmln dXJhdGlvbiB1bmRlciBjb3JuZXIgY29uZGl0aW9ucy4mbmJzcDsgVGhlIGZhY3QgdGhhdCBubzxi cj4NCiZndDsgJmd0OyAmZ3Q7IHN1YnNjcmlwdGlvbiBpcyBjcmVhdGVkIGJlY2F1c2UgaXQgd291 bGQgcmVzdWx0IGluIGFuIHVuYWNjZXB0YWJsZTxicj4NCiZndDsgJmd0OyAmZ3Q7IHZvbHVtZSBv ZiB1cGRhdGVzIGZvciBhIHNwZWNpZmljIGltcGxlbWVudGF0aW9uIGlzIGRpZmZlcmVudCBmcm9t IGFuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZXJyb3IgY29uZGl0aW9uIHN1Y2ggYXMgYSBtYWxmb3Jt ZWQgbWVzc2FnZSB0aGF0IGlzIG1pc3NpbmcgYTxicj4NCiZndDsgJmd0OyAmZ3Q7IHJlcXVpcmVk IG1lc3NhZ2UtaWQsIG9yIHdoZXJlIGEgdmFsdWUgdmlvbGF0ZXMgYSBjb25zdHJhaW50PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgc3BlY2lmaWVkIGluIGEgTVVTVC1jb25kaXRpb24uJm5ic3A7IEluIG91 ciBjYXNlLCB3aGF0IGlzIGJlaW5nIGRlc2NyaWJlZCBhcmU8YnI+DQomZ3Q7IHNwZWNpZmljIGNv bmRpdGlvbnMgYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyLCBhYm92ZSB0aGU8YnI+DQomZ3Q7ICZn dDsgJmd0OyBOZXRjb25mL1Jlc3Rjb25mIGdlbmVyaWMgdmFsaWRhdGlvbiBpbmZyYXN0cnVjdHVy ZS4mbmJzcDsgJm5ic3A7VGhlIG9wZXJhdGlvbiBkb2VzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgbm90 IOKAnHdvcmvigJ0gaW4gdGhlIHNlbnNlIHRoYXQgaXQgZG9lcyBub3QgcmVzdWx0IGluIGFuIGFj dGl2ZTxicj4NCiZndDsgJmd0OyAmZ3Q7IHN1YnNjcmlwdGlvbiwgYnV0IGl0IGRvZXMgd29yayBp biB0aGUgc2Vuc2UgdGhhdCB0aGUgYmVoYXZpb3IgaXM8YnI+DQomZ3Q7ICZndDsgJmd0OyB2ZXJ5 IHdlbGwgZGVmaW5lZCBpbiB0ZXJtcyBvZiB0aGUgZWZmZWN0IHRoYXQgdGhlIFJQQyBoYXMgKGku ZS4gdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZWZmZWN0IGlzIHRoYXQgaXQgcmVzdWx0IGluIGNy ZWF0aW9uIG9mIGEgc3Vic2NyaXB0aW9uLCBpZiBjZXJ0YWluPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Y29uZGl0aW9ucyBhcmUgbWV0LCBhbmQgaXQgZG9lcyBub3QgcmVzdWx0IGluIGNyZWF0aW9uIG9m IGE8YnI+DQomZ3Q7ICZndDsgJmd0OyBzdWJzY3JpcHRpb24gaW4gY2FzZSBjZXJ0YWluIGNvbmRp dGlvbnMgYXJlIG5vdCBtZXQpLiZuYnNwOyBXaHkgc2hvdWxkPGJyPg0KJmd0OyAmZ3Q7ICZndDsg TmV0Y29uZiByZXN0cmljdCB3aGF0IGFuIFJQQyBjYW4gb3IgY2Fubm90IGRvPyZuYnNwOyBUaGlz IGlzIGFsbCBhcHBsaWNhdGlvbi08YnI+DQomZ3Q7IHNwZWNpZmljLjxicj4NCiZndDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7IC0tLSBBbGV4PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICpGcm9tOiogTmV0Y29uZiBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XSAqT24gQmVoYWxmIE9mPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgKkFuZHkgQmllcm1hbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICpTZW50Oiog TW9uZGF5LCBEZWNlbWJlciAwNCwgMjAxNyA5OjE1IEFNPGJyPg0KJmd0OyAmZ3Q7ICZndDsgKlRv OiogTWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIj48 c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYmpAdGFpbC1mLmNvbTwvc3Bhbj48L2E+Jmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7ICpDYzoqIE5ldGNvbmYgJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRj b25mQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5uZXRjb25mQGlldGYub3Jn PC9zcGFuPjwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgKlN1YmplY3Q6KiBSZTogW05ldGNv bmZdIHlhbmctcHVzaCBpc3N1ZTogZXJyb3IgaGFuZGxpbmc8YnI+DQomZ3Q7ICZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIE1vbiwgRGVjIDQsIDIwMTcgYXQgNDo1NSBBTSwg TWFydGluIEJqb3JrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5tYmpAdGFpbC1mLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4N CiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBBbmR5 IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iPjxzcGFuIHN0 eWxlPSJjb2xvcjpwdXJwbGUiPmFuZHlAeXVtYXdvcmtzLmNvbTwvc3Bhbj48L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEhpLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IElNTyB0aGUgc3BlY2lhbCBlcnJvciBoYW5kbGluZyBp biBZQU5HIFB1c2ggaXMgbm90IGFjY2VwdGFibGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJl Y2F1c2UgaXQgdmlvbGF0ZXMgTkVUQ09ORiBhbmQgUkVTVENPTkYgZXJyb3IgaGFuZGxpbmcgcHJv Y2VkdXJlcy48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IE5FVENPTkYgc2F5cyBpZiB0aGUgb3Bl cmF0aW9uIGRvZXMgbm90IHdvcmsgZm9yIGFueSByZWFzb24gYW48YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZsdDtycGMtZXJyb3ImZ3Q7IGVsZW1lbnQgU0hPVUxEIGJlIHJldHVybmVkLjxicj4N CiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSSBmdWxseSBhZ3JlZSwgYW5kIEkg aGF2ZSBwb2ludGVkIHRoaXMgb3V0IHNldmVyYWwgdGltZXMgaW4gbXk8YnI+DQomZ3Q7ICZndDsg Jmd0OyByZXZpZXdzLiZuYnNwOyBUaGUgcHJvYmxlbSBpcyBhY3R1YWxseSBpbiBzdWJzY3JpYmVk IG5vdGlmaWNhdGlvbnMsIGFuZCBJPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhpbmsgRXJpYyBpcyB0 cmFja2luZyB0aGF0IGlzc3VlLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgVHJ5aW5nIHRvIGJlIGNvbnN0cnVjdGl2ZSwgSSB0aGluayB0aGF0IHRoZSBleGlzdGluZyBt ZWNoYW5pc21zIGluPGJyPg0KJmd0OyAmZ3Q7ICZndDsgWUFORyBjYW4gYmUgdXNlZCB0byBhY2hp ZXZlIHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHkgdGhhdCB0aGVzZSBkcmFmdHM8YnI+DQomZ3Q7ICZn dDsgJmd0OyB0cnkgdG8gYWNoaWV2ZS4mbmJzcDsgU3BlY2lmaWNhbGx5Ojxicj4NCiZndDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7MS4gVXNlIGlkZW50aXRpZXMg anVzdCBsaWtlIHRoZSBvbmVzIHlvdSBoYXZlPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAoJnF1b3Q7dW5zdXBwb3J0YWJsZS12b2x1bWUmcXVvdDssICZxdW90O2ZpbHRl ci11bmF2YWlsYWJsZSZxdW90OyBldGMpLCBidXQgYWRkIHRleHQ8YnI+DQomZ3Q7ICZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoYXQgZXhwbGFpbnMgdGhhdCB0aGVzZSBpZGVudGl0aWVz IGFyZSBzZW50IGFzICZxdW90O2Vycm9yLWFwcC10YWcmcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7IGluICZxdW90O3JwYy1lcnJvciZxdW90OywgZW5jb2RlZCB0 byBhIHN0cmluZyBhcyAmbHQ7bW9kdWxlJmd0OzombHQ7aWRlbnRpdHkmZ3Q7LiZuYnNwOyBUaGlz PGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyB3b3JrcyBmb3IgYm90aCBO RVRDT05GIGFuZCBSRVNUQ09ORi48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOzIuIEZvciB0aGUgJnF1b3Q7aGludHMmcXVvdDsgZXh0cmEgaW5mbyB0 aGF0IHlvdSByZXR1cm4sIGRlZmluZSBhICZxdW90O3lhbmctZGF0YSZxdW90Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgc3RydWN0dXJlIHdpdGggdGhlIGhpbnRzLCBh bmQgZXhwbGFpbiBpbiB0ZXh0IHRoYXQgdGhpcyBzdHJ1Y3R1cmU8YnI+DQomZ3Q7ICZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7IGlzIHJldHVybmVkIGluICZxdW90O2Vycm9yLWluZm8mcXVv dDsuJm5ic3A7IFRoaXMgd29ya3MgZm9yIGJvdGggTkVUQ09ORiBhbmQ8YnI+DQomZ3Q7ICZndDsg Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IFJFU1RDT05GLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmIzQzOzE8YnI+DQomZ3Q7 ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgJmd0OyBJZiB0aGUgZXJyb3IgaGFuZGxpbmcgd2FzIGRvbmUgY29ycmVjdGx5IHRo ZW4gdGhlIHNhbWUgcHJvY2VkdXJlczxicj4NCiZndDsgJmd0OyAmZ3Q7IGNvdWxkIGJlPGJyPg0K Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBhcHBsaWVkIHRvICZsdDtlZGl0LWNv bmZpZyZndDsgZmFpbHVyZXMgZm9yIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9ucy48YnI+DQomZ3Q7 ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyBBcyBhbiBhbHRlcm5hdGl2ZSB0byAxLCB5b3UgY2FuIHB1dCB0aGUg ZXJyb3IgaWRlbnRpdGl5cmVmIGluIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZxdW90O3lhbmct ZGF0YSZxdW90OyBzdHJ1Y3R1cmUsIGFuZCBzZW5kIGJvdGggdGhlIGlkZW50aXRpeXJlZiBhbmQg aGludHMgaW48YnI+DQomZ3Q7ICZndDsgJmd0OyAmcXVvdDtlcnJvci1pbmZvJnF1b3Q7Ljxicj4N CiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAv bWFydGluPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7IEFuZHk8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZSAmbHQ7 ZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiZndDsgcmV0dXJucyBkYXRhIGV2ZW4gb24gZXJyb3IuPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBJbnN0ZWFkIG9mIHRoZSBjb21tb24gZXJyb3ItdGFnLCBl cnJvci1pbmZvLCBhbmQgb3RoZXIgZmllbGRzLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgdGhl cmUgaXMgYSBzdWJzY3JpcHRpb24tcmVzdWx0IGxlYWYuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSWYgYW55IGNsaWVudCAob3IgZXZlbiBzZXJ2ZXIp IGZ1bmN0aW9uYWxpdHkgdXNlcyB0aGUgTkVUQ09ORiBhbmQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7IFJFU1RDT05GIHN0YW5kYXJkIGVycm9yIGhhbmRsaW5nLCB0aGVuIHN1YnNjcmlwdGlvbi1y ZXN1bHQgd2lsbDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgbm90IGJlIHNlbnQgb3IgZXhwZWN0 ZWQgYXMgYW4gZXJyb3IgcmVzcG9uc2UuIERlcGVuZGluZyBvbiB0aGU8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7IHNlcnZlciBpbXBsZW1lbnRhdGlvbiwgdGhlIGNvZGUgdGhhdCBrbm93cyBhYm91 dDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgZXN0YWJsaXNoLXN1YnNjcmlwdGlvbiBtYXkgbm90 IGdldCBjYWxsZWQgYmVjYXVzZSBjb21tb24gZXJyb3I8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 IGhhbmRsaW5nIGNvZGUgaGFzIGFscmVhZHkgZGV0ZXJtaW5lZCB0aGVyZSBpcyBhbiAmbHQ7cnBj LWVycm9yJmd0OyB0bzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgc2VuZCBpbnN0ZWFkIG9mIGEg ZGF0YSByZXNwb25zZS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZn dDsgJmd0OyBFeHBlY3QgdGhhdCBzb21lIHNlcnZlcnMgYXJlIG5ldmVyIGdvaW5nIHRvIHNlbmQg ZGF0YSBvbiBhbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgb3BlcmF0aW9uIGZhaWx1cmUsIGFu ZCB3aWxsIG9ubHkgc2VuZCAmbHQ7cnBjLWVycm9yJmd0OyBpbnN0ZWFkLjxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7RnJvbSBzZWMuIDMuODo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgRm9yIGluc3RhbmNlLCBmb3IgdGhlIGZvbGxv d2luZyByZXF1ZXN0Ojxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZsdDtuZXRjb25mOnJwYyBtZXNzYWdlLWlkPSZxdW90OzEwMSZxdW90Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IHhtbG5zOm5ldGNvbmY9JnF1b3Q7dXJuOmll dGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wJnF1b3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZsdDtlc3RhYmxpc2gtc3Vic2NyaXB0aW9uPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB4bWxucz0mcXVv dDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlv bnMmcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHhtbG5zOnlwPSZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLXlhbmct cHVzaCZxdW90OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmx0O3lwOmRhdGFzdG9yZSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDt5cDpzb3VyY2UgeG1sbnM9JnF1b3Q7 dXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtZGF0YXN0b3JlcyZxdW90OyZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtvcGVyYXRpb25hbDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy95cDpzb3VyY2UmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7eXA6c3VidHJlZS1maWx0 ZXIgbmV0Y29uZjp0eXBlPSZxdW90O3hwYXRoJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3htbG5zOmV4 PSZxdW90OzxhIGhyZWY9Imh0dHA6Ly9leGFtcGxlLmNvbS9zYW1wbGUtZGF0YS8xLjAiIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwOi8vZXhhbXBsZS5jb20v c2FtcGxlLWRhdGEvMS4wPC9zcGFuPjwvYT4mcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2VsZWN0PSZx dW90Oy9leDpmb28mcXVvdDsvJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmbHQ7L3lwOmRhdGFzdG9yZSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3lwOnBlcmlvZCZndDs1MDAmbHQ7 L3lwOnBlcmlvZCZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbHQ7 L2VzdGFibGlzaC1zdWJzY3JpcHRpb24mZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7 L25ldGNvbmY6cnBjJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgRmlndXJlIDM6IEVzdGFibGlzaC1TdWJzY3JpcHRpb24gZXhhbXBsZTxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwOyB0aGUgcHVibGlzaGVyIG1pZ2h0IHJldHVybjo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0O3Jw Yy1yZXBseSBtZXNzYWdlLWlkPSZxdW90OzEwMSZxdW90Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyB4bWxucz0mcXVvdDt1cm46aWV0ZjpwYXJhbXM6eG1sOm5z Om5ldGNvbmY6YmFzZToxLjAmcXVvdDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNw OyAmbmJzcDsgJmx0O3N1YnNjcmlwdGlvbi1yZXN1bHQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHhtbG5zPSZxdW90O3VybjppZXRmOnBhcmFtczp4 bWw6bnM6eWFuZzppZXRmLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucyZxdW90Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgeG1sbnM6eXA9JnF1b3Q7 dXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYteWFuZy1wdXNoJnF1b3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyB5cDpwZXJpb2QtdW5zdXBw b3J0ZWQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbHQ7L3N1YnNjcmlw dGlvbi1yZXN1bHQmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJmx0 O3BlcmlvZC1oaW50IHhtbG5zOiZxdW90O3VybjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRm LXlhbmctcHVzaCZxdW90OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7MjAwMDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7 ICZsdDsvcGVyaW9kLWhpbnQmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbHQ7L3JwYy1y ZXBseSZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgRmlndXJlIDQ6IEVycm9yIHJlc3BvbnNlIGV4YW1wbGU8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEJUVywgYWxsIHRoZSBmaWx0 ZXIgZXhhbXBsZXMgc2VlbSB0byBiZSB3cm9uZywgaW5jbHVkaW5nIHRoZSBvbmU8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IGFib3ZlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IE9MRDo8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsmbHQ7eXA6c3VidHJlZS1maWx0ZXIgbmV0Y29uZjp0eXBlPSZxdW90O3hw YXRoJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3htbG5zOmV4PSZxdW90OzxhIGhyZWY9Imh0dHA6Ly9l eGFtcGxlLmNvbS9zYW1wbGUtZGF0YS8xLjAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6cHVycGxlIj5odHRwOi8vZXhhbXBsZS5jb20vc2FtcGxlLWRhdGEvMS4wPC9zcGFuPjwv YT4mcXVvdDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c2VsZWN0PSZxdW90Oy9leDpmb28mcXVvdDsvJmd0Ozxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyBORVc6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZsdDt5cDpzdWJ0cmVlLWZpbHRlciZndDs8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0O2V4 OmZvbyB4bWxuczpleD0mcXVvdDs8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vc2FtcGxlLWRh dGEvMS4wIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDov L2V4YW1wbGUuY29tL3NhbXBsZS1kYXRhLzEuMDwvc3Bhbj48L2E+JnF1b3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgJmd0OyAvJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDsveXA6c3Vi dHJlZS1maWx0ZXImZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFuZHk8YnI+DQomZ3Q7ICZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFpbGluZyBsaXN0PGJyPg0KPC9z cGFuPjxhIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOnB1cnBsZSI+TmV0Y29uZkBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbmV0Y29uZiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJwbGUiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_765779b15f1f4edc9b27891fb94b3f15XCHRTP013ciscocom_-- From nobody Wed Dec 6 10:02:59 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 67CDC126D3F for ; Wed, 6 Dec 2017 10:02: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 yLA5clgeMlz7 for ; Wed, 6 Dec 2017 10:02: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 BE090124F57 for ; Wed, 6 Dec 2017 10:02:55 -0800 (PST) Received: from localhost (h-85-209.A165.priv.bahnhof.se [94.254.85.209]) by mail.tail-f.com (Postfix) with ESMTPSA id 89CF81AE0141; Wed, 6 Dec 2017 19:02:54 +0100 (CET) Date: Wed, 06 Dec 2017 19:02:54 +0100 (CET) Message-Id: <20171206.190254.1586521076827811095.mbj@tail-f.com> To: einarnn@cisco.com Cc: alexander.clemm@huawei.com, andy@yumaworks.com, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD12B7@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=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Netconf] yang-push issue: error handling 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, 06 Dec 2017 18:02:58 -0000 SGksDQoNCiJFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikiIDxlaW5hcm5uQGNpc2NvLmNv bT4gd3JvdGU6DQo+IHRsO2RyIOKAlCBJIGFncmVlIHRoYXQgd2Ugc2hvdWxkIGNsb3NlIHRoaXMg YW5kIHVzZSBhIHlhbmctZGF0YQ0KPiBkZWNsYXJhdGlvbiB0byBkZWZpbmUgd2hhdCBnb2VzIGlu dG8gdGhlIOKAnGVycm9yLWluZm/igJ0uIExldOKAmXMgbWFrZQ0KPiBwcm9ncmVzcy4NCj4gDQo+ IA0KPiBIb3dldmVyLCBJIGFsc28gYWdyZWUgd2l0aCBBbGV4IHRoYXQgdGhlIHNvbHV0aW9uIHBy b3Bvc2VkIGlzIGNsdW5reSwNCj4gYW5kIEkgZG9u4oCZdCB0aGluayBpdCBhY3R1YWxseSBwcm9t b3RlcyBzdGFuZGFyZGlzZWQgZXJyb3IgaGFuZGxpbmcgYXMNCj4gdGhlIGNvbmRpdGlvbnMgd2Ug YXJlIGRlYWxpbmcgd2l0aCBoZXJlIGFyZSBqdXN0IG5vdCBhcyBzaW1wbGUgYXMNCj4g4oCcc29y cnksIGl0IGRpZG7igJl0IHdvcmvigJ0uDQoNCkluIHRoZSBkcmFmdCwgdGhlcmUgaXMgb25lICJz dWJzY3JpcHRpb24tcmVzdWx0IiBjYWxsZWQgIm9rIiwgYW5kIG9uZQ0KY2FsbGVkICJlcnJvciIu ICBUaGVuIHRoZXJlIGFyZSBhIGJ1bmNoIG9mIGlkZW50ZW50aWVzIGRlcml2ZWQgZnJvbQ0KImVy cm9yIi4gIEFyZSB5b3Ugc2F5aW5nIHRoYXQgdGhlc2UgaW4gZmFjdCBhcmUgKm5vdCogZXJyb3Jz Pw0KDQoNCj4gVGhlIFJQQyB3aWxsIGhhdmUgd29ya2VkIGV4YWN0bHkgYXMgaW50ZW5kZWQsDQo+ IGFuZCBtYXkgaGF2ZSBwcm92aWRlZCB5b3Ugd2l0aCBpbmZvcm1hdGlvbiByZWxhdGluZyB0bywg Zm9yIGV4YW1wbGUsDQo+IGhvdyB0byBjcmVhdGUgYSBzdWJzY3JpcHRpb24gcmVxdWVzdCB0aGF0 IHdpbGwgd29yay4gSXQganVzdCB3b27igJl0DQo+IG5lY2Vzc2FyaWx5IGhhdmUgZXN0YWJsaXNo ZWQgdGhlIHN1YnNjcmlwdGlvbiBleGFjdGx5IGFzIHlvdQ0KPiB3YW50ZWQuDQoNCjpEICBJJ2xs IHRyeSB0byByZW1lbWJlciB0byB1c2UgdGhpcyBhcmd1bWVudCB3aGVuZXZlciBvbmUgb2YgbXkN CnByb2dyYW0gY3JhY2hlcyAiaXQgd29ya2VkLCBidXQgbWF5YmUgbm90IGluIHRoZSB3YXkgeW91 IHdhbnRlZCIgOy0pDQoNCg0KPiBUaGUgUlBDIGl0c2VsZiBleGVjdXRlZCBjb21wbGV0ZWx5IGNv cnJlY3RseSwgYW5kIHRodXMNCj4g4oCccnBjLWVycm9y4oCdIHNlZW1zIGxpa2UgYW4gaW5jb3Jy ZWN0IHJlc3BvbnNlLg0KDQpJIGFic29sdXRlbHkgYWdyZWUgdGhhdCBpZiB5b3Ugd2FudCB0byBy ZXR1cm4gc3VjY2Vzc2Z1bGx5LCBhbmQNCnByb3ZpZGUgc29tZSByZXN1bHQsIHlvdSBzaG91bGQg bm90IHB1dCB0aGF0IGludG8gInJwYy1lcnJvciIuDQoNCg0KDQovbWFydGluDQoNCg0KDQoNCj4g V2hhdCB3ZSBhcmUgZG9pbmcgaGVyZQ0KPiBpcyBzaW1wbHkgbm90IHRoZSBzYW1lIGFzLCBmb3Ig ZXhhbXBsZSwgYW4gZWRpdCBjb25maWcgdGhhdCBmYWlsZWQgZHVlDQo+IHRvIGludmFsaWQgZGF0 YSBhbmQgbGVmdCB0aGUgc3lzdGVtIGNvbmZpZ3VyYXRpb24gc3RhdGUgdW5jaGFuZ2VkLg0KPiAN Cj4gQnV0IGFueXdheSwgbGV04oCZcyBtYWtlIHByb2dyZXNzLiBNYWNoaW5lIHJlYWRhYmxlIGVy cm9yLWluZm8gd2l0aA0KPiB5YW5nLWRhdGEgaXMgYSBzdGVwIGluIHRoZSByaWdodCBkaXJlY3Rp b24sIGJ1dCBiZWNhdXNlIG9mIHRoYXQNCj4gc3RhbmRhcmRpc2VkIGVycm9yIGhhbmRsaW5nIGp1 c3QgaXNu4oCZdCBwbGF1c2libGUuIElmIHdl4oCZZCByZXNlcnZlZA0KPiDigJxycGMtZXJyb3Li gJ0gZm9yIHRoaW5ncyB0aGF0IGp1c3QgZGlkbuKAmXQgd29yaywgdGhhdCB3b3VsZCBwcm92aWRl DQo+IGNsZWFuZXIgc2VtYW50aWNzLg0KPiANCj4gQ2hlZXJzLA0KPiANCj4gRWluYXINCj4gDQo+ IA0KPiBPbiA2IERlYyAyMDE3LCBhdCAwMjowMSwgQWxleGFuZGVyIENsZW1tDQo+IDxhbGV4YW5k ZXIuY2xlbW1AaHVhd2VpLmNvbTxtYWlsdG86YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+PiB3 cm90ZToNCj4gDQo+IEkgc3RpbGwgZmluZCB0aGlzIGEgYml0IGNsdW5reSAoYW5kIEkgc3RpbGwg d29uZGVyIGlmIHdlIGNvdWxkIGRlZmluZQ0KPiDigJxjb3JuZXIgYmVoYXZpb3LigJ0gaW5zdGVh ZCBvZiBlcnJvciBjb25kaXRpb25zKSwgYnV0IE9LLCBsZXTigJlzIGdvIHdpdGgNCj4gdGhlIHBy b3Bvc2VkIGFzIG91dGxpbmVkIGJ5IE1hcnRpbi4NCj4gDQo+IExldOKAmXMgY2xvc2UgdGhpczsg d2Ugd2lsbCB1cGRhdGUgdGhlIFJQQ3MgYWNjb3JkaW5nbHkuDQo+IA0KPiBUaGFua3MNCj4gLS0t IEFsZXgNCj4gDQo+IEZyb206IEFuZHkgQmllcm1hbiBbbWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNv bV0NCj4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDUsIDIwMTcgMjoyMCBQTQ0KPiBUbzogQWxl eGFuZGVyIENsZW1tDQo+IDxhbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbTxtYWlsdG86YWxleGFu ZGVyLmNsZW1tQGh1YXdlaS5jb20+Pg0KPiBDYzogTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwt Zi5jb208bWFpbHRvOm1iakB0YWlsLWYuY29tPj47DQo+IG5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRv Om5ldGNvbmZAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbTmV0Y29uZl0geWFuZy1wdXNoIGlz c3VlOiBlcnJvciBoYW5kbGluZw0KPiANCj4gSGksDQo+IA0KPiBIZXJlIGlzIHRoZSBwcm9ibGVt IHdpdGggdGhlIFlBTkcgUHVzaCBlcnJvciBoYW5kbGluZy4NCj4gVGhlIDxycGMtZXJyb3I+IHJl c3BvbnNlIGlzIGEgTVVTVCwgbm90IGEgU0hPVUxEOg0KPiANCj4gDQo+IDQuMy4gIDxycGMtZXJy b3I+IEVsZW1lbnQNCj4gDQo+IA0KPiANCj4gICAgVGhlIDxycGMtZXJyb3I+IGVsZW1lbnQgaXMg c2VudCBpbiA8cnBjLXJlcGx5PiBtZXNzYWdlcyBpZiBhbiBlcnJvcg0KPiANCj4gICAgb2NjdXJz IGR1cmluZyB0aGUgcHJvY2Vzc2luZyBvZiBhbiA8cnBjPiByZXF1ZXN0Lg0KPiANCj4gDQo+IA0K PiAgICBJZiBhIHNlcnZlciBlbmNvdW50ZXJzIG11bHRpcGxlIGVycm9ycyBkdXJpbmcgdGhlIHBy b2Nlc3Npbmcgb2YgYW4NCj4gDQo+ICAgIDxycGM+IHJlcXVlc3QsIHRoZSA8cnBjLXJlcGx5PiBN QVkgY29udGFpbiBtdWx0aXBsZSA8cnBjLWVycm9yPg0KPiANCj4gICAgZWxlbWVudHMuICBIb3dl dmVyLCBhIHNlcnZlciBpcyBub3QgcmVxdWlyZWQgdG8gZGV0ZWN0IG9yIHJlcG9ydCBtb3JlDQo+ IA0KPiAgICB0aGFuIG9uZSA8cnBjLWVycm9yPiBlbGVtZW50LCBpZiBhIHJlcXVlc3QgY29udGFp bnMgbXVsdGlwbGUgZXJyb3JzLg0KPiANCj4gICAgQSBzZXJ2ZXIgaXMgbm90IHJlcXVpcmVkIHRv IGNoZWNrIGZvciBwYXJ0aWN1bGFyIGVycm9yIGNvbmRpdGlvbnMgaW4NCj4gDQo+ICAgIGEgc3Bl Y2lmaWMgc2VxdWVuY2UuICBBIHNlcnZlciBNVVNUIHJldHVybiBhbiA8cnBjLWVycm9yPiBlbGVt ZW50IGlmDQo+IA0KPiAgICBhbnkgZXJyb3IgY29uZGl0aW9ucyBvY2N1ciBkdXJpbmcgcHJvY2Vz c2luZy4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBBbmR5DQo+IA0KPiANCj4gDQo+IA0KPiBPbiBU dWUsIERlYyA1LCAyMDE3IGF0IDEyOjM1IFBNLCBBbGV4YW5kZXIgQ2xlbW0NCj4gPGFsZXhhbmRl ci5jbGVtbUBodWF3ZWkuY29tPG1haWx0bzphbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbT4+IHdy b3RlOg0KPiBIaSBNYXJ0aW4sDQo+IA0KPiBTdXJlLCB0aGUgZXZlbnR1YWwgc29sdXRpb24gbWF5 IG1ha2UgdXNlIG9mIHJwYy1lcnJvciBhZ2Fpbi4gIEJ1dA0KPiB1bnRpbCB3ZSBnZXQgdGhlcmUs IHRoZSBjdXJyZW50bHkgcHJvcG9zZWQgc29sdXRpb24gc2VlbXMgdG8gbWFrZQ0KPiBzZW5zZSB0 byBtZS4gIEkgZG9uJ3QgdGhpbmsgd2UgaGF2ZSBhbiBpc3N1ZSB0b2RheSB3aXRoIGxvdHMgb2Yg UlBDcw0KPiBlYWNoIGRlZmluaW5nIHRoZWlyIG93biB3YXkgb2YgZGVhbGluZyB3aXRoIGNvcm5l ciBjb25kaXRpb25zIC0NCj4gZGVmaW5pdGlvbiBvZiBSUENzIGlzIHNvbWV0aGluZyB0aGF0IGhh cyBzbyBmYXIgb25seSByYXJlbHkgYmVlbg0KPiBleGVyY2lzZWQgd2l0aCBZQU5HIG1vZGVscy4g IE9uY2UgdGhpcyBiZWNvbWVzIG1vcmUgY29tbW9uLCBJIGFtIHN1cmUNCj4gd2Ugd2lsbCBmaW5k IGEgbW9yZSBnZW5lcmFsIHNvbHV0aW9uLCBidXQgSSBkb24ndCB0aGluayB3ZSBhcmUgYXQgdGhh dA0KPiBwb2ludC4NCj4gDQo+IC0tLSBBbGV4DQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+ID4gRnJvbTogTWFydGluIEJqb3JrbHVuZCBbbWFpbHRvOm1iakB0YWlsLWYuY29t PG1haWx0bzptYmpAdGFpbC1mLmNvbT5dDQo+ID4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMDUs IDIwMTcgMTI6MjUgUE0NCj4gPiBUbzogYW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1 bWF3b3Jrcy5jb20+DQo+ID4gQ2M6IEFsZXhhbmRlciBDbGVtbQ0KPiA+IDxhbGV4YW5kZXIuY2xl bW1AaHVhd2VpLmNvbTxtYWlsdG86YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+PjsNCj4gPiBu ZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KPiA+IFN1YmplY3Q6IFJl OiBbTmV0Y29uZl0geWFuZy1wdXNoIGlzc3VlOiBlcnJvciBoYW5kbGluZw0KPiA+DQo+ID4gQW5k eSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+ IHdyb3RlOg0KPiA+ID4gSGksDQo+ID4gPg0KPiA+ID4gVGhlIHByb3RvY29sIGRlZmluZXMgaG93 IGVycm9yIGhhbmRsaW5nIGlzIGRvbmUsIG5vdCB0aGUgaW5kaXZpZHVhbA0KPiA+ID4gb3BlcmF0 aW9ucy4NCj4gPiA+IElmIHRoZSByZXF1ZXN0IGZhaWxzLCB0aGVuIGNsaWVudHMgZXhwZWN0IGFu IDxycGMtZXJyb3I+IGFuZCBzZXJ2ZXJzDQo+ID4gPiBhcmUgZGVzaWduZWQgdG8gc2VuZCBhbiA8 cnBjLWVycm9yPiB3aGVuIGEgY2xpZW50IHJlcXVlc3QgZmFpbHMuDQo+ID4NCj4gPiBBZ3JlZWQs IGFuZCBmb3IgUkVTVENPTkYsIHRoZSBIVFRQIGVycm9yIGNvZGVzIGFyZSB1c2VkLiAgQW4gSFRU UA0KPiA+IHJlcXVlc3QNCj4gPiB0aGF0IGZhaWxzIGRvZXMgbm90IHJldHVybiAyMDAgb2sgd2l0 aCBhIGJvZHkgdGhhdCBleHBsYWlucyB0aGF0IGl0DQo+ID4gYWN0dWFsbHkgd2FzDQo+ID4gYW4g ZXJyb3IuDQo+ID4NCj4gPiA+IElNTywgYSBzZXBhcmF0ZSBlcnJvciBoYW5kbGluZyBwcm9jZWR1 cmUgZm9yIGVhY2ggUlBDIGlzIG1vcmUgY2x1bmt5DQo+ID4gPiB0aGFuIGVycm9yLWluZm8uDQo+ ID4NCj4gPiArMQ0KPiA+DQo+ID4gU29tZSBhZGRpdGlvbmFsIGNvbW1lbnRzIGlubGluZS4NCj4g Pg0KPiA+DQo+ID4gPiA+IFdoaWxlIHBvc3NpYmxlLCB0aGUgc29sdXRpb24gb2YgaGF2aW5nIHRv IHJldHVybiBycGMtZXJyb3IgZXRjIGRvZXMNCj4gPiA+ID4gc3RyaWtlIG1lIGFzIHNvbWV3aGF0 IGNsdW5reS4gIFdoaWxlIGl0IGlzIHBvc3NpYmxlIHRvIGFkZCBhbg0KPiA+ID4gPiBlcnJvci1h cHAtdGFnLCBhbmQgbmVnb3RpYXRpb24gc3R1ZmYgYXMgZXJyb3ItaW5mbyAoYW5kIEkgYXBwcmVj aWF0ZQ0KPiA+ID4gPiB0aGUgc3VnZ2VzdGlvbiksIHRoYXQgc29sdXRpb24gd291bGQgbmVlZCB0 byBiZSBkZXNjcmliZWQgdXNpbmcgYQ0KPiA+ID4gPiBsb3Qgb2YgcHJvc2UgaW4gZGVzY3JpcHRp b24gc3RhdGVtZW50cyBhIGxhIFNNSXYyIChwcmVzdW1hYmx5IGFzDQo+ID4gPiA+IHBhcnQgb2Yg dGhlIFJQQyBkZXNjcmlwdGlvbiwgbm90IGFzIHBhcnQgb2YgZS5nLiB0aGUgaWRlbnRpdGllcywN Cj4gPiA+ID4gd2hpY2ggbWlnaHQgYmUgdXNlZCBpbiBhIG51bWJlciBvZiBwbGFjZXMsIG5vdCBq dXN0IHRoZQ0KPiA+ID4gPiBlcnJvci1hcHAtdGFnKS4NCj4gPg0KPiA+IElmIGJvdGggdGhlIGVy cm9yIGNvZGUgYW5kIGhpbnQgaXMgZGVmaW5lZCBpbiBhIHlhbmctZGF0YSAoaS5lLiwgbm90DQo+ ID4gdXNpbmcgdGhlDQo+ID4gZXJyb3ItYXBwLXRhZyksIHlvdSB3b3VsZCBkbzoNCj4gPg0KPiA+ ICAgeXg6eWFuZy1kYXRhIHN1YnNjcmlwdGlvbi1lcnJvciB7DQo+ID4gICAgIGNvbnRhaW5lciBz dWJzY3JpcHRpb24tZXJyb3Igew0KPiA+ICAgICAgIGxlYWYgZXJyb3ItY29kZSB7DQo+ID4gICAg ICAgICB0eXBlIGlkZW50aXR5IHsNCj4gPiAgICAgICAgICAgYmFzZSBlcnJvcjsNCj4gPiAgICAg ICAgIH0NCj4gPiAgICAgICB9DQo+ID4gICAgICAgY29udGFpbmVyIGhpbnRzIHsgLi4uIH0NCj4g PiAgICAgfQ0KPiA+ICAgfQ0KPiA+DQo+ID4gVGhlbiB5b3UgYXJlIHJpZ2h0LCB5b3UgaGF2ZSB0 byBkZXNjcmliZSBpbiBwcm9zZSB0aGF0IHRoaXMgeWFuZy1kYXRhDQo+ID4gc3RydWN0dXJlIGNh biBiZSBzZW50IGFzIGVycm9yLWluZm8uDQo+ID4NCj4gPg0KPiA+ID4gPiBJIGFtIG5vdCBzdXJl IHdoeSB0aGF0IHdvdWxkIG1ha2UgYW4gUlBDIGFueSBlYXNpZXIgdG8gaW1wbGVtZW50Lg0KPiA+ ID4gPiBUaGUgc2FtZSBjaGVja3Mgc3RpbGwgaGF2ZSB0byBiZSBtYWRlLg0KPiA+DQo+ID4gQWdy ZWVkLg0KPiA+DQo+ID4gPiA+IFdoeSB3b3VsZCB0aGUgcHJvcG9zZWQgc29sdXRpb24gbm90IGFj Y2VwdGFibGU/ICAgSWRlYWxseSBZQU5HIHdvdWxkDQo+ID4gPiA+IHByb3ZpZGUgYmV0dGVyIHN1 cHBvcnQgdG8gZm9ybWFsbHkgZGVmaW5lIGFwcGxpY2F0aW9uL1JQQy1zcGVjaWZpYw0KPiA+ID4g PiByZXR1cm4gY29kZXMgYW5kIGNvcm5lciBjb25kaXRpb25zIGV0Yy4NCj4gPg0KPiA+IEFsc28g YWdyZWVkLiAgQnV0IG9uY2Ugd2UgaGF2ZSB0aGF0LCBzdWNoIGEgc29sdXRpb24gd291bGQgbWFr ZSB1c2Ugb2YNCj4gPiB0aGUNCj4gPiBycGMtZXJyb3Igd2UgaGF2ZSAoZm9yIGJvdGggTkVUQ09O RiBhbmQgUkVTVENPTkYpLg0KPiA+DQo+ID4NCj4gPiAvbWFydGluDQo+ID4NCj4gPg0KPiA+ID4g PiBTaG9ydCBvZiB0aGF0LCB0aGUgcHJvcG9zZWQgc29sdXRpb24gb2YgYWRkaW5nIFJQQyBvdXRw dXQgcGFyYW1ldGVycw0KPiA+ID4gPiB0aGF0IGFyZSB1c2VkIGZvciB0aGUgcHVycG9zZSBvZiBp bmRpY2F0aW5nIHdoYXQgaXMgZ29pbmcgb24gYXQgdGhlDQo+ID4gPiA+IGFwcGxpY2F0aW9uIGxl dmVsIHNpbXBseSBtYWtlcyB0aGVtIHBhcnQgb2YgdGhlIHNlbWFudGljcyBvZiB0aGUNCj4gPiA+ ID4gc3BlY2lmaWMgUlBDIGl0c2VsZi4gIEl0IGlzIG5vdCBOZXRjb25m4oCZcyByb2xlIHRvIGRl ZmluZSB3aGF0IGFuIFJQQw0KPiA+ID4gPiBjYW4gb3IgY2Fubm90IGRvLCBqdXN0IGxpa2UgaXQg Y2Fubm90IGRlZmluZSB3aGF0IGEgcGFydGljdWxhciBsZWFmDQo+ID4gPiA+IG1heSBvciBtYXkg bm90IHJlcHJlc2VudC4gIFRoYXQgaXMgcGFydCBvZiB0aGUgUlBDIGRlZmluaXRpb24uDQo+ID4g PiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IEJhc2ljYWxseSwgd2hhdCB3ZSBhcmUgZGlz Y3Vzc2luZyBoZXJlIGlzIGJlaGF2aW9yIG9mIHN1YnNjcmlwdGlvbg0KPiA+ID4gPiBjb25maWd1 cmF0aW9uIHVuZGVyIGNvcm5lciBjb25kaXRpb25zLiAgVGhlIGZhY3QgdGhhdCBubw0KPiA+ID4g PiBzdWJzY3JpcHRpb24gaXMgY3JlYXRlZCBiZWNhdXNlIGl0IHdvdWxkIHJlc3VsdCBpbiBhbiB1 bmFjY2VwdGFibGUNCj4gPiA+ID4gdm9sdW1lIG9mIHVwZGF0ZXMgZm9yIGEgc3BlY2lmaWMgaW1w bGVtZW50YXRpb24gaXMgZGlmZmVyZW50IGZyb20gYW4NCj4gPiA+ID4gZXJyb3IgY29uZGl0aW9u IHN1Y2ggYXMgYSBtYWxmb3JtZWQgbWVzc2FnZSB0aGF0IGlzIG1pc3NpbmcgYQ0KPiA+ID4gPiBy ZXF1aXJlZCBtZXNzYWdlLWlkLCBvciB3aGVyZSBhIHZhbHVlIHZpb2xhdGVzIGEgY29uc3RyYWlu dA0KPiA+ID4gPiBzcGVjaWZpZWQgaW4gYSBNVVNULWNvbmRpdGlvbi4gIEluIG91ciBjYXNlLCB3 aGF0IGlzIGJlaW5nIGRlc2NyaWJlZA0KPiA+ID4gPiBhcmUNCj4gPiBzcGVjaWZpYyBjb25kaXRp b25zIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciwgYWJvdmUgdGhlDQo+ID4gPiA+IE5ldGNvbmYv UmVzdGNvbmYgZ2VuZXJpYyB2YWxpZGF0aW9uIGluZnJhc3RydWN0dXJlLiAgVGhlIG9wZXJhdGlv bg0KPiA+ID4gPiBkb2VzDQo+ID4gPiA+IG5vdCDigJx3b3Jr4oCdIGluIHRoZSBzZW5zZSB0aGF0 IGl0IGRvZXMgbm90IHJlc3VsdCBpbiBhbiBhY3RpdmUNCj4gPiA+ID4gc3Vic2NyaXB0aW9uLCBi dXQgaXQgZG9lcyB3b3JrIGluIHRoZSBzZW5zZSB0aGF0IHRoZSBiZWhhdmlvciBpcw0KPiA+ID4g PiB2ZXJ5IHdlbGwgZGVmaW5lZCBpbiB0ZXJtcyBvZiB0aGUgZWZmZWN0IHRoYXQgdGhlIFJQQyBo YXMgKGkuZS4gdGhlDQo+ID4gPiA+IGVmZmVjdCBpcyB0aGF0IGl0IHJlc3VsdCBpbiBjcmVhdGlv biBvZiBhIHN1YnNjcmlwdGlvbiwgaWYgY2VydGFpbg0KPiA+ID4gPiBjb25kaXRpb25zIGFyZSBt ZXQsIGFuZCBpdCBkb2VzIG5vdCByZXN1bHQgaW4gY3JlYXRpb24gb2YgYQ0KPiA+ID4gPiBzdWJz Y3JpcHRpb24gaW4gY2FzZSBjZXJ0YWluIGNvbmRpdGlvbnMgYXJlIG5vdCBtZXQpLiAgV2h5IHNo b3VsZA0KPiA+ID4gPiBOZXRjb25mIHJlc3RyaWN0IHdoYXQgYW4gUlBDIGNhbiBvciBjYW5ub3Qg ZG8/ICBUaGlzIGlzIGFsbA0KPiA+ID4gPiBhcHBsaWNhdGlvbi0NCj4gPiBzcGVjaWZpYy4NCj4g PiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gLS0tIEFsZXgNCj4gPiA+ID4NCj4gPiA+ ID4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gKkZyb206KiBOZXRjb25mDQo+ ID4gPiA+ICpbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0Y29uZi1i b3VuY2VzQGlldGYub3JnPl0gKk9uDQo+ID4gPiA+ICpCZWhhbGYgT2YNCj4gPiA+ID4gKkFuZHkg Qmllcm1hbg0KPiA+ID4gPiAqU2VudDoqIE1vbmRheSwgRGVjZW1iZXIgMDQsIDIwMTcgOToxNSBB TQ0KPiA+ID4gPiAqVG86KiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbTxtYWlsdG86 bWJqQHRhaWwtZi5jb20+Pg0KPiA+ID4gPiAqQ2M6KiBOZXRjb25mIDxuZXRjb25mQGlldGYub3Jn PG1haWx0bzpuZXRjb25mQGlldGYub3JnPj4NCj4gPiA+ID4gKlN1YmplY3Q6KiBSZTogW05ldGNv bmZdIHlhbmctcHVzaCBpc3N1ZTogZXJyb3IgaGFuZGxpbmcNCj4gPiA+ID4NCj4gPiA+ID4NCj4g PiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gT24gTW9u LCBEZWMgNCwgMjAxNyBhdCA0OjU1IEFNLCBNYXJ0aW4gQmpvcmtsdW5kDQo+ID4gPiA+IDxtYmpA dGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwtZi5jb20+Pg0KPiA+IHdyb3RlOg0KPiA+ID4gPg0K PiA+ID4gPiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbTxtYWlsdG86YW5keUB5dW1h d29ya3MuY29tPj4gd3JvdGU6DQo+ID4gPiA+ID4gSGksDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJ TU8gdGhlIHNwZWNpYWwgZXJyb3IgaGFuZGxpbmcgaW4gWUFORyBQdXNoIGlzIG5vdCBhY2NlcHRh YmxlDQo+ID4gPiA+ID4gYmVjYXVzZSBpdCB2aW9sYXRlcyBORVRDT05GIGFuZCBSRVNUQ09ORiBl cnJvciBoYW5kbGluZyBwcm9jZWR1cmVzLg0KPiA+ID4gPiA+IE5FVENPTkYgc2F5cyBpZiB0aGUg b3BlcmF0aW9uIGRvZXMgbm90IHdvcmsgZm9yIGFueSByZWFzb24gYW4NCj4gPiA+ID4gPiA8cnBj LWVycm9yPiBlbGVtZW50IFNIT1VMRCBiZSByZXR1cm5lZC4NCj4gPiA+ID4NCj4gPiA+ID4gSSBm dWxseSBhZ3JlZSwgYW5kIEkgaGF2ZSBwb2ludGVkIHRoaXMgb3V0IHNldmVyYWwgdGltZXMgaW4g bXkNCj4gPiA+ID4gcmV2aWV3cy4gIFRoZSBwcm9ibGVtIGlzIGFjdHVhbGx5IGluIHN1YnNjcmli ZWQgbm90aWZpY2F0aW9ucywgYW5kIEkNCj4gPiA+ID4gdGhpbmsgRXJpYyBpcyB0cmFja2luZyB0 aGF0IGlzc3VlLg0KPiA+ID4gPg0KPiA+ID4gPiBUcnlpbmcgdG8gYmUgY29uc3RydWN0aXZlLCBJ IHRoaW5rIHRoYXQgdGhlIGV4aXN0aW5nIG1lY2hhbmlzbXMgaW4NCj4gPiA+ID4gWUFORyBjYW4g YmUgdXNlZCB0byBhY2hpZXZlIHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHkgdGhhdCB0aGVzZSBkcmFm dHMNCj4gPiA+ID4gdHJ5IHRvIGFjaGlldmUuICBTcGVjaWZpY2FsbHk6DQo+ID4gPiA+DQo+ID4g PiA+ICAgMS4gVXNlIGlkZW50aXRpZXMganVzdCBsaWtlIHRoZSBvbmVzIHlvdSBoYXZlDQo+ID4g PiA+ICAgICAgKCJ1bnN1cHBvcnRhYmxlLXZvbHVtZSIsICJmaWx0ZXItdW5hdmFpbGFibGUiIGV0 YyksIGJ1dCBhZGQgdGV4dA0KPiA+ID4gPiAgICAgIHRoYXQgZXhwbGFpbnMgdGhhdCB0aGVzZSBp ZGVudGl0aWVzIGFyZSBzZW50IGFzICJlcnJvci1hcHAtdGFnIg0KPiA+ID4gPiAgICAgIGluICJy cGMtZXJyb3IiLCBlbmNvZGVkIHRvIGEgc3RyaW5nIGFzIDxtb2R1bGU+OjxpZGVudGl0eT4uICBU aGlzDQo+ID4gPiA+ICAgICAgd29ya3MgZm9yIGJvdGggTkVUQ09ORiBhbmQgUkVTVENPTkYuDQo+ ID4gPiA+DQo+ID4gPiA+ICAgMi4gRm9yIHRoZSAiaGludHMiIGV4dHJhIGluZm8gdGhhdCB5b3Ug cmV0dXJuLCBkZWZpbmUgYSAieWFuZy1kYXRhIg0KPiA+ID4gPiAgICAgIHN0cnVjdHVyZSB3aXRo IHRoZSBoaW50cywgYW5kIGV4cGxhaW4gaW4gdGV4dCB0aGF0IHRoaXMgc3RydWN0dXJlDQo+ID4g PiA+ICAgICAgaXMgcmV0dXJuZWQgaW4gImVycm9yLWluZm8iLiAgVGhpcyB3b3JrcyBmb3IgYm90 aCBORVRDT05GIGFuZA0KPiA+ID4gPiAgICAgIFJFU1RDT05GLg0KPiA+ID4gPg0KPiA+ID4gPg0K PiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiArMQ0KPiA+ID4gPg0KPiA+ID4gPg0K PiA+ID4gPg0KPiA+ID4gPiBJZiB0aGUgZXJyb3IgaGFuZGxpbmcgd2FzIGRvbmUgY29ycmVjdGx5 IHRoZW4gdGhlIHNhbWUgcHJvY2VkdXJlcw0KPiA+ID4gPiBjb3VsZCBiZQ0KPiA+ID4gPg0KPiA+ ID4gPiBhcHBsaWVkIHRvIDxlZGl0LWNvbmZpZz4gZmFpbHVyZXMgZm9yIGNvbmZpZ3VyZWQgc3Vi c2NyaXB0aW9ucy4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4N Cj4gPiA+ID4NCj4gPiA+ID4gQXMgYW4gYWx0ZXJuYXRpdmUgdG8gMSwgeW91IGNhbiBwdXQgdGhl IGVycm9yIGlkZW50aXRpeXJlZiBpbiB0aGUNCj4gPiA+ID4gInlhbmctZGF0YSIgc3RydWN0dXJl LCBhbmQgc2VuZCBib3RoIHRoZSBpZGVudGl0aXlyZWYgYW5kIGhpbnRzIGluDQo+ID4gPiA+ICJl cnJvci1pbmZvIi4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gL21hcnRpbg0KPiA+ID4gPg0K PiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBBbmR5DQo+ID4gPiA+ DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+ID4g VGhlIDxlc3RhYmxpc2gtc3Vic2NyaXB0aW9uPiByZXR1cm5zIGRhdGEgZXZlbiBvbiBlcnJvci4N Cj4gPiA+ID4gPiBJbnN0ZWFkIG9mIHRoZSBjb21tb24gZXJyb3ItdGFnLCBlcnJvci1pbmZvLCBh bmQgb3RoZXIgZmllbGRzLA0KPiA+ID4gPiA+IHRoZXJlIGlzIGEgc3Vic2NyaXB0aW9uLXJlc3Vs dCBsZWFmLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSWYgYW55IGNsaWVudCAob3IgZXZlbiBzZXJ2 ZXIpIGZ1bmN0aW9uYWxpdHkgdXNlcyB0aGUgTkVUQ09ORiBhbmQNCj4gPiA+ID4gPiBSRVNUQ09O RiBzdGFuZGFyZCBlcnJvciBoYW5kbGluZywgdGhlbiBzdWJzY3JpcHRpb24tcmVzdWx0IHdpbGwN Cj4gPiA+ID4gPiBub3QgYmUgc2VudCBvciBleHBlY3RlZCBhcyBhbiBlcnJvciByZXNwb25zZS4g RGVwZW5kaW5nIG9uIHRoZQ0KPiA+ID4gPiA+IHNlcnZlciBpbXBsZW1lbnRhdGlvbiwgdGhlIGNv ZGUgdGhhdCBrbm93cyBhYm91dA0KPiA+ID4gPiA+IGVzdGFibGlzaC1zdWJzY3JpcHRpb24gbWF5 IG5vdCBnZXQgY2FsbGVkIGJlY2F1c2UgY29tbW9uIGVycm9yDQo+ID4gPiA+ID4gaGFuZGxpbmcg Y29kZSBoYXMgYWxyZWFkeSBkZXRlcm1pbmVkIHRoZXJlIGlzIGFuIDxycGMtZXJyb3I+IHRvDQo+ ID4gPiA+ID4gc2VuZCBpbnN0ZWFkIG9mIGEgZGF0YSByZXNwb25zZS4NCj4gPiA+ID4gPg0KPiA+ ID4gPiA+IEV4cGVjdCB0aGF0IHNvbWUgc2VydmVycyBhcmUgbmV2ZXIgZ29pbmcgdG8gc2VuZCBk YXRhIG9uIGFuDQo+ID4gPiA+ID4gb3BlcmF0aW9uIGZhaWx1cmUsIGFuZCB3aWxsIG9ubHkgc2Vu ZCA8cnBjLWVycm9yPiBpbnN0ZWFkLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ RnJvbSBzZWMuIDMuODoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgIEZvciBpbnN0YW5jZSwgZm9y IHRoZSBmb2xsb3dpbmcgcmVxdWVzdDoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IDxuZXRjb25mOnJw YyBtZXNzYWdlLWlkPSIxMDEiDQo+ID4gPiA+ID4gICAgeG1sbnM6bmV0Y29uZj0idXJuOmlldGY6 cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4NCj4gPiA+ID4gPiAgICA8ZXN0YWJsaXNo LXN1YnNjcmlwdGlvbg0KPiA+ID4gPiA+ICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnht bDpuczp5YW5nOmlldGYtc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zIg0KPiA+ID4gPiA+ICAgICAg ICB4bWxuczp5cD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYteWFuZy1wdXNoIj4N Cj4gPiA+ID4gPiAgICAgICA8eXA6ZGF0YXN0b3JlPg0KPiA+ID4gPiA+ICAgICAgICAgPHlwOnNv dXJjZSB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtZGF0YXN0b3JlcyI+ DQo+ID4gPiA+ID4gICAgICAgICAgIG9wZXJhdGlvbmFsDQo+ID4gPiA+ID4gICAgICAgICA8L3lw OnNvdXJjZT4NCj4gPiA+ID4gPiAgICAgICAgIDx5cDpzdWJ0cmVlLWZpbHRlciBuZXRjb25mOnR5 cGU9InhwYXRoIg0KPiA+ID4gPiA+ICAgICAgICAgICAgIHhtbG5zOmV4PSJodHRwOi8vZXhhbXBs ZS5jb20vc2FtcGxlLWRhdGEvMS4wIg0KPiA+ID4gPiA+ICAgICAgICAgICAgIHNlbGVjdD0iL2V4 OmZvbyIvPg0KPiA+ID4gPiA+ICAgICAgIDwveXA6ZGF0YXN0b3JlPg0KPiA+ID4gPiA+ICAgICAg IDx5cDpwZXJpb2Q+NTAwPC95cDpwZXJpb2Q+DQo+ID4gPiA+ID4gICAgPC9lc3RhYmxpc2gtc3Vi c2NyaXB0aW9uPg0KPiA+ID4gPiA+IDwvbmV0Y29uZjpycGM+DQo+ID4gPiA+ID4NCj4gPiA+ID4g PiAgICAgICAgICAgICAgICAgIEZpZ3VyZSAzOiBFc3RhYmxpc2gtU3Vic2NyaXB0aW9uIGV4YW1w bGUNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgIHRoZSBwdWJsaXNoZXIgbWlnaHQgcmV0dXJuOg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA8cnBjLXJlcGx5IG1lc3NhZ2UtaWQ9IjEw MSINCj4gPiA+ID4gPiAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6 YmFzZToxLjAiPg0KPiA+ID4gPiA+ICAgIDxzdWJzY3JpcHRpb24tcmVzdWx0DQo+ID4gPiA+ID4g ICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnlhbmc6aWV0Zi1zdWJzY3JpYmVk LW5vdGlmaWNhdGlvbnMiDQo+ID4gPiA+ID4gICAgICAgIHhtbG5zOnlwPSJ1cm46aWV0ZjpwYXJh bXM6eG1sOm5zOnlhbmc6aWV0Zi15YW5nLXB1c2giPg0KPiA+ID4gPiA+ICAgICAgeXA6cGVyaW9k LXVuc3VwcG9ydGVkDQo+ID4gPiA+ID4gICAgPC9zdWJzY3JpcHRpb24tcmVzdWx0Pg0KPiA+ID4g PiA+ICAgIDxwZXJpb2QtaGludCB4bWxuczoidXJuOmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmll dGYteWFuZy1wdXNoIj4NCj4gPiA+ID4gPiAgICAgICAyMDAwDQo+ID4gPiA+ID4gICAgPC9wZXJp b2QtaGludD4NCj4gPiA+ID4gPiA8L3JwYy1yZXBseT4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAg ICAgICAgICAgICAgICAgICAgIEZpZ3VyZSA0OiBFcnJvciByZXNwb25zZSBleGFtcGxlDQo+ID4g PiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQlRXLCBhbGwgdGhlIGZpbHRl ciBleGFtcGxlcyBzZWVtIHRvIGJlIHdyb25nLCBpbmNsdWRpbmcgdGhlIG9uZQ0KPiA+ID4gPiA+ IGFib3ZlDQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE9MRDoNCj4gPiA+ID4gPg0K PiA+ID4gPiA+ICAgICAgICAgPHlwOnN1YnRyZWUtZmlsdGVyIG5ldGNvbmY6dHlwZT0ieHBhdGgi DQo+ID4gPiA+ID4gICAgICAgICAgICAgeG1sbnM6ZXg9Imh0dHA6Ly9leGFtcGxlLmNvbS9zYW1w bGUtZGF0YS8xLjAiDQo+ID4gPiA+ID4gICAgICAgICAgICAgc2VsZWN0PSIvZXg6Zm9vIi8+DQo+ ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE5FVzoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gICAgICAgICA8eXA6c3VidHJlZS1maWx0ZXI+DQo+ID4gPiA+ID4gICAgICAg ICAgICA8ZXg6Zm9vIHhtbG5zOmV4PSJodHRwOi8vZXhhbXBsZS5jb20vc2FtcGxlLWRhdGEvMS4w Ig0KPiA+ID4gPiA+IC8+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAgICAgICAgIDwveXA6c3VidHJl ZS1maWx0ZXI+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEFuZHkNCj4gPiA+ID4N Cj4gPiA+ID4NCj4gPiA+ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+IE5ldGNvbmZAaWV0Zi5v cmc8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZg0KPiANCg== From nobody Wed Dec 6 10:05: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 CA804127286 for ; Wed, 6 Dec 2017 10:05:48 -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_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 itWsvgVaFpIj for ; Wed, 6 Dec 2017 10:05: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 26E4F1241F5 for ; Wed, 6 Dec 2017 10:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8502; q=dns/txt; s=iport; t=1512583546; x=1513793146; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qUFcpz24fv0DDmzZPJvj+7MuTS5XzCrK+WVidEQjVHM=; b=doPgJXfDVk2qRUsIQ/zY096CI7o5386lUZYETwGIH1J9RaomRyqktT+i hrgZ24d0U48eYJLHRZ4s+RHmkorb7HvOBini/lwixdH3tcBiWSfnwMlEN PSBfL/eCQpO+K4pcUyTNFhTItZtTzGCf9xauhvTDbQgLLF2SiNCwxL9Tf Y=; X-IronPort-AV: E=Sophos;i="5.45,369,1508803200"; d="scan'208";a="327426160" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Dec 2017 18:05:08 +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 vB6I580P001780 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Dec 2017 18:05:08 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 6 Dec 2017 13:05:07 -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, 6 Dec 2017 13:05:07 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Juergen Schoenwaelder CC: Balazs Lengyel , Martin Bjorklund , "netconf@ietf.org" Thread-Topic: [Netconf] "notifiable-on-change" Thread-Index: AQHTbnD+9I2b119a1UiTPWuIbdyqC6M2cf+AgABtkwCAAAWHgIAAC1iA Date: Wed, 6 Dec 2017 18:05:07 +0000 Message-ID: <649B1612-C107-4194-A2A2-A9305887AD0B@cisco.com> References: <20171128.103735.1654378548309425095.mbj@tail-f.com> <81f49c62-e1fe-4a90-a93f-c7fd55229100@ericsson.com> <20171206.100112.298803456348365967.mbj@tail-f.com> <4aacc669-5470-bef5-a3e7-fd9047c72562@ericsson.com> <20171206172433.aeysedjtcm3u7rf3@elstar.local> In-Reply-To: <20171206172433.aeysedjtcm3u7rf3@elstar.local> 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.160.20] Content-Type: text/plain; charset="utf-8" Content-ID: <58A2DFC8E7DC4146A5FEF13870D62F6B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] "notifiable-on-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, 06 Dec 2017 18:05:49 -0000 SnVlcmdlbiwNCg0KVGhhbmtzIGZvciB0aGlzLiBUaGFua3MgZm9yIHBpY2tpbmcgdXAgdGhhdCBh IHRvcCBsZXZlbCBjb250YWluaW5nIGVsZW1lbnQgYXMgeW91IGhhdmUgaXMgbmVjZXNzYXJ5LiBP dGhlcndpc2Ugd2Ugd291bGQgd291bGQgYmUgbGltaXRlZCB0byBhIHNpbmdsZSBtb2R1bGUsIHdo aWNoIGlzIG5vdCBzbyB1c2VmdWwuIEkgZG9u4oCZdCB0aGluayB0aGF0IHRoZSB0b3AgbGV2ZWwg dGFnIHNob3VsZCBiZSDigJxvcGVyYXRpb25hbOKAnSwgdGhvdWdoLiBNYXliZSBzb21ldGhpbmcg bW9yZSBsaWtlIOKAnDxkYXRhc3RvcmUtY29udGVudHM+4oCdPw0KDQpDaGVlcnMsDQoNCkVpbmFy DQoNCg0KPiBPbiA2IERlYyAyMDE3LCBhdCAxNzoyNCwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxq LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiANCj4gSXQgcHJv YmFibHkgbWFrZXMgc2Vuc2UgdG8gd3JpdGUgYSBkb2N1bWVudCB0aGF0IGRlZmluZXMgaG93IGRh dGFzdG9yZQ0KPiBjb250ZW50IChvciBzdWJzZXRzIG9mIGRhdGFzdG9yZSBjb250ZW50KSBpbiBn ZW5lcmFsIGNhbiBiZSBzdG9yZWQgaW4NCj4gYSBmaWxlLiBXaXRoIHRoYXQgaW4gcGxhY2UsIHdl IGtub3cgaG93IHRvIHN0b3JlIGlldGYteWFuZy1saWJyYXJ5DQo+IGNvbnRlbnQgYW5kIGFzIGEg c2lkZSBlZmZlY3Qgd2Uga25vdyBob3cgdG8gc3RvcmUgZGF0YXN0b3JlIGNvbnRlbnQNCj4gdXNl ZCBhcyBleGFtcGxlcyBmb3IgWUFORyBkYXRhIG1vZGVscyBhbmQgbGlrZWx5IHNldmVyYWwgb3Ro ZXINCj4gcHVycG9zZXMuIFRoZSByb290IG9mIHRoZSBYTUwgZG9jdW1lbnQgd291bGQgbGlrZSBi ZSB0aGUgZGF0YXN0b3JlDQo+IGlkZW50aXR5IG5hbWUgaW4gdGhlIFlBTkcgbW9kdWxlIG5hbWVz cGFjZSBkZWZpbmluZyB0aGUgaWRlbnRpdHkNCj4gDQo+IDw/eG1sIHZlcnNpb249IjEuMCI/Pg0K PiA8b3BlcmF0aW9uYWwgeG1sbnM9ImlldGYtZGF0YXN0b3JlcyI+DQo+ICA8bW9kdWxlcy1zdGF0 ZSB4bWxucz0iaWV0Zi15YW5nLWxpYnJhcnkiPg0KPiAgPC9tb2R1bGVzLXN0YXRlPg0KPiA8L29w ZXJhdGlvbmFsPg0KPiANCj4gUmlnaHQgbm93LCBpdCBzZWVtcyBJIGhhdmUgdG8gZmVlZCBpbnN0 YW5jZSBkYXRhIGluIHNsaWdodGx5IGRpZmZlcmVudA0KPiBmb3JtYXRzIGludG8gdG9vbHMuIEl0 IHdvdWxkIGJlIG5pY2UgaWYgdG9vbHMgY291bGQgYWN0dWFsbHkgY29udmVyZ2UNCj4gdG8gY29t bW9uIGZvcm1hdHMuIFtJIGFtIHBhcnRpY3VsYXJseSBpbnRlcmVzdGVkIGluIHZhbGlkYXRpb25z IG9mDQo+IGV4YW1wbGVzLl0NCj4gDQo+IC9qcw0KPiANCj4gT24gV2VkLCBEZWMgMDYsIDIwMTcg YXQgMDU6MDQ6NDRQTSArMDAwMCwgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pIHdyb3Rl Og0KPj4gSSBhZ3JlZSB3aXRoIEJhbGF6cyB0aGF0IHdlIHJlYWxseSB3YW50IHRoaXMgaXNzdWUg dG8gYmUgbmFpbGVkIHJpZ2h0IGZvcm0gdGhlIHN0YXJ0Lg0KPj4gDQo+PiBJIHdvdWxkIGJlIGhh cHB5IHdpdGggZGVmaW5pbmcgYW4gYXVnbWVudGF0aW9uIHRvIGlldGYteWFuZy1saWJyYXJ5IHRv IGFsbG93IGRldmljZXMgdG8gcmV0dXJuIHRoZSBkYXRhIG9uIHdoYXQgY29udGVudCBpcyBub3Rp ZmlhYmxlIC1vbi1jaGFuZ2Ugbm90IHRoaXMgc3BlY2lmaWMgZGV2aWNlIGF0IHRoZSBzcGVjaWZp YyB0aW1lIHRoZSBkYXRhIHdhcyByZXRyaWV2ZWQuDQo+PiANCj4+IEZvciBvZmZsaW5lIGNvbnN1 bXB0aW9uLCB3ZSBzaG91bGQgZGVmaW5lIHRoYXQgYW4gWE1MIGRvY3VtZW50IGNvbmZvcm1pbmcg dG8gdGhlIFhNTCBzY2hlbWEgZGVmaW5lZCBieSBpZXRmLXlhbmctbGlicmFyeSArIGF1Z21lbnRh dGlvbnMgaXMgYW4gYXBwcm9wcmlhdGUgZm9ybWF0LiBUaGlzIFhNTCBkb2N1bWVudCB3b3VsZCBo YXZlIGF0IGl0cyByb290IHRoZSBlbGVtZW50IGlldGYteWFuZy1saWJyYXJ5Om1vZHVsZXMtc3Rh dGUuIEhvdyB0aGlzIFhNTCBkb2N1bWVudCBpcyBwcm92aWRlZCBpcyBvdXQgb2Ygc2NvcGUuIEl0 IG1heSBiZSBhIGZsYXQgZmlsZSwgaXQgY291bGQgY29tZSBmcm9tIGEgVVJMLCB3aGF0ZXZlci4N Cj4+IA0KPj4gSXMgdGhpcyBhbmQgYWNjZXB0YWJsZSBhcHByb2FjaD8NCj4+IA0KPj4gQ2hlZXJz LA0KPj4gDQo+PiBFaW5hcg0KPj4gDQo+PiANCj4+PiBPbiA2IERlYyAyMDE3LCBhdCAxMDozMiwg QmFsYXpzIExlbmd5ZWwgPGJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+Pj4g DQo+Pj4gDQo+Pj4gT24gMjAxNy0xMi0wNiAxMDowMSwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToN Cj4+Pj4gQmFsYXpzIExlbmd5ZWwgPGJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbT4gd3JvdGU6 DQo+Pj4+PiBJIHZlcnkgc3Ryb25nbHkgb2JqZWN0IHRvIGV4Y2x1ZGluZyB0aGUgaXNzdWUuIFRo ZXJlIGlzIGEgc3Ryb25nIGFuZA0KPj4+Pj4gaW1tZWRpYXRlIG5lZWQgdG8gYmUgYWJsZSB0byBz cGVjaWZ5IGluIHZlbmRvciBkZXNpZ24gdGltZSBmb3Igd2hpY2gNCj4+Pj4+IGRhdGEgbm9kZXMg d2lsbCB0aGVyZSBiZSBvbi1jaGFuZ2Ugbm90aWZpY2F0aW9uIGJlIGdlbmVyYXRlZC4NCj4+Pj4+ IA0KPj4+Pj4gV2hlbiBhIHZlbmRvciByZWxlYXNlIGEgcHJvZHVjdCB0aGV5IGtub3cgd2hpY2gg bm9kZXMgd2lsbCBlbWl0DQo+Pj4+PiBvbi1jaGFuZ2Ugbm90aWZpY2F0aW9ucyBpbiBkZXNpZ24g dGltZS4gU3lzdGVtIGludGVncmF0b3JzIG5lZWQgdG8NCj4+Pj4+IGtub3cgdGhpcy4gUHJvdmlk aW5nIHRoZSBzYW1lIGluZm9ybWF0aW9uIGluIHJ1bi10aW1lIGFzIGluc3RhbmNlIGRhdGENCj4+ Pj4+IGlzIG5vdCBhIGdvb2Qgc29sdXRpb24gZWl0aGVyIGFzIHlvdSB3b3VsZCBuZWVkIHRvIGdl dCBhIHJlYWwgbm9kZSB0bw0KPj4+Pj4gcmVhZCB0aGUgZGF0YSBmcm9tLg0KPj4+PiBUaGUgc2Ft ZSBhcmd1bWVudCBhcHBsaWVzIHRvIHdoaWNoIFlBTkcgbW9kdWxlcywgZmVhdHVyZXMgYW5kDQo+ Pj4+IGRldmlhdGlvbnMgYSBwcm9kdWN0IHN1cHBvcnRzLiAgSW4gU01JdjIgd2UgaGFkIEFHRU5U LUNBUEFCSUxJVElFUw0KPj4+PiB3aGljaCB3YXMgYW4gb2ZmLWxpbmUgZG9jdW1lbnQgd2l0aCB0 aGlzIGluZm9ybWF0aW9uLiAgVGhlIGV4cGVyaWVuY2UNCj4+Pj4gc2VlbXMgdG8gYmUgdGhhdCBp dCB3YXMgcmFyZWx5IHVzZWQgYnkgbWFuYWdlcnMuICBJbiBZQU5HIHdlIHByb3ZpZGUNCj4+Pj4g dGhpcyBpbmZvcm1hdGlvbiBvbi1saW5lIHdpdGggdGhlIFlBTkcgbGlicmFyeSAoYW5kIGF0IGxl YXN0IG91cg0KPj4+PiBleHBlcmllbmNlIHNvIGZhciBpcyB0aGF0IHRoaXMgKmlzKiB1c2VkIGJ5 IGNsaWVudHMpLg0KPj4+IEJBTEFaUzogSSBhZ3JlZSB0aGF0IHlhbmctbGlicmFyeSBpcyBnb29k LiBJIGFtIG5vdCBhcmd1aW5nIGFnYWluc3QgaXQuIEp1c3QgaXQgaXMNCj4+PiBub3QgZW5vdWdo LCBiZWNhdXNlIGl0IGlzIG9ubHkgYXZhaWxhYmxlIGluIHJ1bi10aW1lLCB0b28gbGF0ZS4NCj4+ Pj4gSXQgd291bGQgcHJvYmFibHkgYmUgYSBnb29kIGlkZWEgdG8gY29tYmluZSB0aGVzZSB0d28g YXBwcm9hY2hlcy4NCj4+PiBCQUxBWlM6IEkgYWdyZWUuIEVhcmx5IGRvY3VtZW50YXRpb24gYW5k IG9uLWxpbmUgZG9jdW1lbnRhdGlvbg0KPj4+IGNvbWJpbmVkIHdvdWxkIGJlIGEgZ29vZCBzb2x1 dGlvbi4NCj4+PiBJTUhPIHRoZSAyIGNvdWxkIHVzZSB0aGUgc2FtZSBmb3JtYXQuIEUuZy4NCj4+ PiAtIFB1dCBhbGwgc2VydmVyLWNhcGFiaWxpdGllcyBpbnRvIHlhbmctbGlicmFyeSAocG9zc2li bHkgYXVnbWVudGluZyBpdCB3aGVyZSBuZWVkZWQpDQo+Pj4gLSBkZWZpbmUgYW4gb2ZmLWxpbmUg Zm9ybWF0IGZvciBZQU5HIEluc3RhbmNlIGRhdGENCj4+PiAgICBlLmcuIHRoZSBkYXRhIHNlY3Rp b24gb2YgYSA8Z2V0PiByZXBseSBUaGlzIHdheSB5b3UgZG9uJ3QgZXZlbiBoYXZlIHRvIGRlZmlu ZSBhIHJlYWwgbmV3IGZvcm1hdA0KPj4+IC0gZGVjbGFyZSB0aGF0IG9mZi1saW5lIGluc3RhbmNl IGRhdGEgZnJvbSB5YW5nbGliIGlzIHRoZSBmb3JtYXQgdG8gZGVmaW5lIHNlcnZlciBjYXBhYmls aXRpZXMNCj4+Pj4gDQo+Pj4+IEkgdGhpbmsgdGhhdCB0aGlzIHdvdWxkIGJlIGZhaXJseSBzdHJh aWdodC1mb3J3YXJkLiAgQXMgYSBmaXJzdA0KPj4+PiBhcHByb3hpbWF0aW9uLCBzdXBwb3NlIHdl IGhhZCBhIHN0YW5kYXJkIGZpbGUgZm9ybWF0IGZvciBhDQo+Pj4+ICJzZXJ2ZXItY2FwYWJpbGl0 aWVzIiBkb2N1bWVudC4gIEl0IGNvdWxkIGJlIHNvbWV0aGluZyBsaWtlIHRoaXM6DQo+Pj4+IA0K Pj4+PiAgPHNlcnZlci1jYXBhYmlsaXRpZXM+DQo+Pj4+ICAgIC8vIHRoaXMgaWRlbnRpZmllciBt dXN0IGFsc28gYmUgYXZhaWxhYmxlIG9uIHRoZSBkZXZpY2UsIHNvIHRoYXQNCj4+Pj4gICAgLy8g YSBjbGllbnQgY2FuIG1hdGNoIHRoZSBjYXBhYmlsaXR5IGRvY3VtZW50IHdpdGggdGhlIGRldmlj ZS4NCj4+Pj4gICAgPHNlcnZlci1jYXBhYmlsaXR5LWlkZW50aWZpZXI+c29tZSB1bmlxdWUgaWRl bnRpZmllcjwvPg0KPj4+PiANCj4+Pj4gICAgLy8gbWV0YS1kYXRhIGdvZXMgaGVyZQ0KPj4+PiAg ICA8dmVuZG9yPiAuLi4gPC92ZW5kb3I+DQo+Pj4+ICAgIDxwcm9kdWN0LW5hbWU+IC4uLiA8L3By b2R1Y3QtbmFtZT4NCj4+Pj4gICAgLi4uDQo+Pj4+IA0KPj4+PiAgICA8eWFuZy1saWJyYXJ5Pg0K Pj4+PiAgICAgIC8vIHRoZSBjb250ZW50cyBvZiB5YW5nLWxpYnJhcnkgZnJvbSB0aGlzIHByb2R1 Y3QNCj4+Pj4gICAgICAvLyB3aXRoIG1vZHVsZXMsIGZlYXR1cmVzLCBkZXZpYXRpb25zDQo+Pj4+ ICAgICAgLy8gLi4uIGFuZCBwb3NzaWJseSBvbi1jaGFuZ2UgaW5mbw0KPj4+PiAgICA8L3lhbmct bGlicmFyeT4NCj4+Pj4gIDwvc2VydmVyLWNhcGFiaWxpdGllcz4NCj4+Pj4gDQo+Pj4+IE5vdywg dGhpcyB3b24ndCBiZSB1c2VmdWwgZm9yIGFsbCBzeXN0ZW1zLCBmb3IgZXhhbXBsZSBpZiB0aGUg c2VydmVyDQo+Pj4+IGlzIHZlcnkgZHluYW1pYyBhbmQgc3VwcG9ydCBkeW5hbWljIGxvYWRpbmcg b2YgcGFja2FnZXMgZXRjLg0KPj4+IEJBTEFaUzogSSB3b3VsZCBwdXQgc2VydmVyLWNhcGFiaWxp dGllcyBpbiAzIGJhZ3M6DQo+Pj4gMSkgY2FwYWJpbGl0aWVzIHRoYXQgY2hhbmdlIG9ubHkgYXQg dXBncmFkZQ0KPj4+IDIpIGNhcGFiaWxpdGllcyB0aGF0IGNoYW5nZSByYXJlbHkgKGUuZy4gZHVl IHRvIGxpY2Vuc2luZykNCj4+PiAzKSBjYXBhYmlsaXRpZXMgdGhhdCBjaGFuZ2UgZnJlcXVlbnRs eSAoPz8/KQ0KPj4+IElNSE8gMSkgY292ZXJzIDcwJSBvZiB0aGUgY2FzZXMgMikgY292ZXJzIDIw JSAzKSBpcyA8IDEwJS4NCj4+PiBNYW55IG5ldHdvcmsgbm9kZXMgb25seSBoYXZlIHR5cGUgMSkg b3IgdHlwZSAxKzIpIGNhcGFiaWxpdGllcy4NCj4+PiBTbyBvdXIgbWFpbiBmb2N1cyBzaG91bGQg YmUgb24gc3RhYmxlIGNhcGFiaWxpdGllcw0KPj4+IA0KPj4+IC0tIA0KPj4+IEJhbGF6cyBMZW5n eWVsICAgICAgICAgICAgICAgICAgICAgICBFcmljc3NvbiBIdW5nYXJ5IEx0ZC4NCj4+PiBTZW5p b3IgU3BlY2lhbGlzdA0KPj4+IE1vYmlsZTogKzM2LTcwLTMzMC03OTA5ICAgICAgICAgICAgICBl bWFpbDogQmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tDQo+Pj4gDQo+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBOZXRjb25mIG1haWxpbmcg bGlzdA0KPj4+IE5ldGNvbmZAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+PiBOZXRjb25m QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNv bmYNCj4gDQo+IC0tIA0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBV bml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAg IENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+IEZheDogICArNDkgNDIx IDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KDQo= From nobody Wed Dec 6 12:17: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 93D6C12426E for ; Wed, 6 Dec 2017 12:17: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, 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 O2Z76D7PwAQY for ; Wed, 6 Dec 2017 12:17:16 -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 79251124207 for ; Wed, 6 Dec 2017 12:17: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 487DCEFE; Wed, 6 Dec 2017 21:17: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 sI2nVwpTd6pz; Wed, 6 Dec 2017 21:17:13 +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, 6 Dec 2017 21:17:15 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 124822012C; Wed, 6 Dec 2017 21:17:15 +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 tZzzdIM4z_BD; Wed, 6 Dec 2017 21:17:13 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0FAC620129; Wed, 6 Dec 2017 21:17:12 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 6A3B1418E50B; Wed, 6 Dec 2017 21:15:43 +0100 (CET) Date: Wed, 6 Dec 2017 21:15:43 +0100 From: Juergen Schoenwaelder To: "Einar Nilsen-Nygaard (einarnn)" Cc: Balazs Lengyel , Martin Bjorklund , "netconf@ietf.org" Message-ID: <20171206201542.depjrlqlulnpkk6r@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Einar Nilsen-Nygaard (einarnn)" , Balazs Lengyel , Martin Bjorklund , "netconf@ietf.org" References: <20171128.103735.1654378548309425095.mbj@tail-f.com> <81f49c62-e1fe-4a90-a93f-c7fd55229100@ericsson.com> <20171206.100112.298803456348365967.mbj@tail-f.com> <4aacc669-5470-bef5-a3e7-fd9047c72562@ericsson.com> <20171206172433.aeysedjtcm3u7rf3@elstar.local> <649B1612-C107-4194-A2A2-A9305887AD0B@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: <649B1612-C107-4194-A2A2-A9305887AD0B@cisco.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Netconf] "notifiable-on-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, 06 Dec 2017 20:17:18 -0000 Einar, I like to know which datastore content belongs to, hence I suggested to use as the toplevel the datastore name (defined as a identity). If you have content from , the top-level would be Since YANG library is config false, I picked as the top-level for the example. /js On Wed, Dec 06, 2017 at 06:05:07PM +0000, Einar Nilsen-Nygaard (einarnn) wrote: > Juergen, > > Thanks for this. Thanks for picking up that a top level containing element as you have is necessary. Otherwise we would would be limited to a single module, which is not so useful. I don’t think that the top level tag should be “operationalâ€, though. Maybe something more like “â€? > > Cheers, > > Einar > > > > On 6 Dec 2017, at 17:24, Juergen Schoenwaelder wrote: > > > > It probably makes sense to write a document that defines how datastore > > content (or subsets of datastore content) in general can be stored in > > a file. With that in place, we know how to store ietf-yang-library > > content and as a side effect we know how to store datastore content > > used as examples for YANG data models and likely several other > > purposes. The root of the XML document would like be the datastore > > identity name in the YANG module namespace defining the identity > > > > > > > > > > > > > > > > Right now, it seems I have to feed instance data in slightly different > > formats into tools. It would be nice if tools could actually converge > > to common formats. [I am particularly interested in validations of > > examples.] > > > > /js > > > > On Wed, Dec 06, 2017 at 05:04:44PM +0000, Einar Nilsen-Nygaard (einarnn) wrote: > >> I agree with Balazs that we really want this issue to be nailed right form the start. > >> > >> I would be happy with defining an augmentation to ietf-yang-library to allow devices to return the data on what content is notifiable -on-change not this specific device at the specific time the data was retrieved. > >> > >> For offline consumption, we should define that an XML document conforming to the XML schema defined by ietf-yang-library + augmentations is an appropriate format. This XML document would have at its root the element ietf-yang-library:modules-state. How this XML document is provided is out of scope. It may be a flat file, it could come from a URL, whatever. > >> > >> Is this and acceptable approach? > >> > >> Cheers, > >> > >> Einar > >> > >> > >>> On 6 Dec 2017, at 10:32, Balazs Lengyel wrote: > >>> > >>> > >>> On 2017-12-06 10:01, Martin Bjorklund wrote: > >>>> Balazs Lengyel wrote: > >>>>> I very strongly object to excluding the issue. There is a strong and > >>>>> immediate need to be able to specify in vendor design time for which > >>>>> data nodes will there be on-change notification be generated. > >>>>> > >>>>> When a vendor release a product they know which nodes will emit > >>>>> on-change notifications in design time. System integrators need to > >>>>> know this. Providing the same information in run-time as instance data > >>>>> is not a good solution either as you would need to get a real node to > >>>>> read the data from. > >>>> The same argument applies to which YANG modules, features and > >>>> deviations a product supports. In SMIv2 we had AGENT-CAPABILITIES > >>>> which was an off-line document with this information. The experience > >>>> seems to be that it was rarely used by managers. In YANG we provide > >>>> this information on-line with the YANG library (and at least our > >>>> experience so far is that this *is* used by clients). > >>> BALAZS: I agree that yang-library is good. I am not arguing against it. Just it is > >>> not enough, because it is only available in run-time, too late. > >>>> It would probably be a good idea to combine these two approaches. > >>> BALAZS: I agree. Early documentation and on-line documentation > >>> combined would be a good solution. > >>> IMHO the 2 could use the same format. E.g. > >>> - Put all server-capabilities into yang-library (possibly augmenting it where needed) > >>> - define an off-line format for YANG Instance data > >>> e.g. the data section of a reply This way you don't even have to define a real new format > >>> - declare that off-line instance data from yanglib is the format to define server capabilities > >>>> > >>>> I think that this would be fairly straight-forward. As a first > >>>> approximation, suppose we had a standard file format for a > >>>> "server-capabilities" document. It could be something like this: > >>>> > >>>> > >>>> // this identifier must also be available on the device, so that > >>>> // a client can match the capability document with the device. > >>>> some unique identifier > >>>> > >>>> // meta-data goes here > >>>> ... > >>>> ... > >>>> ... > >>>> > >>>> > >>>> // the contents of yang-library from this product > >>>> // with modules, features, deviations > >>>> // ... and possibly on-change info > >>>> > >>>> > >>>> > >>>> Now, this won't be useful for all systems, for example if the server > >>>> is very dynamic and support dynamic loading of packages etc. > >>> BALAZS: I would put server-capabilities in 3 bags: > >>> 1) capabilities that change only at upgrade > >>> 2) capabilities that change rarely (e.g. due to licensing) > >>> 3) capabilities that change frequently (???) > >>> IMHO 1) covers 70% of the cases 2) covers 20% 3) is < 10%. > >>> Many network nodes only have type 1) or type 1+2) capabilities. > >>> So our main focus should be on stable capabilities > >>> > >>> -- > >>> 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 > >> > >> _______________________________________________ > >> 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 > -- 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 Dec 6 14:58: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 58842128990 for ; Wed, 6 Dec 2017 14:58:00 -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 Xzsnd-25XbvR for ; Wed, 6 Dec 2017 14:57:58 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1CF4128854 for ; Wed, 6 Dec 2017 14:57:58 -0800 (PST) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vB6MsPu6020764 for ; Wed, 6 Dec 2017 14:57:58 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=K82Ku/6oiqXxBxO7ywpbI0g/UzO/D3xOYK/ad1eQydo=; b=dVIxKgFiV6oD49lpl/qRF+XzxaJR7kzW9Y7N3r4EePS89b5bFZzcYvFjhqfVN39PwFH9 iwssk3CAlFPJBFuGP99x0LpoWxiI7/1VP8wm/su3CS97H8qrBjQFYTFy92oNrZ0jBgKM iUsOLtStyAndwu7uIDOZaqo+AvUny5Z7k0oq6PV6uk8JZWEhLRtHYQzZHriuYA03343x FrOPRE2SSx2k64xMEBX0JMYPTvC5Jfz2Q/yjWJQQfyZOh9sNY/hjkbf3SkqM0W+erc+l v/wScfoYTkF6XYZyPPtJXSCRXfrJpd0zciqznz/j+Dv73gN77NRPsDrIp9190rIzBX0l tA== Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0115.outbound.protection.outlook.com [207.46.163.115]) by mx0a-00273201.pphosted.com with ESMTP id 2epnymgktc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 06 Dec 2017 14:57:58 -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.302.2; Wed, 6 Dec 2017 22:57:57 +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.0302.007; Wed, 6 Dec 2017 22:57:56 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: NETCONF WG virtual interim on YANG Library Wed Dec 13th Thread-Index: AQHTbuWng8ljGqk14k2g3NJsOcf69Q== Date: Wed, 6 Dec 2017 22:57:56 +0000 Message-ID: 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.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB276; 6:MP/X9oOj6jxQWGGBW8aH1DQuIUGAOXD4f2rmxyb5Yk0rt4M4wxOdvsKBhZl+R4KOt4102H2s0iKt3C3xrXf0X9gaVARkml4bgVJnb8/JQCuLkxZ5rsS/amzhh2tV+B2FckuqAF8rfiIpzhT1Qzlw+vkbhpth20HKfzISAnwmO8fJstE/kDuCA6+tj0671kZHxL2xTonDgAvlXVQhWfi4Vut+CSx+uHkMvuS/fKEPjUZudA10se+9gOMijCD4NAHGOI3u8zdAWI7ZlsGkvOWmGpEYwHadR1fxxh3aZsl77r6OgXGxZJs9t5bhfU0HmMm1/4fVmXhfEVq7ycJU+31vZ/SBrP0Xhaxe3eMv2G06zD0=; 5:Ahg1eOD1SdcW/Q4ICTleU7X02SMcX9WoCwY3JapAs26XeZzRO6ylGQenv3YRfReYlw0GyO6JXctQzJs1+LBSMgRIFKjuQSMm5Ngqyvw5DKpKHTRIlbbnfSWysDmRcG6QAh6eWuyVSvVdPn6iSGpmyLjgpE3s2bgAjpQ+X0xCoYY=; 24:UxWDtJGd56iTxoQFm52mawotOW7y7Fc9hiyiMVjX/jwsHc8/HwKW1/IHKmMRO/PXRJIFxAsFYMbdXTp50vEvP428jL+RAdDbXpY78VreOGg=; 7:hq30IvcNpTKSvTwIw+RORjhyT8wevUPgPiBhreSMEo9SYZKqBain2OV9dwtR1kuDL4Tb2Uql+kYZl1RHsaYG+7rVVt87wn1N1x/Jcm/eeg582CJiwyG5iHuJyiC9qvmQZ0xxTwHqwWKWS4sAMYzn2PB7tPI1UayzkXMQSIax2fWLM0VhTsLdEybriIByloBw5RSENQuEeCmEZt06BCNERZcxlA719/3Pp4S+TbYknUwR393A7OId5efvd5nIl3U5 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1006db3b-4145-4581-c864-08d53cfcca74 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603286); SRVR:BLUPR05MB276; x-ms-traffictypediagnostic: BLUPR05MB276: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(209352067349851); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231022)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011); SRVR:BLUPR05MB276; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR05MB276; x-forefront-prvs: 05134F8B4F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(376002)(346002)(189003)(199004)(6506006)(77096006)(58126008)(2900100001)(6486002)(6116002)(5660300001)(5640700003)(305945005)(6512007)(6436002)(102836003)(68736007)(316002)(97736004)(25786009)(2501003)(83716003)(99286004)(53936002)(2906002)(83506002)(3846002)(81166006)(81156014)(36756003)(1730700003)(8676002)(8936002)(478600001)(82746002)(106356001)(413944005)(3280700002)(101416001)(14454004)(561944003)(6916009)(66066001)(86362001)(2351001)(105586002)(7736002)(33656002)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB276; 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: <15E4FE663DF46745A789DEAEF7351514@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 1006db3b-4145-4581-c864-08d53cfcca74 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2017 22:57:56.7463 (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-12-06_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1712060319 Archived-At: Subject: [Netconf] NETCONF WG virtual interim on YANG Library Wed Dec 13th 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, 06 Dec 2017 22:58:00 -0000 DQpEZWFyIFdHLA0KDQpQbGVhc2UgYmUgYXdhcmUgdGhhdCB0aGUgTkVUQ09ORiBXRyB3aWxsIGhh dmUgYSB2aXJ0dWFsIGludGVyaW0gbmV4dCBXZWRuZXNkYXkgRGVjIDEzIGZyb20gMTBhbS1ub29u IEVhc3Rlcm4gKDdhbS05YW0gUGFjaWZpYykuDQoNClRoZSBhZ2VuZGEgZm9yIHRoaXMgbWVldGlu ZyBpcyBhcyBmb2xsb3dzOg0KDQoxKSBSZXZpZXcgWUFORyBMaWJyYXJ5IHByb3Bvc2Fscw0KICAg UHJlc2VudGVyOiBOTURBIEF1dGhvcnMNCg0KICAgVGhpcyBwcmVzZW50YXRpb24gd2lsbCBhbHNv IGdvIG92ZXIgdG9waWNzIHJhaXNlZCBkdXJpbmcgdGhlDQogICBJRVRGIDEwMCBtZWV0aW5nIGlu Y2x1ZGluZzoNCiAgICAgLSBsaWNlbnNpbmcNCiAgICAgLSBsaW5lIGNhcmQgaW5zZXJ0aW9uL2Rl bGV0aW9uDQogICAgIC0gc2VtYW50aWMgdmVyc2lvbmluZw0KDQogICBOb3RlOiBBbiBlbWFpbCBs aXN0aW5nIDItMyBwcm9wb3NhbHMgd2lsbCBiZSBzZW50IG91dCBsYXRlcg0KICAgICAgICAgdGhp cyB3ZWVrLg0KDQoNCjIpIERpc2N1c3Npb24NCiAgIFByZXNlbnRlcjogTi9BIChhbGwpDQoNCiAg IEdvYWwgaXMgdG8gc2VsZWN0IGEgcHJvcG9zYWwuDQoNCg0KUFM6IER1ZSB0byBhIG1hbGZ1bmN0 aW9uaW5nIHdlYnBhZ2UsIHRoaXMgZW1haWwgaXMgbmV0aGVyIHNlbnQgDQogICAgYnkgdGhlIElF U0cgU2VjcmV0YXJ5IG5vciBjb250YWlucyBhIENhbGVuZGFyIGludml0ZSBoYXZpbmcNCiAgICB0 aGUgV2ViRVggb25saW5lIG1lZXRpbmcgaW5mb3JtYXRpb24uICBXZSBhcmUgd29ya2luZyB3aXRo DQogICAgdGhlIHRvb2xzIHRlYW0gdG8gcmVzb2x2ZSB0aGUgaXNzdWUsIGFuZCB3aWxsIHNlbmQg YSBwcm9wZXINCiAgICBpbnRlcmltIGFubm91bmNlbWVudCBBU0FQLg0KDQpLZW50IChhbmQgTWFo ZXNoKSAgLy8gTkVUQ09ORiBXRyBjby1jaGFpcnMNCg0K From nobody Wed Dec 6 15:32: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 570C6126B6D for ; Wed, 6 Dec 2017 15:32:03 -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 BJIHFW6F2sl7 for ; Wed, 6 Dec 2017 15:32:00 -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 29A491205F0 for ; Wed, 6 Dec 2017 15:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16016; q=dns/txt; s=iport; t=1512603120; x=1513812720; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ST/0Of/WJnpXaZEg/tQDQ21Iyp8ut1Jko5r4Njt0ueo=; b=AFxfeirq2GVpwdRtul8DS0e3SOscnX0fUo5qWfYZt6eENPfgjdFPTAFR 7iiuAhCYDjb8u8S423qh76qPUzj4wzFHDW2v/NbU27FWuG/pycongyyHf eJt1ezXEZvq/PvU8ECt1a2RVVK8YrdeSvIAQCzwGuqvTr1ljQlMbXpvi1 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5AgCnfSha/5BdJa1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDPWZxJweDe5kegX2XBRSCAQoYC4RJTwIahTpBFgEBAQEBAQE?= =?us-ascii?q?BAWsohSIBAQEEAQEhEToLDAQCAQYCEQQBAQECAgkIEgMCAgIlCxQBCAgCBAENB?= =?us-ascii?q?QgTiggQiyKdbIIniloBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPhE2BVoFpgyu?= =?us-ascii?q?EXBIBBwUGAQgBLSiCVoJjBYdqmxMCixdLg2iFRIIfhhGLNIo+i2gCERkBgTkBJ?= =?us-ascii?q?gIwYW1vFTqCKYJSHIFneAGHJAEOGASBCIEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,370,1508803200"; d="scan'208";a="318955619" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2017 23:31:58 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id vB6NVwnD002597 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Dec 2017 23:31:58 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, 6 Dec 2017 18:31:57 -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, 6 Dec 2017 18:31:57 -0500 From: "Eric Voit (evoit)" To: Balazs Lengyel , Henk Birkholz CC: "netconf@ietf.org" Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11 Thread-Index: AQHTaCzLQRPr9GM9Jka7UxKyCaa4a6MsMpiA//+ZgDCAAEyf8IAAV64AgAFczAD//6+3cIAJBwOAgACAB1A= Date: Wed, 6 Dec 2017 23:31:57 +0000 Message-ID: <475fc2f829fb4ae4868b8894f22e10e6@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> <782c1aad-1e85-fe11-4c9f-47a2d1fd9304@sit.fraunhofer.de> 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.86.244.103] 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: Wed, 06 Dec 2017 23:32:03 -0000 WWVzIHRoaXMgd29ya3MgdG9vLiAgV2hpY2ggaXMgb25lIHJlYXNvbiBib3RoIHRoZSBzZWxlY3Rp b24gZmlsdGVyIGFuZCB0aGUgZGFtcGVuaW5nLXBlcmlvZCBhcmUgYm90aCBtb2RpZmlhYmxlIHdp dGhpbiBhIHNpbmdsZSBzdWJzY3JpcHRpb24gOi0pDQoNCkVyaWMNCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCYWxhenMgTGVuZ3llbCBbbWFpbHRvOmJhbGF6cy5sZW5n eWVsQGVyaWNzc29uLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciA2LCAyMDE3IDU6 NTIgQU0NCj4gVG86IEVyaWMgVm9pdCAoZXZvaXQpIDxldm9pdEBjaXNjby5jb20+OyBIZW5rIEJp cmtob2x6DQo+IDxoZW5rLmJpcmtob2x6QHNpdC5mcmF1bmhvZmVyLmRlPg0KPiBDYzogbmV0Y29u ZkBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW05ldGNvbmZdIHJldmlldyBvZiBkcmFmdC1pZXRm LW5ldGNvbmYteWFuZy1wdXNoLTExDQo+IA0KPiBIZWxsbywNCj4gDQo+IFlvdSBjb3VsZCB1c2Ug YSBsb25nZXIgZGFtcGVuaW5nIHBlcmlvZCBmb3IgZGV0ZWN0aW5nIGNodXJuIGFuZCBsYXRlcg0K PiBzd2l0Y2ggdG8gYSB2ZXJ5IHNob3J0IGRhbXBlbmluZyBwZXJpb2Qgd2l0aCBhIG5hcnJvdyBm aWx0ZXIuwqAgR2V0dGluZyB0aGUNCj4gaW5mb3JtYXRpb24gaW4gdHdvIHN0ZXBzwqAgc29tZXRp bWVzIG1heWJlIGEgcHJvYmxlbS4NCj4gDQo+IHJlZ2FyZHMgQmFsYXpzDQo+IA0KPiANCj4gT24g MjAxNy0xMS0zMCAyMzoxNiwgRXJpYyBWb2l0IChldm9pdCkgd3JvdGU6DQo+ID4gSGkgSGVuaywN Cj4gPg0KPiA+IFlBTkcgUHVzaCBkb2VzIGlkZW50aWZ5IHRoYXQgY2h1cm4gaGFzIG9jY3VycmVk LCBidXQgbm90IGhvdyBtdWNoDQo+IGNodXJuIGhhcyBvY2N1cnJlZCBkdXJpbmcgYSBkYW1wZW5p bmcgcGVyaW9kLiAgIFRoaXMgYWxsb3dzIHRoaW5ncyBsaWtlDQo+IHNlY3VyaXR5IGFwcGxpY2F0 aW9ucyB0byBrbm93IHRoaW5ncyBsaWtlIHRlbXBvcmFyeSBBQ0wgY2hhbmdlcy4gIE9yIHRoaW5n cw0KPiBsaWtlIG5ldHdvcmsgbWFuYWdlbWVudCBzeXN0ZW1zIGtub3dpbmcgdGhhdCB0aGVyZSBh cmUgdHJhbnNpZW50DQo+IG91dGFnZXMgb24gYW4gaW50ZXJmYWNlLg0KPiA+DQo+ID4gQXQgdGhp cyBwb2ludCwgdGhlIHRoaW5raW5nIGlzIHRoYXQgYW4gYXBwbGljYXRpb24gYWx3YXlzIGhhcyB0 aGUgb3B0aW9uIG9mDQo+IGdvaW5nIHRvIFB1Ymxpc2hlciB0byBnZXQgdGhlIGRldGFpbHMgb2Yg dGhlIGNodXJuLiAgIFBlcmhhcHMgbmV3IGRyYWZ0cyBjb3VsZA0KPiBhbHNvIHB1c2ggdGhlIHF1 YW50aXR5IG9mIGNoYW5nZXMgd2hpY2ggb2NjdXJyZWQsIG9yIGEgaGlzdG9ncmFtIG9yDQo+IGNo YW5nZXMsIG9yIHNvbWUgb3RoZXIgbWV0cmljLiAgQXQgdGhpcyBwb2ludCB0aGF0IHRvcGljIGlz IHVuZXhwbG9yZWQuICBCdXQNCj4gdGhlcmUgaXMgbm8gcmVhc29uIHRoYXQgc3VjaCBpbmZvcm1h dGlvbiBjb3VsZG4ndCBiZSBhdWdtZW50ZWQgaW50byBzb21lDQo+IGhlYWRlciBhc3NvY2lhdGVk IHdpdGggdGhlIHB1c2gtY2hhbmdlLXVwZGF0ZSByZWNvcmQuDQo+ID4NCj4gPiBFcmljDQo+ID4N Cj4gPj4gRnJvbTogSGVuayBCaXJraG9seiwgTm92ZW1iZXIgMzAsIDIwMTcgNDo0OCBQTQ0KPiA+ Pg0KPiA+PiBIaSBhbGwsDQo+ID4+DQo+ID4+IEFkbWl0dGVkbHksIEkgYW0gcmVsYXRpdmVseSBu ZXcgdG8gdGhpcyBkb21haW4gYW5kIGJlZm9yZSBJIHByb3ZpZGUNCj4gPj4gbXkgY29tbWVudCBJ IHdhbnQgdG8gYWNrbm93bGVkZ2UgdGhhdDoNCj4gPj4NCj4gPj4gLSBpdCBpcyBpbXBvcnRhbnQg bm90IHRvIG9mZi1sb2FkIHRvIG11Y2ggY29tcGxleGl0eSB0byB0aGUgYWdlbnRzDQo+ID4+IHRo YXQgYXJlIHBhcnQgb2YgdGhlIGRhdGEgc3RvcmUNCj4gPj4gLSBjb21wbGV4IGNvbXBvc2l0ZSBk ZXZpY2VzIG1pZ2h0IGNyZWF0ZSBhIGxvdCBvZiAibm9pc2UiIGluIHdydA0KPiA+PiBjaGFuZ2Vz IG9mIGRhdGEgbm9kZSB2YWx1ZXMgYW5kIHRoYXQgaGFzIHRvIGJlIGRlYWx0IHdpdGggaW4gYSBz YW5lDQo+ID4+IGFuZCByZWFzb25hYmxlIHdheQ0KPiA+Pg0KPiA+PiBUaGF0IHNhaWQsIFlBTkcg UHVzaCBjYXVnaHQgYSBsb3Qgb2YgYXR0ZW50aW9uIG91dHNpZGUgb2YgTkVUQ09ORi4gSW4NCj4g Pj4gYSBudXRzaGVsbCwgaXQgaXMgYSBzb2x1dGlvbiB0aGF0IHByb3ZpZGVzIG1lYW5pbmdmdWwg dGVsZW1ldHJ5LA0KPiA+PiB3aGljaCBzaW1wbGlmaWVzIHBvc3QtcHJvY2Vzc2luZyBvZiBzdWJz Y3JpYmVkIG5vdGlmaWNhdGlvbnMgc2lnbmlmaWNhbnRseS4NCj4gPj4NCj4gPj4gQnV0IC0gdGhl cmUgaXMgYWx3YXlzIGEgYnV0LCBJIGd1ZXNzIC0gInZpc2liaWxpdHkiIGlzIGEga2V5DQo+ID4+ IGNhcGFiaWxpdHkgaW4gdGhpcyBjb250ZXh0LCBJIHRoaW5rLiBZZXMsIHRoZXJlIG1pZ2h0IGJl IG9zY2lsbGF0aW5nDQo+ID4+IHZhbHVlcywgeWVzLCB0aGV5IG1pZ2h0IGJlIG9mIG5vIHZhbHVl IHRvIG1vc3QgcG9zdC1wcm9jZXNzaW5nDQo+ID4+IHByb2Nlc3NlcywgYnV0IHRvIGV4Y2x1ZGUg dGhlbSBlbnRpcmVseSBtaWdodCByZWR1Y2UgdGhlIHVzZWZ1bG5lc3Mgb2YNCj4gdGhlIG9uLWNo YW5nZSBjYXBhYmlsaXR5IHNpZ25pZmljYW50bHkuDQo+ID4+DQo+ID4+IFRoZXJlIGlzIHRoZSBj b21wbGVtZW50YXJ5IHRvcGljIG9mIHNtYXJ0IGZpbHRlcnMgdGhhdCBtaWdodCBkZWFsDQo+ID4+ IHdpdGggcHJvdmlkaW5nIG1ldGFkYXRhIGFib3V0IHRoaXMgIm9taXR0ZWQgbm90aWZpY2F0aW9u cyIgKGNvbWluZw0KPiA+PiBiYWNrIHRvIHRoZSBvc2NpbGxhdGluZyB2YWx1ZXMgZXhhbXBsZSwg QWxleCBpbGx1c3RyYXRlZCksIGJ1dA0KPiA+PiB2aXNpYmlsaXR5IG9mIG9uZ29pbmcgY2hhbmdl cyBzaG91bGQgYmUgc3VwcG9ydGVkIHNvbWVob3csIEkgdGhpbmsuDQo+ID4+IE1heWJlIG5vdCBp biB0aGUgdG9wIGxldmVsIGRyYWZ0IHRoYXQgaXMgbmV0Y29uZi15YW5nLXB1c2gsIGJ1dCBhdCBz b21lDQo+IGxldmVsLCBJIGhvcGUuDQo+ID4+DQo+ID4+IEFnYWluLCB0aGlzIGlzIGNvbWluZyBm cm9tIGEgZnJlc2ggcGFpciBvZiBleWVzIHN0aWxsIHJlbGF0aXZlbHkNCj4gPj4gdW5mYW1pbGlh ciB3aXRoIHRoZSBlbWVyZ2luZyBlY29zeXN0ZW0gYXJvdW5kIFlBTkcgUHVzaC4NCj4gPj4NCj4g Pj4gSW4gYSBudXRzaGVsbCwgSSBqdXN0IHdhbnQgdG8gaGlnaGxpZ2h0IHRoYXQgdmlzaWJpbGl0 eSBvZiBwYXN0DQo+ID4+IGNoYW5nZXMgYW5kIGRlYWxpbmcgd2l0aCBoaWdoIGZyZXF1ZW5jeSBv ZiBjaGFuZ2VzIG9mIGNvdXJzZSByZXF1aXJlcw0KPiA+PiBhIGZlYXNpYmxlIGNvbXByb21pc2Uu IEJ1dCBmcm9tIG15IFBPViwgInRoZSBtb3N0IHJlY2VudCB1cGRhdGUiDQo+IG1pZ2h0IG5vdCBj dXQgaXQuDQo+ID4+IEkgb25seSB3YW50IHRvIGhpZ2hsaWdodCB0aGF0IGZpbmUgZ3JhbnVsYXIg dmlzaWJpbGl0eSBpcyBhIHZpdGFsDQo+ID4+IGNoYXJhY3RlcmlzdGljIG9mIG9uLWNoYW5nZSBl bWlzc2lvbiBvZiBub3RpZmljYXRpb25zLiBNYXliZSB0aGVyZQ0KPiA+PiBjYW4gYmUgYSBrbm9i LCBhcyBTdWUgbWlnaHQgcGhyYXNlIGl0Lg0KPiA+Pg0KPiA+PiBJZiB0aGlzIGlzIGFscmVhZHkg YWRkcmVzc2VkIGJ5IGFub3RoZXIgZHJhZnQsIEkgYXBvbG9naXplIGZvciBteSB3YWxsIG9mDQo+ IHRleHQuDQo+ID4+IElmIG5vdCwgcGxlYXNlIHRha2UgdGhpcyBQT1YgaW50byBhY2NvdW50IDop DQo+ID4+DQo+ID4+IFZpZWxlIEdyw7zDn2UsDQo+ID4+DQo+ID4+IEhlbmsNCj4gPj4NCj4gPj4g T24gMTEvMzAvMjAxNyAwMTo1OSBBTSwgQWxleGFuZGVyIENsZW1tIHdyb3RlOg0KPiA+Pj4gVGhp cyB3b3JrcyBmb3IgbWUuwqAgUGVyaGFwcyBvbmUgYWRkaXRpb25hbCBpdGVtIHdlIG1pZ2h0IGFk ZCAoZm9yDQo+ID4+PiBjcnlzdGFsLWNsZWFyIGNsYXJpZmljYXRpb24pIGlzIHRoYXQgd2hlbiB0 aGUgbm90aWZpY2F0aW9uIG1lc3NhZ2UNCj4gPj4+IGlzIHNlbnQsIGl0IGNvbnRhaW5zIHRoZSBt b3N0IHJlY2VudCB1cGRhdGUgZm9yIHRoYXQgb2JqZWN0IChpLmUuDQo+ID4+PiB0aGUgdmFsdWUg dGhhdCBpcyBpbiBlZmZlY3Qgd2hlbiB0aGUgdXBkYXRlIGlzIHNlbnQpLsKgIElmIHRoZXJlIGFy ZQ0KPiA+Pj4gc29tZSBxdWlja2x5IG9zY2lsbGF0aW5nIHZhbHVlcyB3ZSBkb27igJl0IHNlbmQg dGhlIHdob2xlIHNlcXVlbmNlIG9mDQo+ID4+IHVwZGF0ZXMvdmFsdWVzLg0KPiA+Pj4gLS0tIEFs ZXgNCj4gPj4+DQo+ID4+PiAqRnJvbToqRXJpYyBWb2l0IChldm9pdCkgW21haWx0bzpldm9pdEBj aXNjby5jb21dDQo+ID4+PiAqU2VudDoqIFdlZG5lc2RheSwgTm92ZW1iZXIgMjksIDIwMTcgNDo1 MSBQTQ0KPiA+Pj4gKlRvOiogQWxleGFuZGVyIENsZW1tIDxhbGV4YW5kZXIuY2xlbW1AaHVhd2Vp LmNvbT47IEFuZHkNCj4gQmllcm1hbg0KPiA+Pj4gPGFuZHlAeXVtYXdvcmtzLmNvbT47IE1hcnRp biBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPjsNCj4gPj4+IGt3YXRzZW5AanVuaXBlci5uZXQN Cj4gPj4+ICpDYzoqIE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc+DQo+ID4+PiAqU3ViamVjdDoq IFJFOiBbTmV0Y29uZl0gcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1c2gtMTEN Cj4gPj4+DQo+ID4+PiBUaGUgU2VjdGlvbiAzLjEgdGV4dCBJIHByb3Bvc2VkIGluIG15IHJlc3Bv bnNlIHRvIE1hcnRpbiBvbiB0aGUNCj4gPj4+IGRhbXBlbmluZyBxdWVzdGlvbjoNCj4gPj4+DQo+ ID4+PiBEYW1wZW5pbmcgcGVyaW9kOiBJbiBhbiBvbi1jaGFuZ2Ugc3Vic2NyaXB0aW9uLCBkZXRl Y3RlZCBvYmplY3QNCj4gPj4+IGNoYW5nZXMgc2hvdWxkIGJlIHNlbnQgYXMgcXVpY2tseSBhcyBw b3NzaWJsZS7CoCBIb3dldmVyIHdpdGhvdXQNCj4gPj4+IGFkZXF1YXRlIHByb3RlY3Rpb25zLCBh IHJhcGlkIHNlcmllcyBvZiBvYmplY3QgY2hhbmdlcyBtaWdodCBleGhhdXN0DQo+ID4+PiBvZiBy ZXNvdXJjZXMgaW4gdGhlIHB1Ymxpc2hlciBvciByZWNlaXZlci4gSW4gb3JkZXIgdG8gcHJvdGVj dA0KPiA+Pj4gYWdhaW5zdCB0aGF0LCBhIGRhbXBlbmluZyBwZXJpb2QgTUFZIGJlIHVzZWQgdG8g c3BlY2lmeSB0aGUgaW50ZXJ2YWwNCj4gPj4+IHdoaWNoIG11c3QgcGFzcyBiZWZvcmUgc3VjY2Vz c2l2ZSB1cGRhdGUgcmVjb3JkcyBmb3IgdGhlIHNhbWUNCj4gPj4+IHN1YnNjcmlwdGlvbiBhcmUg Z2VuZXJhdGVkIGZvciBhIHJlY2VpdmVyLsKgIFRoZSBkYW1wZW5pbmcgcGVyaW9kDQo+ID4+PiBj b2xsZWN0aXZlbHkgYXBwbGllcyB0byB0aGUgc2V0IG9mIGFsbCBkYXRhIG5vZGVzIHNlbGVjdGVk IGJ5IGENCj4gPj4+IHNpbmdsZSBzdWJzY3JpcHRpb24gYW5kIHNlbnQgdG8gYSBzaW5nbGUgcmVj ZWl2ZXIuwqAgVGhpcyBtZWFucyB0aGF0DQo+ID4+PiB3aGVuIHRoZXJlIGlzIGEgY2hhbmdlIHRv IGEgc3Vic2NyaWJlZCBvYmplY3QsIGFuIHVwZGF0ZSByZWNvcmQNCj4gPj4+IGNvbnRhaW5pbmcg dGhhdCBvYmplY3QgaXMgY3JlYXRlZCBlaXRoZXIgaW1tZWRpYXRlbHkgd2hlbiBubw0KPiA+Pj4g ZGFtcGVuaW5nIHBlcmlvZCBpcyBpbiBlZmZlY3QsIG9yIGF0IHRoZSBlbmQgb2YgYSBkYW1wZW5p bmcgcGVyaW9kLg0KPiA+Pj4gQSBkYW1wZW5pbmcgcGVyaW9kIGlzIHJlc2V0IGV2ZXJ5IHRpbWUg YSBuZXcgbm90aWZpY2F0aW9uIG1lc3NhZ2UgaXMNCj4gcGFzc2VkIHRvIHRyYW5zcG9ydC4NCj4g Pj4+DQo+ID4+PiBXaXRoIHRoZSBZQU5HIGRlc2NyaXB0aW9uIG9mOg0KPiA+Pj4NCj4gPj4+ICJT cGVjaWZpZXMgdGhlIGludGVydmFsIHdoaWNoIG11c3QgcGFzcyBiZWZvcmUgc3VjY2Vzc2l2ZSB1 cGRhdGUNCj4gPj4+IHJlY29yZHMgZm9yIHRoZSBzYW1lIHN1YnNjcmlwdGlvbiBhcmUgZ2VuZXJh dGVkIGZvciBhIHJlY2VpdmVyLsKgIFRoZQ0KPiA+Pj4gZGFtcGVuaW5nIHBlcmlvZCBjb2xsZWN0 aXZlbHkgYXBwbGllcyB0byB0aGUgc2V0IG9mIGFsbCBkYXRhIG5vZGVzDQo+ID4+PiBzZWxlY3Rl ZCBieSBhIHNpbmdsZSBzdWJzY3JpcHRpb24gYW5kIHNlbnQgdG8gYSBzaW5nbGUgcmVjZWl2ZXIu DQo+ID4+PiBUaGlzIG1lYW5zIHRoYXQgd2hlbiB0aGVyZSBpcyBhIGNoYW5nZSB0byBhIHN1YnNj cmliZWQgb2JqZWN0LCBhbg0KPiA+Pj4gdXBkYXRlIHJlY29yZCBjb250YWluaW5nIHRoYXQgb2Jq ZWN0IGlzIGNyZWF0ZWQgZWl0aGVyIGltbWVkaWF0ZWx5DQo+ID4+PiB3aGVuIG5vIGRhbXBlbmlu ZyBwZXJpb2QgaXMgaW4gZWZmZWN0LCBvciBhdCB0aGUgZW5kIG9mIGEgZGFtcGVuaW5nDQo+ID4+ PiBwZXJpb2QuwqAgQSBkYW1wZW5pbmcgcGVyaW9kIGlzIHJlc2V0IGV2ZXJ5IHRpbWUgYSBuZXcg bm90aWZpY2F0aW9uDQo+ID4+PiBtZXNzYWdlIGlzIHBhc3NlZCB0byB0cmFuc3BvcnQuwqAgQSBk YW1wZW5pbmcgcGVyaW9kIGlzIHJlc2V0IGV2ZXJ5DQo+ID4+PiB0aW1lIGEgbmV3IG5vdGlmaWNh dGlvbiBtZXNzYWdlIGlzIHBhc3NlZCB0byB0cmFuc3BvcnQuwqAgQSB6ZXJvDQo+ID4+PiB2YWx1 ZSBpbmRpY2F0ZXMgbm8gZGFtcGVuaW5nIHBlcmlvZCwgYW5kIGFsbCBzdWJzY3JpYmVkIG9iamVj dA0KPiA+Pj4gY2hhbmdlcyBhcmUgc2VudA0KPiA+PiBpbW1lZGlhdGVseS4iDQo+ID4+PiBEb2Vz IHRoaXMgd29yayBmb3IgZXZlcnlvbmU/DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEVyaWMNCj4gPj4+ DQo+ID4+PiAqRnJvbToqTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10g Kk9uIEJlaGFsZiBPZg0KPiA+Pj4gKkFsZXhhbmRlciBDbGVtbQ0KPiA+Pj4gKlNlbnQ6KiBXZWRu ZXNkYXksIE5vdmVtYmVyIDI5LCAyMDE3IDM6MTcgUE0NCj4gPj4+ICpUbzoqIEFuZHkgQmllcm1h biA8YW5keUB5dW1hd29ya3MuY29tDQo+ID4+IDxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPj47 DQo+ID4+PiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbSA8bWFpbHRvOm1iakB0YWls LWYuY29tPj4NCj4gPj4+ICpDYzoqIE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmcgPG1haWx0bzpu ZXRjb25mQGlldGYub3JnPj4NCj4gPj4+ICpTdWJqZWN0OiogUmU6IFtOZXRjb25mXSByZXZpZXcg b2YgZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaC0xMQ0KPiA+Pj4NCj4gPj4+IEkgdGhvdWdo dCB3ZSBkZWNpZGVkIHRoYXQgd2UgaGF2ZSBjb21iaW5lZCBkYW1wZW5pbmcgZm9yIGFsbCBvYmpl Y3RzDQo+ID4+PiBpbiB0aGUgc3Vic2NyaXB0aW9uLsKgIEluIHRoaXMgY2FzZSwgd2Ugd291bGQg c2VuZCB1cGRhdGVzIGF0IDIsIDEyDQo+ID4+PiAoY29udGFpbmluZyAzLDQsMTEpLCBhbmQgMjIg KGNvbnRhaW5pbmcgMTMsIDE0LCAxNSkuDQo+ID4+Pg0KPiA+Pj4gSWYgdGhlIHNjb3BlIG9mIHRo ZSBzdWJzY3JpcHRpb24gYmVjb21lcyBzdWZmaWNpZW50bHkgbGFyZ2UsIHRoaXMNCj4gPj4+IGFs bW9zdCByZXZlcnRzIGJhY2sgdG8gYSBwZXJpb2RpYyBzdWJzY3JpcHRpb24gKHNpbmNlIHRoZXJl IGlzDQo+ID4+PiBhbHdheXMgZ29pbmcgdG8gYmUgYSBjaGFuZ2Ugc29tZXdoZXJlKS4gVGhpcyBp cyB3aHkgSSBvcmlnaW5hbGx5DQo+ID4+PiBhcmd1ZWQgdG8gaGF2ZSBpdCBpbmRlZWQgb24gYSBw ZXItb2JqZWN0IGJhc2lzLCBidXQgSSBsb3N0IHRoYXQNCj4gPj4+IGFyZ3VtZW50LsKgIEZvciBz dWNoIGZpbmUtZ3JhaW5lZCB1cGRhdGVzLCB3aGVyZSBhIGNsaWVudCBpcyBpbmRlZWQNCj4gPj4+ IGludGVyZXN0IGluIGdldHRpbmcgZGVsYXlzIG9mIGluZGl2aWR1YWwgb2JqZWN0cyB3aXRob3V0 IGRlbGF5LCDCoGENCj4gPj4+IGNsaWVudCBjb3VsZCBzaW1wbHkgbmVlZCB0byBlc3RhYmxpc2gg bXVsdGlwbGUg4oCcbWljcm/igJ0gc3Vic2NyaXB0aW9ucy4NCj4gPj4+DQo+ID4+PiBUQ0FzIGlu IFJNT04gYXJlIHNvbWV0aGluZyBkaWZmZXJlbnQgYWx0b2dldGhlci7CoCBUaGlzIGlzIHNvbWV0 aGluZw0KPiA+Pj4gd2UgYXJlIHRyeWluZyB0byBhZGRyZXNzIHdpdGggc21hcnQgZmlsdGVycy4N Cj4gPj4+DQo+ID4+PiAtLS0gQWxleA0KPiA+Pj4NCj4gPj4+ICpGcm9tOipOZXRjb25mIFttYWls dG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mDQo+ICpBbmR5DQo+ID4+ PiBCaWVybWFuDQo+ID4+PiAqU2VudDoqIFdlZG5lc2RheSwgTm92ZW1iZXIgMjksIDIwMTcgMTA6 MTggQU0NCj4gPj4+ICpUbzoqIE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tIDxtYWls dG86bWJqQHRhaWwtZi5jb20+Pg0KPiA+Pj4gKkNjOiogTmV0Y29uZiA8bmV0Y29uZkBpZXRmLm9y ZyA8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+Pg0KPiA+Pj4gKlN1YmplY3Q6KiBSZTogW05ldGNv bmZdIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoLTExDQo+ID4+Pg0KPiA+ Pj4gT24gVHVlLCBOb3YgMjgsIDIwMTcgYXQgMTozNyBBTSwgTWFydGluIEJqb3JrbHVuZCA8bWJq QHRhaWwtZi5jb20NCj4gPj4+IDxtYWlsdG86bWJqQHRhaWwtZi5jb20+PiB3cm90ZToNCj4gPj4+ DQo+ID4+PiAgICAgIEhpLA0KPiA+Pj4NCj4gPj4+ICAgICAgLi4uLg0KPiA+Pj4NCj4gPj4+ICAg ICAgb8KgIDMuMQ0KPiA+Pj4NCj4gPj4+ICAgICAgIMKgIEknbSBub3Qgc3VyZSBJIHVuZGVyc3Rh bmQgdGhlIGRhbXBlbmluZyBwZXJpb2QgY29uY2VwdC7CoCBMZXQncw0KPiA+Pj4gICAgICAgwqAg YXNzdW1lIHRoYXQgdGhlIGRhbXBlbmluZyBwZXJpb2QgaXMgMTBzLsKgIFRoZW4gY2hhbmdlcyBo YXBwZW4NCj4gYXQNCj4gPj4+ICAgICAgIMKgIHRpbWVzOg0KPiA+Pj4NCj4gPj4+ICAgICAgIMKg IMKgIDLCoCAzwqAgNMKgIDExwqAgMTPCoCAxNMKgIDE1DQo+ID4+Pg0KPiA+Pj4gICAgICAgwqAg RnJvbSB0aGUgZGVzY3JpcHRpb24sIGl0IHNlZW1zIEkgd291bGQgcmVjZWl2ZSA0IG5vdGlmaWNh dGlvbnMsIGZyb20NCj4gPj4+ICAgICAgIMKgIHRpbWVzOg0KPiA+Pj4NCj4gPj4+ICAgICAgIMKg IMKgIDLCoCAoY29udGFpbmluZyBvbmx5IGNoYW5nZSBmcm9tIDIpDQo+ID4+PiAgICAgICDCoCDC oCAxMiAoY29udGFpbmluZyBjaGFuZ2UgZnJvbSAzLDQsMTEpDQo+ID4+PiAgICAgICDCoCDCoCAx MyAoY29udGFpbmluZyBvbmx5IGNoYW5nZSBmcm9tIDEzKQ0KPiA+Pj4gICAgICAgwqAgwqAgMjMg KGNvbnRhaW5pbmcgY2hhbmdlcyBmcm9tIDE0LDE1KQ0KPiA+Pj4NCj4gPj4+ICAgICAgIMKgIElz IHRoaXMgY29ycmVjdD8NCj4gPj4+DQo+ID4+PiAgICAgICDCoCBJbiBhbnkgY2FzZSwgSSBzdWdn ZXN0IHRoZSBkZXNjcmlwdGlvbiBpbiB0aGUgWUFORyBtb2R1bGUgaXMNCj4gPj4+ICAgICAgIMKg IGNsYXJpZmllZCAtIGN1cnJlbnRseSB0aGUgUkZDIHRleHQgY29udGFpbnMgbW9yZSBkZXRhaWxz IHRoYW4gdGhlDQo+ID4+PiAgICAgICDCoCBZQU5HIG1vZHVsZS4NCj4gPj4+DQo+ID4+PiBTZWVt cyB0byBtZSAoZnJvbSBhIGNsaWVudCBQT1YpIHRoYXQgSSB3YW50IHRoZSBkYW1wZW5pbmcgdG8g YXBwbHkNCj4gPj4+DQo+ID4+PiB0byB0aGUgZW50aXJlIHN1YnNjcmlwdGlvbiwgbm90IHRvIGVh Y2ggbm9kZSB3aXRoaW4gdGhlIHN1YnNjcmlwdGlvbi4NCj4gPj4+DQo+ID4+PiBJIHdhbnQgImF0 IG1vc3QsIDEgbm90aWZpY2F0aW9uIHBlciBzZWNvbmQiLsKgIEkgZG9uJ3Qgc2VlIHdoeSBJDQo+ ID4+PiB3b3VsZCB3YW50DQo+ID4+Pg0KPiA+Pj4gdG8gYmUgdG9sZCBhYm91dCBhbiBpbmRpdmlk dWFsIGRhdGEgbm9kZSBvbmNlIHBlciBzZWNvbmQuwqAgSSBjb3VsZA0KPiA+Pj4gc3RpbGwNCj4g Pj4+DQo+ID4+PiBnZXQgMTAsMDAwIGV2ZW50cy9zZWMgYnV0IGZvciBkaWZmZXJlbnQgZGF0YSBu b2Rlcy7CoCBUaGUgcmVjZWl2ZXINCj4gPj4+IGRvZXMgbm90DQo+ID4+Pg0KPiA+Pj4gcmVhbGx5 IGNhcmUgd2hldCBub2RlcyBhcmUgYmVpbmcgcmVwb3J0ZWQgaW4gZWFjaCBub3RpZmljYXRpb24u IFRoZQ0KPiA+Pj4gZ29hbA0KPiA+Pj4NCj4gPj4+IGlzIHRvIHNpbXBseSBsaW1pdCB0aGUgbmV0 d29yayBhbmQgcHJvY2Vzc29yIGxvYWQuDQo+ID4+Pg0KPiA+Pj4gICBGcm9tIGEgc2VydmVyIFBP ViwgSSBkbyBub3Qgd2FudCBhIHRpbWVyIG9uIGV2ZXJ5IGRhdGEgbm9kZQ0KPiA+Pj4gaW5zdGFu Y2UNCj4gPj4+DQo+ID4+PiBhbmQgY29tcGxleCBjb2RlIHRvIGNvbnN0cnVjdCB0aGUgbmV4dCBv bi1jaGFuZ2Ugbm90aWZpY2F0aW9uLg0KPiA+Pj4NCj4gPj4+IFJNT04gaGFuZGxlcyBkYW1wZW5p bmcgdmVyeSBkaWZmZXJlbnRseS4NCj4gPj4+DQo+ID4+PiBUaGUgcmlzaW5nIGFuZCBmYWxsaW5n IHRocmVzaG9sZHMgYXJlIHVzZWQgdG8gYXJtIGFuZCByZS1hcm0gYW4NCj4gPj4+IGV2ZW50IHRy aWdnZXIuDQo+ID4+Pg0KPiA+Pj4gVGhlIHRpbWUgYmV0d2VlbiBjaGFuZ2VzIGlzIG5vdCB1c2Vk IGF0IGFsbCB0byBkZXRlcm1pbmUgaG93IG1hbnkNCj4gPj4+IGV2ZW50cyB0byBzZW5kLg0KPiA+ Pj4NCj4gPj4+IChOb3Qgc3VnZ2VzdGluZyBhbGwgeWFuZy1wdXNoIHVzZS1jYXNlcyBhcmUgdGhy ZXNob2xkLWJhc2VkLikNCj4gPj4+DQo+ID4+PiBJTU8sIHRoZSBvcGVyYXRvciBzaG91bGQgcHV0 IGV2ZW50cyB0aGF0IHJlcXVpcmUgbG93LWxhdGVuY3kgaW50byBhDQo+ID4+PiBzZXBhcmF0ZSBz dWJzY3JpcHRpb24sDQo+ID4+Pg0KPiA+Pj4gYW5kIHRoZSBkYW1wZW5pbmcgcGVyaW9kIHNob3Vs ZCBhcHBseSB0byB0aGUgZW50aXJlIHN1YnNjcmlwdGlvbi4NCj4gPj4+DQo+ID4+PiAgIMKgLi4u DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAvbWFydGluDQo+ID4+Pg0KPiA+Pj4gQW5keQ0K PiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPj4+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4+PiBOZXRj b25mQGlldGYub3JnIDxtYWlsdG86TmV0Y29uZkBpZXRmLm9yZz4NCj4gPj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0K PiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g Pj4+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID4+PiBOZXRjb25mQGlldGYub3JnDQo+ID4+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPj4+DQo+ID4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IE5l dGNvbmYgbWFpbGluZyBsaXN0DQo+ID4+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+ID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBOZXRjb25mIG1haWxpbmcgbGlz dA0KPiA+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldGNvbmYNCj4gDQo+IC0tDQo+IEJhbGF6cyBMZW5neWVsICAgICAgICAgICAg ICAgICAgICAgICBFcmljc3NvbiBIdW5nYXJ5IEx0ZC4NCj4gU2VuaW9yIFNwZWNpYWxpc3QNCj4g TW9iaWxlOiArMzYtNzAtMzMwLTc5MDkgICAgICAgICAgICAgIGVtYWlsOiBCYWxhenMuTGVuZ3ll bEBlcmljc3Nvbi5jb20NCg0K From nobody Thu Dec 7 00:21: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 558ED1292FC for ; Thu, 7 Dec 2017 00:21: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, 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 i_DXoYgdDGgS for ; Thu, 7 Dec 2017 00:21:28 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4C15B126C0F for ; Thu, 7 Dec 2017 00:21:28 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 4DE5B1AE0335; Thu, 7 Dec 2017 09:21:26 +0100 (CET) Date: Thu, 07 Dec 2017 09:20:01 +0100 (CET) Message-Id: <20171207.092001.1087388873746464030.mbj@tail-f.com> To: evoit@cisco.com Cc: netconf@ietf.org, balazs.lengyel@ericsson.com, andy@yumaworks.com, alexander.clemm@huawei.com From: Martin Bjorklund In-Reply-To: <905820dba0e24c0ca3d1b15849cd4961@XCH-RTP-013.cisco.com> References: <422b669242674349975651d2ef7c436e@XCH-RTP-013.cisco.com> <20171206.094009.1934958524737452117.mbj@tail-f.com> <905820dba0e24c0ca3d1b15849cd4961@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] 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, 07 Dec 2017 08:21:31 -0000 Hi, "Eric Voit (evoit)" wrote: > Hi Martin, > > > From: Martin Bjorklund, December 6, 2017 3:40 AM > > > > Hi, > > > > > > > > > > > > o 3.9 > > > > > A publisher could choose to allow a subscription to an empty > > > > > location where there might plausibly be objects someday. (E.g., > > > > > maybe where an interface might appear; even if there is no such > > > > > interface currently > > > > > existing.) > > > > > > > > I think the spec needs to be clear if servers are required to allow > > > > filters to cover non-existing nodes or not (I think it should). > > > > Hence, selecting a non-existing node should not be an error. > > > > > > Agree. The " Receiver Authorization" section now has a clarified > > > sentence: > > > " A publisher MAY allow subscriptions which select non-existent or > > > access-protected data." > > > > So it seems you *didn't* agree with what I wrote :) > > > > With the selection filter algorithm you have chosen, I think the > > server MUST > > allow subscriptions that select non-existing instances. > > MUST forces a subscription to be accepted (even with other issues). Of course not. If there are other issues like out of resources or don't support on-change or whatever the subscription must not be accepted. > MAY gives the publisher the option of accepting a subscription > (something it has the right to do with any subscription). The point is that we need to specify what the expected behavior of a server is, so clients can code for that. There are two alternatives: 1. this is a required feature that all servers must support 2. this is an optional feature. If 2, how will a client know if the server supports the feature or not? Three alternatives: 2a. there's a YANG feature (or similar) that informs the client about this behavior 2b. the client doens't know and will have to guess 2c. the server informs the client in a way out of scope of this specification. Personally, I prefer 1. My reading of the currect document is 2b. > > At time t0 the filter might return a node set with a node. Then at > > time t1 > > the node set might be empty, this is then reported. Then at time t2 > > the > > node set contains a node again, this is then reported. > > Etc. > > Agree. This is a valid case where a publisher chose allowed a > subscription which might include empty node sets. > > > > > NOTE: we may want to handle the case that the client asks for a node > > > > that can *never* exist (e.g. a node in a non-implemented module or a > > > > misspelled node name) differently than the case that an instance > > > > doesn't exist. > > > > > > Agree. Such determination is up to the publisher. > > > > > > > > Likewise a publisher could choose to reject a subscription because > > > > > it is obvious that a subscriber will never have access to the > > > > > requested data. (E.g., maybe always disallow subscription to YANG > > > > > model which controls the configuration of private keys.) > > > > > > > > > > Pretending they might have access someday and allowing the > > > > > subscription will just waste resources. So I think the error is > > > > > useful for such situations. > > > > > > > > This is fine, but not what the current description says. The text > > > > in > > > > 3.9 and the YANG module don't match. > > > > > > on-change-unsupported definition now is: > > > "On-change is not supported for any objects which are likely to be > > > provided through the selection filter." > > > > See below. > > Any is correct. Reasoning is also below. > > > > > > > > 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. > > > > > > > > > > > > Ok; i.e., the text should explain that it is used if the client > > > > > > asks for an obejct that does not support on-change. The > > > > > > if-feature case is already handled as described above. > > > > > > > > > > Have changed the definition to: > > > > > "On-change is not supportable for any objects which may be > > > > > provided through the selection filter."; > > > > > > > > s/any/all/ ? > > > > > > Any. Because this includes any objects which might come into > > > existence under a subscribed subtree. > > > > Logically, "not for all" means that there exists one for which it it > > false. "not > > for any" is a bit unclear... > > > > Compare: > > > > "not all integers in the range 1..10 are even" > > > > with: > > > > "any integer in the range 1..10 is not even" > > > > > > How about: > > > > "This value means that on change is not supported for some node that > > may be selected by the given filter." > > A selection filter need not be designed to explicitly remove nodes > which are not-notifiable-on-change. These are automatically removed > without any knowledge of the filter, and need not be considered by the > designer of the filter. (I.e., you can on-change subscribe to > interfaces, and will never see any counters.) This behavior is not specified anywhere! This must be explained. Ok, so with this behavior I agree "any" is correct. I suggest: "This value means that on change is not supported for any node that may be selected by the given filter." > An on-change subscription should not be allow if it is unlikely there > will be any on-change nodes ever within its domain of selection. > > > > Tweaked the definition to: > > > "On-change is not supported for any objects which are likely to be > > > provided through the selection filter." > > > > "likely to be provided" is a bit confusing. > > "Likely to be provided" covers the case of nodes which don't exist as > the time of subscription, yet appear later. The "Likely to" is better > than "Never will" since it is theoretically possible for a system to > add a lightly protected node deep in a tree. But in that case it probably should not return this error. What does "provided through a filter" mean? I think "selected by a filter" is easier to understand. > > > > > > > > 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 > > > > > > > > > > > > But in this case the error will be "on-change-unsupported", right? > > > > > > > > > > I mean to say "except for" rather that e.g. My bad. > > > > > > > > > > > > ). Will enhance the > > > > > > > definition. > > > > > > > > > > Current text is now: > > > > > "Neither synch on start nor resynchonization are supported for > > > > > this subscription. This error will be used for two reasons. First > > > > > if an 'establish-subscription' RPC doesn't include > > > > > 'no-synch-on-start', yet the publisher can't support sending a > > > > > 'push update' for this subscription for reasons other that > > > > > 'on-change-unsupported' or 'result-too-big'. > > > > > > > > What would that reason be? > > > > > > One example might be the CPU capacity is prohibitively low at that > > > immediate time. Or there are too many subscriptions pulling counters > > > or routing tables or MAC addresses from a specific line card. Or > > > other platform wide issues which shouldn't fall under 'result-too-big' > > > because making the result smaller still won't result in the > > > subscription being allowed to push the state of current nodes. > > > > > > > I think that if the idea is that a server may or may not support > > > > sync on start, you should make a feature for it and call the leaf > > > > "sync-on-start" instead. And OTOH, if the default is sync on start > > > > (as it is now), it should be required to support it. > > > > You didn't reply to this comment. > > Synch-on-start should be the default, and should be required for a > platform to implement. At this point, I think I have to see the new draft to be able to comment further. I am a bit lost wrt what is required and what is optional and how that is communicated to the client. > > > > > However a patch must be able to do more than just describe the > > > > > delta from the previous state to the current state. As per > > > > target="on-change"/>, it must also be able to identify if > > > > > transient changes have occurred on an object during a dampening > > > > > period. To support this, it is valid to encode a YANG patch > > > > > operation so that its application would result in a no change > > > > > between the previous and current state. This indicates that some > > > > > churn has occurred on the object. An example of this would be a > > patch that does a "create" > > > > > operation for a datastore node where the receiver believes one > > > > > already exists, or a "merge" operation which replaces a previous > > > > > value with the same value. > > > > > > > > Hmm, I think that this is a very strange way to indicate "churn", it > > > > is very implicit. Is it really necessary to be able to indicate > > > > this "churn"? > > > > It seems > > > > quite complex on both the server and client side. > > > > If a client needs to know this information, it can just not specify > > > > a dampening period. > > > > > > Churn indication is an absolute *must* for security applications. > > > Both the SACM and I2NSF WGs have indicated need. It is also highly > > > useful for Network Management applications which simply cannot get a > > > continuous stream of interface flaps. This is a highly advantageous > > > capability and I have quite a few customer requests for this. > > > > Ok. (so what do you do if you know that churn has happend, but you > > have > > no idea what the churn was?) > > You will know the node has churned. You will know the latest change. > If you need to find out more, about the current datastore you can do a > get. If you need to know more about each change, you could check the > log. Applications never could get this type of information > efficiently before. > > > Depending on the outcome of the filter issue (full XPath/subtree > > filter vs. > > node-instance-identifier (BTW, will you crete a separate thread for > > that > > discussion?)), > > If you means Balazs discussion, then yes. On Tue, 5 Dec 2017 03:02:33 +0000, you wrote: I want to generalize this "only-keys?" issue for the full WG. It is too important to handle this deep in the thread. Look for me to open an issue shortly. That's the issue I was referring to. /martin > > I will have to come back to this issue. It seems awfully > > expensive to implement correctly. > > For a good view of why this is essential, see slides 29 & 30 of the > IETF 96 presentation on subscriptions at: > https://datatracker.ietf.org/meeting/96/materials/slides-96-netconf-5/ > > > /martin > From nobody Thu Dec 7 01:15: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 AFE831293D6 for ; Thu, 7 Dec 2017 01:15:15 -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 PV8HetqfGIQa for ; Thu, 7 Dec 2017 01:15:13 -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 4C6DF120454 for ; Thu, 7 Dec 2017 01:15:12 -0800 (PST) Received: from birdie1784 (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id A02C1645CA for ; Thu, 7 Dec 2017 10:15:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1512638109; bh=7Hobrtb1suBs4vesMOVLpjvEDTNFVWxGtbeFf5UwCD0=; h=From:To:Date; b=Wvc0NHmoAQClXC3o2MAdTTBDrrKz7cS0diJL28dv897lKG8ujGW8Lwz4/FtwwH/Mw bG3CrZVLuKxYUwqqSAILwM4/mltcZqe7s+H9avY/8rlSkY7ZM7K25NIlfufjxjdhH2 WEf7KITBXvokFt7XefbJnNQTC/7NiofqsvzDmseQ= Message-ID: <1512638108.22520.1.camel@nic.cz> From: Ladislav Lhotka To: netconf@ietf.org Date: Thu, 07 Dec 2017 10:15:08 +0100 In-Reply-To: References: 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] NETCONF WG virtual interim on YANG Library Wed Dec 13th 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, 07 Dec 2017 09:15:16 -0000 On Wed, 2017-12-06 at 22:57 +0000, Kent Watsen wrote: > Dear WG, > > Please be aware that the NETCONF WG will have a virtual interim next Wednesday > Dec 13 from 10am-noon Eastern (7am-9am Pacific). Unfortunately, I can't attend this interim although I'd like to. Lada > > The agenda for this meeting is as follows: > > 1) Review YANG Library proposals > Presenter: NMDA Authors > > This presentation will also go over topics raised during the > IETF 100 meeting including: > - licensing > - line card insertion/deletion > - semantic versioning > > Note: An email listing 2-3 proposals will be sent out later > this week. > > > 2) Discussion > Presenter: N/A (all) > > Goal is to select a proposal. > > > PS: Due to a malfunctioning webpage, this email is nether sent > by the IESG Secretary nor contains a Calendar invite having > the WebEX online meeting information. We are working with > the tools team to resolve the issue, and will send a proper > interim announcement ASAP. > > Kent (and Mahesh) // NETCONF WG co-chairs > > _______________________________________________ > 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 Thu Dec 7 06:04: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 95FAF129456 for ; Thu, 7 Dec 2017 06:04: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, 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 OD9c-m_6la_H for ; Thu, 7 Dec 2017 06:04:44 -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 612B9129455 for ; Thu, 7 Dec 2017 06:04:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22776; q=dns/txt; s=iport; t=1512655484; x=1513865084; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ONN83jNh+CP6PYxP6dnNx40XPu01toB5mgrmzmTsOtg=; b=a281xT+s2O993S3o0os4FXLozSOiGiHxju0hpuAoFY9+ya3M+sRVradk iww1ZEeX1T/ZWuz7/JYGV+J4LLO5aui0pznac8cZner4WE1pmaMhFmYFg +xBG3iHK2IrH7PyVfqhFrKQjYXp36Ak0q8uBdILp+FS7DCcEd123fWWkU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAQBJSSla/4sNJK1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDDy9mcicHg3uKII59gX2XCYIVChgLhANGTwIahUI/GAEBAQE?= =?us-ascii?q?BAQEBAWsdC4UiAQEBAQIBAQEhBA06EAsCAQYCEQQBAQECAgkaAwICAiULFAEIC?= =?us-ascii?q?AIEEwgTigQIEIlznWyBbTqKVwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+CRYI?= =?us-ascii?q?KgVaBaYMrhHYEARAdECOCW4JjBZIJkHgCh3aNHJNljQWJJwIRGQGBOgEfOYFPb?= =?us-ascii?q?xU6gimDB4FOeIc9AQElB4EFgRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,373,1508803200"; d="scan'208";a="41012666" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Dec 2017 14:04:43 +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 vB7E4gJn020257 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 7 Dec 2017 14:04:43 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, 7 Dec 2017 09:04:42 -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, 7 Dec 2017 09:04:42 -0500 From: "Eric Voit (evoit)" To: "netconf@ietf.org" Thread-Topic: [Netconf] Issue SN #5: How to represent Source VRF of configured subscription? Thread-Index: AdNdqNgU4QJmn1g8RCO8EZWBkLDxQwALeFkAAAkwfMAAWON/kAAnygQAAJhO04AACinC0P//tAyAgABTJJCAAJppAIAAJx6AgABLagD//9vuAIAAPCsw/+d4WcA= Date: Thu, 7 Dec 2017 14:04:42 +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> <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> In-Reply-To: <6e6cf4edb48441fbadb5e19b36d7a2ca@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.86.245.143] 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: Thu, 07 Dec 2017 14:04:48 -0000 QmFzZWQgb24gdGhlIGRpc2N1c3Npb25zIGNvbXBsZXRpbmcsIEkgYmVsaWV2ZSB0aGVyZSB0byBi ZSByb3VnaCBjb25zZW5zdXMgb24gdGhlIGNvbmZpZ3VyYXRpb24gb2YgYSBWUkYgZm9yIGEgY29u ZmlndXJlZCBzdWJzY3JpcHRpb24gYmVpbmcgdmlhIGEgbGVhZnJlZiB0byBuZXR3b3JrLWluc3Rh bmNlcyB3aXRoIHZyZi1zdXBwb3J0IGJlaW5nIGFuIGlmLWZlYXR1cmUuICBJLmUuOg0KKy0tcm8g c291cmNlLXZyZj8gICAtPiAgL25pOm5ldHdvcmstaW5zdGFuY2VzL25ldHdvcmstaW5zdGFuY2Uv bmFtZSB7c3VwcG9ydHMtdnJmfT8NCg0KQmFzZWQgb24gdGhlIHBsYW5uZWQgdGltZSBmcmFtZSBm b3IgbmV0d29yay1pbnN0YW5jZXMueWFuZyBnb2luZyB0byB0aGUgSUVTRywgSSBkb24ndCBleHBl Y3QgdGhlcmUgdG8gYmUgYW55IHRpbWluZyBpc3N1ZXMuICBCdXQgaWYgaXQgZG9lcyB0dXJuIG91 dCB0aGF0IHRoZXJlIGlzIGEgZGVsYXkgaW4gdGhpcyBkcmFmdCwgdGhpcyBpc3N1ZSBtYW55IG5l ZWQgdG8gYmUgcmV2aXNpdGVkLg0KDQpFcmljDQoNCj4gSGkgTG91LA0KPiANCj4gPiBGcm9tOiBM b3UgQmVyZ2VyLCBOb3ZlbWJlciAyMSwgMjAxNyA5OjM3IEFNDQo+ID4NCj4gPiBFcmljLA0KPiA+ DQo+ID4gU2VlIGJlbG93DQo+ID4NCj4gPiBPbiAxMS8yMS8yMDE3IDA4OjA2IEFNLCBFcmljIFZv aXQgKGV2b2l0KSB3cm90ZToNCj4gPiA+IEhpIExvdSwNCj4gPiA+DQo+ID4gPj4gRnJvbTogTG91 IEJlcmdlciwgTm92ZW1iZXIgMjEsIDIwMTcgNzoxNiBBTQ0KPiA+ID4+DQo+ID4gPj4gVGFraW5n IGEgc3RlcCBiYWNrOiB3aGF0IGlzIHRoZSBwdXJwb3NlIG9mIGhhdmluZyBzb3VyY2UtdnJmIGlu DQo+ID4gPj4gZHJhZnQtaWV0Zi0gbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnM/DQo+ ID4gPg0KPiA+ID4gVGhlcmUgYXJlIG1hbnkgdXNlcyBmb3IgdGhpcywgYW5kIG5vdCBoYXZpbmcg aXQgaXMgYWxyZWFkeSBiZWluZw0KPiA+ID4gc2VlbiBhcyBhDQo+ID4gcHJvZHVjdGlvbiBwcm9i bGVtIGluIHR3byBzZXBhcmF0ZSB0ZWxlbWV0cnkgZW52aXJvbm1lbnRzOg0KPiA+ID4gKDEpIEJl aW5nIGFibGUgdG8gcHVzaCB0ZWxlbWV0cnkgdHJhZmZpYyB0byBvbmUgb3IgbW9yZSBjb2xsZWN0 aW9uDQo+ID4gPiBWUkZzDQo+ID4gd2hpY2ggYXJlIG5vdCBleHBvc2VkIGluIHRoZSBnbG9iYWwg cm91dGluZyB0YWJsZS4NCj4gPg0KPiA+IEJ5ICJjb2xsZWN0aW9uIFZSRnMiIHlvdSBtZWFuIHRo YXQgdGhlIGNvbmZpZ3VyZWQgcmVjZWl2ZXJzIGFyZSBvbmx5DQo+ID4gcmVhY2hhYmxlIHdpdGhp biB0aGUgY29udGV4dCBvZiBhIFZSRi9OSSwgcmlnaHQ/ICBJZiBub3QsIEkgZG9uJ3QgdGhpbmsg SQ0KPiBmb2xsb3cuDQo+ID4gSSB0aGlzIGNhc2UsIHRoZSBTTiBjb25maWd1cmF0aW9uIGlzIHN0 aWxsIHNlcnZlci13aWRlIGFuZCBub3Qgc2NvcGVkDQo+ID4gcGVyIE5JL1ZSRiwgcmlnaHQ/DQo+ IA0KPiBZZXMgdG8gYm90aC4gICBIZXJlIHdlIGhhdmUgYSBUZWxlbWV0cnkgU2VydmVyIGdhdGhl cmluZyBwcmV0dHkgbXVjaA0KPiBhbnl0aGluZyBhYm91dCBhIHNldCBvZiBuZXR3b3JrIGRldmlj ZXMsIGJ1dCBzZW5kaW5nIHRoZSB0ZWxlbWV0cnkgdHJhZmZpYw0KPiBvdXQgb24gYSBkZWRpY2F0 ZWQgbWFuYWdlbWVudCBWUkYuDQo+IA0KPiA+ID4gKDIpIEJlaW5nIGFibGUgdG8gc2VuZCByb3V0 aW5nIGFuZCBzd2l0Y2hpbmcgaW5mbyByZWxldmFudCB0byBhDQo+ID4gPiBzcGVjaWZpYyBjdXN0 b21lciBWUkZzIG9uIHRoYXQgY3VzdG9tZXIncyBWUkYuICAoSS5lLiwgcHJvdmlkZQ0KPiA+ID4g dHJhZmZpYyBjb3VudGVycyB0byBhIGNvbGxlY3Rpb24gSVAgYWRkcmVzcy9kb21haW4gZm9yIHRo YXQgVlJGKQ0KPiA+DQo+ID4gTm93IHdlJ3JlIGdldHRpbmcgc29tZXdoZXJlLiAgU28geW91IGFs c28gaGF2ZSBhIHVzZSBjYXNlIHdoZXJlIFNOcw0KPiA+IGFyZSBWUkYtc3BlY2lmaWMsIHJpZ2h0 PyBEb2VzIGNvbmZpZyBoYXBwZW4gaW5zaWRlIHRoZSBjb250ZXh0IG9mIHRoZQ0KPiA+IFZSRiBv ciB0aGUgY29yZSBpbnN0YW5jZT8gIElzIHRoZXJlIGEgc2VwYXJhdGUgbG9naWNhbCBtYW5hZ2Vt ZW50DQo+ID4gaW5zdGFuY2UgZm9yIHRoZSBWUkY/DQo+IA0KPiBUaGUgY29uZmlndXJhdGlvbiBv ZiB0aGUgc3Vic2NyaXB0aW9uIGlzIGluIHRoZSBjb3JlIGluc3RhbmNlLiAgIEkgaGF2ZSBub3Qg eWV0DQo+IGhlYXJkIGFueSByZXF1aXJlbWVudHMgZm9yIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9u cyB1bmRlciBhIFZSRiBpbnN0YW5jZS4NCj4gDQo+ID4gPg0KPiA+ID4+IEZyb20gdGhlIGNvbmZp Z3VyYXRpb24gc2lkZSwgdGhlIG1vZGVsIHNlZW1zIHRvIGFsbG93IHRoZQ0KPiA+ID4+IGNvbmZp Z3VyYXRpb24gb2YgYW4gSVAgYWRkcmVzcyBmb3LCoCBub3RpZmljYXRpb24tbWVzc2FnZS1vcmln aW4NCj4gPiA+PiB0aGF0IGRvZXNuJ3QgbWF0Y2ggYW55IGNvbmZpZ3VyZWQgaW50ZXJmYWNlLsKg IERvZXMgdGhpcyByZWFsbHkgbWFrZQ0KPiBzZW5zZT8NCj4gPiA+PiBXaHkgbm90IGp1c3QgbGlt aXQgY29uZmlndXJhdGlvbiB0byBpZjppbnRlcmZhY2UtcmVmPw0KPiA+ID4NCj4gPiA+IFRoZSBw ZXJzb24gZG9pbmcgdGhlIGNvbmZpZ3VyYXRpb24gbmVlZCBoYXZlIG5vIHVuZGVyc3RhbmRpbmcg b2YgdGhlDQo+ID4gaW50ZXJmYWNlcyBvbiB0aGUgcm91dGVyLiAgSW4gYWRkaXRpb24sIGlmIHRo ZSBuaS1uYW1lIGlzIHRoZSBzYW1lDQo+ID4gYWNyb3NzIHJvdXRlcnMsIHRoZSBzYW1lIG5pLW5h bWUgY2FuIGJlIHVzZWQgYWNyb3NzIHRoZSBkb21haW4gd2l0aG91dA0KPiA+IGtub3dsZWRnZSBv ZiBzdWNoIGRldmljZSBzcGVjaWZpY3MuDQo+ID4gPg0KPiA+DQo+ID4gU28gdGhpcyBzb3VuZHMg bGlrZSB0aGUgcHJvdmlkZXIgY29uZmlnIHBvbGljeSwgcmlnaHQ/DQo+IA0KPiBEZXBlbmRpbmcg b24gd2hhdCB5b3UgbWVhbiBieSB0aGF0LCBJIGJlbGlldmUgdGhlIGFuc3dlciBpcyBZZXMuICBU aGUNCj4gY29uZmlndXJhdGlvbiBwb2xpY3kgaXMgdG8gc2VuZCB0byBhbiBJUCBhZGRyZXNzIG9u IHRoaXMgVlJGLiAgIEFuZCBmb3INCj4gbWFuYWdlbWVudCBzaW1wbGlmaWNhdGlvbi9zZWN1cml0 eSwgd2UgYXJlIG5vdCBhbGxvd2luZyBhIHNpbmdsZQ0KPiBzdWJzY3JpcHRpb24gdG8gaGF2ZSBp bmRlcGVuZGVudCByZWNlaXZlcnMgbG9jYXRlZCBpbiBkaWZmZXJlbnQgVlJGcy4NCj4gDQo+ID4g Pj4gRG9pbmcgdGhpcyBlbGltaW5hdGVzIHRoZSB3aG9sZSBWUkYgZGlzY3Vzc2lvbiBmb3IgdGhp cyBtb2RlbCAob2YNCj4gPiA+PiBjb3Vyc2UsIEknbSBub3Qgc2F5aW5nIHRoZSBkaXNjdXNzaW9u IHdvbid0IGhhcHBlbiBpbiBvdGhlcg0KPiA+ID4+IGNvbnRleHRzKS4NCj4gPiA+Pg0KPiA+ID4+ IFdoYXQgYW0gSSBtaXNzaW5nPw0KPiA+ID4NCj4gPiA+IFRoaXMgdHlwZSBvZiBjb25maWd1cmF0 aW9uIGlzIHJlYWxseSBhaW1lZCBhdCBhIGxldmVsIGhpZ2hlciB0aGFuDQo+ID4gPiBzb21lb25l DQo+ID4gd2hvIG5lZWRzIGNhcmUgYWJvdXQgdG9wb2xvZ3kgaXNzdWVzLg0KPiA+DQo+ID4gV2hh dCB0b3BvbG9neSBpc3N1ZXM/DQo+IA0KPiBUb3BvbG9neSBpc3N1ZXMgd2FzIHNob3J0LWhhbmQg Zm9yIG5ldHdvcmtpbmcgc3BlY2lmaWNzLiAgTGV0J3Mgc2F5IHRoZQ0KPiBzdWJzY3JpcHRpb24g aXMganVzdCBmb3IgQ1BVIFRlbXBlcmF0dXJlLCBvciBmb3IgY29uZmlndXJlZCBrZXlzLCBvciBm b3INCj4gcnVubmluZyBwcm9jZXNzZXMsIGV0Yy4uLiAgIEluIHRoaXMgY2FzZSwgdGhlcmUgaXMg bm8gbmVlZCB0byBjYXJlIGFib3V0DQo+IGludGVyZmFjZXMsIGxpbmsgc3RhdHVzLCBhZGphY2Vu Y2llcywgZXRjLg0KPiANCj4gPiA+IFRoZXkganVzdCB3YW50IHNvbWV0aGluZyBvdXQgb2YgdGhl IG5ldHdvcmsgY2xvdWQuICAgSXQgaXMgcXVpdGUgcG9zc2libGUNCj4gPiB0byBjb25maWd1cmUg dGhlIHNhbWUgc3Vic2NyaXB0aW9uIGluZm8gdG8gYWxsIGRldmljZXMgaW4gYSBkb21haW4NCj4g PiB3aXRob3V0IGFueSBwZXItZGV2aWNlIGRldmlhdGlvbnMgYXQgYWxsLiAgKEkuZS4sIHNhbWUg Y29uZmlndXJlZA0KPiA+IHN1YnNjcmlwdGlvbi1pZCwgc2FtZSBmaWx0ZXIsIHNhbWUgVlJGLCBz YW1lIHBlcmlvZCwgLi4uKQ0KPiA+DQo+ID4gU28gdGhpcyBjYXNlIHdvdWxkIGNvbmZpZ3VyZSB2 cmYgYnV0IG5vdCBzb3VyY2UgSVAsIHJpZ2h0PyAgSXMgdGhlcmUgYQ0KPiA+IHVzZSBjYXNlIGZv ciBzb3VyY2UgaXA/DQo+IA0KPiBZZXMuICBBdCBsZWFzdCBvbmUgbGFyZ2UgZGF0YSBjZW50ZXIg Y3VzdG9tZXIgaGFzIHdhbnRlZCB0byB1c2Ugc291cmNlLUlQIHRvDQo+IGFsbG93IGRpZmZlcmVu dGlhdGlvbiBvZiBjb250ZW50IG9uIHRoZSBXQU4uICAgVGhpcyBpcyBwcmVzdW1hYmx5IGZvciBR b1MNCj4gcHVycG9zZXMuICAgUGVyc29uYWxseSBJIHdvdWxkIHJhdGhlciB1c2Ugb3RoZXIgUW9T IGNvbnN0cnVjdHMgYXMgdGhlcmUgaXMNCj4gbGVzcyBjaGFuZ2UgZm9yIG1pc3MtY29uZmlndXJh dGlvbi4gIEJ1dCBzaWduYWxpbmcgdmlhIHNvdXJjZSBhZGRyZXNzIGlzIGENCj4gdmFsaWQgd2F5 IHRvIGRvIG5ldHdvcmsgZGVzaWduIHdoaWNoIHJlbGllcyBsZXNzIG9uIHRoZSBjYXBhYmlsaXRp ZXMgb2YNCj4gc3BlY2lmaWMgdmVuZG9ycy4NCj4gDQo+ID4gPg0KPiA+ID4+IEFsc28gaWYgeW91 IGRvIGtlZXAgJ3NvdXJjZS12cmYnIEkgdGhpbmsgJ3NvdXJjZS1uaS1uYW1lJyBpcyBtb3JlDQo+ ID4gPj4gY29uc2lzdGVudCB3aXRoIGRyYWZ0LWlldGYtcnRnd2ctbmktbW9kZWwgYXVnbWVudGF0 aW9ucyBvZg0KPiBpZjppbnRlcmZhY2UuDQo+ID4gPg0KPiA+ID4gIk5pLW5hbWUiIGlzIG1vcmUg Z2VuZXJpYyBiZWNhdXNlIGl0IHN1cHBvcnRzIG1vcmUgdHlwZXMgb2YNCj4gPiA+IHRlY2hub2xv Z2llcw0KPiA+IHRoYW4gcmVxdWlyZWQgYXQgdGhpcyB0aW1lLiAgIEFzIG5vIGN1c3RvbWVyIGlz IHRhbGtpbmcgYWJvdXQgdGhpbmdzDQo+IGJleW9uZA0KPiA+IFZSRiwgaW5zdGFsbGluZyB0aGUg bW9yZSBnZW5lcmljIG5hbWUgd291bGQgYmUgYW4gYWRkZWQgbGF5ZXIgb2YNCj4gPiBjb21wbGV4 aXR5Lg0KPiA+DQo+ID4gdGhlIGF1Z21lbnRhdGlvbiB0byBpbnRlcmZhY2VzIGlzIGNhbGxlZCBi aW5kLW5pLW5hbWUsIGFzIGxvbmcgYXMgeW91DQo+ID4gcmVmZXJlbmNlIGl0IG9yIG5pLW5hbWUg YWxsIGlzIGdvb2QuDQo+IA0KPiBFeGNlbGxlbnQuICAgTW9kZWwgbm93IHVzZXM6DQo+IA0KPiAg ICAgICAgICAgdHlwZSBsZWFmcmVmIHsNCj4gICAgICAgICAgICAgcGF0aCAiL25pOm5ldHdvcmst aW5zdGFuY2VzL25pOm5ldHdvcmstaW5zdGFuY2Uvbmk6bmFtZSI7DQo+ICAgICAgICAgICB9DQo+ IA0KPiBFcmljDQo+IA0KPiANCj4gPiBMb3UNCj4gPiA+DQo+ID4gPiBFcmljDQo+ID4gPg0KPiA+ ID4+IExvdQ0KPiA+ID4+DQo+ID4gPj4gT24gMTEvMjEvMjAxNyA0OjU2IEFNLCBSb2JlcnQgV2ls dG9uIHdyb3RlOg0KPiA+ID4+Pg0KPiA+ID4+PiBJIHRoaW5rIHRoYXQgdXNpbmcgYSBmZWF0dXJl IGlzIGJldHRlciBoZXJlLsKgIERlZmluaW5nIGEgc2VwYXJhdGUNCj4gPiA+Pj4gbW9kdWxlIGZv ciBqdXN0IG9uZSBsZWFmIHNlZW1zIHNvbWV3aGF0IGxpa2Ugb3ZlcmtpbGwuDQo+ID4gPj4+DQo+ ID4gPj4+IEknbSBub3Qgc3VyZSB0aGF0IGFueSBjb21waWxlIHRpbWUgZGVwZW5kZW5jeSBvbiBu ZXR3b3JrDQo+ID4gPj4+IGluc3RhbmNlcywgYW5kIGhlbmNlIHNjaGVtYSBtb3VudCwgaXMgcmVh bGx5IGFuIGlzc3VlOyB0aGUgbW9yZQ0KPiA+ID4+PiBpbXBvcnRhbnQgb25lIHRvIGF2b2lkIGlz IHRoZSBydW4gdGltZSBkZXBlbmRlbmN5IG9uIG5ldHdvcmsNCj4gPiA+Pj4gaW5zdGFuY2VzIGFu ZCBzY2hlbWEgbW91bnQsIGFuZCBib3RoIHNvbHV0aW9ucyBhY2hpZXZlIHRoaXMuDQo+ID4gPj4+ DQo+ID4gPj4+IEJ1dCBJIGFsc28gYWdyZWUgd2l0aCBKdWVyZ2VuJ3MgY29tbWVudCB0aGF0IHdl IHNob3VsZCBiZQ0KPiA+ID4+PiBjb25zaXN0ZW50LCBhbmQgdGhlIHNhbWUgYXBwcm9hY2ggc2hv dWxkIGJlIHVzZWQgZm9yIG90aGVyDQo+ID4gPj4+IHByb3RvY29scyB3aXRoIGNvbmRpdGlvbmFs IGRlcGVuZGVuY2llcyBvbiBuZXR3b3JrIGluc3RhbmNlcyBhcw0KPiB3ZWxsLg0KPiA+ID4+Pg0K PiA+ID4+PiBUaGFua3MsDQo+ID4gPj4+IFJvYg0KPiA+ID4+Pg0KPiA+ID4+Pg0KPiA+ID4+PiBP biAyMC8xMS8yMDE3IDE5OjU0LCBFcmljIFZvaXQgKGV2b2l0KSB3cm90ZToNCj4gPiA+Pj4+DQo+ ID4gPj4+PiAqRnJvbToqQWxleGFuZGVyIENsZW1tLCBOb3ZlbWJlciAyMCwgMjAxNyAyOjQ2IFBN DQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+PiBIaSBFcmljLA0KPiA+ID4+ Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4gSSBhZ3JlZSB0aGF0IHByb2xpZmVyYXRp b24gb2YgbW9kdWxlcyBpcyBhIGNvbmNlcm4sIGFuZCBjZXJ0YWlubHkNCj4gPiA+Pj4+IHdlIHdv dWxkIG5vdCB3YW50IHRvIHJ1biBpbnRvIGNvbWJpbmF0b3JpYWwgZXhwbG9zaW9ucy7CoCBIb3dl dmVyLA0KPiA+ID4+Pj4gSSBkb27igJl0IHRoaW5rIHRoaXMgd291bGQgYmUgdGhlIGNhc2UgaGVy ZSAtIHdlIHdvdWxkIG5vdCBuZWVkIHRvDQo+ID4gPj4+PiBhdWdtZW50IFZSRiBpbnRvIHlhbmct cHVzaCBhbHNvIChvciB5YW5nLXB1c2ggaW50byBWUkYpLg0KPiA+ID4+Pj4gSW5zdGVhZCwgYm90 aCB5YW5nLXB1c2ggYW5kIHZyZi1mb3Itbm90aWZpY2F0aW9ucyB3b3VsZCBiZQ0KPiA+ID4+Pj4g YXVnbWVudGluZyBzdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMgaW4gcGFyYWxsZWwuDQo+ID4gPj4+ Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+PiA8RXJpYz7CoCBZZXMsIHlvdSBhcmUgcmln aHQsIHdpdGggdGhpcyBhcHByb2FjaCB3ZSB3b3VsZCBlbmQgd2l0aA0KPiA+ID4+Pj4gdGhyZWUg bW9kZWxzIHJhdGhlciB0aGFuIGZvdXIuwqAgQnV0IHR3byBtb2RlbHMgaXMgYWxyZWFkeSBhIGxv dC4NCj4gPiA+Pj4+IMKgQW5kIHdlIHN0aWxsIHNldCBwcmVjZWRlbmNlIHRoYXQgd2UgZW5kIHdp dGggYSBuZXcgVlJGIHNwZWNpZmljDQo+ID4gPj4+PiBtb2RlbCBldmVyeSB0aW1lIGFueSBZQU5H IG1vZGVsIG5lZWRzIGEgVlJGLg0KPiA+ID4+Pj4NCj4gPiA+Pj4+IEVyaWMNCj4gPiA+Pj4+DQo+ ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+IC0tLSBBbGV4DQo+ID4gPj4+Pg0KPiA+ID4+Pj4N Cj4gPiA+Pj4+DQo+ID4gPj4+PiAqRnJvbToqRXJpYyBWb2l0IChldm9pdCkgW21haWx0bzpldm9p dEBjaXNjby5jb21dDQo+ID4gPj4+PiAqU2VudDoqIE1vbmRheSwgTm92ZW1iZXIgMjAsIDIwMTcg MTE6MzkgQU0NCj4gPiA+Pj4+ICpUbzoqIEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1t QGh1YXdlaS5jb20NCj4gPiA+Pj4+IDxtYWlsdG86YWxleGFuZGVyLmNsZW1tQGh1YXdlaS5jb20+ PjsgUm9iZXJ0IFdpbHRvbiAtWA0KPiAocndpbHRvbiAtDQo+ID4gPj4+PiBFTlNPRlQgTElNSVRF RCBhdCBDaXNjbykgPHJ3aWx0b25AY2lzY28uY29tDQo+ID4gPj4+PiA8bWFpbHRvOnJ3aWx0b25A Y2lzY28uY29tPj47IG5ldGNvbmZAaWV0Zi5vcmcNCj4gPiA+Pj4+IDxtYWlsdG86bmV0Y29uZkBp ZXRmLm9yZz47IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQNCj4gPiA+Pj4+IDxtYWlsdG86 bGJlcmdlckBsYWJuLm5ldD4+DQo+ID4gPj4+PiAqU3ViamVjdDoqIFJFOiBbTmV0Y29uZl0gSXNz dWUgU04gIzU6IEhvdyB0byByZXByZXNlbnQgU291cmNlIFZSRg0KPiA+ID4+Pj4gb2YgY29uZmln dXJlZCBzdWJzY3JpcHRpb24/DQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+ PiBJIGFncmVlIHRoaXMgaXMgbW9yZSBlbGVnYW50IGlmIHdlIGxvb2sganVzdCBhdA0KPiA+ID4+ Pj4gc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zLsKgwqAgSG93ZXZlciBleHRyYXBvbGF0aW5nIHRo aXMgbWVhbnMgdGhhdA0KPiA+ID4+Pj4gd2UgaGF2ZSBhIGR1cGxpY2F0ZSBZQU5HIG1vZHVsZSBl dmVyeSB0aW1lIHdlIGhhdmUgYSBWUkYuwqDCoCBBbmQNCj4gPiA+Pj4+IGluIG91ciBjYXNlIHdo ZW4gd2UgYXVnbWVudCB5YW5nLXB1c2gsIHdoaWNoIG1vZGVsIGRvIHdlIHN0YXJ0DQo+ID4gZnJv bT8NCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+IEVyaWMNCj4gPiA+Pj4+ DQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+ICpGcm9tOipBbGV4YW5kZXIgQ2xlbW0gW21h aWx0bzphbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbV0NCj4gPiA+Pj4+ICpTZW50OiogTW9uZGF5 LCBOb3ZlbWJlciAyMCwgMjAxNyAyOjI3IFBNDQo+ID4gPj4+PiAqVG86KiBSb2JlcnQgV2lsdG9u IC1YIChyd2lsdG9uIC0gRU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pDQo+ID4gPj4+PiA8cndpbHRv bkBjaXNjby5jb20gPG1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbT4+OyBFcmljIFZvaXQgKGV2b2l0 KQ0KPiA+ID4+Pj4gPGV2b2l0QGNpc2NvLmNvbSA8bWFpbHRvOmV2b2l0QGNpc2NvLmNvbT4+OyBu ZXRjb25mQGlldGYub3JnDQo+ID4gPj4+PiA8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+OyBMb3Ug QmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0DQo+ID4gPj4+PiA8bWFpbHRvOmxiZXJnZXJAbGFibi5u ZXQ+Pg0KPiA+ID4+Pj4gKlN1YmplY3Q6KiBSRTogW05ldGNvbmZdIElzc3VlIFNOICM1OiBIb3cg dG8gcmVwcmVzZW50IFNvdXJjZSBWUkYNCj4gPiA+Pj4+IG9mIGNvbmZpZ3VyZWQgc3Vic2NyaXB0 aW9uPw0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4gSSBhbSBmaW5lIHdp dGggdGhhdCBjaGFuZ2UsIGJ1dCB3YW50ZWQgdG8gYnJpbmcgdXAgb25lIGFkZGl0aW9uYWwNCj4g PiA+Pj4+IG9wdGlvbiB0aGF0IHdhcyBhbHNvIGJyaWVmbHkgbWVudGlvbmVkIGluIHRoZSByb29t IHdoaWNoIHN0cmlrZXMNCj4gPiA+Pj4+IG1lIGFzIHBlcmhhcHMgYSBiaXQgbW9yZSBlbGVnYW50 LsKgIFRoYXQgaXMgdGhlIG9wdGlvbiB0byB1c2UNCj4gPiA+Pj4+IGF1Z21lbnRhdGlvbi7CoCBJ biB0aGF0IGNhc2UsIHNvdXJjZS12cmYgYW5kIHRoZSBpbXBvcnQgc3RhdGVtZW50DQo+ID4gPj4+ PiB3b3VsZCBzaW1wbHkgYmUgb21pdHRlZC4gSW5zdGVhZCwgYSBuZXcgbW9kdWxlIHdvdWxkIGJl IGNyZWF0ZWQNCj4gPiAoZS5nLg0KPiA+ID4+Pj4gaWV0Zi12cmYtZm9yLXN1YnNjcmliZWQtbm90 aWZpY2F0aW9ucyksIHdoaWNoIGNvbnRhaW5zIHRoZSBpbXBvcnQNCj4gPiA+Pj4+IHN0YXRlbWVu dCBhbmQgdHdvIGF1Z21lbnRzIHN0YXRlbWVudHMgdG8gYXVnbWVudCB0aGUgc291cmNlLXZyZg0K PiA+ID4+Pj4gaW50byB0aGUgZXhpc3RpbmcgbW9kdWxlLg0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ ID4gPj4+Pg0KPiA+ID4+Pj4gLS0tIEFsZXgNCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4N Cj4gPiA+Pj4+ICpGcm9tOipOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3Jn XSAqT24gQmVoYWxmIE9mDQo+ID4gPj4+PiAqUm9iZXJ0IFdpbHRvbg0KPiA+ID4+Pj4gKlNlbnQ6 KiBGcmlkYXksIE5vdmVtYmVyIDE3LCAyMDE3IDEwOjQ2IEFNDQo+ID4gPj4+PiAqVG86KiBFcmlj IFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tDQo+ID4gPj4+PiA8bWFpbHRvOmV2b2l0QGNp c2NvLmNvbT4+OyBuZXRjb25mQGlldGYub3JnDQo+ID4gPj4+PiA8bWFpbHRvOm5ldGNvbmZAaWV0 Zi5vcmc+OyBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0DQo+ID4gPj4+PiA8bWFpbHRvOmxi ZXJnZXJAbGFibi5uZXQ+Pg0KPiA+ID4+Pj4gKlN1YmplY3Q6KiBSZTogW05ldGNvbmZdIElzc3Vl IFNOICM1OiBIb3cgdG8gcmVwcmVzZW50IFNvdXJjZSBWUkYNCj4gPiA+Pj4+IG9mIGNvbmZpZ3Vy ZWQgc3Vic2NyaXB0aW9uPw0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4N Cj4gPiA+Pj4+DQo+ID4gPj4+PiBPbiAxNy8xMS8yMDE3IDE4OjE3LCBFcmljIFZvaXQgKGV2b2l0 KSB3cm90ZToNCj4gPiA+Pj4+DQo+ID4gPj4+PiAgICAgSSB3b3VsZCBsaWtlIHRvIGNvbnRpbnVl IHRoZSBkaXNjdXNzaW9uIG9uIHRoaXMgdG9waWMgZnJvbSBvdXINCj4gPiA+Pj4+ICAgICBzZXNz aW9uLsKgwqAgSSB0aGluayB3ZSBjYW1lIHRvIGFncmVlbWVudCBhbW9uZyB0aGUgYXR0ZW5kZWVz Lg0KPiA+ID4+Pj4gICAgIEhvcGVmdWxseSB0aGlzIHRocmVhZCBjYW4gY29uZmlybSwgb3IgcmVm aW5lIGFzIG5lZWQuDQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+PiAgICAg Rmlyc3QgbGV04oCZcyBsb29rIGF0IFJvYmVydOKAmXMgcHJvcG9zYWwgYmVsb3c6DQo+ID4gPj4+ Pg0KPiA+ID4+Pj4gICAgIFRoZXJlIGFyZSBsb3RzIG9mIGdvb2QgZWxlbWVudHMgaW4gUm9iZXJ0 4oCZcyBwcm9wb3NhbCBiZWxvdywgYnV0DQo+ID4gPj4+PiAgICAgaXQgaXNu4oCZdCB1cCB0byBv dXIgV0cgdG8gZGV0ZXJtaW5lIHRoZSBwcm9wZXIgc3RydWN0dXJlIG9mIHRoZQ0KPiA+ID4+Pj4g ICAgIG5ldHdvcmstaW5zdGFuY2UtbW9kZWwuwqDCoCBBdXRob3JzIG9mIHRoYXQgbW9kZWwgd2Vy ZSBpbiB0aGUNCj4gcm9vbSwNCj4gPiA+Pj4+ICAgICBhbmQgYXJlIGF3YXJlIHRoYXQgWUFORyBt b2RlbCBkZXZlbG9wZXJzIGZyb20gb3V0c2lkZSB3b3VsZA0KPiA+ID4+Pj4gICAgIHdlbGNvbWUg YSBwYXJ0aXRpb25pbmcgd2hpY2ggZGVjb3VwbGVzIGFueSBsaW5rYWdlcyB0bw0KPiA+ID4+Pj4g ICAgIHNjaGVtYS1tb3VudCB3aGVuIGFsbCB0aGF0IGlzIG5lZWRlZCBpcyB0byBpZGVudGlmeSBh IFZSRiBieQ0KPiBuYW1lLg0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4g ICAgIExvb2tpbmcgYXQgd2hhdCB3ZSBjYW4gY29udHJvbCwgZGlzY3Vzc2VkIGluIHRoZSByb29t IHdhcyB0aGUNCj4gPiA+Pj4+ICAgICBmb2xsb3dpbmcgY2hhbmdlIHRvIHN1YnNjcmliZWQtbm90 aWZpY2F0aW9uczoNCj4gPiA+Pj4+DQo+ID4gPj4+PiAgICAgMS7CoMKgwqDCoMKgIGltcG9ydCDi gJxpZXRmLW5ldHdvcmstaW5zdGFuY2XigJ0NCj4gPiA+Pj4+DQo+ID4gPj4+PiAgICAgMi7CoMKg wqDCoMKgIGNyZWF0ZSBpZi1mZWF0dXJlIOKAnFZSRuKAnS4NCj4gPiA+Pj4+DQo+ID4gPj4+PiAg ICAgMy7CoMKgwqDCoMKgIGFwcGx5IGZlYXR1cmUg4oCcVlJG4oCdIHRvIG9iamVjdCDigJxzb3Vy Y2UtVlJG4oCdDQo+ID4gPj4+Pg0KPiA+ID4+Pj4gICAgIDQuwqDCoMKgwqDCoCBMZWFmcmVmIHRv IOKAnHNvdXJjZS1WUkbigJ0gdG8gdmFsaWRhdGUgYWdhaW5zdCB0aGUNCj4gPiA+Pj4+ICAgICBu ZXR3b3JrLWluc3RhbmNlIG1vZGVs4oCZcw0KPiA+ID4+Pj4gL25ldHdvcmstaW5zdGFuY2VzL25l dHdvcmstaW5zdGFuY2UvbmFtZS4NCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+ Pj4+ICAgICBUaGlzIGlzIHRoZSBjdXJyZW50IHByb3Bvc2FsLsKgIEFyZSB0aGVyZSBhcmUNCj4g PiA+Pj4+ICAgICBjb25jZXJucy9vYmplY3Rpb25zL3JlZmluZW1lbnRzPw0KPiA+ID4+Pj4NCj4g PiA+Pj4+DQo+ID4gPj4+PiBObyBjb25jZXJucywgYnV0IHBlcmhhcHMgb25lIHRyaXZpYWwgcmVm aW5lbWVudC4NCj4gPiA+Pj4+DQo+ID4gPj4+PiBJIGhhZCBtaXN0YWtlbmx5IHRob3VnaHQgdGhh dCBhIGRldmljZSB3b3VsZCBlaXRoZXIgc3VwcG9ydCBWUkZzDQo+ID4gPj4+PiBmb3IgYWxsIHBy b3RvY29scyBvciBub25lLCBoZW5jZSBteSBzdWdnZXN0aW9uIHRvIGhhdmUgYSBzaW5nbGUNCj4g IlZSRiINCj4gPiA+Pj4+IGZlYXR1cmUsIHdoaWNoIHdvdWxkIG5hdHVyYWxseSBiZSBkZWZpbmVk IGJ5IHRoZQ0KPiA+ID4+Pj4gbmV0d29yay1pbnN0YW5jZXMNCj4gPiA+PiBtb2RlbC4NCj4gPiA+ Pj4+DQo+ID4gPj4+PiBJbiB0aGUgZGlzY3Vzc2lvbnMgdGhhdCBJIGhhZCB3aXRoIExvdSwgc29t ZSBvZiB0aGVtIGF0IHRoZSBtaWMsDQo+ID4gPj4+PiBzb21lIGFmdGVyd2FyZHMsIExvdSBjbGFy aWZpZWQgdGhhdCBpdCBxdWl0ZSBwbGF1c2libGUgdGhhdCBWUkZzDQo+ID4gPj4+PiBtYXkgb25s eSBiZSBzdXBwb3J0ZWQgYnkgc29tZSBwcm90b2NvbHMgb24gYSBkZXZpY2UgYW5kIG5vdCBhbGws DQo+ID4gPj4+PiBhbmQgaGVuY2UgdGhlIHNvbHV0aW9uIG9mIGhhdmluZyBhICJWUkYiIGZlYXR1 cmUgcGVyIHByb3RvY29sDQo+ID4gPj4+PiBzZWVtcyBsaWtlIHRoZSByaWdodCBzb2x1dGlvbi4N Cj4gPiA+Pj4+DQo+ID4gPj4+PiBJIHRoaW5rIHRoYXQgSSB3b3VsZCBjYWxsIHRoZSBmZWF0dXJl ICJzdXBwb3J0cy12cmYiIHJhdGhlciB0aGFuICJ2cmYiLg0KPiA+ID4+Pj4NCj4gPiA+Pj4+IFRo YW5rcywNCj4gPiA+Pj4+IFJvYg0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+ Pj4gICAgIEVyaWMNCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4g Pj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+PiAgICAgKkZyb206Kk5ldGNvbmYgW21h aWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YNCj4gPiA+Pj4+ICAg ICAqRXJpYyBWb2l0IChldm9pdCkNCj4gPiA+Pj4+ICAgICAqU2VudDoqIFR1ZXNkYXksIE5vdmVt YmVyIDE0LCAyMDE3IDEwOjIzIFBNDQo+ID4gPj4+PiAgICAgKlRvOiogUm9iZXJ0IFdpbHRvbiAt WCAocndpbHRvbiAtIEVOU09GVCBMSU1JVEVEIGF0IENpc2NvKQ0KPiA+ID4+Pj4gICAgIDxyd2ls dG9uQGNpc2NvLmNvbT4gPG1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbT47DQo+ID4gbmV0Y29uZkBp ZXRmLm9yZw0KPiA+ID4+Pj4gICAgIDxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz47IExvdSBCZXJn ZXIgPGxiZXJnZXJAbGFibi5uZXQ+DQo+ID4gPj4+PiAgICAgPG1haWx0bzpsYmVyZ2VyQGxhYm4u bmV0Pg0KPiA+ID4+Pj4gICAgICpTdWJqZWN0OiogUmU6IFtOZXRjb25mXSBJc3N1ZSBTTiAjNTog SG93IHRvIHJlcHJlc2VudCBTb3VyY2UNCj4gVlJGDQo+ID4gPj4+PiAgICAgb2YgY29uZmlndXJl ZCBzdWJzY3JpcHRpb24/DQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+PiAg ICAgQWdyZWUgaXQgaXMgYSBnZW5lcmljIHByb2JsZW0uDQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4g PiA+Pj4+DQo+ID4gPj4+PiAgICAgSSB3b3VsZCBkZWZlciB0byBMb3UgYW5kIHRoZSBvdGhlciBh dXRob3JzIG9mDQo+ID4gPj4+PiAgICAgZHJhZnQtaWV0Zi1ydGd3Zy1uaS1tb2RlbCBhcyB0aGlz IHdvdWxkIGJlIGEgZmFpcmx5IHNpZ25pZmljYW50DQo+ID4gPj4+PiAgICAgY2hhbmdlLg0KPiA+ ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4gICAgIEVyaWMNCj4gPiA+Pj4+DQo+ ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+ICAgICAqRnJvbToqUm9iZXJ0IFdpbHRvbiwgTm92 ZW1iZXIgMTQsIDIwMTcgNzo1OCBQTQ0KPiA+ID4+Pj4NCj4gPiA+Pj4+ICAgICBIaSBFcmljLCBM b3UsDQo+ID4gPj4+Pg0KPiA+ID4+Pj4gICAgIFRoaXMgc2VlbXMgdG8gYmUgYSBnZW5lcmljIHBy b2JsZW0uDQo+ID4gPj4+Pg0KPiA+ID4+Pj4gICAgIENvdWxkIHRoZSBWUkYgbGVhZnJlZiBuYW1l IGRlcGVuZGVuY3kgaXNzdWUgYmUgc29sdmVkIHdpdGggYW4NCj4gPiA+Pj4+ICAgICBpZi1mZWF0 dXJlIHN0YXRlbWVudD8uDQo+ID4gPj4+Pg0KPiA+ID4+Pj4gICAgIEkuZS5jb3VsZCB0aGUgbmV0 d29yayBpbnN0YW5jZSBkcmFmdCBkZWZpbmUgYSBzZXBhcmF0ZSBZQU5HDQo+ID4gPj4+PiAgICAg bW9kdWxlICh3aXRoIG5vIGRlcGVuZGVuY2llcykgdGhhdCBkZWZpbmVzIGEgIlZSRiIgZmVhdHVy ZS4NCj4gPiA+Pj4+DQo+ID4gPj4+PiAgICAgQWxsIHRoZSBWUkYgcmVmZXJlbmNlcyAoaWRlYWxs eSBpZiBhbGwgSUVURiBZQU5HIG1vZHVsZXMgdGhhdCBtYXkNCj4gPiA+Pj4+ICAgICBvcHRpb25h bGx5IGRlcGVuZCBvbiBWUkZzKSBjb3VsZCBiZSBsZWFmLXJlZnMgdG8NCj4gPiA+Pj4+ICAgICAv bmV0d29yay1pbnN0YW5jZXMvbmV0d29yay1pbnN0YW5jZS9uYW1lIGJ1dCBwcmVkaWNhdGVkIHdp dGgNCj4gYW4NCj4gPiA+Pj4+ICAgICBpZi1mZWF0dXJlICJuaTp2cmYiLg0KPiA+ID4+Pj4NCj4g PiA+Pj4+ICAgICBIZW5jZSBpZiBhIGRldmljZSBkb2Vzbid0IHN1cHBvcnQgVlJGcywgdGhlbiBp dCBkb2Vzbid0IGltcGxlbWVudA0KPiA+ID4+Pj4gICAgIHRoZSAidnJmIiBmZWF0dXJlLCBzbyBp dCBkb2Vzbid0IGhhdmUgdG8gaW1wbGVtZW50IHRoZSBmdWxsDQo+ID4gPj4+PiAgICAgbmV0d29y ayBpbnN0YW5jZXMgbW9kdWxlLCBvciBzY2hlbWEgbW91bnQuDQo+ID4gPj4+Pg0KPiA+ID4+Pj4g ICAgIFRoYW5rcywNCj4gPiA+Pj4+ICAgICBSb2INCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+ Pj4NCj4gPiA+Pj4+ICAgICBPbiAxNS8xMS8yMDE3IDA4OjQ1LCBFcmljIFZvaXQgKGV2b2l0KSB3 cm90ZToNCj4gPiA+Pj4+DQo+ID4gPj4+PiAgICAgICAgIEluIHRoZSBXRyBzZXNzaW9uIHRvbW9y cm93LCBJIGFtIGhvcGluZyB0byBnZXQg4oCcaHVtDQo+IGZlZWRiYWNr4oCdDQo+ID4gPj4gb246 DQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+PiAgICAgICAgIGRyYWZ0LWll dGYtbmV0Y29uZi1zdWJzY3JpYmVkLW5vdGlmaWNhdGlvbnMNCj4gPiA+Pj4+DQo+ID4gPj4+PiAg ICAgICAgIGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3JmYzUyNzdiaXMvaXNzdWVzLzUN Cj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+ICAgICAgICAgVGhlIHR3byBj aG9pY2VzIGV4cG9zZWQgZHVyaW5nIHRoZSB0d28gd2VlayByZXZpZXcgZm9yIGhvdw0KPiB0bw0K PiA+ID4+Pj4gICAgICAgICByZXByZXNlbnQgU291cmNlIFZSRiBvZiBjb25maWd1cmVkIHN1YnNj cmlwdGlvbiB3ZXJlOg0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4gICAg ICAgICAoMSkgTGVhZnJlZiB0byDigJxpZXRmLW5ldHdvcmstaW5zdGFuY2XigJ0NCj4gPiA+Pj4+ ICAgICAgICAgL25ldHdvcmstaW5zdGFuY2VzL25ldHdvcmstaW5zdGFuY2UvbmFtZQ0KPiA+ID4+ Pj4NCj4gPiA+Pj4+ICAgICAgICAgwrfCoMKgwqDCoMKgwqDCoCBDcmVhdGVzIGRlcGVuZGVuY3kg b24gc2NoZW1hIG1vdW50IGZvciBzdWJzY3JpcHRpb25zLg0KPiA+ID4+Pj4NCj4gPiA+Pj4+ICAg ICAgICAgwrfCoMKgwqDCoMKgwqDCoCBTb3VyY2UgVlJGIGlzIGFuIG9wdGlvbmFsIGNhcGFiaWxp dHksIGJ1dCBwdWJsaXNoZXJzDQo+ID4gPj4+PiAgICAgICAgIHRoYXQgZG9u4oCZdCBjYXJlIGFi b3V0IFZSRnMgbXVzdCBzdGlsbCBpbXBvcnQuwqAgKE5vdGU6IGNvdWxkDQo+ID4gPj4+PiAgICAg ICAgIGFsc28gYXVnbWVudCB0aGUgbGVhZnJlZiBpbiBhbm90aGVyIG1vZGVsLCBidXQgdGhhdCBh ZGRzDQo+ID4gPj4+PiAgICAgICAgIGFub3RoZXIgbGF5ZXIgb2YgY29tcGxleGl0eSkNCj4gPiA+ Pj4+DQo+ID4gPj4+PiAgICAgICAgIMK3wqDCoMKgwqDCoMKgwqAgZXN0YWJsaXNoZXMgbW9kZWwg ZGVwZW5kZW5jeSB0bw0KPiA+ID4+Pj4gICAgICAgICBkcmFmdC1pZXRmLXJ0Z3dnLW5pLW1vZGVs DQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+PiAgICAgICAgICgyKSBVc2Ug YSBzdHJpbmcgd2hpY2ggd291bGQgYmUgcG9wdWxhdGVkIHdpdGggZXhhY3Qgc2FtZQ0KPiA+ID4+ Pj4gICAgICAgICBuYW1lIGFzIHdvdWxkIGJlIGluIHRoZSBsZWFmcmVmIG9mICgxKQ0KPiA+ID4+ Pj4NCj4gPiA+Pj4+ICAgICAgICAgwrfCoMKgwqDCoMKgwqDCoCBQb3NzaWJsZSB0byBuYW1lIFZS RiB3aGljaCBkb2VzbuKAmXQgZXhpc3QNCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4g PiA+Pj4+ICAgICAgICAgVGhlIGN1cnJlbnQgZHJhZnQgZG9lcyAoMikuDQo+ID4gPj4+Pg0KPiA+ ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+PiAgICAgICAgIFRoYW5rcywNCj4gPiA+Pj4+DQo+ID4g Pj4+PiAgICAgICAgIEVyaWMNCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+ DQo+ID4gPj4+Pg0KPiA+ID4+Pj4gICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4+Pj4NCj4gPiA+Pj4+ICAgICAgICAgTmV0Y29uZiBt YWlsaW5nIGxpc3QNCj4gPiA+Pj4+DQo+ID4gPj4+PiAgICAgICAgIE5ldGNvbmZAaWV0Zi5vcmcg PG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KPiA+ID4+Pj4NCj4gPiA+Pj4+ICAgICAgICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo+ID4gPj4+Pg0KPiA+ ID4+Pj4NCj4gPiA+Pj4+DQo+ID4gPj4+PiAgICAgLg0KPiA+ID4+Pj4NCj4gPiA+Pj4+DQo+ID4g Pj4+Pg0KPiA+ID4+Pg0KPiA+ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+IE5ldGNvbmZAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQo= From nobody Thu Dec 7 06:09: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 7AEFF12945A for ; Thu, 7 Dec 2017 06:09:08 -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_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 47bVAIylLB74 for ; Thu, 7 Dec 2017 06:09:02 -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 B8157120721 for ; Thu, 7 Dec 2017 06:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14202; q=dns/txt; s=iport; t=1512655741; x=1513865341; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=VhzKwaIUA8BKw+HFd4BqSEWYhOZNovqQBwDsDtZpEig=; b=UyFWxzh9r0HbPE/OqkM2hXsJNAx0az6cPxlTDBWQ4aQCEmfmsedoNaA2 uQVLrQtzvwUTLC79wYGctpIsOQpt4Uyme+FWTBSw60D4pM2xlzvMa0PMd NApPwwQNPiytEV5x94G7c92I0ag+lC1Bp8BS6RaQZsWV5pAPhW1sakNkq g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAQDJSila/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnInB4N7iiCOfYF9lwkUggEKGAuESU8CGoVDPxgBAQEBAQE?= =?us-ascii?q?BAQFrHQuFIgEBAQEDAQEhEToGEQQCAQgRBAEBAQICCRYEAwICAiULFAEICAIEE?= =?us-ascii?q?wgTigwQp1uCJ4pXAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4JFggqBVoFpgyu?= =?us-ascii?q?FCS+CfoJjBaMBAod2jRyTZY0FiScCERkBgToBHzmBT28VOoIpgweBTniHPSuBC?= =?us-ascii?q?IEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,373,1508803200"; d="scan'208";a="327779344" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Dec 2017 14:09:00 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id vB7E8xi0023175 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 7 Dec 2017 14:08:59 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, 7 Dec 2017 09:08:58 -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, 7 Dec 2017 09:08:58 -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+YAAEmKugAAKViNQABak1OAEAaKY4A== Date: Thu, 7 Dec 2017 14:08:58 +0000 Message-ID: <535a854490d149b0a5b68247f047b65e@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> <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-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.86.245.143] 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, 07 Dec 2017 14:09:08 -0000 Tm8gb2JqZWN0aW9uIGhhcyBiZWVuIGFzc2VydGVkLiAgUm91Z2ggY29uc2Vuc3VzIGhhcyBiZWVu IGFjaGlldmVkLiAgVGhlIG5vbi1OTURBIHJlcHJlc2VudGF0aW9uIGlzOg0KDQogICAgKy0tcncg c3Vic2NyaXB0aW9uLWNvbmZpZyB7Y29uZmlndXJlZH0/DQogICAgICAgKy0tcncgc3Vic2NyaXB0 aW9uKiBbaWRlbnRpZmllcl0NCiAgICAgICAgICArLS1ydyBpZGVudGlmaWVyICAgICAgICAgICAg ICAgICAgICAgc3Vic2NyaXB0aW9uLWlkDQogICAgICAgICAgKy0tcncgcHJvdG9jb2wgICAgICAg ICAgICAgICAgICAgICAgIHRyYW5zcG9ydCB7Y29uZmlndXJlZH0/DQogICAgICAgICAgKy0tcncg ZW5jb2RpbmcgICAgICAgICAgICAgICAgICAgICAgIGVuY29kaW5nDQoNClRoZSBOTURBIHJlcHJl c2VudGF0aW9uIHdpbGwgYmUgc2VlbiBzaG9ydGx5Lg0KDQpFcmljDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgVm9pdA0KPiAoZXZvaXQpDQo+IFNlbnQ6IEZyaWRh eSwgTm92ZW1iZXIgMTcsIDIwMTcgMToxNyBQTQ0KPiBUbzogbmV0Y29uZkBpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW05ldGNvbmZdIElzc3VlIFNOICM0OiBDYW4gVHJhbnNwb3J0IHZhcnkgYWNy b3NzIGRpZmZlcmVudA0KPiByZWNlaXZlcnMgb2YgYSBzaW5nbGUgY29uZmlndXJlZCBzdWJzY3Jp cHRpb24/DQo+IA0KPiBJbiB0aGUgbWVldGluZyByb29tIGRpc2N1c3Npb24gZHVyaW5nIHRoZSBO RVRDT05GIFdHLCBzZW50aW1lbnQgd2FzIHRvDQo+IHVzZSBhIGNvbW1vbiBUcmFuc3BvcnQgYWNy b3NzIGFsbCByZWNlaXZlcnMgb2YgYSBzaW5nbGUgY29uZmlndXJlZA0KPiBzdWJzY3JpcHRpb24u ICAgVGhpcyB3YXMgcHJvcG9zYWwgKDIpIGJlbG93Lg0KPiANCj4gSSB3b3VsZCBsaWtlIHRvIHNl ZSBpZiB0aGVyZSBpcyBhbnkgb2JqZWN0aW9uIHRvIHRoaXMuICAgSWYgbm90LCB3ZSBjYW4gY2xv c2UgdGhpcw0KPiBpc3N1ZSBpbiBhIGZldyB3ZWVrcy4NCj4gDQo+IEVyaWMNCj4gDQo+ID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29u Zi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRXJpYyBWb2l0DQo+ID4gKGV2b2l0KQ0K PiA+IFNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxNiwgMjAxNyAzOjMwIEFNDQo+ID4gVG86IE1h cnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPjsgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVp bmFybm4pDQo+ID4gPGVpbmFybm5AY2lzY28uY29tPg0KPiA+IENjOiBuZXRjb25mQGlldGYub3Jn DQo+ID4gU3ViamVjdDogUmU6IFtOZXRjb25mXSBJc3N1ZSBTTiAjNDogQ2FuIFRyYW5zcG9ydCB2 YXJ5IGFjcm9zcw0KPiA+IGRpZmZlcmVudCByZWNlaXZlcnMgb2YgYSBzaW5nbGUgY29uZmlndXJl ZCBzdWJzY3JpcHRpb24/DQo+ID4NCj4gPiBIaSBNYXJ0aW4sDQo+ID4NCj4gPiBZZXMsIEkgb3Jp Z2luYWxseSBoYWQgYm90aCB5b3VyIG9wdGlvbnMgaW4gdGhlIFdHIHNsaWRlcy4gICAgSSByZW1v dmVkIChBKQ0KPiA+IGFmdGVyIGRpc2N1c3Npb24gd2l0aCBNYWhlc2ggZm9yIHRoZSBXRyBzZXNz aW9uIHNsaWRlcyB0byBzaW1wbGlmeSB0aGUNCj4gPiBpbi0gcm9vbSBkaXNjdXNzaW9ucywgYXMg d2VsbCBhcyBjb25zaWRlcmF0aW9uIG9mIHRoZSBwb2ludHMgRWluYXIgbWFrZXMNCj4gYmVsb3cu DQo+ID4gV2UgY2FuIG9mIGNvdXJzZSBoYXZlIG1vcmUgYW5kIGRlZXBlciByZXNvbHV0aW9uIGRp c2N1c3Npb25zIGhlcmUuDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gRXJpYw0KPiA+DQo+ID4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogTWFydGluIEJqb3JrbHVuZCBb bWFpbHRvOm1iakB0YWlsLWYuY29tXQ0KPiA+ID4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDE2 LCAyMDE3IDI6NTQgQU0NCj4gPiA+IFRvOiBFaW5hciBOaWxzZW4tTnlnYWFyZCAoZWluYXJubikg PGVpbmFybm5AY2lzY28uY29tPg0KPiA+ID4gQ2M6IEVyaWMgVm9pdCAoZXZvaXQpIDxldm9pdEBj aXNjby5jb20+OyBuZXRjb25mQGlldGYub3JnDQo+ID4gPiBTdWJqZWN0OiBSZTogW05ldGNvbmZd IElzc3VlIFNOICM0OiBDYW4gVHJhbnNwb3J0IHZhcnkgYWNyb3NzDQo+ID4gPiBkaWZmZXJlbnQg cmVjZWl2ZXJzIG9mIGEgc2luZ2xlIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uPw0KPiA+ID4NCj4g PiA+IEhpLA0KPiA+ID4NCj4gPiA+IE5vdGUgdGhhdCB0aGUgaXNzdWUgaXMgdGhhdCB0aGUgY3Vy cmVudCBtb2RlbCBoYXM6DQo+ID4gPg0KPiA+ID4gICAgICAgKy0tcncgc3Vic2NyaXB0aW9uKiBb aWRlbnRpZmllcl0NCj4gPiA+ICAgICAgICAgIC4uLg0KPiA+ID4gICAgICAgICAgKy0tcncgZW5j b2RpbmcNCj4gPiA+ICAgICAgICAgIC4uLg0KPiA+ID4gICAgICAgICAgKy0tcncgcmVjZWl2ZXJz DQo+ID4gPiAgICAgICAgICAgICArLS1ydyByZWNlaXZlciogW2FkZHJlc3MgcG9ydF0NCj4gPiA+ ICAgICAgICAgICAgICAgIC4uLg0KPiA+ID4gICAgICAgICAgICAgICAgKy0tcncgcHJvdG9jb2wN Cj4gPiA+DQo+ID4gPiBNeSBwcm9wb3NhbCBpcyBoYXZlIGVuY29kaW5nIGFuZCBwcm90b2NvbCB0 b2dldGhlcjoNCj4gPiA+DQo+ID4gPiAoQSkNCj4gPiA+ICAgICAgICstLXJ3IHN1YnNjcmlwdGlv biogW2lkZW50aWZpZXJdDQo+ID4gPiAgICAgICAgICAuLi4NCj4gPiA+ICAgICAgICAgIC4uLg0K PiA+ID4gICAgICAgICAgKy0tcncgcmVjZWl2ZXJzDQo+ID4gPiAgICAgICAgICAgICArLS1ydyBy ZWNlaXZlciogW2FkZHJlc3MgcG9ydF0NCj4gPiA+ICAgICAgICAgICAgICAgIC4uLg0KPiA+ID4g ICAgICAgICAgICAgICAgKy0tcncgcHJvdG9jb2wNCj4gPiA+ICAgICAgICAgICAgICAgICstLXJ3 IGVuY29kaW5nDQo+ID4gPg0KPiA+ID4gb3I6DQo+ID4gPg0KPiA+ID4gKEIpDQo+ID4gPiAgICAg ICArLS1ydyBzdWJzY3JpcHRpb24qIFtpZGVudGlmaWVyXQ0KPiA+ID4gICAgICAgICAgLi4uDQo+ ID4gPiAgICAgICAgICArLS1ydyBlbmNvZGluZw0KPiA+ID4gICAgICAgICAgKy0tcncgcHJvdG9j b2wNCj4gPiA+ICAgICAgICAgIC4uLg0KPiA+ID4gICAgICAgICAgKy0tcncgcmVjZWl2ZXJzDQo+ ID4gPiAgICAgICAgICAgICArLS1ydyByZWNlaXZlciogW2FkZHJlc3MgcG9ydF0NCj4gPiA+ICAg ICAgICAgICAgICAgIC4uLg0KPiA+ID4NCj4gPiA+IEkgdGhpbmsgdGhhdCB0aGlzIGlzICpsZXNz KiBjb21wbGV4IGFuZCBwcm9iYWJseSBtb3JlIG9wdGltYWwgdGhhbg0KPiA+ID4gdGhlIGN1cnJl bnQgc29sdXRpb24uDQo+ID4gPg0KPiA+ID4gIkVpbmFyIE5pbHNlbi1OeWdhYXJkIChlaW5hcm5u KSIgPGVpbmFybm5AY2lzY28uY29tPiB3cm90ZToNCj4gPiA+ID4gTWFydGluLA0KPiA+ID4gPg0K PiA+ID4gPiBBcyB5ZXQsIHdlIGhhdmUgbm8gcHJhY3RpY2FsIHVzZSBjYXNlcyB3aGVyZSB3ZSB3 b3VsZCBoYXZlIGENCj4gPiA+ID4gc2luZ2xlIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIHdpdGgg bXVsdGlwbGUgcmVjZWl2ZXJzIHdobyB3aXNoIHRvDQo+ID4gPiA+IHJlY2VpdmUgdGhlIGRhdGEg aW4gZGlmZmVyZW50IGZvcm1hdHMuIFRodXMgc3VwcG9ydGluZyB0aGlzIHNlZW1zDQo+ID4gPiA+ IGxpa2UgYW4gdW5uZWNlc3NhcnkgY29tcGxleGl0eSBmb3IgcGxhdGZvcm1zLCBhbmQgb25lIHdo aWNoDQo+ID4gPiA+IHBvdGVudGlhbGx5IGltcGFjdHMgb3B0aW1pc2F0aW9ucyB0aGF0IHdlIGFs cmVhZHkgdXNlIGluIHNvbWUNCj4gPiA+ID4gcGxhdGZvcm0gaW1wbGVtZW50YXRpb25zIChlLmcu IHNlbmRpbmcgdGhlIHNhbWUgZW5jb2RlZCBQRFUgdG8NCj4gPiA+ID4gbXVsdGlwbGUgcmVjZWl2 ZXJzLCByZWxpZXZpbmcgdGhlIHBsYXRmb3JtIG9mIGVuY29kaW5nIHRoZSBzYW1lDQo+ID4gPiA+ IGRhdGEgbXVsdGlwbGUgd2F5cykuDQo+ID4gPg0KPiA+ID4gQnV0IHRoaXMgb3B0aW1pemF0aW9u IGRvZXNuJ3QgcmVhbGx5IHdvcmssIGFzIHlvdSBub3RlIGJlbG93ICgqKS4NCj4gPiA+DQo+ID4g PiA+IE9mIGNvdXJzZSwgaWYgYSBjbGllbnQgcmVhbGx5IHdhbnRzIHRvIGhhdmUgdGhlIHNhbWUg ZGF0YSBzZW50IHRvDQo+ID4gPiA+IG11bHRpcGxlIHJlY2VpdmVycyBidXQgaW4gZGlmZmVyZW50 IGZvcm1hdHMsIHRoZXkgY2FuIGRvIHRoaXMg4oCUDQo+ID4gPiA+IGp1c3QgcHJvdmlzaW9uIHNl cGFyYXRlIHN1YnNjcmlwdGlvbnMgd2l0aCB0aGUgc2FtZSBmaWx0ZXIuDQo+ID4gPg0KPiA+ID4g RXhhY3RseTsgdGhpcyBpcyBtb3JlIGNvbXBsZXggYW5kIGxlc3Mgb3B0aW1hbCBzaW5jZSB0aGUg c2FtZSBmaWx0ZXINCj4gPiA+IG1pZ2h0IGJlIGV2YWx1YXRlZCB0d2ljZSwgdW5sZXNzIHlvdSBh ZGQgY29kZSB0byBvcHRpbWl6ZSBmb3IgdGhhdA0KPiA+ID4gKHdoaWNoIHByb2JhYmx5IGZhbGxz IGluIHlvdXIgY2F0ZWdvcnkgb2YgInVubmVjZXNzYXJ5IGNvbXBsZXhpdHkiKS4NCj4gPiA+DQo+ ID4gPiAoKikgU28gaWYgdGhlIG9wZXJhdG9yIHJlcXVpcmVzIHRoaXMgc2V0dXAsIGhlIHdpbGwg aGF2ZSB0bw0KPiA+ID4gY29uZmlndXJlIHR3byBkaWZmZXJlbnQgc3Vic2NyaXB0aW9ucyB0b2Rh eS4gIFRodXMsIHRoZSBwbGF0Zm9ybQ0KPiA+ID4gd2lsbCBlbmNvZGUgdGhlIGRhdGEgdHdpY2Us IGFuZCB5b3VyIG9wdGltaXphdGlvbiBhYm92ZSB3b24ndCBoZWxwLg0KPiA+ID4NCj4gPiA+ID4g QWxsLWluLWFsbCwgSSBkb27igJl0IHNlZSBhbnkgYmVuZWZpdCBpbiBtYWtpbmcgdGhlIGJhc2Ug bW9kZWwNCj4gPiA+ID4gc3VwcG9ydCB0aGlzLCBvbmx5IGRvd25zaWRlcywgc28gZG8geW91IGhh dmUgYW55IHNwZWNpZmljIHVzZQ0KPiA+ID4gPiBjYXNlcyBpbiBtaW5kIHdoZXJlIHRoaXMgd291 bGQgYmUgYSBiZW5lZml0PyBTbyBmYXIgaW4gdGhlIHVzZQ0KPiA+ID4gPiBjYXNlcyB3ZSBoYXZl IGxvb2tlZCBhdCBpbiBTUCwgREMsIGVudGVycHJpc2UgYW5kIElvVCB3ZSBoYXZlIG5vdA0KPiA+ ID4gPiBzZWVuIGFueSByZXF1aXJlbWVudCB0byBzdXBwb3J0IHRoaXMsIGJ1dCB3ZSBoYXZlIHNl ZW4gdGhlIG5lZWQNCj4gPiA+ID4gZm9yIG11bHRpcGxlDQo+ID4gcmVjZWl2ZXJzIChlLmcuDQo+ ID4gPiA+IHRvIHN1cHBvcnQgSEEvcmVkdW5kYW5jeSBhcHByb2FjaGVzKS4NCj4gPiA+DQo+ID4g PiBUaGUgY3VycmVudCBtb2RlbCBzdXBwb3J0cyBkaWZmZXJlbnQgKnByb3RvY29scyogZm9yIHRo ZSBkaWZmZXJlbnQNCj4gPiA+IHJlY2VpdmVycy4gIERvIHlvdSBoYXZlIGEgdXNlIGNhc2Ugc3Vw cG9ydGluZyB0aGF0LCBvciB3b3VsZCAoQikNCj4gPiA+IGFib3ZlIGZ1bGZpbCB5b3VyIHJlcXVp cmVtZW50cy4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gL21hcnRpbg0KPiA+ID4NCj4gPiA+DQo+ID4g Pg0KPiA+ID4gPiBBcyBzdWNoLCBJIHdvdWxkIGJlDQo+ID4gPiA+IHJlbHVjdGFudCB0byBhZGQg dGhpcyB0byB0aGUgZHJhZnQgYXQgdGhpcyBzdGFnZSB3aGVuIHRoZQ0KPiA+ID4gPiBmdW5jdGlv bmFsaXR5IGNhbiBiZSBhY2hpZXZlZCBhbHJlYWR5IGlmIGFic29sdXRlbHkgbmVjZXNzYXJ5Lg0K PiA+ID4gPg0KPiA+ID4gPiBDaGVlcnMsDQo+ID4gPiA+DQo+ID4gPiA+IEVpbmFyDQo+ID4gPiA+ DQo+ID4gPiA+DQo+ID4gPiA+ID4gT24gMTUgTm92IDIwMTcsIGF0IDIxOjUzLCBFcmljIFZvaXQg KGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPg0KPiB3cm90ZToNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ IEFkZGluZyBFaW5hciBhcyBoZSBoYWQgc29tZSBzdHJvbmcgb3BpbmlvbnMgb24gdGhpcyBhIGZl dyB5ZWFycw0KPiA+ID4gPiA+IGFnbyB3aGVuIHdlIHdlcmUgc2V0dGluZyB0aGUgbW9kZWwuLi4N Cj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4+IEZyb206IE1hcnRpbiBCam9ya2x1bmQs IE5vdmVtYmVyIDE1LCAyMDE3IDEwOjQzIEFNDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+ICJFcmlj IFZvaXQgKGV2b2l0KSIgPGV2b2l0QGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4gPiA+ID4+PiBIaSBN YXJ0aW4sDQo+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+Pj4+IEZyb206IE1hcnRpbiBCam9ya2x1bmQg W21haWx0bzptYmpAdGFpbC1mLmNvbV0NCj4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+Pj4+ICJFcmlj IFZvaXQgKGV2b2l0KSIgPGV2b2l0QGNpc2NvLmNvbT4gd3JvdGU6DQo+ID4gPiA+ID4+Pj4+IElu IHRoZSBXRyBzZXNzaW9uIHRvbW9ycm93LCBJIGFtIGhvcGluZyB0byBnZXQgImh1bQ0KPiBmZWVk YmFjayINCj4gPiA+IG9uOg0KPiA+ID4gPiA+Pj4+Pg0KPiA+ID4gPiA+Pj4+Pg0KPiA+ID4gPiA+ Pj4+Pg0KPiA+ID4gPiA+Pj4+PiBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3RpZmlj YXRpb25zDQo+ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9u ZXRjb25mLXdnL3JmYzUyNzdiaXMvaXNzdWVzLzQNCj4gPiA+ID4gPj4+Pj4NCj4gPiA+ID4gPj4+ Pj4NCj4gPiA+ID4gPj4+Pj4NCj4gPiA+ID4gPj4+Pj4gVGhlIHR3byBjaG9pY2VzIGFuZCB0aGVp ciBpc3N1ZXMgZXhwb3NlZCBkdXJpbmcgdGhlIHR3byB3ZWVrDQo+ID4gPiA+ID4+Pj4+IHJldmll dyBvbg0KPiA+ID4gPiA+Pj4+ICJDYW4gVHJhbnNwb3J0IHZhcnkgYWNyb3NzIGRpZmZlcmVudCBy ZWNlaXZlcnMgb2YgYSBzaW5nbGUNCj4gPiA+ID4gPj4+PiBjb25maWd1cmVkIHN1YnNjcmlwdGlv bj8iIGFyZToNCj4gPiA+ID4gPj4+Pj4NCj4gPiA+ID4gPj4+Pj4NCj4gPiA+ID4gPj4+Pj4NCj4g PiA+ID4gPj4+Pj4gKDEpIFllcywgVHJhbnNwb3J0IGNhbiB2YXJ5IGJ5IHJlY2VpdmVyDQo+ID4g PiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+ICogICAgICAgIEZld2VyIHN1YnNjcmlwdGlvbnMgKHNj YWxlIGJlbmVmaXQpDQo+ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+ICogICAgICAgIENhbiBj b252ZXJ0IHRyYW5zcG9ydCB3aXRob3V0IHJlcXVpcmluZyBhbiBhcHBsaWNhdGlvbiB0bw0KPiA+ ID4gbGVhcm4NCj4gPiA+ID4gPj4gYQ0KPiA+ID4gPiA+Pj4+IG11bHRpcGxlIHN1YnNjcmlwdGlv biBpZHMNCj4gPiA+ID4gPj4+Pj4NCj4gPiA+ID4gPj4+Pj4gKiAgICAgICAgTm8gZHVwbGljYXRp b24gb2YgY29udGVudCBkdXJpbmcgdHJhbnNwb3J0IGNvbnZlcnNpb24uDQo+ID4gPiA+ID4+Pj4+ DQo+ID4gPiA+ID4+Pj4+ICogICAgICAgIChQb3RlbnRpYWwgY29uZnVzaW9uIGluIGFsbG93aW5n IHRyYW5zcG9ydCB0byB2YXJ5LCBidXQNCj4gPiA+ID4gPj4+Pj4gKiAgICAgICAgZW5jb2RpbmcN Cj4gPiA+ID4gPj4gbm90DQo+ID4gPiA+ID4+Pj4gdG8gdmFyeT8pDQo+ID4gPiA+ID4+Pj4+DQo+ ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+ICgyKSBObywgb25seSBv bmUgVHJhbnNwb3J0IGFjcm9zcyBhbGwgc3Vic2NyaXB0aW9ucw0KPiA+ID4gPiA+Pj4+Pg0KPiA+ ID4gPiA+Pj4+PiAqICAgICAgICBTaW1wbGVyIG1vZGVsDQo+ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ ID4+Pj4+ICogICAgICAgIEJ1dCBhcHBsaWNhdGlvbnMgbWF5IG5lZWQgdG8gY3JlYXRlIGFuZCB0 cmFjayBtdWx0aXBsZQ0KPiA+ID4gPiA+Pj4+IHN1YnNjcmlwdGlvbi1pZHMgZm9yIHRoZSBzYW1l IGNvbnRlbnQuDQo+ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+ICogICAgICAgIFRlbXBvcmFy eSBkdXBsaWNhdGlvbiBvZiBjb250ZW50IHN0cmVhbXMgZHVyaW5nDQo+IHRyYW5zcG9ydA0KPiA+ ID4gPiA+PiBjaGFuZ2UuDQo+ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+Pj4+DQo+ID4gPiA+ID4+ Pj4+DQo+ID4gPiA+ID4+Pj4+IFRoZSBjdXJyZW50IGRyYWZ0IGRvZXMgKDEpLg0KPiA+ID4gPiA+ Pj4+DQo+ID4gPiA+ID4+Pj4gQWN0dWFsbHksIHRoZSBnaXRodWIgaXNzdWUgbGlzdHMgMyBvcHRp b25zLCBidXQgaGVyZSB5b3UganVzdCBsaXN0IDIuDQo+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+Pj4g SW4gcmV2aWV3aW5nIHRvbW9ycm93J3Mgc2xpZGVzIHdpdGggTWFoZXNoLCBoZSBwcmVmZXJyZWQg Mg0KPiA+IG9wdGlvbnMuDQo+ID4gPiA+ID4+PiBBbmQgYXMgdmFyeWluZyB0aGUgZW5jb2Rpbmcg YnkgcmVjZWl2ZXIgc2VlbXMgdW5saWtlbHkgaW4NCj4gPiA+ID4gPj4+IGltcGxlbWVudGF0aW9u DQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IFdoeSBpcyB0aGlzIHVubGlrZWx5PyAgU3VwcG9zZSBJ IGhhdmUgdHdvIHJlY2VpdmVycyBmb3IgdGhlDQo+ID4gPiA+ID4+IHNhbWUgc3Vic2NyaXB0aW9u LCBvbmUgd2FudHMgTkVUQ09ORi9YTUwgYW5kIHRoZSBvdGhlcg0KPiA+ID4gUkVTVENPTkYvSlNP Ti4NCj4gPiA+ID4gPj4gSXMgdGhhdCB1bmxpa2VseT8NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEVp bmFyJ3MgYmVsaWVmIHdhcyB0aGF0IGEgcHVibGlzaGVyIGltcGxlbWVudGF0aW9uIHdvdWxkIGJl DQo+ID4gPiA+ID4gdW5saWtlbHkgdG8gc2VydmljZSBhIHNpbmdsZSBzdWJzY3JpcHRpb24gaW50 byBtdWx0aXBsZSBlbmNvZGluZ3MuDQo+ID4gPiA+ID4gSWYgc3VjaCBhIGNvbmRpdGlvbiBleGlz dGVkLCBpdCB3b3VsZCBiZSBmYXIgZWFzaWVyIHRvIGNyZWF0ZQ0KPiA+ID4gPiA+IHR3bw0KPiA+ IHN1YnNjcmlwdGlvbnMuDQo+ID4gPiA+ID4gVGhpcyBhbHNvIHdvdWxkIGhhdmUgZmV3ZXIgZXJy b3IgY29uZGl0aW9ucy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+Pj4gLCB0aGVyZSBpcyBsaXR0bGUg cmVhc29uIHRvIHNvY2lhbGl6ZSB0aGlzIHVubGlrZWx5IHZhcmlhbnQgYmVmb3JlDQo+ID4gPiA+ ID4+PiB0aGUgd2hvbGUgV0cuICAgU2luY2UgYXMgeW91ciBvcGluaW9uIHdhcyBlaXRoZXIgYm90 aCBlbmNvZGluZw0KPiA+IGFuZA0KPiA+ID4gPiA+Pj4gdHJhbnNwb3J0IG9yIG5laXRoZXIgZW5j b2RpbmcgYW5kIHRyYW5zcG9ydCB2YXJ5IGJ5IHJlY2VpdmVyLA0KPiA+ID4gPiA+Pj4gdGhlIG1v cmUgbGlrZWx5IG9mIHlvdXIgcHJpbWFyeSBhc2sgaXMgc3VwcG9ydGVkLg0KPiA+ID4gPiA+Pj4N Cj4gPiA+ID4gPj4+DQo+ID4gPiA+ID4+Pj4gSSB0aGluayB0aGUgcG9pbnQgaXMgdGhhdCBpbiB0 aGUgdGVybSAiVHJhbnNwb3J0Iiwgd2UgbmVlZCB0bw0KPiA+ID4gPiA+Pj4+IGluY2x1ZGUgYm90 aCBwcm90b2NvbCBhbmQgZW5jb2RpbmcgKGluIHRoZSBjYXNlIHRoZSBwcm90b2NvbA0KPiA+ID4g PiA+Pj4+IHN1cHBvcnRzIG11bHRpcGxlIGVuY29kaW5ncykuDQo+ID4gPiA+ID4+Pg0KPiA+ID4g PiA+Pj4gV2hpbGUgbW9zdCBsaWtlbHkgdGhlIGNhc2UgZm9yIE5FVENPTkYgYW5kIFJFU1RDT05G LCBUaWFucmFuJ3MNCj4gPiA+ID4gPj4+IGRyYWZ0LWlldGYtbmV0Y29uZi11ZHAtcHViLWNoYW5u ZWwgc2hvd3MgdGhhdCB0aGVyZSBjYW4gYmUNCj4gPiBlbmNvZGluZw0KPiA+ID4gPiA+Pj4gdmFy aWF0aW9uIGJ5IHRyYW5zcG9ydHMgLiAgIEl0IFRoZXJlZm9yZSBpdCBzZWVtcyBiZXR0ZXIgdG8g bGV0IHRoZW0NCj4gPiA+ID4gPj4+IGJvdGggdmFyeSBpbmRlcGVuZGVudGx5Lg0KPiA+ID4gPiA+ Pg0KPiA+ID4gPiA+PiBOb3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbi4gIFRvIGJl IGNsZWFyLCBkbyB5b3UgdGhpbmsNCj4gPiA+ID4gPj4gdGhlICJlbmNvZGluZyIgbGVhZiBzaG91 bGQgc3RheSB3aGVyZSBpdCBpcywgb3IgYmUgbW92ZWQgZG93bg0KPiA+ID4gPiA+PiB0byB0aGUg cmVjZWl2ZXIsIGFzIGEgc2libGluZyB0byAicHJvdG9jb2wiPw0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4gRW5jb2RpbmcgbGVhZiBzaG91bGQgc3RheSB3aGVyZSBpdCBpcy4gIFlvdXIgcHJldmlvdXMg YXNrIHdhcyB0bw0KPiA+ID4gPiA+IHB1dCBlbmNvZGluZyBhbmQgdHJhbnNwb3J0IGFuZCB0aGUg c2FtZSBsZXZlbC4gVGhlcmUgaXMgYW4NCj4gPiA+ID4gPiBvcHRpb24gcHJvcG9zZWQgaW4gdGhl IHNsaWRlcyB3aGljaCBkb2VzIHRoYXQuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBFcmljDQo+ID4g PiA+ID4NCj4gPiA+ID4gPj4gL21hcnRpbg0KPiA+ID4gPiA+DQo+ID4gPiA+DQo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBOZXRjb25mIG1h aWxpbmcgbGlzdA0KPiA+IE5ldGNvbmZAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gTmV0Y29uZkBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYN Cg== From nobody Thu Dec 7 06:31: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 B2134128B37 for ; Thu, 7 Dec 2017 06:31:16 -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 bEAQ3nShMhAw for ; Thu, 7 Dec 2017 06:31:15 -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 666021286C7 for ; Thu, 7 Dec 2017 06:31:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=669; q=dns/txt; s=iport; t=1512657075; x=1513866675; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=DsbRB2lzVfHP+2bNqPo+JX/664cbWMkZRMlMYdG/3oE=; b=dah4KSQyPlcLuX/8fDKzJoBK1XZrDubfFNxOt4Mq8VKpF7PhTztmB960 kDGZvlxQrix7gyrlPblR1t8QnTHgUCmEL5rF8MiSDMsXfmI6ZlsCui24Z 2tVNW5AbYQ4Fdj3c1uArEtLgIVCZWHx5IM5O86az4AM5F9RQb3YZw6pK0 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAQBeUCla/4QNJK1dGwEBAQEDAQEBC?= =?us-ascii?q?QEBAYM+gVgujhuOfZkGghUKixs/GAEBAQEBAQEBAWsdC4VjPRQBLRFCJgEEG4o?= =?us-ascii?q?fqhGKVwEBCAEBAQEBI4NUggqBVoFpjkQFowEClRKCBpFfliwCERkBgToBHzmBT?= =?us-ascii?q?28VgmSEVIlogRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,373,1508803200"; d="scan'208";a="41690060" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Dec 2017 14:31:14 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vB7EVEKj007740 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 7 Dec 2017 14:31:14 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, 7 Dec 2017 09:31: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; Thu, 7 Dec 2017 09:31:13 -0500 From: "Eric Voit (evoit)" To: "netconf@ietf.org" Thread-Topic: Moving QoS elements from yang-push to subscribed-notifications? Thread-Index: AdNvZUr+t4/jeXXFTbyqfHNMrgk5Kw== Date: Thu, 7 Dec 2017 14:31:13 +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.86.245.143] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Netconf] Moving QoS elements from yang-push to 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, 07 Dec 2017 14:31:17 -0000 Several people have asked in reviews to move the QoS elements (dscp, weight= ing, dependency) from yang-push.yang to subscribed-notification.yang. Any = objections to making this an optional capability in subscribed-notification= s? =20 (Note 1: the reason these QoS elements were initially put into yang-push wa= s that there wasn't known demand for these QoS parameters for event streams= . Now that people have asserted there is need, we should move these elemen= ts.) =20 (Note 2: doing this now before releasing the NMDA subscription model varian= ts will be helpful as it will reduce future model changes and duplicative m= aintenance.) Eric From nobody Thu Dec 7 10:26:53 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 2B425127698; Thu, 7 Dec 2017 10:26:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151267120804.30741.7134181316786792466@ietfa.amsl.com> Date: Thu, 07 Dec 2017 10:26:48 -0800 Archived-At: Subject: [Netconf] Network Configuration (netconf) WG Virtual Meeting: 2017-12-13 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: Thu, 07 Dec 2017 18:26:48 -0000 The Network Configuration (netconf) Working Group will hold a virtual interim meeting on 2017-12-13 from 10:00 to 12:00 America/New_York. Agenda: The agenda for this meeting is as follows: 1) Review YANG Library proposals (Presenter: NMDA Authors) 2-3 proposals will be compared. An email with the proposals will be posted to the list prior to the meeting. This presentation will also go over topics raised during the IETF 100 meeting including: - licensing - line card insertion/deletion - semantic versioning 2) Discussion (Presenter: N/A) Goal is to select a proposal. Information about remote participation: https://ietf.webex.com/meet/netconf From nobody Thu Dec 7 11:58: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 5BAF71287A3 for ; Thu, 7 Dec 2017 11:58:02 -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 t9g6jJGGXMHb for ; Thu, 7 Dec 2017 11:58:00 -0800 (PST) Received: from mail-pg0-f42.google.com (mail-pg0-f42.google.com [74.125.83.42]) (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 BFD031242EA for ; Thu, 7 Dec 2017 11:58:00 -0800 (PST) Received: by mail-pg0-f42.google.com with SMTP id m25so5187839pgv.12 for ; Thu, 07 Dec 2017 11:58:00 -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=nbeYKOu/pVpY7oOzIIimam1sAk+H1zMqf3ZlyHwDqvc=; b=ExzKtG0uKy8O55F+WP26srzPzz6zMb845D9Ui4+GR3rJzcNWk7JuIxC99EYjWF85JX c5IJxPYJijiPZfY+QYhNHSReGx4hRE1S2WD35jM+WwwOkgFv3PSKQyfkk7q/bg7VqfeV 5RxMcEiq1K/BQItO/jeZ65z8iWVAj/GKiGu/UmN6VAT564JQoaS9Gg7Yea3R2z6EBQON pgLiIrYWj+Xt97KSxFiOKH/cP74ipROboVKOJmI1MI00/xM/JJmH2K7Bs5scNT8wEStj 5ACjzPW5uAcVj/CqZIOd2QJYF2a76M/H0sY+U0t/uBvprSUViuJi3Cx6Uck6zluCVLbZ dQfg== X-Gm-Message-State: AJaThX5sbe1Ct8hoEM9AApyP93UVcuGwagUKh/VsdQbBEV9Nwc83Ai/b 3Zv5v+8qG4BEVYX29MpsNi7iC2pZOXI= X-Google-Smtp-Source: AGs4zMYa4AXWsTgcroYPwbRT/ev6VdL+zU9qrPYMUFvjI9LPzbzmN9g6FeijJmZp2i94nKdqj2ldDw== X-Received: by 10.84.132.34 with SMTP id 31mr26672110ple.395.1512676679484; Thu, 07 Dec 2017 11:57:59 -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 m87sm11558510pfi.88.2017.12.07.11.57.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Dec 2017 11:57:58 -0800 (PST) To: netconf@ietf.org References: <16ea77c9d7944aeea09a0b1971ab02a0@XCH-RTP-013.cisco.com> <20171205.110255.1069937786544957099.mbj@tail-f.com> <422b669242674349975651d2ef7c436e@XCH-RTP-013.cisco.com> <20171206.094009.1934958524737452117.mbj@tail-f.com> From: Randy Presuhn Message-ID: <62535d34-a226-1fd9-9777-8f17873277d4@alumni.stanford.edu> Date: Thu, 7 Dec 2017 11:58:00 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171206.094009.1934958524737452117.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [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, 07 Dec 2017 19:58:02 -0000 Hi - Regarding the "not ... all" vs "not ... any" vs other alternatives, and given the emerging desire to provide at least at little support for systems allowing hot-insertion, etc., there seems to be some conflict between presumed use cases regarding what would be an "error." Rather than treating the "no objects (currently) selected" case as an error, perhaps one might consider providing an operation to query the number of items selected (at the time of the operation) by an "on change" subscription which have the instrumentation to support the generation of the notification. This would allow both use cases (nothing selected is ok because we know the information objects of interest will come into being later; vs. nothing selected is a problem because it means we're confused about the system's configuration). Randy From nobody Thu Dec 7 12:11: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 0150C1294E6 for ; Thu, 7 Dec 2017 12:11:14 -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 0jFBtEp0eJEX for ; Thu, 7 Dec 2017 12:11:11 -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 8B7F71293EE for ; Thu, 7 Dec 2017 12:11:11 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id j124so9546972lfg.2 for ; Thu, 07 Dec 2017 12:11:11 -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=Old0G8RKHHoxQeXI1Qlpv4DgJ1eLoyrOE5masJay/xw=; b=yDHqCIF+9djLOIGRulTPGdpqz4jxYgEfvuNuVvn5rTu7hkQ+w5+hFg8MmtLB1EqRBS wEOD9C6NU2WVJQwbJ/0iHCkD+eDeKiZqs9Odm1VW0KqDnl4HeKAxMB3/6gCecE4455gf 1KI/nWZEwia2Akbjjn9Z+0ecX+FPgUfNLgz5g1syG9zIij8pYT8uDJ6AtQFL/enW9mSj am0iqpbPxXgGEvd5tkbm1O7T4M/ZHdDNuDeP+OVlY+3ozNB8cZF0ZuCh+XqGGqf+mD2X S116DyWd6pkKiwpAeNjKViej52XQiHLUXVIOdXkqv1+v7ZO2jrFygZw9dhmc720bz6jZ BPnA== 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=Old0G8RKHHoxQeXI1Qlpv4DgJ1eLoyrOE5masJay/xw=; b=WeF7gAy/aRkqZxvXcoVqAUI5imKhzKid4TokITT2oK4ZBw5vRTOnA4SaXvaGSqsFLG CS1pHz6nVe4/8sQEbZbEp8QpP/rxEgl9HWZJREMCGKrciKfYNqS186KXcpz6bOESZOT7 f2rNg6a/RtHXaMNZJANBmvv3U56sgqXGddcdE4PKn4PXi23mjhwN1qDXd8o1zTFBScS6 nhWbZBr0+JO+hbSJzU9AB4IqGWABwFh5b7xje7gi/21Lr8/l9YUN+rJlLk8XoZTepJsL n1+AbKCQOQYaJpEe9NMiwOVn/2n45RhsT5vVfWe6T9TC/lMU7tIkyinNONJaCJwKx7R6 uqBg== X-Gm-Message-State: AJaThX4tM9tkk/f0iOeRI9vYPH1CtsTmb09EY3s+2gYD5akNSEPMcGK7 KzR/1iEoON0A/cs0Yo07hiARhLzkNwxelnhmyh9qQw== X-Google-Smtp-Source: AGs4zMY6D6hvdEdghLfRzBvhg0Dxk5hmlm/pMDQrBgB6c/J+cmq742e/xVv2/zlMAtIBSf2+qkhgvlvA5clLnxkw2Ns= X-Received: by 10.25.147.67 with SMTP id v64mr10552320lfd.99.1512677469590; Thu, 07 Dec 2017 12:11:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Thu, 7 Dec 2017 12:11:08 -0800 (PST) In-Reply-To: <62535d34-a226-1fd9-9777-8f17873277d4@alumni.stanford.edu> References: <16ea77c9d7944aeea09a0b1971ab02a0@XCH-RTP-013.cisco.com> <20171205.110255.1069937786544957099.mbj@tail-f.com> <422b669242674349975651d2ef7c436e@XCH-RTP-013.cisco.com> <20171206.094009.1934958524737452117.mbj@tail-f.com> <62535d34-a226-1fd9-9777-8f17873277d4@alumni.stanford.edu> From: Andy Bierman Date: Thu, 7 Dec 2017 12:11:08 -0800 Message-ID: To: Randy Presuhn Cc: Netconf Content-Type: multipart/alternative; boundary="f403045c31c23c2ffe055fc5ab5d" 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, 07 Dec 2017 20:11:14 -0000 --f403045c31c23c2ffe055fc5ab5d Content-Type: text/plain; charset="UTF-8" On Thu, Dec 7, 2017 at 11:58 AM, Randy Presuhn < randy_presuhn@alumni.stanford.edu> wrote: > Hi - > > Regarding the "not ... all" vs "not ... any" vs other alternatives, > and given the emerging desire to provide at least at little support > for systems allowing hot-insertion, etc., there seems to be some > conflict between presumed use cases regarding what would be an "error." > > Rather than treating the "no objects (currently) selected" case as > an error, perhaps one might consider providing an operation to query > the number of items selected (at the time of the operation) by an "on > change" subscription which have the instrumentation to support the > generation of the notification. > > This would allow both use cases (nothing selected is ok because > we know the information objects of interest will come into being later; > vs. nothing selected is a problem because it means we're confused > about the system's configuration). > > Agreed -- I am not up on this thread but it is never an error for subtree/XPath retrieval or NACM data rules if the resulting node-set is empty. If we had actually designed NETCONF correctly so an rpc-warning could be returned, this would be a good use-case for a server warning. (Maybe NETCONF 2.0). > Randy > > Andy > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --f403045c31c23c2ffe055fc5ab5d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Dec 7, 2017 at 11:58 AM, Randy Presuhn <randy_= presuhn@alumni.stanford.edu> wrote:
Hi -

Regarding the "not ... all" vs "not ... any" vs other a= lternatives,
and given the emerging desire to provide at least at little support
for systems allowing hot-insertion, etc., there seems to be some
conflict between presumed use cases regarding what would be an "error.= "

Rather than treating the "no objects (currently) selected" case a= s
an error, perhaps one might consider providing an operation to query
the number of items selected (at the time of the operation) by an "on<= br> change" subscription which have the instrumentation to support the
generation of the notification.

This would allow both use cases (nothing selected is ok because
we know the information objects of interest will come into being later;
vs. nothing selected is a problem because it means we're confused
about the system's configuration).


Agreed -- I am not up on this thread b= ut it is never an error for subtree/XPath
retrieval or NACM data = rules if the resulting node-set is empty.

If we ha= d actually designed NETCONF correctly so an rpc-warning could be
= returned, this would be a good use-case for a server warning. (Maybe NETCON= F 2.0).


=C2=A0
Randy



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

--f403045c31c23c2ffe055fc5ab5d-- From nobody Thu Dec 7 14:52: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 EF4D41294EC for ; Thu, 7 Dec 2017 14:52:17 -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 vHzuDk2vfB2q for ; Thu, 7 Dec 2017 14:52: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 1F42A126B72 for ; Thu, 7 Dec 2017 14:52:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11809; q=dns/txt; s=iport; t=1512687135; x=1513896735; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=si0bGBhKhNcz7hMs3onT2Li2aAFiJ+lEqg5y63GVIKo=; b=iJ/5OfAlRC5QbT6Brpy/By23+0TkN3OHnb3KEGbOTGiozzuRuIJgFpyU kDdlqeOElfIyzprubSzzUx97sO7vxMHi3RXoHUq0Bpk2/68IHZ+J+dAnv BkprK7Y58h4AfUQO1aC3PpFOoCck2D9ijHi82n4yjleXBUex1ILizmIML w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTAQBkxSla/5ldJa1SAQkZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgz5mcicHnRqBfX6WH4IBCiWFFgKFY0MUAQEBAQEBAQEBayi?= =?us-ascii?q?FIgEBAQECAScTPwULAgEIDgcDDAELBhAyJQIEDgMCCIoXCBCpbzqKYQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFg1mCCoFWgWmCdTaEdgESAmSFKgWSCZB4Aod2jRy?= =?us-ascii?q?CH5FGikCCRYknAhEZAYE6ATYigU9vFYJjgk2BBQGBAkUzh3iBDoEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,374,1508803200"; d="scan'208";a="111884025" 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; 07 Dec 2017 22:52:13 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vB7MqDKl017738 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Dec 2017 22:52:13 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; Thu, 7 Dec 2017 17:52: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, 7 Dec 2017 17:52:12 -0500 From: "Eric Voit (evoit)" To: Martin Bjorklund CC: "netconf@ietf.org" , "balazs.lengyel@ericsson.com" , "andy@yumaworks.com" , "alexander.clemm@huawei.com" Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11 Thread-Index: AQHTaCy/QRPr9GM9Jka7UxKyCaa4a6MpyuqggAmhy4D///elMIABf46AgAB7+cCAAP88gIAACbyAgAGC+YCAAFcy0A== Date: Thu, 7 Dec 2017 22:52:12 +0000 Message-ID: References: <422b669242674349975651d2ef7c436e@XCH-RTP-013.cisco.com> <20171206.094009.1934958524737452117.mbj@tail-f.com> <905820dba0e24c0ca3d1b15849cd4961@XCH-RTP-013.cisco.com> <20171207.092001.1087388873746464030.mbj@tail-f.com> In-Reply-To: <20171207.092001.1087388873746464030.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: Thu, 07 Dec 2017 22:52:18 -0000 Hi Martin, > From: Martin Bjorklund, December 7, 2017 3:20 AM >=20 > Hi, >=20 > "Eric Voit (evoit)" wrote: > > Hi Martin, > > > > > From: Martin Bjorklund, December 6, 2017 3:40 AM > > > > > > Hi, > > > > > > > > > > > > > > > o 3.9 > > > > > > A publisher could choose to allow a subscription to an empty > > > > > > location where there might plausibly be objects someday. > > > > > > (E.g., maybe where an interface might appear; even if there is > > > > > > no such interface currently > > > > > > existing.) > > > > > > > > > > I think the spec needs to be clear if servers are required to > > > > > allow filters to cover non-existing nodes or not (I think it shou= ld). > > > > > Hence, selecting a non-existing node should not be an error. > > > > > > > > Agree. The " Receiver Authorization" section now has a clarified > > > > sentence: > > > > " A publisher MAY allow subscriptions which select non-existent or > > > > access-protected data." > > > > > > So it seems you *didn't* agree with what I wrote :) > > > > > > With the selection filter algorithm you have chosen, I think the > > > server MUST allow subscriptions that select non-existing instances. > > > > MUST forces a subscription to be accepted (even with other issues). >=20 > Of course not. If there are other issues like out of resources or don't > support on-change or whatever the subscription must not be accepted. >=20 > > MAY gives the publisher the option of accepting a subscription > > (something it has the right to do with any subscription). >=20 > The point is that we need to specify what the expected behavior of a serv= er > is, so clients can code for that. There are two alternatives: >=20 > 1. this is a required feature that all servers must support >=20 > 2. this is an optional feature. >=20 > If 2, how will a client know if the server supports the feature or not? = Three > alternatives: >=20 > 2a. there's a YANG feature (or similar) that informs the client > about this behavior >=20 > 2b. the client doens't know and will have to guess >=20 > 2c. the server informs the client in a way out of scope of this > specification. >=20 >=20 > Personally, I prefer 1. My reading of the currect document is 2b. We really are not far apart. Here is my view... =20 It is mandatory that a publisher have the ability to handle selection filte= rs referencing non-existent datastore nodes. It is not mandatory that a p= ublisher MUST accept at least one instance of such a request. In fact I do= n't believe it is advantageous for us to define and expose such support as = a 'feature' as it would be very hard to provide a subscriber with definitiv= e guidance on where in various subtrees this might be attempted. =20 As an example, for which users should a publisher allow subscription to: (From RFC-7317) +--rw authentication ---> +--rw user* [name] +--rw name =20 +--rw password? =20 Per the draft for any unauthorized user, the proper response would be the e= rror identity "data-unavailable". However for a system administrator, it= might be ok to allow such a subscription. As a result of this, the text I propose is: "A publisher MUST allow for the possibility that a subscription's selection= filter references non-existent or access-protected data... A publisher M= AY choose not to allow a particular subscription which selects non-existent= or access-protected data." =20 The latest draft version has placed these as the lead sentences in two sequ= ential paragraphs. (See link to draft version below) > > A selection filter need not be designed to explicitly remove nodes > > which are not-notifiable-on-change. These are automatically removed > > without any knowledge of the filter, and need not be considered by the > > designer of the filter. (I.e., you can on-change subscribe to > > interfaces, and will never see any counters.) >=20 > This behavior is not specified anywhere! This must be explained. New wording has been added to the bottom of the "Datastore Selection" secti= on: "When the set of selection filtering criteria is applied for periodic subsc= ription, all selected datastore nodes for which a receiver has access are p= rovided to a receiver. If the same filtering criteria is applied to an on-c= hange subscription, only the subset of those datastore nodes supporting on-= change are provided. A datastore node which doesn't support on-change is n= ever sent as part of an on-change subscription's "push-update" or "push-cha= nge-update"." > Ok, so with this behavior I agree "any" is correct. I suggest: >=20 > "This value means that on change is not supported for any node that > may be selected by the given filter." Made it: "On-change is not supported for any objects which are selectable by this fi= lter." > > An on-change subscription should not be allow if it is unlikely there > > will be any on-change nodes ever within its domain of selection. > > > > > > Tweaked the definition to: > > > > "On-change is not supported for any objects which are likely to be > > > > provided through the selection filter." > > > > > > "likely to be provided" is a bit confusing. > > > > "Likely to be provided" covers the case of nodes which don't exist as > > the time of subscription, yet appear later. The "Likely to" is better > > than "Never will" since it is theoretically possible for a system to > > add a lightly protected node deep in a tree. >=20 > But in that case it probably should not return this error. My text was allowing for the possible but unlikely. I am fine with removin= g this ambiguity via the text proposal below: > What does "provided through a filter" mean? I think "selected by a filte= r" is > easier to understand. Changed to: "On-change is not supported for any objects which are selectable by this fi= lter." > > > > > > > > > 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 th= at sync > > > > > > > > > on > > > > > > > > > start is the default. So when will this identity be us= ed? > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > But in this case the error will be "on-change-unsupported", > right? > > > > > > > > > > > > I mean to say "except for" rather that e.g. My bad. > > > > > > > > > > > > > > ). Will enhance the > > > > > > > > definition. > > > > > > > > > > > > Current text is now: > > > > > > "Neither synch on start nor resynchonization are supported for > > > > > > this subscription. This error will be used for two reasons. > > > > > > First if an 'establish-subscription' RPC doesn't include > > > > > > 'no-synch-on-start', yet the publisher can't support sending a > > > > > > 'push update' for this subscription for reasons other that > > > > > > 'on-change-unsupported' or 'result-too-big'. > > > > > > > > > > What would that reason be? > > > > > > > > One example might be the CPU capacity is prohibitively low at that > > > > immediate time. Or there are too many subscriptions pulling > > > > counters or routing tables or MAC addresses from a specific line > > > > card. Or other platform wide issues which shouldn't fall under 're= sult- > too-big' > > > > because making the result smaller still won't result in the > > > > subscription being allowed to push the state of current nodes. > > > > > > > > > I think that if the idea is that a server may or may not support > > > > > sync on start, you should make a feature for it and call the > > > > > leaf "sync-on-start" instead. And OTOH, if the default is sync > > > > > on start (as it is now), it should be required to support it. > > > > > > You didn't reply to this comment. > > > > Synch-on-start should be the default, and should be required for a > > platform to implement. >=20 > At this point, I think I have to see the new draft to be able to comment > further. I am a bit lost wrt what is required and what is optional and h= ow > that is communicated to the client. https://github.com/netconf-wg/yang-push/blob/master/draft-ietf-netconf-yang= -push-12.txt I believe this version contains the results of the dialogs from this thread= . But not including the scrub of examples, the error discussion which just= resolved, and the items which will become numbered issues. Eric =20 > > > > > > However a patch must be able to do more than just describe the > > > > > > delta from the previous state to the current state. As per > > > > > > , it must also be able to identify > > > > > > if transient changes have occurred on an object during a > > > > > > dampening period. To support this, it is valid to encode a > > > > > > YANG patch operation so that its application would result in a > > > > > > no change between the previous and current state. This > > > > > > indicates that some churn has occurred on the object. An > > > > > > example of this would be a > > > patch that does a "create" > > > > > > operation for a datastore node where the receiver believes one > > > > > > already exists, or a "merge" operation which replaces a > > > > > > previous value with the same value. > > > > > > > > > > Hmm, I think that this is a very strange way to indicate > > > > > "churn", it is very implicit. Is it really necessary to be able > > > > > to indicate this "churn"? > > > > > It seems > > > > > quite complex on both the server and client side. > > > > > If a client needs to know this information, it can just not > > > > > specify a dampening period. > > > > > > > > Churn indication is an absolute *must* for security applications. > > > > Both the SACM and I2NSF WGs have indicated need. It is also > > > > highly useful for Network Management applications which simply > > > > cannot get a continuous stream of interface flaps. This is a > > > > highly advantageous capability and I have quite a few customer > requests for this. > > > > > > Ok. (so what do you do if you know that churn has happend, but you > > > have no idea what the churn was?) > > > > You will know the node has churned. You will know the latest change. > > If you need to find out more, about the current datastore you can do a > > get. If you need to know more about each change, you could check the > > log. Applications never could get this type of information > > efficiently before. > > > > > Depending on the outcome of the filter issue (full XPath/subtree > > > filter vs. > > > node-instance-identifier (BTW, will you crete a separate thread for > > > that discussion?)), > > > > If you means Balazs discussion, then yes. >=20 > On Tue, 5 Dec 2017 03:02:33 +0000, you wrote: >=20 > I want to generalize this "only-keys?" issue for the full WG. It is > too important to handle this deep in the thread. Look for me to > open an issue shortly. >=20 > That's the issue I was referring to. Yes, this is soon to be a numbered issue. Eric >=20 > /martin From nobody Thu Dec 7 16:03: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 9E4AC128768 for ; Thu, 7 Dec 2017 16:03:07 -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 JJGtkls4jaFH for ; Thu, 7 Dec 2017 16:03:05 -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 6C566127B73 for ; Thu, 7 Dec 2017 16:03:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14992; q=dns/txt; s=iport; t=1512691385; x=1513900985; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Rn4v57wlE5GN86F+CAfiwS2B9vGPphK9rl2wes0eEyQ=; b=KDnQm4WdHai3Tzhtoij4JIukXZDX4pRFtwQikUeejZ4MssOFDdxaYh5u pe4qKRdZF5PKidf7YkI4gFN8DHbA3Gyf8Hd1QYk9UR9x/LmATkboXHlgW 6AHAotTj2OvF6HWOi9SS3p5jjJ6Kk75IwjV0CtGc+jmSLEl/MPveP1qLK c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C7AgDE1Sla/49dJa1cDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCSnRmcicHg3uZH4F9kT6FS4IVChgBCoRJTwIahUlBFgEBAQE?= =?us-ascii?q?BAQEBAWsohSIBAQEBAwEBIQpBCxACAQgVEBoDAgICJQsUEQIEAQ0FCIk7ZBCoB?= =?us-ascii?q?IInimMBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYNZggqBVoFpgyuFCyQoAoJdgmM?= =?us-ascii?q?Fil2JHo8GApUSk2WWLAIRGQGBOgEmAjCBT28VOoIphBY/eIkGgRUBAQE?= X-IronPort-AV: E=Sophos;i="5.45,375,1508803200"; d="scan'208,217";a="327986628" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Dec 2017 00:03:04 +0000 Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vB8034pu007037 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Dec 2017 00:03:04 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, 7 Dec 2017 19:03:03 -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, 7 Dec 2017 19:03:03 -0500 From: "Eric Voit (evoit)" To: Andy Bierman , Randy Presuhn CC: Netconf Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11 Thread-Index: AQHTaCy/QRPr9GM9Jka7UxKyCaa4a6MpyuqggAmhy4D///elMIABf46AgAB7+cCAAP88gIAB/7Q6gAA9nlA= Date: Fri, 8 Dec 2017 00:03:03 +0000 Message-ID: <80721fc9b4d64a2e83d0d10bc790f8ce@XCH-RTP-013.cisco.com> References: <16ea77c9d7944aeea09a0b1971ab02a0@XCH-RTP-013.cisco.com> <20171205.110255.1069937786544957099.mbj@tail-f.com> <422b669242674349975651d2ef7c436e@XCH-RTP-013.cisco.com> <20171206.094009.1934958524737452117.mbj@tail-f.com> <62535d34-a226-1fd9-9777-8f17873277d4@alumni.stanford.edu> 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.118.56.228] Content-Type: multipart/alternative; boundary="_000_80721fc9b4d64a2e83d0d10bc790f8ceXCHRTP013ciscocom_" 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: Fri, 08 Dec 2017 00:03:08 -0000 --_000_80721fc9b4d64a2e83d0d10bc790f8ceXCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCkhpIFJhbmR5LA0KDQpGcm9tOiBBbmR5IEJpZXJtYW4sIERlY2VtYmVyIDcsIDIw MTcgMzoxMSBQTQ0KDQpPbiBUaHUsIERlYyA3LCAyMDE3IGF0IDExOjU4IEFNLCBSYW5keSBQcmVz dWhuIDxyYW5keV9wcmVzdWhuQGFsdW1uaS5zdGFuZm9yZC5lZHU8bWFpbHRvOnJhbmR5X3ByZXN1 aG5AYWx1bW5pLnN0YW5mb3JkLmVkdT4+IHdyb3RlOg0KSGkgLQ0KDQpSZWdhcmRpbmcgdGhlICJu b3QgLi4uIGFsbCIgdnMgIm5vdCAuLi4gYW55IiB2cyBvdGhlciBhbHRlcm5hdGl2ZXMsDQoNCjxF cmljPiAgSSBhbSBob3BpbmcgdGhhdCB0aGUgYWxsL2FueSAmIG11c3QvbWF5IGRpc2N1c3Npb25z IGlzIHJlc29sdmVkIHdpdGggdGhlIGxhdGVzdCB3b3JkaW5nIHR3ZWFrcy4gICBXZSB3aWxsIHNl ZS4uLg0KDQphbmQgZ2l2ZW4gdGhlIGVtZXJnaW5nIGRlc2lyZSB0byBwcm92aWRlIGF0IGxlYXN0 IGF0IGxpdHRsZSBzdXBwb3J0DQpmb3Igc3lzdGVtcyBhbGxvd2luZyBob3QtaW5zZXJ0aW9uLCBl dGMuLCB0aGVyZSBzZWVtcyB0byBiZSBzb21lDQpjb25mbGljdCBiZXR3ZWVuIHByZXN1bWVkIHVz ZSBjYXNlcyByZWdhcmRpbmcgd2hhdCB3b3VsZCBiZSBhbiAiZXJyb3IuIg0KDQpSYXRoZXIgdGhh biB0cmVhdGluZyB0aGUgIm5vIG9iamVjdHMgKGN1cnJlbnRseSkgc2VsZWN0ZWQiIGNhc2UgYXMN CmFuIGVycm9yLA0KPEVyaWM+IFRoaXMgaXMgbm90IChuZWNlc3NhcmlseSkgYW4gZXJyb3IuICBU aGUgc3Vic2NyaXB0aW9uIGlzIG9ubHkgcmVqZWN0ZWQgd2l0aCBhbiBlcnJvciBpZiB0aGUgcHVi bGlzaGVyIGRldGVybWluZXMgdGhhdCB0aGVyZSB3aWxsIG5ldmVyIGJlIGEgY29uY2VpdmFibGUg Y2FzZSB3aGVyZSB0aGUgZmlsdGVyIHdpbGwgcmV0dXJuIG9iamVjdHMuICAgVGhpcyBpcyBhIHZh bGlkIHJlc3BvbnNlLCBiZWNhdXNlIGl0IGFsbG93cyBzdWJzY3JpcHRpb24gdG8gbm9uLWV4aXN0 ZW50IG9iamVjdHMsIGFuZCBhbHNvIGFsbG93cyB0aGUgcHVibGlzaGVyIHRvIHJlamVjdCBhIHN1 YnNjcmlwdGlvbiB3aGVuIHRoZXJlIHdpbGwgbmV2ZXIgYmUgYW55dGhpbmcgc2VsZWN0ZWQuDQpw ZXJoYXBzIG9uZSBtaWdodCBjb25zaWRlciBwcm92aWRpbmcgYW4gb3BlcmF0aW9uIHRvIHF1ZXJ5 DQp0aGUgbnVtYmVyIG9mIGl0ZW1zIHNlbGVjdGVkIChhdCB0aGUgdGltZSBvZiB0aGUgb3BlcmF0 aW9uKSBieSBhbiAib24NCmNoYW5nZSIgc3Vic2NyaXB0aW9uIHdoaWNoIGhhdmUgdGhlIGluc3Ry dW1lbnRhdGlvbiB0byBzdXBwb3J0IHRoZQ0KZ2VuZXJhdGlvbiBvZiB0aGUgbm90aWZpY2F0aW9u Lg0KPEVyaWM+IElmIHlvdSBjYW4gZG8gYSBHRVQgb3BlcmF0aW9uIHdoaWNoIGlzIGFibGUgdG8g YWxzbyBhYmxlIHRvIHJldHJpZXZlIGp1c3QgdGhlIG9uLWNoYW5nZSBub3RpZmlhYmxlIG9iamVj dHMsIHRoaXMgc2hvdWxkIGFsc28gYWNjb21wbGlzaCBzb21ldGhpbmcgdXNlZnVsIHByZS1zdWJz Y3JpcHRpb24uDQoNClRoaXMgd291bGQgYWxsb3cgYm90aCB1c2UgY2FzZXMgKG5vdGhpbmcgc2Vs ZWN0ZWQgaXMgb2sgYmVjYXVzZQ0Kd2Uga25vdyB0aGUgaW5mb3JtYXRpb24gb2JqZWN0cyBvZiBp bnRlcmVzdCB3aWxsIGNvbWUgaW50byBiZWluZyBsYXRlcjsNCnZzLiBub3RoaW5nIHNlbGVjdGVk IGlzIGEgcHJvYmxlbSBiZWNhdXNlIGl0IG1lYW5zIHdlJ3JlIGNvbmZ1c2VkDQphYm91dCB0aGUg c3lzdGVtJ3MgY29uZmlndXJhdGlvbikuDQoNCkFncmVlZCAtLSBJIGFtIG5vdCB1cCBvbiB0aGlz IHRocmVhZCBidXQgaXQgaXMgbmV2ZXIgYW4gZXJyb3IgZm9yIHN1YnRyZWUvWFBhdGgNCnJldHJp ZXZhbCBvciBOQUNNIGRhdGEgcnVsZXMgaWYgdGhlIHJlc3VsdGluZyBub2RlLXNldCBpcyBlbXB0 eS4NCg0KPEVyaWM+IEFncmVlDQoNCklmIHdlIGhhZCBhY3R1YWxseSBkZXNpZ25lZCBORVRDT05G IGNvcnJlY3RseSBzbyBhbiBycGMtd2FybmluZyBjb3VsZCBiZQ0KcmV0dXJuZWQsIHRoaXMgd291 bGQgYmUgYSBnb29kIHVzZS1jYXNlIGZvciBhIHNlcnZlciB3YXJuaW5nLiAoTWF5YmUgTkVUQ09O RiAyLjApLg0KDQo8RXJpYz4gVGhhdCB3b3VsZCBoYXZlIGhlbHBlZCBoZXJlIGZvciBzdXJlLg0K DQpFcmljDQoNCg0KDQpSYW5keQ0KDQoNCkFuZHkNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGll dGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg== --_000_80721fc9b4d64a2e83d0d10bc790f8ceXCHRTP013ciscocom_ 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 c3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEFuZHksPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkhpIFJhbmR5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBBbmR5IEJpZXJtYW4sIERlY2VtYmVyIDcsIDIwMTcgMzoxMSBQTTxicj4NCjxicj4NCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUs IERlYyA3LCAyMDE3IGF0IDExOjU4IEFNLCBSYW5keSBQcmVzdWhuICZsdDs8YSBocmVmPSJtYWls dG86cmFuZHlfcHJlc3VobkBhbHVtbmkuc3RhbmZvcmQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+cmFu ZHlfcHJlc3VobkBhbHVtbmkuc3RhbmZvcmQuZWR1PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5IaSAtPGJyPg0KPGJyPg0KUmVnYXJkaW5nIHRoZSAmcXVvdDtub3QgLi4uIGFs bCZxdW90OyB2cyAmcXVvdDtub3QgLi4uIGFueSZxdW90OyB2cyBvdGhlciBhbHRlcm5hdGl2ZXMs PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6IzAwNzBDMCI+Jmx0O0VyaWMmZ3Q7Jm5ic3A7IDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 IzAwNzBDMCI+SSBhbSBob3BpbmcgdGhhdCB0aGUgYWxsL2FueSAmYW1wOyBtdXN0L21heSBkaXNj dXNzaW9ucyBpcyByZXNvbHZlZCB3aXRoIHRoZSBsYXRlc3Qgd29yZGluZyB0d2Vha3MuJm5ic3A7 Jm5ic3A7IFdlIHdpbGwgc2VlLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQphbmQgZ2l2ZW4gdGhl IGVtZXJnaW5nIGRlc2lyZSB0byBwcm92aWRlIGF0IGxlYXN0IGF0IGxpdHRsZSBzdXBwb3J0PGJy Pg0KZm9yIHN5c3RlbXMgYWxsb3dpbmcgaG90LWluc2VydGlvbiwgZXRjLiwgdGhlcmUgc2VlbXMg dG8gYmUgc29tZTxicj4NCmNvbmZsaWN0IGJldHdlZW4gcHJlc3VtZWQgdXNlIGNhc2VzIHJlZ2Fy ZGluZyB3aGF0IHdvdWxkIGJlIGFuICZxdW90O2Vycm9yLiZxdW90Ozxicj4NCjxicj4NClJhdGhl ciB0aGFuIHRyZWF0aW5nIHRoZSAmcXVvdDtubyBvYmplY3RzIChjdXJyZW50bHkpIHNlbGVjdGVk JnF1b3Q7IGNhc2UgYXM8YnI+DQphbiBlcnJvciwgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDA3MEMwIj4mbHQ7RXJpYyZndDsgVGhpcyBpcyBub3QgKG5lY2Vzc2FyaWx5KSBhbiBl cnJvci4mbmJzcDsgVGhlIHN1YnNjcmlwdGlvbiBpcyBvbmx5IHJlamVjdGVkIHdpdGggYW4gZXJy b3IgaWYgdGhlIHB1Ymxpc2hlciBkZXRlcm1pbmVzIHRoYXQgdGhlcmUNCiB3aWxsIG5ldmVyIGJl IGEgY29uY2VpdmFibGUgY2FzZSB3aGVyZSB0aGUgZmlsdGVyIHdpbGwgcmV0dXJuIG9iamVjdHMu Jm5ic3A7Jm5ic3A7IFRoaXMgaXMgYSB2YWxpZCByZXNwb25zZSwgYmVjYXVzZSBpdCBhbGxvd3Mg c3Vic2NyaXB0aW9uIHRvIG5vbi1leGlzdGVudCBvYmplY3RzLCBhbmQgYWxzbyBhbGxvd3MgdGhl IHB1Ymxpc2hlciB0byByZWplY3QgYSBzdWJzY3JpcHRpb24gd2hlbiB0aGVyZSB3aWxsIG5ldmVy IGJlIGFueXRoaW5nIHNlbGVjdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+cGVyaGFwcyBvbmUgbWlnaHQg Y29uc2lkZXIgcHJvdmlkaW5nIGFuIG9wZXJhdGlvbiB0byBxdWVyeTxicj4NCnRoZSBudW1iZXIg b2YgaXRlbXMgc2VsZWN0ZWQgKGF0IHRoZSB0aW1lIG9mIHRoZSBvcGVyYXRpb24pIGJ5IGFuICZx dW90O29uPGJyPg0KY2hhbmdlJnF1b3Q7IHN1YnNjcmlwdGlvbiB3aGljaCBoYXZlIHRoZSBpbnN0 cnVtZW50YXRpb24gdG8gc3VwcG9ydCB0aGU8YnI+DQpnZW5lcmF0aW9uIG9mIHRoZSBub3RpZmlj YXRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj4mbHQ7RXJpYyZn dDsgSWYgeW91IGNhbiBkbyBhIEdFVCBvcGVyYXRpb24gd2hpY2ggaXMgYWJsZSB0byBhbHNvIGFi bGUgdG8gcmV0cmlldmUganVzdCB0aGUgb24tY2hhbmdlIG5vdGlmaWFibGUgb2JqZWN0cywgdGhp cyBzaG91bGQgYWxzbw0KIGFjY29tcGxpc2ggc29tZXRoaW5nIHVzZWZ1bCBwcmUtc3Vic2NyaXB0 aW9uLjwvc3Bhbj48YnI+DQo8YnI+DQpUaGlzIHdvdWxkIGFsbG93IGJvdGggdXNlIGNhc2VzIChu b3RoaW5nIHNlbGVjdGVkIGlzIG9rIGJlY2F1c2U8YnI+DQp3ZSBrbm93IHRoZSBpbmZvcm1hdGlv biBvYmplY3RzIG9mIGludGVyZXN0IHdpbGwgY29tZSBpbnRvIGJlaW5nIGxhdGVyOzxicj4NCnZz LiBub3RoaW5nIHNlbGVjdGVkIGlzIGEgcHJvYmxlbSBiZWNhdXNlIGl0IG1lYW5zIHdlJ3JlIGNv bmZ1c2VkPGJyPg0KYWJvdXQgdGhlIHN5c3RlbSdzIGNvbmZpZ3VyYXRpb24pLjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVkIC0tIEkgYW0gbm90IHVwIG9uIHRoaXMgdGhyZWFkIGJ1 dCBpdCBpcyBuZXZlciBhbiBlcnJvciBmb3Igc3VidHJlZS9YUGF0aDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmV0cmlldmFsIG9yIE5BQ00gZGF0 YSBydWxlcyBpZiB0aGUgcmVzdWx0aW5nIG5vZGUtc2V0IGlzIGVtcHR5LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwNzBDMCI+Jmx0O0VyaWMmZ3Q7IEFncmVlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3ZSBoYWQgYWN0dWFsbHkgZGVzaWdu ZWQgTkVUQ09ORiBjb3JyZWN0bHkgc28gYW4gcnBjLXdhcm5pbmcgY291bGQgYmU8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnJldHVybmVkLCB0aGlz IHdvdWxkIGJlIGEgZ29vZCB1c2UtY2FzZSBmb3IgYSBzZXJ2ZXIgd2FybmluZy4gKE1heWJlIE5F VENPTkYgMi4wKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPiZsdDtFcmljJmd0OyBUaGF0IHdvdWxk IGhhdmUgaGVscGVkIGhlcmUgZm9yIHN1cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPjxicj4NCkVyaWM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlJhbmR5PG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFu ZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpOZXRjb25mIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+TmV0Y29uZkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_80721fc9b4d64a2e83d0d10bc790f8ceXCHRTP013ciscocom_-- From nobody Thu Dec 7 21:30: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 7B43F127517 for ; Thu, 7 Dec 2017 21:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.18 X-Spam-Level: X-Spam-Status: No, score=-3.18 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFeD2CMQu4N4 for ; Thu, 7 Dec 2017 21:30:30 -0800 (PST) Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com [209.85.192.175]) (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 2A595128D64 for ; Thu, 7 Dec 2017 21:30:21 -0800 (PST) Received: by mail-pf0-f175.google.com with SMTP id a90so6496839pfk.1 for ; Thu, 07 Dec 2017 21:30:21 -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:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Hwzgtr7zY7u8GxTddGTSr2tKObcs3bhY/3Vcuu1Zs6g=; b=jLwt6gkZTUqnmcckBbmVfU4TaA6VKfyskK0Ps8xkmMMEYcAsiXTolmTTxZyHrIAOKA 09RMvan0zFDTIlMa4onANwRI++Jp/Fy6b/IBMazOwc1emXcJHIqIfySZ71XeArbs4b6j F3sLD8vpCnxYGxeLRNQWCWRquITo4bj3qPEJelNVLMkjtbWs159lGVPodQtLLViOGje4 3YnzKye0vvZNDJxi9EHLA8TPWNx47CQsKq5kssAohpaRjW1xo3DUj26uV6WbQTp0tL1a L0e2krHRc374z09IBE4/Ijd1N1leZzN7YeCnCBkTOSaFHWFBUotGPW9gOm2OJ7hYelfV /sCQ== X-Gm-Message-State: AJaThX5eA3OtFGXDrXpu7AO2y5xip9hGW3AU3ivPF0ibDoYWXBvqHukZ /sIG5gAkN8RNjn8yLXTd3dg9/UcAWOM= X-Google-Smtp-Source: AGs4zMY8uXmBA9MY2cRYGHK+d1XD/L+p+D16gM8fr+wPvJSwVdbZN0EWJz5Z1G0xHLOLD6MybjyWwA== X-Received: by 10.99.127.88 with SMTP id p24mr27960419pgn.98.1512711020418; Thu, 07 Dec 2017 21:30:20 -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 b184sm9687277pga.90.2017.12.07.21.30.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Dec 2017 21:30:19 -0800 (PST) Cc: Netconf References: <16ea77c9d7944aeea09a0b1971ab02a0@XCH-RTP-013.cisco.com> <20171205.110255.1069937786544957099.mbj@tail-f.com> <422b669242674349975651d2ef7c436e@XCH-RTP-013.cisco.com> <20171206.094009.1934958524737452117.mbj@tail-f.com> <62535d34-a226-1fd9-9777-8f17873277d4@alumni.stanford.edu> <80721fc9b4d64a2e83d0d10bc790f8ce@XCH-RTP-013.cisco.com> From: Randy Presuhn Message-ID: <6ccfcd45-14b0-f42c-ffb8-f5d6b0033d89@alumni.stanford.edu> Date: Thu, 7 Dec 2017 21:30:20 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <80721fc9b4d64a2e83d0d10bc790f8ce@XCH-RTP-013.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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, 08 Dec 2017 05:30:31 -0000 Hi - On 12/7/2017 4:03 PM, Eric Voit (evoit) wrote: ... > Rather than treating the "no objects (currently) selected" case as > an error, > > This is not (necessarily) an error.  The subscription is only > rejected with an error if the publisher determines that there will > never be a conceivable case where the filter will return objects. In my experience developers are really bad at putting together logic which can accurately make a determination of "will never be a conceivable case". This is particularly true of systems which permit software upgrades/installations without requiring a reboot, and of systems permitting hot insertion of (upgraded) line cards. The "inconceivable" happens with about every third software update. :-) > This is a valid response, because it allows subscription to > non-existent objects, and also allows the publisher to reject a > subscription when there will never be anything selected. An accurate determination of "never" can be a dicey proposition. Randy From nobody Thu Dec 7 23: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 77A0D126C19 for ; Thu, 7 Dec 2017 23:47: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, 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 U-LbWpr9x0bL for ; Thu, 7 Dec 2017 23:47:29 -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 5430812421A for ; Thu, 7 Dec 2017 23:47:29 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 1B67C6AC; Fri, 8 Dec 2017 08:47:28 +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 PUr4Mgkqfuhd; Fri, 8 Dec 2017 08:47: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; Fri, 8 Dec 2017 08:47:28 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 077CC2012C; Fri, 8 Dec 2017 08:47:28 +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 fAN9S1w3WSlA; Fri, 8 Dec 2017 08:47:27 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 576EE20129; Fri, 8 Dec 2017 08:47:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B14CB4190293; Fri, 8 Dec 2017 08:45:56 +0100 (CET) Date: Fri, 8 Dec 2017 08:45:56 +0100 From: Juergen Schoenwaelder To: "Eric Voit (evoit)" Cc: Martin Bjorklund , "netconf@ietf.org" Message-ID: <20171208074556.uegeprzakbk3sxhr@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Eric Voit (evoit)" , Martin Bjorklund , "netconf@ietf.org" References: <422b669242674349975651d2ef7c436e@XCH-RTP-013.cisco.com> <20171206.094009.1934958524737452117.mbj@tail-f.com> <905820dba0e24c0ca3d1b15849cd4961@XCH-RTP-013.cisco.com> <20171207.092001.1087388873746464030.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170714 (1.8.3) 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, 08 Dec 2017 07:47:31 -0000 On Thu, Dec 07, 2017 at 10:52:12PM +0000, Eric Voit (evoit) wrote: > As an example, for which users should a publisher allow subscription to: > (From RFC-7317) > +--rw authentication > ---> +--rw user* [name] > +--rw name > +--rw password? > > Per the draft for any unauthorized user, the proper response would be the error identity "data-unavailable". However for a system administrator, it might be ok to allow such a subscription. What exactly is 'authorized user' here? I would expect that access to data is controlled by NACM. A subscription to 'user' may be valid for everybody (who is allowed to create a subscription) but access to 'user' data may be prohibited by NACM, i.e., the subscription never returns data for some clients. Note that NACM rules can change independently of the subscription (hence it is difficult to reject a subscription on the ground there is _currently_ no access to data under 'user'). In draft-ietf-netconf-yang-push-11.txt I read: A publisher MAY alternatively choose not to allow subscriptions which select non-existent or access-protected data. Such a capability enables the publisher to avoid having to perform filtering of authorized content on each update. Then there is text following I do not know how to read: [...] Relevant scenarios here include: o the rejecting of a subscription request to access-protected objects, o the suspension of a subscription where new access-controlled objects are selected mid-subscription for which the receiver does not have the necessary authorization, or o the authorization privileges of a receiver change over the course of the subscription. What is this telling me? What do these 'relevant scenarios mean'? I think we need to settle on clear definition of behaviour instead of having descriptions of scenarios that someone needs to map to behaviour of objects. I also find the following text unclear. And this strikes me as odd: If read access into previously accessible nodes has been lost due to a receiver permissions change, this SHOULD be reported as node 'delete' operations for on-change subscriptions. Are you telling a subscriber that data was deleted while in fact only access to it has been restricted? I think there is a huge difference between these. Then later I read this: 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. Why is there not a single behaviour? Frankly, a spec that says an implementation MAY to A but it also MAY do not A is not really helpful. How do I know whether an implementation does A or not A? ("MAY allow subscriptions which select non-existent or access-protected data" and "MAY alternatively choose not to allow subscriptions which select non-existent or access-protected data"). I think the document should converge to a single set of rules that give us interoperability and the text touching on authorization needs to be streamlined and consistent throughout the document(s). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Dec 8 06:44: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 356D4126C25 for ; Fri, 8 Dec 2017 06:44:25 -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 qk494Fn4xjkp for ; Fri, 8 Dec 2017 06:44:23 -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 542841243FE for ; Fri, 8 Dec 2017 06:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2814; q=dns/txt; s=iport; t=1512744263; x=1513953863; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MJeV4Lt+m7U+ewyJIDALgvwq352fpwCV3hzKnprlUL8=; b=CER+C5ZfacWrzfDdmag0qIe9ehLb57mr9gqeIey7cG63xJmlD6tYkHzE sbpNCzubE1NMtfXULCcqrJZ5U93fQfymoFOyKx9Zt4xFuLfFqAGUpSLrt dv5rV+dSjBAfswOhfKfBE4yqPi6bOPQyXB7KQwDZ2T0jOslUZyr8fY2SK k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAQACpCpa/5BdJa1cDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDPmZ0JweDe5khgX2ZIQoYC4FegmtPAhqFOEMUAQEBAQEBAQE?= =?us-ascii?q?BayiFIgEBAQECAQEBIRE6CwULAgEIFQMCAgkdAgICJQsVEAIEDgUIEooGCBCnf?= =?us-ascii?q?YInimQBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPgkyCC4FWhRSFEiQjgluCYwW?= =?us-ascii?q?KXYkgjwsClRWCH5FLikCLbwIRGQGBOgE2IoFPbxU6gimEFj94h3CBMYEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,377,1508803200"; d="scan'208";a="333067933" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Dec 2017 14:41:25 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id vB8EfOGS025691 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Dec 2017 14:41:25 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, 8 Dec 2017 09:41: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; Fri, 8 Dec 2017 09:41:24 -0500 From: "Eric Voit (evoit)" To: Randy Presuhn CC: Netconf Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11 Thread-Index: AQHTaCy/QRPr9GM9Jka7UxKyCaa4a6MpyuqggAmhy4D///elMIABf46AgAB7+cCAAP88gIAB/7Q6gAA9nlCAALJPAIAANryg Date: Fri, 8 Dec 2017 14:41:24 +0000 Message-ID: <810d00e6b78642d89ab67e56d71330d2@XCH-RTP-013.cisco.com> References: <16ea77c9d7944aeea09a0b1971ab02a0@XCH-RTP-013.cisco.com> <20171205.110255.1069937786544957099.mbj@tail-f.com> <422b669242674349975651d2ef7c436e@XCH-RTP-013.cisco.com> <20171206.094009.1934958524737452117.mbj@tail-f.com> <62535d34-a226-1fd9-9777-8f17873277d4@alumni.stanford.edu> <80721fc9b4d64a2e83d0d10bc790f8ce@XCH-RTP-013.cisco.com> <6ccfcd45-14b0-f42c-ffb8-f5d6b0033d89@alumni.stanford.edu> In-Reply-To: <6ccfcd45-14b0-f42c-ffb8-f5d6b0033d89@alumni.stanford.edu> 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: Fri, 08 Dec 2017 14:44:25 -0000 SGkgUmFuZHksDQoNCj4gRnJvbTogUmFuZHkgUHJlc3VobiwgRGVjZW1iZXIgOCwgMjAxNyAxMjoz MCBBTQ0KPiANCj4gSGkgLQ0KPiANCj4gT24gMTIvNy8yMDE3IDQ6MDMgUE0sIEVyaWMgVm9pdCAo ZXZvaXQpIHdyb3RlOg0KPiAuLi4NCj4gPiAgICAgUmF0aGVyIHRoYW4gdHJlYXRpbmcgdGhlICJu byBvYmplY3RzIChjdXJyZW50bHkpIHNlbGVjdGVkIiBjYXNlIGFzDQo+ID4gICAgIGFuIGVycm9y LA0KPiA+DQo+ID4gICAgIDxFcmljPiBUaGlzIGlzIG5vdCAobmVjZXNzYXJpbHkpIGFuIGVycm9y LsKgIFRoZSBzdWJzY3JpcHRpb24gaXMgb25seQ0KPiA+ICAgICByZWplY3RlZCB3aXRoIGFuIGVy cm9yIGlmIHRoZSBwdWJsaXNoZXIgZGV0ZXJtaW5lcyB0aGF0IHRoZXJlIHdpbGwNCj4gPiAgICAg bmV2ZXIgYmUgYSBjb25jZWl2YWJsZSBjYXNlIHdoZXJlIHRoZSBmaWx0ZXIgd2lsbCByZXR1cm4g b2JqZWN0cy4NCj4gDQo+IEluIG15IGV4cGVyaWVuY2UgZGV2ZWxvcGVycyBhcmUgcmVhbGx5IGJh ZCBhdCBwdXR0aW5nIHRvZ2V0aGVyIGxvZ2ljIHdoaWNoDQo+IGNhbiBhY2N1cmF0ZWx5IG1ha2Ug YSBkZXRlcm1pbmF0aW9uIG9mICJ3aWxsIG5ldmVyIGJlIGEgY29uY2VpdmFibGUgY2FzZSIuDQo+ IFRoaXMgaXMgcGFydGljdWxhcmx5IHRydWUgb2Ygc3lzdGVtcyB3aGljaCBwZXJtaXQgc29mdHdh cmUNCj4gdXBncmFkZXMvaW5zdGFsbGF0aW9ucyB3aXRob3V0IHJlcXVpcmluZyBhIHJlYm9vdCwg YW5kIG9mIHN5c3RlbXMNCj4gcGVybWl0dGluZyBob3QgaW5zZXJ0aW9uIG9mICh1cGdyYWRlZCkg bGluZSBjYXJkcy4NCj4gVGhlICJpbmNvbmNlaXZhYmxlIiBoYXBwZW5zIHdpdGggYWJvdXQgZXZl cnkgdGhpcmQgc29mdHdhcmUgdXBkYXRlLg0KPiA6LSkNCj4NCj4gPiAgICAgVGhpcyBpcyBhIHZh bGlkIHJlc3BvbnNlLCBiZWNhdXNlIGl0IGFsbG93cyBzdWJzY3JpcHRpb24gdG8NCj4gPiAgICAg bm9uLWV4aXN0ZW50IG9iamVjdHMsIGFuZCBhbHNvIGFsbG93cyB0aGUgcHVibGlzaGVyIHRvIHJl amVjdCBhDQo+ID4gICAgIHN1YnNjcmlwdGlvbiB3aGVuIHRoZXJlIHdpbGwgbmV2ZXIgYmUgYW55 dGhpbmcgc2VsZWN0ZWQuDQo+IA0KPiBBbiBhY2N1cmF0ZSBkZXRlcm1pbmF0aW9uIG9mICJuZXZl ciIgY2FuIGJlIGEgZGljZXkgcHJvcG9zaXRpb24uDQoNCkV4YWN0bHkhICAgICBUbyBhbGwgeW91 ciBwb2ludHMgYWJvdmUuDQoNClRoaXMgaXMgd2h5IGEgZmV3IGRheXMgYWdvIEkgZmxvYXRlZCB0 aGUgd29yZHMgIm5vdCBsaWtlbHkiLiAgQnV0IHRoaXMgaW5leGFjdG5lc3Mgd2FzIHNlZW4gYXMg Y29uZnVzaW5nIHRvIGltcGxlbWVudGVycy4NCg0KTm8gbWF0dGVyIHdoYXQgd29yZHMgYXJlIGNo b3NlbiwgdGhlIGdvb2QgbmV3cyBpcyB0aGF0Og0KDQooYSkgYW55IGRlY2lzaW9uIHRvIGFnZ3Jl c3NpdmVseSByZWplY3Qgc3Vic2NyaXB0aW9ucyB3aGljaCBsYXRlciBwcm92ZSBpbnRlcmVzdGlu ZyB3aWxsIGNhdXNlIHJlcXVlc3RzIGZyb20gY3VzdG9tZXJzIHRvIHZlbmRvcnMgdG8gaW1wcm92 ZSB0aGVpciBpbXBsZW1lbnRhdGlvbiwgYW5kDQoNCihiKSBhbnkgZGVjaXNpb24gdG8gYWdncmVz c2l2ZWx5IGFsbG93IHN1YnNjcmlwdGlvbnMgZm9yIHN1YnRyZWVzIHdoaWNoIChhbG1vc3QgY2Vy dGFpbmx5KSB3aWxsIG5ldmVyIGhhdmUgb2JqZWN0cyBwdXNoZWQgd2lsbCB3YXN0ZSBzdWJzY3Jp cHRpb24ncyB3b3J0aCBvZiAgQ1BVL21lbW9yeS4gIEJ1dCBzaG91bGRuJ3QgaW1wYWN0IG11Y2gg ZWxzZS4NCg0KU28gdG8gbWUgdGhpcyBpcyBhIGNsYXNzaWMgZmVhdHVyZSBjb3ZlcmFnZSBhbmQg cGxhdGZvcm0gc2NhbGUgb3B0aW1pemF0aW9uIHdoaWNoIHdpbGwgcGxheSBvdXQgb3ZlciB0aW1l Lg0KDQpFcmljDQoNCg0KPiBSYW5keQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gTmV0Y29uZkBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYN Cg== From nobody Fri Dec 8 09:21: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 8C4EB126DFB; Fri, 8 Dec 2017 09:21:52 -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 jm3Gs_U8o8iO; Fri, 8 Dec 2017 09:21:50 -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 242E0120713; Fri, 8 Dec 2017 09:21:50 -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 vB8HJil8017674; Fri, 8 Dec 2017 09:21:49 -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 : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=lDf6y5241xP2QJdb1nFcEhiLmicPxdsGpFN3OBymNTY=; b=Cc0ojMOn8azDliO+oyhHAa2rg00yu+Qn4a+K1/W5K06JJTJjJrCljupgZkTj09kmwpmb ZmQX5YDkthldcZz2jAmbz5ZA168SxyAUEGPAVDIDiIuQrVRKrr6sCaHoYAO+E1hgdSLx ZkyLSfonsR7tv3zP7GmJQbu9EsoXTxGeUVzuB+65RaKMS5R4BLiyrXStaJgwpureJeXX vMcAh9Pq2BUtgX9joCY/G16bsBWHUKqlAQi5VpCw29hSsc3XRjYksp46RQCCB3omPCCB xVXFublhKv+hHq+GMKVYTndAf1wkjHdLE2qo8UY0rjxNok35MZWksW+fZ+HV9NuFy1rM 4A== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0022.outbound.protection.outlook.com [216.32.180.22]) by mx0b-00273201.pphosted.com with ESMTP id 2eqvs0ge9k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 08 Dec 2017 09:21:49 -0800 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_P256) id 15.20.323.4; Fri, 8 Dec 2017 17:21:47 +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.0323.004; Fri, 8 Dec 2017 17:21:47 +0000 From: Kent Watsen To: Ladislav Lhotka CC: "netconf@ietf.org" , "netmod@ietf.org" Thread-Topic: [netmod] [Netconf] Alternative YANG library structure for 7895bis Thread-Index: AQHTWXr4QzV6rQAfmUKbAB+TvqMKD6MVuWCAgAACOoCAI/VDAIAAB3oAgAAA4QCAAAOyAIAABEIAgAAOAID//7wZgA== Date: Fri, 8 Dec 2017 17:21:47 +0000 Message-ID: References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> In-Reply-To: <1512750289.11843.3.camel@nic.cz> 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.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB273; 6:BWkAYdFYw5sG6+DveqkMK0TyHzF2tbku6w0ZON/WrXXCglAF+E9rpIt1+urfSlgzUM7ATzWqc+/Zocz66eD/6tv+yeAo0ZceoZ9ZRvtCkKRYiWVXWZNi1M5Njc2pX37zuS/FzYYSQncRT8R/+lV15iPwgDntz8DfMSkeq7GQutZqjvE2cfr5b1tfmeaTfauHtqDW1cSpQsSWUTR33Z3L8MsCHZGFfuh142HoD4zdtffoK676hA1Ssn81wkveS1+KGvUmoay9/TkUF6WIQI7Wl0nY38cf/oklECP6CnvzYTeeg64srOLqgCyHZ6iis9B3ItI38GNgyHKFWe91MHDhPHkOvZ3kH+5QnHPDf4QGWiM=; 5:J0kCOOCPzxarqkKchAbQpWq5SoNtp7ysHSNKzKW74nvl3AqaJ9DuAuAcAgi6hCL2iQtY2P+wkUXujH/t4/StvTrWRT1hmaGq2yAF9uz03XRIXRv59XcGhRH5TeOi+bOaDdUO5/iaSqsYEDWOPj+OIGSBCu5rfwsvvzxdEfuSbvY=; 24:M4VgdivN98xZ4Y1D1YJMTqkSIIQnFlzr2wNK5fGavriq1MvAsuvW8Z2x13hvdTvfz/shg2vO0v785PngE5GzkjPL4kdFMxMlT3PQ5+HdXHE=; 7:TXsBKuNznGyMwvqQt5C3ICHLFXGumbFjbGujBYl9GO/eMNcMO9s0TX3E+IhT3LgVGKVHEAh9RocIlo5uiSCSVDOHk7//dSnNMkm8E9SqS1T+uVxDhyHh4ee3L6F1rHtHwkGT/UDVPM/kBTw7l15E/gt1x3m1mAshxOYOvD+lUuE91AAD/Jc/zjfC01WkNJbs1Vy/hC/vYfUqCbVVZ0HVz8zwDSfNcd6YdTNcMAbre+ska5QIR1jD7EFgRaVMo3qp x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 897fb496-db54-4d64-ae27-08d53e602998 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); SRVR:BLUPR05MB273; x-ms-traffictypediagnostic: BLUPR05MB273: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231022)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011); SRVR:BLUPR05MB273; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR05MB273; x-forefront-prvs: 0515208626 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(346002)(376002)(24454002)(377424004)(189003)(199004)(97736004)(53936002)(114624004)(7736002)(82746002)(6116002)(4326008)(3846002)(25786009)(102836003)(6246003)(66066001)(316002)(58126008)(93886005)(54906003)(33656002)(3280700002)(106356001)(3660700001)(105586002)(2950100002)(68736007)(81166006)(8936002)(575784001)(8676002)(81156014)(305945005)(229853002)(6916009)(83716003)(2906002)(83506002)(6512007)(36756003)(2900100001)(5660300001)(6506006)(86362001)(6436002)(77096006)(99286004)(76176011)(6306002)(14454004)(478600001)(966005)(6486002); 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) 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: 897fb496-db54-4d64-ae27-08d53e602998 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2017 17:21:47.7510 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB273 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-08_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712080238 Archived-At: Subject: Re: [Netconf] [netmod] 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, 08 Dec 2017 17:21:53 -0000 Q0MtaW5nIE5FVENPTkYsIHdoZXJlIHRoZSBkcmFmdCBpcyBiZWluZyB3b3JrZWQgb24uDQoNCktl bnQNCg0KDQpPbiBGcmksIDIwMTctMTItMDggYXQgMTY6MzQgKzAxMDAsIEp1ZXJnZW4gU2Nob2Vu d2FlbGRlciB3cm90ZToNCj4gT24gRnJpLCBEZWMgMDgsIDIwMTcgYXQgMDQ6MTk6MjhQTSArMDEw MCwgVmxhZGltaXIgVmFzc2lsZXYgd3JvdGU6DQo+ID4gDQo+ID4gWWVzLiBUaGUgZGVmYXVsdCB2 YWx1ZSBmb3IgeWFuZy1saWJyYXJ5LWRhdGFzdG9yZSBsZWFmIGlzIGRzOm9wZXJhdGlvbmFsDQo+ ID4gKHRoZSBvbmx5IHBvc3NpYmxlIG9uZSBmb3IgdGhlIGRzOm9wZXJhdGlvbmFsIGRhdGFzdG9y ZSkuIFRoaXMgaXMgYmFja3dhcmQNCj4gPiBjb21wYXRpYmxlLiBJZiBvbmUgbmVlZHMgZGlmZmVy ZW50IG1vZGVsIGZvciAncnVubmluZycsIGV0Yy4gdGhlbiBhIG5ldw0KPiA+IGRhdGFzdG9yZSBp ZGVudGl0eSBoYXMgdG8gYmUgZGVmaW5lZCAgYW5kIHNldCBpbiBwbGFjZSBvZiB0aGUgZGVmYXVs dCB2YWx1ZS4NCj4gPiBUaGVuIHRoaXMgaWRlbnRpdHkgY2FuIGJlIHVzZWQgdG8gcmVhZCB0aGUg eWFuZy1saWJyYXJ5IGRhdGEgd2l0aA0KPiA+IDxnZXQtZGF0YT4uDQo+ID4gDQo+IA0KPiBTb3Jy eSwgYnV0IEkgaGF2ZSB0byBhc2sgdGhpczogSG93IGRvIEkgb2J0YWluIHRoZSBzY2hlbWEgZm9y IHRoZQ0KPiBkYXRhc3RvcmUgKGxldHMgY2FsbCBpdCA8cnVubmluZy1saWJyYXJ5PikgdGhhdCBy ZXBvcnRzIHRoZSBzY2hlbWEgZm9yDQo+IDxydW5uaW5nPj8gSXMgdGhlcmUgYW5vdGhlciA8cnVu bmluZy1saWJyYXJ5LWxpYnJhcnk+IGRhdGFzdG9yZT8gV2lsbA0KPiB0aGUgcmVjdXJzaW9uIGVu ZD8gUGVyaGFwcyBpdCBkb2VzIHNpbmNlIDxydW5uaW5nLWxpYnJhcnktbGlicmFyeT4NCj4gbWln aHQgaGF2ZSBpdHNlbGYgbGlzdGVkIGFzIHRoZSBzY2hlbWEgZGVmaW5pbmcgZGF0YXN0b3JlLiBJ IGd1ZXNzDQo+IExhZGEgd2lsbCBsaWtlIHRoZXNlIGtpbmQgb2YgbWV0YSBhbmQgbWV0YS1tZXRh IGRhdGFzdG9yZXMuDQoNCk5vdCByZWFsbHkuIE1ldGFkYXRhIG5lZWRuJ3QgYmUgaW4gZGF0YXN0 b3Jlcy4NCg0KTGFkYQ0KDQo+IA0KPiAvanMNCj4gDQotLSANCkxhZGlzbGF2IExob3RrYQ0KSGVh ZCwgQ1ouTklDIExhYnMNClBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcg bGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZk PUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05 emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09NXFqNkJRVVN3cVlt a0FWZUt6NWF4RlY4azNneFlFUFNKNUNwMFJTbnhyRSZzPUk3ZlIxR1k1bE4yaFZNa0R1dnJ5cmhE ZVJ5cGlrZTN3UGVGUnJ2UUk1bDgmZT0NCg0KDQo= From nobody Fri Dec 8 09:22: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 21BCE120713; Fri, 8 Dec 2017 09:21:53 -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 1W_9LmtBIF8g; Fri, 8 Dec 2017 09:21:50 -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 0AA3C1201FA; Fri, 8 Dec 2017 09:21:49 -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 vB8HJjca017679; Fri, 8 Dec 2017 09:21: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 : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=gP5lWcV9oGpRMdljWOXJZHcK5p5R3p9d1F70aBTuF8k=; b=S/GjiDoTPtGT7hRQw3rmfT+h1RTw/UuIMHvQhsVqR00uXw3tdx6adJQ+4N3yORpoZJs9 iqXQjDwwznMNigO6DnjTmstmmY1Pl6Jzwx3NUK3yxLK58jeEYDepefuZ3mvJEm9fO2T/ rjoZjUkiKP05QxAXYSCeCZqZ9jI857fj4n1W1PjJZc2pqkM6aJLYwUN40y8hbuBabvKb DRHKPA/uJ+xZ5wqNhHlNznLIoNYFzF99tlS9Lh+CmxsFSy0VVU/0D+peWcqQpJ/WEfxJ u5Al3xYsVgdX36KXVSdXGSnbgzYdg5OZNdevFxNYnkkiybk+HH9bagIaV3oCXHU7SCPY 3Q== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0023.outbound.protection.outlook.com [216.32.180.23]) by mx0b-00273201.pphosted.com with ESMTP id 2eqvs0ge9g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 08 Dec 2017 09:21:47 -0800 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_P256) id 15.20.323.4; Fri, 8 Dec 2017 17:21:45 +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.0323.004; Fri, 8 Dec 2017 17:21:45 +0000 From: Kent Watsen To: Vladimir Vassilev , Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" CC: "netconf@ietf.org" , "netmod@ietf.org" Thread-Topic: [netmod] YANG library structure Thread-Index: AQHTcAmh7On8if5A/Ee2i3mIHQ1NsKM5SlSAgAABMACAAA7wAIAAAbAAgAAf1oCAAAwRAP//1hqA Date: Fri, 8 Dec 2017 17:21:45 +0000 Message-ID: <43C2E52C-08E1-4100-B948-F40B43038D97@juniper.net> References: <20171208111504.iwpcck3hkbboryeo@elstar.local> <20171208121434.2vfbrc5pdbwnx3ig@elstar.local> <20171208.150831.2068512524982133442.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.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB273; 6:ODePrTeuGFIRjlYT1bpcDU5CxvoZGCtLRIJo9iheafGpTeIhwwiabfQulf7qvVRvowwhl977Yv346JsuuPKLbcMt32GDgVUEY2QVKQCic6SIlKKbUx5txUg/UygAhac9k5lTsaxvxtAIdRwVsqNk7nDsyMcPg5PaaB/syTb4zpmZDkxXk3wP5EjOtD2FZW6UIIVKDCNXyar14gTRZFqWZZu3Li86o17j1743IpPaFPiCM0x6ms9oJ740JlVaNMZo8H7pxnlmMnLAkIi3IF10KDcxax3J/cQKVPJfNIlt7Op+6xGcfdBlAKbjy911vmNwnEVv12XfEk3zeVSCRIerb0NDuLJnaOT52KzquPwbiFE=; 5:26sHjufYtpbfMJ/fu6t+9vZubHEkfSb/+2Iz3UWXmZPXte06mF3Ue2/wg26uk5nw15kCdZZjQ+Wips4kDSD1NO8RG8oGf5ECN2FxTBIVo5a8BPZ3BJrp/TwMDXZIHmVk6LLD3czHhf8r0aQJBcb/dS/DDDoY7Qe6mGZaKskyTns=; 24:eYVuGJIfekTurGKxZDRpGBxfpEia6ATXPL7/Ests9U2ifEfV4lVQnM1X3sV4yYidBY+cPuMKsqMLDkuSsh+a4rRm7ra12wNAnuq5GX/sfbY=; 7:oRTmycoihax0+rNPTbFEP1EFefZiiwdINDHJ+qTAwsUscmE/luC1p8e17/Dg3gBFZaym6gh+pLhOjJu+3rdu+1IzuiOxfZX8yy+3Ra8d4LKWIF38Gvzslm65HFbhSJ+VW92Y8R2MoIyLxWvYj98bD2AacpRyeyZZdRR3r/Ob7edzmGCVz6RQQePhhszE5zYt0ONCRb5cz3GTjXnkcaWzzD9S5+WAc3b2052QX9H8WxdwAHDA7+ZHOeDDynNO9bSY x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f63016e5-6f1c-4af4-a95e-08d53e60286e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307); 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:(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231022)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011); SRVR:BLUPR05MB273; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR05MB273; x-forefront-prvs: 0515208626 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(346002)(376002)(24454002)(189003)(199004)(97736004)(53936002)(53546010)(7736002)(82746002)(6116002)(4326008)(3846002)(25786009)(102836003)(6246003)(66066001)(316002)(110136005)(58126008)(93886005)(54906003)(561944003)(33656002)(3280700002)(106356001)(3660700001)(105586002)(2950100002)(68736007)(81166006)(8936002)(575784001)(8676002)(81156014)(305945005)(229853002)(83716003)(2906002)(83506002)(6512007)(36756003)(2900100001)(5660300001)(6506006)(86362001)(6436002)(77096006)(2501003)(99286004)(76176011)(6306002)(14454004)(478600001)(966005)(6486002); 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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <35DC6E912A6E924B97C8C414DE72DE9E@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: f63016e5-6f1c-4af4-a95e-08d53e60286e X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2017 17:21:45.8291 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB273 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-12-08_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712080238 Archived-At: Subject: Re: [Netconf] [netmod] YANG library structure 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, 08 Dec 2017 17:21:53 -0000 DQpDQy1pbmcgTkVUQ09ORiwgd2hlcmUgdGhlIGRyYWZ0IGlzIGJlaW5nIHdvcmtlZCBvbi4NCg0K S2VudA0KDQoNCk9uIDEyLzA4LzIwMTcgMDM6MDggUE0sIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6 DQoNCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZl cnNpdHkuZGU+IHdyb3RlOg0KPj4gT24gRnJpLCBEZWMgMDgsIDIwMTcgYXQgMDc6MDg6MzJBTSAt MDUwMCwgTG91IEJlcmdlciB3cm90ZToNCj4+PiBPbiAxMi8wOC8yMDE3IDA2OjE1IEFNLCBKdWVy Z2VuIFNjaG9lbndhZWxkZXIgd3JvdGU6DQo+Pj4+ICAgDQo+Pj4+PiBJbiB0YWxraW5nIHRvIHNv bWUgb3RoZXJzIG9uIHRoaXMgdG9waWMsIHRoZXkgc3VnZ2VzdGVkIHVzaW5nIGEgbGlicmFyeSBw ZXINCj4+Pj4+IGRhdGFzdG9yZS4gSSBoYXZlbid0IGxvb2sgaW50byB0aGlzIGVub3VnaCB0byBr bm93IGlmIHRoYXQgaXMgYSBnb29kIG9yIGJhZA0KPj4+Pj4gaWRlYSwgYnV0IGl0IHNlZW1zIGZ1 bmN0aW9uYWxseSBlcXVpdmFsZW50IHRvIHlvdXIgZmlyc3Qgb3B0aW9uIGJ1dCByZWFsaXplZA0K Pj4+Pj4gaW4gYSBkaWZmZXJlbnQgd2F5LiBKdXN0IHNvbWV0aGluZyB0byBhZGQgdG8gdGhlIG1p eC4NCj4+Pj4gSWYgcGVvcGxlIHdhbnQgdG8gcHV0IGFkZGl0aW9uYWwgb3B0aW9ucyBvbiB0aGUg dGFibGUsIHRoZXkgc2hvdWxkDQo+Pj4+IHdvcmsgb3V0IHRoZSBkZXRhaWxzIGFuZCB3cml0ZSBk b3duIGEgdHJlZSBkaWFncmFtIGFuZCBzZW5kIHRoZSByZXN1bHQNCj4+Pj4gdG8gdGhlIGxpc3Qu DQo+Pj4gSSBndWVzcyB3ZSBoYXZlIGEgZGlmZmVyZW50IHBoaWxvc29waGljYWwgYXBwcm9hY2gg aGVyZS4gIEknZCBwcmVmZXIgdG8NCj4+PiBoZWFyIGFib3V0IGZyZXNoIGlkZWFzLCBldmVuIGlm IGhhbGYgYmFrZWQgb3IgYXNrZWQgYXMgYSAic3R1cGlkDQo+Pj4gcXVlc3Rpb24iLiBTb21ldGlt ZXMsIGlmIG5vdCBkaXNtaXNzZWQgb3V0IG9mIGhhbmQsIHRoZXNlIGxlYWQgdG8NCj4+PiBzb21l dGhpbmcgdGhhdCBpcyBhIGJldHRlciByZXN1bHQgdGhhbiBvdGhlcnMgdGhhdCBoYXZlIGJlZW4g aW1tZXJzZWQgaW4NCj4+PiB0aGUgaXNzdWUgaGF2ZSB0aG91Z2h0IG9mLg0KPj4+DQo+PiBUaGUg ZGV2aWwgaXMgdXNhbGx5IGluIHRoZSBkZXRhaWxzIGFuZCAndXNpbmcgYSBsaWJyYXJ5IHBlciBk YXRhc3RvcmUnDQo+PiBpcyBmb3IgbXkgdGFzdGUgYSBiaXQgdG9vIGxpdHRsZSB0byB1bmRlcnN0 YW5kIHdoYXQgaXMgYWN0dWFsbHkgYmVpbmcNCj4+IHByb3Bvc2VkLiBJIGFtIG5vdCBkaXNtaXNz aW5nIHByb3Bvc2FscywgYnV0IEkgbGlrZSB0byBiZSBhYmxlIHRvDQo+PiB1bmRlcnN0YW5kIHdo YXQgaXMgYmVpbmcgcHJvcG9zZWQuIEFuZCBmb3IgdGhhdCBJIG5lZWQgYSBwcm9wb3NhbCB0aGF0 DQo+PiBpcyBhIGJpdCBtb3JlIHRoYW4gJ3VzaW5nIGEgbGlicmFyeSBwZXIgZGF0YXN0b3JlJy4N Cj4gSSBhZ3JlZS4gIEluIHRoaXMgY2FzZSwgSSBjYW4ndCB1bmRlcnN0YW5kIGhvdyBpdCB3b3Vs ZCB3b3JrIGF0IGFsbC4NCj4gVGhlIGxpYnJhcnkgaXMgY29uZmlnIGZhbHNlLCBzbyBhIGNsaWVu dCBjYW4gbmV2ZXIgZ2V0IGl0IHZpYQ0KPiBnZXQtY29uZmlnIGZyb20gPHJ1bm5pbmc+LiAgTWF5 YmUgdGhlIHByb3Bvc2FsIGlzIGEgbmV3IG9wZXJhdGlvbg0KPiA8Z2V0LXlhbmctbGlicmFyeT4g d2l0aCB0aGUgZGF0YXN0b3JlIGFzIGEgcGFyYW1ldGVyPyAgT3IgbWF5YmUgdGhlDQo+IGlkZWEg aXMgdG8gc29tZWhvdyByZXR1cm4gbWV0YSBkYXRhIHRvZ2V0aGVyIHdpdGggPGdldC1jb25maWc+ PyAgSSBjYW4NCj4gZ3Vlc3MsIGFuZCBkaXNtaXNzIHRoZSBwcm9wb3NhbCBiYXNlZCBvbiBteSBn dWVzc2VzIDstKSAgT3Igc29tZW9uZQ0KPiBjYW4gd3JpdGUgdXAgYSBjb25jcmV0ZSBwcm9wb3Nh bC4NCkkganVzdCBwb3N0ZWQgYSBmb2xsb3d1cCBvbiBhIHJlbGV2YW50IHByb3Bvc2FsIGluIGEg dGhyZWFkICJbbmV0bW9kXSANCltOZXRjb25mXSBBbHRlcm5hdGl2ZSBZQU5HIGxpYnJhcnkgc3Ry dWN0dXJlIGZvciA3ODk1YmlzIi4NCg0KVmxhZGltaXINCj4NCj4gL21hcnRpbg0KPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFp bGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZv X25ldG1vZCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhj V3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09RVA2 NEdJWDVYUzJ6TzhLMUc3QTZ2WG1UbGNIVjBXQlpadzVyNUdhQlFaVSZzPXdKVzFfMWxmZUdSMUYw WlVpWm1mbWFLTnpFLUVwRTREUXVMd0tZaXlSaWcmZT0NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBp ZXRmLm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed0lDQWcmYz1IQWtZ dWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlF UG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPUVQNjRHSVg1WFMyek84SzFHN0E2dlhtVGxj SFYwV0JaWnc1cjVHYUJRWlUmcz13SlcxXzFsZmVHUjFGMFpVaVptZm1hS056RS1FcEU0RFF1THdL WWl5UmlnJmU9DQoNCg0K From nobody Fri Dec 8 10:01: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 3B719126BFD for ; Fri, 8 Dec 2017 10:01:28 -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 CntQOv04aPVi for ; Fri, 8 Dec 2017 10:01:25 -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 CDF571288A9 for ; Fri, 8 Dec 2017 10:01:24 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id 74so12743130lfs.0 for ; Fri, 08 Dec 2017 10:01:24 -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=3dwhztOLwvXmXXoxMK4N7GPHlDOnZjto3w65anNtocY=; b=we2UGomCbHRqKj8cBbXJRtY+AcXkKS7RlrJ/GUtCZg3H4cpk8OgU9P5vE6gxRBjFHl /G22I4sBxuSWDwuxkhm0ghqgm9hen6MY/LJsnPvAwzP3yUf5D13/Dw22I8ZGFJnsY3xb 1UwWNMGn63YA2ow9g0er0dDI3B4fNHLk10P1FVTLtdFbbh5tduPhxy6UN/EG/zBMbDlr cvGgeD9PBhAQ6Lm2yc/lPA9uowN+rj1KpOGTIaXSYFUkrvYS4yAzhICxNc5Rxts4aZSB 1V4Uj42ngJKIX3e6jLjm97KhrMsmEDiWhic3mIWR3BqWeofEWPxj7wbRDzykNyaBUlDe 3JBA== 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=3dwhztOLwvXmXXoxMK4N7GPHlDOnZjto3w65anNtocY=; b=KfpTYE6WEIWZc2S/ruADylYEfkosn4RzufL2JfIievxed6kA3o7Li0GbcKXAhWUp88 1z748RzcLg4KFPrjIHMnLh2UspXfNPp/EC22SQo+d41X9P7oHZfQLlof28emhTTIUh62 1852rVuWIOeiPTpnvlUdua+Xl9EH9SwrwvH1vyiTUM0l8QPA+Cy7dHUogSJIWq8hPkJ2 6BcBl353BbER5/77bBQOgwN6b1tK3vlIxfBUSUDMByY4knS1O9yxth5a6cv5wF4rkJT8 IT1ujI7t+z/ebbJUjewPgCjcy+Wnps2tqq3V767b7Ij0xH4YCskiHgm9V30CuzTiJHVc LMcQ== X-Gm-Message-State: AJaThX76+KCt0gCboyd7ki8bIgrz63JoPqP1lg0rV+ObAbWw7IO4P4jA aLDmep4Y2BJNv+biC/3V/wi2tx6wI9QBppan7C7+lg== X-Google-Smtp-Source: AGs4zMZNcOpx5rSGKQA0fvXh3PrJH2r2JyMFDV4YBhboW4DM8GFDzu6+oklGNp/M9HCT7sQLk0VLPPm7F5msIN8IvQ4= X-Received: by 10.46.93.2 with SMTP id r2mr16162376ljb.182.1512756083041; Fri, 08 Dec 2017 10:01:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Fri, 8 Dec 2017 10:01:20 -0800 (PST) In-Reply-To: References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> From: Andy Bierman Date: Fri, 8 Dec 2017 10:01:20 -0800 Message-ID: To: Kent Watsen Cc: Ladislav Lhotka , "netconf@ietf.org" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a114b8c24f63bfb055fd7f84e" Archived-At: Subject: Re: [Netconf] [netmod] 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, 08 Dec 2017 18:01:28 -0000 --001a114b8c24f63bfb055fd7f84e Content-Type: text/plain; charset="UTF-8" Hi, A library per datastore sounds too complicated. I prefer the proposal that was made at the IETF meeting that had a 'not-implemented-in' leaf-list and a single module list. Why is it interesting to have a separate module list for regular modules and imported modules? I prefer to keep the conformance leaf and not change the module list. NMDA needs to be possible to implement with a single schema tree such that a module is implemented in all datastores, or a subset of all datastores. Otherwise it probably won't get supported in clients. Andy On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen wrote: > CC-ing NETCONF, where the draft is being worked on. > > Kent > > > On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote: > > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote: > > > > > > Yes. The default value for yang-library-datastore leaf is > ds:operational > > > (the only possible one for the ds:operational datastore). This is > backward > > > compatible. If one needs different model for 'running', etc. then a new > > > datastore identity has to be defined and set in place of the default > value. > > > Then this identity can be used to read the yang-library data with > > > . > > > > > > > Sorry, but I have to ask this: How do I obtain the schema for the > > datastore (lets call it ) that reports the schema for > > ? Is there another datastore? Will > > the recursion end? Perhaps it does since > > might have itself listed as the schema defining datastore. I guess > > Lada will like these kind of meta and meta-meta datastores. > > Not really. Metadata needn't be in datastores. > > Lada > > > > > /js > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www. > ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m= > 5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s= > I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e= > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a114b8c24f63bfb055fd7f84e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

A library per datastore sounds too = complicated.
I prefer the proposal that was made at the IETF meet= ing that had
a 'not-implemented-in' leaf-list and a singl= e module list.

Why is it interesting to have a sep= arate module list for regular modules and imported modules?
I pre= fer to keep the conformance leaf and not change the module list.
=
NMDA needs to be possible to implement with a single schema = tree such that a module
is implemented in all datastores, or a su= bset of all datastores.=C2=A0 Otherwise it probably won't
get= supported in clients.


Andy



On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen <kwatsen@ju= niper.net> wrote:
CC-ing N= ETCONF, where the draft is being worked on.

Kent


On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote:
> On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote:
> >
> > Yes. The default value for yang-library-datastore leaf is ds:oper= ational
> > (the only possible one for the ds:operational datastore). This is= backward
> > compatible. If one needs different model for 'running', e= tc. then a new
> > datastore identity has to be defined=C2=A0 and set in place of th= e default value.
> > Then this identity can be used to read the yang-library data with=
> > <get-data>.
> >
>
> Sorry, but I have to ask this: How do I obtain the schema for the
> datastore (lets call it <running-library>) that reports the sche= ma for
> <running>? Is there another <running-library-library> data= store? Will
> the recursion end? Perhaps it does since <running-library-library&g= t;
> might have itself listed as the schema defining datastore. I guess
> Lada will like these kind of meta and meta-meta datastores.

Not really. Metadata needn't be in datastores.

Lada

>
> /js
>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@ietf.org
ht= tps://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scb= fh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYa= GTvjISlaJdcZo&m=3D5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0R= SnxrE&s=3DI7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e= =3D


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

--001a114b8c24f63bfb055fd7f84e-- From nobody Fri Dec 8 11:03: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 2A31D1275F4 for ; Fri, 8 Dec 2017 11:03:51 -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 yr0oH32udkYQ for ; Fri, 8 Dec 2017 11:03:47 -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 80316126D85 for ; Fri, 8 Dec 2017 11:03:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=61652; q=dns/txt; s=iport; t=1512759827; x=1513969427; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WzlXz2obnYci+bN/ZrsBPmEhP3W7866hZhdDvtPZrEg=; b=EYLyIelTQPMhUsGqdAzHuy9yEUqwjXsdkhq7IF3OtIBhKefZRgHRKFnp NJTB16qS4Zuau4QVmPOoIye6pdObhu6DWg/OKE4Cq06Vx9P3Vl5qDVdaD uuCipdNFBL0sdmTzR17Qk5HDSfR4/8A4saFApKzr8b3Wwr0cGHWEdfz5f c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DiAQCw4Spa/4YNJK1VBxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCSnRmdCcHg3uZIoF9lwwUggEKhTsCGoRFQBcBAQEBAQEBAQF?= =?us-ascii?q?rKIUiAQEBAQMaCQpKAhACAQgVAg4TAQYDAgICMBQJCAIEDgUIiTxkqBeCJyaKP?= =?us-ascii?q?gEBAQEBAQEBAQEBAQEBAQEBAQEBAR2DW4ILgVaBaYMrhGwBEgEHBRoHCR8Cgl2?= =?us-ascii?q?CYwWKPgcHiTGPCwKVFYQcj06WLwIRGQGBOgEhAzRhbm8VgmOCUhyBZgF4h24PG?= =?us-ascii?q?AOBCYEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,378,1508803200"; d="scan'208,217";a="330189752" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Dec 2017 19:03:23 +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 vB8J3NEb002327 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Dec 2017 19:03:23 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; Fri, 8 Dec 2017 14:03:22 -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, 8 Dec 2017 14:03:22 -0500 From: "Eric Voit (evoit)" To: Balazs Lengyel CC: "netconf@ietf.org" Thread-Topic: [Netconf] Comments on draft-ietf-netconf-subscribed-notifications-07 Thread-Index: AQHTbRsShRwLk9UfAEqo1yQ5SFUVPKM5hQ2w Date: Fri, 8 Dec 2017 19:03:22 +0000 Message-ID: <324be64174484ddca5a8b19b358b95e1@XCH-RTP-013.cisco.com> References: <1da803f0-206e-a00b-f62c-48659947c51b@ericsson.com> In-Reply-To: <1da803f0-206e-a00b-f62c-48659947c51b@ericsson.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_324be64174484ddca5a8b19b358b95e1XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] Comments on draft-ietf-netconf-subscribed-notifications-07 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, 08 Dec 2017 19:03:51 -0000 --_000_324be64174484ddca5a8b19b358b95e1XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmFsYXpzLA0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cy4gIEluLWxpbmUuLi4NCg0KRnJv bTogQmFsYXpzIExlbmd5ZWwsIERlY2VtYmVyIDQsIDIwMTcgMTE6MTUgQU0NClRvOiBuZXRjb25m QGlldGYub3JnDQpTdWJqZWN0OiBbTmV0Y29uZl0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1uZXRj b25mLXN1YnNjcmliZWQtbm90aWZpY2F0aW9ucy0wNw0KDQoNCkhlbGxvLA0KDQpTb3JyeSBpZiBz b21lIG9mIHRoZSBjb21tZW50cyBhcmUgYWxyZWFkeSByZXNvbHZlZC4gSSBkaWQgbm90IGhhdmUg dGltZSB0byBzY2FuIHRocm91Z2ggYWxsIHRoZSBtYWlscy4NCg0KMS4zKQ0KDQpTaG91bGQgd2Ug Zm9ybWFsbHkgc3RhdGUgc29tZSB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzPw0KDQpUaGlzIGNoYXB0 ZXIgc2VlbXMgdG8gYXNzdW1lOg0KLSB0cmFuc3BvcnQgaXMgZWl0aGVyIGNvbm5lY3Rpb24tb3Jp ZW50ZWQgYW5kIHJlbGlhYmxlDQotIG9yIGNvbm5lY3Rpb25sZXNzL3N0YXRlbGVzcywgYnV0IGhh cyBhY2tub3dsZWRnZW1lbnQgZm9yIHRoZSBub3RpZmljYXRpb25zDQpzbyB0aGUgcHVibGlzaGVy IGNhbiBkZXRlcm1pbmUgd2hldGhlciB0aGUgcmVjZWl2ZXIgYWN0dWFsbHkgZ290IHRoZSBub3Rp ZmljYXRpb24gb3Igbm90Lg0KDQo8ZXJpYz4gVGhlcmUgaXMgbm8gZXhwbGljaXQgcmVxdWlyZW1l bnRzIHRoYXQgU3Vic2NyaWJlZCBub3RpZmljYXRpb25zIG11c3QgYmUgdXNlZCB3aXRoIHNvbWUg Zm9ybSBvZiBhY2tub3dsZWRnZW1lbnQuICAgQW5kIHdpdGggTkVUQ09ORiwgUkVTVENPTkYsIEhU VFAyLCBhbmQgVURQIHRyYW5zcG9ydCBkcmFmdHMgYWxyZWFkeSBhZG9wdGVkIGJ5IHRoZSBXRywg dGhlIG1ham9yaXR5IG9mIHRoZSB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzIGFyZSB0aGVyZS4gIElz IHRoZXJlIGFueXRoaW5nIHNwZWNpZmljIHlvdSBkb27igJl0IHNlZSB3aGljaCBjYW4gYmUgY2Fs bGVkIG91dD8NCg0KIlRoZSBsaWZldGltZSBvZiBhIGNvbmZpZ3VyZWQgIHN1YnNjcmlwdGlvbiBp cyBkcml2ZW4gYnkgcmVsZXZhbnQNCmNvbmZpZ3VyYXRpb24gYmVpbmcgcHJlc2VudCBvbiB0aGUg cnVubmluZyBjb25maWd1cmF0aW9uLiINCklzIGl0IHJlYWxseSB0aGUgInJ1bm5pbmciIGNvbmZp Zz8gSU1ITyBpdCBzaG91bGQgYmUgdGhlIG9wZXJhdGlvbmFsLg0KDQo8ZXJpYz4gSSBiZWxpZXZl IHJ1bm5pbmcgaXMgY29ycmVjdC4gICBJIGJlbGlldmUgc3VjaCBhIHN1YnNjcmlwdGlvbiBhbGl2 ZSBpZiBpdCBjYW4gYmUgc2VlbiBvbiB0aGUgc3lzdGVtLCBldmVuIGlmIG5vIHJlY2VpdmVycyBh cmUgYWN0aXZlLg0KDQoiRHluYW1pYyBzdWJzY3JpcHRpb25zIGNhbiBvbmx5IGJlIG1vZGlmaWVk IHZpYSBhbiBSUEMgcmVxdWVzdA0KDQptYWRlIHVwb24gdGhlIG9yaWdpbmFsIHN1YnNjcmliaW5n IHRyYW5zcG9ydCBzZXNzaW9uLiINCg0KSG93IGRvZXMgdGhpcyB3b3JrIGluIGNhc2Ugb2YgUmVz dGNvbmY/IFRoZSB0cmFuc3BvcnQgc2Vzc2lvbiBjYW4gYmUgdmVyeSBicmllZi4NCg0KU2hvdWxk bid0IHdlIGRpc2N1c3MgcmVzdGNvbmYgYW5kICJzYW1lIHRyYW5zcG9ydCBzZXNzaW9uIiBnZW5l cmFsbHkgc29tZXdoZXJlPw0KDQoNCg0KPEVyaWM+IFllcywgaWRlbnRpZmljYXRpb24gb2YgdGhl IHNhbWUgdHJhbnNwb3J0IHNlc3Npb24gYXQgYSBoaWdoIGxldmVsIGJlY29tZXMgdHJpY2t5IGZv ciBjb25uZWN0aW9ubGVzcyB0cmFuc3BvcnQuICBBdCBhIG1pbmltdW0sIHRoZSBwcm9wZXIgbGlm ZWN5Y2xlIGFsd2F5cyBuZWVkcyB0byBiZSBkZXRlcm1pbmVkL2luY2x1ZGVkIGluIHRoZSB0cmFu c3BvcnQgZHJhZnRzLiAgRm9yIFJFU1RDT05GLCBpbiBkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNv bmYtbm90aWYgdGhlcmUgaXMgQXBwZW5kaXggQS4yIHdoaWNoIGRlc2NyaWJlcyBob3cgdG8gaGFu ZGxlIHRoaXMgd2l0aCBhIFRMUyBIZWFydGJlYXQuICBJbiBsaWV1IG9mIHRoYXQgb3B0aW1pemF0 aW9uLCBhIFRDUCBjb25uZWN0aW9uIGluaXRpYXRlZCBmcm9tIHRoZSByZWNlaXZlciB3aGljaCBp cyBsb3N0IHdpbGwgYXQgc29tZSBwb2ludCBiZSByZWNvZ25pemVkIGJ5IHRoZSBwdWJsaXNoZXIg KGUuZy4sIHNlZSBmbG93cyBpbiBzZWN0aW9ucyAzLjEpLiAgICBDb21pbmcgYmFjayB0byBzdWJz Y3JpYmVkLW5vdGlmaWNhdGlvbnMsIHdoYXQgaWYgSSBqdXN0IHNheSDigJwuLi5hbiBSUEMgcmVx dWVzdCBtYWRlIGZyb20gdGhlIG9yaWdpbmFsIHN1YnNjcmliZXLigJ0/DQoNCg0KDQoyLjIpDQoN CiJBIHN1YnNldCBvZiBpbmZvcm1hdGlvbiBpcyBuZXZlciBzdHJpcHBlZCBmcm9tIHdpdGhpbiB0 aGUgZXZlbnQgcmVjb3JkLiINCg0KSSBkb24ndCBmdWxseSB1bmRlcnN0YW5kIHRoaXMuIE1heWJl IHJld29yZCBpdCB0bw0KDQoiQSBmaWx0ZXIgYWx3YXlzIHJlbW92ZXMgYSBjb21wbGV0ZSBldmVu dCByZWNvcmQ7IGEgc3Vic2V0IG9mDQoNCmluZm9ybWF0aW9uIGlzIG5ldmVyIHN0cmlwcGVkIGZy b20gYW4gZXZlbnQgcmVjb3JkLiAiDQoNCg0KDQo8RXJpYz4gQ2hhbmdlIG1hZGUuDQoNCg0KDQpJ ZiBhIGZpbHRlciByZW1vdmVzIDIgb3V0IG9mIDMgZXZlbnQgcmVjb3JkcyB3aWxsIHRoZSBub3Rp ZmljYXRpb24gc3RpbGwgYmUgc2VudD8gSXMgdGhhdCBhIHJlYWxpc3RpYyBzaXR1YXRpb24/DQoN Cg0KDQo8RXJpYz4gQXMgZWFjaCBub3RpZmljYXRpb24gd291bGQgYmUgaXRzIG93biBldmVudCBy ZWNvcmQsIHllcyBhbmQgeWVzLg0KDQoNCg0KMi4zKQ0KDQpGaWd1cmUgMSkgSU1ITyBhIHN0YXRl IHRyYW5zaXRpb24gZnJvbSBzdXNwZW5kZWQgdG8gc3VzcGVuZGVkIG9uIG1vZGlmeS1zdWJzY3Jp cHRpb24gaXMgbWlzc2luZy4NCg0KDQoNClRoZSBzdGF0ZSBkaWFncmFtIGZvciBjb25maWd1cmVk IHN1YnNjcmlwdGlvbnMgaXMgbm90IHJlYWxseSBjbGVhci4NCg0KLSBkb2VzIHRoZSBzdWJzY3Jp cHRpb24gaGF2ZSBhIHN0YXRlL3N0YXRlLW1hY2hpbmUgb3IgdGhlIGluZGl2aWR1YWwgcmVjZWl2 ZXJzPw0KDQpUaGUgbW9kZWwgc3VnZ2VzdCBpdHMgdGhlIHJlY2VpdmVycy4NCg0KDQoNCjxFcmlj PiBZZXMsIGl0IGlzIHBlci1yZWNlaXZlci4NCg0KDQoNCi0gdGhlIGRlc2NyaWJlZCBzdGF0ZXMg ZG8gbm90IGNvcnJlc3BvbmQgdG8gdGhlIHN0YXRlcyBkZWZpbmVkIGluDQoNCi9zbjpzdWJzY3Jp cHRpb25zL3NuOnN1YnNjcmlwdGlvbi9zbjpyZWNlaXZlcnMvc246cmVjZWl2ZXIvc246c3RhdHVz DQoNCg0KDQo8RXJpYz4gQXMgc2hvd24gbm93LCB0aGUgc3RhdGUgbWFjaGluZSByZWZsZWN0cyB0 aGUgdmlldyBvZiB0aGUgcmVjZWl2ZXIgY29ubmVjdGlvbiBmcm9tIHRoZSBwb2ludCBvZiB2aWV3 IG9mIHRoZSByZWNlaXZlci4gIEkuZS4sIHRoZSByZWNlaXZlciBpcyBub3QgYXV0b21hdGljYWxs eSBzZW50IGFsbCBhc3BlY3RzIG9mIGludGVybmFsIHN0YXRlIHdoaWNoIG5lZWQgdG8gYmUgcmVw b3J0YWJsZSB0byBhIHB1Ymxpc2hlcuKAmXMgb3BlcmF0b3Igd2hvIGlzIG1hbmFnaW5nIHRoaXMg c3Vic2NyaXB0aW9uLg0KDQoNCg0KVGhhdCBzYWlkLCB5b3UgYXJlIGNvcnJlY3QgdGhhdCBhbiBl YXN5IG1hcHBpbmcgYmV0d2VlbiB0aGUgdHdvIHdvdWxkIGJlIHVzZWZ1bC4NCg0KDQoNCklmIEkg Y2hhbmdlIOKAnGNyZWF0ZeKAnSB0byDigJxjb25maWd1cmF0aW9uIG9wZXJhdGlvbuKAnSAsIGFu ZCBtYWtlIHRoZSBmb2xsb3dpbmcgY2hhbmdlIHRvIHRoZSBib3R0b20gb2YgdGhlIGRpYWdyYW0s IHRoZW4gdGhlIGRpYWdyYW0gY2FuIGFjY29tcGxpc2ggYm90aCBpbnRlcm5hbCBzdGF0ZXMsIGFu ZCBzdGF0ZXM6DQoNCg0KDQogICAgICAnLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tJw0KDQogICAgICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgfA0KDQogICAgICAgICBTdG9wLXRpbWU6ICAgICAgZXJyb3I6ICAgICAgICAgIGNvbmZpZyBk ZWxldGU6DQoNCiAgICAgICAgIHN1YnNjcmlwdGlvbi0gICBzdWJzY3JpcHRpb24tICAgc3Vic2Ny aXB0aW9uLQ0KDQogICAgICAgICBjb21wbGV0ZWQgICAgICAgdGVybWluYXRlZCAgICAgIHRlcm1p bmF0ZWQNCg0KICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICB8DQoN CiAgICAgICAgICAgICAgViAgICAgICAgICAgICAgViAgICAgICAgICAgICAgVg0KDQogICAgICAg Li0tLS0tLS0tLS0tLiAgICAuLS0tLS0tLS0tLS4gICAgIC4tLS0tLS4NCg0KICAgICAgIHwgY29u Y2x1ZGVkIHwgICAgfCBpbi1lcnJvciB8ICAgICB8IGVuZCB8DQoNCiAgICAgICctLS0tLS0tLS0t LScgICAgJy0tLS0tLS0tLS0nICAgICAnLS0tLS0nDQoNCg0KDQpXaGF0IGRvIHlvdSB0aGluaz8N Cg0KDQoNCi0gYnVmZmVyIG92ZXJmbG93IGlzIG1lbnRpb25lZC4gSXMgaXQgYW4gb3ZlcmZsb3cg YXQgdGhlIHJlY2VpdmVyIG9yIHRoZSBwdWJsaXNoZXI/DQoNCg0KDQo8RXJpYz4gUHVibGlzaGVy LiAgIEhhdmUgY2hhbmdlZCB0aGUgdGV4dCB0byB0aGUg4oCcYSBwdWJsaXNoZXIgYnVmZmVyIG92 ZXJmbG934oCdLg0KDQoNCg0KNC4xLjEpIHMvYSBldmVudC9hbiBldmVudC8NCg0KDQoNCjxFcmlj PiBGaXhlZA0KDQoNCg0KNC40KSBzL2Fzc29jaWF0ZWQgdGhlIHRyYW5zcG9ydC9hc3NvY2lhdGVk IHdpdGggdGhlIHRyYW5zcG9ydC8NCg0KDQoNCjxFcmljPiBGaXhlZA0KDQoNCg0KDQoNCjUpIDNy ZCBzZW50ZW5jZSByZXdvcmQhDQoNCg0KDQo8RXJpYz4gSG93IGFib3V0Og0KDQoNCg0KVGhlIGxv d2VyIGhhbGYgdGhlIOKAnGlkZW50aWZpZXLigJ0gb2JqZWN0IGluIHRoZSBzdWJzY3JpcHRpb25z IGNvbnRhaW5lciBTSE9VTEQgYmUgdXNlZCB3aGVuIHRoZSDigJxpZGVudGlmaWVy4oCdIGlzIHNl bGVjdGVkIGFuZCBhc3NpZ25lZCBieSBhbiBleHRlcm5hbCBlbnRpdHkgKHN1Y2ggYXMgd2l0aCBh IGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uKS4gICBBbmQgdGhlIHVwcGVyIGhhbGYgU0hPVUxEIGJl IHVzZWQgZm9yIHN1YnNjcmlwdGlvbiBpZGVudGlmaWVycyBkeW5hbWljYWxseSBjaG9zZW4gYW5k IGFzc2lnbmVkIGJ5IHRoZSBwdWJsaXNoZXIuDQoNCg0KDQo1LjEpDQoNCmhlcmUgaXQgaXMgd3Jp dHRlbiB0aGF0Og0KDQoiTm90ZSB0aGF0IGlzIHBvc3NpYmxlIHRvIGNvbmZpZ3VyZSByZXBsYXkg b24gYSBjb25maWd1cmVkIHN1YnNjcmlwdGlvbi4iDQoNCkluICA0LjEuMSBpdCBpcyB3cml0dGVu IHRoYXQNCg0KIlJlcGxheSBpcyBvbmx5IHZpYWJsZSBmb3IgZHluYW1pYyBzdWJzY3JpcHRpb25z LiINCg0KT25lIG9mIHRoZSB0d28gc3RhdGVtZW50cyBtdXN0IGJlIGNoYW5nZWQhDQoNCg0KDQo8 RXJpYz4gIFllcywgSSBjYXVnaHQgdGhhdCBlYXJsaWVyLiAgIFRoZSBzZWNvbmQgc2VudGVuY2Ug d2FzIHJlbW92ZWQuDQoNCg0KDQo1LjMpIG1lcmdlIHdpdGggY2hhcHRlciA2DQoNCg0KDQo8RXJp Yz4gIFllcywgZHVwbGljYXRpb24gY2F1Z2h0IGVhcmxpZXIuDQoNCg0KDQo4LjQsIDguNSkNCg0K U3VzcGVuc2lvbnMgYXJlIG5vdGlmaWVkIHRvIHRoZSBzdWJzY3JpYmVyICguLi4pIGFuZCBhbGwg cmVjZWl2ZXJzIC4uLg0KDQpBbHJlYWR5IGRlc2NyaWJlZCBpbiBjaGFwdGVyIDguIFJlbW92ZQ0K DQoNCg0KPEVyaWM+IEkgdGhpbmsgSSBjYXVnaHQgdGhpcyBpbiB0aGUgbGF0ZXN0IHZlcnNpb24u ICBMZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zDQoNCg0KDQoxMCkNCg0KYW55 ZGF0YSBzdWJ0cmVlLWZpbHRlcikgZXZlbnQtZmlsdGVyOiBJcyB0aGlzIGFwcGxpZWQgYWdhaW5z dCB0aGUgZnVsbA0KDQpub3RpZmljYXRpb24gb3IgYWdhaW5zdCBhbiBldmVudC1yZWNvcmQ/DQoN Cg0KDQo8RXJpYz4gQ2hhbmdlZCB0byBzaW5ndWxhciwgbm90IHBsdXJhbC4gIFNvIGl0IGlzIGFw cGxpZWQgYWdhaW5zdCDigJxhbiBpbmRpdmlkdWFsLCBkZWxpbmVhdGVkIGV2ZW50IHJlY29yZOKA nS4gIE5vdGU6DQoNCg0KDQpJdCBpcyBub3QgY2xlYXIhIEEgbm90aWZpY2F0aW9uIG1heSBjb250 YWluIG11bHRpcGxlIGV2ZW50IHJlY29yZHMuDQoNCg0KDQo8RXJpYz4gSSBzZWUgYSBzaW5nbGUg UkZDLTc5NTAgWUFORyBOb3RpZmljYXRpb24gYXMgYmVpbmcgYSBzaW5nbGUgaW5kaXZpc2libGUg cmVjb3JkLiAgQnV0IGEgbm90aWZpY2F0aW9uLW1lc3NhZ2UgKGFzIHBlciBkcmFmdC1pZXRmLW5l dGNvbmYtbm90aWZpY2F0aW9uLW1lc3NhZ2VzKSBhbGxvd2luZyB0aGUgYnVuZGxpbmcgb2YgbXVs dGlwbGUgZXZlbnQgcmVjb3Jkcy4NCg0KDQoNCkluIHRoZSB0d28gY2FzZXMgdGhlIHRvcCBsZXZl bCBlbGVtZW50IHNob3VsZCBiZSBkaWZmZXJlbnQuDQoNCg0KDQo8RXJpYz4gTm90IHN1cmUgaWYg SSBjb3ZlciB0aGlzIHdpdGggb3RoZXIgcmVzcG9uc2VzLiAgTGV0IG1lIGtub3cgaWYgSSBhbSBt aXNzaW5nIHNvbWV0aGluZy4NCg0KDQoNCklmIGFnYWluc3QgdGhlIGV2ZW50IHJlY29yZHMsIGlz IGl0IHRoZSBmdWxsIG5vdGlmaWNhdGlvbiBvciBvbmx5IHRoZQ0KDQppbmRpdmlkdWFsIGV2ZW50 IHJlY29yZCB0aGF0IGlzIG5vdCBzZW50Pw0KDQoNCg0KPEVyaWM+IFBlciBhYm92ZSwgSSB0aGlu ayBhbiBSRkMtNzk1MCBZQU5HIE5vdGlmaWNhdGlvbiBhcyBiZWluZyBhIHNpbmdsZSBpbmRpdmlz aWJsZSByZWNvcmQuICAgQXMgZXZlbnQgc3RyZWFtcyBjYW4gY29tZSB3aXRoIGRpZmZlcmVudCBk ZWxpbmVhdGlvbnMsDQoNCg0KDQpJZiBhbGwgZXZlbnQgcmVjb3JkcyBhcmUgbm90IHNlbnQgdGhl IG5vdGlmaWNhdGlvbnMgc2hhbGwgbm90IGJlIHNlbnQuDQoNCklNSE8gdGhpcyB3b3VsZCBkZXNl cnZlIGEgZmV3IHNlbnRlbmNlcyBzb21ld2hlcmUuDQoNCg0KDQo8RXJpYz4gSSBoYXZlIHB1dCB0 aGUgZm9sbG93aW5nIFllbGxvdyBpbiB0aGUgc3RyZWFtcyBzZWN0aW9uLg0KDQoNCg0KVGhlIE5F VENPTkYgZXZlbnQgc3RyZWFtIGNvbnRhaW5zIGFsbCBORVRDT05GIFhNTCBldmVudCByZWNvcmQg aW5mb3JtYXRpb24gc3VwcG9ydGVkIGJ5IHRoZSBwdWJsaXNoZXIsIGV4Y2VwdCBmb3Igd2hlcmUg aXQgaGFzIGJlZW4gZXhwbGljaXRseSBpbmRpY2F0ZWQgdGhhdCB0aGlzIHRoZSBldmVudCByZWNv cmQgTVVTVCBiZSBleGNsdWRlZCBmcm9tIHRoZSBORVRDT05GIHN0cmVhbS4gIEFuIFtSRkM3OTUw XSBZQU5HIG5vdGlmaWNhdGlvbiB3aWxsIGJlIHNlbnQgdG8gdGhpcyBzdHJlYW0sIGFuZCBlYWNo IHN1Y2ggbm90aWZpY2F0aW9uIE1VU1QgYmUgY29uc2lkZXJlZCBhcyBhIHNpbmdsZSBpbmRpdmlz aWJsZSBldmVudCByZWNvcmQuDQoNCg0KDQpUaGUgc2FtZSBxdWVzdGlvbiBpcyB2YWxpZCBmb3Ig WFBhdGguIFdoaWNoIGlzIHRoZSBjb3JyZWN0IGZvcm1hdD8NCg0KLSAvbm90aWZpY2F0aW9uL215 Tm90aWZpY2F0aW9uL2V2ZW50UmVjb3JkW3R5cGU9J3R5cGVBJ10gICAgb3INCg0KLSAvZXZlbnRS ZWNvcmRbdHlwZT0ndHlwZUEnXQ0KDQoNCg0KPEVyaWM+IEkgcHJlZmVyIHRoZSBmaXJzdC4gIEkg YW0gc3VyZSBzb21lb25lIGNvdWxkIGNyZWF0ZSBzaW1wbGVyIG1vcmUgZ2VuZXJhbGx5IGFwcGxp Y2FibGUgeHBhdGggZXhwcmVzc2lvbnMgd2hpY2ggYWNjb21wbGlzaCB0aGUgc2FtZSB0aGluZy4N Cg0KDQoNCnN0b3AtdGltZSkgIklmIHJlcGxheS1zdGFydC10aW1lIGRvZXNuJ3QgZXhpc3QsIHN0 b3AtdGltZSBtdXN0IGJlIGZvciBhIGZ1dHVyZSB0aW1lLiINCg0KVGhpcyBtYXkgYmUgcmVxdWly ZWQgYXQgc3Vic2NyaXB0aW9uIGVzdGFibGlzaG1lbnQsIGJ1dCBsYXRlciB3aGVuIHRoZQ0KDQpz dWJzY3JpcHRpb24gc3RhdGUgYmVjb21lcyBjb25jbHVkZWQsIHRoaXMgd2lsbCBiZWNvbWUgZmFs c2UuDQoNCg0KDQo8RXJpYz4gSGF2ZSBjaGFuZ2VkIGl0IHRvOiDigJxzdG9wLXRpbWUgKGF0IHRo ZSB0aW1lIGl0IGlzIHNldCkgbXVzdCBiZSAuLi7igJ0NCg0KDQoNCmRlcGVuZGVuY3kgIGJvdGgg c3Vic3RyZWVzKSBzaG91bGRuJ3QgdGhpcyBiZSBhIGxlYWZyZWYgd2l0aCByZXF1aXJlLWluc3Rh bmNlPWZhbHNlPw0KDQoNCg0KPEVyaWM+IEJhc2VkIG9uIHRoZSB3YXkgSFRUUDIgUkZDLTc1NDAg U2VjdGlvbiA1LjMuNCBkb2VzIFFvUywgc3RyZWFtIGRlcGVuZGVuY2llcyBjYW4gYmUgcXVpdGUg dHJhbnNpZW50LiAgICAgV2l0aCBIVFRQMiDigJxkZXBlbmRlbmNpZXMgY2FuIGJlIG1vdmVkIHRv IGJlY29tZSBkZXBlbmRlbnQgb24gdGhlIHBhcmVudCBvZiB0aGUgY2xvc2Vk4oCdIHN1YnNjcmlw dGlvbi4NCg0KDQoNClRyYW5zbGF0aW5nIHRoYXQgdG8gWUFORyBiZWhhdmlvciBpcyBzb21ldGhp bmcgSSBoYXZlIG5vIGlkZWEgaG93IHRvIGRvLiAgIEkuZS4sIGhvdyBkbyB5b3UgZW5jb2RlIHJ1 bGVzIHRoYXQgc2F5IOKAnGlmIGEgc3Vic2NyaXB0aW9uIHdpdGggYSBsZWFmcmVmIHBvaW50aW5n IHRvIGl0IGlzIGJlaW5nIGRlbGV0ZWQ6IHRha2UgaXRzIG93biBkZXBlbmRlbmN5IGxlYWZyZWYg KGlmIGl0IGV4aXN0cykgYW5kIHBsYWNlIGl0IGludG8gdGhlIGxlYWZyZWYgb2YgdGhlIGRlcGVu ZGVudCBzdWJzY3JpcHRpb27igJ0uDQoNCg0KDQpTaW5jZSBJIGRpZG7igJl0IGtub3cgaG93IHRv IGRvIGl0LCBJIGZpZ3VyZWQgaXQgY291bGQgYmUgdXAgdG8gYXBwbGljYXRpb25zIHRvIG1haW50 YWluIHRoYXQgZGVwZW5kZW5jeSB0cmVlLiAgSWYgc29tZW9uZSBoYXMgYW5vdGhlciBwcm9wb3Nh bCB3aGljaCBjYW4ga2VlcCB1cCB3aXRoIHN1YnNjcmlwdGlvbnMgaW4tZmxpZ2h0LCBJIHdvdWxk IGJlIHZlcnkgaW50ZXJlc3RlZC4NCg0KDQoNCi9zdWJzY3JpcHRpb24tY29uZmlnL3N1YnNjcmlw dGlvbi9zbjpzdHJlYW0gYW5kDQoNCi9zdWJzY3JpcHRpb25zL3N1YnNjcmlwdGlvbi9zbjpzdHJl YW0gYW5kDQoNCi9lc3RhYmxpc2gtc3Vic2NyaXB0aW9uL2lucHV0L3NuOnN0cmVhbSkgc2hvdWxk bid0IHRoZXNlIGJlIGEgbGVhZnJlZnMNCg0KDQoNCjxFcmljPiBBbGV4IGFuZCBJIGNoYXR0ZWQg YWJvdXQgdGhpcyBwcmV2aW91c2x5LiAgIEl0IGlzIGZpbmUgZWl0aGVyIHdheS4gIEJ1dCBhcyB5 b3UgcHJlZmVyIGxlYWZyZWYsIEkgaGF2ZSBjaGFuZ2VkIGl0IHRvIHRoYXQuICBUaGlzIG1ha2Vz IGl0IGNvbnNpc3RlbnQgd2l0aCB0aGUgd2F5IFZSRnMgYXJlIG5vdyByZWZlcmVuY2VkLg0KDQoN Cg0KMTEpDQoNCnMvb3Igbm9yIHN1YnNjcmliZWQvb3Igc3Vic2NyaWJlZC8NCg0KDQoNCjxFcmlj PiBGaXhlZC4NCg0KDQoNCg0KDQoxMS4yKQ0KDQoiQSBwdWJsaXNoZXIgTVVTVCBOT1QgaW5jbHVk ZSBhbnkgY29udGVudCBpbiBhIG5vdGlmaWNhdGlvbiBtZXNzYWdlDQoNCiAgIGZvciB3aGljaCB0 aGUgdXNlciBoYXMgbm90IGJlZW4gYXV0aG9yaXplZC4iDQoNCkNsYXJpZnkgaWYgdGhlIHVzZXIg aXMgdGhlIHN1YnNjcmliZXIgb3IgdGhlIHJlY2VpdmVyLg0KDQoNCg0KPEVyaWM+IFVwZGF0ZWQg dG8gcmVjZWl2ZXIgaW4gdGhhdCBzZWN0aW9uIGEgZmV3IHRpbWVzLg0KDQoNCg0KIlN1YnNjcmli ZXJzIHRoYXQgZG8gbm90IHdhbnQgbm90aWZpY2F0aW9uIG1lc3NhZ2VzIG5lZWQgb25seSB0ZXJt aW5hdGUgb3IgcmVmdXNlDQoNCmFueSB0cmFuc3BvcnQgc2Vzc2lvbnMgZnJvbSB0aGUgcHVibGlz aGVyLiINCg0KSU1ITyB0aGUgZmlyc3Qgd29yZCBzaG91bGQgYmUgcmVjZWl2ZXJzLg0KDQoNCg0K PEVyaWM+IEZpeGVkLg0KDQoNCg0KQWxzbyBpbiB0aGUgY2FzZSBvZiBhIGNvbmZpZ3VyZWQgc3Vi c2NyaXB0aW9uIGNhbiB3ZSBnZXQgaW50byBhIGN5Y2xlPw0KDQotIHB1Ymxpc2hlciB0cmllcyB0 byBzZW5kIGEgbm90aWZpY2F0aW9uDQoNCi0gcmVjZWl2ZXIgcmVjZWl2ZXMgYSBub3RpZmljYXRp b24gaXQgZG9lcyBub3Qgd2FudA0KDQotIHJlY2VpdmVyIGNsb3NlcyB0cmFuc3BvcnQgc2Vzc2lv bg0KDQotIHN0YXJ0IGZyb20gdGhlIHRvcA0KDQoNCg0KPEVyaWM+ICBUaGlzIGNhbiBiZSB0aGUg Y2FzZSwgYnV0IGl0IGlzIGF2b2lkYWJsZS4gICBJdCBpcyB1cCB0byB0aGUgdHJhbnNwb3J0IGRv Y3VtZW50cyB0byBkZWZpbmUgaG93IHRvIGF2b2lkIHRoYXQgbG9vcC4gIE9mIGNvdXJzZSB0aGVy ZSBhcmUgbW9yZSBncmFudWxhciBtZWNoYW5pc21zIGF2YWlsYWJsZSBmb3IgZml4aW5nIHRoaXMg d2l0aCB0cmFuc3BvcnRzIHZzLiBvdGhlcnMuICAgVGhpcyBpcyBvbmUgcGxhY2Ugd2hlcmUgSFRU UDIgaGFzIGEgcmVhbCBhZHZhbnRhZ2UuDQoNCg0KDQpGb3IgTkVUQ09ORiwgeW91IG9ubHkgbWFu YWdlIHRoZSBvbmUgdHJhbnNwb3J0IHNlc3Npb24gYmV0d2VlbiBwdWJsaXNoZXIgYW5kIHJlY2Vp dmVyLCBhbmQgdGhlcmUgYXJlIG5vdCB2ZXJ5IGdyYW51bGFyIG9wdGlvbnMuICAgUmVsZXZhbnQg dGV4dCBpbiBkcmFmdC1pZXRmLW5ldGNvbmYtbmV0Y29uZi1ldmVudC1ub3RpZmljYXRpb25zIHNh eXM6DQoNCg0KDQogIOKAnElmIHRoZSBjYWxsIGhvbWUgZmFpbHMgdG8gZXN0YWJsaXNoIGZvciBh bnkgb3RoZXIgcmVhc29uLCB0aGUNCg0KICAgcHVibGlzaGVyIE1BWSBsZWF2ZSB0aGUgcmVjZWl2 ZXIgaW4gYSAiY29ubmVjdGluZyIgc3RhdHVzLCBhbmQgcmV0cnkNCg0KICAgdGhlIGNhbGwgaG9t ZSBhdCBhIGZ1dHVyZSB0aW1lLiAgQWx0ZXJuYXRpdmVseSwgdGhlIHB1Ymxpc2hlciBNQVkNCg0K ICAgcGxhY2UgdGhlIHJlY2VpdmVyIGludG8gYSAic3VzcGVuZGVkIiBzdGF0dXMgYWZ0ZXIgYSBw cmVkZXRlcm1pbmVkDQoNCiAgICAgbnVtYmVyIG9mIGNhbGwgaG9tZSBhdHRlbXB0cy7igJ0NCg0K DQoNClBlcmhhcHMgdGhpcyBjb3VsZCBiZSB0d2Vha2VkIHRvIHNheToNCg0KDQoNCiAg4oCcSWYg dGhlIGNhbGwgaG9tZSBmYWlscyB0byBlc3RhYmxpc2ggZm9yIGFueSBvdGhlciByZWFzb24sIHRo ZQ0KDQogICBwdWJsaXNoZXIgTUFZIGxlYXZlIHRoZSByZWNlaXZlciBpbiBhICJjb25uZWN0aW5n IiBzdGF0dXMsIGFuZCByZXRyeQ0KDQogICB0aGUgY2FsbCBob21lIGF0IGEgZnV0dXJlIHRpbWUu ICBBZGRpdGlvbmFsbHksIHRoZSBwdWJsaXNoZXIgU0hPVUxEDQoNCiAgIHBsYWNlIHRoZSByZWNl aXZlciBpbnRvIGEgInN1c3BlbmRlZCIgc3RhdHVzIGFmdGVyIGEgcHJlZGV0ZXJtaW5lZA0KDQog ICAgIG51bWJlciBvZiBlaXRoZXIgZmFpbGVkIGNhbGwgaG9tZSBhdHRlbXB0cyBvciBORVRDT05G IHNlc3Npb25zIHJlbW90ZWx5IHRlcm1pbmF0ZWQgYnkgdGhlIHJlY2VpdmVyLuKAnQ0KDQoNCg0K V291bGQgdGhpcyB3b3JrIGZvciB5b3U/DQoNCg0KRXJpYw0KDQoNCg0KDQoNCkJhbGF6cyBMZW5n eWVsICAgICAgICAgICAgICAgICAgICAgICBFcmljc3NvbiBIdW5nYXJ5IEx0ZC4NCg0KU2VuaW9y IFNwZWNpYWxpc3QNCg0KTW9iaWxlOiArMzYtNzAtMzMwLTc5MDkgICAgICAgICAgICAgIGVtYWls OiBCYWxhenMuTGVuZ3llbEBlcmljc3Nvbi5jb208bWFpbHRvOkJhbGF6cy5MZW5neWVsQGVyaWNz c29uLmNvbT4NCg== --_000_324be64174484ddca5a8b19b358b95e1XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAy IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpwLm1zb25vcm1hbDAs IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h bDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNr O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJs YWNrO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPkhpIEJhbGF6 cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPlRoYW5rcyBmb3Ig dGhlIGNvbW1lbnRzLiZuYnNwOyBJbi1saW5lLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6d2luZG93dGV4dCI+IEJhbGF6cyBMZW5neWVsLCBEZWNlbWJlciA0LCAyMDE3IDExOjE1 IEFNPGJyPg0KPGI+VG86PC9iPiBuZXRjb25mQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFtOZXRjb25mXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLW5ldGNvbmYtc3Vic2NyaWJlZC1ub3Rp ZmljYXRpb25zLTA3PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+SGVsbG8sPG86cD48L286 cD48L3A+DQo8cD5Tb3JyeSBpZiBzb21lIG9mIHRoZSBjb21tZW50cyBhcmUgYWxyZWFkeSByZXNv bHZlZC4gSSBkaWQgbm90IGhhdmUgdGltZSB0byBzY2FuIHRocm91Z2ggYWxsIHRoZSBtYWlscy48 bzpwPjwvbzpwPjwvcD4NCjxwPjEuMyk8bzpwPjwvbzpwPjwvcD4NCjxwPlNob3VsZCB3ZSBmb3Jt YWxseSBzdGF0ZSBzb21lIHRyYW5zcG9ydCByZXF1aXJlbWVudHM/IDxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0Ij4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPlRoaXMgY2hhcHRlciBz ZWVtcyB0byBhc3N1bWU6PGJyPg0KLSB0cmFuc3BvcnQgaXMgZWl0aGVyIGNvbm5lY3Rpb24tb3Jp ZW50ZWQgYW5kIHJlbGlhYmxlPGJyPg0KLSBvciBjb25uZWN0aW9ubGVzcy9zdGF0ZWxlc3MsIGJ1 dCBoYXMgYWNrbm93bGVkZ2VtZW50IGZvciB0aGUgbm90aWZpY2F0aW9uczxicj4NCnNvIHRoZSBw dWJsaXNoZXIgY2FuIGRldGVybWluZSB3aGV0aGVyIHRoZSByZWNlaXZlciBhY3R1YWxseSBnb3Qg dGhlIG5vdGlmaWNhdGlvbiBvciBub3QuPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu LWxlZnQ6NC44cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj4mbHQ7ZXJpYyZndDsg VGhlcmUgaXMgbm8gZXhwbGljaXQgcmVxdWlyZW1lbnRzIHRoYXQgU3Vic2NyaWJlZCBub3RpZmlj YXRpb25zIG11c3QgYmUgdXNlZCB3aXRoIHNvbWUgZm9ybSBvZiBhY2tub3dsZWRnZW1lbnQuJm5i c3A7ICZuYnNwO0FuZCB3aXRoIE5FVENPTkYsIFJFU1RDT05GLCBIVFRQMiwNCiBhbmQgVURQIHRy YW5zcG9ydCBkcmFmdHMgYWxyZWFkeSBhZG9wdGVkIGJ5IHRoZSBXRywgdGhlIG1ham9yaXR5IG9m IHRoZSB0cmFuc3BvcnQgcmVxdWlyZW1lbnRzIGFyZSB0aGVyZS4mbmJzcDsgSXMgdGhlcmUgYW55 dGhpbmcgc3BlY2lmaWMgeW91IGRvbuKAmXQgc2VlIHdoaWNoIGNhbiBiZSBjYWxsZWQgb3V0Pzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxpPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+JnF1b3Q7VGhlIGxpZmV0aW1lIG9mIGEgY29uZmln dXJlZCZuYnNwOyBzdWJzY3JpcHRpb24gaXMgZHJpdmVuIGJ5IHJlbGV2YW50DQo8YnI+DQpjb25m aWd1cmF0aW9uIGJlaW5nIHByZXNlbnQgb24gdGhlIHJ1bm5pbmcgY29uZmlndXJhdGlvbi4mcXVv dDs8L3NwYW4+PC9pPjxicj4NCklzIGl0IHJlYWxseSB0aGUgJnF1b3Q7cnVubmluZyZxdW90OyBj b25maWc/IElNSE8gaXQgc2hvdWxkIGJlIHRoZSBvcGVyYXRpb25hbC4gPG86cD48L286cD48L3A+ DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Jmx0O2VyaWMmZ3Q7IEkgYmVsaWV2 ZSBydW5uaW5nIGlzIGNvcnJlY3QuJm5ic3A7Jm5ic3A7IEkgYmVsaWV2ZSBzdWNoIGEgc3Vic2Ny aXB0aW9uIGFsaXZlIGlmIGl0IGNhbiBiZSBzZWVuIG9uIHRoZSBzeXN0ZW0sIGV2ZW4gaWYgbm8g cmVjZWl2ZXJzIGFyZSBhY3RpdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZT48aT4mcXVv dDtEeW5hbWljIHN1YnNjcmlwdGlvbnMgY2FuIG9ubHkgYmUgbW9kaWZpZWQgdmlhIGFuIFJQQyBy ZXF1ZXN0IDxvOnA+PC9vOnA+PC9pPjwvcHJlPg0KPHByZT48aT5tYWRlIHVwb24gdGhlIG9yaWdp bmFsIHN1YnNjcmliaW5nIHRyYW5zcG9ydCBzZXNzaW9uLiZxdW90OzwvaT48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5Ib3cgZG9lcyB0aGlzIHdvcmsgaW4gY2FzZSBvZiBSZXN0Y29uZj8gVGhlIHRy YW5zcG9ydCBzZXNzaW9uIGNhbiBiZSB2ZXJ5IGJyaWVmLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5TaG91bGRuJ3Qgd2UgZGlzY3VzcyByZXN0Y29uZiBhbmQgJnF1b3Q7c2FtZSB0cmFuc3BvcnQg c2Vzc2lvbiZxdW90OyBnZW5lcmFsbHkgc29tZXdoZXJlPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMzVwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMwMDcwQzAiPiZsdDtFcmljJmd0OyBZZXMsIGlkZW50aWZpY2F0aW9uIG9mIHRoZSBz YW1lIHRyYW5zcG9ydCBzZXNzaW9uIGF0IGEgaGlnaCBsZXZlbCBiZWNvbWVzIHRyaWNreSBmb3Ig Y29ubmVjdGlvbmxlc3MgdHJhbnNwb3J0LiAmbmJzcDtBdCBhIG1pbmltdW0sIHRoZSBwcm9wZXIg bGlmZWN5Y2xlIGFsd2F5cyBuZWVkcyB0byBiZSBkZXRlcm1pbmVkL2luY2x1ZGVkIGluIHRoZSB0 cmFuc3BvcnQgZHJhZnRzLiZuYnNwOyBGb3IgUkVTVENPTkYsIGluIGRyYWZ0LWlldGYtbmV0Y29u Zi1yZXN0Y29uZi1ub3RpZiB0aGVyZSBpcyBBcHBlbmRpeCBBLjIgd2hpY2ggZGVzY3JpYmVzIGhv dyB0byBoYW5kbGUgdGhpcyB3aXRoIGEgVExTIEhlYXJ0YmVhdC4mbmJzcDsgSW4gbGlldSBvZiB0 aGF0IG9wdGltaXphdGlvbiwgYSBUQ1AgY29ubmVjdGlvbiBpbml0aWF0ZWQgZnJvbSB0aGUgcmVj ZWl2ZXIgd2hpY2ggaXMgbG9zdCB3aWxsIGF0IHNvbWUgcG9pbnQgYmUgcmVjb2duaXplZCBieSB0 aGUgcHVibGlzaGVyIChlLmcuLCBzZWUgZmxvd3MgaW4gc2VjdGlvbnMgMy4xKS4mbmJzcDsgJm5i c3A7Jm5ic3A7Q29taW5nIGJhY2sgdG8gc3Vic2NyaWJlZC1ub3RpZmljYXRpb25zLCB3aGF0IGlm IEkganVzdCBzYXkg4oCcLi4uYW4gUlBDIHJlcXVlc3QgbWFkZSBmcm9tIHRoZSBvcmlnaW5hbCBz dWJzY3JpYmVy4oCdPzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT4yLjIpPG86cD48L286cD48L3ByZT4NCjxwcmU+PGk+JnF1b3Q7QSBz dWJzZXQgb2YgaW5mb3JtYXRpb24gaXMgbmV2ZXIgc3RyaXBwZWQgZnJvbSB3aXRoaW4gdGhlIGV2 ZW50IHJlY29yZC4mcXVvdDs8L2k+IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkkgZG9uJ3QgZnVs bHkgdW5kZXJzdGFuZCB0aGlzLiBNYXliZSByZXdvcmQgaXQgdG88bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mcXVvdDtBIGZpbHRlciBhbHdheXMgcmVtb3ZlcyBhIGNvbXBsZXRlIGV2ZW50IHJlY29y ZDsgYSBzdWJzZXQgb2YgPG86cD48L286cD48L3ByZT4NCjxwcmU+aW5mb3JtYXRpb24gaXMgbmV2 ZXIgc3RyaXBwZWQgZnJvbSBhbiBldmVudCByZWNvcmQuICZxdW90OzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiZs dDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPkVyaWMmZ3Q7IENoYW5nZSBt YWRlLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPklmIGEgZmls dGVyIHJlbW92ZXMgMiBvdXQgb2YgMyBldmVudCByZWNvcmRzIHdpbGwgdGhlIG5vdGlmaWNhdGlv biBzdGlsbCBiZSBzZW50PyBJcyB0aGF0IGEgcmVhbGlzdGljIHNpdHVhdGlvbj88bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj4m bHQ7RXJpYyZndDsgQXMgZWFjaCBub3RpZmljYXRpb24gd291bGQgYmUgaXRzIG93biBldmVudCBy ZWNvcmQsIHllcyBhbmQgeWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjIuMyk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5GaWd1cmUgMSkgSU1ITyBhIHN0YXRl IHRyYW5zaXRpb24gZnJvbSBzdXNwZW5kZWQgdG8gc3VzcGVuZGVkIG9uIG1vZGlmeS1zdWJzY3Jp cHRpb24gaXMgbWlzc2luZy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZT5UaGUgc3RhdGUgZGlhZ3JhbSBmb3IgY29uZmlndXJlZCBzdWJzY3JpcHRp b25zIGlzIG5vdCByZWFsbHkgY2xlYXIuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0gZG9lcyB0 aGUgc3Vic2NyaXB0aW9uIGhhdmUgYSBzdGF0ZS9zdGF0ZS1tYWNoaW5lIG9yIHRoZSBpbmRpdmlk dWFsIHJlY2VpdmVycz8gPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhlIG1vZGVsIHN1Z2dlc3Qg aXRzIHRoZSByZWNlaXZlcnMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Jmx0O0VyaWMmZ3Q7IFllcywgaXQgaXMgcGVy LXJlY2VpdmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPi0g dGhlIGRlc2NyaWJlZCBzdGF0ZXMgZG8gbm90IGNvcnJlc3BvbmQgdG8gdGhlIHN0YXRlcyBkZWZp bmVkIGluIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi9zbjpzdWJzY3JpcHRpb25zL3NuOnN1YnNj cmlwdGlvbi9zbjpyZWNlaXZlcnMvc246cmVjZWl2ZXIvc246c3RhdHVzPG86cD48L286cD48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Jmx0 O0VyaWMmZ3Q7IEFzIHNob3duIG5vdywgdGhlIHN0YXRlIG1hY2hpbmUgcmVmbGVjdHMgdGhlIHZp ZXcgb2YgdGhlIHJlY2VpdmVyIGNvbm5lY3Rpb24gZnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0 aGUgcmVjZWl2ZXIuJm5ic3A7IEkuZS4sIHRoZSByZWNlaXZlciBpcyBub3QgYXV0b21hdGljYWxs eSBzZW50IGFsbCBhc3BlY3RzIG9mIGludGVybmFsIHN0YXRlIHdoaWNoIG5lZWQgdG8gYmUgcmVw b3J0YWJsZSB0byBhIHB1Ymxpc2hlcuKAmXMgb3BlcmF0b3Igd2hvIGlzIG1hbmFnaW5nIHRoaXMg c3Vic2NyaXB0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwNzBDMCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj5UaGF0IHNhaWQsIHlvdSBhcmUgY29ycmVjdCB0 aGF0IGFuIGVhc3kgbWFwcGluZyBiZXR3ZWVuIHRoZSB0d28gd291bGQgYmUgdXNlZnVsLiZuYnNw OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwNzBDMCI+SWYgSSBjaGFuZ2Ug4oCcY3JlYXRl4oCdIHRvIOKAnGNvbmZpZ3Vy YXRpb24gb3BlcmF0aW9u4oCdICwgYW5kIG1ha2UgdGhlIGZvbGxvd2luZyBjaGFuZ2UgdG8gdGhl IGJvdHRvbSBvZiB0aGUgZGlhZ3JhbSwgdGhlbiB0aGUgZGlhZ3JhbSBjYW4gYWNjb21wbGlzaCBi b3RoIGludGVybmFsIHN0YXRlcywgYW5kIHN0YXRlczo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwNzBDMCI+IDxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtj b2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsnLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTAuMTVwdCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO3wmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7fCAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjM1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2NvbG9yOiMwMDcwQzAiPiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtTdG9wLXRpbWU6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O2Vycm9yOiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtjb25maWcgZGVsZXRlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6NS4zNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg c3Vic2NyaXB0aW9uLSAmbmJzcDsmbmJzcDtzdWJzY3JpcHRpb24tICZuYnNwOyZuYnNwO3N1YnNj cmlwdGlvbi08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjUuMzVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwNzBDMCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbXBsZXRlZCAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0ZXJtaW5hdGVkICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO3Rlcm1pbmF0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMzVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjM1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBWICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO1YmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4zNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Li0tLS0tLS0tLS0tLiZuYnNwOyZuYnNwOyAmbmJzcDsuLS0tLS0tLS0tLS4mbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Li0tLS0tLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6NS4zNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MDA3MEMwIj4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCBjb25jbHVkZWQg fCZuYnNwOyAmbmJzcDsmbmJzcDt8IGluLWVycm9yIHwmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 fCBlbmQgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 MTAuMTVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzAwNzBDMCI+Jm5i c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyctLS0tLS0tLS0tLScmbmJzcDsmbmJzcDsgJm5i c3A7Jy0tLS0tLS0tLS0nICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyctLS0tLScmbmJzcDsgJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3 aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDcwQzAiPldoYXQgZG8geW91IHRoaW5rPzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPi0gYnVmZmVyIG92ZXJmbG93IGlzIG1lbnRpb25l ZC4gSXMgaXQgYW4gb3ZlcmZsb3cgYXQgdGhlIHJlY2VpdmVyIG9yIHRoZSBwdWJsaXNoZXI/PG86 cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwNzBDMCI+Jmx0O0VyaWMmZ3Q7IFB1Ymxpc2hlci4mbmJzcDsmbmJzcDsgSGF2ZSBjaGFuZ2Vk IHRoZSB0ZXh0IHRvIHRoZSDigJxhIHB1Ymxpc2hlciBidWZmZXIgb3ZlcmZsb3figJ0uPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjQu MS4xKSBzL2EgZXZlbnQvYW4gZXZlbnQvPG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Jmx0O0VyaWMmZ3Q7IEZpeGVkPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PjQuNCkgcy9hc3NvY2lhdGVkIHRoZSB0cmFuc3BvcnQvYXNzb2NpYXRlZCB3aXRoIHRoZSB0cmFu c3BvcnQvPG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRv d3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwNzBDMCI+Jmx0O0VyaWMmZ3Q7IEZpeGVkPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+NSkg M3JkIHNlbnRlbmNlIHJld29yZCE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj4mbHQ7RXJpYyZndDsgSG93IGFib3V0Ojxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBD MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDA3MEMwIj5UaGUgbG93ZXIgaGFsZiB0aGUg4oCcaWRlbnRpZmllcuKAnSBvYmplY3Qg aW4gdGhlIHN1YnNjcmlwdGlvbnMgY29udGFpbmVyIFNIT1VMRCBiZSB1c2VkIHdoZW4gdGhlIOKA nGlkZW50aWZpZXLigJ0gaXMgc2VsZWN0ZWQgYW5kIGFzc2lnbmVkIGJ5IGFuIGV4dGVybmFsIGVu dGl0eSAoc3VjaCBhcyB3aXRoIGEgY29uZmlndXJlZCBzdWJzY3JpcHRpb24pLiZuYnNwOyZuYnNw OyBBbmQgdGhlIHVwcGVyIGhhbGYgU0hPVUxEIGJlIHVzZWQgZm9yIHN1YnNjcmlwdGlvbiBpZGVu dGlmaWVycyBkeW5hbWljYWxseSBjaG9zZW4gYW5kIGFzc2lnbmVkIGJ5IHRoZSBwdWJsaXNoZXIu PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlPjUuMSkgPG86cD48L286cD48L3ByZT4NCjxwcmU+aGVyZSBpdCBpcyB3cml0dGVuIHRoYXQ6 PG86cD48L286cD48L3ByZT4NCjxwcmU+JnF1b3Q7Tm90ZSB0aGF0IGlzIHBvc3NpYmxlIHRvIGNv bmZpZ3VyZSByZXBsYXkgb24gYSBjb25maWd1cmVkIHN1YnNjcmlwdGlvbi4mcXVvdDs8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5JbiZuYnNwOyA0LjEuMSBpdCBpcyB3cml0dGVuIHRoYXQ8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mcXVvdDtSZXBsYXkgaXMgb25seSB2aWFibGUgZm9yIGR5bmFtaWMg c3Vic2NyaXB0aW9ucy4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5PbmUgb2YgdGhlIHR3 byBzdGF0ZW1lbnRzIG11c3QgYmUgY2hhbmdlZCE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj4mbHQ7RXJpYyZndDsmbmJz cDsgWWVzLCBJIGNhdWdodCB0aGF0IGVhcmxpZXIuJm5ic3A7Jm5ic3A7IFRoZSBzZWNvbmQgc2Vu dGVuY2Ugd2FzIHJlbW92ZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlPjUuMykgbWVyZ2Ugd2l0aCBjaGFwdGVyIDY8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMw Ij4mbHQ7RXJpYyZndDsmbmJzcDsgWWVzLCBkdXBsaWNhdGlvbiBjYXVnaHQgZWFybGllci4mbmJz cDsmbmJzcDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+OC40 LCA4LjUpIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlN1c3BlbnNpb25zIGFyZSBub3RpZmllZCB0 byB0aGUgc3Vic2NyaWJlciAoLi4uKSBhbmQgYWxsIHJlY2VpdmVycyAuLi48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5BbHJlYWR5IGRlc2NyaWJlZCBpbiBjaGFwdGVyIDguIFJlbW92ZTxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcw QzAiPiZsdDtFcmljJmd0OyBJIHRoaW5rIEkgY2F1Z2h0IHRoaXMgaW4gdGhlIGxhdGVzdCB2ZXJz aW9uLiZuYnNwOyBMZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBhbnkgcXVlc3Rpb25zPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjEwKTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFueWRhdGEgc3VidHJlZS1maWx0ZXIpIGV2ZW50LWZpbHRl cjogSXMgdGhpcyBhcHBsaWVkIGFnYWluc3QgdGhlIGZ1bGwgPG86cD48L286cD48L3ByZT4NCjxw cmU+bm90aWZpY2F0aW9uIG9yIGFnYWluc3QgYW4gZXZlbnQtcmVjb3JkPyA8c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dCI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPiZsdDtFcmljJmd0OyBDaGFuZ2Vk IHRvIHNpbmd1bGFyLCBub3QgcGx1cmFsLiZuYnNwOyBTbyBpdCBpcyBhcHBsaWVkIGFnYWluc3Qg 4oCcYW4gaW5kaXZpZHVhbCwgZGVsaW5lYXRlZCBldmVudCByZWNvcmTigJ0uJm5ic3A7IE5vdGU6 IDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2lu ZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPkl0IGlzIG5vdCBj bGVhciEgQSBub3RpZmljYXRpb24gbWF5IGNvbnRhaW4gbXVsdGlwbGUgZXZlbnQgcmVjb3Jkcy4g PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwNzBDMCI+Jmx0O0VyaWMmZ3Q7IEkgc2VlIGEgc2luZ2xlIFJGQy03OTUwIFlBTkcgTm90 aWZpY2F0aW9uIGFzIGJlaW5nIGEgc2luZ2xlIGluZGl2aXNpYmxlIHJlY29yZC4mbmJzcDsgQnV0 IGEgbm90aWZpY2F0aW9uLW1lc3NhZ2UgKGFzIHBlciBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZp Y2F0aW9uLW1lc3NhZ2VzKSBhbGxvd2luZyB0aGUgYnVuZGxpbmcgb2YgbXVsdGlwbGUgZXZlbnQg cmVjb3Jkcy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPkluIHRoZSB0d28gY2FzZXMgdGhlIHRv cCBsZXZlbCBlbGVtZW50IHNob3VsZCBiZSBkaWZmZXJlbnQuIDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPiZsdDtFcmljJmd0 OyBOb3Qgc3VyZSBpZiBJIGNvdmVyIHRoaXMgd2l0aCBvdGhlciByZXNwb25zZXMuJm5ic3A7IExl dCBtZSBrbm93IGlmIEkgYW0gbWlzc2luZyBzb21ldGhpbmcuPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+SWYgYWdhaW5zdCB0aGUgZXZlbnQgcmVjb3JkcywgaXMg aXQgdGhlIGZ1bGwgbm90aWZpY2F0aW9uIG9yIG9ubHkgdGhlIDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPmluZGl2aWR1YWwgZXZlbnQgcmVjb3JkIHRoYXQgaXMgbm90IHNlbnQ/IDxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Jmx0O0VyaWMmZ3Q7IFBlciBh Ym92ZSwgSSB0aGluayBhbiBSRkMtNzk1MCBZQU5HIE5vdGlmaWNhdGlvbiBhcyBiZWluZyBhIHNp bmdsZSBpbmRpdmlzaWJsZSByZWNvcmQuJm5ic3A7Jm5ic3A7IEFzIGV2ZW50IHN0cmVhbXMgY2Fu IGNvbWUgd2l0aCBkaWZmZXJlbnQgZGVsaW5lYXRpb25zLCA8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOndpbmRvd3RleHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPklmIGFsbCBldmVudCByZWNvcmRzIGFyZSBub3Qgc2VudCB0aGUgbm90aWZpY2F0aW9u cyBzaGFsbCBub3QgYmUgc2VudC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JTUhPIHRoaXMgd291 bGQgZGVzZXJ2ZSBhIGZldyBzZW50ZW5jZXMgc29tZXdoZXJlLiA8c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dCI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPiZsdDtFcmljJmd0OyBJIGhhdmUgcHV0IHRo ZSBmb2xsb3dpbmcgWWVsbG93IGluIHRoZSBzdHJlYW1zIHNlY3Rpb24uPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcw QzAiPlRoZSBORVRDT05GIGV2ZW50IHN0cmVhbSBjb250YWlucyBhbGwgTkVUQ09ORiBYTUwgZXZl bnQgcmVjb3JkIGluZm9ybWF0aW9uIHN1cHBvcnRlZCBieSB0aGUgcHVibGlzaGVyLCBleGNlcHQg Zm9yIHdoZXJlIGl0IGhhcyBiZWVuIGV4cGxpY2l0bHkgaW5kaWNhdGVkIHRoYXQgdGhpcyB0aGUg ZXZlbnQgcmVjb3JkIE1VU1QgYmUgZXhjbHVkZWQgZnJvbSB0aGUgTkVUQ09ORiBzdHJlYW0uJm5i c3A7IDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+ QW4gW1JGQzc5NTBdIFlBTkcgbm90aWZpY2F0aW9uIHdpbGwgYmUgc2VudCB0byB0aGlzIHN0cmVh bSwgYW5kIGVhY2ggc3VjaCBub3RpZmljYXRpb24gTVVTVCBiZSBjb25zaWRlcmVkIGFzIGEgc2lu Z2xlIGluZGl2aXNpYmxlIGV2ZW50IHJlY29yZDwvc3Bhbj4uPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+VGhlIHNhbWUgcXVlc3Rpb24gaXMgdmFsaWQgZm9yIFhQ YXRoLiBXaGljaCBpcyB0aGUgY29ycmVjdCBmb3JtYXQ/PG86cD48L286cD48L3ByZT4NCjxwcmU+ LSAvbm90aWZpY2F0aW9uL215Tm90aWZpY2F0aW9uL2V2ZW50UmVjb3JkW3R5cGU9J3R5cGVBJ10m bmJzcDsmbmJzcDsmbmJzcDsgb3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tIC9ldmVudFJlY29y ZFt0eXBlPSd0eXBlQSddPG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Jmx0O0VyaWMmZ3Q7IEkgcHJlZmVyIHRoZSBmaXJzdC4m bmJzcDsgSSBhbSBzdXJlIHNvbWVvbmUgY291bGQgY3JlYXRlIHNpbXBsZXIgbW9yZSBnZW5lcmFs bHkgYXBwbGljYWJsZSB4cGF0aCBleHByZXNzaW9ucyB3aGljaCBhY2NvbXBsaXNoIHRoZSBzYW1l IHRoaW5nLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+c3RvcC10aW1lKSAmcXVvdDtJZiBy ZXBsYXktc3RhcnQtdGltZSBkb2Vzbid0IGV4aXN0LCBzdG9wLXRpbWUgbXVzdCBiZSBmb3IgYSBm dXR1cmUgdGltZS4mcXVvdDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhpcyBtYXkgYmUgcmVx dWlyZWQgYXQgc3Vic2NyaXB0aW9uIGVzdGFibGlzaG1lbnQsIGJ1dCBsYXRlciB3aGVuIHRoZSA8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zdWJzY3JpcHRpb24gc3RhdGUgYmVjb21lcyBjb25jbHVk ZWQsIHRoaXMgd2lsbCBiZWNvbWUgZmFsc2UuPG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Jmx0O0VyaWMmZ3Q7IEhhdmUgY2hh bmdlZCBpdCB0bzog4oCcc3RvcC10aW1lIChhdCB0aGUgdGltZSBpdCBpcyBzZXQpIG11c3QgYmUg Li4u4oCdPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ZGVwZW5k ZW5jeSZuYnNwOyBib3RoIHN1YnN0cmVlcykgc2hvdWxkbid0IHRoaXMgYmUgYSBsZWFmcmVmIHdp dGggcmVxdWlyZS1pbnN0YW5jZT1mYWxzZT88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjM1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MDA3MEMwIj4mbHQ7RXJpYyZndDsgQmFzZWQgb24gdGhlIHdheSBIVFRQMiBSRkMtNzU0MCBTZWN0 aW9uIDUuMy40IGRvZXMgUW9TLCBzdHJlYW0gZGVwZW5kZW5jaWVzIGNhbiBiZSBxdWl0ZSB0cmFu c2llbnQuJm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwO1dpdGggSFRUUDIg4oCcZGVwZW5kZW5jaWVz IGNhbiBiZSBtb3ZlZCB0byBiZWNvbWUgZGVwZW5kZW50IG9uIHRoZSBwYXJlbnQgb2YgdGhlIGNs b3NlZOKAnSBzdWJzY3JpcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPlRyYW5zbGF0aW5nIHRoYXQgdG8g WUFORyBiZWhhdmlvciBpcyBzb21ldGhpbmcgSSBoYXZlIG5vIGlkZWEgaG93IHRvIGRvLiZuYnNw OyZuYnNwOyBJLmUuLCBob3cgZG8geW91IGVuY29kZSBydWxlcyB0aGF0IHNheSDigJxpZiBhIHN1 YnNjcmlwdGlvbiB3aXRoIGEgbGVhZnJlZiBwb2ludGluZyB0byBpdCBpcyBiZWluZyBkZWxldGVk OiB0YWtlIGl0cyBvd24gZGVwZW5kZW5jeSBsZWFmcmVmIChpZiBpdCBleGlzdHMpIGFuZCBwbGFj ZSBpdCBpbnRvIHRoZSBsZWFmcmVmIG9mIHRoZSBkZXBlbmRlbnQgc3Vic2NyaXB0aW9u4oCdLiZu YnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzAwNzBDMCI+U2luY2UgSSBkaWRu4oCZdCBrbm93IGhvdyB0byBkbyBpdCwg SSBmaWd1cmVkIGl0IGNvdWxkIGJlIHVwIHRvIGFwcGxpY2F0aW9ucyB0byBtYWludGFpbiB0aGF0 IGRlcGVuZGVuY3kgdHJlZS4mbmJzcDsgSWYgc29tZW9uZSBoYXMgYW5vdGhlciBwcm9wb3NhbCB3 aGljaCBjYW4ga2VlcCB1cCB3aXRoIHN1YnNjcmlwdGlvbnMgaW4tZmxpZ2h0LCBJIHdvdWxkIGJl IHZlcnkgaW50ZXJlc3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT4vc3Vic2NyaXB0aW9uLWNvbmZpZy9zdWJzY3JpcHRpb24vc246c3RyZWFtIGFuZDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPi9zdWJzY3JpcHRpb25zL3N1YnNjcmlwdGlvbi9zbjpzdHJlYW0g YW5kIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi9lc3RhYmxpc2gtc3Vic2NyaXB0aW9uL2lucHV0 L3NuOnN0cmVhbSkgc2hvdWxkbid0IHRoZXNlIGJlIGEgbGVhZnJlZnMgPG86cD48L286cD48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Jmx0O0Vy aWMmZ3Q7IEFsZXggYW5kIEkgY2hhdHRlZCBhYm91dCB0aGlzIHByZXZpb3VzbHkuJm5ic3A7Jm5i c3A7IEl0IGlzIGZpbmUgZWl0aGVyIHdheS4mbmJzcDsgQnV0IGFzIHlvdSBwcmVmZXIgbGVhZnJl ZiwgSSBoYXZlIGNoYW5nZWQgaXQgdG8gdGhhdC4mbmJzcDsgVGhpcyBtYWtlcyBpdCBjb25zaXN0 ZW50IHdpdGggdGhlIHdheSBWUkZzIGFyZSBub3cgcmVmZXJlbmNlZC48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT4xMSk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5z L29yIG5vciBzdWJzY3JpYmVkL29yIHN1YnNjcmliZWQvIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPiZsdDtFcmljJmd0 OyBGaXhlZC4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+MTEuMik8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m cXVvdDtBIHB1Ymxpc2hlciBNVVNUIE5PVCBpbmNsdWRlIGFueSBjb250ZW50IGluIGEgbm90aWZp Y2F0aW9uIG1lc3NhZ2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgZm9yIHdo aWNoIHRoZSB1c2VyIGhhcyBub3QgYmVlbiBhdXRob3JpemVkLiZxdW90OzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPkNsYXJpZnkgaWYgdGhlIHVzZXIgaXMgdGhlIHN1YnNjcmliZXIgb3IgdGhlIHJl Y2VpdmVyLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5k b3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMwMDcwQzAiPiZsdDtFcmljJmd0OyBVcGRhdGVkIHRvIHJlY2VpdmVyIGluIHRo YXQgc2VjdGlvbiBhIGZldyB0aW1lcy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+JnF1b3Q7U3Vic2NyaWJlcnMgdGhhdCBkbyBub3Qg d2FudCBub3RpZmljYXRpb24gbWVzc2FnZXMgbmVlZCBvbmx5IHRlcm1pbmF0ZSBvciByZWZ1c2U8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hbnkgdHJhbnNwb3J0IHNlc3Npb25zIGZyb20gdGhlIHB1 Ymxpc2hlci4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JTUhPIHRoZSBmaXJzdCB3b3Jk IHNob3VsZCBiZSByZWNlaXZlcnMuIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPiZsdDtFcmljJmd0OyBGaXhlZC4gPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0 ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+QWxzbyBpbiB0aGUgY2Fz ZSBvZiBhIGNvbmZpZ3VyZWQgc3Vic2NyaXB0aW9uIGNhbiB3ZSBnZXQgaW50byBhIGN5Y2xlPyA8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tIHB1Ymxpc2hlciB0cmllcyB0byBzZW5kIGEgbm90aWZp Y2F0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+LSByZWNlaXZlciByZWNlaXZlcyBhIG5vdGlm aWNhdGlvbiBpdCBkb2VzIG5vdCB3YW50PG86cD48L286cD48L3ByZT4NCjxwcmU+LSByZWNlaXZl ciBjbG9zZXMgdHJhbnNwb3J0IHNlc3Npb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tIHN0YXJ0 IGZyb20gdGhlIHRvcDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPiZsdDtFcmljJmd0OyZuYnNwOyBUaGlzIGNhbiBiZSB0 aGUgY2FzZSwgYnV0IGl0IGlzIGF2b2lkYWJsZS4mbmJzcDsmbmJzcDsgSXQgaXMgdXAgdG8gdGhl IHRyYW5zcG9ydCBkb2N1bWVudHMgdG8gZGVmaW5lIGhvdyB0byBhdm9pZCB0aGF0IGxvb3AuJm5i c3A7IE9mIGNvdXJzZSB0aGVyZSBhcmUgbW9yZSBncmFudWxhciBtZWNoYW5pc21zIGF2YWlsYWJs ZSBmb3IgZml4aW5nIHRoaXMgd2l0aCB0cmFuc3BvcnRzIHZzLiBvdGhlcnMuJm5ic3A7Jm5ic3A7 IFRoaXMgaXMgb25lIHBsYWNlIHdoZXJlIEhUVFAyIGhhcyBhIHJlYWwgYWR2YW50YWdlLiZuYnNw OyZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Rm9yIE5FVENPTkYsIHlvdSBvbmx5IG1hbmFnZSB0aGUg b25lIHRyYW5zcG9ydCBzZXNzaW9uIGJldHdlZW4gcHVibGlzaGVyIGFuZCByZWNlaXZlciwgYW5k IHRoZXJlIGFyZSBub3QgdmVyeSBncmFudWxhciBvcHRpb25zLiZuYnNwOyZuYnNwOyBSZWxldmFu dCB0ZXh0IGluIGRyYWZ0LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2ZW50LW5vdGlmaWNhdGlvbnMg c2F5czo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6NS4zNXB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7IOKA nElmIHRoZSBjYWxsIGhvbWUgZmFpbHMgdG8gZXN0YWJsaXNoIGZvciBhbnkgb3RoZXIgcmVhc29u LCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjUu MzVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyBwdWJsaXNo ZXIgTUFZIGxlYXZlIHRoZSByZWNlaXZlciBpbiBhICZxdW90O2Nvbm5lY3RpbmcmcXVvdDsgc3Rh dHVzLCBhbmQgcmV0cnk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjUuMzVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNw OyB0aGUgY2FsbCBob21lIGF0IGEgZnV0dXJlIHRpbWUuJm5ic3A7IEFsdGVybmF0aXZlbHksIHRo ZSBwdWJsaXNoZXIgTUFZPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDo1LjM1cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj4mbmJzcDsmbmJz cDsgcGxhY2UgdGhlIHJlY2VpdmVyIGludG8gYSAmcXVvdDtzdXNwZW5kZWQmcXVvdDsgc3RhdHVz IGFmdGVyIGEgcHJlZGV0ZXJtaW5lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwO251bWJl ciBvZiBjYWxsIGhvbWUgYXR0ZW1wdHMu4oCdPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPlBlcmhhcHMgdGhp cyBjb3VsZCBiZSB0d2Vha2VkIHRvIHNheTo8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4zNXB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwNzBDMCI+Jm5ic3A7IOKAnElmIHRoZSBjYWxsIGhvbWUgZmFpbHMgdG8gZXN0YWJs aXNoIGZvciBhbnkgb3RoZXIgcmVhc29uLCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMzVwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcw QzAiPiZuYnNwOyZuYnNwOyBwdWJsaXNoZXIgTUFZIGxlYXZlIHRoZSByZWNlaXZlciBpbiBhICZx dW90O2Nvbm5lY3RpbmcmcXVvdDsgc3RhdHVzLCBhbmQgcmV0cnk8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMzVwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyB0aGUgY2FsbCBob21lIGF0IGEgZnV0dXJlIHRpbWUu Jm5ic3A7IDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxv dyI+QWRkaXRpb25hbGx5PC9zcGFuPiwgdGhlIHB1Ymxpc2hlciA8c3BhbiBzdHlsZT0iYmFja2dy b3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPlNIT1VMRDwvc3Bhbj48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMzVwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMwMDcwQzAiPiZuYnNwOyZuYnNwOyBwbGFjZSB0aGUgcmVjZWl2ZXIgaW50 byBhICZxdW90O3N1c3BlbmRlZCZxdW90OyBzdGF0dXMgYWZ0ZXIgYSBwcmVkZXRlcm1pbmVkPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMw Ij4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7bnVtYmVyIG9mIDxzcGFuIHN0eWxlPSJiYWNrZ3Jv dW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+ZWl0aGVyIGZhaWxlZDwvc3Bhbj4gY2Fs bCBob21lIGF0dGVtcHRzIDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxp Z2h0OnllbGxvdyI+b3IgTkVUQ09ORiBzZXNzaW9ucyByZW1vdGVseSB0ZXJtaW5hdGVkIGJ5IHRo ZSByZWNlaXZlcjwvc3Bhbj4u4oCdPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPldvdWxkIHRoaXMgd29yayBmb3Ig eW91Pzxicj48YnI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDA3MEMwIj5FcmljPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT5CYWxhenMgTGVuZ3llbCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtF cmljc3NvbiBIdW5nYXJ5IEx0ZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TZW5pb3IgU3BlY2lh bGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk1vYmlsZTogJiM0MzszNi03MC0zMzAtNzkwOSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBlbWFpbDogPGEgaHJlZj0ibWFpbHRvOkJhbGF6cy5MZW5neWVs QGVyaWNzc29uLmNvbSI+QmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tPC9hPiA8bzpwPjwvbzpw PjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_324be64174484ddca5a8b19b358b95e1XCHRTP013ciscocom_-- From nobody Fri Dec 8 12:01: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 2EBC8126BF7 for ; Fri, 8 Dec 2017 12:01:54 -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 9oTXDP1T4Bmt for ; Fri, 8 Dec 2017 12:01:52 -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 EAFAC120454 for ; Fri, 8 Dec 2017 12:01:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6806; q=dns/txt; s=iport; t=1512763311; x=1513972911; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ICNF5V6LLZ5oKAOhySxRm6Zpu9rZWqpC3X2u0VaI2IM=; b=g5Iwwh9NM+Yv1gQ6PlJQ+qEge4eATvAq+ivzDnk3NOS5xKqrhsgJeSRD sAeg1GAdCqlcwFJzY0M0eF7ZJFklCU/pj7wCnfUglQ+dZ+ojHOJYFRqt0 c4eRxRDV4MQg2mtnz2RcOV/TtsbC2fRXhVewOKEg5VP/bTVulEA70pfXX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DoAQCj7ipa/4MNJK1TBgMZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgz5mdC6dHYF9fpgjCh+FHAKEX0MUAQEBAQEBAQEBayiFIgE?= =?us-ascii?q?BAQMBJxM/BQkCAgEIDgIFAwwBCwYQGxclAgQODYoYCKl+OoplAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBHQWDVoILgVaBaYJ1NoR1SyYHhSoFkguQfQKVFYIfih2HLop?= =?us-ascii?q?Ai28CERkBgToBNiKBT28VgmQIgkQFHGQBgQKJGSUFgQmBFQEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,378,1508803200"; d="scan'208";a="330208090" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Dec 2017 20:01:50 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id vB8K1oMq026033 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Dec 2017 20:01:50 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; Fri, 8 Dec 2017 15:01:49 -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, 8 Dec 2017 15:01:49 -0500 From: "Eric Voit (evoit)" To: Juergen Schoenwaelder CC: Martin Bjorklund , "netconf@ietf.org" Thread-Topic: [Netconf] review of draft-ietf-netconf-yang-push-11 Thread-Index: AQHTaCy/QRPr9GM9Jka7UxKyCaa4a6MpyuqggAmhy4D///elMIABf46AgAB7+cCAAP88gIAACbyAgAGC+YCAAFcy0IABMZ0AgABpn8A= Date: Fri, 8 Dec 2017 20:01:49 +0000 Message-ID: <947b9b18251b42acbb66ed20754f52f8@XCH-RTP-013.cisco.com> References: <422b669242674349975651d2ef7c436e@XCH-RTP-013.cisco.com> <20171206.094009.1934958524737452117.mbj@tail-f.com> <905820dba0e24c0ca3d1b15849cd4961@XCH-RTP-013.cisco.com> <20171207.092001.1087388873746464030.mbj@tail-f.com> <20171208074556.uegeprzakbk3sxhr@elstar.local> In-Reply-To: <20171208074556.uegeprzakbk3sxhr@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="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: Fri, 08 Dec 2017 20:01:54 -0000 Hi Juergen, > From: Juergen Schoenwaelder, December 8, 2017 2:46 AM >=20 > On Thu, Dec 07, 2017 at 10:52:12PM +0000, Eric Voit (evoit) wrote: >=20 > > As an example, for which users should a publisher allow subscription to= : > > (From RFC-7317) > > +--rw authentication > > ---> +--rw user* [name] > > +--rw name > > +--rw password? > > > > Per the draft for any unauthorized user, the proper response would be t= he > error identity "data-unavailable". However for a system administrator,= it > might be ok to allow such a subscription. >=20 > What exactly is 'authorized user' here? I would expect that access to dat= a is > controlled by NACM. A subscription to 'user' may be valid for everybody > (who is allowed to create a subscription) but access to 'user' data may b= e > prohibited by NACM, i.e., the subscription never returns data for some > clients. Note that NACM rules can change independently of the subscriptio= n > (hence it is difficult to reject a subscription on the ground there is > _currently_ no access to data under 'user'). An operator likely won't want to allow everyone who can subscribe to *somew= here* on a publisher to the ability to place a continuous subscription to '= user'. Even if it wasn't a possible new vector for security leakage, it w= ould needlessly consume resources. =20 It makes sense to provide an implementer the option of denying such undesir= able subscriptions up front. > In draft-ietf-netconf-yang-push-11.txt I read: >=20 > A publisher MAY alternatively choose not to allow subscriptions which > select non-existent or access-protected data. Such a capability > enables the publisher to avoid having to perform filtering of > authorized content on each update. >=20 > Then there is text following I do not know how to read: >=20 > [...] Relevant scenarios here include: >=20 > o the rejecting of a subscription request to access-protected > objects, >=20 > o the suspension of a subscription where new access-controlled > objects are selected mid-subscription for which the receiver doe= s > not have the necessary authorization, or >=20 > o the authorization privileges of a receiver change over the cours= e > of the subscription. >=20 > What is this telling me? What do these 'relevant scenarios mean'? I think > we need to settle on clear definition of behaviour instead of having > descriptions of scenarios that someone needs to map to behaviour of > objects. I see your point. There are actually two cases in the examples. The first= bullet refers to denying an establish-subscription request. The second an= d third bullets provide the publisher the option of terminating a subscript= ion should access permissions change in a way impacting the subscription. How about the following... A publisher MAY choose reject an establish-subscription request which selec= ts non-existent or access-protected data. In addition, a publisher MAY choo= se to terminate a dynamic subscription or suspend a configured receiver whe= n the authorization privileges of a receiver change, or the access controls= for subscribed objects change. Such a capability enables the publisher to= avoid having to support a continuous, and total filtering of an entire sub= scription's content. =20 > I also find the following text unclear. And this strikes me as odd: >=20 > If read access into previously accessible nodes has been lost due to > a receiver permissions change, this SHOULD be reported as node > 'delete' operations for on-change subscriptions. >=20 > Are you telling a subscriber that data was deleted while in fact only acc= ess > to it has been restricted? I think there is a huge difference between the= se. This is absolutely true. But differentiating these from the point of view = of the receiver gives unwanted insights to access control permissions. The= refore the definitions of what 'delete' is within the patch have been frame= d so receiver will not know which of these two have happened. I.e., the = patch only promises to allow a receiver to maintain a current extract of a = subscribed datastore. It does not promise to show what operations have occ= urred on that datastore. > Then later I read this: >=20 > 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. >=20 > Why is there not a single behaviour? Basically because there are YANG Push implementers who are active in NETCON= F whose implementations cannot perform the changing of permissions during a= subscription. Therefore the text: "or must terminate or restart the subsc= riptions so that new access control permissions are re-established" was add= ed to allow those implementations to achieve the overall security filtering= objective without having to touch their access control filtering code. = We could delete this text block, but it would simply irritate those vendors= who would rather be able to claim some reasonable form of security complia= nce. > Frankly, a spec that says an implementation MAY to A but it also MAY do > not A is not really helpful. How do I know whether an implementation does > A or not A? ("MAY allow subscriptions which select non-existent or access= - > protected data"=20 Per other parts of this thread, text has been updated to show that a publis= her MUST be able to accept subscription requests for non-existent nodes, an= d MAY choose to reject such requests if there is no chance that the subscri= ption will result in pushed data. This is both useful and efficient for ev= eryone. > and "MAY alternatively choose not to allow subscriptions > which select non-existent or access-protected data"). >=20 > I think the document should converge to a single set of rules that give u= s > interoperability and the text touching on authorization needs to be > streamlined and consistent throughout the document(s). I will continue to do my best in refining the words. The new version due = out shortly should have some improvements driven very much by the excellent= comments made in this thread. Eric =20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Sat Dec 9 03:49: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 88458127698; Sat, 9 Dec 2017 03:49:24 -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 cYC5SfKtGirs; Sat, 9 Dec 2017 03:49:22 -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 B92131201F8; Sat, 9 Dec 2017 03:49:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 37A861424F47; Sat, 9 Dec 2017 12:49:19 +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 9kOd37tPkgMm; Sat, 9 Dec 2017 12:49:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 025071424F4B; Sat, 9 Dec 2017 12:49:19 +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 ZCAdw3VxeFEr; Sat, 9 Dec 2017 12:49:18 +0100 (CET) Received: from [192.168.2.191] (cm-84.211.71.154.getinternet.no [84.211.71.154]) by mail.transpacket.com (Postfix) with ESMTPSA id C51BE1424F47; Sat, 9 Dec 2017 12:49:18 +0100 (CET) From: Vladimir Vassilev To: Andy Bierman , Kent Watsen Cc: "netmod@ietf.org" , "netconf@ietf.org" References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> Message-ID: <9b62952b-d3e6-2db2-6aac-9a544a991078@transpacket.com> Date: Sat, 9 Dec 2017 12:49:18 +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: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Netconf] [netmod] 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, 09 Dec 2017 11:49:24 -0000 On 12/08/2017 07:01 PM, Andy Bierman wrote: > Hi, > > A library per datastore sounds too complicated. I am not proposing that. The fundamental point proposed is that the datastore relevant bits are=20 kept in the ietf-datastores module instead of merging everything in a=20 new ietf-yang-library entangled monster module. If needed=20 ietf-datastores can augment ietf-yang-library but ietf-yang-library=20 should be usable on its own without ietf-datastores. The solution is=20 coherent and modular and addresses the problem statement. > I prefer the proposal that was made at the IETF meeting that had > a 'not-implemented-in' leaf-list and a single module list. This constraint is already specified in the text of the revised=20 datastores draft. Clients conforming to the draft can expect servers to=20 comply with the MUST requirement even if there is a separate=20 yang-library data tree for each datastore the constraint of=20 configuration stores mapping to 'operational' should be enforced=20 according to the draft. There is no contradiction here. That said I would be also be OK with ietf-datastores augmenting=20 ietf-yang-library with such a leaf-list ('not-implemented-in' leaf-list)=20 as a more constrained flavor of the same approach instead of going for=20 independent copies of yang-library data. For any of that to happen=20 change in ietf-datastores.yang is needed and change in the original=20 rfc7895 ietf-yang-library is not needed at all. Vladimir > > Why is it interesting to have a separate module list for regular=20 > modules and imported modules? > I prefer to keep the conformance leaf and not change the module list. > > NMDA needs to be possible to implement with a single schema tree such=20 > that a module > is implemented in all datastores, or a subset of all datastores.=C2=A0=20 > Otherwise it probably won't > get supported in clients. > > > Andy > > > > On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen > wrote: > > CC-ing NETCONF, where the draft is being worked on. > > Kent > > > On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote: > > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote= : > > > > > > Yes. The default value for yang-library-datastore leaf is > ds:operational > > > (the only possible one for the ds:operational datastore). This > is backward > > > compatible. If one needs different model for 'running', etc. > then a new > > > datastore identity has to be defined=C2=A0 and set in place of = the > default value. > > > Then this identity can be used to read the yang-library data wi= th > > > . > > > > > > > Sorry, but I have to ask this: How do I obtain the schema for the > > datastore (lets call it ) that reports the > schema for > > ? Is there another datastore? > Will > > the recursion end? Perhaps it does since > > might have itself listed as the schema defining datastore. I gues= s > > Lada will like these kind of meta and meta-meta datastores. > > Not really. Metadata needn't be in datastores. > > Lada > > > > > /js > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3v= oDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D5qj6BQUSwq= YmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=3DI7fR1GY5lN2hVMkDuvryrhDeRypike3wPeF= RrvQI5l8&e=3D > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Sat Dec 9 09:44: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 C06ED1200FC for ; Sat, 9 Dec 2017 09:44:06 -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 gfJZ8a_63WoI for ; Sat, 9 Dec 2017 09:44:02 -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 F1EFB1270FC for ; Sat, 9 Dec 2017 09:44:01 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id f18so14968572lfg.8 for ; Sat, 09 Dec 2017 09:44:01 -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=JazFw+k1T9cT1bmg608gM23L2nvDOKfWun5JsVeNjPE=; b=2FGkqr2ggdJDh3Q9Anl4lVOrMQf0PTcqzkjG4gtWrzpePIFzX91gwydcSt04M9G6zi utv0djB/iZMYmtZAwI8G4t2zGglITkBDlLQWVLbvT5Brc59fflttlxXgLuEpHV59wI3E ljPP6jS2AcjtJgvSIFrFjfglQlbdrN/gqEtCikmhVqWupeBvRsf+KaOvP9PCVJPxewZn rTv1YMdZnec1cPQrnL5shstdiXrUm9dRPn7PfP75lFxDZgKHRkptrCH6XiyH1fcmG8f7 s7PpyXk8oSp6OW8sl7t/wkEA781rNBTuKwajP72170x2aiKZ7re5VKJQ/ydI3fHEP2i9 h+Jg== 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=JazFw+k1T9cT1bmg608gM23L2nvDOKfWun5JsVeNjPE=; b=t3zF+fAcUPqkaSD71c3PBolrP778pC9M/LiD4fxnH5i02AGb0Tu7PxV/rHmZc64C9h LpjGqZfYIueAx+1GvNZj/Qt5mesL30hjmdrKZtR+Z/+6HTV7x5Yh1qYDIvyuIAZQm1zw dPQmO0KbajuX+keJ4qtEYZu2P2JyN67K5Uhq4jGI+Mu1kuTKADL51nl0UPT4j4rccjln HoOtp2kfflP8cNgftYNR2R4FS04P7yHDfoUjjUaY1yCaXVKhhVVa0BB7MuT/AT6aKWRI IGpaaZxA2/2uNzn06C637/tsyC3wsjKjxouO4J8mJWcpsznEj+2HLzmK5gI0bX41jTIG HO4Q== X-Gm-Message-State: AJaThX589mYtbDXny3xu7pywCx80orcprcTFuFun5Dsmy2oVlYtwqv05 jqXOovYhMOCvqhCe+SqwXqAHZTyvUFT6+djl0/NgCA== X-Google-Smtp-Source: AGs4zMZjiEG/1B5RI9e0QLZ9yotgfRigW1CUOkB+Rx8KZXOo6NTp+iPyJZDowHNLl/ALlQU9EWNZn0WfR4ewgg+J0jY= X-Received: by 10.46.70.18 with SMTP id t18mr17751227lja.190.1512841440071; Sat, 09 Dec 2017 09:44:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Sat, 9 Dec 2017 09:43:59 -0800 (PST) In-Reply-To: <20171208.104741.1957721911727198135.mbj@tail-f.com> References: <20171208.104741.1957721911727198135.mbj@tail-f.com> From: Andy Bierman Date: Sat, 9 Dec 2017 09:43:59 -0800 Message-ID: To: Martin Bjorklund , Netconf Cc: NetMod WG Content-Type: multipart/alternative; boundary="f403045f771ea32625055febd813" Archived-At: Subject: Re: [Netconf] [netmod] YANG library structure 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, 09 Dec 2017 17:44:07 -0000 --f403045f771ea32625055febd813 Content-Type: text/plain; charset="UTF-8" On Fri, Dec 8, 2017 at 1:47 AM, Martin Bjorklund wrote: > Hi, > > There has been quite a lot of discussion about the YANG library > data model on the list. The authors of draft-ietf-netconf-rfc7895bis > have tried to understand all arguments in the discussion, and provide > a solution. Below are 3 solution proposals (we have discussed more, > but they are basically just variations on the same themes). > > Absolute Requirements > --------------------- > > o RFC 7950, Section 5.6.5 says: > > A server MUST NOT implement more than one revision of a module. > > o draft-ietf-netmod-revised-datastores says: > > The conventional configuration datastores [...] share exactly > the same datastore schema > > o draft-ietf-netmod-revised-datastores says: > > The datastore schema for MUST be a superset of the > combined datastore schema used in all configuration datastores > except that YANG nodes supported in a configuration datastore MAY > be omitted from if a server is not able to > accurately report them. > > > These requirements (of course) still hold, and we think that the YANG > library document should explain what they imply for the data reported > as part of the library. (For example, all conventional datastores > MUST have a reference to the same "schema"). > > > Objectives (in no particular order) > ----------------------------------- > > 1. As efficient as possible for a client to consume. > > Since the size of the yang library can be quite large, it should > be possible for clients to cache the yang library information. > > Why do all of the alternatives ignore this objective? All of them are 2X to 3X larger for message encoding than the IETF100 solution. Why is the schema list needed at all? Is this for schema-mount? What does each schema list instance represent in an NMDA server? The existing RFC 7895 library could be used, and each special feature (NMDA, licensing, who-knows-what-else) can augment the module list with additional data. I guess YANG stability only matters to the people who already ship code that does it the existing way. Given that the new NMDA version (modules instead of modules-state) is read-only, I fail to see how deprecating the modules-state subtree solves any real problem. IMO, all of the new proposals are moving in the wrong direction and force the client to potentially retrieve lots of conflicting schema information. An existing client can easily be adapted to work with a single module list / schema tree that now applies to a subset of datastores (instead of all datastores). If the client now needs to retrieve and resolve potentially overlapping module lists / schema trees, then deployment may be limited to new 2nd party client implementations only. Andy 2. A dynamic datastore must be able to implement a module or feature > that is not implemented in the conventional datastores. > > 3. It must be possible to NOT implement a module or feature in > operational, even if it is implemented in some other datastore. > > This is required for transition purposes; a server that wants to > implement should not have to implement all modules at > once. > > 4. A given module can only be implemented in one revision in all > datastores. If a module is implemented in more than one > datastores, the same revision is implemented in all these > datastores. > > 5. Multiple revisions can be used for import, if import-by revision > is used. > > 6. Nice to have: make it possible to be used by schema mount > > > It should be noted that because of 2 and 3 (and 6), the original data > model in RFC 7895 cannot be used. > > > Use Cases > --------- > > Here's a set of use cases that must be supported. > > C1. conventional + operational, all have the same schema > > C2. conventional + operational, ietf-hardware is not implemented in > conventional > > C3. conventional + operational, some modules not yet implemented in > operational, and some modules are partly implemented in > operational. > > C4. conventional + operational + ephemeral, ephemeral has its own > set of modules > > > > Alt. A. > ------- > > Each datastore refers to a schema, and each schema contains a flat > list of all modules, features, etc. > > +--ro yang-library > +--ro schema* [name] > | +--ro name string > | +--ro checksum string > | +--ro module* [name] > | | +--ro name yang:yang-identifier > | | +--ro revision? revision-identifier > | | +--ro namespace inet:uri > | | +--ro location* inet:uri > | | +--ro submodule* [name] > | | | +--ro name yang:yang-identifier > | | | +--ro revision? revision-identifier > | | | +--ro location* inet:uri > | | +--ro feature* [name] > | | | +--ro name yang:yang-identifier > | | +--ro deviation* [module] > | | +--ro module -> ../../name > | +--ro import-only-module* [name revision] > | +--ro name yang:yang-identifier > | +--ro revision union > | +--ro namespace inet:uri > | +--ro location* inet:uri > | +--ro submodule* [name] > | +--ro name yang:yang-identifier > | +--ro revision? revision-identifier > | +--ro location* inet:uri > +--ro datastore* [name] > | +--ro name identityref > | +--ro schema -> ../../schema/name > +--ro checksum string > > > How does this solution handle the use cases above? > > C1: One schema, all datastores refer to this schema. > > C2: Two schemas, "conventional" and "operational". They differ in > just one element (ietf-hardware). All other module information > is entirely duplicated in both. > > C3: Two schemas, "conventional" and "operational". They differ in > the modules not implemented in operational, and operational also > has some deviation modules with "not-implemented". > > C4: Three schemas, "conventional", "ephemeral", "operational". > "operational" contains the union of all modules in the other > two. > > > Pro: simple on the client, simple on the server > > Con: verbose, since a single difference requires a complete, new, > schema. > > > Alt. B. > ------- > > Each datastore refers to a schema, and each schema contains a list > of references to module-sets, and each module-set contains a flat > list of all modules, features, etc. > > When combining module-sets into a schema there MUST NOT be any > duplicate module definitions in the module-sets. > > > +--ro yang-library > +--ro module-set* [name] > | +--ro name string > | +--ro checksum string > | +--ro module* [name] > | | +--ro name yang:yang-identifier > | | +--ro revision? revision-identifier > | | +--ro namespace inet:uri > | | +--ro location* inet:uri > | | +--ro submodule* [name] > | | | +--ro name yang:yang-identifier > | | | +--ro revision? revision-identifier > | | | +--ro location* inet:uri > | | +--ro feature* [name] > | | | +--ro name yang:yang-identifier > | | +--ro deviation* [module] > | | +--ro module -> ../../name > | +--ro import-only-module* [name revision] > | +--ro name yang:yang-identifier > | +--ro revision union > | +--ro namespace inet:uri > | +--ro location* inet:uri > | +--ro submodule* [name] > | +--ro name yang:yang-identifier > | +--ro revision? revision-identifier > | +--ro location* inet:uri > +--ro schema* [name] > | +--ro name string > | +--ro checksum string > | +--ro module-set* -> ../../module-set/name > +--ro datastore* [name] > | +--ro name identityref > | +--ro schema -> ../../schema/name > +--ro checksum string > > How does this solution handle the use cases above? > > C1: One module-set, one schema, all datastores refer to this schema, > the schema refers to the single module-set. > > C2: Two schemas, "conventional" and "operational", and two > module-sets. One module-set contains just "ietf-hardware" and > the other everything else. The "operational" schema refers to > both module-sets, and the "conventional" to just the one without > "ietf-hardware". > > C3: Two schemas, "conventional" and "operational", and three > module-sets. One module-set contains all modules fully > implemented in both conventional and operational, one contains > the modules implemented only in conventional, and one the > modules and deviations for the partly implemented modules in > operational. > > C4: Three schemas, "conventional", "ephemeral", "operational", but > just two module-sets. "conventional" refers to one of the > module-sets, and "ephemeral" to the other. "operational" refers > to both. > > Pro: less verbose > > Con: the client has to follow extra references and must combine the > result from the references into a single schema. > > > Alt. C. > ------- > > (This is the draft -02 version with just some name changes) > > Each datastore refers to a schema, and each schema contains a list > of references to each module it includes. > > +--ro yang-library > +--ro module* [id] > | +--ro id string > | +--ro name yang:yang-identifier > | +--ro revision? revision-identifier > | +--ro location* 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 location* inet:uri > +--ro schema* [name] > | +--ro name string > | +--ro module* -> ../../module/id > +--ro datastore* [name] > | +--ro name identityref > | +--ro schema -> ../../schema/name > +--ro checksum string > > How does this solution handle the use cases above? > > C1: One schema, all datastores refer to this schema, > the schema refers to all modules. > > C2: Two schemas, "conventional" and "operational", and the module > list contains all modules. The "operational" schema refers to > all modules, and "conventional" to all modules except > "ietf-hardware". > > C3: similar to C2, except there will be two entries in the module > list for evenry module that is partly implemented in > operational. > > C4: Three schemas, "conventional", "ephemeral", "operational", and > the module list contains all modules. > Each schema refers to the modules it supports. > > Pro: All modules available are listed in one place. > > Con: the client has to follow extra references and must combine the > result from the references into a single schema. > > the least "direct" solution due to the module "id". > > probably a bit tricky to implement on the server. > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --f403045f771ea32625055febd813 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Dec 8, 2017 at 1:47 AM, Martin Bjorklund <= mbj@tail-f.com><= /span> wrote:
Hi,

There has been quite a lot of discussion about the YANG library
data model on the list.=C2=A0 The authors of draft-ietf-netconf-rfc7895bis<= br> have tried to understand all arguments in the discussion, and provide
a solution.=C2=A0 Below are 3 solution proposals (we have discussed more, but they are basically just variations on the same themes).

Absolute Requirements
---------------------

o=C2=A0 RFC 7950, Section 5.6.5 says:

=C2=A0 =C2=A0 =C2=A0A server MUST NOT implement more than one revision of a= module.

o=C2=A0 draft-ietf-netmod-revised-datastores says:

=C2=A0 =C2=A0 =C2=A0The conventional configuration datastores [...] share e= xactly
=C2=A0 =C2=A0 =C2=A0the same datastore schema

o=C2=A0 draft-ietf-netmod-revised-datastores says:

=C2=A0 =C2=A0 =C2=A0The datastore schema for <operational> MUST be a = superset of the
=C2=A0 =C2=A0 =C2=A0combined datastore schema used in all configuration dat= astores
=C2=A0 =C2=A0 =C2=A0except that YANG nodes supported in a configuration dat= astore MAY
=C2=A0 =C2=A0 =C2=A0be omitted from <operational> if a server is not = able to
=C2=A0 =C2=A0 =C2=A0accurately report them.


These requirements (of course) still hold, and we think that the YANG
library document should explain what they imply for the data reported
as part of the library.=C2=A0 (For example, all conventional datastores
MUST have a reference to the same "schema").


Objectives (in no particular order)
-----------------------------------

1. As efficient as possible for a client to consume.

=C2=A0 =C2=A0Since the size of the yang library can be quite large, it shou= ld
=C2=A0 =C2=A0be possible for clients to cache the yang library information.=



Why do all of the alter= natives ignore this objective?
All of them are 2X to 3X larger fo= r message encoding than the IETF100 solution.

= Why is the schema list needed at all?
Is this for schema-mount?
What does each schema list instance represent in an NMDA server?

The existing RFC 7895 library could be used, and ea= ch special feature
(NMDA, licensing, who-knows-what-else) can aug= ment the module list
with additional data.=C2=A0 I guess YANG sta= bility only matters to the people
who already ship code that does= it the existing way.=C2=A0 Given that the new NMDA
version (modu= les instead of modules-state) is read-only, I fail to see how
dep= recating the modules-state subtree solves any real problem.

<= /div>
IMO, all of the new proposals are moving in the wrong direction a= nd force
the client to potentially retrieve lots of conflicting s= chema information.
An existing client can easily be adapted to wo= rk with a single module list / schema
tree that now applies to a = subset of datastores (instead of all datastores).
If the client n= ow needs to retrieve and resolve potentially overlapping
module l= ists / schema trees, then deployment may be limited to new
2nd pa= rty client implementations only.


An= dy


2. A dynamic datastore must be able to implement a module or feature
=C2=A0 =C2=A0that is not implemented in the conventional datastores.

3. It must be possible to NOT implement a module or feature in
=C2=A0 =C2=A0operational, even if it is implemented in some other datastore= .

=C2=A0 =C2=A0This is required for transition purposes; a server that wants = to
=C2=A0 =C2=A0implement <operational> should not have to implement all= modules at
=C2=A0 =C2=A0once.

4. A given module can only be implemented in one revision in all
=C2=A0 =C2=A0datastores.=C2=A0 If a module is implemented in more than one<= br> =C2=A0 =C2=A0datastores, the same revision is implemented in all these
=C2=A0 =C2=A0datastores.

5. Multiple revisions can be used for import, if import-by revision
=C2=A0 =C2=A0is used.

6. Nice to have: make it possible to be used by schema mount


It should be noted that because of 2 and 3 (and 6), the original data
model in RFC 7895 cannot be used.


Use Cases
---------

Here's a set of use cases that must be supported.

=C2=A0 C1. conventional + operational, all have the same schema

=C2=A0 C2. conventional + operational, ietf-hardware is not implemented in<= br> =C2=A0 =C2=A0 =C2=A0 conventional

=C2=A0 C3. conventional + operational, some modules not yet implemented in<= br> =C2=A0 =C2=A0 =C2=A0 operational, and some modules are partly implemented i= n
=C2=A0 =C2=A0 =C2=A0 operational.

=C2=A0 C4. conventional + operational + ephemeral, ephemeral has its own =C2=A0 =C2=A0 =C2=A0 set of modules



Alt. A.
-------

=C2=A0 Each datastore refers to a schema, and each schema contains a flat =C2=A0 list of all modules, features, etc.

=C2=A0 =C2=A0 +--ro yang-library
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro schema* [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 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro checksum=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro module* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro name=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro revision?=C2=A0 =C2=A0 rev= ision-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro namespace=C2=A0 =C2=A0 ine= t:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro location*=C2=A0 =C2=A0 ine= t:uri
=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 +--ro name=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=A0revision-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 |=C2=A0 +--ro location*=C2=A0 = =C2=A0inet:uri
=C2=A0 =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 |=C2=A0 +--ro name=C2=A0 =C2=A0 = yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro deviation* [module]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0+--ro module=C2=A0 = =C2=A0 -> ../../name
=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=A0yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro revision=C2=A0 =C2=A0= =C2=A0union
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro namespace=C2=A0 =C2= =A0 inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro location*=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 +--ro name=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 revision?=C2= =A0 =C2=A0revision-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro location*=C2= =A0 =C2=A0inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro datastore* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro name=C2=A0 =C2=A0 =C2=A0 identityr= ef
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro schema=C2=A0 =C2=A0 -> ../../sc= hema/name
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro checksum=C2=A0 =C2=A0 =C2=A0string


=C2=A0 How does this solution handle the use cases above?

=C2=A0 C1: One schema, all datastores refer to this schema.

=C2=A0 C2: Two schemas, "conventional" and "operational"= ;.=C2=A0 They differ in
=C2=A0 =C2=A0 =C2=A0 just one element (ietf-hardware).=C2=A0 All other modu= le information
=C2=A0 =C2=A0 =C2=A0 is entirely duplicated in both.

=C2=A0 C3: Two schemas, "conventional" and "operational"= ;.=C2=A0 They differ in
=C2=A0 =C2=A0 =C2=A0 the modules not implemented in operational, and operat= ional also
=C2=A0 =C2=A0 =C2=A0 has some deviation modules with "not-implemented&= quot;.

=C2=A0 C4: Three schemas, "conventional", "ephemeral", = "operational".
=C2=A0 =C2=A0 =C2=A0 "operational" contains the union of all modu= les in the other
=C2=A0 =C2=A0 =C2=A0 two.


=C2=A0 Pro: simple on the client, simple on the server

=C2=A0 Con: verbose, since a single difference requires a complete, new, =C2=A0 =C2=A0 =C2=A0 =C2=A0schema.


Alt. B.
-------

=C2=A0 Each datastore refers to a schema, and each schema contains a list =C2=A0 of references to module-sets, and each module-set contains a flat =C2=A0 list of all modules, features, etc.

=C2=A0 When combining module-sets into a schema there MUST NOT be any
=C2=A0 duplicate module definitions in the module-sets.


=C2=A0 =C2=A0 +--ro yang-library
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro module-set* [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 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro checksum=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro module* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro name=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro revision?=C2=A0 =C2=A0 rev= ision-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro namespace=C2=A0 =C2=A0 ine= t:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro location*=C2=A0 =C2=A0 ine= t:uri
=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 +--ro name=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=A0revision-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 |=C2=A0 +--ro location*=C2=A0 = =C2=A0inet:uri
=C2=A0 =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 |=C2=A0 +--ro name=C2=A0 =C2=A0 = yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro deviation* [module]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0+--ro module=C2=A0 = =C2=A0 -> ../../name
=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=A0yang:yang-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro revision=C2=A0 =C2=A0= =C2=A0union
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro namespace=C2=A0 =C2= =A0 inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro location*=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 +--ro name=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 revision?=C2= =A0 =C2=A0revision-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro location*=C2= =A0 =C2=A0inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro schema* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro name=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro checksum=C2=A0 =C2=A0 =C2=A0 strin= g
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro module-set*=C2=A0 =C2=A0-> ../.= ./module-set/name
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro datastore* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro name=C2=A0 =C2=A0 =C2=A0 identityr= ef
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro schema=C2=A0 =C2=A0 -> ../../sc= hema/name
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro checksum=C2=A0 =C2=A0 =C2=A0 string

=C2=A0 How does this solution handle the use cases above?

=C2=A0 C1: One module-set, one schema, all datastores refer to this schema,=
=C2=A0 =C2=A0 =C2=A0 the schema refers to the single module-set.

=C2=A0 C2: Two schemas, "conventional" and "operational"= ;, and two
=C2=A0 =C2=A0 =C2=A0 module-sets.=C2=A0 One module-set contains just "= ietf-hardware" and
=C2=A0 =C2=A0 =C2=A0 the other everything else.=C2=A0 The "operational= " schema refers to
=C2=A0 =C2=A0 =C2=A0 both module-sets, and the "conventional" to = just the one without
=C2=A0 =C2=A0 =C2=A0 "ietf-hardware".

=C2=A0 C3: Two schemas, "conventional" and "operational"= ;, and three
=C2=A0 =C2=A0 =C2=A0 module-sets.=C2=A0 One module-set contains all modules= fully
=C2=A0 =C2=A0 =C2=A0 implemented in both conventional and operational, one = contains
=C2=A0 =C2=A0 =C2=A0 the modules implemented only in conventional, and one = the
=C2=A0 =C2=A0 =C2=A0 modules and deviations for the partly implemented modu= les in
=C2=A0 =C2=A0 =C2=A0 operational.

=C2=A0 C4: Three schemas, "conventional", "ephemeral", = "operational", but
=C2=A0 =C2=A0 =C2=A0 just two module-sets. "conventional" refers = to one of the
=C2=A0 =C2=A0 =C2=A0 module-sets, and "ephemeral" to the other.= =C2=A0 "operational" refers
=C2=A0 =C2=A0 =C2=A0 to both.

=C2=A0 Pro: less verbose

=C2=A0 Con: the client has to follow extra references and must combine the<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0result from the references into a single schema.=


Alt. C.
-------

=C2=A0 (This is the draft -02 version with just some name changes)

=C2=A0 Each datastore refers to a schema, and each schema contains a list =C2=A0 of references to each module it includes.

=C2=A0 =C2=A0 +--ro yang-library
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro module* [id]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro id=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|=C2=A0 +--ro name=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 =C2=A0revision-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro location*=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro namespace=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro feature*=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 deviation* [module]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 +--ro module=C2=A0 =C2=A0 -> = ../../id
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro conformance-type=C2=A0 =C2=A0 enum= eration
=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+--ro name=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= =A0revision-identifier
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--ro location*=C2=A0 =C2= =A0inet:uri
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro schema* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro name=C2=A0 =C2=A0 =C2=A0 string =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro module*=C2=A0 =C2=A0-> ../../mo= dule/id
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro datastore* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro name=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 identityref
=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--ro schema=C2=A0 =C2=A0 -> ../../sc= hema/name
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro checksum=C2=A0 =C2=A0 =C2=A0 =C2=A0string<= br>
=C2=A0 How does this solution handle the use cases above?

=C2=A0 C1: One schema, all datastores refer to this schema,
=C2=A0 =C2=A0 =C2=A0 the schema refers to all modules.

=C2=A0 C2: Two schemas, "conventional" and "operational"= ;, and the module
=C2=A0 =C2=A0 =C2=A0 list contains all modules.=C2=A0 The "operational= " schema refers to
=C2=A0 =C2=A0 =C2=A0 all modules, and "conventional" to all modul= es except
=C2=A0 =C2=A0 =C2=A0 "ietf-hardware".

=C2=A0 C3: similar to C2, except there will be two entries in the module =C2=A0 =C2=A0 =C2=A0 list for evenry module that is partly implemented in =C2=A0 =C2=A0 =C2=A0 operational.

=C2=A0 C4: Three schemas, "conventional", "ephemeral", = "operational", and
=C2=A0 =C2=A0 =C2=A0 the module list contains all modules.
=C2=A0 =C2=A0 =C2=A0 Each schema refers to the modules it supports.

=C2=A0 Pro: All modules available are listed in one place.

=C2=A0 Con: the client has to follow extra references and must combine the<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0result from the references into a single schema.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0the least "direct" solution due to the= module "id".

=C2=A0 =C2=A0 =C2=A0 =C2=A0probably a bit tricky to implement on the server= .



/martin

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

--f403045f771ea32625055febd813-- From nobody Sun Dec 10 07:45: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 1733E12702E for ; Sun, 10 Dec 2017 07:45:43 -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 nCNN05EN-UYp for ; Sun, 10 Dec 2017 07:45:40 -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 78DBC124D6C for ; Sun, 10 Dec 2017 07:45:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10224; q=dns/txt; s=iport; t=1512920740; x=1514130340; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4iTD0X/0e/c0WKE6xkOAomg7EznT0miF+ReuVrlBCZ4=; b=cD5tC7FTJQ1FipZB7oh9l6nVHqgMUNOFTQ2hDB4oTIF8puMg9Imz7LjI BxMkMMKIe98eEk53ZfWNzA4QwKj8PIakFGO6DS0UgzCohUlZhA6JmuFjj g6wxbJC1fXMbxwEaBm8H5uRYWjDpSBp+Vi9luegtPjCAYowZB3DqZMNte 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAgC3VS1a/5JdJa1SBgMZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgz5mdCcHg3uZHYF9lyCCAQoYC4RJTwIahEVDFAEBAQEBAQE?= =?us-ascii?q?BAWsohSIBAQEDAQEBIRE6CwUJAgIBCA4CCAICJgICAhkMCxUQAgQOBRuKBQgQp?= =?us-ascii?q?myCJ4pjAQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWBCoJZgguDPymDAoRsAQgDBwE?= =?us-ascii?q?JFRgKJoJOMYIyBZIPkQIClR+CFoofhy6TG4MWAhEZAYE6ATYiYW5vFToqAYF+C?= =?us-ascii?q?TaEFniHHQINGAeBBYEVAQEB?= X-IronPort-AV: E=Sophos;i="5.45,389,1508803200"; d="scan'208";a="330704816" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Dec 2017 15:45:38 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vBAFjc8w031207 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 10 Dec 2017 15:45:38 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 10 Dec 2017 10:45:37 -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; Sun, 10 Dec 2017 10:45:37 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Juergen Schoenwaelder CC: Balazs Lengyel , Martin Bjorklund , "netconf@ietf.org" Thread-Topic: [Netconf] "notifiable-on-change" Thread-Index: AQHTbnD+9I2b119a1UiTPWuIbdyqC6M2cf+AgABtkwCAAAWHgIAAC1iAgAAkeoCABf3XAA== Date: Sun, 10 Dec 2017 15:45:37 +0000 Message-ID: <13114A81-F54E-4E8D-A8AA-4CBD3453BE36@cisco.com> References: <20171128.103735.1654378548309425095.mbj@tail-f.com> <81f49c62-e1fe-4a90-a93f-c7fd55229100@ericsson.com> <20171206.100112.298803456348365967.mbj@tail-f.com> <4aacc669-5470-bef5-a3e7-fd9047c72562@ericsson.com> <20171206172433.aeysedjtcm3u7rf3@elstar.local> <649B1612-C107-4194-A2A2-A9305887AD0B@cisco.com> <20171206201542.depjrlqlulnpkk6r@elstar.local> In-Reply-To: <20171206201542.depjrlqlulnpkk6r@elstar.local> 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.55.106.12] Content-Type: text/plain; charset="utf-8" Content-ID: <6EF8EDCC42F84A4592E360C9AEE2BD54@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] "notifiable-on-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, 10 Dec 2017 15:45:43 -0000 SnVlcmdlbiwNCg0KSSBhZ3JlZSB0aGF0IGtub3dpbmcgdGhlIHNvdXJjZSBtYWtlcyBzZW5zZSwg YW5kIEkgZGlkbuKAmXQgcmVhZCB0aGUgdGV4dCBzdXJyb3VuZGluZyB5b3VyIGV4YW1wbGUgY29y cmVjdGx5LCBhcG9sb2dpZXMuIFRoaXMgYXBwcm9hY2ggaXMgZmluZSB3aXRoIG1lLg0KDQpDaGVl cnMsDQoNCkVpbmFyDQoNCj4gT24gNiBEZWMgMjAxNywgYXQgMjA6MTUsIEp1ZXJnZW4gU2Nob2Vu d2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4g DQo+IEVpbmFyLA0KPiANCj4gSSBsaWtlIHRvIGtub3cgd2hpY2ggZGF0YXN0b3JlIGNvbnRlbnQg YmVsb25ncyB0bywgaGVuY2UgSSBzdWdnZXN0ZWQNCj4gdG8gdXNlIGFzIHRoZSB0b3BsZXZlbCB0 aGUgZGF0YXN0b3JlIG5hbWUgKGRlZmluZWQgYXMgYSBpZGVudGl0eSkuIElmDQo+IHlvdSBoYXZl IGNvbnRlbnQgZnJvbSA8cnVubmluZz4sIHRoZSB0b3AtbGV2ZWwgd291bGQgYmUNCj4gDQo+IDw/ eG1sIHZlcnNpb249IjEuMCI/Pg0KPiA8cnVubmluZyB4bWxucz0iaWV0Zi1kYXRhc3RvcmVzIj4N Cj4gPC9ydW5uaW5nPg0KPiANCj4gU2luY2UgWUFORyBsaWJyYXJ5IGlzIGNvbmZpZyBmYWxzZSwg SSBwaWNrZWQgPG9wZXJhdGlvbmFsPiBhcyB0aGUNCj4gdG9wLWxldmVsIGZvciB0aGUgZXhhbXBs ZS4NCj4gDQo+IC9qcw0KPiANCj4gT24gV2VkLCBEZWMgMDYsIDIwMTcgYXQgMDY6MDU6MDdQTSAr MDAwMCwgRWluYXIgTmlsc2VuLU55Z2FhcmQgKGVpbmFybm4pIHdyb3RlOg0KPj4gSnVlcmdlbiwN Cj4+IA0KPj4gVGhhbmtzIGZvciB0aGlzLiBUaGFua3MgZm9yIHBpY2tpbmcgdXAgdGhhdCBhIHRv cCBsZXZlbCBjb250YWluaW5nIGVsZW1lbnQgYXMgeW91IGhhdmUgaXMgbmVjZXNzYXJ5LiBPdGhl cndpc2Ugd2Ugd291bGQgd291bGQgYmUgbGltaXRlZCB0byBhIHNpbmdsZSBtb2R1bGUsIHdoaWNo IGlzIG5vdCBzbyB1c2VmdWwuIEkgZG9u4oCZdCB0aGluayB0aGF0IHRoZSB0b3AgbGV2ZWwgdGFn IHNob3VsZCBiZSDigJxvcGVyYXRpb25hbOKAnSwgdGhvdWdoLiBNYXliZSBzb21ldGhpbmcgbW9y ZSBsaWtlIOKAnDxkYXRhc3RvcmUtY29udGVudHM+4oCdPw0KPj4gDQo+PiBDaGVlcnMsDQo+PiAN Cj4+IEVpbmFyDQo+PiANCj4+IA0KPj4+IE9uIDYgRGVjIDIwMTcsIGF0IDE3OjI0LCBKdWVyZ2Vu IFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3Jv dGU6DQo+Pj4gDQo+Pj4gSXQgcHJvYmFibHkgbWFrZXMgc2Vuc2UgdG8gd3JpdGUgYSBkb2N1bWVu dCB0aGF0IGRlZmluZXMgaG93IGRhdGFzdG9yZQ0KPj4+IGNvbnRlbnQgKG9yIHN1YnNldHMgb2Yg ZGF0YXN0b3JlIGNvbnRlbnQpIGluIGdlbmVyYWwgY2FuIGJlIHN0b3JlZCBpbg0KPj4+IGEgZmls ZS4gV2l0aCB0aGF0IGluIHBsYWNlLCB3ZSBrbm93IGhvdyB0byBzdG9yZSBpZXRmLXlhbmctbGli cmFyeQ0KPj4+IGNvbnRlbnQgYW5kIGFzIGEgc2lkZSBlZmZlY3Qgd2Uga25vdyBob3cgdG8gc3Rv cmUgZGF0YXN0b3JlIGNvbnRlbnQNCj4+PiB1c2VkIGFzIGV4YW1wbGVzIGZvciBZQU5HIGRhdGEg bW9kZWxzIGFuZCBsaWtlbHkgc2V2ZXJhbCBvdGhlcg0KPj4+IHB1cnBvc2VzLiBUaGUgcm9vdCBv ZiB0aGUgWE1MIGRvY3VtZW50IHdvdWxkIGxpa2UgYmUgdGhlIGRhdGFzdG9yZQ0KPj4+IGlkZW50 aXR5IG5hbWUgaW4gdGhlIFlBTkcgbW9kdWxlIG5hbWVzcGFjZSBkZWZpbmluZyB0aGUgaWRlbnRp dHkNCj4+PiANCj4+PiA8P3htbCB2ZXJzaW9uPSIxLjAiPz4NCj4+PiA8b3BlcmF0aW9uYWwgeG1s bnM9ImlldGYtZGF0YXN0b3JlcyI+DQo+Pj4gPG1vZHVsZXMtc3RhdGUgeG1sbnM9ImlldGYteWFu Zy1saWJyYXJ5Ij4NCj4+PiA8L21vZHVsZXMtc3RhdGU+DQo+Pj4gPC9vcGVyYXRpb25hbD4NCj4+ PiANCj4+PiBSaWdodCBub3csIGl0IHNlZW1zIEkgaGF2ZSB0byBmZWVkIGluc3RhbmNlIGRhdGEg aW4gc2xpZ2h0bHkgZGlmZmVyZW50DQo+Pj4gZm9ybWF0cyBpbnRvIHRvb2xzLiBJdCB3b3VsZCBi ZSBuaWNlIGlmIHRvb2xzIGNvdWxkIGFjdHVhbGx5IGNvbnZlcmdlDQo+Pj4gdG8gY29tbW9uIGZv cm1hdHMuIFtJIGFtIHBhcnRpY3VsYXJseSBpbnRlcmVzdGVkIGluIHZhbGlkYXRpb25zIG9mDQo+ Pj4gZXhhbXBsZXMuXQ0KPj4+IA0KPj4+IC9qcw0KPj4+IA0KPj4+IE9uIFdlZCwgRGVjIDA2LCAy MDE3IGF0IDA1OjA0OjQ0UE0gKzAwMDAsIEVpbmFyIE5pbHNlbi1OeWdhYXJkIChlaW5hcm5uKSB3 cm90ZToNCj4+Pj4gSSBhZ3JlZSB3aXRoIEJhbGF6cyB0aGF0IHdlIHJlYWxseSB3YW50IHRoaXMg aXNzdWUgdG8gYmUgbmFpbGVkIHJpZ2h0IGZvcm0gdGhlIHN0YXJ0Lg0KPj4+PiANCj4+Pj4gSSB3 b3VsZCBiZSBoYXBweSB3aXRoIGRlZmluaW5nIGFuIGF1Z21lbnRhdGlvbiB0byBpZXRmLXlhbmct bGlicmFyeSB0byBhbGxvdyBkZXZpY2VzIHRvIHJldHVybiB0aGUgZGF0YSBvbiB3aGF0IGNvbnRl bnQgaXMgbm90aWZpYWJsZSAtb24tY2hhbmdlIG5vdCB0aGlzIHNwZWNpZmljIGRldmljZSBhdCB0 aGUgc3BlY2lmaWMgdGltZSB0aGUgZGF0YSB3YXMgcmV0cmlldmVkLg0KPj4+PiANCj4+Pj4gRm9y IG9mZmxpbmUgY29uc3VtcHRpb24sIHdlIHNob3VsZCBkZWZpbmUgdGhhdCBhbiBYTUwgZG9jdW1l bnQgY29uZm9ybWluZyB0byB0aGUgWE1MIHNjaGVtYSBkZWZpbmVkIGJ5IGlldGYteWFuZy1saWJy YXJ5ICsgYXVnbWVudGF0aW9ucyBpcyBhbiBhcHByb3ByaWF0ZSBmb3JtYXQuIFRoaXMgWE1MIGRv Y3VtZW50IHdvdWxkIGhhdmUgYXQgaXRzIHJvb3QgdGhlIGVsZW1lbnQgaWV0Zi15YW5nLWxpYnJh cnk6bW9kdWxlcy1zdGF0ZS4gSG93IHRoaXMgWE1MIGRvY3VtZW50IGlzIHByb3ZpZGVkIGlzIG91 dCBvZiBzY29wZS4gSXQgbWF5IGJlIGEgZmxhdCBmaWxlLCBpdCBjb3VsZCBjb21lIGZyb20gYSBV UkwsIHdoYXRldmVyLg0KPj4+PiANCj4+Pj4gSXMgdGhpcyBhbmQgYWNjZXB0YWJsZSBhcHByb2Fj aD8NCj4+Pj4gDQo+Pj4+IENoZWVycywNCj4+Pj4gDQo+Pj4+IEVpbmFyDQo+Pj4+IA0KPj4+PiAN Cj4+Pj4+IE9uIDYgRGVjIDIwMTcsIGF0IDEwOjMyLCBCYWxhenMgTGVuZ3llbCA8YmFsYXpzLmxl bmd5ZWxAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBPbiAyMDE3 LTEyLTA2IDEwOjAxLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPj4+Pj4+IEJhbGF6cyBMZW5n eWVsIDxiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4+Pj4+PiBJIHZlcnkg c3Ryb25nbHkgb2JqZWN0IHRvIGV4Y2x1ZGluZyB0aGUgaXNzdWUuIFRoZXJlIGlzIGEgc3Ryb25n IGFuZA0KPj4+Pj4+PiBpbW1lZGlhdGUgbmVlZCB0byBiZSBhYmxlIHRvIHNwZWNpZnkgaW4gdmVu ZG9yIGRlc2lnbiB0aW1lIGZvciB3aGljaA0KPj4+Pj4+PiBkYXRhIG5vZGVzIHdpbGwgdGhlcmUg YmUgb24tY2hhbmdlIG5vdGlmaWNhdGlvbiBiZSBnZW5lcmF0ZWQuDQo+Pj4+Pj4+IA0KPj4+Pj4+ PiBXaGVuIGEgdmVuZG9yIHJlbGVhc2UgYSBwcm9kdWN0IHRoZXkga25vdyB3aGljaCBub2RlcyB3 aWxsIGVtaXQNCj4+Pj4+Pj4gb24tY2hhbmdlIG5vdGlmaWNhdGlvbnMgaW4gZGVzaWduIHRpbWUu IFN5c3RlbSBpbnRlZ3JhdG9ycyBuZWVkIHRvDQo+Pj4+Pj4+IGtub3cgdGhpcy4gUHJvdmlkaW5n IHRoZSBzYW1lIGluZm9ybWF0aW9uIGluIHJ1bi10aW1lIGFzIGluc3RhbmNlIGRhdGENCj4+Pj4+ Pj4gaXMgbm90IGEgZ29vZCBzb2x1dGlvbiBlaXRoZXIgYXMgeW91IHdvdWxkIG5lZWQgdG8gZ2V0 IGEgcmVhbCBub2RlIHRvDQo+Pj4+Pj4+IHJlYWQgdGhlIGRhdGEgZnJvbS4NCj4+Pj4+PiBUaGUg c2FtZSBhcmd1bWVudCBhcHBsaWVzIHRvIHdoaWNoIFlBTkcgbW9kdWxlcywgZmVhdHVyZXMgYW5k DQo+Pj4+Pj4gZGV2aWF0aW9ucyBhIHByb2R1Y3Qgc3VwcG9ydHMuICBJbiBTTUl2MiB3ZSBoYWQg QUdFTlQtQ0FQQUJJTElUSUVTDQo+Pj4+Pj4gd2hpY2ggd2FzIGFuIG9mZi1saW5lIGRvY3VtZW50 IHdpdGggdGhpcyBpbmZvcm1hdGlvbi4gIFRoZSBleHBlcmllbmNlDQo+Pj4+Pj4gc2VlbXMgdG8g YmUgdGhhdCBpdCB3YXMgcmFyZWx5IHVzZWQgYnkgbWFuYWdlcnMuICBJbiBZQU5HIHdlIHByb3Zp ZGUNCj4+Pj4+PiB0aGlzIGluZm9ybWF0aW9uIG9uLWxpbmUgd2l0aCB0aGUgWUFORyBsaWJyYXJ5 IChhbmQgYXQgbGVhc3Qgb3VyDQo+Pj4+Pj4gZXhwZXJpZW5jZSBzbyBmYXIgaXMgdGhhdCB0aGlz ICppcyogdXNlZCBieSBjbGllbnRzKS4NCj4+Pj4+IEJBTEFaUzogSSBhZ3JlZSB0aGF0IHlhbmct bGlicmFyeSBpcyBnb29kLiBJIGFtIG5vdCBhcmd1aW5nIGFnYWluc3QgaXQuIEp1c3QgaXQgaXMN Cj4+Pj4+IG5vdCBlbm91Z2gsIGJlY2F1c2UgaXQgaXMgb25seSBhdmFpbGFibGUgaW4gcnVuLXRp bWUsIHRvbyBsYXRlLg0KPj4+Pj4+IEl0IHdvdWxkIHByb2JhYmx5IGJlIGEgZ29vZCBpZGVhIHRv IGNvbWJpbmUgdGhlc2UgdHdvIGFwcHJvYWNoZXMuDQo+Pj4+PiBCQUxBWlM6IEkgYWdyZWUuIEVh cmx5IGRvY3VtZW50YXRpb24gYW5kIG9uLWxpbmUgZG9jdW1lbnRhdGlvbg0KPj4+Pj4gY29tYmlu ZWQgd291bGQgYmUgYSBnb29kIHNvbHV0aW9uLg0KPj4+Pj4gSU1ITyB0aGUgMiBjb3VsZCB1c2Ug dGhlIHNhbWUgZm9ybWF0LiBFLmcuDQo+Pj4+PiAtIFB1dCBhbGwgc2VydmVyLWNhcGFiaWxpdGll cyBpbnRvIHlhbmctbGlicmFyeSAocG9zc2libHkgYXVnbWVudGluZyBpdCB3aGVyZSBuZWVkZWQp DQo+Pj4+PiAtIGRlZmluZSBhbiBvZmYtbGluZSBmb3JtYXQgZm9yIFlBTkcgSW5zdGFuY2UgZGF0 YQ0KPj4+Pj4gICBlLmcuIHRoZSBkYXRhIHNlY3Rpb24gb2YgYSA8Z2V0PiByZXBseSBUaGlzIHdh eSB5b3UgZG9uJ3QgZXZlbiBoYXZlIHRvIGRlZmluZSBhIHJlYWwgbmV3IGZvcm1hdA0KPj4+Pj4g LSBkZWNsYXJlIHRoYXQgb2ZmLWxpbmUgaW5zdGFuY2UgZGF0YSBmcm9tIHlhbmdsaWIgaXMgdGhl IGZvcm1hdCB0byBkZWZpbmUgc2VydmVyIGNhcGFiaWxpdGllcw0KPj4+Pj4+IA0KPj4+Pj4+IEkg dGhpbmsgdGhhdCB0aGlzIHdvdWxkIGJlIGZhaXJseSBzdHJhaWdodC1mb3J3YXJkLiAgQXMgYSBm aXJzdA0KPj4+Pj4+IGFwcHJveGltYXRpb24sIHN1cHBvc2Ugd2UgaGFkIGEgc3RhbmRhcmQgZmls ZSBmb3JtYXQgZm9yIGENCj4+Pj4+PiAic2VydmVyLWNhcGFiaWxpdGllcyIgZG9jdW1lbnQuICBJ dCBjb3VsZCBiZSBzb21ldGhpbmcgbGlrZSB0aGlzOg0KPj4+Pj4+IA0KPj4+Pj4+IDxzZXJ2ZXIt Y2FwYWJpbGl0aWVzPg0KPj4+Pj4+ICAgLy8gdGhpcyBpZGVudGlmaWVyIG11c3QgYWxzbyBiZSBh dmFpbGFibGUgb24gdGhlIGRldmljZSwgc28gdGhhdA0KPj4+Pj4+ICAgLy8gYSBjbGllbnQgY2Fu IG1hdGNoIHRoZSBjYXBhYmlsaXR5IGRvY3VtZW50IHdpdGggdGhlIGRldmljZS4NCj4+Pj4+PiAg IDxzZXJ2ZXItY2FwYWJpbGl0eS1pZGVudGlmaWVyPnNvbWUgdW5pcXVlIGlkZW50aWZpZXI8Lz4N Cj4+Pj4+PiANCj4+Pj4+PiAgIC8vIG1ldGEtZGF0YSBnb2VzIGhlcmUNCj4+Pj4+PiAgIDx2ZW5k b3I+IC4uLiA8L3ZlbmRvcj4NCj4+Pj4+PiAgIDxwcm9kdWN0LW5hbWU+IC4uLiA8L3Byb2R1Y3Qt bmFtZT4NCj4+Pj4+PiAgIC4uLg0KPj4+Pj4+IA0KPj4+Pj4+ICAgPHlhbmctbGlicmFyeT4NCj4+ Pj4+PiAgICAgLy8gdGhlIGNvbnRlbnRzIG9mIHlhbmctbGlicmFyeSBmcm9tIHRoaXMgcHJvZHVj dA0KPj4+Pj4+ICAgICAvLyB3aXRoIG1vZHVsZXMsIGZlYXR1cmVzLCBkZXZpYXRpb25zDQo+Pj4+ Pj4gICAgIC8vIC4uLiBhbmQgcG9zc2libHkgb24tY2hhbmdlIGluZm8NCj4+Pj4+PiAgIDwveWFu Zy1saWJyYXJ5Pg0KPj4+Pj4+IDwvc2VydmVyLWNhcGFiaWxpdGllcz4NCj4+Pj4+PiANCj4+Pj4+ PiBOb3csIHRoaXMgd29uJ3QgYmUgdXNlZnVsIGZvciBhbGwgc3lzdGVtcywgZm9yIGV4YW1wbGUg aWYgdGhlIHNlcnZlcg0KPj4+Pj4+IGlzIHZlcnkgZHluYW1pYyBhbmQgc3VwcG9ydCBkeW5hbWlj IGxvYWRpbmcgb2YgcGFja2FnZXMgZXRjLg0KPj4+Pj4gQkFMQVpTOiBJIHdvdWxkIHB1dCBzZXJ2 ZXItY2FwYWJpbGl0aWVzIGluIDMgYmFnczoNCj4+Pj4+IDEpIGNhcGFiaWxpdGllcyB0aGF0IGNo YW5nZSBvbmx5IGF0IHVwZ3JhZGUNCj4+Pj4+IDIpIGNhcGFiaWxpdGllcyB0aGF0IGNoYW5nZSBy YXJlbHkgKGUuZy4gZHVlIHRvIGxpY2Vuc2luZykNCj4+Pj4+IDMpIGNhcGFiaWxpdGllcyB0aGF0 IGNoYW5nZSBmcmVxdWVudGx5ICg/Pz8pDQo+Pj4+PiBJTUhPIDEpIGNvdmVycyA3MCUgb2YgdGhl IGNhc2VzIDIpIGNvdmVycyAyMCUgMykgaXMgPCAxMCUuDQo+Pj4+PiBNYW55IG5ldHdvcmsgbm9k ZXMgb25seSBoYXZlIHR5cGUgMSkgb3IgdHlwZSAxKzIpIGNhcGFiaWxpdGllcy4NCj4+Pj4+IFNv IG91ciBtYWluIGZvY3VzIHNob3VsZCBiZSBvbiBzdGFibGUgY2FwYWJpbGl0aWVzDQo+Pj4+PiAN Cj4+Pj4+IC0tIA0KPj4+Pj4gQmFsYXpzIExlbmd5ZWwgICAgICAgICAgICAgICAgICAgICAgIEVy aWNzc29uIEh1bmdhcnkgTHRkLg0KPj4+Pj4gU2VuaW9yIFNwZWNpYWxpc3QNCj4+Pj4+IE1vYmls ZTogKzM2LTcwLTMzMC03OTA5ICAgICAgICAgICAgICBlbWFpbDogQmFsYXpzLkxlbmd5ZWxAZXJp Y3Nzb24uY29tDQo+Pj4+PiANCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4+PiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPj4+Pj4gTmV0Y29u ZkBpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRjb25mDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+PiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPj4+PiBOZXRjb25mQGlldGYu b3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K Pj4+IA0KPj4+IC0tIA0KPj4+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2Jz IFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+Pj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAg ICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPj4+IEZheDogICAr NDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUv Pg0KPj4gDQo+IA0KPiAtLSANCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNv YnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAg ICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPiBGYXg6ICAgKzQ5 IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4N Cg0K From nobody Sun Dec 10 22:31: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 475E21241FC; Sun, 10 Dec 2017 22:31:11 -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 8k7V1JDFLD2F; Sun, 10 Dec 2017 22:31:09 -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 CA7B012717E; Sun, 10 Dec 2017 22:31:08 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id CA84AF88; Mon, 11 Dec 2017 07:31:06 +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 oegvP17KfV6h; Mon, 11 Dec 2017 07:31:03 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 11 Dec 2017 07:31:06 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B4FEC2012C; Mon, 11 Dec 2017 07:31:06 +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 xXOlITnXPGaC; Mon, 11 Dec 2017 07:31:06 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0252F20129; Mon, 11 Dec 2017 07:31:05 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8399A419379A; Mon, 11 Dec 2017 07:29:36 +0100 (CET) Date: Mon, 11 Dec 2017 07:29:36 +0100 From: Juergen Schoenwaelder To: Andy Bierman Cc: Kent Watsen , "netmod@ietf.org" , "netconf@ietf.org" Message-ID: <20171211062936.sfgj3pq6zivbcltu@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Kent Watsen , "netmod@ietf.org" , "netconf@ietf.org" References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Netconf] [netmod] 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, 11 Dec 2017 06:31:11 -0000 On Fri, Dec 08, 2017 at 10:01:20AM -0800, Andy Bierman wrote: > > NMDA needs to be possible to implement with a single schema tree > such that a module is implemented in all datastores, or a subset of > all datastores. Otherwise it probably won't get supported in > clients. We believe it is. At the end, a+b = a+b+c-c. You can either use set addition to create the schema of a datastore or you create a superset and remove things from it. The result is the same. The key is that configuration datastores may implement a+b and operational a+b+c (and during transition even something different). /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 Dec 11 02:58: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 C7C75124205; Mon, 11 Dec 2017 02:57:56 -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 sFSm57EglJW3; Mon, 11 Dec 2017 02:57:54 -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 A2CCF120724; Mon, 11 Dec 2017 02:57:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14746; q=dns/txt; s=iport; t=1512989874; x=1514199474; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=DjOKLPzFUGl6LWwRYXSzl7tH51MgrgSjOPf+qHCqX40=; b=ElvBYidiZ7pA1SOmJZYa8y2sb0zf24ri/JFveyv6lidbwW3ehnTT8olX b09pWkzK14iQOHMydQigrrxCizAzRpjOKnbq5uWsLDwkK8dRc5YziOHBi IUlbS/8HnRxJy59MjfTnwED9GbtW9SwUx7dslWPIpj7PAAu/LZXU1oQfB M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAQBXYy5a/xbLJq1SCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDD4EVdCeEAoohdI9WL5FBhUuCFQoYAQmESk8ChSsYAQEBAQE?= =?us-ascii?q?BAQEBayiFIgEBAQECAQEBIUsLBQsLGCcDAgInHxEGAQwGAgEBF4oFCBCnQoInJ?= =?us-ascii?q?oo8AQEBAQEBAQEBAQEBAQEBAQEBAQEBHYNog2GBaSmDAoNJgSwUgyuCYwWZS4l?= =?us-ascii?q?Gh3mNKIIWY4kYJIcujQqBVYd/gTsfOSaBKTIaCBsVOoIpCYIQgjxBNwEBiWUBA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.45,391,1508803200"; d="scan'208,217";a="777616" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2017 10:57:51 +0000 Received: from [10.63.23.92] (dhcp-ensft1-uk-vla370-10-63-23-92.cisco.com [10.63.23.92]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vBBAvoxA015329; Mon, 11 Dec 2017 10:57:51 GMT To: Andy Bierman , Kent Watsen Cc: "netmod@ietf.org" , "netconf@ietf.org" References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> From: Robert Wilton Message-ID: <5242d50f-6f9e-b57e-ec1b-64828c456339@cisco.com> Date: Mon, 11 Dec 2017 10:57:50 +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="------------72EB40BA8927C7E67E2F34CA" Content-Language: en-US Archived-At: Subject: Re: [Netconf] [netmod] 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, 11 Dec 2017 10:57:57 -0000 This is a multi-part message in MIME format. --------------72EB40BA8927C7E67E2F34CA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, On 08/12/2017 18:01, Andy Bierman wrote: > Hi, > > A library per datastore sounds too complicated. > I prefer the proposal that was made at the IETF meeting that had > a 'not-implemented-in' leaf-list and a single module list. The use case that this particular design doesn't work particularly well for is if you have a dynamic datastore that just contains a few modules that are not supported via the conventional datastores. I think that there are future uses cases where the set of modules used for a dynamic datastore could be really quite different and separate from conventional configuration.  E.g. if dynamic subscribers were managed through a dynamic configuration datastore rather than RADIUS. > > Why is it interesting to have a separate module list for regular > modules and imported modules? Several reasons: 1) It means that the list of implemented modules have a single key and hence any references to an implemented module are cleaner/simpler. 2) The model structure naturally more strictly enforces that only a single revision/version of a module is implemented.  (E.g. it prevents a server stating that two revisions of a module are both implemented). 3) I genuinely think that the list of implemented modules is more interesting to the client than the imported, but not implemented modules. For a server, I would design it to "implement" one revision of every module that it uses (including those that don't contain any data nodes, RPCs, actions, notifications, or deviations), and then the "import-only" list becomes the list of modules that the server implements to satisfy "import-by-revision" and these are stated in the implemented schema anyway. > I prefer to keep the conformance leaf and not change the module list. > > NMDA needs to be possible to implement with a single schema tree such > that a module > is implemented in all datastores, or a subset of all datastores.  > Otherwise it probably won't > get supported in clients. All solutions accommodate this requirement. For me, some of the interesting design questions have revolved around: - is it better to reduce duplication in the list of modules reported at the cost of increased model complexity? - does the solution extend to schema mount? - how well does the solution cope with with configuration datastores that support very different sets of modules? To a lesser extent we have also been considering how well the solution extends to packaging and semantic versioning, but I think that it is quite tricky to know who these are going to pan out. E.g. I think that the restriction that a given schema will only implement a single revision of a module will end up still holding, but I'm not sure that everyone has that same view point. Thanks, Rob > > > Andy > > > > On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen > wrote: > > CC-ing NETCONF, where the draft is being worked on. > > Kent > > > On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote: > > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote: > > > > > > Yes. The default value for yang-library-datastore leaf is > ds:operational > > > (the only possible one for the ds:operational datastore). This > is backward > > > compatible. If one needs different model for 'running', etc. > then a new > > > datastore identity has to be defined  and set in place of the > default value. > > > Then this identity can be used to read the yang-library data with > > > . > > > > > > > Sorry, but I have to ask this: How do I obtain the schema for the > > datastore (lets call it ) that reports the > schema for > > ? Is there another datastore? > Will > > the recursion end? Perhaps it does since > > might have itself listed as the schema defining datastore. I guess > > Lada will like these kind of meta and meta-meta datastores. > > Not really. Metadata needn't be in datastores. > > Lada > > > > > /js > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e= > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------72EB40BA8927C7E67E2F34CA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,


On 08/12/2017 18:01, Andy Bierman wrote:
Hi,

A library per datastore sounds too complicated.
I prefer the proposal that was made at the IETF meeting that had
a 'not-implemented-in' leaf-list and a single module list.
The use case that this particular design doesn't work particularly well for is if you have a dynamic datastore that just contains a few modules that are not supported via the conventional datastores.

I think that there are future uses cases where the set of modules used for a dynamic datastore could be really quite different and separate from conventional configuration.  E.g. if dynamic subscribers were managed through a dynamic configuration datastore rather than RADIUS.


Why is it interesting to have a separate module list for regular modules and imported modules?
Several reasons:
1) It means that the list of implemented modules have a single key and hence any references to an implemented module are cleaner/simpler.
2) The model structure naturally more strictly enforces that only a single revision/version of a module is implemented.  (E.g. it prevents a server stating that two revisions of a module are both implemented).
3) I genuinely think that the list of implemented modules is more interesting to the client than the imported, but not implemented modules.

For a server, I would design it to "implement" one revision of every module that it uses (including those that don't contain any data nodes, RPCs, actions, notifications, or deviations), and then the "import-only" list becomes the list of modules that the server implements to satisfy "import-by-revision" and these are stated in the implemented schema anyway.


I prefer to keep the conformance leaf and not change the module list.

NMDA needs to be possible to implement with a single schema tree such that a module
is implemented in all datastores, or a subset of all datastores.  Otherwise it probably won't
get supported in clients.
All solutions accommodate this requirement.

For me, some of the interesting design questions have revolved around:
- is it better to reduce duplication in the list of modules reported at the cost of increased model complexity?
- does the solution extend to schema mount?
- how well does the solution cope with with configuration datastores that support very different sets of modules?

To a lesser extent we have also been considering how well the solution extends to packaging and semantic versioning, but I think that it is quite tricky to know who these are going to pan out.  E.g. I think that the restriction that a given schema will only implement a single revision of a module will end up still holding, but I'm not sure that everyone has that same view point.

Thanks,
Rob




Andy



On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen <kwatsen@juniper.net> wrote:
CC-ing NETCONF, where the draft is being worked on.

Kent


On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote:
> On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote:
> >
> > Yes. The default value for yang-library-datastore leaf is ds:operational
> > (the only possible one for the ds:operational datastore). This is backward
> > compatible. If one needs different model for 'running', etc. then a new
> > datastore identity has to be defined  and set in place of the default value.
> > Then this identity can be used to read the yang-library data with
> > <get-data>.
> >
>
> Sorry, but I have to ask this: How do I obtain the schema for the
> datastore (lets call it <running-library>) that reports the schema for
> <running>? Is there another <running-library-library> datastore? Will
> the recursion end? Perhaps it does since <running-library-library>
> might have itself listed as the schema defining datastore. I guess
> Lada will like these kind of meta and meta-meta datastores.

Not really. Metadata needn't be in datastores.

Lada

>
> /js
>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e=


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



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

--------------72EB40BA8927C7E67E2F34CA-- From nobody Mon Dec 11 03:16: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 3EBDC124BE8; Mon, 11 Dec 2017 03:16:29 -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 v6YGbLF6cYZi; Mon, 11 Dec 2017 03:16:27 -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 61C70120721; Mon, 11 Dec 2017 03:16:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6991; q=dns/txt; s=iport; t=1512990986; x=1514200586; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=5kjSd3jH59ZldufV7PYlKd9u4VaEx0ebwfr9PHOf9mI=; b=G5ib0b0CQOvHyxYpr2jAtXNlAHrdQKOXRd1F5yf4QhbrP1GxgN5WiRUR 3IgAF04DeAD6VEUDBLJvcQXwERkcArrL9d8+u2rE0EikCT90f+CwOwqao zhok9nkWeyIGtT/u2I3Lsv4E5D6hKpUJY1wnfZN31XO735l8bCAQ8cQ+v E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DSAAAKaC5a/xbLJq1SCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGEJHQnhAKKIXSPVi+XDIIVChgLhElPAoUuGAEBAQEBAQEBAWs?= =?us-ascii?q?ohSIBAQEBAgEBASEPAQU2CxALGAICIwMCAicfEQYBDAYCAQEXigUIEKdDgieKY?= =?us-ascii?q?wEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BD4JZg2GBaSmDAoR1FBaDFYJjBaMRh3m?= =?us-ascii?q?NKIIWY4kYJIcujl+Hf4E7HzmBTzIaCBsVOoIpCYJJHIFnQTeJZwEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,391,1508803200"; d="scan'208";a="824856" 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; 11 Dec 2017 11:16:24 +0000 Received: from [10.63.23.92] (dhcp-ensft1-uk-vla370-10-63-23-92.cisco.com [10.63.23.92]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vBBBGNMl020129; Mon, 11 Dec 2017 11:16:24 GMT To: Vladimir Vassilev , Andy Bierman , Kent Watsen Cc: "netconf@ietf.org" , "netmod@ietf.org" References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> <9b62952b-d3e6-2db2-6aac-9a544a991078@transpacket.com> From: Robert Wilton Message-ID: <3aac1b82-9cfb-97af-cecb-c469587c37d1@cisco.com> Date: Mon, 11 Dec 2017 11:16:23 +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: <9b62952b-d3e6-2db2-6aac-9a544a991078@transpacket.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Netconf] [netmod] 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, 11 Dec 2017 11:16:29 -0000 Hi Vladimir, On 09/12/2017 11:49, Vladimir Vassilev wrote: > On 12/08/2017 07:01 PM, Andy Bierman wrote: > >> Hi, >> >> A library per datastore sounds too complicated. > I am not proposing that. I'm slightly lost, because I thought that was exactly what you were proposing! ;-) > > > The fundamental point proposed is that the datastore relevant bits are > kept in the ietf-datastores module instead of merging everything in a > new ietf-yang-library entangled monster module. If needed > ietf-datastores can augment ietf-yang-library but ietf-yang-library > should be usable on its own without ietf-datastores. The solution is > coherent and modular and addresses the problem statement. The issue with this is that datastore augmentations to YANG library would end up changing the meaning of the existing YANG library nodes.  E.g. an old client that ignores the datastore augmentations is going to get a nasty surprise when the server does not behave how it expects.  E.g. because the configuration node that it thinks should be there isn't there because it only supported in . This was one of the reasons for changing YANG library. In terms of the idea of just re-using YANG library but export a separate copy for each datastore I think that this has its own problems: - I don't like the idea of returning meta-data along with configuration for a on any of the configuration datastores. - How does a client know whether the YANG library for applies to the whole server (as it does today) vs just applies to the datastore (as it would for an NMDA server)? - It requires more handshaking between the client and server to get the schema, since a separate request would be required for each datastore that is supported. So, for me, I think that the only way that this solution works, would be to define a new RPC, but even then I think that it would make sense to combine the data together into a new YANG library structure. At the end of the day, I don't think that a new YANG library is going to be were the real cost for supporting NMDA comes from.  I think that the real work is supporting independently from both in the client and servers. But I also think that once servers start implementing this properly that it will simplify automation, because rather than a client having to guess what state a server is in, it can actually querey, or be notified of it, without having to write a lot of model specific code. Thanks, Rob >> I prefer the proposal that was made at the IETF meeting that had >> a 'not-implemented-in' leaf-list and a single module list. > This constraint is already specified in the text of the revised > datastores draft. Clients conforming to the draft can expect servers > to comply with the MUST requirement even if there is a separate > yang-library data tree for each datastore the constraint of > configuration stores mapping to 'operational' should be enforced > according to the draft. There is no contradiction here. > > That said I would be also be OK with ietf-datastores augmenting > ietf-yang-library with such a leaf-list ('not-implemented-in' > leaf-list) as a more constrained flavor of the same approach instead > of going for independent copies of yang-library data. For any of that > to happen change in ietf-datastores.yang is needed and change in the > original rfc7895 ietf-yang-library is not needed at all. > > Vladimir > >> >> Why is it interesting to have a separate module list for regular >> modules and imported modules? >> I prefer to keep the conformance leaf and not change the module list. >> >> NMDA needs to be possible to implement with a single schema tree such >> that a module >> is implemented in all datastores, or a subset of all datastores.  >> Otherwise it probably won't >> get supported in clients. >> >> >> Andy >> >> >> >> On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen > > wrote: >> >>     CC-ing NETCONF, where the draft is being worked on. >> >>     Kent >> >> >>     On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote: >>     > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote: >>     > > >>     > > Yes. The default value for yang-library-datastore leaf is >>     ds:operational >>     > > (the only possible one for the ds:operational datastore). This >>     is backward >>     > > compatible. If one needs different model for 'running', etc. >>     then a new >>     > > datastore identity has to be defined  and set in place of the >>     default value. >>     > > Then this identity can be used to read the yang-library data >> with >>     > > . >>     > > >>     > >>     > Sorry, but I have to ask this: How do I obtain the schema for the >>     > datastore (lets call it ) that reports the >>     schema for >>     > ? Is there another datastore? >>     Will >>     > the recursion end? Perhaps it does since >>     > might have itself listed as the schema defining datastore. I guess >>     > Lada will like these kind of meta and meta-meta datastores. >> >>     Not really. Metadata needn't be in datastores. >> >>     Lada >> >>     > >>     > /js >>     > >>     -- >>     Ladislav Lhotka >>     Head, CZ.NIC Labs >>     PGP Key ID: 0xB8F92B08A9F76C67 >> >>     _______________________________________________ >>     netmod mailing list >>     netmod@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e= >> >> >> >>     _______________________________________________ >>     netmod mailing list >>     netmod@ietf.org >>     https://www.ietf.org/mailman/listinfo/netmod >>     >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Mon Dec 11 07:53: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 9169E126DFF; Mon, 11 Dec 2017 07:53:37 -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 YoI6pvKcwKxi; Mon, 11 Dec 2017 07:53:34 -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 C6D52126B71; Mon, 11 Dec 2017 07:53:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 4F2231521335; Mon, 11 Dec 2017 16:53:31 +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 AVJ-_334inVi; Mon, 11 Dec 2017 16:53:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 220BA1521331; Mon, 11 Dec 2017 16:53:31 +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 0YNE3TS80wio; Mon, 11 Dec 2017 16:53:31 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id EC762921E25; Mon, 11 Dec 2017 16:53:30 +0100 (CET) To: Robert Wilton , "netmod@ietf.org" , Netconf References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> <9b62952b-d3e6-2db2-6aac-9a544a991078@transpacket.com> <3aac1b82-9cfb-97af-cecb-c469587c37d1@cisco.com> From: Vladimir Vassilev Message-ID: <137c9dac-acb8-69ba-6b9d-20c92d5aeec0@transpacket.com> Date: Mon, 11 Dec 2017 16:53:30 +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: <3aac1b82-9cfb-97af-cecb-c469587c37d1@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] [netmod] 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, 11 Dec 2017 15:53:37 -0000 On 12/11/2017 12:16 PM, Robert Wilton wrote: > Hi Vladimir, > > > On 09/12/2017 11:49, Vladimir Vassilev wrote: >> On 12/08/2017 07:01 PM, Andy Bierman wrote: >> >>> Hi, >>> >>> A library per datastore sounds too complicated. >> I am not proposing that. > I'm slightly lost, because I thought that was exactly what you were=20 > proposing! ;-) I propose a solution that keeps ietf-yang-library a data model of a=20 single YANG context specification doing the datastore specific modeling=20 in ietf-datastores model instead. The solution can be both flexible=20 (independent yang-library data instances per datastore as my example was=20 focused on) or constrained ('not-implemented-in' modules leaf-list).=20 Here is everything that is needed: module: ietf-datastores =C2=A0=C2=A0=C2=A0 +--ro datastores-state =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro datastore* [name] =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro (model)? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(same-as-oper= ational) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(constrained-= to-operational) =C2=A0=C2=A0=C2=A0=C2=A0=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 ->=20 /yanglib:module-state/module/name =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(unconstraine= d) =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 yang-library-datastore?=C2=A0=C2=A0 identityref YANG: ... container datastores-state { =C2=A0=C2=A0=C2=A0 config false; =C2=A0=C2=A0=C2=A0 list datastore { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key name; =C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0 choice model { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case same-as-operational { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case constrained-to-operation= al { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf-list not-imp= lemented-in { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type = leafref { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 path "/yanglib:module-state/yanglib:module/yanglib: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=C2=A0=C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case unconstrained { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf yang-library= -datastore { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type = identityref { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 base ds:datastore; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } =C2=A0=C2=A0=C2=A0 } =C2=A0 } ... IMO ietf-yang-library as defined in rfc7895 is modular and reusable. I=20 do not see why this has to be compromised. >> >> The fundamental point proposed is that the datastore relevant bits=20 >> are kept in the ietf-datastores module instead of merging everything=20 >> in a new ietf-yang-library entangled monster module. If needed=20 >> ietf-datastores can augment ietf-yang-library but ietf-yang-library=20 >> should be usable on its own without ietf-datastores. The solution is=20 >> coherent and modular and addresses the problem statement. > > The issue with this is that datastore augmentations to YANG library=20 > would end up changing the meaning of the existing YANG library nodes.=C2= =A0=20 > E.g. an old client that ignores the datastore augmentations is going=20 > to get a nasty surprise when the server does not behave how it=20 > expects.=C2=A0 E.g. because the configuration node that it thinks shoul= d be=20 > there isn't there because it only supported in . > > This was one of the reasons for changing YANG library. A well written client that finds out unsupported newer versions of=20 ietf-yang-library (which is reported in the capabilities) or any of the=20 NMDA modules is deployed should not do any damage. How exactly did you=20 solve the problem for the bad clients by changing the structure of=20 yang-library in a incompatible way is something I do not understand. > > In terms of the idea of just re-using YANG library but export a=20 > separate copy for each datastore I think that this has its own problems= : > - I don't like the idea of returning meta-data along with=20 > configuration for a on any of the configuration datastores. There is no meta data. The datastores contain only the config false;=20 /modules-state tree. I think I explained that very clearly. > - How does a client know whether the YANG library for =20 > applies to the whole server (as it does today) vs just applies to the=20 > datastore (as it would for an NMDA server)? All datastore models are "case same-as-operational" for such systems. > - It requires more handshaking between the client and server to get=20 > the schema, since a separate request would be required for each=20 > datastore that is supported. Correct. Flexibility and modularity come at a price. IMO modularity is=20 more important in this case. And there are solutions for the problem=20 e.g. send all requests before waiting for replies. NETCONF=20 supports this. > > So, for me, I think that the only way that this solution works, would=20 > be to define a new RPC, but even then I think=20 > that it would make sense to combine the data together into a new YANG=20 > library structure. As I said my focus is on keeping ietf-yang-library modular (single YANG=20 model context). or just adding datastore=20 identities allowing the client to use to achieve the=20 retrieval of the data is of little importance to me. > > At the end of the day, I don't think that a new YANG library is going=20 > to be were the real cost for supporting NMDA comes from.=C2=A0 I think = that=20 > the real work is supporting independently from =20 > both in the client and servers. But I also think that once servers=20 > start implementing this properly that it will simplify automation,=20 > because rather than a client having to guess what state a server is=20 > in, it can actually querey, or be notified of it, without having to=20 > write a lot of model specific code. +1 Vladimir > > Thanks, > Rob > > >>> I prefer the proposal that was made at the IETF meeting that had >>> a 'not-implemented-in' leaf-list and a single module list. >> This constraint is already specified in the text of the revised=20 >> datastores draft. Clients conforming to the draft can expect servers=20 >> to comply with the MUST requirement even if there is a separate=20 >> yang-library data tree for each datastore the constraint of=20 >> configuration stores mapping to 'operational' should be enforced=20 >> according to the draft. There is no contradiction here. >> >> That said I would be also be OK with ietf-datastores augmenting=20 >> ietf-yang-library with such a leaf-list ('not-implemented-in'=20 >> leaf-list) as a more constrained flavor of the same approach instead=20 >> of going for independent copies of yang-library data. For any of that=20 >> to happen change in ietf-datastores.yang is needed and change in the=20 >> original rfc7895 ietf-yang-library is not needed at all. >> >> Vladimir >> >>> >>> Why is it interesting to have a separate module list for regular=20 >>> modules and imported modules? >>> I prefer to keep the conformance leaf and not change the module list. >>> >>> NMDA needs to be possible to implement with a single schema tree=20 >>> such that a module >>> is implemented in all datastores, or a subset of all datastores.=C2=A0= =20 >>> Otherwise it probably won't >>> get supported in clients. >>> >>> >>> Andy >>> >>> >>> >>> On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen >> > wrote: >>> >>> =C2=A0=C2=A0=C2=A0 CC-ing NETCONF, where the draft is being worked on= . >>> >>> =C2=A0=C2=A0=C2=A0 Kent >>> >>> >>> =C2=A0=C2=A0=C2=A0 On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenw= aelder wrote: >>> =C2=A0=C2=A0=C2=A0 > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladim= ir Vassilev=20 >>> wrote: >>> =C2=A0=C2=A0=C2=A0 > > >>> =C2=A0=C2=A0=C2=A0 > > Yes. The default value for yang-library-datast= ore leaf is >>> =C2=A0=C2=A0=C2=A0 ds:operational >>> =C2=A0=C2=A0=C2=A0 > > (the only possible one for the ds:operational = datastore). This >>> =C2=A0=C2=A0=C2=A0 is backward >>> =C2=A0=C2=A0=C2=A0 > > compatible. If one needs different model for '= running', etc. >>> =C2=A0=C2=A0=C2=A0 then a new >>> =C2=A0=C2=A0=C2=A0 > > datastore identity has to be defined=C2=A0 and= set in place of the >>> =C2=A0=C2=A0=C2=A0 default value. >>> =C2=A0=C2=A0=C2=A0 > > Then this identity can be used to read the yan= g-library data=20 >>> with >>> =C2=A0=C2=A0=C2=A0 > > . >>> =C2=A0=C2=A0=C2=A0 > > >>> =C2=A0=C2=A0=C2=A0 > >>> =C2=A0=C2=A0=C2=A0 > Sorry, but I have to ask this: How do I obtain t= he schema for the >>> =C2=A0=C2=A0=C2=A0 > datastore (lets call it ) that = reports the >>> =C2=A0=C2=A0=C2=A0 schema for >>> =C2=A0=C2=A0=C2=A0 > ? Is there another datastore? >>> =C2=A0=C2=A0=C2=A0 Will >>> =C2=A0=C2=A0=C2=A0 > the recursion end? Perhaps it does since=20 >>> >>> =C2=A0=C2=A0=C2=A0 > might have itself listed as the schema defining = datastore. I=20 >>> guess >>> =C2=A0=C2=A0=C2=A0 > Lada will like these kind of meta and meta-meta = datastores. >>> >>> =C2=A0=C2=A0=C2=A0 Not really. Metadata needn't be in datastores. >>> >>> =C2=A0=C2=A0=C2=A0 Lada >>> >>> =C2=A0=C2=A0=C2=A0 > >>> =C2=A0=C2=A0=C2=A0 > /js >>> =C2=A0=C2=A0=C2=A0 > >>> =C2=A0=C2=A0=C2=A0 -- >>> =C2=A0=C2=A0=C2=A0 Ladislav Lhotka >>> =C2=A0=C2=A0=C2=A0 Head, CZ.NIC Labs >>> =C2=A0=C2=A0=C2=A0 PGP Key ID: 0xB8F92B08A9F76C67 >>> >>> =C2=A0=C2=A0=C2=A0 _______________________________________________ >>> =C2=A0=C2=A0=C2=A0 netmod mailing list >>> =C2=A0=C2=A0=C2=A0 netmod@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voD= TXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D5qj6BQUSwqYm= kAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=3DI7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRr= vQI5l8&e=3D=20 >>> >>> =20 >>> >>> >>> >>> =C2=A0=C2=A0=C2=A0 _______________________________________________ >>> =C2=A0=C2=A0=C2=A0 netmod mailing list >>> =C2=A0=C2=A0=C2=A0 netmod@ietf.org >>> =C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/netmod >>> =C2=A0=C2=A0=C2=A0 >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf > From nobody Mon Dec 11 08:17: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 68DE3126DEE; Mon, 11 Dec 2017 08:17: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 BMpnbDLxCFIN; Mon, 11 Dec 2017 08:17:30 -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 94441126D73; Mon, 11 Dec 2017 08:17:30 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E36E269A; Mon, 11 Dec 2017 17:17:28 +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 ap06WK_SdQYN; Mon, 11 Dec 2017 17:17:25 +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, 11 Dec 2017 17:17:28 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CDFF92012E; Mon, 11 Dec 2017 17:17:28 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hV-QL91UCLau; Mon, 11 Dec 2017 17:17:27 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 326C820129; Mon, 11 Dec 2017 17:17:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F33E3419454C; Mon, 11 Dec 2017 17:15:56 +0100 (CET) Date: Mon, 11 Dec 2017 17:15:56 +0100 From: Juergen Schoenwaelder To: Vladimir Vassilev Cc: Robert Wilton , "netmod@ietf.org" , Netconf Message-ID: <20171211161556.me7thzsos2ywai3r@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Vladimir Vassilev , Robert Wilton , "netmod@ietf.org" , Netconf References: <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> <9b62952b-d3e6-2db2-6aac-9a544a991078@transpacket.com> <3aac1b82-9cfb-97af-cecb-c469587c37d1@cisco.com> <137c9dac-acb8-69ba-6b9d-20c92d5aeec0@transpacket.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: <137c9dac-acb8-69ba-6b9d-20c92d5aeec0@transpacket.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Netconf] [netmod] 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, 11 Dec 2017 16:17:33 -0000 I do not fully understand why you think it is worth to preserve the old YANG module library structure. Clearly, it won't be backwards compatible since an NMDA implementation may list modules that are not implemented in all datastores and an old client talking to a new server will thus misunderstand what is exposed via the old YANG module library structure. Your proposal "looks" backwards compatible but it is not if one takes a closer look. One can start making changes to say the conformance-type but then this does not solve the problem since an old client does not know what a new conformance type value means. The design team did look into the option of keeping the old structure unchanged some weeks ago and we finally arrived at the conclusion that it gets (i) ugly and (ii) does not really provide backwards compatibility for a client written agains the old YANG module library structure. Note that with the new proposals on the table, it should be possible to provide a backwards compatible view on YANG library for systems that implement the exact same module set (with the exact same set of features and deviations) on all datastores they support. But for systems where this is not true, it seems better to use new definitions instead of tweaking semantics. Perhaps it helps if you can clearly phrase the objective of keeping the old structure. What is the goal you want to achieve with that? /js On Mon, Dec 11, 2017 at 04:53:30PM +0100, Vladimir Vassilev wrote: > On 12/11/2017 12:16 PM, Robert Wilton wrote: > > > Hi Vladimir, > > > > > > On 09/12/2017 11:49, Vladimir Vassilev wrote: > > > On 12/08/2017 07:01 PM, Andy Bierman wrote: > > > > > > > Hi, > > > > > > > > A library per datastore sounds too complicated. > > > I am not proposing that. > > I'm slightly lost, because I thought that was exactly what you were > > proposing! ;-) > I propose a solution that keeps ietf-yang-library a data model of a single > YANG context specification doing the datastore specific modeling in > ietf-datastores model instead. The solution can be both flexible > (independent yang-library data instances per datastore as my example was > focused on) or constrained ('not-implemented-in' modules leaf-list). Here is > everything that is needed: > > module: ietf-datastores >     +--ro datastores-state >        +--ro datastore* [name] >        +--ro (model)? >           +--:(same-as-operational) >           +--:(constrained-to-operational) >           |  +--ro not-implemented-in*       -> > /yanglib:module-state/module/name >           +--:(unconstrained) >              +--ro yang-library-datastore?   identityref > > YANG: > ... > container datastores-state { >     config false; >     list datastore { >       key name; >     } >     choice model { >         case same-as-operational { >         } >         case constrained-to-operational { >           leaf-list not-implemented-in { >             type leafref { >               path "/yanglib:module-state/yanglib:module/yanglib:name"; >             } >           } >         } >         case unconstrained { >           leaf yang-library-datastore { >             type identityref { >               base ds:datastore; >           } >         } >       } >     } >   } > ... > > IMO ietf-yang-library as defined in rfc7895 is modular and reusable. I do > not see why this has to be compromised. > > > > > > The fundamental point proposed is that the datastore relevant bits > > > are kept in the ietf-datastores module instead of merging everything > > > in a new ietf-yang-library entangled monster module. If needed > > > ietf-datastores can augment ietf-yang-library but ietf-yang-library > > > should be usable on its own without ietf-datastores. The solution is > > > coherent and modular and addresses the problem statement. > > > > The issue with this is that datastore augmentations to YANG library > > would end up changing the meaning of the existing YANG library nodes.  > > E.g. an old client that ignores the datastore augmentations is going to > > get a nasty surprise when the server does not behave how it expects.  > > E.g. because the configuration node that it thinks should be there isn't > > there because it only supported in . > > > > This was one of the reasons for changing YANG library. > A well written client that finds out unsupported newer versions of > ietf-yang-library (which is reported in the capabilities) or any of the NMDA > modules is deployed should not do any damage. How exactly did you solve the > problem for the bad clients by changing the structure of yang-library in a > incompatible way is something I do not understand. > > > > In terms of the idea of just re-using YANG library but export a separate > > copy for each datastore I think that this has its own problems: > > - I don't like the idea of returning meta-data along with configuration > > for a on any of the configuration datastores. > There is no meta data. The datastores contain only the config false; > /modules-state tree. I think I explained that very clearly. > > - How does a client know whether the YANG library for applies > > to the whole server (as it does today) vs just applies to the > > datastore (as it would for an NMDA server)? > All datastore models are "case same-as-operational" for such systems. > > - It requires more handshaking between the client and server to get the > > schema, since a separate request would be required for each datastore > > that is supported. > Correct. Flexibility and modularity come at a price. IMO modularity is more > important in this case. And there are solutions for the problem e.g. send > all requests before waiting for replies. NETCONF supports this. > > > > So, for me, I think that the only way that this solution works, would be > > to define a new RPC, but even then I think that it > > would make sense to combine the data together into a new YANG library > > structure. > As I said my focus is on keeping ietf-yang-library modular (single YANG > model context). or just adding datastore identities > allowing the client to use to achieve the retrieval of the data > is of little importance to me. > > > > > At the end of the day, I don't think that a new YANG library is going to > > be were the real cost for supporting NMDA comes from.  I think that the > > real work is supporting independently from both > > in the client and servers. But I also think that once servers start > > implementing this properly that it will simplify automation, because > > rather than a client having to guess what state a server is in, it can > > actually querey, or be notified of it, without having to write a lot of > > model specific code. > +1 > > Vladimir > > > > Thanks, > > Rob > > > > > > > > I prefer the proposal that was made at the IETF meeting that had > > > > a 'not-implemented-in' leaf-list and a single module list. > > > This constraint is already specified in the text of the revised > > > datastores draft. Clients conforming to the draft can expect servers > > > to comply with the MUST requirement even if there is a separate > > > yang-library data tree for each datastore the constraint of > > > configuration stores mapping to 'operational' should be enforced > > > according to the draft. There is no contradiction here. > > > > > > That said I would be also be OK with ietf-datastores augmenting > > > ietf-yang-library with such a leaf-list ('not-implemented-in' > > > leaf-list) as a more constrained flavor of the same approach instead > > > of going for independent copies of yang-library data. For any of > > > that to happen change in ietf-datastores.yang is needed and change > > > in the original rfc7895 ietf-yang-library is not needed at all. > > > > > > Vladimir > > > > > > > > > > > Why is it interesting to have a separate module list for regular > > > > modules and imported modules? > > > > I prefer to keep the conformance leaf and not change the module list. > > > > > > > > NMDA needs to be possible to implement with a single schema tree > > > > such that a module > > > > is implemented in all datastores, or a subset of all > > > > datastores.  Otherwise it probably won't > > > > get supported in clients. > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen > > > > wrote: > > > > > > > >     CC-ing NETCONF, where the draft is being worked on. > > > > > > > >     Kent > > > > > > > > > > > >     On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote: > > > >     > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir > > > > Vassilev wrote: > > > >     > > > > > >     > > Yes. The default value for yang-library-datastore leaf is > > > >     ds:operational > > > >     > > (the only possible one for the ds:operational datastore). This > > > >     is backward > > > >     > > compatible. If one needs different model for 'running', etc. > > > >     then a new > > > >     > > datastore identity has to be defined  and set in place of the > > > >     default value. > > > >     > > Then this identity can be used to read the yang-library > > > > data with > > > >     > > . > > > >     > > > > > >     > > > > >     > Sorry, but I have to ask this: How do I obtain the schema for the > > > >     > datastore (lets call it ) that reports the > > > >     schema for > > > >     > ? Is there another datastore? > > > >     Will > > > >     > the recursion end? Perhaps it does since > > > > > > > >     > might have itself listed as the schema defining datastore. > > > > I guess > > > >     > Lada will like these kind of meta and meta-meta datastores. > > > > > > > >     Not really. Metadata needn't be in datastores. > > > > > > > >     Lada > > > > > > > >     > > > > >     > /js > > > >     > > > > >     -- > > > >     Ladislav Lhotka > > > >     Head, CZ.NIC Labs > > > >     PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > >     _______________________________________________ > > > >     netmod mailing list > > > >     netmod@ietf.org > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e= > > > > > > > > > > > > > > > > > > > > > > > >     _______________________________________________ > > > >     netmod mailing list > > > >     netmod@ietf.org > > > >     https://www.ietf.org/mailman/listinfo/netmod > > > >     > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Dec 11 08:37: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 AB553127076; Mon, 11 Dec 2017 08:37:51 -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 xnDfXUiRcVYD; Mon, 11 Dec 2017 08:37:49 -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 171C4126DEE; Mon, 11 Dec 2017 08:37:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8553; q=dns/txt; s=iport; t=1513010269; x=1514219869; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=EsV8cq/hoXqt4q6VEFBpss8vZiaijQw+q7bp/fcErjc=; b=fqX1xTJzSSAXPfsGEO2MtyFksMApT/X1B8GYl8smjFHYq6QQoSEDfTcE TL6VdEuOYnS9H09mdX5c9ANKUmY5SA4nhbYcplZuQ7Lh67yP61EXF0jzz zC68onknSnMNspA4GAN2QOB7VC9jTsTkgYvlcxQ9g8YCTsFU/nn4uILG0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQAZsy5a/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUYhCmLFY9XCSaXDIIVCoU7AoUzFgEBAQEBAQEBAWsohSMBBSM?= =?us-ascii?q?ECwEFUQkCGAICJgICVwYBDAgBAReKDYo0nWyBbTqKZAEBAQEBAQEDAQEBAQEBA?= =?us-ascii?q?SGBD4JZfYJkgWkpC4FpgQ6FCYMrgmMFkg+RApUhjBGHUo5fh3+BOyYGLIFPMho?= =?us-ascii?q?IGxU6giqCURyBZ0GKFgEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,392,1508803200"; d="scan'208";a="785658" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2017 16:37:47 +0000 Received: from [10.63.23.92] (dhcp-ensft1-uk-vla370-10-63-23-92.cisco.com [10.63.23.92]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vBBGbkaA028335; Mon, 11 Dec 2017 16:37:46 GMT To: Vladimir Vassilev , "netmod@ietf.org" , Netconf References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> <9b62952b-d3e6-2db2-6aac-9a544a991078@transpacket.com> <3aac1b82-9cfb-97af-cecb-c469587c37d1@cisco.com> <137c9dac-acb8-69ba-6b9d-20c92d5aeec0@transpacket.com> From: Robert Wilton Message-ID: <516c0470-cf99-6761-f73c-9b1806b0de66@cisco.com> Date: Mon, 11 Dec 2017 16:37:46 +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: <137c9dac-acb8-69ba-6b9d-20c92d5aeec0@transpacket.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Netconf] [netmod] 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, 11 Dec 2017 16:37:51 -0000 On 11/12/2017 15:53, Vladimir Vassilev wrote: > On 12/11/2017 12:16 PM, Robert Wilton wrote: > >> Hi Vladimir, >> >> >> On 09/12/2017 11:49, Vladimir Vassilev wrote: >>> On 12/08/2017 07:01 PM, Andy Bierman wrote: >>> >>>> Hi, >>>> >>>> A library per datastore sounds too complicated. >>> I am not proposing that. >> I'm slightly lost, because I thought that was exactly what you were >> proposing! ;-) > I propose a solution that keeps ietf-yang-library a data model of a > single YANG context specification doing the datastore specific > modeling in ietf-datastores model instead. The solution can be both > flexible (independent yang-library data instances per datastore as my > example was focused on) or constrained ('not-implemented-in' modules > leaf-list). Here is everything that is needed: > > module: ietf-datastores >     +--ro datastores-state >        +--ro datastore* [name] >        +--ro (model)? >           +--:(same-as-operational) >           +--:(constrained-to-operational) >           |  +--ro not-implemented-in*       -> > /yanglib:module-state/module/name >           +--:(unconstrained) >              +--ro yang-library-datastore?   identityref > > YANG: > ... > container datastores-state { >     config false; >     list datastore { >       key name; >     } >     choice model { >         case same-as-operational { >         } >         case constrained-to-operational { >           leaf-list not-implemented-in { >             type leafref { >               path "/yanglib:module-state/yanglib:module/yanglib:name"; >             } >           } >         } >         case unconstrained { >           leaf yang-library-datastore { >             type identityref { >               base ds:datastore; >           } >         } >       } >     } >   } > ... > > IMO ietf-yang-library as defined in rfc7895 is modular and reusable. I > do not see why this has to be compromised. But a major version change to YANG library is happening here. In rfc7895, if a module is implemented then it is implemented in all configuration datastores, and doesn't exist. Alas, that is not what is required for NMDA, it needs different semantics with more granularity.  You cannot achieve this without changing the meaning of the existing YANG library data nodes, which will break clients. >>> >>> The fundamental point proposed is that the datastore relevant bits >>> are kept in the ietf-datastores module instead of merging everything >>> in a new ietf-yang-library entangled monster module. If needed >>> ietf-datastores can augment ietf-yang-library but ietf-yang-library >>> should be usable on its own without ietf-datastores. The solution is >>> coherent and modular and addresses the problem statement. >> >> The issue with this is that datastore augmentations to YANG library >> would end up changing the meaning of the existing YANG library >> nodes.  E.g. an old client that ignores the datastore augmentations >> is going to get a nasty surprise when the server does not behave how >> it expects.  E.g. because the configuration node that it thinks >> should be there isn't there because it only supported in . >> >> This was one of the reasons for changing YANG library. > A well written client that finds out unsupported newer versions of > ietf-yang-library (which is reported in the capabilities) or any of > the NMDA modules is deployed should not do any damage. How exactly did > you solve the problem for the bad clients by changing the structure of > yang-library in a incompatible way is something I do not understand. Servers have a choice: If a server just wants to supports pre NMDA models + RPCs then it would use rfc7895. If a server only wants to support post NMDA models + RPCs + clients, then it can use the new YANG library (and not implement the modules-state container). If a server wants to support old and new clients then there are few choices: (1) Use configuration to control which mode the server is running in. (2) Run separate copies of the mgmt protocols on separate port numbers. (3) Implement the NMDA models, and then publish the schema of , or perhaps , in the modules-state container.  Pre NMDA clients, using would probably not see all system information.  This approach starts to have issues if there are differences between what is configurable and what is in operational. >> >> In terms of the idea of just re-using YANG library but export a >> separate copy for each datastore I think that this has its own problems: >> - I don't like the idea of returning meta-data along with >> configuration for a on any of the configuration datastores. > There is no meta data. The datastores contain only the config false; > /modules-state tree. I think I explained that very clearly. YANG library doesn't represent regular server operational data, but instead it is meta-data about the server instance, which is why it is allowed to differ between NETCONF and RESTCONF (which I don't really like). Yes, you explained returning /modules-state from candidate, running, intended, i2rs, etc.  Unfortunately I really dislike this approach because it feels like a backwards step where we have trying to get a clean split between configuration and state.   Hence defining a RPC would be a better choice. >> - How does a client know whether the YANG library for >> applies to the whole server (as it does today) vs just applies to the >> datastore (as it would for an NMDA server)? > All datastore models are "case same-as-operational" for such systems. This isn't about how the server implements it, but instead my concern is about how the client interacts with it. I appreciate that it avoids a client having to parse a new YANG library, but more concerning for me is that the existing YANG clients will not see the behavior that they expect, and rather than failing, they will work in an unknown degraded fashion. > >> - It requires more handshaking between the client and server to get >> the schema, since a separate request would be required for each >> datastore that is supported. > Correct. Flexibility and modularity come at a price. IMO modularity is > more important in this case. And there are solutions for the problem > e.g. send all requests before waiting for replies. NETCONF > supports this. I perceive that your argument is less about modularity, and instead it seems to be more centered around not making any changes to the structure of the existing YANG library. >> >> So, for me, I think that the only way that this solution works, would >> be to define a new RPC, but even then I think >> that it would make sense to combine the data together into a new YANG >> library structure. > As I said my focus is on keeping ietf-yang-library modular (single > YANG model context). or just adding datastore > identities allowing the client to use to achieve the > retrieval of the data is of little importance to me. This seems to be a complex approach, introducing new protocol semantics, or overloading operations, to avoid revising an existing module structure. I don't think the new proposed YANG library structures are less modular, in fact, I would argue that some of the approaches are designed to make the structure more modular and reusable (e.g. by having named schema). Thanks, Rob > >> >> At the end of the day, I don't think that a new YANG library is going >> to be were the real cost for supporting NMDA comes from. I think that >> the real work is supporting independently from >> both in the client and servers. But I also think that once >> servers start implementing this properly that it will simplify >> automation, because rather than a client having to guess what state a >> server is in, it can actually querey, or be notified of it, without >> having to write a lot of model specific code. > +1 > > Vladimir >> >> Thanks, >> Rob From nobody Mon Dec 11 11:03: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 CD864126D73; Mon, 11 Dec 2017 11:03:03 -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.67.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151301898379.21100.1281220665197948585@ietfa.amsl.com> Date: Mon, 11 Dec 2017 11:03:03 -0800 Archived-At: Subject: [Netconf] I-D Action: draft-ietf-netconf-rfc6536bis-09.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: Mon, 11 Dec 2017 19:03:04 -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 : Network Configuration Access Control Module Authors : Andy Bierman Martin Bjorklund Filename : draft-ietf-netconf-rfc6536bis-09.txt Pages : 56 Date : 2017-12-11 Abstract: The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc6536bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-09 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-rfc6536bis-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-rfc6536bis-09 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 Dec 11 12:55: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 E19601273B1 for ; Mon, 11 Dec 2017 12:55: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 U4U56uzv-yRY for ; Mon, 11 Dec 2017 12:55:32 -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 F25FA1289B0 for ; Mon, 11 Dec 2017 12:55:31 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id f18so20741934lfg.8 for ; Mon, 11 Dec 2017 12:55:31 -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=7fRZLSI/E1KXckeLggr3bqIGezVQEffWLuNcExJF3rM=; b=C2QIdJMbVmU+I8PbaIE/amVY5GDLQVpYtazxBNPBQZtMFAqDThiCPnboCPbfTQvo2k 0wzpWqPGZ+PWz/Q2D3rbpd/bTs9yC4coBum+HWheOw4xe0GVsXlkbDg/bQjno3fP6O4u EPrnMfdSpKySmOCRtfmxyG5qheVLk0atE+dByDa+eizFjSHwsg4CrEhJLK8scUHRTHMN MskyJXem6AyYqmZGHG50tSBBhGKxtXJ36+b19olRI6CzP2fs5UXxSD6F+Ohfiwb1huL0 /EzrXGjmymAq4kp05At3cd7qf6AJSKgVUSVMQ4d44bWyWF+eP4BBXsugEK/NUUH8GI6z Db+g== 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=7fRZLSI/E1KXckeLggr3bqIGezVQEffWLuNcExJF3rM=; b=a58RZ2j3xvIgHok5raxq7A1WJcQqlOpRVC0V3kHWTXUIDF62LdcB1LEQuIo6qb7Dc4 ApZcGUgr4r17pT23eGdArHvDOgVA7WBZt4jQnaerCxI2C/x/XhNaB9R2lzWmC/SYwq4r /++SR491e/Qr1XLlWD4lGgXjZKxNw6SwIlt+wepm3MwB4anVYm6qjMmFgzAU9lprgeYu Yh82Dgcp2su0j6RO1sztM+J6QgMzohVuhiMQV3OLAR257ZZ0tafjqMUig4+7M75nAwxP Mvcaas96NF66fTi6qd83o59HdeJcwqrK3UREFOksaMJOPoG/ucZ37ZwztU2Ptn81uGek A/zw== X-Gm-Message-State: AKGB3mKcLnEp2q8MgFY6CT8lHLWkhPqKDuxaZPwIoWPTiuGhPcxZ9dWc D7Q98BzgjpxwpYAemkE0WyXlhhv80m7wlUdALZNJzQ== X-Google-Smtp-Source: ACJfBouMaGVsjOFZo5wVjlDCd9Rq9xBpMNqOrj3KB6Gz8bgkl8AYs7dGNOoCSzlvTAdqQDl4TZ4xE/iB+91i2gn0pGU= X-Received: by 10.46.70.18 with SMTP id t18mr826704lja.190.1513025730095; Mon, 11 Dec 2017 12:55:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Mon, 11 Dec 2017 12:55:28 -0800 (PST) In-Reply-To: <5242d50f-6f9e-b57e-ec1b-64828c456339@cisco.com> References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> <5242d50f-6f9e-b57e-ec1b-64828c456339@cisco.com> From: Andy Bierman Date: Mon, 11 Dec 2017 12:55:28 -0800 Message-ID: To: Robert Wilton Cc: Kent Watsen , "netmod@ietf.org" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="f403045f771e2dcb01056016c1e9" Archived-At: Subject: Re: [Netconf] [netmod] 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, 11 Dec 2017 20:55:36 -0000 --f403045f771e2dcb01056016c1e9 Content-Type: text/plain; charset="UTF-8" On Mon, Dec 11, 2017 at 2:57 AM, Robert Wilton wrote: > Hi, > > On 08/12/2017 18:01, Andy Bierman wrote: > > Hi, > > A library per datastore sounds too complicated. > I prefer the proposal that was made at the IETF meeting that had > a 'not-implemented-in' leaf-list and a single module list. > > The use case that this particular design doesn't work particularly well > for is if you have a dynamic datastore that just contains a few modules > that are not supported via the conventional datastores. > > I think that there are future uses cases where the set of modules used for > a dynamic datastore could be really quite different and separate from > conventional configuration. E.g. if dynamic subscribers were managed > through a dynamic configuration datastore rather than RADIUS. > > > Why is it interesting to have a separate module list for regular modules > and imported modules? > > Several reasons: > 1) It means that the list of implemented modules have a single key and > hence any references to an implemented module are cleaner/simpler. > IMO you are replacing universally meaningful keys (module-name, revision-date) with an arbitrary name, It is not cleaner and not simpler for a client. 2) The model structure naturally more strictly enforces that only a single > revision/version of a module is implemented. (E.g. it prevents a server > stating that two revisions of a module are both implemented). > How is that the case if the schema list includes its own module list? You mean there is a "unique" statement in the outer list that insures that a module/revision shows up at most once in all instances of the inner module list? > 3) I genuinely think that the list of implemented modules is more > interesting to the client than the imported, but not implemented modules. > The conformance leaf was good enough. Duplicating the module list and removing the conformance leaf is aggressively non-backward compatible. > > For a server, I would design it to "implement" one revision of every > module that it uses (including those that don't contain any data nodes, > RPCs, actions, notifications, or deviations), and then the "import-only" > list becomes the list of modules that the server implements to satisfy > "import-by-revision" and these are stated in the implemented schema anyway. > > > I prefer to keep the conformance leaf and not change the module list. > > NMDA needs to be possible to implement with a single schema tree such that > a module > is implemented in all datastores, or a subset of all datastores. > Otherwise it probably won't > get supported in clients. > > All solutions accommodate this requirement. > Seems to me all new solutions allow a server to violate the MUST in the NMDA draft that there is a superset of all modules. A client has to look for every module in a server-specific set of named schema sets, and then reconcile all these sets. I still prefer the single module list with a conformance leaf and a leaf-list indicating the supported (or unsupported) datastores. > For me, some of the interesting design questions have revolved around: > - is it better to reduce duplication in the list of modules reported at > the cost of increased model complexity? > - does the solution extend to schema mount? > - how well does the solution cope with with configuration datastores that > support very different sets of modules? > > To a lesser extent we have also been considering how well the solution > extends to packaging and semantic versioning, but I think that it is quite > tricky to know who these are going to pan out. E.g. I think that the > restriction that a given schema will only implement a single revision of a > module will end up still holding, but I'm not sure that everyone has that > same view point. > > Thanks, > Rob > > > Andy > > > Andy > > > > On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen wrote: > >> CC-ing NETCONF, where the draft is being worked on. >> >> Kent >> >> >> On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote: >> > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote: >> > > >> > > Yes. The default value for yang-library-datastore leaf is >> ds:operational >> > > (the only possible one for the ds:operational datastore). This is >> backward >> > > compatible. If one needs different model for 'running', etc. then a >> new >> > > datastore identity has to be defined and set in place of the default >> value. >> > > Then this identity can be used to read the yang-library data with >> > > . >> > > >> > >> > Sorry, but I have to ask this: How do I obtain the schema for the >> > datastore (lets call it ) that reports the schema for >> > ? Is there another datastore? Will >> > the recursion end? Perhaps it does since >> > might have itself listed as the schema defining datastore. I guess >> > Lada will like these kind of meta and meta-meta datastores. >> >> Not really. Metadata needn't be in datastores. >> >> Lada >> >> > >> > /js >> > >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet >> f.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh >> 0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTv >> jISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I >> 7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e= >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > > > _______________________________________________ > Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf > > > --f403045f771e2dcb01056016c1e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Dec 11, 2017 at 2:57 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:
=20 =20 =20

Hi,


On 08/12/2017 18:01= , Andy Bierman wrote:
=20
Hi,

A library per datastore sounds too complicated.
I prefer the proposal that was made at the IETF meeting that had
a 'not-implemented-in' leaf-list and a single module l= ist.
The use case that this particular design doesn't work particularly well for is if you have a dynamic datastore that just contains a few modules that are not supported via the conventional datastores.

I think that there are future uses cases where the set of modules used for a dynamic datastore could be really quite different and separate from conventional configuration.=C2=A0 E.g. if dynamic subscribers were managed through a dynamic configuration datastore rather than RADIUS.


Why is it interesting to have a separate module list for regular modules and imported modules?
Several reasons:
1) It means that the list of implemented modules have a single key and hence any references to an implemented module are cleaner/simpler.


IMO you are replacing universally meaningful keys =C2=A0(module-name, re= vision-date) with an arbitrary name,
It is not cleaner and not si= mpler for a client.


2) The model structure naturally more strictly enforces that only a single revision/version of a module is implemented.=C2=A0 (E.g. it prevents a server stating that two revisions of a module are both implemented).


= How is that the case if the schema list includes its own module list?
=
You mean there is a "unique" statement in the outer list tha= t insures that a module/revision
shows up at most once in all ins= tances of the inner module list?

=C2=A0
3) I genuinely think that the list of implemented modules is more interesting to the client than the imported, but not implemented modules.


The c= onformance leaf was good enough.
Duplicating the module list and = removing the conformance leaf is aggressively non-backward compatible.

=C2=A0

For a server, I would design it to "implement" one revision o= f every module that it uses (including those that don't contain any data nodes, RPCs, actions, notifications, or deviations), and then the "import-only" list becomes the list of modules that the serve= r implements to satisfy "import-by-revision" and these are stat= ed in the implemented schema anyway.


I prefer to keep the conformance leaf and not change the module list.

NMDA needs to be possible to implement with a single schema tree such that a module
is implemented in all datastores, or a subset of all datastores.=C2=A0 Otherwise it probably won't
get supported in clients.
All solutions accommodate this requirement.
=

Seems to me all new solutions allow a server = to violate the MUST in the NMDA draft that
there is a superset of= all modules.=C2=A0 A client has to look for every module in a server-speci= fic
set of named schema sets, and then reconcile all these sets.<= /div>
I still prefer the single module list with a conformance leaf and= a leaf-list indicating
the supported (or unsupported) datastores= .



For me, some of the interesting design questions have revolved around:
- is it better to reduce duplication in the list of modules reported at the cost of increased model complexity?
- does the solution extend to schema mount?
- how well does the solution cope with with configuration datastores that support very different sets of modules?

To a lesser extent we have also been considering how well the solution extends to packaging and semantic versioning, but I think that it is quite tricky to know who these are going to pan out.=C2=A0 E.g. I think that the restriction that a given schema will only implement a single revision of a module will end up still holding, but I'm not sure that everyone has that same view point.

Thanks,
Rob




Andy
=C2=A0


Andy



On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen <kwatsen@juniper.net> wrote:
CC-ing NETCONF, where the draft is being worked on.

Kent


On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote:
> On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote:
> >
> > Yes. The default value for yang-library-datastore leaf is ds:operational
> > (the only possible one for the ds:operational datastore). This is backward
> > compatible. If one needs different model for 'running', etc. then a new
> > datastore identity has to be defined=C2=A0 and set in place of the default value.
> > Then this identity can be used to read the yang-library data with
> > <get-data>.
> >
>
> Sorry, but I have to ask this: How do I obtain the schema for the
> datastore (lets call it <running-library>) that reports the schema for
> <running>? Is there another <running-library-library> datastore? Will
> the recursion end? Perhaps it does since <running-library-library>
> might have itself listed as the schema defining datastore. I guess
> Lada will like these kind of meta and meta-meta datastores.

Not really. Metadata needn't be in datastores.

Lada

>
> /js
>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@iet= f.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www= .ietf.org_mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63= rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Y= hqn2gsBYaGTvjISlaJdcZo&m=3D5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5= Cp0RSnxrE&s=3DI7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&= ;e=3D


_______________________________________________
netmod mailing list
netmod@iet= f.org
https://www.ietf.org/mailman/listinfo/n= etmod



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


--f403045f771e2dcb01056016c1e9-- From nobody Tue Dec 12 02:38: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 9FE91129415; Tue, 12 Dec 2017 02:38:05 -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 YfEFADYIqdMC; Tue, 12 Dec 2017 02:38:02 -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 AD3AD128D86; Tue, 12 Dec 2017 02:38:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 5437E154198B; Tue, 12 Dec 2017 11:37:59 +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 RA0tqejBfJH0; Tue, 12 Dec 2017 11:37:59 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 2B88F154198A; Tue, 12 Dec 2017 11:37:59 +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 G8hne69XbXbt; Tue, 12 Dec 2017 11:37:59 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id DE5461541985; Tue, 12 Dec 2017 11:37:58 +0100 (CET) From: Vladimir Vassilev To: Juergen Schoenwaelder , "netmod@ietf.org" , Netconf References: <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> <9b62952b-d3e6-2db2-6aac-9a544a991078@transpacket.com> <3aac1b82-9cfb-97af-cecb-c469587c37d1@cisco.com> <137c9dac-acb8-69ba-6b9d-20c92d5aeec0@transpacket.com> <20171211161556.me7thzsos2ywai3r@elstar.local> Message-ID: <7a0def88-53d3-0c58-a6e3-80b59c87e1bc@transpacket.com> Date: Tue, 12 Dec 2017 11:37:58 +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: <20171211161556.me7thzsos2ywai3r@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Netconf] [netmod] 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, 12 Dec 2017 10:38:06 -0000 On 12/11/2017 05:15 PM, Juergen Schoenwaelder wrote: > I do not fully understand why you think it is worth to preserve the > old YANG module library structure. Clearly, it won't be backwards > compatible since an NMDA implementation may list modules that are not > implemented in all datastores and an old client talking to a new > server will thus misunderstand what is exposed via the old YANG module > library structure. Your proposal "looks" backwards compatible but it > is not if one takes a closer look. > > One can start making changes to say the conformance-type but then this > does not solve the problem since an old client does not know what a > new conformance type value means. The design team did look into the > option of keeping the old structure unchanged some weeks ago and we > finally arrived at the conclusion that it gets (i) ugly and (ii) does > not really provide backwards compatibility for a client written agains > the old YANG module library structure. > > Note that with the new proposals on the table, it should be possible > to provide a backwards compatible view on YANG library for systems > that implement the exact same module set (with the exact same set of > features and deviations) on all datastores they support. But for > systems where this is not true, it seems better to use new > definitions instead of tweaking semantics. > > Perhaps it helps if you can clearly phrase the objective of keeping > the old structure. What is the goal you want to achieve with that? I prefer to call it the current structure for now. I will try to=20 explain. My goal is to efficiently build transactional systems based on=20 YANG models and open standards. For this I need some reusable bricks. Such a brick is the rfc7895=20 ietf-yang-libraray module. Even in a system with multiple YANG model=20 contexts eventually processing breaks down to a single model context=20 e.g. for example a YANG data validation task performed in a command line=20 application comes down to: =C2=A0$ yang-data-validator yang-library-data.xml data.xml The command can be called multiple times for different data and=20 different contexts but it is the same very well tested simple tool. So=20 my point is why can we not use one of the 2 newly introduced methods for=20 instantiating this very well designed model for the needs of NMDA. 1. Use datastore for instantiation. 2. Use schema mount to mount rfc 7895 ietf-yang-library in the=20 ietf-datastores list. (an alternative I assume is especially applicable=20 to modules like ietf-yang-library that are self-contained) In general having a solution that is flexible can easily be trimmed=20 down. Adding special cases that are less flexible e.g. the=20 (not-implemented-in leaf-list or none at all for the case of fully=20 transactional systems with a single model context (no extra work for=20 these)). The advantage is that even with the not-implemented-in=20 leaf-list solution or other diff based the data processing tasks will=20 eventually convert the differential information to a data structure=20 implementing the rfc7895 ietf-yang-library data tree and the=20 yang-data-validator application will be backward compatible and=20 reusable. With changes that introduce a whole new level of abstraction=20 in place of the simple list with module name and revision as keys one=20 can't even reuse the groupings defined in that module and that is a=20 problem I try to avoid. Vladimir > /js > > On Mon, Dec 11, 2017 at 04:53:30PM +0100, Vladimir Vassilev wrote: >> On 12/11/2017 12:16 PM, Robert Wilton wrote: >> >>> Hi Vladimir, >>> >>> >>> On 09/12/2017 11:49, Vladimir Vassilev wrote: >>>> On 12/08/2017 07:01 PM, Andy Bierman wrote: >>>> >>>>> Hi, >>>>> >>>>> A library per datastore sounds too complicated. >>>> I am not proposing that. >>> I'm slightly lost, because I thought that was exactly what you were >>> proposing! ;-) >> I propose a solution that keeps ietf-yang-library a data model of a si= ngle >> YANG context specification doing the datastore specific modeling in >> ietf-datastores model instead. The solution can be both flexible >> (independent yang-library data instances per datastore as my example w= as >> focused on) or constrained ('not-implemented-in' modules leaf-list). H= ere is >> everything that is needed: >> >> module: ietf-datastores >> =C2=A0=C2=A0=C2=A0 +--ro datastores-state >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro datastore* [name] >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro (model)? >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(same-as-o= perational) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(constrain= ed-to-operational) >> =C2=A0=C2=A0=C2=A0=C2=A0=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 -> >> /yanglib:module-state/module/name >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(unconstra= ined) >> =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 yang-library-datastore?=C2=A0=C2=A0 identityref >> >> YANG: >> ... >> container datastores-state { >> =C2=A0=C2=A0=C2=A0 config false; >> =C2=A0=C2=A0=C2=A0 list datastore { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 key name; >> =C2=A0=C2=A0=C2=A0 } >> =C2=A0=C2=A0=C2=A0 choice model { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case same-as-operational { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case constrained-to-operat= ional { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf-list 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 ty= pe leafref { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 path "/yanglib:module-state/yanglib:module/yanglib: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=C2=A0=C2=A0=C2=A0=C2=A0 } >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 case unconstrained { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf yang-libr= ary-datastore { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ty= pe identityref { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 base ds:datastore; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } >> =C2=A0=C2=A0=C2=A0 } >> =C2=A0 } >> ... >> >> IMO ietf-yang-library as defined in rfc7895 is modular and reusable. I= do >> not see why this has to be compromised. >>>> The fundamental point proposed is that the datastore relevant bits >>>> are kept in the ietf-datastores module instead of merging everything >>>> in a new ietf-yang-library entangled monster module. If needed >>>> ietf-datastores can augment ietf-yang-library but ietf-yang-library >>>> should be usable on its own without ietf-datastores. The solution is >>>> coherent and modular and addresses the problem statement. >>> The issue with this is that datastore augmentations to YANG library >>> would end up changing the meaning of the existing YANG library nodes. >>> E.g. an old client that ignores the datastore augmentations is going = to >>> get a nasty surprise when the server does not behave how it expects. >>> E.g. because the configuration node that it thinks should be there is= n't >>> there because it only supported in . >>> >>> This was one of the reasons for changing YANG library. >> A well written client that finds out unsupported newer versions of >> ietf-yang-library (which is reported in the capabilities) or any of th= e NMDA >> modules is deployed should not do any damage. How exactly did you solv= e the >> problem for the bad clients by changing the structure of yang-library = in a >> incompatible way is something I do not understand. >>> In terms of the idea of just re-using YANG library but export a separ= ate >>> copy for each datastore I think that this has its own problems: >>> - I don't like the idea of returning meta-data along with configurati= on >>> for a on any of the configuration datastores. >> There is no meta data. The datastores contain only the config false; >> /modules-state tree. I think I explained that very clearly. >>> - How does a client know whether the YANG library for appli= es >>> to the whole server (as it does today) vs just applies to the >>> datastore (as it would for an NMDA server)? >> All datastore models are "case same-as-operational" for such systems. >>> - It requires more handshaking between the client and server to get t= he >>> schema, since a separate request would be required for each datastore >>> that is supported. >> Correct. Flexibility and modularity come at a price. IMO modularity is= more >> important in this case. And there are solutions for the problem e.g. s= end >> all requests before waiting for replies. NETCONF supports t= his. >>> So, for me, I think that the only way that this solution works, would= be >>> to define a new RPC, but even then I think that= it >>> would make sense to combine the data together into a new YANG library >>> structure. >> As I said my focus is on keeping ietf-yang-library modular (single YAN= G >> model context). or just adding datastore identit= ies >> allowing the client to use to achieve the retrieval of the = data >> is of little importance to me. >> >>> At the end of the day, I don't think that a new YANG library is going= to >>> be were the real cost for supporting NMDA comes from.=C2=A0 I think t= hat the >>> real work is supporting independently from bo= th >>> in the client and servers. But I also think that once servers start >>> implementing this properly that it will simplify automation, because >>> rather than a client having to guess what state a server is in, it ca= n >>> actually querey, or be notified of it, without having to write a lot = of >>> model specific code. >> +1 >> >> Vladimir >>> Thanks, >>> Rob >>> >>> >>>>> I prefer the proposal that was made at the IETF meeting that had >>>>> a 'not-implemented-in' leaf-list and a single module list. >>>> This constraint is already specified in the text of the revised >>>> datastores draft. Clients conforming to the draft can expect servers >>>> to comply with the MUST requirement even if there is a separate >>>> yang-library data tree for each datastore the constraint of >>>> configuration stores mapping to 'operational' should be enforced >>>> according to the draft. There is no contradiction here. >>>> >>>> That said I would be also be OK with ietf-datastores augmenting >>>> ietf-yang-library with such a leaf-list ('not-implemented-in' >>>> leaf-list) as a more constrained flavor of the same approach instead >>>> of going for independent copies of yang-library data. For any of >>>> that to happen change in ietf-datastores.yang is needed and change >>>> in the original rfc7895 ietf-yang-library is not needed at all. >>>> >>>> Vladimir >>>> >>>>> Why is it interesting to have a separate module list for regular >>>>> modules and imported modules? >>>>> I prefer to keep the conformance leaf and not change the module lis= t. >>>>> >>>>> NMDA needs to be possible to implement with a single schema tree >>>>> such that a module >>>>> is implemented in all datastores, or a subset of all >>>>> datastores.=C2=A0 Otherwise it probably won't >>>>> get supported in clients. >>>>> >>>>> >>>>> Andy >>>>> >>>>> >>>>> >>>>> On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen >>>> > wrote: >>>>> >>>>> =C2=A0=C2=A0=C2=A0 CC-ing NETCONF, where the draft is being worked= on. >>>>> >>>>> =C2=A0=C2=A0=C2=A0 Kent >>>>> >>>>> >>>>> =C2=A0=C2=A0=C2=A0 On Fri, 2017-12-08 at 16:34 +0100, Juergen Scho= enwaelder wrote: >>>>> =C2=A0=C2=A0=C2=A0 > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vla= dimir >>>>> Vassilev wrote: >>>>> =C2=A0=C2=A0=C2=A0 > > >>>>> =C2=A0=C2=A0=C2=A0 > > Yes. The default value for yang-library-dat= astore leaf is >>>>> =C2=A0=C2=A0=C2=A0 ds:operational >>>>> =C2=A0=C2=A0=C2=A0 > > (the only possible one for the ds:operation= al datastore). This >>>>> =C2=A0=C2=A0=C2=A0 is backward >>>>> =C2=A0=C2=A0=C2=A0 > > compatible. If one needs different model fo= r 'running', etc. >>>>> =C2=A0=C2=A0=C2=A0 then a new >>>>> =C2=A0=C2=A0=C2=A0 > > datastore identity has to be defined=C2=A0 = and set in place of the >>>>> =C2=A0=C2=A0=C2=A0 default value. >>>>> =C2=A0=C2=A0=C2=A0 > > Then this identity can be used to read the = yang-library >>>>> data with >>>>> =C2=A0=C2=A0=C2=A0 > > . >>>>> =C2=A0=C2=A0=C2=A0 > > >>>>> =C2=A0=C2=A0=C2=A0 > >>>>> =C2=A0=C2=A0=C2=A0 > Sorry, but I have to ask this: How do I obtai= n the schema for the >>>>> =C2=A0=C2=A0=C2=A0 > datastore (lets call it ) th= at reports the >>>>> =C2=A0=C2=A0=C2=A0 schema for >>>>> =C2=A0=C2=A0=C2=A0 > ? Is there another datastore? >>>>> =C2=A0=C2=A0=C2=A0 Will >>>>> =C2=A0=C2=A0=C2=A0 > the recursion end? Perhaps it does since >>>>> >>>>> =C2=A0=C2=A0=C2=A0 > might have itself listed as the schema defini= ng datastore. >>>>> I guess >>>>> =C2=A0=C2=A0=C2=A0 > Lada will like these kind of meta and meta-me= ta datastores. >>>>> >>>>> =C2=A0=C2=A0=C2=A0 Not really. Metadata needn't be in datastores. >>>>> >>>>> =C2=A0=C2=A0=C2=A0 Lada >>>>> >>>>> =C2=A0=C2=A0=C2=A0 > >>>>> =C2=A0=C2=A0=C2=A0 > /js >>>>> =C2=A0=C2=A0=C2=A0 > >>>>> =C2=A0=C2=A0=C2=A0 -- >>>>> =C2=A0=C2=A0=C2=A0 Ladislav Lhotka >>>>> =C2=A0=C2=A0=C2=A0 Head, CZ.NIC Labs >>>>> =C2=A0=C2=A0=C2=A0 PGP Key ID: 0xB8F92B08A9F76C67 >>>>> >>>>> =C2=A0=C2=A0=C2=A0 _______________________________________________ >>>>> =C2=A0=C2=A0=C2=A0 netmod mailing list >>>>> netmod@ietf.org >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_netmod&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3v= oDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D5qj6BQUSwq= YmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=3DI7fR1GY5lN2hVMkDuvryrhDeRypike3wPeF= RrvQI5l8&e=3D >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> =C2=A0=C2=A0=C2=A0 _______________________________________________ >>>>> =C2=A0=C2=A0=C2=A0 netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Dec 12 02:47: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 70D01129420; Tue, 12 Dec 2017 02:47:54 -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 ixVqc_NLFvM9; Tue, 12 Dec 2017 02:47:51 -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 AEC5B124C27; Tue, 12 Dec 2017 02:47:50 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D4CC669; Tue, 12 Dec 2017 11:47:48 +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 syCyj3YvFqn0; Tue, 12 Dec 2017 11:47:45 +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, 12 Dec 2017 11:47:48 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF6BA2012C; Tue, 12 Dec 2017 11:47:48 +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 v5VPPG1XKWUZ; Tue, 12 Dec 2017 11:47:46 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D93B220129; Tue, 12 Dec 2017 11:47:46 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 891294195397; Tue, 12 Dec 2017 11:46:17 +0100 (CET) Date: Tue, 12 Dec 2017 11:46:17 +0100 From: Juergen Schoenwaelder To: Vladimir Vassilev Cc: "netmod@ietf.org" , Netconf Message-ID: <20171212104617.fvmpzn7q2kh2xaku@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Vladimir Vassilev , "netmod@ietf.org" , Netconf References: <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> <9b62952b-d3e6-2db2-6aac-9a544a991078@transpacket.com> <3aac1b82-9cfb-97af-cecb-c469587c37d1@cisco.com> <137c9dac-acb8-69ba-6b9d-20c92d5aeec0@transpacket.com> <20171211161556.me7thzsos2ywai3r@elstar.local> <7a0def88-53d3-0c58-a6e3-80b59c87e1bc@transpacket.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: <7a0def88-53d3-0c58-a6e3-80b59c87e1bc@transpacket.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Netconf] [netmod] 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, 12 Dec 2017 10:47:54 -0000 On Tue, Dec 12, 2017 at 11:37:58AM +0100, Vladimir Vassilev wrote: > > > On 12/11/2017 05:15 PM, Juergen Schoenwaelder wrote: > > I do not fully understand why you think it is worth to preserve the > > old YANG module library structure. Clearly, it won't be backwards > > compatible since an NMDA implementation may list modules that are not > > implemented in all datastores and an old client talking to a new > > server will thus misunderstand what is exposed via the old YANG module > > library structure. Your proposal "looks" backwards compatible but it > > is not if one takes a closer look. > > > > One can start making changes to say the conformance-type but then this > > does not solve the problem since an old client does not know what a > > new conformance type value means. The design team did look into the > > option of keeping the old structure unchanged some weeks ago and we > > finally arrived at the conclusion that it gets (i) ugly and (ii) does > > not really provide backwards compatibility for a client written agains > > the old YANG module library structure. > > > > Note that with the new proposals on the table, it should be possible > > to provide a backwards compatible view on YANG library for systems > > that implement the exact same module set (with the exact same set of > > features and deviations) on all datastores they support. But for > > systems where this is not true, it seems better to use new > > definitions instead of tweaking semantics. > > > > Perhaps it helps if you can clearly phrase the objective of keeping > > the old structure. What is the goal you want to achieve with that? > I prefer to call it the current structure for now. I will try to explain. My > goal is to efficiently build transactional systems based on YANG models and > open standards. > > For this I need some reusable bricks. Such a brick is the rfc7895 > ietf-yang-libraray module. Even in a system with multiple YANG model > contexts eventually processing breaks down to a single model context e.g. > for example a YANG data validation task performed in a command line > application comes down to: >  $ yang-data-validator yang-library-data.xml data.xml I think you can implement $ yang-data-validator yang-library-data-bis.xml data.xml and it will work for any datastore data in data.xml with and without schema mount. > The command can be called multiple times for different data and different > contexts but it is the same very well tested simple tool. Looks like you do not want to make changes but then you have to make changes. I am not sure how to address such a requirement. > So my point is why > can we not use one of the 2 newly introduced methods for instantiating this > very well designed model for the needs of NMDA. > > 1. Use datastore for instantiation. > 2. Use schema mount to mount rfc 7895 ietf-yang-library in the > ietf-datastores list. (an alternative I assume is especially applicable to > modules like ietf-yang-library that are self-contained) > > In general having a solution that is flexible can easily be trimmed down. > Adding special cases that are less flexible e.g. the (not-implemented-in > leaf-list or none at all for the case of fully transactional systems with a > single model context (no extra work for these)). The advantage is that even > with the not-implemented-in leaf-list solution or other diff based the data > processing tasks will eventually convert the differential information to a > data structure implementing the rfc7895 ietf-yang-library data tree and the > yang-data-validator application will be backward compatible and reusable. > With changes that introduce a whole new level of abstraction in place of the > simple list with module name and revision as keys one can't even reuse the > groupings defined in that module and that is a problem I try to avoid. I think you can easily express the ietf-yang-library model in ietf-yang-library-bis so moving to ietf-yang-library-bis will give you a clean solution. > Vladimir > > > > /js > > > > On Mon, Dec 11, 2017 at 04:53:30PM +0100, Vladimir Vassilev wrote: > > > On 12/11/2017 12:16 PM, Robert Wilton wrote: > > > > > > > Hi Vladimir, > > > > > > > > > > > > On 09/12/2017 11:49, Vladimir Vassilev wrote: > > > > > On 12/08/2017 07:01 PM, Andy Bierman wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > A library per datastore sounds too complicated. > > > > > I am not proposing that. > > > > I'm slightly lost, because I thought that was exactly what you were > > > > proposing! ;-) > > > I propose a solution that keeps ietf-yang-library a data model of a single > > > YANG context specification doing the datastore specific modeling in > > > ietf-datastores model instead. The solution can be both flexible > > > (independent yang-library data instances per datastore as my example was > > > focused on) or constrained ('not-implemented-in' modules leaf-list). Here is > > > everything that is needed: > > > > > > module: ietf-datastores > > >     +--ro datastores-state > > >        +--ro datastore* [name] > > >        +--ro (model)? > > >           +--:(same-as-operational) > > >           +--:(constrained-to-operational) > > >           |  +--ro not-implemented-in*       -> > > > /yanglib:module-state/module/name > > >           +--:(unconstrained) > > >              +--ro yang-library-datastore?   identityref > > > > > > YANG: > > > ... > > > container datastores-state { > > >     config false; > > >     list datastore { > > >       key name; > > >     } > > >     choice model { > > >         case same-as-operational { > > >         } > > >         case constrained-to-operational { > > >           leaf-list not-implemented-in { > > >             type leafref { > > >               path "/yanglib:module-state/yanglib:module/yanglib:name"; > > >             } > > >           } > > >         } > > >         case unconstrained { > > >           leaf yang-library-datastore { > > >             type identityref { > > >               base ds:datastore; > > >           } > > >         } > > >       } > > >     } > > >   } > > > ... > > > > > > IMO ietf-yang-library as defined in rfc7895 is modular and reusable. I do > > > not see why this has to be compromised. > > > > > The fundamental point proposed is that the datastore relevant bits > > > > > are kept in the ietf-datastores module instead of merging everything > > > > > in a new ietf-yang-library entangled monster module. If needed > > > > > ietf-datastores can augment ietf-yang-library but ietf-yang-library > > > > > should be usable on its own without ietf-datastores. The solution is > > > > > coherent and modular and addresses the problem statement. > > > > The issue with this is that datastore augmentations to YANG library > > > > would end up changing the meaning of the existing YANG library nodes. > > > > E.g. an old client that ignores the datastore augmentations is going to > > > > get a nasty surprise when the server does not behave how it expects. > > > > E.g. because the configuration node that it thinks should be there isn't > > > > there because it only supported in . > > > > > > > > This was one of the reasons for changing YANG library. > > > A well written client that finds out unsupported newer versions of > > > ietf-yang-library (which is reported in the capabilities) or any of the NMDA > > > modules is deployed should not do any damage. How exactly did you solve the > > > problem for the bad clients by changing the structure of yang-library in a > > > incompatible way is something I do not understand. > > > > In terms of the idea of just re-using YANG library but export a separate > > > > copy for each datastore I think that this has its own problems: > > > > - I don't like the idea of returning meta-data along with configuration > > > > for a on any of the configuration datastores. > > > There is no meta data. The datastores contain only the config false; > > > /modules-state tree. I think I explained that very clearly. > > > > - How does a client know whether the YANG library for applies > > > > to the whole server (as it does today) vs just applies to the > > > > datastore (as it would for an NMDA server)? > > > All datastore models are "case same-as-operational" for such systems. > > > > - It requires more handshaking between the client and server to get the > > > > schema, since a separate request would be required for each datastore > > > > that is supported. > > > Correct. Flexibility and modularity come at a price. IMO modularity is more > > > important in this case. And there are solutions for the problem e.g. send > > > all requests before waiting for replies. NETCONF supports this. > > > > So, for me, I think that the only way that this solution works, would be > > > > to define a new RPC, but even then I think that it > > > > would make sense to combine the data together into a new YANG library > > > > structure. > > > As I said my focus is on keeping ietf-yang-library modular (single YANG > > > model context). or just adding datastore identities > > > allowing the client to use to achieve the retrieval of the data > > > is of little importance to me. > > > > > > > At the end of the day, I don't think that a new YANG library is going to > > > > be were the real cost for supporting NMDA comes from.  I think that the > > > > real work is supporting independently from both > > > > in the client and servers. But I also think that once servers start > > > > implementing this properly that it will simplify automation, because > > > > rather than a client having to guess what state a server is in, it can > > > > actually querey, or be notified of it, without having to write a lot of > > > > model specific code. > > > +1 > > > > > > Vladimir > > > > Thanks, > > > > Rob > > > > > > > > > > > > > > I prefer the proposal that was made at the IETF meeting that had > > > > > > a 'not-implemented-in' leaf-list and a single module list. > > > > > This constraint is already specified in the text of the revised > > > > > datastores draft. Clients conforming to the draft can expect servers > > > > > to comply with the MUST requirement even if there is a separate > > > > > yang-library data tree for each datastore the constraint of > > > > > configuration stores mapping to 'operational' should be enforced > > > > > according to the draft. There is no contradiction here. > > > > > > > > > > That said I would be also be OK with ietf-datastores augmenting > > > > > ietf-yang-library with such a leaf-list ('not-implemented-in' > > > > > leaf-list) as a more constrained flavor of the same approach instead > > > > > of going for independent copies of yang-library data. For any of > > > > > that to happen change in ietf-datastores.yang is needed and change > > > > > in the original rfc7895 ietf-yang-library is not needed at all. > > > > > > > > > > Vladimir > > > > > > > > > > > Why is it interesting to have a separate module list for regular > > > > > > modules and imported modules? > > > > > > I prefer to keep the conformance leaf and not change the module list. > > > > > > > > > > > > NMDA needs to be possible to implement with a single schema tree > > > > > > such that a module > > > > > > is implemented in all datastores, or a subset of all > > > > > > datastores.  Otherwise it probably won't > > > > > > get supported in clients. > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen > > > > > > wrote: > > > > > > > > > > > >     CC-ing NETCONF, where the draft is being worked on. > > > > > > > > > > > >     Kent > > > > > > > > > > > > > > > > > >     On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote: > > > > > >     > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir > > > > > > Vassilev wrote: > > > > > >     > > > > > > > >     > > Yes. The default value for yang-library-datastore leaf is > > > > > >     ds:operational > > > > > >     > > (the only possible one for the ds:operational datastore). This > > > > > >     is backward > > > > > >     > > compatible. If one needs different model for 'running', etc. > > > > > >     then a new > > > > > >     > > datastore identity has to be defined  and set in place of the > > > > > >     default value. > > > > > >     > > Then this identity can be used to read the yang-library > > > > > > data with > > > > > >     > > . > > > > > >     > > > > > > > >     > > > > > > >     > Sorry, but I have to ask this: How do I obtain the schema for the > > > > > >     > datastore (lets call it ) that reports the > > > > > >     schema for > > > > > >     > ? Is there another datastore? > > > > > >     Will > > > > > >     > the recursion end? Perhaps it does since > > > > > > > > > > > >     > might have itself listed as the schema defining datastore. > > > > > > I guess > > > > > >     > Lada will like these kind of meta and meta-meta datastores. > > > > > > > > > > > >     Not really. Metadata needn't be in datastores. > > > > > > > > > > > >     Lada > > > > > > > > > > > >     > > > > > > >     > /js > > > > > >     > > > > > > >     -- > > > > > >     Ladislav Lhotka > > > > > >     Head, CZ.NIC Labs > > > > > >     PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > >     _______________________________________________ > > > > > >     netmod mailing list > > > > > > netmod@ietf.org > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e= > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >     _______________________________________________ > > > > > >     netmod mailing list > > > > > > netmod@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > netmod mailing list > > > > > > netmod@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > _______________________________________________ > > > > > Netconf mailing list > > > > > Netconf@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Dec 12 05:48: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 B654712946B; Tue, 12 Dec 2017 05:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.953 X-Spam-Level: X-Spam-Status: No, score=-12.953 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_20=1.546, 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 iayqSjfXd04W; Tue, 12 Dec 2017 05:48:46 -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 9C4BA126CC7; Tue, 12 Dec 2017 05:48:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=63068; q=dns/txt; s=iport; t=1513086525; x=1514296125; h=subject:from:to:cc:references:message-id:date: mime-version:in-reply-to; bh=HAg3kGLAf9wYZ9wsTT16IwrANavHWgHaYnyG1/pbgZ8=; b=m6reeHu+5M6Slo4rFyZNcvXI/LkxOxnGav93pDPM2y6HSsFXpoOzvQRt aYocI5+ZzgMI8tZ/dMcZJEWWcoDbr7S5uJL/pcOzPTBDbysVYWSwfgEIr vHuEO6CykwzYGIBeahBY4wCZbe19JWXOghhHIQBTcLrWKNQ6j2ryV1re1 Y=; X-Files: dfpcfioondggippe.png : 43605 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CIAgC83S9a/xbLJq1cGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJNBYFSdCeEAosVoU+FTRSBfgMHAQIYAQyER08ChUgWAQEBAQEBAQE?= =?us-ascii?q?BayiFJAIEAQEDHksLEAsBAxkBAQEiAgICFQEOATAGDQUBAgEBAooiEKgXgicmi?= =?us-ascii?q?kgBAQEBAQEBAQEBAQEBAQEBAQEBAQEOCgWDY4NhgWkpgwKDLgEYgR4Eg0mCYwW?= =?us-ascii?q?hdIEjhnkBgQGNK4wSh1WNDoFWiACBOyYHK4FOMhoIGxU6gimDB4FPQDcBiAIsg?= =?us-ascii?q?hoBAQE?= X-IronPort-AV: E=Sophos;i="5.45,395,1508803200"; d="png'150?scan'150,208,217,150";a="852132" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2017 13:48:43 +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 vBCDmgmf018122; Tue, 12 Dec 2017 13:48:42 GMT From: Benoit Claise To: NETCONF Cc: "sec-ads@ietf.org" References: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> Message-ID: <1b8fa624-988e-dfc6-22b7-c7e2ad10afe6@cisco.com> Date: Tue, 12 Dec 2017 14:48:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <987f0de3-00d3-37f0-c919-4fe4f0f16efc@cisco.com> Content-Type: multipart/alternative; boundary="------------08C20E1F790089FBD7DD7FE1" 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: Tue, 12 Dec 2017 13:48:50 -0000 This is a multi-part message in MIME format. --------------08C20E1F790089FBD7DD7FE1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, v9 is posted. I'll approve the draft unless someone screams now... Regards, Benoit > 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 --------------08C20E1F790089FBD7DD7FE1 Content-Type: multipart/related; boundary="------------92AC8BC2FA80584EDE8508E5" --------------92AC8BC2FA80584EDE8508E5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Dear all,

v9 is posted.
I'll approve the draft unless someone screams now...

Regards, Benoit
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

--------------92AC8BC2FA80584EDE8508E5 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 --------------92AC8BC2FA80584EDE8508E5-- --------------08C20E1F790089FBD7DD7FE1-- From nobody Tue Dec 12 20:40: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 E185D128DF2 for ; Tue, 12 Dec 2017 20:40:52 -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 O1PnStuyYm-4 for ; Tue, 12 Dec 2017 20:40:51 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48A7B1271DF for ; Tue, 12 Dec 2017 20:40:51 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id m25so762511pgv.12 for ; Tue, 12 Dec 2017 20:40:51 -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=EJiIINKDRBOflIrb3Qfz5yOyd4dWHXSMf5833+7nnVs=; b=VWeSsO+ngo1TCf7DuLkpCS9cZWoFwZ3gFT4WofSX+q661TMOCF8xxspLEHljQIbpSz 0BLVxRXmm+4c1UVZapIihmGexL6Z/I1GCEHvoAjjysUjYhIsbrPR23iQ8Jo3Xebg+jSY EsODaukFjgxxRG9x6Q8e0eO19Juq5yi7aG1m4hEAC7dBqorIjrsBy74ASorTm/Tf6Mek 4g/d2/e4uUSvj7wkGKFH6UQkFUA0XDz83q/G4YZuWDra2GrzxVPjt4Cu/RnqqIMLq1kR N02G7MFpIlkcdEawg+OiBmUWADaL19J+iJJFTs1Q5MZAXHROP2MGBu7/iD8VIC3hvW7u 3S1w== 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=EJiIINKDRBOflIrb3Qfz5yOyd4dWHXSMf5833+7nnVs=; b=Xh5izaUfzOubCVqkre+QkpYOUy2jRfMdXKxbqONee+thGInFQSCOgykBOqzhYiX1Vf Hb7KqXrA6r9E+Ennc39RN2M1O1xwbVWtSWL+ndA0wu5eL8m8b1m9WkukvkjDMzys0kPm J2Pjy1QscdJZJtZBKsn4m0ZKuchZWPQcIdF97chxcGK6PwfqTcob3gSCYoz4aIcCYswq TWzbfkX/1zCAZLWjhqjE7+Nenb6mJJ6RCpLZFz0NF44RW9keSdXiecxCZdvVe3sgRrMX LwBvxdQtoUGTUVSmlbubrZ9nlNu0U1SQsPBmAm5JjYnRWdCBwt9wPoBPLWqKuKdopf4V 8hlw== X-Gm-Message-State: AKGB3mJrjB+gbKzNb5jqohlKCS+QAhq/ci6MYuiuu390k16mwA8dCLH+ FMT5KoLkNBIcqnS76450cGKPRa2R X-Google-Smtp-Source: ACJfBosbV7LXgtl5wjfia5ypeWIZ0p3ArTqz7x0dTBrCOyN/KPms8gO7OEGBZI0fphPWXO5DYnrqtg== X-Received: by 10.101.97.204 with SMTP id j12mr4104624pgv.75.1513140050540; Tue, 12 Dec 2017 20:40:50 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:4c65:acaa:7a67:d727]) by smtp.gmail.com with ESMTPSA id l73sm1096638pfi.82.2017.12.12.20.40.49 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Dec 2017 20:40:49 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_0CFA8C3F-8357-433F-927F-44D34E011295" Message-Id: <2412C125-587E-47DB-B492-440313572774@gmail.com> Date: Tue, 12 Dec 2017 20:40:48 -0800 To: netconf Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Netconf] WebEx details for interim meeting on December 13, 2017 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, 13 Dec 2017 04:40:53 -0000 --Apple-Mail=_0CFA8C3F-8357-433F-927F-44D34E011295 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii NETCONF Working Group's Webex | Join by phone 1-650-479-3208 Call-in toll number (US/Canada) 1-877-668-4493 Call-in toll free number (US/Canada) Access code: 649 894 536 Host PIN: 7498 Mahesh & Kent --Apple-Mail=_0CFA8C3F-8357-433F-927F-44D34E011295 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

NETCONF Working Group's Webex
 |
Join by phone
1-650-479-3208 Call-in toll = number (US/Canada)
1-877-668-4493 Call-in toll free number (US/Canada)
Access code:  649 894 536
Host PIN: 7498



Mahesh & Kent
= --Apple-Mail=_0CFA8C3F-8357-433F-927F-44D34E011295-- From nobody Tue Dec 12 20:50: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 03FB0128E00 for ; Tue, 12 Dec 2017 20:50:18 -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 P6-8YiLvw19m for ; Tue, 12 Dec 2017 20:50:16 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 34C971271DF for ; Tue, 12 Dec 2017 20:50:16 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id y89so852806pfk.0 for ; Tue, 12 Dec 2017 20:50:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=RnAnDdk7JSLaYynnT7GWdiXHxv9BD31yXbN9HnFrMZs=; b=P9a40q/FjFzBS1ygw8VgirP23WP/lj4WVx0tOMUoipARvBVP+gcd5KlABGBSzsjNCS GVB1phv6OhqJtTNMoH/ychoq6btxre/cypyawPSaYPrzATcjUdXenUzMCQzu+b+7PvuZ qnIojLppaxRofAOS2yPJofRu6Xb15E6WloIlbLyiXPTwsAOsxV37rNMajubtwQs1E9uM I3JcmSVvZaNCxu/+DMFxuZsCwBEwym62Qb3XX8cXD5kqLVqePtjrWwI90UWnVVcf+HAx ZeSBRleCShH6z2/1rdM7e5ELByoNOFp+FpvXGUEtyRVL7snncLDciv2TpnuxHL6ykCAG bkZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=RnAnDdk7JSLaYynnT7GWdiXHxv9BD31yXbN9HnFrMZs=; b=InrM2Fhqa9U9gpQ007uMWcw5qMYYGhroG/LBKEGVQgr6g3CYZ4mbxTV+RGQ2C3RBlL SGaiFfoVK6HwOPai57/5uEjt37q4AgUfBvSeGBhsf4iI9DnEA0h0VdBd5LzCuBaooMTA rpjzAEyD9dvXdfyjZjurWtAoEfkfcVXFzBJofM6Xxv81t8R5EZey1NLTamXNqINaBCnv 86bD+Zvr7r5oDfCsiyModYlBA13wdSjfDKt9esp2i7mTANox8XmWSBY+UPpMLtQbq/3/ ci8kWvuZkRGIsinRkHgKvbk3W0/v5wyfKGqCXUXV/8oUNoYxuuTCX66o+DfamslN3eFN AbBA== X-Gm-Message-State: AKGB3mI8FA/WiwecfMSkjNDbgfCbLWssHj7/s1UHDqyCKuue7C79kbyo HXMMqCR7APqOsUYaD6g8LIEP0yiq X-Google-Smtp-Source: ACJfBos4K0x3SPsaXofk/ynawrboMvEpezjwgfXwFGd/q9jzZSzCruAh0WGTlGI7lSiOeXQiXV426Q== X-Received: by 10.99.189.65 with SMTP id d1mr4223232pgp.104.1513140615300; Tue, 12 Dec 2017 20:50:15 -0800 (PST) Received: from ?IPv6:2600:1700:edb0:8fd0:4c65:acaa:7a67:d727? ([2600:1700:edb0:8fd0:4c65:acaa:7a67:d727]) by smtp.gmail.com with ESMTPSA id m8sm845776pgc.64.2017.12.12.20.50.14 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Dec 2017 20:50:14 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_99AF6929-F7A0-437A-85BA-31C9F940BFD8" Message-Id: <6AAF297B-D5FC-44F7-AEB2-497B6882AC52@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Tue, 12 Dec 2017 20:50:13 -0800 References: <2412C125-587E-47DB-B492-440313572774@gmail.com> To: netconf In-Reply-To: <2412C125-587E-47DB-B492-440313572774@gmail.com> X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Netconf] WebEx details for interim meeting on December 13, 2017 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, 13 Dec 2017 04:50:18 -0000 --Apple-Mail=_99AF6929-F7A0-437A-85BA-31C9F940BFD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii For folks dialing internationally, here is a link to the list of local = numbers by country: = https://www.cisco.com/c/en/us/about/conferencing-global-access-numbers.htm= l = M&K > On Dec 12, 2017, at 8:40 PM, Mahesh Jethanandani = wrote: >=20 >=20 > NETCONF Working Group's Webex > | > Join by phone > 1-650-479-3208 Call-in toll number (US/Canada) > 1-877-668-4493 Call-in toll free number (US/Canada) > Access code: 649 894 536 >=20 >=20 >=20 >=20 > Mahesh & Kent --Apple-Mail=_99AF6929-F7A0-437A-85BA-31C9F940BFD8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

For folks dialing = internationally, here is a link to the list of local numbers by = country:

https://www.cisco.com/c/en/us/about/conferencing-global-access-= numbers.html

M&K

On Dec 12, 2017, at 8:40 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:


NETCONF Working Group's Webex
 |
Join by phone
1-650-479-3208 Call-in toll = number (US/Canada)
1-877-668-4493 Call-in toll free number (US/Canada)
Access code:  649 894 536




Mahesh & = Kent


= --Apple-Mail=_99AF6929-F7A0-437A-85BA-31C9F940BFD8-- From nobody Tue Dec 12 20:58: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 DC6711271DF for ; Tue, 12 Dec 2017 20:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com header.b=ddWp2mla; dkim=pass (2048-bit key) header.d=gmail.com header.b=imaXsU29 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gm9UxoYiGdP6 for ; Tue, 12 Dec 2017 20:58:49 -0800 (PST) Received: from mail-ua0-x24a.google.com (mail-ua0-x24a.google.com [IPv6:2607:f8b0:400c:c08::24a]) (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 A892C1270AC for ; Tue, 12 Dec 2017 20:58:49 -0800 (PST) Received: by mail-ua0-x24a.google.com with SMTP id t24so734481uaa.3 for ; Tue, 12 Dec 2017 20:58:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:reply-to:sender:message-id:date:subject:from:to; bh=p9i5hUbElD15RhZpIseb20Dnf/+uimqezq6RiCDb5Mg=; b=ddWp2mla7k9G8oiztHVrixyIHipsfDSg3asaJQ8YA0hnigd1vNvXxiXEWw3I3dXVYD woEIEkUzL4NYyfaLa71CmCix/tZTUM4vbsL2SFax6qO39EzN+3UyaejsbbPR6vARJ64z +NqPoA/QySb6ocWQY1TCkTYqcnHVvbJsB5JKxIWmtan6D7l4YFjZ61ykiZlvahvMMKEA kS+jcjGE2fMKj6OSRw8S+VxUI7umirNMD5bmMnIQYJB8xBIhJBcfEQBaW8vLpJSRYKVr xPHvuk86JJC0/H7/IpGyzPLeIXnf3QuG7JTg89TAe532SxtnmoDj1a9i2gvR77LXJHLw 6onA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:sender:message-id:date:subject:from:to; bh=p9i5hUbElD15RhZpIseb20Dnf/+uimqezq6RiCDb5Mg=; b=imaXsU29Q3MbuHMcyxO6C7BTiiAMiISwYMETiEiBpkYQ5XYJYC2w13YZJAz07ucABy HEGeUhLCunfDd9HjgPyT7SlLa25D5O61Noo4m06NehRqMXphSdsOaZAqQhD6VXZX1MGU GczsNV8fVzmZM1k4JJ7TzFhxQzhkyCFkssGuYAh2B7PNJNvsrR4ax0zc8J0jx8ddKFK+ jFdToTdvFJnDBScQImzeWO2vdMM8tZLnwrSeRWp3yT1SPyg33FTKq4DLNvhPc5fFceqT T0zpn7zNzPD04asc4uqMU6jXhe2k+N13GO6Na1Z1PFqamsURt1sH/WARGijhlK5KPNDt wpmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:sender:message-id:date :subject:from:to; bh=p9i5hUbElD15RhZpIseb20Dnf/+uimqezq6RiCDb5Mg=; b=TbFcn08l6sLW39p1lNeUyvoFaqbIJEwJ0FXFkU5SU/m7uhoQ4tYa9hR+MYryP1VVtX mom4AIjzF3aYdFHpXL/nU6F7y9RyAzw7+NG65LWYre0SCxUTc/ASNsLz8HQLKjh9pg39 6wiViP3+j9JQki6TRRobecT9sWFFr/GUsBEOSWYOSDmuwn5UBiZE07fhkuttuBENPgiK UGgCxUjGPfgt91ffrSSPP/wozDrVRKos24GjcBqYX0SUKUaOqwIe3iImub9OwaRTd+xG CmVFXoeNQRz7z//gFH4tReRNkLW0SNWd6P6m+46TdTDMgTeNJLgE90BkM6S8Pyc1guBs kifA== X-Gm-Message-State: AKGB3mKe0TmTcqWtg+0lmOA+067/4GOmYVK+ndMbgg3r0elnCzmQ3C0q 5NtuQvOEjSOmODUCmNiaUdR9xo4A7UxWLmoinmRz X-Google-Smtp-Source: ACJfBot9nmvF3YfPtcLU3OMFVdNqB1hTZFvcUkQOZz1an/Q5WUO056TiFVsE2x1S90LpvHjscMB97a7f79vyvlCpG5Jp MIME-Version: 1.0 X-Received: by 10.31.138.75 with SMTP id m72mr2990063vkd.4.1513141128614; Tue, 12 Dec 2017 20:58:48 -0800 (PST) Reply-To: mjethanandani@gmail.com Sender: Google Calendar Message-ID: <001a114585d27759f20560319f92@google.com> Date: Wed, 13 Dec 2017 04:58:48 +0000 From: Mahesh Jethanandani To: netconf@ietf.org Content-Type: multipart/mixed; boundary="001a114585d27759d90560319f91" Archived-At: Subject: [Netconf] Invitation: NETCONF Interim Meeting @ Wed Dec 13, 2017 7am - 9am (PST) (netconf@ietf.org) 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, 13 Dec 2017 04:58:52 -0000 --001a114585d27759d90560319f91 Content-Type: multipart/alternative; boundary="001a114585d27759d70560319f8f" --001a114585d27759d70560319f8f Content-Type: text/plain; charset="UTF-8"; format=flowed; delsp=yes Content-Transfer-Encoding: base64 WW91IGhhdmUgYmVlbiBpbnZpdGVkIHRvIHRoZSBmb2xsb3dpbmcgZXZlbnQuDQoNClRpdGxlOiBO RVRDT05GIEludGVyaW0gTWVldGluZw0KTkVUQ09ORiBXb3JraW5nIEdyb3VwJ3MgV2ViZXgNCmh0 dHBzOi8vaWV0Zi53ZWJleC5jb20vbWVldC9uZXRjb25mDQoNCkpvaW4gYnkgcGhvbmUNCjEtNjUw LTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSkNCjEtODc3LTY2OC00NDkz IENhbGwtaW4gdG9sbCBmcmVlIG51bWJlciAoVVMvQ2FuYWRhKQ0KQWNjZXNzIGNvZGU6ICA2NDkg ODk0IDUzNg0KV2hlbjogV2VkIERlYyAxMywgMjAxNyA3YW0g4oCTIDlhbSBQYWNpZmljIFRpbWUN CldoZXJlOiBodHRwczovL2lldGYud2ViZXguY29tL21lZXQvbmV0Y29uZiB8IDY0OSA4OTQgNTM2 DQpDYWxlbmRhcjogbmV0Y29uZkBpZXRmLm9yZw0KV2hvOg0KICAgICAqIE1haGVzaCBKZXRoYW5h bmRhbmkgLSBvcmdhbml6ZXINCiAgICAgKiBuZXRjb25mQGlldGYub3JnDQoNCkV2ZW50IGRldGFp bHM6ICANCmh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vY2FsZW5kYXIvZXZlbnQ/YWN0aW9uPVZJRVcm ZWlkPVh6WmtNR3BuWkhFeE9Hd3lORFJpWVRVNFpEQnFNbUk1YXpjd2NXcGpZbUV5TnpSdk0ybGlZ VEkyYzNKcU5HTm9jRFl3Y0RNd1kyaHVObThnYm1WMFkyOXVaa0JwWlhSbUxtOXladyZ0b2s9TWpN amJXcGxkR2hoYm1GdVpHRnVhVUJuYldGcGJDNWpiMjAyTVRWbE5XTTJNRFk1TTJFNVpHUmxZV000 WVdGbU5XTTRZVE16TVRNeE5qUmlNVEZrTlRneCZjdHo9QW1lcmljYS9Mb3NfQW5nZWxlcyZobD1l bg0KDQpJbnZpdGF0aW9uIGZyb20gR29vZ2xlIENhbGVuZGFyOiBodHRwczovL3d3dy5nb29nbGUu Y29tL2NhbGVuZGFyLw0KDQpZb3UgYXJlIHJlY2VpdmluZyB0aGlzIGNvdXJ0ZXN5IGVtYWlsIGF0 IHRoZSBhY2NvdW50IG5ldGNvbmZAaWV0Zi5vcmcgIA0KYmVjYXVzZSB5b3UgYXJlIGFuIGF0dGVu ZGVlIG9mIHRoaXMgZXZlbnQuDQoNClRvIHN0b3AgcmVjZWl2aW5nIGZ1dHVyZSB1cGRhdGVzIGZv ciB0aGlzIGV2ZW50LCBkZWNsaW5lIHRoaXMgZXZlbnQuICANCkFsdGVybmF0aXZlbHkgeW91IGNh biBzaWduIHVwIGZvciBhIEdvb2dsZSBhY2NvdW50IGF0ICANCmh0dHBzOi8vd3d3Lmdvb2dsZS5j b20vY2FsZW5kYXIvIGFuZCBjb250cm9sIHlvdXIgbm90aWZpY2F0aW9uIHNldHRpbmdzIGZvciAg DQp5b3VyIGVudGlyZSBjYWxlbmRhci4NCg0KRm9yd2FyZGluZyB0aGlzIGludml0YXRpb24gY291 bGQgYWxsb3cgYW55IHJlY2lwaWVudCB0byBtb2RpZnkgeW91ciBSU1ZQICANCnJlc3BvbnNlLiBM ZWFybiBtb3JlIGF0ICANCmh0dHBzOi8vc3VwcG9ydC5nb29nbGUuY29tL2NhbGVuZGFyL2Fuc3dl ci8zNzEzNSNmb3J3YXJkaW5nDQo= --001a114585d27759d70560319f8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=

NETCONF Interim Meeting

When
Wed Dec 13, 2017 7am = =E2=80=93 9am Pacific Time
Where
=
https://ietf.webex.com/meet/netconf | 649 894 536 (map)
Calendar
netconf@ietf.org
Who
<= td style=3D"padding-right:10px;font-family:Arial,Sans-serif;font-size:13px;= color:#222">
netconf@ietf.org
•=
Mahesh Jethanandani<= span style=3D"font-size:11px;color:#888"> - organizer
•
NETCONF Working Group's Webex
h= ttps://ietf.webex.com/meet/netconf

Join by phone
1-650-479-3208 = Call-in toll number (US/Canada)
1-877-668-4493 Call-in toll free numbe= r (US/Canada)
Access code: 649 894 536

Going?   Yes= - Maybe - No    more op= tions »

Invitation from Google Calendar

You are receiving this cou= rtesy email at the account netconf@ietf.org because you are an attendee of = this event.

To stop receiving future updates for this event, decline = this event. Alternatively you can sign up for a Google account at https://w= ww.google.com/calendar/ and control your notification settings for your ent= ire calendar.

Forwarding this invitation could allow any recipient to= modify your RSVP response. Learn More.

= --001a114585d27759d70560319f8f Content-Type: text/calendar; charset="UTF-8"; method=REQUEST Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT DTSTART:20171213T150000Z DTEND:20171213T170000Z DTSTAMP:20171213T045848Z ORGANIZER;CN=Mahesh Jethanandani:mailto:mjethanandani@gmail.com UID:3A87AEDB-ECA1-4856-B909-B77229020276 ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=netconf@ietf.org;X-NUM-GUESTS=0:mailto:netconf@ietf.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=Mahesh Jethanandani;X-NUM-GUESTS=0:mailto:mjethanandani@gmail.com URL:https://www.cisco.com/c/en/us/about/conferencing-global-access-numbers. html CREATED:20171213T045848Z DESCRIPTION:NETCONF Working Group's Webex\nhttps://ietf.webex.com/meet/netc onf\n\nJoin by phone\n1-650-479-3208 Call-in toll number (US/Canada)\n1-877 -668-4493 Call-in toll free number (US/Canada)\nAccess code: 649 894 536\n \n-::~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~ :~:~:~::~:~::-\nPlease do not edit this section of the description.\n\nView your event at https://www.google.com/calendar/event?action=VIEW&eid=XzZkMG pnZHExOGwyNDRiYTU4ZDBqMmI5azcwcWpjYmEyNzRvM2liYTI2c3JqNGNocDYwcDMwY2huNm8gb mV0Y29uZkBpZXRmLm9yZw&tok=MjMjbWpldGhhbmFuZGFuaUBnbWFpbC5jb202MTVlNWM2MDY5M 2E5ZGRlYWM4YWFmNWM4YTMzMTMxNjRiMTFkNTgx&ctz=America/Los_Angeles&hl=en.\n-:: ~:~::~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~:~: ~::~:~::- LAST-MODIFIED:20171213T045848Z LOCATION:https://ietf.webex.com/meet/netconf | 649 894 536 SEQUENCE:0 STATUS:CONFIRMED SUMMARY:NETCONF Interim Meeting TRANSP:OPAQUE X-APPLE-TRAVEL-ADVISORY-BEHAVIOR:AUTOMATIC BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:This is an event reminder TRIGGER:-P0DT0H15M0S END:VALARM END:VEVENT END:VCALENDAR --001a114585d27759d70560319f8f-- --001a114585d27759d90560319f91 Content-Type: application/ics; name="invite.ics" Content-Disposition: attachment; filename="invite.ics" Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vR29vZ2xlIEluYy8vR29vZ2xlIENhbGVuZGFyIDcw LjkwNTQvL0VODQpWRVJTSU9OOjIuMA0KQ0FMU0NBTEU6R1JFR09SSUFODQpNRVRIT0Q6UkVRVUVT VA0KQkVHSU46VkVWRU5UDQpEVFNUQVJUOjIwMTcxMjEzVDE1MDAwMFoNCkRURU5EOjIwMTcxMjEz VDE3MDAwMFoNCkRUU1RBTVA6MjAxNzEyMTNUMDQ1ODQ4Wg0KT1JHQU5JWkVSO0NOPU1haGVzaCBK ZXRoYW5hbmRhbmk6bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tDQpVSUQ6M0E4N0FFREIt RUNBMS00ODU2LUI5MDktQjc3MjI5MDIwMjc2DQpBVFRFTkRFRTtDVVRZUEU9SU5ESVZJRFVBTDtS T0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD0NCiBUUlVFO0NO PW5ldGNvbmZAaWV0Zi5vcmc7WC1OVU0tR1VFU1RTPTA6bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmcN CkFUVEVOREVFO0NVVFlQRT1JTkRJVklEVUFMO1JPTEU9UkVRLVBBUlRJQ0lQQU5UO1BBUlRTVEFU PUFDQ0VQVEVEO1JTVlA9VFJVRQ0KIDtDTj1NYWhlc2ggSmV0aGFuYW5kYW5pO1gtTlVNLUdVRVNU Uz0wOm1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbQ0KVVJMOmh0dHBzOi8vd3d3LmNpc2Nv LmNvbS9jL2VuL3VzL2Fib3V0L2NvbmZlcmVuY2luZy1nbG9iYWwtYWNjZXNzLW51bWJlcnMuDQog aHRtbA0KQ1JFQVRFRDoyMDE3MTIxM1QwNDU4NDhaDQpERVNDUklQVElPTjpORVRDT05GIFdvcmtp bmcgR3JvdXAncyBXZWJleFxuaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9tZWV0L25ldGMNCiBvbmZc blxuSm9pbiBieSBwaG9uZVxuMS02NTAtNDc5LTMyMDggQ2FsbC1pbiB0b2xsIG51bWJlciAoVVMv Q2FuYWRhKVxuMS04NzcNCiAtNjY4LTQ0OTMgQ2FsbC1pbiB0b2xsIGZyZWUgbnVtYmVyIChVUy9D YW5hZGEpXG5BY2Nlc3MgY29kZTogIDY0OSA4OTQgNTM2XG4NCiBcbi06On46fjo6fjp+On46fjp+ On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On4N CiA6fjp+On46On46fjo6LVxuUGxlYXNlIGRvIG5vdCBlZGl0IHRoaXMgc2VjdGlvbiBvZiB0aGUg ZGVzY3JpcHRpb24uXG5cblZpZXcNCiAgeW91ciBldmVudCBhdCBodHRwczovL3d3dy5nb29nbGUu Y29tL2NhbGVuZGFyL2V2ZW50P2FjdGlvbj1WSUVXJmVpZD1YelprTUcNCiBwblpIRXhPR3d5TkRS aVlUVTRaREJxTW1JNWF6Y3djV3BqWW1FeU56UnZNMmxpWVRJMmMzSnFOR05vY0RZd2NETXdZMmh1 Tm04Z2INCiBtVjBZMjl1WmtCcFpYUm1MbTl5WncmdG9rPU1qTWpiV3BsZEdoaGJtRnVaR0Z1YVVC bmJXRnBiQzVqYjIwMk1UVmxOV00yTURZNU0NCiAyRTVaR1JsWVdNNFlXRm1OV000WVRNek1UTXhO alJpTVRGa05UZ3gmY3R6PUFtZXJpY2EvTG9zX0FuZ2VsZXMmaGw9ZW4uXG4tOjoNCiB+On46On46 fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+On46fjp+ On46fjp+On46fjoNCiB+Ojp+On46Oi0NCkxBU1QtTU9ESUZJRUQ6MjAxNzEyMTNUMDQ1ODQ4Wg0K TE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9tZWV0L25ldGNvbmYgfCA2NDkgODk0IDUz Ng0KU0VRVUVOQ0U6MA0KU1RBVFVTOkNPTkZJUk1FRA0KU1VNTUFSWTpORVRDT05GIEludGVyaW0g TWVldGluZw0KVFJBTlNQOk9QQVFVRQ0KWC1BUFBMRS1UUkFWRUwtQURWSVNPUlktQkVIQVZJT1I6 QVVUT01BVElDDQpCRUdJTjpWQUxBUk0NCkFDVElPTjpESVNQTEFZDQpERVNDUklQVElPTjpUaGlz IGlzIGFuIGV2ZW50IHJlbWluZGVyDQpUUklHR0VSOi1QMERUMEgxNU0wUw0KRU5EOlZBTEFSTQ0K RU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg0K --001a114585d27759d90560319f91-- From nobody Tue Dec 12 23:19: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 EF2FA126C26; Tue, 12 Dec 2017 23:19:10 -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 VCK3aOtOhtxJ; Tue, 12 Dec 2017 23:19:06 -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 D232A1292C5; Tue, 12 Dec 2017 23:19:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 90E2C1541B65; Wed, 13 Dec 2017 08:19:03 +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 0Rh9TDIovatf; Wed, 13 Dec 2017 08:19:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 6318F1541A12; Wed, 13 Dec 2017 08:19:03 +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 tIYUHKMsiQOV; Wed, 13 Dec 2017 08:19:03 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 30E9D15419CA; Wed, 13 Dec 2017 08:19:03 +0100 (CET) To: Martin Bjorklund References: <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171212.202001.1743562517319162368.mbj@tail-f.com> Cc: "netmod@ietf.org" , Netconf From: Vladimir Vassilev Message-ID: Date: Wed, 13 Dec 2017 08:19:02 +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: <20171212.202001.1743562517319162368.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nb Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Netconf] [netmod] 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, 13 Dec 2017 07:19:11 -0000 On 12/12/2017 08:20 PM, Martin Bjorklund wrote: > Hi, > > Vladimir Vassilev wrote: >> >> On 12/08/2017 04:06 PM, Juergen Schoenwaelder wrote: >>> On Fri, Dec 08, 2017 at 04:03:06PM +0100, Martin Bjorklund wrote: >>>> Vladimir Vassilev wrote: >>>>> On 11/15/2017 06:29 PM, Robert Wilton wrote: >>>>> >>>>>> I don't think that this is really a good idea.=C2=A0 You would end= up >>>>>> returning server metadata in addition to the configuration. >>>>> Obviously RFC 7895 defines only config false; data and I was not >>>>> proposing a change to that. But I agree something has to be added t= o >>>>> complete the solution. Special purpose datastore identities can be >>>>> defined that return instance of yang-library data when read with >>>>> . (Datastores with yang-library config false; only data n= ot >>>>> represented in 'operational') >>>>> >>>>> Adding this special yang-library-datastore to the proposed >>>>> ietf-datastores container e.g. >>>>> >>>>> module: ietf-datastores >>>>> +--ro datastores >>>>> |=C2=A0 +--ro datastore* [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 identityref >>>>> |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro yang-library-datastore =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref >>>>> >>>> I don't understand this proposal. How would a client learn the >>>> library for ? For ? >>> My interpretation is that the client reads the datastores list from >>> and the list entries give you the identity of a separat= e >>> datastore that gives you the content of the yang library for that >>> datastore. (For each datastore, you have a separate datastore to >>> report its yang library.) >> Yes. The default value for yang-library-datastore leaf is >> ds:operational (the only possible one for the ds:operational >> datastore). This is backward compatible. If one needs different model >> for 'running', etc. then a new datastore identity has to be defined >> and set in place of the default value. Then this identity can be used >> to read the yang-library data with . > Ah, ok. This is a clever solution, but quite complicated. It > requires several round trips for a client to learn all library > instances. Also, w/o any changes, it is not clear which module-set-id > is sent in the capability, and a client must query all module-set-ids > in all (meta)datastores in order to just check if it has the latest > version or not. It is also not clear how the existing notification > "yang-library-change" would work when there are multiple instances > involved. How about this? module: ietf-datastores ... =C2=A0 augment /yanglib:yang-library-change: =C2=A0=C2=A0=C2=A0 +---- datastore?=C2=A0=C2=A0 identityref Vladimir > So I don't think that this solution will actually work w/o > an update to 7895 - but not updating 7895 was the whole reason for > doing this. > > > /martin > From nobody Tue Dec 12 23:41: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 56A9D12700F; Tue, 12 Dec 2017 23:41: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 VpK9CdTRZIyg; Tue, 12 Dec 2017 23:41: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 CBF40126C26; Tue, 12 Dec 2017 23:41:50 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 9C4AE1AE02BD; Wed, 13 Dec 2017 08:41:49 +0100 (CET) Date: Wed, 13 Dec 2017 08:40:30 +0100 (CET) Message-Id: <20171213.084030.1399882156946529918.mbj@tail-f.com> To: vladimir@transpacket.com Cc: netmod@ietf.org, netconf@ietf.org From: Martin Bjorklund In-Reply-To: References: <20171212.202001.1743562517319162368.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Netconf] [netmod] 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, 13 Dec 2017 07:41:53 -0000 Vladimir Vassilev wrote: > On 12/12/2017 08:20 PM, Martin Bjorklund wrote: > = > > Hi, > > > > Vladimir Vassilev wrote: > >> > >> On 12/08/2017 04:06 PM, Juergen Schoenwaelder wrote: > >>> On Fri, Dec 08, 2017 at 04:03:06PM +0100, Martin Bjorklund wrote:= > >>>> Vladimir Vassilev wrote: > >>>>> On 11/15/2017 06:29 PM, Robert Wilton wrote: > >>>>> > >>>>>> I don't think that this is really a good idea.=A0 You would en= d up > >>>>>> returning server metadata in addition to the configuration. > >>>>> Obviously RFC 7895 defines only config false; data and I was no= t > >>>>> proposing a change to that. But I agree something has to be add= ed to > >>>>> complete the solution. Special purpose datastore identities can= be > >>>>> defined that return instance of yang-library data when read wit= h > >>>>> . (Datastores with yang-library config false; only da= ta not > >>>>> represented in 'operational') > >>>>> > >>>>> Adding this special yang-library-datastore to the proposed > >>>>> ietf-datastores container e.g. > >>>>> > >>>>> module: ietf-datastores > >>>>> +--ro datastores > >>>>> |=A0 +--ro datastore* [name] > >>>>> |=A0=A0=A0=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0=A0=A0 identityref= > >>>>> |=A0=A0=A0=A0 +--ro yang-library-datastore =A0=A0=A0=A0=A0=A0=A0= =A0 identityref > >>>>> > >>>> I don't understand this proposal. How would a client learn the > >>>> library for ? For ? > >>> My interpretation is that the client reads the datastores list fr= om > >>> and the list entries give you the identity of a sep= arate > >>> datastore that gives you the content of the yang library for that= > >>> datastore. (For each datastore, you have a separate datastore to > >>> report its yang library.) > >> Yes. The default value for yang-library-datastore leaf is > >> ds:operational (the only possible one for the ds:operational > >> datastore). This is backward compatible. If one needs different mo= del > >> for 'running', etc. then a new datastore identity has to be define= d > >> and set in place of the default value. Then this identity can be u= sed > >> to read the yang-library data with . > > Ah, ok. This is a clever solution, but quite complicated. It > > requires several round trips for a client to learn all library > > instances. Also, w/o any changes, it is not clear which module-set= -id > > is sent in the capability, and a client must query all module-set-i= ds > > in all (meta)datastores in order to just check if it has the latest= > > version or not. It is also not clear how the existing notification= > > "yang-library-change" would work when there are multiple instances > > involved. > How about this? > module: ietf-datastores > ... > =A0 augment /yanglib:yang-library-change: > =A0=A0=A0 +---- datastore?=A0=A0 identityref This has the same issue as augementing a datastore leaf-list into the current /modules-state/modules list would have - old clients won't understand this new node. /martin From nobody Tue Dec 12 23:50: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 B2935126D05; Tue, 12 Dec 2017 23:50:37 -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 AW1DCyMeo-Gs; Tue, 12 Dec 2017 23:50:35 -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 6B869126C26; Tue, 12 Dec 2017 23:50:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id C5EC11541B5F; Wed, 13 Dec 2017 08:50:33 +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 gf2Pr6xHjdey; Wed, 13 Dec 2017 08:50:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 9911C1541B65; Wed, 13 Dec 2017 08:50:33 +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 XYQt8yAcXsay; Wed, 13 Dec 2017 08:50:33 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 63A8B1541AB1; Wed, 13 Dec 2017 08:50:33 +0100 (CET) From: Vladimir Vassilev To: Martin Bjorklund Cc: Netconf , "netmod@ietf.org" References: <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171212.202001.1743562517319162368.mbj@tail-f.com> Message-ID: <1c97862a-9bc5-6101-6a79-3438573a9aca@transpacket.com> Date: Wed, 13 Dec 2017 08:50:33 +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: text/plain; charset=utf-8; format=flowed Content-Language: nb Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Netconf] [netmod] 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, 13 Dec 2017 07:50:37 -0000 On 12/13/2017 08:19 AM, Vladimir Vassilev wrote: > On 12/12/2017 08:20 PM, Martin Bjorklund wrote: > >> Hi, >> >> Vladimir Vassilev wrote: >>> >>> On 12/08/2017 04:06 PM, Juergen Schoenwaelder wrote: >>>> On Fri, Dec 08, 2017 at 04:03:06PM +0100, Martin Bjorklund wrote: >>>>> Vladimir Vassilev wrote: >>>>>> On 11/15/2017 06:29 PM, Robert Wilton wrote: >>>>>> >>>>>>> I don't think that this is really a good idea.=C2=A0 You would en= d up >>>>>>> returning server metadata in addition to the configuration. >>>>>> Obviously RFC 7895 defines only config false; data and I was not >>>>>> proposing a change to that. But I agree something has to be added = to >>>>>> complete the solution. Special purpose datastore identities can be >>>>>> defined that return instance of yang-library data when read with >>>>>> . (Datastores with yang-library config false; only data=20 >>>>>> not >>>>>> represented in 'operational') >>>>>> >>>>>> Adding this special yang-library-datastore to the proposed >>>>>> ietf-datastores container e.g. >>>>>> >>>>>> module: ietf-datastores >>>>>> +--ro datastores >>>>>> |=C2=A0 +--ro datastore* [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 identityref >>>>>> |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro yang-library-datastore =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref >>>>>> >>>>> I don't understand this proposal.=C2=A0 How would a client learn th= e >>>>> library for ?=C2=A0 For ? >>>> My interpretation is that the client reads the datastores list from >>>> and the list entries give you the identity of a separa= te >>>> datastore that gives you the content of the yang library for that >>>> datastore. (For each datastore, you have a separate datastore to >>>> report its yang library.) >>> Yes. The default value for yang-library-datastore leaf is >>> ds:operational (the only possible one for the ds:operational >>> datastore). This is backward compatible. If one needs different model >>> for 'running', etc. then a new datastore identity has to be defined >>> and set in place of the default value. Then this identity can be used >>> to read the yang-library data with . >> Ah, ok.=C2=A0 This is a clever solution, but quite complicated.=C2=A0 = It >> requires several round trips for a client to learn all library >> instances.=C2=A0 Also, w/o any changes, it is not clear which module-s= et-id >> is sent in the capability, The module-set-id sent in capabilities has to be the one for operational=20 since the client needs to get started by reading /datastores-state. >> and a client must query all module-set-ids >> in all (meta)datastores in order to just check if it has the latest >> version or not. Adding a /datastores-state/datastore/module-set-id leaf in operational=20 can resolve this problem. At the current point I think all issues raised are addressed with the=20 following model (notice the added anydata option which can replace the=20 use of yang-library-datastore and if implemented as an alternative can=20 make retrieval as a single tree): module: ietf-datastores =C2=A0=C2=A0=C2=A0 +--ro datastores-state =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro datastore* [name] =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro module-set-id=C2=A0=C2=A0=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=C2=A0=C2=A0 +--ro (model)? =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(same-as-oper= ational) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(constrained-= to-operational) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro not= -implemented* [name revision] =C2=A0=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 -> /yanglib:m= odule-state/module/name =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0= =C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0 -> /yanglib:module-state/module/r= evision =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(unconstraine= d-datastore-instance) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro yan= g-library-datastore=C2=A0=C2=A0=C2=A0 identityref =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(unconstraine= d-anydata) =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 yang-library?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 =C2=A0 augment /yanglib:yang-library-change: =C2=A0=C2=A0=C2=A0 +---- datastore?=C2=A0=C2=A0 identityref Vladimir >> =C2=A0 It is also not clear how the existing notification >> "yang-library-change" would work when there are multiple instances >> involved. > How about this? > module: ietf-datastores > ... > =C2=A0 augment /yanglib:yang-library-change: > =C2=A0=C2=A0=C2=A0 +---- datastore?=C2=A0=C2=A0 identityref > > Vladimir >> =C2=A0=C2=A0 So I don't think that this solution will actually work w/= o >> an update to 7895 - but not updating 7895 was the whole reason for >> doing this. >> >> >> /martin >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Dec 13 00:31: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 5C38812700F; Wed, 13 Dec 2017 00:31:45 -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 ZJQDRTHDedlb; Wed, 13 Dec 2017 00:31:43 -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 ABEE4120726; Wed, 13 Dec 2017 00:31:42 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 554B54C6; Wed, 13 Dec 2017 09:31:41 +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 OYAL1pQSCqi3; Wed, 13 Dec 2017 09:31:41 +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, 13 Dec 2017 09:31:41 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 412392012E; Wed, 13 Dec 2017 09:31:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KXLy__gk6Is9; Wed, 13 Dec 2017 09:31:40 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 94BF12012C; Wed, 13 Dec 2017 09:31:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 96A704196B76; Wed, 13 Dec 2017 09:29:39 +0100 (CET) Date: Wed, 13 Dec 2017 09:29:39 +0100 From: Juergen Schoenwaelder To: Vladimir Vassilev Cc: Martin Bjorklund , Netconf , "netmod@ietf.org" Message-ID: <20171213082939.thmjs6zf4nfwtsrd@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Vladimir Vassilev , Martin Bjorklund , Netconf , "netmod@ietf.org" References: <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171212.202001.1743562517319162368.mbj@tail-f.com> <1c97862a-9bc5-6101-6a79-3438573a9aca@transpacket.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: <1c97862a-9bc5-6101-6a79-3438573a9aca@transpacket.com> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Netconf] [netmod] 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, 13 Dec 2017 08:31:45 -0000 On Wed, Dec 13, 2017 at 08:50:33AM +0100, Vladimir Vassilev wrote: > > At the current point I think all issues raised are addressed with the > following model (notice the added anydata option which can replace the use > of yang-library-datastore and if implemented as an alternative can make > retrieval as a single tree): > > module: ietf-datastores >     +--ro datastores-state >        +--ro datastore* [name] >        +--ro module-set-id             string >        +--ro (model)? >           +--:(same-as-operational) >           +--:(constrained-to-operational) >           |  +--ro not-implemented* [name revision] >           |     +--ro name        -> /yanglib:module-state/module/name >           |     +--ro revision    -> /yanglib:module-state/module/revision >           +--:(unconstrained-datastore-instance) >           |  +--ro yang-library-datastore    identityref >           +--:(unconstrained-anydata) >              +--ro yang-library?             > >   augment /yanglib:yang-library-change: >     +---- datastore?   identityref > It is (a) architecturally backwards to have ietf-datastores depend on ietf-yang-library and (b) the proposal does not solve the issue that you are silently changing the semantics of the definitions in the old ietf-yang-library. It remains unclear to me which problem this is approach solving, i.e., what the benfit is over the other proposals (since the semantics of ietf-yang-library change, it is _not_ backwards compatible). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Dec 13 00:56: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 15792127869; Wed, 13 Dec 2017 00:56:38 -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 gwNzNZmbBDbA; Wed, 13 Dec 2017 00:56:34 -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 C64E7120726; Wed, 13 Dec 2017 00:56:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id D745B1541B6D; Wed, 13 Dec 2017 09:56:31 +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 WSg18S3-XZdb; Wed, 13 Dec 2017 09:56:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 4A82F1541B6A; Wed, 13 Dec 2017 09:56:31 +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 Vdby_2G2r6PH; Wed, 13 Dec 2017 09:56:31 +0100 (CET) Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 241371541980; Wed, 13 Dec 2017 09:56:31 +0100 (CET) To: Martin Bjorklund Cc: netmod@ietf.org, netconf@ietf.org References: <20171212.202001.1743562517319162368.mbj@tail-f.com> <20171213.084030.1399882156946529918.mbj@tail-f.com> From: Vladimir Vassilev Message-ID: <5c71cddd-b091-223a-9d6f-2e338e7044ed@transpacket.com> Date: Wed, 13 Dec 2017 09:56:30 +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: <20171213.084030.1399882156946529918.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nb Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Netconf] [netmod] 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, 13 Dec 2017 08:56:38 -0000 On 12/13/2017 08:40 AM, Martin Bjorklund wrote: > Vladimir Vassilev wrote: >> On 12/12/2017 08:20 PM, Martin Bjorklund wrote: >> >>> Hi, >>> >>> Vladimir Vassilev wrote: >>>> On 12/08/2017 04:06 PM, Juergen Schoenwaelder wrote: >>>>> On Fri, Dec 08, 2017 at 04:03:06PM +0100, Martin Bjorklund wrote: >>>>>> Vladimir Vassilev wrote: >>>>>>> On 11/15/2017 06:29 PM, Robert Wilton wrote: >>>>>>> >>>>>>>> I don't think that this is really a good idea.=C2=A0 You would e= nd up >>>>>>>> returning server metadata in addition to the configuration. >>>>>>> Obviously RFC 7895 defines only config false; data and I was not >>>>>>> proposing a change to that. But I agree something has to be added= to >>>>>>> complete the solution. Special purpose datastore identities can b= e >>>>>>> defined that return instance of yang-library data when read with >>>>>>> . (Datastores with yang-library config false; only data= not >>>>>>> represented in 'operational') >>>>>>> >>>>>>> Adding this special yang-library-datastore to the proposed >>>>>>> ietf-datastores container e.g. >>>>>>> >>>>>>> module: ietf-datastores >>>>>>> +--ro datastores >>>>>>> |=C2=A0 +--ro datastore* [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 identityref >>>>>>> |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro yang-library-datastore =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 identityref >>>>>>> >>>>>> I don't understand this proposal. How would a client learn the >>>>>> library for ? For ? >>>>> My interpretation is that the client reads the datastores list from >>>>> and the list entries give you the identity of a separ= ate >>>>> datastore that gives you the content of the yang library for that >>>>> datastore. (For each datastore, you have a separate datastore to >>>>> report its yang library.) >>>> Yes. The default value for yang-library-datastore leaf is >>>> ds:operational (the only possible one for the ds:operational >>>> datastore). This is backward compatible. If one needs different mode= l >>>> for 'running', etc. then a new datastore identity has to be defined >>>> and set in place of the default value. Then this identity can be use= d >>>> to read the yang-library data with . >>> Ah, ok. This is a clever solution, but quite complicated. It >>> requires several round trips for a client to learn all library >>> instances. Also, w/o any changes, it is not clear which module-set-i= d >>> is sent in the capability, and a client must query all module-set-ids >>> in all (meta)datastores in order to just check if it has the latest >>> version or not. It is also not clear how the existing notification >>> "yang-library-change" would work when there are multiple instances >>> involved. >> How about this? >> module: ietf-datastores >> ... >> =C2=A0 augment /yanglib:yang-library-change: >> =C2=A0=C2=A0=C2=A0 +---- datastore?=C2=A0=C2=A0 identityref > This has the same issue as augementing a datastore leaf-list into the > current /modules-state/modules list would have - old clients won't > understand this new node. IMO it is different. Augmenting the data tree under /modules-state can=20 potentially compromise the bootstrap resolution of the model context=20 (depending on whether ignoring the data with unknown namespaces does=20 change the original model semantics). However I do not see any issue=20 with the case of the proposed augmentation to yang-library-change=20 notification. Correctly implemented client needs to read /modules-state=20 and make sure there are no unsupported modules,features etc. (e.g.=20 ietf-datastores is supported) before going further (e.g. subscribing to=20 notifications editing configuration etc.). > /martin From nobody Wed Dec 13 06:55: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 AF8EE124B0A; Wed, 13 Dec 2017 06:55:36 -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 tNW59Nyn6-4Y; Wed, 13 Dec 2017 06:55:33 -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 E052F120227; Wed, 13 Dec 2017 06:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25462; q=dns/txt; s=iport; t=1513176933; x=1514386533; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=7HWsKJt/TwllmdJwxpCCozLpL5ZC4WTNyLOvR5Jssf4=; b=XWJxjyojPAjlLMXJsEzXj8EbfK4pNIGd0tT1ZG3JbJKDPLsRkBez5Y4Q UGZgWSxWFDJ7Mlroz26Hqlq7rPstpGCn0IQmRUZwmeGdlqrk4NcwTH312 gdjxpCgAhM14pP1NreYKKVrJ/v/cxjrMZF9lPMsMKVHLU0CosC1RVZsa8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAACtPjFa/xbLJq1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDD4EVdCeEAoohdJAOfpYTghUKGAEJhEpPAoVSGAEBAQEBAQE?= =?us-ascii?q?BAWsohSMBAQEBAgEBASFLCxALGCAHAwICJx8RBg0GAgEBF4oFCBCoZYInJoo2A?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBHYNgg2GBaSmCTDaDLgEYgSwUgyuCYwWSFIc?= =?us-ascii?q?+iU2He40sghZjiRokhzGNEIFWiACBOx85JYEpMhoIGxU6gikJghCCPEE3AQGKO?= =?us-ascii?q?AEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,397,1508803200"; d="scan'208,217";a="885961" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2017 14:55:30 +0000 Received: from [10.63.23.92] (dhcp-ensft1-uk-vla370-10-63-23-92.cisco.com [10.63.23.92]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vBDEtU0j009264; Wed, 13 Dec 2017 14:55:30 GMT To: Andy Bierman Cc: Kent Watsen , "netmod@ietf.org" , "netconf@ietf.org" References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> <5242d50f-6f9e-b57e-ec1b-64828c456339@cisco.com> From: Robert Wilton Message-ID: <60876a73-3dec-9a4f-e313-1787b432fb34@cisco.com> Date: Wed, 13 Dec 2017 14:55:30 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------829A8D330DE6ABA13763460A" Content-Language: en-US Archived-At: Subject: Re: [Netconf] [netmod] 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, 13 Dec 2017 14:55:37 -0000 This is a multi-part message in MIME format. --------------829A8D330DE6ABA13763460A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/12/2017 20:55, Andy Bierman wrote: > > > On Mon, Dec 11, 2017 at 2:57 AM, Robert Wilton > wrote: > > Hi, > > > On 08/12/2017 18:01, Andy Bierman wrote: >> Hi, >> >> A library per datastore sounds too complicated. >> I prefer the proposal that was made at the IETF meeting that had >> a 'not-implemented-in' leaf-list and a single module list. > The use case that this particular design doesn't work particularly > well for is if you have a dynamic datastore that just contains a > few modules that are not supported via the conventional datastores. > > I think that there are future uses cases where the set of modules > used for a dynamic datastore could be really quite different and > separate from conventional configuration.  E.g. if dynamic > subscribers were managed through a dynamic configuration datastore > rather than RADIUS. > >> >> Why is it interesting to have a separate module list for regular >> modules and imported modules? > Several reasons: > 1) It means that the list of implemented modules have a single key > and hence any references to an implemented module are cleaner/simpler. > > > > IMO you are replacing universally meaningful keys  (module-name, > revision-date) with an arbitrary name, > It is not cleaner and not simpler for a client. No, for alternatives A and B, the list key is the module name itself, nor an arbitrary name. Alternative C uses an arbitrary name. > > > 2) The model structure naturally more strictly enforces that only > a single revision/version of a module is implemented. (E.g. it > prevents a server stating that two revisions of a module are both > implemented). > > > > How is that the case if the schema list includes its own module list? > You mean there is a "unique" statement in the outer list that insures > that a module/revision > shows up at most once in all instances of the inner module list? For alt A, each schema represents a single list (so no duplicated implemented modules are possible). For alt B, yes, the rule is that there must be no duplicates in the module-sets that are combined into a single schema. > > 3) I genuinely think that the list of implemented modules is more > interesting to the client than the imported, but not implemented > modules. > > > > The conformance leaf was good enough. > Duplicating the module list and removing the conformance leaf is > aggressively non-backward compatible. > > > For a server, I would design it to "implement" one revision of > every module that it uses (including those that don't contain any > data nodes, RPCs, actions, notifications, or deviations), and then > the "import-only" list becomes the list of modules that the server > implements to satisfy "import-by-revision" and these are stated in > the implemented schema anyway. > > >> I prefer to keep the conformance leaf and not change the module list. >> >> NMDA needs to be possible to implement with a single schema tree >> such that a module >> is implemented in all datastores, or a subset of all datastores.  >> Otherwise it probably won't >> get supported in clients. > All solutions accommodate this requirement. > > > > Seems to me all new solutions allow a server to violate the MUST in > the NMDA draft that > there is a superset of all modules.  A client has to look for every > module in a server-specific > set of named schema sets, and then reconcile all these sets. > I still prefer the single module list with a conformance leaf and a > leaf-list indicating > the supported (or unsupported) datastores. So, this is a trade off between a more expressive model vs a more constrained model. It is worth noting that the existing YANG library (RFC 7895) allows servers to produce illegal module lists because they could implement multiple revisions of the same module. Thanks, Rob > > > > For me, some of the interesting design questions have revolved around: > - is it better to reduce duplication in the list of modules > reported at the cost of increased model complexity? > - does the solution extend to schema mount? > - how well does the solution cope with with configuration > datastores that support very different sets of modules? > > To a lesser extent we have also been considering how well the > solution extends to packaging and semantic versioning, but I think > that it is quite tricky to know who these are going to pan out.  > E.g. I think that the restriction that a given schema will only > implement a single revision of a module will end up still holding, > but I'm not sure that everyone has that same view point. > > Thanks, > Rob > > > > > Andy > >> >> >> Andy >> >> >> >> On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen > > wrote: >> >> CC-ing NETCONF, where the draft is being worked on. >> >> Kent >> >> >> On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote: >> > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev >> wrote: >> > > >> > > Yes. The default value for yang-library-datastore leaf is >> ds:operational >> > > (the only possible one for the ds:operational datastore). >> This is backward >> > > compatible. If one needs different model for 'running', >> etc. then a new >> > > datastore identity has to be defined and set in place of >> the default value. >> > > Then this identity can be used to read the yang-library >> data with >> > > . >> > > >> > >> > Sorry, but I have to ask this: How do I obtain the schema >> for the >> > datastore (lets call it ) that reports the >> schema for >> > ? Is there another >> datastore? Will >> > the recursion end? Perhaps it does since >> >> > might have itself listed as the schema defining datastore. >> I guess >> > Lada will like these kind of meta and meta-meta datastores. >> >> Not really. Metadata needn't be in datastores. >> >> Lada >> >> > >> > /js >> > >> -- >> Ladislav Lhotka >> Head, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e= >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > --------------829A8D330DE6ABA13763460A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 11/12/2017 20:55, Andy Bierman wrote:


On Mon, Dec 11, 2017 at 2:57 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi,


On 08/12/2017 18:01, Andy Bierman wrote:
Hi,

A library per datastore sounds too complicated.
I prefer the proposal that was made at the IETF meeting that had
a 'not-implemented-in' leaf-list and a single module list.
The use case that this particular design doesn't work particularly well for is if you have a dynamic datastore that just contains a few modules that are not supported via the conventional datastores.

I think that there are future uses cases where the set of modules used for a dynamic datastore could be really quite different and separate from conventional configuration.  E.g. if dynamic subscribers were managed through a dynamic configuration datastore rather than RADIUS.


Why is it interesting to have a separate module list for regular modules and imported modules?
Several reasons:
1) It means that the list of implemented modules have a single key and hence any references to an implemented module are cleaner/simpler.


IMO you are replacing universally meaningful keys  (module-name, revision-date) with an arbitrary name,
It is not cleaner and not simpler for a client.
No, for alternatives A and B, the list key is the module name itself, nor an arbitrary name.
Alternative C uses an arbitrary name.




2) The model structure naturally more strictly enforces that only a single revision/version of a module is implemented.  (E.g. it prevents a server stating that two revisions of a module are both implemented).


How is that the case if the schema list includes its own module list?
You mean there is a "unique" statement in the outer list that insures that a module/revision
shows up at most once in all instances of the inner module list?
For alt A, each schema represents a single list (so no duplicated implemented modules are possible).

For alt B, yes, the rule is that there must be no duplicates in the module-sets that are combined into a single schema.



 
3) I genuinely think that the list of implemented modules is more interesting to the client than the imported, but not implemented modules.


The conformance leaf was good enough.
Duplicating the module list and removing the conformance leaf is aggressively non-backward compatible.

 

For a server, I would design it to "implement" one revision of every module that it uses (including those that don't contain any data nodes, RPCs, actions, notifications, or deviations), and then the "import-only" list becomes the list of modules that the server implements to satisfy "import-by-revision" and these are stated in the implemented schema anyway.


I prefer to keep the conformance leaf and not change the module list.

NMDA needs to be possible to implement with a single schema tree such that a module
is implemented in all datastores, or a subset of all datastores.  Otherwise it probably won't
get supported in clients.
All solutions accommodate this requirement.


Seems to me all new solutions allow a server to violate the MUST in the NMDA draft that
there is a superset of all modules.  A client has to look for every module in a server-specific
set of named schema sets, and then reconcile all these sets.
I still prefer the single module list with a conformance leaf and a leaf-list indicating
the supported (or unsupported) datastores.
So, this is a trade off between a more expressive model vs a more constrained model.

It is worth noting that the existing YANG library (RFC 7895) allows servers to produce illegal module lists because they could implement multiple revisions of the same module.

Thanks,
Rob





For me, some of the interesting design questions have revolved around:
- is it better to reduce duplication in the list of modules reported at the cost of increased model complexity?
- does the solution extend to schema mount?
- how well does the solution cope with with configuration datastores that support very different sets of modules?

To a lesser extent we have also been considering how well the solution extends to packaging and semantic versioning, but I think that it is quite tricky to know who these are going to pan out.  E.g. I think that the restriction that a given schema will only implement a single revision of a module will end up still holding, but I'm not sure that everyone has that same view point.

Thanks,
Rob




Andy
 


Andy



On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen <kwatsen@juniper.net> wrote:
CC-ing NETCONF, where the draft is being worked on.

Kent


On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote:
> On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote:
> >
> > Yes. The default value for yang-library-datastore leaf is ds:operational
> > (the only possible one for the ds:operational datastore). This is backward
> > compatible. If one needs different model for 'running', etc. then a new
> > datastore identity has to be defined  and set in place of the default value.
> > Then this identity can be used to read the yang-library data with
> > <get-data>.
> >
>
> Sorry, but I have to ask this: How do I obtain the schema for the
> datastore (lets call it <running-library>) that reports the schema for
> <running>? Is there another <running-library-library> datastore? Will
> the recursion end? Perhaps it does since <running-library-library>
> might have itself listed as the schema defining datastore. I guess
> Lada will like these kind of meta and meta-meta datastores.

Not really. Metadata needn't be in datastores.

Lada

>
> /js
>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

_______________________________________________
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e=


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



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



--------------829A8D330DE6ABA13763460A-- From nobody Wed Dec 13 08:46:50 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 4DD1B1286C7; Wed, 13 Dec 2017 08:46:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.67.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , Mahesh Jethanandani , mjethanandani@gmail.com, netconf@ietf.org, bclaise@cisco.com, draft-ietf-netconf-rfc6536bis@ietf.org, rfc-editor@rfc-editor.org, netconf-chairs@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151318360331.30085.3266557006105806577.idtracker@ietfa.amsl.com> Date: Wed, 13 Dec 2017 08:46:43 -0800 Archived-At: Subject: [Netconf] Protocol Action: 'Network Configuration Access Control Module' to Internet Standard (draft-ietf-netconf-rfc6536bis-09.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: Wed, 13 Dec 2017 16:46:43 -0000 The IESG has approved the following document: - 'Network Configuration Access Control Module' (draft-ietf-netconf-rfc6536bis-09.txt) as Internet Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Warren Kumari and Benoit Claise. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc6536bis/ Technical Summary The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. Working Group Summary This document is a bis document to RFC 6536 and as such is an update rather than a new draft. The main purpose of the document is to bring it up to date with the publication of RFC 7950 (YANG 1.1). Document Quality The document was reviewed and comments were provided in both the IETF meetings and on the NETCONF WG mailing list. A YANG doctors review was requested for the YANG module in the document, and Kent has agreed to provide it soon. The changes to the document are minor w.r.t. RFC 6536 and it would be difficult to distinguish the implementation of this draft vis-a-vis RFC 6536. YumaWorks has indicated that they have implemented RFC 6536 for NETCONF and RESTCONF and for YANG 1.1 actions. Support for nested notifications, which is also a YANG 1.1 feature is not yet supported. Cisco is currently implementing RFC 6536 for NETCONF on the XR platforms, and the NCS platform (from tail-f acquisition) implements RFC 6536. Personnel The document shepherd is Mahesh Jethanandani and the AD will be Benoit Claise. From nobody Wed Dec 13 22: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 D34AC12702E for ; Wed, 13 Dec 2017 22:20:34 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A66tFy-NKQR7 for ; Wed, 13 Dec 2017 22:20:33 -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 0EC6B1270AC for ; Wed, 13 Dec 2017 22:20:32 -0800 (PST) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBE6Jc6N029462 for ; Wed, 13 Dec 2017 22:20:32 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=6IpiaNNa/IQH9ti7MkctD2CykgfTwbfX2JVBN9/TU9E=; b=1BqEm1WmxsV1Jk/kQYnpSHCZUVklYpFHuia/OxGbmoUjJjLBZ0KEa9WR09yLv6jPvnQV B2+BKESMLJYRBoYYD2NkTdz3EshXdZEQjXYHseAmCfDt/xn+yUFhQMwHaRML1SSE2pfn QXpJpVgrNdOMmArb0rJNEq0VCeH4Png+EIVs+kEgicAYq9b+jLJ81kkUrkzG2Phf2OCQ RKmBH9XCLG5slPrp0hfqXXCxj4/ymTB8FjUtlEAlVtVjfO4GBq3S+EB2PDC4dEKmXvC8 JSnFz/1ps0sPCiklFQ6SElezyP5V+4FwZ5UkPpU60rxK1BzmNpueE7TtI/X2dDOXS78a jQ== Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0117.outbound.protection.outlook.com [207.46.163.117]) by mx0b-00273201.pphosted.com with ESMTP id 2euku9r0ba-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 13 Dec 2017 22:20:31 -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.323.4; Thu, 14 Dec 2017 06:20:28 +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.0323.011; Thu, 14 Dec 2017 06:20:28 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: Virtual Interim Results Thread-Index: AQHTdKOibhSCoe8YoEC3JzdZ5zqILA== Date: Thu, 14 Dec 2017 06:20:28 +0000 Message-ID: <5F4462F2-2679-4CFE-A060-41177F9A5D04@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 x-originating-ip: [66.129.239.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB275; 6:oBsjINYzzH5jBnFWTs5+iVhpPgxHHJp8+6szdpWhVZiI2X07lYtPOKpNNTaVCdDfSKOsa6X58hHlHqpN+eY8l9LPlyvvF/i4U1gagz0wmCE1GRHLCKFirQrfZQpHlwYFaQLWLTAQrDYAJ+PnTFkuHe0XfSbjOOicEMcWseKB+j0ZNfblZdviMlgmhsjsOrfp9fIZ7L02IJ/yht0QjdvDM2fhOi2+IkpuRFGLUAhiohhFWfhT2sF+/bkFmKzV8yRhGqcsPw3FF+Kp11AOepFfEwe01xHTq5ezMaMiPWpwc2OTJCoC/rOgXTJxgN55DnBIjVnFuU5uI7YkmY2b1s+v380ZZ9fWEIYdZ7RH2XPTFmU=; 5:mXCn7af4AZrlluwYB39ztdu+cG/XcmCDuwRS+bx8mpGMjciRv8Cx/n4mkQNirLtP/pM6FiSgEh18CUNCOsbYCzOgT71gc/QZZk3dY6UkxXs0ld8Wz8PuZy1iNGnP+qI59pG6uCeEBIlC6CneJKHHfK8heqY8j/NuBr/B6c8jLvA=; 24:EerOIdzV7mwS+E4Ory/faNhfGjreHMV3uXjA/DB+Ju6c07+yF28ICsgYAXS0m12+YV8UyosZgQKcPK6ZoQT5peoQ+Roy+OjLS8ubOxKSwXM=; 7:NtJADHTpqw84Fgja87jFGxH8mQgBmRjuSqAqCUedDFNcEOusgSMhf1iD0b43k5ykXF4coagqvVc5g3wDD8IbSUNoLVdZ7qinsljQgw00yxlxgMxIzEqYXHxZXgst/cXChOWPudHcUXkDwEmholeks+PDfwkXqXDL2h3PdrXLyUorT20Ky99y5xxpYWUqL9Rsy9luVBfC04AQcGuYLYFSuGETORlL4uGY/hiyfob2EXEXLi4ZfjsBDhSCkBvhoijF x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fe87e11f-d850-4c15-63fb-08d542bac56c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:BLUPR05MB275; x-ms-traffictypediagnostic: BLUPR05MB275: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231023)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(6072148)(201708071742011); SRVR:BLUPR05MB275; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR05MB275; x-forefront-prvs: 05214FD68E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(346002)(39860400002)(199004)(189003)(5660300001)(36756003)(81166006)(5640700003)(81156014)(2351001)(6436002)(2501003)(6486002)(316002)(106356001)(83506002)(1730700003)(58126008)(83716003)(82746002)(66066001)(478600001)(105586002)(966005)(77096006)(14454004)(97736004)(8676002)(53936002)(99286004)(6506007)(7736002)(33656002)(6512007)(68736007)(3280700002)(6306002)(2906002)(305945005)(86362001)(3660700001)(2900100001)(3480700004)(6116002)(102836003)(3846002)(8936002)(6916009)(7116003)(25786009); 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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <09F9474416C98A45860B695577291181@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: fe87e11f-d850-4c15-63fb-08d542bac56c X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2017 06:20:28.5421 (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-12-14_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712140091 Archived-At: Subject: [Netconf] Virtual Interim Results 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, 14 Dec 2017 06:20:35 -0000 DQpUaGlzIG1lZXRpbmcgY29uY2x1ZGVkIHdpdGggYW4gW2Fub255bW91c10gcG9sbCB3aXRoIHRo ZSBmb2xsb3dpbmcgcmVzdWx0czoNCg0KICBXaGljaCBvcHRpb24gZG8geW91IHByZWZlcj8gICAg ICAgICAgICAgICAgICAgICBNb3N0IGZhdm9yZWQ6IEFsdCBCDQogIFNob3VsZCBsaWNlbnNpbmcg YmUgY29uc2lkZXJlZCBub3c/ICAgICAgICAgICAgIDgwJSBubw0KICBTaG91bGQgaC93IGluc2Vy dGlvbi9yZW1vdmFsIGJlIGNvbnNpZGVyZWQgbm93PyA4MCUgbm8NCiAgU2hvdWxkIHNlbS12ZXIg YmUgY29uc2lkZXJlZCBub3c/ICAgICAgICAgICAgICAgODAlIG5vDQoNCk5vdGU6IEFsdCBCIGlz IGRlc2NyaWJlZCBvbiB0aGUgc2xpZGUgIzUgcG9zdGVkIGhlcmU6ICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL21lZXRpbmcvaW50ZXJpbS0yMDE3LW5ldGNvbmYtMDEvbWF0ZXJpYWxzL3Ns aWRlcy1pbnRlcmltLTIwMTctbmV0Y29uZi0wMS1zZXNzYS15YW5nLWxpYnJhcnktb3B0aW9ucw0K DQpUaGVzZSBzZWxlY3Rpb25zIG5vdyBuZWVkIHRvIGJlIGNvbmZpcm1lZCBvbiB0aGUgbGlzdC4g IFNpbmNlIGl0J3MgYXNzdW1lZCB0aGF0IGFsbCBpbnRlcmVzdGVkIHBhcnRpZXMgYXR0ZW5kZWQg dGhlIG1lZXRpbmcsIHRoZXNlIGRlY2lzaW9ucyB3aWxsIGJlIGZpbmFsIHVubGVzcyB0aGVyZSBh cmUgYW55IG9iamVjdGlvbnMgcmFpc2VkIGluIGEgd2VlaydzIHRpbWUuDQoNClRoYW5rcywNCktl bnQgJiBNYWhlc2gNCg0KDQo= From nobody Wed Dec 13 22:25: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 5BC281270AC for ; Wed, 13 Dec 2017 22:25:29 -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 H9fsWhc7Ljx5 for ; Wed, 13 Dec 2017 22:25:27 -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 6FE7312702E for ; Wed, 13 Dec 2017 22:25:27 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id u25so2972982pfg.5 for ; Wed, 13 Dec 2017 22:25:27 -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=1UJ510t/2iC87VXQgTo/ZXbx5w4pm5QO16TrbsTnQWM=; b=QcXl/Tw+xsWDy3uCaRsLQtkQhf9PUNCFSbA896gbaS7Z6xXvKWo5X6Z5DZ8RrqNIxf EeGGXJ6yqU7ahQUQbnGgg+hQhtlT9h+mdgnQY4cZpt00tsQTTB0YPEla21NK72CJiRks XDysLlvYICpBixCo92Op2x+Hg9g14fT3b7NhIxIHZb7XoQ7BDBjNB+6A8Vlf/+5eUtDb lfWtR2cuiQtH7u+WZ/mxHS8/NfdLXj0Cwz6jyZbKxo1MGw7ae5kGPzNc/KazFfAt5azj A7rhluVW/CfbyGXwN4R7I3CjJ8mSyklUNTCEfvzVQCJoduXH2PIzAmRii7S6NKva/tdB HFnQ== 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=1UJ510t/2iC87VXQgTo/ZXbx5w4pm5QO16TrbsTnQWM=; b=Z8N+sp7vPLsNOEnCn6oTagr6/Vu8cE9Swoe2McUPjeZCTVq8IY/vOqGhHNB3CSFiXU UJyaDJN/2yp7PgOkVy/U8ZVtklK567rs1Z82gKkO/TiCteAemn1OLjPrVcbQDEwC9ufy ajrFWiBVFgQ+21hJc2NqnhAIKPS/pG62dAb1eDK8SuToAIlyM4Nn/IeY7RuGyihjOncA Np4Rz8KA7Fc6FWs3NxSdMA64gqdBKAR7K/7mZ2OLJh/CtkFpEuFH7akwRx4tD69qrDye sbXX7f+Aa7+W9CHR5Yy8KlX3abLtm4mzFVzh8DUsykm94yb3wA/IN/NQm3C4X1W3IjOW 7Qrw== X-Gm-Message-State: AKGB3mKiogekXEoVaoRy+8wNIWqq08SLoPI8TIHp1HZDHchrx29AXj7B urLXdh/Y1SZyK3wYjDviCCDVtpPiNF4= X-Google-Smtp-Source: ACJfBoubbvPTiEft1hkfqkaadniZYRHdmLVvrhob+zJRC1VIVgOHQZi4cqkoWMPBL/HxOgKwgzXwXw== X-Received: by 10.101.100.215 with SMTP id t23mr7621152pgv.433.1513232726715; Wed, 13 Dec 2017 22:25:26 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:a941:9189:b38c:fb3a]) by smtp.gmail.com with ESMTPSA id p85sm6402891pfk.147.2017.12.13.22.25.25 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 13 Dec 2017 22:25:26 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_970CE99A-7AB4-46FF-92E1-B54695A610A5" Message-Id: Date: Wed, 13 Dec 2017 22:25:25 -0800 To: netconf Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Netconf] Virtual Interim meeting minutes 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, 14 Dec 2017 06:25:29 -0000 --Apple-Mail=_970CE99A-7AB4-46FF-92E1-B54695A610A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii NETCONF held an interim meeting today. The rough notes from the minutes = are recorded here = in the = etherpad. If you attended the meeting, please review these minutes. A = link to the recording is included in the etherpad.=20 Thanks Mahesh & Kent --Apple-Mail=_970CE99A-7AB4-46FF-92E1-B54695A610A5 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii NETCONF held an interim meeting today. The rough notes from the minutes are recorded here in the etherpad. If you attended the meeting, please review these minutes. A link to the recording is included in the etherpad. 

Thanks

Mahesh & Kent

--Apple-Mail=_970CE99A-7AB4-46FF-92E1-B54695A610A5-- From nobody Thu Dec 14 05:17: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 15765126C25 for ; Thu, 14 Dec 2017 05:17:18 -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, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ndLB2M_ruFK for ; Thu, 14 Dec 2017 05:17:16 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A14124205 for ; Thu, 14 Dec 2017 05:17:16 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 1C2691E0872 for ; Thu, 14 Dec 2017 06:17:16 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id lpHD1w0032SSUrH01pHGDY; Thu, 14 Dec 2017 06:17:16 -0700 X-Authority-Analysis: v=2.2 cv=VcCHBBh9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=ocR9PWop10UA:10 a=48vgC7mUAAAA:8 a=LBklH7xXG4czXxWD3LoA:9 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG: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=vKTqrkm6CTOjDlKYPiTicyc67vCa2WkOQ/yY9lfIqoQ=; b=fAfkNCgJi8PoEuRVQ8KX/BRJ3T vIsXjmSKWs0uDqtUVczIQQXCRRb1F1ALmnR0C77Hcwvook+7+r5Wu3VK2GSjCGaDOinCdivHax+0u nnCYScyOI5d71taHYeo6NlPLl; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:39252 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ePTNw-003IHV-RI; Thu, 14 Dec 2017 06:17:12 -0700 To: Kent Watsen , "netconf@ietf.org" References: <5F4462F2-2679-4CFE-A060-41177F9A5D04@juniper.net> From: Lou Berger Message-ID: <307ec8f7-4562-ae02-d8f1-1a281966ac56@labn.net> Date: Thu, 14 Dec 2017 08:17:10 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <5F4462F2-2679-4CFE-A060-41177F9A5D04@juniper.net> 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: 1ePTNw-003IHV-RI 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]:39252 X-Source-Auth: lberger@labn.net X-Email-Count: 6 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Netconf] Virtual Interim Results 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, 14 Dec 2017 13:17:18 -0000 Hi, Sorry I wasn't able to attend this short-notice interim - I had to run a long-scheduled meeting. See below for some questions and comments. On 12/14/2017 1:20 AM, Kent Watsen wrote: > This meeting concluded with an [anonymous] poll with the following results: > > Which option do you prefer? Most favored: Alt B > Should licensing be considered now? 80% no > Should h/w insertion/removal be considered now? 80% no > Should sem-ver be considered now? 80% no > > Note: Alt B is described on the slide #5 posted here: https://datatracker.ietf.org/meeting/interim-2017-netconf-01/materials/slides-interim-2017-netconf-01-sessa-yang-library-options Reading the notes it is subject to interpretation how B addresses the questions/issues raised on the objectives slide, I'm not sure who, but I think this information is needed to evaluate this alternative.  Can someone (Martin?) provide this? > These selections now need to be confirmed on the list. Since it's assumed that all interested parties attended the meeting, these decisions will be final unless there are any objections raised in a week's time. I guess I have no choice but to object.    I'm an interested party who was unable to attend this very short notice interim - so am proof that this assertion is false.  This is a process objection, which I really don't like making, but as chair of NetMod I feel obligated to make it as NetMod has many interested parties and that WG wasn't even notified of the meeting -- I know most of us at least track both groups/lists, but I don't think it fair to assume that all interested in Library do. As an individual contributor, I suspect that the choice is a fine one, but would like to understand how (b) addresses  the objectives on slides 2 and 3 or is even intended to be implemented - e.g., I read "Each datastore refers to a schema" as meaning library is retrievable from every datastore, and I'd be surprised if that was the intent.  -- Although, I think an answer that library is metadata, not operational data, and therefore retrievable and identical in all datastores is a workable answer; just not one I personally expected. Lou > > Thanks, > Kent & Mahesh > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Thu Dec 14 05: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 830BF1292CE for ; Thu, 14 Dec 2017 05: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 aWhWmrfappGW for ; Thu, 14 Dec 2017 05:29:04 -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 CC1E2128DE5 for ; Thu, 14 Dec 2017 05:29:03 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9C882A24; Thu, 14 Dec 2017 14:29:02 +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 1qdNKcOTDoVe; Thu, 14 Dec 2017 14: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; Thu, 14 Dec 2017 14:29:02 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 896892012E; Thu, 14 Dec 2017 14:29:02 +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 3xY9eysjjkOR; Thu, 14 Dec 2017 14:29:01 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 823F120130; Thu, 14 Dec 2017 14:29:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 583494198E04; Thu, 14 Dec 2017 14:29:00 +0100 (CET) Date: Thu, 14 Dec 2017 14:29:00 +0100 From: Juergen Schoenwaelder To: Lou Berger Cc: Kent Watsen , "netconf@ietf.org" Message-ID: <20171214132900.azvb6o53wbf4xdq7@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Lou Berger , Kent Watsen , "netconf@ietf.org" References: <5F4462F2-2679-4CFE-A060-41177F9A5D04@juniper.net> <307ec8f7-4562-ae02-d8f1-1a281966ac56@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <307ec8f7-4562-ae02-d8f1-1a281966ac56@labn.net> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Netconf] Virtual Interim Results 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, 14 Dec 2017 13:29:07 -0000 On Thu, Dec 14, 2017 at 08:17:10AM -0500, Lou Berger wrote: > I guess I have no choice but to object.    I'm an interested party who > was unable to attend this very short notice interim - so am proof that > this assertion is false.  This is a process objection, which I really > don't like making, but as chair of NetMod I feel obligated to make it as > NetMod has many interested parties and that WG wasn't even notified of > the meeting -- I know most of us at least track both groups/lists, but I > don't think it fair to assume that all interested in Library do. This was a NETCONF interim. I do not think there is a process requirement that NETMOD is formally notified. So what exactly is your process objection? That NETMOD was not formally notified or do you object to the statement that "it is assumed that all interested parties attended the meeting"? Sure, this assertion may not be true but the complete sentence was: These selections now need to be confirmed on the list. Since it's assumed that all interested parties attended the meeting, these decisions will be final unless there are any objections raised in a week's time. So what is basis of your process objection? Can we simply stop this debate and get back to the technical issues. Do you have any technical concerns with alternative B? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Dec 14 06:03: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 F22CD1200CF for ; Thu, 14 Dec 2017 06:03:28 -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 (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 RUvkAoQm2TCc for ; Thu, 14 Dec 2017 06:03:22 -0800 (PST) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF141124205 for ; Thu, 14 Dec 2017 06:03:22 -0800 (PST) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 923EB175E87 for ; Thu, 14 Dec 2017 07:03:22 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id lq3J1w00l2SSUrH01q3MB2; Thu, 14 Dec 2017 07:03:22 -0700 X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=ocR9PWop10UA:10 a=SYBhv4dmsoHmqJVBed8A:9 a=7Zwj6sZBwVKJAoWSPKxL6X1jA+E=:19 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=RQYFtYNEclHjKiPhdFxEeDGqepj4cLqP7kbTJDRFht8=; b=xsynmCzShEBCWoOAON6vLJGBuj ZiAIWdsGSLD7/EUqhh1e9M4Hz1d54PBr7YRMKoH4aNDHjywtx/CsrsPX520qRvZrveWtGtn+B1HNT 4I9GgcTe/9rPtwOuGQIpLSTz7; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:43910 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ePU6Y-003WsY-IP; Thu, 14 Dec 2017 07:03:18 -0700 To: Kent Watsen , "netconf@ietf.org" References: <5F4462F2-2679-4CFE-A060-41177F9A5D04@juniper.net> <307ec8f7-4562-ae02-d8f1-1a281966ac56@labn.net> <20171214132900.azvb6o53wbf4xdq7@elstar.local> From: Lou Berger Message-ID: <0f2270a0-7c2b-76c0-a30b-041301bf655c@labn.net> Date: Thu, 14 Dec 2017 09:03:15 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171214132900.azvb6o53wbf4xdq7@elstar.local> 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: 1ePU6Y-003WsY-IP 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]:43910 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Netconf] Virtual Interim Results 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, 14 Dec 2017 14:03:29 -0000 Juergen, Sigh. On 12/14/2017 8:29 AM, Juergen Schoenwaelder wrote: > On Thu, Dec 14, 2017 at 08:17:10AM -0500, Lou Berger wrote: > >> I guess I have no choice but to object.    I'm an interested party who >> was unable to attend this very short notice interim - so am proof that >> this assertion is false.  This is a process objection, which I really >> don't like making, but as chair of NetMod I feel obligated to make it as >> NetMod has many interested parties and that WG wasn't even notified of >> the meeting -- I know most of us at least track both groups/lists, but I >> don't think it fair to assume that all interested in Library do. > taking this out of order, and restoring context: > So what exactly is your > process objection? The original message that I responded to says: >>     Since it's assumed that all interested parties attended the meeting, >>    these decisions will be final unless there are any objections raised in a week's time. and my response is: > I'm an interested party who > was unable to attend this very short notice interim - so am proof that > this assertion is false.  I'm not sure how this could be more clear, do you really need more explanation? > This was a NETCONF interim. I do not think there is a process > requirement that NETMOD is formally notified. It is not uncommon for chairs to agree to run the process for a document that overlaps multiple WGs in one wg and to keep the other WG informed of updates.  This is what happened for revised datastores as well as this document. > That NETMOD was not formally notified or do you > object to the statement that "it is assumed that all interested > parties attended the meeting"? Sure, this assertion may not be true > but the complete sentence was: > > These selections now need to be confirmed on the list. Since it's > assumed that all interested parties attended the meeting, these > decisions will be final unless there are any objections raised in a > week's time. Yes, so I raised an objection, one based on both the assertion (as a chair of WG that has interest in this document) and a technical concern (as a contributor) -- I frankly don't understand why are you pushing back on this? > So what is basis of your process objection? Can we simply stop this > debate and get back to the technical issues. Do you have any technical > concerns with alternative B? Please see my original message and feel free to respond. Thanks, Lou > > /js > From nobody Thu Dec 14 06:14:29 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 4E7FA1292FD for ; Thu, 14 Dec 2017 06:14:27 -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 zmVuke3-bB8I for ; Thu, 14 Dec 2017 06:14:25 -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 78A7B1293DB for ; Thu, 14 Dec 2017 06:14:24 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 2F7ABEE6; Thu, 14 Dec 2017 15:14:23 +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 VjJblZdLT8aX; Thu, 14 Dec 2017 15:14:22 +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; Thu, 14 Dec 2017 15:14:23 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1C2E420131; Thu, 14 Dec 2017 15:14:23 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 1kRBU2v84hdp; Thu, 14 Dec 2017 15:14:22 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAC3F20130; Thu, 14 Dec 2017 15:14:22 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C7C7D41991CF; Thu, 14 Dec 2017 15:14:22 +0100 (CET) Date: Thu, 14 Dec 2017 15:14:22 +0100 From: Juergen Schoenwaelder To: Lou Berger Cc: Kent Watsen , "netconf@ietf.org" Message-ID: <20171214141422.3y7wnwg43qalsnqc@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Lou Berger , Kent Watsen , "netconf@ietf.org" References: <5F4462F2-2679-4CFE-A060-41177F9A5D04@juniper.net> <307ec8f7-4562-ae02-d8f1-1a281966ac56@labn.net> <20171214132900.azvb6o53wbf4xdq7@elstar.local> <0f2270a0-7c2b-76c0-a30b-041301bf655c@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0f2270a0-7c2b-76c0-a30b-041301bf655c@labn.net> User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Netconf] Virtual Interim Results 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, 14 Dec 2017 14:14:27 -0000 On Thu, Dec 14, 2017 at 09:03:15AM -0500, Lou Berger wrote: > > I'm not sure how this could be more clear, do you really need more > explanation? > I understand your concern, I still do not see how you justify a 'process objection'. Perhaps my understanding what a 'process objection' is is differnet from yours. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Dec 14 06:33: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 10877126C89 for ; Thu, 14 Dec 2017 06:33:24 -0800 (PST) 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 DHTQybNCrFAw for ; Thu, 14 Dec 2017 06:33:16 -0800 (PST) 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 C07DA124B09 for ; Thu, 14 Dec 2017 06:33:12 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2EjAgCh299Z/xoHYZleGgEBAQECAQEBAQgBAQEBg12BUi6Dc5lRgUsrmEEKhTsChD9XAQIBAQEBAQIDaCiFHgEFIw8BBVEJAg4KAgIJHQICRxAGAQwIAQGKGQEEjgadZ4InizwBAQgBAQEBJIEOgh+CB4FRghWCf4gYgmEFoUSBCIEmjHOHeIkuBYculT4CBAYFAhkBgTlYgQ5TJl2HHos7AYEQAQEB X-IPAS-Result: A2EjAgCh299Z/xoHYZleGgEBAQECAQEBAQgBAQEBg12BUi6Dc5lRgUsrmEEKhTsChD9XAQIBAQEBAQIDaCiFHgEFIw8BBVEJAg4KAgIJHQICRxAGAQwIAQGKGQEEjgadZ4InizwBAQgBAQEBJIEOgh+CB4FRghWCf4gYgmEFoUSBCIEmjHOHeIkuBYculT4CBAYFAhkBgTlYgQ5TJl2HHos7AYEQAQEB X-IronPort-AV: E=Sophos;i="5.43,368,1503352800"; d="scan'208";a="54615897" Received: from mail-mtas26.fraunhofer.de ([153.97.7.26]) by mail-edgeS23.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Dec 2017 15:33:10 +0100 X-IronPort-AV: E=Sophos;i="5.45,400,1508796000"; d="scan'208";a="7108243" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaS26.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Dec 2017 15:33:08 +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 vBEEX6Xr031878 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Dec 2017 15:33:08 +0100 Received: from [134.102.160.137] (134.102.160.137) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 14 Dec 2017 15:33:01 +0100 To: Lou Berger , Kent Watsen , "netconf@ietf.org" References: <5F4462F2-2679-4CFE-A060-41177F9A5D04@juniper.net> <307ec8f7-4562-ae02-d8f1-1a281966ac56@labn.net> <20171214132900.azvb6o53wbf4xdq7@elstar.local> From: Henk Birkholz Message-ID: Date: Thu, 14 Dec 2017 15:33:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171214132900.azvb6o53wbf4xdq7@elstar.local> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [134.102.160.137] Archived-At: Subject: Re: [Netconf] Virtual Interim Results 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, 14 Dec 2017 14:33:24 -0000 Hello all, with respect to "process", a subscription to ietf announce and a few filters thrown into that to enable you to only see what you want to know might significantly increase visibility (at least for me it does). Also, yes 5 days is pretty much "on short notice", too short for my schedule at least. Viele Grüße, Henk On 12/14/2017 02:29 PM, Juergen Schoenwaelder wrote: > On Thu, Dec 14, 2017 at 08:17:10AM -0500, Lou Berger wrote: > >> I guess I have no choice but to object.    I'm an interested party who >> was unable to attend this very short notice interim - so am proof that >> this assertion is false.  This is a process objection, which I really >> don't like making, but as chair of NetMod I feel obligated to make it as >> NetMod has many interested parties and that WG wasn't even notified of >> the meeting -- I know most of us at least track both groups/lists, but I >> don't think it fair to assume that all interested in Library do. > > This was a NETCONF interim. I do not think there is a process > requirement that NETMOD is formally notified. So what exactly is your > process objection? That NETMOD was not formally notified or do you > object to the statement that "it is assumed that all interested > parties attended the meeting"? Sure, this assertion may not be true > but the complete sentence was: > > These selections now need to be confirmed on the list. Since it's > assumed that all interested parties attended the meeting, these > decisions will be final unless there are any objections raised in a > week's time. > > So what is basis of your process objection? Can we simply stop this > debate and get back to the technical issues. Do you have any technical > concerns with alternative B? > > /js > From nobody Thu Dec 14 06:36: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 1C01E1293DB for ; Thu, 14 Dec 2017 06:36:15 -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 pV7FmOgxqnb8 for ; Thu, 14 Dec 2017 06:36:08 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 27A76124B09 for ; Thu, 14 Dec 2017 06:36:08 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id F41341AE0144; Thu, 14 Dec 2017 15:36:06 +0100 (CET) Date: Thu, 14 Dec 2017 15:34:48 +0100 (CET) Message-Id: <20171214.153448.1803445847942771029.mbj@tail-f.com> To: lberger@labn.net Cc: kwatsen@juniper.net, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <307ec8f7-4562-ae02-d8f1-1a281966ac56@labn.net> References: <5F4462F2-2679-4CFE-A060-41177F9A5D04@juniper.net> <307ec8f7-4562-ae02-d8f1-1a281966ac56@labn.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Netconf] Virtual Interim Results 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, 14 Dec 2017 14:36:15 -0000 Lou Berger wrote: > As an individual contributor, I suspect that the choice is a fine one= , > but would like to understand how (b) addresses=A0 the objectives on s= lides > 2 and 3 or is even intended to be implemented - e.g., I read "Each > datastore refers to a schema" as meaning library is retrievable from > every datastore, and I'd be surprised if that was the intent.=A0 With Alt A - C, the yang-library data is normal operational state. When it says "each datastore refers to a schema", the word "datastore" refers to a list entry in the "datastore" list shown in the figure. The text really just says the same as the tree diagram: +=AD=ADro datastore* [name] | +=AD=ADro name identityref | +=AD=ADro schema =AD> ../../schema/name "a datastore refers to a schema" /martin From nobody Thu Dec 14 06:37: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 5C789126C89 for ; Thu, 14 Dec 2017 06:37:10 -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_MSPIKE_H2=-2.8, 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 AFYP94qix2yt for ; Thu, 14 Dec 2017 06:37:09 -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 0EC571201F2 for ; Thu, 14 Dec 2017 06:37:09 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 669E31AB16B for ; Thu, 14 Dec 2017 07:37:07 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id lqd31w00w2SSUrH01qd6t4; Thu, 14 Dec 2017 07:37:07 -0700 X-Authority-Analysis: v=2.2 cv=VcCHBBh9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=ocR9PWop10UA:10 a=M6BW37zdGaBS0J_zdZIA: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=nkpOXo8QufZ2ScCqSvwgqG0fUSJg3QUKIymvr9waDIw=; b=IXGWAMf+5Zk/nsZHTI5vLt0f4i h2yi6DgOWwM1M8hURnbsCx7ds4pyyJpNpx1igcWMvBMRLHYXicIyIHtUkI9SVR84IDrsjq6AqLuwy ojgiy1QkAIsd04w8FCzeNk98u; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:46712 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ePUdD-003iZq-MC; Thu, 14 Dec 2017 07:37:03 -0700 To: Henk Birkholz , Kent Watsen , "netconf@ietf.org" References: <5F4462F2-2679-4CFE-A060-41177F9A5D04@juniper.net> <307ec8f7-4562-ae02-d8f1-1a281966ac56@labn.net> <20171214132900.azvb6o53wbf4xdq7@elstar.local> From: Lou Berger Message-ID: Date: Thu, 14 Dec 2017 09:37:00 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Exim-ID: 1ePUdD-003iZq-MC 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]:46712 X-Source-Auth: lberger@labn.net X-Email-Count: 5 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Netconf] Virtual Interim Results 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, 14 Dec 2017 14:37:10 -0000 On 12/14/2017 9:33 AM, Henk Birkholz wrote: > Also, yes 5 days is pretty much "on short notice", too short for my > schedule at least. Strictly speaking this too is a process violation, but not the one I objected to... Lou PS I'm looking forward to the technical discussion on this topic. From nobody Thu Dec 14 06: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 5F58E1293D6 for ; Thu, 14 Dec 2017 06:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55WeExupF873 for ; Thu, 14 Dec 2017 06:42:39 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F7F12932A for ; Thu, 14 Dec 2017 06:42:39 -0800 (PST) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id DB090140615 for ; Thu, 14 Dec 2017 07:42:37 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id lqia1w0032SSUrH01qidCd; Thu, 14 Dec 2017 07:42:37 -0700 X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=ocR9PWop10UA:10 a=wU2YTnxGAAAA:8 a=3jYNHFgHMwvkwKzdkUoA:9 a=QEXdDO2ut3YA:10 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:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=wit/6UoNjZDWhin5QGl0cfn6FVtzxDgPZYgAlH2vS8A=; b=fVwnAFMJqbjJ/QHDHJp3a39MNZ y9Yqd0pA1rLLqRrY891Ul7YbexPjEXNNx4NfVMpm38VDy2OEmzXzs7ZJPG1McDh5UAU/i2EABlaam 6o7ZW22Iw510Lh8/iCzpLVdSm; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:47610 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ePUiX-003kKR-Rz; Thu, 14 Dec 2017 07:42:33 -0700 To: Martin Bjorklund Cc: kwatsen@juniper.net, netconf@ietf.org References: <5F4462F2-2679-4CFE-A060-41177F9A5D04@juniper.net> <307ec8f7-4562-ae02-d8f1-1a281966ac56@labn.net> <20171214.153448.1803445847942771029.mbj@tail-f.com> From: Lou Berger Message-ID: <7e4bd018-e270-35a4-7ada-620d74b9d63b@labn.net> Date: Thu, 14 Dec 2017 09:42:30 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171214.153448.1803445847942771029.mbj@tail-f.com> 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: 1ePUiX-003kKR-Rz 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]:47610 X-Source-Auth: lberger@labn.net X-Email-Count: 8 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Netconf] Virtual Interim Results 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, 14 Dec 2017 14:42:42 -0000 Thanks Martin, see below. On 12/14/2017 9:34 AM, Martin Bjorklund wrote: > Lou Berger wrote: >> As an individual contributor, I suspect that the choice is a fine one, >> but would like to understand how (b) addresses  the objectives on slides >> 2 and 3 or is even intended to be implemented - e.g., I read "Each >> datastore refers to a schema" as meaning library is retrievable from >> every datastore, and I'd be surprised if that was the intent.  > With Alt A - C, the yang-library data is normal operational state. so is only available from that data store, right.  I think this has to be made explicit when documenting this as I've seen this misinterpreted (I asked a handful of folks and got different answers...) > When it says "each datastore refers to a schema", the word "datastore" > refers to a list entry in the "datastore" list shown in the figure. > The text really just says the same as the tree diagram: > > +­­ro datastore* [name] > | +­­ro name identityref > | +­­ro schema ­> ../../schema/name > > > "a datastore refers to a schema" can you summarize how b addresses, the objectives: > > o As efficient as possible for a client to consume. > Since the size of the yang library can be quite large, it > shouldbe possible for clients to cache the yang library > information. > > o A dynamic datastore must be able to implement a module or > feature that is not implemented in the conventional > datastores. > > o It must be possible to NOT implement a module or feature in > operational, even if it is implemented in some other datastore. > This is required for transition purposes; a server that wants to > implement should not have to implement all > modules at once. > > o A given module can only be implemented in one revision in all > datastores. If a module is implemented in more than one > datastores, the same revision is implemented in all these > datastores. > > o Multiple revisions can be used for import, if import-by revision > is used. > > o Nice to have: make it possible to be used by schema mount Thanks, Lou > > > /martin > From nobody Thu Dec 14 06:59: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 4FABD126D3F for ; Thu, 14 Dec 2017 06:59:40 -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 myJUi457NqRR for ; Thu, 14 Dec 2017 06:59:38 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id ACF211293DF for ; Thu, 14 Dec 2017 06:59:38 -0800 (PST) Received: from localhost (unknown [173.38.220.60]) by mail.tail-f.com (Postfix) with ESMTPSA id BBD501AE0144; Thu, 14 Dec 2017 15:59:37 +0100 (CET) Date: Thu, 14 Dec 2017 15:58:18 +0100 (CET) Message-Id: <20171214.155818.214441561403113870.mbj@tail-f.com> To: lberger@labn.net Cc: kwatsen@juniper.net, netconf@ietf.org From: Martin Bjorklund In-Reply-To: <7e4bd018-e270-35a4-7ada-620d74b9d63b@labn.net> References: <307ec8f7-4562-ae02-d8f1-1a281966ac56@labn.net> <20171214.153448.1803445847942771029.mbj@tail-f.com> <7e4bd018-e270-35a4-7ada-620d74b9d63b@labn.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Netconf] Virtual Interim Results 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, 14 Dec 2017 14:59:40 -0000 Lou Berger wrote: > Thanks Martin, see below. > = > = > On 12/14/2017 9:34 AM, Martin Bjorklund wrote: > > Lou Berger wrote: > >> As an individual contributor, I suspect that the choice is a fine = one, > >> but would like to understand how (b) addresses=A0 the objectives o= n slides > >> 2 and 3 or is even intended to be implemented - e.g., I read "Each= > >> datastore refers to a schema" as meaning library is retrievable fr= om > >> every datastore, and I'd be surprised if that was the intent.=A0 > > With Alt A - C, the yang-library data is normal operational state. > = > so is only available from that data store, right.=A0 I think this has= to > be made explicit when documenting this as I've seen this misinterpret= ed > (I asked a handful of folks and got different answers...) Yes, I think you have already made this comment on the list, and I have updated the document (not yet published) with: All data nodes in "ietf-yang-library" are "config false", and thus accessible in the operational state datastore. > > When it says "each datastore refers to a schema", the word "datasto= re" > > refers to a list entry in the "datastore" list shown in the figure.= > > The text really just says the same as the tree diagram: > > > > +=AD=ADro datastore* [name] > > | +=AD=ADro name identityref > > | +=AD=ADro schema =AD> ../../schema/name > > > > > > "a datastore refers to a schema" > = > can you summarize how b addresses, the objectives: > > > > o As efficient as possible for a client to consume. > > Since the size of the yang library can be quite large, it > > shouldbe possible for clients to cache the yang library > > information. There's a global checksum, and a checksum per schema. So a client can cache the yang library contents. > > o A dynamic datastore must be able to implement a module or > > feature that is not implemented in the conventional > > datastores. The dynamic datastore would have its own schema, which would not be the same as the schema for the conventional datastores. > > o It must be possible to NOT implement a module or feature in > > operational, even if it is implemented in some other datastore. > > This is required for transition purposes; a server that wants to > > implement should not have to implement all > > modules at once. The operational state datastore would have its own schema, which would not be the same as the schema for the other datastore. > > o A given module can only be implemented in one revision in all > > datastores. If a module is implemented in more than one > > datastores, the same revision is implemented in all these > > datastores. This objective is redundant; it is a requirement from RFC 7950. The YANG library is a reporting module; the server is supposed to follow RFC 7950 and use YANG library to report what it implements. > > o Multiple revisions can be used for import, if import-by revision > > is used. This is the same for all solutions; the proposed way of handling this is to have a list of imported modules, keyed by module name and revision. > > o Nice to have: make it possible to be used by schema mount This alternative defines a reusable "schema", which schema mount can re-use. See Rob's presentation from the last IETF, for example. He has also sent this to the list (see his message from 2017-11-09, "Alternative YANG library structure for 7895bis") /martin From nobody Thu Dec 14 07: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 879FC126DED for ; Thu, 14 Dec 2017 07:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiMCExTUD2-a for ; Thu, 14 Dec 2017 07:17:23 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0541B126D3F for ; Thu, 14 Dec 2017 07:17:23 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id n138so11977594wmg.2 for ; Thu, 14 Dec 2017 07:17:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=ZWFqGr9rsFqKhrlL1reF//9YMcJPlOOkehGHgF0e3co=; b=JwVO08vfWd43IJAbu65n0KufsiNDbog5Kv+Sme//zOMHqVVtmQ1zVrK+uycInRXEaS lYRdZg/qigfglrmVIkXE8tZb9i9wAlSYfQ+U1IozGhlIM2MaXVgJok1p7tv8Br4DaoK8 bcSgBTRoSD6pP3+VcKEzvaSB3JeCQGbYSxj9uSIjDKT/qi6tBUFTdx8O9W4mwrFMnv6E IxaW6s3RbaGYlR+1vF29XfjiVXajL42TP8FA6xCDsOuQd3RFbKN6GaONzcrsP4qufSbZ zvmaPGH2Cw/8W1EjpgDmTOcl2iNjBmUD3db8DHWkGAI3OTVOCAq4WAz5PBKH19bk/BrF 1nCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=ZWFqGr9rsFqKhrlL1reF//9YMcJPlOOkehGHgF0e3co=; b=CNRLd/c5UHpoRivqCYWoCDmPzmUZ6IKQ9bM2FZvFF/5cIq4VT3ilqG193vgN9A1ufX +rwCHTTj79CvKW9VwnoDXwNhoVm96bymbqLQ661CVOjRUvu8pqb/mA4D9bzm4SW1xnJl 76DPSHHLcIDL4d0m5FDKBX7RXugO7wXf3lU9CftyE2Q1sZ0vNmZ61h5/UGqHlOUWxWZr Gxo4zXsEizsCz9TKQjggLAjhzUFdMeBT88Ml9j6SsZQGNF5wnuaAXCIOJ9bgf1F1JX7Q A+BU4O80BXsCTEx6nNjVl+6d04CjgH7MW7PNXQr2PGBRgWlPCqTUMdA8XYIWIrBNiSb+ 6DMQ== X-Gm-Message-State: AKGB3mKix4tAIBF38qp3NRdGDgJ9VUOTet+RhqHB29Otf3w7m9K8uFBe EP4h/h2IASHbuL5gro/da6S1xw== X-Google-Smtp-Source: ACJfBosPV3pyySnKLQ+EDjqTs12iflCqrIL739PeqUrEHdmsIXGIW+kTLaf5jX2hGMGuZ8+oG0tCHQ== X-Received: by 10.28.165.130 with SMTP id o124mr2759408wme.88.1513264641349; Thu, 14 Dec 2017 07:17:21 -0800 (PST) Received: from DESKTOPFLHJVQJ ([2001:16b8:2dff:f500:dc2b:c443:5d52:a511]) by smtp.gmail.com with ESMTPSA id c12sm4478892wmi.43.2017.12.14.07.17.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 07:17:20 -0800 (PST) From: "Mehmet Ersue" To: "'Henk Birkholz'" , "'Lou Berger'" , "'Kent Watsen'" , References: <5F4462F2-2679-4CFE-A060-41177F9A5D04@juniper.net> <307ec8f7-4562-ae02-d8f1-1a281966ac56@labn.net> <20171214132900.azvb6o53wbf4xdq7@elstar.local> In-Reply-To: Date: Thu, 14 Dec 2017 16:17:19 +0100 Message-ID: <012c01d374ee$a2d605d0$e8821170$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHaIH4FM+pUWbbv2HmPzvAZLqTLswFOGcXtAhWFDFUCPt4JoaMIh6hw Content-Language: de Archived-At: Subject: Re: [Netconf] Virtual Interim Results 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, 14 Dec 2017 15:17:25 -0000 The integration of YANG Library and Schema Mount has been discussed in = NETMOD WG. Process-wise it would be more appropriate to forward the = interim invitation to NETMOD maillist. IETF process allows the announcement of virtual interims one week before = the call but says in the same sentence "(ideally two)". Obviously one = week is too short for many people. Cheers, Mehmet > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Henk > Birkholz > Sent: Thursday, December 14, 2017 3:33 PM > To: Lou Berger ; Kent Watsen ; > netconf@ietf.org > Subject: Re: [Netconf] Virtual Interim Results >=20 > Hello all, >=20 > with respect to "process", a subscription to ietf announce and a few = filters > thrown into that to enable you to only see what you want to know might > significantly increase visibility (at least for me it does). >=20 > Also, yes 5 days is pretty much "on short notice", too short for my = schedule > at least. >=20 > Viele Gr=C3=BC=C3=9Fe, >=20 > Henk >=20 > On 12/14/2017 02:29 PM, Juergen Schoenwaelder wrote: > > On Thu, Dec 14, 2017 at 08:17:10AM -0500, Lou Berger wrote: > > > >> I guess I have no choice but to object. I'm an interested party > >> who was unable to attend this very short notice interim - so am = proof > >> that this assertion is false. This is a process objection, which I > >> really don't like making, but as chair of NetMod I feel obligated = to > >> make it as NetMod has many interested parties and that WG wasn't = even > >> notified of the meeting -- I know most of us at least track both > >> groups/lists, but I don't think it fair to assume that all = interested in Library > do. > > > > This was a NETCONF interim. I do not think there is a process > > requirement that NETMOD is formally notified. So what exactly is = your > > process objection? That NETMOD was not formally notified or do you > > object to the statement that "it is assumed that all interested > > parties attended the meeting"? Sure, this assertion may not be true > > but the complete sentence was: > > > > These selections now need to be confirmed on the list. Since it's > > assumed that all interested parties attended the meeting, these > > decisions will be final unless there are any objections raised in a > > week's time. > > > > So what is basis of your process objection? Can we simply stop this > > debate and get back to the technical issues. Do you have any = technical > > concerns with alternative B? > > > > /js > > >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Dec 14 09:00: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 598B0126C0F for ; Thu, 14 Dec 2017 09:00:50 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id us-28IhW1Uk5 for ; Thu, 14 Dec 2017 09:00:48 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2C45127F0E for ; Thu, 14 Dec 2017 09:00:47 -0800 (PST) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vBEH0kaM027022; Thu, 14 Dec 2017 09:00:46 -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=Ritjp3A6yemFb1H9ADZI005rHejQQtgb+r2zIfFjUI8=; b=TZ5qfzeO8/XH1OyBAUtKHJzQKw8g8tpLWuzBv6bokhcfr7RFA+JdBeufvSVUW+8vfaS6 WCoAlLnZLAQ1GwtDIzTMEbDFwB8Z/uKp6wKNV+dg4jKh2KNLl57clt5O5//LdvNfyd3W pxIZT682YRQTHEejWa7Neoc2bt31efZNA9CLsKzeG9ZK4rL5M1nNRp/71A13PEemhq1b BVjal68eyWn8m85KgLCEWwm0Tjd7afo2gTNA/OOqMj86VMVPdD1ttmp5OI9Ecd2m+aa/ u5hrmgc8HiAaBeIfK3feWpb2Xt2ElvJE8Moo9OuIkE/e1J54b93//zOBnOYWNXJwx8ON pA== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0018.outbound.protection.outlook.com [216.32.180.18]) by mx0b-00273201.pphosted.com with ESMTP id 2eutp1rdw4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 14 Dec 2017 08:59:59 -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.323.4; Thu, 14 Dec 2017 16:59:57 +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.0323.011; Thu, 14 Dec 2017 16:59:57 +0000 From: Kent Watsen To: Mehmet Ersue , 'Henk Birkholz' , 'Lou Berger' , "netconf@ietf.org" Thread-Topic: [Netconf] Virtual Interim Results Thread-Index: AQHTdKOibhSCoe8YoEC3JzdZ5zqILKNC0moAgAADTgCAABHiAIAADGKA//+WkYA= Date: Thu, 14 Dec 2017 16:59:57 +0000 Message-ID: <24A7C727-2A7C-4737-8A2D-5C4B25CE6423@juniper.net> References: <5F4462F2-2679-4CFE-A060-41177F9A5D04@juniper.net> <307ec8f7-4562-ae02-d8f1-1a281966ac56@labn.net> <20171214132900.azvb6o53wbf4xdq7@elstar.local> <012c01d374ee$a2d605d0$e8821170$@gmail.com> In-Reply-To: <012c01d374ee$a2d605d0$e8821170$@gmail.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: [66.129.239.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR05MB275; 6:3ZBsGjljnZxp1G/VRt5ihRylOsyiIwfETs5Q4gB1nx7S7uFaVhnxbG+nTKZL962Ezyw0nOq/DjfmCHaIyoBovYW5h1jmzhDr9szK/yNxdgosHWT/FnBzOJGc9pFlvNhZGS2tGQUljv2vhSub9A8/unHtaleI0Xb6PUfoxY3u5n6HVBwKgrBUgL77LdX72sV+DeeP35YFMtdH66JM4Rno6E1yhSyF8xUdnV2x7YjI+P+7fQtGY6zgJCbBMYlrGXMGdV1pHno/Dy/SnmivSRnkcZ7s4pKXdHuUpRFFAbww1nRkI1qfmnXLvkp6lx2fynRugdz3Q2+n+gSFxUeBzXpkMDmf8toi0ArEjHlEsyVYbX8=; 5:BLCanxodFuUGqdX6uQpytmShzzY3ECm1FoGiowgVvF1IeqsegaKZ9/3H+j/r32R2MJHF/Y4z7l8kp/zKmnbeFxT8U7wFNDaa8hotE9v3NuFLvf1Mj3ABgbYDHXNuzPT96w7/dCwRc27ymWL0ZQQ6e2be2+NUfwxY4eTsOHgQfSE=; 24:s33FUhpin0uXyTHuU+483ZjauRAxBaCWfrOHAX1TpJPMLxMkoha9nzXar95mbhPqg6cof29CmcbxdH2tKKei8v4D2dMAhWg7wH5/GVd+hdU=; 7:A2jL2ZK3oe+Zc+157hGz5qcTyP34lS2zreNbVGJiWPRmiIQIgQbxRkQV7BSCwzhvPOS3B8BK2xpY3Ouk8Uhjb0hIDVbHM0EkUL4YWU7NsWKaXAg3ihhfjEC8GmXr1aACY4DuV1SRXaWppQ1+vI7kLX8qrrGsYhHpOcdtkM8YiGXxYzIzT+JU1EB0YR/XkO9y+kdTJW+Ba3o6DdrgVZ8Z8Besa9Z5bvP68scQTkqaWcYoD0f84hK7C8BdrqR8Q4oi x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4e2879e9-3529-4db8-5c26-08d543141b41 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603307); SRVR:BLUPR05MB275; x-ms-traffictypediagnostic: BLUPR05MB275: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231023)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6072148)(201708071742011); SRVR:BLUPR05MB275; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR05MB275; x-forefront-prvs: 05214FD68E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(396003)(39860400002)(13464003)(189003)(199004)(24454002)(53754006)(2906002)(6306002)(2950100002)(6512007)(33656002)(68736007)(3280700002)(102836003)(6116002)(3846002)(7736002)(8936002)(25786009)(305945005)(575784001)(86362001)(2900100001)(3660700001)(316002)(106356001)(83506002)(66066001)(82746002)(83716003)(58126008)(229853002)(6246003)(81166006)(36756003)(5660300001)(6486002)(2501003)(6436002)(110136005)(53936002)(77096006)(97736004)(14454004)(99286004)(8676002)(39060400002)(93886005)(478600001)(53546011)(6506007)(76176011)(966005)(59450400001)(105586002)(81156014); 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: <6BD75174D6F67F40B76B2E94DF68C5F4@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 4e2879e9-3529-4db8-5c26-08d543141b41 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2017 16:59:57.7062 (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-12-14_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712140233 Archived-At: Subject: Re: [Netconf] Virtual Interim Results 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, 14 Dec 2017 17:00:50 -0000 DQpIaSBNZWhtZXQsIGV0IGFsLiwNCg0KDQo+IFRoZSBpbnRlZ3JhdGlvbiBvZiBZQU5HIExpYnJh cnkgYW5kIFNjaGVtYSBNb3VudCBoYXMgYmVlbiBkaXNjdXNzZWQgaW4gTkVUTU9EIFdHLiBQcm9j ZXNzLXdpc2UgaXQgd291bGQgYmUgbW9yZSBhcHByb3ByaWF0ZSB0byBmb3J3YXJkIHRoZSBpbnRl cmltIGludml0YXRpb24gdG8gTkVUTU9EIG1haWxsaXN0Lg0KDQpJIGFncmVlIHRoYXQgaXQgd291 bGQndmUgYmVlbiBnb29kbmVzcyBhbmQgdGhhdCB3ZSBzaG91bGQndmUgZG9uZSB0aGlzLCBidXQg bm90IGFuIGFjdHVhbCBJRVRGIHByb2Nlc3MgdmlvbGF0aW9uLCByaWdodD8NCg0KDQo+IElFVEYg cHJvY2VzcyBhbGxvd3MgdGhlIGFubm91bmNlbWVudCBvZiB2aXJ0dWFsIGludGVyaW1zIG9uZSB3 ZWVrIGJlZm9yZSB0aGUgY2FsbCBidXQgc2F5cyBpbiB0aGUgc2FtZSBzZW50ZW5jZSAiKGlkZWFs bHkgdHdvKSIuIE9idmlvdXNseSBvbmUgd2VlayBpcyB0b28gc2hvcnQgZm9yIG1hbnkgcGVvcGxl Lg0KDQpGV0lXLCBhIHdlZWsncyBub3RpY2Ugd2FzIGdpdmVuIChzZWUgWzFdLCBhbmQgbm90ZSB0 aGUgUFMgYXQgYm90dG9tKSwgYXMgaXMgdGhlIG1pbmltdW0gYWxsb3dlZCBwZXIgWzJdLiAgVGhl IGNoYWlycyBkaXNjdXNzZWQgdGhlIHNob3J0IHRpbWluZywgYnV0IGl0IHdhcyBlaXRoZXIgdGhp cyBvciB3YWl0IHVudGlsIGFmdGVyIHRoZSBOZXcgWWVhciwgaW50cm9kdWNpbmcgd2Vla3Mgb2Yg ZGVsYXkuICAgV2UgZmVsdCBpdCB3b3J0aCBwdXNoaW5nIGZvciB0aGUgbW9yZSBhZ2dyZXNzaXZl IHRpbWluZyBpbiB0aGlzIGNpcmN1bXN0YW5jZS4gIFBsZWFzZSBub3RlLCBhcyBteSBjby1jaGFp cnMgYW5kIEFEIHdpbGwgYXR0ZXN0LCBJJ20gY29uc2lzdGVudGx5IHRyeWluZyB0byBiZSBmYWly IHdpdGggcGVvcGxlJ3MgdGltZTsgdGhpcyBjaXJjdW1zdGFuY2UgaXMgYW4gb3V0bGllciBhbmQg ZG9lcyBub3QgcmVwcmVzZW50IGEgbW9kdXMgb3BlcmFuZGkgZ29pbmcgZm9yd2FyZC4NCg0KWzFd IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0Y29uZi9jdXJyZW50L21z ZzEzODcwLmh0bWwNClsyXSBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9pbnRl cmltLW1lZXRpbmdzLmh0bWwNCg0KDQpLZW50DQoNCg0KPiBDaGVlcnMsDQo+IE1laG1ldA0KDQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTmV0Y29uZiBbbWFpbHRvOm5l dGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEhlbmsNCj4gQmlya2hvbHoNCj4g U2VudDogVGh1cnNkYXksIERlY2VtYmVyIDE0LCAyMDE3IDM6MzMgUE0NCj4gVG86IExvdSBCZXJn ZXIgPGxiZXJnZXJAbGFibi5uZXQ+OyBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD47 DQo+IG5ldGNvbmZAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtOZXRjb25mXSBWaXJ0dWFsIElu dGVyaW0gUmVzdWx0cw0KPiANCj4gSGVsbG8gYWxsLA0KPiANCj4gd2l0aCByZXNwZWN0IHRvICJw cm9jZXNzIiwgYSBzdWJzY3JpcHRpb24gdG8gaWV0ZiBhbm5vdW5jZSBhbmQgYSBmZXcgZmlsdGVy cw0KPiB0aHJvd24gaW50byB0aGF0IHRvIGVuYWJsZSB5b3UgdG8gb25seSBzZWUgd2hhdCB5b3Ug d2FudCB0byBrbm93IG1pZ2h0DQo+IHNpZ25pZmljYW50bHkgaW5jcmVhc2UgdmlzaWJpbGl0eSAo YXQgbGVhc3QgZm9yIG1lIGl0IGRvZXMpLg0KPiANCj4gQWxzbywgeWVzIDUgZGF5cyBpcyBwcmV0 dHkgbXVjaCAib24gc2hvcnQgbm90aWNlIiwgdG9vIHNob3J0IGZvciBteSBzY2hlZHVsZQ0KPiBh dCBsZWFzdC4NCj4gDQo+IFZpZWxlIEdyw7zDn2UsDQo+IA0KPiBIZW5rDQo+IA0KPiBPbiAxMi8x NC8yMDE3IDAyOjI5IFBNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgd3JvdGU6DQo+ID4gT24gVGh1 LCBEZWMgMTQsIDIwMTcgYXQgMDg6MTc6MTBBTSAtMDUwMCwgTG91IEJlcmdlciB3cm90ZToNCj4g Pg0KPiA+PiBJIGd1ZXNzIEkgaGF2ZSBubyBjaG9pY2UgYnV0IHRvIG9iamVjdC4gICAgSSdtIGFu IGludGVyZXN0ZWQgcGFydHkNCj4gPj4gd2hvIHdhcyB1bmFibGUgdG8gYXR0ZW5kIHRoaXMgdmVy eSBzaG9ydCBub3RpY2UgaW50ZXJpbSAtIHNvIGFtIHByb29mDQo+ID4+IHRoYXQgdGhpcyBhc3Nl cnRpb24gaXMgZmFsc2UuICBUaGlzIGlzIGEgcHJvY2VzcyBvYmplY3Rpb24sIHdoaWNoIEkNCj4g Pj4gcmVhbGx5IGRvbid0IGxpa2UgbWFraW5nLCBidXQgYXMgY2hhaXIgb2YgTmV0TW9kIEkgZmVl bCBvYmxpZ2F0ZWQgdG8NCj4gPj4gbWFrZSBpdCBhcyBOZXRNb2QgaGFzIG1hbnkgaW50ZXJlc3Rl ZCBwYXJ0aWVzIGFuZCB0aGF0IFdHIHdhc24ndCBldmVuDQo+ID4+IG5vdGlmaWVkIG9mIHRoZSBt ZWV0aW5nIC0tIEkga25vdyBtb3N0IG9mIHVzIGF0IGxlYXN0IHRyYWNrIGJvdGgNCj4gPj4gZ3Jv dXBzL2xpc3RzLCBidXQgSSBkb24ndCB0aGluayBpdCBmYWlyIHRvIGFzc3VtZSB0aGF0IGFsbCBp bnRlcmVzdGVkIGluIExpYnJhcnkNCj4gZG8uDQo+ID4NCj4gPiBUaGlzIHdhcyBhIE5FVENPTkYg aW50ZXJpbS4gSSBkbyBub3QgdGhpbmsgdGhlcmUgaXMgYSBwcm9jZXNzDQo+ID4gcmVxdWlyZW1l bnQgdGhhdCBORVRNT0QgaXMgZm9ybWFsbHkgbm90aWZpZWQuIFNvIHdoYXQgZXhhY3RseSBpcyB5 b3VyDQo+ID4gcHJvY2VzcyBvYmplY3Rpb24/IFRoYXQgTkVUTU9EIHdhcyBub3QgZm9ybWFsbHkg bm90aWZpZWQgb3IgZG8geW91DQo+ID4gb2JqZWN0IHRvIHRoZSBzdGF0ZW1lbnQgdGhhdCAiaXQg aXMgYXNzdW1lZCB0aGF0IGFsbCBpbnRlcmVzdGVkDQo+ID4gcGFydGllcyBhdHRlbmRlZCB0aGUg bWVldGluZyI/IFN1cmUsIHRoaXMgYXNzZXJ0aW9uIG1heSBub3QgYmUgdHJ1ZQ0KPiA+IGJ1dCB0 aGUgY29tcGxldGUgc2VudGVuY2Ugd2FzOg0KPiA+DQo+ID4gVGhlc2Ugc2VsZWN0aW9ucyBub3cg bmVlZCB0byBiZSBjb25maXJtZWQgb24gdGhlIGxpc3QuICBTaW5jZSBpdCdzDQo+ID4gYXNzdW1l ZCB0aGF0IGFsbCBpbnRlcmVzdGVkIHBhcnRpZXMgYXR0ZW5kZWQgdGhlIG1lZXRpbmcsIHRoZXNl DQo+ID4gZGVjaXNpb25zIHdpbGwgYmUgZmluYWwgdW5sZXNzIHRoZXJlIGFyZSBhbnkgb2JqZWN0 aW9ucyByYWlzZWQgaW4gYQ0KPiA+IHdlZWsncyB0aW1lLg0KPiA+DQo+ID4gU28gd2hhdCBpcyBi YXNpcyBvZiB5b3VyIHByb2Nlc3Mgb2JqZWN0aW9uPyBDYW4gd2Ugc2ltcGx5IHN0b3AgdGhpcw0K PiA+IGRlYmF0ZSBhbmQgZ2V0IGJhY2sgdG8gdGhlIHRlY2huaWNhbCBpc3N1ZXMuIERvIHlvdSBo YXZlIGFueSB0ZWNobmljYWwNCj4gPiBjb25jZXJucyB3aXRoIGFsdGVybmF0aXZlIEI/DQo+ID4N Cj4gPiAvanMNCj4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gTmV0Y29uZiBtYWlsaW5nIGxpc3QNCj4gTmV0Y29uZkBpZXRmLm9yZw0K PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldGNvbmYmZD1Ed0lGYVEmYz1IQWtZdWg2M3Jz dWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZ aHFuMmdzQllhR1R2aklTbGFKZGNabyZtPVlaYXVSX2Q1WlYyZDBmalpQSnVua3R1bHNac1hhczVp R29QcTMxNWxCXzQmcz16akk5WlB1dUxBQVZHUzdGcUdzYlkzZWN3SVRtd0lsc1ZpMjU5bTd6MWdv JmU9DQoNCg0KDQo= From nobody Thu Dec 14 10:57: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 449DE129459 for ; Thu, 14 Dec 2017 10:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFUXVbVhNDj7 for ; Thu, 14 Dec 2017 10:57:41 -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 687DF129443 for ; Thu, 14 Dec 2017 10:57:40 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 1F6FD1AB08B for ; Thu, 14 Dec 2017 11:57:39 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id luxb1w00Z2SSUrH01uxem1; Thu, 14 Dec 2017 11:57:39 -0700 X-Authority-Analysis: v=2.2 cv=VcCHBBh9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=ocR9PWop10UA:10 a=wU2YTnxGAAAA:8 a=_sAHpe3Ugkmj9FcqgeMA:9 a=QEXdDO2ut3YA:10 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:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=+GQUWtBwbu9mYDTRpY6tU2MkGA342iPJpP6uK85zKUY=; b=Bs7EV5BWJM3YuE2bY/bDhVVl6S GMfHnmLIeM+/+SV6yBsGe1fCnSH51MJZvqZ/btx0RnUC0i4ZDg1C1KjpFDpjed+FDnK+xKdmmjLvF pj9RXdwwXucGD1MY/MCK7+2SK; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:38404 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1ePYhL-000jh6-82; Thu, 14 Dec 2017 11:57:35 -0700 To: Martin Bjorklund Cc: kwatsen@juniper.net, netconf@ietf.org References: <307ec8f7-4562-ae02-d8f1-1a281966ac56@labn.net> <20171214.153448.1803445847942771029.mbj@tail-f.com> <7e4bd018-e270-35a4-7ada-620d74b9d63b@labn.net> <20171214.155818.214441561403113870.mbj@tail-f.com> From: Lou Berger Message-ID: Date: Thu, 14 Dec 2017 13:57:31 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171214.155818.214441561403113870.mbj@tail-f.com> 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: 1ePYhL-000jh6-82 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]:38404 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Netconf] Virtual Interim Results 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, 14 Dec 2017 18:57:43 -0000 On 12/14/2017 9:58 AM, Martin Bjorklund wrote: > Lou Berger wrote: >> Thanks Martin, see below. >> >> >> On 12/14/2017 9:34 AM, Martin Bjorklund wrote: >>> Lou Berger wrote: >>>> As an individual contributor, I suspect that the choice is a fine one, >>>> but would like to understand how (b) addresses  the objectives on slides >>>> 2 and 3 or is even intended to be implemented - e.g., I read "Each >>>> datastore refers to a schema" as meaning library is retrievable from >>>> every datastore, and I'd be surprised if that was the intent.  >>> With Alt A - C, the yang-library data is normal operational state. >> so is only available from that data store, right.  I think this has to >> be made explicit when documenting this as I've seen this misinterpreted >> (I asked a handful of folks and got different answers...) > Yes, I think you have already made this comment on the list, and I > have updated the document (not yet published) with: > > All data nodes in "ietf-yang-library" are "config false", and thus > accessible in the operational state datastore. WFM >>> When it says "each datastore refers to a schema", the word "datastore" >>> refers to a list entry in the "datastore" list shown in the figure. >>> The text really just says the same as the tree diagram: >>> >>> +­­ro datastore* [name] >>> | +­­ro name identityref >>> | +­­ro schema ­> ../../schema/name >>> >>> >>> "a datastore refers to a schema" >> can you summarize how b addresses, the objectives: >>> o As efficient as possible for a client to consume. >>> Since the size of the yang library can be quite large, it >>> shouldbe possible for clients to cache the yang library >>> information. > There's a global checksum, and a checksum per schema. So a client can > cache the yang library contents. > >>> o A dynamic datastore must be able to implement a module or >>> feature that is not implemented in the conventional >>> datastores. > The dynamic datastore would have its own schema, which would not be > the same as the schema for the conventional datastores. > >>> o It must be possible to NOT implement a module or feature in >>> operational, even if it is implemented in some other datastore. >>> This is required for transition purposes; a server that wants to >>> implement should not have to implement all >>> modules at once. > The operational state datastore would have its own schema, which would > not be the same as the schema for the other datastore. > >>> o A given module can only be implemented in one revision in all >>> datastores. If a module is implemented in more than one >>> datastores, the same revision is implemented in all these >>> datastores. > This objective is redundant; it is a requirement from RFC 7950. The > YANG library is a reporting module; the server is supposed to follow > RFC 7950 and use YANG library to report what it implements. > >>> o Multiple revisions can be used for import, if import-by revision >>> is used. > This is the same for all solutions; the proposed way of handling this > is to have a list of imported modules, keyed by module name and > revision. Thanks for the above. >>> o Nice to have: make it possible to be used by schema mount > This alternative defines a reusable "schema", which schema mount can > re-use. See Rob's presentation from the last IETF, for example. He > has also sent this to the list (see his message from 2017-11-09, > "Alternative YANG library structure for 7895bis") I think it would be good to understand / define impact to schema mount as part of this discussion.  I infer from your response, that an update to schema mount will be required  for it to be aligned with this new definition of library, correct?  Why not just do it as part of this bis, probably as a feature as not all implementations of YL will implement SM?  This seems cleaner to me and would ensure alignment between YL and SM solutions. Thanks, Lou > > > /martin > From nobody Thu Dec 14 11:32:59 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 27C99124D6C for ; Thu, 14 Dec 2017 11:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 m43PVdGsUdY6 for ; Thu, 14 Dec 2017 11:32:56 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29AC71200C1 for ; Thu, 14 Dec 2017 11:32:56 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id y82so27645663wmg.1 for ; Thu, 14 Dec 2017 11:32:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=gyEWw3Ly42Z9XWa+MwDHSDYLNOzOc637gfoIAwdrv9c=; b=rfZH8QQMX7E7c4jQX6KzQwk4co+B4OEi0Eog7rLV/xvLJIO/kdjMxa70Fbnr1DYaGL fwXQTp1SmmfYlmAA1rYJSbWZIClWAF2A4hVKAr8SAmI1C50XcU1ZDTDeRcBiMudK9fTe nxnIiQ6MWcBrkv0zCWt+7MsbpxUvNtLIkTO/xb0uRMvSimwZYQtektWoTdSMF2/nTVcH XSVQXsXhW5YfjyfCGHaMttw2RcnSLPHro0kbncUjTTldH1XTXjjRPEr23ioRoEc3vvtW 0v+ZI9+KGUrrsxppT8unieAdPOSamYpqph9yLahiHiYK95aJsecTEeuXfpatIbn+M6iV SAkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=gyEWw3Ly42Z9XWa+MwDHSDYLNOzOc637gfoIAwdrv9c=; b=MCr1Xc5FZo8XhLb4zOf2fCeu2YGlUlMAanrasy8AvCYK47Vpz0SAfn9axDs9n/qS/j uOEuPkwcc/B1gwbzdGckwQ5LOfxP2YzWAsBpc3cE7LcTe0Lo0EwUt2p5AvHvjJ6roXtF XQ5gnMmiZ5wJGZtyqe+blrKxlII8oNYb1Vx5AQ75BxZ7CQLUWbndItatjQH6SyvOqwwR jFB5LW+FOusT996PPoyPseMkmaN0gOfgGD4MrtYmmqPnq+epPooI3v1ZuSoTT3jF1mQc HXNP5KwrN5mTdkZ910IMBrtNI2U7Rjq/7Q6TZqrnGFEqPar3Qqq7GMGTWUYykNbZ9njS JaCA== X-Gm-Message-State: AKGB3mI68h433iUoQEJ2yM+vs4jEH51bH3u+RIsL1+cPbpRwc/3R4OlN ZQB+nC+r6VnhZri6V9KLhRc= X-Google-Smtp-Source: ACJfBotxvZO8CnfoZR8Z2AsSB7rJwDleoNsXfusrQlh59HLKqI/NqzmshPXP2qQw6VcBE5qotTi1TQ== X-Received: by 10.28.59.133 with SMTP id i127mr2967815wma.30.1513279974628; Thu, 14 Dec 2017 11:32:54 -0800 (PST) Received: from DESKTOPFLHJVQJ ([2001:16b8:2dff:f500:ed2f:561b:159f:5b1a]) by smtp.gmail.com with ESMTPSA id 73sm1525977wrb.64.2017.12.14.11.32.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 11:32:53 -0800 (PST) From: "Mehmet Ersue" To: "'Kent Watsen'" , "'Lou Berger'" , References: <5F4462F2-2679-4CFE-A060-41177F9A5D04@juniper.net> <307ec8f7-4562-ae02-d8f1-1a281966ac56@labn.net> <20171214132900.azvb6o53wbf4xdq7@elstar.local> <012c01d374ee$a2d605d0$e8821170$@gmail.com> <24A7C727-2A7C-4737-8A2D-5C4B25CE6423@juniper.net> In-Reply-To: <24A7C727-2A7C-4737-8A2D-5C4B25CE6423@juniper.net> Date: Thu, 14 Dec 2017 20:32:52 +0100 Message-ID: <016001d37512$56401de0$02c059a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHaIH4FM+pUWbbv2HmPzvAZLqTLswFOGcXtAhWFDFUCPt4JoQJYY34qAnRA7cSi4mfioA== Content-Language: de Archived-At: Subject: Re: [Netconf] Virtual Interim Results 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, 14 Dec 2017 19:32:58 -0000 Hi Kent, yes, you are right. There is no IETF process we've violated.=20 However, I would like to suggest to follow the process we agreed for the = NMDA architecture draft also in this case.=20 For drafts in the interest of both WGS I think we should collect the = opinion of and involve both maillists for final consensus.=20 Thanks, Mehmet > -----Original Message----- > From: Kent Watsen [mailto:kwatsen@juniper.net] > Sent: Thursday, December 14, 2017 6:00 PM > To: Mehmet Ersue ; 'Henk Birkholz' > ; 'Lou Berger' ; > netconf@ietf.org > Subject: Re: [Netconf] Virtual Interim Results >=20 >=20 > Hi Mehmet, et al., >=20 >=20 > > The integration of YANG Library and Schema Mount has been discussed = in > NETMOD WG. Process-wise it would be more appropriate to forward the > interim invitation to NETMOD maillist. >=20 > I agree that it would've been goodness and that we should've done = this, but > not an actual IETF process violation, right? >=20 >=20 > > IETF process allows the announcement of virtual interims one week = before > the call but says in the same sentence "(ideally two)". Obviously one = week is > too short for many people. >=20 > FWIW, a week's notice was given (see [1], and note the PS at bottom), = as is > the minimum allowed per [2]. The chairs discussed the short timing, = but it > was either this or wait until after the New Year, introducing weeks of = delay. > We felt it worth pushing for the more aggressive timing in this = circumstance. > Please note, as my co-chairs and AD will attest, I'm consistently = trying to be > fair with people's time; this circumstance is an outlier and does not = represent > a modus operandi going forward. >=20 > [1] = https://www.ietf.org/mail-archive/web/netconf/current/msg13870.html > [2] https://www.ietf.org/iesg/statement/interim-meetings.html >=20 >=20 > Kent >=20 >=20 > > Cheers, > > Mehmet >=20 >=20 > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Henk > > Birkholz > > Sent: Thursday, December 14, 2017 3:33 PM > > To: Lou Berger ; Kent Watsen = ; > > netconf@ietf.org > > Subject: Re: [Netconf] Virtual Interim Results > > > > Hello all, > > > > with respect to "process", a subscription to ietf announce and a few > > filters thrown into that to enable you to only see what you want to > > know might significantly increase visibility (at least for me it = does). > > > > Also, yes 5 days is pretty much "on short notice", too short for my > > schedule at least. > > > > Viele Gr=C3=BC=C3=9Fe, > > > > Henk > > > > On 12/14/2017 02:29 PM, Juergen Schoenwaelder wrote: > > > On Thu, Dec 14, 2017 at 08:17:10AM -0500, Lou Berger wrote: > > > > > >> I guess I have no choice but to object. I'm an interested = party > > >> who was unable to attend this very short notice interim - so am > > >> proof that this assertion is false. This is a process objection, > > >> which I really don't like making, but as chair of NetMod I feel > > >> obligated to make it as NetMod has many interested parties and = that > > >> WG wasn't even notified of the meeting -- I know most of us at > > >> least track both groups/lists, but I don't think it fair to = assume > > >> that all interested in Library > > do. > > > > > > This was a NETCONF interim. I do not think there is a process > > > requirement that NETMOD is formally notified. So what exactly is > > > your process objection? That NETMOD was not formally notified or = do > > > you object to the statement that "it is assumed that all = interested > > > parties attended the meeting"? Sure, this assertion may not be = true > > > but the complete sentence was: > > > > > > These selections now need to be confirmed on the list. Since it's > > > assumed that all interested parties attended the meeting, these > > > decisions will be final unless there are any objections raised in = a > > > week's time. > > > > > > So what is basis of your process objection? Can we simply stop = this > > > debate and get back to the technical issues. Do you have any > > > technical concerns with alternative B? > > > > > > /js > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mail > > man_listinfo_netconf&d=3DDwIFaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXc > > > WzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DYZauR_d5Z > V2d0fjZ > > > PJunktulsZsXas5iGoPq315lB_4&s=3DzjI9ZPuuLAAVGS7FqGsbY3ecwITmwIlsVi25 > 9m7z > > 1go&e=3D >=20 >=20 From nobody Fri Dec 15 06:27: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 BEBC91252BA for ; Fri, 15 Dec 2017 06:27:20 -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 bF1XD79f-uD0 for ; Fri, 15 Dec 2017 06:27:18 -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 730CF124205 for ; Fri, 15 Dec 2017 06:27:18 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 456756CF; Fri, 15 Dec 2017 15:27:17 +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 roSsg0hxwycV; Fri, 15 Dec 2017 15:27:16 +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; Fri, 15 Dec 2017 15:27:17 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 32A5220131; Fri, 15 Dec 2017 15:27:17 +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 bQ_iH6UkPW-k; Fri, 15 Dec 2017 15:27:16 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 007B020130; Fri, 15 Dec 2017 15:27:16 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E161B419B28C; Fri, 15 Dec 2017 15:27:15 +0100 (CET) Date: Fri, 15 Dec 2017 15:27:15 +0100 From: Juergen Schoenwaelder To: Lou Berger Cc: Martin Bjorklund , netconf@ietf.org Message-ID: <20171215142715.hqhfwjf3orkhzi4b@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Lou Berger , Martin Bjorklund , netconf@ietf.org References: <307ec8f7-4562-ae02-d8f1-1a281966ac56@labn.net> <20171214.153448.1803445847942771029.mbj@tail-f.com> <7e4bd018-e270-35a4-7ada-620d74b9d63b@labn.net> <20171214.155818.214441561403113870.mbj@tail-f.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: User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [Netconf] Virtual Interim Results 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, 15 Dec 2017 14:27:21 -0000 On Thu, Dec 14, 2017 at 01:57:31PM -0500, Lou Berger wrote: > > I think it would be good to understand / define impact to schema mount > as part of this discussion.  I infer from your response, that an update > to schema mount will be required  for it to be aligned with this new > definition of library, correct?  Why not just do it as part of this bis, > probably as a feature as not all implementations of YL will implement > SM?  This seems cleaner to me and would ensure alignment between YL and > SM solutions. > I think it is cleaner if yang library just defines yang library and schema mount adds to it whatever is needed to make schema mount work (if any). What we are trying to achieve is that yang library is designed to make this possible (by exposing named schemas that can be referenced). I think it is not desirable that yang library depends on schema mount, even if guarded by a feature, since this leads to circular dependencies between specifications, which makes it difficult to move technology forward later on. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Dec 15 06:35: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 A395D128BBB for ; Fri, 15 Dec 2017 06:35:16 -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 wiexVYGFk5Yo for ; Fri, 15 Dec 2017 06:35:14 -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 76A0C124205 for ; Fri, 15 Dec 2017 06:35:14 -0800 (PST) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:58e5:e6ff:fec4:a503]) by mail.nic.cz (Postfix) with ESMTPSA id AE8D464236 for ; Fri, 15 Dec 2017 15:35:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1513348512; bh=qtZ3/bm/S9IqfEwSrADkAy2PhDNvuRKCGATKYDV4u00=; h=From:To:Date; b=GxW6LVfBH4LliTTSC65/FnNNXaER/HdsRv45ULQk7wi0aNDXrikmC/F14Va61OaBW uTUyGna5z7sdWN8KHngVv0GtAyxtxInjbBq0mlhBeUMrZ673z53lsz3LgFhYIXpoI4 BLDRL8Pj5ARx+6BrgKHtqSD8Du7wTH83Ct1dToQI= Message-ID: <1513348512.18254.70.camel@nic.cz> From: Ladislav Lhotka To: netconf@ietf.org Date: Fri, 15 Dec 2017 15:35:12 +0100 In-Reply-To: <20171215142715.hqhfwjf3orkhzi4b@elstar.local> References: <307ec8f7-4562-ae02-d8f1-1a281966ac56@labn.net> <20171214.153448.1803445847942771029.mbj@tail-f.com> <7e4bd018-e270-35a4-7ada-620d74b9d63b@labn.net> <20171214.155818.214441561403113870.mbj@tail-f.com> <20171215142715.hqhfwjf3orkhzi4b@elstar.local> 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] Virtual Interim Results 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, 15 Dec 2017 14:35:17 -0000 On Fri, 2017-12-15 at 15:27 +0100, Juergen Schoenwaelder wrote: > On Thu, Dec 14, 2017 at 01:57:31PM -0500, Lou Berger wrote: > > > > I think it would be good to understand / define impact to schema mount > > as part of this discussion. I infer from your response, that an update > > to schema mount will be required for it to be aligned with this new > > definition of library, correct? Why not just do it as part of this bis, > > probably as a feature as not all implementations of YL will implement > > SM? This seems cleaner to me and would ensure alignment between YL and > > SM solutions. > > > > I think it is cleaner if yang library just defines yang library and > schema mount adds to it whatever is needed to make schema mount work > (if any). What we are trying to achieve is that yang library is > designed to make this possible (by exposing named schemas that can be > referenced). I think it is not desirable that yang library depends on > schema mount, even if guarded by a feature, since this leads to > circular dependencies between specifications, which makes it difficult > to move technology forward later on. I agree, the only thing that's needed is the ability to include mounted schemas in the YANG library's "schema" list. Schema mount data that complement/augment YANG library could then simply refer to these schemas. Lada > > /js > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Dec 18 12:22: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 899681271FD for ; Mon, 18 Dec 2017 12:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhXr-YRz3OOk for ; Mon, 18 Dec 2017 12:22:47 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C64124239 for ; Mon, 18 Dec 2017 12:22:47 -0800 (PST) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 3EF651E0754 for ; Mon, 18 Dec 2017 13:22:47 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id nYNk1w00L2SSUrH01YNnp1; Mon, 18 Dec 2017 13:22:47 -0700 X-Authority-Analysis: v=2.2 cv=XM9AcUpE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=ocR9PWop10UA:10 a=aNUWOh1-2X_oYk_d_d0A: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=6GRFteBm9/KCPR00YRalQq5Tq/FBzYsk3xxM6TNYzE4=; b=xlXImkaHlSuCv0aWUqNRl9uG6Y ZpDYPL9h/K5p1ZfFOSTdoNvY+3F29Tt/vJERumyxTZQmRJTURq33wUWnglnVAVLxe6bzutbp2XHPZ tV2hE9BZCn830OZERsQZZdBAP; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:49814 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eR1vw-00472L-43; Mon, 18 Dec 2017 13:22:44 -0700 To: Martin Bjorklund , netconf@ietf.org References: <307ec8f7-4562-ae02-d8f1-1a281966ac56@labn.net> <20171214.153448.1803445847942771029.mbj@tail-f.com> <7e4bd018-e270-35a4-7ada-620d74b9d63b@labn.net> <20171214.155818.214441561403113870.mbj@tail-f.com> <20171215142715.hqhfwjf3orkhzi4b@elstar.local> From: Lou Berger Message-ID: <7fe1c999-d952-5710-1216-a26dd33715d6@labn.net> Date: Mon, 18 Dec 2017 15:22:42 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171215142715.hqhfwjf3orkhzi4b@elstar.local> 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: 1eR1vw-00472L-43 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]:49814 X-Source-Auth: lberger@labn.net X-Email-Count: 8 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Netconf] Virtual Interim Results 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, 18 Dec 2017 20:22:48 -0000 On 12/15/2017 9:27 AM, Juergen Schoenwaelder wrote: > On Thu, Dec 14, 2017 at 01:57:31PM -0500, Lou Berger wrote: >> I think it would be good to understand / define impact to schema mount >> as part of this discussion.  I infer from your response, that an update >> to schema mount will be required  for it to be aligned with this new >> definition of library, correct?  Why not just do it as part of this bis, >> probably as a feature as not all implementations of YL will implement >> SM?  This seems cleaner to me and would ensure alignment between YL and >> SM solutions. >> > I think it is cleaner if yang library just defines yang library and > schema mount adds to it whatever is needed to make schema mount work > (if any). What we are trying to achieve is that yang library is > designed to make this possible (by exposing named schemas that can be > referenced). I think it is not desirable that yang library depends on > schema mount, even if guarded by a feature, since this leads to > circular dependencies between specifications, which makes it difficult > to move technology forward later on. I'm fine with SM being an independent document/module, but I think this doesn't change the need to understand  understand / define impact to schema mount as part of this discussion.  From my perspective, YL is really more about server metadata than true operational data.  While I don't object to accessing server metadata as operational data I do think we should make sure there aren't unintended consequences that are unreasonable.  SM brings in additional form of server metadata and affords an opportunity to test the approach.  It seems to me that if we don't see the metadata access approach as viable  for a second case. i.e., SM, I don't see how we can consider it a good/viable general solution. Lou > /js > From nobody Wed Dec 20 12:17: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 ABDC71275FD for ; Wed, 20 Dec 2017 12:17:02 -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 mebeJmAGKz7S for ; Wed, 20 Dec 2017 12:17:00 -0800 (PST) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::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 1C3DC12751F for ; Wed, 20 Dec 2017 12:16:48 -0800 (PST) Received: by mail-lf0-x243.google.com with SMTP id c19so5554480lfg.3 for ; Wed, 20 Dec 2017 12:16: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 :cc; bh=4YHVsCZA4QDakbiFlzIbE5TLMnTAp5pC3e8WEfgX7Oo=; b=Hd31CZ7QZF0OF7HVgIXjEC7Df9bMRDyRLFl45TTsllect4OcQbQuhzV6y/uXBLh6sf H9KqiIq/d6IOavpOOGD6f14QyDP81IB1B7B3syWcy+WpIMVSy1SvH8vvIzjlWW8Gy4v4 fBpaaSuyVZ/gKNgcdtQvpkDV4n6qdi6QCZBvWkfiYgn6UOM0tgslcpTAQTSMqjMgqiJw aqlpJxCYK0rCFObJA441lcDP0hp9kT/8ov+wmlTb1Ay0L1wwSztXg/s7xBBkDsitTZes BhO7g3ddPL/G2vNgMb+mxbxzZzySQG/b6RNBxZKl593cOgEuwHIcpZ1jZ2auW2T0z71T fzVw== 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=4YHVsCZA4QDakbiFlzIbE5TLMnTAp5pC3e8WEfgX7Oo=; b=TTlvxf2OgaKFnaC6GGLFeknHufAGt4b8JL0jDrAY6B4oF7mWVn5IhZCwd9x/gPVcCB g0IcWO/iYSv5VjdO40rwHzqi2ajoqUaKc3Q7h4n5sg2lPCYVtu6kPxHJxe/YTeAqoGQu +uzt0yWuVG0ho1qhh4gi9wnPI+KqANPa57HzxtprDBTy64O3VZirTJqDt5C4iZGyhnWs F6yi8gn5f2SZFCSLhTCqr72GaiZNmMCdjgfg5foRBliu/x9L6VA3bETMbIfTq978nJ4J nut9YJSoep3z1UNurZYTjqo/XoIheHAXRiGaLmpAaShsZs0cwmGcFJvD5yspL3HaScjj Xc3Q== X-Gm-Message-State: AKGB3mIKvPN/qH+wfCF1HuAueTqAKqMhiV5jO0Ni2KR5Qy5voCZMh9cT 0jYHqK6Xrn+/brnIcIWNbHGeJA3VpLjxk0gTJc3dYQ== X-Google-Smtp-Source: ACJfBos7dBFYPbDoswYXDJS19xYRv7/wPc/TDoADLtgZijhjxdYxQI9QpR4uXUrJFhl7Z6iLwz9s3hIAhmbxoZAHBYI= X-Received: by 10.25.28.9 with SMTP id c9mr4778061lfc.40.1513801006223; Wed, 20 Dec 2017 12:16:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.33.81 with HTTP; Wed, 20 Dec 2017 12:16:44 -0800 (PST) In-Reply-To: <60876a73-3dec-9a4f-e313-1787b432fb34@cisco.com> References: <75e91419-9436-d1b7-29f6-02e3ff4ff86d@transpacket.com> <668cc9e1-c006-ce25-1473-549bc0b71a7d@cisco.com> <6cc655e0-1c28-fe75-b854-08e2d878816c@transpacket.com> <20171208.160306.109290175567894287.mbj@tail-f.com> <20171208150614.axuynu4atpg7aaj2@elstar.local> <20171208153442.roomf7rhixtckrfk@elstar.local> <1512750289.11843.3.camel@nic.cz> <5242d50f-6f9e-b57e-ec1b-64828c456339@cisco.com> <60876a73-3dec-9a4f-e313-1787b432fb34@cisco.com> From: Andy Bierman Date: Wed, 20 Dec 2017 12:16:44 -0800 Message-ID: To: Robert Wilton Cc: Kent Watsen , "netmod@ietf.org" , "netconf@ietf.org" Content-Type: multipart/alternative; boundary="001a114020f03cb0310560cb43b7" Archived-At: Subject: Re: [Netconf] [netmod] 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, 20 Dec 2017 20:17:03 -0000 --001a114020f03cb0310560cb43b7 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 13, 2017 at 6:55 AM, Robert Wilton wrote: > > > On 11/12/2017 20:55, Andy Bierman wrote: > > > > On Mon, Dec 11, 2017 at 2:57 AM, Robert Wilton wrote: > >> Hi, >> >> On 08/12/2017 18:01, Andy Bierman wrote: >> >> Hi, >> >> A library per datastore sounds too complicated. >> I prefer the proposal that was made at the IETF meeting that had >> a 'not-implemented-in' leaf-list and a single module list. >> >> The use case that this particular design doesn't work particularly well >> for is if you have a dynamic datastore that just contains a few modules >> that are not supported via the conventional datastores. >> >> I think that there are future uses cases where the set of modules used >> for a dynamic datastore could be really quite different and separate from >> conventional configuration. E.g. if dynamic subscribers were managed >> through a dynamic configuration datastore rather than RADIUS. >> >> >> Why is it interesting to have a separate module list for regular modules >> and imported modules? >> >> Several reasons: >> 1) It means that the list of implemented modules have a single key and >> hence any references to an implemented module are cleaner/simpler. >> > > > IMO you are replacing universally meaningful keys (module-name, > revision-date) with an arbitrary name, > It is not cleaner and not simpler for a client. > > No, for alternatives A and B, the list key is the module name itself, nor > an arbitrary name. > Alternative C uses an arbitrary name. > > > > > 2) The model structure naturally more strictly enforces that only a single >> revision/version of a module is implemented. (E.g. it prevents a server >> stating that two revisions of a module are both implemented). >> > > > How is that the case if the schema list includes its own module list? > You mean there is a "unique" statement in the outer list that insures that > a module/revision > shows up at most once in all instances of the inner module list? > > For alt A, each schema represents a single list (so no duplicated > implemented modules are possible). > > For alt B, yes, the rule is that there must be no duplicates in the > module-sets that are combined into a single schema. > > > The alt-B approach that seems to be favored is not constrained, but even if the server does conform (and not have any overlaps between schema lists) this approach is rather complicated in order to answer the simple question "What datastores are supported for module foo, revision A?" If the previous design was used, a client could simply retrieve the module entry and check the 'not-implemented-in' leaf-list. Now a client has to retrieve the entire library, then analyze the datastore lists (built from the schema entries for the datastore). The client has to match instances and look for module "foo" in multiple places. The client then assumes that any missing entry means the module is not supported in that datastore (assumes read access control is never applied to the YANG library). The corner case used as an excuse to redesign the library (ephemeral datastore with a few modules in it) is not very interesting, and also not expensive in terms of processing complexity and bandwidth. IMO the library should be optimized for conventional + operational, and also be optimized for the long-term, not a short-term transition period, biased for server developers who want to release partial implementations. Andy > > >> 3) I genuinely think that the list of implemented modules is more >> interesting to the client than the imported, but not implemented modules. >> > > > The conformance leaf was good enough. > Duplicating the module list and removing the conformance leaf is > aggressively non-backward compatible. > > > >> >> For a server, I would design it to "implement" one revision of every >> module that it uses (including those that don't contain any data nodes, >> RPCs, actions, notifications, or deviations), and then the "import-only" >> list becomes the list of modules that the server implements to satisfy >> "import-by-revision" and these are stated in the implemented schema anyway. >> >> >> I prefer to keep the conformance leaf and not change the module list. >> >> NMDA needs to be possible to implement with a single schema tree such >> that a module >> is implemented in all datastores, or a subset of all datastores. >> Otherwise it probably won't >> get supported in clients. >> >> All solutions accommodate this requirement. >> > > > Seems to me all new solutions allow a server to violate the MUST in the > NMDA draft that > there is a superset of all modules. A client has to look for every module > in a server-specific > set of named schema sets, and then reconcile all these sets. > I still prefer the single module list with a conformance leaf and a > leaf-list indicating > the supported (or unsupported) datastores. > > So, this is a trade off between a more expressive model vs a more > constrained model. > > It is worth noting that the existing YANG library (RFC 7895) allows > servers to produce illegal module lists because they could implement > multiple revisions of the same module. > > Thanks, > Rob > > > > > >> For me, some of the interesting design questions have revolved around: >> - is it better to reduce duplication in the list of modules reported at >> the cost of increased model complexity? >> - does the solution extend to schema mount? >> - how well does the solution cope with with configuration datastores that >> support very different sets of modules? >> >> To a lesser extent we have also been considering how well the solution >> extends to packaging and semantic versioning, but I think that it is quite >> tricky to know who these are going to pan out. E.g. I think that the >> restriction that a given schema will only implement a single revision of a >> module will end up still holding, but I'm not sure that everyone has that >> same view point. >> >> Thanks, >> Rob >> >> >> > > Andy > > >> >> >> Andy >> >> >> >> On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen wrote: >> >>> CC-ing NETCONF, where the draft is being worked on. >>> >>> Kent >>> >>> >>> On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote: >>> > On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote: >>> > > >>> > > Yes. The default value for yang-library-datastore leaf is >>> ds:operational >>> > > (the only possible one for the ds:operational datastore). This is >>> backward >>> > > compatible. If one needs different model for 'running', etc. then a >>> new >>> > > datastore identity has to be defined and set in place of the >>> default value. >>> > > Then this identity can be used to read the yang-library data with >>> > > . >>> > > >>> > >>> > Sorry, but I have to ask this: How do I obtain the schema for the >>> > datastore (lets call it ) that reports the schema for >>> > ? Is there another datastore? Will >>> > the recursion end? Perhaps it does since >>> > might have itself listed as the schema defining datastore. I guess >>> > Lada will like these kind of meta and meta-meta datastores. >>> >>> Not really. Metadata needn't be in datastores. >>> >>> Lada >>> >>> > >>> > /js >>> > >>> -- >>> Ladislav Lhotka >>> Head, CZ.NIC Labs >>> PGP Key ID: 0xB8F92B08A9F76C67 >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet >>> f.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh >>> 0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTv >>> jISlaJdcZo&m=5qj6BQUSwqYmkAVeKz5axFV8k3gxYEPSJ5Cp0RSnxrE&s=I >>> 7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFRrvQI5l8&e= >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> >> >> _______________________________________________ >> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf >> >> >> > > --001a114020f03cb0310560cb43b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 13, 2017 at 6:55 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:
=20 =20 =20



On 11/12/2017 20:5= 5, Andy Bierman wrote:
=20


On Mon, Dec 11, 2017 at 2:57 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi,


On 08/12/2017 18:01, Andy Bierman wrote:
Hi,

A library per datastore sounds too complicated.
I prefer the proposal that was made at the IETF meeting that had
a 'not-implemented-in' leaf-list and a sin= gle module list.
The use case that this particular design doesn't work particularly well for is if you have a dynamic datastore that just contains a few modules that are not supported via the conventional datastores.

I think that there are future uses cases where the set of modules used for a dynamic datastore could be really quite different and separate from conventional configuration.=C2=A0 E.g. if dynamic subscribers were manag= ed through a dynamic configuration datastore rather than RADIUS.


Why is it interesting to have a separate module list for regular modules and imported modules?
Several reasons:
1) It means that the list of implemented modules have a single key and hence any references to an implemented module are cleaner/simpler.


IMO you are replacing universally meaningful keys =C2=A0(module-name, revision-date) with an arbitrary name,
It is not cleaner and not simpler for a client.
No, for alternatives A and B, the list key is the module name itself, nor an arbitrary name.
Alternative C uses an arbitrary name.




2) The model structure naturally more strictly enforces that only a single revision/version of a module is implemented.=C2=A0 (E.g. it prevents a server stating that two revisions of a module are both implemented).


How is that the case if the schema list includes its own module list?
You mean there is a "unique" statement in the ou= ter list that insures that a module/revision
shows up at most once in all instances of the inner module list?
For alt A, each schema represents a single list (so no duplicated implemented modules are possible).

For alt B, yes, the rule is that there must be no duplicates in the module-sets that are combined into a single schema.




The alt-B app= roach that seems to be favored is not constrained, but even if the server d= oes conform
(and not have any overlaps between schema lists) this= approach is rather complicated in order
to answer the simple que= stion "What datastores are supported for module foo, revision A?"=

If the previous design was used, a client could s= imply retrieve the module entry and check
the 'not-implemente= d-in' leaf-list.=C2=A0 Now a client has to retrieve the entire library,= then analyze the
datastore lists (built from the schema entries = for the datastore). The client has to match
instances and look fo= r module "foo" in multiple places.=C2=A0 The client then assumes = that
any missing entry means the module is not supported in that = datastore (assumes read access control
is never applied to the YA= NG library).

The corner case used as an excuse to = redesign the library (ephemeral datastore with a few modules in it)
is not very interesting, and also not expensive in terms of processing c= omplexity and bandwidth.
IMO the library should be optimized for = conventional + operational, and also be optimized for
the long-te= rm, not a short-term transition period, biased for server developers who wa= nt
to release partial implementations.

<= br>
Andy



=C2=A0
3) I genuinely think that the list of implemented modules is more interesting to the client than the imported, but not implemented modules.


The conformance leaf was good enough.
Duplicating the module list and removing the conformance leaf is aggressively non-backward compatible.

=C2=A0

For a server, I would design it to "implement" on= e revision of every module that it uses (including those that don't contain any data nodes, RPCs, actions, notifications, or deviations), and then the "import-only" list becomes the list of modules th= at the server implements to satisfy "import-by-revision"= and these are stated in the implemented schema anyway.


I prefer to keep the conformance leaf and not change the module list.

NMDA needs to be possible to implement with a single schema tree such that a module
is implemented in all datastores, or a subset of all datastores.=C2=A0 Otherwise it probably won= 9;t
get supported in clients.
All solutions accommodate this requirement.


Seems to me all new solutions allow a server to violate the MUST in the NMDA draft that
there is a superset of all modules.=C2=A0 A client has to look for every module in a server-specific
set of named schema sets, and then reconcile all these sets.
I still prefer the single module list with a conformance leaf and a leaf-list indicating
the supported (or unsupported) datastores.
So, this is a trade off between a more expressive model vs a more constrained model.

It is worth noting that the existing YANG library (RFC 7895) allows servers to produce illegal module lists because they could implement multiple revisions of the same module.

Thanks,
Rob





For me, some of the interesting design questions have revolved around:
- is it better to reduce duplication in the list of modules reported at the cost of increased model complexity?
- does the solution extend to schema mount?
- how well does the solution cope with with configuration datastores that support very different sets of modules?

To a lesser extent we have also been considering how well the solution extends to packaging and semantic versioning, but I think that it is quite tricky to know who these are going to pan out.=C2=A0 E.g. I think that the restriction that a given schema will only implement a single revision of a module will end up still holding, but I'm not sure that everyone has that same view point= .

Thanks,
Rob




Andy
=C2=A0


Andy



On Fri, Dec 8, 2017 at 9:21 AM, Kent Watsen <kwatsen@juniper.net> wrote:
CC-ing NETCONF, where the draft is being worked on.

Kent


On Fri, 2017-12-08 at 16:34 +0100, Juergen Schoenwaelder wrote:
> On Fri, Dec 08, 2017 at 04:19:28PM +0100, Vladimir Vassilev wrote:
> >
> > Yes. The default value for yang-library-datastore leaf is ds:operational
> > (the only possible one for the ds:operational datastore). This is backward
> > compatible. If one needs different model for 'running', etc. then a new
> > datastore identity has to be defined=C2= =A0 and set in place of the default value.
> > Then this identity can be used to read the yang-library data with
> > <get-data>.
> >
>
> Sorry, but I have to ask this: How do I obtain the schema for the
> datastore (lets call it <running-library>) that reports the schema for
> <running>? Is there another <running-library-library> datastore? Will
> the recursion end? Perhaps it does since <running-library-library>
> might have itself listed as the schema defining datastore. I guess
> Lada will like these kind of meta and meta-meta datastores.

Not really. Metadata needn't be in datastores.<= br>
Lada

>
> /js
>
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

______________________________________________= _
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhtt= ps-3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwICAg&c= =3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUv= ZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D5qj6BQUSwqYmkAVeKz5axFV= 8k3gxYEPSJ5Cp0RSnxrE&s=3DI7fR1GY5lN2hVMkDuvryrhDeRypike3wPeFR= rvQI5l8&e=3D


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



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




--001a114020f03cb0310560cb43b7-- From nobody Fri Dec 22 10:49: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 BF23A120724 for ; Fri, 22 Dec 2017 10:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMPGAfK8Yk8C for ; Fri, 22 Dec 2017 10:49:37 -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 7C1B11200B9 for ; Fri, 22 Dec 2017 10:49:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19686; q=dns/txt; s=iport; t=1513968577; x=1515178177; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=5ujTvagMxFnqmvRYO/ihgJfh3kX6UmsEPlppYZmxeQw=; b=cb4rJ/dRogtwgS2J00C/ikHTkSEvK+ecJ4NNim/r+C49KCSqkiqg1Akl uk8xr8q5XMGL9s4QGjVm6yoOL1lLHO/bDLWXCED8i2phtTTBAGUgt/4tY iIvDUAp9Y0yEnAwP74UcD7s8rZgl31mGkKANiw7Ro9cQUjis/29zNpZiO c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxAACzUj1a/4kNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM+ZnQnB44jjxKCAYkGiEyFVhSCAQojhRgChE4/GAEBAQEBAQE?= =?us-ascii?q?BAWsdC4UjAQE/PwwGARkEAQEBDREFBCgRFAkJAQQOBQgTiXsDFRCnT4c2DYMOA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARoFhAyCEoFWgWmCIIN5RAGBOwERAgEGAoYSBYp?= =?us-ascii?q?XmDU9Aod/gWuGRYR1giCKJYc+jSE+iHMCERkBgToBHzlgb28VPYIpglQcGYFOe?= =?us-ascii?q?IkfgRYBAQE?= X-IronPort-AV: E=Sophos;i="5.45,442,1508803200"; d="scan'208";a="48259078" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Dec 2017 18:49:36 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id vBMInZoV032586 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Dec 2017 18:49:35 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, 22 Dec 2017 13:49:34 -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, 22 Dec 2017 13:49:34 -0500 From: "Eric Voit (evoit)" To: "netconf@ietf.org" Thread-Topic: YP#10 Notifiable-on-change for application designers (was RE: [Netconf] review of draft-ietf-netconf-yang-push-11) Thread-Index: AdN7VYjPZJNU1L0PSUOuJIeFPLouaQ== Date: Fri, 22 Dec 2017 18:49:34 +0000 Message-ID: <39515140c57b4d8198af032da1202fe2@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Netconf] YP#10 Notifiable-on-change for application designers (was RE: 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, 22 Dec 2017 18:49:43 -0000 Coming back to issue YP#10: https://github.com/netconf-wg/yang-push/issues/10 =20 I am hoping we can get to a rough consensus. Basically the open question f= or the yang-push draft is: should we provide guidance on how to indicate wh= ich schema objects are notifiable-on-change. There are things we have agreed upon during previous discussions of this is= sue. (1) Providing information on which schema nodes might be notifiable-on-chan= ge is useful for application designers (i.e., design time). =20 (2) Just providing information on which schema nodes are notifiable-on-chan= ge is insufficient/incomplete for run-time enforcement (as some instance da= ta based on the schema nodes may go either way.) (3) The YANG library seems a reasonable place to maintain definitive instan= ce information. But any such specification will be outside the scope of th= e yang-push draft. (4) Whatever mechanism(s) are ultimately selected for identifying whether a= n instance object or schema node is notifiable-on-change must include suppo= rt for both explicit marking and inheriting the value of the parent. The = default for unmarked top level nodes is false. So that seems to be what we have agreed on. What we haven't closed on is = the following: Section 3.10 of yang-push provides a mechanism for marking s= chema objects as notifiable-on-change. Section 3.10 will be either removed= , or moved to an appendix. So the open question is do we want 3.10 as an appendix, or do we want it re= moved? =20 Below are the arguments for each... FOR moving 3.10 into an appendix: - this provides guidance for today's implementations, without asserting tha= t this would be the long term mechanism - the previous draft Balazs provided (https://tools.ietf.org/html/draft-len= gyel-netmod-schema-annotation-00), didn't get traction when it was proposed= . We would have no timeline for resolution. =20 - we need some mechanism, and the deviations construct has many of the requ= ired characteristics. FOR removing 3.10: - the mechanism proposed (deviations) overloads the meaning of deviations. = =20 - it is hard to step back from such a meaning expansion of augmentation, ev= en when it is just within an informational appendix - we don't have majority consensus for any proposal at this point. (e.g., I= n Alex' latest email below he suggests an alternate to deviation based on "= augmentation") - mechanisms for schema annotation should be in the domain of the NETMOD WG= , and it is possible that a generalized solution could emerge from there - solutions for the instance data (perhaps using the YANG library) might ex= pose a better way of doing this, early guidance might constrain the ultimat= e solution - adding this appendix makes the draft and model more complex with content = which might provide incorrect guidance should another mechanism emerge as Y= ANG library evolves. Is there anything else people want to articulate for either side? Or a ne= w side? Without getting a majority for the Appendix option, I believe we should *no= t* include any mechanism to tag notifiable-on-change for schema objects wit= hin yang-push. Thoughts? Eric P.S.: The version of yang-push soon to be posted still will still have sect= ion 3.10. It won't be moved/removed until we resolve the issue above. > -----Original Message----- > From: Alexander Clemm [mailto:alexander.clemm@huawei.com] > Sent: Thursday, November 30, 2017 1:54 PM > To: Martin Bjorklund ; balazs.lengyel@ericsson.com; Mahes= h > Jethanandani ; kwatsen@juniper.net > Cc: Eric Voit (evoit) ; netconf@ietf.org; > andy@yumaworks.com > Subject: RE: [Netconf] review of draft-ietf-netconf-yang-push-11 >=20 > Hi Martin, >=20 > Instead of "deviation", we could also use "augmentation". The point is t= hat the > implementation-specifics would be provided in an implementation-specific > YANG module. Clearly the possibility to have implementation-specific YAN= G > modules is foreseen by the very fact that the deviation statement exists,= and > the genie is out of the bottle here. >=20 > That said, yes, there was an original proposal to use annotations, which = Balazs > proposed. When it became clear that the general annotations proposal was= n'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 notifiab= ility) > that we have today. >=20 > As indicated by you and others on this thread, alternatively we can certa= inly > also simply defer this issue for now. In this case, as you state, we wou= ld simply > indicate in the text that clients need to be aware that not every 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 implementatio= ns > might support a module with such an extension, which we would then includ= e > in the appendix as an example. Having a module enumerating the nodes (pe= r > your earlier suggestion), or suggesting a library augmentation (without > introducing a dependency on that - can be informational only!) could be > described there as well. Perhaps it is a question to our WG chairs, Mahe= sh and > Kent, whether putting this as an informational example for a way in which= to > addresss this would be feasible, in the same way as some drafts explain h= ow > something might be implemented - really this is a process question - or i= f it > should simply be omitted entirely. >=20 > We would also make clear that if a subscription contains objects that are= not > 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 par= t of the > library will be the technically preferable option. Having this as an > 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 als= o serve as > an example there how the library might be used to keep track also of othe= r > "annotations" in the future. Perhaps something to discuss on the other t= hread. >=20 > Thanks > --- Alex >=20 >=20 > > -----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 > > > > 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 th= is 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 soluti= on 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 someth= ing > > > > 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, = 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-chang= e > > > > subscribable. Here it would be up to the implementation to determ= ine > > > > 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 datast= ore, > > > > > but not in operational. Again, marking a node in the sch= ema > > > > > 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 i= n > > > > > deviation modules. This is quite an expensive and compli= cated > > > > > 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, fo= r > > > > > 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 paren= t? > > > > 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 wi= th > > > > something here, especially as the on-chance implementations I have > > > > seen have all used phased introduction of on-change for different > > > > schema objects. From nobody Fri Dec 22 11:52: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 2FC98120227 for ; Fri, 22 Dec 2017 11:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsZbnlOHAqH6 for ; Fri, 22 Dec 2017 11:52:33 -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 BDA7B1200B9 for ; Fri, 22 Dec 2017 11:52:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6689; q=dns/txt; s=iport; t=1513972352; x=1515181952; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=bYGij0XBeaMUo4Y7x1tLdvV6qLrGe9dn4zi6aoGA8y0=; b=lAzBuZZGuRyDciWHsE+lD4BBbrtPRO89O94xTBu0cgHwhHCEKR0+1Bt1 gn8RrQaWv1fCLp2mUv1kaa6cYjQF/JdAMR3bb/s5IF4Uj4MiA+sMlB3Fs CZfTiS+YFyzkD6KGI3PzpRoC82GI3ER6Biba0eN19FWmqPLBneTz3L4xA 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCAgCJYT1a/5JdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMPL2Z0Lp02ggGZPQojhRiEUEMUAQEBAQEBAQEBayiFIwEBBDs?= =?us-ascii?q?/BQ0BHSEFPSYBBAENDROKCwgQp12KUgEBAQEBAQEBAQEBAQEBAQEBAQEaBYQMg?= =?us-ascii?q?hKBVohGgTghhhIFimqHM5EsAod/jSWCIJFjilKCT4kxAhEZAYE6ATYigU9vFYJ?= =?us-ascii?q?ngwiBTohqgTSBFgEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,442,1508803200"; d="scan'208";a="48399055" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Dec 2017 19:52:31 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id vBMJqVkm013185 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Dec 2017 19:52:31 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, 22 Dec 2017 14:52:30 -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, 22 Dec 2017 14:52:30 -0500 From: "Eric Voit (evoit)" To: "netconf@ietf.org" , "andy@yumaworks.com" , "alexander.clemm@huawei.com" Thread-Topic: YP#12 Value filtering on non-key objects (was RE: [Netconf] review of draft-ietf-netconf-yang-push-11) Thread-Index: AdN7XmISrt06JHX0S+eBeXdtumGSmw== Date: Fri, 22 Dec 2017 19:52:30 +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.118.56.228] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Netconf] YP#12 Value filtering on non-key objects (was RE: 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, 22 Dec 2017 19:52:35 -0000 I am looking to see if anyone has an issue with my opening and closing of: https://github.com/netconf-wg/yang-push/issues/12=20 as described below... During Martin's recent review of yang-push, he argued that we should allow = selection filtering using non-key properties. I believe he is correct. (= In fact, this is what was supported in yang-push drafts -v00 through -v08.) The reason we changed in -v09 is that if a non-key property changes, it mig= ht mean that the object as a whole is no longer selected. The result is = that an entire subtree may no longer should be visible to the receiver. So= the YANG patch sent from the subscriber to the receiver would need to add/= remove entire subtree based on a simple value change for a non-key object i= n that subtree. The thought for -v09 was that if we restricted on-change = selection filtering just to keys, this might be simpler/easier to implement= . But per Martin's comments below, he pointed out other issues which come = with placing such restrictions in filters. =20 Does anyone have an objections to once again allowing selection filters to = be placed on non-key properties? (Alex & Andy, this was something we wen= t back-and-forth on as part of the Dezign Team discussions.) If there is no objection, this makes the conceptual selection process for c= reating an push-change-update: =09 (1) Just before a change, or at the start of a dampening period, evaluate = any filtering and any access control rules. The result is a set "A" of dat= astore nodes and subtrees. (2) Just after a change, or at the end of a dampening period, evaluate any= filtering and any (possibly new) access control rules. The result is a se= t "B" of datastore nodes and subtrees. (3) Construct a YANG patch record for going from A to B. If the record i= s non-empty, send it to the receiver. Eric > From: Martin Bjorklund, December 5, 2017 5:03 AM >=20 > > > > > 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 f= ilter > > > > > that would be too complex to implement / evaluate (in fact I th= ink > > > > > 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. > > > > > > But you are constraining the entire solution to support just this > > > use case, when a simpler unconstrained solution just as easily > > > supports this use case, *plus other use cases* - if a client does > > > not want these "fake *deletes", they can simply construct filters > > > based on keys only, which they would in the current solution anyway. > > > > This is true. > > > > > Note also that b/c of the last paragraph in section 3.9, a client > > > must deal with such deletes anyway, even if it specificied only > > > keys. > > > > This is true. > > > > > But I do understand your point. This is also related to my comment > > > below about when a filter is evaluated. Based on you reply to that > > > comment, I think the conceptual algorithm is like this: > > > > > > Just before a change, evaluate the filter and any access control > > > rules. The result is a set "A" of nodes (including subnodes). > > > > > > Just after a change, evaluate the filter and any (possibly new) > > > access control rules. The result is a set "B" of nodes (including > > > subnodes). > > > > > > Construct a YANG patch record for going from A to B. If the recor= d > > > is non-empty, send it to the subscriber. > > > > > > (this is conceptual, an implementation can do lots of optimizations > > > to avoid evaluating filters on un-related changes) > > > > Yes, this is it. The only tweak I would make is to add the dampening > > period. As a result, I have added the following text at the end of > > the "On-Change Considerations" section > > > > "Putting it all together, following is the conceptual process for > > creating an push-change-update notification: > > > > 1.Just before a change, or at the start of a dampening period, > > evaluate any filtering and any access control rules. The result is a > > set "A" of datastore nodes and subtrees. > > > > 2.Just after a change, or at the end of a dampening period, evaluate > > any filtering and any (possibly new) access control rules. The resul= t > > is a set "B" of datastore nodes and subtrees. > > > > 3. Construct a YANG patch record for going from A to B. If the recor= d > > is non-empty, send it to the receiver." > > > > > > 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 > > > > > > What about this one: > > > > > > /interfaces/interface[contains(name, //name)] > > > > > > it also filters on a key is it ok? > > > > > > [if the answer is "yes" we have a problem; and if it is "no", we > > > need to tighten the text] > > > > > > > > > All this makes me wonder if it is correct to have "subtree" and > > > "xpath" > > > filters at all. If they only can match on keys, they become > > > severely constrained. > > > > > > An alternative could be to specify filters as > > > "nacm:node-instance-identifier" > > > instead; these are instance-identitifiers that allow missing keys. > > > For > > > example: > > > > > > /if:interfaces/if:interface/if:oper-status > > > > > > This would be easier to understand and probably easier to optimize > > > for in the server code. > > > > I want to generalize this "only-keys?" issue for the full WG. It is > > too important to handle this deep in the thread. Look for me to open > > an issue shortly. >=20 > Ok! >=20 > /martin From nobody Fri Dec 22 14:15:11 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 75EE3127137; Fri, 22 Dec 2017 14:15:09 -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.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151398090944.30144.7820682070816196933@ietfa.amsl.com> Date: Fri, 22 Dec 2017 14:15:09 -0800 Archived-At: Subject: [Netconf] I-D Action: draft-ietf-netconf-subscribed-notifications-08.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: Fri, 22 Dec 2017 22:15:09 -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 : Custom Subscription to Event Streams Authors : Eric Voit Alexander Clemm Alberto Gonzalez Prieto Einar Nilsen-Nygaard Ambika Prasad Tripathy Filename : draft-ietf-netconf-subscribed-notifications-08.txt Pages : 59 Date : 2017-12-22 Abstract: This document defines capabilities and operations for the customized establishment of subscriptions upon a publisher's event streams. Also defined are delivery mechanisms for instances of the resulting notification messages. Effectively this allows a subscriber to request and receive a continuous, custom feed of publisher generated information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-subscribed-notifications/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-08 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-subscribed-notifications-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-subscribed-notifications-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 22 14:24: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 43AB7124207; Fri, 22 Dec 2017 14:24:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151398145123.29986.13251100173833065181@ietfa.amsl.com> Date: Fri, 22 Dec 2017 14:24:11 -0800 Archived-At: Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-push-12.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: Fri, 22 Dec 2017 22:24:11 -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 : YANG Datastore Subscription Authors : Alexander Clemm Eric Voit Alberto Gonzalez Prieto Ambika Prasad Tripathy Einar Nilsen-Nygaard Andy Bierman Balazs Lengyel Filename : draft-ietf-netconf-yang-push-12.txt Pages : 53 Date : 2017-12-22 Abstract: Via the mechanism described in this document, subscriber applications may request a continuous, customized stream of updates from a YANG datastore. Providing such visibility into changes made upon YANG configuration and operational objects enables new capabilities based on the remote mirroring of configuration and operational state. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-push/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netconf-yang-push-12 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-push-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-yang-push-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Dec 22 14:40: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 4FF1C126BF0 for ; Fri, 22 Dec 2017 14:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 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_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUaijQfR-MBp for ; Fri, 22 Dec 2017 14:40:34 -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 B925B124207 for ; Fri, 22 Dec 2017 14:40:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37265; q=dns/txt; s=iport; t=1513982433; x=1515192033; h=from:to:cc:subject:date:message-id:mime-version; bh=nbf2FHcefTorGtUTxZd5NIUg0SF4I86GCQ4ThWir2gA=; b=hcdkgr4jTvZIC89AusKVjYGHFLd8kwGZ3WMF2yVEh9WB2RTZ4c87LmdH Kn7DNMh7Qc+8qhRNF6OcY6oJlyXQSq48Tp9F/zSXm6XxU9FIc37e1qrSt TznAV5mt1e1GelO2YXuh/xTn/VFF77KKSZtbdpHvSOq0wbWiXAkhMg2zz 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DnAAD2iD1a/51dJa1WBxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCSnRmdC6OI48UmSkUggEKI4UYhFA/GAEBAQEBAQEBAWsdC4V?= =?us-ascii?q?RBkwSAS0TAT8mAQQODYlCZBCnTDqKUgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFh?= =?us-ascii?q?AyCEoFWgWmCfgGDXoE8ARIBBwEEhg8FikcHiUGFUYlpAoF5hgaNJYIghhWLTop?= =?us-ascii?q?Sgk+JMQIRGQGBOgEfOSU7b28VPYIqhFaIagINGAMEgQaBFgEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,442,1508803200"; d="scan'208,217";a="338669628" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Dec 2017 22:40:31 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vBMMeVpr019689 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Dec 2017 22:40:31 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; Fri, 22 Dec 2017 17:40:30 -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, 22 Dec 2017 17:40:30 -0500 From: "Eric Voit (evoit)" To: "netconf@ietf.org" CC: "alexander.clemm@huawei.com" , "alex@clemm.org" Thread-Topic: Updates to subscription drafts posted Thread-Index: AdN7c6tla9+Rg8JSQvKl4A/Q45Vxzw== Date: Fri, 22 Dec 2017 22:40:30 +0000 Message-ID: <49524f8e94924bbda2575ad37dceb59f@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_49524f8e94924bbda2575ad37dceb59fXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Updates to subscription drafts 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, 22 Dec 2017 22:40:36 -0000 --_000_49524f8e94924bbda2575ad37dceb59fXCHRTP013ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, At the end of IETF Singapore, we subscription draft authors promised an upd= ate to the subscription drafts. As of today, the yang-push and subscribed-= notification drafts have been updated. Below are a list of the elements updated. And below that are the four cur= rent known open issues. If you know of anything else which needs to be do= ne, please chime in! ---------------------------------------------------------------------------= ------------- draft-ietf-netconf-yang-push-12 - Changes per the latest version... ---------------------------------------------------------------------------= ------------- (1) Section 3.7: "patch-id" is populated by a sequential number, starting w= ith value '1' for each on-change update. This allows easy identification o= f loss. (2) YANG model: Containers added for 'periodic' and 'on-change' to explicit= ly group parameters within subscription model. (3) YANG model: Removed the "time-of-update" objects in the YANG Push notif= ications. These can be seen as redundant with eventTime (RFC-5277) or the = more explicit time elements currently under discussion within the notificat= ion-messages draft. (4) YANG model: Streams all made as leafrefs to the streams container (rat= her than string). As a result, elements of the stream container are all no= w "rw", as YANG doesn't allow configured subscriptions to point to configur= ation false streams. (5) Draft text clarifications as documented on separate review threads with= Martin & Balazs. (6) Passed examples through yanglint to validate. ---------------------------------------------------------------------------= -------------------------------- draft-ietf-netconf-subscribed-notifications-08 - Changes per the latest = version... ---------------------------------------------------------------------------= -------------------------------- (1) YANG model tree partitioned into different sections of the document. T= his is intended to simplify readability. (2) Dynamic subscription receivers will receive a "subscription-modified" n= otification if the definition of a configured filter changes during the lif= ecycle of that dynamic subscription. (3) A configured subscription VRF is now via leafref to Network Instance YA= NG model (4) The transport protocol must be common across all receivers of a configu= red subscription. (5) QoS objects have been moved from YANG push into Subscribed-notification= s (6) The configured subscription state machine has been tweaked. It now exp= licitly includes the invalid and concluded states. See Section 2.5.1 for= the text which backs up the pictures below.... .-------. | start |-. '-------' | create .---modify-----.----------------------------------. | | | | V V .-------. .-----. .---------. .----[evaluate]--no--->|invalid|-delete->| end |<-delete-|concluded| | '-------' '-----' '---------' |----[evaluate]--no-. ^ ^ ^ | ^ | | | | yes | '->unsupportable delete stop-time | modify (subscription- (subscription- (subscription- | | terminated) terminated) concluded) | | | | | | .---------------------------------------------------------------. '-->| valid | '---------------------------------------------------------------' Beyond this diagrammatic change, also extracted and updated is the configur= ed subscription receiver state machine. It now includes an explicit "recei= ver timeout" state. .----------------------------------------------------------------. | valid | | .----------. .--------. | | | receiver |------------------timeout->|receiver| | | |connecting|<------------------reset---|timeout | | | | |<-transport---. '--------' | | '----------' loss,reset | | | | | | | | (subscription | | | | started) .--------. | .---------. | | '----->| | '----------------------| | | | |receiver|-(subscription-suspended)-->|receiver | | |(subscription-| active | |suspended| | | modified) | |<-(subscription-resumed,----| | | | '---->'--------' subscription-modified) '---------' | '----------------------------------------------------------------' To match with this mew state, in the YANG model, added is the action "reset= -receiver". This allows the resetting of a configured receiver. This can= be interesting if call-home has failed (leaving a receiver in "receiver ti= meout"), and an operator wants to restart the connecting process for a rece= iver. +--ro receivers +--ro receiver* +---x reset-receiver +--ro output +--ro time yang:date-and-time This leaves the following four updates which need to be included in the dra= fts: ---------------------------------------------------------------------------= ----------------------------- (a) Existing NETCONF error mechanism will replace RPC based error responses= in -v08 & -v12 * Alex should have shortly (b) NMDA model versions * Eric has done this, awaiting completion of (a), will then integrate= and post. (c) Closure of Issue YP #12, value filtering on non-key objects. * Awaiting feedback from email to NETCONF alias made earlier today (e) Closure of Issue YP#10: Not notifiable on-change. * Awaiting feedback from email to NETCONF alias made earlier today Thanks! Eric --_000_49524f8e94924bbda2575ad37dceb59fXCHRTP013ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

At the end of IETF Singapore, we subscription draft = authors promised an update to the subscription drafts.  As of today, t= he yang-push and subscribed-notification drafts have been updated. 

 

Below are a list of the elements updated.  &nbs= p;And below that are the four current known open issues.   If you= know of anything else which needs to be done, please chime in!<= /p>

 

 

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

draft-ietf-netconf-yang-push-12  -  Change= s per the latest version...

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

(1) Section 3.7: “patch-id” is populated= by a sequential number, starting with value ‘1’ for each on-ch= ange update.  This allows easy identification of loss.  

 

(2) YANG model: Containers added for ‘periodic= ’ and ‘on-change’ to explicitly group parameters within s= ubscription model.

 

(3) YANG model: Removed the “time-of-update= 221; objects in the YANG Push notifications.  These can be seen as red= undant with eventTime (RFC-5277) or the more explicit time elements current= ly under discussion within the notification-messages draft.

 

(4) YANG model: Streams all made as leafrefs to the =  streams container (rather than string).  As a result, elements o= f the stream container are all now “rw”, as YANG doesn’t = allow configured subscriptions to point to configuration false streams.

 

(5) Draft text clarifications as documented on separ= ate review threads with Martin & Balazs.

 

(6) Passed examples through yanglint to validate.

 

 

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

draft-ietf-netconf-subscribed-notifications-08 =   -  Changes per the latest version...

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

 

(1) YANG model tree partitioned into different secti= ons of the document.  This is intended to simplify readability.

 

(2) Dynamic subscription receivers will receive a &#= 8220;subscription-modified” notification if the definition of a confi= gured filter changes during the lifecycle of that dynamic subscription.

 

(3) A configured subscription VRF is now via leafref= to Network Instance YANG model

 

(4) The transport protocol must be common across all= receivers of a configured subscription.

 

(5) QoS objects have been moved from YANG push into = Subscribed-notifications

 

(6) The configured subscription state machine has be= en tweaked.  It now explicitly includes the invalid and concluded stat= es.    See Section 2.5.1 for the text which backs up the pic= tures below....

 

= .-------.

= | start |-.  

= '-------' |

=      create  .---modify-----.----------------= ------------------.

=           |  |  = ;            | =             &nb= sp;            =         |     &= nbsp;  

=           V  V =          .-------.   = ;      .-----.      =    .---------.     

=  .----[evaluate]--no--->|invalid|-delete->| end |<-delete-|co= ncluded|

=  |           &n= bsp;          '-------' &= nbsp;       '-----'    &n= bsp;    '---------'

= |----[evaluate]--no-.      ^   &nbs= p;            ^ = ;            &n= bsp;   ^ 

=  |        ^    =       |      |  = ;            &n= bsp; |           &nb= sp;     |       

= yes       |     &nbs= p;    '->unsupportable      dele= te           stop-time&nb= sp;   

=  |      modify     &= nbsp;   (subscription-   (subscription-   (su= bscription-

=  |        |    =           terminated) &nb= sp;    terminated)      concluded)&= nbsp;    

=  |        |    =              |&= nbsp;           &nbs= p;   |          = ;       |      =  

=  |   .------------------------------------------------------= ---------.

= '-->|           &= nbsp;           &nbs= p; valid           &= nbsp;           &nbs= p;         |

=      '-------------------------------------------------= --------------'

=  

 

Beyond this diagrammatic change, also extracted and = updated is the configured subscription receiver state machine.  It now= includes an explicit “receiver timeout” state.  

=  

=      .-------------------------------------------------= ---------------.

=      |        &= nbsp;            &nb= sp;   valid         =             &nb= sp;            = |

=      |   .----------.    =             &nb= sp;          .--------. &= nbsp;          |

=      |   | receiver |------------------timeou= t->|receiver|          &nbs= p; |

=      |   |connecting|<------------------re= set---|timeout |          = ;  |

=      |   |      = ;    |<-transport---.      =       '--------'     &nbs= p;      |

=      |   '----------'  loss,reset  = |            &n= bsp;            = ;         |

=      |       |  = ;         |    =      |        &= nbsp;           &nbs= p;             = |

=      | (subscription     | &nb= sp;       |     &nbs= p;            &= nbsp;           &nbs= p;   |

=      |  started)    .--------. = ;    |         =              .-= --------. |

=      |       '----->|&= nbsp;       |     '------= ----------------|         | |

=      |       &n= bsp;      |receiver|-(subscription-suspended)-->= ;|receiver | |

=      |(subscription-| active |    &= nbsp;           &nbs= p;           |suspended| = |

=      |   modified)  |   &= nbsp;    |<-(subscription-resumed,----|   =       | |

=      |        '----&= gt;'--------'   subscription-modified)   '---------' |<= o:p>

=      '-------------------------------------------------= ---------------'

 

 

To match with this mew state, in the YANG model, add= ed is the action “reset-receiver”.   This allows the = resetting of a configured receiver.  This can be interesting if call-h= ome has failed (leaving a receiver in “receiver timeout”), and an operator wants to restart the connecting process for a receiver.

 

=        +--ro receivers<= /p>

=              &#= 43;--ro receiver*

=             &nb= sp;   +---x reset-receiver

=             &nb= sp;      +--ro output

=             &nb= sp;         +--ro time &nb= sp;  yang:date-and-time

 

 

This leaves the following four updates which need to= be included in the drafts:

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

 

(a) Existing NETCONF erro= r mechanism will replace RPC based error responses in –v08 & -v12=

·       Alex should have shortly

 

(b) NMDA model versions&n= bsp;

·       Eric has done this, awaiting completion of (= a), will then integrate and post.

 

(c) Closure of Issue YP #12, value filtering on non-key objects. 

·       Awaiting feedback from email to NETCONF alia= s made earlier today

 

(e) Closure of Issue YP#10: Not notifiable on-change.  

·       Awaiting feedback from email to NETCONF alia= s made earlier today

 

Thanks!

Eric

--_000_49524f8e94924bbda2575ad37dceb59fXCHRTP013ciscocom_-- From nobody Wed Dec 27 02:36: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 1D1AF124319 for ; Wed, 27 Dec 2017 02:36:03 -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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 ndDbC41P7WKJ for ; Wed, 27 Dec 2017 02:36:01 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 D2ADA1200C1 for ; Wed, 27 Dec 2017 02:36:00 -0800 (PST) Received: from LAPTOPR7T053C2 ([188.174.111.15]) by mrelay.perfora.net (mreueus001 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MOQIV-1eZLaK0uwf-005wHs; Wed, 27 Dec 2017 11:35:41 +0100 From: "Alexander Clemm" To: "'Alexander Clemm'" , "'Martin Bjorklund'" , , "'Eric Voit \(evoit\)'" Cc: References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD10E9@sjceml521-mbx.china.huawei.com> <20171205.212443.660483858000758249.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1165@sjceml521-mbx.china.huawei.com> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAD1165@sjceml521-mbx.china.huawei.com> Date: Wed, 27 Dec 2017 02:35:49 -0800 Message-ID: <013601d37efe$78f37350$6ada59f0$@clemm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEEkb9SiUaVzHZaCNq6lY4hch3iUAFwjI4tAiKaWl4CUNQopgIFojdYpLWG/pA= Content-Language: en-us X-Provags-ID: V03:K0:JD42v0ZeLRNHIEXDRzmOpphBIjA5vHRyxkzTU7YdXn7ksviNx2c bzOzlcY11vQHsJaL4DXvcBeVCB27ODS4c2xruPaK5eQ3fhC7YmSY7SaLxyUVDVSI5qy0aJ4 CwADjRZ9nMKQ3mqGzwkelzc+m1CIRXBQSrRZcpdoiON3MAt+ANtPW9roW1ezf83h8R74XRc bJrchuEubmXLURy5ChI+g== X-UI-Out-Filterresults: notjunk:1;V01:K0:gAOt5mR6SgY=:ZzDP1mH/QzP4l8FaaEt7ZF us2u3wbm/RTLkmPIV4EtnlDPYP0tH2Y0n5ZsHgjz/j/iobvyhM29rt5kps4DBweY5glgpC977 dv8NzmeZT+bLj6gU9L8pUCwqIOhiU5Dw4LmBP5geT+w5o+ZQQ16gku1vKYiaWzkUmQGswSSjB fzhMNdJFWxwmVrgdEonjEz/9NGhgBeuNwj11e7eZ8vzcAettiLOznltzbjieduMub6cd8zSH+ 8gxXo6TAy1mSRq3maDuyqJQpAXy04G1gp2w5LCtEmsoQkwbUFa1skzJ9f+eLZsSQqk5L34Ex5 s1x2b2ng/cUmKecly4MtvrudrzUrrJysr6LTQh8Xs+4MkHUjsZg6vx1CoX68lMTSbl7BmEn5B 6BKqoVUZKFAwhxjRlhhjclk1bQwM99TTQwaVuac4jo0+0sD2eIq6VaRylMyt6/ntgfscvjPSC x0K7r5tXCWj1Bl1oBVW/cOvh3KFHhSRwmZkR4mBeTnne53Yk28a3wc6V3N2bVL1/42MXswTLY 9CgUhC5e0UEcKOVW9lEQdX8mf4nUegtw8a1+LxsAip5XCJmdvIsfuNua+DVv9Qm7h8Pf4EuNM /kqo9DFm1MTcydSs/Aa6WGGUGXAEh3YRXp+3dVPyrmeT3Vayx1uk1NODkgI3lwWtMIrfcZeBD d/eJ7/s+dOBBS2k+B6bhj016xJWlhTCyhbUqhoMpCu7qgo++oT9eZK02pT98G05KkvuGHVbWK xlqTHNQ8umFq/9c57JPeVABvSM/TEvs0Iykd2vKaK466hUxHkyB52qCDmW9Ux9gE0Rp11KVHG 1iQCpJL Archived-At: Subject: Re: [Netconf] yang-push issue: error handling 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, 27 Dec 2017 10:36:03 -0000 Hi all, Getting back to the thread on error handling in YANG-Push. =20 In updating the module to move the negotiation hints into = and error-info etc, I have come across another issue for which it is not = clear what is the best way to address it in YANG. It would be great to = get some guidance here from some of the resident YANG experts:-) The problem comes when augmenting the RPCs defined in = subscribed-notifications for YANG-Push. As discussed earlier in the = thread, the negotiation hints and application-specific error conditions = have now been moved into , specifically error-info (as well = as the app-error-tag). The information to include is defined as part of = the description clause pasted below. =20 In YANG-Push, we want to add additional information to return as part of = error-info. For this, we would ideally want to augment the description = clause of the RPC (previously we had augmented the RPC output = parameters, but now this is moving into error-info). How do we do that? = Clearly, we cannot augment just the description clause. Given that we = are still augmenting the input parameters of the RPC, one possibility = would be to use the description clause of that. This does not seem the = ideal place to put it, but what are the alternatives? Another option = would be to not augment the RPC, but define an entirely new RPC (e.g. = "establish-datastore-subscription" in addition to = "establish-subscription"). This is not preferred (as it would run = somehow counter to why we introduced the subscribed-notification = mechanism as generalization of YANG-push, as opposed to making them = orthogonal) . Or perhaps there is a third option that we haven't yet = thought of? =20 Here is the description of establish-subscription in subscribed = notifications that we want to augment. rpc establish-subscription { description "This RPC allows a subscriber to create (and possibly negotiate)=20 a subscription on its own behalf. If successful, the=20 subscription remains in effect for the duration of the=20 subscriber's association with the publisher, or until the=20 subscription is terminated.=20 =20 In case an error is returned, the subscription is not created. =20 In that case, the RPC error response SHOULD include an=20 error-app-tag that indicates the reason why the subscription=20 was not created. Depending on the reason, one of the=20 following strings SHOULD be returned: =20 "stream unavailable"=20 "encoding not supported" "replay not supported"=20 "filter unavailable" // referenced filter does not = exist "filter type unsupported"=20 "filter unsupported" // example: filter too complex "namespace unavailable" =20 "insufficient resources"=20 "unsupportable volume" // requested data volume too = large "no such option" // requested parameter setting not = supported "DSCP unavailable" // requested DSCP marking not = allocatable "QoS unsupported" // requested QoS parameter not = supported =20 In addition, the RPC error response SHOULD include error-info with a set of suggested parameter settings that would have a=20 higher likelihood of succeeding in a subsequent=20 establish-subscription request. The error-info should include the following YANG data: // begin error-info =20 uses hints; =20 leaf replay-start-time-hint { type yang:date-and-time; description "If a replay has been requested, but the requested replay time cannot be honored, this may provide a hint at an alternate time which may be supportable."; } // end error-info "; ... For the datastore subscription in YANG-push, we would like to augment = that YANG-data that the error-info should include. We also want to add = additional app-error tags. =20 Thoughts? --- Alex -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Alexander = Clemm Sent: Tuesday, December 5, 2017 12:35 PM To: Martin Bjorklund ; andy@yumaworks.com Cc: netconf@ietf.org Subject: Re: [Netconf] yang-push issue: error handling Hi Martin, Sure, the eventual solution may make use of rpc-error again. But until = we get there, the currently proposed solution seems to make sense to me. = I don't think we have an issue today with lots of RPCs each defining = their own way of dealing with corner conditions - definition of RPCs is = something that has so far only rarely been exercised with YANG models. = Once this becomes more common, I am sure we will find a more general = solution, but I don't think we are at that point.=20 --- Alex=20 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Tuesday, December 05, 2017 12:25 PM > To: andy@yumaworks.com > Cc: Alexander Clemm ; netconf@ietf.org > Subject: Re: [Netconf] yang-push issue: error handling >=20 > Andy Bierman wrote: > > Hi, > > > > The protocol defines how error handling is done, not the individual=20 > > operations. > > If the request fails, then clients expect an and servers = > > are designed to send an when a client request fails. >=20 > Agreed, and for RESTCONF, the HTTP error codes are used. An HTTP=20 > request that fails does not return 200 ok with a body that explains=20 > that it actually was an error. >=20 > > IMO, a separate error handling procedure for each RPC is more clunky = > > than error-info. >=20 > +1 >=20 > Some additional comments inline. >=20 >=20 > > > While possible, the solution of having to return rpc-error etc=20 > > > does strike me as somewhat clunky. While it is possible to add an = > > > error-app-tag, and negotiation stuff as error-info (and I=20 > > > appreciate the suggestion), that solution would need to be=20 > > > described using a lot of prose in description statements a la=20 > > > SMIv2 (presumably as part of the RPC description, not as part of=20 > > > e.g. the identities, which might be used in a number of places, = not just the error-app-tag). >=20 > If both the error code and hint is defined in a yang-data (i.e., not=20 > using the error-app-tag), you would do: >=20 > yx:yang-data subscription-error { > container subscription-error { > leaf error-code { > type identity { > base error; > } > } > container hints { ... } > } > } >=20 > Then you are right, you have to describe in prose that this yang-data=20 > structure can be sent as error-info. >=20 >=20 > > > I am not sure why that would make an RPC any easier to implement. > > > The same checks still have to be made. >=20 > Agreed. >=20 > > > Why would the proposed solution not acceptable? Ideally YANG = would > > > provide better support to formally define application/RPC-specific = > > > return codes and corner conditions etc. >=20 > Also agreed. But once we have that, such a solution would make use of = > the rpc-error we have (for both NETCONF and RESTCONF). >=20 >=20 > /martin >=20 >=20 > > > Short of that, the proposed solution of adding RPC output=20 > > > parameters that are used for the purpose of indicating what is=20 > > > going on at the application level simply makes them part of the=20 > > > semantics of the specific RPC itself. It is not Netconf=E2=80=99s = role to=20 > > > define what an RPC can or cannot do, just like it cannot define=20 > > > what a particular leaf may or may not represent. That is part of = the RPC definition. > > > > > > > > > > > > Basically, what we are discussing here is behavior of subscription = > > > configuration under corner conditions. The fact that no=20 > > > subscription is created because it would result in an unacceptable = > > > volume of updates for a specific implementation is different from=20 > > > an error condition such as a malformed message that is missing a=20 > > > required message-id, or where a value violates a constraint=20 > > > specified in a MUST-condition. In our case, what is being=20 > > > described are > specific conditions at the application layer, above the > > > Netconf/Restconf generic validation infrastructure. The = operation does > > > not =E2=80=9Cwork=E2=80=9D in the sense that it does not result in = an active=20 > > > subscription, but it does work in the sense that the behavior is=20 > > > very well defined in terms of the effect that the RPC has (i.e.=20 > > > the effect is that it result in creation of a subscription, if=20 > > > certain conditions are met, and it does not result in creation of=20 > > > a subscription in case certain conditions are not met). Why=20 > > > should Netconf restrict what an RPC can or cannot do? This is all = > > > application- > specific. > > > > > > > > > > > > --- Alex > > > > > > > > > > > > > > > > > > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of=20 > > > *Andy Bierman > > > *Sent:* Monday, December 04, 2017 9:15 AM > > > *To:* Martin Bjorklund > > > *Cc:* Netconf > > > *Subject:* Re: [Netconf] yang-push issue: error handling > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Dec 4, 2017 at 4:55 AM, Martin Bjorklund > wrote: > > > > > > Andy Bierman wrote: > > > > Hi, > > > > > > > > IMO the special error handling in YANG Push is not acceptable=20 > > > > because it violates NETCONF and RESTCONF error handling = procedures. > > > > NETCONF says if the operation does not work for any reason an=20 > > > > element SHOULD be returned. > > > > > > I fully agree, and I have pointed this out several times in my=20 > > > reviews. The problem is actually in subscribed notifications, and = > > > I think Eric is tracking that issue. > > > > > > Trying to be constructive, I think that the existing mechanisms in = > > > YANG can be used to achieve the same functionality that these=20 > > > drafts try to achieve. Specifically: > > > > > > 1. Use identities just like the ones you have > > > ("unsupportable-volume", "filter-unavailable" etc), but add = text > > > that explains that these identities are sent as = "error-app-tag" > > > in "rpc-error", encoded to a string as :. = This > > > works for both NETCONF and RESTCONF. > > > > > > 2. For the "hints" extra info that you return, define a = "yang-data" > > > structure with the hints, and explain in text that this = structure > > > is returned in "error-info". This works for both NETCONF and > > > RESTCONF. > > > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > If the error handling was done correctly then the same procedures=20 > > > could be > > > > > > applied to failures for configured subscriptions. > > > > > > > > > > > > > > > > > > > > > As an alternative to 1, you can put the error identitiyref in the=20 > > > "yang-data" structure, and send both the identitiyref and hints in = > > > "error-info". > > > > > > > > > /martin > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > > > > > The returns data even on error. > > > > Instead of the common error-tag, error-info, and other fields,=20 > > > > there is a subscription-result leaf. > > > > > > > > If any client (or even server) functionality uses the NETCONF=20 > > > > and RESTCONF standard error handling, then subscription-result=20 > > > > will not be sent or expected as an error response. Depending on=20 > > > > the server implementation, the code that knows about=20 > > > > establish-subscription may not get called because common error=20 > > > > handling code has already determined there is an to=20 > > > > send instead of a data response. > > > > > > > > Expect that some servers are never going to send data on an=20 > > > > operation failure, and will only send instead. > > > > > > > > > > > > >From sec. 3.8: > > > > > > > > For instance, for the following request: > > > > > > > > > > > xmlns:netconf=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > = xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications" > > > > xmlns:yp=3D"urn:ietf:params:xml:ns:yang:ietf-yang-push"> > > > > > > > > > > > > operational > > > > > > > > > > > xmlns:ex=3D"http://example.com/sample-data/1.0" > > > > select=3D"/ex:foo"/> > > > > > > > > 500 > > > > > > > > > > > > > > > > Figure 3: Establish-Subscription example > > > > > > > > the publisher might return: > > > > > > > > > > > > > > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > > = xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-subscribed-notifications" > > > > xmlns:yp=3D"urn:ietf:params:xml:ns:yang:ietf-yang-push"> > > > > yp:period-unsupported > > > > > > > > > > > > 2000 > > > > > > > > > > > > > > > > Figure 4: Error response example > > > > > > > > > > > > > > > > BTW, all the filter examples seem to be wrong, including the one = > > > > above > > > > > > > > > > > > OLD: > > > > > > > > > > > xmlns:ex=3D"http://example.com/sample-data/1.0" > > > > select=3D"/ex:foo"/> > > > > > > > > > > > > NEW: > > > > > > > > > > > > > > > > > > > /> > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf