From nobody Thu Jul 1 05:58:28 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C122C3A0D03; Thu, 1 Jul 2021 05:58:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov via Datatracker To: Cc: draft-ietf-netmod-nmda-diff.all@ietf.org, last-call@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162514430275.17979.13728329356212798526@ietfa.amsl.com> Reply-To: Alexey Melnikov Date: Thu, 01 Jul 2021 05:58:22 -0700 Archived-At: Subject: [netmod] Secdir last call review of draft-ietf-netmod-nmda-diff-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2021 12:58:23 -0000 Reviewer: Alexey Melnikov Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines an RPC operation to compare management datastores that comply with the NMDA architecture. The Security Considerations talks about a couple of issues specific to the new operation: 1) sensitivity of the new "compare" operation and how access control rights to access it should be restricted. 2) performance considerations of running "compare" and how it can lead to Denial-of-Service, if the number of requests allowed in any given time interval is not restricted. I can't think of other security issues raised by this document that are missing from it. Nits: In Section 6: > The same request in RESTCONF (using JSON format): > > POST /restconf/operations/ietf-nmda-compare:compare HTTP/1.1 > Host: example.com > Content-Type: application/yang-data+json > Accept: application/yang-d Please insert an empty line after the HTTP request header and before the following payload, or your example is not syntactically valid. Also, I don't "application/yang-d" in the list of registered media types on . Did I miss it? > { "ietf-nmda-compare:input" { > "source" : "ietf-datastores:operational", > "target" : "ietf-datastores:intended", > "report-origin" : null, > "xpath-filter" : "/ietf-interfaces:interfaces" > } > } > > The same response in RESTCONF (using JSON format): > > HTTP/1.1 200 OK > Date: Thu, 26 Jan 2019 20:56:30 GMT > Server: example-server > Content-Type: application/yang-d Similar to the above, you need an empty line inserted here. > { "ietf-nmda-compare:output" : { > "differences" : { > "ietf-yang-patch:yang-patch" : { > "patch-id" : "interface status", > "comment" : "diff between intended (source) and operational", > "edit" : [ > { > "edit-id" : "1", > "operation" : "replace", > "target" : "/ietf-interfaces:interface=eth0/enabled", > "value" : { > "ietf-interfaces:interface/enabled" : "false" > }, > "source-value" : { > "ietf-interfaces:interface/enabled" : "true", > "@ietf-interfaces:interface/enabled" : { > "ietf-origin:origin" : "ietf-origin:learned" > } > } > }, > { > "edit-id" : "2", > "operation" : "create", > "target" : "/ietf-interfaces:interface=eth0/description", > "value" : { > "ietf-interface:interface/description" : "ip interface" > } > } > ] > } > } > } > } Best Regards, Alexey From nobody Thu Jul 1 06:42:20 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C253A0884 for ; Thu, 1 Jul 2021 06:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7z_l832u4zZ8 for ; Thu, 1 Jul 2021 06:42:05 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 242F73A0891 for ; Thu, 1 Jul 2021 06:42:01 -0700 (PDT) Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GFzdC0yNzz6L7Wb for ; Thu, 1 Jul 2021 21:31:27 +0800 (CST) Received: from dggeme720-chm.china.huawei.com (10.1.199.116) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Thu, 1 Jul 2021 15:41:54 +0200 Received: from dggeme770-chm.china.huawei.com (10.3.19.116) by dggeme720-chm.china.huawei.com (10.1.199.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Thu, 1 Jul 2021 21:41:52 +0800 Received: from dggeme770-chm.china.huawei.com ([10.8.68.58]) by dggeme770-chm.china.huawei.com ([10.8.68.58]) with mapi id 15.01.2176.012; Thu, 1 Jul 2021 21:41:52 +0800 From: "maqiufang (A)" To: Kent Watsen CC: NETMOD Group Thread-Topic: system configuration sync mechanism Thread-Index: AQHXbTlbMwNyPORPlUmnVFiRkmWyo6ssGKCw Date: Thu, 1 Jul 2021 13:41:52 +0000 Message-ID: References: <38c3aa805f1846d0ad0e5ac67a82cfa1@huawei.com> <0100017a5501b507-02588bdb-c4c4-430f-9b53-39eefdfffe8b-000000@email.amazonses.com> <765757acb49741f7a64013b5525cdbb4@huawei.com> <0100017a59f81d52-dd739c93-2634-487f-a4c9-403f9d350c19-000000@email.amazonses.com> In-Reply-To: <0100017a59f81d52-dd739c93-2634-487f-a4c9-403f9d350c19-000000@email.amazonses.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.123.93] Content-Type: multipart/alternative; boundary="_000_d913d5e6abc54436b27ac02119c0aed9huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] system configuration sync mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2021 13:42:18 -0000 --_000_d913d5e6abc54436b27ac02119c0aed9huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEtlbnQ6DQoNCkZyb206IEtlbnQgV2F0c2VuIFttYWlsdG86a2VudCtpZXRmQHdhdHNlbi5u ZXRdDQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMzAsIDIwMjEgNjo1MSBBTQ0KVG86IG1hcWl1ZmFu ZyAoQSkgPG1hcWl1ZmFuZzFAaHVhd2VpLmNvbT4NCkNjOiBuZXRjb25mQGlldGYub3JnOyBuZXRt b2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBzeXN0ZW0gY29uZmlndXJhdGlvbiBzeW5jIG1lY2hh bmlzbQ0KDQpbQ0MtaW5nIE5FVE1PRCwgYXMgSSB0aGluayB0aGlzIGRpc2N1c3Npb24gYmVsb25n cyBvbiB0aGF0IGxpc3QuLi5wbGVhc2UgY29uc2lkZXIgcmVtb3ZpbmcgTkVUQ09ORiBpbiB5b3Vy IHJlcGx5XQ0KW1FpdWZhbmcgTWFdIFRoYW5rcywgYWNjZXB0ZWQuLTopDQoNCkhpIFFpdWZhbmcs DQoNCg0KDQpIaSwgS2VudDoNClRoYW5rcyBmb3Iga2lja2luZyBvZmYgc29tZSBkaXNjdXNzaW9u IGFyb3VuZCB0aGlzIGRyYWZ0LiBQbGVhc2Ugc2VlIG15IHJlcGx5IGlubGluZS4NCg0KSSdtIGlu dGVyZXN0ZWQgaW4gdGhpcyB3b3JrLCBhcyBpdCBzZWVtcyBhcyBpZiB0aGUgPHN5c3RlbT4gZGF0 YXN0b3JlIHdhcyBsZWZ0IG91dCBvZiB0aGUgTk1EQSB3b3JrLg0KDQoNCjEpIEkgd2lzaCB0aGVy ZSB3ZXJlIG1vcmUgZXhhbXBsZXMsIGVzcGVjaWFsbHkgZm9yICJyZXNvdXJjZS1pbmRlcGVuZGVu dOKAnSBjb25maWd1cmF0aW9uLiAgSSB1bmRlcnN0YW5kIHdlbGwgZW5vdWdoICJyZXNvdXJjZS1k ZXBlbmRlbnQiIChkeW5hbWljKSBjb25maWd1cmF0aW9uLCBidXQgYW0gdW5jbGVhciBhYm91dCB3 aGF0IGFsbCAicmVzb3VyY2UtaW5kZXBlbmRlbnTigJ0gZW50YWlscy4gIEJ5IGV4YW1wbGUsIEpV Tk9TIGhhcyBhIGNvbmNlcHQgY2FsbGVkIOKAnEpVTk9TIGRlZmF1bHRz4oCdLCB3aGljaCBpcyBl ZmZlY3RpdmVseSByZWFkLW9ubHkgYW5kIGhpZGRlbi1ieS1kZWZhdWx0IGNvbmZpZ3VyYXRpb24g dGhhdCwgbW9zdCB0aW1lcywgbXVzdCBiZSByZWZlcmVuY2VkIGluIG9yZGVyIHRvIHRha2UgZWZm ZWN0LiAgIEZvciBpbnN0YW5jZSwgY2hlY2sgdGhlIGV4YW1wbGVzIGhhbGZ3YXkgZG93biB0aGlz IHBhZ2U6IGh0dHBzOi8vbmV4dGhlYWRlci5uZXQvMjAxNi8wNi8xMC9qdW5vcy1kZWZhdWx0cy1n cm91cC4gIElzIHRoaXMgc2ltaWxhciB0byB3aGF0IHlvdSBoYXZlIGluIG1pbmQ/DQpbUWl1ZmFu ZyBNYV0gIFllcy4gUGh5c2ljYWwtcmVzb3VyY2UtaW5kZXBlbmRlbnQgc3lzdGVtIGNvbmZpZ3Vy YXRpb24gaXMgZ2VuZXJhdGVkIHdoZW4gdGhlIGRldmljZSBpcyBwb3dlcmVkIG9uIGFuZCBoYXMg bm90aGluZyB0byBkbyB3aXRoIHRoZSBwaHlzaWNhbCByZXNvdXJjZS4gTG9vcGJhY2sgaW50ZXJm YWNlIG1heSBiZSB0aGUgbW9zdCBjb21tb24gcGh5c2ljYWwtcmVzb3VyY2UtaW5kZXBlbmRlbnQg c3lzdGVtIGNvbmZpZ3VyYXRpb24uIFRvIG15IGtub3dsZWRnZSwgbWFueSB2ZW5kb3JzICgoZS5n LiwgSHVhd2VpIE5FNDBFIGFuZCBDaXNjbyBJT1MgWFIpIHdpbGwgcHJvdmlkZSBzZXZlcmFsIHBy ZWRlZmluZWQgdXNlciBncm91cHMgYW5kL29yIHRhc2sgZ3JvdXBzIHdoaWNoIGFyZSB1c2VkIGZv ciBhdXRoZW50aWNhdGlvbiwgYXV0aG9yaXphdGlvbiBhbmQgYWNjb3VudGluZyAoQUFBKSBzZXJ2 aWNlcy4gU2luY2UgdGhlc2UgY29uZmlndXJhdGlvbnMgYXJlIHByb3ZpZGVkIGJ5IHRoZSBkZXZp Y2Uvc3lzdGVtLCB0aGV5IGNvdWxkICBiZSB0cmVhdGVkIGFzIHN5c3RlbSBjb25maWd1cmF0aW9u LiBJIHRoaW5rIHlvdXIgIGluZm9ybWF0aW9uIGFib3V0IHRoZSBwcmVkZWZpbmVkIGhpZGRlbiBj b25maWd1cmF0aW9uIGdyb3VwIHdoaWNoIGNvbnRhaW5zIHByZWNvbmZpZ3VyZWQgdmFsdWVzIHNo b3VsZCBhbHNvIGJlIHRyZWF0ZWQgdGhlIHNhbWUuDQpNb3JlIGV4YW1wbGVzIGFib3V0IHN5c3Rl bSBjb25maWd1cmF0aW9ucyB3b3VsZCBiZSB3b3JrZWQgb24gYW5kIGFkZGVkIGluICB0aGUgbmV4 dCB2ZXJzaW9uIG9mIHRoZSBkcmFmdC46KQ0KDQpSaWdodCwgdGhlIGxvb3BiYWNrIGludGVyZmFj ZSBpcyBhIGNvbW1vbiBleGFtcGxlIGJ1dCwgbW9yZSBnZW5lcmFsbHksIEkgdGhpbmsgInJlc291 cmNlLWluZGVwZW5kZW504oCdIGNvbmZpZ3VyYXRpb24gbWlnaHQgZmFsbCBpbnRvIGV4YWN0bHkg dHdvIGNhdGVnb3JpZXM6DQoNCiAgICAgICAgICAgIDEpIGNvbmZpZyB0aGF0IGlzIOKAnGFwcGxp ZWTigJ0gaW1tZWRpYXRlbHkNCiAgICAgICAgICAgICAgICAgICAgICAgIC0gZXg6IGludGVyZmFj ZXMvbG8wL3VuaXQgMC9mYW1pbHkgWyBpbmV0IGluZXQ2IF0NCiAgICAgICAgICAgICAgICAgICAg ICAgIC0gZXg6IHN5c3RlbS9sb2dpbi9wYXNzd29yZC9taW5pbXVtLWxlbmd0aD02DQogICAgICAg ICAgICAgICAgICAgICAgICAtIGV4OiBzeXN0ZW0vcG9ydHMvY29uc29sZS10eXBlPXZ0MTAwDQog ICAgICAgICAgICAgICAgICAgICAgICAtIGV4OiBzeXN0ZW0vc3lzbG9nL2FyY2hpdmUtc2l6ZT0y NTZrOw0KICAgICAgICAgICAgICAgICAgICAgICAgLSBleDogY2hhc3Npcy9jbHVzdGVyL2ZhYnJp Yy1tb25pdG9yaW5nL2hlYXJ0YmVhdC1pbnRlcnZhbD0xMDAwOw0KICAgICAgICAgICAgICAgICAg ICAgICAgLSBleDogc2VjdXJpdHkvem9uZXMvc2VjdXJpdHktem9uZS9qdW5vcy1ob3N0Ow0KICAg ICAgICAgICAgICAgICAgICAgICAgLSBleDogc2VjdXJpdHkvYWxnL3NpcC9pbmFjdGl2ZS1tZWRp YS10aW1lb3V0PTEyMDsNCg0KICAgICAgICAgICAgMikgY29uZmlnIHRoYXQgaXMg4oCcYXBwbGll ZOKAnSBvbmx5IGFmdGVyIGJlaW5nIHJlZmVyZW5jZWQgYnkgb3RoZXIgY29uZmlnIChlLmcuLCBB Q0xzKQ0KICAgICAgICAgICAgICAgICAgICAgICAgLSBleDogYXBwbGljYXRpb25zL2Z0cC/igKYN CiAgICAgICAgICAgICAgICAgICAgICAgIC0gZXg6IGFwcGxpY2F0aW9ucy90ZnRwLy4uLg0KICAg ICAgICAgICAgICAgICAgICAgICAgLSBleDogYXBwbGljYXRpb25zL3NtdHAv4oCmDQogICAgICAg ICAgICAgICAgICAgICAgICAtIGV4OiB1dG0vY3VzdG9tLW9iamVjdHMvQWR1bHRfTWF0ZXJpYWwv Li4uDQogICAgICAgICAgICAgICAgICAgICAgICAtIGV4OiB1dG0vY3VzdG9tLW9iamVjdHMvUmVs aWdpb24vLi4uDQogICAgICAgICAgICAgICAgICAgICAgICAtIGV4OiB1dG0vY3VzdG9tLW9iamVj dHMvR2FtYmxpbmcv4oCmDQpbUWl1ZmFuZyBNYV0gSSBkb27igJl0IHF1aXRlIHVuZGVyc3RhbmQg dGhpcyBraW5kIG9mIGNvbmZpZ3VyYXRpb24sIGNvdWxkIHlvdSBwbGVhc2UgZXhwYW5kPyBEbyB5 b3UgbWVhbiB0aGF0IHRoZSBwcmVkZWZpbmVkIGNvbmZpZ3VyYXRpb25zICBmb3IgYSBjZXJ0YWlu IGFwcGxpY2F0aW9uKGUuZy4sIGZ0cCkgd2lsbCBub3QgdGFrZSBlZmZlY3QgdW50aWwgYmVpbmcg cmVmZXJlbmNlZC9lbmFibGVkPyBJIGFtIHdvbmRlcmluZyBpZiB0aGVzZSBjb25maWd1cmF0aW9u IHdpbGwgcHJlc2VudCBpbiB0aGUgPG9wZXJhdGlvbmFsPih3aGljaCBjb250YWlucyBhbGwgdGhl IGNvbmZpZ3VyYXRpb24gYWN0dWFsbHkgdXNlZCBieSB0aGUgZGV2aWNlKSBiZWZvcmUgdGhleeKA mXJlIHJlZmVyZW5jZWQuDQoNCkl0IHdvdWxkIGJlIGdvb2QgaWYgd2UgY291bGQgZGV0ZXJtaW5l IGlmIHRoZXJlIGFyZSBhbnkgb3RoZXIgInJlc291cmNlLWluZGVwZW5kZW504oCdIGNvbmZpZ3Vy YXRpb24gY2F0ZWdvcmllcyBoZXJlLg0KW1FpdWZhbmcgTWFdIERvIHlvdSB0aGluayB0aGVyZSBl eGlzdHMgY29uZGl0aW9uYWwgc3lzdGVtIGNvbmZpZ3VyYXRpb24oaWYgdGhlIHByZWNlZGluZyBj b25maWd1cmF0aW9ucyB5b3UgbWVudGlvbmVkIGFib3ZlIGlzIG5vdCk/IEZvciBleGFtcGxlLCBp ZiBTU0ggaXMgZW5hYmxlZCBvbiBhIGRldmljZSwgU1NILXJlbGF0ZWQga2V5cyBhcmUgYXV0b21h dGljYWxseSBnZW5lcmF0ZWQuIFN1Y2ggY29uZmlndXJhdGlvbnMgYXJlIGdlbmVyYXRlZCBhdCB0 aGUgbW9tZW50IHdoZW4gYSBzcGVjaWFsIGZ1bmN0aW9uYWxpdHkgaXMgZW5hYmxlZC4NCg0KQXMg Zm9yICJyZXNvdXJjZS1kZXBlbmRlbnTigJ0gY29uZmlndXJhdGlvbiwgSSB3b25kZXIgaG93IHRo aXMgaXMgc3VwcG9zZWQgdG8gd29ya+KApm1vcmUgc3BlY2lmaWNhbGx5LCBJIHdvbmRlciB0byB3 aGF0IGV4dGVudCB0aGUgSUVURiBuZWVkcyB0byBjYXJlIGhvdyBpZiB3b3JrcyAocGVyaGFwcyB0 aGUgc2FtZSBjb3VsZCBiZSBzYWlkIGZvciAicmVzb3VyY2UtaW5kZXBlbmRlbnTigJ0gY29uZmln dXJhdGlvbiB0b28pLiAgRm9yIGluc3RhbmNlLCBpbiBKVU5PUywgdGhlcmUgZXhpc3RzIGEgY29u ZmlnLXRlbXBsYXRlIHRoYXQgaXMgYXV0b21hdGljYWxseSBhcHBsaWVkIHRvIGFueSB1c2VyLWRl ZmluZWQgaW50ZXJmYWNlLCBzdWNoIGFzOg0KDQogICAganVub3MtZGVmYXVsdC1wcm9maWxlIHsN CiAgICAgICAgaW50ZXJmYWNlcyB7DQogICAgICAgICAgICAiJGp1bm9zLWludGVyZmFjZS1pZmQt bmFtZSIgew0KICAgICAgICAgICAgICAgIHVuaXQgIiRqdW5vcy11bmRlcmx5aW5nLWludGVyZmFj ZS11bml0IiB7DQogICAgICAgICAgICAgICAgICAgIGZhbWlseSBpbmV0Ow0KICAgICAgICAgICAg ICAgICAgICBmYW1pbHkgaW5ldDY7DQogICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgfQ0K ICAgICAgICB9DQogICAgfQ0KTm90YWJseSwgUkZDIDgzNDIgbWVudGlvbnMgdGVtcGxhdGVzIGFz IHNvbWV0aGluZyB0aGF0IG1pZ2h0IGJlIGV4cGFuZGVkIHdoZW4gY29udmVydGluZyA8cnVubmlu Zz4gdG8gPGludGVuZGVkPi4gIEFjdHVhbGx5LCBrbm93aW5nIHRoYXQgaXQgaXMgPGludGVuZGVk PiB0aGF0IGlzIHN1YmplY3QgdG8gdmFsaWRhdGlvbiwgaXQgc2VlbXMgdGhhdCBtdWNoIChpZiBu b3QgYWxsKSBvZiA8c3lzdGVtPiBzaG91bGQgYmUgY29uc3VtZWQgd2hlbiBjb252ZXJ0aW5nIDxy dW5uaW5nPiB0byA8aW50ZW5kZWQ+IC0gYWdyZWVkPw0KW1FpdWZhbmcgTWFdIERvIHlvdSBtZWFu IHRoYXQgIDxpbnRlbmRlZD4gc2hvdWxkIGluY2x1ZGUgdGhlIHN5c3RlbSBjb25maWd1cmF0aW9u IHdoaWNoIGlzIGdlbmVyYXRlZCBkdWUgdG8gdGhlIGV4cGFuc2lvbiBvZiB0ZW1wbGF0ZXM/ICBJ IG5vdGljZSB0aGF0IFJGQzgzNDIgc2F5cyBpbiBzZWMuNC4xDQrigJxPbmUgb2YgdGhlIG9ic2Vy dmF0aW9uczoNClNvbWUgaW1wbGVtZW50YXRpb25zIGhhdmUgcHJvcHJpZXRhcnkgbWVjaGFuaXNt cyB0aGF0IGFsbG93DQpjbGllbnRzIHRvIGRlZmluZSBjb25maWd1cmF0aW9uIHRlbXBsYXRlcyBp biA8cnVubmluZz4uICBUaGVzZQ0KdGVtcGxhdGVzIGFyZSBleHBhbmRlZCBhdXRvbWF0aWNhbGx5 IGJ5IHRoZSBzeXN0ZW0sIGFuZCB0aGUNCnJlc3VsdGluZyBjb25maWd1cmF0aW9uIGlzIGFwcGxp ZWQgaW50ZXJuYWxseS7igJ0NClNvIEkgYW0gd29uZGVyaW5nIHdoZXRoZXIgdGhlIHN5c3RlbS1w cmVkZWZpbmVkIGNvbmZpZy10ZW1wbGF0ZSB3b3VsZCBiZSBwcmVzZW50IGluIHRoZSA8cnVubmlu Zz4gYW5kIHVwZGF0aW5nIDxpbnRlbmRlZD4gIHRocm91Z2ggcGVyZm9ybWVkIHRlbXBsYXRlLWV4 cGFuc2lvbi4NCk15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBpZiB0aGUgY29uZmlnLXRlbXBsYXRl IGlzIGNvbmZpZ3VyZWQgaW4gPHJ1bm5pbmc+LCB0aGUgZXhwYW5kZWQgY29uZmlndXJhdGlvbiBp biB0aGUgPGludGVuZGVkPiBzaG91bGQgc3RpbGwgYmUgdGhlIGNsaWVudCBjb25maWd1cmF0aW9u Lg0KSWYgdGhlIHRlbXBsYXRlIGlzIHByZWNvbmZpZ3VyZWQgYnkgdGhlIHN5c3RlbSwgdGhlIGNv bmZpZ3VyYXRpb24gZ2VuZXJhdGVkIHRocm91Z2ggcGVyZm9ybWVkIHRlbXBsYXRlLWV4cGFuc2lv biBzaG91bGQgYmUgb25seSBwcmVzZW50IGluIHRoZSA8b3BlcmF0aW9uYWw+IGlmIG5vdCBleHBs aWNpdGx5IHJlLWNvbmZpZ3VyZWQgaW4gPHJ1bm5pbmc+IGJ5IHRoZSBjbGllbnQuDQoNCg0KMikg UGxlYXNlIHRyZWF0IE5FVENPTkYgYW5kIFJFU1RDT05GIGVxdWFsbHkuICBDdXJyZW50bHkgdGhl IGRyYWZ0IHNwZWFrcyBvbmx5IHRvIGhvdyBpdCBpbXBhY3RzIE5FVENPTkYsIGJ1dCBpdCBzaG91 bGQgZXF1YWxseSBzaG93IGhvdyBSRVNUQ09ORiBpbiBpbXBhY3RlZC4NCltRaXVmYW5nIE1hXSBU aGFua3MgZm9yIGJyaW5naW5nIGl0IHRvIG15IGF0dGVudGlvbiwgSSB3b3VsZCB0YWtlIFJFU1RD T05GIGludG8gY29uc2lkZXJhdGlvbiBhbmQgc2VlIGhvdyB0aGUgcHJvcG9zYWwgd29ya3Mgb24g UkVTVENPTkYuDQoNCkl0IHdpbGwgd29yayBuZWFybHkgdHJhbnNwYXJlbnRseSwgaWYgbm90IGNv bXBsZXRlbHkgc28uDQoNCldoYXQgeW91IG5lZWQgdG8gZG8sIG1vc3RseSwgaXMgc2VhcmNoL3Jl cGxhY2Ug4oCcTkVUQ09ORuKAnSDigJQ+IOKAnFlBTkctZHJpdmVuIG1hbmFnZW1lbnQgcHJvdG9j b2xzIHN1Y2ggYXMgTkVUQ09ORiBhbmQgUkVTVENPTkbigJ0NCg0K4oCmYW5kIGFsc28g4oCc4oCm VGhlIGZvbGxvd2luZyBleGFtcGxlIGlzIHByb3ZpZGVkIHVzaW5nIE5FVENPTkYsIGJ1dCBjb3Vs ZCBqdXN0IGFzIGVhc2lseSBiZSBwcm92aWRlZCB1c2luZyBSRVNUQ09ORiwgaW4gWE1MIG9yIEpT T04u4oCdICAgQWx0ZXJuYXRlbHksIGFuZCBwZXJoYXBzIGJldHRlciwgaGF2ZSBhIG1peCBvZiBi b3RoIGtpbmRzIG9mIGV4YW1wbGVzIHRocm91Z2hvdXQgeW91ciBkb2N1bWVudC4NCltRaXVmYW5n IE1hXSBJIGFtIGFsc28gdGhpbmtpbmcgIHRoZSBzYW1lIGVmZmVjdGl2ZSB3YXksIHRoYW5rcy4N Cg0KDQoNCjMpIFRoZSDigJxiYXNpYyBtb2Rl4oCdIHRlcm0gc291bmRzIHRvbyBjbG9zZSB0byB0 aGUg4oCcd2l0aC1kZWZhdWx0c+KAnSBiYXNpYyBtb2Rlcy4uLmNhbiB3ZSBwbGVhc2UgcGljayBh bm90aGVyIG5hbWUgKGUuZy4sIHN5c3RlbS1kYXRhc3RvcmUtb3BlcmF0aW5nLW1vZGUpPw0KW1Fp dWZhbmcgTWFdIFllcywgYWdyZWUuIEFjdHVhbGx5IHdlIGRvbuKAmXQgcmVhbGx5IHdhbnQgdG8g Y2F1c2UgYW55IGNvbmZ1c2lvbiBvciBtaXN1bmRlcnN0YW5kaW5ncy4gVGhpcyB0ZXJtIGNvbnRy b2xzIHdoZXRoZXIgdGhlIGRldmljZSB3aWxsIHVwZGF0ZSA8cnVubmluZz4gd2l0aCBzeXN0ZW0g Y29uZmlndXJhdGlvbiBjaGFuZ2Ugb3Igbm90Lg0KWW91ciBwcm9wb3NhbCBsb29rcyBnb29kIHRv IG1lLCBvdGhlciBzdWdnZXN0aW9ucyBhcmUgYWxzbyB3ZWxjb21lIGhlcmUuDQoNCkFjay4NCg0K DQogUmVnYXJkaW5nIHlvdXIgcXVlc3Rpb24gYmVsb3cgSSBkb27igJl0IGZlZWwgcmVhZHkgdG8g Y29tbWVudCBvbiBpdCB5ZXQuICBJIGRvIHVuZGVyc3RhbmQgdGhlIEpVTk9TIG1vZGVsIGFuZCwg aWYgaXQgaXMgY29tcGF0aWJsZSwgd291bGQgcmVjb21tZW5kIGNvbnNpZGVyaW5nLCBhcyBpdCBp cyBpbXBsZW1lbnRlZCBhbmQgc2VlbXMgdG8gYmUgd29ya2luZyB3ZWxsIGVub3VnaC4gIFRoYXQg c2FpZCwgaXQgbWlnaHQgYmUgdGhlIGNhc2UgdGhhdCBldmVyeSB2ZW5kb3IgaGFzIGRlZmluZWQg dGhlaXIgb3duIHdheSBhbmQgZWFjaCBuZWVkcyB0byBiZSBkb2N1bWVudGVkIGluIHR1cm4uLi4N CltRaXVmYW5nIE1hXSBUaGUgaXNzdWUgd2UgdHJ5IHRvIHJlc29sdmUgaGVyZSBpcyB0aGF0IGlu IG9yZGVyIGZvciBzeXN0ZW0gY29uZmlndXJhdGlvbnMgYmVpbmcgcmVmZXJlbmNlZCBvciB0byBt YWtlIHN1cmUgYSBzdWNjZXNzZnVsIHZhbGlkYXRpb24gd2hlbiB0aGUgc3lzdGVtIGNvbmZpZ3Vy YXRpb24gaXMgaW4gdGhlIHdoZW4vbXVzdCBzdGF0ZW1lbnQsIHRoZSBzeXN0ZW0gY29uZmlndXJh dGlvbiBtdXN0IGJlIHJldHJpZXZlZCBmcm9tIDxvcGVyYXRpb25hbD4gZmlyc3RseSBhbmQgdGhl biBjb3BpZWQgaW50byA8cnVubmluZz4gbWFudWFsbHksIHdoaWNoIGlzIGN1bWJlcnNvbWUuIElu IHRoaXMgY2FzZSwgd2Ugd291bGQgbGlrZSB0byBkZWZpbmUgc29tZSBraW5kIG9mIG1lY2hhbmlz bSB0byBzeW5jaHJvbml6ZSBzeXN0ZW0gY29uZmlndXJhdGlvbiBpbnRvIDxydW5uaW5nPi4gQ3Vy cmVudGx5IHR3byBzeXN0ZW0gY29uZmlndXJhdGlvbiBkYXRhIGhhbmRsaW5nIG1vZGVzIGFyZSBz cGVjaWZpZWQuIE9uZSB3aWxsIHVwZGF0ZSA8cnVubmluZz4gd2l0aCBhbnkgc3lzdGVtIGNvbmZp Z3VyYXRpb24gY2hhbmdlIGF1dG9tYXRpY2FsbHksIGFuZCB0aGUgb3RoZXIgd2lsbCBub3QsIHNv IHRoYXQgdGhlIGltcGxlbWVudGVyIG1heSBjaG9vc2UgdGhlIG1vZGUgbW9yZSBzdWl0YWJsZSBm b3IgdGhlbS4gSG9wZWZ1bGx5IHRoaXMgY2xhcmlmaWVzIHdoYXQgd2UgdHJ5IHRvIGRvLiBQbGVh c2UgZmVlbCBmcmVlIHRvIGNvbW1lbnQgb3Igc3VnZ2VzdC4NCg0KDQpJ4oCZbSBiZWdpbm5pbmcg dG8gdGhpbmsgdGhhdDoNCsK3ICAgICAgICAgYXV0by1jb3B5aW5nIGludG8gPHJ1bm5pbmc+IGlz IGxpa2VseSBuZXZlciBhIGdvb2QgaWRlYSwgYmVjYXVzZSBpdCB2aW9sYXRlcyB0aGUgZGVmaW5p dGlvbiBvZiA8cnVubmluZz4NCltRaXVmYW5nIE1hXSBJIGFtIHF1aXRlIGF3YXJlIHRoYXQgZGlm ZmVyZW50IGRhdGFzdG9yZXMgaW4gTk1EQSByZXByZXNlbnRzIGRpZmZlcmVudCB2aWV3cyBvZiBk YXRhIG5vZGVzLiAgQW5kIDxydW5uaW5nPiByZXByZXNlbnRzIGEgY29uZmlndXJhdGlvbiBkYXRh c3RvcmUgaG9sZGluZyB0aGUgY3VycmVudCBjb25maWd1cmF0aW9uIG9mIHRoZSBkZXZpY2UuDQpT aG91bGQgd2UgY29uc2lkZXIgc3lzdGVtIGNvbmZpZ3VyYXRpb24gYWxzbyBiZSBwYXJ0IG9mIGN1 cnJlbnQgY29uZmlndXJhdGlvbiBvZiB0aGUgZGV2aWNlPyBGcm9tIG15IHBlcnNwZWN0aXZlLCB0 aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHN5c3RlbSBjb25maWd1cmF0aW9uIGFuZCAgY2xpZW50LWNv bmZpZ3VyYXRpb24gbGllcyBvbmx5IGluIHdobyBwcm92aWRlcyBpdC4NCsK3ICAgICAgICAgaGF2 aW5nIGluIDxvcGVyYXRpb25hbD4gZG9lc27igJl0IG1ha2Ugc2Vuc2UsIHNpbmNlIHRoZSB0d2Vh a3Mgd291bGRu4oCZdCBnbyB0aHJ1IDxydW5uaW5nPiAtLT4gPGludGVuZGVkPiB2YWxpZGF0aW9u Lg0KDQpJ4oCZbSB3b25kZXJpbmcgaWYgYSBtb2RlbCBsaWtlIGJlbG93IHdvdWxkIHdvcmsgZm9y IGV2ZXJ5b25lIC0gdGhvdWdodHM/DQpbUWl1ZmFuZyBNYV0gPGludGVuZGVkPiByZXByZXNlbnRz IHRoZSBjb25maWd1cmF0aW9uIGFmdGVyIGFsbCBjb25maWd1cmF0aW9uIHRyYW5zZm9ybWF0aW9u cyB0byA8cnVubmluZz4gaGF2ZSBiZWVuIHBlcmZvcm1lZCwgc28gSSB0aGluayBpdCBpcyBvbmx5 IGNvdXBsZWQgdG8gPHJ1bm5pbmc+Lg0KQW55d2F5LCB0aGUgPHN5c3RlbT4gc2hvdWxkIGFsc28g aW50ZXJhY3RzIHdpdGggPG9wZXJhdGlvbmFsPi4gIEFncmVlZD8NCg0KQmVzdCBSZWdhcmRzLA0K UWl1ZmFuZyBNYQ0KDQogICAgICstLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgKy0tLS0t LS0tLS0tKw0KICAgICB8IDxjYW5kaWRhdGU+IHwgICAgICAgICAgICAgICAgIHwgPHN0YXJ0dXA+ IHwNCiAgICAgfCAgKGN0LCBydykgICB8PC0tLSsgICAgICAgKy0tLT58IChjdCwgcncpICB8DQog ICAgICstLS0tLS0tLS0tLS0tKyAgICB8ICAgICAgIHwgICAgKy0tLS0tLS0tLS0tKw0KICAgICAg ICAgICAgfCAgICAgICAgICAgfCAgICAgICB8ICAgICAgICAgICB8DQogICAgICAgICAgICB8ICAg ICAgICAgKy0tLS0tLS0tLS0tKyAgICAgICAgIHwNCiAgICAgICAgICAgICstLS0tLS0tLT58IDxy dW5uaW5nPiB8PC0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgIHwgKGN0LCBydykgIHwN CiAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICstLS0tLS0tLS0tKyAgICAgICAgICAgICAgIHwgICAgICAgIC8vIGNvbmZp Z3VyYXRpb24gdHJhbnNmb3JtYXRpb25zLA0KIHwgPHN5c3RlbT4gfC0tLS0tLS0tLS0tLS0tPnwg ICAgICAgIC8vIGUuZy4sIHJlbW92YWwgb2Ygbm9kZXMgbWFya2VkIGFzDQogfCAoY3QsIHJvKSB8 IC8vIHVuZGVybGF5ICAgfCAgICAgICAgLy8gImluYWN0aXZlIiwgZXhwYW5zaW9uIG9mDQogKy0t LS0tLS0tLS0rICAgICAgICAgICAgICAgfCAgICAgICAgLy8gdGVtcGxhdGVzDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgdg0KICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0r DQogICAgICAgICAgICAgICAgICAgICAgfCA8aW50ZW5kZWQ+IHwgLy8gc3ViamVjdCB0byB2YWxp ZGF0aW9uDQogICAgICAgICAgICAgICAgICAgICAgfCAoY3QsIHJvKSAgIHwNCiAgICAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgICAgIC8vIGNoYW5nZXMgYXBwbGllZCwgc3ViamVjdCB0bw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgIC8vIGxvY2FsIGZhY3RvcnMsIGUuZy4sIG1pc3NpbmcNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAvLyByZXNvdXJjZXMsIGRlbGF5cw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICBkeW5hbWljICAgICAgICAgICAgICB8 ICAgKy0tLS0tLS0tIGxlYXJuZWQgY29uZmlndXJhdGlvbg0KICAgICAgIGNvbmZpZ3VyYXRpb24g ICAgICAgIHwgICArLS0tLS0tLS0gc3lzdGVtIGNvbmZpZ3VyYXRpb24NCiAgICAgICBkYXRhc3Rv cmVzIC0tLS0tKyAgICB8ICAgKy0tLS0tLS0tIGRlZmF1bHQgY29uZmlndXJhdGlvbg0KICAgICAg ICAgICAgICAgICAgICAgICB8ICAgIHwgICB8DQogICAgICAgICAgICAgICAgICAgICAgIHYgICAg diAgIHYNCiAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAg ICAgICAgICAgfCA8b3BlcmF0aW9uYWw+IHwgPC0tIHN5c3RlbSBzdGF0ZQ0KICAgICAgICAgICAg ICAgICAgICB8IChjdCArIGNmLCBybykgfA0KICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0t LS0tLS0tKw0KDQoNCg0KDQoNCg0KQmVzdCBSZWdhcmRzLA0KUWl1ZmFuZyBNYQ0KDQpLLiAvLyBj b250cmlidXRvcg0KDQoNCg0KDQoNCg== --_000_d913d5e6abc54436b27ac02119c0aed9huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6TWVubG87fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0 ZWQtc3BhY2U7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10 YWItc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs MA0KCXttc28tbGlzdC1pZDoxNTI5OTUyNzc2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo3MDcw MDczNzA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5IaSwgS2VudDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEtlbnQgV2F0c2VuIFtt YWlsdG86a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5l c2RheSwgSnVuZSAzMCwgMjAyMSA2OjUxIEFNPGJyPg0KPGI+VG86PC9iPiBtYXFpdWZhbmcgKEEp ICZsdDttYXFpdWZhbmcxQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBuZXRjb25mQGll dGYub3JnOyBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IHN5c3RlbSBj b25maWd1cmF0aW9uIHN5bmMgbWVjaGFuaXNtPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+W0NDLWluZyBORVRNT0QsIGFzIEkgdGhpbmsgdGhpcyBkaXNjdXNzaW9u IGJlbG9uZ3Mgb24gdGhhdCBsaXN0Li4ucGxlYXNlIGNvbnNpZGVyIHJlbW92aW5nIE5FVENPTkYg aW4geW91ciByZXBseV08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUWl1ZmFuZyBNYV0gVGhhbmtzLCBhY2Nl cHRlZC4tOik8L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPkhpJm5ic3A7UWl1ZmFuZyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkhpLCBLZW50Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBmb3Iga2lja2luZyBvZmYgc29tZSBkaXNjdXNzaW9u IGFyb3VuZCB0aGlzIGRyYWZ0LiBQbGVhc2Ugc2VlIG15IHJlcGx5IGlubGluZS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+SSdtIGludGVyZXN0ZWQgaW4gdGhpcyB3b3JrLCBhcyBpdCBzZWVtcyBh cyBpZiB0aGUgJmx0O3N5c3RlbSZndDsgZGF0YXN0b3JlIHdhcyBsZWZ0IG91dCBvZiB0aGUgTk1E QSB3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjEpIEkgd2lzaCB0aGVyZSB3ZXJlIG1v cmUmbmJzcDtleGFtcGxlcywmbmJzcDtlc3BlY2lhbGx5IGZvciAmcXVvdDtyZXNvdXJjZS1pbmRl cGVuZGVudOKAnSZuYnNwO2NvbmZpZ3VyYXRpb24uICZuYnNwO0kgdW5kZXJzdGFuZCB3ZWxsIGVu b3VnaCAmcXVvdDtyZXNvdXJjZS1kZXBlbmRlbnQmcXVvdDsgKGR5bmFtaWMpDQogY29uZmlndXJh dGlvbiwgYnV0IGFtIHVuY2xlYXIgYWJvdXQmbmJzcDt3aGF0Jm5ic3A7YWxsICZxdW90O3Jlc291 cmNlLWluZGVwZW5kZW504oCdJm5ic3A7ZW50YWlscy4gJm5ic3A7QnkgZXhhbXBsZSwgSlVOT1Mg aGFzIGEgY29uY2VwdCBjYWxsZWQmbmJzcDvigJxKVU5PUyBkZWZhdWx0c+KAnSwgd2hpY2ggaXMm bmJzcDtlZmZlY3RpdmVseSZuYnNwO3JlYWQtb25seSBhbmQgaGlkZGVuLWJ5LWRlZmF1bHQgY29u ZmlndXJhdGlvbiB0aGF0LCBtb3N0IHRpbWVzLCBtdXN0IGJlIHJlZmVyZW5jZWQgaW4gb3JkZXIg dG8gdGFrZQ0KIGVmZmVjdC4gJm5ic3A7IEZvciBpbnN0YW5jZSwgY2hlY2sgdGhlIGV4YW1wbGVz IGhhbGZ3YXkgZG93biZuYnNwO3RoaXMgcGFnZTombmJzcDs8YSBocmVmPSJodHRwczovL25leHRo ZWFkZXIubmV0LzIwMTYvMDYvMTAvanVub3MtZGVmYXVsdHMtZ3JvdXAiPjxzcGFuIHN0eWxlPSJj b2xvcjpwdXJwbGUiPmh0dHBzOi8vbmV4dGhlYWRlci5uZXQvMjAxNi8wNi8xMC9qdW5vcy1kZWZh dWx0cy1ncm91cDwvc3Bhbj48L2E+LiAmbmJzcDtJcyB0aGlzIHNpbWlsYXIgdG8gd2hhdCB5b3Ug aGF2ZQ0KIGluIG1pbmQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5bUWl1ZmFuZyBNYV0gJm5ic3A7WWVzLiBQaHlzaWNhbC1yZXNv dXJjZS1pbmRlcGVuZGVudCBzeXN0ZW0gY29uZmlndXJhdGlvbiBpcyBnZW5lcmF0ZWQgd2hlbiB0 aGUgZGV2aWNlIGlzIHBvd2VyZWQgb24gYW5kIGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIHBo eXNpY2FsDQogcmVzb3VyY2UuIExvb3BiYWNrIGludGVyZmFjZSBtYXkgYmUgdGhlIG1vc3QgY29t bW9uIHBoeXNpY2FsLXJlc291cmNlLWluZGVwZW5kZW50IHN5c3RlbSBjb25maWd1cmF0aW9uLiBU byBteSBrbm93bGVkZ2UsIG1hbnkgdmVuZG9ycyAoKGUuZy4sIEh1YXdlaSBORTQwRSBhbmQgQ2lz Y28gSU9TIFhSKSB3aWxsIHByb3ZpZGUgc2V2ZXJhbCBwcmVkZWZpbmVkIHVzZXIgZ3JvdXBzIGFu ZC9vciB0YXNrIGdyb3VwcyB3aGljaCBhcmUgdXNlZCBmb3IgYXV0aGVudGljYXRpb24sDQogYXV0 aG9yaXphdGlvbiBhbmQgYWNjb3VudGluZyAoQUFBKSBzZXJ2aWNlcy4gU2luY2UgdGhlc2UgY29u ZmlndXJhdGlvbnMgYXJlIHByb3ZpZGVkIGJ5IHRoZSBkZXZpY2Uvc3lzdGVtLCB0aGV5IGNvdWxk ICZuYnNwO2JlIHRyZWF0ZWQgYXMgc3lzdGVtIGNvbmZpZ3VyYXRpb24uIEkgdGhpbmsgeW91ciAm bmJzcDtpbmZvcm1hdGlvbiBhYm91dCB0aGUgcHJlZGVmaW5lZCBoaWRkZW4gY29uZmlndXJhdGlv biBncm91cCB3aGljaCBjb250YWlucyBwcmVjb25maWd1cmVkDQogdmFsdWVzIHNob3VsZCBhbHNv IGJlIHRyZWF0ZWQgdGhlIHNhbWUuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+TW9yZSBleGFtcGxlcyBhYm91dCBzeXN0ZW0gY29uZmlndXJhdGlvbnMgd291bGQgYmUgd29y a2VkIG9uIGFuZCBhZGRlZCBpbiAmbmJzcDt0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBkcmFmdC46 KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlJpZ2h0LCB0aGUgbG9vcGJhY2sgaW50 ZXJmYWNlIGlzIGEgY29tbW9uIGV4YW1wbGUgYnV0LCBtb3JlIGdlbmVyYWxseSwgSSB0aGluayAm cXVvdDtyZXNvdXJjZS1pbmRlcGVuZGVudOKAnSBjb25maWd1cmF0aW9uIG1pZ2h0IGZhbGwgaW50 byBleGFjdGx5IHR3byBjYXRlZ29yaWVzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjEpIGNvbmZpZyB0aGF0IGlzIOKAnGFwcGxpZWTigJ0gaW1tZWRpYXRlbHk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+LSBleDogaW50ZXJmYWNlcy9sbzAvdW5pdCAwL2ZhbWls eSBbIGluZXQgaW5ldDYgXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gY2xhc3M9ImFwcGxl LXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj4tIGV4OiZuYnNwOzxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+c3lzdGVtL2xvZ2luL3Bhc3N3b3JkLzwvc3Bhbj5taW5p bXVtLWxlbmd0aD02PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBjbGFzcz0iYXBwbGUtdGFi LXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPi0gZXg6IHN5c3RlbS9wb3J0 cy9jb25zb2xlLXR5cGU9dnQxMDA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGNsYXNzPSJh cHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+LSZuYnNwO2V4 OiZuYnNwOzxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+c3lzdGVtLzwvc3Bhbj5zeXNsb2cvYXJj aGl2ZS1zaXplPTI1Nms7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBjbGFzcz0iYXBwbGUt dGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPi0gZXg6IGNoYXNzaXMv Y2x1c3Rlci9mYWJyaWMtbW9uaXRvcmluZy9oZWFydGJlYXQtaW50ZXJ2YWw9MTAwMDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LSBleDogc2VjdXJpdHkvem9uZXMvc2VjdXJp dHktem9uZS9qdW5vcy1ob3N0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGNs YXNzPSJhcHBsZS10YWItc3BhbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4t IGV4OiBzZWN1cml0eS9hbGcvc2lwL2luYWN0aXZlLW1lZGlhLXRpbWVvdXQ9MTIwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjIpIGNvbmZp ZyB0aGF0IGlzIOKAnGFwcGxpZWTigJ0gb25seSBhZnRlciBiZWluZyByZWZlcmVuY2VkIGJ5IG90 aGVyIGNvbmZpZyAoZS5nLiwgQUNMcyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGNsYXNz PSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+LSBleDog YXBwbGljYXRpb25zL2Z0cC/igKY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBj bGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ LSBleDogYXBwbGljYXRpb25zL3RmdHAvLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4tIGV4OiBhcHBsaWNhdGlvbnMvc210cC/igKY8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4i PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+LSBleDogdXRtL2N1c3RvbS1vYmpl Y3RzL0FkdWx0X01hdGVyaWFsLy4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+LSBleDogdXRtL2N1c3RvbS1vYmplY3RzL1JlbGlnaW9uLy4uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWIt c3BhbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tIGV4OiB1dG0vY3VzdG9t LW9iamVjdHMvR2FtYmxpbmcv4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltRaXVmYW5nIE1h XSBJIGRvbuKAmXQgcXVpdGUgdW5kZXJzdGFuZCB0aGlzIGtpbmQgb2YgY29uZmlndXJhdGlvbiwg Y291bGQgeW91IHBsZWFzZSBleHBhbmQ/IERvIHlvdSBtZWFuIHRoYXQgdGhlIHByZWRlZmluZWQg Y29uZmlndXJhdGlvbnMmbmJzcDsgZm9yIGEgY2VydGFpbg0KIGFwcGxpY2F0aW9uKGUuZy4sIGZ0 cCkgd2lsbCBub3QgdGFrZSBlZmZlY3QgdW50aWwgYmVpbmcgcmVmZXJlbmNlZC9lbmFibGVkPyBJ IGFtIHdvbmRlcmluZyBpZiB0aGVzZSBjb25maWd1cmF0aW9uIHdpbGwgcHJlc2VudCBpbiB0aGUg Jmx0O29wZXJhdGlvbmFsJmd0Oyh3aGljaCBjb250YWlucyBhbGwgdGhlIGNvbmZpZ3VyYXRpb24g YWN0dWFsbHkgdXNlZCBieSB0aGUgZGV2aWNlKSBiZWZvcmUgdGhleeKAmXJlIHJlZmVyZW5jZWQu PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5JdCB3b3VsZCBiZSBnb29kIGlmIHdlIGNvdWxkIGRldGVybWlu ZSBpZiB0aGVyZSBhcmUgYW55IG90aGVyICZxdW90O3Jlc291cmNlLWluZGVwZW5kZW504oCdIGNv bmZpZ3VyYXRpb24gY2F0ZWdvcmllcyBoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUWl1 ZmFuZyBNYV0gRG8geW91IHRoaW5rIHRoZXJlIGV4aXN0cyBjb25kaXRpb25hbCBzeXN0ZW0gY29u ZmlndXJhdGlvbihpZiB0aGUgcHJlY2VkaW5nIGNvbmZpZ3VyYXRpb25zIHlvdSBtZW50aW9uZWQg YWJvdmUgaXMgbm90KT8gRm9yIGV4YW1wbGUsIGlmIFNTSA0KIGlzIGVuYWJsZWQgb24gYSBkZXZp Y2UsIFNTSC1yZWxhdGVkIGtleXMgYXJlIGF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkLiBTdWNoIGNv bmZpZ3VyYXRpb25zIGFyZSBnZW5lcmF0ZWQgYXQgdGhlIG1vbWVudCB3aGVuIGEgc3BlY2lhbCBm dW5jdGlvbmFsaXR5IGlzIGVuYWJsZWQuPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5BcyBmb3ImbmJzcDsmcXVvdDtyZXNvdXJjZS1kZXBlbmRlbnTigJ0g Y29uZmlndXJhdGlvbiwgSSB3b25kZXIgaG93IHRoaXMgaXMgc3VwcG9zZWQgdG8gd29ya+KApm1v cmUgc3BlY2lmaWNhbGx5LCBJIHdvbmRlciB0byB3aGF0IGV4dGVudCB0aGUgSUVURiBuZWVkcyB0 byBjYXJlIGhvdyBpZiB3b3JrcyAocGVyaGFwcyB0aGUgc2FtZSBjb3VsZA0KIGJlIHNhaWQgZm9y Jm5ic3A7JnF1b3Q7cmVzb3VyY2UtaW5kZXBlbmRlbnTigJ0gY29uZmlndXJhdGlvbiB0b28pLiAm bmJzcDtGb3IgaW5zdGFuY2UsIGluIEpVTk9TLCB0aGVyZSBleGlzdHMgYSBjb25maWctdGVtcGxh dGUgdGhhdCBpcyBhdXRvbWF0aWNhbGx5IGFwcGxpZWQgdG8gYW55IHVzZXItZGVmaW5lZCBpbnRl cmZhY2UsIHN1Y2ggYXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4t bGVmdDozNi4wcHQiPg0KJm5ic3A7ICZuYnNwOyZuYnNwO2p1bm9zLWRlZmF1bHQtcHJvZmlsZSB7 PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7aW50ZXJmYWNlcyB7PGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmcXVvdDskanVu b3MtaW50ZXJmYWNlLWlmZC1uYW1lJnF1b3Q7IHs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7dW5pdCAmcXVvdDskanVub3Mt dW5kZXJseWluZy1pbnRlcmZhY2UtdW5pdCZxdW90OyB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7 ZmFtaWx5IGluZXQ7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ZmFtaWx5IGluZXQ2Ozxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJz cDt9PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDt9 PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7fTxicj4NCiZuYnNwOyAmbmJz cDsmbmJzcDt9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5Ob3RhYmx5LCBSRkMgODM0MiBtZW50aW9u cyB0ZW1wbGF0ZXMgYXMgc29tZXRoaW5nIHRoYXQgbWlnaHQgYmUgZXhwYW5kZWQgd2hlbiBjb252 ZXJ0aW5nICZsdDtydW5uaW5nJmd0OyB0byAmbHQ7aW50ZW5kZWQmZ3Q7LiAmbmJzcDtBY3R1YWxs eSwga25vd2luZyB0aGF0IGl0IGlzICZsdDtpbnRlbmRlZCZndDsgdGhhdCBpcyBzdWJqZWN0IHRv IHZhbGlkYXRpb24sIGl0IHNlZW1zIHRoYXQgbXVjaCAoaWYNCiBub3QgYWxsKSBvZiAmbHQ7c3lz dGVtJmd0OyBzaG91bGQgYmUgY29uc3VtZWQmbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PndoZW4gY29udmVydGluZyAmbHQ7cnVubmluZyZndDsgdG8gJmx0O2ludGVuZGVkJmd0OyAtIGFn cmVlZD88L3NwYW4+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1FpdWZhbmcgTWFdIERvIHlvdSBt ZWFuIHRoYXQgJm5ic3A7Jmx0O2ludGVuZGVkJmd0OyBzaG91bGQgaW5jbHVkZSB0aGUgc3lzdGVt IGNvbmZpZ3VyYXRpb24gd2hpY2ggaXMgZ2VuZXJhdGVkIGR1ZSB0byB0aGUgZXhwYW5zaW9uIG9m IHRlbXBsYXRlcz8gJm5ic3A7SSBub3RpY2UgdGhhdCBSRkM4MzQyDQogc2F5cyBpbiBzZWMuNC4x PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+4oCcT25lIG9mIHRoZSBvYnNlcnZhdGlv bnM6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Tb21lIGltcGxlbWVudGF0aW9u cyBoYXZlIHByb3ByaWV0YXJ5IG1lY2hhbmlzbXMgdGhhdCBhbGxvdzxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPmNsaWVudHMgdG8gZGVmaW5lIGNvbmZpZ3VyYXRpb24gdGVtcGxhdGVz IGluICZsdDtydW5uaW5nJmd0Oy4mbmJzcDsgVGhlc2U8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj50ZW1wbGF0ZXMgYXJlIGV4cGFuZGVkIGF1dG9tYXRpY2FsbHkgYnkgdGhlIHN5c3Rl bSwgYW5kIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnJlc3VsdGluZyBjb25m aWd1cmF0aW9uIGlzIGFwcGxpZWQgaW50ZXJuYWxseS7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L2k+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5TbyBJIGFtIHdvbmRlcmluZyB3aGV0aGVyIHRoZSBzeXN0ZW0tcHJlZGVmaW5l ZCBjb25maWctdGVtcGxhdGUgd291bGQgYmUgcHJlc2VudCBpbiB0aGUgJmx0O3J1bm5pbmcmZ3Q7 IGFuZCB1cGRhdGluZyAmbHQ7aW50ZW5kZWQmZ3Q7ICZuYnNwO3Rocm91Z2ggcGVyZm9ybWVkIHRl bXBsYXRlLWV4cGFuc2lvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk15IHVu ZGVyc3RhbmRpbmcgaXMgdGhhdCBpZiB0aGUgY29uZmlnLXRlbXBsYXRlIGlzIGNvbmZpZ3VyZWQg aW4gJmx0O3J1bm5pbmcmZ3Q7LCB0aGUgZXhwYW5kZWQgY29uZmlndXJhdGlvbiBpbiB0aGUgJmx0 O2ludGVuZGVkJmd0OyBzaG91bGQgc3RpbGwgYmUgdGhlIGNsaWVudCBjb25maWd1cmF0aW9uLjxv OnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHRoZSB0ZW1wbGF0ZSBpcyBwcmVjb25m aWd1cmVkIGJ5IHRoZSBzeXN0ZW0sIHRoZSBjb25maWd1cmF0aW9uIGdlbmVyYXRlZCB0aHJvdWdo IHBlcmZvcm1lZCB0ZW1wbGF0ZS1leHBhbnNpb24gc2hvdWxkIGJlIG9ubHkgcHJlc2VudCBpbiB0 aGUgJmx0O29wZXJhdGlvbmFsJmd0Ow0KIGlmIG5vdCBleHBsaWNpdGx5IHJlLWNvbmZpZ3VyZWQg aW4gJmx0O3J1bm5pbmcmZ3Q7IGJ5IHRoZSBjbGllbnQuPG86cD48L286cD48L3NwYW4+PC9pPjwv Yj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjIpIFBsZWFzZSB0cmVhdCBORVRD T05GIGFuZCBSRVNUQ09ORiZuYnNwO2VxdWFsbHkuICZuYnNwO0N1cnJlbnRseSB0aGUgZHJhZnQg c3BlYWtzIG9ubHkgdG8gaG93IGl0IGltcGFjdHMgTkVUQ09ORiwgYnV0IGl0IHNob3VsZCBlcXVh bGx5IHNob3cgaG93IFJFU1RDT05GDQogaW4mbmJzcDtpbXBhY3RlZC48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltRaXVmYW5nIE1hXSBUaGFua3MgZm9yIGJy aW5naW5nIGl0IHRvIG15IGF0dGVudGlvbiwgSSB3b3VsZCB0YWtlIFJFU1RDT05GIGludG8gY29u c2lkZXJhdGlvbiBhbmQgc2VlIGhvdyB0aGUgcHJvcG9zYWwgd29ya3Mgb24gUkVTVENPTkYuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SXQgd2lsbCB3b3JrIG5lYXJseSB0cmFuc3Bh cmVudGx5LCBpZiBub3QgY29tcGxldGVseSBzby4gJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPldoYXQgeW91IG5lZWQgdG8gZG8s IG1vc3RseSwgaXMgc2VhcmNoL3JlcGxhY2Ug4oCcTkVUQ09ORuKAnSDigJQmZ3Q7IOKAnFlBTkct ZHJpdmVuIG1hbmFnZW1lbnQgcHJvdG9jb2xzIHN1Y2ggYXMgTkVUQ09ORiBhbmQgUkVTVENPTkbi gJ08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+4oCm YW5kIGFsc28g4oCc4oCmVGhlIGZvbGxvd2luZyBleGFtcGxlIGlzIHByb3ZpZGVkIHVzaW5nIE5F VENPTkYsIGJ1dCBjb3VsZCBqdXN0IGFzIGVhc2lseSBiZSBwcm92aWRlZCB1c2luZyBSRVNUQ09O RiwgaW4gWE1MIG9yIEpTT04u4oCdICZuYnNwOyBBbHRlcm5hdGVseSwgYW5kIHBlcmhhcHMgYmV0 dGVyLCBoYXZlIGEgbWl4IG9mIGJvdGgga2luZHMgb2YgZXhhbXBsZXMgdGhyb3VnaG91dA0KIHlv dXIgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1FpdWZhbmcgTWFdIEkgYW0gYWxzbyB0aGlu a2luZyAmbmJzcDt0aGUgc2FtZSBlZmZlY3RpdmUgd2F5LCB0aGFua3MuICZuYnNwOzwvc3Bhbj48 L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+MykgVGhlJm5ic3A74oCcYmFzaWMgbW9kZeKAnSB0ZXJtJm5ic3A7c291bmRzIHRvbyBj bG9zZSB0byB0aGUmbmJzcDvigJx3aXRoLWRlZmF1bHRz4oCdIGJhc2ljIG1vZGVzLi4uY2FuIHdl IHBsZWFzZSBwaWNrIGFub3RoZXIgbmFtZSAoZS5nLiwgc3lzdGVtLWRhdGFzdG9yZS1vcGVyYXRp bmctbW9kZSk/DQogJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5bUWl1ZmFuZyBNYV0gWWVzLCBhZ3JlZS4gQWN0dWFsbHkgd2UgZG9u4oCZdCByZWFs bHkgd2FudCB0byBjYXVzZSBhbnkgY29uZnVzaW9uIG9yIG1pc3VuZGVyc3RhbmRpbmdzLiBUaGlz IHRlcm0gY29udHJvbHMgd2hldGhlciB0aGUgZGV2aWNlIHdpbGwgdXBkYXRlDQogJmx0O3J1bm5p bmcmZ3Q7IHdpdGggc3lzdGVtIGNvbmZpZ3VyYXRpb24gY2hhbmdlIG9yIG5vdC48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Zb3VyIHByb3Bvc2FsIGxvb2tzIGdvb2QgdG8g bWUsIG90aGVyIHN1Z2dlc3Rpb25zIGFyZSBhbHNvIHdlbGNvbWUgaGVyZS48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5BY2suPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ UmVnYXJkaW5nIHlvdXIgcXVlc3Rpb24gYmVsb3cgSSBkb27igJl0IGZlZWwgcmVhZHkgdG8gY29t bWVudCBvbiBpdCB5ZXQuICZuYnNwO0kgZG8gdW5kZXJzdGFuZCB0aGUgSlVOT1MgbW9kZWwgYW5k LCBpZiBpdCBpcyZuYnNwO2NvbXBhdGlibGUsJm5ic3A7d291bGQgcmVjb21tZW5kDQogY29uc2lk ZXJpbmcsIGFzIGl0IGlzIGltcGxlbWVudGVkIGFuZCBzZWVtcyB0byBiZSB3b3JraW5nIHdlbGwg ZW5vdWdoLiAmbmJzcDtUaGF0IHNhaWQsIGl0IG1pZ2h0IGJlIHRoZSBjYXNlIHRoYXQgZXZlcnkg dmVuZG9yIGhhcyBkZWZpbmVkJm5ic3A7dGhlaXIgb3duIHdheSBhbmQgZWFjaCBuZWVkcyB0byBi ZSZuYnNwO2RvY3VtZW50ZWQgaW4gdHVybi4uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W1FpdWZhbmcgTWFdIFRoZSBpc3N1ZSB3 ZSB0cnkgdG8gcmVzb2x2ZSBoZXJlIGlzIHRoYXQgaW4gb3JkZXIgZm9yIHN5c3RlbSBjb25maWd1 cmF0aW9ucyBiZWluZyByZWZlcmVuY2VkIG9yIHRvIG1ha2Ugc3VyZSBhIHN1Y2Nlc3NmdWwgdmFs aWRhdGlvbg0KIHdoZW4gdGhlIHN5c3RlbSBjb25maWd1cmF0aW9uIGlzIGluIHRoZSB3aGVuL211 c3Qgc3RhdGVtZW50LCB0aGUgc3lzdGVtIGNvbmZpZ3VyYXRpb24gbXVzdCBiZSByZXRyaWV2ZWQg ZnJvbSAmbHQ7b3BlcmF0aW9uYWwmZ3Q7IGZpcnN0bHkgYW5kIHRoZW4gY29waWVkIGludG8gJmx0 O3J1bm5pbmcmZ3Q7IG1hbnVhbGx5LCB3aGljaCBpcyBjdW1iZXJzb21lLiBJbiB0aGlzIGNhc2Us IHdlIHdvdWxkIGxpa2UgdG8gZGVmaW5lIHNvbWUga2luZCBvZiBtZWNoYW5pc20gdG8NCiBzeW5j aHJvbml6ZSBzeXN0ZW0gY29uZmlndXJhdGlvbiBpbnRvICZsdDtydW5uaW5nJmd0Oy4gQ3VycmVu dGx5IHR3byBzeXN0ZW0gY29uZmlndXJhdGlvbiBkYXRhIGhhbmRsaW5nIG1vZGVzIGFyZSBzcGVj aWZpZWQuIE9uZSB3aWxsIHVwZGF0ZSAmbHQ7cnVubmluZyZndDsgd2l0aCBhbnkgc3lzdGVtIGNv bmZpZ3VyYXRpb24gY2hhbmdlIGF1dG9tYXRpY2FsbHksIGFuZCB0aGUgb3RoZXIgd2lsbCBub3Qs IHNvIHRoYXQgdGhlIGltcGxlbWVudGVyIG1heSBjaG9vc2UNCiB0aGUgbW9kZSBtb3JlIHN1aXRh YmxlIGZvciB0aGVtLiBIb3BlZnVsbHkgdGhpcyBjbGFyaWZpZXMgd2hhdCB3ZSB0cnkgdG8gZG8u IFBsZWFzZSBmZWVsIGZyZWUgdG8gY29tbWVudCBvciBzdWdnZXN0Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SeKAmW0gYmVnaW5u aW5nIHRvIHRoaW5rIHRoYXQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+YXV0by1jb3B5aW5nIGludG8gJmx0O3J1 bm5pbmcmZ3Q7IGlzIGxpa2VseSBuZXZlciBhIGdvb2QgaWRlYSwgYmVjYXVzZSBpdCB2aW9sYXRl cyB0aGUgZGVmaW5pdGlvbiBvZiAmbHQ7cnVubmluZyZndDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltR aXVmYW5nIE1hXSBJIGFtIHF1aXRlIGF3YXJlIHRoYXQgZGlmZmVyZW50IGRhdGFzdG9yZXMgaW4g Tk1EQSByZXByZXNlbnRzIGRpZmZlcmVudCB2aWV3cyBvZg0KIGRhdGEgbm9kZXMuICZuYnNwO0Fu ZCAmbHQ7cnVubmluZyZndDsgcmVwcmVzZW50cyBhIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlIGhv bGRpbmcgdGhlIGN1cnJlbnQgY29uZmlndXJhdGlvbiBvZiB0aGUgZGV2aWNlLg0KPG86cD48L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TaG91bGQgd2UgY29uc2lkZXIgc3lzdGVtIGNvbmZp Z3VyYXRpb24gYWxzbyBiZSBwYXJ0IG9mIGN1cnJlbnQgY29uZmlndXJhdGlvbiBvZiB0aGUgZGV2 aWNlPw0KIEZyb20gbXkgcGVyc3BlY3RpdmUsIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gc3lzdGVt IGNvbmZpZ3VyYXRpb24gYW5kICZuYnNwO2NsaWVudC1jb25maWd1cmF0aW9uIGxpZXMgb25seSBp biB3aG8gcHJvdmlkZXMgaXQuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+aGF2aW5nIGluICZsdDtvcGVyYXRpb25h bCZndDsgZG9lc27igJl0IG1ha2Ugc2Vuc2UsIHNpbmNlIHRoZSB0d2Vha3Mgd291bGRu4oCZdCBn byB0aHJ1ICZsdDtydW5uaW5nJmd0OyAtLSZndDsgJmx0O2ludGVuZGVkJmd0OyB2YWxpZGF0aW9u LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5J4oCZ bSB3b25kZXJpbmcgaWYgYSBtb2RlbCBsaWtlIGJlbG93IHdvdWxkIHdvcmsgZm9yIGV2ZXJ5b25l IC0gdGhvdWdodHM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1FpdWZhbmcgTWFdICZsdDtpbnRlbmRlZCZn dDsgcmVwcmVzZW50cyB0aGUgY29uZmlndXJhdGlvbiBhZnRlciBhbGwgY29uZmlndXJhdGlvbiB0 cmFuc2Zvcm1hdGlvbnMgdG8gJmx0O3J1bm5pbmcmZ3Q7IGhhdmUgYmVlbiBwZXJmb3JtZWQsIHNv IEkgdGhpbmsgaXQgaXMgb25seSBjb3VwbGVkDQogdG8gJmx0O3J1bm5pbmcmZ3Q7LjxvOnA+PC9v OnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFueXdheSwgdGhlICZsdDtzeXN0ZW0mZ3Q7IHNob3Vs ZCBhbHNvIGludGVyYWN0cyB3aXRoICZsdDtvcGVyYXRpb25hbCZndDsuICZuYnNwO0FncmVlZD88 bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+UWl1ZmFuZyBNYTxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Ok1l bmxvIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS0tLS0tLS0tLS0tLSYjNDM7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0t LS0tLS0tLSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5Ok1lbmxvIj4mbmJzcDsgJm5ic3A7ICZuYnNwO3wgJmx0O2NhbmRpZGF0ZSZndDsg fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHwgJmx0O3N0YXJ0dXAmZ3Q7IHw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6TWVubG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsoY3Qs IHJ3KSAmbmJzcDsgfCZsdDstLS0mIzQzOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLSZn dDt8IChjdCwgcncpICZuYnNwO3w8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6TWVubG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLS0tLS0t LS0tLS0tJiM0MzsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsg Jm5ic3A7JiM0MzstLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Ok1lbmxvIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg fDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpN ZW5sbyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tLSYjNDM7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB8PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5Ok1lbmxvIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmIzQzOy0tLS0tLS0tJmd0O3wgJmx0O3J1bm5pbmcmZ3Q7IHwmbHQ7LS0tLS0tLS0mIzQz Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpN ZW5sbyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8IChjdCwgcncpICZuYnNwO3w8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6TWVubG8iPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Ok1lbmxvIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6TWVubG8iPiZuYnNwOyYjNDM7LS0tLS0tLS0tLSYjNDM7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOy8vIGNvbmZpZ3VyYXRpb24gdHJhbnNmb3JtYXRpb25zLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpNZW5sbyI+ Jm5ic3A7fCAmbHQ7c3lzdGVtJmd0OyB8LS0tLS0tLS0tLS0tLS0mZ3Q7fCAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsvLyBlLmcuLCByZW1vdmFsIG9mIG5vZGVzIG1hcmtlZCBhczwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpNZW5sbyI+Jm5i c3A7fCAoY3QsIHJvKSB8IC8vIHVuZGVybGF5ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOy8vICZxdW90O2luYWN0aXZlJnF1b3Q7LCBleHBhbnNpb24gb2Y8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6TWVubG87Y29sb3I6Ymxh Y2siPiZuYnNwOyYjNDM7LS0tLS0tLS0tLSYjNDM7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTpNZW5sbyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ly8gdGVtcGxhdGVzPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Ok1lbmxvIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHY8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6TWVubG8iPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpNZW5sbyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8 ICZsdDtpbnRlbmRlZCZndDsgfCAvLyBzdWJqZWN0IHRvIHZhbGlkYXRpb248L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6TWVubG8iPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgfCAoY3QsIHJvKSAmbmJzcDsgfDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpNZW5sbyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm IzQzOy0tLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5Ok1lbmxvIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ly8gY2hhbmdlcyBhcHBsaWVk LCBzdWJqZWN0IHRvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5Ok1lbmxvIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ly8gbG9jYWwgZmFjdG9ycywgZS5nLiwgbWlz c2luZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpNZW5sbyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOy8vIHJlc291cmNlcywgZGVsYXlzPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Ok1lbmxvIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6TWVubG8iPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO2R5bmFtaWMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fCAmbmJzcDsgJiM0MzstLS0tLS0tLSBsZWFybmVkIGNvbmZpZ3VyYXRpb248L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6TWVubG8iPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbmZpZ3VyYXRpb24gJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7fCAmbmJzcDsgJiM0MzstLS0tLS0tLSBzeXN0ZW0gY29uZmlndXJhdGlvbjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpNZW5sbyI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGF0YXN0b3JlcyAtLS0tLSYjNDM7ICZuYnNwOyAm bmJzcDt8ICZuYnNwOyAmIzQzOy0tLS0tLS0tIGRlZmF1bHQgY29uZmlndXJhdGlvbjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpNZW5sbyI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyB8PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Ok1lbmxvIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3YgJm5ic3A7ICZuYnNwO3YgJm5ic3A7IHY8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6TWVubG8iPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Ok1lbmxvIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbHQ7 b3BlcmF0aW9uYWwmZ3Q7IHwgJmx0Oy0tIHN5c3RlbSBzdGF0ZTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpNZW5sbyI+Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwg KGN0ICYjNDM7IGNmLCBybykgfDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpNZW5sbyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0t JiM0Mzs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDow Y207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDozNi4w cHQiPg0KPG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5CZXN0IFJlZ2FyZHMsPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5RaXVmYW5nIE1hPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+Sy4gLy8gY29udHJpYnV0b3I8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_d913d5e6abc54436b27ac02119c0aed9huaweicom_-- From nobody Fri Jul 2 05:59:28 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D1A3A1DCD; Fri, 2 Jul 2021 05:59:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Shwetha Bhandari via Datatracker To: Cc: draft-ietf-netmod-nmda-diff.all@ietf.org, last-call@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162523075802.5464.801347526657945@ietfa.amsl.com> Reply-To: Shwetha Bhandari Date: Fri, 02 Jul 2021 05:59:18 -0700 Archived-At: Subject: [netmod] Opsdir last call review of draft-ietf-netmod-nmda-diff-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 12:59:18 -0000 Reviewer: Shwetha Bhandari Review result: Has Nits I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: This is a Standards Track document that defines an RPC operation to compare management datastores and returns diffs between the datastores as a yang-patch. While most access management of the RPC, ensuring availability of the server by rate limiting are considered I have an open question to authors: where/how will operational metrics such as rate of requests received, errors, rate limiting if applied, server resources consumed to process the request etc, about this new RPC be defined and reported? This is useful information for server operation where this RPC is enabled. Nits: The RESTCONF example content-type is json but it is set to application/yang-d that is not present in the registry - should it be application/yang-patch+json? From nobody Fri Jul 2 08:19:15 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA57D3A21F2 for ; Fri, 2 Jul 2021 08:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 He_xuANlnA5D for ; Fri, 2 Jul 2021 08:19:10 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 11C1A3A21F6 for ; Fri, 2 Jul 2021 08:19:09 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id a15so18685783lfr.6 for ; Fri, 02 Jul 2021 08:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3VRvxqwZQaJ3jU9LPxSaadXKFoKo7yX0h92J78muLBo=; b=1nPhTv+j+pIq/9Acp8V7naHiIlRQBZxljLzKpCw9BHD8Xm3BMUtpyPLgJVdzaQu+A6 S6o2mC8FpI6oZWcndPFXMU0cWle2gV2x5X3oLE0+79x+33mgeq90B17ySwsaSTb8X02o h7mzYloCnYE70xLumeHXfrcuPL5lwu373c7BBtPC62EC7ZLJjBuDNDsPZ/CEs+YSMfe+ Ux59O8V8rIvcv+N7u2QiI6RCx8or/oy2clBxbkIeI0eH2mtC470N3IZZG0YOcVmK2eK1 EnCjnJhJKj8a8aM3mV24CHc1eXT1o20WFPnqjEkfmSQXBWZm75e3L9OKttag9VArouob ioSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3VRvxqwZQaJ3jU9LPxSaadXKFoKo7yX0h92J78muLBo=; b=Xla1iRo2UHKYksw8wXCcC8iUHGWWnokxZbmH9gW1xA3pvfBGqrXPAVQhc60zimDz6E 5OXY19fPJ6Nd9np+ROSlHiYx5HM/lsZJIljvnZv1lNSb5Qs6zvlw639HyITZydYAYfVk zt8IPRqvm/tAuRFLGWs/FuRLdFP0+M54gKKPJ9ao/hnUaBxuoDfi9QCCv1Mjyl3u2aZg s5+UTdE5j3YFMLnks2e8nzyB/eV9HrC/Y6xDfaJFN6FjFQU2v32Nd3ZE0z4KWzx3iLkE 0spEoAtdmR2ktGBakr34Dgo9xyhk9NP0l2czx24ttqneBx6UZW8sOWH7EOXzKOBgmm+D gwjg== X-Gm-Message-State: AOAM532NOlQjAT/fRpK7DSNz695cU+hupfGvN/yOS4G9zhI6peDu/d2t UzpB6nPpSwLGZceekKtQurCdf6qbmyQ/rWeSNzaiDw== X-Google-Smtp-Source: ABdhPJy48tn89eJUdB9K8KUtij5HDPMujuJoEH1DEvOROUiP1uSTMzFlTW25Y7+v2TxtQBDIFNuNIh+fbghovZuzYq8= X-Received: by 2002:a05:6512:374b:: with SMTP id a11mr95844lfs.377.1625239146862; Fri, 02 Jul 2021 08:19:06 -0700 (PDT) MIME-Version: 1.0 References: <162523075802.5464.801347526657945@ietfa.amsl.com> In-Reply-To: <162523075802.5464.801347526657945@ietfa.amsl.com> From: Andy Bierman Date: Fri, 2 Jul 2021 08:18:56 -0700 Message-ID: To: Shwetha Bhandari Cc: ops-dir@ietf.org, draft-ietf-netmod-nmda-diff.all@ietf.org, Last Call , NetMod WG Content-Type: multipart/alternative; boundary="000000000000063f8905c6257a83" Archived-At: Subject: Re: [netmod] Opsdir last call review of draft-ietf-netmod-nmda-diff-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 15:19:13 -0000 --000000000000063f8905c6257a83 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 2, 2021 at 5:59 AM Shwetha Bhandari via Datatracker < noreply@ietf.org> wrote: > Reviewer: Shwetha Bhandari > Review result: Has Nits > > I have reviewed this document as part of the Operational directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These > comments were written with the intent of improving the operational aspects > of > the IETF drafts. Comments that are not addressed in last call may be > included > in AD reviews during the IESG review. Document editors and WG chairs > should > treat these comments just like any other last call comments. > > Summary: > This is a Standards Track document that defines an RPC operation to compare > management datastores and returns diffs between the datastores as a > yang-patch. > > While most access management of the RPC, ensuring availability of the > server > by rate limiting are considered I have an open question to authors: > where/how > will operational metrics such as rate of requests received, errors, rate > limiting if applied, server resources consumed to process the request etc, > about this new RPC be defined and reported? This is useful information for > server operation where this RPC is enabled. > > There are no standard YANG objects to monitor the server resources. This new operation is likely to consume a lot of resources so I understand your concern. The actual diff results may depend on implementation choices and impact resources used. E.g. comparing 2 datastores that are constantly changing while they are being compared. I am not sure what changes to the draft are needed at this time. A resource monitoring module would be a generalized solution but it does not belong in this draft. Nits: > The RESTCONF example content-type is json but it is set to > application/yang-d > that is not present in the registry - should it be > application/yang-patch+json? > > I think it is supposed to be application/yang-data+json Andy --000000000000063f8905c6257a83 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jul 2, 2021 at 5:59 AM Shweth= a Bhandari via Datatracker <noreply@= ietf.org> wrote:
Reviewer: Shwetha Bhandari
Review result: Has Nits

I have reviewed this document as part of the Operational directorate's<= br> ongoing effort to review all IETF documents being processed by the IESG.=C2= =A0 These
comments were written with the intent of improving the operational aspects = of
the IETF drafts. Comments that are not addressed in last call may be includ= ed
in AD reviews during the IESG review.=C2=A0 Document editors and WG chairs = should
treat these comments just like any other last call comments.

=C2=A0Summary:
This is a Standards Track document that defines an RPC operation to compare=
management datastores and returns diffs between the datastores as a yang-pa= tch.

While=C2=A0 most access management of the RPC, ensuring availability of the= server
by rate limiting are considered I have an open question to authors: where/h= ow
will operational metrics such as rate of requests received, errors, rate limiting if applied, server resources consumed to process the request etc,<= br> about this new RPC be defined and reported? This is useful information for<= br> server operation where this RPC is enabled.



There are no standard Y= ANG objects to monitor the server resources.
This new operation i= s likely to consume a lot of resources so I understand your concern.
<= div>The actual diff results may depend on implementation choices and impact= resources used.
E.g. comparing 2 datastores that are constantly = changing while they are being compared.

I am not s= ure what changes to the draft are needed at this time.
A resource= monitoring module would be a generalized solution but it does
no= t belong in this draft.

Nits:
The RESTCONF example content-type is json but it is set to application/yang= -d
that is not present in the registry - should it be application/yang-patch+j= son?


I think it is supposed to be applicati= on/yang-data+json


Andy
= =C2=A0
--000000000000063f8905c6257a83-- From nobody Fri Jul 2 13:41:18 2021 Return-Path: <0100017a68f43151-49438f99-216e-4edd-ad55-03ba7e4686b1-000000@amazonses.watsen.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D003A0969 for ; Fri, 2 Jul 2021 13:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61z9eMKsuzRI for ; Fri, 2 Jul 2021 13:41:13 -0700 (PDT) Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 652003A0964 for ; Fri, 2 Jul 2021 13:41:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1625258471; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=BWiOfak4RGU0oY8sSHNK36mU+uUR5t28yjApyyekqlw=; b=iLgn6n+z2GJMhGVoipx47ojyMeD6RNdYS5l0SpbrJJrWHUOeVWh/BoKOLpRG4sIW 7t5pLvZZaD4UuThlwF8LHWWdnK0a7UTna45m9j/sqI6jUHyEGJ4x7gjP7jszZ8taMro Kq4IYl0xJNbo6UhfCUvSpufbiRPPCCRW9qBPrc+Q= From: Kent Watsen Message-ID: <0100017a68f43151-49438f99-216e-4edd-ad55-03ba7e4686b1-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F35A461E-43F8-4F03-84D6-E4ED64227F7D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Fri, 2 Jul 2021 20:41:11 +0000 In-Reply-To: Cc: "netmod@ietf.org" To: "maqiufang (A)" References: <38c3aa805f1846d0ad0e5ac67a82cfa1@huawei.com> <0100017a5501b507-02588bdb-c4c4-430f-9b53-39eefdfffe8b-000000@email.amazonses.com> <765757acb49741f7a64013b5525cdbb4@huawei.com> <0100017a59f81d52-dd739c93-2634-487f-a4c9-403f9d350c19-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3654.100.0.2.22) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.07.02-54.240.48.90 Archived-At: Subject: Re: [netmod] system configuration sync mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 20:41:16 -0000 --Apple-Mail=_F35A461E-43F8-4F03-84D6-E4ED64227F7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [Thanks for removing NETCONF from the CC] Hi Qiufang, > Right, the loopback interface is a common example but, more generally, = I think "resource-independent=E2=80=9D configuration might fall into = exactly two categories: > =20 > 1) config that is =E2=80=9Capplied=E2=80=9D immediately > - ex: interfaces/lo0/unit 0/family [ inet = inet6 ] > - ex: system/login/password/minimum-length=3D6 > - ex: system/ports/console-type=3Dvt100 > - ex: system/syslog/archive-size=3D256k; > - ex: = chassis/cluster/fabric-monitoring/heartbeat-interval=3D1000; > - ex: security/zones/security-zone/junos-host; > - ex: = security/alg/sip/inactive-media-timeout=3D120; > =20 > 2) config that is =E2=80=9Capplied=E2=80=9D only after = being referenced by other config (e.g., ACLs) > - ex: applications/ftp/=E2=80=A6 > - ex: applications/tftp/... > - ex: applications/smtp/=E2=80=A6 > - ex: utm/custom-objects/Adult_Material/... > - ex: utm/custom-objects/Religion/... > - ex: utm/custom-objects/Gambling/=E2=80=A6 > [Qiufang Ma] I don=E2=80=99t quite understand this kind of = configuration, could you please expand? Do you mean that the predefined = configurations for a certain application(e.g., ftp) will not take = effect until being referenced/enabled? For the second category, imagine containing some predefined = objects. These objects follow the standard data-model allowed by the = YANG. Operators could have defined these objects as well but, because = there may be hundreds of these objects, and the objects are the same for = everyone, the vendor decides to pre-define them as a convenience for = their customers. This way, operators only have to define custom objects = for what is unique in their environments. By example, imagine this in = : system-defined-defaults { applications { application ftp { protocol tcp; destination-port 21; } application tftp { protocol udp; destination-port 69; } application smtp { protocol tcp; destination-port 25; } ... } } And this in # custom objects applications { application my-app-1 { protocol tcp; destination-port 2345; } application my-app-2 { protocol udp; destination-port 69; } } // an ACL policy referencing both sys-defined and custom = objects policy from-zone untrust to-zone untrust { policy allow-external-access-to-foobar-app { match { source-address any; destination-address any; application [ ftp tftp, = my-app-1, my-app-2 ]; } then { permit; } } } Note that, by itself would not pass validation, due to missing = leafrefs. Thankfully, NMDA never says that validation runs on = . But once and have been merged, to become = , the result does pass validation. > I am wondering if these configuration will present in the = (which contains all the configuration actually used by the = device) before they=E2=80=99re referenced. I think that it would depend in the specific server=E2=80=99s behavior, = regarding if *unused* predefine objects are present in . = Certainly the unused objects would not have to be present in = . If I were implementing the server, the unused objects = would NOT be present in . > It would be good if we could determine if there are any other = "resource-independent=E2=80=9D configuration categories here. > [Qiufang Ma] Do you think there exists conditional system = configuration (if the preceding configurations you mentioned above is = not)? For example, if SSH is enabled on a device, SSH-related keys are = automatically generated. Such configurations are generated at the moment = when a special functionality is enabled. I=E2=80=99m unsure what you mean in general by "conditional = configuration=E2=80=9D, but I can speak to your specific example. Though = I must preface my comments that I imagine there are a number of ways = servers might go about enabling `sshd`. What follows is my personal = view, forged by being around systems for awhile ;) In general: - `sshd` is NOT enabled by default. - `sshd` is enabled via a configuration knob. - the SSH host key is dynamically generated the first time = `sshd` is enabled. - the SSH host key itself is in (not ) This view is consistent with the first paragraph in Section 3 of the = =E2=80=9Ckeystore=E2=80=9D draft (reproduced below): 3. Support for Built-in Keys In some implementations, a server may support built-in keys. = Built- in keys MAY be set during the manufacturing process or be = dynamically generated the first time the server is booted or a particular = service (e.g., SSH) is enabled. As a closing thought, this model (which I stated upfront may not be = universal) would have no presence-in or interaction-with = =E2=80=A6though, perhaps, there may be some predefined values = for what key-algorithms and/or key-lengths to use when generating the = SSH host key... > As for "resource-dependent=E2=80=9D configuration, I wonder how this = is supposed to work=E2=80=A6more specifically, I wonder to what extent = the IETF needs to care how if works (perhaps the same could be said for = "resource-independent=E2=80=9D configuration too). For instance, in = JUNOS, there exists a config-template that is automatically applied to = any user-defined interface, such as: > =20 > junos-default-profile { > interfaces { > "$junos-interface-ifd-name" { > unit "$junos-underlying-interface-unit" { > family inet; > family inet6; > } > } > } > } >=20 > Notably, RFC 8342 mentions templates as something that might be = expanded when converting to . Actually, knowing = that it is that is subject to validation, it seems that much = (if not all) of should be consumed when converting to = - agreed?=20 > [Qiufang Ma] Do you mean that should include the system = configuration which is generated due to the expansion of templates? I = notice that RFC8342 says in sec.4.1 > =E2=80=9COne of the observations: > Some implementations have proprietary mechanisms that allow > clients to define configuration templates in . These > templates are expanded automatically by the system, and the > resulting configuration is applied internally.=E2=80=9D > So I am wondering whether the system-predefined config-template would = be present in the and updating through performed = template-expansion. > My understanding is that if the config-template is configured in = , the expanded configuration in the should still be = the client configuration. > If the template is preconfigured by the system, the configuration = generated through performed template-expansion should be only present in = the if not explicitly re-configured in by the = client. Firstly, I again have to preface my comment that there are likely many = ways that templating mechanisms can be defined. But, in general, once = a templating mechanism has been defined, then it stands to reason that = templates could be defined either in (by operators) or in = (by the manufacturer). In one implementation I=E2=80=99m = familiar with, the templates are objects that are = referenced/parameterized by other parts of the configuration. (Same as = with the predefined objects discussion above.) =20 To answer your questions: 1) Yes, it is my opinion that *activated* templates in will be = expanded and present in . 2) I would never suggest that the system-defined templates are present = in , though they may be referenced/parameterized by config in = . 3) if a config-template is configured in (i.e., it is = operator-defined) then, yes, the expanded configuration in is = "client configuration=E2=80=9D (note, "client configuration=E2=80=9D is = not a formal term). That said, it seems fair to say that a template = defined in and then referenced by "client configuration=E2=80=9D = in is also expanded as "client configuration=E2=80=9D in = . 4) I don=E2=80=99t not understand your last sentence, that the expansion = of templates are only present in . Maybe you=E2=80=99= re saying something subtle, e.g., that servers currently don=E2=80=99t = support GET on . But, in theory, the expansion of = templates should (IMO) be present in , so that they may be = subject to validation. Of course, all the configuration = (whether originating in or ) that is successfully = =E2=80=9Capplied=E2=80=9D will also be present in . > I=E2=80=99m beginning to think that: > =C2=B7 auto-copying into is likely never a good = idea, because it violates the definition of > [Qiufang Ma] I am quite aware that different datastores in NMDA = represents different views of data nodes. And represents a = configuration datastore holding the current configuration of the device. > Should we consider system configuration also be part of current = configuration of the device? =46rom my perspective, the difference = between system configuration and client-configuration lies only in who = provides it. holds the current *operator-specified* configuration of the = device. System-provided configuration is NOT specified by operators = (though system-defined objects may be referenced by operator-specified = config in ). I believe that this arrangement is consistent = with the definition of . Agreed? > =C2=B7 having in doesn=E2=80=99t make sense, = since the tweaks wouldn=E2=80=99t go thru --> = validation. > =20 > I=E2=80=99m wondering if a model like below would work for everyone - = thoughts? > [Qiufang Ma] represents the configuration after all = configuration transformations to have been performed, so I = think it is only coupled to . > Anyway, the should also interacts with . = Agreed? I don=E2=80=99t agree that must only be coupled to . = Specifically, I think that it is okay (compatible with NMDA) to define = a that also impacts . This is the only (IMO) sane = approach, as it enables the combination + to be = validated. > =20 > Best Regards, > Qiufang Ma Cheers, Kent // contributor --Apple-Mail=_F35A461E-43F8-4F03-84D6-E4ED64227F7D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[Thanks for removing NETCONF from the CC]

Hi Qiufang,


<snip>
Right, the loopback = interface is a common example but, more generally, I think = "resource-independent=E2=80=9D configuration might fall into exactly two = categories:
 
        &= nbsp;   1) config that is = =E2=80=9Capplied=E2=80=9D immediately
        &= nbsp;           &nb= sp;   -= ex: interfaces/lo0/unit 0/family [ inet inet6 ]
        &= nbsp;           &nb= sp;   -= ex: system/login/password/minimum-length=3D6
        &= nbsp;           &nb= sp;   -= ex: system/ports/console-type=3Dvt100
        &= nbsp;           &nb= sp;   - ex: system/syslog/archive-size=3D256k;
        &= nbsp;           &nb= sp;   -= ex: chassis/cluster/fabric-monitoring/heartbeat-interval=3D1000;
          &nb= sp;            = ; - ex: = security/zones/security-zone/junos-host;
          &nb= sp;            = ; - ex: = security/alg/sip/inactive-media-timeout=3D120;
 
        &= nbsp;   2) config that is = =E2=80=9Capplied=E2=80=9D only after being referenced by other config = (e.g., ACLs)
        &= nbsp;           &nb= sp;   -= ex: applications/ftp/=E2=80=A6
          &nb= sp;            = ; - ex: applications/tftp/...
          &nb= sp;            = ; - ex: applications/smtp/=E2=80=A6
          &nb= sp;            = ; - ex: utm/custom-objects/Adult_Material/...
          &nb= sp;            = ; - ex: utm/custom-objects/Religion/...
          &nb= sp;            = ; - ex: utm/custom-objects/Gambling/=E2=80=A6
[Qiufang Ma] I don=E2=80=99t quite understand this kind of = configuration, could you please expand? Do you mean that the predefined = configurations  for a certain application(e.g., ftp) will not take = effect until being = referenced/enabled?


For the second category, imagine <system> = containing some predefined objects.  These objects follow the = standard data-model allowed by the YANG.  Operators could have = defined these objects as well but, because there may be hundreds of = these objects, and the objects are the same for everyone, the vendor = decides to pre-define them as a convenience for their customers. =  This way, operators only have to define custom objects for what is = unique in their environments.    By example, imagine this in = <system>:

= system-defined-defaults {
= applications {
application ftp = {
protocol = tcp;
= destination-port 21;
= }
application tftp = {
protocol = udp;
= destination-port 69;
= }
application smtp = {
protocol = tcp;
= destination-port 25;
= }
...
=  }
}

And this in <running>

# custom = objects
applications {
= application my-app-1 {
= protocol tcp;
= destination-port 2345;
}
= application my-app-2 {
protocol = udp;
= destination-port 69;
= }
 }

= // an ACL policy referencing both sys-defined and custom = objects
= policy from-zone untrust to-zone untrust {
= policy allow-external-access-to-foobar-app {
= match {
= source-address any;
= destination-address any;
= application [ ftp tftp, my-app-1, my-app-2 ];
= }
= then {
= permit;
= }
= }
}


Note that, <running> by = itself would not pass validation, due to missing leafrefs. =  Thankfully, NMDA never says that validation runs on = <running>.  But once <running> and <system> have = been merged, to become <intended>, the result does pass = validation.


I am wondering if these configuration will = present in the <operational> (which contains all the configuration = actually used by the device) before they=E2=80=99re = referenced.
=

I think that it would depend = in the specific server=E2=80=99s behavior, regarding if *unused* = predefine objects are present in <operational>.  Certainly = the unused objects would not have to be present in <operational>. =  If I were implementing the server, the unused objects would NOT be = present in <operational>.



It would be good if we could determine if there = are any other "resource-independent=E2=80=9D configuration categories = here.
[Qiufang Ma] Do you think there exists conditional system = configuration (if the preceding configurations you mentioned above is = not)? For example, if SSH is enabled on a device, SSH-related keys are = automatically generated. Such configurations are generated at the moment = when a special functionality is = enabled.

I=E2=80=99m unsure what you mean in = general by "conditional configuration=E2=80=9D, but I can speak to your = specific example. Though I must preface my comments that I imagine there = are a number of ways servers might go about enabling `sshd`.  What = follows is my personal view, forged by being around systems for awhile =  ;)

In general:

- `sshd` is NOT enabled by = default.
- `sshd` is enabled via a = configuration knob.
- the SSH host key is dynamically = generated the first time `sshd` is enabled.
- the SSH = host key itself is in <operational> (not = <running>)

This view is = consistent with the first paragraph in Section 3 of the =E2=80=9Ckeystore=E2= =80=9D draft (reproduced below):

3. =  Support for Built-in Keys

=    In some implementations, a server may support = built-in keys.  Built-
  =  in keys MAY be set during the manufacturing process or be = dynamically
   generated the first = time the server is booted or a particular service
=    (e.g., SSH) is enabled.

As a closing thought, this model = (which I stated upfront may not be universal) would have no presence-in = or interaction-with <system>=E2=80=A6though, perhaps, there may be = some predefined values for what key-algorithms and/or key-lengths to use = when generating the SSH host key...



As for "resource-dependent=E2=80=9D configuration, I = wonder how this is supposed to work=E2=80=A6more specifically, I wonder = to what extent the IETF needs to care how if works (perhaps the same = could be said for "resource-independent=E2=80=9D configuration = too).  For instance, in JUNOS, there exists a config-template that = is automatically applied to any user-defined interface, such = as:
 

  =   junos-default-profile {
      =   interfaces {
        =     "$junos-interface-ifd-name" {
  =               unit = "$junos-underlying-interface-unit" {
      =               family inet;
                =     family inet6;
      =           }
    =         }
      =   }
    }

Notably, RFC 8342 mentions templates as = something that might be expanded when converting <running> to = <intended>.  Actually, knowing that it is <intended> = that is subject to validation, it seems that much (if not all) of = <system> should be consumed when = converting <running> to <intended> - = agreed? 
[Qiufang Ma] Do you mean that =  <intended> should include the system configuration which is = generated due to the expansion of templates?  I notice that RFC8342 = says in sec.4.1
=E2=80=9COne of the = observations:
Some implementations = have proprietary mechanisms that allow
clients to define configuration templates in = <running>.  These
templates are expanded automatically by the system, and = the
resulting configuration is applied internally.=E2=80=9D
So I am wondering whether the system-predefined = config-template would be present in the <running> and updating = <intended>  through performed template-expansion.
My understanding is that if the config-template is configured = in <running>, the expanded configuration in the <intended> = should still be the client configuration.
If the template is preconfigured by the system, the = configuration generated through performed template-expansion should be = only present in the <operational> if not explicitly re-configured = in <running> by the = client.

Firstly, I again have to preface my comment that = there are likely many ways that templating mechanisms can be defined. =    But, in general, once a templating mechanism has been = defined, then it stands to reason that templates could be defined either = in <running> (by operators) or in <system> (by the = manufacturer).  In one implementation I=E2=80=99m familiar = with, the templates are objects that are = referenced/parameterized by other parts of = the configuration.  (Same as = with the predefined objects discussion above.)  

To = answer your questions:

1) Yes, = it is my opinion that *activated* templates in <system> will be = expanded and present in <intended>.

2) I would never suggest that the = system-defined templates are present in <running>, though they may = be referenced/parameterized by config in = <running>.

3) if a config-template is configured in = <running> (i.e., it is operator-defined) then, yes, the expanded = configuration in <intended> is "client configuration=E2=80=9D = (note, "client configuration=E2=80=9D is not a formal term).  That = said, it seems fair to say that a template defined in <system> and = then referenced by "client configuration=E2=80=9D in <running> is = also expanded as "client configuration=E2=80=9D in = <intended>.

4) I don=E2=80=99t not understand your last = sentence, that the expansion of <system> templates are = only present in <operational>.  Maybe you=E2=80=99re = saying something subtle, e.g., that servers currently don=E2=80=99t = support GET on <intended>.  But, in theory, the expansion of = <system> templates should (IMO) be present in <intended>, so = that they may be subject to validation.   Of course, all the = <intended> configuration (whether originating in <running> = or <system>) that is successfully =E2=80=9Capplied=E2=80=9D = will also be present in <operational>.


<big snip>
I=E2=80=99m beginning to think = that:
=C2=B7         auto-cop= ying into <running> is likely never a good idea, because it = violates the definition of <running>
[Qiufang Ma] I am quite = aware that different datastores in NMDA represents different views of = data nodes.  And <running> represents a configuration = datastore holding the current configuration of the device.
Should we consider system configuration also be part of = current configuration of the device? =46rom my perspective, the = difference between system configuration and  client-configuration = lies only in who provides = it.

<running> holds the current = *operator-specified* configuration of the device.  System-provided = configuration is NOT specified by operators (though system-defined = objects may be referenced by operator-specified config in = <running>).   I believe that this arrangement is consistent = with the definition of <running>.  Agreed?


=C2=B7         having = in <operational> doesn=E2=80=99t make sense, since the tweaks = wouldn=E2=80=99t go thru <running> --> <intended> = validation.
 
I=E2=80=99m wondering if a model like = below would work for everyone - thoughts?
[Qiufang Ma] = <intended> represents the configuration after all configuration = transformations to <running> have been performed, so I think it is = only coupled to <running>.
Anyway, the <system> should also interacts with = <operational>. =  Agreed?

I don=E2=80=99t agree that <intended> = must only be coupled to <running>.  Specifically, I think = that it is okay (compatible with NMDA) to define a <system> that = also impacts <intended>.   This is the only (IMO) sane = approach, as it enables the combination <running> + <system> = to be validated.



 
Best Regards,
Qiufang = Ma

Cheers,
Kent // contributor


= --Apple-Mail=_F35A461E-43F8-4F03-84D6-E4ED64227F7D-- From nobody Fri Jul 2 15:03:50 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DC93A08DC; Fri, 2 Jul 2021 15:02:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: netmod@ietf.org, rwilton@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162526337197.26814.11520855575715474628@ietfa.amsl.com> Date: Fri, 02 Jul 2021 15:02:51 -0700 Archived-At: Subject: [netmod] netmod - Requested session has been scheduled for IETF 111 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 22:02:56 -0000 Dear Lou Berger, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. netmod Session 1 (1:00 requested) Tuesday, 27 July 2021, Session II 1430-1530 Room Name: Room 6 size: 506 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/111/sessions/netmod.ics Request Information: --------------------------------------------------------- Working Group Name: Network Modeling Area Name: Operations and Management Area Session Requester: Lou Berger Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 100 Conflicts to Avoid: People who must be present: Joel Jaeggli Kent Watsen Lou Berger Robert Wilton Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Jul 4 15:13:48 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEEB3A246F; Sun, 4 Jul 2021 15:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BA-2aMhl7bxX; Sun, 4 Jul 2021 15:13:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C6F3A2470; Sun, 4 Jul 2021 15:13:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 97EBA38B00; Sun, 4 Jul 2021 18:15:52 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2NqAVb3zxJyK; Sun, 4 Jul 2021 18:15:48 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id ECC2F38AAB; Sun, 4 Jul 2021 18:15:47 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DB80D4B6; Sun, 4 Jul 2021 18:13:25 -0400 (EDT) From: Michael Richardson To: anima@ietf.org, "Rob Wilton \(rwilton\)" cc: "netmod\@ietf.org" , Juergen Schoenwaelder In-Reply-To: References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2021 22:13:38 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I have converted RFC8366.xml to Markdown, and switched to the latest MT makefile, and after a bit of small massage to remove "8366" from the page, and point to RFCs which are published, the result is at: https://www.ietf.org/rfcdiff?url1=3Drfc8366&url2=3Ddraft-richardson-anima-r= fc8366bis.txt Rob Wilton (rwilton) wrote: Rob> More seriously though, this can't be done as an errata. Rob> An RFC8366bis is the right option. If the changes are minor then I Rob> may be able to ease the passage through the IESG, but I can't do Rob> much to affect the elapsed time. I propose that the WG adopt this as the -00, and then we change the document to change this into an RFC7224-style IANA-maintained YANG module. (In DHC WG, when we did RFC3315bis to make RFC8415 we did a -00 which was whitespace equivalent to RFC3315 first, and then we amended it) As I understand it, we would be creating a Registry with IANA Consideration= s, and when documents extend the Registry, that IANA writes a new YANG module (with a new date) for us. I believe that given that the module gets revised, that we don't have to worry about enumeration vs leaf/choice/empty. But, if there is some advantage to doing it the non-enumeration way, it would be good to understa= nd that. I also think that in our enumeration/Registry, that we should include the "value" parameter, so that constrained-voucher can consistently set values even if the enumeration changes order. Subject: New Version Notification for draft-richardson-anima-rfc8366bis-00.= txt Date: Sun, 04 Jul 2021 15:03:18 -0700 A new version of I-D, draft-richardson-anima-rfc8366bis-00.txt has been successfully submitted by Michael C. Richardson and posted to the IETF repository. Name: draft-richardson-anima-rfc8366bis Revision: 00 Title: A Voucher Artifact for Bootstrapping Protocols Document date: 2021-07-04 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/archive/id/draft-richardson-anima-rfc8= 366bis-00.txt Status: https://datatracker.ietf.org/doc/draft-richardson-anima-rfc= 8366bis/ Html: https://www.ietf.org/archive/id/draft-richardson-anima-rfc8= 366bis-00.html Htmlized: https://datatracker.ietf.org/doc/html/draft-richardson-anim= a-rfc8366bis =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDiMoUACgkQgItw+93Q 3WW7Sgf+NtBp7MIvWQHNUKJb1loX9a6aA7e9HrZz1B86Dez82u7/rQOxcs18eWx3 xIbzeOeJaYjf9mxGZfbc8C3A3KCav/lpgpuos/f1+EU8eNTBQnqlgOHunBDP55r8 3vGesPngI/5o4zsSC/QlChc8qTZtxRXTfqVYQNHNaI44bSPWRYF5xgxhAVrFW12j 3sai+UbIZ1xktjSmzaGp0wz78NLeGtpna0oUShcaJ/XYjgtxIzElyP+d/GzNVoUB u8mvs+B3DJ6+/Te2T/quh1BYy9kUDJkHREnn4WKYEbVagRrcVmbubluPIe/qFd9c 0Vq+hu5KyAfAQNBWTWubHmuIYe8c9g== =UoUP -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 4 15:17:35 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D023A24B0; Sun, 4 Jul 2021 15:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec-RrcgV4sXy; Sun, 4 Jul 2021 15:17:25 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20ED23A24AD; Sun, 4 Jul 2021 15:17:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8FB6338B10; Sun, 4 Jul 2021 18:19:44 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nEgyaik93mkj; Sun, 4 Jul 2021 18:19:40 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8250C38AAB; Sun, 4 Jul 2021 18:19:40 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5665F4B6; Sun, 4 Jul 2021 18:17:18 -0400 (EDT) From: Michael Richardson To: "Fries\, Steffen" , "Rob Wilton \(rwilton\)" , "anima\@ietf.org" , "netmod\@ietf.org" , Toerless Eckert , Kent Watsen In-Reply-To: References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> <27560.1625013411@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2021 22:17:30 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Fries, Steffen wrote: >> I thought I wrote a really nice ASCII art version of what documents = inherit from >> RFC8366. I can't find it in my outbox... I wonder if I nuked the dr= aft by mistake. >> >> The short of it: >> RFC8366 -> RFC8995 (voucher-request) -> constrained-voucher (voucher-request, voucher) -> brski-async-enroll (voucher-request) > Would it make sense to also state the voucher for BRSKI-AE as it also > uses the voucher and tries to argue for a new assertion type > (agent-proximity)? I am of two feelings here. On the one hand, it would be IANA proceedurally simpler to include the new assertion type into the 8366bis document. On the other hand, this means having some kind of explanation in RFC8366bis for the new choice, and that might force a lot of text to enter and get rev= iewed. Once RFC8366bis is published, then async-enroll can make use of the IANA Considerations to allocate that new enum value. That won't slow async-enro= ll down, because either way, it has to wait for RFC8366bis. Where I'm a bit blurry is how stuff like the YANG in RFC8995, which uses RFC8366 gets updated when IANA revises the module. I think, it mostly doesn't matter because none of are generating code from YANG... AT THIS TIM= E. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDiM20ACgkQgItw+93Q 3WWcFgf+MogbnuQ4dIYWK9xscBdg7whmyYdUSZwMtdhxzny4V2O5oHYjCcBTq/Hw GpEIHwFu6QvEbl7N9Y0zdB5TkXxgdXCboTkqbKzTdRKipp36S407ChJoVbp4NEZ6 +u1JuCb3MzVP2NsQ+OP4Q70/LCb8RN8fNCNvHTefthPQNzid8+NspSlqWr+/20aE P8deDGlmBeY95OPl5KxfQR/Ldibfs2YY427Nfv5Qi0dXIP5kIZa4fW/e6tdqLBTL swORtMRy73ewhiZ1vz6TNWfufBmLwpe3KkGGQP/7gs/UbZNEj5+JX8at1VYGhcMS ZqF4P5q0dFWtK6UdETHZspvePN19tw== =d+E0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 4 16:21:14 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 745783A28BF; Sun, 4 Jul 2021 16:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TC0SZicEoINF; Sun, 4 Jul 2021 16:21:08 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC243A28BA; Sun, 4 Jul 2021 16:21:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 60E6B38B00; Sun, 4 Jul 2021 19:23:27 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gojLAtENy6SF; Sun, 4 Jul 2021 19:23:24 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1640738AFD; Sun, 4 Jul 2021 19:23:24 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E7831319; Sun, 4 Jul 2021 19:21:01 -0400 (EDT) From: Michael Richardson to: anima@ietf.org, "Rob Wilton \(rwilton\)" , Juergen Schoenwaelder , "netmod\@ietf.org" In-Reply-To: <10907.1625436805@localhost> References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> <10907.1625436805@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2021 23:21:13 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > I propose that the WG adopt this as the -00, and then we change the d= ocument > to change this into an RFC7224-style IANA-maintained YANG module. > (In DHC WG, when we did RFC3315bis to make RFC8415 we did a -00 which= was > whitespace equivalent to RFC3315 first, and then we amended it) > As I understand it, we would be creating a Registry with IANA Conside= rations, > and when documents extend the Registry, that IANA writes a new YANG m= odule > (with a new date) for us. > I believe that given that the module gets revised, that we don't have= to > worry about enumeration vs leaf/choice/empty. But, if there is some > advantage to doing it the non-enumeration way, it would be good to un= derstand > that. But, we might want to do a WG Consensus call on the differences. We might also want to ask a YANG Doctor to come to the ANIMA WG meeting at the end of the Month, to explain the differences. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDiQl0ACgkQgItw+93Q 3WVhmgf+LcgeNWPVIWGmoPf6o8ybPo0WFLM0PSljxGWVbUTa34+eb7Dy4VXEdeMg XTH8qtpBDflXvf6yap7u9VbnrMjt+QJaz3SI3B++ciDi8Xdhcf7oFwhmo3X62ptA QT3OuLjrrLN5bTfyLgIAB/bhxZLwJvDOdhFFK8bdduwa+mZeMz/s0Wbj3rYQqs6X ZXdGU1c5rO7VElVTBp0RH2kdoYQ47VXl4o5jCOh53CcbtAQAjKGacF6i8f4XWcBw 71B5aSvv6QXJtRt7JUBvsiFvUJ+7O+fkq4b6k6cY0dSiIRYRQSFpz8UyANsxg2BH JyXuMDTVhd/72DFCRbMwD88blb5bhA== =sm+P -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 5 02:38:12 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9EE3A0CF2; Mon, 5 Jul 2021 02:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 eRu0G0QAvw5t; Mon, 5 Jul 2021 02:38:03 -0700 (PDT) Received: from gw-eagle1.siemens.com (gw-eagle1.siemens.com [194.138.20.72]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C913A0CD8; Mon, 5 Jul 2021 02:38:02 -0700 (PDT) Received: from mail1.dc4ca.siemens.de (mail1.dc4ca.siemens.de [139.25.224.78]) by gw-eagle1.siemens.com (Postfix) with ESMTPS id 490F34F0264; Mon, 5 Jul 2021 11:38:00 +0200 (CEST) Received: from DEMCHDC8A0A.ad011.siemens.net (demchdc8a0a.ad011.siemens.net [139.25.226.106]) by mail1.dc4ca.siemens.de (Postfix) with ESMTPS id C3DA81A5714E3; Mon, 5 Jul 2021 11:37:58 +0200 (CEST) Received: from DEMCHDC89XA.ad011.siemens.net (139.25.226.103) by DEMCHDC8A0A.ad011.siemens.net (139.25.226.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Mon, 5 Jul 2021 11:37:58 +0200 Received: from DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) by DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) with mapi id 15.01.2176.014; Mon, 5 Jul 2021 11:37:58 +0200 From: "Fries, Steffen" To: Michael Richardson , "Rob Wilton (rwilton)" , "anima@ietf.org" , "netmod@ietf.org" , Toerless Eckert , Kent Watsen Thread-Topic: [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? Thread-Index: AQHXcSJZCevmeqNnhUCF3zrB5xtXJqs0EVgg Date: Mon, 5 Jul 2021 09:37:57 +0000 Message-ID: <46808a908497458db93ccbf16b8f0dd2@siemens.com> References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> <27560.1625013411@localhost> <11899.1625437038@localhost> In-Reply-To: <11899.1625437038@localhost> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2021-07-05T09:37:56Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=f48ed91c-279b-4b2f-9da4-7efba7aef191; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0 document_confidentiality: Restricted x-originating-ip: [139.21.146.182] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 09:38:08 -0000 PiBGcm9tOiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT4NCj4gU2Vu dDogTW9udGFnLCA1LiBKdWxpIDIwMjEgMDA6MTcNCj4gRnJpZXMsIFN0ZWZmZW4gPHN0ZWZmZW4u ZnJpZXNAc2llbWVucy5jb20+IHdyb3RlOg0KPiAgICAgPj4gSSB0aG91Z2h0IEkgd3JvdGUgYSBy ZWFsbHkgbmljZSBBU0NJSSBhcnQgdmVyc2lvbiBvZiB3aGF0IGRvY3VtZW50cyBpbmhlcml0DQo+ IGZyb20NCj4gICAgID4+IFJGQzgzNjYuICBJIGNhbid0IGZpbmQgaXQgaW4gbXkgb3V0Ym94Li4u IEkgd29uZGVyIGlmIEkgbnVrZWQgdGhlIGRyYWZ0IGJ5DQo+IG1pc3Rha2UuDQo+ICAgICA+Pg0K PiAgICAgPj4gVGhlIHNob3J0IG9mIGl0Og0KPiAgICAgPj4gUkZDODM2NiAtPiBSRkM4OTk1ICh2 b3VjaGVyLXJlcXVlc3QpDQo+ICAgICAtPiBjb25zdHJhaW5lZC12b3VjaGVyICh2b3VjaGVyLXJl cXVlc3QsIHZvdWNoZXIpDQo+ICAgICAtPiBicnNraS1hc3luYy1lbnJvbGwgKHZvdWNoZXItcmVx dWVzdCkNCj4gDQo+ICAgICA+IFdvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gYWxzbyBzdGF0ZSB0aGUg dm91Y2hlciBmb3IgQlJTS0ktQUUgYXMgaXQgYWxzbw0KPiAgICAgPiB1c2VzIHRoZSB2b3VjaGVy IGFuZCB0cmllcyB0byBhcmd1ZSBmb3IgYSBuZXcgYXNzZXJ0aW9uIHR5cGUNCj4gICAgID4gKGFn ZW50LXByb3hpbWl0eSk/DQo+IA0KPiBJIGFtIG9mIHR3byBmZWVsaW5ncyBoZXJlLg0KPiBPbiB0 aGUgb25lIGhhbmQsIGl0IHdvdWxkIGJlIElBTkEgcHJvY2VlZHVyYWxseSBzaW1wbGVyIHRvIGlu Y2x1ZGUgdGhlIG5ldw0KPiBhc3NlcnRpb24gdHlwZSBpbnRvIHRoZSA4MzY2YmlzIGRvY3VtZW50 Lg0KPiANCj4gT24gdGhlIG90aGVyIGhhbmQsIHRoaXMgbWVhbnMgaGF2aW5nIHNvbWUga2luZCBv ZiBleHBsYW5hdGlvbiBpbiBSRkM4MzY2YmlzDQo+IGZvciB0aGUgbmV3IGNob2ljZSwgYW5kIHRo YXQgbWlnaHQgZm9yY2UgYSBsb3Qgb2YgdGV4dCB0byBlbnRlciBhbmQgZ2V0IHJldmlld2VkLg0K PiANCj4gT25jZSBSRkM4MzY2YmlzIGlzIHB1Ymxpc2hlZCwgdGhlbiBhc3luYy1lbnJvbGwgY2Fu IG1ha2UgdXNlIG9mIHRoZSBJQU5BDQo+IENvbnNpZGVyYXRpb25zIHRvIGFsbG9jYXRlIHRoYXQg bmV3IGVudW0gdmFsdWUuICBUaGF0IHdvbid0IHNsb3cgYXN5bmMtZW5yb2xsDQo+IGRvd24sIGJl Y2F1c2UgZWl0aGVyIHdheSwgaXQgaGFzIHRvIHdhaXQgZm9yIFJGQzgzNjZiaXMuDQpZZXMgdHJ1 ZS4gSGF2aW5nIHRoZSBvcHRpb24gZG9pbmcgaXQgdmlhIGFuIElBTkEgY29uc2lkZXJhdGlvbnMg d2lsbCBiZSBzaW1wbGVyIGZvciBvdGhlciBkcmFmdHMgbGlrZSBhc3luYy1lbnJvbGwgZXh0ZW5k aW5nIHRoZSBhc3NlcnRpb25zIGluIHRoZSB2b3VjaGVyLiANCg0KPiBXaGVyZSBJJ20gYSBiaXQg Ymx1cnJ5IGlzIGhvdyBzdHVmZiBsaWtlIHRoZSBZQU5HIGluIFJGQzg5OTUsIHdoaWNoIHVzZXMN Cj4gUkZDODM2NiBnZXRzIHVwZGF0ZWQgd2hlbiBJQU5BIHJldmlzZXMgdGhlIG1vZHVsZS4gIEkg dGhpbmssIGl0IG1vc3RseSBkb2Vzbid0DQo+IG1hdHRlciBiZWNhdXNlIG5vbmUgb2YgYXJlIGdl bmVyYXRpbmcgY29kZSBmcm9tIFlBTkcuLi4gQVQgVEhJUyBUSU1FLg0KPiANCj4gLS0NCj4gTWlj aGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+ICAgLiBvIE8gKCBJUHY2IEnD uFQgY29uc3VsdGluZyApDQo+ICAgICAgICAgICAgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzIElu YywgT3R0YXdhIGFuZCBXb3JsZHdpZGUNCj4gDQo+IA0KPiANCg0K From nobody Mon Jul 5 03:53:51 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9473A1277; Mon, 5 Jul 2021 03:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.534 X-Spam-Level: X-Spam-Status: No, score=-4.534 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foSF4rgP_2o9; Mon, 5 Jul 2021 03:53:44 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 571543A125F; Mon, 5 Jul 2021 03:53:44 -0700 (PDT) Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GJMlx60Vjz6G8D7; Mon, 5 Jul 2021 18:45:33 +0800 (CST) Received: from [10.47.68.107] (10.47.68.107) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Mon, 5 Jul 2021 12:53:31 +0200 To: "Rob Wilton (rwilton)" , "netmod@ietf.org" , "draft-ietf-netconf-notification-capabilities@ietf.org" CC: NetMod WG Chairs References: From: Benoit Claise Message-ID: Date: Mon, 5 Jul 2021 12:53:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------017B1888E4A5F1504A8F33F7" Content-Language: en-GB X-Originating-IP: [10.47.68.107] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To fraeml736-chm.china.huawei.com (10.206.15.217) X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netconf-notification-capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 10:53:50 -0000 --------------017B1888E4A5F1504A8F33F7 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hi Rob, Thanks for your detailed review. A new draft version has been posted. URL:https://www.ietf.org/archive/id/draft-ietf-netconf-notification-capabilities-17.txt Status:https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/ Htmlized:https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-17 See the justifications below. On 6/21/2021 10:45 AM, Rob Wilton (rwilton) wrote: > Hi, > > Here is my AD review of draft-ietf-netconf-notification-capabiltiies-16 > > Thanks for this draft, sorry for the delay in reviewing. It looks like it is in good shape. > > I think that most of my comments are minor or cosmetic suggestions to potentially improve the phrasing of the text. > > > 1. > Abstract: > > The module "ietf-system-capabilities" provides a placeholder > structure that can be used to discover YANG related system > capabilities for servers. The module can be used to report > capability information from the server at run-time or implementation- > time, per the YANG Instance Data File Format. > > Suggest "by making use of" rather than "per". DONE. > > > 2. > 1. Introduction > > There is a need to publish this capability information as it is part > of the contract between the server and client. > > Suggest "contract" -> "API contract". DONE > > > 3. > There is a need to publish this capability information as it is part > of the contract between the server and client. Examples include > maximum size of data that can be stored or transferred, information > about counters (whether a node supports "on-change" telemetry), etc. > Such capabilities are often dependent on a vendor's implementation or > the available resources at deployment. Many such capabilities are > specific to either the complete system, individual YANG datastores > [RFC8342] or specific parts of the YANG schema, or even individual > data nodes. It is a goal of this document to provide a common way of > representing such capabilities in a format that is: > > Suggest: maximum -> the maximum > "or specific" -> ", specific" DONE > > > 4. > o available in identical format both at implementation-time and run- > time > > Suggest: "in an identical", and a period at the end. DONE > > > 5. > If the information is > not documented in a way available to the NMS designer, but only as > instance data from the network node once it is deployed, the NMS > implementation will be delayed > > Suggest: "way available" => "way that is readily available" DONE > > > 6. > The network operator needs to plan his > management practices and NMS implementation before he even decides to > buy the specific network node type. > > Suggest: "him" -> "their", "he even decides" -> "they decide" DONE > > > 7. > Run-time information is needed: > > Suggest: Run-time capability information is needed: DONE. > > > 8. > o to check that capability information provided earlier, at > implementation-time is what the publisher has implemented. > > Suggest: "at implementation-time, is" DONE > > > 9. > To find a capability value for a specific data node in a > specific datastore the user SHALL: > > Please clarify that the capability value is selected by the relative path > to the datanode defining the capability. i.e., the same name/path must be > used both under the system level and per datastore level capabilties. NEW SENTENCE. "When stating a specific capability, the relative path for any specific capability must be the same under the system-capabilities container and under the per-node-capabilities list: the same grouping for defining the capabilities MUST be used. " > 10. > 2) If the datastore entry is found within that entry, process all > per-node-capabilities entries in the order they appear in the list. > The first entry that specifies the specific capability and has a > node-selector selecting the specific data node defines the > capability value. > > I'm not sure this is required, but perhaps consider adding text to make it clear > that longest path matching can be achieved by ordering more specific > matches before less specific matches. ADDED "Note that longest path matching can be achieved by ordering more specific matches before less specific ones" under list per-node-capabilities { description "Each list entry specifies capabilities for the selected data nodes. The same capabilities apply for the data nodes in the subtree below the selected nodes. The system SHALL order the entries according to their precedence. The order of the entries MUST NOT change unless the underlying capabilities also change."; We did NOT add next to "2) If the datastore entry is found within that entry ..." because that section focuses on the user (as opposed to the implementer on the server), as mentioned in "To find a capability value for a specific data node in a specific datastore the user SHALL:" > > > 11. > // augmentation point for system level capabilities > Suggest: "Augmentation ... capabilities." I would also suggest using a block style > comment so this doesn't get lost. DONE. > > > 12. > Only one specific datastore can be specified > e.g., ds:conventional is not allowed."; > > Suggest changing to: > > Only specific datastores can be specified. > E.g., ds:conventional, which represents a > set of configuration datastores, must not be > used"; DONE > > > 13. > description > "A method to select all or some nodes within a datastore."; > > "some or all" would flow better. DONE > > > 14. > // augmentation point for datastore or data node level > // capabilities > > Suggest: "Augmentation ... capabilities." I would also suggest using a block style > comment so this doesn't get lost. DONE. > > > 15. > 5.2. YANG Module (ietf-notification-capabilities) > > - capabilities related to the throughput of notification data > the publisher can support. (Note that for a specific > subscription the publisher MAY still allow only longer periods > or smaller updates depending on e.g., actual load conditions.) > > Suggest: "data that the publisher" > "specific subscription, the" > "still allow" -> "allow" > "e.g., -> ", e.g., " DONE. > > > > 16. > bit config-changes { > description > "The publisher is capable of sending > notifications for 'config false' nodes for the > relevant scope and subscription type."; > > I presume that this should this be 'config true' nodes? GOOD CATCH+ > > > 17. > description > "Type for defining whether 'on-change' or > 'periodic' notifications are supported 'config false' > data nodes, 'config true' date nodes, no data nodes, > or all data nodes. > > Suggest: "supported for 'config false'", > "date" -> "data > As an optional minor nit, it might be worth putting 'all' at the beginning > of the list rather than the end. DONE. > > > 18. > "Indicates the minimal update period that is > supported for a 'periodic' subscription. > > A subscription request to the selected data > nodes with a smaller period than what this leaf > specifies will result in a 'period-unsupported' error."; > > Is "will result" right here, or should it be "MAY result" or "is likely to result"? > I.e., is the server guaranteeing that it won't handle a smaller update for the > given capability under any circumstance? The same question also applies > to the "supported-update-period". DONE. "is likely to result" > > > 19. > "The change types that can be excluded in > YANG-Push subscriptions."; > > Suggest adding something like "for the selected data nodes." DONE > > > 20. > 7.2. The YANG Module Names Registry > > This document registers two YANG modules in the YANG Module Names > registry. Following the format in [RFC7950], the the following > registrations are requested: > > This should be (along with a normative reference to RFC 6020): > > This document registers two YANG modules in the YANG Module Names > registry [RFC6020]. Following the format in [RFC6020], the the following > registrations are requested: DONE. > > > 21. > 9.2. Informative References > > [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, > DOI 10.17487/RFC3688, January 2004, > . > > This needs to be a normative reference (for the IANA registry) definition. DONE > > > 22. > Appendix A. Instance data example #1 > > Suggest changing: > "the running, and operational datastores" => "the running and operational datastores". > '"on-change" only' -> '"on-change", only' > 'reported "on-change" as they' -> 'reported "on-change", as they' DONE > > > 23. > ========== NOTE: '\' line wrapping per BCP YYY (RFC YYYY) =========== > > This can be updated to "NOTE: '\' line wrapping per RFC 8792". DONE > > > 24. > "only has running, and operational" -> "only has running and operational" DONE. > > > 25. > false" data from the operational datastore. Statistics are > not reported on-change only two important counters, for these > a smaller dampening period is possible. > > Suggest: > false" data from the operational datastore. Statistics are > not reported on-change except for two important counters, where > a small dampening period is mandated. DONE. > > > Spelling/grammar warnings (generated by tool): > > Potentially incorrect spellings: sheperds, getconfig > > Grammar Warnings: > Section: 1, draft text: > Servers and/or a publishers often have capabilities, values describing operational behavior, that need to be conveyed to clients, which is enabled by the YANG modules described in this document. > Warning: The plural noun "publishers" cannot be used with the article "a". Did you mean a publisher or publishers? > Suggested change: "a publisher" DONE > > Section: 1, draft text: > It is a goal of this document to provide a common way of representing such capabilities in a format that is: > - vendor independent > - machine readable > - available in identical format both at implementation-time and run-time > > Warning: This word is normally spelled with hyphen. > Suggested change: "machine-readable" DONE > > > Section: 1, draft text: > It is a goal of this document to provide a common way of representing such capabilities in a format that is: > - vendor independent > - machine readable > - available in identical format both at implementation-time and run-time > > Warning: Please add a punctuation mark at the end of paragraph. > Suggested change: "run-time." DONE > > > Section: 1, draft text: > Moreover the decision to buy the node type sometimes depends on these management possibilities. > Warning: Did you forget a comma after a conjunctive/linking adverb? > Suggested change: "Moreover," DONE. > > > Section: 1.1, draft text: > "Implementation-time information": Information about the server's behavior that is made available during the implementation of the server, available from a source other then a running server. > Warning: Did you mean other than? > Suggested change: "other than" DONE. > > > Section: 3, draft text: > These include: > - Supported (reporting) periods for "periodic" subscriptions > - Maximum number of objects that can be sent in an update > - The set of datastores or data nodes for which "periodic" notification is supported > > Warning: Please add a punctuation mark at the end of paragraph. > Suggested change: "supported." DONE > > > Section: 7.2, draft text: > Following the format in [RFC7950], the the following registrations are requested: > Warning: Maybe you need to remove one determiner so that only the or the is left. > Suggested change: "the" DONE > > > Section: Appendix C, draft text: > In this latter case it is really the server functionality that is discussed > > Warning: Please add a punctuation mark at the end of paragraph. > Suggested change: "discussed." DONE > > Thanks, > Rob > . --------------017B1888E4A5F1504A8F33F7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Hi Rob,

Thanks for your detailed review.
A new draft version has been posted.
URL:            https://www.ietf.org/archive/id/draft-ietf-netconf-notification-capabilities-17.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-netconf-notification-capabilities/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notification-capabilities
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-notification-capabilities-17

See the justifications below.

On 6/21/2021 10:45 AM, Rob Wilton (rwilton) wrote:
Hi,

Here is my AD review of draft-ietf-netconf-notification-capabiltiies-16

Thanks for this draft, sorry for the delay in reviewing.  It looks like it is in good shape.

I think that most of my comments are minor or cosmetic suggestions to potentially improve the phrasing of the text.


1.
Abstract:

   The module "ietf-system-capabilities" provides a placeholder
   structure that can be used to discover YANG related system
   capabilities for servers.  The module can be used to report
   capability information from the server at run-time or implementation-
   time, per the YANG Instance Data File Format.

Suggest "by making use of" rather than "per".
DONE.


2.
   1.  Introduction

   There is a need to publish this capability information as it is part
   of the contract between the server and client.

Suggest "contract" -> "API contract".
DONE


3.
   There is a need to publish this capability information as it is part
   of the contract between the server and client.  Examples include
   maximum size of data that can be stored or transferred, information
   about counters (whether a node supports "on-change" telemetry), etc.
   Such capabilities are often dependent on a vendor's implementation or
   the available resources at deployment.  Many such capabilities are
   specific to either the complete system, individual YANG datastores
   [RFC8342] or specific parts of the YANG schema, or even individual
   data nodes.  It is a goal of this document to provide a common way of
   representing such capabilities in a format that is:

Suggest: maximum -> the maximum
         "or specific" -> ", specific"
DONE


4.
   o  available in identical format both at implementation-time and run-
      time
	  
Suggest: "in an identical", and a period at the end.
DONE


5.
   If the information is
   not documented in a way available to the NMS designer, but only as
   instance data from the network node once it is deployed, the NMS
   implementation will be delayed

Suggest: "way available" => "way that is readily available"
DONE


6.
   The network operator needs to plan his
   management practices and NMS implementation before he even decides to
   buy the specific network node type.

Suggest: "him" -> "their", "he even decides" -> "they decide"
DONE


7.
   Run-time information is needed:
   
Suggest: Run-time capability information is needed:
DONE.


8.
   o  to check that capability information provided earlier, at
      implementation-time is what the publisher has implemented.

Suggest: "at implementation-time, is"
DONE


9.
     To find a capability value for a specific data node in a
     specific datastore the user SHALL:
	 
Please clarify that the capability value is selected by the relative path
to the datanode defining the capability.  i.e., the same name/path must be
used both under the system level and per datastore level capabilties.
NEW SENTENCE. 
"When stating a specific capability, the relative path for any specific
capability must be the same under the system-capabilities container and
under the per-node-capabilities list: the same grouping for defining the
capabilities MUST be used. "
10.
2) If the datastore entry is found within that entry, process all
     per-node-capabilities entries in the order they appear in the list.
     The first entry that specifies the specific capability and has a
     node-selector selecting the specific data node defines the
     capability value.

I'm not sure this is required, but perhaps consider adding text to make it clear
that longest path matching can be achieved by ordering more specific
matches before less specific matches.
ADDED "Note that longest path matching can be achieved by ordering more specific matches before less specific ones"
under 
    list per-node-capabilities {
        description
          "Each list entry specifies capabilities for the selected
           data nodes. The same capabilities apply for the data nodes
           in the subtree below the selected nodes.

           The system SHALL order the entries according to their
           precedence. The order of the entries MUST NOT change unless
           the underlying capabilities also change.";
We did NOT add next to "2) If the datastore entry is found within that entry ..." because that section focuses on the user (as opposed to the implementer on the server), as mentioned in "To find a capability value for a specific data node in a 
     specific datastore the user SHALL:"


11.
    // augmentation point for system level capabilities
Suggest: "Augmentation ... capabilities."  I would also suggest using a block style
comment so this doesn't get lost.
DONE.


12. 
           Only one specific datastore can be specified
           e.g., ds:conventional is not allowed.";
		   
Suggest changing to:

           Only specific datastores can be specified.
		   E.g., ds:conventional, which represents a
		   set of configuration datastores, must not be
		   used";
DONE


13.
          description
            "A method to select all or some nodes within a datastore.";

"some or all" would flow better.
DONE


14.
        // augmentation point for datastore or data node level
        // capabilities

Suggest: "Augmentation ... capabilities."  I would also suggest using a block style
comment so this doesn't get lost.
DONE.


15.
5.2.  YANG Module (ietf-notification-capabilities)

      - capabilities related to the throughput of notification data
      the publisher can support. (Note that for a specific
      subscription the publisher MAY still allow only longer periods
      or smaller updates depending on e.g., actual load conditions.)
	  
Suggest: "data that the publisher"
         "specific subscription, the"
		 "still allow" -> "allow"
         "e.g., -> ", e.g., "
DONE.
 


16.
           bit config-changes {
             description
               "The publisher is capable of sending
                notifications for 'config false' nodes for the
                relevant scope and subscription type.";
				
I presume that this should this be 'config true' nodes?
GOOD CATCH+



17.
         description
           "Type for defining whether 'on-change' or
            'periodic' notifications are supported 'config false'
            data nodes, 'config true' date nodes, no data nodes,
            or all data nodes.
			
Suggest: "supported for 'config false'",
         "date" -> "data
As an optional minor nit, it might be worth putting 'all' at the beginning
of the list rather than the end.
DONE.


18.
             "Indicates the minimal update period that is
              supported for a 'periodic' subscription.

              A subscription request to the selected data
              nodes with a smaller period than what this leaf
              specifies will result in a 'period-unsupported' error.";

Is "will result" right here, or should it be "MAY result" or "is likely to result"?
I.e., is the server guaranteeing that it won't handle a smaller update for the
given capability under any circumstance?  The same question also applies
to the "supported-update-period".
DONE. "is likely to result"


19.
           "The change types that can be excluded in
            YANG-Push subscriptions.";
			
Suggest adding something like "for the selected data nodes."
DONE


20.
7.2.  The YANG Module Names Registry

   This document registers two YANG modules in the YANG Module Names
   registry.  Following the format in [RFC7950], the the following
   registrations are requested:
   
This should be (along with a normative reference to RFC 6020):

   This document registers two YANG modules in the YANG Module Names
   registry [RFC6020].  Following the format in [RFC6020], the the following
   registrations are requested:
DONE.


21.
9.2.  Informative References

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.
			 
This needs to be a normative reference (for the IANA registry) definition.
DONE


22.
Appendix A.  Instance data example #1

Suggest changing:
"the running, and operational datastores" => "the running and operational datastores".
'"on-change" only' -> '"on-change", only'
'reported "on-change" as they' -> 'reported "on-change", as they'
DONE


23.
========== NOTE: '\' line wrapping per BCP YYY (RFC YYYY) ===========

This can be updated to "NOTE: '\' line wrapping per RFC 8792".
DONE


24.
"only has running, and operational" -> "only has running and operational"
DONE.


25.
    false" data from the operational datastore. Statistics are
    not reported on-change only two important counters, for these
    a smaller dampening period is possible.
	
Suggest:
	false" data from the operational datastore. Statistics are
    not reported on-change except for two important counters, where
    a small dampening period is mandated.
DONE.
	

Spelling/grammar warnings (generated by tool):

Potentially incorrect spellings: sheperds, getconfig

Grammar Warnings:
Section: 1, draft text:
 Servers and/or a publishers often have capabilities, values describing operational behavior, that need to be conveyed to clients, which is enabled by the YANG modules described in this document. 
Warning:  The plural noun "publishers" cannot be used with the article "a". Did you mean a publisher or publishers?
Suggested change:  "a publisher"
DONE

Section: 1, draft text:
It is a goal of this document to provide a common way of representing such capabilities in a format that is: 
- vendor independent
- machine readable
- available in identical format both at implementation-time and run-time

Warning:  This word is normally spelled with hyphen.
Suggested change:  "machine-readable"
DONE


Section: 1, draft text:
It is a goal of this document to provide a common way of representing such capabilities in a format that is: 
- vendor independent
- machine readable
- available in identical format both at implementation-time and run-time

Warning:  Please add a punctuation mark at the end of paragraph.
Suggested change:  "run-time."
DONE


Section: 1, draft text:
Moreover the decision to buy the node type sometimes depends on these management possibilities. 
Warning:  Did you forget a comma after a conjunctive/linking adverb?
Suggested change:  "Moreover,"
DONE.


Section: 1.1, draft text:
 "Implementation-time information": Information about the server's behavior that is made available during the implementation of the server, available from a source other then a running server. 
Warning:  Did you mean other than?
Suggested change:  "other than"
DONE.


Section: 3, draft text:
These include: 
- Supported (reporting) periods for "periodic" subscriptions
- Maximum number of objects that can be sent in an update
- The set of datastores or data nodes for which "periodic" notification is supported

Warning:  Please add a punctuation mark at the end of paragraph.
Suggested change:  "supported."
DONE


Section: 7.2, draft text:
Following the format in [RFC7950], the the following registrations are requested:
Warning:  Maybe you need to remove one determiner so that only the or the is left.
Suggested change:  "the"
DONE


Section: Appendix C, draft text:
In this latter case it is really the server functionality that is discussed

Warning:  Please add a punctuation mark at the end of paragraph.
Suggested change:  "discussed."
DONE

Thanks,
Rob
.

--------------017B1888E4A5F1504A8F33F7-- From nobody Mon Jul 5 04:03:42 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E343A12D6; Mon, 5 Jul 2021 04:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=h45Nc8OI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cAIo4lNf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QD1B5Zbz01Mk; Mon, 5 Jul 2021 04:03:35 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA223A12D5; Mon, 5 Jul 2021 04:03:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=66580; q=dns/txt; s=iport; t=1625483014; x=1626692614; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=N2jLIWKEISs7s3BEDJ8XoGBVBz4+TQUzfGA5IZfskEA=; b=h45Nc8OI9+qXLdmf5B5kVMdVMSU3fziDmJcr8OieLIaJ3d1qJ5wo2Xsd qlndsEFGOJODllK/GpteVJjs0Ba460xLuiBPcRAB6atGZkTSxockyUrB8 hMqhEfkIlJDAwmNVQJv3QpjGc5r/rlVl286Fc20z1iFA+uRP1adbybai1 w=; X-IPAS-Result: =?us-ascii?q?A0CdAADA5eJg/4gNJK1aHQEBAQEJARIBBQUBggUIAQsBg?= =?us-ascii?q?SIwUQd3WjcxC4Q9g0gDhFlgiE8Dj2SKQ4EugSUDVAsBAQENAQE3CAIEAQGEU?= =?us-ascii?q?wIXglYCJTQJDgIEAQEBAQMCAwEBAQEBAQMBAQUBAQECAQYEcROFaA2GRQEBA?= =?us-ascii?q?QQSCAkEBhMBATUCAQ8CAQgRBAEBDhMBCQICAjAdCAEBBAEJBAUIGoJQgX5XA?= =?us-ascii?q?y8BAwuaIwGBOgKKH3p/M4EBggcBAQYEBIE5Ag5BgnsYgjIDBoE6AYJ6hAwBA?= =?us-ascii?q?YZhJxyBSUSBFUOCYj6CYgEBAgEXgS4aFRaCajaCLoJQLRkGAhUZNAEDFBMcC?= =?us-ascii?q?gQCgQIDSA0EBhQFBw8eAgoLkU45gwyIJzeDbokKkhEKgyGKJYc3jGMSg2KLR?= =?us-ascii?q?gOXAJV4ghqKEZNKAxAJARaETwICAgIEBQIOAQEGgic7K4EYDwdwFTuCaVAXA?= =?us-ascii?q?g6OHwwWg06FFIVKcwI2AgYKAQEDCXyHeQGBEAEB?= IronPort-PHdr: A9a23:wO4e1BUyeIC9VnADUqSalwA5bKbV8K3iAWYlg6HPw5pOb6288pWkN 0vatr1hj17MCIPc7f8My+/bqLvpVmFI55Gd+GsDf5pBW15g640WkgUsDdTDBRj9K/jnPCwnF dtPVRlu+HToeURQEdz1MlvVpHD65DUOGxL5YAxyIOm9GoPbg8mtke6o/JiGaARTjz37arR3f 32L IronPort-HdrOrdr: A9a23:wcEmNKFYurEOBU5KpLqFbpHXdLJyesId70hD6qkvc31om52j+f xGws516fatskdvZJkh8erwX5VoMkmsi6KdgLNhfItKOTOHhILGFvAY0WKP+UyEJ8S6zJ8g6U 4CSdk/NDSTNykBsS+S2mDReLxMrKjlgcKVbKXlvgpQpGpRGsddBnJCe36m+zpNNXB77PQCZf 6hz/sCgwDlVWUcb8y9CHVAdfPEvcf3mJXvZgNDLwI76SGV5AnYq4LSIly95FMzQjlPybAt/S zuiAri/JiutPm911v1y3LT1ZJLg9Hso+EzRvBky/JlbwkEuDzYI7iJaIfy+gzdZ9vfsWrCpe O85yvI+f4Ds085MFvF+icFkDOQoQrGo0WSuWNwx0GT+/AQgFkBepZ8bUUzSGqF16NohqAO7I tbm22erJZZFhXGgWD04MXJTQhjkg6urWMlivN7tQ0TbWIyUs4bkWUkxjIeLH7AJlON1Kk3VO 11SM3M7vdfdl2XK3jfo2l02dSpGnA+BA2PTEQOstGcl2E+pgE382IIgMgE2nsQ/pM0TJdJo+ zCL6RzjblLCssbd7h0CusNSda+TmbNXRXPOmSPJkmPLtBKB5sMke++3FwR3pDlRHUl9upHpH 3xaiIQiYdpQTOaNSSn5uw9zvniehTOYQjQ X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.83,325,1616457600"; d="scan'208,217";a="728341966" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Jul 2021 11:03:33 +0000 Received: from mail.cisco.com (xbe-aln-002.cisco.com [173.36.7.17]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 165B3XDo013416 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Jul 2021 11:03:33 GMT Received: from xfe-aln-001.cisco.com (173.37.135.121) by xbe-aln-002.cisco.com (173.36.7.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 5 Jul 2021 06:03:33 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.15; Mon, 5 Jul 2021 06:03:32 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Mon, 5 Jul 2021 07:03:32 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AEts4OPGBT8RTgzuZpvZWQrX0js0HbedmrAZ/8hAGofrbLaGrONUPVVjrq9Ov7fIsnknOPKMO7XqCZXQccWpsjnjEWD7WvMdd+tjLZuzAI9JBY4DVfcKSWo4x7cEpvSeUbdwTFaoA7fkI9n4IzBQ3/c18DV/f2GejZJSsPYUl27+cqdvRQy77WAOakQIwsGdiR4zRn5tFA3Oy8LYuFBoTfMzhF71XwximtCq9w3lPMy1QE6Qru5LZYF45TiDecGdPqTA/uVpHi65McEbQULCIIh7X/AsIGjpgcnn4m/kYG3OvD5n8dugKE0ExhgSC3HJOC4OaX16DAb5ao6RR6W5Fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N2jLIWKEISs7s3BEDJ8XoGBVBz4+TQUzfGA5IZfskEA=; b=fR3LwQPSPRSqAEmuegFIESMlb1o03Knj6pdhaiXFvu6E0G0u3EfZmGcJpJJ6+lJiIGqVkdFDsVH9f0DwY9bQcBZSun9OrszWOKVhAQRmn4vp8djQDgv7zCG7wWaTjLax9TbdbfgjbyIRPiKxxRcIs/yEgMqT3JecyPjuO96TUaIJ1M5iozQyZYx/DTc51gcZCHRXDyUnRQ2Eo4Fjg7UJiL+XPDYIaEqc9QhllcNwgo/xMKGcgQ2u1BGtNyXxwNS8YT7EjWQMCB4KOZwpTbY5Nu7PnX/prpi1vIT9xOkCCKY6v8Di8YdGA6ksCJLjJWr4SI2tTeg8+gqRvYjMPSbgXw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N2jLIWKEISs7s3BEDJ8XoGBVBz4+TQUzfGA5IZfskEA=; b=cAIo4lNfXic5MCjqyBLqpobEhStvqGW2P2NYl0BPm+SSOROG/tcEqo6NxteVGFSehlEKC72fSK91SiRUcW2BosFH7ttzZTeDSgEthiw1lGAQCuoMmXu3L9pOT/zUD+HiINd+qhPKmT85fH+fBtGMPfyBNjiQNhRzC4QEcBBhL4Q= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM6PR11MB3897.namprd11.prod.outlook.com (2603:10b6:5:4::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.33; Mon, 5 Jul 2021 11:03:30 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12%5]) with mapi id 15.20.4287.033; Mon, 5 Jul 2021 11:03:30 +0000 From: "Rob Wilton (rwilton)" To: Benoit Claise , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "netmod@ietf.org" , "draft-ietf-netconf-notification-capabilities@ietf.org" CC: NetMod WG Chairs Thread-Topic: AD review of draft-ietf-netconf-notification-capabilities Thread-Index: AddmeRIyRipJy+knSnCwVIYs/HEmSgLEuHgAAAA3ecA= Date: Mon, 5 Jul 2021 11:03:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 247b3629-6f17-45d2-d76c-08d93fa48621 x-ms-traffictypediagnostic: DM6PR11MB3897: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RCCTI4HHeMP8z7uIXUpOY6lhae2+y/P6upME4GYM9U82lRYGxz6j4zEbK7EDIBQ9QweyUFaVT/zU/GjsVVoPZcc2eZiWS5bT6fv3vtyzVzeN9OFrQi29k+TFhEJppHOwY2eGQgjSQW3JaKz4NW8GkrQOGTRSlRJPdHYfHWx3/URPeR91yW+/becQIZv87uiyOXH2R5twF18b1Ed3MIVRg3aBt4xCJzl/TkhF0NxgDa3ipBrrC2sqv7R3CQpcbsdf7+R1vDirhTS0nrZg2j7SJreDKxZhfQeNrQja8ku5hgpY3tOHmQUdX4pvt7wlgNWzxkEJuCIgoGsjlSZQcvyewnlLRtv3kfKfoteiLV4EoWoNtamAHKtbFv0RL5RwwXQeepGabEa7uovc7ZA9IVx4HpMf0pnNgWOG4ClwljNg8JYCiM2I+bfq9ZoFIRVVVdl7rdHyy0t8JUfuF19cbj59wYRZcptXZ3/nAXbs/IGXAlA7IXXeKXr0QR0GFUQIpuMB6VGMRjxTROtZbwZpUwaJfn0MMY7Hpl/nhscXFheN4sp0ZJybndOf5HU4srWTcgGGMLcxilpsJyHL34+Zr71PeMdy7nyfTITd6KkOSiqREI7KQK/Ag+JdQh16FrwYMd+q335EiNDGI6TwNO3i3vtj3mvsqbu5IVmqIveU28T9GDE+a9VsoZaA0LayIocUkC0iClZQ2xNGXzfk006xbZ52bzYwwzgaMryDphdwDfAaBD5xz87YxwQlR/FXGS3jrtJKD8pcEMbvfFB3XDolW8g1bA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(39860400002)(376002)(366004)(346002)(136003)(52536014)(9326002)(83380400001)(4326008)(966005)(186003)(5660300002)(15650500001)(26005)(110136005)(8936002)(166002)(2906002)(38100700002)(8676002)(6506007)(33656002)(7696005)(30864003)(122000001)(316002)(76116006)(9686003)(86362001)(66476007)(55016002)(71200400001)(66446008)(66946007)(478600001)(66556008)(53546011)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?THBJdGlwc2pUaE5tQm01QjdQa1NveGpGV2JXT0JIVm9zakJIYmU0NFNPM3lU?= =?utf-8?B?OCtyK1ZSOGZIT0daOWFQMit0cmxCYXBiL2poWGtjUUk1ai90c1FTaGZ4Szl4?= =?utf-8?B?Mk1ZalA0b3N5K1krajZrQVpzYnF0SEJSZTFoNytkWlh5UmFndmt4ZG1MZWxp?= =?utf-8?B?NkV2K1hmVWV1YTZNZmNuQUNaYTA1KzZ4MFFhMStZZ0lGT1NpNnRDUkVvU2Ez?= =?utf-8?B?dnpYdXNINHhUeDJiUmN3dUVKZVg3cjFkWHRWVGJNa0MrRmlPOVVCKzR6OE5n?= =?utf-8?B?dVNkZGZDY09vNFJGY1BFT0lPNjdXRFh0L3Z0RzBWR3B2SnMyRmpIZzZ2T2Ey?= =?utf-8?B?OFgzMmtnV3FwVjBtaEoyNFpJMWhpSmxmckNiRXpKb1pHS1haSzB4d1kxbW45?= =?utf-8?B?UnFQQnRWM1M4a2QrcHVQbDJsMGNybGUrbGtOajlqR1Brei9kb2twMnRKSG1R?= =?utf-8?B?MjFpa3k3VDZtWE82SVdGdUo3R3Q3WE1HN04zaTQ5eGVkTUFGeGNvZTJDZEli?= =?utf-8?B?MklFd21mU1JjOFJUaWZPWTJrSjlQREUzTFNDY3AzWVUrZzVjVjRGVTFuTDQr?= =?utf-8?B?ZXFCNGNHdzQxMGRzdTlONkY0bUp2eGQ2MDFMWmtqZ0tOSTgyY28ySTlBWk9W?= =?utf-8?B?d01sSnFnUWNmUEM4Zm4wTGVvZ0ZSTHlON1NZSTQwVWtWdUN1U1o1TE1IUFpp?= =?utf-8?B?emlzajV0SFNzR1F2Wktsd05SNE5xbVBUaTdsY2lnWlByUkxRTnAvbnBuS1BT?= =?utf-8?B?b09OUEdCMFJiSWNlTy9WMEhreWsxc0xSWXJBRVlsU0ZNN1pCTmxXbmpxbzFI?= =?utf-8?B?RDFFYnE1RmFsa2U0UHh3blhJcjRsdjk3MWcwSGZSeG5yOWtqdjJ1eHViTGt5?= =?utf-8?B?WS9pWEg0eVU4dmZ5b3NSUEZWRHVjWHZQbUZZdjM1cis2YUo0U0NUUzZuMnp6?= =?utf-8?B?L1NmUHBIbnV2VmJYUHN0ME81VzI4VmphSjUxSGRVTlNmbGw0UEh1ajdaOFk0?= =?utf-8?B?bHRCcGNFZVdRRmdHNnRCWGdjbFphTDRvMWNRWC9yUGVqbDd0RmFVVW5NSjU4?= =?utf-8?B?Um84bVBZUTdkNnBNdWM4RFhYbkR2YVJFZkFMMnNaY25saVYxek1xUlhGU3ph?= =?utf-8?B?dlF1NWw5MmpCRUVzTG1IS25GMWt1T1JBUkw3cmNKMzFja1NFMVhJalhQZE5R?= =?utf-8?B?SlRWZXBXYVFSZWsyMXZXdWJzTGVpOGxPdnhmRjNTSU8yYkxBU3pVZnBxWElp?= =?utf-8?B?QlRGSytFclNkNkR3LzdpTGJkcGprUjMrUkNCVkQwVG5Yd2thNGc1OXVRTU1S?= =?utf-8?B?Y1lKU0hFOUlyZDJIeE80Qit2N3FBeXAyWmtsM2NvclY2TUZnTFhwa2o0Z3hl?= =?utf-8?B?Zmp4UmtnTm0rV2xvQXYxOXpwMm56aUYwRE1hUjgyUXQ3dk1pYjRDV2pFZ2Zx?= =?utf-8?B?TjUrR1MyOUllaXlBZUV0bmpiQ3ZYY1ZvcWRDMW00eVVCaE44aG9tS1AvcVpL?= =?utf-8?B?TmtrU2Q1WkQzZUkzWm1KUHozc0dIWGJwU0V6TERpbWw5Y21FS0FvbnFqLy9R?= =?utf-8?B?NzhPaHdFSkRaRnM0bHBQN1QwRCtJemF0NXEranR6WHdjdElacXNzajJkNFZJ?= =?utf-8?B?REJhN3hsYUs2Q0RRc3AzemhJNkdwQ0tWSFFkNTN3b3ZGbDJYWk10M3d3Rjk2?= =?utf-8?B?TXBIek1ZdDhHTzg2SlVLNFpQRUcvSjRESVhpNDdPTE5PbUJoMW1Za0dNVnYy?= =?utf-8?Q?D+8KPfw1sz/7UaD9GwAgITl/0X1domWUfJNZYBW?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM4PR11MB543811DFFCCCAA56FDCC2797B51C9DM4PR11MB5438namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 247b3629-6f17-45d2-d76c-08d93fa48621 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2021 11:03:30.5793 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TZwa/3n2hUJCp42KjsJ3mMsZX3hEO0JkOoZjsEL/QKzWHsE+1gR5tJc3tYi3ouxfVItzjKW32LzNBGgGkhLH1w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3897 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xbe-aln-002.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netconf-notification-capabilities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 11:03:41 -0000 --_000_DM4PR11MB543811DFFCCCAA56FDCC2797B51C9DM4PR11MB5438namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVub2l0LA0KDQpUaGFua3MgZm9yIGFjY29tbW9kYXRpbmcgbXkgc3VnZ2VzdGlvbnMuICBB bGwgcmVzb2x1dGlvbnMgbG9vayBnb29kIHRvIG1lLg0KDQpJIGhhdmUgYSBwcmVmZXJlbmNlIHRv IGhvbGQgc2hpcHBpbmcgdGhpcyBkb2N1bWVudCB0byBJRVRGIExDIHVudGlsIHRoZSBpbnN0YW5j ZS1kYXRhIGRvYyBpcyBhbHNvIHJlYWR5LiAgSSB0aGluayB0aGF0IGl0IHdpbGwgaGVscCB0aGUg SUVTRyByZXZpZXcgaWYgdGhleSBoYXZlIGJvdGggZG9jdW1lbnRzIGF2YWlsYWJsZSB0byByZXZp ZXcgYXQgdGhlIHNhbWUgdGltZS4gIEkgYXNzdW1lIHRoYXQgdGhlIHVwZGF0ZXMgdG8gdGhlIGlu c3RhbmNlLWRhdGEgZG9jIGFyZSBhbHNvIGluIHByb2dyZXNzPw0KDQpUaGFua3MsDQpSb2INCg0K DQpGcm9tOiBCZW5vaXQgQ2xhaXNlIDxiZW5vaXQuY2xhaXNlQGh1YXdlaS5jb20+DQpTZW50OiAw NSBKdWx5IDIwMjEgMTE6NTMNClRvOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNj by5jb20+OyBuZXRtb2RAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24t Y2FwYWJpbGl0aWVzQGlldGYub3JnDQpDYzogTmV0TW9kIFdHIENoYWlycyA8bmV0bW9kLWNoYWly c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRjb25m LW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMNCg0KSGkgUm9iLA0KDQpUaGFua3MgZm9yIHlvdXIg ZGV0YWlsZWQgcmV2aWV3Lg0KQSBuZXcgZHJhZnQgdmVyc2lvbiBoYXMgYmVlbiBwb3N0ZWQuDQoN Cg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQt aWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMtMTcudHh0DQoNClN0YXR1czog ICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldGNv bmYtbm90aWZpY2F0aW9uLWNhcGFiaWxpdGllcy8NCg0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNh dGlvbi1jYXBhYmlsaXRpZXMNCg0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3Jn L3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLWNhcGFiaWxpdGll cy0xNw0KDQpTZWUgdGhlIGp1c3RpZmljYXRpb25zIGJlbG93Lg0KT24gNi8yMS8yMDIxIDEwOjQ1 IEFNLCBSb2IgV2lsdG9uIChyd2lsdG9uKSB3cm90ZToNCg0KSGksDQoNCg0KDQpIZXJlIGlzIG15 IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLWNhcGFiaWx0aWll cy0xNg0KDQoNCg0KVGhhbmtzIGZvciB0aGlzIGRyYWZ0LCBzb3JyeSBmb3IgdGhlIGRlbGF5IGlu IHJldmlld2luZy4gIEl0IGxvb2tzIGxpa2UgaXQgaXMgaW4gZ29vZCBzaGFwZS4NCg0KDQoNCkkg dGhpbmsgdGhhdCBtb3N0IG9mIG15IGNvbW1lbnRzIGFyZSBtaW5vciBvciBjb3NtZXRpYyBzdWdn ZXN0aW9ucyB0byBwb3RlbnRpYWxseSBpbXByb3ZlIHRoZSBwaHJhc2luZyBvZiB0aGUgdGV4dC4N Cg0KDQoNCg0KDQoxLg0KDQpBYnN0cmFjdDoNCg0KDQoNCiAgIFRoZSBtb2R1bGUgImlldGYtc3lz dGVtLWNhcGFiaWxpdGllcyIgcHJvdmlkZXMgYSBwbGFjZWhvbGRlcg0KDQogICBzdHJ1Y3R1cmUg dGhhdCBjYW4gYmUgdXNlZCB0byBkaXNjb3ZlciBZQU5HIHJlbGF0ZWQgc3lzdGVtDQoNCiAgIGNh cGFiaWxpdGllcyBmb3Igc2VydmVycy4gIFRoZSBtb2R1bGUgY2FuIGJlIHVzZWQgdG8gcmVwb3J0 DQoNCiAgIGNhcGFiaWxpdHkgaW5mb3JtYXRpb24gZnJvbSB0aGUgc2VydmVyIGF0IHJ1bi10aW1l IG9yIGltcGxlbWVudGF0aW9uLQ0KDQogICB0aW1lLCBwZXIgdGhlIFlBTkcgSW5zdGFuY2UgRGF0 YSBGaWxlIEZvcm1hdC4NCg0KDQoNClN1Z2dlc3QgImJ5IG1ha2luZyB1c2Ugb2YiIHJhdGhlciB0 aGFuICJwZXIiLg0KRE9ORS4NCg0KDQoNCg0KDQoNCg0KDQoyLg0KDQogICAxLiAgSW50cm9kdWN0 aW9uDQoNCg0KDQogICBUaGVyZSBpcyBhIG5lZWQgdG8gcHVibGlzaCB0aGlzIGNhcGFiaWxpdHkg aW5mb3JtYXRpb24gYXMgaXQgaXMgcGFydA0KDQogICBvZiB0aGUgY29udHJhY3QgYmV0d2VlbiB0 aGUgc2VydmVyIGFuZCBjbGllbnQuDQoNCg0KDQpTdWdnZXN0ICJjb250cmFjdCIgLT4gIkFQSSBj b250cmFjdCIuDQpET05FDQoNCg0KDQoNCg0KDQoNCg0KMy4NCg0KICAgVGhlcmUgaXMgYSBuZWVk IHRvIHB1Ymxpc2ggdGhpcyBjYXBhYmlsaXR5IGluZm9ybWF0aW9uIGFzIGl0IGlzIHBhcnQNCg0K ICAgb2YgdGhlIGNvbnRyYWN0IGJldHdlZW4gdGhlIHNlcnZlciBhbmQgY2xpZW50LiAgRXhhbXBs ZXMgaW5jbHVkZQ0KDQogICBtYXhpbXVtIHNpemUgb2YgZGF0YSB0aGF0IGNhbiBiZSBzdG9yZWQg b3IgdHJhbnNmZXJyZWQsIGluZm9ybWF0aW9uDQoNCiAgIGFib3V0IGNvdW50ZXJzICh3aGV0aGVy IGEgbm9kZSBzdXBwb3J0cyAib24tY2hhbmdlIiB0ZWxlbWV0cnkpLCBldGMuDQoNCiAgIFN1Y2gg Y2FwYWJpbGl0aWVzIGFyZSBvZnRlbiBkZXBlbmRlbnQgb24gYSB2ZW5kb3IncyBpbXBsZW1lbnRh dGlvbiBvcg0KDQogICB0aGUgYXZhaWxhYmxlIHJlc291cmNlcyBhdCBkZXBsb3ltZW50LiAgTWFu eSBzdWNoIGNhcGFiaWxpdGllcyBhcmUNCg0KICAgc3BlY2lmaWMgdG8gZWl0aGVyIHRoZSBjb21w bGV0ZSBzeXN0ZW0sIGluZGl2aWR1YWwgWUFORyBkYXRhc3RvcmVzDQoNCiAgIFtSRkM4MzQyXSBv ciBzcGVjaWZpYyBwYXJ0cyBvZiB0aGUgWUFORyBzY2hlbWEsIG9yIGV2ZW4gaW5kaXZpZHVhbA0K DQogICBkYXRhIG5vZGVzLiAgSXQgaXMgYSBnb2FsIG9mIHRoaXMgZG9jdW1lbnQgdG8gcHJvdmlk ZSBhIGNvbW1vbiB3YXkgb2YNCg0KICAgcmVwcmVzZW50aW5nIHN1Y2ggY2FwYWJpbGl0aWVzIGlu IGEgZm9ybWF0IHRoYXQgaXM6DQoNCg0KDQpTdWdnZXN0OiBtYXhpbXVtIC0+IHRoZSBtYXhpbXVt DQoNCiAgICAgICAgICJvciBzcGVjaWZpYyIgLT4gIiwgc3BlY2lmaWMiDQpET05FDQoNCg0KDQoN Cg0KDQoNCg0KNC4NCg0KICAgbyAgYXZhaWxhYmxlIGluIGlkZW50aWNhbCBmb3JtYXQgYm90aCBh dCBpbXBsZW1lbnRhdGlvbi10aW1lIGFuZCBydW4tDQoNCiAgICAgIHRpbWUNCg0KDQoNClN1Z2dl c3Q6ICJpbiBhbiBpZGVudGljYWwiLCBhbmQgYSBwZXJpb2QgYXQgdGhlIGVuZC4NCkRPTkUNCg0K DQoNCg0KDQoNCg0KDQo1Lg0KDQogICBJZiB0aGUgaW5mb3JtYXRpb24gaXMNCg0KICAgbm90IGRv Y3VtZW50ZWQgaW4gYSB3YXkgYXZhaWxhYmxlIHRvIHRoZSBOTVMgZGVzaWduZXIsIGJ1dCBvbmx5 IGFzDQoNCiAgIGluc3RhbmNlIGRhdGEgZnJvbSB0aGUgbmV0d29yayBub2RlIG9uY2UgaXQgaXMg ZGVwbG95ZWQsIHRoZSBOTVMNCg0KICAgaW1wbGVtZW50YXRpb24gd2lsbCBiZSBkZWxheWVkDQoN Cg0KDQpTdWdnZXN0OiAid2F5IGF2YWlsYWJsZSIgPT4gIndheSB0aGF0IGlzIHJlYWRpbHkgYXZh aWxhYmxlIg0KRE9ORQ0KDQoNCg0KDQoNCg0KDQoNCjYuDQoNCiAgIFRoZSBuZXR3b3JrIG9wZXJh dG9yIG5lZWRzIHRvIHBsYW4gaGlzDQoNCiAgIG1hbmFnZW1lbnQgcHJhY3RpY2VzIGFuZCBOTVMg aW1wbGVtZW50YXRpb24gYmVmb3JlIGhlIGV2ZW4gZGVjaWRlcyB0bw0KDQogICBidXkgdGhlIHNw ZWNpZmljIG5ldHdvcmsgbm9kZSB0eXBlLg0KDQoNCg0KU3VnZ2VzdDogImhpbSIgLT4gInRoZWly IiwgImhlIGV2ZW4gZGVjaWRlcyIgLT4gInRoZXkgZGVjaWRlIg0KRE9ORQ0KDQoNCg0KDQoNCg0K DQoNCjcuDQoNCiAgIFJ1bi10aW1lIGluZm9ybWF0aW9uIGlzIG5lZWRlZDoNCg0KDQoNClN1Z2dl c3Q6IFJ1bi10aW1lIGNhcGFiaWxpdHkgaW5mb3JtYXRpb24gaXMgbmVlZGVkOg0KRE9ORS4NCg0K DQoNCg0KDQoNCg0KDQo4Lg0KDQogICBvICB0byBjaGVjayB0aGF0IGNhcGFiaWxpdHkgaW5mb3Jt YXRpb24gcHJvdmlkZWQgZWFybGllciwgYXQNCg0KICAgICAgaW1wbGVtZW50YXRpb24tdGltZSBp cyB3aGF0IHRoZSBwdWJsaXNoZXIgaGFzIGltcGxlbWVudGVkLg0KDQoNCg0KU3VnZ2VzdDogImF0 IGltcGxlbWVudGF0aW9uLXRpbWUsIGlzIg0KRE9ORQ0KDQoNCg0KDQoNCg0KDQoNCjkuDQoNCiAg ICAgVG8gZmluZCBhIGNhcGFiaWxpdHkgdmFsdWUgZm9yIGEgc3BlY2lmaWMgZGF0YSBub2RlIGlu IGENCg0KICAgICBzcGVjaWZpYyBkYXRhc3RvcmUgdGhlIHVzZXIgU0hBTEw6DQoNCg0KDQpQbGVh c2UgY2xhcmlmeSB0aGF0IHRoZSBjYXBhYmlsaXR5IHZhbHVlIGlzIHNlbGVjdGVkIGJ5IHRoZSBy ZWxhdGl2ZSBwYXRoDQoNCnRvIHRoZSBkYXRhbm9kZSBkZWZpbmluZyB0aGUgY2FwYWJpbGl0eS4g IGkuZS4sIHRoZSBzYW1lIG5hbWUvcGF0aCBtdXN0IGJlDQoNCnVzZWQgYm90aCB1bmRlciB0aGUg c3lzdGVtIGxldmVsIGFuZCBwZXIgZGF0YXN0b3JlIGxldmVsIGNhcGFiaWx0aWVzLg0KTkVXIFNF TlRFTkNFLg0KDQoNCiJXaGVuIHN0YXRpbmcgYSBzcGVjaWZpYyBjYXBhYmlsaXR5LCB0aGUgcmVs YXRpdmUgcGF0aCBmb3IgYW55IHNwZWNpZmljDQoNCmNhcGFiaWxpdHkgbXVzdCBiZSB0aGUgc2Ft ZSB1bmRlciB0aGUgc3lzdGVtLWNhcGFiaWxpdGllcyBjb250YWluZXIgYW5kDQoNCnVuZGVyIHRo ZSBwZXItbm9kZS1jYXBhYmlsaXRpZXMgbGlzdDogdGhlIHNhbWUgZ3JvdXBpbmcgZm9yIGRlZmlu aW5nIHRoZQ0KDQpjYXBhYmlsaXRpZXMgTVVTVCBiZSB1c2VkLiAiDQoNCjEwLg0KDQoyKSBJZiB0 aGUgZGF0YXN0b3JlIGVudHJ5IGlzIGZvdW5kIHdpdGhpbiB0aGF0IGVudHJ5LCBwcm9jZXNzIGFs bA0KDQogICAgIHBlci1ub2RlLWNhcGFiaWxpdGllcyBlbnRyaWVzIGluIHRoZSBvcmRlciB0aGV5 IGFwcGVhciBpbiB0aGUgbGlzdC4NCg0KICAgICBUaGUgZmlyc3QgZW50cnkgdGhhdCBzcGVjaWZp ZXMgdGhlIHNwZWNpZmljIGNhcGFiaWxpdHkgYW5kIGhhcyBhDQoNCiAgICAgbm9kZS1zZWxlY3Rv ciBzZWxlY3RpbmcgdGhlIHNwZWNpZmljIGRhdGEgbm9kZSBkZWZpbmVzIHRoZQ0KDQogICAgIGNh cGFiaWxpdHkgdmFsdWUuDQoNCg0KDQpJJ20gbm90IHN1cmUgdGhpcyBpcyByZXF1aXJlZCwgYnV0 IHBlcmhhcHMgY29uc2lkZXIgYWRkaW5nIHRleHQgdG8gbWFrZSBpdCBjbGVhcg0KDQp0aGF0IGxv bmdlc3QgcGF0aCBtYXRjaGluZyBjYW4gYmUgYWNoaWV2ZWQgYnkgb3JkZXJpbmcgbW9yZSBzcGVj aWZpYw0KDQptYXRjaGVzIGJlZm9yZSBsZXNzIHNwZWNpZmljIG1hdGNoZXMuDQpBRERFRCAiTm90 ZSB0aGF0IGxvbmdlc3QgcGF0aCBtYXRjaGluZyBjYW4gYmUgYWNoaWV2ZWQgYnkgb3JkZXJpbmcg bW9yZSBzcGVjaWZpYyBtYXRjaGVzIGJlZm9yZSBsZXNzIHNwZWNpZmljIG9uZXMiDQp1bmRlcg0K DQogICAgbGlzdCBwZXItbm9kZS1jYXBhYmlsaXRpZXMgew0KDQogICAgICAgIGRlc2NyaXB0aW9u DQoNCiAgICAgICAgICAiRWFjaCBsaXN0IGVudHJ5IHNwZWNpZmllcyBjYXBhYmlsaXRpZXMgZm9y IHRoZSBzZWxlY3RlZA0KDQogICAgICAgICAgIGRhdGEgbm9kZXMuIFRoZSBzYW1lIGNhcGFiaWxp dGllcyBhcHBseSBmb3IgdGhlIGRhdGEgbm9kZXMNCg0KICAgICAgICAgICBpbiB0aGUgc3VidHJl ZSBiZWxvdyB0aGUgc2VsZWN0ZWQgbm9kZXMuDQoNCg0KDQogICAgICAgICAgIFRoZSBzeXN0ZW0g U0hBTEwgb3JkZXIgdGhlIGVudHJpZXMgYWNjb3JkaW5nIHRvIHRoZWlyDQoNCiAgICAgICAgICAg cHJlY2VkZW5jZS4gVGhlIG9yZGVyIG9mIHRoZSBlbnRyaWVzIE1VU1QgTk9UIGNoYW5nZSB1bmxl c3MNCg0KICAgICAgICAgICB0aGUgdW5kZXJseWluZyBjYXBhYmlsaXRpZXMgYWxzbyBjaGFuZ2Uu IjsNCldlIGRpZCBOT1QgYWRkIG5leHQgdG8gIjIpIElmIHRoZSBkYXRhc3RvcmUgZW50cnkgaXMg Zm91bmQgd2l0aGluIHRoYXQgZW50cnkgLi4uIiBiZWNhdXNlIHRoYXQgc2VjdGlvbiBmb2N1c2Vz IG9uIHRoZSB1c2VyIChhcyBvcHBvc2VkIHRvIHRoZSBpbXBsZW1lbnRlciBvbiB0aGUgc2VydmVy KSwgYXMgbWVudGlvbmVkIGluICJUbyBmaW5kIGEgY2FwYWJpbGl0eSB2YWx1ZSBmb3IgYSBzcGVj aWZpYyBkYXRhIG5vZGUgaW4gYQ0KDQogICAgIHNwZWNpZmljIGRhdGFzdG9yZSB0aGUgdXNlciBT SEFMTDoiDQoNCg0KDQoNCg0KDQoNCjExLg0KDQogICAgLy8gYXVnbWVudGF0aW9uIHBvaW50IGZv ciBzeXN0ZW0gbGV2ZWwgY2FwYWJpbGl0aWVzDQoNClN1Z2dlc3Q6ICJBdWdtZW50YXRpb24gLi4u IGNhcGFiaWxpdGllcy4iICBJIHdvdWxkIGFsc28gc3VnZ2VzdCB1c2luZyBhIGJsb2NrIHN0eWxl DQoNCmNvbW1lbnQgc28gdGhpcyBkb2Vzbid0IGdldCBsb3N0Lg0KRE9ORS4NCg0KDQoNCg0KDQoN Cg0KDQoxMi4NCg0KICAgICAgICAgICBPbmx5IG9uZSBzcGVjaWZpYyBkYXRhc3RvcmUgY2FuIGJl IHNwZWNpZmllZA0KDQogICAgICAgICAgIGUuZy4sIGRzOmNvbnZlbnRpb25hbCBpcyBub3QgYWxs b3dlZC4iOw0KDQoNCg0KU3VnZ2VzdCBjaGFuZ2luZyB0bzoNCg0KDQoNCiAgICAgICAgICAgT25s eSBzcGVjaWZpYyBkYXRhc3RvcmVzIGNhbiBiZSBzcGVjaWZpZWQuDQoNCiAgICAgICAgICAgRS5n LiwgZHM6Y29udmVudGlvbmFsLCB3aGljaCByZXByZXNlbnRzIGENCg0KICAgICAgICAgICBzZXQg b2YgY29uZmlndXJhdGlvbiBkYXRhc3RvcmVzLCBtdXN0IG5vdCBiZQ0KDQogICAgICAgICAgIHVz ZWQiOw0KRE9ORQ0KDQoNCg0KDQoNCg0KDQoNCjEzLg0KDQogICAgICAgICAgZGVzY3JpcHRpb24N Cg0KICAgICAgICAgICAgIkEgbWV0aG9kIHRvIHNlbGVjdCBhbGwgb3Igc29tZSBub2RlcyB3aXRo aW4gYSBkYXRhc3RvcmUuIjsNCg0KDQoNCiJzb21lIG9yIGFsbCIgd291bGQgZmxvdyBiZXR0ZXIu DQpET05FDQoNCg0KDQoNCg0KDQoNCg0KMTQuDQoNCiAgICAgICAgLy8gYXVnbWVudGF0aW9uIHBv aW50IGZvciBkYXRhc3RvcmUgb3IgZGF0YSBub2RlIGxldmVsDQoNCiAgICAgICAgLy8gY2FwYWJp bGl0aWVzDQoNCg0KDQpTdWdnZXN0OiAiQXVnbWVudGF0aW9uIC4uLiBjYXBhYmlsaXRpZXMuIiAg SSB3b3VsZCBhbHNvIHN1Z2dlc3QgdXNpbmcgYSBibG9jayBzdHlsZQ0KDQpjb21tZW50IHNvIHRo aXMgZG9lc24ndCBnZXQgbG9zdC4NCkRPTkUuDQoNCg0KDQoNCg0KDQoNCg0KMTUuDQoNCjUuMi4g IFlBTkcgTW9kdWxlIChpZXRmLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMpDQoNCg0KDQogICAg ICAtIGNhcGFiaWxpdGllcyByZWxhdGVkIHRvIHRoZSB0aHJvdWdocHV0IG9mIG5vdGlmaWNhdGlv biBkYXRhDQoNCiAgICAgIHRoZSBwdWJsaXNoZXIgY2FuIHN1cHBvcnQuIChOb3RlIHRoYXQgZm9y IGEgc3BlY2lmaWMNCg0KICAgICAgc3Vic2NyaXB0aW9uIHRoZSBwdWJsaXNoZXIgTUFZIHN0aWxs IGFsbG93IG9ubHkgbG9uZ2VyIHBlcmlvZHMNCg0KICAgICAgb3Igc21hbGxlciB1cGRhdGVzIGRl cGVuZGluZyBvbiBlLmcuLCBhY3R1YWwgbG9hZCBjb25kaXRpb25zLikNCg0KDQoNClN1Z2dlc3Q6 ICJkYXRhIHRoYXQgdGhlIHB1Ymxpc2hlciINCg0KICAgICAgICAgInNwZWNpZmljIHN1YnNjcmlw dGlvbiwgdGhlIg0KDQogICAgICAgICAic3RpbGwgYWxsb3ciIC0+ICJhbGxvdyINCg0KICAgICAg ICAgImUuZy4sIC0+ICIsIGUuZy4sICINCkRPTkUuDQoNCg0KDQoNCg0KDQoNCg0KMTYuDQoNCiAg ICAgICAgICAgYml0IGNvbmZpZy1jaGFuZ2VzIHsNCg0KICAgICAgICAgICAgIGRlc2NyaXB0aW9u DQoNCiAgICAgICAgICAgICAgICJUaGUgcHVibGlzaGVyIGlzIGNhcGFibGUgb2Ygc2VuZGluZw0K DQogICAgICAgICAgICAgICAgbm90aWZpY2F0aW9ucyBmb3IgJ2NvbmZpZyBmYWxzZScgbm9kZXMg Zm9yIHRoZQ0KDQogICAgICAgICAgICAgICAgcmVsZXZhbnQgc2NvcGUgYW5kIHN1YnNjcmlwdGlv biB0eXBlLiI7DQoNCg0KDQpJIHByZXN1bWUgdGhhdCB0aGlzIHNob3VsZCB0aGlzIGJlICdjb25m aWcgdHJ1ZScgbm9kZXM/DQpHT09EIENBVENIKw0KDQoNCg0KDQoNCg0KDQoNCg0KMTcuDQoNCiAg ICAgICAgIGRlc2NyaXB0aW9uDQoNCiAgICAgICAgICAgIlR5cGUgZm9yIGRlZmluaW5nIHdoZXRo ZXIgJ29uLWNoYW5nZScgb3INCg0KICAgICAgICAgICAgJ3BlcmlvZGljJyBub3RpZmljYXRpb25z IGFyZSBzdXBwb3J0ZWQgJ2NvbmZpZyBmYWxzZScNCg0KICAgICAgICAgICAgZGF0YSBub2Rlcywg J2NvbmZpZyB0cnVlJyBkYXRlIG5vZGVzLCBubyBkYXRhIG5vZGVzLA0KDQogICAgICAgICAgICBv ciBhbGwgZGF0YSBub2Rlcy4NCg0KDQoNClN1Z2dlc3Q6ICJzdXBwb3J0ZWQgZm9yICdjb25maWcg ZmFsc2UnIiwNCg0KICAgICAgICAgImRhdGUiIC0+ICJkYXRhDQoNCkFzIGFuIG9wdGlvbmFsIG1p bm9yIG5pdCwgaXQgbWlnaHQgYmUgd29ydGggcHV0dGluZyAnYWxsJyBhdCB0aGUgYmVnaW5uaW5n DQoNCm9mIHRoZSBsaXN0IHJhdGhlciB0aGFuIHRoZSBlbmQuDQpET05FLg0KDQoNCg0KDQoNCg0K DQoNCjE4Lg0KDQogICAgICAgICAgICAgIkluZGljYXRlcyB0aGUgbWluaW1hbCB1cGRhdGUgcGVy aW9kIHRoYXQgaXMNCg0KICAgICAgICAgICAgICBzdXBwb3J0ZWQgZm9yIGEgJ3BlcmlvZGljJyBz dWJzY3JpcHRpb24uDQoNCg0KDQogICAgICAgICAgICAgIEEgc3Vic2NyaXB0aW9uIHJlcXVlc3Qg dG8gdGhlIHNlbGVjdGVkIGRhdGENCg0KICAgICAgICAgICAgICBub2RlcyB3aXRoIGEgc21hbGxl ciBwZXJpb2QgdGhhbiB3aGF0IHRoaXMgbGVhZg0KDQogICAgICAgICAgICAgIHNwZWNpZmllcyB3 aWxsIHJlc3VsdCBpbiBhICdwZXJpb2QtdW5zdXBwb3J0ZWQnIGVycm9yLiI7DQoNCg0KDQpJcyAi d2lsbCByZXN1bHQiIHJpZ2h0IGhlcmUsIG9yIHNob3VsZCBpdCBiZSAiTUFZIHJlc3VsdCIgb3Ig ImlzIGxpa2VseSB0byByZXN1bHQiPw0KDQpJLmUuLCBpcyB0aGUgc2VydmVyIGd1YXJhbnRlZWlu ZyB0aGF0IGl0IHdvbid0IGhhbmRsZSBhIHNtYWxsZXIgdXBkYXRlIGZvciB0aGUNCg0KZ2l2ZW4g Y2FwYWJpbGl0eSB1bmRlciBhbnkgY2lyY3Vtc3RhbmNlPyAgVGhlIHNhbWUgcXVlc3Rpb24gYWxz byBhcHBsaWVzDQoNCnRvIHRoZSAic3VwcG9ydGVkLXVwZGF0ZS1wZXJpb2QiLg0KRE9ORS4gImlz IGxpa2VseSB0byByZXN1bHQiDQoNCg0KDQoNCg0KDQoNCg0KMTkuDQoNCiAgICAgICAgICAgIlRo ZSBjaGFuZ2UgdHlwZXMgdGhhdCBjYW4gYmUgZXhjbHVkZWQgaW4NCg0KICAgICAgICAgICAgWUFO Ry1QdXNoIHN1YnNjcmlwdGlvbnMuIjsNCg0KDQoNClN1Z2dlc3QgYWRkaW5nIHNvbWV0aGluZyBs aWtlICJmb3IgdGhlIHNlbGVjdGVkIGRhdGEgbm9kZXMuIg0KRE9ORQ0KDQoNCg0KDQoNCg0KDQoN CjIwLg0KDQo3LjIuICBUaGUgWUFORyBNb2R1bGUgTmFtZXMgUmVnaXN0cnkNCg0KDQoNCiAgIFRo aXMgZG9jdW1lbnQgcmVnaXN0ZXJzIHR3byBZQU5HIG1vZHVsZXMgaW4gdGhlIFlBTkcgTW9kdWxl IE5hbWVzDQoNCiAgIHJlZ2lzdHJ5LiAgRm9sbG93aW5nIHRoZSBmb3JtYXQgaW4gW1JGQzc5NTBd LCB0aGUgdGhlIGZvbGxvd2luZw0KDQogICByZWdpc3RyYXRpb25zIGFyZSByZXF1ZXN0ZWQ6DQoN Cg0KDQpUaGlzIHNob3VsZCBiZSAoYWxvbmcgd2l0aCBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8g UkZDIDYwMjApOg0KDQoNCg0KICAgVGhpcyBkb2N1bWVudCByZWdpc3RlcnMgdHdvIFlBTkcgbW9k dWxlcyBpbiB0aGUgWUFORyBNb2R1bGUgTmFtZXMNCg0KICAgcmVnaXN0cnkgW1JGQzYwMjBdLiAg Rm9sbG93aW5nIHRoZSBmb3JtYXQgaW4gW1JGQzYwMjBdLCB0aGUgdGhlIGZvbGxvd2luZw0KDQog ICByZWdpc3RyYXRpb25zIGFyZSByZXF1ZXN0ZWQ6DQpET05FLg0KDQoNCg0KDQoNCg0KDQoNCjIx Lg0KDQo5LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQoNCg0KDQogICBbUkZDMzY4OF0gIE1l YWxsaW5nLCBNLiwgIlRoZSBJRVRGIFhNTCBSZWdpc3RyeSIsIEJDUCA4MSwgUkZDIDM2ODgsDQoN CiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzM2ODgsIEphbnVhcnkgMjAwNCwNCg0KICAg ICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMzNjg4PjxodHRw czovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzM2ODg+Lg0KDQoNCg0KVGhpcyBuZWVkcyB0 byBiZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgKGZvciB0aGUgSUFOQSByZWdpc3RyeSkgZGVmaW5p dGlvbi4NCkRPTkUNCg0KDQoNCg0KDQoNCg0KDQoyMi4NCg0KQXBwZW5kaXggQS4gIEluc3RhbmNl IGRhdGEgZXhhbXBsZSAjMQ0KDQoNCg0KU3VnZ2VzdCBjaGFuZ2luZzoNCg0KInRoZSBydW5uaW5n LCBhbmQgb3BlcmF0aW9uYWwgZGF0YXN0b3JlcyIgPT4gInRoZSBydW5uaW5nIGFuZCBvcGVyYXRp b25hbCBkYXRhc3RvcmVzIi4NCg0KJyJvbi1jaGFuZ2UiIG9ubHknIC0+ICcib24tY2hhbmdlIiwg b25seScNCg0KJ3JlcG9ydGVkICJvbi1jaGFuZ2UiIGFzIHRoZXknIC0+ICdyZXBvcnRlZCAib24t Y2hhbmdlIiwgYXMgdGhleScNCkRPTkUNCg0KDQoNCg0KDQoNCg0KDQoyMy4NCg0KPT09PT09PT09 PSBOT1RFOiAnXCcgbGluZSB3cmFwcGluZyBwZXIgQkNQIFlZWSAoUkZDIFlZWVkpID09PT09PT09 PT09DQoNCg0KDQpUaGlzIGNhbiBiZSB1cGRhdGVkIHRvICJOT1RFOiAnXCcgbGluZSB3cmFwcGlu ZyBwZXIgUkZDIDg3OTIiLg0KRE9ORQ0KDQoNCg0KDQoNCg0KDQoNCjI0Lg0KDQoib25seSBoYXMg cnVubmluZywgYW5kIG9wZXJhdGlvbmFsIiAtPiAib25seSBoYXMgcnVubmluZyBhbmQgb3BlcmF0 aW9uYWwiDQpET05FLg0KDQoNCg0KDQoNCg0KDQoNCjI1Lg0KDQogICAgZmFsc2UiIGRhdGEgZnJv bSB0aGUgb3BlcmF0aW9uYWwgZGF0YXN0b3JlLiBTdGF0aXN0aWNzIGFyZQ0KDQogICAgbm90IHJl cG9ydGVkIG9uLWNoYW5nZSBvbmx5IHR3byBpbXBvcnRhbnQgY291bnRlcnMsIGZvciB0aGVzZQ0K DQogICAgYSBzbWFsbGVyIGRhbXBlbmluZyBwZXJpb2QgaXMgcG9zc2libGUuDQoNCg0KDQpTdWdn ZXN0Og0KDQogZmFsc2UiIGRhdGEgZnJvbSB0aGUgb3BlcmF0aW9uYWwgZGF0YXN0b3JlLiBTdGF0 aXN0aWNzIGFyZQ0KDQogICAgbm90IHJlcG9ydGVkIG9uLWNoYW5nZSBleGNlcHQgZm9yIHR3byBp bXBvcnRhbnQgY291bnRlcnMsIHdoZXJlDQoNCiAgICBhIHNtYWxsIGRhbXBlbmluZyBwZXJpb2Qg aXMgbWFuZGF0ZWQuDQpET05FLg0KDQoNCg0KDQoNCg0KDQoNClNwZWxsaW5nL2dyYW1tYXIgd2Fy bmluZ3MgKGdlbmVyYXRlZCBieSB0b29sKToNCg0KDQoNClBvdGVudGlhbGx5IGluY29ycmVjdCBz cGVsbGluZ3M6IHNoZXBlcmRzLCBnZXRjb25maWcNCg0KDQoNCkdyYW1tYXIgV2FybmluZ3M6DQoN ClNlY3Rpb246IDEsIGRyYWZ0IHRleHQ6DQoNCiBTZXJ2ZXJzIGFuZC9vciBhIHB1Ymxpc2hlcnMg b2Z0ZW4gaGF2ZSBjYXBhYmlsaXRpZXMsIHZhbHVlcyBkZXNjcmliaW5nIG9wZXJhdGlvbmFsIGJl aGF2aW9yLCB0aGF0IG5lZWQgdG8gYmUgY29udmV5ZWQgdG8gY2xpZW50cywgd2hpY2ggaXMgZW5h YmxlZCBieSB0aGUgWUFORyBtb2R1bGVzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQpX YXJuaW5nOiAgVGhlIHBsdXJhbCBub3VuICJwdWJsaXNoZXJzIiBjYW5ub3QgYmUgdXNlZCB3aXRo IHRoZSBhcnRpY2xlICJhIi4gRGlkIHlvdSBtZWFuIGEgcHVibGlzaGVyIG9yIHB1Ymxpc2hlcnM/ DQoNClN1Z2dlc3RlZCBjaGFuZ2U6ICAiYSBwdWJsaXNoZXIiDQpET05FDQoNCg0KDQoNCg0KDQpT ZWN0aW9uOiAxLCBkcmFmdCB0ZXh0Og0KDQpJdCBpcyBhIGdvYWwgb2YgdGhpcyBkb2N1bWVudCB0 byBwcm92aWRlIGEgY29tbW9uIHdheSBvZiByZXByZXNlbnRpbmcgc3VjaCBjYXBhYmlsaXRpZXMg aW4gYSBmb3JtYXQgdGhhdCBpczoNCg0KLSB2ZW5kb3IgaW5kZXBlbmRlbnQNCg0KLSBtYWNoaW5l IHJlYWRhYmxlDQoNCi0gYXZhaWxhYmxlIGluIGlkZW50aWNhbCBmb3JtYXQgYm90aCBhdCBpbXBs ZW1lbnRhdGlvbi10aW1lIGFuZCBydW4tdGltZQ0KDQoNCg0KV2FybmluZzogIFRoaXMgd29yZCBp cyBub3JtYWxseSBzcGVsbGVkIHdpdGggaHlwaGVuLg0KDQpTdWdnZXN0ZWQgY2hhbmdlOiAgIm1h Y2hpbmUtcmVhZGFibGUiDQpET05FDQoNCg0KDQoNCg0KDQoNCg0KU2VjdGlvbjogMSwgZHJhZnQg dGV4dDoNCg0KSXQgaXMgYSBnb2FsIG9mIHRoaXMgZG9jdW1lbnQgdG8gcHJvdmlkZSBhIGNvbW1v biB3YXkgb2YgcmVwcmVzZW50aW5nIHN1Y2ggY2FwYWJpbGl0aWVzIGluIGEgZm9ybWF0IHRoYXQg aXM6DQoNCi0gdmVuZG9yIGluZGVwZW5kZW50DQoNCi0gbWFjaGluZSByZWFkYWJsZQ0KDQotIGF2 YWlsYWJsZSBpbiBpZGVudGljYWwgZm9ybWF0IGJvdGggYXQgaW1wbGVtZW50YXRpb24tdGltZSBh bmQgcnVuLXRpbWUNCg0KDQoNCldhcm5pbmc6ICBQbGVhc2UgYWRkIGEgcHVuY3R1YXRpb24gbWFy ayBhdCB0aGUgZW5kIG9mIHBhcmFncmFwaC4NCg0KU3VnZ2VzdGVkIGNoYW5nZTogICJydW4tdGlt ZS4iDQpET05FDQoNCg0KDQoNCg0KDQoNCg0KU2VjdGlvbjogMSwgZHJhZnQgdGV4dDoNCg0KTW9y ZW92ZXIgdGhlIGRlY2lzaW9uIHRvIGJ1eSB0aGUgbm9kZSB0eXBlIHNvbWV0aW1lcyBkZXBlbmRz IG9uIHRoZXNlIG1hbmFnZW1lbnQgcG9zc2liaWxpdGllcy4NCg0KV2FybmluZzogIERpZCB5b3Ug Zm9yZ2V0IGEgY29tbWEgYWZ0ZXIgYSBjb25qdW5jdGl2ZS9saW5raW5nIGFkdmVyYj8NCg0KU3Vn Z2VzdGVkIGNoYW5nZTogICJNb3Jlb3ZlciwiDQpET05FLg0KDQoNCg0KDQoNCg0KDQoNClNlY3Rp b246IDEuMSwgZHJhZnQgdGV4dDoNCg0KICJJbXBsZW1lbnRhdGlvbi10aW1lIGluZm9ybWF0aW9u IjogSW5mb3JtYXRpb24gYWJvdXQgdGhlIHNlcnZlcidzIGJlaGF2aW9yIHRoYXQgaXMgbWFkZSBh dmFpbGFibGUgZHVyaW5nIHRoZSBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc2VydmVyLCBhdmFpbGFi bGUgZnJvbSBhIHNvdXJjZSBvdGhlciB0aGVuIGEgcnVubmluZyBzZXJ2ZXIuDQoNCldhcm5pbmc6 ICBEaWQgeW91IG1lYW4gb3RoZXIgdGhhbj8NCg0KU3VnZ2VzdGVkIGNoYW5nZTogICJvdGhlciB0 aGFuIg0KRE9ORS4NCg0KDQoNCg0KDQoNCg0KDQpTZWN0aW9uOiAzLCBkcmFmdCB0ZXh0Og0KDQpU aGVzZSBpbmNsdWRlOg0KDQotIFN1cHBvcnRlZCAocmVwb3J0aW5nKSBwZXJpb2RzIGZvciAicGVy aW9kaWMiIHN1YnNjcmlwdGlvbnMNCg0KLSBNYXhpbXVtIG51bWJlciBvZiBvYmplY3RzIHRoYXQg Y2FuIGJlIHNlbnQgaW4gYW4gdXBkYXRlDQoNCi0gVGhlIHNldCBvZiBkYXRhc3RvcmVzIG9yIGRh dGEgbm9kZXMgZm9yIHdoaWNoICJwZXJpb2RpYyIgbm90aWZpY2F0aW9uIGlzIHN1cHBvcnRlZA0K DQoNCg0KV2FybmluZzogIFBsZWFzZSBhZGQgYSBwdW5jdHVhdGlvbiBtYXJrIGF0IHRoZSBlbmQg b2YgcGFyYWdyYXBoLg0KDQpTdWdnZXN0ZWQgY2hhbmdlOiAgInN1cHBvcnRlZC4iDQpET05FDQoN Cg0KDQoNCg0KDQoNCg0KU2VjdGlvbjogNy4yLCBkcmFmdCB0ZXh0Og0KDQpGb2xsb3dpbmcgdGhl IGZvcm1hdCBpbiBbUkZDNzk1MF0sIHRoZSB0aGUgZm9sbG93aW5nIHJlZ2lzdHJhdGlvbnMgYXJl IHJlcXVlc3RlZDoNCg0KV2FybmluZzogIE1heWJlIHlvdSBuZWVkIHRvIHJlbW92ZSBvbmUgZGV0 ZXJtaW5lciBzbyB0aGF0IG9ubHkgdGhlIG9yIHRoZSBpcyBsZWZ0Lg0KDQpTdWdnZXN0ZWQgY2hh bmdlOiAgInRoZSINCkRPTkUNCg0KDQoNCg0KDQoNCg0KDQpTZWN0aW9uOiBBcHBlbmRpeCBDLCBk cmFmdCB0ZXh0Og0KDQpJbiB0aGlzIGxhdHRlciBjYXNlIGl0IGlzIHJlYWxseSB0aGUgc2VydmVy IGZ1bmN0aW9uYWxpdHkgdGhhdCBpcyBkaXNjdXNzZWQNCg0KDQoNCldhcm5pbmc6ICBQbGVhc2Ug YWRkIGEgcHVuY3R1YXRpb24gbWFyayBhdCB0aGUgZW5kIG9mIHBhcmFncmFwaC4NCg0KU3VnZ2Vz dGVkIGNoYW5nZTogICJkaXNjdXNzZWQuIg0KRE9ORQ0KDQoNCg0KDQoNCg0KVGhhbmtzLA0KDQpS b2INCg0KLg0KDQo= --_000_DM4PR11MB543811DFFCCCAA56FDCC2797B51C9DM4PR11MB5438namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25z b2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEJlbm9pdCw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtz IGZvciBhY2NvbW1vZGF0aW5nIG15IHN1Z2dlc3Rpb25zLiZuYnNwOyBBbGwgcmVzb2x1dGlvbnMg bG9vayBnb29kIHRvIG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGhhdmUgYSBwcmVmZXJlbmNlIHRvIGhvbGQgc2hpcHBp bmcgdGhpcyBkb2N1bWVudCB0byBJRVRGIExDIHVudGlsIHRoZSBpbnN0YW5jZS1kYXRhIGRvYyBp cyBhbHNvIHJlYWR5LiZuYnNwOyBJIHRoaW5rIHRoYXQgaXQgd2lsbCBoZWxwIHRoZSBJRVNHIHJl dmlldyBpZiB0aGV5IGhhdmUgYm90aCBkb2N1bWVudHMgYXZhaWxhYmxlIHRvIHJldmlldw0KIGF0 IHRoZSBzYW1lIHRpbWUuJm5ic3A7IEkgYXNzdW1lIHRoYXQgdGhlIHVwZGF0ZXMgdG8gdGhlIGlu c3RhbmNlLWRhdGEgZG9jIGFyZSBhbHNvIGluIHByb2dyZXNzPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Sb2I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gQmVub2l0IENsYWlzZSAmbHQ7YmVub2l0LmNs YWlzZUBodWF3ZWkuY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDA1IEp1bHkgMjAyMSAxMTo1 Mzxicj4NCjxiPlRvOjwvYj4gUm9iIFdpbHRvbiAocndpbHRvbikgJmx0O3J3aWx0b25AY2lzY28u Y29tJmd0OzsgbmV0bW9kQGlldGYub3JnOyBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9u LWNhcGFiaWxpdGllc0BpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gTmV0TW9kIFdHIENoYWlycyAm bHQ7bmV0bW9kLWNoYWlyc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEFE IHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZpY2F0aW9uLWNhcGFiaWxpdGllczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFJvYiw8YnI+ DQo8YnI+DQpUaGFua3MgZm9yIHlvdXIgZGV0YWlsZWQgcmV2aWV3Ljxicj4NCkEgbmV3IGRyYWZ0 IHZlcnNpb24gaGFzIGJlZW4gcG9zdGVkLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHBy ZT5VUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQv ZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMtMTcudHh0Ij5odHRw czovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRp b24tY2FwYWJpbGl0aWVzLTE3LnR4dDwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TdGF0dXM6 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29uZi1ub3Rp ZmljYXRpb24tY2FwYWJpbGl0aWVzLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1uZXRjb25mLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMvPC9hPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPkh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0 LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tY2FwYWJpbGl0aWVzIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tY2Fw YWJpbGl0aWVzPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkRpZmY6Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLW5ldGNvbmYtbm90aWZp Y2F0aW9uLWNhcGFiaWxpdGllcy0xNyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy PWRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tY2FwYWJpbGl0aWVzLTE3PC9hPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NClNlZSB0aGUganVzdGlmaWNhdGlvbnMgYmVsb3cuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNi8yMS8yMDIxIDEwOjQ1IEFNLCBSb2Ig V2lsdG9uIChyd2lsdG9uKSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkhp LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkhl cmUgaXMgbXkgQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0Y29uZi1ub3RpZmljYXRpb24tY2Fw YWJpbHRpaWVzLTE2PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmU+VGhhbmtzIGZvciB0aGlzIGRyYWZ0LCBzb3JyeSBmb3IgdGhlIGRlbGF5IGluIHJl dmlld2luZy4mbmJzcDsgSXQgbG9va3MgbGlrZSBpdCBpcyBpbiBnb29kIHNoYXBlLjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkkgdGhpbmsgdGhh dCBtb3N0IG9mIG15IGNvbW1lbnRzIGFyZSBtaW5vciBvciBjb3NtZXRpYyBzdWdnZXN0aW9ucyB0 byBwb3RlbnRpYWxseSBpbXByb3ZlIHRoZSBwaHJhc2luZyBvZiB0aGUgdGV4dC48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT4xLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFic3RyYWN0OjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyBUaGUgbW9kdWxlICZxdW90O2lldGYtc3lzdGVtLWNhcGFiaWxpdGllcyZxdW90OyBwcm92 aWRlcyBhIHBsYWNlaG9sZGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHN0 cnVjdHVyZSB0aGF0IGNhbiBiZSB1c2VkIHRvIGRpc2NvdmVyIFlBTkcgcmVsYXRlZCBzeXN0ZW08 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgY2FwYWJpbGl0aWVzIGZvciBzZXJ2 ZXJzLiZuYnNwOyBUaGUgbW9kdWxlIGNhbiBiZSB1c2VkIHRvIHJlcG9ydDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBjYXBhYmlsaXR5IGluZm9ybWF0aW9uIGZyb20gdGhlIHNl cnZlciBhdCBydW4tdGltZSBvciBpbXBsZW1lbnRhdGlvbi08bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsgdGltZSwgcGVyIHRoZSBZQU5HIEluc3RhbmNlIERhdGEgRmlsZSBGb3Jt YXQuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+ U3VnZ2VzdCAmcXVvdDtieSBtYWtpbmcgdXNlIG9mJnF1b3Q7IHJhdGhlciB0aGFuICZxdW90O3Bl ciZxdW90Oy48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+RE9ORS48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZT4yLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyAxLiZuYnNwOyBJbnRyb2R1Y3Rpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgVGhlcmUgaXMgYSBuZWVkIHRvIHB1 Ymxpc2ggdGhpcyBjYXBhYmlsaXR5IGluZm9ybWF0aW9uIGFzIGl0IGlzIHBhcnQ8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgb2YgdGhlIGNvbnRyYWN0IGJldHdlZW4gdGhlIHNl cnZlciBhbmQgY2xpZW50LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlPlN1Z2dlc3QgJnF1b3Q7Y29udHJhY3QmcXVvdDsgLSZndDsgJnF1b3Q7QVBJ IGNvbnRyYWN0JnF1b3Q7LjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5ET05FPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+My48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsgVGhlcmUgaXMgYSBuZWVkIHRvIHB1Ymxpc2ggdGhpcyBjYXBhYmlsaXR5IGlu Zm9ybWF0aW9uIGFzIGl0IGlzIHBhcnQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsgb2YgdGhlIGNvbnRyYWN0IGJldHdlZW4gdGhlIHNlcnZlciBhbmQgY2xpZW50LiZuYnNwOyBF eGFtcGxlcyBpbmNsdWRlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG1heGlt dW0gc2l6ZSBvZiBkYXRhIHRoYXQgY2FuIGJlIHN0b3JlZCBvciB0cmFuc2ZlcnJlZCwgaW5mb3Jt YXRpb248bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYWJvdXQgY291bnRlcnMg KHdoZXRoZXIgYSBub2RlIHN1cHBvcnRzICZxdW90O29uLWNoYW5nZSZxdW90OyB0ZWxlbWV0cnkp LCBldGMuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IFN1Y2ggY2FwYWJpbGl0 aWVzIGFyZSBvZnRlbiBkZXBlbmRlbnQgb24gYSB2ZW5kb3IncyBpbXBsZW1lbnRhdGlvbiBvcjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyB0aGUgYXZhaWxhYmxlIHJlc291cmNl cyBhdCBkZXBsb3ltZW50LiZuYnNwOyBNYW55IHN1Y2ggY2FwYWJpbGl0aWVzIGFyZTxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBzcGVjaWZpYyB0byBlaXRoZXIgdGhlIGNvbXBs ZXRlIHN5c3RlbSwgaW5kaXZpZHVhbCBZQU5HIGRhdGFzdG9yZXM8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsgW1JGQzgzNDJdIG9yIHNwZWNpZmljIHBhcnRzIG9mIHRoZSBZQU5H IHNjaGVtYSwgb3IgZXZlbiBpbmRpdmlkdWFsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7IGRhdGEgbm9kZXMuICZuYnNwO0l0IGlzIGEgZ29hbCBvZiB0aGlzIGRvY3VtZW50IHRv IHByb3ZpZGUgYSBjb21tb24gd2F5IG9mPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IHJlcHJlc2VudGluZyBzdWNoIGNhcGFiaWxpdGllcyBpbiBhIGZvcm1hdCB0aGF0IGlzOjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlN1Z2dl c3Q6IG1heGltdW0gLSZndDsgdGhlIG1heGltdW08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7b3Igc3Bl Y2lmaWMmcXVvdDsgLSZndDsgJnF1b3Q7LCBzcGVjaWZpYyZxdW90OzxvOnA+PC9vOnA+PC9wcmU+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ET05FPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+NC48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgbyZuYnNwOyBhdmFpbGFibGUgaW4g aWRlbnRpY2FsIGZvcm1hdCBib3RoIGF0IGltcGxlbWVudGF0aW9uLXRpbWUgYW5kIHJ1bi08bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGltZTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiAmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+U3Vn Z2VzdDogJnF1b3Q7aW4gYW4gaWRlbnRpY2FsJnF1b3Q7LCBhbmQgYSBwZXJpb2QgYXQgdGhlIGVu ZC48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ RE9ORTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPjUuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IElm IHRoZSBpbmZvcm1hdGlvbiBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBu b3QgZG9jdW1lbnRlZCBpbiBhIHdheSBhdmFpbGFibGUgdG8gdGhlIE5NUyBkZXNpZ25lciwgYnV0 IG9ubHkgYXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgaW5zdGFuY2UgZGF0 YSBmcm9tIHRoZSBuZXR3b3JrIG5vZGUgb25jZSBpdCBpcyBkZXBsb3llZCwgdGhlIE5NUzxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBpbXBsZW1lbnRhdGlvbiB3aWxsIGJlIGRl bGF5ZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZT5TdWdnZXN0OiAmcXVvdDt3YXkgYXZhaWxhYmxlJnF1b3Q7ID0mZ3Q7ICZxdW90O3dheSB0aGF0 IGlzIHJlYWRpbHkgYXZhaWxhYmxlJnF1b3Q7PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRPTkU8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT42LjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGUgbmV0d29yayBvcGVyYXRvciBuZWVkcyB0byBwbGFu IGhpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBtYW5hZ2VtZW50IHByYWN0 aWNlcyBhbmQgTk1TIGltcGxlbWVudGF0aW9uIGJlZm9yZSBoZSBldmVuIGRlY2lkZXMgdG88bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYnV5IHRoZSBzcGVjaWZpYyBuZXR3b3Jr IG5vZGUgdHlwZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT5TdWdnZXN0OiAmcXVvdDtoaW0mcXVvdDsgLSZndDsgJnF1b3Q7dGhlaXImcXVvdDss ICZxdW90O2hlIGV2ZW4gZGVjaWRlcyZxdW90OyAtJmd0OyAmcXVvdDt0aGV5IGRlY2lkZSZxdW90 OzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5E T05FPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmU+Ny48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgUnVu LXRpbWUgaW5mb3JtYXRpb24gaXMgbmVlZGVkOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TdWdnZXN0OiBSdW4tdGltZSBjYXBhYmls aXR5IGluZm9ybWF0aW9uIGlzIG5lZWRlZDo8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RE9ORS48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT44LjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBvJm5ic3A7IHRvIGNoZWNrIHRoYXQgY2FwYWJpbGl0eSBp bmZvcm1hdGlvbiBwcm92aWRlZCBlYXJsaWVyLCBhdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbXBsZW1lbnRhdGlvbi10aW1lIGlzIHdoYXQg dGhlIHB1Ymxpc2hlciBoYXMgaW1wbGVtZW50ZWQuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+U3VnZ2VzdDogJnF1b3Q7YXQgaW1wbGVtZW50YXRp b24tdGltZSwgaXMmcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RE9ORTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjkuPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRvIGZpbmQgYSBjYXBhYmlsaXR5IHZhbHVlIGZvciBh IHNwZWNpZmljIGRhdGEgbm9kZSBpbiBhPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHNwZWNpZmljIGRhdGFzdG9yZSB0aGUgdXNlciBTSEFMTDo8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4gIDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlBsZWFzZSBjbGFyaWZ5 IHRoYXQgdGhlIGNhcGFiaWxpdHkgdmFsdWUgaXMgc2VsZWN0ZWQgYnkgdGhlIHJlbGF0aXZlIHBh dGg8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50byB0aGUgZGF0YW5vZGUgZGVmaW5pbmcgdGhlIGNh cGFiaWxpdHkuJm5ic3A7IGkuZS4sIHRoZSBzYW1lIG5hbWUvcGF0aCBtdXN0IGJlPG86cD48L286 cD48L3ByZT4NCjxwcmU+dXNlZCBib3RoIHVuZGVyIHRoZSBzeXN0ZW0gbGV2ZWwgYW5kIHBlciBk YXRhc3RvcmUgbGV2ZWwgY2FwYWJpbHRpZXMuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5FVyBTRU5URU5DRS4gPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8cHJlPiZxdW90O1doZW4gc3RhdGluZyBhIHNwZWNpZmljIGNhcGFiaWxpdHks IHRoZSByZWxhdGl2ZSBwYXRoIGZvciBhbnkgc3BlY2lmaWM8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5jYXBhYmlsaXR5IG11c3QgYmUgdGhlIHNhbWUgdW5kZXIgdGhlIHN5c3RlbS1jYXBhYmlsaXRp ZXMgY29udGFpbmVyIGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnVuZGVyIHRoZSBwZXItbm9k ZS1jYXBhYmlsaXRpZXMgbGlzdDogdGhlIHNhbWUgZ3JvdXBpbmcgZm9yIGRlZmluaW5nIHRoZTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmNhcGFiaWxpdGllcyBNVVNUIGJlIHVzZWQuICZxdW90Ozxv OnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+MTAuPG86cD48L286cD48L3ByZT4NCjxwcmU+MikgSWYg dGhlIGRhdGFzdG9yZSBlbnRyeSBpcyBmb3VuZCB3aXRoaW4gdGhhdCBlbnRyeSwgcHJvY2VzcyBh bGw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcGVyLW5v ZGUtY2FwYWJpbGl0aWVzIGVudHJpZXMgaW4gdGhlIG9yZGVyIHRoZXkgYXBwZWFyIGluIHRoZSBs aXN0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUg Zmlyc3QgZW50cnkgdGhhdCBzcGVjaWZpZXMgdGhlIHNwZWNpZmljIGNhcGFiaWxpdHkgYW5kIGhh cyBhPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5vZGUt c2VsZWN0b3Igc2VsZWN0aW5nIHRoZSBzcGVjaWZpYyBkYXRhIG5vZGUgZGVmaW5lcyB0aGU8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2FwYWJpbGl0eSB2 YWx1ZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZT5JJ20gbm90IHN1cmUgdGhpcyBpcyByZXF1aXJlZCwgYnV0IHBlcmhhcHMgY29uc2lkZXIgYWRk aW5nIHRleHQgdG8gbWFrZSBpdCBjbGVhcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoYXQgbG9u Z2VzdCBwYXRoIG1hdGNoaW5nIGNhbiBiZSBhY2hpZXZlZCBieSBvcmRlcmluZyBtb3JlIHNwZWNp ZmljPG86cD48L286cD48L3ByZT4NCjxwcmU+bWF0Y2hlcyBiZWZvcmUgbGVzcyBzcGVjaWZpYyBt YXRjaGVzLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BRERFRCAmcXVvdDtOb3RlIHRoYXQgbG9uZ2VzdCBwYXRoIG1hdGNoaW5nIGNhbiBiZSBh Y2hpZXZlZCBieSBvcmRlcmluZyBtb3JlIHNwZWNpZmljIG1hdGNoZXMgYmVmb3JlIGxlc3Mgc3Bl Y2lmaWMgb25lcyZxdW90Ozxicj4NCnVuZGVyIDxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtsaXN0IHBlci1ub2RlLWNhcGFiaWxpdGllcyB7PG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRl c2NyaXB0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O0VhY2ggbGlzdCBlbnRyeSBzcGVj aWZpZXMgY2FwYWJpbGl0aWVzIGZvciB0aGUgc2VsZWN0ZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZGF0YSBub2Rlcy4gVGhlIHNhbWUgY2FwYWJpbGl0aWVzIGFwcGx5IGZvciB0aGUgZGF0 YSBub2RlczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbiB0aGUgc3VidHJlZSBiZWxvdyB0 aGUgc2VsZWN0ZWQgbm9kZXMuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBzeXN0ZW0gU0hBTEwgb3JkZXIgdGhlIGVudHJpZXMgYWNj b3JkaW5nIHRvIHRoZWlyPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByZWNlZGVuY2UuIFRo ZSBvcmRlciBvZiB0aGUgZW50cmllcyBNVVNUIE5PVCBjaGFuZ2UgdW5sZXNzPG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHRoZSB1bmRlcmx5aW5nIGNhcGFiaWxpdGllcyBhbHNvIGNoYW5nZS4m cXVvdDs7PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGRpZCBOT1Qg YWRkIG5leHQgdG8gJnF1b3Q7MikgSWYgdGhlIGRhdGFzdG9yZSBlbnRyeSBpcyBmb3VuZCB3aXRo aW4gdGhhdCBlbnRyeSAuLi4mcXVvdDsgYmVjYXVzZSB0aGF0IHNlY3Rpb24gZm9jdXNlcyBvbiB0 aGUgdXNlciAoYXMgb3Bwb3NlZCB0byB0aGUgaW1wbGVtZW50ZXIgb24gdGhlIHNlcnZlciksIGFz IG1lbnRpb25lZCBpbiAmcXVvdDtUbyBmaW5kIGEgY2FwYWJpbGl0eSB2YWx1ZSBmb3IgYSBzcGVj aWZpYyBkYXRhIG5vZGUNCiBpbiBhIDxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDtzcGVjaWZpYyBkYXRhc3RvcmUgdGhlIHVzZXIgU0hBTEw6JnF1b3Q7 PG86cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZT4xMS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgLy8gYXVnbWVu dGF0aW9uIHBvaW50IGZvciBzeXN0ZW0gbGV2ZWwgY2FwYWJpbGl0aWVzPG86cD48L286cD48L3By ZT4NCjxwcmU+U3VnZ2VzdDogJnF1b3Q7QXVnbWVudGF0aW9uIC4uLiBjYXBhYmlsaXRpZXMuJnF1 b3Q7Jm5ic3A7IEkgd291bGQgYWxzbyBzdWdnZXN0IHVzaW5nIGEgYmxvY2sgc3R5bGU8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5jb21tZW50IHNvIHRoaXMgZG9lc24ndCBnZXQgbG9zdC4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRPTkUuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3By ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+MTIuIDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO09ubHkgb25lIHNwZWNpZmljIGRhdGFzdG9yZSBjYW4gYmUgc3Bl Y2lmaWVkPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGUuZy4sIGRzOmNvbnZlbnRpb25hbCBp cyBub3QgYWxsb3dlZC4mcXVvdDs7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5TdWdnZXN0IGNoYW5naW5nIHRvOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPbmx5IHNwZWNpZmljIGRhdGFzdG9yZXMg Y2FuIGJlIHNwZWNpZmllZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IEUuZy4sIGRzOmNvbnZlbnRp b25hbCwgd2hpY2ggcmVwcmVzZW50cyBhPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyBzZXQgb2YgY29u ZmlndXJhdGlvbiBkYXRhc3RvcmVzLCBtdXN0IG5vdCBiZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsg dXNlZCZxdW90Ozs8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RE9ORTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjEzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlw dGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtBIG1ldGhvZCB0byBz ZWxlY3QgYWxsIG9yIHNvbWUgbm9kZXMgd2l0aGluIGEgZGF0YXN0b3JlLiZxdW90Ozs8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mcXVvdDtzb21l IG9yIGFsbCZxdW90OyB3b3VsZCBmbG93IGJldHRlci48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RE9ORTxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjE0LjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAvLyBhdWdtZW50YXRpb24gcG9pbnQgZm9yIGRhdGFzdG9yZSBvciBkYXRhIG5vZGUgbGV2ZWw8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgLy8gY2FwYWJpbGl0aWVzPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmU+U3VnZ2VzdDogJnF1b3Q7QXVnbWVudGF0aW9uIC4uLiBjYXBh YmlsaXRpZXMuJnF1b3Q7Jm5ic3A7IEkgd291bGQgYWxzbyBzdWdnZXN0IHVzaW5nIGEgYmxvY2sg c3R5bGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5jb21tZW50IHNvIHRoaXMgZG9lc24ndCBnZXQg bG9zdC48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RE9ORS48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZT4xNS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT41LjIuJm5ic3A7 IFlBTkcgTW9kdWxlIChpZXRmLW5vdGlmaWNhdGlvbi1jYXBhYmlsaXRpZXMpPG86cD48L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IC0gY2FwYWJpbGl0aWVzIHJlbGF0ZWQgdG8gdGhlIHRocm91Z2hwdXQg b2Ygbm90aWZpY2F0aW9uIGRhdGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgdGhlIHB1Ymxpc2hlciBjYW4gc3VwcG9ydC4gKE5vdGUgdGhhdCBm b3IgYSBzcGVjaWZpYzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBzdWJzY3JpcHRpb24gdGhlIHB1Ymxpc2hlciBNQVkgc3RpbGwgYWxsb3cgb25s eSBsb25nZXIgcGVyaW9kczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBvciBzbWFsbGVyIHVwZGF0ZXMgZGVwZW5kaW5nIG9uIGUuZy4sIGFjdHVh bCBsb2FkIGNvbmRpdGlvbnMuKTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiAmbmJzcDsgPG86cD48 L286cD48L3ByZT4NCjxwcmU+U3VnZ2VzdDogJnF1b3Q7ZGF0YSB0aGF0IHRoZSBwdWJsaXNoZXIm cXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7c3BlY2lmaWMgc3Vic2NyaXB0aW9uLCB0aGUmcXVv dDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgICZxdW90O3N0aWxsIGFsbG93JnF1b3Q7IC0mZ3Q7ICZxdW90O2FsbG93JnF1 b3Q7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O2UuZy4sIC0mZ3Q7ICZxdW90OywgZS5nLiwgJnF1b3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxv OnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ET05F Ljxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPiA8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT4xNi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYml0IGNvbmZpZy1jaGFuZ2Vz IHs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb248bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7VGhl IHB1Ymxpc2hlciBpcyBjYXBhYmxlIG9mIHNlbmRpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbm90aWZpY2F0aW9ucyBmb3IgJ2NvbmZp ZyBmYWxzZScgbm9kZXMgZm9yIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZWxldmFudCBzY29wZSBhbmQgc3Vic2NyaXB0aW9uIHR5 cGUuJnF1b3Q7OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JIHByZXN1bWUgdGhhdCB0aGlzIHNob3VsZCB0aGlz IGJlICdjb25maWcgdHJ1ZScgbm9kZXM/PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdPT0QgQ0FUQ0grPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+MTcuPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90 O1R5cGUgZm9yIGRlZmluaW5nIHdoZXRoZXIgJ29uLWNoYW5nZScgb3I8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJ3BlcmlvZGljJyBub3RpZmljYXRpb25zIGFyZSBzdXBwb3J0ZWQg J2NvbmZpZyBmYWxzZSc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGF0YSBub2Rl cywgJ2NvbmZpZyB0cnVlJyBkYXRlIG5vZGVzLCBubyBkYXRhIG5vZGVzLDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBvciBhbGwgZGF0YSBub2Rlcy48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4N CjxwcmU+U3VnZ2VzdDogJnF1b3Q7c3VwcG9ydGVkIGZvciAnY29uZmlnIGZhbHNlJyZxdW90Oyw8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJnF1b3Q7ZGF0ZSZxdW90OyAtJmd0OyAmcXVvdDtkYXRhPG86cD48L286 cD48L3ByZT4NCjxwcmU+QXMgYW4gb3B0aW9uYWwgbWlub3Igbml0LCBpdCBtaWdodCBiZSB3b3J0 aCBwdXR0aW5nICdhbGwnIGF0IHRoZSBiZWdpbm5pbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5v ZiB0aGUgbGlzdCByYXRoZXIgdGhhbiB0aGUgZW5kLjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2Nr cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ET05FLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjE4LjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtJbmRpY2F0ZXMgdGhlIG1pbmlt YWwgdXBkYXRlIHBlcmlvZCB0aGF0IGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHN1cHBvcnRlZCBmb3IgYSAncGVyaW9kaWMnIHN1YnNjcmlwdGlvbi48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgQSBzdWJzY3JpcHRpb24gcmVxdWVzdCB0byB0aGUgc2VsZWN0ZWQgZGF0 YTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBub2RlcyB3aXRo IGEgc21hbGxlciBwZXJpb2QgdGhhbiB3aGF0IHRoaXMgbGVhZjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzcGVjaWZpZXMgd2lsbCByZXN1bHQgaW4gYSAncGVy aW9kLXVuc3VwcG9ydGVkJyBlcnJvci4mcXVvdDs7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SXMgJnF1b3Q7d2lsbCByZXN1bHQmcXVvdDsgcmln aHQgaGVyZSwgb3Igc2hvdWxkIGl0IGJlICZxdW90O01BWSByZXN1bHQmcXVvdDsgb3IgJnF1b3Q7 aXMgbGlrZWx5IHRvIHJlc3VsdCZxdW90Oz88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JLmUuLCBp cyB0aGUgc2VydmVyIGd1YXJhbnRlZWluZyB0aGF0IGl0IHdvbid0IGhhbmRsZSBhIHNtYWxsZXIg dXBkYXRlIGZvciB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5naXZlbiBjYXBhYmlsaXR5IHVu ZGVyIGFueSBjaXJjdW1zdGFuY2U/Jm5ic3A7IFRoZSBzYW1lIHF1ZXN0aW9uIGFsc28gYXBwbGll czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRvIHRoZSAmcXVvdDtzdXBwb3J0ZWQtdXBkYXRlLXBl cmlvZCZxdW90Oy48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RE9ORS4gJnF1b3Q7aXMgbGlrZWx5IHRvIHJlc3VsdCZxdW90Ozxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PjE5LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtUaGUgY2hhbmdlIHR5cGVzIHRo YXQgY2FuIGJlIGV4Y2x1ZGVkIGluPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFlB TkctUHVzaCBzdWJzY3JpcHRpb25zLiZxdW90Ozs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPG86cD48L286cD48L3ByZT4NCjxwcmU+U3Vn Z2VzdCBhZGRpbmcgc29tZXRoaW5nIGxpa2UgJnF1b3Q7Zm9yIHRoZSBzZWxlY3RlZCBkYXRhIG5v ZGVzLiZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5ET05FPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCjxwcmU+MjAuPG86cD48L286cD48L3ByZT4NCjxwcmU+Ny4yLiZu YnNwOyBUaGUgWUFORyBNb2R1bGUgTmFtZXMgUmVnaXN0cnk8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgVGhpcyBkb2N1bWVu dCByZWdpc3RlcnMgdHdvIFlBTkcgbW9kdWxlcyBpbiB0aGUgWUFORyBNb2R1bGUgTmFtZXM8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgcmVnaXN0cnkuJm5ic3A7IEZvbGxvd2lu ZyB0aGUgZm9ybWF0IGluIFtSRkM3OTUwXSwgdGhlIHRoZSBmb2xsb3dpbmc8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgcmVnaXN0cmF0aW9ucyBhcmUgcmVxdWVzdGVkOjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5U aGlzIHNob3VsZCBiZSAoYWxvbmcgd2l0aCBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDIDYw MjApOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IHJlZ2lzdGVycyB0d28gWUFORyBtb2R1bGVzIGlu IHRoZSBZQU5HIE1vZHVsZSBOYW1lczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyByZWdpc3RyeSBbUkZDNjAyMF0uJm5ic3A7IEZvbGxvd2luZyB0aGUgZm9ybWF0IGluIFtSRkM2 MDIwXSwgdGhlIHRoZSBmb2xsb3dpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsgcmVnaXN0cmF0aW9ucyBhcmUgcmVxdWVzdGVkOjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2Nr cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ET05FLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjIxLjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjkuMi4mbmJzcDsgSW5mb3JtYXRpdmUgUmVmZXJlbmNlczxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyBbUkZDMzY4OF0mbmJzcDsgTWVhbGxpbmcsIE0uLCAmcXVvdDtUaGUgSUVURiBYTUwgUmVnaXN0 cnkmcXVvdDssIEJDUCA4MSwgUkZDIDM2ODgsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IERPSSAxMC4xNzQ4Ny9SRkMzNjg4LCBKYW51YXJ5IDIwMDQsPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8v d3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMzY4OCI+Jmx0O2h0dHBzOi8vd3d3LnJmYy1lZGl0 b3Iub3JnL2luZm8vcmZjMzY4OCZndDs8L2E+LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAgPG86cD48L286cD48L3ByZT4NCjxwcmU+VGhp cyBuZWVkcyB0byBiZSBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgKGZvciB0aGUgSUFOQSByZWdpc3Ry eSkgZGVmaW5pdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RE9ORTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxv OnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjIyLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFw cGVuZGl4IEEuJm5ic3A7IEluc3RhbmNlIGRhdGEgZXhhbXBsZSAjMTxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlN1Z2dlc3QgY2hhbmdpbmc6PG86 cD48L286cD48L3ByZT4NCjxwcmU+JnF1b3Q7dGhlIHJ1bm5pbmcsIGFuZCBvcGVyYXRpb25hbCBk YXRhc3RvcmVzJnF1b3Q7ID0mZ3Q7ICZxdW90O3RoZSBydW5uaW5nIGFuZCBvcGVyYXRpb25hbCBk YXRhc3RvcmVzJnF1b3Q7LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPicmcXVvdDtvbi1jaGFuZ2Um cXVvdDsgb25seScgLSZndDsgJyZxdW90O29uLWNoYW5nZSZxdW90Oywgb25seSc8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4ncmVwb3J0ZWQgJnF1b3Q7b24tY2hhbmdlJnF1b3Q7IGFzIHRoZXknIC0m Z3Q7ICdyZXBvcnRlZCAmcXVvdDtvbi1jaGFuZ2UmcXVvdDssIGFzIHRoZXknPG86cD48L286cD48 L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRPTkU8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZT4yMy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT49PT09PT09PT09IE5PVEU6ICdcJyBsaW5lIHdy YXBwaW5nIHBlciBCQ1AgWVlZIChSRkMgWVlZWSkgPT09PT09PT09PT08bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGlzIGNhbiBiZSB1cGRhdGVk IHRvICZxdW90O05PVEU6ICdcJyBsaW5lIHdyYXBwaW5nIHBlciBSRkMgODc5MiZxdW90Oy48bzpw PjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RE9ORTxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlPjI0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZxdW90O29ubHkgaGFzIHJ1bm5p bmcsIGFuZCBvcGVyYXRpb25hbCZxdW90OyAtJmd0OyAmcXVvdDtvbmx5IGhhcyBydW5uaW5nIGFu ZCBvcGVyYXRpb25hbCZxdW90OzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5ET05FLjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJl PjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjI1LjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyBmYWxzZSZxdW90OyBkYXRhIGZyb20gdGhlIG9wZXJhdGlv bmFsIGRhdGFzdG9yZS4gU3RhdGlzdGljcyBhcmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsgbm90IHJlcG9ydGVkIG9uLWNoYW5nZSBvbmx5IHR3byBpbXBvcnRhbnQg Y291bnRlcnMsIGZvciB0aGVzZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZu YnNwOyBhIHNtYWxsZXIgZGFtcGVuaW5nIHBlcmlvZCBpcyBwb3NzaWJsZS48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4gPG86cD48L286cD48L3ByZT4NCjxwcmU+U3VnZ2VzdDo8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4gZmFsc2UmcXVvdDsgZGF0YSBmcm9tIHRoZSBvcGVyYXRpb25hbCBkYXRhc3Rv cmUuIFN0YXRpc3RpY3MgYXJlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7IG5vdCByZXBvcnRlZCBvbi1jaGFuZ2UgZXhjZXB0IGZvciB0d28gaW1wb3J0YW50IGNvdW50 ZXJzLCB3aGVyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyBhIHNt YWxsIGRhbXBlbmluZyBwZXJpb2QgaXMgbWFuZGF0ZWQuPG86cD48L286cD48L3ByZT4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRPTkUuPGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+IDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlNwZWxsaW5nL2dyYW1t YXIgd2FybmluZ3MgKGdlbmVyYXRlZCBieSB0b29sKTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5Qb3RlbnRpYWxseSBpbmNvcnJlY3Qgc3BlbGxp bmdzOiBzaGVwZXJkcywgZ2V0Y29uZmlnPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmU+R3JhbW1hciBXYXJuaW5nczo8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5TZWN0aW9uOiAxLCBkcmFmdCB0ZXh0OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiBTZXJ2 ZXJzIGFuZC9vciBhIHB1Ymxpc2hlcnMgb2Z0ZW4gaGF2ZSBjYXBhYmlsaXRpZXMsIHZhbHVlcyBk ZXNjcmliaW5nIG9wZXJhdGlvbmFsIGJlaGF2aW9yLCB0aGF0IG5lZWQgdG8gYmUgY29udmV5ZWQg dG8gY2xpZW50cywgd2hpY2ggaXMgZW5hYmxlZCBieSB0aGUgWUFORyBtb2R1bGVzIGRlc2NyaWJl ZCBpbiB0aGlzIGRvY3VtZW50LiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5XYXJuaW5nOiZuYnNw OyBUaGUgcGx1cmFsIG5vdW4gJnF1b3Q7cHVibGlzaGVycyZxdW90OyBjYW5ub3QgYmUgdXNlZCB3 aXRoIHRoZSBhcnRpY2xlICZxdW90O2EmcXVvdDsuIERpZCB5b3UgbWVhbiBhIHB1Ymxpc2hlciBv ciBwdWJsaXNoZXJzPzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlN1Z2dlc3RlZCBjaGFuZ2U6Jm5i c3A7ICZxdW90O2EgcHVibGlzaGVyJnF1b3Q7PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRPTkU8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZT5TZWN0aW9uOiAxLCBkcmFmdCB0ZXh0OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl Pkl0IGlzIGEgZ29hbCBvZiB0aGlzIGRvY3VtZW50IHRvIHByb3ZpZGUgYSBjb21tb24gd2F5IG9m IHJlcHJlc2VudGluZyBzdWNoIGNhcGFiaWxpdGllcyBpbiBhIGZvcm1hdCB0aGF0IGlzOiA8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4tIHZlbmRvciBpbmRlcGVuZGVudDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPi0gbWFjaGluZSByZWFkYWJsZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0gYXZhaWxh YmxlIGluIGlkZW50aWNhbCBmb3JtYXQgYm90aCBhdCBpbXBsZW1lbnRhdGlvbi10aW1lIGFuZCBy dW4tdGltZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlPldhcm5pbmc6Jm5ic3A7IFRoaXMgd29yZCBpcyBub3JtYWxseSBzcGVsbGVkIHdpdGggaHlw aGVuLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlN1Z2dlc3RlZCBjaGFuZ2U6Jm5ic3A7ICZxdW90 O21hY2hpbmUtcmVhZGFibGUmcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RE9ORTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlNlY3Rpb246IDEsIGRyYWZ0IHRl eHQ6PG86cD48L286cD48L3ByZT4NCjxwcmU+SXQgaXMgYSBnb2FsIG9mIHRoaXMgZG9jdW1lbnQg dG8gcHJvdmlkZSBhIGNvbW1vbiB3YXkgb2YgcmVwcmVzZW50aW5nIHN1Y2ggY2FwYWJpbGl0aWVz IGluIGEgZm9ybWF0IHRoYXQgaXM6IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi0gdmVuZG9yIGlu ZGVwZW5kZW50PG86cD48L286cD48L3ByZT4NCjxwcmU+LSBtYWNoaW5lIHJlYWRhYmxlPG86cD48 L286cD48L3ByZT4NCjxwcmU+LSBhdmFpbGFibGUgaW4gaWRlbnRpY2FsIGZvcm1hdCBib3RoIGF0 IGltcGxlbWVudGF0aW9uLXRpbWUgYW5kIHJ1bi10aW1lPG86cD48L286cD48L3ByZT4NCjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+V2FybmluZzombmJzcDsgUGxlYXNlIGFkZCBh IHB1bmN0dWF0aW9uIG1hcmsgYXQgdGhlIGVuZCBvZiBwYXJhZ3JhcGguPG86cD48L286cD48L3By ZT4NCjxwcmU+U3VnZ2VzdGVkIGNoYW5nZTombmJzcDsgJnF1b3Q7cnVuLXRpbWUuJnF1b3Q7PG86 cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRPTkU8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv cHJlPg0KPHByZT5TZWN0aW9uOiAxLCBkcmFmdCB0ZXh0OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl Pk1vcmVvdmVyIHRoZSBkZWNpc2lvbiB0byBidXkgdGhlIG5vZGUgdHlwZSBzb21ldGltZXMgZGVw ZW5kcyBvbiB0aGVzZSBtYW5hZ2VtZW50IHBvc3NpYmlsaXRpZXMuIDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPldhcm5pbmc6Jm5ic3A7IERpZCB5b3UgZm9yZ2V0IGEgY29tbWEgYWZ0ZXIgYSBjb25q dW5jdGl2ZS9saW5raW5nIGFkdmVyYj88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TdWdnZXN0ZWQg Y2hhbmdlOiZuYnNwOyAmcXVvdDtNb3Jlb3ZlciwmcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RE9ORS48YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5TZWN0aW9u OiAxLjEsIGRyYWZ0IHRleHQ6PG86cD48L286cD48L3ByZT4NCjxwcmU+ICZxdW90O0ltcGxlbWVu dGF0aW9uLXRpbWUgaW5mb3JtYXRpb24mcXVvdDs6IEluZm9ybWF0aW9uIGFib3V0IHRoZSBzZXJ2 ZXIncyBiZWhhdmlvciB0aGF0IGlzIG1hZGUgYXZhaWxhYmxlIGR1cmluZyB0aGUgaW1wbGVtZW50 YXRpb24gb2YgdGhlIHNlcnZlciwgYXZhaWxhYmxlIGZyb20gYSBzb3VyY2Ugb3RoZXIgdGhlbiBh IHJ1bm5pbmcgc2VydmVyLiA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5XYXJuaW5nOiZuYnNwOyBE aWQgeW91IG1lYW4gb3RoZXIgdGhhbj88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TdWdnZXN0ZWQg Y2hhbmdlOiZuYnNwOyAmcXVvdDtvdGhlciB0aGFuJnF1b3Q7PG86cD48L286cD48L3ByZT4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRPTkUuPGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJz cDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+U2VjdGlv bjogMywgZHJhZnQgdGV4dDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGVzZSBpbmNsdWRlOiA8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4tIFN1cHBvcnRlZCAocmVwb3J0aW5nKSBwZXJpb2RzIGZv ciAmcXVvdDtwZXJpb2RpYyZxdW90OyBzdWJzY3JpcHRpb25zPG86cD48L286cD48L3ByZT4NCjxw cmU+LSBNYXhpbXVtIG51bWJlciBvZiBvYmplY3RzIHRoYXQgY2FuIGJlIHNlbnQgaW4gYW4gdXBk YXRlPG86cD48L286cD48L3ByZT4NCjxwcmU+LSBUaGUgc2V0IG9mIGRhdGFzdG9yZXMgb3IgZGF0 YSBub2RlcyBmb3Igd2hpY2ggJnF1b3Q7cGVyaW9kaWMmcXVvdDsgbm90aWZpY2F0aW9uIGlzIHN1 cHBvcnRlZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlPldhcm5pbmc6Jm5ic3A7IFBsZWFzZSBhZGQgYSBwdW5jdHVhdGlvbiBtYXJrIGF0IHRoZSBl bmQgb2YgcGFyYWdyYXBoLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlN1Z2dlc3RlZCBjaGFuZ2U6 Jm5ic3A7ICZxdW90O3N1cHBvcnRlZC4mcXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1 b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RE9ORTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlNlY3Rpb246IDcuMiwg ZHJhZnQgdGV4dDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Gb2xsb3dpbmcgdGhlIGZvcm1hdCBp biBbUkZDNzk1MF0sIHRoZSB0aGUgZm9sbG93aW5nIHJlZ2lzdHJhdGlvbnMgYXJlIHJlcXVlc3Rl ZDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5XYXJuaW5nOiZuYnNwOyBNYXliZSB5b3UgbmVlZCB0 byByZW1vdmUgb25lIGRldGVybWluZXIgc28gdGhhdCBvbmx5IHRoZSBvciB0aGUgaXMgbGVmdC48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5TdWdnZXN0ZWQgY2hhbmdlOiZuYnNwOyAmcXVvdDt0aGUm cXVvdDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RE9ORTxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlPlNlY3Rpb246IEFwcGVuZGl4IEMsIGRyYWZ0IHRleHQ6PG86cD48 L286cD48L3ByZT4NCjxwcmU+SW4gdGhpcyBsYXR0ZXIgY2FzZSBpdCBpcyByZWFsbHkgdGhlIHNl cnZlciBmdW5jdGlvbmFsaXR5IHRoYXQgaXMgZGlzY3Vzc2VkPG86cD48L286cD48L3ByZT4NCjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+V2FybmluZzombmJzcDsgUGxlYXNlIGFk ZCBhIHB1bmN0dWF0aW9uIG1hcmsgYXQgdGhlIGVuZCBvZiBwYXJhZ3JhcGguPG86cD48L286cD48 L3ByZT4NCjxwcmU+U3VnZ2VzdGVkIGNoYW5nZTombmJzcDsgJnF1b3Q7ZGlzY3Vzc2VkLiZxdW90 OzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5E T05FPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhhbmtzLDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPlJvYjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi48bzpwPjwvbzpwPjwv cHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM4PR11MB543811DFFCCCAA56FDCC2797B51C9DM4PR11MB5438namp_-- From nobody Mon Jul 5 04:52:50 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637993A148B; Mon, 5 Jul 2021 04:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7cs1ep6uPCR; Mon, 5 Jul 2021 04:52:39 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2124.outbound.protection.outlook.com [40.107.22.124]) (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 6F8843A1489; Mon, 5 Jul 2021 04:52:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Vdg0IvsFznf91ThZDRyZ34cYb+96+jmo09IQ0i/UR4uqLFdXgaW9ZAnxL7Ih+JIFuCipxWNPpTLApWfIW3OjVrFVgDXIsiEm33t9qRzSBG/w0GcJNovuUlJbj4PfP4deudhjnT7v95b+rWSdvibAWCikqadkFnCJkL8gMw5YaHcXm8jfTDagIXG2NMaUNOWnWdgoxsZcJeAImiNbxCmpuL/KTy5uNs5I9O+4BTizMjQHXfSY+bz4JvcPkCHSUYCPommOlBEU881Vn1QeyFIBbIaRH4OsWit9wx5+0Ld7euaME0UZME6phyQxxrVpsNDOgjdy6a/zglV8IeOH8gteDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y2990v6wB+d/kTrMgYtvMrhPd8kd+aXZ2IIrjMGw39Q=; b=FSYscT9yyUkK3I6+i/LC1hbWBFP3fOdfr4dmD3xS5H+U52g5wELHIku9E8tD2xJ9wxcVfLB4z21u4/Hkoxn7qPYqBjSlD2dTlzBMrpQ1+5UR0OA9X0QJ2VFs4jedXyBRICJyWJjPmn+dUSKrxhWLncvPjnPpvQ5R31TOLov1V4xH5CVl5LJ5Oxo65nssTEZxziFEzx3LLnubp2HSytJZ+WrxB3ARq+Lew3z0s6kpY16cRhgf1i/Z130Dosoy5SB010nW3G1TG9kkw2uDE9Ew4wl0yL1ZGX+loxwW+VDBWceMMO/aFdQ7uiGLSNTwRTM8CdsM9/Xl9VMyZZzqM/Jo/Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y2990v6wB+d/kTrMgYtvMrhPd8kd+aXZ2IIrjMGw39Q=; b=kveBa6y0AOUY8/M0+jnoaIw6EYcTLYdBatd7eqD3GyOJbmdM7ERcEtKawjLyeB3YrVr6AjSRs3n9YTbTo3zyghMztU16khLASqUgsuo1IXfgt+Yk6pQnTocGX+yXR5NE3GpnmpF4ndPqSyBjzrAle3gbvIS19Jkl+/CAAsMsmsI= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR0702MB3669.eurprd07.prod.outlook.com (2603:10a6:209:11::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.7; Mon, 5 Jul 2021 11:52:34 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::fc5d:ca7a:e2ea:ca9d]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::fc5d:ca7a:e2ea:ca9d%9]) with mapi id 15.20.4308.019; Mon, 5 Jul 2021 11:52:34 +0000 From: tom petch To: Michael Richardson , "anima@ietf.org" , "Rob Wilton (rwilton)" , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? Thread-Index: AQHXcSHiKTYF/jGkPkWzUxBfj3NVpaszdD2AgADNPgc= Date: Mon, 5 Jul 2021 11:52:34 +0000 Message-ID: References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> <10907.1625436805@localhost>,<29456.1625440861@localhost> In-Reply-To: <29456.1625440861@localhost> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=btconnect.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dd36e86f-2379-4998-6d65-08d93fab60f0 x-ms-traffictypediagnostic: AM6PR0702MB3669: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UtSOC5D8ChASgPPNyIwd0gUzcOtHovgFosgoCVg/ktRtBqVqJweK0YpOOZVho2nzQyh/sA5S5+dY7GXC5iVR/u0dxxLnnRfioAfPfA36Wx+QGjW1Ab8W6NpWF44RltoQ2Pw0hVWfrhghfFfgwGjKTjt6+z3mTsX7lJDuQmzykcgXnwyDVu7Y0gaHvZKoORcTIjzWzLYqp1U+KrdJnWC6nlH34O9LwP4MhY2t0CseNNXlK6bS4WPZOHIYUY8Y+29zOQ22Klt0D7uGfnUWE/ag4F9uOH/l/4tJn1USNLFMCDDPBkeUjNFQbmYOQmXXiDz1VS+aLj9H0k8vqiXbhBWCCY774hITjD8L6leRNEhF8bQ4RF1vULR8oP+jp7IKO2G+KAyWXUYzsk4l4Iirp5TjyLNkbwPeW+wWEye8CVZrNO6MGuFxpJedTivWP7eXwy3DIYDCirMN3nfr6EOUQVPQ63qEybZaFYJX12e6D1bTVUXoetltBNCfeA69PAVSEibWoQaLAKpfYcPYeMAeGavFfqShDzv8Ot0p1j2LeC4Fbv79BEjCkjoqVZjVV8a+R3I8bIYFBUTt/GPnHrNXm+OwMsMUQhQCGJzgMyFh18wuV7rJAKgwZtWaFKjOtfQt54T3hlJfpl+MWtec7p1awp2dDw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(366004)(39860400002)(396003)(136003)(110136005)(186003)(478600001)(6506007)(26005)(52536014)(83380400001)(8936002)(316002)(5660300002)(76116006)(66946007)(9686003)(66574015)(7696005)(122000001)(71200400001)(38100700002)(91956017)(33656002)(8676002)(55016002)(66446008)(64756008)(86362001)(2906002)(66556008)(66476007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?TLDC8KT6uCNTncNUpUC/IZwmiBC2gmndPJAmSJchxDeJW04rc8gH3ZoWAc?= =?iso-8859-1?Q?yS/Qd0+G3JqcXHThB8FOM4K8HSAO/4uC8vb6J9XlkWTNaOWUsUQi7m0+uM?= =?iso-8859-1?Q?dOEa3ZrKRcv1FMy4NzZ10mpVJQaRkikOMHaIneiKjkqN6GSGcpqKvmgBaQ?= =?iso-8859-1?Q?6/XrUL6nJQkT9LVYZx2NCCcZZ/p/Xj2P3aTi2dLs3296nDlzgPIbAYq/dc?= =?iso-8859-1?Q?vT4HZImjV4YPKnRLFJB1c1ATJLiYeylsSpmcD9kRSNjVaJcARkzwrjgweo?= =?iso-8859-1?Q?1Fr1mr++hSBlrk25NKDpS1QLmsPAq2GJODzCTa97qiIGChlho7c1qn4BGU?= =?iso-8859-1?Q?iSCMoRguvFVpbSdqt4+2tc3tElp64nGT/2oV+S4NtCX2gZ5qLqW31QoSgw?= =?iso-8859-1?Q?m1Ha7IPSUCnjqr/BaGcJGdpIpJvuLA/WENQBvb/RuazlGe/TqN5OGOn8W3?= =?iso-8859-1?Q?1/IXiHr9q/+f3BO4EwvGvUoYz86kBYAKvZpGyU1j8yndHmgKLa0caYRzYb?= =?iso-8859-1?Q?7zZVS7OuOPZB7rHunBwlL3LzbINo2ZGna3l5G8rzgfEDbAibMj5TEBhsfd?= =?iso-8859-1?Q?6mQZIYZRZr80Wl+VHqNShBHlfKyRPQcrr2Q1tesCsBT9SdftCu8xl3dpIm?= =?iso-8859-1?Q?dtVU/yqUPw82w3c0ZmjRhos3g+e536vnQ+u78ObOhF01+qGbIXqzs6N1eX?= =?iso-8859-1?Q?DV5C+tfi8buX90YSOGu89b7g3r2qq/9D+781HyvHpi6tkSNNkfbz8p5TSF?= =?iso-8859-1?Q?jlXBiiOqjA5WkLTUNXfnRCAaVD/S3LEoXCkd/pbdUsjzDjkEN9+Ng1Rn+z?= =?iso-8859-1?Q?5AFIARoG2IxEhyPpB9UJOLoddqQhsnYAjbKNRyC9dieosA7GZFz1N18eQw?= =?iso-8859-1?Q?9LUI3Ui+4uTzzF2gH/8nvHA9WyeQJO3FmzFmycehLRTp4apnLwAISTBJpe?= =?iso-8859-1?Q?C2GLf3VgFjLBJvXKi3U6w5yzQZoTLc16XEAuK7hVYL32D4QEPT6HgoSpCF?= =?iso-8859-1?Q?DLctlhUipHjui+Pysfi5FZTiT73v0AJjrz7gvrEPql61hIGQAxfegIzfQ/?= =?iso-8859-1?Q?DI0Z2ooIccHItE9Kk/mFPeDTH2VQ79SJ1isoa+2vtORo2kFSly58839qAx?= =?iso-8859-1?Q?MadHRUP2nlGpKgx+XwymmwCRju2Gdelelh54qr9fbF0aHFe52vC72NgYHx?= =?iso-8859-1?Q?ai509uL6wUqQgXzdbjukSLLfjaf/AfsSHIWqX/RPA+KcCVcqm5lg4XOtfP?= =?iso-8859-1?Q?KH+QYgC2VrdBjNOFIKOULC0O7r/dkv8F2eFWsTH7ToABhbF7+nkOTtbiFn?= =?iso-8859-1?Q?o6vWeZ1y9q6tjqDYuklK3iKsC4WAEOEYH4rK7ICtVIRei98=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dd36e86f-2379-4998-6d65-08d93fab60f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2021 11:52:34.7026 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iFPEw0HPQDjdogF+W9xZYg6wRBd1z6YXJqNymCaMQODAUAGQhPrWSsP8nhz12gELbBeEkMXM1lvoAF3yK1vM4A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0702MB3669 Archived-At: Subject: Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 11:52:45 -0000 From: netmod on behalf of Michael Richardson =0A= Sent: 05 July 2021 00:21=0A= =0A= Michael Richardson wrote:=0A= > I propose that the WG adopt this as the -00, and then we change the d= ocument=0A= > to change this into an RFC7224-style IANA-maintained YANG module.=0A= > (In DHC WG, when we did RFC3315bis to make RFC8415 we did a -00 which= was=0A= > whitespace equivalent to RFC3315 first, and then we amended it)=0A= =0A= > As I understand it, we would be creating a Registry with IANA Conside= rations,=0A= > and when documents extend the Registry, that IANA writes a new YANG m= odule=0A= > (with a new date) for us.=0A= =0A= > I believe that given that the module gets revised, that we don't have= to=0A= > worry about enumeration vs leaf/choice/empty. But, if there is some= =0A= > advantage to doing it the non-enumeration way, it would be good to un= derstand=0A= > that.=0A= =0A= But, we might want to do a WG Consensus call on the differences.=0A= We might also want to ask a YANG Doctor to come to the ANIMA WG meeting=0A= at the end of the Month, to explain the differences.=0A= =0A= =0A= I would love to know what the problem is (rather than possible solutions to= potential problems:-)=0A= =0A= enum and identity are solutions with different characteristics as others ha= ve spelt out. Which is better depends on the problem, how easy it should b= e to make changes or to prevent people from making changes:-)=0A= =0A= Likewise involving IANA. They maintain registries which anyone can access.= They perform updates, on request, according to the policy of the registry= , which is set when the registry is set up and can range from requiring a S= tandards Track RFC to First Come First Served, depending on how easy you wa= nt it to be to make changes. See 'IANA Considerations' RFC for the range o= f options. And they can turn updates to a registry into an update to a cod= e module (such as an SMI MIB). =0A= =0A= So the IANA Considerations section in an RFC creates the registry but what = it takes to update it varies depending on what they say.=0A= =0A= What I am missing is how easy or difficult you want it to be to make change= s, who will make changes, (IETF only, another SDO, a manufacturer ....), wh= at review you want for changes by whom, how frequent changes will be (usual= ly a guess and usually wrong but it helps to have the assumptions about the= requirements spelt out) and such like.=0A= =0A= As an engineer, I do like to know the requirements before working on the de= sign!=0A= =0A= Tom Petch=0A= --=0A= Michael Richardson . o O ( IPv6 I=F8T consulting = )=0A= Sandelman Software Works Inc, Ottawa and Worldwide=0A= From nobody Mon Jul 5 05:47:23 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2813A167A for ; Mon, 5 Jul 2021 05:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qr5XRc10sXWK for ; Mon, 5 Jul 2021 05:47:17 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2056.outbound.protection.outlook.com [40.107.20.56]) (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 0EB543A1679 for ; Mon, 5 Jul 2021 05:47:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RAvNArJEfxkZjLLlDmmW9n6jS8fcrv8orM+lED+yrKVuquDPkVlGFbwyhbVq3MQ07iG9Gtud0rwREUvpME1hTWYIBjLekyDWPHSWOTcRcQfsElR+HlAMNF2rnfmO4xs6DAKOlATNFM/hGg6XzQP2V8egBRRGDm0fZAchMrluY8bGluquCQQef2ea/YnaizexlZhSubZbQKbicVhN11mGKIFJQhqx6d6ci481TJ6ZOQ3Bd4dQHD3EaVoFPiUJlYZyyw2SMFxhq/J3ROeL7Aw5hu5IrqrxoAj7TU6u6Pyl6uIIeE1tdQ2q8Bs5hJdx6lPZSr126LywHt4aYSM+xUVidg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Aa3iyyKkNTpddnFG2fNNji3TNXpzHJXzwayVWZ1sIsA=; b=E1x7FSIfj+I1s0mSPDuiCK9Oy5OaBmXajvecNyfNpWWqtZ4yO1GGxQ0wUQjeHZGZmOJrjhHO8ZaC2JYNqFX3Z+eAVfVQEqw5bycjFZVAebhJGkDrrRE/MbUgKFs80CMAZo0/m/Mdj1icXdNRDlS/moB3dPB42f553692F/WfyicyX0MUWoPrQrEWcPUF/0Sr6IzRNH6lywDsTwZSk2cfUeMq6RLcez+YFAzYoENoXG6tbTKNrDpQ8ibePArZFiKHQVUWpsiQM1YPIPQfbHYhSJSL4k0dtW0KWYvOv8pKJImP8PiyfOMtxL17k2c2qfEPVbZyr61gbibtCpRYUL1vRw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Aa3iyyKkNTpddnFG2fNNji3TNXpzHJXzwayVWZ1sIsA=; b=lUGD9hovvor2f6rpa74BrvwIzqDTy8AGR16Xfd5D/JQKKKMBrOgg4q0oBNNIy9SPeg3S2dK0HtPH0VEcZmK3oXl+g1ZsgRR/LjeICxUP4vZz5xFxxlav9bMBoZz23UeA5oolVY35mdH4Gmk9Vvf8Ohb2MvrpDnaf403qw4Xz8rk= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8124.eurprd07.prod.outlook.com (2603:10a6:20b:36f::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.7; Mon, 5 Jul 2021 12:47:14 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4308.018; Mon, 5 Jul 2021 12:47:14 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: "'netmod@ietf.org'" , "Rob Wilton (rwilton)" Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfA= Date: Mon, 5 Jul 2021 12:47:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4ecebd56-7011-4929-6564-08d93fb30383 x-ms-traffictypediagnostic: AM8PR07MB8124: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sgDzsTFV4WtWFJ4WPBykBvCeHpgE728ngKHUtNdiDYwrxB/yNrpZTDeDYYMOmxEugjM7NV1JG7utV+THSZduUjDwcWZbfe7iPwMkh4A07n9EWG/W+cRNmqIjZJliYoAXjfHMjmTwJKdhrSMXZN8ZXaY5odncHstfq4Jj+wjVEWIWOQ+zQ9XRl0hqP84dgYfRup7Q/vC/Qv4kocsWk+eBsy8vdOSRZ1J6e7fv1H/WPeM4yulnuyrtH5ogaJVBJZo6pD/1dUt0frWBsHt5a/jQYLIb0H+6CKerFp8/Ixxzzf9oaWs/tK26Tu0jmnBdVymuDzxmvDATu714WKb5KiXLrJEmAp7012tzcDay6T8tGS6VQKpHhYsz6VfbXs5xrkwFiJDREJGstVKrIS7x3mQzzOUGvLcKhz3/ZWil5oYbisgHC7/a8flb4u1HVvSgEYsTmeCbSHsWgqu3UCM62CfGGq+wRC6yJBtLDds65B7HZwrUY0mApKD4G2CzkOh4vrBA0I3jvubEOsm5vzpMaCbynBL250xSacNrZWoG41nDm0w3f5YphFZF2N7i9Iw9x4vOvxoEoBqwlq0LqkgvfAfkOMTc3W3fp2N22zkfij44LO76kwaUTnj9I9ZoniQUTGejc1yZ5xxzNYpVSAzUGEWR0RygmJTVttEzPmP0AlZEJrRgAw+3Esjy5fe1rBfznnnxiQTsOnAabIAkNK/tC0qvPw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(366004)(346002)(376002)(39860400002)(110136005)(7696005)(9686003)(55016002)(8936002)(8676002)(66556008)(66476007)(66946007)(5660300002)(66616009)(4326008)(26005)(64756008)(186003)(33656002)(86362001)(316002)(83380400001)(52536014)(99936003)(38100700002)(2906002)(478600001)(122000001)(76116006)(30864003)(66446008)(6506007)(71200400001)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?I4prP2LhPFABgqtK8V/rysKc4WVgDDclvQ/jLYdALElMrPmyLHm282qMxC?= =?iso-8859-1?Q?KhpakdHGoDkC7HpWwjPS9Lg5eu+zA/5DEeiIR4eu33SfxIV9UM5AbrDKhM?= =?iso-8859-1?Q?cVBvMpa7OELMR7KHZ/DdHZLtH8WigmzZiUn7iaw12PHmxby9q96VeT6wkI?= =?iso-8859-1?Q?6FkgOcpaC3TFX9deE6IpFTgmPqILOdSE0x6s1euasVhiPm0NABgOkPxUiP?= =?iso-8859-1?Q?0XTU/zXiOI3CpdZXvrXRl0Pw6zxxYnoOVO7ektJsilFKH5yxVK+AJ9ITED?= =?iso-8859-1?Q?SnfU9w190RwuxpnRafYwNQ0iFPbLxiNZwgQ7MDxOAiNOOl1/0wPWV3GPXr?= =?iso-8859-1?Q?EqB8OIDTLHwSFBOE6lkCy64Pwnw9DE+i4VjT1+ZAyDkAm7+ixaxaeuLvEn?= =?iso-8859-1?Q?fEEzLsSx9dih8pnP4lJi4rIEXj8Ia/YMp3u1ZrryXo/2KXOQfBg3DONQXO?= =?iso-8859-1?Q?o2wNEZM06JlwjDstw0kBmBa/IK8BVzR0k5lM4vm/eeNCFICa+90lFXR28y?= =?iso-8859-1?Q?ZvnWMNa13QMrod3W6zWVH+Jx74ukIGkVgYfuarK4Mj0hgFlAiE7dnINM3J?= =?iso-8859-1?Q?w2SXY7/sXpbNMJlWXe1zkX89B44kLyVqF0yuHOrWbx72qzaTArbhgW54yX?= =?iso-8859-1?Q?aljgj6VJdyIfNFK5i76CBdbPgDtiebMoYp0wRf53C9t8w4UvzASc3FfAZE?= =?iso-8859-1?Q?/YJyNXGVFV9gaqZruMxLTcQ6pFOB+T+UM2JEH0Q8kL7LuiEl/+sbogMSb8?= =?iso-8859-1?Q?yvFkxwpsqJutVb7p2iWt7f996Aqdu5Dt0V1O35piVukFbjbldY97voX5Bq?= =?iso-8859-1?Q?8YA/QaWrvrITldMv55t9YjdVMWz1xg12cu+na82je3SjW7tfdl3YgNL/8P?= =?iso-8859-1?Q?Ibc8EEEQQP/4P7MhSlimYUnzgLecTh37zqVgeaFShi00QYht25+nyWugAZ?= =?iso-8859-1?Q?v/bbFPhVuUp/dVaCeExDfZPoAsTXwwGhpQ4sQ/VqLa3ZjFuqnqu5ew+gQU?= =?iso-8859-1?Q?m5P234G1sHUi7Q+D38xn3xQqWR9Qp+rgTpxUir/INNCkUA8cJeURmQGQOn?= =?iso-8859-1?Q?zsJfcDkMwM5R3qxIXFh3K1NNPWn8AU7sNY7crbKefMxuqQHhhqsStxIQ95?= =?iso-8859-1?Q?6gux3aVcPX5O3QL5zcakd1OWZBeBaQXpe8yjv6QQV4YOg2aaMDCG5PA/wd?= =?iso-8859-1?Q?UUgT0/ZFSCUFevHtkg1BDifqx70FMkTRB/vgbi3aNhNG7gr6kh9Dl+zUdU?= =?iso-8859-1?Q?DohdpXeUoUI2GfF3oQ8eL/YBRNtmWuezrhqgfapdnz9pGM3Va3w9GsKebc?= =?iso-8859-1?Q?9mIZNxSB+DOXcpMXBvh/zBVvnbJ0r2xKnFa4QcQndTvZQPEfuKH/+c9t0z?= =?iso-8859-1?Q?bE1BRMD2kd?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0283_01D771AC.A37C1290" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4ecebd56-7011-4929-6564-08d93fb30383 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2021 12:47:13.9487 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 30tqcUcxp8tzUw2mXRIDntQ4vcZUIeHjoPF8Nx7o2bilkHWnyGC8TwZlvebp0Fa4c2DRD+/GJHVEazbNK2tVg5pVw5rbNAeKbdOI0ZWl1Xo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8124 Archived-At: Subject: [netmod] FW: AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 12:47:22 -0000 ------=_NextPart_000_0283_01D771AC.A37C1290 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello Rob, Thanks for the review. Here are my answers below. I will also upload the new version asap. Regards Balazs ----------------------------------------------------------- Hi, Here is my AD review of draft-ietf-netmod-yang-instance-file-format-13. Thanks for this document, I think that it represents important useful work for advancing the YANG ecosystem. This document is in good shape, and I mostly have minor comments but with a few more significant comments. Main comments: 1. An instance data set MAY contain data for any number of YANG modules; if needed it MAY carry the complete configuration and state data for a server. Default values SHOULD NOT be included. This document recommends that default values SHOULD NOT be included, but there are cases where they are useful, and e.g., NMDA recommends that "in-use" values (effectively including default values) are returned. Further, there is no way for a consumer of the file to know whether default values are included or not. Hence, I would recommend that the instance-data-set defines an "includes-defaults" leaf that indicates whether default values are included in the dataset, the leaf can default to them not being included in the dataset. Further, I would suggest weakening "Default values SHOULD NOT be included" to something like: "Default values should be excluded where they do not provide additional useful data." BALAZS: Section 2 states that a default attribute may be specified, following the with-defaults capability. However, your proposal is better. I will include it. Added leaf includes-defaults. 2. In the YANG Module: feature inline-content-schema { description "This feature indicates that inline content-schema option is supported. Support for this feature might be documented only via out-of-band documentation."; } What is the benefit of having 'inline-content-schema' as a feature? It seems to potentially add complexity without any benefit, given that the device originating the instance data file would effectively choose whether to use the inline-content-schema, hence I suggest that it might be simpler just to remove the feature definition. BALAZS: This was explicitly requested earlier by a reviewer (Andy ?). The system can declare supported/not-supported in design documentation. In a use-case when a client or a design department is sending data to a server this is needed. E.g. in UC2, Preloading Default Configuration the designer preparing instance data, can decide to use or not use the inline-content-schema based on this. 3. In the YANG Module: "case inline", description: The first item is either ietf-yang-library or some other YANG module that contains a list of YANG modules with their name, revision-date, supported-features, and deviations. The usage of revision '2019-01-04' of the 'ietf-yang-library' module MUST be supported. Using other modules, module versions MAY also be supported. This seems to make interop for consumers of instance data files hard, since the schema can be defined by any arbitrary YANG module without updating this module. I would suggest that it is safer to limit this to the two currently published versions of YANG library. BALAZS: I fully agree, however this was explicitly requested by some reviewer earlier (Juergen ?) Shall I simplify this or not? If additional modules are supported in future, then I think that it would be safer to create a new version of this YANG module that documents what other module formats can be used. 4. In the YANG Module: list "revision" Is revision expected to be unique, if provided? If so, should this be explicitly stated in the YANG module description? BALAZS: I don't think I understand your comment. There may be multiple list entries for revision. The 'leaf date' is a key, so it is inherently unique. The description may or may not be unique. 5. In the YANG Module: Is an instance-data file allowed to contain both a revision and also a timestamp? If so, is there any constraints on the values. If not, then would it make sense to put them under a choice? BALAZS: It is allowed to have both. There is some recommendation text about when to use each. However I can see some corner cases, when using both in the same file would be useful, E.g. we want a timestamp including hour, minutes, but we also want the history of the instance data set, including multible revision/descriptions. I propose to add: if both are included the timestamp, SHOULD contain the same date as the latest revision statement. 6. References: - RFC 6020 needs to be normative for the IANA YANG module registration. BALAZS: OK Minor comments: 7. Abstract: There is a need to document data defined in YANG models when a live server is unavailable. Data is often needed at design or implementation time or needed when a live running server is unavailable. This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models, and annotates it with metadata. I suggest combining the first 2 sentences to: There is a need to document data defined in YANG models at design, implementation time or when a live server is unavailable. BALAZS: OK 8. Sec 1. Introduction: I suggest tweaking 2nd sentence to: Data is often needed at design, implementation time, or when a live running server is unavailable. BALAZS: OK 9. Sec 2. Instance Data File Format: o a default attribute as defined in [RFC6243] section 6. and in [RFC8040] section 4.8.9. I would suggest putting default in quotes. E.g., "a 'default' attribute, as defined ...". BALAZS: OK For the two other bullets in the list, it might read better as "metadata, as defined ..." and "origin metadata, as specified ..." BALAZS: OK 10. Sec 2. Instance Data File Format: instance-data-set-name ['@' ( revision-date / timestamp ) ] (i) Possibly helpful to clarify that the revision-date and timestamp take the same format as they are encoded in the equivalent leaves in the YANG file. (ii) Would it be helpful to include an example without a revision-date? (iii) I also note that no recommendation is made as to whether a date or timestamp is included (which I think is okay). BALAZS: OK, Added text for (i). Added example for (ii) 11. Sec: 2.2 Examples (i) Should the module name start with example-acme-system-ext and acme.example.com BALAZS: IMHO the use of "acme" as a company name already indicates this is an example. "E.g." and the word "example" is also included in the text in a number of places. (ii) Would it be helpful for some/all of the examples to also give the filename that they would be expected to use? BALAZS: OK. Actually, they already have filenames, but it is only visible in the XML not in the TXT format. If you export the files with rfcstrip these filenames will be used. I added the filenames into the text too. 12. YANG Module: (i) I note that the module only indicates Balazs as an author and not Benoit (which differs from the draft authors). BALAZS: OK. added Benoit (ii) "format-version" Please ensure that there is an RFC editor note to update this value if the module gets changed in anyway during reviews or RFC editor process. BALAZS: OK. added (iii) "case simplified-inline", description: The value SHALL start with the module name. If the module contains a revision statement the revision date SHALL be included in the leaf-list entry. If other methods (e.g., revision-label) are defined to identify individual module revisions those MAY be used instead of using a revision date. I wonder whether it would be clearer to merge the second and third sentences into one: The value SHALL start with the module name. If the module contains a revision statement the revision date SHALL be included in the leaf-list entry, unless other methods (e.g., revision-label) are defined to identify individual module revisions, when those MAY be used instead of using a revision date. If you agree to this change, then please update the equivalent text in the inline case as well. BALAZS: OK, changed (iv) Should the example version of YANG library used match the mandatory to support version (in the YANG module)? BALAZS: OK, changed. But I will still use the old modules-state branch because its simpler (v) I also note that the content schema case statement order differs from how they are described earlier in the document. Does it make sense to align them? Is one of the content-schema-specs the default approach, i.e., does it make sense to specify a default for the choice statement? BALAZS: IMO default should not be specified. In chapter 2.1 we have: "External Method: Do not include the "content-schema" node; the user needs to obtain the information through external documents." In this case, none of the "cases" are used. Reordered items in section 2.1. IMHO the simplified inline will be the most used method. 13. IANA section 5.2. YANG Module Name Registration This document registers one YANG module in the YANG Module Names registry [RFC6020]. Please change to: This document registers a YANG module in the YANG Module Names registry [RFC6020]. Following the format in [RFC6020], the following registrations are requested: BALAZS: OK, changed Grammar Warnings (generated, by tool): Section: 2, draft text: Later as other YANG encodings (e.g., CBOR) are defined, further instance data formats may be specified. Warning: Comparison requires than, not 'then' nor 'as'. Suggested change: "Later, as other ..." BALAZS: OK Section: 2.1.1, draft text: The anydata inline-schema carries instance data (conforming to the inline-modules) that actually specifies the content defining YANG modules including revision, supported features, deviations and any relevant additional data (e.g., revision labels, described by [REF]) as alternative to the revision date). Warning: Unpaired symbol: '(' seems to be missing BALAZS: OK, actually there was one to many ")" Section: 4, draft text: Because of this the the security considerations template for YANG models in section 3.7.1 in [REF] is not followed. Warning: Maybe you need to remove one determiner so that only the or the is left. Suggested change: "the" BALAZS: OK Section: 4, draft text: Depending on the nature of the instance data, instance data files MAY need to be handled in a secure way. Warning: Consider replacing this phrase with the adverb securely to avoid wordiness. Suggested change: "securely" BALAZS: OK Section: C.1, draft text: Server capabilities include: - data defined in "ietf-yang-library": YANG modules, submodules, features, deviations, schema-mounts, and datastores supported ([REF]) - alarms supported ([REF]) - data nodes and subtrees that support or do not support on-change notifications ([REF]) - netconf-capabilities in ietf-netconf-monitoring Warning: Please add a punctuation mark at the end of paragraph. Suggested change: "ietf-netconf-monitoring." BALAZS: OK Thanks, Rob ------=_NextPart_000_0283_01D771AC.A37C1290 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDcwNTEyNDcxMlowIwYJKoZIhvcNAQkEMRYEFB1r4krckobE VYDYuYzkOVazc5HqMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBADej 1AYoMqCGs5aetWFm7hzcC23UYGEsimnl6hz19ID4oOrpPvHZ+MC+PogdhTSIw3C4OQTJrlI5ljFp EfD0LNhs72yhOjDbKdozO3H95wRRH5fv50g1vslKqLxyWkwIs+trjhwB7qVXKou1MUg6PkUVM5ws NnND0NcOHskBPasqsfd1YDHT6qAi2hK40J2oFW5mQCXUZw/YAqO0pPFyIIq7ZW2SeclEzMInx+C2 FbYccpGcPYrfIYV5pQwOc1tjd5sc5iPOSAKaRJWUonvk+wWNwdyHSdF6A53JLdJ63DhLvlkJMIzF EujAwJwU1qFS2cp1PiNY/h0rM1abhFrnaQ0AAAAAAAA= ------=_NextPart_000_0283_01D771AC.A37C1290-- From nobody Mon Jul 5 05:59:55 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F743A16E8; Mon, 5 Jul 2021 05:59:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <162548999330.17420.14830627557819693639@ietfa.amsl.com> Date: Mon, 05 Jul 2021 05:59:53 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-14.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 12:59:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : YANG Instance Data File Format Authors : Balazs Lengyel Benoit Claise Filename : draft-ietf-netmod-yang-instance-file-format-14.txt Pages : 29 Date : 2021-07-05 Abstract: There is a need to document data defined in YANG models at design, implementation time or when a live server is unavailable. This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models, and annotates it with metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 5 08:18:06 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EC93A1B2A; Mon, 5 Jul 2021 08:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZZuB9SEsxB2; Mon, 5 Jul 2021 08:18:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574703A1AFB; Mon, 5 Jul 2021 08:18:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id DF8C438A91; Mon, 5 Jul 2021 11:20:21 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ee6scW3Xq-k1; Mon, 5 Jul 2021 11:20:18 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C479338A58; Mon, 5 Jul 2021 11:20:18 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2E0C186F; Mon, 5 Jul 2021 11:17:54 -0400 (EDT) From: Michael Richardson To: tom petch , "anima\@ietf.org" , "Rob Wilton \(rwilton\)" , Juergen Schoenwaelder , "netmod\@ietf.org" In-Reply-To: References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> <10907.1625436805@localhost>, <29456.1625440861@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 15:18:05 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable tp> Likewise involving IANA. They maintain registries which anyone can tp> access. They perform updates, on request, according to the policy = of tp> the registry, which is set when the registry is set up and can range tp> from requiring a Standards Track RFC to First Come First Served, tp> depending on how easy you want it to be to make changes. See 'IANA tp> Considerations' RFC for the range of options. And they can turn tp> updates to a registry into an update to a code module (such as an S= MI tp> MIB). Probably Standards Track RFC to update the voucher types. tp> What I am missing is how easy or difficult you want it to be to make tp> changes, who will make changes, (IETF only, another SDO, a manufact= urer tp> ....), what review you want for changes by whom, how frequent chang= es tp> will be (usually a guess and usually wrong but it helps to have the tp> assumptions about the requirements spelt out) and such like. tp> As an engineer, I do like to know the requirements before working o= n the design! We need to be able to write RFCs that extend the voucher types. Not that often though. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDjIqEACgkQgItw+93Q 3WXMvAf/dONfZ9UsbBI6qZZ+8mMNYVYuGbCF4X3p4XJ0uCGq7/J8HYQYCOX60VZn qNVD5DaY34kn86FBAhHRWfj7aRyg1K42vxuaFUz2u2W7fzZ5VwdMmgyILjx2S8AD WuhAa559LThhqqEPRRfoYaDVd2+neWJgz4GzS3oQgq/bAd5KS9K6+PZKtkxJTBuC UCZCZJDV+krFA3SCoOFIRwhJXPY23iIdxBbFRvjl1DVLmg7xMeSwBqT3WZ+XfGaX JfG1p9tLIsA4saMzUrIN6TkHjpW2W3EEALYKH/TOJUbhiDDejOThpVOvfWrlTsNR eL3GNZAu4lfYSwlgTbLqAnXe44NWxA== =A1Ia -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 5 09:13:47 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0D63A1CFC; Mon, 5 Jul 2021 09:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OICcHsW3uvkD; Mon, 5 Jul 2021 09:13:39 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2092.outbound.protection.outlook.com [40.107.21.92]) (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 D60B13A1CEC; Mon, 5 Jul 2021 09:13:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eLX4NMixMP6gYSne1J2iFm3zjx6SDonoQgoh37ArnxNikmVDFrSJnbx6W5tKBosIcIuPtwgCjLKS6DtWHHeGaZhoKrCuoXm5tp1BtoQ30KJ+wDndtu/DnM/86oUko5U+SMBm5rHW1nSHeqqFhehZn29xlS6ciho+97nWdPEMP5QLVjaUQcpimPxINXvuJgNJHHmnJJINH8BfSPjq5nd2+oWoAsGdKW5PPdU3fkPcjGNTJ0QTRY6ZHW3vzsbya0M+ONTA6Of7fZc+oqDM5IVH88fqj60srnQ4kRYi+0U8wlCD33tNn6SGL8UdnTJhwhLMWZzCSLC31lorybYsZ0S6pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vIRWAIa8bef9muCqjdEgeDEF7wRo//+jH46YkKtI8QA=; b=EcriSKSuL0nenSPVKYNQRiSbeBFneNjjWeZFsLf5nRuM+qUiPVrpKlvcMmpIbR3muGRpcAiPzwtgqvTkR32P02YA5PZDGjG5+1H9l8jBF5hu7/ZJzEKKIV9aZ4h/7AkO3OT1rDRyw0lEP5NJ3i4qBjbNTluvOTMCNMNVVBzA+2KMKDejiCwhgkHgxGE4wWffthePm8oDbW79zz5nDjXT/qk6ew3qwLeqlVrEhWBdndmAxiAX1cMHLZl2RQDLw57kFj70a5G1vG7YrSs+tBLU94Rl0zG3SEu9ow5QlbVzygE2LDYRzE8vo8u7xZgY7pfSE0oAejnyH+d2XWZtCgBtAg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vIRWAIa8bef9muCqjdEgeDEF7wRo//+jH46YkKtI8QA=; b=MZ53UZu1jOCUzIi8NiN1c0YwlFuWjCneCG0UJSzObT34mHON/ul2yH135rRpjkf+NTmfuow2xztvoD0jmIgYRfUkFStOywz/Lk829DGtqs47ooQ5K6c3+G2LvTZR546J5w5ADuy3F/haSm0UMqdv7fJWDYno6ouColBIpcJQw+U= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR07MB5142.eurprd07.prod.outlook.com (2603:10a6:20b:3f::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.8; Mon, 5 Jul 2021 16:13:36 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::fc5d:ca7a:e2ea:ca9d]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::fc5d:ca7a:e2ea:ca9d%9]) with mapi id 15.20.4308.019; Mon, 5 Jul 2021 16:13:36 +0000 From: tom petch To: Michael Richardson , "anima@ietf.org" , "Rob Wilton (rwilton)" , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? Thread-Index: AQHXcbMbXBq0wbK1vEGnorzfRBCN2Q== Date: Mon, 5 Jul 2021 16:13:36 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=btconnect.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3d811d1c-e1f3-4bce-0923-08d93fcfd7d5 x-ms-traffictypediagnostic: AM6PR07MB5142: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8i4D1y01a7e2s64+byTAxPPL5gDM8rS6/oYqI3kBNrU+984PfoxubXzfBbbJqPbbS6ZZ/6BBlRO6hKt/m6+7uKJuIDLGpTj3+FW/IojN4pQ42MLT4sMvlmn3Q6OOSwXZuhY1X6g+tphfAHljcUR047Gmk/tKRfySnZVqDVL+w8+Yz4aPlt6MpyJz8ypLH7aOHcXBb77lzc8kwsc+360IbvjCUESLSpQEVnWukLXZqcJqjvdzniFa5tAl8x+FSSFLa0AL5T8o/L2eStG4SKkbM43JBIVbcCHmx8Iz3m/kR2B/SQy6IrkGTw4eykrYTIMzMY7cUqEjlGEAXlUg0Vvg4vSD2n+5YrfhXNsiIx3A9GQ9wA3K7o29zmInKCqaxswknyARckjn43lTegL079meokYFaL/1fHXv1nrHMryAqCDcnCcQAdaYoKBYt4rMPPf+vaU+BotM8Z0xxSG03xAo6HVaGWBNpdAanfTtrvp4BiUtHUHu8MV8kGvTIoVInLBNcwdVOraH7y3lAwnuWziBVQm4LPdJnY0r57o6166lGP7iTRWxvslWL5qR6HsCyuFcQ9cen5Bj1asR6UazURLn99Zb9sZMT8EdJ60rF1SyWYNI4+k3LEpfa2O13baibHv4DXe+Qa6Q8QKxlQecR4A/9Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(66574015)(8936002)(52536014)(86362001)(110136005)(91956017)(8676002)(64756008)(66446008)(26005)(186003)(55016002)(66946007)(66556008)(38100700002)(66476007)(76116006)(498600001)(122000001)(2906002)(7696005)(5660300002)(83380400001)(71200400001)(33656002)(9686003)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?gy/CAGLnx0LIFJsc/V1kZpGDROs5b4JnXmkR03G6UZzmA9NBxbKj6L3UD8?= =?iso-8859-1?Q?WZ1Xm0UhMOnn/O38vPNL86gn6qQR38HVmuYSQh9NlenmGG/1IaCgCs9PlR?= =?iso-8859-1?Q?WR7tUlXyKWz8FmueRHf3awUvYlMAHasX8VpymYiRCk/MVgCVECF9KuaBCu?= =?iso-8859-1?Q?hS0JuNtNCvjoneRnB3973l/DZC52YJRQTENU635awN+MwvcT72MyS+I8Ci?= =?iso-8859-1?Q?F5tcotXK+nGZvQdGx8Z9EHymPHl1ivYA/Ljq++2oJqRVHuj4tfnFMovfAM?= =?iso-8859-1?Q?eF5eU1XiZQvcl1esxqryakmGItvu23n3hxR9rNX/RhfxHb2mG/+gsbzi9L?= =?iso-8859-1?Q?dOT+dOgBKsCjiao5UGAaGqwv38doyKekYhDwNnerPoWFNlXJt5WrwvgGjX?= =?iso-8859-1?Q?3WSukncpzRfBoVuwBkJFL+6CXNZGzlBcZhvdWRb9GaoyxZwLTV6eyoLPs0?= =?iso-8859-1?Q?MpjoIOvTAM9XJi1N/gQWxzQ0hk+/blW0ZRXg+MnH8W0EXZj2NAbt9+bDBY?= =?iso-8859-1?Q?NWXL3Wurn4fXljIZMx375LAHpEo73yoeqR2rAcErtD23cXVBa5kTCHwf8Q?= =?iso-8859-1?Q?Wn8WbLIkkpBEeCVsrm1UPifK9JYkH2ueGdy5+NsUT3x2U40KS5ABt40bHn?= =?iso-8859-1?Q?rEmaDeUw2/VfDhGVhoWU7snA3yzgJ8bUD53Cn7S9PoqtuxKCH+z8cGcg/R?= =?iso-8859-1?Q?pFUdi1XFzZM5JL8wjB/0AGgtu9qeaF7aLO2CgUwoILfkDj5KvG9icGxVC4?= =?iso-8859-1?Q?qjP/vCcyRrlJn7kpjypvMp1Y3l2yNFIJ4KbTZIZ3IvpoJvhmP3lDizuzgG?= =?iso-8859-1?Q?R/RrbdokDMFgJ3A99Vu0J7JP5SMkJQjFF5pAWKexMyEq5ZR17utxEMmPze?= =?iso-8859-1?Q?JvUorpX6DYd+t2k7Ko0/oCWBkVXLafEGXfViaXgI6qn3ls4OKec83IN6Rs?= =?iso-8859-1?Q?DBHkL0r9ni/L6tZwpT5mkjQXvlUHj+TxVNG5IZ+4ew/4Tictrg4/TpV1Tw?= =?iso-8859-1?Q?V+pOoHi3TCzwNukBrbJsjFCuwTRlFBcRs2nRY/+07gcRxPb0GWPiQMLPo5?= =?iso-8859-1?Q?MW+y0yzzex4JQvRSYKQmqkmoobZUiL1HFmj46PushhkQ0QGcv2+dHKdQpf?= =?iso-8859-1?Q?e1QdAw+ib8rHXM/77Od4nGKHiNRvlugItpHeqS50E6pn11hZs4mzmkp1qE?= =?iso-8859-1?Q?3eIGmoFcWNpa1UMXD4mc5nKlsXsKCaR/VE4Hz4/8uOD75cVq1KDsDF5xTE?= =?iso-8859-1?Q?KZKIMsmOk0886M4p8gyaBo6Khmk8w5Rsf8ZLZ31qsptemaeI4aOwOOiUdK?= =?iso-8859-1?Q?6Gdcdz7aNAFp13p0U2B45/qL8ugLObCXE8xQjYMMN4tsmHI=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3d811d1c-e1f3-4bce-0923-08d93fcfd7d5 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2021 16:13:36.0722 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QA7+vT3jQC6yUCHNA8ygeOECdRBfuHl/Xfqa8dPiqXn94v5m/cDZmIpWHwUNyK1hjo3wzW6IaKOydvTfNdY6lw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5142 Archived-At: Subject: Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 16:13:45 -0000 From: Michael Richardson=0A= Sent: Monday, July 05, 2021 16:17=0A= =0A= =0A= tp> Likewise involving IANA. They maintain registries which anyone can= =0A= =0A= tp> access. They perform updates, on request, according to the policy = of=0A= =0A= tp> the registry, which is set when the registry is set up and can rang= e=0A= =0A= tp> from requiring a Standards Track RFC to First Come First Served,=0A= =0A= tp> depending on how easy you want it to be to make changes. See 'IANA= =0A= =0A= tp> Considerations' RFC for the range of options. And they can turn=0A= =0A= tp> updates to a registry into an update to a code module (such as an S= MI=0A= =0A= tp> MIB).=0A= =0A= =0A= Probably Standards Track RFC to update the voucher types.=0A= =0A= tp> What I am missing is how easy or difficult you want it to be to mak= e=0A= tp> changes, who will make changes, (IETF only, another SDO, a manufact= urer=0A= tp> ....), what review you want for changes by whom, how frequent chang= es=0A= tp> will be (usually a guess and usually wrong but it helps to have the= =0A= tp> assumptions about the requirements spelt out) and such like.=0A= =0A= tp> As an engineer, I do like to know the requirements before working o= n the design!=0A= =0A= We need to be able to write RFCs that extend the voucher types.=0A= =0A= Not that often though.=0A= =0A= =0A= =0A= Michael,=0A= =0A= That is nice and clear.=0A= =0A= To quote an earlier e-mail in this thread,=0A= > Where I'm a bit blurry is how stuff like the YANG in RFC8995, which uses= =0A= > RFC8366 gets updated when IANA revises the module. I think, it mostly do= esn't=0A= > matter because none of are generating code from YANG... AT THIS TIME.=0A= Well my answer would be that confusion reigns.=A0 An IANA Registry is autho= ritative so the minute the RFC is published asking IANA to maintain a modul= e, then the module in RFC8366(-bis) is obsolete. Trouble is,=A0that the res= t of the RFC - if any - is not.=A0 (You may have seen this on the DHCP list= with I-D referencing an RFC when they should have been referencing the IAN= A website)=A0=A0 RFC7224 gets it right because the contents are only the in= itial version of the IANA module so that (almost) any reference to RFC7224 = is an error, the reference should be to the IANA website.=A0 That says that= having long-lived text in an RFC with the initial version of an IANA-maint= ained module can only cause confusion (IMHO); they are clearer as separate = RFC.=0A= =0A= Again a quote that caught my eye,=0A= "I also think that in our enumeration/Registry, that we should include the= =0A= "value" parameter, so that constrained-voucher can consistently set values= =0A= even if the enumeration changes order."=0A= If by 'value' that means the value substatement of the 'enum' YANG statemen= t, then that may not give you what you expect.=A0 What goes on the wire is = the text name string.=A0 If a number is displayed to a user, then it is bec= ause the local software had deduced one, perhaps from a YANG module.=A0 The= text string is the authoritative definition, the value conveys nothing.=A0= If you want a value, then you need a different type of leaf like an intege= r.=A0 (In other languages, the binding of text string to value is part of t= he specification of an enumeration - not in YANG).=0A= =0A= The usual alternative to a YANG enum is identity which can also be in an IA= NA-maintained module but which can be augmented. It is just an identifier = (which to me is more honest than an enum with its 'value' substatement:-). = It is referenced by identityref. (It can also form a tree structure). AFA= ICT 'leaf assertion' in RFC8366 could equally well be an identityref. and t= hen later RFC could augment the identity.=0A= =0A= So I have reservations about enum and about IANA-maintained modules (at lea= st as part of a larger RFC:-) but I did note when I looked at=0A= draft-ietf-anima-voucher =0A= that one of the authors was a YANG doctor so assumed that the choice of 'en= um was made knowingly.=0A= =0A= Tom Petch=0A= =0A= --=0A= =0A= Michael Richardson . o O ( IPv6 I=F8T consulting = )=0A= =0A= Sandelman Software Works Inc, Ottawa and Worldwide=0A= =0A= =0A= =0A= =0A= From nobody Mon Jul 5 09:27:21 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1DE3A1D73; Mon, 5 Jul 2021 09:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfiFVAitiPQT; Mon, 5 Jul 2021 09:27:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33693A1D6F; Mon, 5 Jul 2021 09:27:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 9415C38AC5; Mon, 5 Jul 2021 12:29:33 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id V_zpe1q7rF2e; Mon, 5 Jul 2021 12:29:30 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 43AFC38A6D; Mon, 5 Jul 2021 12:29:30 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 453BD86F; Mon, 5 Jul 2021 12:27:05 -0400 (EDT) From: Michael Richardson To: tom petch , "anima\@ietf.org" , "Rob Wilton \(rwilton\)" , Juergen Schoenwaelder , "netmod\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 16:27:16 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tom writes: > If by 'value' that means the value substatement of the 'enum' YANG > statement, then that may not give you what you expect.=C2=A0 What goe= s on > the wire is the text name string.=C2=A0 If a number is displayed to a= user, > then it is because the local software had deduced one, perhaps from a > YANG module.=C2=A0 The text string is the authoritative definition, t= he > value conveys nothing.=C2=A0 If you want a value, then you need a dif= ferent > type of leaf like an integer.=C2=A0 (In other languages, the binding = of text > string to value is part of the specification of an enumeration - not = in > YANG). yes, it's a text string for XML and JSON, this isn't the case for YANG-CBOR if a value is set. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDjMtkACgkQgItw+93Q 3WWlMAf/aR0SqIU91MB+uOIuKStVmLFZ4UX6QUnAjNrOMh5o2Jrd7Zqo9C2Ex7zF ohSKsu9DURiTcgrz+9B/2IuYzoYGDOSYlSiOFg5eirv4/mc2A7+DTmHAys+87Wf+ XBOKAmnq4JU7o5AFfHlBWyjghP9LOnh1NhbkrjYOBc226rkZn6jBrlfxJG139twn UygHflwtqjvSd/vHHzZnQe+D4DYpFH3SkaN7U1tfVqmW5leLS6yDt5UZuUKQN8Es 0Fcdl4IQeeQroihWz7Fxk/elTB3POXZXSjrypfNx3kKZBnRyjeW2j7HkLkQl51Wq dO5zJ/ZINSH/MvXVa8HPSIF3BQGNxA== =28jI -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 5 10:29:30 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8CF3A2073 for ; Mon, 5 Jul 2021 10:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNoWHH7fkd9n for ; Mon, 5 Jul 2021 10:29:23 -0700 (PDT) Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) (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 BE98E3A206D for ; Mon, 5 Jul 2021 10:29:23 -0700 (PDT) Received: by mail-pf1-f172.google.com with SMTP id 17so16976273pfz.4 for ; Mon, 05 Jul 2021 10:29:23 -0700 (PDT) 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=IWHvEH06fTCQ7G+LqWmJ8iNE7bwsao1ZTqpo3jL3nJY=; b=JpcijWtgkU+O2tyNhnudc1ayBidlFTC/HcSqYhhSYqtvdCXPCcgfDR95ZXiFgqU1un lM4jCMeFGNzxe8KEinRZABkkDaE74+SkCXskASvx9MgGjhwcjEiizAArTA7HDCcj4ReM gNQYCROUjckZUrg3NoMhOC3w/OBTQZhXdmJSL0yjMDVlOXA/BoZ1vj/qz1mdJf8SqRps 35W1IlcpC2VJksHYTPcfMKLYl2wf1FEjPSl9+FkNFNM89IMFRnhr2delRLhpRu2BEmb1 boxl1tcf9JMRa/eguxlb5eAz8yxfaJ/+0seQkJAVgXfqGhXmmcg0UYpEEgbeXOjMvKUi nIDA== X-Gm-Message-State: AOAM53316GrZ9DL9vRM87OPu+gGX/ZNnIYmuJwa/NTxSF6xkC5FzZ23G OpBGS1GqLGaxNrex3wBbHNWjfQ== X-Google-Smtp-Source: ABdhPJwtVpvdYi/wvtImLyfFbHil0lUszACiHq0ZzyLBRQXTF1/3MLnFhtaJkj4WdOqfwrSRG3t0Mg== X-Received: by 2002:a63:5cb:: with SMTP id 194mr16501265pgf.146.1625506163183; Mon, 05 Jul 2021 10:29:23 -0700 (PDT) Received: from ?IPv6:2601:646:9300:791:ad33:1ff5:5bf9:4138? ([2601:646:9300:791:ad33:1ff5:5bf9:4138]) by smtp.gmail.com with ESMTPSA id d13sm77112pjr.49.2021.07.05.10.29.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 05 Jul 2021 10:29:22 -0700 (PDT) To: netmod@ietf.org, "anima@ietf.org" References: From: Randy Presuhn Message-ID: Date: Mon, 5 Jul 2021 10:29:20 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 17:29:29 -0000 Hi - On 2021-07-05 9:13 AM, tom petch wrote: ... > Well my answer would be that confusion reigns.  An IANA Registry is > authoritative so the minute the RFC is published asking IANA to > maintain a module, then the module in RFC8366(-bis) is obsolete. > Trouble is, that the rest of the RFC - if any - is not. ... There are other straightforward ways to deal with this. In ltru the I-Ds contained both material for publication in the RFC as well as a *massive* amount of material for population of the IANA language tag registry. We needed it in I-D form for review during development, but wanted to remove all temptation to use the RFC instead of the IANA registry. All it took was a word of instruction to the RFC editor to delete the many many many pages of registry content upon publication. Worked fine. In this case, just tell the RFC editor to delete the IANA-maintained module. Randy From nobody Mon Jul 5 13:41:03 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2A03A17A1; Mon, 5 Jul 2021 13:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSgMIvrKEk3k; Mon, 5 Jul 2021 13:40:45 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B677C3A179A; Mon, 5 Jul 2021 13:40:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6CDA438ADD; Mon, 5 Jul 2021 16:43:07 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id z5b0NqHWgLXD; Mon, 5 Jul 2021 16:43:03 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B52D938AD8; Mon, 5 Jul 2021 16:43:03 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0969B454; Mon, 5 Jul 2021 16:40:38 -0400 (EDT) From: Michael Richardson To: Randy Presuhn , netmod@ietf.org, "anima\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 20:40:51 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Randy Presuhn wrote: > In ltru the I-Ds contained both material for publication > in the RFC as well as a *massive* amount of material for > population of the IANA language tag registry. We needed > it in I-D form for review during development, but wanted to > remove all temptation to use the RFC instead of the IANA > registry. > All it took was a word of instruction to the RFC editor > to delete the many many many pages of registry content > upon publication. Worked fine. > In this case, just tell the RFC editor to delete the > IANA-maintained module. I think you mean, the RFC-maintained module :-) How do we keep the YANG catalog from latching onto it. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDjbkUACgkQgItw+93Q 3WVT+gf/QUKLrz8ZqvHtpvf/BrW5RLAgzgnHu2wt63bS3RuxNgb+fMTaMWytZRRz /nDSNGVRrXQ9i7gVcEKOHkgBxCGti4MyREEAISdvwYaiCZbbwtsXdvefxg7ob4Lw ktpXD1jCBZiVry7whcY031WQeavwZDZ54nFhGdBpJmCI1nsCkVEXBENT3npHFA3y La947pzlNOBNvzbb+x3xCIbiQvA3sYjJR3qkytA8eBYx8QTIY9ZMQ+zzzALQRLm5 S48H4+fuXJndI9+uMhzs+3hLqlG1CwCMZ//iDnyUwKD3sgRvPVEypombrSWT5AzM 5GtA7j96bwpPvI3nZrTtNCP5ACadMQ== =jAEZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 6 01:49:54 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15903A1F17; Tue, 6 Jul 2021 01:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4alY8PufB-pr; Tue, 6 Jul 2021 01:49:44 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20092.outbound.protection.outlook.com [40.107.2.92]) (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 D1E0C3A1F15; Tue, 6 Jul 2021 01:49:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bOYi+irbSWnsG42Z7wa/JlqyOLyO6EbZqZQkJU9G8HROZMfZOydI1uDEqSih/yJN1AT0rkU/JxhbtyrPQpKnqrVtCzYCoFggDBpLRqccKeneE3Zejsg2imu+qlaxlbjdfku23E029S5Hv7dcZ5lrGd6jrWl52oZ5A1wuLQCphNNXsGimVSTwM5y/wg2CFfqmR3nctc/644hNrB02bF0aEnSKlu8gvUfT0p39HtIwdENQFyEGQgKZiE6TIH9Yh1VFPn6ADISZAh/4VbYkPdYEBANGLVEMYFfeOuEPjfmV5P2aD7ynC5fS9VdqTyVIgF/WCFuLdv3Hjk4e/7WX3dUo+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DqDzxQPliElSfw9eLzhJPW9y4+kGwJz8nc1Iur5yhL4=; b=MFbPCtuYr7RP5pgu7zG99SPi3JJOmOzBAnj2s2YJsLkJ+MgFFwVf6a4xq+0JUasDmv2nUFEAqgabxTqL1/bky+kPHAVnP1owOi4t/FYdrlJK4U8deoMxn+PU9fdEKWTKkNf80JeZc2Oh9yk4dGfzxYQlqAyLOjEcCz9HsOJ7J+kiLzNn0kwZg1pNjKcTN6dU1t+eq65NqmGfbxZC9V0KfI5BMUZ2EyvAg3YYHW+tz4HBpKCY0wU3U+pIvjJGoNEh4TNkF6b9V5YqH5spzPBGVxKhBw/QmZdwHQTa0gISZAzupz92hgImgsfCapBBEQoIywmvRUG5j8/+CCKgRV2xgA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DqDzxQPliElSfw9eLzhJPW9y4+kGwJz8nc1Iur5yhL4=; b=eiv9/RSzZx0kw2R3RebHSjIhy4on8yMiuN996HCtP+hmdMmQbxB+difLXuFguee4BIu8wed30tzj4ixOJVf6EBEIhiCyQZrSmqZH/tsft0NrqGvTECQ4jFAWkatXnsfety19+3JS/beDVGrXrA7G+bAOutrXU4lMCF43oo4fKZI= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR07MB5058.eurprd07.prod.outlook.com (2603:10a6:20b:5e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.14; Tue, 6 Jul 2021 08:49:38 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::fc5d:ca7a:e2ea:ca9d]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::fc5d:ca7a:e2ea:ca9d%9]) with mapi id 15.20.4308.019; Tue, 6 Jul 2021 08:49:38 +0000 From: tom petch To: Michael Richardson , Randy Presuhn , "netmod@ietf.org" , "anima@ietf.org" Thread-Topic: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? Thread-Index: AQHXcbMbXBq0wbK1vEGnorzfRBCN2as0oy0AgAA1cwCAAMRzGQ== Date: Tue, 6 Jul 2021 08:49:38 +0000 Message-ID: References: , <1567.1625517638@localhost> In-Reply-To: <1567.1625517638@localhost> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=btconnect.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: babbefa2-37ea-4c98-50ca-08d9405afce2 x-ms-traffictypediagnostic: AM6PR07MB5058: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: r4k2Bwp37zRcy22rZAqq8hPjsRiFYkmhV/1cLZHyU61mUWJ5YM1gy4ZoFa7F8cedSL/8v22t9BzCt+LGUQ9YvEqmcmQQBvMgnUEHNZrbKeh1GW6KsT0jI9lAnGjnxwB6x+W4OtNX19ONvVuSdwCRZUEBMNNOWWhu1JIKBxCs5xBIY1eH1IOvgUV0zjQEgGdmaPzohd4DUc5fPf6dV8RxPReb0UNLjfLaAjh+1C14fm01Ac0uDJHeAVThA44uEfYmP2c1jQq2GOkR1Phoc9+hqczn95cqDgVeUTPf0jwL1jlyH/FfnS07Q9lRCo0/qoMpUrEWKpy6OFIjew4zwM7Ah+tOXWvSC8p+KHiDQl1oea2p4eTNc6tz9i1xpANO1j1xANFVjnxFh+hpdESNHZvbhBLm7smRgXpx4DJ7/f6YIOX1YmrFgsbhBp5Z3r0vAWtPQzx1loy72RmMy2NrUKKPAC6Lutxv2XW5ZkaS6w41dL+L7bnMedSHI55ZGEuriA9TAwHcdnTQoFlZ648ot9R7kQDmKRsFF7+CZyWpZymqagdyTwi1pSq2T/jFL731UdrXlZqGMuPWf5SqKZIaXgI7mWtcZ9rOmZyRNJOON2yJHG4ZSFE5nbqj3SpK8QoZQcjOiJb9XaupFSZHWlNSVe65Vg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(366004)(136003)(346002)(39860400002)(91956017)(2906002)(66946007)(64756008)(55016002)(9686003)(76116006)(71200400001)(478600001)(8676002)(186003)(66556008)(66446008)(8936002)(122000001)(66476007)(38100700002)(26005)(66574015)(86362001)(52536014)(5660300002)(83380400001)(110136005)(316002)(6506007)(7696005)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: 4kDFEO50wCYmuowkJIa0AskvLL5nsdNf3pftETmNtAeMVF5Zy0hv0JLkNLnuuvwRvYBgI2Aktmvqf7U7RDAKJq2KCdlGXTslMF4XjtJfYzGKsDmPSl/sGP2MAvDj7PA4/ZTTICZY2JdsIAbaymRoHdMzJqROyozHzwM1s8GyVfJx11oWvQYUbKQped3xqKXHEGqwc4hCBbKhlEWiWqA2F2ycYsAP1MAXLDJYG2StST/ProaQuyf58kCjpQK04VoUaVyDc7V8dvZssGASsUDtbo33bxdE4lXinL7Eo7ojZCkpbhxTpAWK/cHAWrryH0ecaGlqdyiiM+QB+Y1FpX3kGpBcTpPzK5slNY9JjYPZOaHa4VzkqFhuJAq22oZwC7PK6cPL7rMZPGB9ePLqLyRUgs5LM/QvBEMxSPY/ApfbzL5vAq5QrbhZjq5uhfKArfL3rkNvv3F0ciJF7YRfMhdczQFjLits5s5Rz1ymHHba2HFj06+Y11ryxrKNEn90ahdWCDJQNIXGFpU4YSq0hSfkzENWFTGIx8Eq+gedJowrDIujVr+uFK7njqiEN7Z8HEV+U9kI/R13l7J3Sf24vV8nTVfK09eQ/KIuckiXyKplw6ovCr/8PJyEV847l4R5OIlb/eNKR/e4dFbeD9h1JDriVyJJILJdQELItFrm6e4KUPvGvAOK+ThKVqxTCtpIba62LfWOo7cF5bVl+UshtCSkYfa1qnkz/eF648LwQQD22uM= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: babbefa2-37ea-4c98-50ca-08d9405afce2 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2021 08:49:38.3092 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5aet1Mq41gwE59y1cWusQvxaHHnlM2DyCqmJ0wGETyS0zziSB51A7sme//FONm2e/odeQjjvZSWnqG4z4+o8uQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5058 Archived-At: Subject: Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2021 08:49:49 -0000 From: netmod on behalf of Michael Richardson =0A= Sent: 05 July 2021 21:40=0A= =0A= Randy Presuhn wrote:=0A= > In ltru the I-Ds contained both material for publication=0A= > in the RFC as well as a *massive* amount of material for=0A= > population of the IANA language tag registry. We needed=0A= > it in I-D form for review during development, but wanted to=0A= > remove all temptation to use the RFC instead of the IANA=0A= > registry.=0A= =0A= > All it took was a word of instruction to the RFC editor=0A= > to delete the many many many pages of registry content=0A= > upon publication. Worked fine.=0A= =0A= > In this case, just tell the RFC editor to delete the=0A= > IANA-maintained module.=0A= =0A= I think you mean, the RFC-maintained module :-)=0A= How do we keep the YANG catalog from latching onto it.=0A= =0A= =0A= I do not know the answer to YANG Catalog but I do think that Randy has the = right words. I take it to mean delete the initial version of the IANA-main= tained module from the published RFC. MMM, I never thought of that. On th= e other hand, it does break the audit trail, of where did the information i= n IANA come from if the RFC no longer contains it. On balance, I prefer a = separate RFC for just the IANA-maintained module.=0A= =0A= More generally, IANA-maintained modules do have consequences. I see change= control as then residing with IANA so all changes have to go through IANA = and at present, I only see IANA making changes to enum or identity. The mo= dule in RFC8366 contains more than that and if other parts of the YANG nee= d changing, I do not know if IANA would be comfortable with making those ch= anges or not. I have not seen the change control ever reverting from IANA = back to the IETF although that is probably possible, in order to make such = changes.=0A= =0A= One solution is a separate module of just enum maintained by IANA with the = rest of the YANG in rfc8366bis importing that module. But AFAICT such a ch= ange would require a change of module name which then ripples through all t= hose using the module unless RFC7950 s.11 allows such a solution based on s= ubmodules - I am unsure. Changing the module name does open up many possib= ilities but I am do not know if that is acceptable.=0A= =0A= Tom Petch=0A= =0A= --=0A= Michael Richardson . o O ( IPv6 I=F8T consulting = )=0A= Sandelman Software Works Inc, Ottawa and Worldwide=0A= From nobody Tue Jul 6 01:52:40 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DAC3A1F2B; Tue, 6 Jul 2021 01:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6P9-adO8GB1; Tue, 6 Jul 2021 01:52:33 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2105.outbound.protection.outlook.com [40.107.20.105]) (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 242E43A1F29; Tue, 6 Jul 2021 01:52:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E82eB70M2+GjWqpsM5iKvaA/fFbeefkPU7BnVmcp2yngl24AjE7VcDz5jbmxUmAXt0lcHHbYI2Tpa8n7Y53TlDRKVKD5U6cGYK+pqUrkSjc4tQe+Rcjk7koNXKtjyszpOtBVw8lInFHoj/QGeplPAo/17Kv6HmExeD7XTaKFMbpMMKDjnpp65J8bRK9rdwCQuinyVb1rLbRpgSVO9xjw8FoBeGujoZxwKHD2ZflorMd+NxpdHGWEmQ7T0a8ApRMfi9p1wPiuIuYD8/VlnIC2WxklzuXmDmQbGWj7CNA7I9jItfjna/6OliSci09Wix9u0XscPVETWvjDviSv8gHfEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DqDzxQPliElSfw9eLzhJPW9y4+kGwJz8nc1Iur5yhL4=; b=Yr8X4tufyOMVSib2nW1crZWDJuFYFPxKs1FuwhwTmvuYGDQy8pAijOYf4tJrrtBCc18qNfoF+c/2b8q9CYDA12WXF7oxBNXAZOYuX+qxgtp7iDjAvfzAO9z3W8VlPO0LHs79RTqemUBD8aa9ChRLKO2NocOqb9XaZvLPHPbJzmrc/E/++hIMDCdU0N1x8Y+pCnoTIAqcwBjLfd1In28FhGJXcmYdmVx4+5BgP7lndAZ20a8DvwvjsxdxaD7f27rYy/TsFvfkb+vIu7udf/MHzNOxXN1Dtl/HFlhmrsrPJct6qmJ32XDD2yfXAJpsOu0SGe4Em2Ytak0ijcr3WeCG1A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DqDzxQPliElSfw9eLzhJPW9y4+kGwJz8nc1Iur5yhL4=; b=aND8M+ylsIR5Wdj5UW6qwQLppSM5vWPqDE1ktc2dAZBjLUkXfSA1SoyWo+nuUuQevHAc1jqa3uv3ylLGTBYs0uR4QznhawbW1ESWkJIMDl73lWWPb4Oje+3/fgjHd8ptsvo2l5arwe7KP2iz9gKIZZMhUsUePqBg1GGk+r+lv/s= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM7PR07MB6392.eurprd07.prod.outlook.com (2603:10a6:20b:13a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.8; Tue, 6 Jul 2021 08:52:30 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::fc5d:ca7a:e2ea:ca9d]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::fc5d:ca7a:e2ea:ca9d%9]) with mapi id 15.20.4308.019; Tue, 6 Jul 2021 08:52:30 +0000 From: tom petch To: Michael Richardson , Randy Presuhn , "netmod@ietf.org" , "anima@ietf.org" Thread-Topic: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? Thread-Index: AQHXckRAshTPz8b0Q0yC3Mqpk4iTrg== Date: Tue, 6 Jul 2021 08:52:30 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=btconnect.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 19e24cda-c623-4d72-26a8-08d9405b634a x-ms-traffictypediagnostic: AM7PR07MB6392: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: y6ZdJzFFIPfZ3BILaDz9piW5nD93N0PXIE362a31cCTONEv8BfTNDts786Kot4Jk7nnEKFOjgcsjwPcnZcIrprWVMXT0WjatS8KJUK074DfIGCh14ODNmlgWt7MrehINQvdosAgY445tmpmXyxZSQUTqAMJ0Taa/EUq1aVousXpb7Uyxt5gLmGAmjprnrMuXpPEJLFfTW2YgpEKTN5H+UxhGYM7+qLAhK/mgYktjEXeAJoR27GiaNJZbkpYyh/iIFj2oQiN2W0/Z2PcIC2FuoTbFmBlu+h1tFot9dPyoutTGoclOHjIgLwEI81VUqW6YYAA4Vg9KmQZf7O5KxffDWWL8hbnejkdW8pjKI4WdTted8+j5rBtgtJfPVefSUZ5NQN1QS1XzkTeUQJtRANB4s/tsczWlP8kwKA9HcuIjmPFfmF2xXIE12kAbVir/50Ay9tNP1WKc26mXSYN38VKrpZdE7i7NrzRlghUSjph1K6BDnFKizRHlaS/QcNOlOUAiwezEdXlw0CIVkJPTEHjtx4VZ+Flo5DEqDmd5jPwks5PaUxOTOVwxiyHW8EeLRGWKl3fObmRBQTMyNbUHRYgiSRAX4+7qIBJc8ogdsfLROYUHaS4XqbkxNrv47aiv6agBxb8RYUXxzVJ4DjpvS1m8SQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(376002)(39860400002)(136003)(346002)(76116006)(8676002)(38100700002)(478600001)(9686003)(122000001)(66476007)(66446008)(66946007)(55016002)(64756008)(8936002)(33656002)(186003)(83380400001)(66556008)(26005)(66574015)(6506007)(2906002)(110136005)(316002)(7696005)(5660300002)(91956017)(71200400001)(86362001)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: iNOTv1O+TSxHjGP+ejjRfEmWndfrji+1DsUYNhuw+U24GfiD73LyJDE4eXzn9HB7o95Q5wNi1IHAbx+H4Z4WiPmYeINTYElq7csx7wlS870jvzO3h99zyn6UTSPFnc0bw2Y7UYzO/Z+n6dZG3iupKOvRxEtINF5UzLmEG3Z56MPb+LjPJW9rc004Dzf9i6HNfuk9sktvgPT+XfbMi3WLUsTf9V8NSJU20thBG6GX8JjyjGJzQvSPumfcvJtMk5s5JpSDpNVFKYXuUtyVKjWh9piD9WDd0vYjNC0YA66+JLVkuKHbKVA/2qS9kP0AEmJJVf3LPAy/MF5D/LYlUFkZFaHjNCWMmPIQypnPnMKsKoVSxwFsZ91kaG3QydIoFEIXkvo31FmHoxbysOb/Th9gHq/ycHsLeYtVl/hsiR+cKj0Rzja8f9GQq5NfqNas4dtAn0qWVWYOeVoI6Nj0o8cEsx71EUYx1rOvvkIZ4xcEBcMzIFBVO5ZxBcOln9A4W7aM7aBSSRaTLau9IUIBasqavKumWEmk9Jnixy0WOZ267ErQxNTn4B0jxt+LO+AzPYBRzZ6M/0ZDYeRCAj8RefrwP/2syppngLWbtuu5YOj0MeTT6BahUvT9Y2dtfyb1H8DI1eR7fA/rZsdI7Df80zICsOMJn2lU7EtoS3p21M9qtv4CjYhU1h20dlZdBQ4DtbqWonk6Y35HccMt8aMq8UvMsD1kU1lbow0UBQDyIm9GB6A= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 19e24cda-c623-4d72-26a8-08d9405b634a X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2021 08:52:30.1253 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XsHaJx7gEi3uoSITPDyD5rsEkUudOKkvC6XzaQphPkiRzbgJ59rmg+MvbggNkC5tcQM9J5Mr9axbKiH7JXIiiw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6392 Archived-At: Subject: Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2021 08:52:39 -0000 From: netmod on behalf of Michael Richardson =0A= Sent: 05 July 2021 21:40=0A= =0A= Randy Presuhn wrote:=0A= > In ltru the I-Ds contained both material for publication=0A= > in the RFC as well as a *massive* amount of material for=0A= > population of the IANA language tag registry. We needed=0A= > it in I-D form for review during development, but wanted to=0A= > remove all temptation to use the RFC instead of the IANA=0A= > registry.=0A= =0A= > All it took was a word of instruction to the RFC editor=0A= > to delete the many many many pages of registry content=0A= > upon publication. Worked fine.=0A= =0A= > In this case, just tell the RFC editor to delete the=0A= > IANA-maintained module.=0A= =0A= I think you mean, the RFC-maintained module :-)=0A= How do we keep the YANG catalog from latching onto it.=0A= =0A= =0A= I do not know the answer to YANG Catalog but I do think that Randy has the = right words. I take it to mean delete the initial version of the IANA-main= tained module from the published RFC. MMM, I never thought of that. On th= e other hand, it does break the audit trail, of where did the information i= n IANA come from if the RFC no longer contains it. On balance, I prefer a = separate RFC for just the IANA-maintained module.=0A= =0A= More generally, IANA-maintained modules do have consequences. I see change= control as then residing with IANA so all changes have to go through IANA = and at present, I only see IANA making changes to enum or identity. The mo= dule in RFC8366 contains more than that and if other parts of the YANG nee= d changing, I do not know if IANA would be comfortable with making those ch= anges or not. I have not seen the change control ever reverting from IANA = back to the IETF although that is probably possible, in order to make such = changes.=0A= =0A= One solution is a separate module of just enum maintained by IANA with the = rest of the YANG in rfc8366bis importing that module. But AFAICT such a ch= ange would require a change of module name which then ripples through all t= hose using the module unless RFC7950 s.11 allows such a solution based on s= ubmodules - I am unsure. Changing the module name does open up many possib= ilities but I am do not know if that is acceptable.=0A= =0A= Tom Petch=0A= =0A= --=0A= Michael Richardson . o O ( IPv6 I=F8T consulting = )=0A= Sandelman Software Works Inc, Ottawa and Worldwide=0A= From nobody Tue Jul 6 06:39:50 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55D493A2848; Tue, 6 Jul 2021 06:39:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <162557878431.16434.3031452242343153431@ietfa.amsl.com> Date: Tue, 06 Jul 2021 06:39:44 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-yang-versioning-reqs-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2021 13:39:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : YANG Module Versioning Requirements Author : Joe Clarke Filename : draft-ietf-netmod-yang-versioning-reqs-05.txt Pages : 12 Date : 2021-07-06 Abstract: This document describes the problems that can arise because of the YANG language module update rules, that require all updates to YANG module preserve strict backwards compatibility. It also defines the requirements on any solution designed to solve the stated problems. This document does not consider possible solutions, nor endorse any particular solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-versioning-reqs/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-reqs-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-versioning-reqs-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jul 6 06:46:13 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763E33A2889; Tue, 6 Jul 2021 06:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=lBh8A3VC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=M7e6guM0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lTF_Wr27QCE; Tue, 6 Jul 2021 06:46:07 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58A553A2891; Tue, 6 Jul 2021 06:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1835; q=dns/txt; s=iport; t=1625579166; x=1626788766; h=from:to:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=LxpLmknTJZM5M17IGQxhjQOUXcvS/CM+KKb7HxZ8Ncs=; b=lBh8A3VCULAFSygRv1rQyGBXYhikogAJkCWGiaY/a3kMZn2v8XygGm7Z B7/q8A+j6S+cAtzWniF7f36h5NP9GHZ+dI3W/B93cgFsvwtNCIBcRPzdN 0gSuMfwKIVjWSW5j6QiPRqJ7UXhdADo1bAUMM2ZdHk2Q5qwgZDwQRXxiD E=; X-IPAS-Result: =?us-ascii?q?A0CWAgCfXeRgl4YNJK1agQmBWYFTUX5aNzGIEAOFOYhRA?= =?us-ascii?q?5ongS6BJQNUCwEBAQ0BASoNCgQBAYQPRAKCcwIlNQgOAgQBAQEBAwIDAQEBA?= =?us-ascii?q?QUBAQUBAQECAQYEFAEBAQEBAQEBaIVoDYZGAQEEAQEQKAYBASwMDwIBCBgeE?= =?us-ascii?q?CcLJQIEARIIEweCTwGCVQMvAQ6aUQGBOgKKH3iBNIEBggcBAQYEBIE5Ag5Bg?= =?us-ascii?q?woYgjIDBoE6gnuKbyccgUlEgViCYj6CYgEBAgEXgUYCg0uCLoIhe2QBA1ECF?= =?us-ascii?q?EeBKHS8SwqDIYollBoSg2KiSZV4ghqKEZNOhH4CAgICBAUCDgEBBoIpATaBW?= =?us-ascii?q?3AVGiGCaVAZDo44g1eFFIVKczgCBgoBAQMJih4BAQ?= IronPort-PHdr: A9a23:/ndIlx+uUUdRo/9uWDnoyV9kXcBvk7T5IgBT7YAo2PpCcaWmqpLlO kGXpfBgl0TAUoiT7fVYw/HXvKbtVS1lg96BvXkOfYYKW0oDjsMbzA0tHMDDDlf0f7bmaiUgF 5FEU1lot3iwLUlSHpP4YFvf6n2/5DIfAFPxLw1wc+/0AYXVyc+w0rPaxg== IronPort-HdrOrdr: A9a23:B+QwF64t154F78fu8APXwUGBI+orL9Y04lQ7vn2ZFiY1TiXIra 6TdaoguiMc0AxhJU3I6urwRJVoJkmsuqKdgLNhcYtKOTOHhILGFvAb0WKP+UyEJ8SczJ8S6U 4DSdkENDSYNzET5qyWjHjaYrQdKZu8gdqVbIzlvhBQpHRRGthdBnBCe2Cm+yNNNW17LKt8MK DZyttMpjKmd3hSRN+8HGM5U+/KoMCOvI76YDYdbiRXqTWmvHeN0vrXAhKY1hARX3dk2rE561 XIlAT/++GKr+y78BnBzGXehq4m2OcJi+EzR/BkuPJlbwkEuTzYILiJnIfy+wzdldvfqmrCVu O85SvIcf4Dsk85NVvF3icFkzOQrgrGrUWSkWNxRRDY0JbErPVQMbsbuWsRSGqp12Mw+N57y6 5FxGSfqt5eCg7Bhj3045zSWwhtjVfcmwtrrQc/tQ0obWIlUs4ZkWXfxjIhLL4QWCbhrIw3Gu hnC8/RoP5QbFOBdnjc+m1i2salUHg/FgqPBhFqgL3e7xFG2HRii0cIzs0WmXkNsJo7Vplf/u zBdqBljqtHQMMaZb90QO0BXcy0AGrQRg+kChPYHb0mLtBxB5vpke+73FwY3pDYRHU49upHpH 2aaiIpiYcbQTOdNfGz X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.83,328,1616457600"; d="scan'208";a="720195753" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Jul 2021 13:46:05 +0000 Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 166Dk5Xi001050 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Jul 2021 13:46:05 GMT Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 6 Jul 2021 08:46:04 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.15; Tue, 6 Jul 2021 09:46:04 -0400 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Tue, 6 Jul 2021 09:46:04 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BiPKuL/2RX5Y/g3YraqKB9priWu+EV8vx3EnhC02q2xIZvsPup4YD/fYQ3PLAIJXd375tvC2uRVpMdtKMH0bU7xtro3V3hVBaTYXutNWg1NZYE85EueuzYoXj3OfOLV4iwN7Ux/4hlUbcBuGScSQTKZIkixtE31hqJtwj/Of48Ssh689VnvUZVGfDM8lUpuFQUXTALaqDJz5s8wxI/kHVUD54hD1tl0+JgfcxtWW0L0aFnv3Gn43+Vn+Tv84Vq/+M5hwyST+zTe22TtPMspE9FoiX2V+ZrlC7oINUbEZRhXPgdhWPxa3slpLt5I3JdbYZ2yMKMMo6BIZ1IcyhCT0hA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LSSiaa4SrhqKFUfT+OZABQNOU1X2DIo+98rQ0C48+bc=; b=BYCDtihPeYUfpSCY0PhM1O2tjASm0oR6y9RecJNa4m+FDRME0J7xSFKr438MyLckBphl6P1ND9Lif/kGp1sAvAobrwPaIi66uNRI/2C6Fa8jBEvXQ0148nrSVfg83WGUAEoUtfsyiAdH0k4nQQB+GWxKU5nI4FRwAEp9cAieRKu3irItWzHUYdDvMwdpkh9uN4JMUWrHDLekkX2l+6mIEE8FXBZttWrjEIYVo8Jk98LPEvR/3DZafqckTjehKrgRG+j+01WFptRe1blYeA5qvYNeomsnNwaTiUMSE283JFF/D7myDPeIKdcIHFt98mH3PKyZ/RsibNalmrP+dMen7w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LSSiaa4SrhqKFUfT+OZABQNOU1X2DIo+98rQ0C48+bc=; b=M7e6guM0jrhFyTITUbXEqfNH/ZXxyHzzq/cSCjKnmZiBNsg2kvGLFyJgVzGfmK8jlhi25PinuPDtGt0DitFljqOJW4eIgxQSTfrJzcPcPOYjQfMv/Q/G2F/kEBuQ7t0V9tZ+v+veCekaK0PBwPZg/q2diPfzcdEXTJURKVA21n8= Received: from BL3PR11MB5681.namprd11.prod.outlook.com (2603:10b6:208:33c::10) by MN2PR11MB4270.namprd11.prod.outlook.com (2603:10b6:208:18c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.22; Tue, 6 Jul 2021 13:46:02 +0000 Received: from BL3PR11MB5681.namprd11.prod.outlook.com ([fe80::9035:b3c0:8fa8:da91]) by BL3PR11MB5681.namprd11.prod.outlook.com ([fe80::9035:b3c0:8fa8:da91%9]) with mapi id 15.20.4308.020; Tue, 6 Jul 2021 13:46:02 +0000 From: "Joe Clarke (jclarke)" To: "netmod@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-yang-versioning-reqs-05.txt Thread-Index: AQHXcmyL+CaGlIeuqkeZTaEVc81OCA== Date: Tue, 6 Jul 2021 13:46:02 +0000 Message-ID: References: <162557878431.16434.3031452242343153431@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2aa9ee79-8a8f-4f71-229c-08d9408464d8 x-ms-traffictypediagnostic: MN2PR11MB4270: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: o9iMiaISvmvdQ3HsG8KlaO7l41fREM5w177CN3eWdcP+SOvJdtIQz13FWruTnMmx4y0U7myrGWWGwucFkpQZEg6JOnycXcNSzgQzak++jtMN6ACI+vSpQHb4sl/HCICe4yxNlCzGOQEfOquAga+ARDcLNDrz5ak4qpZTHpHMY4+T24rLCeQj9CgbjRWWkeNJu9KxcJ1wflL58OMscTXEdBa/8MlFEjbi+YA2QDJL39w+RVjtMBpm4yBSp1Y1UHauEcRsZJbisepRyRBowxgqqi9nEWHTaIP0/pdhgp8zei+eyEdc6U2dKQ2M5waRv8cDjLgRGFLGHLV9eTqYmhLam8x/8WiFCFjemtozDKtR7ig6vMegejHuW1yfBvNqAUJNKKzBC0klMMdsCQaEbdIntMXEdI7sAt0tgg3tpXXvk3Uq1AxmCgbLx5vOzqPHD/mG4DesJZNYyB3TQkm1fKf/jVO5rYP7t4oZCwezVvUHpdM/5kaGhP3BE1nssyh6gfNZkWCtIhAzCZBkz9ixz6iB1JBX1lbDhVRCzfKNeJSLfffv444qoFIQ5qrtmSJ7wgCZmWWghIvQv4Mg4RNa2wbEB/rv8DhGemrDbbZtq97QHePzOUMeAKWXPzQsu5YcRmdCwup+WD1x+h7ySOWUkh6/KcZhNLGvI/a+RmAZ5/h78235UR1louq/dwY1akvrZhdbmkVwFnzHK0QHuNOzv+hMYHMZucABpxUPXnzDwfT6x/TNgMyJ5y6haFq41HLEih9pj2PrSP9x7qDH26ZozBbd3w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL3PR11MB5681.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(376002)(346002)(366004)(396003)(55016002)(33656002)(122000001)(38100700002)(9686003)(450100002)(8936002)(5660300002)(966005)(8676002)(86362001)(186003)(316002)(66476007)(52536014)(66446008)(71200400001)(76116006)(7696005)(110136005)(66574015)(66556008)(66946007)(478600001)(83380400001)(6506007)(53546011)(64756008)(2906002)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?/cHby9xjd/UUokjAWwtM6fottVd9pdCIJOWhExoIAQFIMdniQ2z+BmbfCrrM?= =?us-ascii?Q?Oyp/KtBcUIi/CSNMJQzg/2lAqNbgTJwp6xkAnFJLHwUkA+WunBofOEaDOwxo?= =?us-ascii?Q?U0x3vnJfG1T6dF68g/aY528l11ZbpLhxmU+NfLiikvyydbTeR82gMUkA6Mfy?= =?us-ascii?Q?JIm2S47ubnKaj/QDomFhYhx/ESOET1EBtTXFzCfl9jCJb6IgOua0U6BBRzYx?= =?us-ascii?Q?2Kb380UEJdZ5zswETBs4oj11gZLQ8OhYZpu4ZMieInumCzSO3ikHHuN0QiLb?= =?us-ascii?Q?tp1HyOxFRH03wEB5xNEHoUUTZz9nNaKH2MczQjXp917q0Pe/nhEBexoRRfEU?= =?us-ascii?Q?shF6d21cVOUWW1QGaJf+lLB0QNiEr55BQqZ/6lUd+NZO3RE+cwwYWg/72/Ln?= =?us-ascii?Q?ooXkXsbR2WkFGoylDvPYhqn4EEJCiveSUqvlCnJnGHv25TbAaLteoxGuNwpI?= =?us-ascii?Q?jhLjIH7/CLjpZVzInmWEYTv+yxzzjo1/YNuPxYI5Tkh9UPUqR0tC0cL5Doxr?= =?us-ascii?Q?7IsPx4jDQG8d7zJSZMi8+r8bDw6NlRnO51jvmJzMoJPEtgAewMR1efnyaOsR?= =?us-ascii?Q?XcydsW+XmCtnNqC2EnNY43qg4coZC+cCI4FplGcz25gpCrr0rtmHJv9/Dqan?= =?us-ascii?Q?dMOs4HUnQrZ+vnQExX8rv3xJXmrwMY1tG5rvtrOAlK1QHx9TZUcf7fbKNIPB?= =?us-ascii?Q?MxsVuOJDXbEl3mCeDGhmZbgcUUnsRtL4fcbqUTJqcM1k3H/1+YqudTARKoUb?= =?us-ascii?Q?ox30u0DVI7X+mKHrUXc0/vJqKVySZosWD3bxyE92oCHh9DE4SHAbkYwIZvrq?= =?us-ascii?Q?Wdqcvl3Bj3evWpHqHhApuBIXfiO1CtwyfC9R/K7rgZQZGoise2oXJT3wb8rO?= =?us-ascii?Q?JKwjubc9LrcgXTbA3Rv7vWgMRq2gZazHmZdnL/CvhbR4fu0ERL0nGACLlf7Z?= =?us-ascii?Q?usRHk10NOh1YlQYxOC5xh+zUEYIwOBLbkMTJuDhNNaywl9+zHvZ90tXIhNrK?= =?us-ascii?Q?a2gz/ab0XF76YZqaTX37RU2GOQ4W77iq55uyjkH9bb9iCcy+39R4Zz36YICX?= =?us-ascii?Q?jo7jNoc0+iKwHWRtkLgWvMvglYPo1vCQwn31txIqehZXi7wrccOZyBhMytaT?= =?us-ascii?Q?wSz0pf5NUy4/D99ZdwcGro0QWGnuqVqUOat++Ocp8iCdAwU4CgEKuwnk8hu+?= =?us-ascii?Q?dv+FB3QamZXXfJCJBYXIpjif4um/Z0Q+NyD0FU/GFh3L8d2Hv2TIrz2Wuhl5?= =?us-ascii?Q?k2YlzzIuFMw1exoTA8rish+CxhbBCmrH5Q9fLLshkcUi29kLTXIejbuckzG7?= =?us-ascii?Q?n6ldAyNcgNE5q2+6OF8fGS6H?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL3PR11MB5681.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2aa9ee79-8a8f-4f71-229c-08d9408464d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2021 13:46:02.0128 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zvLQWWbtzPsSTtDk9ZjylcXnXZSlcoFesibvfQDrDUpIeTY1ZwBtk2s/TwnqNA5CmBDFtM7Vg9YBn/rKTl1d4A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4270 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-versioning-reqs-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2021 13:46:12 -0000 The only change here is a revision bump to keep the draft alive as work=0A= continues on the overall solution documents.=0A= =0A= Joe=0A= =0A= On 7/6/21 09:40, internet-drafts@ietf.org wrote:=0A= > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories.=0A= > This draft is a work item of the Network Modeling WG of the IETF.=0A= >=0A= > Title : YANG Module Versioning Requirements=0A= > Author : Joe Clarke=0A= > Filename : draft-ietf-netmod-yang-versioning-reqs-05.txt=0A= > Pages : 12=0A= > Date : 2021-07-06=0A= >=0A= > Abstract:=0A= > This document describes the problems that can arise because of the=0A= > YANG language module update rules, that require all updates to YANG=0A= > module preserve strict backwards compatibility. It also defines the= =0A= > requirements on any solution designed to solve the stated problems.=0A= > This document does not consider possible solutions, nor endorse any=0A= > particular solution.=0A= >=0A= >=0A= > The IETF datatracker status page for this draft is:=0A= > https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-versioning-reqs/= =0A= >=0A= > There is also an htmlized version available at:=0A= > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-versioning-r= eqs-05=0A= >=0A= > A diff from the previous version is available at:=0A= > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-yang-versioning-req= s-05=0A= >=0A= >=0A= > Internet-Drafts are also available by anonymous FTP at:=0A= > ftp://ftp.ietf.org/internet-drafts/=0A= >=0A= >=0A= > _______________________________________________=0A= > netmod mailing list=0A= > netmod@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/netmod=0A= >=0A= =0A= From nobody Tue Jul 6 08:14:57 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F323A2B1F for ; Tue, 6 Jul 2021 08:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=YIOnf/uF; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=THfmUPen Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcMC4AJZph-l for ; Tue, 6 Jul 2021 08:14:50 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C44B3A2B20 for ; Tue, 6 Jul 2021 08:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6737; q=dns/txt; s=iport; t=1625584490; x=1626794090; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RR5DQggxa9kI4IGTsdGZ8Hx5c98knAGhSSsLlVUNVBY=; b=YIOnf/uFgDAEZNJbg6sKoJzBnwCjcmoFmViaTv8tjAFN+19jfqDFn3de xNdCMa/oRidXlqexophiFHraPBsD8BCQ27o95CvPHtH7rn1Hw6pVxovsX FfeqXRH8pKMcBrmawYBgnsH7D4mvAVWHiCRJCAF1uY6wOLTSnvEgtcCf8 Q=; X-IPAS-Result: =?us-ascii?q?A0AkAADXcuRgl4YNJK1aHQEBAQEJARIBBQUBQIFFCAELA?= =?us-ascii?q?YFSIy6BWDcxiBADhFlgiFQDj2SKQ4EugSUDVAsBAQENAQFBBAEBhFMCgnMCJ?= =?us-ascii?q?TQJDgIEAQEBAQMCAwEBAQEFAQEFAQEBAgEGBBQBAQEBAQEBAWiFaA2GRQEBA?= =?us-ascii?q?QMBEi4BATcBCwQCAQgRBAEBLzIdCAEBBAENBQgagk+CVgMOIQGabAGBOgKKH?= =?us-ascii?q?3iBNIEBggcBAQYEBIUPGIIyCYE6AYJ6gnFThysnHIFJRIEVQ4JiPoQcEBqDS?= =?us-ascii?q?4IMIoIrEVsGThYBAycBBxQwAk8KHUYfBw8CHgoCOJB5BCaMH4Eri02SEQqDI?= =?us-ascii?q?Z4/EqYrlXifcQQdhGUCAgICBAUCDgEBBoInOYFbcBU7gmlQGQ6OHxmDV4pec?= =?us-ascii?q?zgCBgEJAQEDCYdYgkYBAQ?= IronPort-PHdr: A9a23:gnd/Mx+bUHnmnP9uWMHoyV9kXcBvk7juPwUO8Z0hzblJd/fr85fjO RnZ4vNgxB/MUJ7A4v1Jw+zRr+j7WGMG7JrA1RJKcJFFWxIfz8lDmQsmDZ2IE0zwN+XtaWoxG 8ERHFNg9muwZE5SHsu2blbOo3q0uDgVHBi3NQd8KunvXIDIiMHi3OGp8JqVaAJN11KA IronPort-HdrOrdr: A9a23:R+32QqzbZiQ7V1ZQpyzlKrPxquskLtp133Aq2lEZdPULSK2lfp GV8sjziyWatN9IYgBepTiBUJPwJk80hqQFn7X5Wo3SHTUO2VHYYr2KiLGD/9SOIVyEygcw79 YET0E6MqyNMbEYt7e73ODbKadb/DDvysnB7o2yowYPPGNXguNbnnpE422gYytLrXx9dOIE/e 2nl7N6TlSbCBAqR/X+IkNAc/nIptXNmp6jSwUBHQQb5A6Hii7twKLmEjCDty1uEA9n8PMHyy zoggb57qKsv7WQ0RnHzVLe6JxQhZ/I1sZDPsqRkcIYQw+cyDpAJb4RHoFqjgpF591H22xa1u UkZC1QZvib3kmhOl1dZyGdgzUIngxesEMKgmXo8EcL6faJNA7STfAx376wtnDimhYdVBYW6t MX44vRjeslMTrQ2Cv6/NTGTBdsiw69pmcji/caizhFXZIZc6I5l/1UwKp5KuZJIMvB0vFtLA CuNrCq2N9GNVeBK3zJtGhmx9KhGnw1AxedW0AH/siYySJfknx1x1YRgJV3pAZNyLstD51fo+ jUOKVhk79DCscQcKJmHe8EBc+6EHbETx7AOH+bZV7nCKYEMXTQrIOf2sR52AhrQu1A8HIWou WPbLp1jx9GR6veM7z54HQQyGG+fIyUZ0WY9v1j X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.83,328,1616457600"; d="scan'208";a="744806122" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Jul 2021 15:14:49 +0000 Received: from mail.cisco.com (xbe-aln-002.cisco.com [173.36.7.17]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 166FEnWQ009743 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Jul 2021 15:14:49 GMT Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xbe-aln-002.cisco.com (173.36.7.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 6 Jul 2021 10:14:49 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.15; Tue, 6 Jul 2021 11:14:48 -0400 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Tue, 6 Jul 2021 11:14:48 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KVOZHignEbNyI48V4EowVHhqC9QVHvHuspcXb/QHaoa7qMfrsOz6KYo/gc/K4Ee1Y2Ql4xSxfJK+eyzAOK1O2nR2UBGMLeE28rru3gfY6wRIU3FeFZJk5X5tXUEOxEJdW+EFdOLzBXCowm5BzZ9F9h0ixmidfeL8X8xfDJM8kSE7BglhUCeeBBDryJxD7BUrbFxPiategfjThIQOe80Ze1mx+eWAy2IRUztzPPfMmXrwxyAiLyC/Vh8cBCbGZoABN3m/bu6VlHNV1PgWdaEADvt1aYlKuHYEHncy/Cjw/j9OPpg0dmoVBAzM4jVs6/Zz4ycLJqmcWFrK+kKGJq2xLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TzB4eXqdSC5fMh0K30+aF33YQZOxXoGldXJgC0aEcYc=; b=Z2ccQI0F4ltKY3O1G5YJqfrugbOE1dVr8tXYo7s4gSYF9tbSEZptrZNrU9TJYx9n3ENIiOBiIiFI7U4IXzSAb7LbmAhPDwh78XXVbKlipMvCpvoP6kN1KGWnynFbruKbiAs8wzylrM2dvWi44OzGU+IsmsJpltR+Pxj88rxdZhG6vuNiSOYEjV5x/gnm9APaexOZu5gHcWwNm6wtpZkutv1S4RRpKETvWyiYgtOoX5uHR8OMDwY6i/CkosIYDO8PRgvAwc17LfT7SyVAtchOG5BkXD/D7qsyrARa4M/17LRA0aEJho4zE8N4mDVW1d8YvOf6wd1U8eWs9nriyQnJ7A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TzB4eXqdSC5fMh0K30+aF33YQZOxXoGldXJgC0aEcYc=; b=THfmUPen6aaysE691f+LtLWxbhMfwj2EXg8n7WdVCif0nq4W++mYiT2G1etkbb4xkIwjxUG/bUjCXmID4NtktjjMn8Ov6zin/Y3zWNEDBcw6nffZOT06iMsmFceQkiLR3MFi1cdNr8h9R9IOm+N/08CZeDkdZm2GdNU7jSw3wBI= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM5PR11MB1387.namprd11.prod.outlook.com (2603:10b6:3:7::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4264.24; Tue, 6 Jul 2021 15:14:47 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12%5]) with mapi id 15.20.4287.033; Tue, 6 Jul 2021 15:14:47 +0000 From: "Rob Wilton (rwilton)" To: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= , "'netmod@ietf.org'" , "andy@yumaworks.com" , Juergen Schoenwaelder Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8A== Date: Tue, 6 Jul 2021 15:14:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 898ab32a-5f3d-4939-f70a-08d94090cb0e x-ms-traffictypediagnostic: DM5PR11MB1387: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ybmlpMdv+mGWJJGpW+hWfFyHiGwlZrs1R6Vr+RHSAB2IpE09OQL1RuH5tnHTAaiMxj3UBtEBczePW94dYogtGdH6tY/Pbt86YhUnMAIvX/YoPDnBs4r8TNYdAoJLhmcvW9yO+M6MK5adhofxd5dckgvihrUCoWiyOuOhN69o01xtXOOpV7sHdz7zpSFKe3GrH4RGCnWCVcUtkQAuYisig54dyT8e62vQ2A0dlvJGa1MXoZuFSKNs60d590Nunm5EKHiR/QFkbgjmaqGl21mFSCtvCs8xMOqpbAz1LllA/M1i65/PGbrLltl1nKWuvox6oZnAE2MvyC0HA8O/PiuUDcCzocFerz3eSWZ6uw/tiiXaELmUPVv+mZT7iKpGWdy0SNele9wV6tnS3mLmXDZ7CpqMSGFYww4EYzgDg43MyMBu/20TCb4QHXDqr1k6kDz6/3Kwmu3RrZW9yYl6tqDvlhdsrTss0uJGjxycG+RzIEToElUL/fRkGa2K22DgbZUWO5G1XU2NnpkgLKI3LOJtLwcJ3pRBUhswyzDsf5KfVLH259WmLveBcACrAFgCqrbh3QFlHs3wA90prwQ0sJI1PzOyd+pzOX/+weJz+UDxOet1V9CBLpw58DEBMC5HlWnoQqkTD81yo6t6DXHzTxVUi6PAjVxrndhGD1Ar0BILivhGKGGDvHXLT/mvhzSXNxdne4O4OzO5cOJ2PxlMLNX4GQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(346002)(396003)(376002)(366004)(76116006)(122000001)(38100700002)(52536014)(8676002)(8936002)(53546011)(6506007)(5660300002)(2906002)(186003)(316002)(86362001)(64756008)(478600001)(4326008)(66574015)(66476007)(66556008)(26005)(7696005)(66946007)(33656002)(110136005)(83380400001)(66446008)(9686003)(71200400001)(55016002)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?iUz/mhorqMyr9ZIhPeSGjldsOc/ItuRHNfjaP0EgfYN8OpqPwemqoPtCmH?= =?iso-8859-1?Q?sW4HQWxH2LldIWfFL+wZF21/l4s3AU6B6T4lGXimK38PlAQek/Jm8Auyv/?= =?iso-8859-1?Q?soLT2TYPALzzq8IXl6jbp3lupn/mBgjpP/EyRdGBzvGfPbBOrp3WoHNxeg?= =?iso-8859-1?Q?VVk8To28pvYxZPLo9TsyJiMHcfhC2C6XI0kyNj48wjbj5IdKxD274487bA?= =?iso-8859-1?Q?8Hpw2KVNLmj68OM1tLksLXk8LICbz1sz1yLi44DadpKk4u6MfRPavs3Lkc?= =?iso-8859-1?Q?qvi3Aul9F5renAdvsGXe5b/sBYZR1jiRI0VKSxVE8VlzI1md/V+PnMlWte?= =?iso-8859-1?Q?OiGKMUMbP4ERuRCEA3SGQe7WqAY87fmJ3YDaauBfZhqdCTbUFNppVprym/?= =?iso-8859-1?Q?LxFI+9aam1rBCwMVfmCdGOf2DxI3ly16zitHfHtexLGpea3QkKpC/Cyeq4?= =?iso-8859-1?Q?APtx9rqS39iNkbZy2jQpzjj80c/Y18ZDaTNxHzC34L1I8INDu61sF/I0cB?= =?iso-8859-1?Q?/qXFKmIcV71Pq14Qcvi1dAOK7zpckkCq+piTnwUQ3H0iTMM+4AoLIAQk/x?= =?iso-8859-1?Q?DmIENoK8LiLCpBuR/ps7HJ1s4AsjTNdUnwxp6tBW6Fyf3/hLAmVrE/6oNZ?= =?iso-8859-1?Q?NiIAeT6hLwUgmtSzkEfGyYI6AE0r9HwcJuaItVl5JJrMnteUreJx1edf9G?= =?iso-8859-1?Q?am2O5+3Fl8czn/hi0nMC3D7Oa2uNWAZYelxY0g2Epfcw37e6NumzUqCiYV?= =?iso-8859-1?Q?7NgkjajgU22t+TWnM7ZOkdpXrA4HHLCLFyC8SQhKb1zd3cu7gIqPdRFeF+?= =?iso-8859-1?Q?gwqRRiFDpPm5eO+JOyWbdCfAIr563HEYN9Ol/0BWivJOwJfxPN8ibvh+sK?= =?iso-8859-1?Q?0GOMhOEtouU0j68i/7Au/V2vjxGSX7XO090XmgPHZc/fI55+T49h89zUzO?= =?iso-8859-1?Q?I77cIvxQEtLs1Hg+CX5RZ6XVDyCYPQICM7PBx4uXMnjRfjhCkHhaPJQJqw?= =?iso-8859-1?Q?JGsEQcEYwN2QsEnRvCDLYT5uUSN3oE4lx1tCAe9DSVkJd7IGPPxz6/miJa?= =?iso-8859-1?Q?CTZe+Sb8h+UgYh8giPVxqNqV8QL8nycKl7ogyGIZttjwj+0Vwq0amtND4+?= =?iso-8859-1?Q?N9BU/qMc+7KSFFzrSfL5Ml6noc/GTV/Lq5MG2rVJuakMTz4DWUgJwHakOJ?= =?iso-8859-1?Q?DTQ5L4MkWzEinn5Mx1FWhVJD7sAlGdKG8+v9lf5snxTTaH7Zlhmb+y5Klq?= =?iso-8859-1?Q?ZlfZabfNy/jhlkBO4fAWgmo1y4Q4zdkr1Mwm3SXrvhWZhJzte5Y7U7GaGU?= =?iso-8859-1?Q?O0w+JM2FRUFVxXDNeAj/QondQClxBjbcngs0C8R9ftJgXwQBfDz8TMKLs/?= =?iso-8859-1?Q?bW0Ajb2JeD?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 898ab32a-5f3d-4939-f70a-08d94090cb0e X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2021 15:14:47.5262 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UH39RxqdCfGPsrgjSQuAuXWTnekOXH/PIh+i9oYbwo/vaJvHwv3R1sWLKInWwcwW0hKJJMdg4GR0EYUzq0IAHQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1387 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xbe-aln-002.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2021 15:14:55 -0000 Hi Balazs, To follow up with our conversation earlier. Andy and Juergen explicitly co= pied because they may have previously commented on these issues during WG L= C. I think that my comment regarding the "feature statement" and the flexibili= ty of the inline-method are closely related. I find the definition of the = inline-content-schema to be so generic that it effectively allows anything.= E.g., the drafts would allow me to publish a file that has an inline-cont= ent-schema based on robs-random-schema-format@1.0.0, and it would be very d= ifficult for consumers of the associated instance data file to understand t= he file schema. Similarly, I find that allowing revision labels (as examples to avoid a nor= mative reference to the module versioning draft), makes it hard for a gener= ic implementation reader of a instance data file to know how to interpret a= n inline schema. I suspect that this issue could cause problems in the IES= G reviews. Hence, my preference, for this RFC, that defines version 1 of the instance = file format, would be to more heavily constrain how the schema is allowed t= o be specified in the inline-method. Specifically, I think that it would b= e better to: - restrict the inline schema to only be defined using ietf-yang-library@20= 19-01-04 - only allow revision-dates, not revision labels. I would like to understand from Andy, whether he still thinks with these re= strictions whether the inline-schema method should still be under a YANG fe= ature statement? If/when the revision labels draft gets standardized, and perhaps also after= YANG packages, then we could do a bis version of this document to define a= v2 of the instance file format that potentially allows YANG packages to be= used to define the schema, and potentially allows modules to be identified= using revision labels as well as revision dates. Balazs, I'm good with most of your proposed resolutions, but have answered = one further question inline below. > -----Original Message----- > From: Bal=E1zs Lengyel > Sent: 05 July 2021 13:47 > To: 'netmod@ietf.org' ; Rob Wilton (rwilton) > > Cc: Benoit Claise > Subject: FW: AD review of draft-ietf-netmod-yang-instance-file-format >=20 > Hello Rob, > Thanks for the review. Here are my answers below. I will also upload the > new version asap. > Regards Balazs > ----------------------------------------------------------- > Hi, >=20 > Here is my AD review of draft-ietf-netmod-yang-instance-file-format-13. >=20 > Thanks for this document, I think that it represents important useful wor= k > for advancing the YANG ecosystem. >=20 > This document is in good shape, and I mostly have minor comments but with > a > few more significant comments. >=20 > Main comments: >=20 >=20 > 2. > In the YANG Module: > feature inline-content-schema { > description > "This feature indicates that inline content-schema > option is supported. Support for this feature might > be documented only via out-of-band documentation."; > } >=20 > What is the benefit of having 'inline-content-schema' as a feature? It > seems to potentially add complexity without any benefit, given that the > device originating the instance data file would effectively choose whethe= r > to use the inline-content-schema, hence I suggest that it might be simple= r > just to remove the feature definition. > BALAZS: This was explicitly requested earlier by a reviewer (Andy ?). > The system can declare supported/not-supported in design documentation. > In a use-case when a client or a design department is sending data to a > server this is needed. E.g. in UC2, Preloading Default Configuration the > designer preparing instance data, can decide to use or not use the > inline-content-schema based on this. >=20 > 3. > In the YANG Module: >=20 > "case inline", description: > The first item is either ietf-yang-library or > some other YANG module that contains a list of > YANG modules with their name, revision-date, > supported-features, and deviations. > The usage of revision '2019-01-04' of the > 'ietf-yang-library' module MUST be supported. > Using other modules, module versions MAY also > be supported. >=20 > This seems to make interop for consumers of instance data files hard, sin= ce > the schema can be defined by any arbitrary YANG module without updating > this > module. I would suggest that it is safer to limit this to the two curren= tly > published versions of YANG library. > BALAZS: I fully agree, however this was explicitly requested by some > reviewer earlier (Juergen ?) Shall I simplify this or not? >=20 > If additional modules are supported in future, then I think that it would= be > safer to create a new version of this YANG module that documents what > other > module formats can be used. >=20 >=20 > 4. > In the YANG Module: > list "revision" >=20 > Is revision expected to be unique, if provided? If so, should this be > explicitly stated in the YANG module description? > BALAZS: I don't think I understand your comment. There may be multiple li= st > entries for revision. The 'leaf date' is a key, so it is inherently uniqu= e. > The description may or may not be unique. I would suggest changing: For every published editorial change, a new one SHOULD be added in front of the revisions sequence so that all to: For every published editorial change, a new unique revision SHOULD be added in front of the revisions sequence so that all I.e., to also make it clear in the description that revisions dates are req= uired to be unique. >=20 >=20 > 5. > In the YANG Module: >=20 > Is an instance-data file allowed to contain both a revision and also a > timestamp? If so, is there any constraints on the values. If not, then > would it make sense to put them under a choice? > BALAZS: It is allowed to have both. There is some recommendation text > about > when to use each. However I can see some corner cases, when using both in > the same file would be useful, E.g. we want a timestamp including hour, > minutes, but we also want the history of the instance data set, including > multible revision/descriptions. > I propose to add: if both are included the timestamp, SHOULD contain > the same date as the latest revision statement. Okay. Thanks, Rob From nobody Tue Jul 6 09:43:01 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36633A2DCC for ; Tue, 6 Jul 2021 09:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 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_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 vHx2kR9_GPMj for ; Tue, 6 Jul 2021 09:42:54 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178773A2DCA for ; Tue, 6 Jul 2021 09:42:53 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id c28so15960924lfp.11 for ; Tue, 06 Jul 2021 09:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kLXovTCo8hmOGUlLCzfaxmR8KSBuo9FpGNagtO/JnMc=; b=dpvYh9Rv2KC2AveXT3dfcxbEwOuMrtElJnZmyBMT7m+9wsTlB4kqM5+Pahtda5C/q7 OXlQIEAXEesS2Wbth3q+azX93j1Ht20oBdYcEAne9rTm1O+aZi1iz5WHRuKsGRIHZ3L0 9FhzTG68qnXTe4ubCaK3SmviQBvkSA0y/SZYy+mx/6yBnThTyyfOheWLry0zipE7HKwR WMttnliptS2ke9EJuxS5owhMjDrtyot+UegNifIkUoOgEKCjw5gsJ6TMkRgxng3uezvb v5SV5PPpHuWMLeOCgBQdGOo/WoSAgQ2KHPEfEx3fXYZeLssg9z0liQ681gilUBBusrfx SvzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kLXovTCo8hmOGUlLCzfaxmR8KSBuo9FpGNagtO/JnMc=; b=SXDnUJDR/8STv6m9WoUb2dsMuOE7koeVr868Vg4GGcEoKz3YPA4diEwnTJdnRpNgca HqUF3ALun72/f/xnx+XsbOjNDJf5jiSEEi8Kzk9mhf8pR5dz1Y7gZYi1GDAARabQr5cT glqjXNZp1fkL7IxeZhAN8OY1uPdgcJQ2ChMZCxjLQrVjSV0tLiWywBYm+WV9EEg3Mq4o YI+QEf3VY+wsmV4VQt4UlBVUUk2TrInBgb1Qo3l11ESerx4DlYhciUqaZYDHr19X9nHs /caYguJrw3UaftqGHJf506Y4VkGwa4FP3kkC+Ul/wXRcHlACIi+oS/cC4gVrNCZxGcwP qJGA== X-Gm-Message-State: AOAM5311NupsZzXqvfQ9frsQOPg323RMIjj2ZZ3AnxK00ebTFHoPt+PU J4VdYUHqhMeptxKexzqXPP54JXbkoc4o48NGNeyjDg== X-Google-Smtp-Source: ABdhPJzOeTz0IaZHpDewzEJq9Xl3Xb8AP+su73cVbfMcRwhmH/cnMA49Q/UGETyHN0CUELeIqzsjiJcu1SmmB5SfNpM= X-Received: by 2002:a05:6512:210b:: with SMTP id q11mr14956265lfr.577.1625589770585; Tue, 06 Jul 2021 09:42:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Tue, 6 Jul 2021 09:42:39 -0700 Message-ID: To: "Rob Wilton (rwilton)" Cc: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= , "netmod@ietf.org" , Juergen Schoenwaelder , Benoit Claise Content-Type: multipart/alternative; boundary="000000000000d39d2005c6771c6f" Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2021 16:43:00 -0000 --000000000000d39d2005c6771c6f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 6, 2021 at 8:14 AM Rob Wilton (rwilton) wrote: > Hi Balazs, > > To follow up with our conversation earlier. Andy and Juergen explicitly > copied because they may have previously commented on these issues during = WG > LC. > > I think that my comment regarding the "feature statement" and the > flexibility of the inline-method are closely related. I find the > definition of the inline-content-schema to be so generic that it > effectively allows anything. E.g., the drafts would allow me to publish = a > file that has an inline-content-schema based on > robs-random-schema-format@1.0.0, and it would be very difficult for > consumers of the associated instance data file to understand the file > schema. > > Similarly, I find that allowing revision labels (as examples to avoid a > normative reference to the module versioning draft), makes it hard for a > generic implementation reader of a instance data file to know how to > interpret an inline schema. I suspect that this issue could cause proble= ms > in the IESG reviews. > > Hence, my preference, for this RFC, that defines version 1 of the instanc= e > file format, would be to more heavily constrain how the schema is allowed > to be specified in the inline-method. Specifically, I think that it woul= d > be better to: > - restrict the inline schema to only be defined using > ietf-yang-library@2019-01-04 > - only allow revision-dates, not revision labels. > > I would like to understand from Andy, whether he still thinks with these > restrictions whether the inline-schema method should still be under a YAN= G > feature statement? > I do not remember asking for this feature statement. Who is the client and who is the server, for a YANG instance file, sitting on a hard drive? IMO the 4 separate ways to identify the schema are 3 too many, but that is what the WG wants. It seems obvious that any reader of the file has to implement all 4 methods and any writer of the file is free to pick just one. So the feature does not really help. Andy > If/when the revision labels draft gets standardized, and perhaps also > after YANG packages, then we could do a bis version of this document to > define a v2 of the instance file format that potentially allows YANG > packages to be used to define the schema, and potentially allows modules = to > be identified using revision labels as well as revision dates. > > Balazs, I'm good with most of your proposed resolutions, but have answere= d > one further question inline below. > > > > -----Original Message----- > > From: Bal=C3=A1zs Lengyel > > Sent: 05 July 2021 13:47 > > To: 'netmod@ietf.org' ; Rob Wilton (rwilton) > > > > Cc: Benoit Claise > > Subject: FW: AD review of draft-ietf-netmod-yang-instance-file-format > > > > Hello Rob, > > Thanks for the review. Here are my answers below. I will also upload t= he > > new version asap. > > Regards Balazs > > ----------------------------------------------------------- > > Hi, > > > > Here is my AD review of draft-ietf-netmod-yang-instance-file-format-13. > > > > Thanks for this document, I think that it represents important useful > work > > for advancing the YANG ecosystem. > > > > This document is in good shape, and I mostly have minor comments but wi= th > > a > > few more significant comments. > > > > Main comments: > > > > > > > 2. > > In the YANG Module: > > feature inline-content-schema { > > description > > "This feature indicates that inline content-schema > > option is supported. Support for this feature might > > be documented only via out-of-band documentation."; > > } > > > > What is the benefit of having 'inline-content-schema' as a feature? It > > seems to potentially add complexity without any benefit, given that the > > device originating the instance data file would effectively choose > whether > > to use the inline-content-schema, hence I suggest that it might be > simpler > > just to remove the feature definition. > > BALAZS: This was explicitly requested earlier by a reviewer (Andy ?). > > The system can declare supported/not-supported in design documentation. > > In a use-case when a client or a design department is sending data to a > > server this is needed. E.g. in UC2, Preloading Default Configuration th= e > > designer preparing instance data, can decide to use or not use the > > inline-content-schema based on this. > > > > > > 3. > > In the YANG Module: > > > > "case inline", description: > > The first item is either ietf-yang-library or > > some other YANG module that contains a list of > > YANG modules with their name, revision-date, > > supported-features, and deviations. > > The usage of revision '2019-01-04' of the > > 'ietf-yang-library' module MUST be supported. > > Using other modules, module versions MAY also > > be supported. > > > > This seems to make interop for consumers of instance data files hard, > since > > the schema can be defined by any arbitrary YANG module without updating > > this > > module. I would suggest that it is safer to limit this to the two > currently > > published versions of YANG library. > > BALAZS: I fully agree, however this was explicitly requested by some > > reviewer earlier (Juergen ?) Shall I simplify this or not? > > > > If additional modules are supported in future, then I think that it > would be > > safer to create a new version of this YANG module that documents what > > other > > module formats can be used. > > > > > > 4. > > In the YANG Module: > > list "revision" > > > > Is revision expected to be unique, if provided? If so, should this be > > explicitly stated in the YANG module description? > > BALAZS: I don't think I understand your comment. There may be multiple > list > > entries for revision. The 'leaf date' is a key, so it is inherently > unique. > > The description may or may not be unique. > > I would suggest changing: > > For every published editorial change, a new one SHOULD be added > in front of the revisions sequence so that all > > to: > > For every published editorial change, a new unique revision SHOULD > be added in front of the revisions sequence so that all > > I.e., to also make it clear in the description that revisions dates are > required to be unique. > > > > > > > > 5. > > In the YANG Module: > > > > Is an instance-data file allowed to contain both a revision and also a > > timestamp? If so, is there any constraints on the values. If not, the= n > > would it make sense to put them under a choice? > > BALAZS: It is allowed to have both. There is some recommendation text > > about > > when to use each. However I can see some corner cases, when using both = in > > the same file would be useful, E.g. we want a timestamp including hour, > > minutes, but we also want the history of the instance data set, includi= ng > > multible revision/descriptions. > > I propose to add: if both are included the timestamp, SHOULD contain > > the same date as the latest revision statement. > > Okay. > > Thanks, > Rob > > --000000000000d39d2005c6771c6f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 6, 2021 at 8:14 AM Rob Wi= lton (rwilton) <rwilton@cisco.com> wrote:
Hi= Balazs,

To follow up with our conversation earlier.=C2=A0 Andy and Juergen explicit= ly copied because they may have previously commented on these issues during= WG LC.

I think that my comment regarding the "feature statement" and the= flexibility of the inline-method are closely related.=C2=A0 I find the def= inition of the inline-content-schema to be so generic that it effectively a= llows anything.=C2=A0 E.g., the drafts would allow me to publish a file tha= t has an inline-content-schema based on robs-random-schema-format@1.0.0, an= d it would be very difficult for consumers of the associated instance data = file to understand the file schema.

Similarly, I find that allowing revision labels (as examples to avoid a nor= mative reference to the module versioning draft), makes it hard for a gener= ic implementation reader of a instance data file to know how to interpret a= n inline schema.=C2=A0 I suspect that this issue could cause problems in th= e IESG reviews.

Hence, my preference, for this RFC, that defines version 1 of the instance = file format, would be to more heavily constrain how the schema is allowed t= o be specified in the inline-method.=C2=A0 Specifically, I think that it wo= uld be better to:
=C2=A0- restrict the inline schema to only be defined using ietf-yang-libra= ry@2019-01-04
=C2=A0- only allow revision-dates, not revision labels.

I would like to understand from Andy, whether he still thinks with these re= strictions whether the inline-schema method should still be under a YANG fe= ature statement?


Who is the client a= nd who is the server, for a YANG instance file, sitting on a hard drive?

IMO the 4 separate ways to identify the schema are 3= too many, but that
is what the WG wants.=C2=A0 It seems obvious = that any reader of the file
has to implement all 4 methods and an= y writer of the file is free to pick just one.
So the feature doe= s not really help.


Andy
<= br>

If/when the revision labels draft gets standardized, and perhaps also after= YANG packages, then we could do a bis version of this document to define a= v2 of the instance file format that potentially allows YANG packages to be= used to define the schema, and potentially allows modules to be identified= using revision labels as well as revision dates.

Balazs, I'm good with most of your proposed resolutions, but have answe= red one further question inline below.


> -----Original Message-----
> From: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>
> Sent: 05 July 2021 13:47
> To: 'netmod@i= etf.org' <n= etmod@ietf.org>; Rob Wilton (rwilton)
> <rwilton@cis= co.com>
> Cc: Benoit Claise <benoit.claise@huawei.com>
> Subject: FW: AD review of draft-ietf-netmod-yang-instance-file-format<= br> >
> Hello Rob,
> Thanks for the review.=C2=A0 Here are my answers below. I will also up= load the
> new version asap.
> Regards Balazs
> -----------------------------------------------------------
> Hi,
>
> Here is my AD review of draft-ietf-netmod-yang-instance-file-format-13= .
>
> Thanks for this document, I think that it represents important useful = work
> for advancing the YANG ecosystem.
>
> This document is in good shape, and I mostly have minor comments but w= ith
> a
> few more significant comments.
>
> Main comments:
>

>
> 2.
> In the YANG Module:
>=C2=A0 =C2=A0 =C2=A0 feature inline-content-schema {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "This feature indicates that in= line content-schema
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0option is supported. Support f= or this feature might
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be documented only via out-of-= band documentation.";
>=C2=A0 =C2=A0 =C2=A0 }
>
> What is the benefit of having 'inline-content-schema' as a fea= ture?=C2=A0 It
> seems to potentially add complexity without any benefit, given that th= e
> device originating the instance data file would effectively choose whe= ther
> to use the inline-content-schema, hence I suggest that it might be sim= pler
> just to remove the feature definition.
> BALAZS: This was explicitly requested earlier by a reviewer (Andy ?).<= br> > The system can declare supported/not-supported in design documentation= .
> In a use-case when a client or a design department is sending data to = a
> server this is needed. E.g. in UC2, Preloading Default Configuration t= he
> designer preparing instance data, can decide to use or not use the
> inline-content-schema based on this.


>
> 3.
> In the YANG Module:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"case inline", description:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0The first item is either ietf-yang-library or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0some other YANG module that contains a list of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0YANG modules with their name, revision-date,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0supported-features, and deviations.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0The usage of revision '2019-01-04' of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0'ietf-yang-library' module MUST be supported.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Using other modules, module versions MAY also
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0be supported.
>
> This seems to make interop for consumers of instance data files hard, = since
> the schema can be defined by any arbitrary YANG module without updatin= g
> this
> module.=C2=A0 I would suggest that it is safer to limit this to the tw= o currently
> published versions of YANG library.
> BALAZS:=C2=A0 I fully agree, however this was explicitly requested by = some
> reviewer earlier (Juergen ?) Shall I simplify this or not?
>
> If additional modules are supported in future, then I think that it wo= uld be
> safer to create a new version of this YANG module that documents what<= br> > other
> module formats can be used.
>
>
> 4.
> In the YANG Module:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0list "revision"
>
> Is revision expected to be unique, if provided? If so, should this be<= br> > explicitly stated in the YANG module description?
> BALAZS: I don't think I understand your comment. There may be mult= iple list
> entries for revision. The 'leaf date' is a key, so it is inher= ently unique.
> The description may or may not be unique.

I would suggest changing:

For every published editorial change, a new one SHOULD be added
=C2=A0in front of the revisions sequence so that all

to:

For every published editorial change, a new unique revision SHOULD
be added in front of the revisions sequence so that all

I.e., to also make it clear in the description that revisions dates are req= uired to be unique.


>
>
> 5.
> In the YANG Module:
>
> Is an instance-data file allowed to contain both a revision and also a=
> timestamp?=C2=A0 If so, is there any constraints on the values.=C2=A0 = If not, then
> would it make sense to put them under a choice?
> BALAZS:=C2=A0 It is allowed to have both. There is some recommendation= text
> about
> when to use each. However I can see some corner cases, when using both= in
> the same file would be useful, E.g. we want a timestamp including hour= ,
> minutes, but we also want the history of the instance data set, includ= ing
> multible revision/descriptions.
> I propose to add: if both are included the timestamp, SHOULD contain > the same date as the latest revision statement.

Okay.

Thanks,
Rob

--000000000000d39d2005c6771c6f-- From nobody Tue Jul 6 10:33:24 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97CD63A2F4D for ; Tue, 6 Jul 2021 10:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxkTdLbTMVZF for ; Tue, 6 Jul 2021 10:33:18 -0700 (PDT) Received: from mail-pj1-f45.google.com (mail-pj1-f45.google.com [209.85.216.45]) (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 ED3663A2F4B for ; Tue, 6 Jul 2021 10:33:17 -0700 (PDT) Received: by mail-pj1-f45.google.com with SMTP id h1-20020a17090a3d01b0290172d33bb8bcso1977740pjc.0 for ; Tue, 06 Jul 2021 10:33:17 -0700 (PDT) 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=CDvZYbIDfFsf6tl/cjtfZH9xmyKaZZ92wJFfninBgXU=; b=LV2AToxzShJLPyMStZELy6RU4o866G/CSdFAEfRSgLkbevMYOs7IjcYUavhV1K3gNY Ztt9IXvBErDejSr1sPTsOcvlOCdsgY6dEDiWUUBgUXM/NZo65jxZ43ytxPinEYu9O5F9 TF0muk/BqcgAde/Rz9YOQOTASFWoB770invuWiLMgbrSGu2+LshgshrXxtmMed/BPQ6w M1dnsZ/6cF8C08GFVB3mnV/lPW/udLR/+Usg/f5Z+Naqaay1u/xooheRC20nveRUjkAt uneLsZH2m+hljWN5YvaaoHIrgwiXykA6jJ4RfgQEQ9U+G0qdcxsG99WVVXdKxVFFDSSg FUqg== X-Gm-Message-State: AOAM533DHULQyfa3Td+JcaU+FbSfEla6Dn1NqTPxKht0OFhZCF1HJFBd phR891fuEe5XNBnnxQH5IL5tEw== X-Google-Smtp-Source: ABdhPJwWJE7WE4m/RjziwSP256j2ySDYI3W+dwmx83dDM6nx/C+vDdMolFnsQBJzAYBT1lS/VNhKzQ== X-Received: by 2002:a17:90b:1209:: with SMTP id gl9mr1525633pjb.213.1625592797348; Tue, 06 Jul 2021 10:33:17 -0700 (PDT) Received: from ?IPv6:2601:646:9300:791:b1c9:b90a:8e13:d96f? ([2601:646:9300:791:b1c9:b90a:8e13:d96f]) by smtp.gmail.com with ESMTPSA id x4sm19079282pgr.40.2021.07.06.10.33.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 06 Jul 2021 10:33:17 -0700 (PDT) To: tom petch , Michael Richardson , "netmod@ietf.org" , "anima@ietf.org" References: From: Randy Presuhn Message-ID: <26c27178-7dbd-de29-b99f-10a969257769@alumni.stanford.edu> Date: Tue, 6 Jul 2021 10:33:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.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: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2021 17:33:23 -0000 Hi - > From: netmod on behalf of Michael Richardson > Sent: 05 July 2021 21:40 > > Randy Presuhn wrote: > > In ltru the I-Ds contained both material for publication > > in the RFC as well as a *massive* amount of material for > > population of the IANA language tag registry. We needed > > it in I-D form for review during development, but wanted to > > remove all temptation to use the RFC instead of the IANA > > registry. > > > All it took was a word of instruction to the RFC editor > > to delete the many many many pages of registry content > > upon publication. Worked fine. > > > In this case, just tell the RFC editor to delete the > > IANA-maintained module. > > I think you mean, the RFC-maintained module :-) > How do we keep the YANG catalog from latching onto it. No. The to-be-maintainted-by-IANA module appearing in an I-D would never appear in the published RFC text. Randy From nobody Tue Jul 6 10:42:21 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D48A3A2F83 for ; Tue, 6 Jul 2021 10:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.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 6TLyqUhyjfNI for ; Tue, 6 Jul 2021 10:42:14 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140053.outbound.protection.outlook.com [40.107.14.53]) (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 6EFE73A2F76 for ; Tue, 6 Jul 2021 10:42:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CJN7xJH/fSNH31proNF8zmxFY6S0KBiMQer5lOeAGWZPOzWIrMDVaGL6rTcDOHEt9Oosqri/+B6rpD3/kig+XS8fOnRej1zC0zh/RR6pdi3iX4gSKJqY65Lynja35t0C5YcpoTUxiocMN89UbtR4a8FfYa4ayVKbaePWeyHqS58gVcRoJR8LT1Yg21V8PdGzMpLwkn+iSbHjN0UxN5kU6x9+n795KpHZWop93W0LFXohv39O83WHqLDFQrmoxk0yKp1ab5ec3GHRdJBZictf6jb5s/Pju3RHGFewa9DWBgRegQSlwGTJ6ZIxSpF2B6SgYA+tZs9Xv3xhrvfP382kEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CGy86c2G2xSZSDVJLTgE/xeLFPb+voHsR2f8twp0S4A=; b=EdLc/CQROApDY1UbwiHn0FdVpPSAEJyr9x5dI281TyRK+dMCUYoAUgcMqhXortqKhD+8KmZ+PzQWsuFHDMpa0k0R4q9vjMv51+/80dwuhudScWgJCc1qtTdKbxvBpuAmJ2UK0zWzJx3cwiS3RJlobNseJ4c+27SvlJi6tvu7uKyiA7oJl2ybi86Fs+zUTtfaGJvh1YoLKqroZo84zjpbzmhIoABHiHZ45j5TrIYOlF0mThBrufAE/7a4lAcIPnLiE9J78kOTLnaDGPtQLk3Qyq1beePNboTGwcD1EX1KHR2T1OjA/Efz81FZHjQ58QD6g5+1Ap4NUDp85s3BbyZwqQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CGy86c2G2xSZSDVJLTgE/xeLFPb+voHsR2f8twp0S4A=; b=Sz8IXJOnwobRpJD/HbznlZPIQecrOqGeLcpXcn7Wj/M2ubTElmrLzjVP59R2P2r2yzRvY9hBn8VczTE8eGiop0vV/OrmRAs5GyzksMq1hWGxloHJq/2IRRR8wjCeeKibt5gfrRZH/QnMo8ADUZHPe/Pz6pJRLt/mwx7mXfSDJi8= Authentication-Results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0625.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:199::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.23; Tue, 6 Jul 2021 17:42:09 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::d505:1bab:3e82:6d6b]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::d505:1bab:3e82:6d6b%3]) with mapi id 15.20.4287.033; Tue, 6 Jul 2021 17:42:09 +0000 Date: Tue, 6 Jul 2021 19:42:08 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: "Rob Wilton (rwilton)" , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod@ietf.org" , Benoit Claise Message-ID: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , "Rob Wilton (rwilton)" , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod@ietf.org" , Benoit Claise References: Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: PR0P264CA0208.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1f::28) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR0P264CA0208.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1f::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.19 via Frontend Transport; Tue, 6 Jul 2021 17:42:09 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 02dec1ed-b81e-4715-42f1-08d940a56107 X-MS-TrafficTypeDiagnostic: AM0P190MB0625: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: dvW8IfwAUcbF99PlueAm53N+jZtq0Ef3kfPajigcaDoj6X1w+Rm3UHRPNUPptPaMJYd4G8Z2GC2DXGmZl+AvvYaEabcD6awECeAAsWzhV2QIn95d2uLuEQ03vn99ghfqqTMJQFGD9aSLXlWEx52qmJgQRNFT0bQhyosKWQhp5JAXGAYVjApVw9wbUNCoHLLBLdT0LTBgtLwmjLmCTWPatmCfBkutRVEBpyeQHQBhVee0DYUWwCzLnCBZ/LGKRjhVT1ULejwTptD3yHUzHhbDRixe9jwDXbEXblKWw4d76NLkLFE4L6X/+ukf3JWV6juYoSlVE0t8VOMNMUIfhM4ktIkmHJra5yprwFeELO+nIMINwC5xu/zvlhhLQQsU6As5AM2uGg92+Z6X1vGP9dYeXe4W/U++tU8Ur0lvHjwkps+0fh7t3Eq/CC4ROCk5I06SEFZvmzc2SJI2k+WraPc0HztSFK9sCiC/5wcpVk9y7QgqJCECC6KFF+OtHbyyNRfWkUdRJKIB3QU07WTIcMTZPP3rFklujOJ0OzO3aIC2bHN8D7AlTiYklXsQA7kXwdINA5328b1560C2KaxMImzrAoe7R8NqYKCGl9bKqmO8++Z2gGh5nDiH72rsLRz1h6Son4BoJjQu5/EBimKBNSEdSPIDuc91n4Cq3FiRhtFaFVUA276fKkX72narQTJELBkNPmN3b1By+u3MTWNnJKvNyEY+QSYOWZs3lY8mH/P2FXUpSCwtMwh1WKh7Xl2xaXi+8B0e93sQuUuHGnzPtegwhh3SwLnS4cevZVRnUhEwaoI= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39840400004)(346002)(376002)(366004)(136003)(396003)(4326008)(83380400001)(316002)(1076003)(6916009)(86362001)(52116002)(786003)(26005)(66476007)(54906003)(478600001)(6496006)(38350700002)(66946007)(956004)(186003)(38100700002)(8936002)(3450700001)(5660300002)(6486002)(8676002)(4744005)(66556008)(2906002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?eVFfcRQnO1OQX7wfIpKtFekgdaKcD/YUd46KdN8JKyDYLka2RsXlywIhbVde?= =?us-ascii?Q?Go7oaDkNNogR9IC/yhzt+SyAa3SLERwG/cIiKH4TXgohunv14VUZp6S4V8bg?= =?us-ascii?Q?lwZj0zWzxMq0zmWQ9xqD1IY5Mta305ojrfoJghoxfmRIWlkuOe0RP33VKp9R?= =?us-ascii?Q?NZOxmQj5zScluvlzf/qL4G4tHy0BtmD5YfmwwC1JznXe1/r4dImUssa48PXC?= =?us-ascii?Q?hnGoRIl6ICymrQZghQDSMz+AT0jZyhN1zwopubaEZn2H6GRe3AeCanO8qJe6?= =?us-ascii?Q?PmRhidxI61BJy63f8kXgVXLNNRYGTK7smFjAf8xZg/S57ytCdZAZzEGAYpwh?= =?us-ascii?Q?Fj6il0K9ooA9OCRJNTJnjqTRo/37IFmjffxGe16ZwsbuEg8jgbQ3HnT+jBe+?= =?us-ascii?Q?pljb0wYqUxc5Gicaeg3MCSAUJysrKTWcGGR1vWpPytCA7dJ4SQYJjJIRkHap?= =?us-ascii?Q?90OvcyfHzEW9wvaQZZnHPzgdILOGPrpnljuMWzd0YK9+EGcLLU6DOEvau0s0?= =?us-ascii?Q?AgwRVBhxKAkPqV3+/5IzLTYyvx9VTu7+XTQjVd47x5OT2e2FD+OFqwMDfhnf?= =?us-ascii?Q?7dgmKeNmeGd61pi+9MJEEZzWkPPV3Y265gMSdiEeoOvKuSFTyKVDecXZeoyl?= =?us-ascii?Q?jvoNr+T4aJdTDwSJa7C/fmRJP5d0KiDQrWMAjgWrNclpbjTuqhjOaht294XF?= =?us-ascii?Q?qM/Y0JvQpa6oa5beGDcBWM3gyHQFGxBWibfAklfRWfOLEHWO5FIsvSB8mmWw?= =?us-ascii?Q?ENxKx158fTg/3bMXCsOucPDhznngPpC7gQu51RgtvM7kBFR2OXji63ICME2F?= =?us-ascii?Q?Up8/DWv0F4dOsYyenvgJrK1hMDx6pGmKued4dwfWtT4fUfr28hHzBl41mD+I?= =?us-ascii?Q?Me8GyKWZRyOrCIpmaG3CWm1ZUbmT8O+TdOImRIOSSwE+ryZgajLhqCMedgpD?= =?us-ascii?Q?oiq7kxjp3rWLdBQY2qfcVuEwrmWK7n/XU6+rHWc4qdUDRGBlwPNe9KcFRcWn?= =?us-ascii?Q?t/Fv2uUneUOFXxqdPIQ7qkq00b5wvrH9lo3ToWpcT0mMxejbFBK0OcFlGYZc?= =?us-ascii?Q?JaKTHQfRsgMWqPdsvwhaj1IkzbNQGJd+ryqMd682rh8JtfXbieXXTFfIZzxw?= =?us-ascii?Q?54F07LVXtKvNiMakFJI3XsGALCM9WW3o6yLJbL9LJmGiY1lpFfo3ryAhA3GT?= =?us-ascii?Q?K8FOCexneqtLXiUWtQz0MGlWm1529ikwAKNmeqmnZoudr6a2Kba0uaawDXOO?= =?us-ascii?Q?z6LMh2HAbVyYctSqdQpn2B159CTMJzlqyp82v7DScDkv/6fDlXFJPq6dyIBi?= =?us-ascii?Q?LeEpcjpsfQ/ubjW7rL2bGzLr?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 02dec1ed-b81e-4715-42f1-08d940a56107 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jul 2021 17:42:09.2796 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: G5MWMjjND79KLO4uAyKZu0xyLMKGbyW3/+IWUvaR93PYosi/HxBlIRmsV9e3AuLzJbw2euTyQR2nfngKfWkKHXEHpbpwGQ30sY71x6yWRxk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0625 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2021 17:42:19 -0000 On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote: > > IMO the 4 separate ways to identify the schema are 3 too many, but that > is what the WG wants. It seems obvious that any reader of the file > has to implement all 4 methods and any writer of the file is free to pick > just one. > So the feature does not really help. > The feature statements declare that implementation won't work together. Back in a day, the IETF was all about interoperability (and implementation costs). Nowadays we seem to be fine if implementations declare that they won't work together. Well, still slightly better than having implementations fail arbitrarity. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jul 6 10:57:09 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE2033A2FC8 for ; Tue, 6 Jul 2021 10:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 f-ColnO9g4VT for ; Tue, 6 Jul 2021 10:57:03 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 C6BC53A2FC5 for ; Tue, 6 Jul 2021 10:57:02 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id c28so16357705lfp.11 for ; Tue, 06 Jul 2021 10:57:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=LOje3ApcdPX0dFBlgAkGocycX0FcJZYYRKI8mzFv4Nc=; b=vtXwuLkQnT7mAbEmqx16tbmOi+35urtOnyOo7F7C3TOqxFsXXJVHk+8GUguHVeb1Dd 8mAYNZMB9J8n6ZmrUXrE0vbXwGGAXExUi586+7znIG95IqIllB1o8MReOgHAYFUrwNDD KcTnGw93l9z/tAmuaRryvpiLHEGYUpw1TnlMPc/jGQzZf+Kr0QqjlA4kK/4RFz/Q+aBD /Ul1toGm09XXKVr4MuUh5kfRrSrkFDh341OONh8HS6UkmgPrdatzRYG4sh62uFUIvCby BrWdu/d6CgOmJkail0UCsY0Qv5VxheqWvn3ek+ZRT/dbwjMcD8EpBA0t+TymmAndFuze Km/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:references:in-reply-to:from:date :message-id:subject:to; bh=LOje3ApcdPX0dFBlgAkGocycX0FcJZYYRKI8mzFv4Nc=; b=B32RXM9T9bt4u+5ew/RZjrPyHhBg2tG0CmsaEg6LobPHc9wiFk3jbI5hvDi88MEhBt Zuj3D4pqQqHInj5mvlS3PNPfC065BALpIDFRBJ/RzxOfEIzAsWGRWaEByLEpYSyBAFdr JIhN2uvABPKVZhJttG3DhmO5eWEpsbYDKep9PqhjyQnjAcZD65DbQIwWTbb3DfAEjSuq YvloAJUHRUzkwT9XNAntedVv4YjYHIBrhu27kPPDzTjXyWpWI5hJH1JWzfmbzOxYUi9l ypC8Jko8IdVS+mgWMcReN9PCtTXOU+pZcl9xWMd4pZeIpVegi9hIifj39RWA/4oBw+qF glig== X-Gm-Message-State: AOAM531xmjUdGd0R7rf21oEht0n8grKdO+MeTH2/L2Hs715XkpOkptFz PY74FqaK92LV18q/m05n05yfBSfzJJgSdPr4XSB/UA== X-Google-Smtp-Source: ABdhPJzRLzhpIUkjwP3kO1KrhHwhL9lpXnDnwLzQc2UYLv4WH2f5TiI3NHlXFv+nngVqqaDzCK5kcgNfHzJqJJtcKtY= X-Received: by 2002:ac2:5b52:: with SMTP id i18mr15788995lfp.553.1625594219596; Tue, 06 Jul 2021 10:56:59 -0700 (PDT) MIME-Version: 1.0 References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> In-Reply-To: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> From: Andy Bierman Date: Tue, 6 Jul 2021 10:56:48 -0700 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , "Rob Wilton (rwilton)" , =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= , "netmod@ietf.org" , Benoit Claise Content-Type: multipart/alternative; boundary="0000000000000225e005c6782667" Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2021 17:57:08 -0000 --0000000000000225e005c6782667 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote: > > > > IMO the 4 separate ways to identify the schema are 3 too many, but that > > is what the WG wants. It seems obvious that any reader of the file > > has to implement all 4 methods and any writer of the file is free to pick > > just one. > > So the feature does not really help. > > > > The feature statements declare that implementation won't work > together. Back in a day, the IETF was all about interoperability (and > implementation costs). Nowadays we seem to be fine if implementations > declare that they won't work together. Well, still slightly better > than having implementations fail arbitrarity. > > This is a text file stored on a USB stick. There is no client or server. Just readers and writers. So how does a YANG feature work here? The reader is supposed to know how to find out if this feature is set before opening the file? I don't see how server capabilities discovery is relevant to a YANG instance file. The reader code will simply attempt to read the file and fail if it encounters a format that is not implemented. /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --0000000000000225e005c6782667 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 6, 2021 at 10:42 AM Juerg= en Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Jul 06, 2021 at 09:42:39AM -0= 700, Andy Bierman wrote:
>
> IMO the 4 separate ways to identify the schema are 3 too many, but tha= t
> is what the WG wants.=C2=A0 It seems obvious that any reader of the fi= le
> has to implement all 4 methods and any writer of the file is free to p= ick
> just one.
> So the feature does not really help.
>

The feature statements declare that implementation won't work
together. Back in a day, the IETF was all about interoperability (and
implementation costs). Nowadays we seem to be fine if implementations
declare that they won't work together. Well, still slightly better
than having implementations fail arbitrarity.



This is a text file sto= red on a USB stick.
There is no client or server. Just readers an= d writers.
So how does a YANG feature work here?
The re= ader is supposed to know how to find out if this feature is set
b= efore opening the file?=C2=A0

I don't see how = server capabilities discovery is relevant to a YANG=C2=A0instance file.
The reader code will simply attempt to read the file and fail if it = encounters
a format that is not implemented.

=

/js

Andy
=C2=A0

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>
--0000000000000225e005c6782667-- From nobody Tue Jul 6 11:19:44 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85983A3066 for ; Tue, 6 Jul 2021 11:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.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 VoB-MHq00CGI for ; Tue, 6 Jul 2021 11:19:38 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2073.outbound.protection.outlook.com [40.107.22.73]) (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 0D9E93A3064 for ; Tue, 6 Jul 2021 11:19:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O94vP+lkX3ZCh2zzaYxIZqxUFIXJ/+rabTFn04PM863VPa4/geqwdk+0uc3Pt6lmEzVYn/9f7cgvbB5QkK0rDsHD+D7IlYZT7xIYdYy0FMeswLSN4+Zh4SaU4yZD6hm6Y/e1SJa3P+XmXeoqZ+ztMPrhSuciuukIK7KkPw+aGPlkDfAEaBLIDgt7KyQEycKn5YoExxAxsZRmtJa4qmi7JpRo1CkzlQhcHBRuRrN7FO8ZVuijLe0ihmtU5alAnbreJoSKdqU3V6mfBD//WoRdc0sf58UVvxjJD2lw23Z9DgzrlIo5U/vyufEnCYWVIQ8tfXVGIXHfp0UlqfH2f2emJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GKt5svH68vfeeiejU2uqJrhCRFSkl4LXEdozhLeT8P4=; b=QXoRcZ4S8XifElWTdoqds6zhJiqY8hKSrZTSguviTXKZI1hh+PRwA+kjqagqjdtzRNGDtKdtWVbcTbDLdQEwLI8KSG/LZD0fcKZ/1wqJlv2wH76FXxufgZ6z+PA/EKwInUUcFGU5HuB5i+n2nJ0ZAS4lwHIWnFzr8tUqQj3JygdM9hKfGkJqkR5UJyEeAZYb92U+w8+yhmx8vDD1yvnMJStbTP8EBUqBAPzQZ+fsw+/86HUbUvDQABEOus2v+VMrXEpoYKcEQ+oBBpzGmKIAlwFevu/xU/i4BmBRYLxrehsxrzcLGHnwYLT6KeV/6kJAuQALft9TPfZPVaaf2V8tBQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GKt5svH68vfeeiejU2uqJrhCRFSkl4LXEdozhLeT8P4=; b=O8wwQ6xAhY+MJrhLrJBjDeNFk2ZrfbC0iBWKD0BkaS5zJYTtpRTq1b+qmKWVTMWhaT2qPkgX9x802I/C/Ww1YzkhguaQZf8uqFBawOhmUkJrErisqbNS1T3CH9VmvH6dXo8g6WQMviBXobUvqtZ+wOCEwF7ObZR8PXwQH0gJKL8= Authentication-Results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM8P190MB0994.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1de::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.22; Tue, 6 Jul 2021 18:19:35 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::d505:1bab:3e82:6d6b]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::d505:1bab:3e82:6d6b%3]) with mapi id 15.20.4287.033; Tue, 6 Jul 2021 18:19:35 +0000 Date: Tue, 6 Jul 2021 20:19:33 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: "Rob Wilton (rwilton)" , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod@ietf.org" , Benoit Claise Message-ID: <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , "Rob Wilton (rwilton)" , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod@ietf.org" , Benoit Claise References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: PR1P264CA0029.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:19f::16) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR1P264CA0029.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:19f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.19 via Frontend Transport; Tue, 6 Jul 2021 18:19:34 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 09ab4037-3ae0-4498-15ea-08d940aa9b6f X-MS-TrafficTypeDiagnostic: AM8P190MB0994: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: FmscJKepmy4y5ZLH1c/HG80DAh3RDqLvNJBmqQVeUkWyINDSuBSV5VKjHd6TH1W8D2pJa7FUS7+L+lLGM0UbS6+YJr82ozDFDLDoWQLXI9z0Yo6x82YyThx0H8Hay2KxTyrLwGZngKV3/EcL8IwGoiBOgMR09FYR4IWxS4o4JBhZWT1Xt9A46aAhhGKRAv7nq4vwb8PzU+mKMrRxilrtlAHPqZB5SjBAiHP+kDXtBYGfPCM4hSf5G3daV8aM64yZDLehA6cHAoUtv9rRT3ANebdQ2xVLJV/dIKPWGeXVsFt5z1KenDHiRT7NUIZ4vAPeBw34v+wfd8Uh3y+xf7Txp5SfbXhVvPk1L2pxStANZSgCXwdymOyBij6AZK7d+WjagMwSVIt8JJ9+OhsAM+KKC8lDPJGHFjOadBrG4jg6v0zXnD7igTmjAokr40n9+GUuvi51oEtrqSI4wUj4SWCM3YG6c3ml6d/mg+JqL1lotdbRTXcN6f6d0EGZUpjBEUtTlR89Ms1WRhmhla05o7jrz1JRx0SRo11k23bbYE91kX7hJ3nKZmgXjn2vGzMf77oxJlTTi+kPO0SNy76cXYu7J/qCSHbn/5roGkkPhOReTFiuECn3GujB4dvty1uymD7LdbtcsTrQ/ldVw/OP1yrHaP0Wzpnoj6zQjNYIZPRUHm51GkevEeHFmQyqO5c5Zg1ed+kkN7kanNt13PzTjho9OJyRho5Msw5xlN+IAE74qGO1ZcsNVBtE4rxQ5cHYdDqtw48xuOx7mNE0StS12mjKcg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(39850400004)(346002)(396003)(136003)(366004)(52116002)(38350700002)(478600001)(26005)(8936002)(956004)(6916009)(8676002)(316002)(186003)(5660300002)(6496006)(3450700001)(53546011)(1076003)(54906003)(2906002)(6486002)(86362001)(38100700002)(4326008)(66556008)(66946007)(786003)(83380400001)(66476007); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?qLXxnQH5glaiQmwMdgw4hZN/qCLGn4OU61521AuHMrFug8s5CnV1FNtr1HpA?= =?us-ascii?Q?ipzlr3tDoLKzdON+glM9DxsFLT3gJ6bE3DGxrDxO/m3IXj39sNFt/bHqCeDL?= =?us-ascii?Q?SxfmXyrWaUoXrRbDH2ff5WwfDcHdpvCNRyrebd+MVNzsWUSQXzzlEORdWzCX?= =?us-ascii?Q?qc19WQlYHGZ2UfE0iA+k0kbtzsRJj8sPhFbanURfeksHrhoh5H1rAWCsqfb7?= =?us-ascii?Q?A63i1KruSga9zYYHwC3Fi9I604gjycbxmzgtbwJAynLiWjWpvfFszzXDTGV+?= =?us-ascii?Q?ikbWg6mRWBFL/9QTQn9wNlMPWcjT96tdCHSDOqC331FlVVXuvxfAt+E0PxWu?= =?us-ascii?Q?b7JM33oSw0VZ3zUEXthYY/d7OqOxlGE7lSev11m6DZJQZ3kX12iB1WQJVDLa?= =?us-ascii?Q?imJD2YXCBOWhOfSageBfL7HsWwhyjDSy/zIYonDD58WokTFIeEnyH2rOKHp/?= =?us-ascii?Q?Iup72uV6CO9nVJBHcOX3+mt82Z0Cq88uZ7SeWl0znnZDQD4m6AEAlAUe9TIp?= =?us-ascii?Q?+oY9VtJxRgENGahSwRGljZDfB4l4kSphUjQgzOrpoHP9le77JnVvGqvcADGE?= =?us-ascii?Q?P2G6k8IefeLmcyjyd9RDRxoIfzeTtZGBB9YR6fhlTwuQVlQT1Da+eEURq3cJ?= =?us-ascii?Q?tTHh6ismHRdxZh4DNX0a9hcz7nUT8tJe+nMZMa2BziDdzbbN416XE/94rEfv?= =?us-ascii?Q?c8HSssyGkL2hmYKwYTNl+WISImXlZFOKEcN1sauMZxrt1gXc4WfxiVESvZuv?= =?us-ascii?Q?h/h6x2Qpuwb9Vb2xA1g+m6sE3RSjHtKNTcibshrLbNnl2aSevMeRMJvf13XT?= =?us-ascii?Q?po5h4/5gmF+4QzS5YPRZT9ey+bkSUremoOmWsUJoKC2R09eCdQsE9VgeLa1+?= =?us-ascii?Q?HoDR23ezndvel1Vakzep5cQaeaK7NBP+6P3SbVOHyio9V8ezJeXY2cxHl3IW?= =?us-ascii?Q?bnCm7vVzBYbnCfLuA8VInKVFtCISWnQyquazxaSLlQe6BsVDRIU61rnGD5gO?= =?us-ascii?Q?xEVTPkAvj16QnH624HJbHy3UnSsgVRtxr9OOstZlhDQgDNhw19FIh+89hq95?= =?us-ascii?Q?Ck3YGjK9LZRPfbNjaAumnJ5mTUzbYgxfux2ZnL6NsJ3VJwPyShKg2Kz5ox/I?= =?us-ascii?Q?YBtREVByVtHavSC8nV0kDNZp/TsDhtnfBlQlcpV4rgz8H5VzYzWWYINkniDp?= =?us-ascii?Q?2A/MfZznFKsnMB0xUJODKbD8bVEFPw26n2D+4sVUz1cPS1LVLF8aOaSOBOPo?= =?us-ascii?Q?iEjEy+851sUfQxiRYzjrFs2Mj1KjGSEqYOzcP+TEqOZEuFU670+GgnjBiNtC?= =?us-ascii?Q?VeZ69uWyFRPOa5QSwrWdDtYi?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 09ab4037-3ae0-4498-15ea-08d940aa9b6f X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jul 2021 18:19:34.9009 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: q3xqAqZi5sCySpczIgxvwXB5PSVHiljBcEJ0l/RhF0gw+m8tjiKJNHX5kPvaTQdQ9M61GkDXCt52XvIz6KQiZi7n3D5NaJYAEXGGU6BYPjM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P190MB0994 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2021 18:19:43 -0000 On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote: > On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote: > > > > > > IMO the 4 separate ways to identify the schema are 3 too many, but that > > > is what the WG wants. It seems obvious that any reader of the file > > > has to implement all 4 methods and any writer of the file is free to pick > > > just one. > > > So the feature does not really help. > > > > > > > The feature statements declare that implementation won't work > > together. Back in a day, the IETF was all about interoperability (and > > implementation costs). Nowadays we seem to be fine if implementations > > declare that they won't work together. Well, still slightly better > > than having implementations fail arbitrarity. > > > > > > This is a text file stored on a USB stick. > There is no client or server. Just readers and writers. > So how does a YANG feature work here? > The reader is supposed to know how to find out if this feature is set > before opening the file? > > I don't see how server capabilities discovery is relevant to a > YANG instance file. > The reader code will simply attempt to read the file and fail if it > encounters > a format that is not implemented. I assumed that the features are carried in the instance file, i.e., the file declares that it uses way X to announce the schema and then the parser can fail with a suitable error message. If the features are not carried in the file, then they indeed seem to be useless. Perhaps there are Y different ways to announce the features of the instance file as well, I did not check. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jul 6 12:28:29 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B03F3A3283 for ; Tue, 6 Jul 2021 12:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 Cq5X0nsShN6U for ; Tue, 6 Jul 2021 12:28:22 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30A563A3280 for ; Tue, 6 Jul 2021 12:28:22 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id k8so30572318lja.4 for ; Tue, 06 Jul 2021 12:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=YSNC9gKzQAdS2J1F3gENV3r36O5hgU45uEB8Dx6/Pr0=; b=lZw8bB+vM3h3AV+L0uYDQhX4wg0WUVl/bz6FEKJi2Pg7hkawvcrwCUxLgJiIrH7ofH rmHd3M9aN/mGFvcMtTZqijS6PVmXNvUoBwSOiBrm36hWShKsYIhyh4Vvu8IkIBvMoTJQ eITRb0tPLsK39KOz0QklUps94zUYq/B67hNNWZkmg88F41QELkVE33aL6+VSb/cpT2hD K5lBKtgiTW4QkUmBo3k8U5upLqByxPxnuzgUYeud93Ai2DU2WlIJDatylKO10vSbqzyL JEPuGQx7uoIdJW/tFNwPe66be6TzAOMX6W8SQWNfZhuKjf3BK5FIBUkiTmQ4GQjAWpiu /DIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=YSNC9gKzQAdS2J1F3gENV3r36O5hgU45uEB8Dx6/Pr0=; b=Mbbxs53J3Jq5T69y+qsUZxiZA8D1X0xtsVNMN/obbsD5vrRYcqc1H9JCecAYNsQ1oC CMf4pCNtYvkuUqrEEjExwcRdQnX63KHuZXuEQo9sZWmJBAnc1lrmkLf5/aOZEdaLsgF7 /lWyx/9Vv8W6e8/Jgm0hzCTTPokikeovM1UBBZiBZxLkji3iLHE8XL/HHIDBmVi+WMMd XopmUHlbazNUNaDjNJvMy2uvnXL1OyZS+i6BeQ85KaWaDrvy1JTl8XM7d5Phlp1kClNA aREed4jDKsd76uSnfxfWa6YDqXSotDO2TmMtpbB2ERgHZOg9F4f1q4+75+9TYDM2lI3H EQyg== X-Gm-Message-State: AOAM531I9uiF9G9f+pDgWnIBrsO5xFe4BVprhQG5t9da/K+SuzC/HrEn ZJe+/tDtE+sB2UWYyzNiu+wpRhqYGFSPCe79q4yRAg== X-Google-Smtp-Source: ABdhPJxMi6NL1w2REY0UNhk0OGX4FXVf9ULzvriy602Zo82AOqttM64F3T0BKqHI/1ZBSr0mMZAuX8g9C4PCmWZSTK0= X-Received: by 2002:a2e:8215:: with SMTP id w21mr16129338ljg.160.1625599698882; Tue, 06 Jul 2021 12:28:18 -0700 (PDT) MIME-Version: 1.0 References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> In-Reply-To: <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> From: Andy Bierman Date: Tue, 6 Jul 2021 12:28:08 -0700 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , "Rob Wilton (rwilton)" , =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= , "netmod@ietf.org" , Benoit Claise Content-Type: multipart/alternative; boundary="00000000000099674905c6796cf2" Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2021 19:28:27 -0000 --00000000000099674905c6796cf2 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote: > > On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote: > > > > > > > > IMO the 4 separate ways to identify the schema are 3 too many, but > that > > > > is what the WG wants. It seems obvious that any reader of the file > > > > has to implement all 4 methods and any writer of the file is free to > pick > > > > just one. > > > > So the feature does not really help. > > > > > > > > > > The feature statements declare that implementation won't work > > > together. Back in a day, the IETF was all about interoperability (and > > > implementation costs). Nowadays we seem to be fine if implementations > > > declare that they won't work together. Well, still slightly better > > > than having implementations fail arbitrarity. > > > > > > > > > > This is a text file stored on a USB stick. > > There is no client or server. Just readers and writers. > > So how does a YANG feature work here? > > The reader is supposed to know how to find out if this feature is set > > before opening the file? > > > > I don't see how server capabilities discovery is relevant to a > > YANG instance file. > > The reader code will simply attempt to read the file and fail if it > > encounters > > a format that is not implemented. > > I assumed that the features are carried in the instance file, i.e., > the file declares that it uses way X to announce the schema and then > the parser can fail with a suitable error message. If the features are > not carried in the file, then they indeed seem to be useless. > > Perhaps there are Y different ways to announce the features of the > instance file as well, I did not check. ;-) > > Now you made re-read the entire draft :-( I cannot find any text how the reader knows if this feature is set before reading the file and finding out. I do not see any significant use-case for the Inline method and none for the Uri method. Nor do I see any reason why the Simplified-Inline method should not be mandatory to use and always present. If the use-case is offline server validation then the YANG library details need to be known. The entire YANG library for the server (or relevant parts) are recorded in the Inline method. Except it is complicated to store the info about how to interpret YANG schema by reading instance files and guessing what the "anydata" contains. I actually prefer a simple string based on RFC 6020 URI method, since it can be easily integrated into the Simplified Inline form and can be parsed without guessing anything about the contents of anydata. https://datatracker.ietf.org/doc/html/rfc6020#section-5.6.4 e,g, OLD: case simplified-inline { leaf-list module { type module-with-revision-date; ... } } NEW: case simplified-inline { leaf-list module { type union { type module-with-revision-date; type string; } ... } } Example module leaf-list entry: ietf-interfaces?revision=2018-02-20&features=if-mib,arbitrary-names&deviations=acme-deviations IMO Simplified Inline SHOULD be the only format, and the other methods can be removed. /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --00000000000099674905c6796cf2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 6, 2021 at 11:19 AM Juerg= en Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Jul 06, 2021 at 10:56:48AM -0= 700, Andy Bierman wrote:
> On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
> > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote:
> > >
> > > IMO the 4 separate ways to identify the schema are 3 too man= y, but that
> > > is what the WG wants.=C2=A0 It seems obvious that any reader= of the file
> > > has to implement all 4 methods and any writer of the file is= free to pick
> > > just one.
> > > So the feature does not really help.
> > >
> >
> > The feature statements declare that implementation won't work=
> > together. Back in a day, the IETF was all about interoperability = (and
> > implementation costs). Nowadays we seem to be fine if implementat= ions
> > declare that they won't work together. Well, still slightly b= etter
> > than having implementations fail arbitrarity.
> >
> >
>
> This is a text file stored on a USB stick.
> There is no client or server. Just readers and writers.
> So how does a YANG feature work here?
> The reader is supposed to know how to find out if this feature is set<= br> > before opening the file?
>
> I don't see how server capabilities discovery is relevant to a
> YANG instance file.
> The reader code will simply attempt to read the file and fail if it > encounters
> a format that is not implemented.

I assumed that the features are carried in the instance file, i.e.,
the file declares that it uses way X to announce the schema and then
the parser can fail with a suitable error message. If the features are
not carried in the file, then they indeed seem to be useless.

Perhaps there are Y different ways to announce the features of the
instance file as well, I did not check. ;-)


Now you made re-read the entire draft = :-(
I cannot find any text how the reader knows if this feature i= s set before reading the
file and finding out.

I do not see any significant use-case for the Inline method and none= for the Uri method.
Nor do I see any reason why the Simplified-I= nline method should not be mandatory
to use and always present.

If the use-case is offline server validation then t= he YANG library details need to be known.
The entire YANG library= for the server (or relevant parts) are recorded in the Inline method.
Except it is complicated to store the info about how to interpret YAN= G schema by
reading instance files and guessing what the "an= ydata" contains.

I actually prefer a simple s= tring based on RFC 6020 URI method, since it can
be easily integr= ated into the Simplified Inline form and can be parsed without guessing
anything about the contents of anydata.

e,g,

OLD:
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0case simplified-inline {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf-list module {
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type module-with-revision-date;
<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ..= .
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }

NEW:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case simplifie= d-inline {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf-l= ist module {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 type union {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type module-with-revision-date;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0type string;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 }

Example module leaf-list entry:

=C2=A0 =C2=A0 =C2=A0 =C2=A0ietf-interfaces?revision= =3D2018-02-20&features=3Dif-mib,arbitrary-names&deviations=3Dacme-d= eviations


IMO Simplified Inline SHO= ULD be the only format, and the other methods can be removed.

/js


Andy

<= /div>
=C2=A0

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>
--00000000000099674905c6796cf2-- From nobody Tue Jul 6 16:59:35 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 729CC3A08B1; Tue, 6 Jul 2021 16:59:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-netmod-nmda-diff@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, Joel Jaeggli , joelja@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <162561596844.31608.5688267766928727482@ietfa.amsl.com> Date: Tue, 06 Jul 2021 16:59:28 -0700 Archived-At: Subject: [netmod] Erik Kline's No Objection on draft-ietf-netmod-nmda-diff-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2021 23:59:29 -0000 Erik Kline has entered the following ballot position for draft-ietf-netmod-nmda-diff-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [S5] [question] * In the output yang-patch response when differences are present, is it theoretically possible that 'create' or 'insert' operations will need to be represented? If not, why not? [S{7,9}] [observation] * The last paragraph of Section 9 and the whole of Section 7 seem to be saying the same things? Perhaps consider if it's better to just say them once in Section 9 or say everything in Section 7 and just have the last paragraph of Section 9 say, in effect, "see also Section 7". From nobody Wed Jul 7 00:49:25 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BC73A0C3A for ; Wed, 7 Jul 2021 00:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WDKshlCzeAGH for ; Wed, 7 Jul 2021 00:49:17 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2071.outbound.protection.outlook.com [40.107.21.71]) (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 BF0623A0C37 for ; Wed, 7 Jul 2021 00:49:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lbIUERuA359ycM+hqF9CLgWK3acUNtsxz9dJI9q74c5Tx9kGTMbBw3WHmRkx39xsQQv+5xp/aFQP2vX/zgSYREG30DhheHwMzeotW0fjlt5hB6H8faj+0S6u5SQBLiMlM1/C865kjHUMTlYnsif4SFfPg0l1xgFjzQdShGL2E+amc7VuPUnuPOcO3/SVP9t/R9c6UCX/C9GYTJ3cYkEoLNrse2wliIG1P/fhD8HT0EI4neKSmfdzo/vUeUP0cvrNkbn9krD5LuH7a1X1HshkOAaiN/6ySa8woX95YVvjN6TYYJjIgnQcS7dRiTcZH2eihvm1ocp0MblCI8G7AjvlaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mfnkz/t1uoIi0/LggmPJp0kLXw68XaKXsTM3qNPLE9Q=; b=cCPunwc+aGltnat5fQ/ys4j0n5LuhKHlzlhPN9/y23DcuEt0iaJEE2YlyvhXxieAmZzwneYT0sUxbuA0apPtJ1T/Jr5vDClTDYJKzKC7dlhZTr3vhE67sd1YwuC/ejSpFS2SjV/bHxAIqF0llIOyj9kJX1LfUOAb2x1HaDohNODC76lqQpT0P0ZIDlvk0EB5o8hEWC/EcIcC7nKOPQEC+uWqUItYn0zeU1r7gv97zCMeG3joMumWG9OqUkh1QRsJMBL3liVlrzRgyyyLJdZQvR7HqK3yx1nMfN1vF9ZX3hVLqxZd7exGn8kDDNrz78eLgXu3XOHqJLsvl6btloC4Xw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mfnkz/t1uoIi0/LggmPJp0kLXw68XaKXsTM3qNPLE9Q=; b=N0yiLTJ3LkDTaLOVvhzSUOMlfGSFp8veYPWJCa9Hhu2HYroGsKa7pP7dEGoxOjJUT0Gwca6ULEmTvcHOwCFo3L3CRx/9ycCi9EE8hinKD+xgAOf50iZflBEM57LIHhe5KuEzRusuxUfANhYpDKW3zqG7OZM4X9diXIz0kwfBZp8= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8215.eurprd07.prod.outlook.com (2603:10a6:20b:322::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.21; Wed, 7 Jul 2021 07:49:08 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4308.018; Wed, 7 Jul 2021 07:49:08 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: "Rob Wilton (rwilton)" , "'netmod@ietf.org'" , "andy@yumaworks.com" , Juergen Schoenwaelder Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAuhzfQ Date: Wed, 7 Jul 2021 07:49:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bfcca319-bd87-405f-9564-08d9411bb3b7 x-ms-traffictypediagnostic: AM8PR07MB8215: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kzYaHAt/qRdGVwIY2mCLTm2YwhrasqHMxiD3usk9rWVIm7xAz1OXlPoJvf0ga00KMVkboMUKOuAYvLqWgCtR9fdr/czkI9BiyAu4ejquSH18n+G+T/5zRAHjrMU89307C8JznLgf4VQzvArn+ZkpecgXkoWUh3z07pf/F79Cw7QcXZgnsnLsLFwS9k3RBF8L8svjqQv9DZcCMjV7MeXI81sFNnYOqF32a4jGpMJsltoSpdvfqGoKsu36UEH7YY9wcdn5sFLX9vBSO0b5nm1zEreo9UvCsFUY9LZOvwUi0/cUJM5qy0l3w/5G37AwdyE5Q65qGXP5gMTCTnjEEavydXufKsK2mlUTFfMvxhMOLilA8OqQ+yOpxGGgD1udbKMBp8Q2ISIpsj6m5R1LVywyxvBVBZTE+12PsAd1FpL8FrdTZDIglWFCmpNSEcPq71bjM3olRqqKZu/db7HNNLvHc+mGHIP09wFoBJrkUhpGs8I/Hn86Y+9QZULuW20N9kkYDlcCRwxetjLK/gO3QJRpZpEB3AaJPSw2h83yUfa8LVzanyHuYkSQRqVTbaRhwGvr8UqL7kwi8ypGU3Xu+s6v5qid0nutmxIKN1sF48MXixg2W0Hyg7FHEnGFx0dlB2CP+TZL+8GN8Pthd8KxI0xSxdGPJjHVxikDlpOeKkzJnn2DSx06i990iL7s+ngc4lX/z0ieuqpyRBmP4sUaM+L61Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(376002)(346002)(366004)(39860400002)(76116006)(66616009)(66574015)(83380400001)(26005)(66446008)(33656002)(7696005)(64756008)(2906002)(6506007)(53546011)(66556008)(66476007)(316002)(110136005)(8936002)(5660300002)(99936003)(122000001)(52536014)(8676002)(38100700002)(478600001)(4326008)(86362001)(66946007)(55016002)(186003)(71200400001)(9686003)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?yYHV7bei+oPEGPIXbp143MoYWq2F6L5JOn/jI23BqiXTeLbs5O5rs3DonJ?= =?iso-8859-1?Q?QNMmumSqo9I6LakvWhecF3dwtNOnfzU7yFBkg8EAZGAuIVs0uZ0DnXD1HF?= =?iso-8859-1?Q?Qw1OvaxIIjTHnCSmRlNPxoG90ww7b2/vamrRX6MZCJaxGj4G2bhXK2sqFn?= =?iso-8859-1?Q?nk2ppj72P6kEyrJv4iqbNkL9g22/0cHmxMoY4RZkQVSx2SZ3yFmxC0ffzV?= =?iso-8859-1?Q?qivDQ9NcBNSSFaOwiGnFIavnJEFvO1EjQcZ3fe4SVwZydYe8LqlIEFoJPb?= =?iso-8859-1?Q?eZBgL2+zpOg5xpkyQwYUVwSPl/jIM4imagEfsxz1k5yZ1EqkUYwQf2uZbH?= =?iso-8859-1?Q?RthQJDNxOtZN3uYIAUq5X3bsYtgXJwmQ5EOtVranU24J8qIhRJH00/9M0F?= =?iso-8859-1?Q?HWkfzDTMQru3VvmrcVpLlxWzO63Cc8RZnISaraNv3hajfrZee86spZ+STU?= =?iso-8859-1?Q?mXFfRH2WdPfuVZLU5/BFBtWfQgm3nghjU8DgOUZUVPZajdLK159jwzz4xu?= =?iso-8859-1?Q?XNN0ZgeLejJL+4hsSdzsR5t8pJT3/BnkehVzgXyikd7NJPyvp9j/zgDkEp?= =?iso-8859-1?Q?XbbErxmEeuUN52yjzDEZdp/EF4LAfIlnz60k2aCoGvw6MG0dG1896dd7ZA?= =?iso-8859-1?Q?QGKfULZ5zdV3OIfvAm4ujIdE/x0+dLb4NnxPIhgM7wINJS84U2Z8qH6Th7?= =?iso-8859-1?Q?skH8HYVCl5ok1JWATUCZggUaRPbjR7RZzsjqU+qZ5mrYBewELck1oVq3m3?= =?iso-8859-1?Q?0C9TIpybwM1AROVquUB/MvKN/IEeTkMUtOK8xJCXHkAfsNPcrnmHoa6lpD?= =?iso-8859-1?Q?yXKdtC/eDB+0egcNXvCmaLHUXlS2KtOmWyDKpMw5tBxOk4B+BuFEldwgf2?= =?iso-8859-1?Q?w2ofnQT7OJ8D20Ug2yvuXzaKSFqCGymJP0rF+/00/wBVK4W1Tvm5vMPtMg?= =?iso-8859-1?Q?1Q+ctCPiK3ej0/65pKSLCeuYSYL1CuVvZPsPr/QJllFWQfDc+h28uMggqN?= =?iso-8859-1?Q?Il+6CP0ld3l3T0tnohPCtjkuGsFJmZyTE/N9Bq6HCKqrDjmlVzKpNLo53b?= =?iso-8859-1?Q?LlcMsucOZHYFXh9hdOH/OYd08u43dR8BngTEeV4VF4vXd7/bAOtYLwcKRW?= =?iso-8859-1?Q?olUSbVWhLWY1AIh25i9m6pRLjVjHXEsU/8bLu9CkFSfnrDG7oRT4PkvbWZ?= =?iso-8859-1?Q?EOKu87R0DGVzYBELV/ybxtMCeIjwlw4EJBTxctSKwQsIoJdta58YLs0d/o?= =?iso-8859-1?Q?2RFM/gwQjWCcDNOTkdR1sRL/GQhseJ78IizEEFfi5I6Yn6jMOurwcdkD8l?= =?iso-8859-1?Q?qH+pIwfQAt7GM8vPubLMtCAB7Z4t2LBbt9S4kewURogo+N4voNN9/8NgUj?= =?iso-8859-1?Q?ZWHZrpXw97?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0387_01D77315.537C9520" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bfcca319-bd87-405f-9564-08d9411bb3b7 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2021 07:49:08.3018 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 28i289+YPZxolBmELyPjYTtifMpjLQbHsfuOESWtSoElgZkFRO5yPGJbGg/KZ1NqhIZMnDqsyU7+85pOBY/JkzLPqorz7S0Yobn5S+OfdVg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8215 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 07:49:23 -0000 ------=_NextPart_000_0387_01D77315.537C9520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Rob, I would be happy to simplify the draft. Just we are restarting debates = which were settled earlier. This can lead to a never-ending cycle. So, I propose to: - remove all mention of the revision-label - remove the feature - for the inline method allow just ietf-yang-library@2019-01-04 as a _single_ file. This also means that I should remove the leaf = inline-module as there is no need for it anymore. We know the single YANG module it = would define. Is that acceptable? Regards Balazs P.S. The feature was possible to use.=20 It could be read from " out-of-band documentation" As indicated in the = YANG module. For some use-cases (E.g. Use Case 2: Preloading Data) when the operator/designer is sending data to the server (not receiving it), it = is useful to know whether the inline method is supported or not. In case the file comes from the server the feature is less useful. -----Original Message----- From: Rob Wilton (rwilton) =20 Sent: 2021. j=FAlius 6., kedd 17:15 To: Bal=E1zs Lengyel ; 'netmod@ietf.org' ; andy@yumaworks.com; Juergen Schoenwaelder Cc: Benoit Claise Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format Hi Balazs, To follow up with our conversation earlier. Andy and Juergen explicitly copied because they may have previously commented on these issues during = WG LC. I think that my comment regarding the "feature statement" and the flexibility of the inline-method are closely related. I find the = definition of the inline-content-schema to be so generic that it effectively allows anything. E.g., the drafts would allow me to publish a file that has an inline-content-schema based on robs-random-schema-format@1.0.0, and it = would be very difficult for consumers of the associated instance data file to understand the file schema. Similarly, I find that allowing revision labels (as examples to avoid a normative reference to the module versioning draft), makes it hard for a generic implementation reader of a instance data file to know how to interpret an inline schema. I suspect that this issue could cause = problems in the IESG reviews. Hence, my preference, for this RFC, that defines version 1 of the = instance file format, would be to more heavily constrain how the schema is = allowed to be specified in the inline-method. Specifically, I think that it would = be better to: - restrict the inline schema to only be defined using ietf-yang-library@2019-01-04 - only allow revision-dates, not revision labels. I would like to understand from Andy, whether he still thinks with these restrictions whether the inline-schema method should still be under a = YANG feature statement? If/when the revision labels draft gets standardized, and perhaps also = after YANG packages, then we could do a bis version of this document to define = a v2 of the instance file format that potentially allows YANG packages to = be used to define the schema, and potentially allows modules to be = identified using revision labels as well as revision dates. Balazs, I'm good with most of your proposed resolutions, but have = answered one further question inline below. > -----Original Message----- > From: Bal=E1zs Lengyel > Sent: 05 July 2021 13:47 > To: 'netmod@ietf.org' ; Rob Wilton (rwilton)=20 > > Cc: Benoit Claise > Subject: FW: AD review of draft-ietf-netmod-yang-instance-file-format >=20 > Hello Rob, > Thanks for the review. Here are my answers below. I will also upload=20 > the new version asap. > Regards Balazs > ----------------------------------------------------------- > Hi, >=20 > Here is my AD review of = draft-ietf-netmod-yang-instance-file-format-13. >=20 > Thanks for this document, I think that it represents important useful=20 > work for advancing the YANG ecosystem. >=20 > This document is in good shape, and I mostly have minor comments but=20 > with a few more significant comments. >=20 > Main comments: >=20 >=20 > 2. > In the YANG Module: > feature inline-content-schema { > description > "This feature indicates that inline content-schema > option is supported. Support for this feature might > be documented only via out-of-band documentation."; > } >=20 > What is the benefit of having 'inline-content-schema' as a feature? =20 > It seems to potentially add complexity without any benefit, given that = > the device originating the instance data file would effectively choose = > whether to use the inline-content-schema, hence I suggest that it=20 > might be simpler just to remove the feature definition. > BALAZS: This was explicitly requested earlier by a reviewer (Andy ?). > The system can declare supported/not-supported in design = documentation. > In a use-case when a client or a design department is sending data to=20 > a server this is needed. E.g. in UC2, Preloading Default Configuration = > the designer preparing instance data, can decide to use or not use the = > inline-content-schema based on this. >=20 > 3. > In the YANG Module: >=20 > "case inline", description: > The first item is either ietf-yang-library or > some other YANG module that contains a list of > YANG modules with their name, revision-date, > supported-features, and deviations. > The usage of revision '2019-01-04' of the > 'ietf-yang-library' module MUST be supported. > Using other modules, module versions MAY also > be supported. >=20 > This seems to make interop for consumers of instance data files hard,=20 > since the schema can be defined by any arbitrary YANG module without=20 > updating this module. I would suggest that it is safer to limit this=20 > to the two currently published versions of YANG library. > BALAZS: I fully agree, however this was explicitly requested by some=20 > reviewer earlier (Juergen ?) Shall I simplify this or not? >=20 > If additional modules are supported in future, then I think that it=20 > would be safer to create a new version of this YANG module that=20 > documents what other module formats can be used. >=20 >=20 > 4. > In the YANG Module: > list "revision" >=20 > Is revision expected to be unique, if provided? If so, should this be=20 > explicitly stated in the YANG module description? > BALAZS: I don't think I understand your comment. There may be multiple = > list entries for revision. The 'leaf date' is a key, so it is = inherently unique. > The description may or may not be unique. I would suggest changing: For every published editorial change, a new one SHOULD be added in = front of the revisions sequence so that all to: For every published editorial change, a new unique revision SHOULD be = added in front of the revisions sequence so that all I.e., to also make it clear in the description that revisions dates are required to be unique. >=20 >=20 > 5. > In the YANG Module: >=20 > Is an instance-data file allowed to contain both a revision and also a = > timestamp? If so, is there any constraints on the values. If not,=20 > then would it make sense to put them under a choice? > BALAZS: It is allowed to have both. There is some recommendation text = > about when to use each. However I can see some corner cases, when=20 > using both in the same file would be useful, E.g. we want a timestamp=20 > including hour, minutes, but we also want the history of the instance=20 > data set, including multible revision/descriptions. > I propose to add: if both are included the timestamp, SHOULD contain=20 > the same date as the latest revision statement. Okay. Thanks, Rob ------=_NextPart_000_0387_01D77315.537C9520 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDcwNzA3NDkwNlowIwYJKoZIhvcNAQkEMRYEFG5O+lZciyez Qd4Xo2B2lRseFAGUMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAF+9 IfPigiAik8rYt5TyNxgYXHec+GCK1yoD2JAOincnCFpTnpi+979ILAm3jlNS5xc/Fb5k7i4YiJ4Z UGJM6KAhimamE+dnQ51hgL8+sHIANRo0z5DJBC2gn0TL5+hP+Mj/0RIUzMmcQmCj5bfI5PUhQjX2 RT12age6JoxQJY5hGtt5mIILjbUaVEh2z3pk3Z+e3UDvZZJN1A2y/isayAh4308oeXJiT3Bef7QO giic1xx+J1NtbtZMOifpwvYuHZAPrPVWVtHMeq0qy/vU65jgx3wufHrCHDEnnVUb5jvSJpNhHteX GCJ+V80IynZWs+l0Qsoryzj3CDFXrFQzgp8AAAAAAAA= ------=_NextPart_000_0387_01D77315.537C9520-- From nobody Wed Jul 7 01:01:14 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AEA3A10FA for ; Wed, 7 Jul 2021 01:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yf4beLV5BBQw for ; Wed, 7 Jul 2021 01:01:07 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150072.outbound.protection.outlook.com [40.107.15.72]) (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 F04943A10F9 for ; Wed, 7 Jul 2021 01:01:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZhJmZ2jzbEd3qhoDALO+8cUyaEJC4SuWlKnJbZC0fVuA91KiZtb02WUwPO5AHXS5oF1AZmu/LdazbmC5dVXW9IIgfq6lvqxLLjXKry+RDYDLcZ/qL00l8UXPLKOKMywpuV3g9vsvCHc35GgpvHPoJlGIS2jRvCy6MJMx9MVahCIEQz0Uvvf2bMgoEVXnkEN2Y5EAH48CAvNGqHgGpJE5PmFKJtJsqXAfHDn3VLU9kDD1O1li6NyWsuQqoXtl9iW79Gvs0ZljIb8+ard1WE0llu5lq9IsdCBvAcUKRnIvOPV7bEI3gKhT+bvkKPVUKsBSNHqT7lc9mRSsNoSG+atj+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q8qBdrMoNDzz7h9pfB7FrQvCzCSxYHUHFSc9SppC9Gs=; b=OCF+qTwKMr97V6XWkjHQVayWVG/lyajoxqieDVyEoCAr29ZjARETnFenyt3gBggSaDKA0zbPAAk+ltGbf1LwGPrve91bbbou3CNQ53EsscrZ7eH3XYBccHPxifV5edfYs89rvJEWOaaJ+LIfzkdbkWORJOlVHrR6AXbjYrQgOHxEBorU02OhH84Ud98ym9JTaV7laqE2A9jX9HWdop9zoYU3ZzvEsV2EKZ3CSn+2RRtjfGNEeEv8XwP4/jxRDzjYpnOaycV58YYZQLZaFmcVXWvjiuSNe3GmGepSZuWgE25Hc6A0QOAuKiFW9aFux1oJSzJ1KUEVfvDFnpgEp8AJIA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q8qBdrMoNDzz7h9pfB7FrQvCzCSxYHUHFSc9SppC9Gs=; b=tsx1lLMlp3dw0EhsLHEJeP4Lqpdqt9+kD7Cg9y+AES1BZrEbR9uSXaTvx5KEeC6Hr8MHsE7pH5hEyCSKnX4tZzzvKPBeKyFCWbr3thrpJD8fzjrlgcVjWJhYe3QG3ZSoYkWQ2/nOP0+WrsBEaNeGDrrP4PHL5wVG5CL37Do36Ho= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8171.eurprd07.prod.outlook.com (2603:10a6:20b:322::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.19; Wed, 7 Jul 2021 08:00:59 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4308.018; Wed, 7 Jul 2021 08:00:59 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Andy Bierman , Juergen Schoenwaelder , "Rob Wilton (rwilton)" , "netmod@ietf.org" , Benoit Claise Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAPXLWAAAIT0wAAAIMhAAAAy2eAAAJlLwAAGf35QA== Date: Wed, 7 Jul 2021 08:00:59 +0000 Message-ID: References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; yumaworks.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fdf64376-4595-4a66-d445-08d9411d5b5a x-ms-traffictypediagnostic: AM8PR07MB8171: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iaYRcwObuh9UjugxVn7uEsRRnzivNLG5gQgtx4BiRTxL/3/gc9z7u0P/QzoF1xyMk2lMdaXXcxpXsCq9lOmEX2zwpEDpsnwAjhm6HswvXEVO3upCu8PHoiCghiU+drd4MK9/+50Q+sOLaAFrSXtrXO2SDp9zOjJws/Re1WVbdagjdpaSnVr1q7y4ykk2jF/2h65VWtW+qCcMmuNbJc72tTrED4/WWYm+jX5J2I0amIjVxJCsSZ96n2ubhNDDFMZTh79NFu6hMytU+9fltVDn5FALtOvDc6UgpsA93kFka2XxFZYBZ8b3yzrX/Xa+IfiPhi6uQC7hKOHfizObFgJlRR3vYHLkI6cVHdQ+PJcinHTTdf3tJl9AQQ9mcgBM6tB9WwEqNJGMlC1eRajlpZW4s/vQU+g1KDGEpmjDlEKhzi12HoIJZCiwaoDpx71+odauggLihslMP+vmMC6ir6tOUCeueDNLEJSNt5xPrqgddsIU2k3arxHcHuRcz/8yeVZYGLtSkq1mmDCwHjhYM8KT720eF7P1qqwntfUdZAvudLKfyVIV+atj6BX19KO8/pzCiBGaVB6lyZtKG9zOK84zg9JFw3QlYxDqBvvpgVvilNlRaXeJdRIQGIDoera/ZoH/+9XWFoa5jymNxtMP11uEApCH5PQVnXFRlQuLiPRLw9TRzCpMHIIbY2UgNuFKSLqdzGgUeEFiYSqbtdZq2E39X6dBPYaZvopuJMyMWVauPHQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(346002)(136003)(39860400002)(376002)(966005)(6506007)(53546011)(55016002)(85202003)(8936002)(7696005)(26005)(99936003)(52536014)(8676002)(478600001)(33656002)(5660300002)(9686003)(66616009)(122000001)(64756008)(66476007)(316002)(38100700002)(166002)(2906002)(110136005)(86362001)(66556008)(76116006)(66574015)(85182001)(83380400001)(9326002)(66446008)(186003)(66946007)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ck92UllqY0Z3SzRIeEVxK2w4cm1LR0xMM0YxVzR0cEhlK2ZGVnpmcVVUcm1u?= =?utf-8?B?T24wSmd3bVdjZWxuTzg2aUFWZ2VGQUVqc2cydkxXQzBGa2FseWRkMHZDelhy?= =?utf-8?B?dStkdzUyYm0ydWl5ajdFK05WSm5TalNBTGJxOHpqYkZrK20xMzdSOEJvNTFr?= =?utf-8?B?YUloWktpZEVkU2d4bzQvYXpwVkdtYXJiSVNxSXBuWnFoKzh5RUluZnZHTWtr?= =?utf-8?B?RGJ6MTdsaEZMSFB2WEthNE1IMkZZazEwcE02c0Y2eG13bGFuMDBuVG9uMUxV?= =?utf-8?B?S2g4UVhkMGZmQ3ZyMG9KQ0JXQ2EvT1FDanF6dXpJZkFqM05zZ1hsUTV0RGdJ?= =?utf-8?B?MHNuVDk4M3U1a1hGODNIS216ZDdFRmROMThjMVJGTEN4NWd6WEY0OU03TTU3?= =?utf-8?B?V052eUxrVkVpRFFjYXg0b2xMeVhad1kwampRY1hvZ3oranhJTzZpVlJQbnBz?= =?utf-8?B?M3g4TzdpTFpSbHIzV0U1c1RBeC82a2dPZ2tnaXB0aXI5RnJveWV4c2tYUWlw?= =?utf-8?B?d296OTlwSzZaNmJZZGUzWUNDNk5DaFEzU2xZSlhNVHo5bHg5U0NPei9SZ1FR?= =?utf-8?B?Ny81aTgwK1dTUXhkOUViY3RlK3Y3TmMyMGV2aWFhQXE0d24vWUVETitzRkgv?= =?utf-8?B?dVJOcm8vY2M3T0Y1QlA4ZHZUYjA5UnZ0TTJOTmJjcGhzcUlGeDlRTTNpRUZ0?= =?utf-8?B?c1R3Q3Rya3dvKzI4SzVOT0ZOU0lSQWpudTFHZSsxaWV2bC9KK1dKWUNhbUEz?= =?utf-8?B?YXRoMjQwVmhsRFduZVZTUGd1eEZuNVhKRWgxYVdiWXI0OTJkbDFvdkRWc01K?= =?utf-8?B?ejRTbzJhMUFTcnJWZGZuMjBlR2dReXlTWmZ1SXlKWFRpaVc3dGhRTml4QXMx?= =?utf-8?B?UGI2djIvcmhYSEdUOEIxWHdPV1hTQVFVNWduMDlMS1ZXY2R2bkg0WFozbS9O?= =?utf-8?B?a1J4aktHMmtOK0U5RlpzOFpTbS9JckdzeHBQQ1hmei9vaHBTWDl2c2RWM3R0?= =?utf-8?B?a2Ric3VESFkzTzEwV0pWV1ZYdG5iNWVZYkZ0c0JSUkJuMDBBKzd5TWg5cUxa?= =?utf-8?B?R1R5ME1wbkMvRDhtRjYybTRCWkdwNFVRMWZ6NHhnUzJ2by9nc3Z2bXFHaVQw?= =?utf-8?B?UUJFUkpiYm1iUVBOYmZPUTUvbGthNXhHUmV0SnV6Z3BWZnFxY2dGOE5kZWdC?= =?utf-8?B?SmtvMlZURExhcklYdCtjcytPeUVMT0pjYnZ3TDhxWEFqN0N1UHlBa29halBB?= =?utf-8?B?T0pGTkpLd3drZUl5N3lKY1NtbjUzRmVRU1VkemZ0RGM0dUo5Y3NwMFF5VURZ?= =?utf-8?B?b01GNGo4UHZsNFUwcDFBZ1ZXQzFURnRuVDZHblZ5aUVCYnpOaFlKSjJDNWIw?= =?utf-8?B?S2FaVWVXRytRMkFKbEZOV09SSkI0YWJnRlk1Q2tjdFludnNVY0VES0VpMlVK?= =?utf-8?B?bVZyQ3owNE44eDJzZXYyU1RrMHVnTTRYZzR3c2tmOHhQdjRScTl1NC8rOWtC?= =?utf-8?B?WXg2L0FTazU4aEhycnZ6OE1Xbmp2RC9IY3pFd3FOQVM5QXpWbGdSbGE0dUpk?= =?utf-8?B?R1Y5bWZ4VU9WREhrb3lDUCtsbUJlc2wwbjJoSENXWVgxOC9ONllNTWkvUmdD?= =?utf-8?B?MWdXc3FEeXIzSDJoSlhUZVJiTXhnZE5lZCtHS1QveDVNc0dKaTdyZmNUaWg5?= =?utf-8?B?OW1xN2lkMS80WUlYeEZpaWtSbmZRb0VtRDBOdjlXeEVyRXVYMTZlTThURkl6?= =?utf-8?Q?QSLStAYUtWhvvBi3tKHlRyFnvpmwQOIFngdHoKL?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03A0_01D77316.FB664FA0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fdf64376-4595-4a66-d445-08d9411d5b5a X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2021 08:00:59.1276 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ATcmA/NCqCJrNS2QOkM3VXKwVTnMFoPY2HEKUP/COQgHhnYYYheOAWSCfR1qiXR0C4YsFoVWVXyk9Mkv2TYZDO90cGrvfS6IcRhFuEThuvk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8171 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 08:01:13 -0000 ------=_NextPart_000_03A0_01D77316.FB664FA0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_03A1_01D77316.FB664FA0" ------=_NextPart_001_03A1_01D77316.FB664FA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Andy, There are many different use-cases for instance-data-files, each with = slightly different requirements.=20 =20 Inline method is needed, if you want to indicate that the file was = generated by someone who uses some YANG modules with deviations and some = features are not-supported. There is no way to indicate feature-support = and deviations with the simplified-inline method. =20 The URL method was requested for the use-case when you generate = instance-data-sets repeatedly e.g. every minute with the same schema. = You don=E2=80=99t want to include the content-schema in every file, so = you just include a single URL reference. (Note the content schema may be = a longer piece of text, not just a single YANG module+revision) Regards Balazs =20 From: Andy Bierman =20 Sent: 2021. j=C3=BAlius 6., kedd 21:28 To: Juergen Schoenwaelder ; Andy = Bierman ; Rob Wilton (rwilton) ; = Bal=C3=A1zs Lengyel ; netmod@ietf.org; = Benoit Claise Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format =20 =20 =20 On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder = > wrote: On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote: > On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de = > wrote: >=20 > > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote: > > > > > > IMO the 4 separate ways to identify the schema are 3 too many, but = that > > > is what the WG wants. It seems obvious that any reader of the = file > > > has to implement all 4 methods and any writer of the file is free = to pick > > > just one. > > > So the feature does not really help. > > > > > > > The feature statements declare that implementation won't work > > together. Back in a day, the IETF was all about interoperability = (and > > implementation costs). Nowadays we seem to be fine if = implementations > > declare that they won't work together. Well, still slightly better > > than having implementations fail arbitrarity. > > > > >=20 > This is a text file stored on a USB stick. > There is no client or server. Just readers and writers. > So how does a YANG feature work here? > The reader is supposed to know how to find out if this feature is set > before opening the file? > > I don't see how server capabilities discovery is relevant to a > YANG instance file. > The reader code will simply attempt to read the file and fail if it > encounters > a format that is not implemented. I assumed that the features are carried in the instance file, i.e., the file declares that it uses way X to announce the schema and then the parser can fail with a suitable error message. If the features are not carried in the file, then they indeed seem to be useless. Perhaps there are Y different ways to announce the features of the instance file as well, I did not check. ;-) =20 Now you made re-read the entire draft :-( I cannot find any text how the reader knows if this feature is set = before reading the file and finding out. =20 I do not see any significant use-case for the Inline method and none for = the Uri method. Nor do I see any reason why the Simplified-Inline method should not be = mandatory to use and always present. =20 If the use-case is offline server validation then the YANG library = details need to be known. The entire YANG library for the server (or relevant parts) are recorded = in the Inline method. Except it is complicated to store the info about how to interpret YANG = schema by reading instance files and guessing what the "anydata" contains. =20 I actually prefer a simple string based on RFC 6020 URI method, since it = can be easily integrated into the Simplified Inline form and can be parsed = without guessing anything about the contents of anydata. =20 https://datatracker.ietf.org/doc/html/rfc6020#section-5.6.4 =20 e,g, =20 OLD: case simplified-inline { leaf-list module { type module-with-revision-date; ... } } =20 NEW: =20 case simplified-inline { leaf-list module { type union { type module-with-revision-date; type string; } ... } } =20 Example module leaf-list entry: =20 = ietf-interfaces?revision=3D2018-02-20&features=3Dif-mib,arbitrary-names&d= eviations=3Dacme-deviations =20 =20 IMO Simplified Inline SHOULD be the only format, and the other methods = can be removed. =20 =20 /js =20 =20 Andy =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 > ------=_NextPart_001_03A1_01D77316.FB664FA0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello Andy,

There are many different use-cases for = instance-data-files, each with slightly different requirements. =

 

Inline method is needed, if you want to indicate that = the file was generated by someone who uses some YANG modules with = deviations and some features are not-supported. There is no way to = indicate feature-support and deviations with the simplified-inline = method.

 

The URL method was requested for the use-case when you = generate instance-data-sets repeatedly e.g. every minute with the same = schema. You don=E2=80=99t want to include the content-schema in every = file, so you just include a single URL reference. (Note the content = schema may be a longer piece of text, not just a single YANG = module+revision)

Regards = Balazs

 

From: Andy Bierman = <andy@yumaworks.com>
Sent: 2021. j=C3=BAlius 6., kedd = 21:28
To: Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de>; Andy Bierman = <andy@yumaworks.com>; Rob Wilton (rwilton) = <rwilton@cisco.com>; Bal=C3=A1zs Lengyel = <balazs.lengyel@ericsson.com>; netmod@ietf.org; Benoit Claise = <benoit.claise@huawei.com>
Subject: Re: AD review of = draft-ietf-netmod-yang-instance-file-format

 

 

 

On = Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder <j.schoenwaelder@jaco= bs-university.de> wrote:

On Tue, Jul 06, 2021 at 10:56:48AM -0700, = Andy Bierman wrote:
> On Tue, Jul 6, 2021 at 10:42 AM Juergen = Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> = wrote:
>
> > On Tue, Jul 06, 2021 at 09:42:39AM -0700, = Andy Bierman wrote:
> > >
> > > IMO the 4 = separate ways to identify the schema are 3 too many, but that
> = > > is what the WG wants.  It seems obvious that any reader = of the file
> > > has to implement all 4 methods and any = writer of the file is free to pick
> > > just one.
> = > > So the feature does not really help.
> > >
> = >
> > The feature statements declare that implementation = won't work
> > together. Back in a day, the IETF was all about = interoperability (and
> > implementation costs). Nowadays we = seem to be fine if implementations
> > declare that they won't = work together. Well, still slightly better
> > than having = implementations fail arbitrarity.
> >
> >
> =
> This is a text file stored on a USB stick.
> There is no = client or server. Just readers and writers.
> So how does a YANG = feature work here?
> The reader is supposed to know how to find = out if this feature is set
> before opening the = file?
>
> I don't see how server capabilities discovery is = relevant to a
> YANG instance file.
> The reader code will = simply attempt to read the file and fail if it
> = encounters
> a format that is not implemented.

I assumed = that the features are carried in the instance file, i.e.,
the file = declares that it uses way X to announce the schema and then
the = parser can fail with a suitable error message. If the features = are
not carried in the file, then they indeed seem to be = useless.

Perhaps there are Y different ways to announce the = features of the
instance file as well, I did not check. = ;-)

 

Now you made re-read the entire draft = :-(

I cannot find any text = how the reader knows if this feature is set before reading = the

file and finding = out.

 

I = do not see any significant use-case for the Inline method and none for = the Uri method.

Nor do I = see any reason why the Simplified-Inline method should not be = mandatory

to use and = always present.

 

If the use-case is offline server validation then the = YANG library details need to be known.

The entire YANG library for the server (or relevant = parts) are recorded in the Inline method.

Except it is complicated to store the info about how = to interpret YANG schema by

reading instance files and guessing what the = "anydata" contains.

 

I = actually prefer a simple string based on RFC 6020 URI method, since it = can

be easily integrated = into the Simplified Inline form and can be parsed without = guessing

anything about = the contents of anydata.

 

 

e,g,

 

OLD:

         case = simplified-inline {
              =  leaf-list module {
            =       type = module-with-revision-date;

              =     ...

  =               = }

      =     }

 

NEW:

 

         case = simplified-inline {
              =  leaf-list module {
            =       type union {

              =          type = module-with-revision-date;

              =          type = string;

    =               =  }

    =               =  ...

    =             }

          = }

 

Example module leaf-list = entry:

 

      =  ietf-interfaces?revision=3D2018-02-20&features=3Dif-mib,arbitra= ry-names&deviations=3Dacme-deviations

 

 

IMO Simplified Inline SHOULD be the only format, and = the other methods can be removed.

 

 

/js

 

 

Andy

 

 


-- =
Juergen Schoenwaelder           Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587      =    Campus Ring 1 | 28759 Bremen | Germany
Fax:  =  +49 421 200 3103         <https://www.jacobs-university.de/>

------=_NextPart_001_03A1_01D77316.FB664FA0-- ------=_NextPart_000_03A0_01D77316.FB664FA0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDcwNzA4MDA1N1owIwYJKoZIhvcNAQkEMRYEFCaE699KaOgh Ia5F2I3kjIEfEeTHMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAEE8 TrUFJgQMloop4e5LaBDN8NJfDxr+C3eictsDndULCxSqnE5/hV3IuqZ6cL5NH+elvqHPjPqfxfbw p7rJFL2aRsP+DS8Vvdzl8AAGKL42VbogrAo12r4hWlbf7B9l5cKGnkCfWZece46bGG2U9UwaaWbk 0kyWwRcPjEpdq5iiBCARs0JCChdm033gHM/8qYC85AlZtRo7ewzgOQjlG098AGf3s5/4H7NOOVjX RWfRenGmTHUXP46LNDBqI9JHH5Upa9mcgNGyEOeFMAw/mzEZ+0QxJViHlbaojZBiLzJu+0Bdv7FE nbHInYIS+cQDIv7/aKM8PdJPKGY+sHuYsXsAAAAAAAA= ------=_NextPart_000_03A0_01D77316.FB664FA0-- From nobody Wed Jul 7 02:02:22 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCCF3A1690 for ; Wed, 7 Jul 2021 02:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=jJTapa/F; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=NVuNwWPH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaqvaVlvXSVS for ; Wed, 7 Jul 2021 02:02:16 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07FDD3A168C for ; Wed, 7 Jul 2021 02:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10324; q=dns/txt; s=iport; t=1625648536; x=1626858136; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ME4HBvbqSrYd3qTx0zTUesacLcQt008BcaMJ2Iyh5JU=; b=jJTapa/FDSd4yHrg9eb7w7fut7pAtdCRTGQegaGU1V2uLfMPOScpTzdr 0ZSZ8LR1bmis8psceTV+LE3WLLYUhuVdFXQnwFQSRgGk8XGvtpW678zDN W2zekW3jFDuAvwA/1IGWwqNfjPAcJZytL0EgIHD7kELVGZn34eTyRd9Rv E=; IronPort-PHdr: =?us-ascii?q?A9a23=3AaVENAxI6SbjiHgG9NNmcuYUyDhhOgF28FgMP6?= =?us-ascii?q?5E8kLVINK+k+seqME/e4KBri1nEFcXe5ulfguXb+6bnRSQb4JmHvXxDFf4EV?= =?us-ascii?q?xIMhcgM2QB1BsmDBB72Nv/hdDc9GoJJU1o2t32+OFJeTcD5YVCaq3au7DkUT?= =?us-ascii?q?xP4Mwc9Jun8FoPIycqt0OXn8JzIaAIOjz24MttP?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AmQjt3KCV7CTjFlflHegqsceALOsnbusQ8z?= =?us-ascii?q?AXPh9KKCC9I/b3qynxppsmPEfP+UkssHFJo6HmBEDyewKjyXcT2/hRAV7CZn?= =?us-ascii?q?iphILMFuFfBOTZskbd8kHFh4tgPOJbAtRD4b7LfBhHZKTBkXOF+r8bqbHtms?= =?us-ascii?q?3F9ISurUuFDzsaFp2IhD0JbDpzZ3cGPDWucqBJbaZ0iPA3wwaISDAyVICWF3?= =?us-ascii?q?MFV+/Mq5ngj5T9eyMLABYh9U2nkS6owKSSKWna4j4uFxd0hZsy+2nMlAL0oo?= =?us-ascii?q?+5teug9xPa32jPq7xLhdrazMdZDsDksLlWFtyssHfsWG1SYczEgNkHmpDo1L?= =?us-ascii?q?/sqqiUn/4UBbU215oWRBDsnfKi4Xi67N9k0Q6S9bbRuwqSnSW+fkNhNyKE7r?= =?us-ascii?q?gpLicwLCEbzYxBOetwrhGknosSAhXakCvn4d/UExlsi0qvuHIn1fUelnpFTO?= =?us-ascii?q?IlGfVsRKEkjQto+a07bWnHAUEcYZ5TJdCZ4OwTfUKRbnjfsGUqyNuwXm4rFh?= =?us-ascii?q?PDRkQZoMSa3zVfgXg8liIjtYAit2ZF8Ih4R4hP5uzCPKgtnLZSTtUOZaY4AO?= =?us-ascii?q?saW8O4BmHEXBqJOmOPJlbsEr0BJhv22tPKCXUOlaiXkbkzvdQPcbj6ISZlXF?= =?us-ascii?q?8JCjTT4Je1re92Gzj2MRGAYQg=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAABlbOVg/4gNJK1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUcFAQELAYFSUQeBUTcxiBADhTmIWgOPZIpDgS6BJQNUCwE?= =?us-ascii?q?BAQ0BAUEEAQGEUwKCcwIlNgcOAgQBAQESAQEFAQEBAgEGBHEThWgNhkUBAQE?= =?us-ascii?q?DARIuAQE3AQQHBAIBCBABBAEBLzIdCAEBBAENBQgahSUDDiEBmyIBgToCih9?= =?us-ascii?q?4gTSBAYIHAQEGBASFIhiCMgmBOgGCeoJxU4crJxyBSUSBFUOCYj6EHBAag0u?= =?us-ascii?q?CDCKCKxFbBk4WAQMiBQEHFAomAiQrCh1GBwQUBw8CHgoCDymQewQmjCKBK51?= =?us-ascii?q?fCoMhnkESg2OSApBMlXmfcwQdhGUCAgICBAUCDgEBBoIuATOBWXAVO4JpUBk?= =?us-ascii?q?Ojh+DcIpeczgCBgEJAQEDCYd8gkYBAQ?= X-IronPort-AV: E=Sophos;i="5.83,331,1616457600"; d="scan'208";a="899292485" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Jul 2021 09:02:14 +0000 Received: from mail.cisco.com (xbe-aln-007.cisco.com [173.36.7.22]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 16792EaZ023309 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Jul 2021 09:02:14 GMT Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xbe-aln-007.cisco.com (173.36.7.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 7 Jul 2021 04:02:14 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.15; Wed, 7 Jul 2021 04:02:13 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.18 via Frontend Transport; Wed, 7 Jul 2021 05:02:13 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ev0Vfewqn5Yzcby9jVDjDyuuCakUOpEZGMVDnTkpa41/sJ3UQmvNVZOSDPJzWHj61aFlV+id7Ut9/0UikjyQ2G4JPkYO6ACt59ZyajO6RDXLX+l1bS6HTqnXfvCY1qwBRVNlR4zuAmXmWX90BFzN94t16ZwLroX5AiuEiK+MGfVRClJMhx/SqDaggULgA4osAIXayPXio8fgfGDwd0pP3iaJujnJH89VZmZ67QH3zaTTCvAhSiPV6Sr5kBA5x+CjNTSZpJi71Hef/jOCjta9v6IkSw2YXwN4jxxgot8oV9Cnr9fpHFrqhjpSk1K2aSzM8h+75ump0mHt4NXQeTxhzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1N2SWUegSgPDvcd5a7DMHGVB3eUgDgKG3TrF7gB68Zs=; b=j9QCyNvUd4KN/aJ8NzVKrUIr+N4Zr65Yx4yNRwdm6eusS4PgIz9clC5szh2/sze+W3t5Rh+eK8srqmC1PPgcVeAhS0GdFFWy+ni7aHJmUPI9i0QHec09cwTtVOZbW/0qx5Z9MDasyvCEU+XcHYs7EFhVn8j1/Ro9L6EGwKgBjQcHfX3WqbA5fzBobbZfjrGeyeWVK34Nq4cMisQ6PUQ0WGpY3cA+LP1iJMwH2C4ue+IEBsDJPe825wGNf+Nmtm+t7wJhL/eaUGxZvN6a4Gqb2+oLPZ91+a5e6pcimUG9UEasZfqvz+PMijnY5CqIuK8L9am/4iX9WmpCkS5SC4CPKg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1N2SWUegSgPDvcd5a7DMHGVB3eUgDgKG3TrF7gB68Zs=; b=NVuNwWPH706oN5n66yZh2Y9Xpa4dwVJKHUqqo1zfi7S9SElZsY87QyinY0732e3Us6GRwPCHd8qAM+6Sj24Izs4vQIu+TrRWfwZ8l+HMtYl6Rw17vKCyGNTe1+jWznIikiXGA3oODr+8a4UqAYkdUF+EdngU0NQd8BOl1lCBBsc= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM5PR1101MB2249.namprd11.prod.outlook.com (2603:10b6:4:5a::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.26; Wed, 7 Jul 2021 09:02:12 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12%6]) with mapi id 15.20.4308.021; Wed, 7 Jul 2021 09:02:12 +0000 From: "Rob Wilton (rwilton)" To: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= , "'netmod@ietf.org'" , "andy@yumaworks.com" , Juergen Schoenwaelder Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAuhzfQAADaNgA= Date: Wed, 7 Jul 2021 09:02:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6a890ec5-ffd4-467c-127b-08d94125e899 x-ms-traffictypediagnostic: DM5PR1101MB2249: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: S+EPacGTWaNDSdM5fKDeIwt6YQ8GG/zwGQx4Q+CJdNBtzdEQU4dQP8iZfZgVyKR2f4Uit6qB3hopI48kIuzH17zOOmfFHEFFi7xvKhmrZgEoN4+1vAjhYGxFgnCgbY5vD0hTyQPLLmNCu10xMy/l43dt2iWua40SqCWgXMLIoDp5pDYk684zE33L2RfKdfbgtQyUFbx4P6Kb/Vie8z0xLsAEB90LXAP4MPjE29NdMLclNFtkGUrD09hKAM6NStWjFCV6XfC+CdxqhWg1Spw528LUmAdaTlLWcxGIcMKv3yVyBP1WFO+fwynm73FTd/W49oW/JTZc00+/7tS6/BAFWUVXf2LK2XFmsqt4tRinqFswtnEPwYiHsDekev0c2ReTIno9BhVWcA3BbYyv++GIWWCIgUO360mkMJASH61bJZOybQn9Nij2gOzflS/8Iui5Ya5Lt7s0hnLbSUqXzd7ZZGfvUAM9CKALcGq1NNsXhP1j0+U+p/57HD6gkbS/ZGTmLfVfxtuJ3R5LzcVj0KWTBHBreN7W7tfmLYKNTIHFpbOFJfQlFFeJ6a+GEqdmWkp0jkG8kiAdo2ij5BMkWQis1LR3ZqSv2Vt04wjN3pZXVSHZXZpHgLHKfafGluR9Dl9Skx94MY5ly0Yg/y24oHDWOtb9LXeeX6DIMydwbFS7odX36avdQflCiza4ZnMG9hcsko1ZrFtNBoPgnxbPtTZk9A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(376002)(346002)(366004)(396003)(136003)(316002)(9686003)(7696005)(66476007)(122000001)(55016002)(64756008)(83380400001)(110136005)(26005)(478600001)(4326008)(66446008)(52536014)(8936002)(76116006)(86362001)(53546011)(66556008)(6506007)(66946007)(5660300002)(186003)(8676002)(66574015)(71200400001)(2906002)(38100700002)(33656002)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?1zE/csiEBUMsD/FkxAezcKVIF+jdi0IJE29fIjG/L37L1Q683B5X8gaOJs?= =?iso-8859-1?Q?qvwdRA8JRGD0PrlHt+66O6LfZZttVij9ztGvPins+u6bkpCdESeqsKdmdW?= =?iso-8859-1?Q?C7R1rw8cZN+FXeLQtjIdyJZhLcdru380W6cNyP2So09/MTRlKz4wGiSX6v?= =?iso-8859-1?Q?tY3+Bmgs/i8YD1SEBiWfh7VsPw7U76Lnmvj/n0+SaG8XrIrEPWLiVQQHXU?= =?iso-8859-1?Q?NFwjHfc6/S8dXdgeEmF7QjDjMbAdeO1MtsWV4UYdKBH7w2PgMD8nhF6CYp?= =?iso-8859-1?Q?o9Of4Uyru9PveHxmYNR3LeLRdDHlzdJdROSyrl9fmpZlHwrmI/Aa9G81t3?= =?iso-8859-1?Q?3tzqc52Hj/YPkKEeCdV3fQlvSeSwho3ckgZF+FCEDV7SpKJClGus3I5tlC?= =?iso-8859-1?Q?4Z9cvPm73msp8UDaJBFglw3N3RBxTD0PUeDUUgftqpFYRROqiLwEyBPk+9?= =?iso-8859-1?Q?OcW5Z4uyhsVrR0xOaeKXkq1MxC3i48Xq/JR9LoxBF3AQwn3EEKMzM9c7wq?= =?iso-8859-1?Q?TVWP8nyF+0tLwru8pJGehRcXxF2wb/Regvb/llclPG1wY/Ke1q2yc94s1j?= =?iso-8859-1?Q?CTh3nS8Ef7lbyPQX3iQz3wkAOjwcFcDnu7+eaMuFF4JaM7TQAQRNFpUHWT?= =?iso-8859-1?Q?RWbTVIQNu3CTP4P5gPvpjizcbZ3Jf8LPVOVfZVKts9qj35s6QSSg+O64AZ?= =?iso-8859-1?Q?+6c7lLMTHrfM6hdDrImPjcqAOQSNpF4AIJFK3HD1kiWENZbS4f+wSNrBsA?= =?iso-8859-1?Q?fP66m7Wwa9zjxcp3p3l5Wq71S8ZucFCU/jyAFE/sXbMSgrsZxoIzB83fc0?= =?iso-8859-1?Q?L/A5vxgHoPMYFTqzq8VkegdLafgKjhwDWqvm5u4FJqAnQrbC9CCR016jC8?= =?iso-8859-1?Q?pJnB/W9lFxy2ruAyrNP12WPg34caudqyIw19wPhuSBUsZwXd1hAeoqAzle?= =?iso-8859-1?Q?sKi6Mnn+VcdUfaavrj2mjA/+PCJdJva+KtW1OiyQH8c4IWj+erWF7Ma9H8?= =?iso-8859-1?Q?Pjv5fDyIxpxGauf3XYJVHh1bGiS4AN3g8+qVCYXk3rEv2xh6J2EbKk+xtf?= =?iso-8859-1?Q?2plzBifBC/h/0j6ILv7KxwVQCBjgb4BTBt77lHfiDtIiHdd4z9v1jwKxvJ?= =?iso-8859-1?Q?+CxE2OkDBrfP79HexTqtpbB8G2uW370jkBgWZQYjW1Sx8eTyc0dT9kIWvO?= =?iso-8859-1?Q?gExh7dEuQwk7yuw6llWFr+07KtwtXMp/9oDblnuEshmnDUCesICEqSZxy5?= =?iso-8859-1?Q?D0x/9Fc861qk6cd1Huw+sHEFbXDLimfuJfOubSeBMfhd6jQPTtYRvqhxEj?= =?iso-8859-1?Q?bmFcw5UUuUJ3mdyJKtukrgVbujwEihl9pf/eJaVshxme/ZWLvuZJEJMx+J?= =?iso-8859-1?Q?fBoppeuc01?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6a890ec5-ffd4-467c-127b-08d94125e899 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2021 09:02:12.0511 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: GJJeGWaeM/hEDYnxoie/t5vF+jvIiG4PDOu/71+VFsZW729w55yl1zVOndyrDRROrH39+gN5lOjpGm5KMoyPJw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2249 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xbe-aln-007.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 09:02:21 -0000 Hi Balazs, Netmod WG, Yes, broadly that would be acceptable to me. I would actually suggest keepi= ng the "inline-module" leaf, since I think that makes it easier to extend t= he format in future and I think that it makes the file a bit more explicit/= readable, but don't feel strongly on this latter point, so happy to leave t= his to the authors discretion. I do understand Andy's point that having a single method of defining the sc= hema makes interop easier, but I agree with your comment as for there being= valid reasons why supporting these different formats is useful for the dif= ferent use cases, and with the simplification of the inline schema method, = I don't see supporting any of the defined schema options as being particula= rly hard to implement (i.e., beyond what is required to reading/understandi= ng YANG library anyway). As for the feature statement, I think that when it specified that it has to= be communicated via "out-of-band documentation" then it doesn't seem to ho= ld that much value. E.g., it is probably just as easy for the out of band = documentation to say that the provided file must use the simplified-inline = schema definition, as it is to say the server doesn't support the inline-co= ntent-schema feature. Given that there was WG consensus for defining 4 different schema encoding = methods before, then does anyone in the WG strongly object to the changes t= hat Balazs has proposed below? Regards, Rob > -----Original Message----- > From: Bal=E1zs Lengyel > Sent: 07 July 2021 08:49 > To: Rob Wilton (rwilton) ; 'netmod@ietf.org' > ; andy@yumaworks.com; Juergen Schoenwaelder > > Cc: Benoit Claise > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format >=20 > Hello Rob, > I would be happy to simplify the draft. Just we are restarting debates wh= ich > were settled earlier. This can lead to a never-ending cycle. >=20 > So, I propose to: > - remove all mention of the revision-label > - remove the feature > - for the inline method allow just ietf-yang-library@2019-01-04 as a > _single_ file. This also means that I should remove the leaf inline-modul= e > as there is no need for it anymore. We know the single YANG module it > would > define. > Is that acceptable? > Regards Balazs >=20 > P.S. The feature was possible to use. > It could be read from " out-of-band documentation" As indicated in the > YANG > module. For some use-cases (E.g. Use Case 2: Preloading Data) when the > operator/designer is sending data to the server (not receiving it), it is > useful to know whether the inline method is supported or not. >=20 > In case the file comes from the server the feature is less useful. >=20 >=20 > -----Original Message----- > From: Rob Wilton (rwilton) > Sent: 2021. j=FAlius 6., kedd 17:15 > To: Bal=E1zs Lengyel ; 'netmod@ietf.org' > ; andy@yumaworks.com; Juergen Schoenwaelder > > Cc: Benoit Claise > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format >=20 > Hi Balazs, >=20 > To follow up with our conversation earlier. Andy and Juergen explicitly > copied because they may have previously commented on these issues during > WG > LC. >=20 > I think that my comment regarding the "feature statement" and the > flexibility of the inline-method are closely related. I find the definit= ion > of the inline-content-schema to be so generic that it effectively allows > anything. E.g., the drafts would allow me to publish a file that has an > inline-content-schema based on robs-random-schema-format@1.0.0, and it > would > be very difficult for consumers of the associated instance data file to > understand the file schema. >=20 > Similarly, I find that allowing revision labels (as examples to avoid a > normative reference to the module versioning draft), makes it hard for a > generic implementation reader of a instance data file to know how to > interpret an inline schema. I suspect that this issue could cause proble= ms > in the IESG reviews. >=20 > Hence, my preference, for this RFC, that defines version 1 of the instanc= e > file format, would be to more heavily constrain how the schema is allowed= to > be specified in the inline-method. Specifically, I think that it would b= e > better to: > - restrict the inline schema to only be defined using > ietf-yang-library@2019-01-04 > - only allow revision-dates, not revision labels. >=20 > I would like to understand from Andy, whether he still thinks with these > restrictions whether the inline-schema method should still be under a YAN= G > feature statement? >=20 > If/when the revision labels draft gets standardized, and perhaps also aft= er > YANG packages, then we could do a bis version of this document to define = a > v2 of the instance file format that potentially allows YANG packages to b= e > used to define the schema, and potentially allows modules to be identifie= d > using revision labels as well as revision dates. >=20 > Balazs, I'm good with most of your proposed resolutions, but have answere= d > one further question inline below. >=20 >=20 > > -----Original Message----- > > From: Bal=E1zs Lengyel > > Sent: 05 July 2021 13:47 > > To: 'netmod@ietf.org' ; Rob Wilton (rwilton) > > > > Cc: Benoit Claise > > Subject: FW: AD review of draft-ietf-netmod-yang-instance-file-format > > > > Hello Rob, > > Thanks for the review. Here are my answers below. I will also upload > > the new version asap. > > Regards Balazs > > ----------------------------------------------------------- > > Hi, > > > > Here is my AD review of draft-ietf-netmod-yang-instance-file-format-13. > > > > Thanks for this document, I think that it represents important useful > > work for advancing the YANG ecosystem. > > > > This document is in good shape, and I mostly have minor comments but > > with a few more significant comments. > > > > Main comments: > > >=20 > > > > 2. > > In the YANG Module: > > feature inline-content-schema { > > description > > "This feature indicates that inline content-schema > > option is supported. Support for this feature might > > be documented only via out-of-band documentation."; > > } > > > > What is the benefit of having 'inline-content-schema' as a feature? > > It seems to potentially add complexity without any benefit, given that > > the device originating the instance data file would effectively choose > > whether to use the inline-content-schema, hence I suggest that it > > might be simpler just to remove the feature definition. > > BALAZS: This was explicitly requested earlier by a reviewer (Andy ?). > > The system can declare supported/not-supported in design > documentation. > > In a use-case when a client or a design department is sending data to > > a server this is needed. E.g. in UC2, Preloading Default Configuration > > the designer preparing instance data, can decide to use or not use the > > inline-content-schema based on this. >=20 >=20 > > > > 3. > > In the YANG Module: > > > > "case inline", description: > > The first item is either ietf-yang-library or > > some other YANG module that contains a list of > > YANG modules with their name, revision-date, > > supported-features, and deviations. > > The usage of revision '2019-01-04' of the > > 'ietf-yang-library' module MUST be supported. > > Using other modules, module versions MAY also > > be supported. > > > > This seems to make interop for consumers of instance data files hard, > > since the schema can be defined by any arbitrary YANG module without > > updating this module. I would suggest that it is safer to limit this > > to the two currently published versions of YANG library. > > BALAZS: I fully agree, however this was explicitly requested by some > > reviewer earlier (Juergen ?) Shall I simplify this or not? > > > > If additional modules are supported in future, then I think that it > > would be safer to create a new version of this YANG module that > > documents what other module formats can be used. > > > > > > 4. > > In the YANG Module: > > list "revision" > > > > Is revision expected to be unique, if provided? If so, should this be > > explicitly stated in the YANG module description? > > BALAZS: I don't think I understand your comment. There may be multiple > > list entries for revision. The 'leaf date' is a key, so it is inherentl= y > unique. > > The description may or may not be unique. >=20 > I would suggest changing: >=20 > For every published editorial change, a new one SHOULD be added in front > of > the revisions sequence so that all >=20 > to: >=20 > For every published editorial change, a new unique revision SHOULD be > added > in front of the revisions sequence so that all >=20 > I.e., to also make it clear in the description that revisions dates are > required to be unique. >=20 >=20 > > > > > > 5. > > In the YANG Module: > > > > Is an instance-data file allowed to contain both a revision and also a > > timestamp? If so, is there any constraints on the values. If not, > > then would it make sense to put them under a choice? > > BALAZS: It is allowed to have both. There is some recommendation text > > about when to use each. However I can see some corner cases, when > > using both in the same file would be useful, E.g. we want a timestamp > > including hour, minutes, but we also want the history of the instance > > data set, including multible revision/descriptions. > > I propose to add: if both are included the timestamp, SHOULD contain > > the same date as the latest revision statement. >=20 > Okay. >=20 > Thanks, > Rob From nobody Wed Jul 7 11:12:27 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7E13A231A for ; Wed, 7 Jul 2021 11:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 BYEuWxN3pwY0 for ; Wed, 7 Jul 2021 11:12:20 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD303A2315 for ; Wed, 7 Jul 2021 11:12:20 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id a18so6216359lfs.10 for ; Wed, 07 Jul 2021 11:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JdqaX9Gzem1gt1O9Oh6IFLhk1k/EP3ruPgAkxELVxaw=; b=rK+18JY85Vzji/+84sVMEuDUfWNFvK3aXhQChSajWQ2aYYTsqFiX5nJAx4x8ylrNvu YTAKfOhmGcwlc7IY/eB0E249CKKI7KPwmo9v/LsUHIc5D2cTVq2O4UwhfA8INDTcypZz dYVz+FgfH0EYuK5RJEMW/N8u+64lB255O5rXHwGqbqioneEloSSPSVF4EO7xhWafHeHN DOWPMEwOBMPZoi6pWHishhsBeLXP1SJ8BlaOs322atW/DLAd1krjB8D2712ZN4PhRljh UJ0h/kQRi5gEYXJFHfrh0qVn39WYH6TsZFaYFDDEJj89qoiWrJ0c/wbp2sJJKSP9r/sT VWQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JdqaX9Gzem1gt1O9Oh6IFLhk1k/EP3ruPgAkxELVxaw=; b=WrMzFU5JaZynEousCjirP9DlvgMMSIQE0q2EUqtw/ZaJIaCmqvDjmM3o461kMFHbHT sYOTi8BnwS5OJyBCf7zHlRaVXrbYK2jUgSrD29FzkeSvuEAu9AE27PWRKmDBsgmWV4S+ GTtncPar18bxfCaIOgjji6mAk6/GhH/o3yTicIsmOO10jg+U2p9z+JOI8cE+dFFJw0A+ W6XtX2lHkm+VUGMNVetEtBrKtFQPqax2oFNpoPni7ZO3GrhFyuzAIirEtdjDAjYdjL47 BnyzGN3diXiENyaGsGKuG44UVu6GhFDe83z2baA8eC7taVI7789TyvFa1P0rCBvWLbHp /B3w== X-Gm-Message-State: AOAM530ofeV6oPtqQj3Q+TcCgRQZPK72SRvuKtNhkO6QnGjwZIjwad6I BECWmRxlOuE4FifRnVpePKaNf7HxID4SjAaasvjbPw== X-Google-Smtp-Source: ABdhPJygzX1/BhtLqAm8vDKu69+k/pzZp0C1HTOegTlQN2joksQlM7wSGJRX3U7lKu1nOEnaPJzWmUGQU789DQJBI2c= X-Received: by 2002:a2e:b60c:: with SMTP id r12mr2894212ljn.55.1625681537677; Wed, 07 Jul 2021 11:12:17 -0700 (PDT) MIME-Version: 1.0 References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> In-Reply-To: From: Andy Bierman Date: Wed, 7 Jul 2021 11:12:06 -0700 Message-ID: To: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= Cc: Juergen Schoenwaelder , "Rob Wilton (rwilton)" , "netmod@ietf.org" , Benoit Claise Content-Type: multipart/alternative; boundary="00000000000092508905c68c7ac3" Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 18:12:26 -0000 --00000000000092508905c68c7ac3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 7, 2021 at 1:01 AM Bal=C3=A1zs Lengyel wrote: > Hello Andy, > > There are many different use-cases for instance-data-files, each with > slightly different requirements. > > > I don't agree that the solution requires 3 ways to do the same thing. Well, 4 if you count External which means Proprietary and Not Standard At All. Inline method is needed, if you want to indicate that the file was > generated by someone who uses some YANG modules with deviations and some > features are not-supported. There is no way to indicate feature-support a= nd > deviations with the simplified-inline method. > > > The Inline anydata solution is very heavyweight. Before the YANG library there was a simple URI that is easier to use and takes up much less storage. > The URL method was requested for the use-case when you generate > instance-data-sets repeatedly e.g. every minute with the same schema. You > don=E2=80=99t want to include the content-schema in every file, so you ju= st include > a single URL reference. (Note the content schema may be a longer piece of > text, not just a single YANG module+revision) > The solution is very complex and it will not get implemented correctly, or at all. IMO this damages interoperability and prevents some companies from using the solution at all, because a reader tool has so much complexity to implement. The real-world result will be tools that can only read the files they wrote (not written by another tool). Regards Balazs > > > Andy > *From:* Andy Bierman > *Sent:* 2021. j=C3=BAlius 6., kedd 21:28 > *To:* Juergen Schoenwaelder ; Andy > Bierman ; Rob Wilton (rwilton) ; > Bal=C3=A1zs Lengyel ; netmod@ietf.org; Benoi= t > Claise > *Subject:* Re: AD review of draft-ietf-netmod-yang-instance-file-format > > > > > > > > On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote: > > On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote: > > > > > > > > IMO the 4 separate ways to identify the schema are 3 too many, but > that > > > > is what the WG wants. It seems obvious that any reader of the file > > > > has to implement all 4 methods and any writer of the file is free t= o > pick > > > > just one. > > > > So the feature does not really help. > > > > > > > > > > The feature statements declare that implementation won't work > > > together. Back in a day, the IETF was all about interoperability (and > > > implementation costs). Nowadays we seem to be fine if implementations > > > declare that they won't work together. Well, still slightly better > > > than having implementations fail arbitrarity. > > > > > > > > > > This is a text file stored on a USB stick. > > There is no client or server. Just readers and writers. > > So how does a YANG feature work here? > > The reader is supposed to know how to find out if this feature is set > > before opening the file? > > > > I don't see how server capabilities discovery is relevant to a > > YANG instance file. > > The reader code will simply attempt to read the file and fail if it > > encounters > > a format that is not implemented. > > I assumed that the features are carried in the instance file, i.e., > the file declares that it uses way X to announce the schema and then > the parser can fail with a suitable error message. If the features are > not carried in the file, then they indeed seem to be useless. > > Perhaps there are Y different ways to announce the features of the > instance file as well, I did not check. ;-) > > > > Now you made re-read the entire draft :-( > > I cannot find any text how the reader knows if this feature is set before > reading the > > file and finding out. > > > > I do not see any significant use-case for the Inline method and none for > the Uri method. > > Nor do I see any reason why the Simplified-Inline method should not be > mandatory > > to use and always present. > > > > If the use-case is offline server validation then the YANG library detail= s > need to be known. > > The entire YANG library for the server (or relevant parts) are recorded i= n > the Inline method. > > Except it is complicated to store the info about how to interpret YANG > schema by > > reading instance files and guessing what the "anydata" contains. > > > > I actually prefer a simple string based on RFC 6020 URI method, since it > can > > be easily integrated into the Simplified Inline form and can be parsed > without guessing > > anything about the contents of anydata. > > > > https://datatracker.ietf.org/doc/html/rfc6020#section-5.6.4 > > > > e,g, > > > > OLD: > > case simplified-inline { > leaf-list module { > type module-with-revision-date; > > ... > > } > > } > > > > NEW: > > > > case simplified-inline { > leaf-list module { > type union { > > type module-with-revision-date; > > type string; > > } > > ... > > } > > } > > > > Example module leaf-list entry: > > > > > ietf-interfaces?revision=3D2018-02-20&features=3Dif-mib,arbitrary-names&= deviations=3Dacme-deviations > > > > > > IMO Simplified Inline SHOULD be the only format, and the other methods ca= n > be removed. > > > > > > /js > > > > > > Andy > > > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > > --00000000000092508905c68c7ac3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 7, 2021 at 1:01 AM Bal=C3= =A1zs Lengyel <balazs.lengyel@ericsson.com> wrote:

Hello Andy,

There are many = different use-cases for instance-data-files, each with slightly different r= equirements.

=C2=A0


I don't agree that the solutio= n requires 3 ways to do the same thing.
Well, 4 if you count Exte= rnal which means Proprietary and Not Standard At All.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
<= p class=3D"MsoNormal">

Inline method is ne= eded, if you want to indicate that the file was generated by someone who us= es some YANG modules with deviations and some features are not-supported. T= here is no way to indicate feature-support and deviations with the simplifi= ed-inline method.

=C2=A0

=

The Inline anydata solution is= very heavyweight.
Before the YANG library there was a simple URI= that is easier to use
and takes up much less storage.
=
=C2=A0

The URL method was requested for the use-case when you generate in= stance-data-sets repeatedly e.g. every minute with the same schema. You don= =E2=80=99t want to include the content-schema in every file, so you just in= clude a single URL reference. (Note the content schema may be a longer piec= e of text, not just a single YANG module+revision)


The solution is very complex and it will not get im= plemented correctly, or at all.
IMO this damages interoperability= and prevents some companies from using the solution
at all, beca= use a reader tool has so much complexity to implement.=C2=A0 The real-world= result
will be tools that can only read the files they wrote (no= t written by another tool).


Regards Balazs

=C2=A0

<= div>
Andy
=C2=A0

From: Andy Bierman <andy@yumaworks.com>
Sent: 2021. j=C3=BAli= us 6., kedd 21:28
To: Juergen Schoenwaelder <j.schoenwaelder@ja= cobs-university.de>; Andy Bierman <andy@yumaworks.com>; Rob Wilton (rwilton) = <rwilton@cisco.co= m>; Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>; netmod@ietf.org; Benoit Claise = <benoit.cl= aise@huawei.com>
Subject: Re: AD review of draft-ietf-netm= od-yang-instance-file-format

= =C2=A0

=C2=A0

=C2=A0

On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder <= j= .schoenwaelder@jacobs-university.de> wrote:

<= blockquote style=3D"border-top:none;border-right:none;border-bottom:none;bo= rder-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.= 8pt;margin-right:0cm">

O= n Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> On Tue= , Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder <
> j.schoenwaelder= @jacobs-university.de> wrote:
>
> > On Tue, Jul 06, = 2021 at 09:42:39AM -0700, Andy Bierman wrote:
> > >
> >= ; > IMO the 4 separate ways to identify the schema are 3 too many, but t= hat
> > > is what the WG wants.=C2=A0 It seems obvious that any= reader of the file
> > > has to implement all 4 methods and an= y writer of the file is free to pick
> > > just one.
> &g= t; > So the feature does not really help.
> > >
> >=
> > The feature statements declare that implementation won't = work
> > together. Back in a day, the IETF was all about interoper= ability (and
> > implementation costs). Nowadays we seem to be fin= e if implementations
> > declare that they won't work together= . Well, still slightly better
> > than having implementations fail= arbitrarity.
> >
> >
>
> This is a text fil= e stored on a USB stick.
> There is no client or server. Just readers= and writers.
> So how does a YANG feature work here?
> The rea= der is supposed to know how to find out if this feature is set
> befo= re opening the file?
>
> I don't see how server capabilitie= s discovery is relevant to a
> YANG instance file.
> The reader= code will simply attempt to read the file and fail if it
> encounter= s
> a format that is not implemented.

I assumed that the featu= res are carried in the instance file, i.e.,
the file declares that it us= es way X to announce the schema and then
the parser can fail with a suit= able error message. If the features are
not carried in the file, then th= ey indeed seem to be useless.

Perhaps there are Y different ways to = announce the features of the
instance file as well, I did not check. ;-)=

=C2=A0=

Now you made re-read the entire d= raft :-(

I cannot find a= ny text how the reader knows if this feature is set before reading the

file and finding out.=

=C2=A0

=

I do not see any significant use-case for the I= nline method and none for the Uri method.

Nor do I see any reason why the Simplified-Inline method = should not be mandatory

= to use and always present.

=C2=A0

If the use-cas= e is offline server validation then the YANG library details need to be kno= wn.

The entire YANG libr= ary for the server (or relevant parts) are recorded in the Inline method.

Except it is complicated = to store the info about how to interpret YANG schema by

reading instance files and guessing what th= e "anydata" contains.

=C2=A0

I actuall= y prefer a simple string based on RFC 6020 URI method, since it can<= u>

be easily integrated into the S= implified Inline form and can be parsed without guessing

<= /div>

anything about the contents of anydata.=

=C2=A0

=C2=A0

e,g,<= u>

=C2=A0

=

OLD:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case simplified-inline {=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf-list module {=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type mod= ule-with-revision-date;

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

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

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

=C2=A0

N= EW:

=C2=A0=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0case simplified-inline {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0leaf-list module {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 type union {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0type module-with-revision-date;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...<= u>

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

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

=C2=A0

Example module leaf-list entry:

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0ietf-interfaces?revision=3D2018-02-20&fea= tures=3Dif-mib,arbitrary-names&deviations=3Dacme-deviations

=C2=A0

=

=C2=A0

IMO Simplified Inline SHOULD be the only format, and the other method= s can be removed.

=C2=A0

=C2=A0

/js

<= /blockquote>

=C2=A0

=

=C2=A0

Andy

=C2=A0=

=C2=A0

=


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

--00000000000092508905c68c7ac3-- From nobody Wed Jul 7 11:50:12 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B4F3A2464 for ; Wed, 7 Jul 2021 11:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 4Y_paw11bTEo for ; Wed, 7 Jul 2021 11:50:06 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB2A3A2455 for ; Wed, 7 Jul 2021 11:50:05 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id n14so6588114lfu.8 for ; Wed, 07 Jul 2021 11:50:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SHsoythHSUFyudz2xl3aP/IKXVHSEbJRNz7SftjkgzI=; b=MCHC6mh09xnqlJQnlHu9lZvL/VRvu2ig5lIgEvr2ibx2gwJuQZNCLb/VbrC/FIkiOs gKIhPKNMijj9HiZJl/kUtW/xhHPSElbhskUHemsaO2P3H6DOdu7LIrOJMFYKN+SwCMdV Dm9tNhhg148sB1hg4RtD7Ba3qCCcpzvWujiuTHFKmzuUGFlJ85ULAtvmX4vZkYDmxBGI buuUKpFS2qGGOmPrTtdD/NOnsdua8kJPD7FMt+j5lqhyA6HGXd60w6l5is1m52cYHdWc Vx4yrlwy2SfyCsGg8VVyIRoOERrHzT94EYk9AYih4XTN+UadNw4uIAw0l9dgaA4VmWid swLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SHsoythHSUFyudz2xl3aP/IKXVHSEbJRNz7SftjkgzI=; b=mvsSprZuteOWV8m5xGmSCLY/aZ0FFAuLpKWHzmtDtuSzHpY9X4smztZqJgxlULrcEA ZTZFRmHDaavQIsf0Qn5Eqg/FLA6geebhji0C8ilGXI5IZwipc7Mp9IUuwqXValN6e9oS sKxtDXqlowTLOB/8IOD+PhjYP4/F17a7M7Nb+EDJ/5niMpb+VQvzm6BTCzGEUblA/feO jlcKFZWJFzNLeQ8kyZiNxIFwWi/T5HSci3OIKHV1BHZp06EKF1/z3Y0NiQv7r81+aSSx ENfqthQGXhYtz6GAweTjJ95rrEizd46NrdQySKHNd9JWb83mtB2sPvG16Y2Pn6/ReXPM jVZw== X-Gm-Message-State: AOAM530AcZTByW5gc1nmtC0blVnd6a3fWRjpd4EBxoiuwgDD218KkOv9 +yNGy4NVEoqbLc5H6z8NIW2A46F0AJ9ZF2jaS1Et9w== X-Google-Smtp-Source: ABdhPJwNAcU01Sgk9s0G6areWjorNMdhh/vieYUtnqqgAhKaO5B3rZs/Me/v7ti/OPRMJARhvRda1puJzD40++KQjXk= X-Received: by 2002:a19:c1d4:: with SMTP id r203mr19680198lff.512.1625683803374; Wed, 07 Jul 2021 11:50:03 -0700 (PDT) MIME-Version: 1.0 References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> In-Reply-To: From: Andy Bierman Date: Wed, 7 Jul 2021 11:49:52 -0700 Message-ID: To: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= Cc: Juergen Schoenwaelder , "Rob Wilton (rwilton)" , "netmod@ietf.org" , Benoit Claise Content-Type: multipart/alternative; boundary="0000000000009e19cb05c68d0172" Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 18:50:12 -0000 --0000000000009e19cb05c68d0172 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I have some questions about the same-schema-as-file leaf: leaf same-schema-as-file { type inet:uri; description "A reference to another YANG instance data file. This instance data file uses the same content schema as the referenced file."; } The type is an unconstrained URI. Is this the intent? The tool that writes the file can pick any scheme - any valid URI at all. The reader must support every known URI scheme in existence? Is that the intent here? Sec. 4 contains this line: The header part is not security sensitive. Is this really true if a URI is present in this leaf that contains a username and password in cleartext? Andy On Wed, Jul 7, 2021 at 1:01 AM Bal=C3=A1zs Lengyel wrote: > Hello Andy, > > There are many different use-cases for instance-data-files, each with > slightly different requirements. > > > > Inline method is needed, if you want to indicate that the file was > generated by someone who uses some YANG modules with deviations and some > features are not-supported. There is no way to indicate feature-support a= nd > deviations with the simplified-inline method. > > > > The URL method was requested for the use-case when you generate > instance-data-sets repeatedly e.g. every minute with the same schema. You > don=E2=80=99t want to include the content-schema in every file, so you ju= st include > a single URL reference. (Note the content schema may be a longer piece of > text, not just a single YANG module+revision) > > Regards Balazs > > > > *From:* Andy Bierman > *Sent:* 2021. j=C3=BAlius 6., kedd 21:28 > *To:* Juergen Schoenwaelder ; Andy > Bierman ; Rob Wilton (rwilton) ; > Bal=C3=A1zs Lengyel ; netmod@ietf.org; Benoi= t > Claise > *Subject:* Re: AD review of draft-ietf-netmod-yang-instance-file-format > > > > > > > > On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote: > > On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote: > > > > > > > > IMO the 4 separate ways to identify the schema are 3 too many, but > that > > > > is what the WG wants. It seems obvious that any reader of the file > > > > has to implement all 4 methods and any writer of the file is free t= o > pick > > > > just one. > > > > So the feature does not really help. > > > > > > > > > > The feature statements declare that implementation won't work > > > together. Back in a day, the IETF was all about interoperability (and > > > implementation costs). Nowadays we seem to be fine if implementations > > > declare that they won't work together. Well, still slightly better > > > than having implementations fail arbitrarity. > > > > > > > > > > This is a text file stored on a USB stick. > > There is no client or server. Just readers and writers. > > So how does a YANG feature work here? > > The reader is supposed to know how to find out if this feature is set > > before opening the file? > > > > I don't see how server capabilities discovery is relevant to a > > YANG instance file. > > The reader code will simply attempt to read the file and fail if it > > encounters > > a format that is not implemented. > > I assumed that the features are carried in the instance file, i.e., > the file declares that it uses way X to announce the schema and then > the parser can fail with a suitable error message. If the features are > not carried in the file, then they indeed seem to be useless. > > Perhaps there are Y different ways to announce the features of the > instance file as well, I did not check. ;-) > > > > Now you made re-read the entire draft :-( > > I cannot find any text how the reader knows if this feature is set before > reading the > > file and finding out. > > > > I do not see any significant use-case for the Inline method and none for > the Uri method. > > Nor do I see any reason why the Simplified-Inline method should not be > mandatory > > to use and always present. > > > > If the use-case is offline server validation then the YANG library detail= s > need to be known. > > The entire YANG library for the server (or relevant parts) are recorded i= n > the Inline method. > > Except it is complicated to store the info about how to interpret YANG > schema by > > reading instance files and guessing what the "anydata" contains. > > > > I actually prefer a simple string based on RFC 6020 URI method, since it > can > > be easily integrated into the Simplified Inline form and can be parsed > without guessing > > anything about the contents of anydata. > > > > https://datatracker.ietf.org/doc/html/rfc6020#section-5.6.4 > > > > e,g, > > > > OLD: > > case simplified-inline { > leaf-list module { > type module-with-revision-date; > > ... > > } > > } > > > > NEW: > > > > case simplified-inline { > leaf-list module { > type union { > > type module-with-revision-date; > > type string; > > } > > ... > > } > > } > > > > Example module leaf-list entry: > > > > > ietf-interfaces?revision=3D2018-02-20&features=3Dif-mib,arbitrary-names&= deviations=3Dacme-deviations > > > > > > IMO Simplified Inline SHOULD be the only format, and the other methods ca= n > be removed. > > > > > > /js > > > > > > Andy > > > > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > > --0000000000009e19cb05c68d0172 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have some questions about the sam= e-schema-as-file leaf:

=C2=A0 =C2=A0 =C2=A0 =C2=A0= leaf same-schema-as-file {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0type inet:uri;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0descri= ption
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"A ref= erence to another YANG instance data file.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 This instance data file uses the same
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 content schema as the ref= erenced file.";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

The type is an unconstrained URI.
Is this th= e intent?
The tool that writes the file can pick any scheme - any= valid URI at all.
The reader must support every known URI scheme= in existence? Is that the intent here?

Sec. 4 con= tains this line:

    The header part is not security sensitive.

Is this really = true if a URI is present in this leaf that contains a username and password=
in cleartext?=C2=A0


Andy=


On Wed, Jul 7, 2021 at 1:01 AM Bal=C3=A1zs Lengyel <= ;balazs.lengyel@ericsson.com= > wrote:
=

Hello Andy,<= /u>

There are many different use-cases for= instance-data-files, each with slightly different requirements. =

=C2=A0

Inline method is needed, if you want to indicate that the file was gener= ated by someone who uses some YANG modules with deviations and some feature= s are not-supported. There is no way to indicate feature-support and deviat= ions with the simplified-inline method.

=C2=A0

The URL method was requ= ested for the use-case when you generate instance-data-sets repeatedly e.g.= every minute with the same schema. You don=E2=80=99t want to include the c= ontent-schema in every file, so you just include a single URL reference. (N= ote the content schema may be a longer piece of text, not just a single YAN= G module+revision)

Regards Balazs

=C2=A0

From: Andy Bierman <andy@yumaworks.com>
Sent: 2021. j=C3=BAlius 6., kedd 21:= 28
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university= .de>; Andy Bierman <andy@yumaworks.com>; Rob Wilton (rwilton) <rwilton@cisco.com>; Bal= =C3=A1zs Lengyel <balazs.lengyel@ericsson.com>; netmod@ietf.org; Benoit Claise <benoit.claise@huawei= .com>
Subject: Re: AD review of draft-ietf-netmod-yang-ins= tance-file-format

=C2= =A0

=C2=A0

=C2=A0

On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder <j.schoenwae= lder@jacobs-university.de> wrote:

On Tue, Jul= 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> On Tue, Jul 6, 2= 021 at 10:42 AM Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-un= iversity.de> wrote:
>
> > On Tue, Jul 06, 2021 at 09= :42:39AM -0700, Andy Bierman wrote:
> > >
> > > IMO= the 4 separate ways to identify the schema are 3 too many, but that
>= ; > > is what the WG wants.=C2=A0 It seems obvious that any reader of= the file
> > > has to implement all 4 methods and any writer o= f the file is free to pick
> > > just one.
> > > So= the feature does not really help.
> > >
> >
> &= gt; The feature statements declare that implementation won't work
&g= t; > together. Back in a day, the IETF was all about interoperability (a= nd
> > implementation costs). Nowadays we seem to be fine if imple= mentations
> > declare that they won't work together. Well, st= ill slightly better
> > than having implementations fail arbitrari= ty.
> >
> >
>
> This is a text file stored o= n a USB stick.
> There is no client or server. Just readers and write= rs.
> So how does a YANG feature work here?
> The reader is sup= posed to know how to find out if this feature is set
> before opening= the file?
>
> I don't see how server capabilities discover= y is relevant to a
> YANG instance file.
> The reader code will= simply attempt to read the file and fail if it
> encounters
> = a format that is not implemented.

I assumed that the features are ca= rried in the instance file, i.e.,
the file declares that it uses way X t= o announce the schema and then
the parser can fail with a suitable error= message. If the features are
not carried in the file, then they indeed = seem to be useless.

Perhaps there are Y different ways to announce t= he features of the
instance file as well, I did not check. ;-)=

=C2=A0

Now you made re-read the entire draft :-(

I cannot find any text ho= w the reader knows if this feature is set before reading the<= /p>

file and finding out.

=C2=A0

I do not see any significant use-case for the Inline meth= od and none for the Uri method.

Nor do I see any reason why the Simplified-Inline method should not= be mandatory

to use and= always present.

= =C2=A0

If the use-case is offli= ne server validation then the YANG library details need to be known.=

The entire YANG library for th= e server (or relevant parts) are recorded in the Inline method.

Except it is complicated to store t= he info about how to interpret YANG schema by

<= p class=3D"MsoNormal">reading instance files and guessing what the "an= ydata" contains.

=C2=A0

I actually prefer a= simple string based on RFC 6020 URI method, since it can

=

be easily integrated into the Simplified = Inline form and can be parsed without guessing

=

anything about the contents of anydata.

=C2=A0

=C2=A0

e,g,<= /u>

=C2=A0

OLD:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case simplified-inline {
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf-list module {
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type module-wit= h-revision-date;

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

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

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

=C2=A0

NEW:=

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case= simplified-inline {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0leaf-list module {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 type union {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0type module-with-revision-date;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;

=

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

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

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

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

=C2=A0

Example module leaf-list entry:

=C2=A0

= =C2=A0 =C2=A0 =C2=A0 =C2=A0ietf-interfaces?revision=3D2018-02-20&featur= es=3Dif-mib,arbitrary-names&deviations=3Dacme-deviations<= /p>

=C2=A0

=C2=A0

IMO Simplified Inline SHOULD be the only format, and the other methods c= an be removed.

= =C2=A0

=C2=A0

=

/js

=C2=A0

<= p class=3D"MsoNormal">=C2=A0

Andy

=C2=A0<= u>

=C2=A0

<= blockquote style=3D"border-top:none;border-right:none;border-bottom:none;bo= rder-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.= 8pt;margin-right:0cm">


--
Juergen Schoenwaeld= er=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbHPhone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | = 28759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>=

--0000000000009e19cb05c68d0172-- From nobody Wed Jul 7 12:17:56 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3D5E3A253C for ; Wed, 7 Jul 2021 12:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuPpEh1UG0T9 for ; Wed, 7 Jul 2021 12:17:50 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1anam02on2094.outbound.protection.outlook.com [40.107.96.94]) (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 204F53A2538 for ; Wed, 7 Jul 2021 12:17:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OQo6AVdAgD6JHi+nuboZNYNc5TKtzhD6KXMrIRwwN+g/urKirxYDtzAupLNF8Vv4gfSYlISz5PYnaHAVikpoEgpv8490t5pwIFDcddwooVoD6TeSiyfkntjJN0/6qhCrNXMWKOG3zqOisher+cXQrCtXlV+qaToI2M3F0Qt8G8epWT+/lhz+Lrr52RL/2fR9ctRudls7syfitjGG+3hCTvZtIdewB600A8PWjqhsMqpZKxyoGd/IuZAGbOc9f/FK1CsI5kJVj/Jvonua3rXLsrfus0oWhr6WFoDKysRJQR6MHICe9juIHQ7JU3h2DZmR1ex5z1aM5uVEI6sAdj0NBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8wHYo5Jug80gEr6qcVXUhqiOy1gyPlsuU17IZe6znVo=; b=AmaZ7ft3suL+hddqvuOgynWrb1jfVEBH3MsImrbw1ZFA4SeDhwXO5OXGCq17BN0JgP0fp7LaGEefTKXmAuYV1Rcv1kHN8KHq33pp37zgW1o4/2I6SawohhetofWffjIDYuaR2YRdMbux1QHRAULSiFpYJP5tTIICrkzpSWueaYnmsvBgIbszK3Y6nsjc3msQP/ZDMda5OiUowJ0s07B9q/0ZpnlnBv4O0RIN3ExVKwsvER9ztWXVOgDuAmBBBrpihfJ+v3WjxbvKuXrYjFJjZZCf94cA8wwwtvbP/7ESPE3Wv94UUyW6cRSd2JKuwnSX1Q6z5h5To/B9CYWD+u0MpA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8wHYo5Jug80gEr6qcVXUhqiOy1gyPlsuU17IZe6znVo=; b=ZlNMbGZZ7E0kAtzngngYWAWgZRFiCCCBRXkBoqau7u4H4l8ZiBdACFl02npOESp3UtFiEptzsEeefCIjsyG32bjm20Xz9Q3V8CojXZbXB/xBdCCmxAOdqgPZfEyECT3QzjM1t4E4iME2dKq1GMzcBu/iY+7L8iDN82Zwy8G2NYg= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB5706.namprd08.prod.outlook.com (2603:10b6:5:155::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.32; Wed, 7 Jul 2021 19:17:45 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::f431:78d:76de:1ba5]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::f431:78d:76de:1ba5%7]) with mapi id 15.20.4287.033; Wed, 7 Jul 2021 19:17:45 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG Versioning Weekly Call Minutes - 2021-07-06 Thread-Index: AddzZI7tKROKFqNXQcGJI5jtZVxZrA== Date: Wed, 7 Jul 2021 19:17:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2398c56b-cff5-4537-77f1-08d9417be664 x-ms-traffictypediagnostic: DM6PR08MB5706: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nGBopNFB8fVmVaypkBBnbnWGb2JKeXsKbMTg5JKEv2pGZhLv2/FFU/icW+C/L+1SYY1SAXr+l8B2iW5Cb140DHbkYIOJTmBXF50SC5HyaV/IXAArGXpHX7IZUPmGDY06+nCvfq2hUFZ4HaoogM7inmJaXE4B83li5uKG7SqMgykdZ0/6K1yzO4fkDIO+qcsvT3s15q01aMdC42YJTiqF9+3i4UIFSeAp8V/FNtLJVltnOG9Lr84AmghWcrKo3z1Tlc1iZj5tm8epXxJLDzN+WZzcjAeP2mFK4TYPDvtuHkwUQZr6XgKrykbrtowruB9qg+oMww8PMeEQ3V4HPnxTpo8PJWSF+Kwd6lpnVDH2LE8Zt9jnt64E+j/edG3pDhPFpsOYynd9fpxUiUEmxgI/w3dYzWN0dHo7XOp+LIjBM45rmlk00BtrqUFM1PAySXNeVwo/kKgt5cZAB4fRounwX2AFDqCXgzu2+DcR5QL0w4QbTZBrwXvyb4DtNv/FGFvvZNUHRVk0fYpKy05MOIMc8i2M2O5N+y6uoXHKW+vNP9R+To6MbHQ2oLoTItIe1VEcPBxbhuN8mnUROPga3YefPBSXHz2tRNx5n+bacrOVfSt6ilShx2s11fpOVA8/Nvr5nPRFLb0kDJJ/VDg2EIjygf4azVBQl/4ec+rd510hVDMBp9Et34vCMyb2ttRFZRZ/9w0fQY4A9FgmXZqPjq7MALLuRKu6fJiIQLk0p+zzmlI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(376002)(346002)(39860400002)(396003)(38100700002)(71200400001)(2906002)(186003)(76116006)(6506007)(64756008)(6916009)(316002)(33656002)(16799955002)(8936002)(66476007)(9686003)(8676002)(478600001)(122000001)(7696005)(66556008)(966005)(86362001)(5660300002)(55016002)(26005)(66946007)(83380400001)(52536014)(66446008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?eYPiHUnp6jlXXYGl9SRy3blzC/SzKIBYzj3PXRqQXhxIxqueqllwjkxaar4Q?= =?us-ascii?Q?n/g0Pdyq1LP/PBYPr/8VXt31IvU9m5MOIJNl/wZTx+mNCu+Vudb+NfAaG/jj?= =?us-ascii?Q?J3vOOJoAsxfrsJLBlbl0ArEbS+Ix1jB3uqhFLnZzi/HCHk6tGoftJ0g0B2xr?= =?us-ascii?Q?fX8LXVGaeIVv9qMLHaRhLFIqa6A6/x+fYFegF3BHikImKxKkW2sy2H0+2yjN?= =?us-ascii?Q?/7iUORA3bb8Lro7ySDEIjuQIxUTsQ5jVXgaie2HgonxYOCSCazt2PLXfrZhV?= =?us-ascii?Q?ldbDYtYAfnU3twr6YFkTZNjkjaFpysTTZTliTekxRejAEMnAUHH+Hbxt6YCk?= =?us-ascii?Q?aTkzWlaSpK919W4UFsB3VGW4LJvLHB7kZGq+RF7ZpKj3x27mfGVJHGVDau6O?= =?us-ascii?Q?/sI2Qe7Brv+HaxB0WlRJuS+Rmkzoc3z3VLnlK92aoUQc1zrse9vhh8qScUyc?= =?us-ascii?Q?laeBQfzVOYZY3Zp6mErZPF2NC3EPgUbRrC+DGAeA2f63o+SO/CVOWRWiZEvv?= =?us-ascii?Q?uqkGLnxWth3sDiQ4IdQmG1aL2ofZNhaqAPej2SjZq5YabvVNkXd4nL/LE084?= =?us-ascii?Q?MTRR/owBwh2VpFyDyKayvn6OLLtldIUjKAiYBn+9CX6YV4fTb/rei5dHiL7P?= =?us-ascii?Q?/gvk3IIjbOb36YEtMaS7F5ToLuQTREdKdVH5xzfAmGJBfaxO9SHBk3TAi7s/?= =?us-ascii?Q?AJVhWiwBb3KYMuMofOOC9E3/j/yUO7j01gfTC3hdnfrJvC3Fdo5cfJ1rYuFZ?= =?us-ascii?Q?maKWE/4KDrXlE2e/LbLxPLDoKLnFxKEQ0FFlBT0VR3NxgdqZWrYfqHp0sNAK?= =?us-ascii?Q?t0cJerGxJdNkyu4I7hM3idlv8jnKhr3Pu3c7rJgszLcmhOB7NQTF+m+gaHh8?= =?us-ascii?Q?KhvmIX29vZE+l1ioYfCYfX+jcL7NyG3NV4PNtrVBo3UxFwmEvvuhiNLr8vNN?= =?us-ascii?Q?hXxvsaiuCA7fdef2V7UtQIHzSGWwQoXwmEcmGP7pvLmc15NUugEab2Khh+3r?= =?us-ascii?Q?MmXyuh7XV4YZL+DLG5k3c19bS57qAHYZBlMglZT/yRP2uEp45VIBdYD+XoTi?= =?us-ascii?Q?cLUT9Z7gZrMpb4fWwBsG2Z8yVBEhDpRsKLpqE+yZztmGN25dlvO7hd7xX9pM?= =?us-ascii?Q?iR1YJuM4WvbqaS79fCE6q5kQfHHyXFq8mwPehSKUp3zchiPhUrGRiNDSbfWY?= =?us-ascii?Q?FCmmqaX+k5Y9s411JFyiaA2L1qFfqO8Wn5neiLBmkotcNiiCo5Vcijy/qmER?= =?us-ascii?Q?K5XmMWoZHKGwzJHhRAEOcsWc2cjRQg9Zoq4Nr8fdbCtDXk4pPDtw36mEQGKX?= =?us-ascii?Q?SdJV+9aWiW2esKaHV6papxQ4?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB508401A7E6E782B748338D959B1A9DM6PR08MB5084namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2398c56b-cff5-4537-77f1-08d9417be664 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jul 2021 19:17:45.0275 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: sgD+3tXRZjl8pnddmx58yw+1N8D/OYm4rpmTjUxx/R438iC/YvnWifv9l3JLkZkr35HLtR7sCY6WDVV6MquF4g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB5706 Archived-At: Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-07-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 19:17:55 -0000 --_000_DM6PR08MB508401A7E6E782B748338D959B1A9DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YANG Versioning Weekly Call Minutes - 2021-07-06 IETF 111 presentation (July 27 Tues) - Jason present intro + module versioning (Joe as backup) - Joe present semver - slide preparation for module versioning: - A) Module versioning "Updates since last time": Reshad - closed issue - diff the draft - see previous weekly call minutes - B) Module versioning "Open Issues": Jason - Andy & Juergen's comments about yang next (1.2 vs 2.0 with everythi= ng else ?) - ready for WG LC ? (but not take it there yet ? just don't take to = IESG ?) - industry is moving this way anyway - Joe prep semver slides - are all open github issues actually addressed ? Rob's email "PLEASE READ" - done except wording for guidance on removing hi= story -> next steps: more top down reviews (Jan, Jason, Reshad, Joe, Bo ?) Also need to start top down reviews of Semver draft Joe will bump the requirements draft to keep it alive Jason ---------------------------------------------- Weekly webex call details: Meeting number (access code): 171 069 0374 Meeting password: semver? Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, Au= gust 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Cana= da) 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) --_000_DM6PR08MB508401A7E6E782B748338D959B1A9DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

YANG Versioning Weekly Call Minutes - 2021-07-06

 

IETF 111 presentation (July 27 Tues)

- Jason present intro + module versioning (Joe as ba= ckup)

- Joe present semver

- slide preparation for module versioning:

   - A) Module versioning "Updates si= nce last time":  Reshad

      - closed issue

      - diff the draft=

       - see previous = weekly call minutes

   - B) Module versioning "Open Issue= s": Jason

      - Andy & Juergen'= s comments about yang next (1.2 vs 2.0 with everything else ?)

      - ready for WG LC ?&n= bsp; (but not take it there yet ? just don't take to IESG ?)

       - industry is m= oving this way anyway

- Joe prep semver slides

     - are all open github issue= s actually addressed ?

Rob's email "PLEASE READ" - done except wo= rding for guidance on removing history

-> next steps: more top down reviews (Jan, Jason,= Reshad, Joe, Bo ?)

 

Also need to start top down reviews of Semver draft<= o:p>

 

Joe will bump the requirements draft to keep it aliv= e

 

Jason

 

----------------------------------------------<= /o:p>

Weekly webex call details:

Meeting number (access code): 171 069 0374

Meeting password: semver?

Occurs every Tuesday effective Tuesday, September 1,= 2020 until Tuesday, August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) = Eastern Time (US & Canada)

9:00 am  |  (UTC-04:00) Eastern Time (US &= amp; Canada)  |  1 hr

https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7= b770537cff5f5b89293c70

Tap to join from a mobile device (attendees only)

+1-650-479-3208,,1710690374## Call-in toll number (U= S/Canada)

--_000_DM6PR08MB508401A7E6E782B748338D959B1A9DM6PR08MB5084namp_-- From nobody Wed Jul 7 12:25:44 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B687B3A257B for ; Wed, 7 Jul 2021 12:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.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 QKAdOVcyC87d for ; Wed, 7 Jul 2021 12:25:38 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20072.outbound.protection.outlook.com [40.107.2.72]) (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 6D8CC3A2579 for ; Wed, 7 Jul 2021 12:25:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eQ+22oXdNTbPleHIMVqEZkfnWrsKLiPD5TwqVKUJ8CeK6SEfyBns3JumAn81LsHMbXxzVlsCx+CVFYEZp8Vg2Ly5t+7/HHqYBXamcKn7FNqH6XqRHM+bD72ubaeR77SEru48gf8EnnFH5FTr1RSjgHQvMdJCcTcA24tjZ0kNXYkd9sxTKd4SSqmvlNky5GhME9r9VuYdZzOivRQoPwH1/s/SBd6m42dZRa5MeK7Vq3wp/7E1RzQIa4tvTqFi0XtkWN7cqw21J7V+NeLdrwSGBlZBi44OKusB1XgVv5jZt5nVs6A6Z+MeuQvTxSVZAKgSq+qD7WjYWugzQmpY7hfyfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qyyq+5+xEZPKUMbJaaAc+ji5ISj3rI4pilISrcSmLuc=; b=C+G36gtNtpfqCl5GDYz8unBEDQ9PhstXOTOvXiESHENSiAHjESNz/6q12Tc1PCE9Je8VcG9QPXg2JdiMlAwFOWogF+werriOcq2lc4bjLmjC4GtWxmTw+P2+mWpvRqqoAe1HepObZsru7dSbFXwxhus5iOVwou42s5MtnvgjeIqcXWqZJLktvXwqmgo6omyGe8YaLmY93pQQy78Oog4DijkWcvZ03Av2tXDful6nKL8T3gx3SLfd9VL6ol0b771C9TkVL2OgzoLrCPtUTpVK+PQ1L661HeFCZ4DBZIA6E/wT4nYhXsQPUKHiGGNhjffZoe900f0cw4ev4lbC8s8CSw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Qyyq+5+xEZPKUMbJaaAc+ji5ISj3rI4pilISrcSmLuc=; b=UO3Z2AXTD/ckX0WLdZ0RslYLM/1XGmcMuRvYNOr/c2XzVvcDs8t7QLt3SPbf8w87HiLs8gVzQ1MvMIFz2af0GtHALiLVDFiKAGTniDjztj7wTzpmz3HKB6HIQhejTodbY/CtnS4lLQyiOLpoYujAUvXiwl85eZ6lobAt7SNmWwA= Authentication-Results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1220.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:262::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.19; Wed, 7 Jul 2021 19:25:35 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::d505:1bab:3e82:6d6b]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::d505:1bab:3e82:6d6b%4]) with mapi id 15.20.4308.021; Wed, 7 Jul 2021 19:25:35 +0000 Date: Wed, 7 Jul 2021 21:25:34 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "Rob Wilton (rwilton)" , "netmod@ietf.org" , Benoit Claise Message-ID: <20210707192534.4emim5a36zyqrktc@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "Rob Wilton (rwilton)" , "netmod@ietf.org" , Benoit Claise References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: PR0P264CA0204.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1f::24) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR0P264CA0204.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1f::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.20 via Frontend Transport; Wed, 7 Jul 2021 19:25:34 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4c291e7f-98cb-49ae-0014-08d9417cfe6f X-MS-TrafficTypeDiagnostic: AM9P190MB1220: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: kCyzpPMurpJNdhI2uEzHztxuKnYDwXqPHhKDJ19BiH50eIjWgF7H64vDrPjjGwnLllrsUPJO8aQ9caPhQoFwCLrYytdVJ2tbvJj9DZuaxOx5IM0A5TGDTaTU5thd26qXpy+nJLp5LPBObv9cvkLAHRx4fmquMw3xo+ygkZMtOfHFne6WFRBxnlz5FIlZ81ccFVedyn2AXcgh8azWiFcuHx1fM5SpBqwo6DcW08SFMB+nWRhtzYa+AtuZXVoMb6AoOHJBmXfbwlsDSdwG3APrLSduhpJ3qcRqFxVeFMA85bnlmzaOB9o0a9ykfGe+GnGSgcSqZeOei9ywRvPlKSbJ6YyWP2ZCC7Ey+Pb7RkXPZ6h9hNFXV+j4P0NQ7VK5S/muttJrV/0ihz7+JdHycYTCMlw2Z311R0vXDsw9PqyiyEeL/xu4joZ5icOO4WArhdWAJsZHanSn0ums/RjUqQd+3G/6AxBzolCGb9gJXFcf0hCOWTzN356ck6b6KIan0YdLM4KZVkYHjbZ8BYtdPQC/VowN9/2Fx5osj5SrimD3/7mcUb32hOjAcNKwbaKBXjdEESgBwWBbsTRucUrvD+PcSBUe2iOlAKNYMNXTt8k6T36YOBykFzW9WrsceMgpShwX//UBoG3BSC0TH1Bskn4JgnFy9H8gWc3/ScDyOX1watzEzNmwsSZk2z5GZuFf/c+qBfUL//Y6is47lLBhjWyYE+btRa1tMZT1r4QNxdfGNuLOxZZICO8WygKUqEyXkfmWby/z/rsvzqzOEVmjyTI+Eu8t+WJpJw479kxg140GxbU= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(396003)(366004)(136003)(376002)(39840400004)(3450700001)(786003)(316002)(54906003)(8676002)(956004)(1076003)(4326008)(2906002)(6486002)(186003)(26005)(5660300002)(38100700002)(66556008)(66476007)(52116002)(66946007)(6916009)(6496006)(8936002)(478600001)(38350700002)(86362001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?/3Pw7HmKT+V1daXQq/7VBV1p2IOnnJgnaMsE4kLCUId/87dedyGcniIKhHj+?= =?us-ascii?Q?5j3qlr8zyy/5/ByhjVcCAwogCMrP3dq9JYeGRVOHRYL2xRvXuqlekMtsuP1U?= =?us-ascii?Q?fB2XOI/Adb1PO76QJm5sb4UbbtmCwEVAOV5SrbJQ6DGLT9umz0R9n5IsiPlB?= =?us-ascii?Q?orBrgtHqAYnZIfdM7dh+qYqDYEqL+HzdqnIl7ZFQnRh4DiGaKd2EOeUniKGw?= =?us-ascii?Q?W+9xQUNlSx6EcZIw4/7J2eCdcRZCGEMo8cCwBY7Ne/k13uY5Ti49uS3RC0Nv?= =?us-ascii?Q?W2Dygj9YxDqL0YrAnlA4+5P6DS4/RYnf4+yZUiT5tog01UN3TtC8uramjiik?= =?us-ascii?Q?GMCzoBjbS/rpqu4wwfqR4qSTIOuQ8pLW0F6kXQn+tK7z2OFOLab3Q0u1vS+F?= =?us-ascii?Q?W8cZoBnNk1nkpfij4LaMX2gYBBfbXfQ2ECTV8aWmesC7CsONP++DK+ADuMsw?= =?us-ascii?Q?1iXRq6n3Gh3dRTzjYI9t4TWRDPfsEbwYoo7Tlc5jTwibaNvPNFFhY8j6qPn1?= =?us-ascii?Q?NVBKs9ozYUX0DSlz6S3pxIWRL1D87+PIxWlGv1N+fIJAthJBFj2o/EitM5WC?= =?us-ascii?Q?tpQJo6dNGYykA+6g5IAfRzZflQmpuYXNZx/2xsWHlRE11r8Rha9uZ39SxTQB?= =?us-ascii?Q?IRbDdVvdYTHgpz6PAdDAYJmZe7jjhHXOuO7llS1zJ51a4C+9wslGXSIW/EVH?= =?us-ascii?Q?EFxhi659nblq0oi77VIcySO36KDYjq4qvP0J+LotAiAnHat/LsUlzR5af4ie?= =?us-ascii?Q?yi5zAWgJcJzBozPRDPfNjfeA2yf88MKGu+HngiKCsDWPkBsUuLtNdNG2Ej0l?= =?us-ascii?Q?j6GhbeHEPzNWibidiyEN+WO4ve3Y0Hy1iSQH8NwesKFdqIPMYIjkWqk726Fx?= =?us-ascii?Q?nR6AtoosTiXMa0XxgulVmCbsChVkx8/Dfnavu4uQRku+/jWV3f7QAmqu5PS2?= =?us-ascii?Q?7kx/mLWhVZTOnanus+/nts1ek+0tgICEfV9A5VfgC2ONZDqHUR2sFMS5DtX1?= =?us-ascii?Q?NvjQe9Z+aSvdStBKxrfvUW90vI75HuBeSh73Aua73fmSPBZBEy/wmJvP3yHb?= =?us-ascii?Q?ko+jg9o5266bIdTBHY8pDfRwJU65Xy/mMu9mb39OkJPPxJ68d++MIO+TzUTj?= =?us-ascii?Q?JChGvzlS3b6hSk/UHAFAtxBcrFxVZ8l31EzWSUBxpD8osskJrJxz5Pd5OhOm?= =?us-ascii?Q?g9D0WqLIFq4yCZgpMAXPSj0BePQidTsl8/375YbVsskHwRL9GOb4DiduzgU9?= =?us-ascii?Q?BslgxXo0hRNJ7Rus4DEoZ8bWP5ET32s+4Y8ELsi4iZa4FXV1pv27SJkjS5fa?= =?us-ascii?Q?yZZ/Z+UnerQ604Da8Na9u11h?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 4c291e7f-98cb-49ae-0014-08d9417cfe6f X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jul 2021 19:25:35.1019 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: XYOupni3wsQVJrLiMgmpX31L1zkpP230m5EYHyCh8xgxbB4rgybJhlSLvGTrwYFJVMt6zZ8ldfTYpAFK3nNT8wQLog6peAurVjM5U61bhs4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1220 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 19:25:44 -0000 On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote: > > > Inline method is needed, if you want to indicate that the file was > > generated by someone who uses some YANG modules with deviations and some > > features are not-supported. There is no way to indicate feature-support and > > deviations with the simplified-inline method. > > The Inline anydata solution is very heavyweight. > Before the YANG library there was a simple URI that is easier to use > and takes up much less storage. > The inline content schema is super generic since it supports an open ended set of schema defining modules. While you can use it with say ietf-yang-library@2019-01-04, you can use anything else as well. In other words, two implementations supporting inline content schema may not interoperate. I do not think there is a schema format that is mandatory to implement for inline content schema. So here is my assessment of what we have in terms of interoperability: - Simplified-Inline comes with notable restrictions, interoperable - Inline is an open ended content schema, not necessarily interoperable - URI method pushes the problem to another instance file, interoperable - External is by desing not interoperable On the server side, we have YANG Library. Perhaps RFC 8525 has some complexity that is useful for supporting large servers with multiple datastores and not needed for small instance files (I understand that an instance file is always tied to a single datastore?). To me, it feels that reusing RFC 8525 design is actually a good thing. Being able to dump a live server datastore into an instance file seems like a very valid use case to me and ideally this is possible without having to rewrite the schema part. Well, you could go and trim unused datastore schemas and from there unused module sets etc but that can all be done by an external tool trimming the schema part, i.e., it does not need to be done by a tool that just dumps a server datastore. What is the actual value of simplified inline? How much do you really save compared to the simplest equivalent RFC 8525 representation? And does that saving justify to start engineering another schema specification format? I guess my choice would have been to just have +-- content-schema | +-- (content-schema-spec)? | +--: (yang-library) | +--: (uri) but others obviously want much more choice (but lets note that everything sits in a choice, so everything is extensible in case other schema definition formats are out there). /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 Jul 8 02:10:59 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19133A1899 for ; Thu, 8 Jul 2021 02:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mu8Cjk53FnC8 for ; Thu, 8 Jul 2021 02:10:51 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70053.outbound.protection.outlook.com [40.107.7.53]) (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 C12AF3A1898 for ; Thu, 8 Jul 2021 02:10:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N5xwsIRN9ztF1wXfTmz35yoLtIctgjy/5gwiUipbLpgkX5xmThCyFfE9IXfTbizqFS3PIz1VGw4Gbsbr4QRGU+eqMe7HGFB3moycKpyg4f1cXkbHhcIMnE6FcjU4/K3Y3yB4Cwi6CX4sgjgIFQyznoIf1AS69ityGJJ1oE5f/SKFKefLmRFN2UabN0Ck1TLDHm+TG2YCbEv9WT12EHMvanoDvFiuk/7GhCGkVolpICi/btcqT+s7aYxlct1Ov5zECJMJSvcsGxi5yEiDVzfsgxwviDHbW+/m8k5PHc8kvPIkn2vUk+QGMfRqldRgqTzUIjrZU3YRgFGQlunyFkckog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9fj1VfWflUk2DzIE8wB6J68QSLxFsvRLsHKGFXEQVNc=; b=LYwxJvccAYAMv1pChCp4B5MQEtos6StG907qxrVY0BZB8rKDPg+iTXZEm6A5dILSxJxkaWM/AEH5K7DpXhNnO6iwhxlpKWydM3uM9F7630yQHv6rdwvCf9TuRHNrqZ1jmmLeTVhgRnx4oCeqOJZwk3weDX9ueL3MvtzXU7ICj5I3EPGYRusIFlVVEG99EvTRLKCGx6XM0yDujXIjE3+hmX9xKvQiilYE7xTBTqw1u7f7O22ZNnS0wN1Zs3utdgh5jTiVyRaPyRxrJDPgJc622zQZNXF8pjfb1M9KCfFa0as/wGGiwcW8FGkGrCKirDtR4rBIpwuVE9I/V3eEir6KJg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9fj1VfWflUk2DzIE8wB6J68QSLxFsvRLsHKGFXEQVNc=; b=dd47hjXqqrnnC/J5itpbC0AG7Ft1/CjZjF0BHCuv6VgmBaV7RtIymkBFyvgmNAGINydTXVec6F40+hn921EzV0/I5MSamYgOMkPfMweS1YY7SJy4pPZ0vv5jFjPpUt4Rt2UWllWhSM/ufLYMO7AfZLesU15bwm/GkFCd/CpN2EA= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8146.eurprd07.prod.outlook.com (2603:10a6:20b:321::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.11; Thu, 8 Jul 2021 09:10:47 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4308.018; Thu, 8 Jul 2021 09:10:47 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Andy Bierman CC: Juergen Schoenwaelder , "Rob Wilton (rwilton)" , "netmod@ietf.org" , Benoit Claise Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAPXLWAAAIT0wAAAIMhAAAAy2eAAAJlLwAAGf35QAAVpNcAAB8HnHA= Date: Thu, 8 Jul 2021 09:10:47 +0000 Message-ID: References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; yumaworks.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 14f9de41-1786-42ea-dee2-08d941f04630 x-ms-traffictypediagnostic: AM8PR07MB8146: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: skZTFnFQgpf/jZwpvSAb4UdjzOMEMU0gWpSrPT5Pp9M8qwWPOpd3R+7yZ6zXhSqTRD7OBp1pnUxEi9KWd4NFI4uDdjiqBNVRv/FuS8WCXL/3uk7RMURxLPVWRWyCmzKPtZwarzclCtsoZ9d3f4VWweMsvB/oRxoWTtJ4JTtpqz6R2Tcb8N4/a5j2/WrzNfEBXRcSSYyLJVjl0nJkQzPro/Ds7SF+8XLCq3Xw1WPAgMmdVSP5cgFAWqUMLBpuG6qgJEUUjPAblGmtnYkrxoHque6eK40vqU2WqPAeNbEdnsjDiDpTxbfs1D9luvZ7q1kpydgLC+kL5LPpREjm3mCaCNP7+pYjx0yOrhp3W0BftjClWGDY2aB0lU8SQ8FmUn0yUqXOcecha7/EKC8kph25N6LG4LuaDdNB/VCIAWWGP2W29rSVoSQlHL1qSVPAgRG4Sq0fpSL5dQK/8hOPzKzGoeHom+64q8UejaJDuOMEzJdjNt+X4uOKeZRaIiuSl1UmDm1/9g+HfnDAonIqTOjA0aJsClH8PpOSZMhvyNB1K8ZyXsXSs9QKdI5JU5iL02TKB8r8RynH309Lf/4Ls3sCBrZrmc4dnF31xHWNMl+m9d2HQo8fAxe6bP/F4Cj5utYDzhjTi7WGLAuJIYejHWxrgAVjT7Ov/C/kVT0OOY1a4RlopHTnnn5C/fdGY9aSXSfqNfAhoRyhb/3dP6QV4nfhmJQri10qe40n9RsYZGc7FWKOe/RID0aF//l2LEGtu8fC5iCRivNxcMXPWVi+DdVqLQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(346002)(39860400002)(376002)(366004)(396003)(86362001)(9686003)(38100700002)(52536014)(85182001)(33656002)(85202003)(4326008)(66574015)(66616009)(66556008)(2906002)(6506007)(64756008)(66946007)(5660300002)(26005)(186003)(166002)(316002)(478600001)(9326002)(54906003)(71200400001)(83380400001)(66446008)(55016002)(76116006)(8676002)(8936002)(66476007)(7696005)(966005)(6916009)(53546011)(99936003)(122000001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WWlmNnhNQXJjbjNia3l2d0F6empHdFZUZG1BVDFNaC9WbXJpMnZGUHpuMWJa?= =?utf-8?B?aDFNREZhUTQyZGpMdktqMFZYQno0b1M3OWtaZEhDZEh0b0YvQm1qeWFHeXJ0?= =?utf-8?B?L0pwc3R1S2ZkTjJSZFZOSEgzTzlwcTZKdzlwWjc1RUV1Y09Bc3lYTXQ5c3dk?= =?utf-8?B?ODBkZjJvaHlXWGRkSkpnU25Yd0FFYlFhTlJqRE5ZMXY1eEl6N2hBQ2FENmVr?= =?utf-8?B?WjNwZUduUWtXOXRScmtkdkxXWjFtcGVIbndZUGEzQXBsOUZXc0FqbmJ2R2Zx?= =?utf-8?B?elVRU0FaMmhwNXN1ZlYzbG5IaGhDbkFaWkdpUWNXbk9nTWJsTjBTaUJDSnB4?= =?utf-8?B?b3RLRzBhTDladFVSL0IvS0NpQnczTFJhWHdPenN6ei8zQklBRHFscUY1VVNa?= =?utf-8?B?dk5uUUtzd2xSNmJnZVROTWZaamtCSjlRQklSSFJhb280UldEZGUwR3JoOW9Q?= =?utf-8?B?aWdDNlBTUStEYjRIdmw5TklXQ1Nmbk83YS8zck9JMm5taUNGSjJDM2VabFp2?= =?utf-8?B?bmpZc09oZ3FrakFISHdDbGdzNzFsQjdoc013Z3A2OGNvbWg1eVQ2dVN6Ylhi?= =?utf-8?B?OVhuUzZnbGNmTUQwbVdyb1l4cVFvRGdvZEZFeUNsMVBYV0RWTUJLdDJ4SEU2?= =?utf-8?B?Nmo4UTBoZUtWSXpiYStnaGRzelNPelV5ck0xWVRKZEhtdUxtaHZHd2w4SHlO?= =?utf-8?B?dWN4VUoydzRzMlVtV2d4Q3pNOUVrdzdjRWM3ek1QUVcwS1VUVUx3TEI5YlFU?= =?utf-8?B?ai8zZVcybXF5dk02OGxVM2JrbmIvNzl1R2RTeEFDaWZFUFQxaFBHSWROTE9v?= =?utf-8?B?eFV4aTBRQkpMRkdQbFV1SlJPNFE4MW9sS1pONVB5VFljOUoybnVFVVJkREFa?= =?utf-8?B?b05TRUlJOGMzSS9qVzJwREJrTlpJeTZkS21zN015Q1F3SGp5ZW1ibERLeitj?= =?utf-8?B?aVhKVEI2dHlQVEdDdU5FZlZmTngzZlBVa2w3bzZkU1lrcnV1RS9DQUp4d1FN?= =?utf-8?B?cW5ldThVcHp3ek1TTk1oN0kzd1VXYmZiWUtrMldNNTdhK0hUSHAyc202N2pu?= =?utf-8?B?RFcydDd6REVZMDRqVHdrUnM5cVZ6a1pkdllKakloRFhRZFJheERGbTBWY2pL?= =?utf-8?B?Lzgza0VpMzh6VEM2b2s0YkRKVC9YZmRCaUNaTEpHaXlmVlhHMlQ2bFFqRTJV?= =?utf-8?B?UGtOanBudis5MXhEQ0JxcWRrb3RGeGVEZjNmS2tWK2VnMXIwNVVqRENuUjFm?= =?utf-8?B?Z3hQS04rR3VvbU1VWXQ1VDVDT2tpbUJKT1l1RHNnY2Nta1I1NCtPQisreVBG?= =?utf-8?B?a0NtdFYzUWZkZFZwWGZtMnNCNEtsd1VkZUYyR2ZlczZRY1phZURrb21CNUo5?= =?utf-8?B?SGVtNmptMldWa3BZUk9lZGgwU3ZqNThRakxrM0cwTlFNQjVIRmlkcVdiV091?= =?utf-8?B?V1MrWXRSaVp4SWR3ZVFBelQvK1VtTThCZnMzcG9qNksvemRoWFZMVEcveXZO?= =?utf-8?B?bEVvTHY1QmZlcDgvVHh1dG14ZG5NZzNMWFQvRnZRR0RIb1hwcU15UE5GeVpa?= =?utf-8?B?SWVMSlNVLyt4Z1dwbHZwNFdsWm9JZzdmQlZmSm9ZY0Q2d0NMeUlLWU9NV0NG?= =?utf-8?B?Kys0NTcrRklUTDE3TWNOOEluZkNLRzJVbExkQWpTR09jd3ZZbEZzR1FuaVBn?= =?utf-8?B?eVNWMzRsNkFFVm54SkliRC95YktYSzNKK2x1K3F2SklVdTcrNU9nRTBsZ3JU?= =?utf-8?Q?ksWaaYOANNhdhLvalBOuE1Vuq8M1kaXqkqWXzz7?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_043E_01D773E9.E6490BC0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 14f9de41-1786-42ea-dee2-08d941f04630 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2021 09:10:47.4214 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UN64jSJxOcsvIUejcluEgv2Fq4EvKnqzoOyGFR/gm17ioCiqfvVapg7WDN+6oJDbkagCJhOwoXZMnEENTnNkn+bBNyZZzKDTpybVC/fndZY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8146 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 09:10:57 -0000 ------=_NextPart_000_043E_01D773E9.E6490BC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_043F_01D773E9.E6490BC0" ------=_NextPart_001_043F_01D773E9.E6490BC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, * Inline is needed because you might want to specify dozens of YANG = modules with all their features and deviations. That is a lot of = information, so yes it will take some effort to read and understand it; = real life nodes do contain many YAMs, features, deviations.=20 * Simplified-inline is needed, because it is self-contained and often an = instance data set only contains info for 1 or 2 YANG modules without = deviations or feature issues * URL is required because it is self-describing at least via reference. = It might describe big, complicated schemas with a single URI. Most = useful when many files with the same complex schema are processed.=20 * External method is needed because in many environments the schema is = already known, so it does not need to be included =20 The workgroup has agreed that all 4 methods are needed for some = use-cases. We can restart that debate, but I hope not. =20 Regards Balazs =20 From: Andy Bierman =20 Sent: 2021. j=C3=BAlius 7., szerda 20:12 To: Bal=C3=A1zs Lengyel Cc: Juergen Schoenwaelder ; Rob = Wilton (rwilton) ; netmod@ietf.org; Benoit Claise = Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format =20 =20 =20 On Wed, Jul 7, 2021 at 1:01 AM Bal=C3=A1zs Lengyel = > = wrote: Hello Andy, There are many different use-cases for instance-data-files, each with = slightly different requirements.=20 =20 =20 I don't agree that the solution requires 3 ways to do the same thing. Well, 4 if you count External which means Proprietary and Not Standard = At All. =20 Inline method is needed, if you want to indicate that the file was = generated by someone who uses some YANG modules with deviations and some = features are not-supported. There is no way to indicate feature-support = and deviations with the simplified-inline method. =20 =20 The Inline anydata solution is very heavyweight. Before the YANG library there was a simple URI that is easier to use and takes up much less storage. =20 =20 The URL method was requested for the use-case when you generate = instance-data-sets repeatedly e.g. every minute with the same schema. = You don=E2=80=99t want to include the content-schema in every file, so = you just include a single URL reference. (Note the content schema may be = a longer piece of text, not just a single YANG module+revision) =20 The solution is very complex and it will not get implemented correctly, = or at all. IMO this damages interoperability and prevents some companies from using = the solution at all, because a reader tool has so much complexity to implement. The = real-world result will be tools that can only read the files they wrote (not written by = another tool). =20 =20 Regards Balazs =20 =20 Andy =20 From: Andy Bierman >=20 Sent: 2021. j=C3=BAlius 6., kedd 21:28 To: Juergen Schoenwaelder >; Andy Bierman = >; Rob Wilton (rwilton) = >; Bal=C3=A1zs Lengyel = >; = netmod@ietf.org ; Benoit Claise = > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format =20 =20 =20 On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder = > wrote: On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote: > On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de = > wrote: >=20 > > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote: > > > > > > IMO the 4 separate ways to identify the schema are 3 too many, but = that > > > is what the WG wants. It seems obvious that any reader of the = file > > > has to implement all 4 methods and any writer of the file is free = to pick > > > just one. > > > So the feature does not really help. > > > > > > > The feature statements declare that implementation won't work > > together. Back in a day, the IETF was all about interoperability = (and > > implementation costs). Nowadays we seem to be fine if = implementations > > declare that they won't work together. Well, still slightly better > > than having implementations fail arbitrarity. > > > > >=20 > This is a text file stored on a USB stick. > There is no client or server. Just readers and writers. > So how does a YANG feature work here? > The reader is supposed to know how to find out if this feature is set > before opening the file? > > I don't see how server capabilities discovery is relevant to a > YANG instance file. > The reader code will simply attempt to read the file and fail if it > encounters > a format that is not implemented. I assumed that the features are carried in the instance file, i.e., the file declares that it uses way X to announce the schema and then the parser can fail with a suitable error message. If the features are not carried in the file, then they indeed seem to be useless. Perhaps there are Y different ways to announce the features of the instance file as well, I did not check. ;-) =20 Now you made re-read the entire draft :-( I cannot find any text how the reader knows if this feature is set = before reading the file and finding out. =20 I do not see any significant use-case for the Inline method and none for = the Uri method. Nor do I see any reason why the Simplified-Inline method should not be = mandatory to use and always present. =20 If the use-case is offline server validation then the YANG library = details need to be known. The entire YANG library for the server (or relevant parts) are recorded = in the Inline method. Except it is complicated to store the info about how to interpret YANG = schema by reading instance files and guessing what the "anydata" contains. =20 I actually prefer a simple string based on RFC 6020 URI method, since it = can be easily integrated into the Simplified Inline form and can be parsed = without guessing anything about the contents of anydata. =20 https://datatracker.ietf.org/doc/html/rfc6020#section-5.6.4 =20 e,g, =20 OLD: case simplified-inline { leaf-list module { type module-with-revision-date; ... } } =20 NEW: =20 case simplified-inline { leaf-list module { type union { type module-with-revision-date; type string; } ... } } =20 Example module leaf-list entry: =20 = ietf-interfaces?revision=3D2018-02-20&features=3Dif-mib,arbitrary-names&d= eviations=3Dacme-deviations =20 =20 IMO Simplified Inline SHOULD be the only format, and the other methods = can be removed. =20 =20 /js =20 =20 Andy =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 > ------=_NextPart_001_043F_01D773E9.E6490BC0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello,

  • Inline is needed = because you might want to specify dozens of YANG modules with all their = features and deviations. That is a lot of information, =C2=A0so yes it = will take some effort to read and understand it; real life nodes do = contain many YAMs, features, deviations.
  • Simplified-inline is needed, because it is self-contained and = often an instance data set only contains info for 1 or 2 YANG modules = without deviations or feature issues
  • URL is required because it is self-describing at least via = reference. It might describe big, complicated schemas with a single URI. = Most useful when many files with the same complex schema are processed. =
  • External method is = needed because in many environments the schema is already known, so it = does not need to be included

 

The = workgroup has agreed that all 4 methods are needed for some use-cases. = We can restart that debate, but I hope not.

 

Regards = Balazs

 

From: Andy Bierman = <andy@yumaworks.com>
Sent: 2021. j=C3=BAlius 7., szerda = 20:12
To: Bal=C3=A1zs Lengyel = <balazs.lengyel@ericsson.com>
Cc: Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de>; Rob Wilton (rwilton) = <rwilton@cisco.com>; netmod@ietf.org; Benoit Claise = <benoit.claise@huawei.com>
Subject: Re: AD review of = draft-ietf-netmod-yang-instance-file-format

 

 

 

On = Wed, Jul 7, 2021 at 1:01 AM Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com> = wrote:

Hello = Andy,

There are = many different use-cases for instance-data-files, each with slightly = different requirements.

 <= /o:p>

 

I = don't agree that the solution requires 3 ways to do the same = thing.

Well, 4 if you = count External which means Proprietary and Not Standard At = All.

 

Inline = method is needed, if you want to indicate that the file was generated by = someone who uses some YANG modules with deviations and some features are = not-supported. There is no way to indicate feature-support and = deviations with the simplified-inline method.

 <= /o:p>

 

The Inline anydata solution is very = heavyweight.

Before the = YANG library there was a simple URI that is easier to = use

and takes up much less = storage.

 

 

The URL = method was requested for the use-case when you generate = instance-data-sets repeatedly e.g. every minute with the same schema. = You don=E2=80=99t want to include the content-schema in every file, so = you just include a single URL reference. (Note the content schema may be = a longer piece of text, not just a single YANG = module+revision)

 

The solution is very complex and it will not get = implemented correctly, or at all.

IMO this damages interoperability and prevents some = companies from using the solution

at all, because a reader tool has so much complexity = to implement.  The real-world result

will be tools that can only read the files they wrote = (not written by another tool).

 

 

Regards = Balazs

 <= /o:p>

 

Andy

 

From:= Andy Bierman <andy@yumaworks.com>
Sent: 2021. = j=C3=BAlius 6., kedd 21:28
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; Andy = Bierman <andy@yumaworks.com>; Rob Wilton (rwilton) = <rwilton@cisco.com>; Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>; netmod@ietf.org; = Benoit Claise <benoit.claise@huawei.com>
Subject: = Re: AD review of = draft-ietf-netmod-yang-instance-file-format

 <= /o:p>

 <= /o:p>

 <= /o:p>

On Tue, Jul = 6, 2021 at 11:19 AM Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> = wrote:

On Tue, Jul 06, = 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> On Tue, Jul 6, = 2021 at 10:42 AM Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> = wrote:
>
> > On Tue, Jul 06, 2021 at 09:42:39AM -0700, = Andy Bierman wrote:
> > >
> > > IMO the 4 = separate ways to identify the schema are 3 too many, but that
> = > > is what the WG wants.  It seems obvious that any reader = of the file
> > > has to implement all 4 methods and any = writer of the file is free to pick
> > > just one.
> = > > So the feature does not really help.
> > >
> = >
> > The feature statements declare that implementation = won't work
> > together. Back in a day, the IETF was all about = interoperability (and
> > implementation costs). Nowadays we = seem to be fine if implementations
> > declare that they won't = work together. Well, still slightly better
> > than having = implementations fail arbitrarity.
> >
> >
> =
> This is a text file stored on a USB stick.
> There is no = client or server. Just readers and writers.
> So how does a YANG = feature work here?
> The reader is supposed to know how to find = out if this feature is set
> before opening the = file?
>
> I don't see how server capabilities discovery is = relevant to a
> YANG instance file.
> The reader code will = simply attempt to read the file and fail if it
> = encounters
> a format that is not implemented.

I assumed = that the features are carried in the instance file, i.e.,
the file = declares that it uses way X to announce the schema and then
the = parser can fail with a suitable error message. If the features = are
not carried in the file, then they indeed seem to be = useless.

Perhaps there are Y different ways to announce the = features of the
instance file as well, I did not check. = ;-)

 <= /o:p>

Now you = made re-read the entire draft :-(

I cannot = find any text how the reader knows if this feature is set before reading = the

file and = finding out.

 <= /o:p>

I do not = see any significant use-case for the Inline method and none for the Uri = method.

Nor do I = see any reason why the Simplified-Inline method should not be = mandatory

to use and = always present.

 <= /o:p>

If the = use-case is offline server validation then the YANG library details need = to be known.

The entire = YANG library for the server (or relevant parts) are recorded in the = Inline method.

Except it = is complicated to store the info about how to interpret YANG schema = by

reading = instance files and guessing what the "anydata" = contains.

 <= /o:p>

I actually = prefer a simple string based on RFC 6020 URI method, since it = can

be easily = integrated into the Simplified Inline form and can be parsed without = guessing

anything = about the contents of anydata.

 <= /o:p>

 <= /o:p>

e,g,

 <= /o:p>

OLD:

  =        case simplified-inline {
    =            leaf-list module {
  =                 type = module-with-revision-date;

  =                 = ...

  =               = }

  =         }

 <= /o:p>

NEW:

 <= /o:p>

  =        case simplified-inline {
    =            leaf-list module {
  =                 type union = {

  =                     =  type module-with-revision-date;

  =                     =  type string;

  =                 =  }

  =                 =  ...

  =               = }

  =         }

 <= /o:p>

Example = module leaf-list entry:

 <= /o:p>

  =     =  ietf-interfaces?revision=3D2018-02-20&features=3Dif-mib,arbitra= ry-names&deviations=3Dacme-deviations

 <= /o:p>

 <= /o:p>

IMO = Simplified Inline SHOULD be the only format, and the other methods can = be removed.

 <= /o:p>

 <= /o:p>

/js

 <= /o:p>

 <= /o:p>

Andy

 <= /o:p>

 <= /o:p>


-- =
Juergen Schoenwaelder           Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587      =    Campus Ring 1 | 28759 Bremen | Germany
Fax:  =  +49 421 200 3103         <https://www.jacobs-university.de/>

------=_NextPart_001_043F_01D773E9.E6490BC0-- ------=_NextPart_000_043E_01D773E9.E6490BC0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDcwODA5MTA0NVowIwYJKoZIhvcNAQkEMRYEFFhurip7+etX FWXQ9DLki2da3VXJMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAEdR EZ6nTQt6TMPn2Nv2AFh2Kzaocxum2DbcdrqgCqWUCklngF44agEjBBf2e1iYpc4vbgdI/daaHjaW SroE6lLA2kjESTo4SHcXVGYV1nDgMzFkl5ODYrMulA7fPR1ruwBwOeOc2EZxMyj1IT6kz+A4YuPk zxc3wUWm4MD0zXwWlFU9EvsA1/HBBObg7CCAOo0LeF5vPYhdMkXJTypJhPXIDnTU8DNn1lid/RBo 0o4UcFY6LB/a2Ui/WtR/mWphwZqLzAASsBZIcGst25M71zar3LgngrQAfQjZtfH7llq+fmeja4sA Zp+t+msvmQSfPwRwMBQksfHIe/r9zWhg818AAAAAAAA= ------=_NextPart_000_043E_01D773E9.E6490BC0-- From nobody Thu Jul 8 02:17:20 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45683A18F8 for ; Thu, 8 Jul 2021 02:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO18-sYpYByz for ; Thu, 8 Jul 2021 02:17:12 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on062f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::62f]) (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 EF3553A18F4 for ; Thu, 8 Jul 2021 02:17:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Lio07PyW7ox/rcodeXB9GtgeX8djNO17M9dqH/1V1FvBMTwu3kYqBioqJcRdE6U6sQBdsemyLbRdZXlPPuSgSggcbzMX9OYJ32ZXwBdg2Rg1Y0Q3DGkTUofvFPIaDpn5lnNhgXtfotMr+ANaY+I3SukTk3nczAgqX9OHXSTRB02VmugCrvwXlfqRvKL+s+MRbktbZgoLNmsI56OHJ8gy37prfj5nWZaBRiG2a6/7WPnJjk/Fk57kIVdMoVAInNALLiLzwcULhTz/tr+jHfgWf6+CGSxja66SQb2apXVhVPZa5Am3NRxlQWWIgbNUZw0dw7YGp1UZIoW7ZenQbt5tFg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=d6geUebnIGBEiOc+OTnE66xFQfZatdXS3HEe1uSdPmo=; b=cCxX8cD4yvfFxHgyrf8brFZnWJ83+8AFe2dYizR6W59lEjWZcMGWoI/KYBaqz6WByNui8+ObTwjAhZULeJqCgYdZj6PoWh4LWE5GiuhXYvIyhO+20CoPIYSP86+bV50kmaqYsdzPrnETmnbY1ikm8vWPLiL0R3ETOKKlDiqnt8/jtz8qLU/wpVcbg/BGQ376QLOAv/MudghC+zm1lOCVD4Pzj3vME9WkTNoea9pRVRgEEiGeEZeUYD0jjdMiHZ+yuxmycgm5Q80DnooPkTXTEaj+rf+5DZAUQcptgaqK5eU9K8WayU1jsNYgWKPz4Y4imd9UhVsIPjjVY7ZusArKPA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=d6geUebnIGBEiOc+OTnE66xFQfZatdXS3HEe1uSdPmo=; b=DgiTGsHifbSra0gjN4FVZiXIQOM79ASew5qjDgWmr+iNOiQvtvjdvItS1evelXInQeQrD9iwuDOrhQzDts+2Vy0GPITjRbuGklRVDA+nhIEisfacJP11EF5AJlTY9c2hetC3erv23QxTqf0Msy66/TbumhhwBZ/VFa3M3P/HWiQ= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.17; Thu, 8 Jul 2021 09:17:01 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4308.018; Thu, 8 Jul 2021 09:17:01 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Andy Bierman CC: Juergen Schoenwaelder , "Rob Wilton (rwilton)" , "netmod@ietf.org" , Benoit Claise Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAPXLWAAAIT0wAAAIMhAAAAy2eAAAJlLwAAGf35QAAW9oAAAB4Up2A= Date: Thu, 8 Jul 2021 09:17:01 +0000 Message-ID: References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; yumaworks.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1ff91b87-9d88-49dd-e67e-08d941f1250d x-ms-traffictypediagnostic: AM8PR07MB8230: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dzou2mLvTV4/oRD7NI6M/hiVDWaTkp8UEGWAmjd4gO7rJnaDVg4Is6zseH9e5s3aTbviWOXyihCIiOz6WLxo2DA7OFNZ45V21DVUUlOwoiPx5rpi+QuRhbFBs/g2j1ARNnr8YSQJiDGuUsRxAhzdCUp5MjAss8FaMx/RlzzO17avwhGtSaCLPjYXcz7jL4qAr4gUZdI1BYFry2hVEHuCYdgs4z8Wc7bD/k2HLmF8PfWQ7SBFMAUW2fwGgtRXSIk8COA75jsnxhn/5Gom+JlOnCmDKjNW3OovcZfCppkWEwdnxhF1fyfhcqlugFiIrEeW7HODnK9SeEisQxljHIztTCj5SHKJMb2n1dqUO39ubQJbE1t3O0nUPXYBNHEH4MZkHQkwo9e+/qJz0B48qHVmXtP8Rne8ub5NS1Bk45O9khWRM7OSUcjo/cDOKGRJDiYRTKKIHrtf0KrZESbQM4YU50qXqRV/ua65U0lGdMvAltkhiUCVv3QkhcGLpReRMPQ5GVciYCJV7Z3LeRaOUYITGXA1HPpajCPLChDUZG4XCTM495+JWQy1BWrPDJIU4W4rR9nU/03Txh8RD+wjBkriv1hAdq47eDp7yTmYmYIBU8jon7Gx4mf8yU734L0lYTN3gjGzmYhE1zpJ5lqnIVw2gRTVh25XkpaNPvw3NeLmEMUz7CPx2taNMx52X7QiwgWQ1x3ik74InzVOZ3H4IB6GltfDRgfEd4SM8p8jhidT47HAqOy7NxsG2THV1Qcxx+tLp2XzCaIkLjH/cLFPjua8Bg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(39860400002)(346002)(376002)(396003)(66476007)(99936003)(66616009)(53546011)(54906003)(66946007)(122000001)(66446008)(4326008)(5660300002)(9686003)(7696005)(166002)(76116006)(33656002)(6506007)(966005)(71200400001)(6916009)(52536014)(8936002)(186003)(316002)(85182001)(55016002)(2906002)(86362001)(478600001)(85202003)(26005)(83380400001)(8676002)(38100700002)(66574015)(66556008)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?QTJ6OG9zOTNud2FlWnVoU1gxVG9mUzRtdHdyRTJkK2loTnNrallMRFlOdlhi?= =?utf-8?B?eEJESGo4Qko3aGxKVmNsb3NUTnIyQU5UREh3ZFJKR205YW5VUXZWenZ5eHlj?= =?utf-8?B?M1dGVnFHME1OWjkzbHdoRG9ISVlRbDN1bjJJVk55SjdUaTE5ZUx5UHpjcDgx?= =?utf-8?B?cHlISzFtaDdDancxdXdKTU9VWDZzRnMwWURiWUJONS9vK0duUnRmSHNlR2Ns?= =?utf-8?B?UVNBRzc0QkJMeUdIL0dFRFZDWVhycUxGMC9mWjBoTm1tWTNhUVRvNSswMUFw?= =?utf-8?B?eittc1dzbGJZcGlXblVDNTYwYkNreXF4cExDNmIvc1RsM0NObW8rRFlUakdR?= =?utf-8?B?REIyRTlEN09WVGZpL0VhRlp0Y3VjRENtaE9VdzdKMERZUFdHdkFyQ1l5K0Vm?= =?utf-8?B?VE94dDNHcGlOUUdsdmRhbWJtakpBWkVwZ1c0dWxGRWNveEt1UForTFZjb3Q1?= =?utf-8?B?Q3U1RmRVOFpQSTRsa3VZRmhlK1dRcy9yRXNQem54SU10SjhETVhjUERpZm1B?= =?utf-8?B?bmEzallqdUlVekxBVTYrT2xSU2hjd1I1WCs3ZHFLTXFsblE2dHpralVrWEh6?= =?utf-8?B?YzNOYlJ6OFo3RmpheElFSHJKaGlYVGRrUy94eVFFd0J1ZFUrMDZCOVNTcHFU?= =?utf-8?B?Q2thUEhMR2I4cEJpQkZIYmZXcTlETktjWFpqTWljNS83M3l5SkRwcExIbmhJ?= =?utf-8?B?dDdwM2ZxaUhvSE1lTTY4NFRuR0ZmcEJIbDByRnlyK1dXcGxXaHJWOUZKUGJt?= =?utf-8?B?UnFYeVNpRmtmam5yYWl1d2lHNndWdGxuWnFCQU02WXhpVUhOYnhBRXJVNXZF?= =?utf-8?B?cTN0ZCs5R3RoenJwbzZYQnpXa2llTDNlNGY1M2d1MTRmNU56Q1NlTDRMWGd2?= =?utf-8?B?Qy8xYi9oZmhwRnY3S1AyZ1gveUNCS2w5SFhRMlNIUnJERVNtWVFIWTZUTXRX?= =?utf-8?B?MEQ2MEYzM0dqbjNUckRqZ1BkTEVIR3pBelB3ZU95V2ZWTHhlajBXUnp2cStq?= =?utf-8?B?NVU2NTN0UDVJYzNaSE5KQVBGVUEvcExra2RWY2puSGx1OUlydlBjdks0bGlV?= =?utf-8?B?STEzRVhVY0FucHE3Q2pseWE2NURrMFlOVXpIZ2F6cHBYZTlUY1M5aUlWdnJB?= =?utf-8?B?M0lzTkM3aElVQ3ZLYnVXWEFua3RIM1hWSy9LdUFDbkdobU4rWW1oWU1LOHZY?= =?utf-8?B?dnhyVDNUeHlad2dVd01vNGx2ZWhuYzY3dWQyQ1ZCc3Q2YzAxOSticVV3S2N4?= =?utf-8?B?RzZOZEllcjhEa093R2FzTzRUU3o0b1VONGk2MUE4WDRHRnNUZXdPWXN6bnBZ?= =?utf-8?B?YkRRZjJ4b2NCZWhmdmtXa2pYRWhIcjBHVHZ5aTd4Tmx1SDRGamFwejZacDcv?= =?utf-8?B?dVkvcGdPRkdUcFkzYkk1eWYweStKMlVzZHRRT0tFWmxUeHVFMm5kWkJuNDg3?= =?utf-8?B?QmNna2lxNGxiTEhmTWVYMm9od0ZwVzRpcEEyUldQUVcwOHBRc01NMWl4cHk2?= =?utf-8?B?c3JtMFJaZ1JtUkdyVjhHWEJZVUdsRUUrM0dGZFdBRUtNMjk0eWJ0bG9hdW85?= =?utf-8?B?blRtVGJ6bkFqS0R0WUFaOEFiUXdGVWxWN1FaTUFWNkdzalN2MkdLaCtmZVl6?= =?utf-8?B?Tk1WbG84dTBrM0pjVjV1SWNqbnNNdGhkL0w4YnZtQlIza1lNSWttb1dUWFBT?= =?utf-8?B?RXlySmJkaXRncTJvMVgrUmEzUmNoWC9WZllheGJHQ2xncWxSckpLeWdIcWV4?= =?utf-8?Q?WK+ZP+akPJDAYcsP5dS7H5VdLvkVBY1gjnLYRF3?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0445_01D773EA.C5149180" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1ff91b87-9d88-49dd-e67e-08d941f1250d X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2021 09:17:01.3222 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vVzbGhsTb9NRKD7fa0mjZ8LgjIqPA2E/ChUfx92dzGY7/xz7ESVJ2D+setchQxCgbMGyNYRenZ3loPWC9fkxl7kQrXuFaeJHQLt0k5YvxYM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8230 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 09:17:19 -0000 ------=_NextPart_000_0445_01D773EA.C5149180 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0446_01D773EA.C5149180" ------=_NextPart_001_0446_01D773EA.C5149180 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable See inline, Balazs =20 From: Andy Bierman =20 Sent: 2021. j=C3=BAlius 7., szerda 20:50 To: Bal=C3=A1zs Lengyel Cc: Juergen Schoenwaelder ; Rob = Wilton (rwilton) ; netmod@ietf.org; Benoit Claise = Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format =20 Hi, =20 I have some questions about the same-schema-as-file leaf: =20 leaf same-schema-as-file { type inet:uri; description "A reference to another YANG instance data file. This instance data file uses the same content schema as the referenced file."; } =20 The type is an unconstrained URI. Is this the intent? The tool that writes the file can pick any scheme - any valid URI at = all. The reader must support every known URI scheme in existence? Is that the = intent here? BALAZS: As the number of URI schemes is growing with new URI schemes = introduced from time to time, that is clearly impossible. On the other = hand, we don=E2=80=99t want to constrain URI schemes. This draft is not = about selecting the best URI schemes for referencing a file, it only = about providing a common format for metadata about instance files. The = set of usable/used URI schemes will have to be communicated using some = other method. You could ask a similar question: does a Netconf client = need to be prepared for any YANG model? No just for the ones he is = interested in. =20 Sec. 4 contains this line: =20 The header part is not security sensitive. =20 Is this really true if a URI is present in this leaf that contains a = username and password in cleartext?=20 BALAZS: Clear text passwords are not the intention. Shall I add a = statement about this to the security considerations? =20 Andy =20 =20 On Wed, Jul 7, 2021 at 1:01 AM Bal=C3=A1zs Lengyel = > = wrote: Hello Andy, There are many different use-cases for instance-data-files, each with = slightly different requirements.=20 =20 Inline method is needed, if you want to indicate that the file was = generated by someone who uses some YANG modules with deviations and some = features are not-supported. There is no way to indicate feature-support = and deviations with the simplified-inline method. =20 The URL method was requested for the use-case when you generate = instance-data-sets repeatedly e.g. every minute with the same schema. = You don=E2=80=99t want to include the content-schema in every file, so = you just include a single URL reference. (Note the content schema may be = a longer piece of text, not just a single YANG module+revision) Regards Balazs =20 From: Andy Bierman >=20 Sent: 2021. j=C3=BAlius 6., kedd 21:28 To: Juergen Schoenwaelder >; Andy Bierman = >; Rob Wilton (rwilton) = >; Bal=C3=A1zs Lengyel = >; = netmod@ietf.org ; Benoit Claise = > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format =20 =20 =20 On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder = > wrote: On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote: > On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de = > wrote: >=20 > > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote: > > > > > > IMO the 4 separate ways to identify the schema are 3 too many, but = that > > > is what the WG wants. It seems obvious that any reader of the = file > > > has to implement all 4 methods and any writer of the file is free = to pick > > > just one. > > > So the feature does not really help. > > > > > > > The feature statements declare that implementation won't work > > together. Back in a day, the IETF was all about interoperability = (and > > implementation costs). Nowadays we seem to be fine if = implementations > > declare that they won't work together. Well, still slightly better > > than having implementations fail arbitrarity. > > > > >=20 > This is a text file stored on a USB stick. > There is no client or server. Just readers and writers. > So how does a YANG feature work here? > The reader is supposed to know how to find out if this feature is set > before opening the file? > > I don't see how server capabilities discovery is relevant to a > YANG instance file. > The reader code will simply attempt to read the file and fail if it > encounters > a format that is not implemented. I assumed that the features are carried in the instance file, i.e., the file declares that it uses way X to announce the schema and then the parser can fail with a suitable error message. If the features are not carried in the file, then they indeed seem to be useless. Perhaps there are Y different ways to announce the features of the instance file as well, I did not check. ;-) =20 Now you made re-read the entire draft :-( I cannot find any text how the reader knows if this feature is set = before reading the file and finding out. =20 I do not see any significant use-case for the Inline method and none for = the Uri method. Nor do I see any reason why the Simplified-Inline method should not be = mandatory to use and always present. =20 If the use-case is offline server validation then the YANG library = details need to be known. The entire YANG library for the server (or relevant parts) are recorded = in the Inline method. Except it is complicated to store the info about how to interpret YANG = schema by reading instance files and guessing what the "anydata" contains. =20 I actually prefer a simple string based on RFC 6020 URI method, since it = can be easily integrated into the Simplified Inline form and can be parsed = without guessing anything about the contents of anydata. =20 https://datatracker.ietf.org/doc/html/rfc6020#section-5.6.4 =20 e,g, =20 OLD: case simplified-inline { leaf-list module { type module-with-revision-date; ... } } =20 NEW: =20 case simplified-inline { leaf-list module { type union { type module-with-revision-date; type string; } ... } } =20 Example module leaf-list entry: =20 = ietf-interfaces?revision=3D2018-02-20&features=3Dif-mib,arbitrary-names&d= eviations=3Dacme-deviations =20 =20 IMO Simplified Inline SHOULD be the only format, and the other methods = can be removed. =20 =20 /js =20 =20 Andy =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 > ------=_NextPart_001_0446_01D773EA.C5149180 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

See inline, = Balazs

 

From: Andy Bierman = <andy@yumaworks.com>
Sent: 2021. j=C3=BAlius 7., szerda = 20:50
To: Bal=C3=A1zs Lengyel = <balazs.lengyel@ericsson.com>
Cc: Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de>; Rob Wilton (rwilton) = <rwilton@cisco.com>; netmod@ietf.org; Benoit Claise = <benoit.claise@huawei.com>
Subject: Re: AD review of = draft-ietf-netmod-yang-instance-file-format

 

Hi,

 

I = have some questions about the same-schema-as-file = leaf:

 

       leaf same-schema-as-file = {
             type = inet:uri;
            =  description
              =  "A reference to another YANG instance data file.
  =               This instance data file = uses the same
                = content schema as the referenced file.";
      =      }

 

The type is an unconstrained = URI.

Is this the = intent?

The tool that = writes the file can pick any scheme - any valid URI at = all.

The reader must = support every known URI scheme in existence? Is that the intent = here?

BALAZS: As the number of URI = schemes is growing with new URI schemes introduced from time to time, = that is clearly impossible. On the other hand, we don=E2=80=99t want to = constrain URI schemes. This draft is not about selecting the best URI = schemes for referencing a file, it only about providing a common format = for metadata about instance files. The set of usable/used URI schemes = will have to be communicated using some other method. You could ask a = similar question: does a Netconf client need to be prepared for any YANG = model? No just for the ones he is interested = in.

 

Sec. 4 contains this line:

 

=C2=A0=C2=A0=C2=A0 The header part is not security =
sensitive.
 

Is this really true if a URI is present in this leaf = that contains a username and password

in cleartext? 

BALAZS: Clear text passwords are not the intention. = Shall I =C2=A0add a statement about this to the security = considerations?

 

Andy

 

 

On = Wed, Jul 7, 2021 at 1:01 AM Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com> wrote:

Hello = Andy,

There are = many different use-cases for instance-data-files, each with slightly = different requirements.

 <= /o:p>

Inline = method is needed, if you want to indicate that the file was generated by = someone who uses some YANG modules with deviations and some features are = not-supported. There is no way to indicate feature-support and = deviations with the simplified-inline method.

 <= /o:p>

The URL = method was requested for the use-case when you generate = instance-data-sets repeatedly e.g. every minute with the same schema. = You don=E2=80=99t want to include the content-schema in every file, so = you just include a single URL reference. (Note the content schema may be = a longer piece of text, not just a single YANG = module+revision)

Regards = Balazs

 <= /o:p>

From:= Andy Bierman <andy@yumaworks.com>
Sent: 2021. = j=C3=BAlius 6., kedd 21:28
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; Andy = Bierman <andy@yumaworks.com>; Rob Wilton (rwilton) = <rwilton@cisco.com>; Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>; netmod@ietf.org; = Benoit Claise <benoit.claise@huawei.com>
Subject: = Re: AD review of = draft-ietf-netmod-yang-instance-file-format

 <= /o:p>

 <= /o:p>

 <= /o:p>

On Tue, Jul = 6, 2021 at 11:19 AM Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> = wrote:

On Tue, Jul 06, = 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> On Tue, Jul 6, = 2021 at 10:42 AM Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> = wrote:
>
> > On Tue, Jul 06, 2021 at 09:42:39AM -0700, = Andy Bierman wrote:
> > >
> > > IMO the 4 = separate ways to identify the schema are 3 too many, but that
> = > > is what the WG wants.  It seems obvious that any reader = of the file
> > > has to implement all 4 methods and any = writer of the file is free to pick
> > > just one.
> = > > So the feature does not really help.
> > >
> = >
> > The feature statements declare that implementation = won't work
> > together. Back in a day, the IETF was all about = interoperability (and
> > implementation costs). Nowadays we = seem to be fine if implementations
> > declare that they won't = work together. Well, still slightly better
> > than having = implementations fail arbitrarity.
> >
> >
> =
> This is a text file stored on a USB stick.
> There is no = client or server. Just readers and writers.
> So how does a YANG = feature work here?
> The reader is supposed to know how to find = out if this feature is set
> before opening the = file?
>
> I don't see how server capabilities discovery is = relevant to a
> YANG instance file.
> The reader code will = simply attempt to read the file and fail if it
> = encounters
> a format that is not implemented.

I assumed = that the features are carried in the instance file, i.e.,
the file = declares that it uses way X to announce the schema and then
the = parser can fail with a suitable error message. If the features = are
not carried in the file, then they indeed seem to be = useless.

Perhaps there are Y different ways to announce the = features of the
instance file as well, I did not check. = ;-)

 <= /o:p>

Now you = made re-read the entire draft :-(

I cannot = find any text how the reader knows if this feature is set before reading = the

file and = finding out.

 <= /o:p>

I do not = see any significant use-case for the Inline method and none for the Uri = method.

Nor do I = see any reason why the Simplified-Inline method should not be = mandatory

to use and = always present.

 <= /o:p>

If the = use-case is offline server validation then the YANG library details need = to be known.

The entire = YANG library for the server (or relevant parts) are recorded in the = Inline method.

Except it = is complicated to store the info about how to interpret YANG schema = by

reading = instance files and guessing what the "anydata" = contains.

 <= /o:p>

I actually = prefer a simple string based on RFC 6020 URI method, since it = can

be easily = integrated into the Simplified Inline form and can be parsed without = guessing

anything = about the contents of anydata.

 <= /o:p>

 <= /o:p>

e,g,

 <= /o:p>

OLD:

  =        case simplified-inline {
    =            leaf-list module {
  =                 type = module-with-revision-date;

  =                 = ...

  =               = }

  =         }

 <= /o:p>

NEW:

 <= /o:p>

  =        case simplified-inline {
    =            leaf-list module {
  =                 type union = {

  =                     =  type module-with-revision-date;

  =                     =  type string;

  =                 =  }

  =                 =  ...

  =               = }

  =         }

 <= /o:p>

Example = module leaf-list entry:

 <= /o:p>

  =     =  ietf-interfaces?revision=3D2018-02-20&features=3Dif-mib,arbitra= ry-names&deviations=3Dacme-deviations

 <= /o:p>

 <= /o:p>

IMO = Simplified Inline SHOULD be the only format, and the other methods can = be removed.

 <= /o:p>

 <= /o:p>

/js

 <= /o:p>

 <= /o:p>

Andy

 <= /o:p>

 <= /o:p>


-- =
Juergen Schoenwaelder           Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587      =    Campus Ring 1 | 28759 Bremen | Germany
Fax:  =  +49 421 200 3103         <https://www.jacobs-university.de/>

------=_NextPart_001_0446_01D773EA.C5149180-- ------=_NextPart_000_0445_01D773EA.C5149180 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDcwODA5MTY1OVowIwYJKoZIhvcNAQkEMRYEFP2Z74fHdwNu mCl58waHGNgODmqnMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAAT6 CNWOH5RX1ygMCQPZzXJ6b9BVslQA4MppPnwOsWK7TSVl5KJUFprsIdUisA1mOAW6T+OJAzQZLmj8 1vwy3Xl+hCpaGj3nPASpuThMSiHEE7iObtTLvI6jAEabZ4cV+YH2TrMvNqcRmqXX4q2fnz24vgV9 rnUgnipss1+d6Gme1IucmiPTd34HKsrAfZXWIS6+6/D/uRtkgiqjayMa2HWsDxytwVlCJQ45Gorx /N4rUD1qgOi1nf2xfoXTbmMsoW2FUwRfJwK9FT3JYOOsYrEDE3+1xKYI+tQDWv7+vXuqIDgUklEe B2BJkypU/66r3P7gePsJKAvGuiq1KJ9Q6IQAAAAAAAA= ------=_NextPart_000_0445_01D773EA.C5149180-- From nobody Thu Jul 8 02:28:05 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A739E3A19CA for ; Thu, 8 Jul 2021 02:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mXZakiS0NP3 for ; Thu, 8 Jul 2021 02:27:57 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40087.outbound.protection.outlook.com [40.107.4.87]) (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 5CC013A19C4 for ; Thu, 8 Jul 2021 02:27:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TFox4bK+25zMrUF7V6muVwM9KMgEkSkvwYiIzvLXev7a5Fg8cd7G98miIoMQNvsYvANDKAZhw9UDDTxu26WCbfjPewKe4/VhvS0AxCVGkul8inTMRsTo04/dwkL//b73cG/gOgZPzABepZQ/FdF6d6m3OdKECcYeHTkthptnnOuzz28qgYbxbW8rwitmedJ6Q470o/LNsDjC0ET+IGTpG9qQldqO55HoAbHOIBPDEDjEgHEEiVSnuRlyVeQ+kaFA5KI+9+l6sTVS32907rJ6Sr9EiNTIGy2kCxlUl4ns/oX27WlaTtbBOlJzpgXizJMV10waPKmuPyBWfZsvOnUAXw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+aqyiMqRZm2OrIq+4t46NkAAOUUgPzD1EKSR9GGoKy4=; b=aMVnG4xwtyYsczDUYD29DHgHz9lnKdX9mY4xtvmz2L30aM1g4CeGkjLVpkeImkvSHKIJqSZPZvMh89hPYUa468Hu5oUd9rDVs2VcJANab8XYy8ddoY+Mju/jPQ9u5CmRX8IegBtGJveGOuNhCH/5sVGobqXoM+qfDiYabvJciEu7WncO+4gqcBtBoOrTkh1nALjAxcA521mAq+OC6Kn6DmEc80MmrmnKxZxScWlCgHcU1T83MK6lTX8SJQA+WsBlMLxbl6m8w378J6ErORhE+4d2i9Jah+t+QTb7F+RwjxVYu4p56jAw1h8GuVfNfPcHyYOYJ9nP6xH5RnofnqbOqw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+aqyiMqRZm2OrIq+4t46NkAAOUUgPzD1EKSR9GGoKy4=; b=aSPjtzADh2E54iWjFh0K4MJcZHp0rcVewLk63a7GzDL/e5vLBqULCHjxaHXFD+bIb3h8fpHPPy1QP/XUp3H911Crw6KXv4fxzK7M5SSnSj6u8D3Rihf+sple+1LCqqQslTJsAOnNSRr+M9VEJ1qD4CvTwxO/S1um/zGJDImC94s= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8146.eurprd07.prod.outlook.com (2603:10a6:20b:321::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.11; Thu, 8 Jul 2021 09:27:53 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4308.018; Thu, 8 Jul 2021 09:27:53 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: Juergen Schoenwaelder , Andy Bierman CC: "Rob Wilton (rwilton)" , "netmod@ietf.org" , Benoit Claise Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAPXLWAAAIT0wAAAIMhAAAAy2eAAAJlLwAAGf35QAAVpNcAAAKQ2AAAHRePIA== Date: Thu, 8 Jul 2021 09:27:52 +0000 Message-ID: References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> <20210707192534.4emim5a36zyqrktc@anna.jacobs.jacobs-university.de> In-Reply-To: <20210707192534.4emim5a36zyqrktc@anna.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 439925fa-78c5-45f6-1e15-08d941f2a974 x-ms-traffictypediagnostic: AM8PR07MB8146: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NWOVULXcriEghmAMPH9bq2MH4N7bVje6HTos5H7/Be/YTMyQLM6xYCpBa+6NaYMxcpaVNoAJuoryOd5T+8mc2nlPRF5olHzY/UTTdvIiwHYIZAOXjqcmum85NHP7cNDsY6VKJQ2rqcARd/fUnbOMv2Q4sZnwFCe6glFsmPazu96BkV6EPGzc5SRJBOUhGNU4cJE7j51Gopa9OI0Ihz9GIcTHcPoky7mHYFLMGcBKeeLvm/Po7tHzdR8CObIdqsiuqJbEa6TPuTvlKsFZDLzs72Zky9phEXbGRGm3ndPgThqBz4BmrJMZvUHtRbJ79QmOpBHl06G88Ia4XFp7hKfP5zWkfbUhxGwld7s9wGvaTQN+EOmv80QsS28k/gxXUNzCtKJ5fdSZQ5Bx5wsxqHs904UPi77tBfyUDi1JUtkYzrbR4duI/Xazp5iEAYRB2eQTotlMj4LlQz8hOx2NXSln1i94jWOYLmQoZaZ40UKgWQwq7ZpXJqvgj/ZEBOuahUZUiMft+c+jFockfa8dRsidxYvjmPTwJEB4wGOiMeYKx654wtUChV8ACtG7J6nJsVHZBuUh1NVDciUK1wPz7P3Xjgl6xCN7vII9Po11P3e3tDbmX/1yHFLfm2WLSVLHlTGgra/OpZbhox7VAeboc50lpIUXuivOudz3W6eev42Gdo7KD7QaAqNjuoMiFD/+95QfT8SwPMj608/SOwDTQiPjGDqbBL4Okfcq1Sb1m3h+HVw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(39860400002)(346002)(136003)(376002)(71200400001)(54906003)(83380400001)(186003)(26005)(316002)(478600001)(66446008)(53546011)(66476007)(7696005)(122000001)(8936002)(99936003)(55016002)(8676002)(76116006)(110136005)(38100700002)(52536014)(86362001)(9686003)(2906002)(6506007)(5660300002)(64756008)(66946007)(33656002)(4326008)(66574015)(66556008)(66616009); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?2ILpMD5CbyvlHEy0LEkVSOTuVJ3o250QTJ7ASIUjsyZLxHBNNQlH8i65KB?= =?iso-8859-1?Q?AMU1iy++giMK7N55AVNJmTF0/D4N9jW/H/EYkcodQgq8FDv9hMpuP4HGnS?= =?iso-8859-1?Q?kfyTFAPnCyHb3Mz2eELhIhbX7g04AB/SppgCpDWI/c1DCKq5j0LYNATk4L?= =?iso-8859-1?Q?yADGeDAJv00Y6KP4DUo29B/Lbx6guCS0D7nQmzuvLQ+qBhJscLCihFrpMu?= =?iso-8859-1?Q?PaMWwYxgRJrZ1KaiaasKvvzjnGU5A2V4Myeug2gO84rW7bvQLisW7/QdIS?= =?iso-8859-1?Q?PmKiN7JITPSLYyKIwDIsdIAuiLGRc0Z+/sHTtNhDcK5pd6hGy3fKfuuAVt?= =?iso-8859-1?Q?ySbO2rYDS+chyDGnAoemy+OsUADecZqbLqyxq4b+ri1chTpZkkQGp7nXpN?= =?iso-8859-1?Q?4RaZCBAOd6oYH37JRUzmlpdeDhICZWXDGjmreys1fMyImZl/cYFTMcOfPU?= =?iso-8859-1?Q?ikPKVrDuraLT0KOy5BkMaisygHYpgMaGoCekg3sBfQFdxm8ofJIGMJXXn7?= =?iso-8859-1?Q?QJEqZH2x2QiVV7dfyq02CmtP9kzEPzZHl6Ev1Y6YBZY/IkRj5ugGKgIoCS?= =?iso-8859-1?Q?OSjsVYh5BFsKrpI2alr63OSfRxTrE392tykBmVuu9ob+nMImC/iItgq2GZ?= =?iso-8859-1?Q?5MvyNR7+sdtt7qKkEcNoGlirCQbKNOnGqMDAkRYZF/bvfWZFCIgtiFQiqa?= =?iso-8859-1?Q?/bz6OBTTR3aU56zyAO/1yexl28O/yYu4uIBR2wvIoJaC6iMZlGCQQJaW6K?= =?iso-8859-1?Q?DYTvuqFhVnMFNPucUVgfbbAt2iW3BbcGz8yKWBrjW6mAmJoqlY723tprTM?= =?iso-8859-1?Q?6k+E207t9qKZHH8Me/CXeDT79V4LYd7ZpE4gcVbKSj/K3Oetcv1qX6n5sc?= =?iso-8859-1?Q?EK/EbOlmAVuxZtNpgndy/Fp8bMAoqEk6WnMsRFEtXXnv7XeVtavHWRKa6u?= =?iso-8859-1?Q?B0Le2q2q2guYQz0g++TTzrOdlxLi+mnxt4Gu8DHpbkzEZDxllRRr2rx60o?= =?iso-8859-1?Q?Kz7hNFdrnxHnuGTMqYKKB6odD/hhar2/7dYoPHYifuGzg3PFYGreyWngNa?= =?iso-8859-1?Q?IEmWN+IHhT8AhQ7TTqUV+g6K42NPEAhKLgveK8mAxApxQyYht4ggP19M2T?= =?iso-8859-1?Q?+h+61uta1UFTaREoFxn6OSRZMT4VKYKtdGzkq5PSR7Py/tcpNyvclRcU3c?= =?iso-8859-1?Q?je4ZN1Sr4hgrduftyJR74WCgh/1vFgJN5yIqLG6MaeWfYalusRuIbcvZB2?= =?iso-8859-1?Q?+86DcI6N3XG81LXR5cINBaSlY6muGLok7BpP4TEcXCaimCaGWj3/uM6/fh?= =?iso-8859-1?Q?ndHQSTusTpe/Kty47cUsj4R9Y+aW81iVdM3KGB+inZEAhem41fFO8L2uci?= =?iso-8859-1?Q?TGfBfvrPfN?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_044C_01D773EC.497AA710" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 439925fa-78c5-45f6-1e15-08d941f2a974 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2021 09:27:52.8853 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: COXXmcwU4C8HBqVUoXbPsps/xwUOI4NdanJFqXTrxAF7P9PjaPCjLiG4bfdJRuklIx1QWJ2/ycCiNcYICIFMaY3GSZy2gUQqmKt3ox+UKec= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8146 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 09:28:03 -0000 ------=_NextPart_000_044C_01D773EC.497AA710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Jurgen, Inline: This complex form of inline was requested and not objected earlier by = other reviewers.=20 Based on Rob's and others' proposal inline will be simplified to use = only ietf-yang-library@2019-01-04 as you suggest. Simplified inline: In Ericsson we already use simplified inline a lot, it is the most = common format.=20 If you are providing data only for one or a few YANG modules and don't = have, don't care about features/deviations it is the easiest, shortest method = to use. Our most common use-case is to provide preconfigured access control = rules for new nodes.=20 When a YANG modeler designs a new module, he immediately provides a set = of NACM rules=20 for the readOnly and the SystemAdmin roles/groups. In this case you only need to specify "ietf-neconf-acm@2012-02-22" No deviations, no features to indicate. Regards Balazs Regards Balazs -----Original Message----- From: Juergen Schoenwaelder =20 Sent: 2021. j=FAlius 7., szerda 21:26 To: Andy Bierman Cc: Bal=E1zs Lengyel ; Rob Wilton (rwilton) ; netmod@ietf.org; Benoit Claise Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote: >=20 > > Inline method is needed, if you want to indicate that the file was=20 > > generated by someone who uses some YANG modules with deviations and=20 > > some features are not-supported. There is no way to indicate=20 > > feature-support and deviations with the simplified-inline method. >=20 > The Inline anydata solution is very heavyweight. > Before the YANG library there was a simple URI that is easier to use=20 > and takes up much less storage. > The inline content schema is super generic since it supports an open = ended set of schema defining modules. While you can use it with say ietf-yang-library@2019-01-04, you can use anything else as well. In = other words, two implementations supporting inline content schema may not interoperate. I do not think there is a schema format that is mandatory = to implement for inline content schema. So here is my assessment of what we have in terms of interoperability: - Simplified-Inline comes with notable restrictions, interoperable - Inline is an open ended content schema, not necessarily interoperable - URI method pushes the problem to another instance file, interoperable - External is by desing not interoperable On the server side, we have YANG Library. Perhaps RFC 8525 has some complexity that is useful for supporting large servers with multiple datastores and not needed for small instance files (I understand that an instance file is always tied to a single datastore?). To me, it feels that reusing RFC 8525 design is actually a good thing. = Being able to dump a live server datastore into an instance file seems like a = very valid use case to me and ideally this is possible without having to = rewrite the schema part. Well, you could go and trim unused datastore schemas = and from there unused module sets etc but that can all be done by an = external tool trimming the schema part, i.e., it does not need to be done by a = tool that just dumps a server datastore. What is the actual value of simplified inline? How much do you really = save compared to the simplest equivalent RFC 8525 representation? And does = that saving justify to start engineering another schema specification format? I guess my choice would have been to just have +-- content-schema | +-- (content-schema-spec)? | +--: (yang-library) | +--: (uri) but others obviously want much more choice (but lets note that = everything sits in a choice, so everything is extensible in case other schema definition formats are out there). /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 ------=_NextPart_000_044C_01D773EC.497AA710 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDcwODA5Mjc1MVowIwYJKoZIhvcNAQkEMRYEFCgHxuv0YV6M Qxf9Lrah4sVtsUCHMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAH7G +qsGMZsIxnJcBAwI89uzLrILiL6lDGtOYb2y8QpOhQEuGok1djpXOnwzCBmDebvwWEzr8r1QwLxo atkhH1FtSrGjix6+1WSvE67MR36Tvb3ZKtfF/aPbFtv89vjehCKh66L6izDmAZGOHMEAMNjLAhQs +TaWJBwFo+F2eGTL78eLWmz0Qsw2Pvj1P4SE28GHj3T+KM7SAoVzRTKNWqQgj1ENnZif7HaziNPo X5Ddi1thoRECd39KCWvg6FsqhYzFNQx2j2v1TggvByJTbNOZttFlwogzmt3g9UUwSg0jLzH97pCz i3lmIL/OBEdsnKhwKWfgJbTOafqGmnpWImYAAAAAAAA= ------=_NextPart_000_044C_01D773EC.497AA710-- From nobody Thu Jul 8 02:30:38 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1DD3A1A02 for ; Thu, 8 Jul 2021 02:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.494 X-Spam-Level: X-Spam-Status: No, score=-9.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=lBFMIGPH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=rW18y19L Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiMXk7kvJTwp for ; Thu, 8 Jul 2021 02:30:32 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD153A19FF for ; Thu, 8 Jul 2021 02:30:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47134; q=dns/txt; s=iport; t=1625736632; x=1626946232; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JjDGACV8YvFQN7+Bl5B2Ar0/j7CSiM7AY7VVZrNS9+c=; b=lBFMIGPHxY339mFpKfmQM9sRngZYNtUdXS6lZBaDrjEGrPLHxSujFMx4 KLN62JG7uyGwOpxk7IgdeK1HvFZLMdZudrDEcHRG4d+mx7KaGF1XE2JUX Q3oNVcP1f6ajGlodDM4Ywj5U9a7xnMKQynbhdaKDkeuqf32FMoUQvbFYS E=; X-IPAS-Result: =?us-ascii?q?A0DOAgCfxOZgl4UNJK1QBwMdAQEBAQkBEgEFBQGCGYEjM?= =?us-ascii?q?FF+WjcxhEiDSAOFOYheA5ongUKBEQNUCwEBAQ0BATARBAEBgx6BNQIXgl8CJ?= =?us-ascii?q?TgTAgQBAQEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBAQEBaIVoDYZFAQEBB?= =?us-ascii?q?BIRChMBASUSAQ0CAgEIEAEEAQEBGAgBBgMCAgIZFxQJCAIEAQ0FCBqCTwGBf?= =?us-ascii?q?lcDLwEOmwABgToCih96gTKBAYIHAQEGBASBSUGDJhiCMgMGBYE1gnuCcVNIA?= =?us-ascii?q?QGGYSccgUlEgViBYYEBPoJiAQECAReBGRMCGhUKDAkRCIJINoIMIoMVCDA2F?= =?us-ascii?q?BMBCgkWAoEFWQElDwYTEQwFKY5tgigjgzKILI0xkhEKgyKKKJQbEoNjkgiQU?= =?us-ascii?q?5V7jC6TSyGEZQIEAgQFAg4BAQaCPiItgS5wFTuCaVAZDlWNKCIMDQmDTjOEY?= =?us-ascii?q?YVKcwIBNQIGAQkBAQMJiAwkCYIYAQE?= IronPort-PHdr: A9a23:bt1+WRWWc35O59d74bFr/SrdAd3V8K0eAWYlg6HPw5pDaKWo5I/lO grU4vA+xFPKXICO7fVChqKWtq37QmUP7N6Ht2xKa51DURIJyKB01wwtCcKIEwv3efjtaSFpE d5DX0R++Hf9Ok9QS47yYlTIqSi06jgfUhz0KQtyILHzHYjfx8S63uy/4dvdeQJN0TG8erh1a h6xqFa5iw== IronPort-HdrOrdr: A9a23:R64yBKgOR1rRAO8344FbqW65WXBQX1p13DAbv31ZSRFFG/FwyP rOoB1L73HJYWgqN03IwerwR5VpQRvnhPlICPoqTMmftWjdySWVxeRZjbcKrAeQYBEWmtQtsJ uINpIOdOEYbmIKzPoSgjPIaerIqePvmMvD6IuurAYOcegpUdAc0+4TMHf8LqQCfng/OXNPLu vk2iMonUvFRV0nKuCAQlUVVenKoNPG0Lj8ZwQdOhIh4A6SyRu19b/TCXGjr1cjegIK5Y1n3X nOkgT/6Knmmeq80AXg22ja6IkTsMf9y+FEGNeHhqEuW3bRY0eTFcZcso+5zXQISdKUmREXeR 730lEd1vFImjbsl6eO0ELQMkfboW4TAjTZuC6laDPY0LzErXQBepF8bUYzSGqF16Lm1+sMip 6jlljpxKZ/HFfOmj/w6MPPUAwvnk2ooWA6mepWlHBHV5ACAYUh57D30XklWKvoJhiKo7zP0d Mee/309bJTaxeXfnrZtm5gzJilWWkyBA6PRgwHttaO2zZbkXhlxw9ArfZv0kso5dY4Ud1J9u 7EOqNnmPVHSdIXd7t0AKMETdGsAmLATBrQOCaZIEjhFqsAJ3XRwqSHrYndJNvaMaDg6aFC16 gpfGkowFLaSnief/Fmhqc7gCwlaF/NKQjQ9g== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,222,1620691200"; d="scan'208,217";a="745706293" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jul 2021 09:30:30 +0000 Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 1689UUqC001273 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 8 Jul 2021 09:30:30 GMT Received: from xfe-aln-005.cisco.com (173.37.135.125) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 8 Jul 2021 04:30:30 -0500 Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 8 Jul 2021 04:30:30 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 8 Jul 2021 05:30:29 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bvRAQof5GSDCQssWzUJdg8nACKeNDi6UcIebJ2+jAoq6OUrupi6V2XNjMBVLBFSUff2dWvuI+im7tdbsnwjxdO/dUooui+qrJbepiHlaEWRk41OW4pdbc7YhlNkt58mjCMoawp4ZSVNyN22IVzc6xJqnUU4Lc5gNNBQa9d5HJb/H4aMvs9RyTFi7bET1pdci/0utnIQP7h80QHAb6txI9R2O/OpXK32x88/AhyysANhqMFfdOm8KRayFQOK8uJnTlM0O3uKr5TdHYtFluv2nuHumIqzmMSJ19S/8X1ZqMrrvXG7+H8kz+ISAZWcGgqIxfBIiNkKwwxY1GGfdwpW9PA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JjDGACV8YvFQN7+Bl5B2Ar0/j7CSiM7AY7VVZrNS9+c=; b=awUClFYo/xd3R9rIN7mDBjeLXyY+AzYjFx1h23gn+sBWtnY7MeYUm71JbrG7JhYNV0VZbYjiqoeCKzDyt7nZK/yaE1bHjiV/I7DAjJkuhMqBOsO2oCCRzchs842gzgybTXvQ1uKdUI0nR3WHuN/sSph5UWIeMwTn6LEv7Ntg3REn/LNwKlf9O2I4K+hQEQIVbdLBW4tiUb0L25mBghLgnfPfbIK7ZMdapFTPWsXlRkFK/vBe/Abzbyyv9r4kqu1BDHLlBVk8BI35xTyh2fGFkXqVT3kaGAiZMdXO4c20QXLRKFPadl+wgJo7pDU3osQnDGCiVkmP36FUDFZNllc06A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JjDGACV8YvFQN7+Bl5B2Ar0/j7CSiM7AY7VVZrNS9+c=; b=rW18y19LI1fVakU+iMFtiJYY3XSnKrbUkClaf1GTyqs6GcjvMxQSKUsrcaX+F+4RZcVDtD2b497HOXbxL5Ub3frW1H4up/asubk4UHWi/o6+nNgY4JRi+o8I6kX1Ff0a9I5e69mHH5dLjrxecwdg6FTVtYqdeyY6K96lMYwIo4Y= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM4PR11MB5437.namprd11.prod.outlook.com (2603:10b6:5:398::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.20; Thu, 8 Jul 2021 09:30:28 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12%6]) with mapi id 15.20.4308.021; Thu, 8 Jul 2021 09:30:28 +0000 From: "Rob Wilton (rwilton)" To: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "Andy Bierman" CC: Juergen Schoenwaelder , "netmod@ietf.org" , Benoit Claise Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAPXLWAAAIT0wAAAIMhAAAAy2eAAAJlLwAAGf35QAAW9oAAAB4Up2AAAF8VEA== Date: Thu, 8 Jul 2021 09:30:27 +0000 Message-ID: References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 74c28b5f-23af-48ea-bf6c-08d941f305dd x-ms-traffictypediagnostic: DM4PR11MB5437: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XebPjM6iIDYoSHTHJwUIGUPCp8N9EID1ZYNlcz5x0LowapZjIfP0ZjX8QR2fn+Xv1n+xNBaMfRel7lp88yui0+XJjQPVm3bW/0Q58kt78nriOGWXYypn95kN0i/6nzSMdLguCEWefL6KsH5i+39mWfhC6ldmuBu5vZKP10bh8EZNz8Vm1FJWEZfUlXSCkEtAvC2CJxik6FgEzFC8/ShcUg1BCBKLyoR2NkFdQ0ghqtU5JnNYX7DCweDDWKEsLSpHm1pbZzDJcysm9LNt/GBueTLphcCUGD6kqPj+Sf4/GS4qUzNWjTCxqA2Qkl4ItJ5Ua7ln3PCb+27F7u26cT3TCmtpIZfAujGzJFouCDAPy7SlV2RbY2uFBQe2JrXjXjPzqFYE7Hp8llehZcq/xvMYszQOP0tesTUtj1SsSE/rXyoQagSRhB60djZZALXT4/IFC8hC4gctKo2SDnSUk3vh6ZYLB1g6FcrA9sCDChsg4lSSjigoCgHg9nHPyAr9fNkYxJw8YC4ut2e8UY1jL6AVSnLNfDnjjgkRRp7BduoZO+oAL9HvXTC5fAiklN2DdWMq+t/jCeUz0ODRUbdKxsc3Gsj6HyhTPbYCMrZ8abU7mwQg9uLi5Sy70/qTE1OzeL8/9ETViNTzJaiy0/mXHIAdMJX5pjEh7o7fs1HCifZxcJHh5aYFtQq4HotxA9xD0jTq6rJX4ku52UFY6EsYF+lZ2E6bAhFGot7uveqjPwJ2aSE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(39860400002)(366004)(396003)(376002)(26005)(38100700002)(8936002)(9686003)(316002)(8676002)(66476007)(53546011)(122000001)(76116006)(2906002)(54906003)(66946007)(6506007)(55016002)(52536014)(110136005)(66446008)(66556008)(64756008)(66574015)(33656002)(86362001)(966005)(7696005)(186003)(166002)(83380400001)(4326008)(5660300002)(71200400001)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NVNFMHM0SXhLTHZ4ZkJqcWtvdjlEYkNNdGVlbTlBWE5aZVlTWStMSHdXaks3?= =?utf-8?B?SXVUYlNLUkRLK3k0cnRmSXlCZWdad3JlcnhCakJPaWFDMjNNVGNYdDJwYmY2?= =?utf-8?B?TWpGc3hHeWRKUTBMbWRHRUY3VG5maXJubWJtU1VGZHYraFRXaWtGejBxNjlV?= =?utf-8?B?bzRxd3dnb2tpODk3TU5lY2JiSUQyREpOV056azQrTkNCWDErRW1MMm5haGNC?= =?utf-8?B?TDBFYTcwcHVxVEx6TTdqWjhhQzhwK0M2TEhSMW1aSVRCNDZOVlJqV3RpNDVL?= =?utf-8?B?RHdWNytHRzZQaWlFaFdmOVBpYU9rdEFUenJqYmNPOWZXbVkyQ0hiZ3JjS3dH?= =?utf-8?B?aGZlQVJJcEsrTUJpTnI2VUsxZDJaU3NnUkRBc292SnhuOGxKcVdoZEVHZ3l5?= =?utf-8?B?ZzRsVTRvcmwySStsb2ZQdVkrTU5GbytiWlc2SUlrOVh4ZUswZndHbzQvWVNi?= =?utf-8?B?YThmd3B1ZmdHWmtlYkdPamxwaGhmNHcydGE2cjNWUkgwRUxqVHJFdHJMS3A1?= =?utf-8?B?RG82UXFtbW0vQzJnVlhtYi9DaGZWZlRTOXFYY3JKemdTTHBiNCsvZ2NLcmtY?= =?utf-8?B?UGhlOFh1cisrMi92eTRKVWQ5dGF0VHZZUXNiTUJqSkdOSDFnS2JKcGZPaDZo?= =?utf-8?B?RzZhSXRGekhmbTZIckxZbTFZYmdHOHVHVXd6YzU5NEFQbG9xTFBOdTlVc1l5?= =?utf-8?B?RnUxdFVHd09KM2txVmNWREw5cTQ2KzEwNm4wWk45VTlNaG1OSGtmeHBDeFhU?= =?utf-8?B?cmpjaEhvT3hyb290ejZCQVR3Nlo1TmRiWDk2UTNoRkYwWnY1VkVDak1KeURk?= =?utf-8?B?Vm0wOEJZT0lFdVRRZWllSmp1YTVESXljRlp1OVpiSGxEaFQwN1ZKR3Q3TG9x?= =?utf-8?B?UVI4WTBCU08ySnNPMjEwalE3eFM4RkovdDhJaGlUWWN0VldEWDB0SlUyVmM3?= =?utf-8?B?bU1qU3Y2Tkl1SVVQZGI2d0wyNnJINVpHSnVNRlEvSzZhN2N5YmpSNnRYMU9B?= =?utf-8?B?WTFGc0wzd3JIUTRoM2llU0YvQjM0bDdXbDFQcnJhL1pXTXVabmEzSVk3OTF5?= =?utf-8?B?ZXFsWXNYVXJvYnQzbGtBYmhhcFgwaVdTUExKcVI4U1EyRHlwQldwUmI0Sk5i?= =?utf-8?B?UTZ4b2pHL3hoU044UzJUekhaRHRhdjJGRk01dTVteS9vRzVIRGFITm44anA2?= =?utf-8?B?QUUzUWw2RHNML2daSFNZMFlobC83KzVtaS9Nb25UY095cEE5NkE4TGdCRDBR?= =?utf-8?B?VGpuOCtMSEphMXZRQzFCQlIzQ3k5clVVODN0T29EdkJaVFRSdW1KQXZ4SXhB?= =?utf-8?B?bFdqaXkvMlRwOGVCalRNUVFWamxWUnNTZVBOS1JnZkJOYmZoSjY5bTIrMmlr?= =?utf-8?B?Q3ZES3pqQ3I0c3BlZUx2STVHQVBMaU4rNzgyZStCajJFYXFBZWhKbzFpKzRs?= =?utf-8?B?OFQ5VkpQU0NZMU5ZVjVzOEZ6YjJhSlVmOEw2cG9ETGpMWHo0MURzVFdqc2gw?= =?utf-8?B?WW1OcGVoZk9vQitKdDBuanZwTWFrMFNGOVhEZlloYUZ1RmtoMnZ6MVJNRS9O?= =?utf-8?B?WGlTVEZDQ216Tkc0NDZ4SUQ2RTEvNVp0b2ZydFlWQVlIOTBHZVdVWGxzTTAz?= =?utf-8?B?TGhsRG1aQkYwbVlhcGxxRWR1OTlsL3plZURUT3RpRkFmOXdBZTV5OE5STUpN?= =?utf-8?B?ZEZxczB0VnZzSlJNNFZwM0MraHJHUmNINGRjYlhPdmhTSEUvWXU0eGtIbHp2?= =?utf-8?Q?1zu9lVGzkngS+TLbi5T8P5ccnMrPquxl4jz+Ma8?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM4PR11MB54380441E1BDFF7F72294CCCB5199DM4PR11MB5438namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 74c28b5f-23af-48ea-bf6c-08d941f305dd X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2021 09:30:27.9996 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wuQUYNZCMRQ7JlCrkjXmgprF/Bl/t5khhECTmjfD/T9JPmL52HHTmpTThbm6P8jl6khh7SI6xbTvkmamMY8c2Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB5437 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 09:30:38 -0000 --_000_DM4PR11MB54380441E1BDFF7F72294CCCB5199DM4PR11MB5438namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgaXMgcGVyaGFwcyB3b3J0aCBub3RpbmcgdGhhdCB0aGUgTkVUQ09ORiBjb3B5LWNvbmZpZyBh bGxvd3MgZm9yIHRoZSBjb25maWd1cmF0aW9uIHRvIGJlIHNwZWNpZmllZCB1c2luZyBhbnkgVVJJ LCBidXQgdGhlIHNlcnZlciBjYXBhYmlsaXRpZXMgYW5ub3VuY2Ugd2hpY2ggVVJJIHNjaGVtZXMg YXJlIHN1cHBvcnRlZC4NCg0KSGVuY2UsIEkgdGhpbmsgdGhhdCBpdCBpcyBva2F5IGZvciB0aGUg WUFORyBtb2RlbCB0byB1c2UgVVJJLCBidXQgSSB0aGluayB0aGUgZHJhZnQsIGFuZCBkYXRhIG5v ZGUgZGVzY3JpcHRpb24gc2hvdWxkIGNvbnN0cmFpbiB0aGUgVVJJIHNjaGVtZXMgdGhhdCBhbGxv d2VkIChwZXJoYXBzIGZpbGU6Ly8gYW5kIGh0dHBzOi8vKS4gIFRoaXMgd291bGQgYWxsb3cgc3Vw cG9ydCBmb3IgZnV0dXJlIFVSSSBzY2hlbWVzIHRvIGJlIGFkZGVkIGluIGEgZnV0dXJlIHJldmlz aW9uIG9mIHRoZSBZQU5HIGluc3RhbmNlIGRhdGEgbW9kdWxlLCBpZiByZXF1aXJlZC4NCg0KUmVn YXJkcywNClJvYg0KDQoNCkZyb206IEJhbMOhenMgTGVuZ3llbCA8YmFsYXpzLmxlbmd5ZWxAZXJp Y3Nzb24uY29tPg0KU2VudDogMDggSnVseSAyMDIxIDEwOjE3DQpUbzogQW5keSBCaWVybWFuIDxh bmR5QHl1bWF3b3Jrcy5jb20+DQpDYzogSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndh ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+OyBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRv bkBjaXNjby5jb20+OyBuZXRtb2RAaWV0Zi5vcmc7IEJlbm9pdCBDbGFpc2UgPGJlbm9pdC5jbGFp c2VAaHVhd2VpLmNvbT4NClN1YmplY3Q6IFJFOiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRt b2QteWFuZy1pbnN0YW5jZS1maWxlLWZvcm1hdA0KDQpTZWUgaW5saW5lLCBCYWxhenMNCg0KRnJv bTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtz LmNvbT4+DQpTZW50OiAyMDIxLiBqw7psaXVzIDcuLCBzemVyZGEgMjA6NTANClRvOiBCYWzDoXpz IExlbmd5ZWwgPGJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTxtYWlsdG86YmFsYXpzLmxlbmd5 ZWxAZXJpY3Nzb24uY29tPj4NCkNjOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2Fl bGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11 bml2ZXJzaXR5LmRlPj47IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbTxt YWlsdG86cndpbHRvbkBjaXNjby5jb20+PjsgbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RA aWV0Zi5vcmc+OyBCZW5vaXQgQ2xhaXNlIDxiZW5vaXQuY2xhaXNlQGh1YXdlaS5jb208bWFpbHRv OmJlbm9pdC5jbGFpc2VAaHVhd2VpLmNvbT4+DQpTdWJqZWN0OiBSZTogQUQgcmV2aWV3IG9mIGRy YWZ0LWlldGYtbmV0bW9kLXlhbmctaW5zdGFuY2UtZmlsZS1mb3JtYXQNCg0KSGksDQoNCkkgaGF2 ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCB0aGUgc2FtZS1zY2hlbWEtYXMtZmlsZSBsZWFmOg0KDQog ICAgICAgbGVhZiBzYW1lLXNjaGVtYS1hcy1maWxlIHsNCiAgICAgICAgICAgICB0eXBlIGluZXQ6 dXJpOw0KICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAgICAiQSByZWZlcmVu Y2UgdG8gYW5vdGhlciBZQU5HIGluc3RhbmNlIGRhdGEgZmlsZS4NCiAgICAgICAgICAgICAgICBU aGlzIGluc3RhbmNlIGRhdGEgZmlsZSB1c2VzIHRoZSBzYW1lDQogICAgICAgICAgICAgICAgY29u dGVudCBzY2hlbWEgYXMgdGhlIHJlZmVyZW5jZWQgZmlsZS4iOw0KICAgICAgICAgICB9DQoNClRo ZSB0eXBlIGlzIGFuIHVuY29uc3RyYWluZWQgVVJJLg0KSXMgdGhpcyB0aGUgaW50ZW50Pw0KVGhl IHRvb2wgdGhhdCB3cml0ZXMgdGhlIGZpbGUgY2FuIHBpY2sgYW55IHNjaGVtZSAtIGFueSB2YWxp ZCBVUkkgYXQgYWxsLg0KVGhlIHJlYWRlciBtdXN0IHN1cHBvcnQgZXZlcnkga25vd24gVVJJIHNj aGVtZSBpbiBleGlzdGVuY2U/IElzIHRoYXQgdGhlIGludGVudCBoZXJlPw0KQkFMQVpTOiBBcyB0 aGUgbnVtYmVyIG9mIFVSSSBzY2hlbWVzIGlzIGdyb3dpbmcgd2l0aCBuZXcgVVJJIHNjaGVtZXMg aW50cm9kdWNlZCBmcm9tIHRpbWUgdG8gdGltZSwgdGhhdCBpcyBjbGVhcmx5IGltcG9zc2libGUu IE9uIHRoZSBvdGhlciBoYW5kLCB3ZSBkb27igJl0IHdhbnQgdG8gY29uc3RyYWluIFVSSSBzY2hl bWVzLiBUaGlzIGRyYWZ0IGlzIG5vdCBhYm91dCBzZWxlY3RpbmcgdGhlIGJlc3QgVVJJIHNjaGVt ZXMgZm9yIHJlZmVyZW5jaW5nIGEgZmlsZSwgaXQgb25seSBhYm91dCBwcm92aWRpbmcgYSBjb21t b24gZm9ybWF0IGZvciBtZXRhZGF0YSBhYm91dCBpbnN0YW5jZSBmaWxlcy4gVGhlIHNldCBvZiB1 c2FibGUvdXNlZCBVUkkgc2NoZW1lcyB3aWxsIGhhdmUgdG8gYmUgY29tbXVuaWNhdGVkIHVzaW5n IHNvbWUgb3RoZXIgbWV0aG9kLiBZb3UgY291bGQgYXNrIGEgc2ltaWxhciBxdWVzdGlvbjogZG9l cyBhIE5ldGNvbmYgY2xpZW50IG5lZWQgdG8gYmUgcHJlcGFyZWQgZm9yIGFueSBZQU5HIG1vZGVs PyBObyBqdXN0IGZvciB0aGUgb25lcyBoZSBpcyBpbnRlcmVzdGVkIGluLg0KDQpTZWMuIDQgY29u dGFpbnMgdGhpcyBsaW5lOg0KDQoNCiAgICBUaGUgaGVhZGVyIHBhcnQgaXMgbm90IHNlY3VyaXR5 IHNlbnNpdGl2ZS4NCg0KDQpJcyB0aGlzIHJlYWxseSB0cnVlIGlmIGEgVVJJIGlzIHByZXNlbnQg aW4gdGhpcyBsZWFmIHRoYXQgY29udGFpbnMgYSB1c2VybmFtZSBhbmQgcGFzc3dvcmQNCmluIGNs ZWFydGV4dD8NCkJBTEFaUzogQ2xlYXIgdGV4dCBwYXNzd29yZHMgYXJlIG5vdCB0aGUgaW50ZW50 aW9uLiBTaGFsbCBJICBhZGQgYSBzdGF0ZW1lbnQgYWJvdXQgdGhpcyB0byB0aGUgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnM/DQoNCkFuZHkNCg0KDQpPbiBXZWQsIEp1bCA3LCAyMDIxIGF0IDE6MDEg QU0gQmFsw6F6cyBMZW5neWVsIDxiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb208bWFpbHRvOmJh bGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGVsbG8gQW5keSwNClRoZXJlIGFy ZSBtYW55IGRpZmZlcmVudCB1c2UtY2FzZXMgZm9yIGluc3RhbmNlLWRhdGEtZmlsZXMsIGVhY2gg d2l0aCBzbGlnaHRseSBkaWZmZXJlbnQgcmVxdWlyZW1lbnRzLg0KDQpJbmxpbmUgbWV0aG9kIGlz IG5lZWRlZCwgaWYgeW91IHdhbnQgdG8gaW5kaWNhdGUgdGhhdCB0aGUgZmlsZSB3YXMgZ2VuZXJh dGVkIGJ5IHNvbWVvbmUgd2hvIHVzZXMgc29tZSBZQU5HIG1vZHVsZXMgd2l0aCBkZXZpYXRpb25z IGFuZCBzb21lIGZlYXR1cmVzIGFyZSBub3Qtc3VwcG9ydGVkLiBUaGVyZSBpcyBubyB3YXkgdG8g aW5kaWNhdGUgZmVhdHVyZS1zdXBwb3J0IGFuZCBkZXZpYXRpb25zIHdpdGggdGhlIHNpbXBsaWZp ZWQtaW5saW5lIG1ldGhvZC4NCg0KVGhlIFVSTCBtZXRob2Qgd2FzIHJlcXVlc3RlZCBmb3IgdGhl IHVzZS1jYXNlIHdoZW4geW91IGdlbmVyYXRlIGluc3RhbmNlLWRhdGEtc2V0cyByZXBlYXRlZGx5 IGUuZy4gZXZlcnkgbWludXRlIHdpdGggdGhlIHNhbWUgc2NoZW1hLiBZb3UgZG9u4oCZdCB3YW50 IHRvIGluY2x1ZGUgdGhlIGNvbnRlbnQtc2NoZW1hIGluIGV2ZXJ5IGZpbGUsIHNvIHlvdSBqdXN0 IGluY2x1ZGUgYSBzaW5nbGUgVVJMIHJlZmVyZW5jZS4gKE5vdGUgdGhlIGNvbnRlbnQgc2NoZW1h IG1heSBiZSBhIGxvbmdlciBwaWVjZSBvZiB0ZXh0LCBub3QganVzdCBhIHNpbmdsZSBZQU5HIG1v ZHVsZStyZXZpc2lvbikNClJlZ2FyZHMgQmFsYXpzDQoNCkZyb206IEFuZHkgQmllcm1hbiA8YW5k eUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+Pg0KU2VudDogMjAyMS4g asO6bGl1cyA2Liwga2VkZCAyMToyOA0KVG86IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hv ZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFj b2JzLXVuaXZlcnNpdHkuZGU+PjsgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFp bHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+OyBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBj aXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj47IEJhbMOhenMgTGVuZ3llbCA8YmFs YXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPG1haWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5j b20+PjsgbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+OyBCZW5vaXQgQ2xh aXNlIDxiZW5vaXQuY2xhaXNlQGh1YXdlaS5jb208bWFpbHRvOmJlbm9pdC5jbGFpc2VAaHVhd2Vp LmNvbT4+DQpTdWJqZWN0OiBSZTogQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0bW9kLXlhbmct aW5zdGFuY2UtZmlsZS1mb3JtYXQNCg0KDQoNCk9uIFR1ZSwgSnVsIDYsIDIwMjEgYXQgMTE6MTkg QU0gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNp dHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4+IHdyb3Rl Og0KT24gVHVlLCBKdWwgMDYsIDIwMjEgYXQgMTA6NTY6NDhBTSAtMDcwMCwgQW5keSBCaWVybWFu IHdyb3RlOg0KPiBPbiBUdWUsIEp1bCA2LCAyMDIxIGF0IDEwOjQyIEFNIEp1ZXJnZW4gU2Nob2Vu d2FlbGRlciA8DQo+IGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86 ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4gd3JvdGU6DQo+DQo+ID4gT24g VHVlLCBKdWwgMDYsIDIwMjEgYXQgMDk6NDI6MzlBTSAtMDcwMCwgQW5keSBCaWVybWFuIHdyb3Rl Og0KPiA+ID4NCj4gPiA+IElNTyB0aGUgNCBzZXBhcmF0ZSB3YXlzIHRvIGlkZW50aWZ5IHRoZSBz Y2hlbWEgYXJlIDMgdG9vIG1hbnksIGJ1dCB0aGF0DQo+ID4gPiBpcyB3aGF0IHRoZSBXRyB3YW50 cy4gIEl0IHNlZW1zIG9idmlvdXMgdGhhdCBhbnkgcmVhZGVyIG9mIHRoZSBmaWxlDQo+ID4gPiBo YXMgdG8gaW1wbGVtZW50IGFsbCA0IG1ldGhvZHMgYW5kIGFueSB3cml0ZXIgb2YgdGhlIGZpbGUg aXMgZnJlZSB0byBwaWNrDQo+ID4gPiBqdXN0IG9uZS4NCj4gPiA+IFNvIHRoZSBmZWF0dXJlIGRv ZXMgbm90IHJlYWxseSBoZWxwLg0KPiA+ID4NCj4gPg0KPiA+IFRoZSBmZWF0dXJlIHN0YXRlbWVu dHMgZGVjbGFyZSB0aGF0IGltcGxlbWVudGF0aW9uIHdvbid0IHdvcmsNCj4gPiB0b2dldGhlci4g QmFjayBpbiBhIGRheSwgdGhlIElFVEYgd2FzIGFsbCBhYm91dCBpbnRlcm9wZXJhYmlsaXR5IChh bmQNCj4gPiBpbXBsZW1lbnRhdGlvbiBjb3N0cykuIE5vd2FkYXlzIHdlIHNlZW0gdG8gYmUgZmlu ZSBpZiBpbXBsZW1lbnRhdGlvbnMNCj4gPiBkZWNsYXJlIHRoYXQgdGhleSB3b24ndCB3b3JrIHRv Z2V0aGVyLiBXZWxsLCBzdGlsbCBzbGlnaHRseSBiZXR0ZXINCj4gPiB0aGFuIGhhdmluZyBpbXBs ZW1lbnRhdGlvbnMgZmFpbCBhcmJpdHJhcml0eS4NCj4gPg0KPiA+DQo+DQo+IFRoaXMgaXMgYSB0 ZXh0IGZpbGUgc3RvcmVkIG9uIGEgVVNCIHN0aWNrLg0KPiBUaGVyZSBpcyBubyBjbGllbnQgb3Ig c2VydmVyLiBKdXN0IHJlYWRlcnMgYW5kIHdyaXRlcnMuDQo+IFNvIGhvdyBkb2VzIGEgWUFORyBm ZWF0dXJlIHdvcmsgaGVyZT8NCj4gVGhlIHJlYWRlciBpcyBzdXBwb3NlZCB0byBrbm93IGhvdyB0 byBmaW5kIG91dCBpZiB0aGlzIGZlYXR1cmUgaXMgc2V0DQo+IGJlZm9yZSBvcGVuaW5nIHRoZSBm aWxlPw0KPg0KPiBJIGRvbid0IHNlZSBob3cgc2VydmVyIGNhcGFiaWxpdGllcyBkaXNjb3Zlcnkg aXMgcmVsZXZhbnQgdG8gYQ0KPiBZQU5HIGluc3RhbmNlIGZpbGUuDQo+IFRoZSByZWFkZXIgY29k ZSB3aWxsIHNpbXBseSBhdHRlbXB0IHRvIHJlYWQgdGhlIGZpbGUgYW5kIGZhaWwgaWYgaXQNCj4g ZW5jb3VudGVycw0KPiBhIGZvcm1hdCB0aGF0IGlzIG5vdCBpbXBsZW1lbnRlZC4NCg0KSSBhc3N1 bWVkIHRoYXQgdGhlIGZlYXR1cmVzIGFyZSBjYXJyaWVkIGluIHRoZSBpbnN0YW5jZSBmaWxlLCBp LmUuLA0KdGhlIGZpbGUgZGVjbGFyZXMgdGhhdCBpdCB1c2VzIHdheSBYIHRvIGFubm91bmNlIHRo ZSBzY2hlbWEgYW5kIHRoZW4NCnRoZSBwYXJzZXIgY2FuIGZhaWwgd2l0aCBhIHN1aXRhYmxlIGVy cm9yIG1lc3NhZ2UuIElmIHRoZSBmZWF0dXJlcyBhcmUNCm5vdCBjYXJyaWVkIGluIHRoZSBmaWxl LCB0aGVuIHRoZXkgaW5kZWVkIHNlZW0gdG8gYmUgdXNlbGVzcy4NCg0KUGVyaGFwcyB0aGVyZSBh cmUgWSBkaWZmZXJlbnQgd2F5cyB0byBhbm5vdW5jZSB0aGUgZmVhdHVyZXMgb2YgdGhlDQppbnN0 YW5jZSBmaWxlIGFzIHdlbGwsIEkgZGlkIG5vdCBjaGVjay4gOy0pDQoNCk5vdyB5b3UgbWFkZSBy ZS1yZWFkIHRoZSBlbnRpcmUgZHJhZnQgOi0oDQpJIGNhbm5vdCBmaW5kIGFueSB0ZXh0IGhvdyB0 aGUgcmVhZGVyIGtub3dzIGlmIHRoaXMgZmVhdHVyZSBpcyBzZXQgYmVmb3JlIHJlYWRpbmcgdGhl DQpmaWxlIGFuZCBmaW5kaW5nIG91dC4NCg0KSSBkbyBub3Qgc2VlIGFueSBzaWduaWZpY2FudCB1 c2UtY2FzZSBmb3IgdGhlIElubGluZSBtZXRob2QgYW5kIG5vbmUgZm9yIHRoZSBVcmkgbWV0aG9k Lg0KTm9yIGRvIEkgc2VlIGFueSByZWFzb24gd2h5IHRoZSBTaW1wbGlmaWVkLUlubGluZSBtZXRo b2Qgc2hvdWxkIG5vdCBiZSBtYW5kYXRvcnkNCnRvIHVzZSBhbmQgYWx3YXlzIHByZXNlbnQuDQoN CklmIHRoZSB1c2UtY2FzZSBpcyBvZmZsaW5lIHNlcnZlciB2YWxpZGF0aW9uIHRoZW4gdGhlIFlB TkcgbGlicmFyeSBkZXRhaWxzIG5lZWQgdG8gYmUga25vd24uDQpUaGUgZW50aXJlIFlBTkcgbGli cmFyeSBmb3IgdGhlIHNlcnZlciAob3IgcmVsZXZhbnQgcGFydHMpIGFyZSByZWNvcmRlZCBpbiB0 aGUgSW5saW5lIG1ldGhvZC4NCkV4Y2VwdCBpdCBpcyBjb21wbGljYXRlZCB0byBzdG9yZSB0aGUg aW5mbyBhYm91dCBob3cgdG8gaW50ZXJwcmV0IFlBTkcgc2NoZW1hIGJ5DQpyZWFkaW5nIGluc3Rh bmNlIGZpbGVzIGFuZCBndWVzc2luZyB3aGF0IHRoZSAiYW55ZGF0YSIgY29udGFpbnMuDQoNCkkg YWN0dWFsbHkgcHJlZmVyIGEgc2ltcGxlIHN0cmluZyBiYXNlZCBvbiBSRkMgNjAyMCBVUkkgbWV0 aG9kLCBzaW5jZSBpdCBjYW4NCmJlIGVhc2lseSBpbnRlZ3JhdGVkIGludG8gdGhlIFNpbXBsaWZp ZWQgSW5saW5lIGZvcm0gYW5kIGNhbiBiZSBwYXJzZWQgd2l0aG91dCBndWVzc2luZw0KYW55dGhp bmcgYWJvdXQgdGhlIGNvbnRlbnRzIG9mIGFueWRhdGEuDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvcmZjNjAyMCNzZWN0aW9uLTUuNi40DQoNCmUsZywNCg0KT0xEOg0K ICAgICAgICAgY2FzZSBzaW1wbGlmaWVkLWlubGluZSB7DQogICAgICAgICAgICAgICBsZWFmLWxp c3QgbW9kdWxlIHsNCiAgICAgICAgICAgICAgICAgIHR5cGUgbW9kdWxlLXdpdGgtcmV2aXNpb24t ZGF0ZTsNCiAgICAgICAgICAgICAgICAgIC4uLg0KICAgICAgICAgICAgICAgIH0NCiAgICAgICAg ICB9DQoNCk5FVzoNCg0KICAgICAgICAgY2FzZSBzaW1wbGlmaWVkLWlubGluZSB7DQogICAgICAg ICAgICAgICBsZWFmLWxpc3QgbW9kdWxlIHsNCiAgICAgICAgICAgICAgICAgIHR5cGUgdW5pb24g ew0KICAgICAgICAgICAgICAgICAgICAgICB0eXBlIG1vZHVsZS13aXRoLXJldmlzaW9uLWRhdGU7 DQogICAgICAgICAgICAgICAgICAgICAgIHR5cGUgc3RyaW5nOw0KICAgICAgICAgICAgICAgICAg IH0NCiAgICAgICAgICAgICAgICAgICAuLi4NCiAgICAgICAgICAgICAgICB9DQogICAgICAgICAg fQ0KDQpFeGFtcGxlIG1vZHVsZSBsZWFmLWxpc3QgZW50cnk6DQoNCiAgICAgICBpZXRmLWludGVy ZmFjZXM/cmV2aXNpb249MjAxOC0wMi0yMCZmZWF0dXJlcz1pZi1taWIsYXJiaXRyYXJ5LW5hbWVz JmRldmlhdGlvbnM9YWNtZS1kZXZpYXRpb25zDQoNCg0KSU1PIFNpbXBsaWZpZWQgSW5saW5lIFNI T1VMRCBiZSB0aGUgb25seSBmb3JtYXQsIGFuZCB0aGUgb3RoZXIgbWV0aG9kcyBjYW4gYmUgcmVt b3ZlZC4NCg0KDQovanMNCg0KDQpBbmR5DQoNCg0KDQotLQ0KSnVlcmdlbiBTY2hvZW53YWVsZGVy ICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNClBob25lOiArNDkgNDIx IDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkN CkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2 ZXJzaXR5LmRlLzxodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3YxL3VybD9rPTFiODJkYzdj LTQ0MTllNjM5LTFiODI5Y2U3LTg2N2IzNmQxNjM0Yy0zZDM5NWZjZjExNzgxMDEzJnE9MSZlPWNl NmRiYmI4LTg2OTMtNGFjOC1hYmJmLTRhMjAxNGI3N2IzMiZ1PWh0dHBzJTNBJTJGJTJGd3d3Lmph Y29icy11bml2ZXJzaXR5LmRlJTJGPj4NCg== --_000_DM4PR11MB54380441E1BDFF7F72294CCCB5199DM4PR11MB5438namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25z b2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkl0IGlzIHBlcmhhcHMgd29ydGggbm90 aW5nIHRoYXQgdGhlIE5FVENPTkYgY29weS1jb25maWcgYWxsb3dzIGZvciB0aGUgY29uZmlndXJh dGlvbiB0byBiZSBzcGVjaWZpZWQgdXNpbmcgYW55IFVSSSwgYnV0IHRoZSBzZXJ2ZXIgY2FwYWJp bGl0aWVzIGFubm91bmNlIHdoaWNoIFVSSSBzY2hlbWVzIGFyZSBzdXBwb3J0ZWQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhl bmNlLCBJIHRoaW5rIHRoYXQgaXQgaXMgb2theSBmb3IgdGhlIFlBTkcgbW9kZWwgdG8gdXNlIFVS SSwgYnV0IEkgdGhpbmsgdGhlIGRyYWZ0LCBhbmQgZGF0YSBub2RlIGRlc2NyaXB0aW9uIHNob3Vs ZCBjb25zdHJhaW4gdGhlIFVSSSBzY2hlbWVzIHRoYXQgYWxsb3dlZCAocGVyaGFwcyBmaWxlOi8v IGFuZCBodHRwczovLykuJm5ic3A7IFRoaXMNCiB3b3VsZCBhbGxvdyBzdXBwb3J0IGZvciBmdXR1 cmUgVVJJIHNjaGVtZXMgdG8gYmUgYWRkZWQgaW4gYSBmdXR1cmUgcmV2aXNpb24gb2YgdGhlIFlB TkcgaW5zdGFuY2UgZGF0YSBtb2R1bGUsIGlmIHJlcXVpcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxicj4N ClJvYjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiPiBCYWzDoXpzIExlbmd5ZWwgJmx0O2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbSZn dDsNCjxicj4NCjxiPlNlbnQ6PC9iPiAwOCBKdWx5IDIwMjEgMTA6MTc8YnI+DQo8Yj5Ubzo8L2I+ IEFuZHkgQmllcm1hbiAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4g SnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNp dHkuZGUmZ3Q7OyBSb2IgV2lsdG9uIChyd2lsdG9uKSAmbHQ7cndpbHRvbkBjaXNjby5jb20mZ3Q7 OyBuZXRtb2RAaWV0Zi5vcmc7IEJlbm9pdCBDbGFpc2UgJmx0O2Jlbm9pdC5jbGFpc2VAaHVhd2Vp LmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRm LW5ldG1vZC15YW5nLWluc3RhbmNlLWZpbGUtZm9ybWF0PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNlZSBpbmxpbmUsIEJh bGF6czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gQW5keSBCaWVybWFuICZsdDs8YSBocmVm PSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0Ow0K PGJyPg0KPGI+U2VudDo8L2I+IDIwMjEuIGrDumxpdXMgNy4sIHN6ZXJkYSAyMDo1MDxicj4NCjxi PlRvOjwvYj4gQmFsw6F6cyBMZW5neWVsICZsdDs8YSBocmVmPSJtYWlsdG86YmFsYXpzLmxlbmd5 ZWxAZXJpY3Nzb24uY29tIj5iYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb208L2E+Jmd0Ozxicj4N CjxiPkNjOjwvYj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDs8YSBocmVmPSJtYWlsdG86ai5z Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlIj5qLnNjaG9lbndhZWxkZXJAamFjb2Jz LXVuaXZlcnNpdHkuZGU8L2E+Jmd0OzsgUm9iIFdpbHRvbiAocndpbHRvbikgJmx0OzxhIGhyZWY9 Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0OzsNCjxh IGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT47IEJlbm9p dCBDbGFpc2UgJmx0OzxhIGhyZWY9Im1haWx0bzpiZW5vaXQuY2xhaXNlQGh1YXdlaS5jb20iPmJl bm9pdC5jbGFpc2VAaHVhd2VpLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBB RCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy1pbnN0YW5jZS1maWxlLWZvcm1hdDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+SSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFib3V0IHRoZSBzYW1l LXNjaGVtYS1hcy1maWxlIGxlYWY6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsZWFmIHNhbWUtc2NoZW1h LWFzLWZpbGUgezxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3R5cGUgaW5ldDp1cmk7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ZGVzY3JpcHRpb248YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JnF1b3Q7QSByZWZlcmVuY2UgdG8gYW5v dGhlciBZQU5HIGluc3RhbmNlIGRhdGEgZmlsZS48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoaXMgaW5zdGFuY2UgZGF0YSBmaWxl IHVzZXMgdGhlIHNhbWU8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IGNvbnRlbnQgc2NoZW1hIGFzIHRoZSByZWZlcmVuY2VkIGZpbGUu JnF1b3Q7Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHR5cGUg aXMgYW4gdW5jb25zdHJhaW5lZCBVUkkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklzIHRoaXMgdGhl IGludGVudD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHRvb2wgdGhhdCB3cml0ZXMgdGhlIGZp bGUgY2FuIHBpY2sgYW55IHNjaGVtZSAtIGFueSB2YWxpZCBVUkkgYXQgYWxsLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGUgcmVhZGVyIG11c3Qgc3VwcG9ydCBldmVyeSBrbm93biBVUkkgc2NoZW1l IGluIGV4aXN0ZW5jZT8gSXMgdGhhdCB0aGUgaW50ZW50IGhlcmU/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJBTEFaUzogQXMg dGhlIG51bWJlciBvZiBVUkkgc2NoZW1lcyBpcyBncm93aW5nIHdpdGggbmV3IFVSSSBzY2hlbWVz IGludHJvZHVjZWQgZnJvbSB0aW1lIHRvIHRpbWUsIHRoYXQgaXMgY2xlYXJseSBpbXBvc3NpYmxl LiBPbiB0aGUgb3RoZXIgaGFuZCwgd2UgZG9u4oCZdCB3YW50IHRvIGNvbnN0cmFpbiBVUkkgc2No ZW1lcy4gVGhpcyBkcmFmdCBpcyBub3QgYWJvdXQgc2VsZWN0aW5nDQogdGhlIGJlc3QgVVJJIHNj aGVtZXMgZm9yIHJlZmVyZW5jaW5nIGEgZmlsZSwgaXQgb25seSBhYm91dCBwcm92aWRpbmcgYSBj b21tb24gZm9ybWF0IGZvciBtZXRhZGF0YSBhYm91dCBpbnN0YW5jZSBmaWxlcy4gVGhlIHNldCBv ZiB1c2FibGUvdXNlZCBVUkkgc2NoZW1lcyB3aWxsIGhhdmUgdG8gYmUgY29tbXVuaWNhdGVkIHVz aW5nIHNvbWUgb3RoZXIgbWV0aG9kLiBZb3UgY291bGQgYXNrIGEgc2ltaWxhciBxdWVzdGlvbjog ZG9lcyBhIE5ldGNvbmYNCiBjbGllbnQgbmVlZCB0byBiZSBwcmVwYXJlZCBmb3IgYW55IFlBTkcg bW9kZWw/IE5vIGp1c3QgZm9yIHRoZSBvbmVzIGhlIGlzIGludGVyZXN0ZWQgaW4uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5TZWMuIDQgY29udGFpbnMg dGhpcyBsaW5lOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo ZSBoZWFkZXIgcGFydCBpcyBub3Qgc2VjdXJpdHkgc2Vuc2l0aXZlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklzIHRoaXMgcmVhbGx5IHRy dWUgaWYgYSBVUkkgaXMgcHJlc2VudCBpbiB0aGlzIGxlYWYgdGhhdCBjb250YWlucyBhIHVzZXJu YW1lIGFuZCBwYXNzd29yZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5pbiBjbGVhcnRleHQ/Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJBTEFaUzogQ2xlYXIgdGV4dCBwYXNzd29yZHMgYXJlIG5v dCB0aGUgaW50ZW50aW9uLiBTaGFsbCBJICZuYnNwO2FkZCBhIHN0YXRlbWVudCBhYm91dCB0aGlz IHRvIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFuZHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBXZWQs IEp1bCA3LCAyMDIxIGF0IDE6MDEgQU0gQmFsw6F6cyBMZW5neWVsICZsdDs8YSBocmVmPSJtYWls dG86YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tIj5iYWxhenMubGVuZ3llbEBlcmljc3Nvbi5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5IZWxsbyBBbmR5LDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPlRoZXJlIGFyZSBtYW55IGRpZmZlcmVudCB1c2UtY2FzZXMgZm9yIGluc3RhbmNlLWRhdGEt ZmlsZXMsIGVhY2ggd2l0aCBzbGlnaHRseSBkaWZmZXJlbnQgcmVxdWlyZW1lbnRzLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+SW5saW5lIG1ldGhvZCBpcyBuZWVkZWQsIGlmIHlvdSB3YW50IHRv IGluZGljYXRlIHRoYXQgdGhlIGZpbGUgd2FzIGdlbmVyYXRlZCBieSBzb21lb25lIHdobyB1c2Vz IHNvbWUgWUFORyBtb2R1bGVzIHdpdGggZGV2aWF0aW9ucyBhbmQgc29tZSBmZWF0dXJlcyBhcmUg bm90LXN1cHBvcnRlZC4NCiBUaGVyZSBpcyBubyB3YXkgdG8gaW5kaWNhdGUgZmVhdHVyZS1zdXBw b3J0IGFuZCBkZXZpYXRpb25zIHdpdGggdGhlIHNpbXBsaWZpZWQtaW5saW5lIG1ldGhvZC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgVVJMIG1ldGhvZCB3YXMgcmVxdWVzdGVkIGZvciB0aGUg dXNlLWNhc2Ugd2hlbiB5b3UgZ2VuZXJhdGUgaW5zdGFuY2UtZGF0YS1zZXRzIHJlcGVhdGVkbHkg ZS5nLiBldmVyeSBtaW51dGUgd2l0aCB0aGUgc2FtZSBzY2hlbWEuIFlvdSBkb27igJl0IHdhbnQg dG8gaW5jbHVkZQ0KIHRoZSBjb250ZW50LXNjaGVtYSBpbiBldmVyeSBmaWxlLCBzbyB5b3UganVz dCBpbmNsdWRlIGEgc2luZ2xlIFVSTCByZWZlcmVuY2UuIChOb3RlIHRoZSBjb250ZW50IHNjaGVt YSBtYXkgYmUgYSBsb25nZXIgcGllY2Ugb2YgdGV4dCwgbm90IGp1c3QgYSBzaW5nbGUgWUFORyBt b2R1bGUrcmV2aXNpb24pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyBCYWxhenM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiPiBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3 b3Jrcy5jb20iIHRhcmdldD0iX2JsYW5rIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0Ow0KPGJy Pg0KPGI+U2VudDo8L2I+IDIwMjEuIGrDumxpdXMgNi4sIGtlZGQgMjE6Mjg8YnI+DQo8Yj5Ubzo8 L2I+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmouc2Nob2Vud2Fl bGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSIgdGFyZ2V0PSJfYmxhbmsiPmouc2Nob2Vud2FlbGRl ckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7OyBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9 Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iIHRhcmdldD0iX2JsYW5rIj5hbmR5QHl1bWF3b3Jr cy5jb208L2E+Jmd0OzsgUm9iIFdpbHRvbiAocndpbHRvbikNCiAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJ3aWx0b25AY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+cndpbHRvbkBjaXNjby5jb208L2E+ Jmd0OzsgQmFsw6F6cyBMZW5neWVsICZsdDs8YSBocmVmPSJtYWlsdG86YmFsYXpzLmxlbmd5ZWxA ZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+bmV0bW9kQGlldGYub3JnPC9hPjsgQmVub2l0IENsYWlzZSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmJlbm9pdC5jbGFpc2VAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJlbm9pdC5jbGFpc2VA aHVhd2VpLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBBRCByZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy1pbnN0YW5jZS1maWxlLWZvcm1hdDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVHVlLCBKdWwgNiwgMjAyMSBhdCAxMToxOSBB TSBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxk ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUiIHRhcmdldD0iX2JsYW5rIj5qLnNjaG9lbndhZWxkZXJA amFjb2JzLXVuaXZlcnNpdHkuZGU8L2E+Jmd0Ow0KIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBUdWUsIEp1bCAwNiwg MjAyMSBhdCAxMDo1Njo0OEFNIC0wNzAwLCBBbmR5IEJpZXJtYW4gd3JvdGU6PGJyPg0KJmd0OyBP biBUdWUsIEp1bCA2LCAyMDIxIGF0IDEwOjQyIEFNIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7 PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJz aXR5LmRlIiB0YXJnZXQ9Il9ibGFuayI+ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5 LmRlPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgT24gVHVlLCBKdWwg MDYsIDIwMjEgYXQgMDk6NDI6MzlBTSAtMDcwMCwgQW5keSBCaWVybWFuIHdyb3RlOjxicj4NCiZn dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSU1PIHRoZSA0IHNlcGFyYXRlIHdheXMg dG8gaWRlbnRpZnkgdGhlIHNjaGVtYSBhcmUgMyB0b28gbWFueSwgYnV0IHRoYXQ8YnI+DQomZ3Q7 ICZndDsgJmd0OyBpcyB3aGF0IHRoZSBXRyB3YW50cy4mbmJzcDsgSXQgc2VlbXMgb2J2aW91cyB0 aGF0IGFueSByZWFkZXIgb2YgdGhlIGZpbGU8YnI+DQomZ3Q7ICZndDsgJmd0OyBoYXMgdG8gaW1w bGVtZW50IGFsbCA0IG1ldGhvZHMgYW5kIGFueSB3cml0ZXIgb2YgdGhlIGZpbGUgaXMgZnJlZSB0 byBwaWNrPGJyPg0KJmd0OyAmZ3Q7ICZndDsganVzdCBvbmUuPGJyPg0KJmd0OyAmZ3Q7ICZndDsg U28gdGhlIGZlYXR1cmUgZG9lcyBub3QgcmVhbGx5IGhlbHAuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhlIGZlYXR1cmUgc3RhdGVtZW50cyBkZWNs YXJlIHRoYXQgaW1wbGVtZW50YXRpb24gd29uJ3Qgd29yazxicj4NCiZndDsgJmd0OyB0b2dldGhl ci4gQmFjayBpbiBhIGRheSwgdGhlIElFVEYgd2FzIGFsbCBhYm91dCBpbnRlcm9wZXJhYmlsaXR5 IChhbmQ8YnI+DQomZ3Q7ICZndDsgaW1wbGVtZW50YXRpb24gY29zdHMpLiBOb3dhZGF5cyB3ZSBz ZWVtIHRvIGJlIGZpbmUgaWYgaW1wbGVtZW50YXRpb25zPGJyPg0KJmd0OyAmZ3Q7IGRlY2xhcmUg dGhhdCB0aGV5IHdvbid0IHdvcmsgdG9nZXRoZXIuIFdlbGwsIHN0aWxsIHNsaWdodGx5IGJldHRl cjxicj4NCiZndDsgJmd0OyB0aGFuIGhhdmluZyBpbXBsZW1lbnRhdGlvbnMgZmFpbCBhcmJpdHJh cml0eS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsg VGhpcyBpcyBhIHRleHQgZmlsZSBzdG9yZWQgb24gYSBVU0Igc3RpY2suPGJyPg0KJmd0OyBUaGVy ZSBpcyBubyBjbGllbnQgb3Igc2VydmVyLiBKdXN0IHJlYWRlcnMgYW5kIHdyaXRlcnMuPGJyPg0K Jmd0OyBTbyBob3cgZG9lcyBhIFlBTkcgZmVhdHVyZSB3b3JrIGhlcmU/PGJyPg0KJmd0OyBUaGUg cmVhZGVyIGlzIHN1cHBvc2VkIHRvIGtub3cgaG93IHRvIGZpbmQgb3V0IGlmIHRoaXMgZmVhdHVy ZSBpcyBzZXQ8YnI+DQomZ3Q7IGJlZm9yZSBvcGVuaW5nIHRoZSBmaWxlPzxicj4NCiZndDs8YnI+ DQomZ3Q7IEkgZG9uJ3Qgc2VlIGhvdyBzZXJ2ZXIgY2FwYWJpbGl0aWVzIGRpc2NvdmVyeSBpcyBy ZWxldmFudCB0byBhPGJyPg0KJmd0OyBZQU5HIGluc3RhbmNlIGZpbGUuPGJyPg0KJmd0OyBUaGUg cmVhZGVyIGNvZGUgd2lsbCBzaW1wbHkgYXR0ZW1wdCB0byByZWFkIHRoZSBmaWxlIGFuZCBmYWls IGlmIGl0PGJyPg0KJmd0OyBlbmNvdW50ZXJzPGJyPg0KJmd0OyBhIGZvcm1hdCB0aGF0IGlzIG5v dCBpbXBsZW1lbnRlZC48YnI+DQo8YnI+DQpJIGFzc3VtZWQgdGhhdCB0aGUgZmVhdHVyZXMgYXJl IGNhcnJpZWQgaW4gdGhlIGluc3RhbmNlIGZpbGUsIGkuZS4sPGJyPg0KdGhlIGZpbGUgZGVjbGFy ZXMgdGhhdCBpdCB1c2VzIHdheSBYIHRvIGFubm91bmNlIHRoZSBzY2hlbWEgYW5kIHRoZW48YnI+ DQp0aGUgcGFyc2VyIGNhbiBmYWlsIHdpdGggYSBzdWl0YWJsZSBlcnJvciBtZXNzYWdlLiBJZiB0 aGUgZmVhdHVyZXMgYXJlPGJyPg0Kbm90IGNhcnJpZWQgaW4gdGhlIGZpbGUsIHRoZW4gdGhleSBp bmRlZWQgc2VlbSB0byBiZSB1c2VsZXNzLjxicj4NCjxicj4NClBlcmhhcHMgdGhlcmUgYXJlIFkg ZGlmZmVyZW50IHdheXMgdG8gYW5ub3VuY2UgdGhlIGZlYXR1cmVzIG9mIHRoZTxicj4NCmluc3Rh bmNlIGZpbGUgYXMgd2VsbCwgSSBkaWQgbm90IGNoZWNrLiA7LSk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Tm93IHlvdSBtYWRlIHJl LXJlYWQgdGhlIGVudGlyZSBkcmFmdCA6LSg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGNhbm5v dCBmaW5kIGFueSB0ZXh0IGhvdyB0aGUgcmVhZGVyIGtub3dzIGlmIHRoaXMgZmVhdHVyZSBpcyBz ZXQgYmVmb3JlIHJlYWRpbmcgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ZmlsZSBhbmQgZmlu ZGluZyBvdXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+SSBkbyBub3Qgc2VlIGFueSBzaWduaWZpY2FudCB1c2UtY2FzZSBmb3IgdGhlIElubGlu ZSBtZXRob2QgYW5kIG5vbmUgZm9yIHRoZSBVcmkgbWV0aG9kLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPk5vciBkbyBJIHNlZSBhbnkgcmVhc29uIHdoeSB0aGUgU2ltcGxpZmllZC1JbmxpbmUgbWV0 aG9kIHNob3VsZCBub3QgYmUgbWFuZGF0b3J5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+dG8gdXNl IGFuZCBhbHdheXMgcHJlc2VudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj5JZiB0aGUgdXNlLWNhc2UgaXMgb2ZmbGluZSBzZXJ2ZXIgdmFsaWRh dGlvbiB0aGVuIHRoZSBZQU5HIGxpYnJhcnkgZGV0YWlscyBuZWVkIHRvIGJlIGtub3duLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBlbnRpcmUgWUFORyBsaWJyYXJ5IGZvciB0aGUgc2VydmVy IChvciByZWxldmFudCBwYXJ0cykgYXJlIHJlY29yZGVkIGluIHRoZSBJbmxpbmUgbWV0aG9kLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPkV4Y2VwdCBpdCBpcyBjb21wbGljYXRlZCB0byBzdG9yZSB0 aGUgaW5mbyBhYm91dCBob3cgdG8gaW50ZXJwcmV0IFlBTkcgc2NoZW1hIGJ5PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+cmVhZGluZyBpbnN0YW5jZSBmaWxlcyBhbmQgZ3Vlc3Npbmcgd2hhdCB0aGUg JnF1b3Q7YW55ZGF0YSZxdW90OyBjb250YWlucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFjdHVhbGx5IHByZWZlciBhIHNpbXBsZSBzdHJp bmcgYmFzZWQgb24gUkZDIDYwMjAgVVJJIG1ldGhvZCwgc2luY2UgaXQgY2FuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+YmUgZWFzaWx5IGludGVncmF0ZWQgaW50byB0aGUgU2ltcGxpZmllZCBJbmxp bmUgZm9ybSBhbmQgY2FuIGJlIHBhcnNlZCB3aXRob3V0IGd1ZXNzaW5nPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+YW55dGhpbmcgYWJvdXQgdGhlIGNvbnRlbnRzIG9mIGFueWRhdGEuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9yZmM2MDIwI3NlY3Rpb24tNS42LjQi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL3Jm YzYwMjAjc2VjdGlvbi01LjYuNDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj5lLGcsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+T0xEOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjYXNlIHNpbXBsaWZpZWQtaW5saW5lIHs8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bGVh Zi1saXN0IG1vZHVsZSB7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHlwZSBtb2R1bGUtd2l0aC1yZXZpc2lvbi1kYXRl OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg fTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi Pk5FVzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Nhc2Ugc2ltcGxpZmll ZC1pbmxpbmUgezxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtsZWFmLWxpc3QgbW9kdWxlIHs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0eXBlIHVuaW9uIHs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3R5cGUgbW9k dWxlLXdpdGgtcmV2aXNpb24tZGF0ZTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3R5cGUgc3RyaW5nOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO308bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsuLi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPkV4YW1wbGUgbW9kdWxlIGxlYWYtbGlzdCBlbnRyeTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtpZXRmLWludGVyZmFjZXM/cmV2aXNpb249MjAxOC0wMi0yMCZh bXA7ZmVhdHVyZXM9aWYtbWliLGFyYml0cmFyeS1uYW1lcyZhbXA7ZGV2aWF0aW9ucz1hY21lLWRl dmlhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5JTU8gU2ltcGxpZmllZCBJbmxpbmUg U0hPVUxEIGJlIHRoZSBvbmx5IGZvcm1hdCwgYW5kIHRoZSBvdGhlciBtZXRob2RzIGNhbiBiZSBy ZW1vdmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj4vanM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ QW5keTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj48YnI+DQotLSA8YnI+DQpKdWVyZ2VuIFNjaG9lbndhZWxkZXImbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0phY29icyBVbml2ZXJzaXR5IEJy ZW1lbiBnR21iSDxicj4NClBob25lOiArNDkgNDIxIDIwMCAzNTg3Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO0NhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55PGJy Pg0KRmF4OiZuYnNwOyAmbmJzcDsrNDkgNDIxIDIwMCAzMTAzJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZsdDs8YSBocmVmPSJodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3Yx L3VybD9rPTFiODJkYzdjLTQ0MTllNjM5LTFiODI5Y2U3LTg2N2IzNmQxNjM0Yy0zZDM5NWZjZjEx NzgxMDEzJmFtcDtxPTEmYW1wO2U9Y2U2ZGJiYjgtODY5My00YWM4LWFiYmYtNGEyMDE0Yjc3YjMy JmFtcDt1PWh0dHBzJTNBJTJGJTJGd3d3LmphY29icy11bml2ZXJzaXR5LmRlJTJGIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9hPiZndDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_DM4PR11MB54380441E1BDFF7F72294CCCB5199DM4PR11MB5438namp_-- From nobody Thu Jul 8 02:59:43 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F4F3A1BC4 for ; Thu, 8 Jul 2021 02:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4mElCP2H3L9 for ; Thu, 8 Jul 2021 02:59:30 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2069.outbound.protection.outlook.com [40.107.22.69]) (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 640BB3A1B85 for ; Thu, 8 Jul 2021 02:59:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K1gWUejmkaRVxgNz+nxWVPElDx1TlSHaqgJFybPxJYA1+jG1PbDdut1w7n5oLgKKaw/XfCoAtVEE3Dtn7q838bekvhYEX6xJ7+roACOBAF2soOE+IVOWr0wzbfIvbVsnMgb3yHYGVYc6v/xn7UO5ZJI1ixUZs4XPFvYPJ8nHexULxfpPFkeUEB/U5/ap2wefbC4e4cvklpV4W9I3py/QmX9hOzLj4ypQNUDMCHesz0KDcGJi2SgRkPN1qmIWwcgWg5DxU44HYyWPbYNcWmQ7+X/qMyuaItcNp0e3UJvh5GA/oOURAP+UH3kyk4r0jbADFa0k57EFZAJBfe/Yxc3vgw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DrsDWTkZ6QWDpqGXikmF88iZKXWDXedI4DMvml1L32o=; b=oBr5VFr0P/Ks1Khbzi1eHzWzvlB/tlh2iSKsyDh7SmySIgwrN3uQF8THWqUubxzQqtSrmqCl9cs8vQ5yMgE35JRQ78gccyVsZ34xn2dvFlNDD9uwfHtrrbJLeEizZbT18mUvSgPQdOMWsCr3W2/KVr0lh9+l/HBtlw402QVRaaczuZa5gtbjIZvJMXRzh9/sMcIoDyfA1xmSjBe478nygx3mi9uWm5/BLyrr1D2BuCuSjM1Owcu1FKPynCIMSYhTays71VYx9D+u7qc6vPRdPrfMRmcMOUA5dXIWeOq8b3WNXXYE//1Px6C8AZF5R8I+apnEgwlRYccj1ZbnzfVByg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DrsDWTkZ6QWDpqGXikmF88iZKXWDXedI4DMvml1L32o=; b=N235kSlR6nTGMpa00zgxxKBCPPDtp9MkvprH3JpnG9pXfzMFkWolkmv4GVEOkPfgxro/v6i4pRHkGMQXKeHNrQh6cRmpk8ZHXGd41jiRKEA1pcVFc4bcC8wJ6wlwS4sYhPM5d0BiA0Z7oQQuGh+wdoznNY+P5oO1GHkKx/DZ2Qg= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8245.eurprd07.prod.outlook.com (2603:10a6:20b:324::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.9; Thu, 8 Jul 2021 09:59:18 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4308.018; Thu, 8 Jul 2021 09:59:18 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , Andy Bierman CC: "netmod@ietf.org" Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAPXLWAAAIT0wAAAIMhAAAAy2eAAAJlLwAAGf35QAAW9oAAAB4Up2AAAaee4A== Date: Thu, 8 Jul 2021 09:59:18 +0000 Message-ID: References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 747871c5-b8bb-41d2-c017-08d941f70d71 x-ms-traffictypediagnostic: AM8PR07MB8245: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5nOXGsZwApKtXJrvW3LfaaTFZ57md/8pdlaBlDwmd9NDiWzTzSprxl5vV3xjWiQtAugiRBFIYQ3ri/b8TqRbUHHBh7RAN1vGv6oZhVBdlSIIbpwQPrG1YWZKuD2cPP39LHFt+IihY+pBIH5WQHNFFOFO/PD8ckrnXQfoZyS+J/20TC5pHwqNw98UA2GIX3mhWqQdoL714gj1DwkHkSc0/rQp5Aj/aQySTgC0dSegtpNmvigep1yF5hTdrzD7C+4IaCuTVXo6FV1kaxv9tvN1/1TLFCobbg+z72OBUFW4dzNY52XthN+INdfCDYFsqnbfYRd7CufNptHM92z9TB6Iwl6/DrNT48MlBrPqERq5AyodM5K4Jh7aJBwlM+hzjw24Q/7OHn21riXp0tjHSLnGtjcsER/z4gA6TGzrCL/m4PwJZuLo08V8vKtmQc14VQHxlwl2XQ/1E0u4Ou2Bux13rZroIUNx5gVXbVBQa0uiWlrSCTJ7sKo2HaIn98LvMzd5Cg7Ydo2WccUf0JwOxDmaL2U8bIHVqdfGnZL90bGpeNJ9yiKTDPKkYGkBz3t34ChL4FdnurNcml5FfVob4oGCPC+v0+fjtDjDqjbTWAM3G0soyho83vJABS9sqH0zCbZIvWK1NxNp/duV1dkW9a9RwdmG2kJlcPmC0Dl4/UUe7h1hjPGL/enKMf313aand90+Ekzm35WTlSvP3l97bpgV2rjn5UpN7IOzx/uBEch2JZI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(366004)(376002)(136003)(346002)(4326008)(7696005)(2940100002)(85202003)(122000001)(110136005)(8936002)(85182001)(5660300002)(186003)(76116006)(26005)(2906002)(166002)(478600001)(53546011)(316002)(9686003)(38100700002)(6506007)(66616009)(86362001)(55016002)(83380400001)(66946007)(71200400001)(66574015)(8676002)(66476007)(52536014)(66556008)(66446008)(33656002)(64756008)(966005)(99936003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?VHhUcnNLdWlWTEVxZzhEaXU0WUI1OVBHYmI4dndNUHoxa3ZiVjFNTEtHSEgw?= =?utf-8?B?ZzJ5MGY2NFVLaW9DTkFJVk5jdnkzQmV0UE1VMDFLcU9ZTUxFZ0hpa2N0RElw?= =?utf-8?B?SlRXTmhiR0VRUTNpRkxROS9ZSjB3OVVONk41QU1uaDVVTEkwSkZ2NHFVbUFy?= =?utf-8?B?SGMrUUVDZk9ONTRGYjNteXhRcXU2aTVSNkRWOXV3bi9mekpkUlZCZjRlcEFF?= =?utf-8?B?SDdlTlRqNVF1S1NtemJsRnhnVk5veFpyNjkvQkxNbk03eisxeW8rSG51M21W?= =?utf-8?B?Q04yNW05Rk5qY2d0R1Y3UjlRS2tacmlQWDFHcWI2TGFRT2dpMnozaEtNUFFI?= =?utf-8?B?anBaN2pob29PVXE4dHhQZ2N0aGtpZFpaWjFad0g3THVzMFp4ZklYYUNLWHcy?= =?utf-8?B?bGNUNkplNWtxL1VJbkR4Q2YxNEkySSt0U3hONTF0T0s2b3VzeEY0d05aTVpI?= =?utf-8?B?dXZ4MjhwQ0RhZllMTFZpbWtGNUM4S0N0REZRdmtOakVCeHIreHdYbi8yMWUx?= =?utf-8?B?S1pWUUh0YnByRlkyU0YySnE3K3pabFFJL2V3cHgwRm0ycjFEOTBLKzNqKzNV?= =?utf-8?B?QXZSOHpkdE5xYUZVd2xVQ2RyU2FidUh1Y2hORHRnVTM4WldPNDFjSUFlaWdD?= =?utf-8?B?WVZGWmozRHpSVHlNRnB5enBsV3dJUHRuaCtBb0M3MHJlZTVHMExpajFSdXRU?= =?utf-8?B?ZDZrMW1Sb0xDUHV2Z2ZSK3hRbzIrVXJwN1NpUW9kQ1ptVExvdjR6N01DN3FK?= =?utf-8?B?T1NncitKZ1dUN2Z1Y1EvaGo2ankwMjBIQTY2UHV6MmtqZ1ZOeFBGU0VRZjg0?= =?utf-8?B?cWZwaTJDekEwYXdJTWZIMnRBZExsTVY4VVErMTd6YzViMVVTUWRqdTJiMFhm?= =?utf-8?B?VzQvampkYXgyMnBVbnVrNmYreHM3cmg3VEJNOXZZYWhPeWRtdGRkOXVhWTRM?= =?utf-8?B?aWdSZTNBMFA4bktyQk5jMld0Y1hRNFFxbmxOMWdCeDQvdkthbytxQmd1TXAv?= =?utf-8?B?TjJuYjh5VFZZRlZIc2lINTRESk1tZkVyNkhzRWpXbDFBUndMdmU5YWR4eW1u?= =?utf-8?B?MTJ5c0E0UjZpWUZSdUdpOWFlM2FydXMwK3ZGZkZyZ09TdEpiL0w3RzRPVER6?= =?utf-8?B?Q09uQkZmUzVib25FVy84UnpicU1VT0ZEVWZtNFdhNXVlQkVUcWtBMzhURW5N?= =?utf-8?B?dmdWcjhrUVBYY0FsZHFLWkdWdG1ncE4rSERYM081cGlqR1g1S3NQVi9UcUZJ?= =?utf-8?B?azgzRW5DWEFjTkdPMWNCekgwZzJCTnRkajJ6ajBiR0piVzFYenEwQXJCVFV2?= =?utf-8?B?Vmlid0tPK3M4bDBid3VNeFlwenZqa3ZTUW41WEJDMUoxMFh2NGR5WEZXQUxw?= =?utf-8?B?eEorNWdTc2hMSUw4ME1SaWVDZjgxcWRVcnJoU1pXN3ptOTFEdzF0K0x2S0R0?= =?utf-8?B?blBaZmkrYnBidVZVY1grU0IrNkozNVNFVWNLaUFKNGNvYjhtNWFwcWxRNFVu?= =?utf-8?B?QmZXOWhmeG1NanIzbi9zcnF1dlUrWVl4N2d3ZFZNbDgxVWdTbUxabzlvYVNl?= =?utf-8?B?THc4elNmMHY0Y3M2S05IeUlVZVN0ZlhjbERPNVRDSGZacjhMUXpHU244NUIx?= =?utf-8?B?ZVFYaFpyZzAzaVJPWFQ5UWp2MVcrTFFtYUJZUnMwOXJYcXp1cSt4b3M0dDNh?= =?utf-8?B?K0VPOTV4THl6RThUdGh6cjduQmR6R09xUzA0TVU0NW1HSWxmQndRcmxNU3V2?= =?utf-8?Q?mCBYXK1OIL+xVWh03x4NSS8nlOpI72k8xh/rb4n?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0450_01D773F0.AD6FA780" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 747871c5-b8bb-41d2-c017-08d941f70d71 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2021 09:59:18.6488 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /zG40E080BXB9kaKYtsgwZOnPqGoVD3H7l8PNKv/tpXKxZgmu9kLoghcF0IZHEOK92DzexLZQk1tOi1ZLCQMwl54NmU6Vz0J6pCxRWPzD8c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8245 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 09:59:42 -0000 ------=_NextPart_000_0450_01D773F0.AD6FA780 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0451_01D773F0.AD6FCE90" ------=_NextPart_001_0451_01D773F0.AD6FCE90 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable A sentence about the security risk of a username/password in the URI = will be added to the security considerations. Balazs =20 From: netmod On Behalf Of Bal=C3=A1zs Lengyel Sent: 2021. j=C3=BAlius 8., cs=C3=BCt=C3=B6rt=C3=B6k 11:17 To: Andy Bierman Cc: netmod@ietf.org Subject: Re: [netmod] AD review of = draft-ietf-netmod-yang-instance-file-format =20 See inline, Balazs =20 From: Andy Bierman >=20 Sent: 2021. j=C3=BAlius 7., szerda 20:50 To: Bal=C3=A1zs Lengyel > Cc: Juergen Schoenwaelder >; Rob Wilton (rwilton) = >; netmod@ietf.org = ; Benoit Claise > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format =20 Hi, =20 I have some questions about the same-schema-as-file leaf: =20 leaf same-schema-as-file { type inet:uri; description "A reference to another YANG instance data file. This instance data file uses the same content schema as the referenced file."; } =20 The type is an unconstrained URI. Is this the intent? The tool that writes the file can pick any scheme - any valid URI at = all. The reader must support every known URI scheme in existence? Is that the = intent here? BALAZS: As the number of URI schemes is growing with new URI schemes = introduced from time to time, that is clearly impossible. On the other = hand, we don=E2=80=99t want to constrain URI schemes. This draft is not = about selecting the best URI schemes for referencing a file, it only = about providing a common format for metadata about instance files. The = set of usable/used URI schemes will have to be communicated using some = other method. You could ask a similar question: does a Netconf client = need to be prepared for any YANG model? No just for the ones he is = interested in. =20 Sec. 4 contains this line: =20 The header part is not security sensitive. =20 Is this really true if a URI is present in this leaf that contains a = username and password in cleartext?=20 BALAZS: Clear text passwords are not the intention. Shall I add a = statement about this to the security considerations? =20 Andy =20 =20 On Wed, Jul 7, 2021 at 1:01 AM Bal=C3=A1zs Lengyel = > = wrote: Hello Andy, There are many different use-cases for instance-data-files, each with = slightly different requirements.=20 =20 Inline method is needed, if you want to indicate that the file was = generated by someone who uses some YANG modules with deviations and some = features are not-supported. There is no way to indicate feature-support = and deviations with the simplified-inline method. =20 The URL method was requested for the use-case when you generate = instance-data-sets repeatedly e.g. every minute with the same schema. = You don=E2=80=99t want to include the content-schema in every file, so = you just include a single URL reference. (Note the content schema may be = a longer piece of text, not just a single YANG module+revision) Regards Balazs =20 From: Andy Bierman >=20 Sent: 2021. j=C3=BAlius 6., kedd 21:28 To: Juergen Schoenwaelder >; Andy Bierman = >; Rob Wilton (rwilton) = >; Bal=C3=A1zs Lengyel = >; = netmod@ietf.org ; Benoit Claise = > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format =20 =20 =20 On Tue, Jul 6, 2021 at 11:19 AM Juergen Schoenwaelder = > wrote: On Tue, Jul 06, 2021 at 10:56:48AM -0700, Andy Bierman wrote: > On Tue, Jul 6, 2021 at 10:42 AM Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de = > wrote: >=20 > > On Tue, Jul 06, 2021 at 09:42:39AM -0700, Andy Bierman wrote: > > > > > > IMO the 4 separate ways to identify the schema are 3 too many, but = that > > > is what the WG wants. It seems obvious that any reader of the = file > > > has to implement all 4 methods and any writer of the file is free = to pick > > > just one. > > > So the feature does not really help. > > > > > > > The feature statements declare that implementation won't work > > together. Back in a day, the IETF was all about interoperability = (and > > implementation costs). Nowadays we seem to be fine if = implementations > > declare that they won't work together. Well, still slightly better > > than having implementations fail arbitrarity. > > > > >=20 > This is a text file stored on a USB stick. > There is no client or server. Just readers and writers. > So how does a YANG feature work here? > The reader is supposed to know how to find out if this feature is set > before opening the file? > > I don't see how server capabilities discovery is relevant to a > YANG instance file. > The reader code will simply attempt to read the file and fail if it > encounters > a format that is not implemented. I assumed that the features are carried in the instance file, i.e., the file declares that it uses way X to announce the schema and then the parser can fail with a suitable error message. If the features are not carried in the file, then they indeed seem to be useless. Perhaps there are Y different ways to announce the features of the instance file as well, I did not check. ;-) =20 Now you made re-read the entire draft :-( I cannot find any text how the reader knows if this feature is set = before reading the file and finding out. =20 I do not see any significant use-case for the Inline method and none for = the Uri method. Nor do I see any reason why the Simplified-Inline method should not be = mandatory to use and always present. =20 If the use-case is offline server validation then the YANG library = details need to be known. The entire YANG library for the server (or relevant parts) are recorded = in the Inline method. Except it is complicated to store the info about how to interpret YANG = schema by reading instance files and guessing what the "anydata" contains. =20 I actually prefer a simple string based on RFC 6020 URI method, since it = can be easily integrated into the Simplified Inline form and can be parsed = without guessing anything about the contents of anydata. =20 https://datatracker.ietf.org/doc/html/rfc6020#section-5.6.4 =20 e,g, =20 OLD: case simplified-inline { leaf-list module { type module-with-revision-date; ... } } =20 NEW: =20 case simplified-inline { leaf-list module { type union { type module-with-revision-date; type string; } ... } } =20 Example module leaf-list entry: =20 = ietf-interfaces?revision=3D2018-02-20&features=3Dif-mib,arbitrary-names&d= eviations=3Dacme-deviations =20 =20 IMO Simplified Inline SHOULD be the only format, and the other methods = can be removed. =20 =20 /js =20 =20 Andy =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 > ------=_NextPart_001_0451_01D773F0.AD6FCE90 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

A sentence about the security = risk of a username/password in the URI will be added to the security = considerations.

Balazs

 

From: netmod = <netmod-bounces@ietf.org> On Behalf Of Bal=C3=A1zs = Lengyel
Sent: 2021. j=C3=BAlius 8., cs=C3=BCt=C3=B6rt=C3=B6k = 11:17
To: Andy Bierman = <andy@yumaworks.com>
Cc: = netmod@ietf.org
Subject: Re: [netmod] AD review of = draft-ietf-netmod-yang-instance-file-format

 

See inline, = Balazs

 

From: Andy Bierman <andy@yumaworks.com> =
Sent: 2021. j=C3=BAlius 7., szerda 20:50
To: = Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jaco= bs-university.de>; Rob Wilton (rwilton) <rwilton@cisco.com>; netmod@ietf.org; Benoit Claise = <benoit.claise@huawei.com>=
Subject: Re: AD review of = draft-ietf-netmod-yang-instance-file-format

 

Hi,

 

I = have some questions about the same-schema-as-file = leaf:

 

       leaf same-schema-as-file = {
             type = inet:uri;
            =  description
              =  "A reference to another YANG instance data file.
  =               This instance data file = uses the same
                = content schema as the referenced file.";
      =      }

 

The type is an unconstrained = URI.

Is this the = intent?

The tool that = writes the file can pick any scheme - any valid URI at = all.

The reader must = support every known URI scheme in existence? Is that the intent = here?

BALAZS: As the number of URI = schemes is growing with new URI schemes introduced from time to time, = that is clearly impossible. On the other hand, we don=E2=80=99t want to = constrain URI schemes. This draft is not about selecting the best URI = schemes for referencing a file, it only about providing a common format = for metadata about instance files. The set of usable/used URI schemes = will have to be communicated using some other method. You could ask a = similar question: does a Netconf client need to be prepared for any YANG = model? No just for the ones he is interested = in.

 

Sec. 4 contains this line:

 

    The header part is not security =
sensitive.
 

Is this really true if a URI is present in this leaf = that contains a username and password

in cleartext? 

BALAZS: Clear text passwords are not the intention. = Shall I  add a statement about this to the security = considerations?

 

Andy

 

 

On = Wed, Jul 7, 2021 at 1:01 AM Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com> wrote:

Hello = Andy,

There are = many different use-cases for instance-data-files, each with slightly = different requirements.

 <= /o:p>

Inline = method is needed, if you want to indicate that the file was generated by = someone who uses some YANG modules with deviations and some features are = not-supported. There is no way to indicate feature-support and = deviations with the simplified-inline method.

 <= /o:p>

The URL = method was requested for the use-case when you generate = instance-data-sets repeatedly e.g. every minute with the same schema. = You don=E2=80=99t want to include the content-schema in every file, so = you just include a single URL reference. (Note the content schema may be = a longer piece of text, not just a single YANG = module+revision)

Regards = Balazs

 <= /o:p>

From:= Andy Bierman <andy@yumaworks.com>
Sent: 2021. = j=C3=BAlius 6., kedd 21:28
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>; Andy = Bierman <andy@yumaworks.com>; Rob Wilton (rwilton) = <rwilton@cisco.com>; Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>; netmod@ietf.org; = Benoit Claise <benoit.claise@huawei.com>
Subject: = Re: AD review of = draft-ietf-netmod-yang-instance-file-format

 <= /o:p>

 <= /o:p>

 <= /o:p>

On Tue, Jul = 6, 2021 at 11:19 AM Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> = wrote:

On Tue, Jul 06, = 2021 at 10:56:48AM -0700, Andy Bierman wrote:
> On Tue, Jul 6, = 2021 at 10:42 AM Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> = wrote:
>
> > On Tue, Jul 06, 2021 at 09:42:39AM -0700, = Andy Bierman wrote:
> > >
> > > IMO the 4 = separate ways to identify the schema are 3 too many, but that
> = > > is what the WG wants.  It seems obvious that any reader = of the file
> > > has to implement all 4 methods and any = writer of the file is free to pick
> > > just one.
> = > > So the feature does not really help.
> > >
> = >
> > The feature statements declare that implementation = won't work
> > together. Back in a day, the IETF was all about = interoperability (and
> > implementation costs). Nowadays we = seem to be fine if implementations
> > declare that they won't = work together. Well, still slightly better
> > than having = implementations fail arbitrarity.
> >
> >
> =
> This is a text file stored on a USB stick.
> There is no = client or server. Just readers and writers.
> So how does a YANG = feature work here?
> The reader is supposed to know how to find = out if this feature is set
> before opening the = file?
>
> I don't see how server capabilities discovery is = relevant to a
> YANG instance file.
> The reader code will = simply attempt to read the file and fail if it
> = encounters
> a format that is not implemented.

I assumed = that the features are carried in the instance file, i.e.,
the file = declares that it uses way X to announce the schema and then
the = parser can fail with a suitable error message. If the features = are
not carried in the file, then they indeed seem to be = useless.

Perhaps there are Y different ways to announce the = features of the
instance file as well, I did not check. = ;-)

 <= /o:p>

Now you = made re-read the entire draft :-(

I cannot = find any text how the reader knows if this feature is set before reading = the

file and = finding out.

 <= /o:p>

I do not = see any significant use-case for the Inline method and none for the Uri = method.

Nor do I = see any reason why the Simplified-Inline method should not be = mandatory

to use and = always present.

 <= /o:p>

If the = use-case is offline server validation then the YANG library details need = to be known.

The entire = YANG library for the server (or relevant parts) are recorded in the = Inline method.

Except it = is complicated to store the info about how to interpret YANG schema = by

reading = instance files and guessing what the "anydata" = contains.

 <= /o:p>

I actually = prefer a simple string based on RFC 6020 URI method, since it = can

be easily = integrated into the Simplified Inline form and can be parsed without = guessing

anything = about the contents of anydata.

 <= /o:p>

 <= /o:p>

e,g,

 <= /o:p>

OLD:

  =        case simplified-inline {
    =            leaf-list module {
  =                 type = module-with-revision-date;

  =                 = ...

  =               = }

  =         }

 <= /o:p>

NEW:

 <= /o:p>

  =        case simplified-inline {
    =            leaf-list module {
  =                 type union = {

  =                     =  type module-with-revision-date;

  =                     =  type string;

  =                 =  }

  =                 =  ...

  =               = }

  =         }

 <= /o:p>

Example = module leaf-list entry:

 <= /o:p>

  =     =  ietf-interfaces?revision=3D2018-02-20&features=3Dif-mib,arbitra= ry-names&deviations=3Dacme-deviations

 <= /o:p>

 <= /o:p>

IMO = Simplified Inline SHOULD be the only format, and the other methods can = be removed.

 <= /o:p>

 <= /o:p>

/js

 <= /o:p>

 <= /o:p>

Andy

 <= /o:p>

 <= /o:p>


-- =
Juergen Schoenwaelder           Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587      =    Campus Ring 1 | 28759 Bremen | Germany
Fax:  =  +49 421 200 3103         <https://www.jacobs-university.de/>

------=_NextPart_001_0451_01D773F0.AD6FCE90-- ------=_NextPart_000_0450_01D773F0.AD6FA780 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDcwODA5NTkxNlowIwYJKoZIhvcNAQkEMRYEFJMN/X424TI0 JrxuO5V1DcLXcrOWMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAEen lx9mmwTT2561YH1XZx6RLdzg9TBpm/vb4Ljn6IHHTR4Qr/2Bz9aowFlE0yZB3qGy2TiHbMOHVN/0 2L2B/rlUtFdk75td/yXDwNV+A39nhC+X16T1Vvdg+p08mRrCIigMl54ve3K8GyC9Ru0BuBYGOWdA lAGeoDlNMmWITxXRnwsgdJBLcbfgvBxI4BSiMNkW3KeJZzUl0Zt6tIAFVO9CRSb6dKlx31+Xdcm2 rP1+YI5NwEf0hyoBcNk9itLeE+RqHmdJTCDih+22mJUnMeC/ZMpsynP8Wy6JD3cXI8gYhu7X7iw7 auoqnhY/u9I5KH4BMgSv0RqURjZxFtKEEEkAAAAAAAA= ------=_NextPart_000_0450_01D773F0.AD6FA780-- From nobody Thu Jul 8 03:13:36 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB0E3A1C76 for ; Thu, 8 Jul 2021 03:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.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 KfoJtfIqMbS8 for ; Thu, 8 Jul 2021 03:13:29 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140040.outbound.protection.outlook.com [40.107.14.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FCBF3A1C75 for ; Thu, 8 Jul 2021 03:13:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hw5S4OTlTdXeTHdZNnWUOv+FAgZRw6F+K/LY4Ogeoz5F/qoQNgxJjNvp9/OweX4V3c0woyhLqQNO9T4ahUcgCrhNvH5i64P/UkjhrQ1ItxRaQg5EvL0Z2OUdrnbYxgJXhHSRE7U8GDL18jGovMrd2XT3/Hi58mEsNnl8dHCOjlgJXQdZkwzECJRykmp5+SoLVuC+gpP1bFg6Xc9taqxUKRdo+0lbXyjQ1EyOch/6n7MciGtbx0351xvryOHWZcPu5FALfHOXbX1K5B7ORoA7LAUr/FmYnKXqyKz+WVQXX7/TLXcq+RPpbWojAtg5Mjhk90+xghx0TITuXlukbsDlkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Tylqrt7R9OaLVfHhtKws4AE613iHvwlva5OrATZxfnw=; b=JNSKy/oqSbmVuFSaWv8kB2hltUlivmqtolMzCSkmEBO0RmHZn3vjYIc038/PGfNWgBqscoo7EU2w62U62AVu17ZEYqoicr0I7yGGOY1KMtWqJuanbOa4xkzoH8a74PlDvZQQSgu4I7mwycYxDe+cTjYOrSRHMCHXZX8t4Sdtbbs/SxgoAT9N9c7wAFXbvRLdh8YPSkc0095SwzskOQJIuX2d8AMo7+ZjFwVAIBKUmaiXUpZXtZgUOpMwXRSHpy2GksX+Vg+a4cFLU2opSEQdmh/yIaEPIdQVg7SYDL7tUcPB1KvGeljI+7VJs0/QcXFau73aP4YwgL3I1IKCHXd1Fw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Tylqrt7R9OaLVfHhtKws4AE613iHvwlva5OrATZxfnw=; b=VquE7VSh/lr/Pt22FAwOd7XrdDVBgA7F8Si1IS/hZ31966pDGthMjLWad4EVqMLAB1SC5BgZFoaK7NGAxbibMst96oD7C6zCkHpaN9JVxJZ1+M0cgO5rYZZJb034k5RJudIIBMusERUJIM8BtrZ3Onb3pFwirVUZkh5K4itu4tE= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM0P190MB0659.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:198::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.21; Thu, 8 Jul 2021 10:13:27 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::d505:1bab:3e82:6d6b]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::d505:1bab:3e82:6d6b%4]) with mapi id 15.20.4308.021; Thu, 8 Jul 2021 10:13:27 +0000 Date: Thu, 8 Jul 2021 12:13:26 +0200 From: Juergen Schoenwaelder To: "Rob Wilton (rwilton)" Cc: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , Andy Bierman , "netmod@ietf.org" , Benoit Claise Message-ID: <20210708101326.wuzvtjesghpq5jq7@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Rob Wilton (rwilton)" , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , Andy Bierman , "netmod@ietf.org" , Benoit Claise References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: PR3P195CA0016.EURP195.PROD.OUTLOOK.COM (2603:10a6:102:b6::21) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR3P195CA0016.EURP195.PROD.OUTLOOK.COM (2603:10a6:102:b6::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.20 via Frontend Transport; Thu, 8 Jul 2021 10:13:26 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1ffeb8ed-acdb-4202-f2b9-08d941f906eb X-MS-TrafficTypeDiagnostic: AM0P190MB0659: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: V8RNeZJ5wf1+7RA0RCEhBoqOHrJ3JjUzHJ4StAb+xKt7pJ8tJw+8EnhcS2OkVy1P1MCTnMNcnIq3UmCKpZGGGIWCMoTfbKOasb1atrQJefc9gyreEdD9+/IxdPJTMEl/R1P2GmhcNmUgV13alLBLBiuy8fv3L7+nYQ1u/4AOf7Y5OZuNrsGMpCWNYRHYlU9vLV9AFRSx/6l5F6AKhbJGDRn+6cRBEgriELJWYe7dZtcRDCIxmO7CF7uxkO0NiycN1S9Ub6e/PMVaI2DDgBc8mOtciWyvVnv31mO/suVchRaPNxnO2pE4HJYJ3MtFmIMrIClJseWRC4Bt6BiQRntdZOeSzoBYJyIxiHusveJvoYAF2GWG3iboMbeubEVp7y3xWtmsLZOaEdTND4zod1M80mHKmEkf4G9BR5FHDFYCJb0p0gT4n8ARloIG+/AowivfZDoDtZLIAClpwbzocB5nQHOGwHCteHJ9C8AnxE0Ydz5nOKAWuVb7SYxlDs+CVIJWNMzQWRqCH5cW7ifHeZ1pjpbN+Qft76skHy55VbRVElCgjR1zByNrKXo6aN6DgE+ls4wjjP+aIxRCcOsmVJKf+Asz0EWLilqWPB5bo3fKs4W9dt23HlItjR1iQGJGTtUk5h+S5W1Po3zxGrJkyZu1y7UuCRKHRGpiYxLlTEukd69YxWVWJIZNAo+lkb9siWwCfLoLTwt2RN3Zm3ubcCzgt5Wp5iRtbDqXjUmNghGkEHVYvRizDUceZN8yMn5l7H7IgtgUJMvnPVSbICJ2HlLduFp5OXbHaZf4h/f/hduZJpg= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(346002)(376002)(366004)(39850400004)(136003)(4326008)(478600001)(6486002)(3450700001)(66946007)(956004)(8676002)(6916009)(2906002)(86362001)(8936002)(26005)(38350700002)(5660300002)(316002)(52116002)(6496006)(54906003)(1076003)(786003)(66556008)(4744005)(38100700002)(186003)(966005)(66476007); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?7u+Oou7xR3ktYlak2bUHGsweX4a/14bTB/zayR1JiSJm+j9IZbOXLuSfTLSt?= =?us-ascii?Q?qSkd/SPAtvf+OGBiru1jnOaru3aJUiqjum6Dg5zUPEXjZl/sav+xFO7oV4zy?= =?us-ascii?Q?AhwjgxzZHfC6IfgHx+uHi+9A00lbncQfjj8kLjveclsYPN4TqN/tmakflOu2?= =?us-ascii?Q?jLbfxpAdykTvnwceI05jhaelmMmny2jqmWkan03eaM0yg0vAj472/2/rggDJ?= =?us-ascii?Q?7NEL+jAN5Sx2T5PFTuT2Dp/icXOAgK6M5LCXR1DY6xJ5dUCuBFgjQqRGPgXj?= =?us-ascii?Q?YA0LfBWqiyUOz0ZepN/be03UCeOcvZSQ/jTcxm0flpQ8es/cpZk8rHMcwrwH?= =?us-ascii?Q?KRPoMy5WTSRtQ2pKDLI93035v6DA5OmAM1BQnWqLPhwPm85ZDuh7sdEVERvF?= =?us-ascii?Q?avMw3JoWajSTABZs/e+P8RanuX+ik76A0umQzpD5qTkx2UbpJe1lGxIVoYfl?= =?us-ascii?Q?tuwhnouHTC41WfUSbiXkml/fYzx8zK1jpdZU7awCA1J90K9nDGW64j1xPMiG?= =?us-ascii?Q?EmMZkq3tnLnPL084DP1G4UtOcRsE1zzOPxms0wgg18Gvt05/VdPv6nI/VZdO?= =?us-ascii?Q?xZ9zWmk3ZhdsnsIylg6Ik1Ni5oJRzkpfYjxCd88+4eA4/jzBJpBg2QWRUexx?= =?us-ascii?Q?DpM4H9qqPov9zdoZejOA0odPcoMB0hxE8MUhAI24t6JuRIxZMlr8W0pgAQHB?= =?us-ascii?Q?b7vAX4RVDdjt+INkpMKueqhWkAyjNfwCSe0fJRX63ICm4jNfUd3MKhPJOP31?= =?us-ascii?Q?/W/exrioWeqDf2RtHpZ1e8FW+/EN7HP2dTh2yEoYOsYAyvtgGwh7u9H18sTU?= =?us-ascii?Q?Hhxge1nib1Y2mxIbAUdf09VxmleVmiGn9ZWQXfTNyTOwt/4Js5+mp0t1bsb2?= =?us-ascii?Q?NIydJE6fgvObG6PeqjBF7+mG3d+LO1Hao7j8MXY0qkMdre80iPfbBDcd9UXk?= =?us-ascii?Q?7yLqWcjwnxm/h94TcKQEwyslk2m6CtrGPSHv4WkOxNEsb9YMjd//H6gkaXq+?= =?us-ascii?Q?+vuwC99HalJHp6jH0MioHaEGxfqhdkkXqUnX5SSpAosVxQV+1GKifL2c8iP7?= =?us-ascii?Q?BQni2rhYNmLiJcmxDTi7cwPiRI1FYDjY+a6PqNVwBqLk1JL5VoS8gXv3LZ6C?= =?us-ascii?Q?w2AEjOB2Z/EWMl+BFLiCMnZaYWZ17RT76moL2sA1h1j0JfUngX8rRmE7rQyP?= =?us-ascii?Q?NbJLrzKSMVi1f39fLXC1PanwmsKL362CHzCBlPGMCrxLNNVGo9uHi4Up8bCV?= =?us-ascii?Q?zIRoISn78n2rJKhqnLRglK7jqsXrpA4axr1HpQraeY6g6r/r32EgJqpMRzTl?= =?us-ascii?Q?fTwks7u9vjD+AlxAaEqgZW+B?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 1ffeb8ed-acdb-4202-f2b9-08d941f906eb X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2021 10:13:26.9708 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: TZOWjImFVEi8+GcanTRQg0wIxNr2IoH/MasAG/ZDI6TnV4gOk9MKtI2qJupymp/MVlIrpDpqrfjHzGNxOsqz7O3DnJy0Ae1Re2O91MGDeWY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0P190MB0659 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 10:13:34 -0000 On Thu, Jul 08, 2021 at 09:30:27AM +0000, Rob Wilton (rwilton) wrote: > It is perhaps worth noting that the NETCONF copy-config allows for the configuration to be specified using any URI, but the server capabilities announce which URI schemes are supported. > > Hence, I think that it is okay for the YANG model to use URI, but I think the draft, and data node description should constrain the URI schemes that allowed (perhaps file:// and https://). This would allow support for future URI schemes to be added in a future revision of the YANG instance data module, if required. > I think it is not "allowed" but "mandatory to implement". We should allow implementations to support an ftps:// scheme as long as there is a common baseline. /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 Jul 8 03:25:55 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE853A1D3E for ; Thu, 8 Jul 2021 03:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.896 X-Spam-Level: X-Spam-Status: No, score=-11.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=YRhQH1aX; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EtQDz4YB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPCV3zkJE_UJ for ; Thu, 8 Jul 2021 03:25:49 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765EB3A1D3C for ; Thu, 8 Jul 2021 03:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1497; q=dns/txt; s=iport; t=1625739949; x=1626949549; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=R13k2PjWgMMz8C5E2XxYlGZsROhwZDJ+HvR7jVlWmTE=; b=YRhQH1aX1Kxs5nA0wuMZ4X1s4X3HbfALfgHMhSzq6I9RdJhYONzbKK+Z rz3DyMP5vOAL9AlP/XKqmg2Y/tDActF5TKq6sZAr1XL03b5CtBRjGVm+u yD56nedHS9aYT7fkGmEf0AMDzuMnOrJQgPQpdn/jSXc9f+wwfQQB7uoeg Q=; X-IPAS-Result: =?us-ascii?q?A0CpAACm0eZgl4ENJK1XAx0BAQEBCQESAQUFAUCBSAUBC?= =?us-ascii?q?wGBUlF+WjcxiBADhTmIXQOaJ4JTA1QLAQEBDQEBMRAEAQGEUwKCdgIlNwYOA?= =?us-ascii?q?gQBAQEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBAQEBaIVoDYZFAQEBBBIuA?= =?us-ascii?q?QE3AQsCAgIBCA4CAQQBAQEuGxcdCAIEAQ0FCBqCTwGCVQMvAZsqAYE6Aoofe?= =?us-ascii?q?IE0gQGCBwEBBgQEhSsYgjIDBgWBNQGCeopvJxyBSUSBWIJiPoQsGh8mgwaCD?= =?us-ascii?q?CKDTTYnLIEYbA8GJJFyjUCdYAqDIp5DEqY+lXukfwIEAgQFAg4BAQaCPSOBW?= =?us-ascii?q?3AVgyRQGQ6OHxmDVzOKK3M4AgYBCQEBAwmKUQEB?= IronPort-PHdr: A9a23:LMesQxZYj4hSiSLL7zNEl73/LTDbhN3EVzX9orIlgrlJeL/m4pLjI kHF/vRxnRnFUNaT5/FFjr/QtKbtESwF7I2auX8POJpLS1ceiMoQkgBhZazNCUDyIPPwKSBvG sNEWQxn9nq8O1MQBcD/eVDIuXyu/HgeF0a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiV/fKbN/J Rm7t0PfrM4T1IBjMa02jBDOpyggRg== IronPort-HdrOrdr: A9a23:3YpcZamUVWir4f4tH8zbrvrJiZLpDfOqimdD5ihNYBxZY6Wkfp +V/cjzhCWbtN9OYh4dcIi7Sda9qXO1z+8T3WBjB8bdYOCAghroEGgC1/qt/9SEIU3DH4FmpN xdmsRFebjN5B1B/LrHCWqDYpYdKbu8gdqVbI7lph8HJ2wHGsIQjTuRSDzrb3GeLzM2Y6bRYa Dsnvav0ADQAEj/AP7LYkUtbqzmnZnmhZjmaRkJC1oM8w+Vlw6l77b8Dlyxwgoeeykn+8ZgzU H11yjCoomzufCyzRHRk0XJ6Y5NpdfnwtxfQOSRl8kuLCn2gArAXvUiZ1TChkFxnAic0idsrD D+mWZnAy210QKJQoiBm2qo5+An6kd315at8y7CvZKpm72JeNtzMbswuWseSGqC16Ll1+sMjJ 6iGAmixsdq5Fr77VfAzsmNWBdwmkWup30+1eYVknxESIMbLKRctIoF4SpuYd099Q/Bmcga+d NVfYrhDTdtACSnRmGcunMqzM2nX3w1EBvDSk8eutaN2zwTmHxi1UMXyMEWg39FrfsGOtV5zv WBNr4tmKBFT8cQY644DOAdQdGvAmiIRR7XKmqdLVnuCalCMXPQrJz85qkz+YiRCdE1JVsJ6d 38uXZjxCEPkm7VeLizNaxwg2bwqT+GLEbQI+llluxEhoE= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,222,1620691200"; d="scan'208";a="745733815" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jul 2021 10:25:48 +0000 Received: from mail.cisco.com (xbe-aln-007.cisco.com [173.36.7.22]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 168APmAv024481 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 8 Jul 2021 10:25:48 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-aln-007.cisco.com (173.36.7.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 8 Jul 2021 05:25:48 -0500 Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 8 Jul 2021 05:25:47 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 8 Jul 2021 06:25:47 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lQLHmMuaBCKC8PGlq10TGGDRZ6JI5t3uKWoMDhgiQJ/BOn/xx27i/ep7Jt5L0RrnrPoqinTWU/lXqPp9ezbDwVkimFiy0UXgiWnpcukLXvFOPSMA3ihnkR5OZsmXwPwu7DceuDScaORTAxru2blTqEPLwE1bRXLDEVufRhDu8GowkyKq8jIcID7mOSoPnWKHgxXcAVSZ7+v+l1TlYDeOlwWhD4FGAC1ayMgPQvC7BWw5AfA2YlIo+pefJk2BvHe5DHMyyDzH9dVR5HnXzm7J/emxKjUtITQtLPhHFC3jbs90SU65quv1r7t3Y4EKFt8CyzZUHZySvCo/pO83iBIyfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DdE3hU0ol1ujlhHChxOh2wmS7Pms5qDWa80cUZcrgio=; b=guUvjrItb/laGhUZW1zHJiB5yJiQc+GzQFY05I6f3cjR+9ZBCQH0DDIhiZW90s0VTusFex8ZviurjUloXlMSoVw0vw9ruSoiFUg9tVOZWZGLikBxvDY+0WynUgwF/WHAX1bUHiAM8MGDUSHbrRHLBdqx6E/FxyZPJlSRI0NHAFuR795K+bWncBSbf2gdGFH0kjI3fX+ODwuqyzu1+R92xl2iBhwbg+lkv0Ap1LeGQFkTuYVF1dloi6iIGs873po7WDrrDXUoAuL6+xcxmVltQsR8bktPiAgSD1N1n8GSWUaOmXYnUrGxZUoDlniHMDyf9Hhtob75Bep3qslC+7h5jQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DdE3hU0ol1ujlhHChxOh2wmS7Pms5qDWa80cUZcrgio=; b=EtQDz4YBxKcEWJ3c1ZZnjwaXU9mCI5aS/8VE7eP86aiJ5iwakGYxudGIUybAL5safXwlR8X+5CPEDYstNZxPMF5b4RzwLD3IVI2mSdLrk4fT3r0bvKG/PJRak0cFAwE+hB7pBzcjErIt748LZwiZFQT1y4QmWS5VwjNP48whpxk= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM5PR11MB1452.namprd11.prod.outlook.com (2603:10b6:4:9::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.31; Thu, 8 Jul 2021 10:25:46 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12%6]) with mapi id 15.20.4308.021; Thu, 8 Jul 2021 10:25:46 +0000 From: "Rob Wilton (rwilton)" To: Juergen Schoenwaelder , =?iso-8859-1?Q?Bal=E1zs_Lengyel?= CC: Andy Bierman , "netmod@ietf.org" , Benoit Claise Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAPXLWAAAIT0wAAAIMhAAAAy2eAAAJlLwAAGf35QAAW9oAAAB4Up2AAAF8VEAABzZgAAABfRBA= Date: Thu, 8 Jul 2021 10:25:46 +0000 Message-ID: References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> <20210708101326.wuzvtjesghpq5jq7@anna.jacobs.jacobs-university.de> In-Reply-To: <20210708101326.wuzvtjesghpq5jq7@anna.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 728feae1-a5ae-4e89-f3a5-08d941fac00c x-ms-traffictypediagnostic: DM5PR11MB1452: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vKNMnmxFLy2qva36cFOJ5lJDgsl1S/nDljB5O3aDIxfTrjju2mA2j5Chb353XhK37VOskp0TZ6QZedT+pCy1BjtCQGK7o4uPvr42DAiPFRoo/6HXZCDYIVL/PIRFzP284+FMUcQDV8W6jOgTlWhG6JCdKMCUlos5jpFSU9gnjBmT0/WuKWgtZfpaaXG2ZUzllcRWdB+xyy/8HxuBHfTXeKXjyEuzYSHFIK8slJf6l85RJo9a1xwp8Oby0M2nQk3DuqtCZTSOnuLnvVqE4JestfYXZ9lj/Nkp47QqiBlx/MTSnAep7u0Hbnn1HY2DUGtA/2UC1PX43qHW2ShBg/L/3OmQ7OHzMabcqfCkU2Ht6qoYQq5ssChcgsShKsRiUVw9Tsq5FHKYfo2AC8+hlCLs+8KzE29nVYdhTflDcvbhSMEQOYkJCnr2fyI595F5GjWJJLkdy2l/9md7OO5UKNofPElPpNc0E4pc7lGQ71p+N0AMdn9QR7P93Dw6QyEWaLfgts4FWr6CqvaLlG6fWk82UBY6d4d+lBwkXmEWJ584F0riMJl7bFqMkT6uXAy+uJCfU0AeYDDUVvz+3bdSv3linjHgQaeMhS0vSqObaKd42LuShDmOa/mfGuwjsTutK2uN+yHO6tko4PdH8pBKkwIHfghLc8DT1DggBCFXNRQgPF1lnaiHTj+kUHsROydboTZWrQOhHj3qfjsqb7ShdHQgln4fWA5doFootDm2jHJtudA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39860400002)(376002)(396003)(366004)(136003)(52536014)(186003)(316002)(86362001)(38100700002)(6506007)(2906002)(7696005)(478600001)(53546011)(122000001)(26005)(110136005)(54906003)(8676002)(71200400001)(8936002)(64756008)(55016002)(5660300002)(9686003)(66556008)(66946007)(76116006)(66446008)(83380400001)(4326008)(66476007)(966005)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?sMpPjL4BpCDgiTiZH7+QlqsjhCH0ZH4VEax2vr4n9S+GkRsNmZNRa7LZlJ?= =?iso-8859-1?Q?CT/ZqqKijDQ+yLaDT/Cpzqf1kKKMtUBgkOFTedY9OuFnJGYXnMsHerQeAW?= =?iso-8859-1?Q?4DdW5whX8bf3ClHljB0cYe/7taamwmWEEXWsTXNUk+aNnJ+NI3YclCWOWl?= =?iso-8859-1?Q?ZrrbLTZ3XpytyxcS/2llPA8HItGsikHaKkNSm/DnWTR6IzrWJDNnqqlOm2?= =?iso-8859-1?Q?MMEGXlsBffhFG7wU94nT+3oJeGMFlGP71+oMFsJUCOcfSSswmjqp04graZ?= =?iso-8859-1?Q?jMaWSYorfEBFOwJzzw5WP9cUQxROIXKUMAAx1nx+H836Jiw77CNm2o+rIY?= =?iso-8859-1?Q?I23SKtqtOAxLIf36OYDSTRpSfYT02RYbHYPfeXeIe+hW3WPurY+oSxNncX?= =?iso-8859-1?Q?ZNGv+KnlpbNL5F0x5EBT1ATVnqrC3h8l0GlPMYc3+abY9FkQAml+bEicuS?= =?iso-8859-1?Q?F+3uOlSxtfvLW0UqVfa9pdoXAp9pp/zZoPnyiJ0P8nzYU7bJZNndhbFPlN?= =?iso-8859-1?Q?n2zvwpKjfHxt0Z3B6HaIVQn0xhSOadziEDW4exkI3BRraOTIOVqD/idFmD?= =?iso-8859-1?Q?GClG1fPB6BD623/+GIaDaeLc/UePFB0pjhv6AX9GC1Gk9QDz/R8rX/bCF8?= =?iso-8859-1?Q?PiPisS5G164pGX7O9+xtAxRaSJ42svWXuYE4SzjFZ1j33H+3cNwtuDaJHm?= =?iso-8859-1?Q?6wahEH1RxII8QUy99kCAobDppKCYW2rMTe1m36bQC0XnV7tflEIGA5zTwl?= =?iso-8859-1?Q?DnnTeMH9gOZvKb7nI/YVKoEDfIuLlatz1uigapDhb/rsykRseGF9SRgVqY?= =?iso-8859-1?Q?aXOd5MIKnkQYzREoZEi398uEoHcA/xgcFaQEtvLtqmdcW+uAXv7R3jL+nw?= =?iso-8859-1?Q?tm39qEYmml70ye09QdqmovSpyCwqhB9u632A1qJqasR51hEoWBO1ErKMoj?= =?iso-8859-1?Q?qFc6/5X5nsVQGvx9sgVQKyG6Oa2TMatbnWT7uHi7aQGofNsb+zs71zyJwG?= =?iso-8859-1?Q?Jfkkcov5zm3iv/zHTQuyTb1u7B53G1MX0OUeI9G36G09N7VQMe/4d7IS4/?= =?iso-8859-1?Q?EPBwC8xb79oi4ijdT2RF+dwdFmXdGeDFkDe7lx4tvS3/GhG8aSYh0EUJNP?= =?iso-8859-1?Q?zyt0HehF6+KxRYb8Mw3Mr1ZY+Cw54EG4Eu25pNU/eDo16hYUSSUJlL1yyL?= =?iso-8859-1?Q?+koQaJEP6j5T0UyHseHhpWFpCd9vby9S9u+gtA4q1jk+CzU+RbZaiIJcGj?= =?iso-8859-1?Q?3UgYd8jNonGrgWwXhiR5Atsad0hCbPXkAlUWydHwfn0Rxw+pKoYkJvb6Wa?= =?iso-8859-1?Q?IzCm2MkhnTNqQYXN4PFHxirRZRBGCDPs2DNRr0f6CrDeT5XVeMfie+dZLZ?= =?iso-8859-1?Q?QR/VoPeiAO?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 728feae1-a5ae-4e89-f3a5-08d941fac00c X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2021 10:25:46.8961 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: StbbDgWN0h3oObYRyeqXgbMvA+6UGP5bb2l6DB9d3epVJJyjOTG0Zqo2UfC/hMJjuccnVJTWuw7fFS71qgMXtg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1452 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xbe-aln-007.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 10:25:54 -0000 Yes, I would be okay with that too. Regards, Rob > -----Original Message----- > From: Juergen Schoenwaelder > Sent: 08 July 2021 11:13 > To: Rob Wilton (rwilton) > Cc: Bal=E1zs Lengyel ; Andy Bierman > ; netmod@ietf.org; Benoit Claise > > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format >=20 > On Thu, Jul 08, 2021 at 09:30:27AM +0000, Rob Wilton (rwilton) wrote: > > It is perhaps worth noting that the NETCONF copy-config allows for the > configuration to be specified using any URI, but the server capabilities > announce which URI schemes are supported. > > > > Hence, I think that it is okay for the YANG model to use URI, but I thi= nk the > draft, and data node description should constrain the URI schemes that > allowed (perhaps file:// and https://). This would allow support for fut= ure > URI schemes to be added in a future revision of the YANG instance data > module, if required. > > >=20 > I think it is not "allowed" but "mandatory to implement". We should > allow implementations to support an ftps:// scheme as long as there > is a common baseline. >=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 Thu Jul 8 03:35:39 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A973A1DFB for ; Thu, 8 Jul 2021 03:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jacobsuniversity.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 IaWbv20O8w-3 for ; Thu, 8 Jul 2021 03:35:32 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2043.outbound.protection.outlook.com [40.107.21.43]) (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 4AF923A1DFA for ; Thu, 8 Jul 2021 03:35:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Iv982Hv8Qj6pYlbjBA6mchwSspjc0aBSPUdvCFSHtjAmt2k199D8vxYnecRzBdIcljdHIv/tKg7oGnQSTDauWq4ekmjO8RK6tmoP6QZevSpJ/HDf9mI3HvHHSl5t29MvYgBH7KkTVbOaAWzismNXq/1X4NLrYLljUE30oG7llmQJhW253hKzP2Sx5LRvGLCK119yZ3rqeGZPA1zdGNXTK1tfWh+ZwWn+RQxC+1p46QGBEPGNLoOTOMZcAmLniarewCci7S65zqzG5E/HhXC6UeXvqmwfMz1KsQHAEYQEA+MTLpj3XzPqXFaefdw2zfIx9D/CJga3G5suUHQbn54KpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nnax9oUc/Ei1HIsz1Lz9xq+CmbpTUrFgQYVbNIoX9f4=; b=nWS/t9V4+GNtb581qbudwofSytrsVykUTSssrQHBM7g8zAf7Aa3NsAfFrx0l145qlf2knZNezPscczoZtDdjbDir+fPxszQikYtHHYmTPscTVf6X912KkTHV9Is9laJh1p9fACiaRFoojlZb261SVdAAcEoNyRP2LEOTuGcw5oVylaCWDmkFhVHEcsA0edyW3uwUho27nSdqiXKCQ0BADQ4vFGbTlpmEh4aOevBtpdo2gCilMYEPguWiGW3WTZprmhLi/EpBBjoxDlQjMraYcf0QhpdF/oJpGcHSh75oWbUVPw1Zk6C5J6IEJzWIr9MbGldsb6RWO8do3mmK0Sc3ow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nnax9oUc/Ei1HIsz1Lz9xq+CmbpTUrFgQYVbNIoX9f4=; b=ljwPxItMG0zo0nAxVYE/Lg7mfxgQJh0xHfXbIflewhxJli1SlIu9SUtjaeYgNCAPX6qI3ZmiWaljRRuIzhddrp1HyKopEP5SBv/Lplj889MUT5k24SsSf8+w4Jy+bac0+1mWlALzNojIkigDHJJc2eKJ/5owDlRjPsgLiLqLJ64= Authentication-Results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1538.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3eb::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.20; Thu, 8 Jul 2021 10:35:29 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::d505:1bab:3e82:6d6b]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::d505:1bab:3e82:6d6b%4]) with mapi id 15.20.4308.021; Thu, 8 Jul 2021 10:35:29 +0000 Date: Thu, 8 Jul 2021 12:35:28 +0200 From: Juergen Schoenwaelder To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel Cc: Andy Bierman , "Rob Wilton (rwilton)" , "netmod@ietf.org" , Benoit Claise Message-ID: <20210708103528.6ezr4v5qeltinvmv@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , Andy Bierman , "Rob Wilton (rwilton)" , "netmod@ietf.org" , Benoit Claise References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> <20210707192534.4emim5a36zyqrktc@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ClientProxiedBy: PR3P191CA0015.EURP191.PROD.OUTLOOK.COM (2603:10a6:102:54::20) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR3P191CA0015.EURP191.PROD.OUTLOOK.COM (2603:10a6:102:54::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.21 via Frontend Transport; Thu, 8 Jul 2021 10:35:29 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fde01a48-9b4c-4f0a-2d8f-08d941fc1b3a X-MS-TrafficTypeDiagnostic: AM9P190MB1538: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:3044; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: XeekoMXlBJqFxUfszfbPIvxCdQuOGg+fAAESCU0mYcq+XqCP4Hf72z3adRf56o3Vx6gEfOBpXZhKhdOKXfl9Atyv/HHXfhpCdt++noQlFXx87gM8j1r0XIwbqXsDoM6insVS0r77jWD96JS0fSKeI4C5wLHMtO6+vvUU/zH5OeNp2Ed40dp8Ja4YnsV3pMnNEB6xjtXwOYPMPK6Ba4xsJ0gOEWru05xE0gvsi4DlHZ7ec1HNRDkDplyp6noApRrKdvqyHU5X+ZMxJJ8vSpySUEKv54h9GxF9S4gm/jMvtu+U8P4bBFLyQiam+nqqdE7q50iZ4ulInExgoQyQNqs2xZGD37SCP9x23Mp1EAHCnN0VeTutX4MuIdLcTgIUf26/QxkZ0Gr/pmYr28mQbozgEWPY4A8U2Rp2zK7PjliXZOR3uTm6FM8gq97CtksdhQ2nWDQYjpDUcQgsjZXYBwuSpVNlJ2g9bDFvQZG3D8kpkF1EFRCXWhOJI19eWqjSFuhntkLKPVPFi9CJPzpBTsvAR+M0NNn47z61Dhr2gav8OFqtFxK+tRP8M9YSt2HRPU5wfjKX/ktftCJ6bhbTj7TfbO7/RFO+s8WhbQC51wGlF2BJVibOyqkhFrRaa5GJIYfBz+ChZAvrfAf6dAdEC2fpDgUK2h3FFDW+DmiAIBIWqhyZ3dxRKONaj88R4eKZIU8OtLKtbjko4J1vHL0mgwgEGL5fOZ9IPNjP/osqVWHamtMFAAI1s3YaM7ia8BoMKHmO7MjSLR9L+CPpEkgFtvxmfTJOKrJTSdht2Vob/yOsPGU= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(346002)(136003)(366004)(39850400004)(396003)(38350700002)(86362001)(38100700002)(786003)(8676002)(66574015)(3450700001)(4326008)(6916009)(6496006)(478600001)(316002)(8936002)(54906003)(83380400001)(66476007)(53546011)(5660300002)(52116002)(66556008)(66946007)(1076003)(26005)(6486002)(956004)(186003)(2906002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?iso-8859-1?Q?aJvFQ+NKDjpKhyUm0UWL95VYJ4Vt/MYmHalG+FvgbJMYsJ5ttEzKMLXlMI?= =?iso-8859-1?Q?emoWUZuLAojxO+u/g+MEMTbCqrZHa+qJLyEfQ7hh9qr0/XKXdxjwpktIq+?= =?iso-8859-1?Q?ya7CuPYQygMF5/jyU2ss6GMPWyET+E9w7cs7b5nIFZ0bMgqOlM3n2SYDLv?= =?iso-8859-1?Q?welU/Ej0XAa6CHIKc82zi1oMyzaqUTi79+zMX3ODVWgAePFhx1YTXxzAvw?= =?iso-8859-1?Q?9auVobLeUEkfSIcbONw+4EaQblZYJIKvihRM7QDr0riQuYTejTw78YAlgM?= =?iso-8859-1?Q?jRSA8eLkJyjhtKwCGl3bBcQu4suP89nAkqS14lKo7JnEhn5O70eVL0BE2f?= =?iso-8859-1?Q?Xc2noJrGwM7QRHzmaZSnOpkncjslFN0fpXmnVw53t5BBHEQtWKPJWBwwc3?= =?iso-8859-1?Q?9Xv/0U4rRRWThCGhK6+R8M09sjtFVEGaHBBC2bRMlVttFy80U0wlR/5mWt?= =?iso-8859-1?Q?rsq+eLYYs18msUSCmAjDqndeq7ITrIRFgXmn78l3srC5D9J4eznaxkvpd9?= =?iso-8859-1?Q?BJu4a2RpAvr6PHz/nb9K1QOJT59mWh2AxAUHt8SDtW4e6E90WN4mNQBJ0U?= =?iso-8859-1?Q?a83+eJls1lsrBdSCY9IKTHXGpaPfheL4Fg5YVabOSn98KCvWA0frv0zuyX?= =?iso-8859-1?Q?cehKeCLEaF8+RSJVsR2ff9L6CIrMcD/rEtVzelsdIRNTZMek5s2dwBB1QL?= =?iso-8859-1?Q?lZ11ArB2JYZbMh3WF+iGiMoqSe6fatYjlUUKXQTCd7iffp7cy4zoCi2xu8?= =?iso-8859-1?Q?m1nTV/rXpInKqB2I3cvbifzUyPiiY+iY6RZC7WglWuouCyi5ugNsldjs/x?= =?iso-8859-1?Q?OCBCIUUS0M2KdI7RVTxcsjUA6xMCQ1dR5h1ZH4HiVKyiFZRBev03Ge0Mhx?= =?iso-8859-1?Q?XCFr4+0rUw0Qk5AHb/Do1rE58xldTiByW8kkFpwYi3Wvgxe22tiSMDBzNw?= =?iso-8859-1?Q?3VO1zYwP330ygE/Cr7r6kxvjURMok/hUS1KXGBYqynLbnr8O322G94NmxC?= =?iso-8859-1?Q?AT0/1bs9SeXJncbVe4ifKhIoCqOje8Px5MSxxagOid7V8vQ7J5LymzIu3H?= =?iso-8859-1?Q?TuQRnjxjv2AzVz2hMNigxN7v+X3oUkJkgqcyB721H++4HP6KnrwZOC0Iro?= =?iso-8859-1?Q?7TKdJy+fjnVc6RsxxI0FOf6dh3+erckrP+Ar2S6MW77y3k5FmtqEQhhZoh?= =?iso-8859-1?Q?T+ndM1gKqa11RuUJbx5dWd+24kUPpEAoAZ6WuVF2P2rL6/iewlfWy0k0uD?= =?iso-8859-1?Q?yR1Fi1bX2bz/Q+85Rwi6np83A0HFgCe5Hhgi8nzoFKngPEdeXdzZ971d3O?= =?iso-8859-1?Q?3g9IcY9OoHLNe+kGKjEs7uvsbOozxtKZaGxTwJf5f7qAGQrp0z3vsAQCsC?= =?iso-8859-1?Q?xE0rbp7nxm?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: fde01a48-9b4c-4f0a-2d8f-08d941fc1b3a X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2021 10:35:29.4983 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: sU0cupBxWW5FJ3NNiNvgiXiLFzQoW4wJ+lGnbaZPfvtsS2KOw44RcwSS7XaUEgCIqmh5bRN2HzYrdJx2jCqdXs5pfUvDdjAKgi5bRaNZvTM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1538 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 10:35:38 -0000 The question I asked is "how much simpler is it and does that saving justify the introduction of a new rather limited format (that may risk to grow over time and become a second citizen)". So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports from ietf-yang-types (at the time of publication that resolves to ietf-yang-types@2013-07-15. So the YANG Library instance data would roughly look this (please correct what I messed up, I am writing this by hand): m ietf-netconf-acm 2018-02-14 uri1 ietf-yang-types uri2 s m running s Yes, this is a bit longer, but it also conveys more information (note that your datastore leaf in the header would likely not be needed anymore). I am concerned that we start creating another format to define schemas that is very limited and people later come with extension proposals to address some of the limits and at the end we have multiple formats to maintain and deal with. So the question is whether people think this is worth it. (Note that the felt overhead goes down with every additional module used by your instance file, so the example above is really the most extreme case. And if you have many modules defining NACM rules, then you put the above into a separate file and use the URI to point to the schema, no? /js On Thu, Jul 08, 2021 at 09:27:52AM +0000, Balázs Lengyel wrote: > Hello Jurgen, > Inline: > This complex form of inline was requested and not objected earlier by other > reviewers. > Based on Rob's and others' proposal inline will be simplified to use only > ietf-yang-library@2019-01-04 as you suggest. > > Simplified inline: > In Ericsson we already use simplified inline a lot, it is the most common > format. > If you are providing data only for one or a few YANG modules and don't have, > > don't care about features/deviations it is the easiest, shortest method to > use. > Our most common use-case is to provide preconfigured access control rules > for new nodes. > When a YANG modeler designs a new module, he immediately provides a set of > NACM rules > for the readOnly and the SystemAdmin roles/groups. > In this case you only need to specify "ietf-neconf-acm@2012-02-22" No > deviations, no features to indicate. > Regards Balazs > > Regards Balazs > > -----Original Message----- > From: Juergen Schoenwaelder > Sent: 2021. július 7., szerda 21:26 > To: Andy Bierman > Cc: Balázs Lengyel ; Rob Wilton (rwilton) > ; netmod@ietf.org; Benoit Claise > > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format > > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote: > > > > > Inline method is needed, if you want to indicate that the file was > > > generated by someone who uses some YANG modules with deviations and > > > some features are not-supported. There is no way to indicate > > > feature-support and deviations with the simplified-inline method. > > > > The Inline anydata solution is very heavyweight. > > Before the YANG library there was a simple URI that is easier to use > > and takes up much less storage. > > > > The inline content schema is super generic since it supports an open ended > set of schema defining modules. While you can use it with say > ietf-yang-library@2019-01-04, you can use anything else as well. In other > words, two implementations supporting inline content schema may not > interoperate. I do not think there is a schema format that is mandatory to > implement for inline content schema. > > So here is my assessment of what we have in terms of interoperability: > > - Simplified-Inline comes with notable restrictions, interoperable > - Inline is an open ended content schema, not necessarily interoperable > - URI method pushes the problem to another instance file, interoperable > - External is by desing not interoperable > > On the server side, we have YANG Library. Perhaps RFC 8525 has some > complexity that is useful for supporting large servers with multiple > datastores and not needed for small instance files (I understand that an > instance file is always tied to a single datastore?). > > To me, it feels that reusing RFC 8525 design is actually a good thing. Being > able to dump a live server datastore into an instance file seems like a very > valid use case to me and ideally this is possible without having to rewrite > the schema part. Well, you could go and trim unused datastore schemas and > from there unused module sets etc but that can all be done by an external > tool trimming the schema part, i.e., it does not need to be done by a tool > that just dumps a server datastore. > > What is the actual value of simplified inline? How much do you really save > compared to the simplest equivalent RFC 8525 representation? And does that > saving justify to start engineering another schema specification format? > > I guess my choice would have been to just have > > +-- content-schema > | +-- (content-schema-spec)? > | +--: (yang-library) > | +--: (uri) > > but others obviously want much more choice (but lets note that everything > sits in a choice, so everything is extensible in case other schema > definition formats are out there). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > 15-19e5dad375af0063&q=1&e=3637406d-f774-4073-80ee-a7431111e9bc&u=https%3A%2F > %2Fwww.jacobs-university.de%2F> -- 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 Jul 8 03:58:48 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D04B3A077A for ; Thu, 8 Jul 2021 03:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.896 X-Spam-Level: X-Spam-Status: No, score=-11.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=bHTmrYxr; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=XrB5bjxW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzQI5LahvvyE for ; Thu, 8 Jul 2021 03:58:41 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E3F3A0779 for ; Thu, 8 Jul 2021 03:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8541; q=dns/txt; s=iport; t=1625741921; x=1626951521; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=sP+TI52a2LPyWnahUQ9K+dPZotStKjXewnUKfmLqhKs=; b=bHTmrYxrxvHXrU2dNqs+qhfEE5zhW2Ftaz8yOdQwNRFObVJwTElLDYfP /UX3x/qJmb7dNuubkZDkb1S3Lls4yAu9VcEISgFoRQPJAVmVPMVDcDGib Xm+MUxmri9CNNbIqkcY/jKdZ3Vw9kcVZ6pOUmq4/Eez6m9uPrSrb6+m89 I=; X-IPAS-Result: =?us-ascii?q?A0DpAQDA2eZgl4MNJK1XAxwBAQEBAQEHAQESAQEEBAEBQ?= =?us-ascii?q?IFZgVNRflo3MYgQA4U5iF0DmieCUwNUCwEBAQ0BATUMBAEBhFMCgnYCJTgTA?= =?us-ascii?q?gQBAQEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBAQEBaIVoDYZFAQEBBBIuA?= =?us-ascii?q?QE3AQsCAgIBCA4CAQQBAQEuGxcdCAIEAQ0FCBMHgk8BglUDLwEOmwsBgToCi?= =?us-ascii?q?h94gTSBAYIHAQEGBASBSUGDJhiCMgMGBYE1gnuCcVOHKyccgUlEgRVDgmI+g?= =?us-ascii?q?mIBAQIBF4EdEQIYHyaDBoIMIoIrAWtuGA8BChEOAk8OHhYHAyoVBDUGJBGdd?= =?us-ascii?q?oErnWAKgyKKKJQbEoNji02GO5BTlXuMLpMiKSGEZQIEAgQFAg4BAQaCPiKBW?= =?us-ascii?q?3AVO4JpUBkOgRqNBRmDVzOEYYVKczgCBgEJAQEDCYgKASeCHwEB?= IronPort-PHdr: A9a23:0cB9DhxucFfle9LXCzMrngc9DxPP8532NwUS4IFilrRPbKm55JX+L QrT6KYlgFzIWNDd7PRJw6rTvrv7UGMNqZCGrDgZcZNKWhNE7KdenwEpDMOfT0GuKvnsYn84F c9FXkQg4ne6L0VPA8fidhvery764TsbAB6qMw1zK6z8EZLTiMLi0ee09vixKwVFjTawe/V8N hKz+A7QrcIRx4BlL/VZ9w== IronPort-HdrOrdr: A9a23:HktNWawSiS34tUYRmZcLKrPxquskLtp133Aq2lEZdPULSK2lfp GV8sjziyWatN9IYgBepTiBUJPwJk80hqQFn7X5Wo3SHTUO2VHYYr2KiLGD/9SOIVyEygcw79 YET0E6MqyNMbEYt7e73ODbKadb/DDvysnB7o2yowYPPGNXguNbnnpE422gYytLrXx9dOIE/e 2nl7N6TlSbCBAqR/X+IkNAc/nIptXNmp6jSwUBHQQb5A6Hii7twKLmEjCDty1uEA9n8PMHyy zoggb57qKsv7WQ0RnHzVLe6JxQhZ/I1sZDPsqRkcIYQw+cyDpAJb4RHoFqjgpF591H22xa1u UkZC1QZvib3kmhOl1dZyGdgzUIngxesEMKgmXo8EcL6faJNA7STfAx376wtnDimhYdVBYW6t MX44vRjeslMTrQ2Cv6/NTGTBdsiw69pmcji/caizhFXZIZc6I5l/1UwKp5KuZJIMvB0vFtLA CuNrCq2N9GNVeBK3zJtGhmx9KhGnw1AxedW0AH/siYySJfknx1x1YRgJV3pAZNyLstD51fo+ jUOKVhk79DCscQcKJmHe8EBc+6EHbETx7AOH+bZV7nCKYEMXTQrIOf2sR52AhrQu1A8HIWou WPbLp1jx9GR6veM7z54HQQyGG+fIyUZ0WY9v1j X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,222,1620691200"; d="scan'208";a="741581062" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jul 2021 10:58:40 +0000 Received: from mail.cisco.com (xbe-aln-007.cisco.com [173.36.7.22]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 168Awd5u006623 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 8 Jul 2021 10:58:40 GMT Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xbe-aln-007.cisco.com (173.36.7.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 8 Jul 2021 05:58:39 -0500 Received: from xfe-aln-005.cisco.com (173.37.135.125) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 8 Jul 2021 05:58:39 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 8 Jul 2021 05:58:39 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OrKlRM8/VfvMurELPH8025tkrZG5hipEU4/FNW39pROS55nkypDHvwAD0uUvAUkBP7mWGcr0EYm53tYnbJSjlCHiwhAtHs78qFFtqzlevnLDAJTjPG9CnUx2pqrnUXmm0Cgr0ja5ahGr0aaBfuby+LH4YRymBwmylgFo/AVodFOcIeYaekB6IFsV+ygJAIj740ezsgvP+B7h5RnPHYMWFbdy0uPxTN+ExfvgjB2RhiG6cBZZy011Pio+9n44OUMYxhATucX3ZcSUsdwG071vQw78XD1onnSFrU2qBQ2CZCiorjuTMWFX8QPK0qkelHif9uThlP1yGYCZAaSTzKqaGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JLh6lbSGX2lpChI2bW2cL0ri2KKTZNcXsaAIoo1JBTA=; b=hbKQOYLu38eypQL1/xNp47w5qcMDBG8NQog92uqlrCKKABePXrMKpc3IztyqCzlrZ0TbCGydQyPP5qgw7vUFRMNPUx9jYOPN0ufmprX3uqwvc+nxW0wyRZL5LtsSRl4OY9++JRu/nXw5tAg0ZFXexZqb0l0QJnkLUN2ragz5FAht8CV4RDcsdEgr3YBk6j+9l9sAnSwevctp45qTT7+D/eXcIMKpi0S+dd+ZNFf501PuPDdlssYUQcCOHbZPc/sUscjI3FRQo39PQ8ostxkrBWjjfk5+I44GATodHbY0tNJBNG9bpunlxVCzL5/x9gE0M9vfCkehyp7Fu/7A9FG/Tg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JLh6lbSGX2lpChI2bW2cL0ri2KKTZNcXsaAIoo1JBTA=; b=XrB5bjxWWJ/jxVyLi0fu/w1l3TUjob25E43nNMehc8QCr/Ckw+q5tswxaVrfSTIOLPkBWJCmt+jHAWQdEekc7UVH+knGs7ZhZ6+/Mj+z2CuNqBZFSriGvRcPboXo9230M/jtPVbuFDiiOeJieDc1Bw0qKAZQQEpYS3qEfZz34t8= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM6PR11MB4531.namprd11.prod.outlook.com (2603:10b6:5:2a5::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.22; Thu, 8 Jul 2021 10:58:38 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12%6]) with mapi id 15.20.4308.021; Thu, 8 Jul 2021 10:58:37 +0000 From: "Rob Wilton (rwilton)" To: Juergen Schoenwaelder , =?iso-8859-1?Q?Bal=E1zs_Lengyel?= CC: Andy Bierman , "netmod@ietf.org" , Benoit Claise Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAPXLWAAAIT0wAAAIMhAAAAy2eAAAJlLwAAGf35QAAVpNcAAAKQ2AAAHRePIAACr5QAAAAUxvA= Date: Thu, 8 Jul 2021 10:58:37 +0000 Message-ID: References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> <20210707192534.4emim5a36zyqrktc@anna.jacobs.jacobs-university.de> <20210708103528.6ezr4v5qeltinvmv@anna.jacobs.jacobs-university.de> In-Reply-To: <20210708103528.6ezr4v5qeltinvmv@anna.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e1ecf172-576e-47fe-ae7f-08d941ff56dc x-ms-traffictypediagnostic: DM6PR11MB4531: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3383; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P5SvQomFdfFXBxJ6jHsPAMcnLEXgi5FdCd97PSFYTL4mIC17XxdNHiwvUzIOhI6+6S9Tc7rOL0ARlyglycUvEffhUM0D5xv6zJZl9mqZVRDMC3miR/FRc3F/tanOxLKYSge5S3mhreAFJzA8asDMc+LrZ/gdOWA1yRb3HNe+pXRYpL4Zz2C60Vx+5k1k/cvLyIh3QG6W6oeSKFNpZQPHcem+Wy34OY4Rbpj/iunOgqxOiZtVqk+7L8cj1IPDVWJ+8Ws0Rah++rSVikSw7/F02rgf9fHewWJhWLuaSoT0TK2zG+BYUMZhMJCQv+vLWhfkVQJ8IXLNjeoH1jK41Ek8ibcpu0niwe5EK6bNUsg8JzoelAsY24PntbdoxGuSSH9YJvd+6/mL+AqLEMFzoYwA0BjxSjt6qnX3d1+cEASPmMeYhB4rgWAIPxOyMCucfyzooFgzAUv8a8u0O/tsNDnrYcf+jysA6NWMROBc+hmFcBMgEfEUUM3gtdxVA2Q0k9eQpKFZKpqkTWq7Y3SkTa4gXuhDeupmBqnhy1DLHxP7PmFi+GU+vGWNhcu1uc7c1hPE8++U0GQp3esOAeyLw5POSh7PWOJXJBzB1BCEdGBxvSkX5/MGkSshW0L9vpe2/l8Deqv0GCM5sFm4AljALBYQp5v6gj3gxiMiQWo43+5AFJQk/7bPnTZktfMbt08f6OBrmmjl0uL77VNRjUYyMby9RIKe0NMGMvGJcgP+24DDwwNhx+WL6zSLz3LoEk1fH1BOmSk3Or1t386DjH+EdQITRQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(396003)(39860400002)(136003)(376002)(54906003)(110136005)(7696005)(4326008)(6506007)(53546011)(478600001)(9686003)(66556008)(66446008)(64756008)(966005)(76116006)(186003)(5660300002)(66476007)(33656002)(52536014)(66946007)(26005)(86362001)(66574015)(83380400001)(8676002)(8936002)(55016002)(316002)(38100700002)(122000001)(71200400001)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?bcq0V+wbnLbi/jwzbbNO41ZLmc0UWja34jxS/pZZzRYbC0v+chIJI4E7hQ?= =?iso-8859-1?Q?JvcR5e94p8/EGI81pambBku2c4+rHVw8JXrvs+/PlUYIFQM8avSIIzXnhX?= =?iso-8859-1?Q?Q+PBAb1PKKnIax1d2QHoYYemtpk+q0C5eTLLSYhI4vq1BjU6e+XBodtv5B?= =?iso-8859-1?Q?a0vMMxDDFiNg0nWE/rrjVMTOsBsQqVQwpDH2mhBB0pcS1hC5oY5uxPdN9X?= =?iso-8859-1?Q?VvWDkMwot4mf2exDaJB2A2e9ifol+Fe9gbORctSQYhyOaqZuXwDQVQ88HF?= =?iso-8859-1?Q?DCRlbEZdF4nmMbQW/Rbbuy4DxwdWHXdnYw/LlpU8hZB7p551584SQS9z4y?= =?iso-8859-1?Q?2JjLiCBUWsz7TBk/ElTW53Xy6VomlKDZzYRLnaqWICGDakj7UflN/P/GNI?= =?iso-8859-1?Q?sc8gfKQV2YIb203BQffrkhnODzE1i0Cwjvoko5jp2mgxV+W6QkeNThrwSo?= =?iso-8859-1?Q?ZnanyDbR4tH9YbbU2QFEeN0dneSLSm2Z0b0A4H2Jif9vvu8EmQ7A7kkU/c?= =?iso-8859-1?Q?SGGuRnFzgPAYYirDfTiRMME/WZ2D9HdkI10WfqyBPOAYjA70l6jppZ91/P?= =?iso-8859-1?Q?ehD1pKRcMrcIAdUzjwBDaw/R3PH1yxMHkTNL5E4LnbukasokN61dGrN/El?= =?iso-8859-1?Q?C+/iscM62m6QLjWCTw7AOfmhEYKDe0sDs98nFB3YYLWJt5qgIrZgjJEGaF?= =?iso-8859-1?Q?I09E2v1EytlM52sjDhAL+Oavi+fQgZXKjnFJ20N4fNa+fTQnqkRtcBBrvF?= =?iso-8859-1?Q?DvciNSMW8Pj53LiDnfbiV40pqLumiwoDuSaaDhkAbWClbDrQKeEW2k0lz0?= =?iso-8859-1?Q?sqpZLvv8AE2dpjsUSvT76rxitYiANTvxoPL59POkOnXwsnNNoVUnsE5udL?= =?iso-8859-1?Q?rQjd5Hw954NydoMoLXZDcLctH9YE/daJDOMJQGuk55Yea8qranLcUYOC5X?= =?iso-8859-1?Q?yGW7dxDUFaFpc1VIoM6GGgLPNerJCvGuM1DpEa1nm0wztUkWwyK4cSufYr?= =?iso-8859-1?Q?48sPKSZMcKAHRhPC2YxJnAc0PmIATkuyHe7XKdZZN929WzxrUMOtrlHz4z?= =?iso-8859-1?Q?ydvIe29cr/x+FU0enKHoaCk7wxP4epkgvPQg8TAebyIRc+7T6nTPqV+YNH?= =?iso-8859-1?Q?Xu4Pnx3zgDLSeItqkH130igdUGOwz1ZQ8FkkDnHv9XKrCFt2i7ucozj6km?= =?iso-8859-1?Q?GlhGm1coSa5GP+cDQ6pWOd3eacfaBHeDCSqdZn9z35MYRDPxyy/MRV4EOL?= =?iso-8859-1?Q?eFclCTJU6XITmh4LEAjKlvMAFe6p9PuzAokoHIzg5VQwXbiKTqWm8NsipU?= =?iso-8859-1?Q?tcvKDIVtzaHCQtxAQQwg6icL7ytoh4GSxV3Iv6zn3D2Hk7nz+Gk/2KXZym?= =?iso-8859-1?Q?u0uEL1FGeh?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e1ecf172-576e-47fe-ae7f-08d941ff56dc X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2021 10:58:37.8200 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9BfFrLg0LGfQWp+U47Z0cvr7T3SBt5oGZfdcPkYWuDkWgeDms10gIUzWfSzKRIsYmuC+Vpg6y8kF2g3hlfZJPQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4531 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xbe-aln-007.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 10:58:47 -0000 Hi Juergen, I believe that having the simple form is worth the extra complexity. I think that you are right to be concerned that it should not expand into a= separate parallel format. Overtime, I would like the simple form to be ab= le to use revision labels instead of revision dates, but beyond this I thin= k that it should just be a flat list of modules that defines the schema. I= f a subset of features, or datastores, or import-only modules are needed th= en the YANG library version (or URIs) can and should be used. Another example of where I expect it to be useful is in YANG packages. Loo= king at the examples at the end of https://datatracker.ietf.org/doc/html/dr= aft-ietf-netmod-yang-packages, then some of those files (which currently ar= en't defining any schema, but should) would almost double in size if they r= epresented the schema inline using YANG library, which I think would make t= he files harder for humans to read/parse. Using URIs could help mitigate t= his, but then we would need to find a place to publish the file containing = the YANG package schema (presumably somewhere in IANA), and it not obvious = to me that adding the dependency on the URL is really as helpful. Regards, Rob > -----Original Message----- > From: Juergen Schoenwaelder > Sent: 08 July 2021 11:35 > To: Bal=E1zs Lengyel > Cc: Andy Bierman ; Rob Wilton (rwilton) > ; netmod@ietf.org; Benoit Claise > > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format >=20 > The question I asked is "how much simpler is it and does that saving > justify the introduction of a new rather limited format (that may risk > to grow over time and become a second citizen)". >=20 > So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports > from ietf-yang-types (at the time of publication that resolves to > ietf-yang-types@2013-07-15. So the YANG Library instance data would > roughly look this (please correct what I messed up, I am writing this > by hand): >=20 > > > m > > ietf-netconf-acm > 2018-02-14 > uri1 > > > ietf-yang-types > uri2 > > > > > s > m > > > running > s > > >=20 > Yes, this is a bit longer, but it also conveys more information (note > that your datastore leaf in the header would likely not be needed > anymore). >=20 > I am concerned that we start creating another format to define schemas > that is very limited and people later come with extension proposals to > address some of the limits and at the end we have multiple formats to > maintain and deal with. So the question is whether people think this > is worth it. (Note that the felt overhead goes down with every > additional module used by your instance file, so the example above is > really the most extreme case. And if you have many modules defining > NACM rules, then you put the above into a separate file and use the > URI to point to the schema, no? >=20 > /js >=20 > On Thu, Jul 08, 2021 at 09:27:52AM +0000, Bal=E1zs Lengyel wrote: > > Hello Jurgen, > > Inline: > > This complex form of inline was requested and not objected earlier by > other > > reviewers. > > Based on Rob's and others' proposal inline will be simplified to use on= ly > > ietf-yang-library@2019-01-04 as you suggest. > > > > Simplified inline: > > In Ericsson we already use simplified inline a lot, it is the most comm= on > > format. > > If you are providing data only for one or a few YANG modules and don't > have, > > > > don't care about features/deviations it is the easiest, shortest method= to > > use. > > Our most common use-case is to provide preconfigured access control > rules > > for new nodes. > > When a YANG modeler designs a new module, he immediately provides a > set of > > NACM rules > > for the readOnly and the SystemAdmin roles/groups. > > In this case you only need to specify "ietf-neconf-acm@2012-02-22" No > > deviations, no features to indicate. > > Regards Balazs > > > > Regards Balazs > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > Sent: 2021. j=FAlius 7., szerda 21:26 > > To: Andy Bierman > > Cc: Bal=E1zs Lengyel ; Rob Wilton (rwilton= ) > > ; netmod@ietf.org; Benoit Claise > > > > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format > > > > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote: > > > > > > > Inline method is needed, if you want to indicate that the file was > > > > generated by someone who uses some YANG modules with deviations > and > > > > some features are not-supported. There is no way to indicate > > > > feature-support and deviations with the simplified-inline method. > > > > > > The Inline anydata solution is very heavyweight. > > > Before the YANG library there was a simple URI that is easier to use > > > and takes up much less storage. > > > > > > > The inline content schema is super generic since it supports an open en= ded > > set of schema defining modules. While you can use it with say > > ietf-yang-library@2019-01-04, you can use anything else as well. In oth= er > > words, two implementations supporting inline content schema may not > > interoperate. I do not think there is a schema format that is mandatory= to > > implement for inline content schema. > > > > So here is my assessment of what we have in terms of interoperability: > > > > - Simplified-Inline comes with notable restrictions, interoperable > > - Inline is an open ended content schema, not necessarily interoperable > > - URI method pushes the problem to another instance file, interoperable > > - External is by desing not interoperable > > > > On the server side, we have YANG Library. Perhaps RFC 8525 has some > > complexity that is useful for supporting large servers with multiple > > datastores and not needed for small instance files (I understand that a= n > > instance file is always tied to a single datastore?). > > > > To me, it feels that reusing RFC 8525 design is actually a good thing. = Being > > able to dump a live server datastore into an instance file seems like a= very > > valid use case to me and ideally this is possible without having to rew= rite > > the schema part. Well, you could go and trim unused datastore schemas > and > > from there unused module sets etc but that can all be done by an extern= al > > tool trimming the schema part, i.e., it does not need to be done by a t= ool > > that just dumps a server datastore. > > > > What is the actual value of simplified inline? How much do you really s= ave > > compared to the simplest equivalent RFC 8525 representation? And does > that > > saving justify to start engineering another schema specification format= ? > > > > I guess my choice would have been to just have > > > > +-- content-schema > > | +-- (content-schema-spec)? > > | +--: (yang-library) > > | +--: (uri) > > > > but others obviously want much more choice (but lets note that everythi= ng > > sits in a choice, so everything is extensible in case other schema > > definition formats are out there). > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > 866038973a > > 15-19e5dad375af0063&q=3D1&e=3D3637406d-f774-4073-80ee- > a7431111e9bc&u=3Dhttps%3A%2F > > %2Fwww.jacobs-university.de%2F> >=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 From nobody Thu Jul 8 04:47:51 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4873A115D for ; Thu, 8 Jul 2021 04:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUgrCw9B4SkH for ; Thu, 8 Jul 2021 04:47:41 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2076.outbound.protection.outlook.com [40.107.22.76]) (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 2E7713A115A for ; Thu, 8 Jul 2021 04:47:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I7a2OiY3GUX4NAO60xOAUHiLg3uGUuY895zXclqdIrCP9Qm8k0FL6Xwr2YcAcZNrqrVWmHr4zx9/Zwd1JdFOcJrJ3UURWhLPKVYZX2X3WStJpJ0IE88Qj3Jmnl5JIJODw7sY9XoQ7hANl/VzW8roIoaPHTRcIi8PCe/G/qNEjQDdpajZFXMVK7IGFjdPfJ/oT3s/BBv4zupek5x4W8nWYpeI2hNpge8Q8bVaox60i8b9P6KsDKEWa/sQVCvcYdrslXm+ejjZczh0p56iu18tNWup0NnF4zRIfwghWr9KJ8/FDCnciAxaLdvQZPKF09yhZ3PH+YC0uJuJkEEgsnBlzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YchMQNSCT46eyxUpLMAfL67pygYJsD0MNpjSy4QIQM8=; b=TAd3mkVVK9+dIi+xpVpbR19SBQ+jMmbFNA8ZzFFRf7Hi9Vtz0GqO+T9ltKipFN3v9VYA+B1cYJVUfIdrl2RP0GycJ8ff8D+xbIKVMxdtWbbf072d+177HS6kyq1ARKhVVupcNcRMYFFw4mdzN/dUV0DiFLLOU/og+sYgc87p0lTwWOYUtvnrwb64gf4K3uzb+mmhnKB7NDPD+CsRIi/BnlmnQs3VAKo8S6gLaa3vnOFtef7FQmq41oAlMwMqPN8iHnSrPG2DGKscvTN479WsszdQ93J2QIXBdRVtuVYsCbejRhfdhYvJIytZgBUFKCUwZGVGC13Hciw/K+imtbeEaw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YchMQNSCT46eyxUpLMAfL67pygYJsD0MNpjSy4QIQM8=; b=ucrjUe+ToinSrKMQ9MXI8RLt6kEGIcZu5qweu9Ardeu4n3T/t/lLaRNXhQ7F+ZlpyGMiPJCB+5A+Z/QVoiRSQZKmFi2QrKkMfYWNz0GNvSDbYBcIadJjWkkgGJ8y97p33JhI/K7SlwUVEXn1YDI8W7OAYV3UqiBrhcx42eGz5Fk= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8139.eurprd07.prod.outlook.com (2603:10a6:20b:36e::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.14; Thu, 8 Jul 2021 11:47:33 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4308.018; Thu, 8 Jul 2021 11:47:33 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: "Rob Wilton (rwilton)" , Juergen Schoenwaelder CC: Andy Bierman , "netmod@ietf.org" , Benoit Claise Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAPXLWAAAIT0wAAAIMhAAAAy2eAAAJlLwAAGf35QAAVpNcAAAKQ2AAAHRePIAACr5QAAAAUxvAAAke7IA== Date: Thu, 8 Jul 2021 11:47:32 +0000 Message-ID: References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> <20210707192534.4emim5a36zyqrktc@anna.jacobs.jacobs-university.de> <20210708103528.6ezr4v5qeltinvmv@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2f368e7e-c060-4dee-3352-08d942062c88 x-ms-traffictypediagnostic: AM8PR07MB8139: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3383; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HKspUPwqhOQiv9iD87Nuiea1Gz2tm6YiTaTJZy7mClrpEADhuqj806EPdKfEvtGluZqdf1++FBm3O/1lUeRo2ihgi9ihpq+aBDfDKaMVpOVV4ZkfDrV3jgg1CuTRDKA/8flUVKezhRszT54k/x1MUUVqeacNDtArPHLI93KK3fH8qUVOpBSri8zn1sI1Td3ihS8m1JqrN6NY2zP9i2UAlP1wsBAfahvKhGXXuCvILMbJsEmccLFjEUYO5aGHpAX/2pFiykDNJCugrbQc8n5EMAnO1J/m+XajL293nM3xV9KOYERoAJHBVUJgp7yAIgNufoMTb+aRazha54Wb2mPoecQhZTU+iLHHKsm0W549vPS329RsP/AtXl07Cgc3QCe6GqcTyN+Sl6Kb8h6ABXh+4879cSpdynOFzpzWccnlzHT91KlOZT14qPJHuesz9QefHl5FITSsav9QxDUfha5ViZAoWBL5MtvFRSbCLeoxTmKZp06up/SfwUQUdo2Tc2FPvNRyA9G+wRBc5jggjSubE0Zw+c0P3CFYT46CvKYC/nGMWtSVrTH1SXcUZmabY7hGw9IsezsvXGdOZA0nyta9/wAPHRF/d0MpXekEKhEBi8Hii4K0TVxYHcERiPsROFsl3PVVfzsDsV2Ra+6hgn6z2h7iprvESjEANQXNswMNmbtDIag4nbpxXlTM+nE+ck9KEzGexvKR8+JUaOqOSkuSGUV5rzgmYLDoMeHfI4Kgz9AYheBUzcrI0RYjpbN8T2mtNnIOHosN5Fi8DLqe0S414A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(39850400004)(366004)(136003)(346002)(66476007)(122000001)(26005)(66556008)(64756008)(186003)(9686003)(5660300002)(83380400001)(478600001)(33656002)(66574015)(55016002)(8936002)(66616009)(316002)(54906003)(66446008)(7696005)(966005)(110136005)(99936003)(4326008)(38100700002)(6506007)(66946007)(2906002)(53546011)(76116006)(8676002)(52536014)(71200400001)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?S0PGbOYEO1ssSkBsrf0WJu0pBcHKV/Tz8GXKroEyCwDf8NuHSS6qjvl+ge?= =?iso-8859-1?Q?vqoe2vID+PVhKR1YBnmWptRUIDREB2RdFfqIf7+OzkNMbSEvvVF5xCE+uT?= =?iso-8859-1?Q?iEbisM0K1UvFNa22Rj+pWohSqQCU2WURPYbLPz1abxtOpTX3C2UdfgpCId?= =?iso-8859-1?Q?yIUHWSEpk/BUU92ekjB5SmEYaDrQsTxYh0WTh5Yon8PZr1bEbhkB7GpTvi?= =?iso-8859-1?Q?+XnRXt4VFhco9jV1SmQgc8wZimnq+suDlBTyNAWxmWM67XLV2D2SWPeHeW?= =?iso-8859-1?Q?/7fHuceZnHM1+eYDzizulpom7yxtVuk6O/XyjdCbNdmiCpqgnUQJGpUoUl?= =?iso-8859-1?Q?HX4LAqax9H16TUgdWxIzuxdF3QWOp7cpbKOVKc0fXpmFc6mQFD7SqPLN4N?= =?iso-8859-1?Q?CZTQZGi2hKxR1AluVzR73PaTuHFGW53ar8YNKW6MJRi/4E3J9hTZHeTNem?= =?iso-8859-1?Q?BMOUH4zNtRv1xqurxLsKZUMJZTS89DDZhvqSd6453TRmvXv7/ncC5MHQWY?= =?iso-8859-1?Q?QHvJwHWCe8EoLr1Mypt6Z+udBJhiPZhKEvQWM2iu/o+9BU+GvdTIppCowa?= =?iso-8859-1?Q?Ftn7A7ctFe5ccxrC9FTRhKbiZ34bHJmNHPl1qMJKoV11zxJUXfybx45XD2?= =?iso-8859-1?Q?7hhPWrVwtaWrFuN3qqF9XWocDyWkMWUL5ewqjURNYshmsUIZqB1EfYnmoD?= =?iso-8859-1?Q?rX5GgmIrJoHCvOcCniRVljVXZsEq8b6FMRXG6sfPEU7F2fG9YK/QYyuVAM?= =?iso-8859-1?Q?+pFVw1CL2MQKPTmCAc/jK7acR1KjgX1kurgvaNP/SHjx/BO0t+d9NvBbzD?= =?iso-8859-1?Q?M/6PA8/5g2G28LlWgQpWhfwnVFKH5lpJii7m9fmm7k0yPgnz3hBFVnYNM0?= =?iso-8859-1?Q?ZeIv40d1cn0WyvAL/VumpNaSaeXqxFme8X/ETX1u9xk5h0FuODIGNsuaeb?= =?iso-8859-1?Q?c/IwCb9sJfQF+W3wU9lQ/BmN/+DiHIy2ZMsb905xbsVVTXiCSpIriKtq0h?= =?iso-8859-1?Q?JE58vv9OyXQrUrV3kPfeDsZiWgwy3pA1ntB1cFPmF5BM5e9qTZaoj8E2BS?= =?iso-8859-1?Q?rMfuD74C6NhjlWiA1jhc8udBFDcvJE7VR5xrQhsEqhr5jIjWLByo6sDZrv?= =?iso-8859-1?Q?fpVs3xjX3XJ1m5wxgSSW4+VLv4OhDPEl3fatZIKZZTnh64+uyrTJfTRqQQ?= =?iso-8859-1?Q?MWxYMkexcs5GY5Tgk6TX6jfVOQDjGaUBdFf6RuOry4dq/GRTf/Frw0S5vt?= =?iso-8859-1?Q?Ceo4CIWga0FPWyNBHb8WLWSsU/zZQCnOk2ROsHUZ6FusH+vh8UUaG7HXw0?= =?iso-8859-1?Q?87VSGQj+racQWHzqqmc2ckt25cJXwo5JQHicXMiRO6cxqo87/B0w+cddxK?= =?iso-8859-1?Q?idAQ+ydltl?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_04B2_01D773FF.CBB217A0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2f368e7e-c060-4dee-3352-08d942062c88 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2021 11:47:32.8550 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: AEKq6yHD6a05t1FLjph+YyxORNniA8EUg3r3V8Vy9IF7HfSBl+YS7F8ozNk2Zl+dg9bC5zmSGm1MTDiAYUDpe6Snj5QIoRh0NC40DbzAKwI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8139 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 11:47:47 -0000 ------=_NextPart_000_04B2_01D773FF.CBB217A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I would like to keep simplified inline. If I ask my developers (not = experts) which one do they want? I am pretty sure they opt for the = shorter/simpler one. =20 ietf-netconf-acm@2018-02-14 OR m ietf-netconf-acm 2018-02-14 uri1 ietf-yang-types uri2 s m running s Regards Balazs -----Original Message----- From: Rob Wilton (rwilton) =20 Sent: 2021. j=FAlius 8., cs=FCt=F6rt=F6k 12:59 To: Juergen Schoenwaelder ; = Bal=E1zs Lengyel Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format Hi Juergen, I believe that having the simple form is worth the extra complexity. I think that you are right to be concerned that it should not expand = into a separate parallel format. Overtime, I would like the simple form to be = able to use revision labels instead of revision dates, but beyond this I = think that it should just be a flat list of modules that defines the schema. = If a subset of features, or datastores, or import-only modules are needed = then the YANG library version (or URIs) can and should be used. Another example of where I expect it to be useful is in YANG packages. Looking at the examples at the end of https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, = then some of those files (which currently aren't defining any schema, but = should) would almost double in size if they represented the schema inline using = YANG library, which I think would make the files harder for humans to = read/parse. Using URIs could help mitigate this, but then we would need to find a = place to publish the file containing the YANG package schema (presumably = somewhere in IANA), and it not obvious to me that adding the dependency on the URL = is really as helpful. Regards, Rob > -----Original Message----- > From: Juergen Schoenwaelder > Sent: 08 July 2021 11:35 > To: Bal=E1zs Lengyel > Cc: Andy Bierman ; Rob Wilton (rwilton)=20 > ; netmod@ietf.org; Benoit Claise=20 > > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format >=20 > The question I asked is "how much simpler is it and does that saving=20 > justify the introduction of a new rather limited format (that may risk = > to grow over time and become a second citizen)". >=20 > So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports=20 > from ietf-yang-types (at the time of publication that resolves to=20 > ietf-yang-types@2013-07-15. So the YANG Library instance data would=20 > roughly look this (please correct what I messed up, I am writing this=20 > by hand): >=20 > > > m > > ietf-netconf-acm > 2018-02-14 > uri1 > > > ietf-yang-types > uri2 > > > > > s > m > > > running > s > > >=20 > Yes, this is a bit longer, but it also conveys more information (note=20 > that your datastore leaf in the header would likely not be needed=20 > anymore). >=20 > I am concerned that we start creating another format to define schemas = > that is very limited and people later come with extension proposals to = > address some of the limits and at the end we have multiple formats to=20 > maintain and deal with. So the question is whether people think this=20 > is worth it. (Note that the felt overhead goes down with every=20 > additional module used by your instance file, so the example above is=20 > really the most extreme case. And if you have many modules defining=20 > NACM rules, then you put the above into a separate file and use the=20 > URI to point to the schema, no? >=20 > /js >=20 > On Thu, Jul 08, 2021 at 09:27:52AM +0000, Bal=E1zs Lengyel wrote: > > Hello Jurgen, > > Inline: > > This complex form of inline was requested and not objected earlier=20 > > by > other > > reviewers. > > Based on Rob's and others' proposal inline will be simplified to use = > > only > > ietf-yang-library@2019-01-04 as you suggest. > > > > Simplified inline: > > In Ericsson we already use simplified inline a lot, it is the most=20 > > common format. > > If you are providing data only for one or a few YANG modules and=20 > > don't > have, > > > > don't care about features/deviations it is the easiest, shortest=20 > > method to use. > > Our most common use-case is to provide preconfigured access control > rules > > for new nodes. > > When a YANG modeler designs a new module, he immediately provides a > set of > > NACM rules > > for the readOnly and the SystemAdmin roles/groups. > > In this case you only need to specify "ietf-neconf-acm@2012-02-22"=20 > > No deviations, no features to indicate. > > Regards Balazs > > > > Regards Balazs > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > Sent: 2021. j=FAlius 7., szerda 21:26 > > To: Andy Bierman > > Cc: Bal=E1zs Lengyel ; Rob Wilton=20 > > (rwilton) ; netmod@ietf.org; Benoit Claise=20 > > > > Subject: Re: AD review of=20 > > draft-ietf-netmod-yang-instance-file-format > > > > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote: > > > > > > > Inline method is needed, if you want to indicate that the file=20 > > > > was generated by someone who uses some YANG modules with=20 > > > > deviations > and > > > > some features are not-supported. There is no way to indicate=20 > > > > feature-support and deviations with the simplified-inline = method. > > > > > > The Inline anydata solution is very heavyweight. > > > Before the YANG library there was a simple URI that is easier to=20 > > > use and takes up much less storage. > > > > > > > The inline content schema is super generic since it supports an open = > > ended set of schema defining modules. While you can use it with say=20 > > ietf-yang-library@2019-01-04, you can use anything else as well. In=20 > > other words, two implementations supporting inline content schema=20 > > may not interoperate. I do not think there is a schema format that=20 > > is mandatory to implement for inline content schema. > > > > So here is my assessment of what we have in terms of = interoperability: > > > > - Simplified-Inline comes with notable restrictions, interoperable > > - Inline is an open ended content schema, not necessarily=20 > > interoperable > > - URI method pushes the problem to another instance file,=20 > > interoperable > > - External is by desing not interoperable > > > > On the server side, we have YANG Library. Perhaps RFC 8525 has some=20 > > complexity that is useful for supporting large servers with multiple = > > datastores and not needed for small instance files (I understand=20 > > that an instance file is always tied to a single datastore?). > > > > To me, it feels that reusing RFC 8525 design is actually a good=20 > > thing. Being able to dump a live server datastore into an instance=20 > > file seems like a very valid use case to me and ideally this is=20 > > possible without having to rewrite the schema part. Well, you could=20 > > go and trim unused datastore schemas > and > > from there unused module sets etc but that can all be done by an=20 > > external tool trimming the schema part, i.e., it does not need to be = > > done by a tool that just dumps a server datastore. > > > > What is the actual value of simplified inline? How much do you=20 > > really save compared to the simplest equivalent RFC 8525=20 > > representation? And does > that > > saving justify to start engineering another schema specification = format? > > > > I guess my choice would have been to just have > > > > +-- content-schema > > | +-- (content-schema-spec)? > > | +--: (yang-library) > > | +--: (uri) > > > > but others obviously want much more choice (but lets note that=20 > > everything sits in a choice, so everything is extensible in case=20 > > other schema definition formats are out there). > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > > Fax: +49 421 200 3103 > > 866038973a > > 15-19e5dad375af0063&q=3D1&e=3D3637406d-f774-4073-80ee- > a7431111e9bc&u=3Dhttps%3A%2F > > %2Fwww.jacobs-university.de%2F> >=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 ------=_NextPart_000_04B2_01D773FF.CBB217A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDcwODExNDczMFowIwYJKoZIhvcNAQkEMRYEFF462JrzBRlc B8VDMMC/om4c+mTcMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAC02 xvun/0VLny7K7+A0ZxzrcZazI/mF7TPMOz7vOYFW0ofxJp1WAZCg5TB/RYLPY1go1xqhLa8lczST b835b3W9OoJJ2tFslgLMg0O0zC9fj6F0Db+tKVqgaLr1vgRKxCXfclQv5IEIeaW7tBkn/xbcOZyW zfNf5Fgyljv947wi/1E1U/xPE49b7Hp64yYeZI3WCk4a1z15/vuH402zplvFFSX7uiDj/ytlvByX TlIn2KelL44fYLOytG1F0ZtGBiUzmwYJQEiNIE83NIm3oqBIrM7TW4qmxRfjG7GfQx1mR8UjeDNC 9xNNuRMEKid+3OjBujmXZANcaMpJUPvSq6EAAAAAAAA= ------=_NextPart_000_04B2_01D773FF.CBB217A0-- From nobody Thu Jul 8 05:33:26 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7813B3A14EB for ; Thu, 8 Jul 2021 05:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.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 ENcL_DBNVqpa for ; Thu, 8 Jul 2021 05:33:20 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2040.outbound.protection.outlook.com [40.107.21.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D7B3A14E4 for ; Thu, 8 Jul 2021 05:33:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jGGv3WmEnQhyuZVsdNihhuKhsISjdT47EzJ2PQfvB7XtvkDGCbHRKNYLSkxHy9TWo62o78fMY3ncZsKsTZUcf1ti6NdKhw03OUSKz0cTZJktIjCzWAOxa8Nv7ICMquUqvD93Vk/iNAHW0uBr6Lgs7qOaylVdBgCFEXoRzTUob7849qbWDgTxgt3+fwEVAxoDnmKhB/naNxGdOrAouPNt1ggeaHDAhVqKOvsHJt/KYUzuuhOXve9+iVHf3H6/4EI3Y3TEP/UZeTbFJHxquNRMlswNOzl7TQW47KP3IwYRoGJOZDWM0NhwLoPvnftM0wK1gtU6RIGuUA5zYsCiTA8OkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GWPGpqUt3qN/4dCfTlM01nQBH5RaQTALqzr9swy/AJw=; b=D/W2LESMetXlF3xC4QBR3hPNfAwGVylSFUKKwR9tfhhs6vJ7OzKD6LGOZEh1zXsRC4UEEPdgsIBvnUokMa/Z6RJBJ6Dh/iq+2UOrmGgxGLvF9BtokFaojza8KNNxQHpER04r8N7L81Ec5hJL6QissnUbQMOLl51Uk3jMP4PzkTUnwGobd4Ynth2eGTNlH1dqvnNQTs9Czg7fcd6xfvCvA0PY4HwJx1UzDICkUWTZBwKxiNYdmUIbyVe6CzYJsemXv6w42joD7VVI1fNUXuWQee0+WZ6k83Dx784jp2anKqT1vmRNGOsq759YW0VQqmJ99zRF283HNDD3tP6peO8kSQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GWPGpqUt3qN/4dCfTlM01nQBH5RaQTALqzr9swy/AJw=; b=VbULeWkGFmnTpXVmw6SlR3fZ1PUEMfxZOIgeDHuDB3LVKVsW6Lod5hYAWmt9jSMwEfo4t+WoA0w5nf+ymK0s5IieTnymJeFDJYi6E8MBT1zBTa07bB4ZHLlqTk3hNJi1zXvav1DXDMKSQZ2dPr7eircEzZOWpvd4a+7aYHDNuO8= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1155.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:26e::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.23; Thu, 8 Jul 2021 12:33:17 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::d505:1bab:3e82:6d6b]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::d505:1bab:3e82:6d6b%4]) with mapi id 15.20.4308.021; Thu, 8 Jul 2021 12:33:17 +0000 Date: Thu, 8 Jul 2021 14:33:16 +0200 From: Juergen Schoenwaelder To: "Rob Wilton (rwilton)" Cc: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , Andy Bierman , "netmod@ietf.org" , Benoit Claise Message-ID: <20210708123316.hep6zythak75cbf4@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Rob Wilton (rwilton)" , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , Andy Bierman , "netmod@ietf.org" , Benoit Claise References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> <20210707192534.4emim5a36zyqrktc@anna.jacobs.jacobs-university.de> <20210708103528.6ezr4v5qeltinvmv@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: PR3PR09CA0020.eurprd09.prod.outlook.com (2603:10a6:102:b7::25) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR3PR09CA0020.eurprd09.prod.outlook.com (2603:10a6:102:b7::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.20 via Frontend Transport; Thu, 8 Jul 2021 12:33:17 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4f949454-f627-4ddb-5de6-08d9420c9015 X-MS-TrafficTypeDiagnostic: AM9P190MB1155: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: q8l6KGj6u8MmHWpS8bLd/adnJEkAOFQ1sbmAQG/XnJ+nlllPk+MyATP/XKKfUsG5IK+j7r1G+YALF/a1CRu2Kd6ZygtQCnwgAb36SgYri+IO86T6ogvMl4WSPvi3ehgA3Mptj8Gj4zhtHVcjUgGSJboYwQ4RNvFO+r8kIiZ1uJ7Iz5e4u9dmRWW+hUznq0hpb31KaXNVJqW4QEptlt/p0umgxqB+d9S/hRvzUeRRGEw6S1Q+R0fpIJKeVotVCp5BqfIip0Tp9bFQB5GuhSm60IDON/ei53lSCLpOl/aZUBuOWqsw554u2NOnsHFMt7/RGwKs3QD9y4egToOi+jJ8aRiTgd0kpIPtOCQ0E4wlguq9FzBW46LRE7Td9MP/RN6qyTNuU/F0PTeX7FOGgFQ3ObQ+ViqCXIxuQiQeQOv3gtKQZeWysioZUFsPS8zcKQdZic8LahwaAFM89ATJU2Sgq4aOYjkqV+k1XW/6cLOzOv1g2SP8QfYzcsLdkRTOEWGkyGlPxoluz46+A4vCJBJmfzZOAIAmCrM71KE9BFn/Pwydg+yTr/8nFGkBua/NcQjyPinKKpQIVmMDabIu6WWx7hMZSfJGXthTSeoE+mzR/c8zx+Cm3aOg7NJLaDnE9FZKZvz/ScdCq4ULoeNX1gYSSh6W6ZiQMuveomwR6OtUcY0Ng7JH09l34rU39KvzwUfGtfhRl58GUsF8Wnrk1iZYUHzsAbRsje1j544A85dR4guQxG6XobWGaxZXeUuY1WXEjgjepA/7Ufsink47HYdcKiPeAXHAyHAAYQbea4/J2lo= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(136003)(39840400004)(346002)(396003)(366004)(786003)(8936002)(66946007)(38350700002)(8676002)(478600001)(966005)(66476007)(6916009)(1076003)(66556008)(5660300002)(86362001)(2906002)(52116002)(38100700002)(3450700001)(26005)(54906003)(6496006)(956004)(316002)(6486002)(4326008)(186003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?I9TsV7khgfmXSoRniWmEXYF2r2VcGZrQsbTArJdU8ATE/04ThrxzrEKdRa5c?= =?us-ascii?Q?PACJOzWz8/PXb2hpVAOSrftKMWuczoNMvPItSPNRoyHS2YxULRU7t8oBS7Rg?= =?us-ascii?Q?5T+rs2dhh3ebYHXHLSfp0OShik0E1UA+6TRfmw8iUf3X5OswFMKdwFvO+vS0?= =?us-ascii?Q?83iktLLTaoA/pxbnEmaaNjfrUy1MVtHV8dT9e8QgKdRBTAGr0DdWZdMSsvfb?= =?us-ascii?Q?MPn0CoTnJD1/776b1738RMiWEyQggcGNREc7OWrGFoOVrjKEQXbdhug4NGiR?= =?us-ascii?Q?iV48NTSoCenq/dqmBhvfh+RRUc0K1TdvqANtiB6cC9uYmHVo/vj0g2NGPkgL?= =?us-ascii?Q?l+F3UoGgzDvdm/CqctIUCwsD7lwKEDlPaoVsnXKVM5HUYOQgSHv1OsV5bAVL?= =?us-ascii?Q?+HXmF/wDUY4bPhbmqC0QJtq9KhUa0NZmbnpVn8OFbiAVUYQODwV+zrg71ap9?= =?us-ascii?Q?aoGLsjAXh+qLpCSrs1RXyBGxNRInEeKpuRo3W/3yeRszAAoaHeI1IdfRod+j?= =?us-ascii?Q?4xjHGI0R80w2Ckqdx/oKECFjvtPS5iABMcboouOs+e5vtZwyWOT/BiId50Nk?= =?us-ascii?Q?UpWJGeoeqKhJ8Ca5PPNTibPnBUfcAh22ZH4V7BHJz3jSuC+NS2WioFpYMX9M?= =?us-ascii?Q?azQxtMC1FVg5PAKkbVytoIa7x2mhd2xqBZhe3c2amUSvg+/ndk/EZ9jI2fLU?= =?us-ascii?Q?FDEPvYlNvTDv/97amH8k31M0HdX4+Qar5LUeTH4SYtzaj5kw0eVgM/zxoUU9?= =?us-ascii?Q?3nQfNa40eQu5JxpfBHp0lhP7POzeRNJ4bthweWkEwCtylBhK3xPNbInn4gm0?= =?us-ascii?Q?k57rh1/8ILB5Ir5VrzZWxY+C8fwzGEsLWn/UF/B8jBJ2uIIKi2dkRbrQaER4?= =?us-ascii?Q?wmciRAvFsjxitAN/5uuNCwFC/49+E8JdO5TY8DjMbgQ7I6MEkGzQfE2huaxK?= =?us-ascii?Q?cnIc5yXB/UKdh2VP+vrc1PzLG+LJji4GNxteVoBKN4riFc33vz5QuQAfqlPs?= =?us-ascii?Q?RyGnfGAvJQP8Tp7ZLfNVkeLTKgk6Ysv2Q0rf0tfozenhD9TJLZoZwJejaUQv?= =?us-ascii?Q?9B2bYpvrDaBeZ/GamXct2CLjF7MASXCvOsq+Wa8Frx/0Xj0/2t3JCSkaHDAM?= =?us-ascii?Q?eO1MgtKjs0Flv5FobnEOQeSWQDroKz+adzjyJwaUs3ZJPUI/8/U32b0PDBiB?= =?us-ascii?Q?SPbPYuDcV6SzIXpTXSyrPh5LtSPaQCzZaKcbkWANW8+uztMWdIquWEv4oh48?= =?us-ascii?Q?J0hvRMYFAGPQQ352/81CYNCm0TpjOmmjYS/F84fTaBeuKGPVH0+wA/qIwqQh?= =?us-ascii?Q?pzf1eGV0K7X5ffMuBzWLUMQ8?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 4f949454-f627-4ddb-5de6-08d9420c9015 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jul 2021 12:33:17.5668 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Jc75m2/PLNc5BrBmXsjVc4qWVZpusPgaSRIIDuEKp2yjGjWX4tXCymzF46/xLTxlrNFxHP3A4KDNmv43TMD/EX1Y8rBfkmfD+o9h3g2ZC4Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1155 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 12:33:25 -0000 On Thu, Jul 08, 2021 at 10:58:37AM +0000, Rob Wilton (rwilton) wrote: > Hi Juergen, > > I believe that having the simple form is worth the extra complexity. > > I think that you are right to be concerned that it should not expand into a separate parallel format. Overtime, I would like the simple form to be able to use revision labels instead of revision dates, but beyond this I think that it should just be a flat list of modules that defines the schema. If a subset of features, or datastores, or import-only modules are needed then the YANG library version (or URIs) can and should be used. > A tool that does something useful, such as checking an instance file against a schema, likely needs to have more information than just a module name with a revision identifier to do the job well. Anyway, if people feel strongly that this optimization is essential, I will shut up and watch what happens to this over time. ;-) > Another example of where I expect it to be useful is in YANG packages. Looking at the examples at the end of https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, then some of those files (which currently aren't defining any schema, but should) would almost double in size if they represented the schema inline using YANG library, which I think would make the files harder for humans to read/parse. Using URIs could help mitigate this, but then we would need to find a place to publish the file containing the YANG package schema (presumably somewhere in IANA), and it not obvious to me that adding the dependency on the URL is really as helpful. Once there are YANG packages and there is a new way to describe a schema, you likely want to augment in a new choice. So I am not convinced by this argument. /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 Jul 8 06:49:33 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E318C3A1BC4 for ; Thu, 8 Jul 2021 06:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=Q2D+pPkK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=uyLQGrWG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghtI5NFpfZeB for ; Thu, 8 Jul 2021 06:49:26 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4355B3A1BC0 for ; Thu, 8 Jul 2021 06:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11014; q=dns/txt; s=iport; t=1625752166; x=1626961766; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eMquAaJExgYLY9zk5ddhH4SmhBOCpUbVNDo8ZVl5vEw=; b=Q2D+pPkKRiSwbE0KI1q3nPE0PtzkavRWc+EXEHKv7NRd8BTVBABvYf0U X25tmKQsHZsSquPNUrv/60fJNziBnt6fkg0C/4eorfXdm2JNy5Z8SL9Fc 23y8LhHP9cUy2xHBlaTgeZxL7yKlyPFr1xI+gwNieIkLBMP49u7nksl09 A=; IronPort-PHdr: =?us-ascii?q?A9a23=3AhSSKGhWx32By2vS1eSaI9+U+CPfV8K0eAWYlg?= =?us-ascii?q?6HPw5pDaKWo5I/lOgrU4vA+xFPKXICO7fVChqKWtq37QmUP7N6Ht2xKa51DU?= =?us-ascii?q?RIJyKB01wwtCcKIEwv3efjtaSFpEd5DX0R++Hf9Ok9QS47yYlTIqSi06jgfU?= =?us-ascii?q?hz0KQtyILHzHYjfx8S63uy/4dvdeQJN0TG8erh1ah6xqFa5iw=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AWxE4y6/d+F30rFHQ1NBuk+Fedb1zdoMgy1?= =?us-ascii?q?knxilNoENuE/BwxvrBoB1E73DJYW4qKQ4dcdDpAtjmfZquz+8K3WB3B8biYO?= =?us-ascii?q?CGghrnEGgG1+vfKlLbalbDH4JmpMJdmu1FeaHN5DtB/IbHCWuDYqwdKbC8mc?= =?us-ascii?q?jC74qzvhQdLz2CKZsQkjuRYTzrdHGeMTM2fabRY6Dsn/avyQDQHUg/X4CePD?= =?us-ascii?q?0oTuLDr9rEmNbNehgdHSMq7wGIkHeB9KP6OwLw5GZcbxp/hZMZtUTVmQ3w4a?= =?us-ascii?q?uu99uhzAXH6mPV55NK3PP819p4AtCWgMR9EESvtu/oXvUlZ1SxhkFznAid0i?= =?us-ascii?q?dtrDAKmWZ4Ay1H0QKUQohym2q05+Cv6kd015ao8y7ovZKqm72IeNt9MbsauW?= =?us-ascii?q?qcGSGpt3bJe7pHof92NiuixulqJAKFkyLn69fSURZ20kKyvHo5iOYWy2dSSI?= =?us-ascii?q?0EddZq3MYiFW5uYd899RjBmcsa+ShVfbbhzecTdUnfY2HSv2FpztDpVnMvHg?= =?us-ascii?q?2eSkxHvsCOyTBZkH1w0kNdnaUk7zs93YN4T4MB6/XPM6xumr0LRsgKbbhlDO?= =?us-ascii?q?NERcesEGTCTR/FLWrXK1X6E6MMPW7LtvfMkfgIDSGRCdU1Jb4J6dv8uX9jxB?= =?us-ascii?q?sPknPVeLuzNcdwg2LwqU2GLEDQ9v0=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DuBgAiAudg/5hdJa1XAxwBAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIFZgVNRB3daNzGIEAOFOYhdA49kikOCUwNUCwEBAQ0BATU?= =?us-ascii?q?MBAEBhFMCgncCJTgTAgQBAQESAQEFAQEBAgEGBHEThTsBBiYNhkUBAQEDAQw?= =?us-ascii?q?GLgEBKQ4BBAcCAgIBCBABBAEBAS4bFx0IAgQBDQUIEweCUIJVAw4hAQ6aTQG?= =?us-ascii?q?BOgKKH3iBNIEBggcBAQYEBIFJQYMVGIIyAwYFgTWCe4JxE0CHKyccgUlEgRV?= =?us-ascii?q?DgmI+gmIBAQIBF4EdEQIYHyaDBoIMIoIqAWtuGA8BChEOAk8OHhYHAyoVBDU?= =?us-ascii?q?GJBGddoErnWMKgySKKZQbEoNji06GO5BTlXyMLpMiKQgZhGYCBAIEBQIOAQE?= =?us-ascii?q?Ggj4kgVlwFTuCaVAZDoEai3WBEINwhRSFSnM4AgYBCQEBAwmJGAEngh8BAQ?= X-IronPort-AV: E=Sophos;i="5.84,222,1620691200"; d="scan'208";a="908285955" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jul 2021 13:49:03 +0000 Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 168Dn3Ko022266 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 8 Jul 2021 13:49:03 GMT Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xbe-aln-001.cisco.com (173.36.7.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 8 Jul 2021 08:49:03 -0500 Received: from xfe-rtp-002.cisco.com (64.101.210.232) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 8 Jul 2021 09:49:02 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-002.cisco.com (64.101.210.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 8 Jul 2021 09:49:02 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cj+bzdDtNE/1JplCEkrkhMOO2Koo6gZhhgGAfDLrjwSilbXGJ7GXUjl8FI8pQuAZXDKgAWwlWxk8uY7TeC2lJfwBaNXufzuEOjoGuvrp0yPMmOmS8D+oY7APh896TV3NeDSX2+GM9tRfxrto4f6A+qXcomFPp1JRNue7rx3mIEgPADt+fFVXhhElTlBcrS+wdDupsLJzHEL6II1cXu9A9PGZe7OSJ0x1jYDLKjP2Rk3Bdf7cbhodfeUtzi2cqWyUdAdd/fYckKAlqQG7WHdK0jMLm6mb0LuITWKHjTR/M4qJEhWscxeozH7oSmBtSCbUiim0jVn7omNYrzNRt+/JpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T/Hyaew22YEWwVfOyZ3dyRXfe+f0H0EL35GHiWG6UZE=; b=JGIwkOW/J6vYg6+Va0UN3lwiH+/SELCbAHgnwTO8dVXMNv2/zVr1bT4FdEY5G+O3Zf08LXR4AiF6QDd5INNgzEr+aY8VsnOujW1YvWuZkeuPLOERDwwL2G+EE0I6G+fiHxBnDYuSKpqEhqFstiuEkWZ4OKHWVtL/QgfBPHmQH95JW6HvQllyMmE2QquU6tfWh+hQAzWISEHtX5C5Hv4Eb17uae2rtJXEatieaupUUTubr5lauon/suOy08121iesiJ5wAXBH88AwlNinjzH3fkfu19bv4IgB7T3bslAFS89FmGs7yF8+DggaW9v3UiYPGibvhXyq/Wbd0kSwDYreSQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T/Hyaew22YEWwVfOyZ3dyRXfe+f0H0EL35GHiWG6UZE=; b=uyLQGrWGhEgJw4WPoLbdgeNPX+R0l9Ep2myC1/qyuD9KsbyoQWDyjrDGBSQCu6gfgvd1AEXErpCrGXPU5WIUpRlRg7roGpZQGa4M5c83PA/8KdAB5Bx9lakEXUQjOy9XHciAgMGfXbsN8iDqKa5iYygeUakDirQlQPhMKPf7gS8= Received: from BN9PR11MB5436.namprd11.prod.outlook.com (2603:10b6:408:101::13) by BN6PR11MB4065.namprd11.prod.outlook.com (2603:10b6:405:7f::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.20; Thu, 8 Jul 2021 13:49:01 +0000 Received: from BN9PR11MB5436.namprd11.prod.outlook.com ([fe80::d9d8:e769:519a:74a2]) by BN9PR11MB5436.namprd11.prod.outlook.com ([fe80::d9d8:e769:519a:74a2%3]) with mapi id 15.20.4308.022; Thu, 8 Jul 2021 13:49:01 +0000 From: "Rob Wilton (rwilton)" To: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= , "Juergen Schoenwaelder" CC: Andy Bierman , "netmod@ietf.org" , Benoit Claise Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAPXLWAAAIT0wAAAIMhAAAAy2eAAAJlLwAAGf35QAAVpNcAAAKQ2AAAHRePIAACr5QAAAAUxvAAAke7IAAESQ+g Date: Thu, 8 Jul 2021 13:49:01 +0000 Message-ID: References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> <20210707192534.4emim5a36zyqrktc@anna.jacobs.jacobs-university.de> <20210708103528.6ezr4v5qeltinvmv@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 57bceb1e-cf3f-46bd-5ebe-08d94217249a x-ms-traffictypediagnostic: BN6PR11MB4065: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7suHe7S2j3j80tg9K6XaOTGUPuy+o6SDOtdI2OVPytNfs5+rOpm2p+gn50rIHmug5vBTly5V2RmApTyXnZdDEZyKvNW1+mSfbtWuLz9oN5bQGobm4W3vXpIpp5Evh6RDoTJWkXFpT/WYdSAEF8PmeVd8ChY2eGxH0hc9nXQaCgkYp2qUYshvm3NwI2Y0ykr8M+cYqt1Y7wdZwP4aawzrSG3w+UQUtYoioDl8UHOTfcrbSjpABwNSGQrYqUMuT9VTHmRgWX9D76nMGuhz5HbjhJwtVI+vqik++lwNxPnXsmIyefZMX6AOZNobJkny7p9/Pi8Xw4mcE64S98+J0MMcDJ9jOppOp2lflIfUPI3BXFJquVMjwcf8v/qTIOdeqw0yqUBFftq8rU6hObpmp+JF4Fn6nRnc5nF4LzZ7SEvhkSeTHax8EWPRgZ1uhRpp6UJa3WxJHsQs0trTJlqalUmDkZhuJsUrQFtLTgz9mg6i9iEsJOB/mTx4APNvSxGIQn4X1Fx4h27K/Mj5Ogx3U8jGO/0Y0wNqmi3lBuI/Fn8jZseoZXk/l3iWSefgzTzzma+qbwKW3o8LE2cMkSfyv1USnPQJST/wG8w+C5PGe5OfWZ8UgpHP0DOsMvH3m0fd391ZKer9g4tIpPl/ScDD+0f8zs9NW/dUs7cBtOhw8ed1olTL4dy2h75nSmmRUKBEqG9BtY6CsgUy+kB+vOLOQlQqBpxjjZSkhHxvWdNeJFTCXPttvNT0MB5fcmf2sCFow/M211AJS1JDX4RlTYhc14vZCw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN9PR11MB5436.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(396003)(39860400002)(346002)(366004)(136003)(64756008)(4326008)(86362001)(33656002)(2906002)(966005)(38100700002)(66446008)(71200400001)(66556008)(66574015)(5660300002)(7696005)(478600001)(83380400001)(26005)(8936002)(53546011)(316002)(66476007)(8676002)(6506007)(66946007)(110136005)(76116006)(186003)(54906003)(9686003)(52536014)(122000001)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?ICAnHvbHitt/9io2WatFws90ao9xI8rm4Dz/Yrvm5OO7A0jE1eSCZ+UBiB?= =?iso-8859-1?Q?p+a3bxZ3K3YVg2idkJ+mjuQCdyyNfWzd6cu10TxAyqNsnzTIy8PAlzl+uW?= =?iso-8859-1?Q?392dlQ7lkZZtQu7Zf+WoW7hRRA7MeUNe0xDCcQnurX/GrTh8BfUiGQ8bHz?= =?iso-8859-1?Q?Afa13og/8/lhFrSp/PDBTp8sGsUaXvy0xZsCKTAsXIXpEw9mLlIsjUt8eQ?= =?iso-8859-1?Q?8tnk3doTG7gxwo/OaO0ZhAkEhkPj1YYzEbeedaiLYCi8nSf36uMXUA1cNK?= =?iso-8859-1?Q?2sUSS5zA9hCANoQdN1MnBPalRcgcfciYaBemZR9euwLtUun0TzADjhOaT1?= =?iso-8859-1?Q?qK3aSI0aaONRqrfCKBEkPiKiYT859WUgjqNVpAseUmsVJzxIrxdmet/x64?= =?iso-8859-1?Q?aQAI8T4H1EIUlp94vp2q8uE9Lq/HF/lxhvUeit9UFoZ2RkiFp3Nds8hAnW?= =?iso-8859-1?Q?JHsX4JBHKIP6tkpnra4betxtQ/KRhAeuyNFd/Cm8zHvUHExTUwahBMPhCN?= =?iso-8859-1?Q?GKNTsvgIoI2PVcyVBgfwE8ygmU4cWUGlUa7RlMFIGDBp4CYd9DUSjPiwMC?= =?iso-8859-1?Q?c5Izt98Ln7bGq8r03bIo55DQUufES1qtRzuYwK+z/pO3qBycb/zCBbgwli?= =?iso-8859-1?Q?21LZwXYS2kKBenh8+IMOlEbILO4wXN52yHWitN2MyI5RURgQQTirw+UnCH?= =?iso-8859-1?Q?F7PbXRF1qzsNZ7mvwxJkk13GnbwOaBfiDJz5pUy/J45yscZefg4X87hMT7?= =?iso-8859-1?Q?OiVCIaoSez6q83LyfNxKpReqN8ozXCV/wHCO6g8+4FAp7d5za7vF+R8eA5?= =?iso-8859-1?Q?xv8Ju+EM2olkq5TXoYJWLyX6RbMnyq1KBBtkgKLN11LeTFuSLPlUtQhtxV?= =?iso-8859-1?Q?hmUY7j1vygGOcok/hrKKhurc8sX798OJGWi9NQwkruenVLhXieC2y+79UW?= =?iso-8859-1?Q?oiYyYDR8u1YIdEGQ9olrL+4qC0V22exA3mVJQrc7LtkjD+qXD6vm5i/vCE?= =?iso-8859-1?Q?lL2WXpIug4ZsBrweHPK7592Ga97p6hwN3mVZRCx2uJc+wdOxMdTLERL104?= =?iso-8859-1?Q?VssbyagvgrWIXSMp25V2Khv5x6elsoDBl/O68Yb2GhxVgGLPnJXsVBHdse?= =?iso-8859-1?Q?dwAABmKxSCgUCE4evCbOLlg49whANVSuvGp5ReoDRIdolKunK2T73BxsRa?= =?iso-8859-1?Q?dPvIilFa658oQCA1rY4ss5LXJTAgXm35R6Td1caEfm8N/PFSMvEXPts238?= =?iso-8859-1?Q?B9almbY0YiVzbhY0PalLBRrdtdqGijxA9dgMdezjjIWMlyORZ2p6qvW94V?= =?iso-8859-1?Q?UYCpPisFAO/SBhGLnsTyhtEUiJpfPuhNyOl9VPgdyXwA+BTfP48JmLjlyX?= =?iso-8859-1?Q?vGVC4LGnpI?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN9PR11MB5436.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 57bceb1e-cf3f-46bd-5ebe-08d94217249a X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2021 13:49:01.4636 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: K+2OEeqhdefyIYJ43We72HZucIKpuNk4Ltffu/GtokSRx6Ot7vv58dcdR2ZqCZbOLJgS2j3tNwpWmysgBRjDXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB4065 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 13:49:32 -0000 Hi Balazs, Would your inline schema not also need to specify the ietf-yang-types depen= dency? E.g., should it be: ietf-netconf-acm@2018-02-14 ietf-yang-types@2013-07-15 Thanks, Rob > -----Original Message----- > From: Bal=E1zs Lengyel > Sent: 08 July 2021 12:48 > To: Rob Wilton (rwilton) ; Juergen Schoenwaelder > > Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise > > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format >=20 > Hello, > I would like to keep simplified inline. If I ask my developers (not exper= ts) > which one do they want? I am pretty sure they opt for the shorter/simpler > one. >=20 > ietf-netconf-acm@2018-02-14 >=20 > OR >=20 > > > m > > ietf-netconf-acm > 2018-02-14 > uri1 > > > ietf-yang-types > uri2 > > > > > s > m > > > running > s > > >=20 > Regards Balazs >=20 > -----Original Message----- > From: Rob Wilton (rwilton) > Sent: 2021. j=FAlius 8., cs=FCt=F6rt=F6k 12:59 > To: Juergen Schoenwaelder ; Bal=E1z= s > Lengyel > Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise > > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format >=20 > Hi Juergen, >=20 > I believe that having the simple form is worth the extra complexity. >=20 > I think that you are right to be concerned that it should not expand into= a > separate parallel format. Overtime, I would like the simple form to be a= ble > to use revision labels instead of revision dates, but beyond this I think > that it should just be a flat list of modules that defines the schema. I= f a > subset of features, or datastores, or import-only modules are needed then > the YANG library version (or URIs) can and should be used. >=20 > Another example of where I expect it to be useful is in YANG packages. > Looking at the examples at the end of > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, th= en > some of those files (which currently aren't defining any schema, but shou= ld) > would almost double in size if they represented the schema inline using > YANG > library, which I think would make the files harder for humans to read/par= se. > Using URIs could help mitigate this, but then we would need to find a pla= ce > to publish the file containing the YANG package schema (presumably > somewhere > in IANA), and it not obvious to me that adding the dependency on the URL = is > really as helpful. >=20 > Regards, > Rob >=20 >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder > > Sent: 08 July 2021 11:35 > > To: Bal=E1zs Lengyel > > Cc: Andy Bierman ; Rob Wilton (rwilton) > > ; netmod@ietf.org; Benoit Claise > > > > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format > > > > The question I asked is "how much simpler is it and does that saving > > justify the introduction of a new rather limited format (that may risk > > to grow over time and become a second citizen)". > > > > So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports > > from ietf-yang-types (at the time of publication that resolves to > > ietf-yang-types@2013-07-15. So the YANG Library instance data would > > roughly look this (please correct what I messed up, I am writing this > > by hand): > > > > > > > > m > > > > ietf-netconf-acm > > 2018-02-14 > > uri1 > > > > > > ietf-yang-types > > uri2 > > > > > > > > > > s > > m > > > > > > running > > s > > > > > > > > Yes, this is a bit longer, but it also conveys more information (note > > that your datastore leaf in the header would likely not be needed > > anymore). > > > > I am concerned that we start creating another format to define schemas > > that is very limited and people later come with extension proposals to > > address some of the limits and at the end we have multiple formats to > > maintain and deal with. So the question is whether people think this > > is worth it. (Note that the felt overhead goes down with every > > additional module used by your instance file, so the example above is > > really the most extreme case. And if you have many modules defining > > NACM rules, then you put the above into a separate file and use the > > URI to point to the schema, no? > > > > /js > > > > On Thu, Jul 08, 2021 at 09:27:52AM +0000, Bal=E1zs Lengyel wrote: > > > Hello Jurgen, > > > Inline: > > > This complex form of inline was requested and not objected earlier > > > by > > other > > > reviewers. > > > Based on Rob's and others' proposal inline will be simplified to use > > > only > > > ietf-yang-library@2019-01-04 as you suggest. > > > > > > Simplified inline: > > > In Ericsson we already use simplified inline a lot, it is the most > > > common format. > > > If you are providing data only for one or a few YANG modules and > > > don't > > have, > > > > > > don't care about features/deviations it is the easiest, shortest > > > method to use. > > > Our most common use-case is to provide preconfigured access control > > rules > > > for new nodes. > > > When a YANG modeler designs a new module, he immediately provides a > > set of > > > NACM rules > > > for the readOnly and the SystemAdmin roles/groups. > > > In this case you only need to specify "ietf-neconf-acm@2012-02-22" > > > No deviations, no features to indicate. > > > Regards Balazs > > > > > > Regards Balazs > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > Sent: 2021. j=FAlius 7., szerda 21:26 > > > To: Andy Bierman > > > Cc: Bal=E1zs Lengyel ; Rob Wilton > > > (rwilton) ; netmod@ietf.org; Benoit Claise > > > > > > Subject: Re: AD review of > > > draft-ietf-netmod-yang-instance-file-format > > > > > > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote: > > > > > > > > > Inline method is needed, if you want to indicate that the file > > > > > was generated by someone who uses some YANG modules with > > > > > deviations > > and > > > > > some features are not-supported. There is no way to indicate > > > > > feature-support and deviations with the simplified-inline method. > > > > > > > > The Inline anydata solution is very heavyweight. > > > > Before the YANG library there was a simple URI that is easier to > > > > use and takes up much less storage. > > > > > > > > > > The inline content schema is super generic since it supports an open > > > ended set of schema defining modules. While you can use it with say > > > ietf-yang-library@2019-01-04, you can use anything else as well. In > > > other words, two implementations supporting inline content schema > > > may not interoperate. I do not think there is a schema format that > > > is mandatory to implement for inline content schema. > > > > > > So here is my assessment of what we have in terms of interoperability= : > > > > > > - Simplified-Inline comes with notable restrictions, interoperable > > > - Inline is an open ended content schema, not necessarily > > > interoperable > > > - URI method pushes the problem to another instance file, > > > interoperable > > > - External is by desing not interoperable > > > > > > On the server side, we have YANG Library. Perhaps RFC 8525 has some > > > complexity that is useful for supporting large servers with multiple > > > datastores and not needed for small instance files (I understand > > > that an instance file is always tied to a single datastore?). > > > > > > To me, it feels that reusing RFC 8525 design is actually a good > > > thing. Being able to dump a live server datastore into an instance > > > file seems like a very valid use case to me and ideally this is > > > possible without having to rewrite the schema part. Well, you could > > > go and trim unused datastore schemas > > and > > > from there unused module sets etc but that can all be done by an > > > external tool trimming the schema part, i.e., it does not need to be > > > done by a tool that just dumps a server datastore. > > > > > > What is the actual value of simplified inline? How much do you > > > really save compared to the simplest equivalent RFC 8525 > > > representation? And does > > that > > > saving justify to start engineering another schema specification form= at? > > > > > > I guess my choice would have been to just have > > > > > > +-- content-schema > > > | +-- (content-schema-spec)? > > > | +--: (yang-library) > > > | +--: (uri) > > > > > > but others obviously want much more choice (but lets note that > > > everything sits in a choice, so everything is extensible in case > > > other schema definition formats are out there). > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > > > > 866038973a > > > 15-19e5dad375af0063&q=3D1&e=3D3637406d-f774-4073-80ee- > > a7431111e9bc&u=3Dhttps%3A%2F > > > %2Fwww.jacobs-university.de%2F> > > > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > 86e2237f51 > fb-eceadf4f1dc08461&q=3D1&e=3D09140141-b70c-44c9-9909- > 048d736efebf&u=3Dhttps%3A%2F > %2Fwww.jacobs-university.de%2F> From nobody Thu Jul 8 09:55:05 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3013A29C4 for ; Thu, 8 Jul 2021 09:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 zmJm1WFXh_Md for ; Thu, 8 Jul 2021 09:54:58 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2CFD3A29C3 for ; Thu, 8 Jul 2021 09:54:57 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id b40so3469233ljf.12 for ; Thu, 08 Jul 2021 09:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vHdCz9D8V7PFj20+mElh8tB+uiHBnpPmlcj3baMbUIw=; b=YRuCsdWhXEUA6tK3TPLXy0eN2K9Q5g9B8gy/8yPwOWBz1HeGyn615KOW1x9/+5V9us qhx6eaHb/GU0ccXs6l8VxCHqLKxY972MtD/1AHPoK7F+hkNoCm1ECs4uTsDWqebmLSa7 cY53CYmdSyvE/+fHPkfKrsiyaWbLRvOJ5BOCNnNkRnX9oCtMG1lSJuxmlMK4ehnGR7rk bGhGGpPjZo31AtXBcP3VYdw3uvdV4GedHYZvkJqLW+LpxXF0XhrZd9PE45I0KlAu4yuR /pyiDJRH6CP1ziB7E427kWB1VAH7DLywPSjsimCLcf9+pMuAbc4zrOvXxsx0dh1SsEOo pPqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vHdCz9D8V7PFj20+mElh8tB+uiHBnpPmlcj3baMbUIw=; b=dPS4ExwbEM3M67LZdhoaWj64ysrpAS2arcNam1tNQO2DAx8l71dy8SA5INadoRzIkr Urtq2g7GoX5x6UG+wGHD3rsAkItKQQ5OnhD4UsKGQ+03c+5J42/lOCy7aeaTUOTRAWM1 pezgLrdsWRSfmNBChDAimoZSwxgSyUNeS3X7X5vJVavL6XiHWgc1Sc3s8Ao+0IUdlRuo oiv4FRLC2/MX7tH8DBjGSd3DI/nJ8U8XrLCbYMDpPSfC0yzQFzrSxJBdMgxzxKpy62Ev oECnoeQgbltcORxsdd6+dsfC0xinPnQ5QQUPxNj+QBlh4kxapDZhFKdOcBkP38r5xlrT 3q8w== X-Gm-Message-State: AOAM533hmlbqm8Skcw3K/+AT7Xyz/9+qysGuUQ6L0cNFlHtIhrxEZk2L 2fYotYGCx/3AahJoBbZmqt3w9//yDpEiSnR7iYMgHg== X-Google-Smtp-Source: ABdhPJxR/b/LhqoFMEpnaqn+/S2MJ2OzUO+jQahBE8LC2AHMB7gNZ+CbV8DGLCfhuStKapjgABI6QHwLkIxtMgvNji4= X-Received: by 2002:a2e:808f:: with SMTP id i15mr6172612ljg.298.1625763294858; Thu, 08 Jul 2021 09:54:54 -0700 (PDT) MIME-Version: 1.0 References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> <20210707192534.4emim5a36zyqrktc@anna.jacobs.jacobs-university.de> <20210708103528.6ezr4v5qeltinvmv@anna.jacobs.jacobs-university.de> In-Reply-To: From: Andy Bierman Date: Thu, 8 Jul 2021 09:54:43 -0700 Message-ID: To: "Rob Wilton (rwilton)" Cc: Juergen Schoenwaelder , =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= , "netmod@ietf.org" , Benoit Claise Content-Type: multipart/alternative; boundary="000000000000aded5405c69f831a" Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 16:55:04 -0000 --000000000000aded5405c69f831a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 8, 2021 at 3:58 AM Rob Wilton (rwilton) wrote: > Hi Juergen, > > I believe that having the simple form is worth the extra complexity. > > I believe it is the only option that does not have too much complexity. The inline form seems to imply that the NMDA version of the YANG library is used. Only 1 module set is ever shown, but of course the actual schema allows for much more complex instances than that, which the reader must support. Does this mean NMDA must be used or else a YANG data file cannot be saved? So the reader is expected to look for the 'current' /yang-library and then the 'deprecated' /modules-state? And then fish the anydata for whatever non-standard solution is in use? The procedures should be explained better so there is a better chance of interoperability. For the URI method, the reader must check for a broken chain of reference and loops. The draft should say the uri references across N files MUST NOT create a loop (similar language is in YANG wrt import loops). For conformance purposes, I think YANG features are appropriate. IMO simplified-inline is mandatory-to-implement but the rest should be optional. This way a tool can claim conformance and also the standard will provide a minimum level of interoperability. Andy > I think that you are right to be concerned that it should not expand into > a separate parallel format. Overtime, I would like the simple form to be > able to use revision labels instead of revision dates, but beyond this I > think that it should just be a flat list of modules that defines the > schema. If a subset of features, or datastores, or import-only modules a= re > needed then the YANG library version (or URIs) can and should be used. > > This can be done with augment if and when the versioning draft reaches RFC > Another example of where I expect it to be useful is in YANG packages. > Looking at the examples at the end of > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, > then some of those files (which currently aren't defining any schema, but > should) would almost double in size if they represented the schema inline > using YANG library, which I think would make the files harder for humans = to > read/parse. Using URIs could help mitigate this, but then we would need = to > find a place to publish the file containing the YANG package schema > (presumably somewhere in IANA), and it not obvious to me that adding the > dependency on the URL is really as helpful. > > Regards, > Rob > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > Sent: 08 July 2021 11:35 > > To: Bal=C3=A1zs Lengyel > > Cc: Andy Bierman ; Rob Wilton (rwilton) > > ; netmod@ietf.org; Benoit Claise > > > > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format > > > > The question I asked is "how much simpler is it and does that saving > > justify the introduction of a new rather limited format (that may risk > > to grow over time and become a second citizen)". > > > > So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports > > from ietf-yang-types (at the time of publication that resolves to > > ietf-yang-types@2013-07-15. So the YANG Library instance data would > > roughly look this (please correct what I messed up, I am writing this > > by hand): > > > > > > > > m > > > > ietf-netconf-acm > > 2018-02-14 > > uri1 > > > > > > ietf-yang-types > > uri2 > > > > > > > > > > s > > m > > > > > > running > > s > > > > > > > > Yes, this is a bit longer, but it also conveys more information (note > > that your datastore leaf in the header would likely not be needed > > anymore). > > > > I am concerned that we start creating another format to define schemas > > that is very limited and people later come with extension proposals to > > address some of the limits and at the end we have multiple formats to > > maintain and deal with. So the question is whether people think this > > is worth it. (Note that the felt overhead goes down with every > > additional module used by your instance file, so the example above is > > really the most extreme case. And if you have many modules defining > > NACM rules, then you put the above into a separate file and use the > > URI to point to the schema, no? > > > > /js > > > > On Thu, Jul 08, 2021 at 09:27:52AM +0000, Bal=C3=A1zs Lengyel wrote: > > > Hello Jurgen, > > > Inline: > > > This complex form of inline was requested and not objected earlier by > > other > > > reviewers. > > > Based on Rob's and others' proposal inline will be simplified to use > only > > > ietf-yang-library@2019-01-04 as you suggest. > > > > > > Simplified inline: > > > In Ericsson we already use simplified inline a lot, it is the most > common > > > format. > > > If you are providing data only for one or a few YANG modules and don'= t > > have, > > > > > > don't care about features/deviations it is the easiest, shortest > method to > > > use. > > > Our most common use-case is to provide preconfigured access control > > rules > > > for new nodes. > > > When a YANG modeler designs a new module, he immediately provides a > > set of > > > NACM rules > > > for the readOnly and the SystemAdmin roles/groups. > > > In this case you only need to specify "ietf-neconf-acm@2012-02-22" No > > > deviations, no features to indicate. > > > Regards Balazs > > > > > > Regards Balazs > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > Sent: 2021. j=C3=BAlius 7., szerda 21:26 > > > To: Andy Bierman > > > Cc: Bal=C3=A1zs Lengyel ; Rob Wilton (rw= ilton) > > > ; netmod@ietf.org; Benoit Claise > > > > > > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format > > > > > > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote: > > > > > > > > > Inline method is needed, if you want to indicate that the file wa= s > > > > > generated by someone who uses some YANG modules with deviations > > and > > > > > some features are not-supported. There is no way to indicate > > > > > feature-support and deviations with the simplified-inline method. > > > > > > > > The Inline anydata solution is very heavyweight. > > > > Before the YANG library there was a simple URI that is easier to us= e > > > > and takes up much less storage. > > > > > > > > > > The inline content schema is super generic since it supports an open > ended > > > set of schema defining modules. While you can use it with say > > > ietf-yang-library@2019-01-04, you can use anything else as well. In > other > > > words, two implementations supporting inline content schema may not > > > interoperate. I do not think there is a schema format that is > mandatory to > > > implement for inline content schema. > > > > > > So here is my assessment of what we have in terms of interoperability= : > > > > > > - Simplified-Inline comes with notable restrictions, interoperable > > > - Inline is an open ended content schema, not necessarily interoperab= le > > > - URI method pushes the problem to another instance file, interoperab= le > > > - External is by desing not interoperable > > > > > > On the server side, we have YANG Library. Perhaps RFC 8525 has some > > > complexity that is useful for supporting large servers with multiple > > > datastores and not needed for small instance files (I understand that > an > > > instance file is always tied to a single datastore?). > > > > > > To me, it feels that reusing RFC 8525 design is actually a good thing= . > Being > > > able to dump a live server datastore into an instance file seems like > a very > > > valid use case to me and ideally this is possible without having to > rewrite > > > the schema part. Well, you could go and trim unused datastore schemas > > and > > > from there unused module sets etc but that can all be done by an > external > > > tool trimming the schema part, i.e., it does not need to be done by a > tool > > > that just dumps a server datastore. > > > > > > What is the actual value of simplified inline? How much do you really > save > > > compared to the simplest equivalent RFC 8525 representation? And does > > that > > > saving justify to start engineering another schema specification > format? > > > > > > I guess my choice would have been to just have > > > > > > +-- content-schema > > > | +-- (content-schema-spec)? > > > | +--: (yang-library) > > > | +--: (uri) > > > > > > but others obviously want much more choice (but lets note that > everything > > > sits in a choice, so everything is extensible in case other schema > > > definition formats are out there). > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > > > > 866038973a > > > 15-19e5dad375af0063&q=3D1&e=3D3637406d-f774-4073-80ee- > > a7431111e9bc&u=3Dhttps%3A%2F > > > %2Fwww.jacobs-university.de%2F> > > > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > --000000000000aded5405c69f831a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jul 8, 2021 at 3:58 AM Rob Wi= lton (rwilton) <rwilton@cisco.com> wrote:
Hi= Juergen,

I believe that having the simple form is worth the extra complexity.








Andy



<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex"> I think that you are right to be concerned that it should not expand into a= separate parallel format.=C2=A0 Overtime, I would like the simple form to = be able to use revision labels instead of revision dates, but beyond this I= think that it should just be a flat list of modules that defines the schem= a.=C2=A0 If a subset of features, or datastores, or import-only modules are= needed then the YANG library version (or URIs) can and should be used.


This can be done with augment if and w= hen the versioning draft reaches RFC
=C2=A0
Another example of where I expect it to be useful is in YANG packages.=C2= =A0 Looking at the examples at the end of https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-pa= ckages, then some of those files (which currently aren't defining a= ny schema, but should) would almost double in size if they represented the = schema inline using YANG library, which I think would make the files harder= for humans to read/parse.=C2=A0 Using URIs could help mitigate this, but t= hen we would need to find a place to publish the file containing the YANG p= ackage schema (presumably somewhere in IANA), and it not obvious to me that= adding the dependency on the URL is really as helpful.

Regards,
Rob


> -----Original Message-----
> From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> Sent: 08 July 2021 11:35
> To: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>
> Cc: Andy Bierman <andy@yumaworks.com>; Rob Wilton (rwilton)
> <rwilton@cis= co.com>; netmod= @ietf.org; Benoit Claise
> <beno= it.claise@huawei.com>
> Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format<= br> >
> The question I asked is "how much simpler is it and does that sav= ing
> justify the introduction of a new rather limited format (that may risk=
> to grow over time and become a second citizen)".
>
> So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports > from ietf-yang-types (at the time of publication that resolves to
> ietf-yang-types@2013-07-15. So the YANG Library instance data would > roughly look this (please correct what I messed up, I am writing this<= br> > by hand):
>
> <yang-library>
>=C2=A0 =C2=A0<module-set>
>=C2=A0 =C2=A0 =C2=A0<name>m</name>
>=C2=A0 =C2=A0 =C2=A0<module>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<name>ietf-netconf-acm</name> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2018-02-14</revision><= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<namespace>uri1</namespace>
>=C2=A0 =C2=A0 =C2=A0</module>
>=C2=A0 =C2=A0 =C2=A0<import-only-module>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<name>ietf-yang-types</name>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<namespace>uri2</namespace>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<revision/>
>=C2=A0 =C2=A0 =C2=A0</import-only-module>
>=C2=A0 =C2=A0</module-set>
>=C2=A0 =C2=A0<schema>
>=C2=A0 =C2=A0 =C2=A0<name>s</name>
>=C2=A0 =C2=A0 =C2=A0<module-set>m</module-set>
>=C2=A0 =C2=A0</schema>
>=C2=A0 =C2=A0<datastore>
>=C2=A0 =C2=A0 =C2=A0<name>running</name>
>=C2=A0 =C2=A0 =C2=A0<schema>s</schema>
>=C2=A0 =C2=A0</datastore>
> </yang-library>
>
> Yes, this is a bit longer, but it also conveys more information (note<= br> > that your datastore leaf in the header would likely not be needed
> anymore).
>
> I am concerned that we start creating another format to define schemas=
> that is very limited and people later come with extension proposals to=
> address some of the limits and at the end we have multiple formats to<= br> > maintain and deal with. So the question is whether people think this > is worth it. (Note that the felt overhead goes down with every
> additional module used by your instance file, so the example above is<= br> > really the most extreme case. And if you have many modules defining > NACM rules, then you put the above into a separate file and use the > URI to point to the schema, no?
>
> /js
>
> On Thu, Jul 08, 2021 at 09:27:52AM +0000, Bal=C3=A1zs Lengyel wrote: > > Hello Jurgen,
> > Inline:
> > This complex form of inline was requested and not objected earlie= r by
> other
> > reviewers.
> > Based on Rob's and others' proposal inline will be simpli= fied to use only
> > ietf-yang-library@2019-01-04 as you suggest.
> >
> > Simplified inline:
> > In Ericsson we already use simplified inline a lot, it is the mos= t common
> > format.
> > If you are providing data only for one or a few YANG modules and = don't
> have,
> >
> > don't care about features/deviations it is the easiest, short= est method to
> > use.
> >=C2=A0 Our most common use-case is to provide preconfigured access= control
> rules
> > for new nodes.
> > When a YANG modeler designs a new module, he immediately provides= a
> set of
> > NACM rules
> > for the readOnly and the SystemAdmin roles/groups.
> > In this case you only need to specify "ietf-neconf-acm@2012-= 02-22" No
> > deviations, no features to indicate.
> > Regards Balazs
> >
> > Regards Balazs
> >
> > -----Original Message-----
> > From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.= de>
> > Sent: 2021. j=C3=BAlius 7., szerda 21:26
> > To: Andy Bierman <andy@yumaworks.com>
> > Cc: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>; Rob Wilton= (rwilton)
> > <rwilto= n@cisco.com>; n= etmod@ietf.org; Benoit Claise
> > <benoit.claise@huawei.com>
> > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-fo= rmat
> >
> > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote:
> > >
> > > > Inline method is needed, if you want to indicate that t= he file was
> > > > generated by someone who uses some YANG modules with de= viations
> and
> > > > some features are not-supported. There is no way to ind= icate
> > > > feature-support and deviations with the simplified-inli= ne method.
> > >
> > > The Inline anydata solution is very heavyweight.
> > > Before the YANG library there was a simple URI that is easie= r to use
> > > and takes up much less storage.
> > >
> >
> > The inline content schema is super generic since it supports an o= pen ended
> > set of schema defining modules. While you can use it with say
> > ietf-yang-library@2019-01-04, you can use anything else as well. = In other
> > words, two implementations supporting inline content schema may n= ot
> > interoperate. I do not think there is a schema format that is man= datory to
> > implement for inline content schema.
> >
> > So here is my assessment of what we have in terms of interoperabi= lity:
> >
> > - Simplified-Inline comes with notable restrictions, interoperabl= e
> > - Inline is an open ended content schema, not necessarily interop= erable
> > - URI method pushes the problem to another instance file, interop= erable
> > - External is by desing not interoperable
> >
> > On the server side, we have YANG Library. Perhaps RFC 8525 has so= me
> > complexity that is useful for supporting large servers with multi= ple
> > datastores and not needed for small instance files (I understand = that an
> > instance file is always tied to a single datastore?).
> >
> > To me, it feels that reusing RFC 8525 design is actually a good t= hing. Being
> > able to dump a live server datastore into an instance file seems = like a very
> > valid use case to me and ideally this is possible without having = to rewrite
> > the schema part. Well, you could go and trim unused datastore sch= emas
> and
> > from there unused module sets etc but that can all be done by an = external
> > tool trimming the schema part, i.e., it does not need to be done = by a tool
> > that just dumps a server datastore.
> >
> > What is the actual value of simplified inline? How much do you re= ally save
> > compared to the simplest equivalent RFC 8525 representation? And = does
> that
> > saving justify to start engineering another schema specification = format?
> >
> > I guess my choice would have been to just have
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-- content-schema
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +-- (content-schema-spec)?
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0+--: (yang-librar= y)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0+--: (uri)
> >
> > but others obviously want much more choice (but lets note that ev= erything
> > sits in a choice, so everything is extensible in case other schem= a
> > definition formats are out there).
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103
> > <https://protect2.fi= reeye.com/v1/url?k=3Dfe85c8e6-a11ef1cd-fe85887d-
> 866038973a
> > 15-19e5dad375af0063&q=3D1&e=3D3637406d-f774-4073-80ee- > a7431111e9bc&u=3Dhttps%3A%2F
> > %2Fwww.jacobs-university.de%2F>
>
>
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;https://www.jacobs-university.de/>
--000000000000aded5405c69f831a-- From nobody Thu Jul 8 10:16:47 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000C53A094E for ; Thu, 8 Jul 2021 10:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvDGiOkEXSmP for ; Thu, 8 Jul 2021 10:16:44 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 172693A094A for ; Thu, 8 Jul 2021 10:16:43 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id a6so3617177ljq.3 for ; Thu, 08 Jul 2021 10:16:43 -0700 (PDT) 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=E+JCrdQvMrz2F3ronk+Va0Z7oNXLtwkUG5YnDotBCss=; b=TvtbUAWYEO3+TdVia3yCO99gZPcrJuHA5YaP3QLhVeKPQhKDnKJmkYxJg8LnGARSiH 7fg47EbwrRICoRMYeOEI9hIDI9uNlLJRn/jW7mI7ej6ON1mVjb8Pw7rP33NUzk6j20II vGPsuAYND05tzx8rPZzUbMJMs3s6Z893Lht2FLfyEreN6f8zyFWJx+zhNvQrGUhQKzC8 vumc7JwLuF4keIspxbFHUtGRH+jZBYdHAO9Nm+rfbkfbPiKidvqDAEn+8r/Lm/eK4e9C 5hDQP9iZ8uSFGSLt7gvRoM31ij+5lwjQwcfkZXdzmlXEinveQi8OykBqSQXf4ymILdCu wV2g== 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=E+JCrdQvMrz2F3ronk+Va0Z7oNXLtwkUG5YnDotBCss=; b=fU3YSaujC+DBpjbAR1km4xuW22HcBr1w+OLRi33m9iITkcPnGquZ+M8/wU3/bX1TVG 7eglQ8zOzekSx7/q4PL5Fekk6cRzQjZfcVKTu1RrSazeWuDEQ9uDfcMtfz+9/ADmrST2 aN3PpQQ4mwcz71j+afWVrog2WrVaBU8TzWeRnHknH4vdIJDJdgy3oDlRmZ96aVO8rfv2 DEXAT1aT4sNlnsHlgJ8J5NANDeVo8BVvYL2szYfD8+3R3+h18hnQivzkP6uUbcJ+tcA4 UfnJ3KqQjYXXpiTdOtUw4XUREsnjpoP2NtDF/OL3mPewcNCO0qg8MRD9OcPGQ8Cg90oL gCtA== X-Gm-Message-State: AOAM531xYHPM8LnnthITDK1viLaQtbZQScvY05kxxTAZyheg+rLzpLg/ uadh3oSrEHpmI3bvEgO6xW90ymbnQ7Cd7p13Ms63W954QQK+eA== X-Google-Smtp-Source: ABdhPJwJFM2tCtpmaJ0UyUlmbRvOVHy0XCvs5njrQ/uv7yhsaJfc9cIVxuXDxan06oYOkwfugkdjywszYs57G1KYOUY= X-Received: by 2002:a05:651c:544:: with SMTP id q4mr24766328ljp.105.1625764600342; Thu, 08 Jul 2021 10:16:40 -0700 (PDT) MIME-Version: 1.0 From: Andy Bierman Date: Thu, 8 Jul 2021 10:16:29 -0700 Message-ID: To: NetMod WG Content-Type: multipart/alternative; boundary="0000000000007dfe1a05c69fd17a" Archived-At: Subject: [netmod] yang-instance-file include-defaults leaf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 17:16:46 -0000 --0000000000007dfe1a05c69fd17a Content-Type: text/plain; charset="UTF-8" Hi, The module has this object: leaf includes-defaults { type enumeration { enum report-all { value 1; description "All data nodes SHOULD be included independent of any default values."; } enum trim { value 2; description "Data nodes that have a default defined and where the actual value is the default value SHOULD NOT be included."; } enum explicit { value 3; description "Data nodes that have a default defined and where the actual value is the default value SHOULD NOT be included. However, if the actual value was set by a NETCONF client or other management application by the way of an explicit management operation the data node SHOULD be included."; } } default trim; The draft is extremely server-centric, like most IETF standards, but this leaf is too server-centric to ignore. Consider the possibility that the source of the file is NOT a NETCONF server. This data may not be known so the default of "trim" may not be correct. IMO this leaf is noise because any tool that knows the schema will also know the YANG defaults. The solution is incomplete anyway because the presence of a leaf that has a YANG default is not enough. The "report-all-tagged" mode must be used to identify defaults. IMO this leaf should be removed, but at least add an enum called "unknown". Andy --0000000000007dfe1a05c69fd17a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The module has this object:

    =
leaf includes-defaults {
       type enumeration {
         enum report-all {
           value 1;
           description
             "All data nodes SHOULD be included independent of
               any default values.";
         }
         enum trim {
           value 2;
           description
             "Data nodes that have a default defined and where
               the actual value is the default value SHOULD
               NOT be included.";
         }
         enum explicit {
           value 3;
           description
             "Data nodes that have a default defined and where
               the actual value is the default value SHOULD NOT be
               included. However, if the actual value was set by
               a NETCONF client or other management application
               by the way of an explicit management operation the
               data node SHOULD be included.";
         }
       }
       default trim;

The draft is extremely server-centric, like most IETF standar= ds, but this
leaf is too server-centric to ignore.

=
Consider the possibility that the source of the file is NOT a NE= TCONF server.
This data may not be known so the default of "= trim" may not be correct.

IMO this leaf is no= ise because any tool that knows the schema will also
know the YAN= G defaults.=C2=A0 The solution is incomplete anyway because
the p= resence of a leaf that has a YANG default is not enough.
The=C2= =A0 "report-all-tagged" mode must be used to identify defaults.
IMO this leaf should be removed, but at least add an enum called &= quot;unknown".


Andy
=

--0000000000007dfe1a05c69fd17a-- From nobody Thu Jul 8 13:38:17 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15B53A1B05 for ; Thu, 8 Jul 2021 13:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 zHksksrY9CEe for ; Thu, 8 Jul 2021 13:38:10 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 67A663A1B01 for ; Thu, 8 Jul 2021 13:38:10 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id y42so18773627lfa.3 for ; Thu, 08 Jul 2021 13:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BCK2DdzHXfoEqX2mJX342LkC/GdGF8UdvF4tgxuHgUo=; b=NCGe/+d7hnmED2jwFKcjVkREJ0gQ1JKHMkGo90Pzpu/DSXwm99qPn+scre4E8wnOsW +KswNoBMWgNCHEI7v26yj+OophSWVlxtWQqQqMuoNbWXN2IOdBwOts40uFZnVQKSpf0u rnJ4lCSy00LpfWNUQrWVAy4HgCPFWp/+9Zy2iPlI13k2P/OrlSEOpXKKFliPAUbOi+db cKBtgt4M9J15MlCAJPSAD+ClU6gnH/9hnptXN0Gk3idNWKQXeFG2JsJghgn3dAXhPIuz cQz/RNtHUJXdDY3JB846tbfF0kZV/6jHVKaOGKserk9Cc+XTuR0pgdy9nu668O+2vM+S rLDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BCK2DdzHXfoEqX2mJX342LkC/GdGF8UdvF4tgxuHgUo=; b=P+a9ebWPErq8XMLHg0OflA50DfosdEtFRBXCzIlhnvIyhnm0nnZHXCiklUrkbA5nrk 5VLXZS3nhwTWvUEbQzIwVJjxCV1IFBCrt6LP8hg2NA+JPQSTbXiQ6zND4bS58oakS+Cx MboC6xvNq060Sc6Isj6+oJQ0T1nUizaNmTNUfdfh/aIitK/ZiyflbIAmE6QHCQmYpeab CkdSltY26W7oDFxxjTC4WVF90qRUoeFo0v7si9vJtsrNMl/ViueKsZ9Iqt4kyNTP+2Ns L4LHqwh3RAJBXkEymwcdRjbmAb1doZDWkX1NLsMRGq/yiljWQDsGc5Iav23APUeQx2n8 OoNg== X-Gm-Message-State: AOAM531BgBazeK13pDdVEoD111A74IkBDU0WH0y5wyYQKsx+ukasQhN2 fpn4pxGm7cJdB3LCw2VuvdAPUCrIDs8VnXxR0oeQaA== X-Google-Smtp-Source: ABdhPJwWy1UzNlITqN77WDqhyIbdo/X4tFefDVDXyzXn41R4gl3JWdMQ9R7teAKN+won97FhRJMZlTw86HP+KF7HCDg= X-Received: by 2002:a05:6512:210b:: with SMTP id q11mr24596158lfr.577.1625776686731; Thu, 08 Jul 2021 13:38:06 -0700 (PDT) MIME-Version: 1.0 References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> <20210707192534.4emim5a36zyqrktc@anna.jacobs.jacobs-university.de> <20210708103528.6ezr4v5qeltinvmv@anna.jacobs.jacobs-university.de> In-Reply-To: From: Andy Bierman Date: Thu, 8 Jul 2021 13:37:55 -0700 Message-ID: To: "Rob Wilton (rwilton)" Cc: Juergen Schoenwaelder , =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= , "netmod@ietf.org" , Benoit Claise Content-Type: multipart/alternative; boundary="000000000000e5a87805c6a2a1f7" Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 20:38:16 -0000 --000000000000e5a87805c6a2a1f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 8, 2021 at 3:58 AM Rob Wilton (rwilton) wrote: > Hi Juergen, > > I believe that having the simple form is worth the extra complexity. > > I think that you are right to be concerned that it should not expand into > a separate parallel format. Overtime, I would like the simple form to be > able to use revision labels instead of revision dates, but beyond this I > think that it should just be a flat list of modules that defines the > schema. If a subset of features, or datastores, or import-only modules a= re > needed then the YANG library version (or URIs) can and should be used. > > Another example of where I expect it to be useful is in YANG packages. > Looking at the examples at the end of > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, > then some of those files (which currently aren't defining any schema, but > should) would almost double in size if they represented the schema inline > using YANG library, which I think would make the files harder for humans = to > read/parse. Using URIs could help mitigate this, but then we would need = to > find a place to publish the file containing the YANG package schema > (presumably somewhere in IANA), and it not obvious to me that adding the > dependency on the URL is really as helpful. > > https://datatracker.ietf.org/doc/html/draft-bierman-netmod-yang-conformance= -00 An original use-case in my 2013 draft was to allow a vendor to define a package that represented the entire server. Then the entire and YANG library can be replaced by one package-id in this case. This is reasonable for embedded devices that have a fixed YANG library (expected for CORECONF). BTW, the main reason I proposed the YANG syntax (your version has a JSON document) is that these files are needed by automation tools, and YANG allows extensions (and other things like augment). Automation tools cannot work without extensions so not sure how JSON package files will be useful to them. Regards, > Rob > Andy > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > Sent: 08 July 2021 11:35 > > To: Bal=C3=A1zs Lengyel > > Cc: Andy Bierman ; Rob Wilton (rwilton) > > ; netmod@ietf.org; Benoit Claise > > > > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format > > > > The question I asked is "how much simpler is it and does that saving > > justify the introduction of a new rather limited format (that may risk > > to grow over time and become a second citizen)". > > > > So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports > > from ietf-yang-types (at the time of publication that resolves to > > ietf-yang-types@2013-07-15. So the YANG Library instance data would > > roughly look this (please correct what I messed up, I am writing this > > by hand): > > > > > > > > m > > > > ietf-netconf-acm > > 2018-02-14 > > uri1 > > > > > > ietf-yang-types > > uri2 > > > > > > > > > > s > > m > > > > > > running > > s > > > > > > > > Yes, this is a bit longer, but it also conveys more information (note > > that your datastore leaf in the header would likely not be needed > > anymore). > > > > I am concerned that we start creating another format to define schemas > > that is very limited and people later come with extension proposals to > > address some of the limits and at the end we have multiple formats to > > maintain and deal with. So the question is whether people think this > > is worth it. (Note that the felt overhead goes down with every > > additional module used by your instance file, so the example above is > > really the most extreme case. And if you have many modules defining > > NACM rules, then you put the above into a separate file and use the > > URI to point to the schema, no? > > > > /js > > > > On Thu, Jul 08, 2021 at 09:27:52AM +0000, Bal=C3=A1zs Lengyel wrote: > > > Hello Jurgen, > > > Inline: > > > This complex form of inline was requested and not objected earlier by > > other > > > reviewers. > > > Based on Rob's and others' proposal inline will be simplified to use > only > > > ietf-yang-library@2019-01-04 as you suggest. > > > > > > Simplified inline: > > > In Ericsson we already use simplified inline a lot, it is the most > common > > > format. > > > If you are providing data only for one or a few YANG modules and don'= t > > have, > > > > > > don't care about features/deviations it is the easiest, shortest > method to > > > use. > > > Our most common use-case is to provide preconfigured access control > > rules > > > for new nodes. > > > When a YANG modeler designs a new module, he immediately provides a > > set of > > > NACM rules > > > for the readOnly and the SystemAdmin roles/groups. > > > In this case you only need to specify "ietf-neconf-acm@2012-02-22" No > > > deviations, no features to indicate. > > > Regards Balazs > > > > > > Regards Balazs > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > Sent: 2021. j=C3=BAlius 7., szerda 21:26 > > > To: Andy Bierman > > > Cc: Bal=C3=A1zs Lengyel ; Rob Wilton (rw= ilton) > > > ; netmod@ietf.org; Benoit Claise > > > > > > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format > > > > > > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote: > > > > > > > > > Inline method is needed, if you want to indicate that the file wa= s > > > > > generated by someone who uses some YANG modules with deviations > > and > > > > > some features are not-supported. There is no way to indicate > > > > > feature-support and deviations with the simplified-inline method. > > > > > > > > The Inline anydata solution is very heavyweight. > > > > Before the YANG library there was a simple URI that is easier to us= e > > > > and takes up much less storage. > > > > > > > > > > The inline content schema is super generic since it supports an open > ended > > > set of schema defining modules. While you can use it with say > > > ietf-yang-library@2019-01-04, you can use anything else as well. In > other > > > words, two implementations supporting inline content schema may not > > > interoperate. I do not think there is a schema format that is > mandatory to > > > implement for inline content schema. > > > > > > So here is my assessment of what we have in terms of interoperability= : > > > > > > - Simplified-Inline comes with notable restrictions, interoperable > > > - Inline is an open ended content schema, not necessarily interoperab= le > > > - URI method pushes the problem to another instance file, interoperab= le > > > - External is by desing not interoperable > > > > > > On the server side, we have YANG Library. Perhaps RFC 8525 has some > > > complexity that is useful for supporting large servers with multiple > > > datastores and not needed for small instance files (I understand that > an > > > instance file is always tied to a single datastore?). > > > > > > To me, it feels that reusing RFC 8525 design is actually a good thing= . > Being > > > able to dump a live server datastore into an instance file seems like > a very > > > valid use case to me and ideally this is possible without having to > rewrite > > > the schema part. Well, you could go and trim unused datastore schemas > > and > > > from there unused module sets etc but that can all be done by an > external > > > tool trimming the schema part, i.e., it does not need to be done by a > tool > > > that just dumps a server datastore. > > > > > > What is the actual value of simplified inline? How much do you really > save > > > compared to the simplest equivalent RFC 8525 representation? And does > > that > > > saving justify to start engineering another schema specification > format? > > > > > > I guess my choice would have been to just have > > > > > > +-- content-schema > > > | +-- (content-schema-spec)? > > > | +--: (yang-library) > > > | +--: (uri) > > > > > > but others obviously want much more choice (but lets note that > everything > > > sits in a choice, so everything is extensible in case other schema > > > definition formats are out there). > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > > > > 866038973a > > > 15-19e5dad375af0063&q=3D1&e=3D3637406d-f774-4073-80ee- > > a7431111e9bc&u=3Dhttps%3A%2F > > > %2Fwww.jacobs-university.de%2F> > > > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > --000000000000e5a87805c6a2a1f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jul 8, 2021 at 3:58 AM Rob Wi= lton (rwilton) <rwilton@cisco.com> wrote:
Hi= Juergen,

I believe that having the simple form is worth the extra complexity.

I think that you are right to be concerned that it should not expand into a= separate parallel format.=C2=A0 Overtime, I would like the simple form to = be able to use revision labels instead of revision dates, but beyond this I= think that it should just be a flat list of modules that defines the schem= a.=C2=A0 If a subset of features, or datastores, or import-only modules are= needed then the YANG library version (or URIs) can and should be used.

Another example of where I expect it to be useful is in YANG packages.=C2= =A0 Looking at the examples at the end of https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-pa= ckages, then some of those files (which currently aren't defining a= ny schema, but should) would almost double in size if they represented the = schema inline using YANG library, which I think would make the files harder= for humans to read/parse.=C2=A0 Using URIs could help mitigate this, but t= hen we would need to find a place to publish the file containing the YANG p= ackage schema (presumably somewhere in IANA), and it not obvious to me that= adding the dependency on the URL is really as helpful.


=
An original use-case in my 2013 draft was to allow a vendor = to define a package
that represented the entire server. Then the = entire <hello> and YANG library can
be replaced by one pack= age-id in this case. This is reasonable for embedded devices
that= have a fixed YANG library (expected for CORECONF).

BTW, the main reason I proposed the YANG syntax (your version has a JSON = document)
is that these files are needed by automation tools, and= YANG allows extensions
(and other things like augment). Automati= on tools cannot work without extensions
so not sure how JSON pack= age files will be useful to them.


Regards,
Rob

Andy
=C2=A0


> -----Original Message-----
> From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> Sent: 08 July 2021 11:35
> To: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>
> Cc: Andy Bierman <andy@yumaworks.com>; Rob Wilton (rwilton)
> <rwilton@cis= co.com>; netmod= @ietf.org; Benoit Claise
> <beno= it.claise@huawei.com>
> Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format<= br> >
> The question I asked is "how much simpler is it and does that sav= ing
> justify the introduction of a new rather limited format (that may risk=
> to grow over time and become a second citizen)".
>
> So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports > from ietf-yang-types (at the time of publication that resolves to
> ietf-yang-types@2013-07-15. So the YANG Library instance data would > roughly look this (please correct what I messed up, I am writing this<= br> > by hand):
>
> <yang-library>
>=C2=A0 =C2=A0<module-set>
>=C2=A0 =C2=A0 =C2=A0<name>m</name>
>=C2=A0 =C2=A0 =C2=A0<module>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<name>ietf-netconf-acm</name> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<revision>2018-02-14</revision><= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0<namespace>uri1</namespace>
>=C2=A0 =C2=A0 =C2=A0</module>
>=C2=A0 =C2=A0 =C2=A0<import-only-module>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<name>ietf-yang-types</name>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<namespace>uri2</namespace>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<revision/>
>=C2=A0 =C2=A0 =C2=A0</import-only-module>
>=C2=A0 =C2=A0</module-set>
>=C2=A0 =C2=A0<schema>
>=C2=A0 =C2=A0 =C2=A0<name>s</name>
>=C2=A0 =C2=A0 =C2=A0<module-set>m</module-set>
>=C2=A0 =C2=A0</schema>
>=C2=A0 =C2=A0<datastore>
>=C2=A0 =C2=A0 =C2=A0<name>running</name>
>=C2=A0 =C2=A0 =C2=A0<schema>s</schema>
>=C2=A0 =C2=A0</datastore>
> </yang-library>
>
> Yes, this is a bit longer, but it also conveys more information (note<= br> > that your datastore leaf in the header would likely not be needed
> anymore).
>
> I am concerned that we start creating another format to define schemas=
> that is very limited and people later come with extension proposals to=
> address some of the limits and at the end we have multiple formats to<= br> > maintain and deal with. So the question is whether people think this > is worth it. (Note that the felt overhead goes down with every
> additional module used by your instance file, so the example above is<= br> > really the most extreme case. And if you have many modules defining > NACM rules, then you put the above into a separate file and use the > URI to point to the schema, no?
>
> /js
>
> On Thu, Jul 08, 2021 at 09:27:52AM +0000, Bal=C3=A1zs Lengyel wrote: > > Hello Jurgen,
> > Inline:
> > This complex form of inline was requested and not objected earlie= r by
> other
> > reviewers.
> > Based on Rob's and others' proposal inline will be simpli= fied to use only
> > ietf-yang-library@2019-01-04 as you suggest.
> >
> > Simplified inline:
> > In Ericsson we already use simplified inline a lot, it is the mos= t common
> > format.
> > If you are providing data only for one or a few YANG modules and = don't
> have,
> >
> > don't care about features/deviations it is the easiest, short= est method to
> > use.
> >=C2=A0 Our most common use-case is to provide preconfigured access= control
> rules
> > for new nodes.
> > When a YANG modeler designs a new module, he immediately provides= a
> set of
> > NACM rules
> > for the readOnly and the SystemAdmin roles/groups.
> > In this case you only need to specify "ietf-neconf-acm@2012-= 02-22" No
> > deviations, no features to indicate.
> > Regards Balazs
> >
> > Regards Balazs
> >
> > -----Original Message-----
> > From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.= de>
> > Sent: 2021. j=C3=BAlius 7., szerda 21:26
> > To: Andy Bierman <andy@yumaworks.com>
> > Cc: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>; Rob Wilton= (rwilton)
> > <rwilto= n@cisco.com>; n= etmod@ietf.org; Benoit Claise
> > <benoit.claise@huawei.com>
> > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-fo= rmat
> >
> > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote:
> > >
> > > > Inline method is needed, if you want to indicate that t= he file was
> > > > generated by someone who uses some YANG modules with de= viations
> and
> > > > some features are not-supported. There is no way to ind= icate
> > > > feature-support and deviations with the simplified-inli= ne method.
> > >
> > > The Inline anydata solution is very heavyweight.
> > > Before the YANG library there was a simple URI that is easie= r to use
> > > and takes up much less storage.
> > >
> >
> > The inline content schema is super generic since it supports an o= pen ended
> > set of schema defining modules. While you can use it with say
> > ietf-yang-library@2019-01-04, you can use anything else as well. = In other
> > words, two implementations supporting inline content schema may n= ot
> > interoperate. I do not think there is a schema format that is man= datory to
> > implement for inline content schema.
> >
> > So here is my assessment of what we have in terms of interoperabi= lity:
> >
> > - Simplified-Inline comes with notable restrictions, interoperabl= e
> > - Inline is an open ended content schema, not necessarily interop= erable
> > - URI method pushes the problem to another instance file, interop= erable
> > - External is by desing not interoperable
> >
> > On the server side, we have YANG Library. Perhaps RFC 8525 has so= me
> > complexity that is useful for supporting large servers with multi= ple
> > datastores and not needed for small instance files (I understand = that an
> > instance file is always tied to a single datastore?).
> >
> > To me, it feels that reusing RFC 8525 design is actually a good t= hing. Being
> > able to dump a live server datastore into an instance file seems = like a very
> > valid use case to me and ideally this is possible without having = to rewrite
> > the schema part. Well, you could go and trim unused datastore sch= emas
> and
> > from there unused module sets etc but that can all be done by an = external
> > tool trimming the schema part, i.e., it does not need to be done = by a tool
> > that just dumps a server datastore.
> >
> > What is the actual value of simplified inline? How much do you re= ally save
> > compared to the simplest equivalent RFC 8525 representation? And = does
> that
> > saving justify to start engineering another schema specification = format?
> >
> > I guess my choice would have been to just have
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-- content-schema
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 +-- (content-schema-spec)?
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0+--: (yang-librar= y)
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0+--: (uri)
> >
> > but others obviously want much more choice (but lets note that ev= erything
> > sits in a choice, so everything is extensible in case other schem= a
> > definition formats are out there).
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac= obs University Bremen gGmbH
> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 3103
> > <https://protect2.fi= reeye.com/v1/url?k=3Dfe85c8e6-a11ef1cd-fe85887d-
> 866038973a
> > 15-19e5dad375af0063&q=3D1&e=3D3637406d-f774-4073-80ee- > a7431111e9bc&u=3Dhttps%3A%2F
> > %2Fwww.jacobs-university.de%2F>
>
>
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;https://www.jacobs-university.de/>
--000000000000e5a87805c6a2a1f7-- From nobody Thu Jul 8 14:45:34 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2FC3A201C; Thu, 8 Jul 2021 14:45:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-netmod-nmda-diff@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, Joel Jaeggli , joelja@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <162578071895.23622.6414701243842084826@ietfa.amsl.com> Date: Thu, 08 Jul 2021 14:45:18 -0700 Archived-At: Subject: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-nmda-diff-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2021 21:45:26 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-netmod-nmda-diff-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Alexey Melnikov for the secdir review. I'm not experienced enough with YANG to know whether or how problematic it is that the "anydata subtree-filter" node contents are described by reference to the NETCONF specification, which has a particular (XML) representation of YANG data and does not give a clear presentation of the abstract YANG structure/semantics to be used. Is it possible to use the filter-spec choice option when, for example, RESTCONF is used with JSON encoding? Section 4 o report-origin: When set, this parameter indicates that origin metadata should be included as part of RPC output. When this parameter is omitted, origin metadata in comparisons that involve is by default omitted. Why is it important to complicate the semantics of this parameter with a dependence on the datastore? It seems like it would be simpler to get this effect by having clients specify report-origin when the target is not . Note that changing the semantics would require text changes in subsequent parts of the document for consistency. (If retaining the current semantics, please clarify whether "comparisons that involve " applies when operational is source, target, or either.) Section 9 In addition to noting that the "compare" RPC is sensitive and should be restricted to authorized parties, I suggest to reiterate that the "compare" operation should not provide a mechanism to work around access control on other nodes -- that is, a result should only be returned if the requestor would be allowed to access both the "source" and "target" trees independently of the RPC. In particular, even a "no-matches" output should not be returned, as that might provide a way to determine the structure of the datastore even without accessing it. We might also incorporate by reference the security considerations for subtree filtering (RFC 6241) and xpath filtering (RFC 6991). NITS Section 1 an unusually long time to do so. This can be the case due to certain conditions not being met, certain parts of the configuration not propagating because considered inactive, resource dependencies not being resolved, or even implementation errors in corner conditions. "because considered inactive" seems like an incomplete clause; maybe "because they are considered inactive"? Section 4 o differences: This parameter contains the list of differences. Those differences are encoded per YANG-Patch data model defined in s/YANG-Patch/the YANG-Patch/ I'd also consider s/per/according to/, since this is not exactly a logic-driven deduction but rather more of a new requirement. Section 6 for the management of interfaces defined in [RFC8343]. The excerpt of the data model whose instantiation is the basis of the comparison is as follows: I feel like this phrasing is a little misleading, as not only is the following snippet only a subset of the nodes contained within "container interfaces" but the descriptions have been greatly abbreviated as well. Perhaps we could say something about "for the purposes of understanding the subsequent example, the following subset of the [RFC8343] data model is provided". Accept: application/yang-d (I believe this truncated header field was already noted by another reviewer.) From nobody Fri Jul 9 00:25:15 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B513A15F8 for ; Fri, 9 Jul 2021 00:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGsgxkLo1dVh for ; Fri, 9 Jul 2021 00:24:56 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2074.outbound.protection.outlook.com [40.107.20.74]) (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 5C18C3A15EC for ; Fri, 9 Jul 2021 00:24:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c/XksdulW03D57Ce+tkyjplzNhfwsSV3ow/aau2NaMEt01fzTWDxXOpWo11UZP8eskhAgTUVAU+Ca1LUYSUC+jOSu5apr4VwivJdXY59xRYQ47SCRaJP93Jx/UE32mfAyQbIIBsfnLCxt/92OIVqOYlQi62hWhtSzTGv2CcAInZ2tsZS+8aK15hu82Vcf52Sv/ZQMxryC8lQR1QRMkbh+g+LwCfAvezAKZYhhIM7TPySvJUnrgbKB83Q6QV5bZF7Jmwhh202UdKW9U1VBRWUqn4ojH0+v7rd6gu01GNUdmiHTMroWr32qv2xqRdP6p0IpuNNGzsgX/0OR2a6odSR+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t3QfcYmAzq1Rd/fi+4VHeUJOi19KMsSFVjdokuuwZJM=; b=gFGChyTZkfpumk1g/N4oTqWU6eRnwnZbkQly24wvgZyXyWwNw3dGUyV1wmgH9faAuouHNIANFk2au4sZstrfPK5Qj/dHjFwOT3oGK8hQRC+RVQyV9OvT/pdi5j6CXeyXeGqXHBNoUl8z3asVl+AI7Ebs7L3x7kKH7g8wt8ti9XRwfPSIjH2q3W6K44TV5ZOQ8AXyriAIzgMbFhyWhIfEqBnQDzWyS2vKeiQQYiw5Es5tdN6YzsNLYv5sWsvCREH7clfLNWPtZQFOcdTc5XALLFMqOtj5kfKeWKcoSV4nXpWbxYx+3Sg1b3SD6bvD3QZgxFYC3F+9lZ0xsRiu9gfQiA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t3QfcYmAzq1Rd/fi+4VHeUJOi19KMsSFVjdokuuwZJM=; b=h3K8TmLkWA/pMIEIVzVH3sd3Vdb9JwMxdNEBB4q+ywU1b17ILJ/qYGqfcxRth7w+qIxk1aDz1NSiuaMnoRAM2Ln+gFvsnnoW/AsCI7dWFrYsmKQooZlSAmz4e5Z14vbhF0nqKRy1/ad0UyFM617bbO+bbfmKU08iltgD5X0D73Y= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8262.eurprd07.prod.outlook.com (2603:10a6:20b:325::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.12; Fri, 9 Jul 2021 07:24:52 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4308.018; Fri, 9 Jul 2021 07:24:52 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: "Rob Wilton (rwilton)" , Juergen Schoenwaelder CC: Andy Bierman , "netmod@ietf.org" , Benoit Claise Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAPXLWAAAIT0wAAAIMhAAAAy2eAAAJlLwAAGf35QAAVpNcAAAKQ2AAAHRePIAACr5QAAAAUxvAAAke7IAAESQ+gACTRU5A= Date: Fri, 9 Jul 2021 07:24:52 +0000 Message-ID: References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> <20210707192534.4emim5a36zyqrktc@anna.jacobs.jacobs-university.de> <20210708103528.6ezr4v5qeltinvmv@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4488b55d-8d62-4b00-2e0a-08d942aaa4b7 x-ms-traffictypediagnostic: AM8PR07MB8262: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qvlJPCbwVPLkQoB09kVHRes3e1wt1rGejdQZ7QMMYF4XaWphNyJZb5GvOsGFNkmpNtYCEyY4fbq3poGOhvouPyaWYgheVbvX5gLPelhVSXZv0EfYcPICkLrCg4rWkDt0cu9j+w29OFxg3lZiyEROHhPZ6C7IdVPHrqngj31qxLkfz8JWb6q260J1x2vITH22Q+ENhGYAml2Ths0Pis9bVBo1mlsF4CGXFlwu4i4goXLBNYBlQBVSESKkPqj62vmBFkYXpTsw2RDOswYPhfDA1xdUnkEZogqTWoFvnHn2Z9evpYhqfiI1XiYsL4ODqEiSbp1J4ehZifvotwe2Zo5rLHQmCjitirzPc1yLDvtW9xWN19LGFH5liruCBgayXs/N66jTtJXvKghLM1XdjiPxiBBOXgyHLe5BZJgRaM7Y+ei+nDWbifhX6O8HAKlHEXu2mJccv7ZQyuyD0mVHfJ01ScLq2X92esC8p7lxA5AUxsLn4OCHwoZyx3sPx73hRQNFe6HqauR+mI5ha6Nsayzs95LAW1OXl5k33IRB3/byubD4DkW70lkFDX3afuRw2+a8MZ+JNKeKxW/NvgJEtFAXbW7PgljOkVuYyyheWY1gftkZr6/fyu/LhIXNE6lueaAyMm2bgzineqru0XMnapQhHO/KJ8okU26vTxYCty2K5PVokvgQpn5I3fwbm8/fxHjega+8NqE7M3McA+JjJoNpbEueMB1DwHFmtLkduUsBrzkbf/TTMmObfjMTZg4sq5XIZRTRM3SUpaphupdUEfPWiA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(346002)(366004)(39860400002)(376002)(53546011)(33656002)(99936003)(6506007)(66574015)(2906002)(4326008)(38100700002)(55016002)(122000001)(66616009)(5660300002)(8936002)(66946007)(110136005)(478600001)(76116006)(316002)(7696005)(66556008)(83380400001)(54906003)(66476007)(8676002)(86362001)(64756008)(66446008)(26005)(71200400001)(52536014)(966005)(186003)(9686003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?gJetJQEYRPF5Vw6PbDwbmCkm7hCyl3MflH5KTEeyMVd7q1AzsMvEkefy6j?= =?iso-8859-1?Q?T14VoyplzU6nxIQF1Pn/ReL1ZkJYJLGrBBrRbnLmlUQOZdhuOAcl55Grot?= =?iso-8859-1?Q?7clQHMjJHzH37CaXSBkVcyWuLW2RHeNadufM0Sd+kA/2ym+EWJr64rFM8B?= =?iso-8859-1?Q?niU1MXsSvztO5n2wg/x7ZZtApvczRLP6gIDWOTrebHqNH8KE360mSAsNzy?= =?iso-8859-1?Q?k7hdngKv57DgX5gMjMj4Ru6DWEGJfh2NEGTWBboe8BYsKhPIyE+wO8Kn/0?= =?iso-8859-1?Q?BRyb/IBduXIdpIUOx1xEzjxqzb8rfwKFt1sUnz8OY9s0eS1yJeEPy7NOlq?= =?iso-8859-1?Q?tP6uYJiie5nN97JJ/Zw1bXMxz8krm7c4DbtzDz9TgLroTp44j3L31iWZjQ?= =?iso-8859-1?Q?fzd0eTDNTfsgZyjeZqb0+ONZOjZzhVhlKk6yi9pZkxzmeZoZbMiGy7cuwf?= =?iso-8859-1?Q?bfGBOdxtdXbXUn6YqTNtd13sMJ7IORnkK9LCPQxwlKdRvCiDDohFkoEOIs?= =?iso-8859-1?Q?trUhyfhTiuo8mfdG3BQ0K9b9Ce+hRFzx38tt/ZS5w3/QLrlF30vsDiLLBu?= =?iso-8859-1?Q?BzDODzXf/IDw3PzhcD8c91PiO/U3toxnBS6j3sHW+ZJXeTwENSDxYcX85m?= =?iso-8859-1?Q?crqDLfTjsnVUVGe6NUqMdO5zwoR56E29KhtHWF+N56V3QbhNSkzJ/6W6Os?= =?iso-8859-1?Q?WRUVSW3VVDQ8z/dOJvMudYeWkLG1lRPD0TCSo4Idu6jeSY7hM0ByMgOMCb?= =?iso-8859-1?Q?LSEwep7RI3dfVyB2tiikFekuPz0JoJgby4AUBWzBM0+coubgx0VEeXexG/?= =?iso-8859-1?Q?rx/WTvZLc7Z7PNnWDo0yXYRwuFVKgtunx7QLO9zQqnkVNph72t5xwGcH42?= =?iso-8859-1?Q?MUzKWPniipPhAs/x7T6Fxj4blW5r4DvabKaT7/0em/fj/6spm14vAMrTaL?= =?iso-8859-1?Q?CH7/pkYXaeNgCmsnY9C4jPWmaW4ZK+LoxCK3BRCDIlIW2L3gRdcQ9E5wVS?= =?iso-8859-1?Q?cLFLmb8ibsfR5LrpOXbDX6edfHvOrM0SshIEgIAiXc/frLOkc4V3TswgYA?= =?iso-8859-1?Q?0UTd5/k4sKHsokSONUFuXABQJ0TNWZSxnSJS5z798Ptb1sO0LUCf8aU7vE?= =?iso-8859-1?Q?hDLA7e5UvGwiAn8zu5b255biuVvb4IBIfUb5skc0CVdLBfj/dZt/s8pNCe?= =?iso-8859-1?Q?0pWGQoT5mvo6NTdwKCi65j6LahfPZCw5VQTVHJeBK0OFDpHpqTmf13eKTG?= =?iso-8859-1?Q?5bLeef3X28Zh2llDOBNiiJYyIbGWV4GpV9tpWFy+u7iJHnUCEtCqoTUITE?= =?iso-8859-1?Q?+kbhbkOQCwD4lDLGkFDz8bHF9epKToseiN4OyKof6RDX5kJGfFMWYeoPGz?= =?iso-8859-1?Q?L7KacFWsc5?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_04BE_01D774A4.44AA9ED0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4488b55d-8d62-4b00-2e0a-08d942aaa4b7 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2021 07:24:52.4430 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gjavUdkXVoaPuakykA58nrQWoCqHfQTFe/TQYc/Z+1bZt1mOh6UdTlMtYSmyT+lvW+BVUtpIL+yhl+NCwvlPd8lAbAS6+UP5pVSsCHvAjl4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8262 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 07:25:14 -0000 ------=_NextPart_000_04BE_01D774A4.44AA9ED0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, A single line is enough. As long as ietf-yang-types is change in a backward compatible way, I = don't care which version of yang-types is imported. Also, we only use a single type 'yang:xpath1.0' from yang-types. The rules for this type are = described by W3C and not changing.=20 Balazs -----Original Message----- From: Rob Wilton (rwilton) =20 Sent: 2021. j=FAlius 8., cs=FCt=F6rt=F6k 15:49 To: Bal=E1zs Lengyel ; Juergen = Schoenwaelder Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format Hi Balazs, Would your inline schema not also need to specify the ietf-yang-types dependency? E.g., should it be: ietf-netconf-acm@2018-02-14 ietf-yang-types@2013-07-15 Thanks, Rob > -----Original Message----- > From: Bal=E1zs Lengyel > Sent: 08 July 2021 12:48 > To: Rob Wilton (rwilton) ; Juergen Schoenwaelder=20 > > Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise=20 > > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format >=20 > Hello, > I would like to keep simplified inline. If I ask my developers (not=20 > experts) which one do they want? I am pretty sure they opt for the=20 > shorter/simpler one. >=20 > ietf-netconf-acm@2018-02-14 >=20 > OR >=20 > > > m > > ietf-netconf-acm > 2018-02-14 > uri1 > > > ietf-yang-types > uri2 > > > > > s > m > > > running > s > > >=20 > Regards Balazs >=20 > -----Original Message----- > From: Rob Wilton (rwilton) > Sent: 2021. j=FAlius 8., cs=FCt=F6rt=F6k 12:59 > To: Juergen Schoenwaelder ;=20 > Bal=E1zs Lengyel > Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise=20 > > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format >=20 > Hi Juergen, >=20 > I believe that having the simple form is worth the extra complexity. >=20 > I think that you are right to be concerned that it should not expand=20 > into a separate parallel format. Overtime, I would like the simple=20 > form to be able to use revision labels instead of revision dates, but=20 > beyond this I think that it should just be a flat list of modules that = > defines the schema. If a subset of features, or datastores, or=20 > import-only modules are needed then the YANG library version (or URIs) = can and should be used. >=20 > Another example of where I expect it to be useful is in YANG packages. > Looking at the examples at the end of > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, = > then some of those files (which currently aren't defining any schema,=20 > but should) would almost double in size if they represented the schema = > inline using YANG library, which I think would make the files harder=20 > for humans to read/parse. > Using URIs could help mitigate this, but then we would need to find a=20 > place to publish the file containing the YANG package schema=20 > (presumably somewhere in IANA), and it not obvious to me that adding=20 > the dependency on the URL is really as helpful. >=20 > Regards, > Rob >=20 >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder > > Sent: 08 July 2021 11:35 > > To: Bal=E1zs Lengyel > > Cc: Andy Bierman ; Rob Wilton (rwilton)=20 > > ; netmod@ietf.org; Benoit Claise=20 > > > > Subject: Re: AD review of=20 > > draft-ietf-netmod-yang-instance-file-format > > > > The question I asked is "how much simpler is it and does that saving = > > justify the introduction of a new rather limited format (that may=20 > > risk to grow over time and become a second citizen)". > > > > So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports=20 > > from ietf-yang-types (at the time of publication that resolves to=20 > > ietf-yang-types@2013-07-15. So the YANG Library instance data would=20 > > roughly look this (please correct what I messed up, I am writing=20 > > this by hand): > > > > > > > > m > > > > ietf-netconf-acm > > 2018-02-14 > > uri1 > > > > > > ietf-yang-types > > uri2 > > > > > > > > > > s > > m > > > > > > running > > s > > > > > > > > Yes, this is a bit longer, but it also conveys more information=20 > > (note that your datastore leaf in the header would likely not be=20 > > needed anymore). > > > > I am concerned that we start creating another format to define=20 > > schemas that is very limited and people later come with extension=20 > > proposals to address some of the limits and at the end we have=20 > > multiple formats to maintain and deal with. So the question is=20 > > whether people think this is worth it. (Note that the felt overhead=20 > > goes down with every additional module used by your instance file,=20 > > so the example above is really the most extreme case. And if you=20 > > have many modules defining NACM rules, then you put the above into a = > > separate file and use the URI to point to the schema, no? > > > > /js > > > > On Thu, Jul 08, 2021 at 09:27:52AM +0000, Bal=E1zs Lengyel wrote: > > > Hello Jurgen, > > > Inline: > > > This complex form of inline was requested and not objected earlier = > > > by > > other > > > reviewers. > > > Based on Rob's and others' proposal inline will be simplified to=20 > > > use only > > > ietf-yang-library@2019-01-04 as you suggest. > > > > > > Simplified inline: > > > In Ericsson we already use simplified inline a lot, it is the most = > > > common format. > > > If you are providing data only for one or a few YANG modules and=20 > > > don't > > have, > > > > > > don't care about features/deviations it is the easiest, shortest=20 > > > method to use. > > > Our most common use-case is to provide preconfigured access=20 > > > control > > rules > > > for new nodes. > > > When a YANG modeler designs a new module, he immediately provides=20 > > > a > > set of > > > NACM rules > > > for the readOnly and the SystemAdmin roles/groups. > > > In this case you only need to specify "ietf-neconf-acm@2012-02-22" > > > No deviations, no features to indicate. > > > Regards Balazs > > > > > > Regards Balazs > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > Sent: 2021. j=FAlius 7., szerda 21:26 > > > To: Andy Bierman > > > Cc: Bal=E1zs Lengyel ; Rob Wilton > > > (rwilton) ; netmod@ietf.org; Benoit Claise=20 > > > > > > Subject: Re: AD review of > > > draft-ietf-netmod-yang-instance-file-format > > > > > > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote: > > > > > > > > > Inline method is needed, if you want to indicate that the file = > > > > > was generated by someone who uses some YANG modules with=20 > > > > > deviations > > and > > > > > some features are not-supported. There is no way to indicate=20 > > > > > feature-support and deviations with the simplified-inline = method. > > > > > > > > The Inline anydata solution is very heavyweight. > > > > Before the YANG library there was a simple URI that is easier to = > > > > use and takes up much less storage. > > > > > > > > > > The inline content schema is super generic since it supports an=20 > > > open ended set of schema defining modules. While you can use it=20 > > > with say ietf-yang-library@2019-01-04, you can use anything else=20 > > > as well. In other words, two implementations supporting inline=20 > > > content schema may not interoperate. I do not think there is a=20 > > > schema format that is mandatory to implement for inline content schema. > > > > > > So here is my assessment of what we have in terms of = interoperability: > > > > > > - Simplified-Inline comes with notable restrictions, interoperable > > > - Inline is an open ended content schema, not necessarily=20 > > > interoperable > > > - URI method pushes the problem to another instance file,=20 > > > interoperable > > > - External is by desing not interoperable > > > > > > On the server side, we have YANG Library. Perhaps RFC 8525 has=20 > > > some complexity that is useful for supporting large servers with=20 > > > multiple datastores and not needed for small instance files (I=20 > > > understand that an instance file is always tied to a single datastore?). > > > > > > To me, it feels that reusing RFC 8525 design is actually a good=20 > > > thing. Being able to dump a live server datastore into an instance = > > > file seems like a very valid use case to me and ideally this is=20 > > > possible without having to rewrite the schema part. Well, you=20 > > > could go and trim unused datastore schemas > > and > > > from there unused module sets etc but that can all be done by an=20 > > > external tool trimming the schema part, i.e., it does not need to=20 > > > be done by a tool that just dumps a server datastore. > > > > > > What is the actual value of simplified inline? How much do you=20 > > > really save compared to the simplest equivalent RFC 8525=20 > > > representation? And does > > that > > > saving justify to start engineering another schema specification format? > > > > > > I guess my choice would have been to just have > > > > > > +-- content-schema > > > | +-- (content-schema-spec)? > > > | +--: (yang-library) > > > | +--: (uri) > > > > > > but others obviously want much more choice (but lets note that=20 > > > everything sits in a choice, so everything is extensible in case=20 > > > other schema definition formats are out there). > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > > > Fax: +49 421 200 3103 > > > = > 866038973a > > > 15-19e5dad375af0063&q=3D1&e=3D3637406d-f774-4073-80ee- > > a7431111e9bc&u=3Dhttps%3A%2F > > > %2Fwww.jacobs-university.de%2F> > > > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > > Fax: +49 421 200 3103 > 86e2237f51 > fb-eceadf4f1dc08461&q=3D1&e=3D09140141-b70c-44c9-9909- > 048d736efebf&u=3Dhttps%3A%2F > %2Fwww.jacobs-university.de%2F> ------=_NextPart_000_04BE_01D774A4.44AA9ED0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDcwOTA3MjQ1MFowIwYJKoZIhvcNAQkEMRYEFNJn8031TRb4 2wFM/F6FUITuPSiBMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAAfk 45tLJJV6c7f5wqhItFjaI6DQ0cWM/VXjgKvnsWsxpDqL8FjiDwdZ9TSmyZFxVVgIHtIzuwh9xkbp EOIZ9DlteIh9DzHlgMviqDkhCor4FXdA3Wu4WbYnBv/U5w3Sred3kqXdcpVDSbbbahl3idnjIvTT zQ0SM2UEbX7mIobNOPXcFVyHpWYmI9nvkUlPU0zienUbCjmYwasXwRIJ1pTG12duIR4keYpDELOS egNBM2JtGCU5c3WhuZRH+/550RDK4htk9OWo43zHO7fdbkH93AlbiTtqyAHlxYqyVohYQxij7kZU LHl5FvmqslvOqAUPhCZjNbV0Czck98KQRxAAAAAAAAA= ------=_NextPart_000_04BE_01D774A4.44AA9ED0-- From nobody Fri Jul 9 00:39:05 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4192E3A165C for ; Fri, 9 Jul 2021 00:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMhSEI5OmuGS for ; Fri, 9 Jul 2021 00:38:57 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2065.outbound.protection.outlook.com [40.107.20.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 633A13A1659 for ; Fri, 9 Jul 2021 00:38:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZnHd6+SzoUY2PwC5HF0bBLCPRuI7TodAlhS7P0lt8VsP1DNdaDB5ULFq72J2kFR6dLA70pA9mMDnmuZ1ZppvhsDlVLN7T0w/7114LY6o29iRfZA1Fco78CxSfWQatP6Et6LAEAcxQigAVTF52FQxni7wwz47p2V8sHxp76llt3VqRQ0gJld534qM3+FdZ6ECtqkh681eIVnwT8VKHGv4bJPUE85IlZQPgxQUgvnwFRIXkcK6c11NLcMxmLyH7ExCREDffQQkeO68ZnqzfsjVCunM7RIErIhnXhzUZlph3SpJ53VvtY+xMwjhpLQ+bDeJFjF8vghMMKlwus75ZaTG/g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Od7ZM9JMAA6kMmotRNRxGc3fXA6DuDvdqOpFF++L8io=; b=WA8yojTqTMIV/CXxLrIv+32BItDg8GGukCKA+a1UpDj88pB4CQ0WKj8Pl4ZacXuWoHwGAH1f0bBl9HQCQEstpG3kY3th9rhadw25/F/jDHHZN3DLqDk0/jBtEK/4fNd29GXNBathbTvKUyb9qELmGXzHdOB6gvUBpOJN/8RFFxCaeoKHSEEiOvQDtc6ZHGWmLaAocSFGUeDoTA6mEdoe87Sk2mHRScMEPShr7WJau6W8rYaV2aVtfJYfSd/KqnYTvFMeW4oB5xrgNCFH6KVyDHKPZtY7BHoObiRKDVHu0ZUddGt1sMIYYAcBM8uwXsKfslOJ8vb75JycYNnpY/rdbA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Od7ZM9JMAA6kMmotRNRxGc3fXA6DuDvdqOpFF++L8io=; b=b4Xx0dvFJRfsxmc1Ta0ii31SCLyPiXSD5lotAAa+zVpoJPiOX/19wOrihqkv9dVCWZ7Q01XNzFKxbFn7cyR2dR+eh6Hvn4+6sqRYeDA8h1rWBCd+pc2oQidT3owwDuBqf+1nmw6AqMIV9bL0YaxFW/JVhirV0OXcpw1cViORDHY= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8294.eurprd07.prod.outlook.com (2603:10a6:20b:329::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.14; Fri, 9 Jul 2021 07:38:53 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4308.018; Fri, 9 Jul 2021 07:38:53 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Andy Bierman , "Rob Wilton (rwilton)" CC: Juergen Schoenwaelder , "netmod@ietf.org" , Benoit Claise Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAPXLWAAAIT0wAAAIMhAAAAy2eAAAJlLwAAGf35QAAVpNcAAAKQ2AAAHRePIAACr5QAAAAUxvAADSn9gAAel4Vg Date: Fri, 9 Jul 2021 07:38:53 +0000 Message-ID: References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> <20210707192534.4emim5a36zyqrktc@anna.jacobs.jacobs-university.de> <20210708103528.6ezr4v5qeltinvmv@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; yumaworks.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c31a7bc1-931b-4781-f5ec-08d942ac9a3e x-ms-traffictypediagnostic: AM8PR07MB8294: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3383; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7dYtgpr7JHh5MQOopy721qZcacQKttWKP0VS3afsF6VoAwPfSuPmJDjVrIHbZNnxpACiI7YUV/JhrRqxz2ZDChLb7Rh50gXAoQlcHzIjna6Uzc4cFMmwG1/DWBuO/eQHGb00JVgbBRs1ZlDCXnRh3Wra8Z5EnebcMwqSkJ7HdoM0XUjt7DoO4+VapIomAlf9JtgIoe7QawzKpQzBagnE+EZA9L0JqC6a5ZtLRiQnJb3kiCAR8CKfWrrgUoOaDLiqTqbIlTHe2gI2KUUWjoLhUkJvpXahdq7njgsMwoZjzAmX+4PHuScdXRnT4thYpmLHCuRaMwn9aTV0aGLQgaa/P2bjDQ+O5Pm6/tXYSSsnNHENc2QpuwqVt6ILtyv4LcpIlZpxNYUsU3BoEUyGVlMyKUMK/nELUVb+2OnnOkfteUKA3yP1gm8+qM7Ykxm9MztmeDqrC3iTQ7quTYuLyT2dZAe4TbIfDM9EvdYesDmfpVMP5sorAO6u2fJd1Ei+W0pdnMrnKN8tka3LbeMYVkqthaIXg6TGwNXRLek4LA/Lrq2YZ2t6axDa6pN7P92ag/eAQqzno1y4bP7LG1263ovLuWMhYIMxdmKzw8UMBeUskUh1LTvNSpUq7UmjcPPf+iSnGvOFIFzeLCDeasn+2BAUJzzfhPXN3yVWGU5iptpdAsTZuNGv/vET5SlQXerBv9D0pFF3Zr+NAfJTE1aqIwEcs9V4OLkMfquj1uPvxVLTvq8mI+vBDn63X3I008SEjw/4t/ksYnkdorCfeVXvTbP8IQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(366004)(396003)(39860400002)(376002)(66946007)(76116006)(110136005)(86362001)(4326008)(966005)(8936002)(7696005)(55016002)(9686003)(8676002)(83380400001)(66574015)(316002)(166002)(2906002)(478600001)(5660300002)(85202003)(26005)(71200400001)(38100700002)(122000001)(99936003)(9326002)(52536014)(66476007)(66556008)(66616009)(66446008)(6506007)(30864003)(64756008)(54906003)(33656002)(85182001)(186003)(53546011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?U0lxdUZvWGo0K1RaYjZWVjArdi85eVFEdnZQZU9OUFdWekc0QkdVVzRQV0Fv?= =?utf-8?B?eThISlBiMDlsbVVxN0JYRHdRNnI2Y1RNSXhZaHplSUZpa0QyWTc4eE5oK2ti?= =?utf-8?B?aGFmSEI3RFd5R1R6b2xwcDM5ODMzblNETVVpMTdjNXowd3FMZnUrVjIzWUVk?= =?utf-8?B?R3pFS1hIWTZIakY3Ui9GNXN6SUtoNmt6RkRVbnQ0eFl5a0VYeGJVdFArUFRu?= =?utf-8?B?SVhHazB5NzdLTElUOTdnUFZLZjRUa3ZHOVVZRXIzTlpFdjBpcGlnRmNsWTZL?= =?utf-8?B?VUljcWk2U3pVb0M4MFdMMjZhRk5OMmNFRXJDSE9uQW1EVDJlY3dwNk1yMjY2?= =?utf-8?B?anZGamQyZjJZcEFiZ3BsdjF0Z3hQQTRjck1mV0phc3BHQ1lQSmM4R2JMNWxN?= =?utf-8?B?a1JybTkyQjFKUFFDeVZua0o0czdlSFlzNVVCUGNOVnJNSEVZQ0lsWnZGL0lr?= =?utf-8?B?TjlLaWNBM3VvenA2R0QxZmg5SXZPWmh5R3k4c0c0Q042Yld3WG9VNkVXWURw?= =?utf-8?B?N2FEUXdMSHdXb0greFVkZW9VeUZHVlhVTFZYb29QY2pLbld0YkNYdHNJRDJl?= =?utf-8?B?TzVPbTI2RzdiYURjNGlxQVJiTVRMUzI1SE1seGNsK2liUi9hekVKNmZNOEhX?= =?utf-8?B?UHlKL3NMUy9UUkozVElUSGZMUHIzM1pXcjBvN3JhY0FkV05JU05yYjhqT1pT?= =?utf-8?B?QXAvdDFsV0lNYVVOREk5NzlCS3JjS1U0OVZhQ051ZHFZSVdFOC9Cekt2Um4y?= =?utf-8?B?ckdSV2xSUUhRVmRVYktYd1oxMUpuQk5yZ1hqOCttRzAyU2psZHZ6YkxUTXRk?= =?utf-8?B?MHM0aXU0TStINzBGQUpEcVc4Mmo4eHNQbmgrT0huTmc1VVEramxUS2Mram1h?= =?utf-8?B?ZlZsZ0xkYnoyWjNLZDFCOEY2dGZ6M0VQUk1jSHdsVnByaUl5UXJrdGtmWFRJ?= =?utf-8?B?emNUM0s3WHRvTjN1YW1KTWYyM2tQMUVYUllQMUV3SGxHMjFYdEtNWjVRS2NM?= =?utf-8?B?QXUwTXNSS2xCRU43SDdCUmdKclZydHcyMGNqblFVVGRqWkhzU2JwNU5mOThF?= =?utf-8?B?UlJwWWFsaDdSSVA1Ry9hZGd4TVFoOUF5eXFPb2k5UGRlNklhbnFwbDRoQ0RH?= =?utf-8?B?a3Z5cDNUeVpCNkV0ZHdJcUhZdU1sOXVMU3RvUWdUUVBiYzBvRElReGhvQzho?= =?utf-8?B?cnlCS1NhUmEvR29uTjFoZHU5QVJwODJmTmZIaXBBNksvZ3hCVWNqcDhNemRG?= =?utf-8?B?S3NFU1k3aFdtVDRqUmUydlltUWwvM0FmeU5TUVo0Z3phQno0bUVuM0RVTlQ2?= =?utf-8?B?SWFtTmFBK3lWYm9iQ3pubUxuR2w5WHBOVkQvWFpUTmIwK21CQXJub3RxN0Ev?= =?utf-8?B?bmFuK3hYdlZvM0ZleGxLMWUyNXRYcENMV2NKckduN1BPdDJMUEJQdWpLZE9k?= =?utf-8?B?SGFsZ3FEdmIzNnlnZDFlS0RDamV4cVdkdXMyNVlIcWhwNUdRUjgwZ3hRNkVN?= =?utf-8?B?amt3aVZzbjJLckVPWnlsK0tKL2pRZWVjWFQ0RURNL25rSmVsSEkrRWNMUXBK?= =?utf-8?B?a2FISUJQbUdRb2syb2ZMa1VNSEdZWk5YYkNaLzBwR2JYN2p4OFZPQXRhaDNC?= =?utf-8?B?SEVOQWFMK2VQTFBhRlhkZmtFdDIveHI3TkVVMFNDVkVQNkNPa3djQ3pqem92?= =?utf-8?B?aEhwWWpEazExc09pNFo2N0NEeHE5ZFpoUk1qM09RN3I3WXJHSHdFM2RsVGRk?= =?utf-8?Q?21PW3kMS9QE4v/xyaUeSReStpY/3W+vczEhH32g?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_04C2_01D774A6.3A539BB0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c31a7bc1-931b-4781-f5ec-08d942ac9a3e X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2021 07:38:53.8922 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Yvl8bXqX8GR3QvEYKB4HzrAQBq7OhdKjmUICPfBmByvm1cSJuXzEbvPDvDBnorxlvCJhXqQHlmDb0xD+KhJAwj9fi13N9eW/yzweAZ0GAXU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8294 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 07:39:03 -0000 ------=_NextPart_000_04C2_01D774A6.3A539BB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_04C3_01D774A6.3A539BB0" ------=_NextPart_001_04C3_01D774A6.3A539BB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Andy, See below. Balazs =20 From: Andy Bierman =20 Sent: 2021. j=C3=BAlius 8., cs=C3=BCt=C3=B6rt=C3=B6k 18:55 To: Rob Wilton (rwilton) Cc: Juergen Schoenwaelder ; = Bal=C3=A1zs Lengyel ; netmod@ietf.org; = Benoit Claise Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format =20 =20 =20 On Thu, Jul 8, 2021 at 3:58 AM Rob Wilton (rwilton) > wrote: Hi Juergen, I believe that having the simple form is worth the extra complexity. =20 =20 I believe it is the only option that does not have too much complexity. =20 The inline form seems to imply that the NMDA version of the YANG library = is used. Only 1 module set is ever shown, but of course the actual schema allows for much more complex instances than that, which the reader must = support. =20 Does this mean NMDA must be used or else a YANG data file cannot be = saved? So the reader is expected to look for the 'current' /yang-library and = then the 'deprecated' /modules-state? And then fish the anydata for whatever non-standard solution is in use? The procedures should be explained better so there is a better chance of = interoperability. BALAZS: No NMDA is not required. If it would there would be a clear = statement about it. Even in section 2.2.1. Documentation of server = capabilities the new (NMDA compatible) yang-library is used, but the = simple (non- NMDA) modules-state branch. =20 For the URI method, the reader must check for a broken chain of = reference and loops. The draft should say the uri references across N files MUST NOT create a = loop (similar language is in YANG wrt import loops). BALAZS: Someone (don.t know who) asked for longer reference chains. = However, I don=E2=80=99t see them as a common use-case. IMHO the most = common use-case for the URI method will be, when the consumer knows the = content-schema apriori, it only needs a reference to check that the = schema is what it expected. =20 For conformance purposes, I think YANG features are appropriate. IMO simplified-inline is mandatory-to-implement but the rest should=20 be optional. This way a tool can claim conformance and also the standard will provide a minimum level of interoperability. BALAZS: There are very different views about the preferred/required = methods. Also the needs of different use-cases are different. = That=E2=80=99s why we need all 3. =20 =20 Andy =20 =20 =20 =20 I think that you are right to be concerned that it should not expand = into a separate parallel format. Overtime, I would like the simple form = to be able to use revision labels instead of revision dates, but beyond = this I think that it should just be a flat list of modules that defines = the schema. If a subset of features, or datastores, or import-only = modules are needed then the YANG library version (or URIs) can and = should be used. =20 This can be done with augment if and when the versioning draft reaches = RFC =20 Another example of where I expect it to be useful is in YANG packages. = Looking at the examples at the end of = https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, = then some of those files (which currently aren't defining any schema, = but should) would almost double in size if they represented the schema = inline using YANG library, which I think would make the files harder for = humans to read/parse. Using URIs could help mitigate this, but then we = would need to find a place to publish the file containing the YANG = package schema (presumably somewhere in IANA), and it not obvious to me = that adding the dependency on the URL is really as helpful. Regards, Rob > -----Original Message----- > From: Juergen Schoenwaelder > > Sent: 08 July 2021 11:35 > To: Bal=C3=A1zs Lengyel > > Cc: Andy Bierman >; = Rob Wilton (rwilton) > >; netmod@ietf.org = ; Benoit Claise > > > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format >=20 > The question I asked is "how much simpler is it and does that saving > justify the introduction of a new rather limited format (that may risk > to grow over time and become a second citizen)". >=20 > So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports > from ietf-yang-types (at the time of publication that resolves to > ietf-yang-types@2013-07-15. So the YANG Library instance data would > roughly look this (please correct what I messed up, I am writing this > by hand): >=20 > > > m > > ietf-netconf-acm > 2018-02-14 > uri1 > > > ietf-yang-types > uri2 > > > > > s > m > > > running > s > > >=20 > Yes, this is a bit longer, but it also conveys more information (note > that your datastore leaf in the header would likely not be needed > anymore). >=20 > I am concerned that we start creating another format to define schemas > that is very limited and people later come with extension proposals to > address some of the limits and at the end we have multiple formats to > maintain and deal with. So the question is whether people think this > is worth it. (Note that the felt overhead goes down with every > additional module used by your instance file, so the example above is > really the most extreme case. And if you have many modules defining > NACM rules, then you put the above into a separate file and use the > URI to point to the schema, no? >=20 > /js >=20 > On Thu, Jul 08, 2021 at 09:27:52AM +0000, Bal=C3=A1zs Lengyel wrote: > > Hello Jurgen, > > Inline: > > This complex form of inline was requested and not objected earlier = by > other > > reviewers. > > Based on Rob's and others' proposal inline will be simplified to use = only > > ietf-yang-library@2019-01-04 as you suggest. > > > > Simplified inline: > > In Ericsson we already use simplified inline a lot, it is the most = common > > format. > > If you are providing data only for one or a few YANG modules and = don't > have, > > > > don't care about features/deviations it is the easiest, shortest = method to > > use. > > Our most common use-case is to provide preconfigured access control > rules > > for new nodes. > > When a YANG modeler designs a new module, he immediately provides a > set of > > NACM rules > > for the readOnly and the SystemAdmin roles/groups. > > In this case you only need to specify "ietf-neconf-acm@2012-02-22" = No > > deviations, no features to indicate. > > Regards Balazs > > > > Regards Balazs > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > > Sent: 2021. j=C3=BAlius 7., szerda 21:26 > > To: Andy Bierman > > > Cc: Bal=C3=A1zs Lengyel >; Rob Wilton (rwilton) > > >; netmod@ietf.org = ; Benoit Claise > > > > > Subject: Re: AD review of = draft-ietf-netmod-yang-instance-file-format > > > > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote: > > > > > > > Inline method is needed, if you want to indicate that the file = was > > > > generated by someone who uses some YANG modules with deviations > and > > > > some features are not-supported. There is no way to indicate > > > > feature-support and deviations with the simplified-inline = method. > > > > > > The Inline anydata solution is very heavyweight. > > > Before the YANG library there was a simple URI that is easier to = use > > > and takes up much less storage. > > > > > > > The inline content schema is super generic since it supports an open = ended > > set of schema defining modules. While you can use it with say > > ietf-yang-library@2019-01-04, you can use anything else as well. In = other > > words, two implementations supporting inline content schema may not > > interoperate. I do not think there is a schema format that is = mandatory to > > implement for inline content schema. > > > > So here is my assessment of what we have in terms of = interoperability: > > > > - Simplified-Inline comes with notable restrictions, interoperable > > - Inline is an open ended content schema, not necessarily = interoperable > > - URI method pushes the problem to another instance file, = interoperable > > - External is by desing not interoperable > > > > On the server side, we have YANG Library. Perhaps RFC 8525 has some > > complexity that is useful for supporting large servers with multiple > > datastores and not needed for small instance files (I understand = that an > > instance file is always tied to a single datastore?). > > > > To me, it feels that reusing RFC 8525 design is actually a good = thing. Being > > able to dump a live server datastore into an instance file seems = like a very > > valid use case to me and ideally this is possible without having to = rewrite > > the schema part. Well, you could go and trim unused datastore = schemas > and > > from there unused module sets etc but that can all be done by an = external > > tool trimming the schema part, i.e., it does not need to be done by = a tool > > that just dumps a server datastore. > > > > What is the actual value of simplified inline? How much do you = really save > > compared to the simplest equivalent RFC 8525 representation? And = does > that > > saving justify to start engineering another schema specification = format? > > > > I guess my choice would have been to just have > > > > +-- content-schema > > | +-- (content-schema-spec)? > > | +--: (yang-library) > > | +--: (uri) > > > > but others obviously want much more choice (but lets note that = everything > > sits in a choice, so everything is extensible in case other schema > > definition formats are out there). > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > > Fax: +49 421 200 3103 > > 866038973a > > 15-19e5dad375af0063&q=3D1&e=3D3637406d-f774-4073-80ee- > a7431111e9bc&u=3Dhttps%3A%2F > > %2Fwww.jacobs-university.de = %2F> >=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 > ------=_NextPart_001_04C3_01D774A6.3A539BB0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello Andy,

See below.

Balazs

 

From: Andy Bierman = <andy@yumaworks.com>
Sent: 2021. j=C3=BAlius 8., = cs=C3=BCt=C3=B6rt=C3=B6k 18:55
To: Rob Wilton (rwilton) = <rwilton@cisco.com>
Cc: Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de>; Bal=C3=A1zs Lengyel = <balazs.lengyel@ericsson.com>; netmod@ietf.org; Benoit Claise = <benoit.claise@huawei.com>
Subject: Re: AD review of = draft-ietf-netmod-yang-instance-file-format

 

 

 

On = Thu, Jul 8, 2021 at 3:58 AM Rob Wilton (rwilton) <rwilton@cisco.com> = wrote:

Hi Juergen,

I believe that having = the simple form is worth the extra = complexity.

 

 

I = believe it is the only option that does not have too much = complexity.

 

The inline form seems to imply that the NMDA version = of the YANG library is used.

Only 1 module set is ever shown, but of course the = actual schema allows

for = much more complex instances than that, which the reader must = support.

 

Does this mean NMDA must be used or else a YANG data = file cannot be saved?

So = the reader is expected to look for the 'current' /yang-library and then = the 'deprecated' /modules-state?

And then fish the anydata for whatever non-standard = solution is in use?

The = procedures should be explained better so there is a better chance of = interoperability.

BALAZS: No NMDA is = not required. If it would there would be a clear statement about it. = Even in section 2.2.1.=C2=A0 Documentation of server capabilities the = new (NMDA compatible) yang-library is used, but the simple (non- NMDA) = modules-state branch.

 

For the URI method, the reader must check for a broken = chain of reference and loops.

The draft should say the uri references across N files = MUST NOT create a loop

(similar language is in YANG wrt import = loops).

BALAZS: Someone (don.t know = who) asked for longer reference chains. However, I don=E2=80=99t see = them as a common use-case. IMHO the most common use-case for the URI = method will be, when the consumer knows the content-schema apriori, it = only needs a reference to check that the schema is what it = expected.

 

For conformance purposes, I think YANG features are = appropriate.

IMO = simplified-inline is mandatory-to-implement but the rest = should 

be optional. = This way a tool can claim conformance and also the = standard

will provide a = minimum level of interoperability.

BALAZS: There are very different views about the = preferred/required methods. Also the needs of different use-cases are = different. That=E2=80=99s why we need all 3.

 

 

Andy

 

 

 

 

I think that you are right to be = concerned that it should not expand into a separate parallel = format.  Overtime, I would like the simple form to be able to use = revision labels instead of revision dates, but beyond this I think that = it should just be a flat list of modules that defines the schema.  = If a subset of features, or datastores, or import-only modules are = needed then the YANG library version (or URIs) can and should be = used.

 

This can be done with augment if and when the = versioning draft reaches RFC

 

Another example of where I expect it to be useful is = in YANG packages.  Looking at the examples at the end of https://datatracker.ietf.org/doc/html/draft-ietf-netmod= -yang-packages, then some of those files (which currently aren't = defining any schema, but should) would almost double in size if they = represented the schema inline using YANG library, which I think would = make the files harder for humans to read/parse.  Using URIs could = help mitigate this, but then we would need to find a place to publish = the file containing the YANG package schema (presumably somewhere in = IANA), and it not obvious to me that adding the dependency on the URL is = really as helpful.

Regards,
Rob


> -----Original = Message-----
> From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> = Sent: 08 July 2021 11:35
> To: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>
> Cc: Andy = Bierman <andy@yumaworks.com>; Rob Wilton = (rwilton)
> <rwilton@cisco.com>; netmod@ietf.org; = Benoit Claise
> <benoit.claise@huawei.com>
> Subject: Re: = AD review of draft-ietf-netmod-yang-instance-file-format
> =
> The question I asked is "how much simpler is it and does = that saving
> justify the introduction of a new rather limited = format (that may risk
> to grow over time and become a second = citizen)".
>
> So lets take your NACM example. = ietf-netconf-acm@2018-02-14 imports
> from ietf-yang-types (at the = time of publication that resolves to
> ietf-yang-types@2013-07-15. = So the YANG Library instance data would
> roughly look this = (please correct what I messed up, I am writing this
> by = hand):
>
> <yang-library>
>  =  <module-set>
>    =  <name>m</name>
>    =  <module>
>      =  <name>ietf-netconf-acm</name>
>    =    <revision>2018-02-14</revision>
>  =     =  <namespace>uri1</namespace>
>    =  </module>
>    =  <import-only-module>
>      =  <name>ietf-yang-types</name>
>    =    <namespace>uri2</namespace>
>  =      <revision/>
>    =  </import-only-module>
>  =  </module-set>
>  =  <schema>
>    =  <name>s</name>
>    =  <module-set>m</module-set>
>  =  </schema>
>  =  <datastore>
>    =  <name>running</name>
>    =  <schema>s</schema>
>  =  </datastore>
> </yang-library>
>
> = Yes, this is a bit longer, but it also conveys more information = (note
> that your datastore leaf in the header would likely not be = needed
> anymore).
>
> I am concerned that we start = creating another format to define schemas
> that is very limited = and people later come with extension proposals to
> address some = of the limits and at the end we have multiple formats to
> = maintain and deal with. So the question is whether people think = this
> is worth it. (Note that the felt overhead goes down with = every
> additional module used by your instance file, so the = example above is
> really the most extreme case. And if you have = many modules defining
> NACM rules, then you put the above into a = separate file and use the
> URI to point to the schema, = no?
>
> /js
>
> On Thu, Jul 08, 2021 at = 09:27:52AM +0000, Bal=C3=A1zs Lengyel wrote:
> > Hello = Jurgen,
> > Inline:
> > This complex form of inline = was requested and not objected earlier by
> other
> > = reviewers.
> > Based on Rob's and others' proposal inline will = be simplified to use only
> > ietf-yang-library@2019-01-04 as = you suggest.
> >
> > Simplified inline:
> > = In Ericsson we already use simplified inline a lot, it is the most = common
> > format.
> > If you are providing data only = for one or a few YANG modules and don't
> have,
> = >
> > don't care about features/deviations it is the = easiest, shortest method to
> > use.
> >  Our = most common use-case is to provide preconfigured access control
> = rules
> > for new nodes.
> > When a YANG modeler = designs a new module, he immediately provides a
> set of
> = > NACM rules
> > for the readOnly and the SystemAdmin = roles/groups.
> > In this case you only need to specify = "ietf-neconf-acm@2012-02-22" No
> > deviations, no = features to indicate.
> > Regards Balazs
> >
> = > Regards Balazs
> >
> > -----Original = Message-----
> > From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> = > Sent: 2021. j=C3=BAlius 7., szerda 21:26
> > To: Andy = Bierman <andy@yumaworks.com>
> > Cc: = Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>; Rob Wilton = (rwilton)
> > <rwilton@cisco.com>; netmod@ietf.org; = Benoit Claise
> > <benoit.claise@huawei.com>
> > Subject: = Re: AD review of draft-ietf-netmod-yang-instance-file-format
> = >
> > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman = wrote:
> > >
> > > > Inline method is needed, = if you want to indicate that the file was
> > > > = generated by someone who uses some YANG modules with deviations
> = and
> > > > some features are not-supported. There is no = way to indicate
> > > > feature-support and deviations = with the simplified-inline method.
> > >
> > > = The Inline anydata solution is very heavyweight.
> > > = Before the YANG library there was a simple URI that is easier to = use
> > > and takes up much less storage.
> > = >
> >
> > The inline content schema is super = generic since it supports an open ended
> > set of schema = defining modules. While you can use it with say
> > = ietf-yang-library@2019-01-04, you can use anything else as well. In = other
> > words, two implementations supporting inline content = schema may not
> > interoperate. I do not think there is a = schema format that is mandatory to
> > implement for inline = content schema.
> >
> > So here is my assessment of = what we have in terms of interoperability:
> >
> > - = Simplified-Inline comes with notable restrictions, interoperable
> = > - Inline is an open ended content schema, not necessarily = interoperable
> > - URI method pushes the problem to another = instance file, interoperable
> > - External is by desing not = interoperable
> >
> > On the server side, we have YANG = Library. Perhaps RFC 8525 has some
> > complexity that is = useful for supporting large servers with multiple
> > = datastores and not needed for small instance files (I understand that = an
> > instance file is always tied to a single = datastore?).
> >
> > To me, it feels that reusing RFC = 8525 design is actually a good thing. Being
> > able to dump a = live server datastore into an instance file seems like a very
> = > valid use case to me and ideally this is possible without having to = rewrite
> > the schema part. Well, you could go and trim unused = datastore schemas
> and
> > from there unused module sets = etc but that can all be done by an external
> > tool trimming = the schema part, i.e., it does not need to be done by a tool
> = > that just dumps a server datastore.
> >
> > What = is the actual value of simplified inline? How much do you really = save
> > compared to the simplest equivalent RFC 8525 = representation? And does
> that
> > saving justify to = start engineering another schema specification format?
> = >
> > I guess my choice would have been to just have
> = >
> >        +-- content-schema
> = >        |  +-- = (content-schema-spec)?
> >        |  =    +--: (yang-library)
> >        = |     +--: (uri)
> >
> > but others = obviously want much more choice (but lets note that everything
> = > sits in a choice, so everything is extensible in case other = schema
> > definition formats are out there).
> = >
> > /js
> >
> > --
> > Juergen = Schoenwaelder           Jacobs University = Bremen gGmbH
> > Phone: +49 421 200 3587      =    Campus Ring 1 | 28759 Bremen | Germany
> > = Fax:   +49 421 200 3103
> > <https://protect2.fireeye.com/v1/url?k=3Dfe85c8e6-a11ef1= cd-fe85887d-
> 866038973a
> > = 15-19e5dad375af0063&q=3D1&e=3D3637406d-f774-4073-80ee-
> = a7431111e9bc&u=3Dhttps%3A%2F
> > %2Fwww.jacobs-university.de%2F>
>
> =
>
> --
> Juergen Schoenwaelder      =      Jacobs University Bremen gGmbH
> Phone: +49 = 421 200 3587         Campus Ring 1 | 28759 = Bremen | Germany
> Fax:   +49 421 200 3103    =      <https://www.jacobs-university.de/>

------=_NextPart_001_04C3_01D774A6.3A539BB0-- ------=_NextPart_000_04C2_01D774A6.3A539BB0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDcwOTA3Mzg1MlowIwYJKoZIhvcNAQkEMRYEFDEcCHLfFKiG hJBU4a6LqrbUF/o+MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAGPZ sp1eY+85V84gnGbzfzIPzpJQ36QKw3kNj+FPwLs79G12JthFCUkHEZY8YimyfocuW5b9Gt+ixtBx HihjuQgbZU+/W488QeIQenXrHuOGXdjjPU89itHcoGG7s6quVfjYvAgGxFpZB8uL0n5KFp/Lr8nW wsdmgPOJ/wFdGie7UNV4ny4bnRFw/crqdM1+Jnm1wZqOEmGmPlznpa7RgXTj3kBGkQF//r5+fZLi PQiJyecUVr+6gw+orT4XcIPQaNzOVP0bsH4rYKZ1LCON3trO6Auh+rE9uEeo+4pdX55LCEkoMKft GNof3FdtmdY/PedzZbGO1Cm+lLuZsNWpyMAAAAAAAAA= ------=_NextPart_000_04C2_01D774A6.3A539BB0-- From nobody Fri Jul 9 01:57:46 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBF33A18FE for ; Fri, 9 Jul 2021 01:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpyZvXQ-gcdT for ; Fri, 9 Jul 2021 01:57:39 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2096.outbound.protection.outlook.com [40.107.22.96]) (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 31A243A18FD for ; Fri, 9 Jul 2021 01:57:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hK2BE3XXdk3CFwDRqYWHJZswudkhZyc8CRmlynl73+LExkBHVwcNOcT3U3hVKaZbhJZFMH5qVF5V4xfkxB2cN/5k1392AOzAS/lfjjtgD0PTAQb31ZAuo6Igca5r4+yDsbelFJ5UAM1l+YzpJdMbVhfrLRIoXTV91C6RDpUJIFy3raAHSmAakETz6paKjiSMpgFrRhdyQL3zQchmI6yF0nxze/6PSaF2LWE9AFv6NMf5NReiJVgnnaDMRTnpPppHTa3qGB1q1FQH95WTJIIChBKZFD1M3ooUGAOgrX/r5GynVZsoijgJ1i6bN4lbw0nbvgReUiYHGVgthn62logE5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oiRHcuVcwKq/dXB6RjW1PPmtc4ulXSTwWmgVsi6WDL0=; b=Al2dJXjGL+ZmW9AMP2JvrWk45ibfJ/wBmdg3F/aYYP/gsLNH56vqhZO5+fi55VHr6e+WfZ/lhNiwAjB3KnGIwtZ25D8KVneTZ3tN6Tg6VbiRb/5D+bvZjA2jVpXVrSgfexo4vY6dc+bMKm6IKkOtLsqgNDq3KAlIr9lkUsA22d0exGbZDn98x7BpmYtl2LgayNHLpjvneDQyFMyAA4qB5tW7cxefYzv7J1B0BDZWXHLixNXTd/ohNnnliX8wgo5KffmM5l0Nb5km2N7uZD1pdYdnAuzDP3MZuh84xnCNvi2NnaMxJC+t9/MCtNulECRIDcNDGEsows+Qp9PuwKR7hQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oiRHcuVcwKq/dXB6RjW1PPmtc4ulXSTwWmgVsi6WDL0=; b=KMlCBAq3HnUdwQUlXOGioea7iFWt4SuXeX7n87CoLvwb/Br1i8H+zC1mEMzO8dxR5Mszg4OP2QEImUKC5NRG8cy1jGnGuxNNhHEFlrXK0wKAa+XS19xKqfuCTMgDQVo+iaB8A6cErcW4bnnu8tJU1g1C78HmZMKQ+fba8pc/MtY= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM6PR07MB5317.eurprd07.prod.outlook.com (2603:10a6:20b:6c::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.11; Fri, 9 Jul 2021 08:57:34 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::fc5d:ca7a:e2ea:ca9d]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::fc5d:ca7a:e2ea:ca9d%9]) with mapi id 15.20.4331.014; Fri, 9 Jul 2021 08:57:34 +0000 From: tom petch To: "Rob Wilton (rwilton)" , Juergen Schoenwaelder CC: "netmod@ietf.org" Thread-Topic: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AQHXc9oTAOkC5cYJOkO5v1Ayy8xWb6s40BGAgAAMAgCAAXujfA== Date: Fri, 9 Jul 2021 08:57:34 +0000 Message-ID: References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> , <20210708101326.wuzvtjesghpq5jq7@anna.jacobs.jacobs-university.de> In-Reply-To: <20210708101326.wuzvtjesghpq5jq7@anna.jacobs.jacobs-university.de> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=btconnect.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c68ef787-b8c8-4e78-d74d-08d942b797d6 x-ms-traffictypediagnostic: AM6PR07MB5317: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WIyKQ4h0qj1/GfnJNZsvtnnhxH7F3E6v+Cv4cqpbFV0EkzRkViq3UiyPBcZuLI+t4agiblbQ7Dq0redPOHyiKjVgKtDcpeq4xNaHstvmqJx9+AMzYiRVvoERIiRGm2AMpgnxHQBDxXNuFkyyH5+WKluXb95xexiJPRKSRLIXw5wyNA0VjK+mpOy3BXol5shegvoqVAOEgUeTgp16NDSuyhFjYdtUapaRMTYuoWFJTUAvpz2lCHUiqk4QC2NvkXV3RnKY7S9+resSnmWyKMUBeifcmG8X0wcdUb9m+jrjN56vbQ1gnQ6YJ+lkhSIsqUhF2U1IeLZLOMMyM8s8UA2cUJHEPSIFFAl1RPNeDlsiuBRQLpSJdcJjpWCzB3e0rM3SujIE2rJCtIjxgbudvUYVnXCJnvE6uVCHTJb7+t8CAji43hp9amG4AXiQURWFnadAIa10M5TVuV72X6F1DX4+1KuiT6LgTpw7oS2vVOgVP/VjUTvw5wNQst2/eYtmseNgKjB3Ot3BCTbpL0pIVEeUGWNYWoBfhBI9yoplA8O917B7OJ/0aCP8KZwQNfLcWwTK3vTNERT2HC0+swOxTfHuvuGWUePGO9ET5QkW8lW4tYIEetoIu8fX7Y1w5aquXFc6x586Z324BorxgUryrGnyn8wr104MR17NxhLlM/d1goafZTebYHY6w2YnhOGTk3C9Ha8kReOlGqMIz8hQG78wyoJfehNCrbxxxAQw0quWJtJ+E4IJxQMGFYNk4IE6pr0Ti0FdVgsN9QH1qfHk83tKDA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(346002)(136003)(39860400002)(396003)(91956017)(26005)(52536014)(9686003)(110136005)(186003)(7696005)(5660300002)(66556008)(66946007)(66476007)(66446008)(8676002)(966005)(76116006)(8936002)(55016002)(64756008)(316002)(71200400001)(478600001)(33656002)(86362001)(38100700002)(4326008)(122000001)(6506007)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?zzFhCBjStJxLM1TokxSBSJKb8pF+tlgPMDW4kaAX/3utKFZRP6eA1OKM3W?= =?iso-8859-1?Q?hyLVtAFKBFvXWuU8gZsPvi+krGzKAGxWpXQauAtRvyTQ/xJTd9iFv6C0PT?= =?iso-8859-1?Q?+pMs0osiusEOZp6tPwKTW0Snga6gix0SWttcUq3kFT7OPt0RfrdtYmODwe?= =?iso-8859-1?Q?/fPJ+Ad5U9AI/9PB/VoKDZzK9VthsejeUlgTeHXP3l+QQCRXZXwXYRUlnH?= =?iso-8859-1?Q?XOWbfVxqnPLdlFoDW/moMYUyeytA6+pvdB8OSkyg0EP4RFqB8oML34NOvp?= =?iso-8859-1?Q?rKHyIPErxupjkD37M2x7qN/VunSrBvzifRY+eCUXut5ZF2D72LrjoA5UWe?= =?iso-8859-1?Q?pnCIFRyl0Y4zZaDaVZuQxaxx6Oor2OGyEzbpUJiCJH630/kXZzwuM+jnGi?= =?iso-8859-1?Q?FdTebdbEGdLor0mQ3Ktzr2LGo5OncJX4thC31c26rv9XtmGNr2UwNPwhKR?= =?iso-8859-1?Q?ynjNcssBuUfdTKk7YMGt0D7oan1sjvYyaY8FWmF3klk4eRL3UhmDh47obg?= =?iso-8859-1?Q?4yq5kbVaE/ZyLfckw6iobN206Ugh+YXrzrWZvCz51sO7OufZgW1i71qP4C?= =?iso-8859-1?Q?CM9x1VNTP3YpDPSmVi5AWWxpPJZ4YFTQUt8OlZ7mqRZanzXh2fLciPwJHJ?= =?iso-8859-1?Q?MggWe/wFMA5PHumE40UNUbJvmZubenzjDzFVBuqwnliyHaVnuGSAYu32Og?= =?iso-8859-1?Q?R6vPLdOcf/BuEi/aghFBNLYDVIaOrStqkEIdQ54+kY7v5ujSGkD1PqciY+?= =?iso-8859-1?Q?BrhywWKdPDmpZ+rIiRPwgXqyTh0+CCzYcz1M6gK89JTXDSWhAmjFxywv0n?= =?iso-8859-1?Q?r0lK3rc6g4PlB2r75n0yAwhWDJ6uwVbpmDLShr1PQ6xFDwL3HJXqynWi8N?= =?iso-8859-1?Q?h11KtdVaLv+3LE1govE38omihoxbkwOso32HrJdRtKX4quLVCXqGlyY19A?= =?iso-8859-1?Q?a9gVrTWrCyrIeqtiRyy2bdB//77h5ESYMrsinozZbkIFjJV5l3O52uD0ck?= =?iso-8859-1?Q?NbvgPA/6zSTPteJkGlTSL9J3ee5fUIcT7H5+g55NsmsgVkJvQCWlyc38uC?= =?iso-8859-1?Q?KEyF97zVjeX0hzFCJ7DoLVY7uEsnOCMxxmBvjuruTlaLIrcJlb2OUFlT57?= =?iso-8859-1?Q?B/KLlNqV9Y4n9la+X8dGqxmhAaYhDE8y0EWm/kEkOXuNuYR95l9sCx5ldN?= =?iso-8859-1?Q?uNVtO12OCKBx0vw5Uj6AzaQyyGEC/7sTVxpUcbTcl+IS7vP4tNVU9UeCJh?= =?iso-8859-1?Q?beAzD3kNp5FJDldlfwjsUVVH6pefLKn4NsHCteOWUnZKLhvh8KTtwDD9My?= =?iso-8859-1?Q?yhntSGYQOR8sMqMDv8vMV2H18oBOy35896UzM5hzj4i3sxCL9HXcJ6U/Y/?= =?iso-8859-1?Q?/Sv0LQwfqA?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c68ef787-b8c8-4e78-d74d-08d942b797d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2021 08:57:34.2309 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: r0e/O35Fou9MTEYJnu5Nhjw3xCyy9GoEdbpezQNxzgMkUKTERF8vsQbQAnlhn8UakLHyQl6pvxvC/5rAOw1Nyg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5317 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 08:57:44 -0000 From: netmod on behalf of Juergen Schoenwaelder <= j.schoenwaelder@jacobs-university.de>=0A= Sent: 08 July 2021 11:13=0A= =0A= On Thu, Jul 08, 2021 at 09:30:27AM +0000, Rob Wilton (rwilton) wrote:=0A= > It is perhaps worth noting that the NETCONF copy-config allows for the co= nfiguration to be specified using any URI, but the server capabilities anno= unce which URI schemes are supported.=0A= >=0A= > Hence, I think that it is okay for the YANG model to use URI, but I think= the draft, and data node description should constrain the URI schemes that= allowed (perhaps file:// and https://). This would allow support for futu= re URI schemes to be added in a future revision of the YANG instance data m= odule, if required.=0A= >=0A= =0A= I think it is not "allowed" but "mandatory to implement". We should=0A= allow implementations to support an ftps:// scheme as long as there=0A= is a common baseline.=0A= =0A= =0A= I am confused. Is ftps: intended to be an existing scheme or a hypothetica= l one that may appear in the future. I do not see it in the IANA registry= =0A= https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#uri-schemes-= 1=0A= =0A= sftp: appears as a provisional entry in the IANA registry but AFACT did not= get specified. I recall a debate about ftps: v sftp: I favoured the form= er but lost but then I did not see any further work on either.=0A= =0A= Tom Petch=0A= =0A= /js=0A= =0A= --=0A= Juergen Schoenwaelder Jacobs University Bremen gGmbH=0A= Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany=0A= Fax: +49 421 200 3103 =0A= =0A= _______________________________________________=0A= netmod mailing list=0A= netmod@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netmod=0A= From nobody Fri Jul 9 01:58:22 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FD53A1917 for ; Fri, 9 Jul 2021 01:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9a_J8OVxTrjl for ; Fri, 9 Jul 2021 01:58:15 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80085.outbound.protection.outlook.com [40.107.8.85]) (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 7FDB63A190B for ; Fri, 9 Jul 2021 01:58:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Tm0PvwcxZnzB1y4lkBAFe3vSpKw7x5DdO3JpLqZIJrSPIAV7wWqFeVUCiRqzVKf7u0+9BytPtaFIh8mARKee9QFan2ZljsDK5M3PfPMebRfhJDKtr1zNklw9dmVlrLudeYLYrAsIcFP0ZJjKuR4YFzaiMOyXDJjVlZsuLG0kmKp1E/88EwZDcHcE9UtwrsaQILJNH7QBX6AROpvIhpiGQzg1XSYoaeyECL+JDOYmRKOVUyyy56IoIMqGrQCX9YVFEKRx32Vtpx5P9yAfwKT+K2N82CqFeJFtXpie93oehiDyvEwQdXlh0SE7PjDQFPYMjYPvmGaMukuqljHD2I3lpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G2RB0vFiW20S7gPNocGuiHjZLbwCO3ZefhzXeasjkik=; b=G8CWvQ1FOeMkdc0yfJkZEqZBNkax6vg02GGRrEyhfDtaCSnEJgK5u5XGYp1fSZDxPaDNgyssznHvOnpqNslrFSksDVm6dEmsz1sL+v5/wWNSSFTcO9QrMR5v072C7sgKTgw+zSOka2WQzN+of/suRjDgFbx7gV+XqWYnhOGRiiy1+3Sgf3F05nq+FTRF0ZKEOT131c/w+pe/FuOYjJi16O3UMzKbiN9BpstWI4uCrQ7jwokThzeD+kAP0GYzuH2RqJptKiCFgeT3iuL3wN/8nX/mJvEgZgZAvr8zmdLJ8e0pnmQJipQO1Njf/OEsRYIbAMh6hYY/qxo9R5WfrAoP4g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G2RB0vFiW20S7gPNocGuiHjZLbwCO3ZefhzXeasjkik=; b=AAZYYhkQyy2umephbcJhEwE/DXxfqrn8n99tyT7Pn3/d89i4RJOTjoriwY10uy2ICPekc+r8GzwkXVmK9kC2AWIm2G/1ImiC4wcePqlXRO2bZ/f4m8LyT9OvbCVXP6J5Sek344N27XgOs12RLmYFLlSVRt2IsxDp3cBZ4rSVBjs= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8231.eurprd07.prod.outlook.com (2603:10a6:20b:326::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.17; Fri, 9 Jul 2021 08:58:11 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4308.018; Fri, 9 Jul 2021 08:58:11 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , Andy Bierman , "Rob Wilton (rwilton)" CC: "netmod@ietf.org" Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAPXLWAAAIT0wAAAIMhAAAAy2eAAAJlLwAAGf35QAAVpNcAAAKQ2AAAHRePIAACr5QAAAAUxvAADSn9gAAel4VgAALhU4A= Date: Fri, 9 Jul 2021 08:58:11 +0000 Message-ID: References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> <20210707192534.4emim5a36zyqrktc@anna.jacobs.jacobs-university.de> <20210708103528.6ezr4v5qeltinvmv@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dc551b63-aeb8-4808-a342-08d942b7addf x-ms-traffictypediagnostic: AM8PR07MB8231: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 938+2XK40eXBTWr1M/WwH7aR5+NHNXnW7wWhJa0bd7YUCRwL1V+KxJu/BhyePaKOWH1xQ3SGR99QJWjSBf70C9OkLffMu9dOo/qe/F64N55B3dNFXupOn6eu9GL+QPXkJrcqVmlXKKsURyzimD2KCU2PqYKWcF9eP/e5pOTI01btp+SZrDs7r5dAtG9VcFZMM4NpNX/JvYKaLcLoyTIWCNCJTGi7yEjHgUavLQECOwAvw+7VldD+5BtgB81aSnGMwuCnRTC4cfYOYgWTkNSr7LUvj+wlsr73bcPKcyoqgTPBmpZq2GpvsVUUKDpj1NQ61zANeN2wdJBuJ99cD4C0OMqUspoYcCeQ5WQ1wZQqA2yVOZQPVzndq35SPhS73oupxfg3RYu87HZNqBnU20lIz1lTrIp7icNoHMiFLKiRxjE+pzTj9W38N3jjgKQk7yk4XHNpLpJvY6Mulnw1KQEsTyAxHrulidZr6JRYkAjwT8EuU3fXURd6eYcdeP60BQdYPgRoi9oaUfF4I6KksTq/kQpTqsvQYY/EvdAOFbnFKZZyfdBB86b7mUx94FTaGfTz0ijXWf6Zobg26r6Xj7KJ/x7YK/3SJxHCgfQVPGlXFKRpVojL8MS69N5chVnx3UZpS1yvsIsIJ2cy+WwVXI62BIHqny5hpViiaND2x3aoYBuvPVKsf2S0sz+aNvr8HwN8XCasrvcwe8N945qCmidNNiQWj2/KSACeMj0htlSpRokc7uTfEy8PAW70nx9GhOGTykX65Xo0hFDYYNFMlGyaIw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(346002)(39860400002)(396003)(136003)(366004)(5660300002)(110136005)(966005)(478600001)(9326002)(6506007)(66946007)(4326008)(7696005)(122000001)(66616009)(76116006)(186003)(64756008)(53546011)(9686003)(85202003)(99936003)(66556008)(83380400001)(85182001)(316002)(86362001)(8936002)(52536014)(66476007)(66446008)(38100700002)(166002)(26005)(2940100002)(55016002)(71200400001)(2906002)(30864003)(8676002)(66574015)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eWUzOVBTWjlSMlFmc2hOazE3K28zTzNRVHdtM3RyNWp6K2ozOE81bW9nSlE4?= =?utf-8?B?ZDI2ZjhaNkZXOHNQTXV1WWRIeWRjai9rbkszaUY1OCtNcjdqQmhDMVd2NjZn?= =?utf-8?B?eUpOM1BzTy8rT0ZBcDNnYU40encvNTRkRGhHdFkxMmEyS3FmMGFMeHY0U0hj?= =?utf-8?B?MHJVUTBTWlFkYStVUlhhSVcrekQrb2JSY1ArMThVK3NZZk5YT1F0Vk5vSU11?= =?utf-8?B?M1IwenRDRThkUjVJdWI5eXVYV3FsNWJoVkhKODV1K2k2QWZ0Z3hESnFrODIy?= =?utf-8?B?cUJjMlNJeXVEZ2h5ZHgzZnE0WkxCU2tLT0RUaUY0UXliUkQ5V25aUmNMMmVm?= =?utf-8?B?NXVUMVovZE5pWVNZbzFYbUJGTEVsYVZtT3VPejlpTFk0TjJ5OTZGejlaeWgr?= =?utf-8?B?K3BLMkhBZkkrN0lXL2VQTDNWNlNTMnZoY0xjZVl5cWp0SjJwT3lWZFZyUHNL?= =?utf-8?B?em15QWJLWEZ5TGF3MmRWNktZMnQvdVFOQ2JYS1BEcmtvSyszUVo0dGZDazZz?= =?utf-8?B?UlZFRkxObnRrczFJeGdqMHZBQmh1cFFmSDVFbG1YSTBTQm1BNUhMajdaSE5y?= =?utf-8?B?dVV2N005VFFXOGM4L0RCY2pwSWJGeFFqTFBLSDNaQVV5N0hIQjBXd3pRdVpq?= =?utf-8?B?bTFIMDZDUm5vdUFzaTdYRXFjd2xtcnhTVWdxcDBQTmViMmt5d3dDeUxzN0s5?= =?utf-8?B?cHFobXcrWlFjQkYrQmZLODVWeHptckJJSlkyeXF6NWplaWhrYk1tbVdMZjE0?= =?utf-8?B?cGFKV29MWE9jcFlPaUdxUnZaRTlmNlZvcTlmNlhBRWZNWjlvRzZJZUdYQ0Zm?= =?utf-8?B?czFhMkdEaVdvL29ubEJJam5qSzVGNEJERXVtRUVkWXhoR0FoVm54a1Y4NjBn?= =?utf-8?B?S0c2bWI3TGdLL3hHaFBqTXluSFByL0pnMVBCbVZlZXBpeWF2a3g3UDdjWjBM?= =?utf-8?B?M3cwY0hDcVFDOW9tbkhrV05xR1NxRVJCdUJRUmFxamo5MkdkTkhUQ3g2R0dE?= =?utf-8?B?UEltclU2Mmt0V1dkczdZUUF1VHZnMVJCNEN6R3V0aG1zV0NWVHoxQVBwcEwv?= =?utf-8?B?ellaYVY3UnBzT1F4dEM1WTgxdTBialp1d3U2a2tMaFpFQ1NPaXVVaVRPSklJ?= =?utf-8?B?REliMlB6SFQ1VDBSdFhSWHJnVXZnbkFsUzg1dW9tR2xBS1RpSVFJdUk1VlVr?= =?utf-8?B?QVhhbGxiU2Y5VnFkcmpIV0tQZGpia1ZzemRsQllBSWpxejNVSFR0RlFZRHNH?= =?utf-8?B?WXFubzdEdnd4SlpMSG8xZmk5eEE5VjBsVmRPbXkvUW5qaytUeURCZ3N4Qnpx?= =?utf-8?B?YVZDcVdxMS9RUXR4QnhEUitpWE5BNEpLbWZpQWxGM0lGU0lzTzBvODl3RjIr?= =?utf-8?B?Y3owTjBFeVhmU0Q2YjREZ3hrREZnZ2dremxzSzVZK1RJRlc5dUJkYkp6cmV1?= =?utf-8?B?bGpQaWhiTHlNWjc5YmU1c08rbmJtbkFFU1p4dkY2Y0lDaklDa1M0U3I5T1RH?= =?utf-8?B?UExZSVNqRVpsWDc5SlZVanNTWVJYb2g3d21tNXBYRXlOV1RwTmVsRndpNjQ4?= =?utf-8?B?VmZKRVRnalZMTzhZdXA3UUsyMkdOS2dkbmpDL250UDhSV2k4Ui85NnM4Q3Bp?= =?utf-8?B?MzZaNVE2dkxnWHp4ZXNZMFBwNzhOVzFjb2hYSHR0STY1Nlh4SkZaWWVBZjZk?= =?utf-8?B?WXlkRlE3SXR3WlBXV2NOcGpGc2RkTHRmQXExTmdZU3gxd2RNSnhnNjhXUFlN?= =?utf-8?Q?pZSDp9baiIen/hnwbJcbo3NATgYX1Ayh8uCZ+kJ?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_04DC_01D774B1.4DFB7EC0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dc551b63-aeb8-4808-a342-08d942b7addf X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2021 08:58:11.2203 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: U8gxNVshw2vkHH5cgc+NiUlllVBRfk6FHdDGnjkkcULLGBgGXlNI/qASwX1T9Fl8L7vGXLySfjCEzZHGG+JuzlFrX6eiDCrqOvp8ycy0oH4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8231 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 08:58:21 -0000 ------=_NextPart_000_04DC_01D774B1.4DFB7EC0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_04DD_01D774B1.4DFB7EC0" ------=_NextPart_001_04DD_01D774B1.4DFB7EC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Andy, In the name of simplification, I will add the following to the URI = method: =20 Referenced files using "inline" or the "simplified-inline" methods MUST = be supported.=20 Referenced files using the "URI method" MAY be supported. =20 This means the tool does not need to be prepared for chains or loops. I = think chains and loops are something we should discourage.=20 (Referenced files using the =E2=80=9Cexternal Method=E2=80=9D make no = sense anyway. If I don=E2=80=99t tell you the schema of the referenced = file, there is no sense in referencing them) Regards Balazs =20 From: netmod On Behalf Of Bal=C3=A1zs Lengyel Sent: 2021. j=C3=BAlius 9., p=C3=A9ntek 9:39 To: Andy Bierman ; Rob Wilton (rwilton) = Cc: netmod@ietf.org Subject: Re: [netmod] AD review of = draft-ietf-netmod-yang-instance-file-format =20 Hello Andy, See below. Balazs =20 From: Andy Bierman >=20 Sent: 2021. j=C3=BAlius 8., cs=C3=BCt=C3=B6rt=C3=B6k 18:55 To: Rob Wilton (rwilton) > Cc: Juergen Schoenwaelder >; Bal=C3=A1zs Lengyel = >; = netmod@ietf.org ; Benoit Claise = > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format =20 =20 =20 On Thu, Jul 8, 2021 at 3:58 AM Rob Wilton (rwilton) > wrote: Hi Juergen, I believe that having the simple form is worth the extra complexity. =20 =20 I believe it is the only option that does not have too much complexity. =20 The inline form seems to imply that the NMDA version of the YANG library = is used. Only 1 module set is ever shown, but of course the actual schema allows for much more complex instances than that, which the reader must = support. =20 Does this mean NMDA must be used or else a YANG data file cannot be = saved? So the reader is expected to look for the 'current' /yang-library and = then the 'deprecated' /modules-state? And then fish the anydata for whatever non-standard solution is in use? The procedures should be explained better so there is a better chance of = interoperability. BALAZS: No NMDA is not required. If it would there would be a clear = statement about it. Even in section 2.2.1. Documentation of server = capabilities the new (NMDA compatible) yang-library is used, but the = simple (non- NMDA) modules-state branch. =20 For the URI method, the reader must check for a broken chain of = reference and loops. The draft should say the uri references across N files MUST NOT create a = loop (similar language is in YANG wrt import loops). BALAZS: Someone (don.t know who) asked for longer reference chains. = However, I don=E2=80=99t see them as a common use-case. IMHO the most = common use-case for the URI method will be, when the consumer knows the = content-schema apriori, it only needs a reference to check that the = schema is what it expected. =20 For conformance purposes, I think YANG features are appropriate. IMO simplified-inline is mandatory-to-implement but the rest should=20 be optional. This way a tool can claim conformance and also the standard will provide a minimum level of interoperability. BALAZS: There are very different views about the preferred/required = methods. Also the needs of different use-cases are different. = That=E2=80=99s why we need all 3. =20 =20 Andy =20 =20 =20 =20 I think that you are right to be concerned that it should not expand = into a separate parallel format. Overtime, I would like the simple form = to be able to use revision labels instead of revision dates, but beyond = this I think that it should just be a flat list of modules that defines = the schema. If a subset of features, or datastores, or import-only = modules are needed then the YANG library version (or URIs) can and = should be used. =20 This can be done with augment if and when the versioning draft reaches = RFC =20 Another example of where I expect it to be useful is in YANG packages. = Looking at the examples at the end of = https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, = then some of those files (which currently aren't defining any schema, = but should) would almost double in size if they represented the schema = inline using YANG library, which I think would make the files harder for = humans to read/parse. Using URIs could help mitigate this, but then we = would need to find a place to publish the file containing the YANG = package schema (presumably somewhere in IANA), and it not obvious to me = that adding the dependency on the URL is really as helpful. Regards, Rob > -----Original Message----- > From: Juergen Schoenwaelder > > Sent: 08 July 2021 11:35 > To: Bal=C3=A1zs Lengyel > > Cc: Andy Bierman >; = Rob Wilton (rwilton) > >; netmod@ietf.org = ; Benoit Claise > > > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format >=20 > The question I asked is "how much simpler is it and does that saving > justify the introduction of a new rather limited format (that may risk > to grow over time and become a second citizen)". >=20 > So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports > from ietf-yang-types (at the time of publication that resolves to > ietf-yang-types@2013-07-15. So the YANG Library instance data would > roughly look this (please correct what I messed up, I am writing this > by hand): >=20 > > > m > > ietf-netconf-acm > 2018-02-14 > uri1 > > > ietf-yang-types > uri2 > > > > > s > m > > > running > s > > >=20 > Yes, this is a bit longer, but it also conveys more information (note > that your datastore leaf in the header would likely not be needed > anymore). >=20 > I am concerned that we start creating another format to define schemas > that is very limited and people later come with extension proposals to > address some of the limits and at the end we have multiple formats to > maintain and deal with. So the question is whether people think this > is worth it. (Note that the felt overhead goes down with every > additional module used by your instance file, so the example above is > really the most extreme case. And if you have many modules defining > NACM rules, then you put the above into a separate file and use the > URI to point to the schema, no? >=20 > /js >=20 > On Thu, Jul 08, 2021 at 09:27:52AM +0000, Bal=C3=A1zs Lengyel wrote: > > Hello Jurgen, > > Inline: > > This complex form of inline was requested and not objected earlier = by > other > > reviewers. > > Based on Rob's and others' proposal inline will be simplified to use = only > > ietf-yang-library@2019-01-04 as you suggest. > > > > Simplified inline: > > In Ericsson we already use simplified inline a lot, it is the most = common > > format. > > If you are providing data only for one or a few YANG modules and = don't > have, > > > > don't care about features/deviations it is the easiest, shortest = method to > > use. > > Our most common use-case is to provide preconfigured access control > rules > > for new nodes. > > When a YANG modeler designs a new module, he immediately provides a > set of > > NACM rules > > for the readOnly and the SystemAdmin roles/groups. > > In this case you only need to specify "ietf-neconf-acm@2012-02-22" = No > > deviations, no features to indicate. > > Regards Balazs > > > > Regards Balazs > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > > Sent: 2021. j=C3=BAlius 7., szerda 21:26 > > To: Andy Bierman > > > Cc: Bal=C3=A1zs Lengyel >; Rob Wilton (rwilton) > > >; netmod@ietf.org = ; Benoit Claise > > > > > Subject: Re: AD review of = draft-ietf-netmod-yang-instance-file-format > > > > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote: > > > > > > > Inline method is needed, if you want to indicate that the file = was > > > > generated by someone who uses some YANG modules with deviations > and > > > > some features are not-supported. There is no way to indicate > > > > feature-support and deviations with the simplified-inline = method. > > > > > > The Inline anydata solution is very heavyweight. > > > Before the YANG library there was a simple URI that is easier to = use > > > and takes up much less storage. > > > > > > > The inline content schema is super generic since it supports an open = ended > > set of schema defining modules. While you can use it with say > > ietf-yang-library@2019-01-04, you can use anything else as well. In = other > > words, two implementations supporting inline content schema may not > > interoperate. I do not think there is a schema format that is = mandatory to > > implement for inline content schema. > > > > So here is my assessment of what we have in terms of = interoperability: > > > > - Simplified-Inline comes with notable restrictions, interoperable > > - Inline is an open ended content schema, not necessarily = interoperable > > - URI method pushes the problem to another instance file, = interoperable > > - External is by desing not interoperable > > > > On the server side, we have YANG Library. Perhaps RFC 8525 has some > > complexity that is useful for supporting large servers with multiple > > datastores and not needed for small instance files (I understand = that an > > instance file is always tied to a single datastore?). > > > > To me, it feels that reusing RFC 8525 design is actually a good = thing. Being > > able to dump a live server datastore into an instance file seems = like a very > > valid use case to me and ideally this is possible without having to = rewrite > > the schema part. Well, you could go and trim unused datastore = schemas > and > > from there unused module sets etc but that can all be done by an = external > > tool trimming the schema part, i.e., it does not need to be done by = a tool > > that just dumps a server datastore. > > > > What is the actual value of simplified inline? How much do you = really save > > compared to the simplest equivalent RFC 8525 representation? And = does > that > > saving justify to start engineering another schema specification = format? > > > > I guess my choice would have been to just have > > > > +-- content-schema > > | +-- (content-schema-spec)? > > | +--: (yang-library) > > | +--: (uri) > > > > but others obviously want much more choice (but lets note that = everything > > sits in a choice, so everything is extensible in case other schema > > definition formats are out there). > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > > Fax: +49 421 200 3103 > > 866038973a > > 15-19e5dad375af0063&q=3D1&e=3D3637406d-f774-4073-80ee- > a7431111e9bc&u=3Dhttps%3A%2F > > %2Fwww.jacobs-university.de = %2F> >=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 > ------=_NextPart_001_04DD_01D774B1.4DFB7EC0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello Andy,

In the name of simplification, I will add the = following to the URI method:

 

Referenced = files using =C2=A0"inline" or the = "simplified-inline" methods MUST be supported. =

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Referenced files using the "URI method" MAY be = supported.

 

This means the tool does not need to be prepared for = chains or loops. I think chains and loops are something we should = discourage.

(Referenced files using = the =E2=80=9Cexternal Method=E2=80=9D make no sense anyway. If I = don=E2=80=99t tell you the schema of the referenced file, there is no = sense in referencing them)

Regards = Balazs

 

From: netmod = <netmod-bounces@ietf.org> On Behalf Of Bal=C3=A1zs = Lengyel
Sent: 2021. j=C3=BAlius 9., p=C3=A9ntek = 9:39
To: Andy Bierman <andy@yumaworks.com>; Rob Wilton = (rwilton) <rwilton@cisco.com>
Cc: = netmod@ietf.org
Subject: Re: [netmod] AD review of = draft-ietf-netmod-yang-instance-file-format

 

Hello = Andy,

See below.

Balazs

 

From: Andy Bierman <andy@yumaworks.com> =
Sent: 2021. j=C3=BAlius 8., cs=C3=BCt=C3=B6rt=C3=B6k = 18:55
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc:= Juergen Schoenwaelder <j.schoenwaelder@jaco= bs-university.de>; Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>; netmod@ietf.org; Benoit = Claise <benoit.claise@huawei.com>=
Subject: Re: AD review of = draft-ietf-netmod-yang-instance-file-format

 

 

 

On = Thu, Jul 8, 2021 at 3:58 AM Rob Wilton (rwilton) <rwilton@cisco.com> = wrote:

Hi = Juergen,

I believe that having the simple form is worth the extra = complexity.

 

 

I = believe it is the only option that does not have too much = complexity.

 

The inline form seems to imply that the NMDA version = of the YANG library is used.

Only 1 module set is ever shown, but of course the = actual schema allows

for = much more complex instances than that, which the reader must = support.

 

Does this mean NMDA must be used or else a YANG data = file cannot be saved?

So = the reader is expected to look for the 'current' /yang-library and then = the 'deprecated' /modules-state?

And then fish the anydata for whatever non-standard = solution is in use?

The = procedures should be explained better so there is a better chance of = interoperability.

BALAZS: No NMDA is = not required. If it would there would be a clear statement about it. = Even in section 2.2.1.  Documentation of server capabilities the = new (NMDA compatible) yang-library is used, but the simple (non- NMDA) = modules-state branch.

 

For the URI method, the reader must check for a broken = chain of reference and loops.

The draft should say the uri references across N files = MUST NOT create a loop

(similar language is in YANG wrt import = loops).

BALAZS: Someone (don.t know = who) asked for longer reference chains. However, I don=E2=80=99t see = them as a common use-case. IMHO the most common use-case for the URI = method will be, when the consumer knows the content-schema apriori, it = only needs a reference to check that the schema is what it = expected.

 

For conformance purposes, I think YANG features are = appropriate.

IMO = simplified-inline is mandatory-to-implement but the rest = should 

be optional. = This way a tool can claim conformance and also the = standard

will provide a = minimum level of interoperability.

BALAZS: There are very different views about the = preferred/required methods. Also the needs of different use-cases are = different. That=E2=80=99s why we need all 3.

 

 

Andy

 

 

 

 

I think that you = are right to be concerned that it should not expand into a separate = parallel format.  Overtime, I would like the simple form to be able = to use revision labels instead of revision dates, but beyond this I = think that it should just be a flat list of modules that defines the = schema.  If a subset of features, or datastores, or import-only = modules are needed then the YANG library version (or URIs) can and = should be used.

 

This can be done with augment if and when the = versioning draft reaches RFC

 

Another example of where I expect it to be = useful is in YANG packages.  Looking at the examples at the end of = https://datatracker.ietf.org/doc/html/draft-ietf-netmod= -yang-packages, then some of those files (which currently aren't = defining any schema, but should) would almost double in size if they = represented the schema inline using YANG library, which I think would = make the files harder for humans to read/parse.  Using URIs could = help mitigate this, but then we would need to find a place to publish = the file containing the YANG package schema (presumably somewhere in = IANA), and it not obvious to me that adding the dependency on the URL is = really as helpful.

Regards,
Rob


> -----Original = Message-----
> From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> = Sent: 08 July 2021 11:35
> To: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>
> Cc: Andy = Bierman <andy@yumaworks.com>; Rob Wilton = (rwilton)
> <rwilton@cisco.com>; netmod@ietf.org; = Benoit Claise
> <benoit.claise@huawei.com>
> Subject: Re: = AD review of draft-ietf-netmod-yang-instance-file-format
> =
> The question I asked is "how much simpler is it and does = that saving
> justify the introduction of a new rather limited = format (that may risk
> to grow over time and become a second = citizen)".
>
> So lets take your NACM example. = ietf-netconf-acm@2018-02-14 imports
> from ietf-yang-types (at the = time of publication that resolves to
> ietf-yang-types@2013-07-15. = So the YANG Library instance data would
> roughly look this = (please correct what I messed up, I am writing this
> by = hand):
>
> <yang-library>
>  =  <module-set>
>    =  <name>m</name>
>    =  <module>
>      =  <name>ietf-netconf-acm</name>
>    =    <revision>2018-02-14</revision>
>  =     =  <namespace>uri1</namespace>
>    =  </module>
>    =  <import-only-module>
>      =  <name>ietf-yang-types</name>
>    =    <namespace>uri2</namespace>
>  =      <revision/>
>    =  </import-only-module>
>  =  </module-set>
>  =  <schema>
>    =  <name>s</name>
>    =  <module-set>m</module-set>
>  =  </schema>
>  =  <datastore>
>    =  <name>running</name>
>    =  <schema>s</schema>
>  =  </datastore>
> </yang-library>
>
> = Yes, this is a bit longer, but it also conveys more information = (note
> that your datastore leaf in the header would likely not be = needed
> anymore).
>
> I am concerned that we start = creating another format to define schemas
> that is very limited = and people later come with extension proposals to
> address some = of the limits and at the end we have multiple formats to
> = maintain and deal with. So the question is whether people think = this
> is worth it. (Note that the felt overhead goes down with = every
> additional module used by your instance file, so the = example above is
> really the most extreme case. And if you have = many modules defining
> NACM rules, then you put the above into a = separate file and use the
> URI to point to the schema, = no?
>
> /js
>
> On Thu, Jul 08, 2021 at = 09:27:52AM +0000, Bal=C3=A1zs Lengyel wrote:
> > Hello = Jurgen,
> > Inline:
> > This complex form of inline = was requested and not objected earlier by
> other
> > = reviewers.
> > Based on Rob's and others' proposal inline will = be simplified to use only
> > ietf-yang-library@2019-01-04 as = you suggest.
> >
> > Simplified inline:
> > = In Ericsson we already use simplified inline a lot, it is the most = common
> > format.
> > If you are providing data only = for one or a few YANG modules and don't
> have,
> = >
> > don't care about features/deviations it is the = easiest, shortest method to
> > use.
> >  Our = most common use-case is to provide preconfigured access control
> = rules
> > for new nodes.
> > When a YANG modeler = designs a new module, he immediately provides a
> set of
> = > NACM rules
> > for the readOnly and the SystemAdmin = roles/groups.
> > In this case you only need to specify = "ietf-neconf-acm@2012-02-22" No
> > deviations, no = features to indicate.
> > Regards Balazs
> >
> = > Regards Balazs
> >
> > -----Original = Message-----
> > From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
> = > Sent: 2021. j=C3=BAlius 7., szerda 21:26
> > To: Andy = Bierman <andy@yumaworks.com>
> > Cc: = Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>; Rob Wilton = (rwilton)
> > <rwilton@cisco.com>; netmod@ietf.org; = Benoit Claise
> > <benoit.claise@huawei.com>
> > Subject: = Re: AD review of draft-ietf-netmod-yang-instance-file-format
> = >
> > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman = wrote:
> > >
> > > > Inline method is needed, = if you want to indicate that the file was
> > > > = generated by someone who uses some YANG modules with deviations
> = and
> > > > some features are not-supported. There is no = way to indicate
> > > > feature-support and deviations = with the simplified-inline method.
> > >
> > > = The Inline anydata solution is very heavyweight.
> > > = Before the YANG library there was a simple URI that is easier to = use
> > > and takes up much less storage.
> > = >
> >
> > The inline content schema is super = generic since it supports an open ended
> > set of schema = defining modules. While you can use it with say
> > = ietf-yang-library@2019-01-04, you can use anything else as well. In = other
> > words, two implementations supporting inline content = schema may not
> > interoperate. I do not think there is a = schema format that is mandatory to
> > implement for inline = content schema.
> >
> > So here is my assessment of = what we have in terms of interoperability:
> >
> > - = Simplified-Inline comes with notable restrictions, interoperable
> = > - Inline is an open ended content schema, not necessarily = interoperable
> > - URI method pushes the problem to another = instance file, interoperable
> > - External is by desing not = interoperable
> >
> > On the server side, we have YANG = Library. Perhaps RFC 8525 has some
> > complexity that is = useful for supporting large servers with multiple
> > = datastores and not needed for small instance files (I understand that = an
> > instance file is always tied to a single = datastore?).
> >
> > To me, it feels that reusing RFC = 8525 design is actually a good thing. Being
> > able to dump a = live server datastore into an instance file seems like a very
> = > valid use case to me and ideally this is possible without having to = rewrite
> > the schema part. Well, you could go and trim unused = datastore schemas
> and
> > from there unused module sets = etc but that can all be done by an external
> > tool trimming = the schema part, i.e., it does not need to be done by a tool
> = > that just dumps a server datastore.
> >
> > What = is the actual value of simplified inline? How much do you really = save
> > compared to the simplest equivalent RFC 8525 = representation? And does
> that
> > saving justify to = start engineering another schema specification format?
> = >
> > I guess my choice would have been to just have
> = >
> >        +-- content-schema
> = >        |  +-- = (content-schema-spec)?
> >        |  =    +--: (yang-library)
> >        = |     +--: (uri)
> >
> > but others = obviously want much more choice (but lets note that everything
> = > sits in a choice, so everything is extensible in case other = schema
> > definition formats are out there).
> = >
> > /js
> >
> > --
> > Juergen = Schoenwaelder           Jacobs University = Bremen gGmbH
> > Phone: +49 421 200 3587      =    Campus Ring 1 | 28759 Bremen | Germany
> > = Fax:   +49 421 200 3103
> > <https://protect2.fireeye.com/v1/url?k=3Dfe85c8e6-a11ef1= cd-fe85887d-
> 866038973a
> > = 15-19e5dad375af0063&q=3D1&e=3D3637406d-f774-4073-80ee-
> = a7431111e9bc&u=3Dhttps%3A%2F
> > %2Fwww.jacobs-university.de%2F>
>
> =
>
> --
> Juergen Schoenwaelder      =      Jacobs University Bremen gGmbH
> Phone: +49 = 421 200 3587         Campus Ring 1 | 28759 = Bremen | Germany
> Fax:   +49 421 200 3103    =      <https://www.jacobs-university.de/>

------=_NextPart_001_04DD_01D774B1.4DFB7EC0-- ------=_NextPart_000_04DC_01D774B1.4DFB7EC0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDcwOTA4NTgwOVowIwYJKoZIhvcNAQkEMRYEFL46+S7nBa8i 9Mz2GCq6sHio7QahMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBABeZ 8eXsfP344iCDiF15K+/ImzN8I7jEDM8zNgMvWbcXL0Dwfd6J81PzA5CIHOgOv7JLlwRxG0W5wNoZ I+Tt9hc+I28b5DWP56dO+B3LbIle6zSHV41dssLzh/puOCQ5SkJ6IIzFTr0i9fGIUb/L1ro9Bf1F dVdGHUScpWJRxhmX/diasgH/HrjoVyr9BAViID2kaCe7QbMX4hnLSYtOghzaqFhFOiXhv0gxqpjB HTXMrbV3pT3ap56GYtJAurzC2CnO1t6N4Kqo/UlzCC0yZLtH2twgcCbjiABCScfbf7uElb1gFZ/k BRX0EjOb/9nDWIx3x5dnTHXNwXI87PUxoE4AAAAAAAA= ------=_NextPart_000_04DC_01D774B1.4DFB7EC0-- From nobody Fri Jul 9 01:59:47 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B30C3A1929 for ; Fri, 9 Jul 2021 01:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AY573Vq52f_z for ; Fri, 9 Jul 2021 01:59:41 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2078.outbound.protection.outlook.com [40.107.20.78]) (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 083603A1920 for ; Fri, 9 Jul 2021 01:59:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RB5efKf1br9yDZq8j1jKWsuN1WBeRF1I03Mx99wzjz9OfU35jiPzKWAbItMfhqWZ6iinwBjbz3RQ2/46s6sKnv/zHGfMxYqTo1TosWgIkm1NqIrH6SgIFq3dm7j2Ibkbe8Kp9zs8JvWQdxbajR4OLTZ/WY2dkTWEKcMyaMv8MeYG1Yr21QjY7H+U9VQ7y4wn4mLe4PioUb1KWM3sW2zKHP7s2ffjn7Ols+et16pfn1nmAZj9rUt9JNBISHZNygQYobXBOPFD9dQWY56kRPwOY9VDtxcKC4VLRm/ATGuEkxgkmfXHafjTBedRRXbgKoAD18i6mPeeCxrySWHS5uAPWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sMeqSupfTu6zn/ifh6oiRdTdR3oP3Vqrvz/g5cge6tE=; b=aKW4x47wj6RH2nilAqQN/1ZhDzFdK4ceAyJ45WvrlpMIdk1cyPz0wRNgOrXk8PTxzzr6M3PzmEVWFGnmNwjuJVF4Dn/q6OHptYtJxd3w0iOUExTw9jiSG3J/9t8c7ERa5dmMeYQZv/ZXMsGmPOiauuMU3Pdgc0nuaaIx6HCpqb3MNOtXomWnzlTkVBVZYBAFpjnOh5ME5Ks9y2XNfEvPzgyxmGrQvVfkYs/dxud6dvJQCd47fioVDH5weRE678qCwO580vTpOjeg1bXpwALxBPIuZE20Yrt5d8RJ7ie7VPxFxBtbw/9o/5iENH6GJsFcba4J9hblgjwc1dYIWJoaYw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sMeqSupfTu6zn/ifh6oiRdTdR3oP3Vqrvz/g5cge6tE=; b=lQJgjmPKzPU1n36IL3Gko3IeQ13ma3s31UEHfLpNmQfDwrfc73htG3gh5NlfxfIWzHgoh9xBfg82C/3zy5oFprxJZsBplIdk1qjFdl2/3d2B7kzeLPddFbSCTys8O+wha7x/KG333vRYeHjGrjy/RpBXBb/A+wRxs+H4otfbmqo= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8247.eurprd07.prod.outlook.com (2603:10a6:20b:326::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.13; Fri, 9 Jul 2021 08:59:38 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4308.018; Fri, 9 Jul 2021 08:59:38 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: tom petch , "Rob Wilton (rwilton)" , Juergen Schoenwaelder CC: "netmod@ietf.org" Thread-Topic: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAPXLWAAAIT0wAAAIMhAAAAy2eAAAJlLwAAGf35QAAW9oAAAB4Up2AAAF8VEAABzZgAAC+kTgAAAA7L0A== Date: Fri, 9 Jul 2021 08:59:38 +0000 Message-ID: References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> , <20210708101326.wuzvtjesghpq5jq7@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: btconnect.com; dkim=none (message not signed) header.d=none; btconnect.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3c005d16-2430-4d41-10c3-08d942b7e1f2 x-ms-traffictypediagnostic: AM8PR07MB8247: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mdcD6L9SdpwckWmJaqg5yITgS6Wkc+EwW/vsXGRuyjwEgQxxQN8MW8/eN5B7c/fEu4iiB20X/bqS+bYVo3W1uGZibpzKPqrrtY6HvCUgsNYXDqp/X9fyPi1qHc/qRq6xwa3eQMPl03+6sUq16cZM1/PjFdQiHMC6wvWwCrmjh5hVHH2XfNgKT7iE+pL8hCf9bGIk3fvF3OfBxeb1UYCJLG1O4Kbrba/m7FBc3xe/0ZBZffg1C75jU2fXoDUOBwXHVG4ZdVg4u/Lyh1gXDqpImf78w2scPdqizJBT3BxLeF+rUdb3HWFWlcgUjYzwgvlFTNpSRtkgdf+6Zh+E3mLhBFSTLMYmx2UC2lvMfua70APhVFc0HvJas7ZVJYFIIKaeRMqGdNlnlp47CfH8570+alq1XXnw70uVT6w+bJN9KbkZg+jZmNW7lWWa413DoUtj8oSNO48OuAfhbtAESJvvxaJxZDe5OuJSRmpWTEc2Rbw2m1rXzICaR96Xr+UOvgJgOTV4MuVolQNMZAiYMd3AgcHV0H9LzynhhsTDgPu+J6CxjgDqThj7AMBpBHnPBLR9wkhvOhahB5D7tqDvLEJI6dvDGLD6/kPLf0nTlSRTaI/5Tl1YRRYKwYJ+rtoXnQMXEurV7I9c28A3ao3n4ueYO81c8oIwkbTmrGWf+DHM7vIeorIsd5NA9V7KbrM2YSIvRLpROD6LaqULuC6MdyZLRGkt3d5I/azL1XIe19sB4Bs= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(39860400002)(366004)(376002)(136003)(38100700002)(8936002)(478600001)(186003)(83380400001)(66476007)(7696005)(122000001)(52536014)(5660300002)(8676002)(76116006)(66556008)(9686003)(26005)(6506007)(86362001)(71200400001)(64756008)(66446008)(53546011)(99936003)(66616009)(55016002)(316002)(296002)(4326008)(2906002)(33656002)(110136005)(66946007)(966005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?7BLgOaC4Bt8KTAEjEL49HFIZIKFtqNO2eKLsKwe1T2UiZs3qcnAw/gE411?= =?iso-8859-1?Q?7fLCygzy/5OP5kgLqzv3Rps2rCzhOsW86pVcKOFXlFX+oEOqaBJQFGYhHF?= =?iso-8859-1?Q?7adaASEs2Z58aLtIYiQx8TRpmjr/N1aLsBuVHnrDpubhcSsvC1L4at9rjY?= =?iso-8859-1?Q?RHzs6lF45HiW5mY0yWso6GVP2fQukHmmVvS/yOH8+z/wOCxFUzU5C2urBX?= =?iso-8859-1?Q?7aPqbSU6GbHB8ALty62omdc1nILYvDq7WGHXjskogbAv43ENsUUDHKFmRr?= =?iso-8859-1?Q?zbpOxaMzptIjxxUQtLqsSntakZlXvr6ydWPnJKhezzsuRrlidbv4va/Nss?= =?iso-8859-1?Q?w2Z9aitt1Re/e39cMNJ2dqz4e+WvMb+JRhjtjExp8sqzQQ0MB3dUqPzWib?= =?iso-8859-1?Q?AmzArxHqkPpa6Vtemwm/dPR8cansKVHzGHikR7qcPZM7OR9vNe9tQM2PZa?= =?iso-8859-1?Q?VgFcb4rZRSsDBXOst1FVar7rDeGql0+S7xUNDk4yzMbylquZk9dO9wkNTH?= =?iso-8859-1?Q?374kgY0ru+nQtvgu61xTmMVhdeiiQ/xkqSqhxPFoE7bLHFIuWekldhqUEA?= =?iso-8859-1?Q?TUq4jB1VYHOjhb+PfUTVfM8GaRUhDHT6eBwYbcg6Y2CwGn/RBZ0WwldTod?= =?iso-8859-1?Q?yUJzyUVGI6I8u7Srxlku0r09CZyDRKA6u3SfIlRdl3dfCLlP9IQcMggpFp?= =?iso-8859-1?Q?KxI62D+BxqktCiXPVdq1/FvseGzyzTlAY/vgDRZC0QnB0rCNm+bV5daSz3?= =?iso-8859-1?Q?O58deIi9vOQ9zl5awySO0hR7RZp/TEQvI+7MwSGjJsuQHCX0vY3WQP0Kyv?= =?iso-8859-1?Q?hWojY6JQKM1Sl65uHs27B7iGcIVSgM2ZSBPyro28//WaXPU8/1AUOEsCNv?= =?iso-8859-1?Q?u4Ky/3afvSpi5c/494HUlejWMJ+4dnfOvCWIr7lq+4AhmGfdUyy+JW1R7X?= =?iso-8859-1?Q?f+HzbSE8yJFLnXXDMfGOctfgTtxZyzIrzOv4vo8zgps4lfl4O4GhpR3NVZ?= =?iso-8859-1?Q?ghHUp0uWT6jyddUrSCvB5SVqRFXp2avapJhcPT29Q+MUIOBGIITFW7C4LB?= =?iso-8859-1?Q?JBeYX6lyhn8bBMFk5rf6eF4zKb8XdxIPSutz9V9dPtqMoECcwJ4tdlH/ZB?= =?iso-8859-1?Q?8gEG1ZNuaDQdZjTPWhKHrjR6gZh6f2hw2S0Ja1yi76sMo5oTQB50YLL783?= =?iso-8859-1?Q?HHZNI5/tjhN4hnRorDMw5QFB/J7aNO21K0L2FW4w7R4lDW8El1usSfPJEm?= =?iso-8859-1?Q?pXljTrycjbZiph1TO8OAwRj5RGxpVCpOR+MbnhnJ9dV1QK9us/5LhUlhNv?= =?iso-8859-1?Q?NNQVbMtNecR4yFWL6sAFiSoPvd3j+XkWn83xlsC0EXUvqnUyzKOXqFTe2/?= =?iso-8859-1?Q?tgUYuaLMNd?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_04E3_01D774B1.81F501B0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3c005d16-2430-4d41-10c3-08d942b7e1f2 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2021 08:59:38.5975 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Py6jYzUE3JTJzA/VxE3A72Nm2zNSM2ahIs6kIAziLILtAocfKv3diFGjfMCT8F4i3Sl+3DVFG9hxv/jznyZWL9ikgD/xtSJ24auFvZPCVWA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8247 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 08:59:46 -0000 ------=_NextPart_000_04E3_01D774B1.81F501B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Only https and file schemes will be mentioned in the draft. Balazs -----Original Message----- From: netmod On Behalf Of tom petch Sent: 2021. j=FAlius 9., p=E9ntek 10:58 To: Rob Wilton (rwilton) ; Juergen Schoenwaelder Cc: netmod@ietf.org Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format From: netmod on behalf of Juergen = Schoenwaelder Sent: 08 July 2021 11:13 On Thu, Jul 08, 2021 at 09:30:27AM +0000, Rob Wilton (rwilton) wrote: > It is perhaps worth noting that the NETCONF copy-config allows for the configuration to be specified using any URI, but the server capabilities announce which URI schemes are supported. > > Hence, I think that it is okay for the YANG model to use URI, but I = think the draft, and data node description should constrain the URI schemes = that allowed (perhaps file:// and https://). This would allow support for = future URI schemes to be added in a future revision of the YANG instance data module, if required. > I think it is not "allowed" but "mandatory to implement". We should = allow implementations to support an ftps:// scheme as long as there is a = common baseline. I am confused. Is ftps: intended to be an existing scheme or a = hypothetical one that may appear in the future. I do not see it in the IANA registry https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#uri-scheme= s-1 sftp: appears as a provisional entry in the IANA registry but AFACT did = not get specified. I recall a debate about ftps: v sftp: I favoured the = former but lost but then I did not see any further work on either. Tom Petch /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_04E3_01D774B1.81F501B0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDcwOTA4NTkzNlowIwYJKoZIhvcNAQkEMRYEFCYQXwQB3HHy OUcC9e+/8WZVwwQJMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAE4u PkGJY/WAYNa+XjSRRYdz5mzuIvWQWlNojB/x2GP72WhP/gk5Gxa2C3Q2Fzl0DPkTunjnA63sa7Gx egyhVRqmxmUINKCdmx4WXXp1fwwYlbuP6qDBooQCq8JOxTNtzgRPp0tBTfO6TT+V1onxuww1beWp 5sADJOYbTtCO6zVFDO4BxDqrdWTo/ylic9bCKQzSM6cXFiaNmYmGt8/DKd1QY7w5HkloOdP/wa5Q DNoxkOaMzHJ289JbG7c392NkblfldFBRuhGfHFPRq3p3MdEtb2jRm6HHRzSVixiqpyYXnTOnuo4P 29Gqr05Mm2UmPelJpnl0goBhjh9w5r5NZbMAAAAAAAA= ------=_NextPart_000_04E3_01D774B1.81F501B0-- From nobody Fri Jul 9 02:10:45 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822A13A1994 for ; Fri, 9 Jul 2021 02:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=gnTz4FRl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=U/5k30au Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oH1cccALCvSp for ; Fri, 9 Jul 2021 02:10:38 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DDD03A1993 for ; Fri, 9 Jul 2021 02:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13207; q=dns/txt; s=iport; t=1625821838; x=1627031438; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Moc8punhWh5D2L9aTZczgJlZfxWrIdjxMJ6nvbzWgUQ=; b=gnTz4FRlPUQ5cLj+Id11B2NOTGaXedqQI41a2hpCUET8U1qn31+93kxh 67MYTuRk28nNwZquE6ONiNAjMeGUROmMAcR4Uka+5kvKMZw1pnGDwgb0w KE+oDKiH/+GEpHdm296q0filXIOhxjDTtiLa39ZCxS0NNdBypDEvWx0OQ Y=; X-IPAS-Result: =?us-ascii?q?A0DqAQDXEehgl4ENJK1XAxwBAQEBAQEHAQESAQEEBAEBQ?= =?us-ascii?q?IFZgVNRflo3MYgQA4U5iF0Dj2WKQ4JTA1QLAQEBDQEBNQwEAQGEUwKCeAIlO?= =?us-ascii?q?BMCBAEBAQEDAgMBAQEBBQEBBQEBAQIBBgQUAQEBAQEBAQFohTsBBiYNhkUBA?= =?us-ascii?q?QEBAwwGLgEBKQ4BCwICAgEIEAEEAQEBLhsXHQgCBAENBQgTB4JPAYJVAy8BD?= =?us-ascii?q?ppAAYE6AoofeIE0gQGCBwEBBgQEgUlBgzMYgjIDBgWBNYJ7gnETQIcrJxyBS?= =?us-ascii?q?USBFUOCYj6CYgEBAgEXgR0RAhgfJoMGggwigikBawZoGA8BChEOAk8OHhYHA?= =?us-ascii?q?yoVBCYPBiQRnX6BK51kCoMkiiyUHBKDY4tShjuQV5YAjC6TIikIGYRmAgQCB?= =?us-ascii?q?AUCDgEBBoFzIoFbcBU7gmlQGQ6BGot1gRAZg1eFFIVKczgCBgEJAQEDCYk6A?= =?us-ascii?q?SeCHwEB?= IronPort-PHdr: A9a23:nGM6PRXdd0RJJMJrX6dLZBL/+D3V8K0eAWYlg6HPw5pDaKWo5I/lO grU4vA+xFPKXICO7fVChqKWtq37QmUP7N6Ht2xKa51DURIJyKB01wwtCcKIEwv3efjtaSFpE d5DX0R++Hf9Ok9QS47yYlTIqSi06jgfUhz0KQtyILHzHYjfx8S63uy/4dvdeQJN0TG8erh1a h6xqFa5iw== IronPort-HdrOrdr: A9a23:YOLVJaApMpSBddblHegqsceALOsnbusQ8zAXPh9KKCC9I/b3qy nxppsmPEfP+UkssHFJo6HmBEDyewKjyXcT2/hRAV7CZniphILMFuFfBOTZskbd8kHFh4tgPO JbAtRD4b7LfBhHZKTBkXOF+r8bqbHtms3F9ISurUuFDzsaFp2IhD0JbDpzZ3cGPDWucqBJba Z0iPA3wwaISDAyVICWF3MFV+/Mq5ngj5T9eyMLABYh9U2nkS6owKSSKWna4j4uFxd0hZsy+2 nMlAL0oo+5teug9xPa32jPq7xLhdrazMdZDsDksLlWFtyssHfsWG1SYczEgNkHmpDo1L/sqq iUn/4UBbU215oWRBDsnfKi4Xi67N9k0Q6S9bbRuwqSnSW+fkNhNyKE7rgpLicwLCEbzYxBOe twrhGknosSAhXakCvn4d/UExlsi0qvuHIn1fUelnpFTOIlGfVsRKEkjQto+a07bWnHAUEcYZ 5TJdCZ4OwTfUKRbnjfsGUqyNuwXm4rFhPDRkQZoMSa3zVfgXg8liIjtYAit2ZF8Ih4R4hP5u zCPKgtnLZSTtUOZaY4AOsaW8O4BmHEXBqJOmOPJlbsEr0BJhv22tPKCXUOlaiXkbkzvdQPcb j6ISZlXF8JCjTT4Je1re92Gzj2MRGAYQg= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,226,1620691200"; d="scan'208";a="746244710" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Jul 2021 09:10:36 +0000 Received: from mail.cisco.com (xbe-rcd-002.cisco.com [173.37.102.17]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 1699AaGD006176 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 9 Jul 2021 09:10:36 GMT Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xbe-rcd-002.cisco.com (173.37.102.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 9 Jul 2021 04:10:36 -0500 Received: from xfe-aln-002.cisco.com (173.37.135.122) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 9 Jul 2021 04:10:36 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 9 Jul 2021 04:10:35 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hr3SEnAIPL05ufWTdLV2OHZcCtEW9Ayhlru1h5TLXE8b/4+f7H64jG96HflQWNJnuVmgiVSE6iB2cdxGCvOhUKKKE9P/zYnlCI0oK7nEXXk8qfPXGxR+0mph9daOJVhKdhEjaZ7FMaKBvQZ/pvtWkWfl267yfXa4BgL4yYKzuIQYLHbVHMNqajtCLUSyQC5OMPSWKjdXcUbCA7nBWYWuF0qsBrNKiZ5/SG9ZgkARQ8oM/sVsIRPOFrErG76qRwr4jfIzStKA0XbpKA3EN9yYAvNHtE5GdY6ASm2eHdjwYGO8ceP/OVDT0ySMrsH96iNOPgkqrhuNgSll0GTHSvXmig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MPpib9KtcV5LkkSm26BofIaE5VskTgKI9vBINztU/TU=; b=OBPWjLU+ZeUeGz3PRdi5AwBlpfgC+NUslJwhV8pqjfSFAVzX/B8qQ07QbY+gFUFkpXO4aKrCEZSDHWJURWp//h0He6SYRKO0bzADSQqKj6LE1ByjKasWJEtJGz05ZTsf9uS6I0oQLhHLICXjHkCy4HNYFHlSm9W8tu0JU6YR1I0lrJ26nIF3XAIQ2Y+ZagWQqySTNQH5+imCoaGUkZBHEcLlyjQuMtp+pFDXxmHYGkGc1b2gDzzOKU3/SfDLbBKu651SFJpaGXlr7+Yxz9XS0+XMJpGUQwc+7D0IZi9LWoduhEP9vkp7+KHhalck4jSCE+ozN7sBihKnicR/R6FeZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MPpib9KtcV5LkkSm26BofIaE5VskTgKI9vBINztU/TU=; b=U/5k30aub17VA84RTILOyra64Ct+SZGiVzRvK/ZOW80+aLM4xab1Tg45abqYN7Y728Qwhh9VDaZu+4d3Qu9K/mjUJplSeVq5MKNoq/ML3MPEC2nUt4e/vfODanVUm5ByH9uA2CqtVjKrT04GrH8KbJ+p2wnSYKQ0vORY64mBVMM= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM6PR11MB4187.namprd11.prod.outlook.com (2603:10b6:5:19e::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4287.33; Fri, 9 Jul 2021 09:10:34 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12%6]) with mapi id 15.20.4308.023; Fri, 9 Jul 2021 09:10:34 +0000 From: "Rob Wilton (rwilton)" To: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= , "Juergen Schoenwaelder" CC: Andy Bierman , "netmod@ietf.org" , Benoit Claise Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAPXLWAAAIT0wAAAIMhAAAAy2eAAAJlLwAAGf35QAAVpNcAAAKQ2AAAHRePIAACr5QAAAAUxvAAAke7IAAESQ+gACTRU5AAA2B0YA== Date: Fri, 9 Jul 2021 09:10:34 +0000 Message-ID: References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> <20210707192534.4emim5a36zyqrktc@anna.jacobs.jacobs-university.de> <20210708103528.6ezr4v5qeltinvmv@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 34600983-1603-4300-d276-08d942b968cb x-ms-traffictypediagnostic: DM6PR11MB4187: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZUTyWT2s69MjsYKyIvE8N5lj0zlIHhU8XRDUSBTce46pfETqiEbljgbuP/Q6XvslU4gbdB63X+3sCIqiugs1GkiWdRiMitgHzey/J9O0+vfPVC/sZvgxWlp5x0o6wy6WKJ9gWKasYKD6+9a0BYvfNlaoDD8AliNIQLGfo1lh1wgleWVeky3R29ocXUTLqcrwLtv73tRBJ8/8gc52y4XFJRguSKP7EXJ5D4viIvsluRHDmwed1kMDdy4jVdnoEVt2bFkRStsjXY+2okS9/ofhc3ndvhQA2IrF+ZHoq4UaqtMOEon5xZxUxAL1PPPEpske1ey77n3nwbU580GfNP1KWiYjo4DTltOa5tF5pi6/4bQ+2zVLjZigCU4qfIEXhWjTDTA7oFCh6nTgA6+GGcvsonEyD9BFJnf7yECPcV4Swb2OouCKsOeA15Vz8IiNH+1DEhEY/1W42QvT20A4hCDdF9cZ/oNYMA6RGZkCkPfuvCy94GEsNoEZPMrpHs8543y13PcvPdnDGMSIZ2uKzqjHsuoAHPXngf1T3LHc3G5qQvakafInvdJBYjYjewimvx43syeCu6ZTtyt8sn69ObAbfSnYJtQLJiWINR/wyv55J4yU0bAQPbg2R4wPQwXxe4SKPbw141WKUZ+0JPYT1Elk+pCt3qwpYS/N71XNpYmPQ9UCc5g7xf5XwMLG6c4eHqCTyoAHdqdvBj9sRoPD2Lxk41NgHaX+jmHWjmz6nHK5MAeJiC0A1DJGutdlSxOWJp9SHcKFAbyRPNOHHmR6xdJCBg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39850400004)(346002)(136003)(396003)(376002)(366004)(66574015)(30864003)(9686003)(8676002)(122000001)(26005)(8936002)(55016002)(64756008)(53546011)(38100700002)(5660300002)(83380400001)(86362001)(478600001)(6506007)(71200400001)(33656002)(966005)(4326008)(66476007)(110136005)(66946007)(186003)(54906003)(66556008)(66446008)(7696005)(76116006)(316002)(52536014)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?80bGj41m999GqYIsaI9nxPPqsxbzC7AX9Mv7LdXGkckOocLjFnfdFCRwPK?= =?iso-8859-1?Q?HnofWvfH0ku18p7yszvSOZHM+yV916mcczkCu9pEsZ057Az0yh64c42FWs?= =?iso-8859-1?Q?pqZnoy6aG93b1ZDlkNNfgD/6ojdNUP5o5aAfQg4K49JRVr/N5R+rTEQfkY?= =?iso-8859-1?Q?sKwImaKro3Pqieq9IVrXM1OQ67WaNjr2QoVResXf3KkyfxN6InaGSkNhcv?= =?iso-8859-1?Q?b395bd+k8Wh3oEmMAtMzZFyu23eglKQL99Ymw18dB+wgMZQt4LxQd7r15c?= =?iso-8859-1?Q?9bjvK3Lc8q+j9sGHWi5F6Xc7iALwNP0e7/flXxoxLSfdMN558tRDhvziA7?= =?iso-8859-1?Q?BObq75KZdZniYCa/WSeIdA87IU9C2MC2ogU7VqGdRmRtLUnt1tVVjnjW71?= =?iso-8859-1?Q?jT/eVjTEUwuS+aaIDNy6xW78SPJXePZSXYLu6btSbk18+yfzEaqbc+mOKz?= =?iso-8859-1?Q?Jze2aw7d0ZxpGGX5cZdeR+O/uPUjXH5EDOMmCy6GpebgHRc407El3C9wFZ?= =?iso-8859-1?Q?npQCqYdDnGTl/KeNs/gO6tViMVGLf2ilCHmyJBkbDfuBTOhNllMa5kDnA1?= =?iso-8859-1?Q?EaFuisU/Zdc3HOO4CbF6WgHOQAXGtqUj8xmJSBshVs4SNgxeMrrZAwSmMd?= =?iso-8859-1?Q?SNVp4SIL7YAyJaSXRGpVlWyWZAe83sJ77z7+NNQQyfifJdILLQE2jIadmR?= =?iso-8859-1?Q?YGZYqJr22vf/FSg5YZj+4G79EMu9HRQT3MelREZls2QDp4H+EwcG4N4vfb?= =?iso-8859-1?Q?xMNhvsLrVoiSx81a78Mc9vK8Mt624oGXIRZ7yWz5XFG/nhO0KJBrxS0Z4f?= =?iso-8859-1?Q?U2tPOiauq++mBq3xUXxidKDQU/sCvAgtJRSaiIarcqrSkzX+LrgxpV4S8F?= =?iso-8859-1?Q?r6F5TNHDWX+gnpXvI0X0hbv6Hd/y+vtLu5yyklOMJV97A4GQ80nfXnJBGQ?= =?iso-8859-1?Q?sr6w2a4CtiIWqI9tNE4yCkcNjW3ADdRKOhcMjI26mMnTDExe2XXmjy8P2Y?= =?iso-8859-1?Q?r1fiGXPwiIWbAzZ0ulYJ4j+I6EYVmh3KDgRwjJFYGOmJN8V3F/Dg70UPoc?= =?iso-8859-1?Q?+csIRpzjaX1LGY1Vo6mcxKAC7iXnllfi56ZBzi7em8qu9cNKZ0pYits6ZW?= =?iso-8859-1?Q?+mYWJJx6exaN9T6ndo+bX3E3PRQekjVby53rx9WvGlvVysZ1HlScOtZ+2f?= =?iso-8859-1?Q?FB0Z7P9sRHDXOhsJ2lfihpXJ35fEQWFoyazUOG0JWH73RExrjUkV6ZuhSS?= =?iso-8859-1?Q?KRejK1IrLb8GI+zxY91Tn2BPpS5MT23la7/qFua+FsNd+DbNw/Rrzx+P84?= =?iso-8859-1?Q?sAO4MMFLiL69ksTzqR0ZOVSNFcQ50ES46Px1z7vn+r/kuK2DWFToZDeO8E?= =?iso-8859-1?Q?9BR/CC1als?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 34600983-1603-4300-d276-08d942b968cb X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2021 09:10:34.2922 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6pDvzc9pbwxSlIr7EFjUgut46AlBDFqf+NLq3C7W7+ajA8ngt1cvN9umCSUdBsRtO4qjk4dqO2JH2tYoJMK71Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4187 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xbe-rcd-002.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 09:10:44 -0000 Hi Balazs, Thanks. That sounds fine. Please can you add a sentence to the descripti= on of the simplified-inline in the YANG model to state this, which I think = may be something like: "YANG modules that are only required to satisfy import-only dependencies MA= Y be excluded from the leaf-list. If they are excluded then the consumer o= f the instance data file can choose any versions of the YANG modules that s= atisfy the import dependency." Regards, Rob > -----Original Message----- > From: Bal=E1zs Lengyel > Sent: 09 July 2021 08:25 > To: Rob Wilton (rwilton) ; Juergen Schoenwaelder > > Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise > > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format >=20 > Hello, > A single line is enough. > As long as ietf-yang-types is change in a backward compatible way, I don'= t > care which version of yang-types is imported. Also, we only use a single > type 'yang:xpath1.0' from yang-types. The rules for this type are descri= bed > by W3C and not changing. > Balazs >=20 > -----Original Message----- > From: Rob Wilton (rwilton) > Sent: 2021. j=FAlius 8., cs=FCt=F6rt=F6k 15:49 > To: Bal=E1zs Lengyel ; Juergen Schoenwaelder > > Cc: Andy Bierman ; netmod@ietf.org; Benoit Claise > > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format >=20 > Hi Balazs, >=20 > Would your inline schema not also need to specify the ietf-yang-types > dependency? >=20 > E.g., should it be: > ietf-netconf-acm@2018-02-14 > ietf-yang-types@2013-07-15 >=20 > Thanks, > Rob >=20 >=20 > > -----Original Message----- > > From: Bal=E1zs Lengyel > > Sent: 08 July 2021 12:48 > > To: Rob Wilton (rwilton) ; Juergen Schoenwaelder > > > > Cc: Andy Bierman ; netmod@ietf.org; Benoit > Claise > > > > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format > > > > Hello, > > I would like to keep simplified inline. If I ask my developers (not > > experts) which one do they want? I am pretty sure they opt for the > > shorter/simpler one. > > > > ietf-netconf-acm@2018-02-14 > > > > OR > > > > > > > > m > > > > ietf-netconf-acm > > 2018-02-14 > > uri1 > > > > > > ietf-yang-types > > uri2 > > > > > > > > > > s > > m > > > > > > running > > s > > > > > > > > Regards Balazs > > > > -----Original Message----- > > From: Rob Wilton (rwilton) > > Sent: 2021. j=FAlius 8., cs=FCt=F6rt=F6k 12:59 > > To: Juergen Schoenwaelder ; > > Bal=E1zs Lengyel > > Cc: Andy Bierman ; netmod@ietf.org; Benoit > Claise > > > > Subject: RE: AD review of draft-ietf-netmod-yang-instance-file-format > > > > Hi Juergen, > > > > I believe that having the simple form is worth the extra complexity. > > > > I think that you are right to be concerned that it should not expand > > into a separate parallel format. Overtime, I would like the simple > > form to be able to use revision labels instead of revision dates, but > > beyond this I think that it should just be a flat list of modules that > > defines the schema. If a subset of features, or datastores, or > > import-only modules are needed then the YANG library version (or URIs) > can > and should be used. > > > > Another example of where I expect it to be useful is in YANG packages. > > Looking at the examples at the end of > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, > > then some of those files (which currently aren't defining any schema, > > but should) would almost double in size if they represented the schema > > inline using YANG library, which I think would make the files harder > > for humans to read/parse. > > Using URIs could help mitigate this, but then we would need to find a > > place to publish the file containing the YANG package schema > > (presumably somewhere in IANA), and it not obvious to me that adding > > the dependency on the URL is really as helpful. > > > > Regards, > > Rob > > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > Sent: 08 July 2021 11:35 > > > To: Bal=E1zs Lengyel > > > Cc: Andy Bierman ; Rob Wilton (rwilton) > > > ; netmod@ietf.org; Benoit Claise > > > > > > Subject: Re: AD review of > > > draft-ietf-netmod-yang-instance-file-format > > > > > > The question I asked is "how much simpler is it and does that saving > > > justify the introduction of a new rather limited format (that may > > > risk to grow over time and become a second citizen)". > > > > > > So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports > > > from ietf-yang-types (at the time of publication that resolves to > > > ietf-yang-types@2013-07-15. So the YANG Library instance data would > > > roughly look this (please correct what I messed up, I am writing > > > this by hand): > > > > > > > > > > > > m > > > > > > ietf-netconf-acm > > > 2018-02-14 > > > uri1 > > > > > > > > > ietf-yang-types > > > uri2 > > > > > > > > > > > > > > > s > > > m > > > > > > > > > running > > > s > > > > > > > > > > > > Yes, this is a bit longer, but it also conveys more information > > > (note that your datastore leaf in the header would likely not be > > > needed anymore). > > > > > > I am concerned that we start creating another format to define > > > schemas that is very limited and people later come with extension > > > proposals to address some of the limits and at the end we have > > > multiple formats to maintain and deal with. So the question is > > > whether people think this is worth it. (Note that the felt overhead > > > goes down with every additional module used by your instance file, > > > so the example above is really the most extreme case. And if you > > > have many modules defining NACM rules, then you put the above into a > > > separate file and use the URI to point to the schema, no? > > > > > > /js > > > > > > On Thu, Jul 08, 2021 at 09:27:52AM +0000, Bal=E1zs Lengyel wrote: > > > > Hello Jurgen, > > > > Inline: > > > > This complex form of inline was requested and not objected earlier > > > > by > > > other > > > > reviewers. > > > > Based on Rob's and others' proposal inline will be simplified to > > > > use only > > > > ietf-yang-library@2019-01-04 as you suggest. > > > > > > > > Simplified inline: > > > > In Ericsson we already use simplified inline a lot, it is the most > > > > common format. > > > > If you are providing data only for one or a few YANG modules and > > > > don't > > > have, > > > > > > > > don't care about features/deviations it is the easiest, shortest > > > > method to use. > > > > Our most common use-case is to provide preconfigured access > > > > control > > > rules > > > > for new nodes. > > > > When a YANG modeler designs a new module, he immediately provides > > > > a > > > set of > > > > NACM rules > > > > for the readOnly and the SystemAdmin roles/groups. > > > > In this case you only need to specify "ietf-neconf-acm@2012-02-22" > > > > No deviations, no features to indicate. > > > > Regards Balazs > > > > > > > > Regards Balazs > > > > > > > > -----Original Message----- > > > > From: Juergen Schoenwaelder > > > > Sent: 2021. j=FAlius 7., szerda 21:26 > > > > To: Andy Bierman > > > > Cc: Bal=E1zs Lengyel ; Rob Wilton > > > > (rwilton) ; netmod@ietf.org; Benoit Claise > > > > > > > > Subject: Re: AD review of > > > > draft-ietf-netmod-yang-instance-file-format > > > > > > > > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote: > > > > > > > > > > > Inline method is needed, if you want to indicate that the file > > > > > > was generated by someone who uses some YANG modules with > > > > > > deviations > > > and > > > > > > some features are not-supported. There is no way to indicate > > > > > > feature-support and deviations with the simplified-inline metho= d. > > > > > > > > > > The Inline anydata solution is very heavyweight. > > > > > Before the YANG library there was a simple URI that is easier to > > > > > use and takes up much less storage. > > > > > > > > > > > > > The inline content schema is super generic since it supports an > > > > open ended set of schema defining modules. While you can use it > > > > with say ietf-yang-library@2019-01-04, you can use anything else > > > > as well. In other words, two implementations supporting inline > > > > content schema may not interoperate. I do not think there is a > > > > schema format that is mandatory to implement for inline content > schema. > > > > > > > > So here is my assessment of what we have in terms of interoperabili= ty: > > > > > > > > - Simplified-Inline comes with notable restrictions, interoperable > > > > - Inline is an open ended content schema, not necessarily > > > > interoperable > > > > - URI method pushes the problem to another instance file, > > > > interoperable > > > > - External is by desing not interoperable > > > > > > > > On the server side, we have YANG Library. Perhaps RFC 8525 has > > > > some complexity that is useful for supporting large servers with > > > > multiple datastores and not needed for small instance files (I > > > > understand that an instance file is always tied to a single > datastore?). > > > > > > > > To me, it feels that reusing RFC 8525 design is actually a good > > > > thing. Being able to dump a live server datastore into an instance > > > > file seems like a very valid use case to me and ideally this is > > > > possible without having to rewrite the schema part. Well, you > > > > could go and trim unused datastore schemas > > > and > > > > from there unused module sets etc but that can all be done by an > > > > external tool trimming the schema part, i.e., it does not need to > > > > be done by a tool that just dumps a server datastore. > > > > > > > > What is the actual value of simplified inline? How much do you > > > > really save compared to the simplest equivalent RFC 8525 > > > > representation? And does > > > that > > > > saving justify to start engineering another schema specification > format? > > > > > > > > I guess my choice would have been to just have > > > > > > > > +-- content-schema > > > > | +-- (content-schema-spec)? > > > > | +--: (yang-library) > > > > | +--: (uri) > > > > > > > > but others obviously want much more choice (but lets note that > > > > everything sits in a choice, so everything is extensible in case > > > > other schema definition formats are out there). > > > > > > > > /js > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > > > > Fax: +49 421 200 3103 > > > > > > 866038973a > > > > 15-19e5dad375af0063&q=3D1&e=3D3637406d-f774-4073-80ee- > > > a7431111e9bc&u=3Dhttps%3A%2F > > > > %2Fwww.jacobs-university.de%2F> > > > > > > > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > > > 86e2237f51 > > fb-eceadf4f1dc08461&q=3D1&e=3D09140141-b70c-44c9-9909- > > 048d736efebf&u=3Dhttps%3A%2F > > %2Fwww.jacobs-university.de%2F> From nobody Fri Jul 9 02:21:48 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4880C3A19ED for ; Fri, 9 Jul 2021 02:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.895 X-Spam-Level: X-Spam-Status: No, score=-11.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=jUc21QEl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ZcGQi6Ll Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNvUJpTyIZqB for ; Fri, 9 Jul 2021 02:21:40 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D353A19E5 for ; Fri, 9 Jul 2021 02:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42510; q=dns/txt; s=iport; t=1625822500; x=1627032100; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LQcvyG8wm6kRDxwOsml3podKS2F475iFzJo4oE00efw=; b=jUc21QElfQmUe3DbIG8bTNxqEjFtZX1F/ek+UPHgTwNfP33+ONu951BD ZNKCMsYdxQtGlSU4jh+xWDSKNrYBLYypM191yuq1V99xyF0om9YOzL7VG WVc2Fg065yWU8uomtm4UftHRqd1nwXmHFm45FXp6DPiXMwHQtSdLdpM6p Y=; IronPort-PHdr: =?us-ascii?q?A9a23=3AINq3oRP69Tk0gUlvrisl6nfhWUAX0o4cdiYE9?= =?us-ascii?q?58ulLVUcb/l9JPnbwTT5vRo2VnOW4iTq/dJkPHfvK2oX2scqY2Av3YPfN0pN?= =?us-ascii?q?VcFhMwakhZmDJuDDkv2f+/3aiUlG95BTxlu+HToeURQEdz1MlvVpHD65DUOG?= =?us-ascii?q?xL5YAxyIOm9GoPbg8mtke6o/JiGaARTjz37arR3f32L?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AVtIi1KHH/334d0TApLqFaJHXdLJyesId70?= =?us-ascii?q?hD6qkvc31om52j+fxGws516fatskdvZJkh8erwX5VoMkmsi6KdgLNhc4tKOT?= =?us-ascii?q?OHhILGFvAY0WKP+UyEJ8S6zJ8g6U4CSdk+NDSTNykBsS+S2mDReLxMrKjlgc?= =?us-ascii?q?KVbKXlvgpQpGpRGsddBnJCe36m+zpNNXB77PQCZf6hz/sCgwDlVWUcb8y9CH?= =?us-ascii?q?VAdfPEvcf3mJXvZgNDLwI76SGV5AnYqILSIly95FMzQjlPybAt/SzuiAri/J?= =?us-ascii?q?iutPm911v1y3LT1ZJLg9Hso+EzR/Bky/JlaAkEuDzYILiJaIfy+wzdZ9vfrm?= =?us-ascii?q?rCpeO85ivI+f4Dsk85MFvF+ScFkDOQoQrGo0WSuWNwx0GT+vAQgFkBepd8bU?= =?us-ascii?q?UzSGqC16NohqAO7Itbm22erJZZFhXGgWD04MXJTQhjkg6urWMlivN7tQ0UbW?= =?us-ascii?q?IyUs4YkWUkxjIfLH7AJlOM1Kk3VO11SM3M7vdfdl2XK3jfo2l02dSpGnA+BA?= =?us-ascii?q?2PTEQOstGcl2E+pgE082IIgMgE2nsQ/pM0TJdJo+zCL6RzjblLCssbd7h0Cu?= =?us-ascii?q?sNSda+TmbNXRXPOmSPJkmPLtBLB5sMke+/3FwR3pDkRHUl9upGpH3xaiIviY?= =?us-ascii?q?dpQTOdNSSn5uw+zizw?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1CwBjFOhg/5ldJa1XAx4BAQsSDIM?= =?us-ascii?q?8MFEHd1o3MYRIg0gDhTmIXgOaKIJTA1QLAQEBDQEBNwoEAQGEUwIXgmECJTg?= =?us-ascii?q?TAgQBAQESAQEFAQEBAgEGBHEThWgNhkUBAQEBAxIICQoTAQE3AQsCAgIBCBA?= =?us-ascii?q?BBAEBASAHAwICAhkXFAkIAgQOBQgTB4JQgX5XAy8BDpo6AYE6AoofeoEygQG?= =?us-ascii?q?CBwEBBgQEgTUBAwIOQYM2GIIyCQWBNYJ7gnFTSAEBhmEnHIFJRIEVQ4JiPoJ?= =?us-ascii?q?iAQECAReBHRECGBUKDAkICYJQNoIMIoIpAWtqBBgPAQoRDgEBTw4eFgcDKhU?= =?us-ascii?q?ENQYkESmRX4MOiDE3nw8KgySKLJQcEoNjgUeKC4Y7kFeiLpMiKSGEZgIEAgQ?= =?us-ascii?q?FAg4BAQaBSSokgVlwFTuCaQlHGQ6BGo0Fg3AzhGGFSnM4AgYBCQEBAwmJOgE?= =?us-ascii?q?ngh8BAQ?= X-IronPort-AV: E=Sophos;i="5.84,226,1620691200"; d="scan'208,217";a="893445078" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Jul 2021 09:21:37 +0000 Received: from mail.cisco.com (xbe-aln-005.cisco.com [173.36.7.20]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 1699LcdD007821 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 9 Jul 2021 09:21:38 GMT Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xbe-aln-005.cisco.com (173.36.7.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 9 Jul 2021 04:21:38 -0500 Received: from xfe-aln-001.cisco.com (173.37.135.121) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 9 Jul 2021 05:21:37 -0400 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 9 Jul 2021 04:21:37 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hrC9Uxgu6kkoBAXP/AaDRJHWlSJZH5W7B7zEGZfM5UQm1kQFp+LEHOXvKcwdio3eSQNstm4xb4kQxfd16MFmf1tbiRWwu85D9FzJ+kcB0M3VWWNBIYwF5Jb3S4InpUhiNwoCxJsrAYOwlVU5YG7xHZRphyCndQI3MEqhKb8iOsj4VWEZuroXL9vgkjFAMd//nYgjW6nz+cLYiSJIuKFh7eGANa2DP9UdeT9g0o0OOLRBircarhkJK0GOWgRNCT4G1vlCxiRs+xxLoLVbPE9mLShtn1JDB+4UjcJx5xzJFvHY1hBTncsiaZO9kHox4u/7PcR0gQPk/oRfTfuUX5y7/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LQcvyG8wm6kRDxwOsml3podKS2F475iFzJo4oE00efw=; b=KqcobByIAKv+yVR+gNtOm+CxvPrR0LHtx61HhZlqSvv4y2S7mHaNiLomkmjEJhYzEnTOC8zjf0SQH1vWQ92eJd0F1tKKk28g9BOxE902CHHYekcYwBOJO9nZUl4nM3dMoizU8W7T0cSGdMcBb3sM6WgHXJx3r0gfSLflmmMhuFCdyZtMnMlNB2jr1uyQp9inLrsOvWwrwzJQfL1tPlx0SxP2UxrlvIUYQcplo5+0ujMkwGAJI3Wc+7nf0vI7+bKhTAkG7KbCo8fq6/9U2F3AP4RzMbSrBp75AQwfXsK1THlQFhDIhnHevEJeV5NaXTeORSB3v0ZnoL/tf+xVJ9BGjA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LQcvyG8wm6kRDxwOsml3podKS2F475iFzJo4oE00efw=; b=ZcGQi6LljKR1wDuJsbfYvdXunxt1QzHHwKottvv8SBQkNOc8mA50vIB5bA5vdpS0MO1TD4aDC9tVxcQSpJ/2dxw/DNDCwrmUnmAz8kKMpoWeh5YSknNG63HYMEl4HtmyKK3jLy7KgMtJWn1EaPPtqGp9Cmyyv762hndiQCCM+vQ= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM6PR11MB3019.namprd11.prod.outlook.com (2603:10b6:5:67::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.22; Fri, 9 Jul 2021 09:21:31 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12%6]) with mapi id 15.20.4308.023; Fri, 9 Jul 2021 09:21:31 +0000 From: "Rob Wilton (rwilton)" To: Andy Bierman CC: Juergen Schoenwaelder , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "netmod@ietf.org" , Benoit Claise Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAPXLWAAAIT0wAAAIMhAAAAy2eAAAJlLwAAGf35QAAVpNcAAAKQ2AAAHRePIAACr5QAAAAUxvAAFPWNgAAaTRYg Date: Fri, 9 Jul 2021 09:21:31 +0000 Message-ID: References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> <20210707192534.4emim5a36zyqrktc@anna.jacobs.jacobs-university.de> <20210708103528.6ezr4v5qeltinvmv@anna.jacobs.jacobs-university.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e84626c3-5250-4b83-1fbd-08d942baf03f x-ms-traffictypediagnostic: DM6PR11MB3019: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3383; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DNsh6nErrWvJxY1ZYBNBxH2MffD00O0JnzfaZuTjtmt9Yn8w1QTzA2KmeaqoAckdz4TW/iHcy8PjPNfSPeGA8tky+vsGdDdMLITxYC/+4NK4g+vwpV5K14sz52YnTxRfsm+fAbTshjYIvm//4FkzMXKz61cVegUm2cugNETq9TETOhoGsqccQC3Gu4yGs2i1mUUatvaUNqjHp6SDRdSiYwJDYW+RkQghLUwcbc4eBkK6pMIopNd+c2h2ktrkeCmseA40RqrFUSLsoS5YMaWNyR1vU8N1ZQmkK14CTKoKlLIjgl+skLDk2rEhisAu0AqdE4K8hI/ju0u8kAG2nV8IFWwuNvJ7r8vX7k8HHamtxxWiHD5USpet9D9fj/87O0Irvkw7oENHREn76ujFFzG7cgIzRa3dsFyxrunEB/xt98bJbMi5M0S9pY9tbcmTBs9bqrzhNs/0iJJjzGiTvFmCh5uYL7s3MZjMXA5ZeKIvIAoD7IE+8lb//1WeMzDsKYoUau789+fLX3cdWApQyUCzzeECA8C84MX8DRaHK17+SSaCmCtmPY0+J9sFvp3IiPBrQaB5hX6IqX4Anwy/2SotObq5JaUYJiefo0ZnFDcJeA5gXxljLIPuKV72BB3MeLcTyskIFyoNq9MkUdM+73VQwc66QFKJkXWkv+ekvOJNU8rpV+KtP2QU2zhzokl9Ucq/NilJSJfYY64rzmfQjMDChyA/9dLvqS06UQPIBw5iBlToBJ4pLTiQK+0oNQ3CaaWctcATUMNfF5TEGn28dMlbOQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(376002)(136003)(366004)(346002)(396003)(66946007)(166002)(66556008)(33656002)(6506007)(64756008)(38100700002)(76116006)(66446008)(66476007)(7696005)(9686003)(316002)(186003)(966005)(26005)(71200400001)(66574015)(53546011)(478600001)(8936002)(54906003)(30864003)(8676002)(2906002)(86362001)(122000001)(52536014)(5660300002)(6916009)(4326008)(83380400001)(55016002)(9326002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dzhuN3o0dktuY3UxSjJkVnBIVzJFNTVrVGFqQjZHUGRoMkhwV0FHZTRNaktQ?= =?utf-8?B?cjlOR1kweGV3YUF1N2RpMzBqUE5SdTliT2MzakRNaGFUNFhMKzV0cmJ0aklh?= =?utf-8?B?YS9tZ3plUG5zUTdlWTRLbm9CM0g1clFjWHhnSXY2ZzNqcjlBY0VITjhXOE9J?= =?utf-8?B?c1NzdGVEdmFHaGpUa0MwZFJVRkxjcjljWXFUL0FuSDZJM3B0aFd1bmJQeStt?= =?utf-8?B?Q3dqTTlRTnJ2eW1YY2szamp6eHRLek9YOU9VR2ptOHM1dEFFbnY5MElXbHgv?= =?utf-8?B?TnF5UnNIWXhFSjlqRy9nSG1TWUE3NDUvNFpqZEc1THdQTFEyZkVjM1E5bjMz?= =?utf-8?B?M3ptTlQzdjUwS3IxVitxYmNqUHQ0cWVkRWdtZk9FaURGTTFCOXZxc3J2MkJk?= =?utf-8?B?ZUFKTDBTcmQzaHdQNXVhZGQ2cHV2UVNuUlUwZHg2UC9tVW1jQTJsUE5KQlZO?= =?utf-8?B?M01LYmI1WVdSZzk2eDJuKzZEL0RtNXFzWGx1VjZBSHI2VmJpK1RnR3FnWUhl?= =?utf-8?B?cFdPekx4amZzSmp2dXQwbEhRMERaVzQ2Q1dqQjA2SDJacjJWdVZKZHF3V0Vr?= =?utf-8?B?dlp0bEU2MHU4Ujh3Tm1ucWY3dFhCMENSVFJzdGFObXlCdEtYbG5xaVhmRzJl?= =?utf-8?B?U0Zwa3p6QWwvYW1yOEovL2kza05Ha1M1S0ZodEw3REFxUTRwcUhFZk95elZU?= =?utf-8?B?dnljNHFRcmJaaW9YM1VBZytUNFlDcC9ybG9aNXFQVlN5NEhiWnZVOFRLSERi?= =?utf-8?B?OWFIekdxc3JqWWZhUmFFUTdWOU5QcEZoTml6SzNobTl6aFlxKzkwMzlDTHZR?= =?utf-8?B?NStQNFJZQVczWlZubCtoQUpWVkdiWCsyK1NsT1V0UFBmdllTbXpnUjVlWXF4?= =?utf-8?B?dDBwQ2tVMEx6VjV0MmMvczc1YWEvdXV4Slk3U0hnMmowUEliSjhpYitnOFcz?= =?utf-8?B?YUtETWlmUkY5SnNJYWMrK0pHeVltSUEzUU45c0NsZXR4ZTBTRElObWdwU1lo?= =?utf-8?B?aHh4NlZyMU9tbGRiWkFraDRNUXRxQnNBTWNpTWhtVU4veVo0VlVPZUZ5UUNv?= =?utf-8?B?R0NvckdhWVVFcTJONjh4bkJEZFhBTDRwQVdKbERMSzZQRjFpRXd1L2UyMm1w?= =?utf-8?B?bUJZUHp0aWZwZXFJNXZ4bTFTOFhQZVlxZ3JGQ0lqZmdEbGhsWjdxR0RNNkps?= =?utf-8?B?aHlNTXlBdUlWVkF4UGo3K1dXWDBscXpYMFVoZVBSRTllVUFyamYvdVI4cVZi?= =?utf-8?B?K0RVOVpFZ2twMzd4eHVUVjhmTG1PSlpPVXp6bDlkTkhhcUxWaGs1RUgwTFlJ?= =?utf-8?B?bnZCUVBudFpabElJS1dmMUtXR0xmVmtuanVNK2l0dllXOVlQcDE2UitubTdo?= =?utf-8?B?Nlo2anVmU2M1YUZGd0dMU1dDOGp6SFdnWFVvcDMwWHpmaGpEbXp2MEhtSWN0?= =?utf-8?B?VXl3L3lZck9wZ0dLUHVvMXY4UjZrVlpOR1AwMTFLdVNNMW01T2hrL1BnS3Vt?= =?utf-8?B?R0lTQTFsRGpwTFRGRDlFcXhZNWNFWjNvQUhYQk4zR1FrMXdZUUtSWi96VnVO?= =?utf-8?B?d2NwUG1GMlAyTDFVMTV2UFpTT0JWamJWd21QUWJkbGRuRFV6Y091V1lRZzFL?= =?utf-8?B?ME40VGlPdWR1YmhrQVZ5L0d6M0lRcmNXM1FVODgvVXdZbTlPbnpvblBLQmpp?= =?utf-8?B?NHNvL1dQa2drUjJudmljSFNUMjlNUmN2bTRWTXF3ZEdTcFg1UVNJRFVDNEs4?= =?utf-8?Q?+m4uozvymhO6Zo5g1YF26UXobn/d+ypmdiEIxor?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM4PR11MB54380C92315B0321CE94BBECB5189DM4PR11MB5438namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e84626c3-5250-4b83-1fbd-08d942baf03f X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2021 09:21:31.0908 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8svL8VPT9O/T6e8q2qdahJvo8nJPy5dsqjpnmc/DSl2sFzk9/qmRF+JdKZPC149qSmBxBpA9B2VHXNGOJYtcVw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3019 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xbe-aln-005.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 09:21:47 -0000 --_000_DM4PR11MB54380C92315B0321CE94BBECB5189DM4PR11MB5438namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KWWVzLCB0aGUgaW50ZW50aW9uIGlzIHRoYXQgdGhlIFlBTkcgcGFja2FnZXMg d29yayBjb3ZlcnMgZXhhY3RseSB0aGUgdXNlIGNhc2UgdGhhdCB5b3UgZGVzY3JpYmUgYmVsb3cu DQoNClJlZ2FyZGluZyB1c2luZyBKU09OLCBteSBleHBlY3RhdGlvbiBpcyB0aGF0IHRoZSBwYWNr YWdlIHdvdWxkIGdldCBjb25zdW1lZCBieSB0b29scyBhcyBZQU5HIGluc3RhbmNlIGRhdGEgKGku ZS4sIHNpbWlsYXIgdG8gaG93IHlhbmcgbGlicmFyeSBkYXRhIGlzIGZldGNoZWQgZnJvbSBhIHJ1 bm5pbmcgc2VydmVyKS4NCg0KSSB3b3VsZCB0aGluayB0aGF0IGV4dHJhIG1ldGFkYXRhIGluIHRo ZSBwYWNrYWdlIGRlZmluaXRpb24gY291bGQgYmUgZXhwcmVzc2VkIHVzaW5nIHJlZ3VsYXIgWUFO RyBhdWdtZW50YXRpb25zLg0KDQpFLmcuLCB0aGUgc2ltcGxpZmllZC1pbmxpbmUgc2NoZW1hIGZv ciB0aGUgaW5zdGFuY2UgZGF0YSBmaWxlIGNvbnRhaW5pbmcgdGhlIGRlZmluaXRpb24gb2YgYSBz cGVjaWZpYyBZQU5HIHBhY2thZ2UgaW5zdGFuY2UgY291bGQgYmUgc29tZXRoaW5nIGxpa2U6DQo8 bW9kdWxlPklldGYteWFuZy1wYWNrYWdlc0AuLi48L21vZHVsZTxtYWlsdG86SWV0Zi15YW5nLXBh Y2thZ2VzQC4uLiUzYy9tb2R1bGU+Pg0KPG1vZHVsZT5mb28teWFuZy1wa2ctYXVnbWVudGF0aW9u c0AuLi48L21vZHVsZTxtYWlsdG86Zm9vLXlhbmctcGtnLWF1Z21lbnRhdGlvbnNALi4uJTNjL21v ZHVsZT4+DQo8Y29udGVudC1kYXRhPg0KLy8gQ29udGVudCBkYXRhIGNvbnRhaW5zIGJhc2UgcGFj a2FnZSBpbmZvcm1hdGlvbiBhbmQgZXh0cmEgZGF0YSB0aGF0IGNvbmZvcm1zIHRvIHRoZSBhZGRp dGlvbmFsIHNjaGVtYSBlbGVtZW50cyBkZWZpbmVkIGJ5IGZvbyBhdWdtZW50YXRpb25zLg0KPC9j b250ZW50LWRhdGE+DQoNCknigJl2ZSBub3QgdGhvdWdodCBhYm91dCBpdCwgYnV0IHBlcmhhcHMg WUFORyBtZXRhZGF0YSBhbm5vdGF0aW9ucyB3b3VsZCBhbHNvIHdvcmsgKFJGQyA3OTUyKS4NCg0K UmVnYXJkcywNClJvYg0KDQoNCkZyb206IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29t Pg0KU2VudDogMDggSnVseSAyMDIxIDIxOjM4DQpUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3 aWx0b25AY2lzY28uY29tPg0KQ2M6IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVs ZGVyQGphY29icy11bml2ZXJzaXR5LmRlPjsgQmFsw6F6cyBMZW5neWVsIDxiYWxhenMubGVuZ3ll bEBlcmljc3Nvbi5jb20+OyBuZXRtb2RAaWV0Zi5vcmc7IEJlbm9pdCBDbGFpc2UgPGJlbm9pdC5j bGFpc2VAaHVhd2VpLmNvbT4NClN1YmplY3Q6IFJlOiBBRCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1u ZXRtb2QteWFuZy1pbnN0YW5jZS1maWxlLWZvcm1hdA0KDQoNCg0KT24gVGh1LCBKdWwgOCwgMjAy MSBhdCAzOjU4IEFNIFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbTxtYWls dG86cndpbHRvbkBjaXNjby5jb20+PiB3cm90ZToNCkhpIEp1ZXJnZW4sDQoNCkkgYmVsaWV2ZSB0 aGF0IGhhdmluZyB0aGUgc2ltcGxlIGZvcm0gaXMgd29ydGggdGhlIGV4dHJhIGNvbXBsZXhpdHku DQoNCkkgdGhpbmsgdGhhdCB5b3UgYXJlIHJpZ2h0IHRvIGJlIGNvbmNlcm5lZCB0aGF0IGl0IHNo b3VsZCBub3QgZXhwYW5kIGludG8gYSBzZXBhcmF0ZSBwYXJhbGxlbCBmb3JtYXQuICBPdmVydGlt ZSwgSSB3b3VsZCBsaWtlIHRoZSBzaW1wbGUgZm9ybSB0byBiZSBhYmxlIHRvIHVzZSByZXZpc2lv biBsYWJlbHMgaW5zdGVhZCBvZiByZXZpc2lvbiBkYXRlcywgYnV0IGJleW9uZCB0aGlzIEkgdGhp bmsgdGhhdCBpdCBzaG91bGQganVzdCBiZSBhIGZsYXQgbGlzdCBvZiBtb2R1bGVzIHRoYXQgZGVm aW5lcyB0aGUgc2NoZW1hLiAgSWYgYSBzdWJzZXQgb2YgZmVhdHVyZXMsIG9yIGRhdGFzdG9yZXMs IG9yIGltcG9ydC1vbmx5IG1vZHVsZXMgYXJlIG5lZWRlZCB0aGVuIHRoZSBZQU5HIGxpYnJhcnkg dmVyc2lvbiAob3IgVVJJcykgY2FuIGFuZCBzaG91bGQgYmUgdXNlZC4NCg0KQW5vdGhlciBleGFt cGxlIG9mIHdoZXJlIEkgZXhwZWN0IGl0IHRvIGJlIHVzZWZ1bCBpcyBpbiBZQU5HIHBhY2thZ2Vz LiAgTG9va2luZyBhdCB0aGUgZXhhbXBsZXMgYXQgdGhlIGVuZCBvZiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXlhbmctcGFja2FnZXMsIHRo ZW4gc29tZSBvZiB0aG9zZSBmaWxlcyAod2hpY2ggY3VycmVudGx5IGFyZW4ndCBkZWZpbmluZyBh bnkgc2NoZW1hLCBidXQgc2hvdWxkKSB3b3VsZCBhbG1vc3QgZG91YmxlIGluIHNpemUgaWYgdGhl eSByZXByZXNlbnRlZCB0aGUgc2NoZW1hIGlubGluZSB1c2luZyBZQU5HIGxpYnJhcnksIHdoaWNo IEkgdGhpbmsgd291bGQgbWFrZSB0aGUgZmlsZXMgaGFyZGVyIGZvciBodW1hbnMgdG8gcmVhZC9w YXJzZS4gIFVzaW5nIFVSSXMgY291bGQgaGVscCBtaXRpZ2F0ZSB0aGlzLCBidXQgdGhlbiB3ZSB3 b3VsZCBuZWVkIHRvIGZpbmQgYSBwbGFjZSB0byBwdWJsaXNoIHRoZSBmaWxlIGNvbnRhaW5pbmcg dGhlIFlBTkcgcGFja2FnZSBzY2hlbWEgKHByZXN1bWFibHkgc29tZXdoZXJlIGluIElBTkEpLCBh bmQgaXQgbm90IG9idmlvdXMgdG8gbWUgdGhhdCBhZGRpbmcgdGhlIGRlcGVuZGVuY3kgb24gdGhl IFVSTCBpcyByZWFsbHkgYXMgaGVscGZ1bC4NCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1iaWVybWFuLW5ldG1vZC15YW5nLWNvbmZvcm1hbmNlLTAwDQoNCkFu IG9yaWdpbmFsIHVzZS1jYXNlIGluIG15IDIwMTMgZHJhZnQgd2FzIHRvIGFsbG93IGEgdmVuZG9y IHRvIGRlZmluZSBhIHBhY2thZ2UNCnRoYXQgcmVwcmVzZW50ZWQgdGhlIGVudGlyZSBzZXJ2ZXIu IFRoZW4gdGhlIGVudGlyZSA8aGVsbG8+IGFuZCBZQU5HIGxpYnJhcnkgY2FuDQpiZSByZXBsYWNl ZCBieSBvbmUgcGFja2FnZS1pZCBpbiB0aGlzIGNhc2UuIFRoaXMgaXMgcmVhc29uYWJsZSBmb3Ig ZW1iZWRkZWQgZGV2aWNlcw0KdGhhdCBoYXZlIGEgZml4ZWQgWUFORyBsaWJyYXJ5IChleHBlY3Rl ZCBmb3IgQ09SRUNPTkYpLg0KDQpCVFcsIHRoZSBtYWluIHJlYXNvbiBJIHByb3Bvc2VkIHRoZSBZ QU5HIHN5bnRheCAoeW91ciB2ZXJzaW9uIGhhcyBhIEpTT04gZG9jdW1lbnQpDQppcyB0aGF0IHRo ZXNlIGZpbGVzIGFyZSBuZWVkZWQgYnkgYXV0b21hdGlvbiB0b29scywgYW5kIFlBTkcgYWxsb3dz IGV4dGVuc2lvbnMNCihhbmQgb3RoZXIgdGhpbmdzIGxpa2UgYXVnbWVudCkuIEF1dG9tYXRpb24g dG9vbHMgY2Fubm90IHdvcmsgd2l0aG91dCBleHRlbnNpb25zDQpzbyBub3Qgc3VyZSBob3cgSlNP TiBwYWNrYWdlIGZpbGVzIHdpbGwgYmUgdXNlZnVsIHRvIHRoZW0uDQoNCg0KUmVnYXJkcywNClJv Yg0KDQpBbmR5DQoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEp1 ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRl PG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+Pg0KPiBTZW50OiAw OCBKdWx5IDIwMjEgMTE6MzUNCj4gVG86IEJhbMOhenMgTGVuZ3llbCA8YmFsYXpzLmxlbmd5ZWxA ZXJpY3Nzb24uY29tPG1haWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20+Pg0KPiBDYzog QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNv bT4+OyBSb2IgV2lsdG9uIChyd2lsdG9uKQ0KPiA8cndpbHRvbkBjaXNjby5jb208bWFpbHRvOnJ3 aWx0b25AY2lzY28uY29tPj47IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3Jn PjsgQmVub2l0IENsYWlzZQ0KPiA8YmVub2l0LmNsYWlzZUBodWF3ZWkuY29tPG1haWx0bzpiZW5v aXQuY2xhaXNlQGh1YXdlaS5jb20+Pg0KPiBTdWJqZWN0OiBSZTogQUQgcmV2aWV3IG9mIGRyYWZ0 LWlldGYtbmV0bW9kLXlhbmctaW5zdGFuY2UtZmlsZS1mb3JtYXQNCj4NCj4gVGhlIHF1ZXN0aW9u IEkgYXNrZWQgaXMgImhvdyBtdWNoIHNpbXBsZXIgaXMgaXQgYW5kIGRvZXMgdGhhdCBzYXZpbmcN Cj4ganVzdGlmeSB0aGUgaW50cm9kdWN0aW9uIG9mIGEgbmV3IHJhdGhlciBsaW1pdGVkIGZvcm1h dCAodGhhdCBtYXkgcmlzaw0KPiB0byBncm93IG92ZXIgdGltZSBhbmQgYmVjb21lIGEgc2Vjb25k IGNpdGl6ZW4pIi4NCj4NCj4gU28gbGV0cyB0YWtlIHlvdXIgTkFDTSBleGFtcGxlLiBpZXRmLW5l dGNvbmYtYWNtQDIwMTgtMDItMTQgaW1wb3J0cw0KPiBmcm9tIGlldGYteWFuZy10eXBlcyAoYXQg dGhlIHRpbWUgb2YgcHVibGljYXRpb24gdGhhdCByZXNvbHZlcyB0bw0KPiBpZXRmLXlhbmctdHlw ZXNAMjAxMy0wNy0xNS4gU28gdGhlIFlBTkcgTGlicmFyeSBpbnN0YW5jZSBkYXRhIHdvdWxkDQo+ IHJvdWdobHkgbG9vayB0aGlzIChwbGVhc2UgY29ycmVjdCB3aGF0IEkgbWVzc2VkIHVwLCBJIGFt IHdyaXRpbmcgdGhpcw0KPiBieSBoYW5kKToNCj4NCj4gPHlhbmctbGlicmFyeT4NCj4gICA8bW9k dWxlLXNldD4NCj4gICAgIDxuYW1lPm08L25hbWU+DQo+ICAgICA8bW9kdWxlPg0KPiAgICAgICA8 bmFtZT5pZXRmLW5ldGNvbmYtYWNtPC9uYW1lPg0KPiAgICAgICA8cmV2aXNpb24+MjAxOC0wMi0x NDwvcmV2aXNpb24+DQo+ICAgICAgIDxuYW1lc3BhY2U+dXJpMTwvbmFtZXNwYWNlPg0KPiAgICAg PC9tb2R1bGU+DQo+ICAgICA8aW1wb3J0LW9ubHktbW9kdWxlPg0KPiAgICAgICA8bmFtZT5pZXRm LXlhbmctdHlwZXM8L25hbWU+DQo+ICAgICAgIDxuYW1lc3BhY2U+dXJpMjwvbmFtZXNwYWNlPg0K PiAgICAgICA8cmV2aXNpb24vPg0KPiAgICAgPC9pbXBvcnQtb25seS1tb2R1bGU+DQo+ICAgPC9t b2R1bGUtc2V0Pg0KPiAgIDxzY2hlbWE+DQo+ICAgICA8bmFtZT5zPC9uYW1lPg0KPiAgICAgPG1v ZHVsZS1zZXQ+bTwvbW9kdWxlLXNldD4NCj4gICA8L3NjaGVtYT4NCj4gICA8ZGF0YXN0b3JlPg0K PiAgICAgPG5hbWU+cnVubmluZzwvbmFtZT4NCj4gICAgIDxzY2hlbWE+czwvc2NoZW1hPg0KPiAg IDwvZGF0YXN0b3JlPg0KPiA8L3lhbmctbGlicmFyeT4NCj4NCj4gWWVzLCB0aGlzIGlzIGEgYml0 IGxvbmdlciwgYnV0IGl0IGFsc28gY29udmV5cyBtb3JlIGluZm9ybWF0aW9uIChub3RlDQo+IHRo YXQgeW91ciBkYXRhc3RvcmUgbGVhZiBpbiB0aGUgaGVhZGVyIHdvdWxkIGxpa2VseSBub3QgYmUg bmVlZGVkDQo+IGFueW1vcmUpLg0KPg0KPiBJIGFtIGNvbmNlcm5lZCB0aGF0IHdlIHN0YXJ0IGNy ZWF0aW5nIGFub3RoZXIgZm9ybWF0IHRvIGRlZmluZSBzY2hlbWFzDQo+IHRoYXQgaXMgdmVyeSBs aW1pdGVkIGFuZCBwZW9wbGUgbGF0ZXIgY29tZSB3aXRoIGV4dGVuc2lvbiBwcm9wb3NhbHMgdG8N Cj4gYWRkcmVzcyBzb21lIG9mIHRoZSBsaW1pdHMgYW5kIGF0IHRoZSBlbmQgd2UgaGF2ZSBtdWx0 aXBsZSBmb3JtYXRzIHRvDQo+IG1haW50YWluIGFuZCBkZWFsIHdpdGguIFNvIHRoZSBxdWVzdGlv biBpcyB3aGV0aGVyIHBlb3BsZSB0aGluayB0aGlzDQo+IGlzIHdvcnRoIGl0LiAoTm90ZSB0aGF0 IHRoZSBmZWx0IG92ZXJoZWFkIGdvZXMgZG93biB3aXRoIGV2ZXJ5DQo+IGFkZGl0aW9uYWwgbW9k dWxlIHVzZWQgYnkgeW91ciBpbnN0YW5jZSBmaWxlLCBzbyB0aGUgZXhhbXBsZSBhYm92ZSBpcw0K PiByZWFsbHkgdGhlIG1vc3QgZXh0cmVtZSBjYXNlLiBBbmQgaWYgeW91IGhhdmUgbWFueSBtb2R1 bGVzIGRlZmluaW5nDQo+IE5BQ00gcnVsZXMsIHRoZW4geW91IHB1dCB0aGUgYWJvdmUgaW50byBh IHNlcGFyYXRlIGZpbGUgYW5kIHVzZSB0aGUNCj4gVVJJIHRvIHBvaW50IHRvIHRoZSBzY2hlbWEs IG5vPw0KPg0KPiAvanMNCj4NCj4gT24gVGh1LCBKdWwgMDgsIDIwMjEgYXQgMDk6Mjc6NTJBTSAr MDAwMCwgQmFsw6F6cyBMZW5neWVsIHdyb3RlOg0KPiA+IEhlbGxvIEp1cmdlbiwNCj4gPiBJbmxp bmU6DQo+ID4gVGhpcyBjb21wbGV4IGZvcm0gb2YgaW5saW5lIHdhcyByZXF1ZXN0ZWQgYW5kIG5v dCBvYmplY3RlZCBlYXJsaWVyIGJ5DQo+IG90aGVyDQo+ID4gcmV2aWV3ZXJzLg0KPiA+IEJhc2Vk IG9uIFJvYidzIGFuZCBvdGhlcnMnIHByb3Bvc2FsIGlubGluZSB3aWxsIGJlIHNpbXBsaWZpZWQg dG8gdXNlIG9ubHkNCj4gPiBpZXRmLXlhbmctbGlicmFyeUAyMDE5LTAxLTA0IGFzIHlvdSBzdWdn ZXN0Lg0KPiA+DQo+ID4gU2ltcGxpZmllZCBpbmxpbmU6DQo+ID4gSW4gRXJpY3Nzb24gd2UgYWxy ZWFkeSB1c2Ugc2ltcGxpZmllZCBpbmxpbmUgYSBsb3QsIGl0IGlzIHRoZSBtb3N0IGNvbW1vbg0K PiA+IGZvcm1hdC4NCj4gPiBJZiB5b3UgYXJlIHByb3ZpZGluZyBkYXRhIG9ubHkgZm9yIG9uZSBv ciBhIGZldyBZQU5HIG1vZHVsZXMgYW5kIGRvbid0DQo+IGhhdmUsDQo+ID4NCj4gPiBkb24ndCBj YXJlIGFib3V0IGZlYXR1cmVzL2RldmlhdGlvbnMgaXQgaXMgdGhlIGVhc2llc3QsIHNob3J0ZXN0 IG1ldGhvZCB0bw0KPiA+IHVzZS4NCj4gPiAgT3VyIG1vc3QgY29tbW9uIHVzZS1jYXNlIGlzIHRv IHByb3ZpZGUgcHJlY29uZmlndXJlZCBhY2Nlc3MgY29udHJvbA0KPiBydWxlcw0KPiA+IGZvciBu ZXcgbm9kZXMuDQo+ID4gV2hlbiBhIFlBTkcgbW9kZWxlciBkZXNpZ25zIGEgbmV3IG1vZHVsZSwg aGUgaW1tZWRpYXRlbHkgcHJvdmlkZXMgYQ0KPiBzZXQgb2YNCj4gPiBOQUNNIHJ1bGVzDQo+ID4g Zm9yIHRoZSByZWFkT25seSBhbmQgdGhlIFN5c3RlbUFkbWluIHJvbGVzL2dyb3Vwcy4NCj4gPiBJ biB0aGlzIGNhc2UgeW91IG9ubHkgbmVlZCB0byBzcGVjaWZ5ICJpZXRmLW5lY29uZi1hY21AMjAx Mi0wMi0yMiIgTm8NCj4gPiBkZXZpYXRpb25zLCBubyBmZWF0dXJlcyB0byBpbmRpY2F0ZS4NCj4g PiBSZWdhcmRzIEJhbGF6cw0KPiA+DQo+ID4gUmVnYXJkcyBCYWxhenMNCj4gPg0KPiA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxq LnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRl ckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4+DQo+ID4gU2VudDogMjAyMS4gasO6bGl1cyA3Liwgc3pl cmRhIDIxOjI2DQo+ID4gVG86IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0 bzphbmR5QHl1bWF3b3Jrcy5jb20+Pg0KPiA+IENjOiBCYWzDoXpzIExlbmd5ZWwgPGJhbGF6cy5s ZW5neWVsQGVyaWNzc29uLmNvbTxtYWlsdG86YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPj47 IFJvYiBXaWx0b24gKHJ3aWx0b24pDQo+ID4gPHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2ls dG9uQGNpc2NvLmNvbT4+OyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz47 IEJlbm9pdCBDbGFpc2UNCj4gPiA8YmVub2l0LmNsYWlzZUBodWF3ZWkuY29tPG1haWx0bzpiZW5v aXQuY2xhaXNlQGh1YXdlaS5jb20+Pg0KPiA+IFN1YmplY3Q6IFJlOiBBRCByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1uZXRtb2QteWFuZy1pbnN0YW5jZS1maWxlLWZvcm1hdA0KPiA+DQo+ID4gT24gV2Vk LCBKdWwgMDcsIDIwMjEgYXQgMTE6MTI6MDZBTSAtMDcwMCwgQW5keSBCaWVybWFuIHdyb3RlOg0K PiA+ID4NCj4gPiA+ID4gSW5saW5lIG1ldGhvZCBpcyBuZWVkZWQsIGlmIHlvdSB3YW50IHRvIGlu ZGljYXRlIHRoYXQgdGhlIGZpbGUgd2FzDQo+ID4gPiA+IGdlbmVyYXRlZCBieSBzb21lb25lIHdo byB1c2VzIHNvbWUgWUFORyBtb2R1bGVzIHdpdGggZGV2aWF0aW9ucw0KPiBhbmQNCj4gPiA+ID4g c29tZSBmZWF0dXJlcyBhcmUgbm90LXN1cHBvcnRlZC4gVGhlcmUgaXMgbm8gd2F5IHRvIGluZGlj YXRlDQo+ID4gPiA+IGZlYXR1cmUtc3VwcG9ydCBhbmQgZGV2aWF0aW9ucyB3aXRoIHRoZSBzaW1w bGlmaWVkLWlubGluZSBtZXRob2QuDQo+ID4gPg0KPiA+ID4gVGhlIElubGluZSBhbnlkYXRhIHNv bHV0aW9uIGlzIHZlcnkgaGVhdnl3ZWlnaHQuDQo+ID4gPiBCZWZvcmUgdGhlIFlBTkcgbGlicmFy eSB0aGVyZSB3YXMgYSBzaW1wbGUgVVJJIHRoYXQgaXMgZWFzaWVyIHRvIHVzZQ0KPiA+ID4gYW5k IHRha2VzIHVwIG11Y2ggbGVzcyBzdG9yYWdlLg0KPiA+ID4NCj4gPg0KPiA+IFRoZSBpbmxpbmUg Y29udGVudCBzY2hlbWEgaXMgc3VwZXIgZ2VuZXJpYyBzaW5jZSBpdCBzdXBwb3J0cyBhbiBvcGVu IGVuZGVkDQo+ID4gc2V0IG9mIHNjaGVtYSBkZWZpbmluZyBtb2R1bGVzLiBXaGlsZSB5b3UgY2Fu IHVzZSBpdCB3aXRoIHNheQ0KPiA+IGlldGYteWFuZy1saWJyYXJ5QDIwMTktMDEtMDQsIHlvdSBj YW4gdXNlIGFueXRoaW5nIGVsc2UgYXMgd2VsbC4gSW4gb3RoZXINCj4gPiB3b3JkcywgdHdvIGlt cGxlbWVudGF0aW9ucyBzdXBwb3J0aW5nIGlubGluZSBjb250ZW50IHNjaGVtYSBtYXkgbm90DQo+ ID4gaW50ZXJvcGVyYXRlLiBJIGRvIG5vdCB0aGluayB0aGVyZSBpcyBhIHNjaGVtYSBmb3JtYXQg dGhhdCBpcyBtYW5kYXRvcnkgdG8NCj4gPiBpbXBsZW1lbnQgZm9yIGlubGluZSBjb250ZW50IHNj aGVtYS4NCj4gPg0KPiA+IFNvIGhlcmUgaXMgbXkgYXNzZXNzbWVudCBvZiB3aGF0IHdlIGhhdmUg aW4gdGVybXMgb2YgaW50ZXJvcGVyYWJpbGl0eToNCj4gPg0KPiA+IC0gU2ltcGxpZmllZC1Jbmxp bmUgY29tZXMgd2l0aCBub3RhYmxlIHJlc3RyaWN0aW9ucywgaW50ZXJvcGVyYWJsZQ0KPiA+IC0g SW5saW5lIGlzIGFuIG9wZW4gZW5kZWQgY29udGVudCBzY2hlbWEsIG5vdCBuZWNlc3NhcmlseSBp bnRlcm9wZXJhYmxlDQo+ID4gLSBVUkkgbWV0aG9kIHB1c2hlcyB0aGUgcHJvYmxlbSB0byBhbm90 aGVyIGluc3RhbmNlIGZpbGUsIGludGVyb3BlcmFibGUNCj4gPiAtIEV4dGVybmFsIGlzIGJ5IGRl c2luZyBub3QgaW50ZXJvcGVyYWJsZQ0KPiA+DQo+ID4gT24gdGhlIHNlcnZlciBzaWRlLCB3ZSBo YXZlIFlBTkcgTGlicmFyeS4gUGVyaGFwcyBSRkMgODUyNSBoYXMgc29tZQ0KPiA+IGNvbXBsZXhp dHkgdGhhdCBpcyB1c2VmdWwgZm9yIHN1cHBvcnRpbmcgbGFyZ2Ugc2VydmVycyB3aXRoIG11bHRp cGxlDQo+ID4gZGF0YXN0b3JlcyBhbmQgbm90IG5lZWRlZCBmb3Igc21hbGwgaW5zdGFuY2UgZmls ZXMgKEkgdW5kZXJzdGFuZCB0aGF0IGFuDQo+ID4gaW5zdGFuY2UgZmlsZSBpcyBhbHdheXMgdGll ZCB0byBhIHNpbmdsZSBkYXRhc3RvcmU/KS4NCj4gPg0KPiA+IFRvIG1lLCBpdCBmZWVscyB0aGF0 IHJldXNpbmcgUkZDIDg1MjUgZGVzaWduIGlzIGFjdHVhbGx5IGEgZ29vZCB0aGluZy4gQmVpbmcN Cj4gPiBhYmxlIHRvIGR1bXAgYSBsaXZlIHNlcnZlciBkYXRhc3RvcmUgaW50byBhbiBpbnN0YW5j ZSBmaWxlIHNlZW1zIGxpa2UgYSB2ZXJ5DQo+ID4gdmFsaWQgdXNlIGNhc2UgdG8gbWUgYW5kIGlk ZWFsbHkgdGhpcyBpcyBwb3NzaWJsZSB3aXRob3V0IGhhdmluZyB0byByZXdyaXRlDQo+ID4gdGhl IHNjaGVtYSBwYXJ0LiBXZWxsLCB5b3UgY291bGQgZ28gYW5kIHRyaW0gdW51c2VkIGRhdGFzdG9y ZSBzY2hlbWFzDQo+IGFuZA0KPiA+IGZyb20gdGhlcmUgdW51c2VkIG1vZHVsZSBzZXRzIGV0YyBi dXQgdGhhdCBjYW4gYWxsIGJlIGRvbmUgYnkgYW4gZXh0ZXJuYWwNCj4gPiB0b29sIHRyaW1taW5n IHRoZSBzY2hlbWEgcGFydCwgaS5lLiwgaXQgZG9lcyBub3QgbmVlZCB0byBiZSBkb25lIGJ5IGEg dG9vbA0KPiA+IHRoYXQganVzdCBkdW1wcyBhIHNlcnZlciBkYXRhc3RvcmUuDQo+ID4NCj4gPiBX aGF0IGlzIHRoZSBhY3R1YWwgdmFsdWUgb2Ygc2ltcGxpZmllZCBpbmxpbmU/IEhvdyBtdWNoIGRv IHlvdSByZWFsbHkgc2F2ZQ0KPiA+IGNvbXBhcmVkIHRvIHRoZSBzaW1wbGVzdCBlcXVpdmFsZW50 IFJGQyA4NTI1IHJlcHJlc2VudGF0aW9uPyBBbmQgZG9lcw0KPiB0aGF0DQo+ID4gc2F2aW5nIGp1 c3RpZnkgdG8gc3RhcnQgZW5naW5lZXJpbmcgYW5vdGhlciBzY2hlbWEgc3BlY2lmaWNhdGlvbiBm b3JtYXQ/DQo+ID4NCj4gPiBJIGd1ZXNzIG15IGNob2ljZSB3b3VsZCBoYXZlIGJlZW4gdG8ganVz dCBoYXZlDQo+ID4NCj4gPiAgICAgICAgKy0tIGNvbnRlbnQtc2NoZW1hDQo+ID4gICAgICAgIHwg ICstLSAoY29udGVudC1zY2hlbWEtc3BlYyk/DQo+ID4gICAgICAgIHwgICAgICstLTogKHlhbmct bGlicmFyeSkNCj4gPiAgICAgICAgfCAgICAgKy0tOiAodXJpKQ0KPiA+DQo+ID4gYnV0IG90aGVy cyBvYnZpb3VzbHkgd2FudCBtdWNoIG1vcmUgY2hvaWNlIChidXQgbGV0cyBub3RlIHRoYXQgZXZl cnl0aGluZw0KPiA+IHNpdHMgaW4gYSBjaG9pY2UsIHNvIGV2ZXJ5dGhpbmcgaXMgZXh0ZW5zaWJs ZSBpbiBjYXNlIG90aGVyIHNjaGVtYQ0KPiA+IGRlZmluaXRpb24gZm9ybWF0cyBhcmUgb3V0IHRo ZXJlKS4NCj4gPg0KPiA+IC9qcw0KPiA+DQo+ID4gLS0NCj4gPiBKdWVyZ2VuIFNjaG9lbndhZWxk ZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiA+IFBob25lOiAr NDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdl cm1hbnkNCj4gPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMw0KPiA+IDxodHRwczovL3Byb3RlY3Qy LmZpcmVleWUuY29tL3YxL3VybD9rPWZlODVjOGU2LWExMWVmMWNkLWZlODU4ODdkLQ0KPiA4NjYw Mzg5NzNhDQo+ID4gMTUtMTllNWRhZDM3NWFmMDA2MyZxPTEmZT0zNjM3NDA2ZC1mNzc0LTQwNzMt ODBlZS0NCj4gYTc0MzExMTFlOWJjJnU9aHR0cHMlM0ElMkYNCj4gPiAlMkZ3d3cuamFjb2JzLXVu aXZlcnNpdHkuZGU8aHR0cDovLzJGd3d3LmphY29icy11bml2ZXJzaXR5LmRlPiUyRj4NCj4NCj4N Cj4NCj4gLS0NCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVy c2l0eSBCcmVtZW4gZ0dtYkgNCj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1w dXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPiBGYXg6ICAgKzQ5IDQyMSAyMDAg MzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo= --_000_DM4PR11MB54380C92315B0321CE94BBECB5189DM4PR11MB5438namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdy YXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBBbmR5 LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5ZZXMsIHRoZSBpbnRlbnRpb24gaXMgdGhhdCB0aGUgWUFORyBwYWNrYWdlcyB3b3Jr IGNvdmVycyBleGFjdGx5IHRoZSB1c2UgY2FzZSB0aGF0IHlvdSBkZXNjcmliZSBiZWxvdy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+UmVnYXJkaW5nIHVzaW5nIEpTT04sIG15IGV4cGVjdGF0aW9uIGlzIHRoYXQgdGhlIHBhY2th Z2Ugd291bGQgZ2V0IGNvbnN1bWVkIGJ5IHRvb2xzIGFzIFlBTkcgaW5zdGFuY2UgZGF0YSAoaS5l Liwgc2ltaWxhciB0byBob3cgeWFuZyBsaWJyYXJ5IGRhdGEgaXMgZmV0Y2hlZCBmcm9tIGEgcnVu bmluZyBzZXJ2ZXIpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5JIHdvdWxkIHRoaW5rIHRoYXQgZXh0cmEgbWV0YWRhdGEgaW4g dGhlIHBhY2thZ2UgZGVmaW5pdGlvbiBjb3VsZCBiZSBleHByZXNzZWQgdXNpbmcgcmVndWxhciBZ QU5HIGF1Z21lbnRhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkUuZy4sIHRoZSBzaW1wbGlmaWVkLWlubGluZSBzY2hl bWEgZm9yIHRoZSBpbnN0YW5jZSBkYXRhIGZpbGUgY29udGFpbmluZyB0aGUgZGVmaW5pdGlvbiBv ZiBhIHNwZWNpZmljIFlBTkcgcGFja2FnZSBpbnN0YW5jZSBjb3VsZCBiZSBzb21ldGhpbmcgbGlr ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZsdDttb2R1bGUmZ3Q7PGEgaHJlZj0ibWFp bHRvOklldGYteWFuZy1wYWNrYWdlc0AuLi4lM2MvbW9kdWxlIj5JZXRmLXlhbmctcGFja2FnZXNA Li4uJmx0Oy9tb2R1bGU8L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jmx0O21v ZHVsZSZndDs8YSBocmVmPSJtYWlsdG86Zm9vLXlhbmctcGtnLWF1Z21lbnRhdGlvbnNALi4uJTNj L21vZHVsZSI+Zm9vLXlhbmctcGtnLWF1Z21lbnRhdGlvbnNALi4uJmx0Oy9tb2R1bGU8L2E+Jmd0 OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jmx0O2NvbnRlbnQtZGF0YSZndDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi8vIENvbnRlbnQgZGF0YSBjb250YWlucyBiYXNlIHBhY2th Z2UgaW5mb3JtYXRpb24gYW5kIGV4dHJhIGRhdGEgdGhhdCBjb25mb3JtcyB0byB0aGUgYWRkaXRp b25hbCBzY2hlbWEgZWxlbWVudHMgZGVmaW5lZCBieSBmb28gYXVnbWVudGF0aW9ucy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZsdDsvY29udGVudC1kYXRhJmd0OzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5J4oCZdmUg bm90IHRob3VnaHQgYWJvdXQgaXQsIGJ1dCBwZXJoYXBzIFlBTkcgbWV0YWRhdGEgYW5ub3RhdGlv bnMgd291bGQgYWxzbyB3b3JrIChSRkMgNzk1MikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5Sb2I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gQW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5j b20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMDggSnVseSAyMDIxIDIxOjM4PGJyPg0KPGI+VG86 PC9iPiBSb2IgV2lsdG9uIChyd2lsdG9uKSAmbHQ7cndpbHRvbkBjaXNjby5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNv YnMtdW5pdmVyc2l0eS5kZSZndDs7IEJhbMOhenMgTGVuZ3llbCAmbHQ7YmFsYXpzLmxlbmd5ZWxA ZXJpY3Nzb24uY29tJmd0OzsgbmV0bW9kQGlldGYub3JnOyBCZW5vaXQgQ2xhaXNlICZsdDtiZW5v aXQuY2xhaXNlQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBBRCByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy1pbnN0YW5jZS1maWxlLWZvcm1hdDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUs IEp1bCA4LCAyMDIxIGF0IDM6NTggQU0gUm9iIFdpbHRvbiAocndpbHRvbikgJmx0OzxhIGhyZWY9 Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgSnVlcmdlbiw8YnI+DQo8YnI+DQpJ IGJlbGlldmUgdGhhdCBoYXZpbmcgdGhlIHNpbXBsZSBmb3JtIGlzIHdvcnRoIHRoZSBleHRyYSBj b21wbGV4aXR5Ljxicj4NCjxicj4NCkkgdGhpbmsgdGhhdCB5b3UgYXJlIHJpZ2h0IHRvIGJlIGNv bmNlcm5lZCB0aGF0IGl0IHNob3VsZCBub3QgZXhwYW5kIGludG8gYSBzZXBhcmF0ZSBwYXJhbGxl bCBmb3JtYXQuJm5ic3A7IE92ZXJ0aW1lLCBJIHdvdWxkIGxpa2UgdGhlIHNpbXBsZSBmb3JtIHRv IGJlIGFibGUgdG8gdXNlIHJldmlzaW9uIGxhYmVscyBpbnN0ZWFkIG9mIHJldmlzaW9uIGRhdGVz LCBidXQgYmV5b25kIHRoaXMgSSB0aGluayB0aGF0IGl0IHNob3VsZCBqdXN0IGJlIGEgZmxhdA0K IGxpc3Qgb2YgbW9kdWxlcyB0aGF0IGRlZmluZXMgdGhlIHNjaGVtYS4mbmJzcDsgSWYgYSBzdWJz ZXQgb2YgZmVhdHVyZXMsIG9yIGRhdGFzdG9yZXMsIG9yIGltcG9ydC1vbmx5IG1vZHVsZXMgYXJl IG5lZWRlZCB0aGVuIHRoZSBZQU5HIGxpYnJhcnkgdmVyc2lvbiAob3IgVVJJcykgY2FuIGFuZCBz aG91bGQgYmUgdXNlZC48YnI+DQo8YnI+DQpBbm90aGVyIGV4YW1wbGUgb2Ygd2hlcmUgSSBleHBl Y3QgaXQgdG8gYmUgdXNlZnVsIGlzIGluIFlBTkcgcGFja2FnZXMuJm5ic3A7IExvb2tpbmcgYXQg dGhlIGV4YW1wbGVzIGF0IHRoZSBlbmQgb2YNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy1wYWNrYWdlcyIgdGFyZ2V0 PSJfYmxhbmsiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1p ZXRmLW5ldG1vZC15YW5nLXBhY2thZ2VzPC9hPiwgdGhlbiBzb21lIG9mIHRob3NlIGZpbGVzICh3 aGljaCBjdXJyZW50bHkgYXJlbid0IGRlZmluaW5nIGFueSBzY2hlbWEsIGJ1dCBzaG91bGQpIHdv dWxkIGFsbW9zdCBkb3VibGUgaW4gc2l6ZSBpZiB0aGV5IHJlcHJlc2VudGVkIHRoZSBzY2hlbWEg aW5saW5lIHVzaW5nIFlBTkcgbGlicmFyeSwgd2hpY2ggSSB0aGluaw0KIHdvdWxkIG1ha2UgdGhl IGZpbGVzIGhhcmRlciBmb3IgaHVtYW5zIHRvIHJlYWQvcGFyc2UuJm5ic3A7IFVzaW5nIFVSSXMg Y291bGQgaGVscCBtaXRpZ2F0ZSB0aGlzLCBidXQgdGhlbiB3ZSB3b3VsZCBuZWVkIHRvIGZpbmQg YSBwbGFjZSB0byBwdWJsaXNoIHRoZSBmaWxlIGNvbnRhaW5pbmcgdGhlIFlBTkcgcGFja2FnZSBz Y2hlbWEgKHByZXN1bWFibHkgc29tZXdoZXJlIGluIElBTkEpLCBhbmQgaXQgbm90IG9idmlvdXMg dG8gbWUgdGhhdCBhZGRpbmcgdGhlDQogZGVwZW5kZW5jeSBvbiB0aGUgVVJMIGlzIHJlYWxseSBh cyBoZWxwZnVsLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1iaWVybWFuLW5ldG1vZC15YW5nLWNvbmZvcm1hbmNlLTAwIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWJpZXJtYW4tbmV0bW9kLXlhbmctY29u Zm9ybWFuY2UtMDA8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFuIG9yaWdpbmFsIHVzZS1jYXNlIGluIG15IDIwMTMgZHJhZnQgd2FzIHRv IGFsbG93IGEgdmVuZG9yIHRvIGRlZmluZSBhIHBhY2thZ2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYXQgcmVwcmVzZW50ZWQgdGhlIGVudGly ZSBzZXJ2ZXIuIFRoZW4gdGhlIGVudGlyZSAmbHQ7aGVsbG8mZ3Q7IGFuZCBZQU5HIGxpYnJhcnkg Y2FuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5i ZSByZXBsYWNlZCBieSBvbmUgcGFja2FnZS1pZCBpbiB0aGlzIGNhc2UuIFRoaXMgaXMgcmVhc29u YWJsZSBmb3IgZW1iZWRkZWQgZGV2aWNlczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhdCBoYXZlIGEgZml4ZWQgWUFORyBsaWJyYXJ5IChleHBl Y3RlZCBmb3IgQ09SRUNPTkYpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5CVFcsIHRoZSBtYWluIHJlYXNvbiBJIHByb3Bvc2VkIHRoZSBZQU5H IHN5bnRheCAoeW91ciB2ZXJzaW9uIGhhcyBhIEpTT04gZG9jdW1lbnQpPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pcyB0aGF0IHRoZXNlIGZpbGVz IGFyZSBuZWVkZWQgYnkgYXV0b21hdGlvbiB0b29scywgYW5kIFlBTkcgYWxsb3dzIGV4dGVuc2lv bnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihh bmQgb3RoZXIgdGhpbmdzIGxpa2UgYXVnbWVudCkuIEF1dG9tYXRpb24gdG9vbHMgY2Fubm90IHdv cmsgd2l0aG91dCBleHRlbnNpb25zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5zbyBub3Qgc3VyZSBob3cgSlNPTiBwYWNrYWdlIGZpbGVzIHdpbGwg YmUgdXNlZnVsIHRvIHRoZW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8YnI+DQpSb2I8bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTog SnVlcmdlbiBTY2hvZW53YWVsZGVyICZsdDs8YSBocmVmPSJtYWlsdG86ai5zY2hvZW53YWVsZGVy QGphY29icy11bml2ZXJzaXR5LmRlIiB0YXJnZXQ9Il9ibGFuayI+ai5zY2hvZW53YWVsZGVyQGph Y29icy11bml2ZXJzaXR5LmRlPC9hPiZndDs8YnI+DQomZ3Q7IFNlbnQ6IDA4IEp1bHkgMjAyMSAx MTozNTxicj4NCiZndDsgVG86IEJhbMOhenMgTGVuZ3llbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJh bGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJhbGF6cy5sZW5neWVs QGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBDYzogQW5keSBCaWVybWFuICZsdDs8YSBo cmVmPSJtYWlsdG86YW5keUB5dW1hd29ya3MuY29tIiB0YXJnZXQ9Il9ibGFuayI+YW5keUB5dW1h d29ya3MuY29tPC9hPiZndDs7IFJvYiBXaWx0b24gKHJ3aWx0b24pPGJyPg0KJmd0OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+cndpbHRvbkBj aXNjby5jb208L2E+Jmd0OzsgPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPg0KbmV0bW9kQGlldGYub3JnPC9hPjsgQmVub2l0IENsYWlzZTxicj4NCiZndDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpiZW5vaXQuY2xhaXNlQGh1YXdlaS5jb20iIHRhcmdldD0iX2Js YW5rIj5iZW5vaXQuY2xhaXNlQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCiZndDsgU3ViamVjdDog UmU6IEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLW5ldG1vZC15YW5nLWluc3RhbmNlLWZpbGUtZm9y bWF0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBxdWVzdGlvbiBJIGFza2VkIGlzICZxdW90O2hv dyBtdWNoIHNpbXBsZXIgaXMgaXQgYW5kIGRvZXMgdGhhdCBzYXZpbmc8YnI+DQomZ3Q7IGp1c3Rp ZnkgdGhlIGludHJvZHVjdGlvbiBvZiBhIG5ldyByYXRoZXIgbGltaXRlZCBmb3JtYXQgKHRoYXQg bWF5IHJpc2s8YnI+DQomZ3Q7IHRvIGdyb3cgb3ZlciB0aW1lIGFuZCBiZWNvbWUgYSBzZWNvbmQg Y2l0aXplbikmcXVvdDsuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNvIGxldHMgdGFrZSB5b3VyIE5B Q00gZXhhbXBsZS4gaWV0Zi1uZXRjb25mLWFjbUAyMDE4LTAyLTE0IGltcG9ydHM8YnI+DQomZ3Q7 IGZyb20gaWV0Zi15YW5nLXR5cGVzIChhdCB0aGUgdGltZSBvZiBwdWJsaWNhdGlvbiB0aGF0IHJl c29sdmVzIHRvPGJyPg0KJmd0OyBpZXRmLXlhbmctdHlwZXNAMjAxMy0wNy0xNS4gU28gdGhlIFlB TkcgTGlicmFyeSBpbnN0YW5jZSBkYXRhIHdvdWxkPGJyPg0KJmd0OyByb3VnaGx5IGxvb2sgdGhp cyAocGxlYXNlIGNvcnJlY3Qgd2hhdCBJIG1lc3NlZCB1cCwgSSBhbSB3cml0aW5nIHRoaXM8YnI+ DQomZ3Q7IGJ5IGhhbmQpOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbHQ7eWFuZy1saWJyYXJ5Jmd0 Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7Jmx0O21vZHVsZS1zZXQmZ3Q7PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7Jmx0O25hbWUmZ3Q7bSZsdDsvbmFtZSZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsmbHQ7bW9kdWxlJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsmbHQ7bmFtZSZndDtpZXRmLW5ldGNvbmYtYWNtJmx0Oy9uYW1lJmd0Ozxicj4NCiZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7cmV2aXNpb24mZ3Q7MjAxOC0wMi0xNCZs dDsvcmV2aXNpb24mZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtu YW1lc3BhY2UmZ3Q7dXJpMSZsdDsvbmFtZXNwYWNlJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyZsdDsvbW9kdWxlJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtp bXBvcnQtb25seS1tb2R1bGUmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyZsdDtuYW1lJmd0O2lldGYteWFuZy10eXBlcyZsdDsvbmFtZSZndDs8YnI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O25hbWVzcGFjZSZndDt1cmkyJmx0Oy9uYW1lc3BhY2Um Z3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtyZXZpc2lvbi8mZ3Q7 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy9pbXBvcnQtb25seS1tb2R1bGUmZ3Q7 PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsmbHQ7L21vZHVsZS1zZXQmZ3Q7PGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsmbHQ7c2NoZW1hJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtu YW1lJmd0O3MmbHQ7L25hbWUmZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O21v ZHVsZS1zZXQmZ3Q7bSZsdDsvbW9kdWxlLXNldCZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyZs dDsvc2NoZW1hJmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7Jmx0O2RhdGFzdG9yZSZndDs8YnI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7bmFtZSZndDtydW5uaW5nJmx0Oy9uYW1lJmd0 Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDtzY2hlbWEmZ3Q7cyZsdDsvc2NoZW1h Jmd0Ozxicj4NCiZndDsmbmJzcDsgJm5ic3A7Jmx0Oy9kYXRhc3RvcmUmZ3Q7PGJyPg0KJmd0OyAm bHQ7L3lhbmctbGlicmFyeSZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgWWVzLCB0aGlzIGlzIGEg Yml0IGxvbmdlciwgYnV0IGl0IGFsc28gY29udmV5cyBtb3JlIGluZm9ybWF0aW9uIChub3RlPGJy Pg0KJmd0OyB0aGF0IHlvdXIgZGF0YXN0b3JlIGxlYWYgaW4gdGhlIGhlYWRlciB3b3VsZCBsaWtl bHkgbm90IGJlIG5lZWRlZDxicj4NCiZndDsgYW55bW9yZSkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEkgYW0gY29uY2VybmVkIHRoYXQgd2Ugc3RhcnQgY3JlYXRpbmcgYW5vdGhlciBmb3JtYXQgdG8g ZGVmaW5lIHNjaGVtYXM8YnI+DQomZ3Q7IHRoYXQgaXMgdmVyeSBsaW1pdGVkIGFuZCBwZW9wbGUg bGF0ZXIgY29tZSB3aXRoIGV4dGVuc2lvbiBwcm9wb3NhbHMgdG88YnI+DQomZ3Q7IGFkZHJlc3Mg c29tZSBvZiB0aGUgbGltaXRzIGFuZCBhdCB0aGUgZW5kIHdlIGhhdmUgbXVsdGlwbGUgZm9ybWF0 cyB0bzxicj4NCiZndDsgbWFpbnRhaW4gYW5kIGRlYWwgd2l0aC4gU28gdGhlIHF1ZXN0aW9uIGlz IHdoZXRoZXIgcGVvcGxlIHRoaW5rIHRoaXM8YnI+DQomZ3Q7IGlzIHdvcnRoIGl0LiAoTm90ZSB0 aGF0IHRoZSBmZWx0IG92ZXJoZWFkIGdvZXMgZG93biB3aXRoIGV2ZXJ5PGJyPg0KJmd0OyBhZGRp dGlvbmFsIG1vZHVsZSB1c2VkIGJ5IHlvdXIgaW5zdGFuY2UgZmlsZSwgc28gdGhlIGV4YW1wbGUg YWJvdmUgaXM8YnI+DQomZ3Q7IHJlYWxseSB0aGUgbW9zdCBleHRyZW1lIGNhc2UuIEFuZCBpZiB5 b3UgaGF2ZSBtYW55IG1vZHVsZXMgZGVmaW5pbmc8YnI+DQomZ3Q7IE5BQ00gcnVsZXMsIHRoZW4g eW91IHB1dCB0aGUgYWJvdmUgaW50byBhIHNlcGFyYXRlIGZpbGUgYW5kIHVzZSB0aGU8YnI+DQom Z3Q7IFVSSSB0byBwb2ludCB0byB0aGUgc2NoZW1hLCBubz88YnI+DQomZ3Q7IDxicj4NCiZndDsg L2pzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIFRodSwgSnVsIDA4LCAyMDIxIGF0IDA5OjI3OjUy QU0gKzAwMDAsIEJhbMOhenMgTGVuZ3llbCB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgSGVsbG8gSnVy Z2VuLDxicj4NCiZndDsgJmd0OyBJbmxpbmU6PGJyPg0KJmd0OyAmZ3Q7IFRoaXMgY29tcGxleCBm b3JtIG9mIGlubGluZSB3YXMgcmVxdWVzdGVkIGFuZCBub3Qgb2JqZWN0ZWQgZWFybGllciBieTxi cj4NCiZndDsgb3RoZXI8YnI+DQomZ3Q7ICZndDsgcmV2aWV3ZXJzLjxicj4NCiZndDsgJmd0OyBC YXNlZCBvbiBSb2IncyBhbmQgb3RoZXJzJyBwcm9wb3NhbCBpbmxpbmUgd2lsbCBiZSBzaW1wbGlm aWVkIHRvIHVzZSBvbmx5PGJyPg0KJmd0OyAmZ3Q7IGlldGYteWFuZy1saWJyYXJ5QDIwMTktMDEt MDQgYXMgeW91IHN1Z2dlc3QuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFNpbXBsaWZp ZWQgaW5saW5lOjxicj4NCiZndDsgJmd0OyBJbiBFcmljc3NvbiB3ZSBhbHJlYWR5IHVzZSBzaW1w bGlmaWVkIGlubGluZSBhIGxvdCwgaXQgaXMgdGhlIG1vc3QgY29tbW9uPGJyPg0KJmd0OyAmZ3Q7 IGZvcm1hdC48YnI+DQomZ3Q7ICZndDsgSWYgeW91IGFyZSBwcm92aWRpbmcgZGF0YSBvbmx5IGZv ciBvbmUgb3IgYSBmZXcgWUFORyBtb2R1bGVzIGFuZCBkb24ndDxicj4NCiZndDsgaGF2ZSw8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgZG9uJ3QgY2FyZSBhYm91dCBmZWF0dXJlcy9kZXZp YXRpb25zIGl0IGlzIHRoZSBlYXNpZXN0LCBzaG9ydGVzdCBtZXRob2QgdG88YnI+DQomZ3Q7ICZn dDsgdXNlLjxicj4NCiZndDsgJmd0OyZuYnNwOyBPdXIgbW9zdCBjb21tb24gdXNlLWNhc2UgaXMg dG8gcHJvdmlkZSBwcmVjb25maWd1cmVkIGFjY2VzcyBjb250cm9sPGJyPg0KJmd0OyBydWxlczxi cj4NCiZndDsgJmd0OyBmb3IgbmV3IG5vZGVzLjxicj4NCiZndDsgJmd0OyBXaGVuIGEgWUFORyBt b2RlbGVyIGRlc2lnbnMgYSBuZXcgbW9kdWxlLCBoZSBpbW1lZGlhdGVseSBwcm92aWRlcyBhPGJy Pg0KJmd0OyBzZXQgb2Y8YnI+DQomZ3Q7ICZndDsgTkFDTSBydWxlczxicj4NCiZndDsgJmd0OyBm b3IgdGhlIHJlYWRPbmx5IGFuZCB0aGUgU3lzdGVtQWRtaW4gcm9sZXMvZ3JvdXBzLjxicj4NCiZn dDsgJmd0OyBJbiB0aGlzIGNhc2UgeW91IG9ubHkgbmVlZCB0byBzcGVjaWZ5ICZxdW90O2lldGYt bmVjb25mLWFjbUAyMDEyLTAyLTIyJnF1b3Q7IE5vPGJyPg0KJmd0OyAmZ3Q7IGRldmlhdGlvbnMs IG5vIGZlYXR1cmVzIHRvIGluZGljYXRlLjxicj4NCiZndDsgJmd0OyBSZWdhcmRzIEJhbGF6czxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBSZWdhcmRzIEJhbGF6czxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0 OyBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqLnNjaG9l bndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUiIHRhcmdldD0iX2JsYW5rIj5qLnNjaG9lbndh ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyBTZW50OiAy MDIxLiBqw7psaXVzIDcuLCBzemVyZGEgMjE6MjY8YnI+DQomZ3Q7ICZndDsgVG86IEFuZHkgQmll cm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7IENjOiBCYWzDoXpz IExlbmd5ZWwgJmx0OzxhIGhyZWY9Im1haWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20i IHRhcmdldD0iX2JsYW5rIj5iYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb208L2E+Jmd0OzsgUm9i IFdpbHRvbiAocndpbHRvbik8YnI+DQomZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyd2ls dG9uQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDs7 IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCm5ldG1v ZEBpZXRmLm9yZzwvYT47IEJlbm9pdCBDbGFpc2U8YnI+DQomZ3Q7ICZndDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpiZW5vaXQuY2xhaXNlQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5iZW5vaXQu Y2xhaXNlQGh1YXdlaS5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiBSZTogQUQg cmV2aWV3IG9mIGRyYWZ0LWlldGYtbmV0bW9kLXlhbmctaW5zdGFuY2UtZmlsZS1mb3JtYXQ8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgT24gV2VkLCBKdWwgMDcsIDIwMjEgYXQgMTE6MTI6 MDZBTSAtMDcwMCwgQW5keSBCaWVybWFuIHdyb3RlOjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyBJbmxpbmUgbWV0aG9kIGlzIG5lZWRlZCwgaWYgeW91IHdhbnQg dG8gaW5kaWNhdGUgdGhhdCB0aGUgZmlsZSB3YXM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGdl bmVyYXRlZCBieSBzb21lb25lIHdobyB1c2VzIHNvbWUgWUFORyBtb2R1bGVzIHdpdGggZGV2aWF0 aW9uczxicj4NCiZndDsgYW5kPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBzb21lIGZlYXR1cmVz IGFyZSBub3Qtc3VwcG9ydGVkLiBUaGVyZSBpcyBubyB3YXkgdG8gaW5kaWNhdGU8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7IGZlYXR1cmUtc3VwcG9ydCBhbmQgZGV2aWF0aW9ucyB3aXRoIHRoZSBz aW1wbGlmaWVkLWlubGluZSBtZXRob2QuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0OyBUaGUgSW5saW5lIGFueWRhdGEgc29sdXRpb24gaXMgdmVyeSBoZWF2eXdlaWdodC48 YnI+DQomZ3Q7ICZndDsgJmd0OyBCZWZvcmUgdGhlIFlBTkcgbGlicmFyeSB0aGVyZSB3YXMgYSBz aW1wbGUgVVJJIHRoYXQgaXMgZWFzaWVyIHRvIHVzZTxicj4NCiZndDsgJmd0OyAmZ3Q7IGFuZCB0 YWtlcyB1cCBtdWNoIGxlc3Mgc3RvcmFnZS48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyBUaGUgaW5saW5lIGNvbnRlbnQgc2NoZW1hIGlzIHN1cGVyIGdl bmVyaWMgc2luY2UgaXQgc3VwcG9ydHMgYW4gb3BlbiBlbmRlZDxicj4NCiZndDsgJmd0OyBzZXQg b2Ygc2NoZW1hIGRlZmluaW5nIG1vZHVsZXMuIFdoaWxlIHlvdSBjYW4gdXNlIGl0IHdpdGggc2F5 PGJyPg0KJmd0OyAmZ3Q7IGlldGYteWFuZy1saWJyYXJ5QDIwMTktMDEtMDQsIHlvdSBjYW4gdXNl IGFueXRoaW5nIGVsc2UgYXMgd2VsbC4gSW4gb3RoZXI8YnI+DQomZ3Q7ICZndDsgd29yZHMsIHR3 byBpbXBsZW1lbnRhdGlvbnMgc3VwcG9ydGluZyBpbmxpbmUgY29udGVudCBzY2hlbWEgbWF5IG5v dDxicj4NCiZndDsgJmd0OyBpbnRlcm9wZXJhdGUuIEkgZG8gbm90IHRoaW5rIHRoZXJlIGlzIGEg c2NoZW1hIGZvcm1hdCB0aGF0IGlzIG1hbmRhdG9yeSB0bzxicj4NCiZndDsgJmd0OyBpbXBsZW1l bnQgZm9yIGlubGluZSBjb250ZW50IHNjaGVtYS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgU28gaGVyZSBpcyBteSBhc3Nlc3NtZW50IG9mIHdoYXQgd2UgaGF2ZSBpbiB0ZXJtcyBvZiBp bnRlcm9wZXJhYmlsaXR5Ojxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAtIFNpbXBsaWZp ZWQtSW5saW5lIGNvbWVzIHdpdGggbm90YWJsZSByZXN0cmljdGlvbnMsIGludGVyb3BlcmFibGU8 YnI+DQomZ3Q7ICZndDsgLSBJbmxpbmUgaXMgYW4gb3BlbiBlbmRlZCBjb250ZW50IHNjaGVtYSwg bm90IG5lY2Vzc2FyaWx5IGludGVyb3BlcmFibGU8YnI+DQomZ3Q7ICZndDsgLSBVUkkgbWV0aG9k IHB1c2hlcyB0aGUgcHJvYmxlbSB0byBhbm90aGVyIGluc3RhbmNlIGZpbGUsIGludGVyb3BlcmFi bGU8YnI+DQomZ3Q7ICZndDsgLSBFeHRlcm5hbCBpcyBieSBkZXNpbmcgbm90IGludGVyb3BlcmFi bGU8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgT24gdGhlIHNlcnZlciBzaWRlLCB3ZSBo YXZlIFlBTkcgTGlicmFyeS4gUGVyaGFwcyBSRkMgODUyNSBoYXMgc29tZTxicj4NCiZndDsgJmd0 OyBjb21wbGV4aXR5IHRoYXQgaXMgdXNlZnVsIGZvciBzdXBwb3J0aW5nIGxhcmdlIHNlcnZlcnMg d2l0aCBtdWx0aXBsZTxicj4NCiZndDsgJmd0OyBkYXRhc3RvcmVzIGFuZCBub3QgbmVlZGVkIGZv ciBzbWFsbCBpbnN0YW5jZSBmaWxlcyAoSSB1bmRlcnN0YW5kIHRoYXQgYW48YnI+DQomZ3Q7ICZn dDsgaW5zdGFuY2UgZmlsZSBpcyBhbHdheXMgdGllZCB0byBhIHNpbmdsZSBkYXRhc3RvcmU/KS48 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVG8gbWUsIGl0IGZlZWxzIHRoYXQgcmV1c2lu ZyBSRkMgODUyNSBkZXNpZ24gaXMgYWN0dWFsbHkgYSBnb29kIHRoaW5nLiBCZWluZzxicj4NCiZn dDsgJmd0OyBhYmxlIHRvIGR1bXAgYSBsaXZlIHNlcnZlciBkYXRhc3RvcmUgaW50byBhbiBpbnN0 YW5jZSBmaWxlIHNlZW1zIGxpa2UgYSB2ZXJ5PGJyPg0KJmd0OyAmZ3Q7IHZhbGlkIHVzZSBjYXNl IHRvIG1lIGFuZCBpZGVhbGx5IHRoaXMgaXMgcG9zc2libGUgd2l0aG91dCBoYXZpbmcgdG8gcmV3 cml0ZTxicj4NCiZndDsgJmd0OyB0aGUgc2NoZW1hIHBhcnQuIFdlbGwsIHlvdSBjb3VsZCBnbyBh bmQgdHJpbSB1bnVzZWQgZGF0YXN0b3JlIHNjaGVtYXM8YnI+DQomZ3Q7IGFuZDxicj4NCiZndDsg Jmd0OyBmcm9tIHRoZXJlIHVudXNlZCBtb2R1bGUgc2V0cyBldGMgYnV0IHRoYXQgY2FuIGFsbCBi ZSBkb25lIGJ5IGFuIGV4dGVybmFsPGJyPg0KJmd0OyAmZ3Q7IHRvb2wgdHJpbW1pbmcgdGhlIHNj aGVtYSBwYXJ0LCBpLmUuLCBpdCBkb2VzIG5vdCBuZWVkIHRvIGJlIGRvbmUgYnkgYSB0b29sPGJy Pg0KJmd0OyAmZ3Q7IHRoYXQganVzdCBkdW1wcyBhIHNlcnZlciBkYXRhc3RvcmUuPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFdoYXQgaXMgdGhlIGFjdHVhbCB2YWx1ZSBvZiBzaW1wbGlm aWVkIGlubGluZT8gSG93IG11Y2ggZG8geW91IHJlYWxseSBzYXZlPGJyPg0KJmd0OyAmZ3Q7IGNv bXBhcmVkIHRvIHRoZSBzaW1wbGVzdCBlcXVpdmFsZW50IFJGQyA4NTI1IHJlcHJlc2VudGF0aW9u PyBBbmQgZG9lczxicj4NCiZndDsgdGhhdDxicj4NCiZndDsgJmd0OyBzYXZpbmcganVzdGlmeSB0 byBzdGFydCBlbmdpbmVlcmluZyBhbm90aGVyIHNjaGVtYSBzcGVjaWZpY2F0aW9uIGZvcm1hdD88 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSSBndWVzcyBteSBjaG9pY2Ugd291bGQgaGF2 ZSBiZWVuIHRvIGp1c3QgaGF2ZTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyArLS0gY29udGVudC1zY2hlbWE8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyArLS0gKGNvbnRlbnQtc2NoZW1hLXNwZWMp Pzxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNw OyAmbmJzcDsrLS06ICh5YW5nLWxpYnJhcnkpPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOystLTogKHVyaSk8YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsgYnV0IG90aGVycyBvYnZpb3VzbHkgd2FudCBtdWNoIG1vcmUgY2hv aWNlIChidXQgbGV0cyBub3RlIHRoYXQgZXZlcnl0aGluZzxicj4NCiZndDsgJmd0OyBzaXRzIGlu IGEgY2hvaWNlLCBzbyBldmVyeXRoaW5nIGlzIGV4dGVuc2libGUgaW4gY2FzZSBvdGhlciBzY2hl bWE8YnI+DQomZ3Q7ICZndDsgZGVmaW5pdGlvbiBmb3JtYXRzIGFyZSBvdXQgdGhlcmUpLjxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAvanM8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgLS08YnI+DQomZ3Q7ICZndDsgSnVlcmdlbiBTY2hvZW53YWVsZGVyJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkg8 YnI+DQomZ3Q7ICZndDsgUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnk8YnI+ DQomZ3Q7ICZndDsgRmF4OiZuYnNwOyAmbmJzcDsrNDkgNDIxIDIwMCAzMTAzPGJyPg0KJmd0OyAm Z3Q7ICZsdDs8YSBocmVmPSJodHRwczovL3Byb3RlY3QyLmZpcmVleWUuY29tL3YxL3VybD9rPWZl ODVjOGU2LWExMWVmMWNkLWZlODU4ODdkLSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vcHJvdGVj dDIuZmlyZWV5ZS5jb20vdjEvdXJsP2s9ZmU4NWM4ZTYtYTExZWYxY2QtZmU4NTg4N2QtPC9hPjxi cj4NCiZndDsgODY2MDM4OTczYTxicj4NCiZndDsgJmd0OyAxNS0xOWU1ZGFkMzc1YWYwMDYzJmFt cDtxPTEmYW1wO2U9MzYzNzQwNmQtZjc3NC00MDczLTgwZWUtPGJyPg0KJmd0OyBhNzQzMTExMWU5 YmMmYW1wO3U9aHR0cHMlM0ElMkY8YnI+DQomZ3Q7ICZndDsgJTxhIGhyZWY9Imh0dHA6Ly8yRnd3 dy5qYWNvYnMtdW5pdmVyc2l0eS5kZSIgdGFyZ2V0PSJfYmxhbmsiPjJGd3d3LmphY29icy11bml2 ZXJzaXR5LmRlPC9hPiUyRiZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IC0tPGJyPg0KJmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXImbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0phY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSDxi cj4NCiZndDsgUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnk8YnI+DQomZ3Q7 IEZheDombmJzcDsgJm5ic3A7KzQ5IDQyMSAyMDAgMzEwMyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUv IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9hPiZn dDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM4PR11MB54380C92315B0321CE94BBECB5189DM4PR11MB5438namp_-- From nobody Fri Jul 9 03:37:25 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBD43A1C21; Fri, 9 Jul 2021 03:37:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <162582703992.23575.3820243303774593093@ietfa.amsl.com> Date: Fri, 09 Jul 2021 03:37:19 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-15.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 10:37:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : YANG Instance Data File Format Authors : Balazs Lengyel Benoit Claise Filename : draft-ietf-netmod-yang-instance-file-format-15.txt Pages : 28 Date : 2021-07-09 Abstract: There is a need to document data defined in YANG models at design, implementation time or when a live server is unavailable. This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models, and annotates it with metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 9 03:39:44 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9AD3A1C2E for ; Fri, 9 Jul 2021 03:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 198OnwZAX-kQ for ; Fri, 9 Jul 2021 03:39:38 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DF93A1C28 for ; Fri, 9 Jul 2021 03:39:37 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id p1so22331170lfr.12 for ; Fri, 09 Jul 2021 03:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ttMl3glXpJ9K1arBWUdEhO4QMs8TrnNULngp/nRElJ4=; b=VwLcUpZ60ZPPQ5zJPPhEbTAnRuFd4eTGIqjzZbfum8aO2TVkONoci4CZ1eH7Q6XWhw T3CD7F+F6dr0wpSaMyqV8xTB2u8EboynjTH3S4g+H3Ndr282nGG0um9y3nC78b6530s0 P27WBpGIxODc48Jmr0eV+REPMv7mBodEe0x+Ui+wwAIrSb2PsK7tZHfzGvxqfjCJiCWt NQAlg9SegtSEBvndPyIxFqH1bze74RrhE0oJJ5Av1j7AJAFdNBQgFn6U7MTxXkgSq3DT 2530ux1TZa5B6Za2q8Z9K4BduBCnjb4vPZlSHZIrY7j6ROdAY4L9dNf73BrBV4nnReb3 hfcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ttMl3glXpJ9K1arBWUdEhO4QMs8TrnNULngp/nRElJ4=; b=hNOF19foXfFeyv3pyIqlYrCKnyd2VQuXTiy2aoV7UlVrCSVtFuYCCvFZBouoQCzPqI Em0SjFzm5EK8MdjusceyQDqv6oKH0b7YTgSP9PmU3XEqliCqkssccawPyaJmBHkjVXbr ziRjz2Qsc5pkRG3Dh8n9pnvOlbXWeKc+NTMwSSr7N9OYd0T8Omv6zIsTxAN/7UXgnWSD JS9l1NOuI1PF1dVtY/8uIjP8UCtYXn/M8jNBr4fAX4zgD2l6M2EqgsmgCYPXpNIt7Ny+ uWjnKuAZEa8nW+Xtq1PVeMF2R87R8E8EBN+YysXjHLLrAY9/s9ganUPsVRbPg65rsNZx Ef+Q== X-Gm-Message-State: AOAM5318hIeiM1fdVfq8UGDw3I2SZblrcK3PUbU3iWuRRnOUaFSCUzHW 9mpMIbqKpYerjdekPtzPvna9ec5DFnzmrCpe4aQHaw== X-Google-Smtp-Source: ABdhPJzVAgYnXDqsdK+K/kMGqmrvEhZLMLkzhq8qK4Qxq9IOU0OfADGIbMHVo9Tm6CTc9G0uoG955/zvG0rVvjUY+q4= X-Received: by 2002:a05:6512:3c93:: with SMTP id h19mr6297697lfv.512.1625827174664; Fri, 09 Jul 2021 03:39:34 -0700 (PDT) MIME-Version: 1.0 References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> <20210707192534.4emim5a36zyqrktc@anna.jacobs.jacobs-university.de> <20210708103528.6ezr4v5qeltinvmv@anna.jacobs.jacobs-university.de> In-Reply-To: From: Andy Bierman Date: Fri, 9 Jul 2021 03:39:23 -0700 Message-ID: To: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= Cc: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= , "Rob Wilton (rwilton)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="00000000000036661905c6ae63bd" Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 10:39:43 -0000 --00000000000036661905c6ae63bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 9, 2021 at 1:58 AM Bal=C3=A1zs Lengyel wrote: > Hello Andy, > > In the name of simplification, I will add the following to the URI method= : > > > > Referenced files using "inline" or the "simplified-inline" methods MUST > be supported. > > Referenced files using the "URI method" MAY be supported. > > > This is a good compromise. Although it may seem that mandating everything will increase interoperability, it actually has the opposite effect. Companies decide to implement everything, but "in phases". This is code for "phase 1 will implement the parts we need. Phase 2 will never happen." There is plenty of implementation experience with the first 2 methods, and good reason to think they will be supported. The draft details for the URI method clearly lack any meaningful implementation feedback. There are so many problems with this approach, especially for the reader. Storing passwords in cleartext is just the easiest to spot. > This means the tool does not need to be prepared for chains or loops. I > think chains and loops are something we should discourage. > > (Referenced files using the =E2=80=9Cexternal Method=E2=80=9D make no sen= se anyway. If I > don=E2=80=99t tell you the schema of the referenced file, there is no sen= se in > referencing them) > One purpose of a standard is to assign blame when it doesn't work. If the writer generates a series of URIs that form a loop, then the reader will not be able to find the file that has the Simplified Inline or Inline info= . That is clearly the fault of the writer, not the reader. Regards Balazs > Andy > > > *From:* netmod *On Behalf Of *Bal=C3=A1zs Lengy= el > *Sent:* 2021. j=C3=BAlius 9., p=C3=A9ntek 9:39 > *To:* Andy Bierman ; Rob Wilton (rwilton) < > rwilton@cisco.com> > *Cc:* netmod@ietf.org > *Subject:* Re: [netmod] AD review of > draft-ietf-netmod-yang-instance-file-format > > > > Hello Andy, > > See below. > > Balazs > > > > *From:* Andy Bierman > *Sent:* 2021. j=C3=BAlius 8., cs=C3=BCt=C3=B6rt=C3=B6k 18:55 > *To:* Rob Wilton (rwilton) > *Cc:* Juergen Schoenwaelder ; > Bal=C3=A1zs Lengyel ; netmod@ietf.org; Benoi= t > Claise > *Subject:* Re: AD review of draft-ietf-netmod-yang-instance-file-format > > > > > > > > On Thu, Jul 8, 2021 at 3:58 AM Rob Wilton (rwilton) > wrote: > > Hi Juergen, > > I believe that having the simple form is worth the extra complexity. > > > > > > I believe it is the only option that does not have too much complexity. > > > > The inline form seems to imply that the NMDA version of the YANG library > is used. > > Only 1 module set is ever shown, but of course the actual schema allows > > for much more complex instances than that, which the reader must support. > > > > Does this mean NMDA must be used or else a YANG data file cannot be saved= ? > > So the reader is expected to look for the 'current' /yang-library and the= n > the 'deprecated' /modules-state? > > And then fish the anydata for whatever non-standard solution is in use? > > The procedures should be explained better so there is a better chance of > interoperability. > > BALAZS: No NMDA is not required. If it would there would be a clear > statement about it. Even in section 2.2.1. Documentation of server > capabilities the new (NMDA compatible) yang-library is used, but the simp= le > (non- NMDA) modules-state branch. > > > > For the URI method, the reader must check for a broken chain of reference > and loops. > > The draft should say the uri references across N files MUST NOT create a > loop > > (similar language is in YANG wrt import loops). > > BALAZS: Someone (don.t know who) asked for longer reference chains. > However, I don=E2=80=99t see them as a common use-case. IMHO the most com= mon > use-case for the URI method will be, when the consumer knows the > content-schema apriori, it only needs a reference to check that the schem= a > is what it expected. > > > > For conformance purposes, I think YANG features are appropriate. > > IMO simplified-inline is mandatory-to-implement but the rest should > > be optional. This way a tool can claim conformance and also the standard > > will provide a minimum level of interoperability. > > BALAZS: There are very different views about the preferred/required > methods. Also the needs of different use-cases are different. That=E2=80= =99s why we > need all 3. > > > > > > Andy > > > > > > > > > > I think that you are right to be concerned that it should not expand into > a separate parallel format. Overtime, I would like the simple form to be > able to use revision labels instead of revision dates, but beyond this I > think that it should just be a flat list of modules that defines the > schema. If a subset of features, or datastores, or import-only modules a= re > needed then the YANG library version (or URIs) can and should be used. > > > > This can be done with augment if and when the versioning draft reaches RF= C > > > > Another example of where I expect it to be useful is in YANG packages. > Looking at the examples at the end of > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages, > then some of those files (which currently aren't defining any schema, but > should) would almost double in size if they represented the schema inline > using YANG library, which I think would make the files harder for humans = to > read/parse. Using URIs could help mitigate this, but then we would need = to > find a place to publish the file containing the YANG package schema > (presumably somewhere in IANA), and it not obvious to me that adding the > dependency on the URL is really as helpful. > > Regards, > Rob > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > Sent: 08 July 2021 11:35 > > To: Bal=C3=A1zs Lengyel > > Cc: Andy Bierman ; Rob Wilton (rwilton) > > ; netmod@ietf.org; Benoit Claise > > > > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format > > > > The question I asked is "how much simpler is it and does that saving > > justify the introduction of a new rather limited format (that may risk > > to grow over time and become a second citizen)". > > > > So lets take your NACM example. ietf-netconf-acm@2018-02-14 imports > > from ietf-yang-types (at the time of publication that resolves to > > ietf-yang-types@2013-07-15. So the YANG Library instance data would > > roughly look this (please correct what I messed up, I am writing this > > by hand): > > > > > > > > m > > > > ietf-netconf-acm > > 2018-02-14 > > uri1 > > > > > > ietf-yang-types > > uri2 > > > > > > > > > > s > > m > > > > > > running > > s > > > > > > > > Yes, this is a bit longer, but it also conveys more information (note > > that your datastore leaf in the header would likely not be needed > > anymore). > > > > I am concerned that we start creating another format to define schemas > > that is very limited and people later come with extension proposals to > > address some of the limits and at the end we have multiple formats to > > maintain and deal with. So the question is whether people think this > > is worth it. (Note that the felt overhead goes down with every > > additional module used by your instance file, so the example above is > > really the most extreme case. And if you have many modules defining > > NACM rules, then you put the above into a separate file and use the > > URI to point to the schema, no? > > > > /js > > > > On Thu, Jul 08, 2021 at 09:27:52AM +0000, Bal=C3=A1zs Lengyel wrote: > > > Hello Jurgen, > > > Inline: > > > This complex form of inline was requested and not objected earlier by > > other > > > reviewers. > > > Based on Rob's and others' proposal inline will be simplified to use > only > > > ietf-yang-library@2019-01-04 as you suggest. > > > > > > Simplified inline: > > > In Ericsson we already use simplified inline a lot, it is the most > common > > > format. > > > If you are providing data only for one or a few YANG modules and don'= t > > have, > > > > > > don't care about features/deviations it is the easiest, shortest > method to > > > use. > > > Our most common use-case is to provide preconfigured access control > > rules > > > for new nodes. > > > When a YANG modeler designs a new module, he immediately provides a > > set of > > > NACM rules > > > for the readOnly and the SystemAdmin roles/groups. > > > In this case you only need to specify "ietf-neconf-acm@2012-02-22" No > > > deviations, no features to indicate. > > > Regards Balazs > > > > > > Regards Balazs > > > > > > -----Original Message----- > > > From: Juergen Schoenwaelder > > > Sent: 2021. j=C3=BAlius 7., szerda 21:26 > > > To: Andy Bierman > > > Cc: Bal=C3=A1zs Lengyel ; Rob Wilton (rw= ilton) > > > ; netmod@ietf.org; Benoit Claise > > > > > > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format > > > > > > On Wed, Jul 07, 2021 at 11:12:06AM -0700, Andy Bierman wrote: > > > > > > > > > Inline method is needed, if you want to indicate that the file wa= s > > > > > generated by someone who uses some YANG modules with deviations > > and > > > > > some features are not-supported. There is no way to indicate > > > > > feature-support and deviations with the simplified-inline method. > > > > > > > > The Inline anydata solution is very heavyweight. > > > > Before the YANG library there was a simple URI that is easier to us= e > > > > and takes up much less storage. > > > > > > > > > > The inline content schema is super generic since it supports an open > ended > > > set of schema defining modules. While you can use it with say > > > ietf-yang-library@2019-01-04, you can use anything else as well. In > other > > > words, two implementations supporting inline content schema may not > > > interoperate. I do not think there is a schema format that is > mandatory to > > > implement for inline content schema. > > > > > > So here is my assessment of what we have in terms of interoperability= : > > > > > > - Simplified-Inline comes with notable restrictions, interoperable > > > - Inline is an open ended content schema, not necessarily interoperab= le > > > - URI method pushes the problem to another instance file, interoperab= le > > > - External is by desing not interoperable > > > > > > On the server side, we have YANG Library. Perhaps RFC 8525 has some > > > complexity that is useful for supporting large servers with multiple > > > datastores and not needed for small instance files (I understand that > an > > > instance file is always tied to a single datastore?). > > > > > > To me, it feels that reusing RFC 8525 design is actually a good thing= . > Being > > > able to dump a live server datastore into an instance file seems like > a very > > > valid use case to me and ideally this is possible without having to > rewrite > > > the schema part. Well, you could go and trim unused datastore schemas > > and > > > from there unused module sets etc but that can all be done by an > external > > > tool trimming the schema part, i.e., it does not need to be done by a > tool > > > that just dumps a server datastore. > > > > > > What is the actual value of simplified inline? How much do you really > save > > > compared to the simplest equivalent RFC 8525 representation? And does > > that > > > saving justify to start engineering another schema specification > format? > > > > > > I guess my choice would have been to just have > > > > > > +-- content-schema > > > | +-- (content-schema-spec)? > > > | +--: (yang-library) > > > | +--: (uri) > > > > > > but others obviously want much more choice (but lets note that > everything > > > sits in a choice, so everything is extensible in case other schema > > > definition formats are out there). > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > > > Fax: +49 421 200 3103 > > > > 866038973a > > > 15-19e5dad375af0063&q=3D1&e=3D3637406d-f774-4073-80ee- > > a7431111e9bc&u=3Dhttps%3A%2F > > > %2Fwww.jacobs-university.de > > %2F> > > > > > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > --00000000000036661905c6ae63bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jul 9, 2021 at 1:58 AM Bal=C3= =A1zs Lengyel <balazs.len= gyel@ericsson.com> wrote:
<= div class=3D"gmail-m_-1733001898339548410WordSection1">

Hello Andy,

In the name of simpl= ification, I will add the following to the URI method:

=C2=A0

Referenc= ed files using =C2=A0"inline" or the "simplified-inline"= ; methods MUST be supported.

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Refere= nced files using the "URI method" MAY be supported.=

=C2=A0

<= br>
This is a good compromise.
Although it may seem tha= t mandating everything will increase interoperability,
it actuall= y has the opposite effect. Companies decide to implement everything,
<= div>but "in phases".=C2=A0 This is code for "phase 1 will im= plement the parts we need.
Phase 2 will never happen."
=

There is plenty of implementation experience with the f= irst 2 methods,
and good reason to think they will be supported.= =C2=A0 The draft details for the URI
method clearly lack any mean= ingful implementation feedback.
There are so many problems with t= his approach, especially for the reader.
Storing passwords in cle= artext is just the easiest to spot.
=C2=A0

This means the tool do= es not need to be prepared for chains or loops. I think chains and loops ar= e something we should discourage.

= (Referenced files using the =E2=80=9Cexternal Method=E2=80=9D make no sense= anyway. If I don=E2=80=99t tell you the schema of the referenced file, the= re is no sense in referencing them)



One purpose of a standard is to assign blame when i= t doesn't work.
If the writer generates a series of URIs that= form a loop, then the reader will
not be able to find the file t= hat has the Simplified Inline or Inline=C2=A0 info.
That is clear= ly the fault of the writer, not the reader.


Regards Balazs


Andy
=C2=A0

=

=C2=A0

From: netmod <= ;netmod-bounce= s@ietf.org> On Behalf Of Bal=C3=A1zs Lengyel
Sent: = 2021. j=C3=BAlius 9., p=C3=A9ntek 9:39
To: Andy Bierman <andy@yumaworks.com&g= t;; Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: netmod@ietf.org
Subject: Re: [netm= od] AD review of draft-ietf-netmod-yang-instance-file-format<= /p>

=C2=A0

Hello Andy,

See below.=

Balazs

=C2=A0

From: Andy Bierman <andy@yumaworks.com> Sent: 2021. j=C3=BAlius 8., cs=C3=BCt=C3=B6rt=C3=B6k 18:55
To= : Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: Juergen Schoenwaelder &= lt;j.schoenwaelder@jacobs-university.de>; Bal=C3=A1zs Lengyel <balazs.lengye= l@ericsson.com>; netmod@ietf.org; Benoit Claise <benoit.claise@huawei.com>
Subject:= Re: AD review of draft-ietf-netmod-yang-instance-file-format=

=C2=A0

=C2=A0

= =C2=A0

On Thu, Jul 8, 2021 a= t 3:58 AM Rob Wilton (rwilton) <rwilton@cisco.com> wrote:

Hi Juergen,

I belie= ve that having the simple form is worth the extra complexity.=

=C2=A0

=

=C2=A0

I believe it is the only option that does not have too much comp= lexity.

=C2=A0=

The inline form seems to imply th= at the NMDA version of the YANG library is used.

Only 1 module set is ever shown, but of course the= actual schema allows

fo= r much more complex instances than that, which the reader must support.<= /u>

=C2=A0

Does this mean NMDA must be used or else a Y= ANG data file cannot be saved?

So the reader is expected to look for the 'current' /yang-li= brary and then the 'deprecated' /modules-state?

And then fish the anydata for whatever non-= standard solution is in use?

The procedures should be explained better so there is a better chance = of interoperability.

BALAZS: No NMD= A is not required. If it would there would be a clear statement about it. E= ven in section 2.2.1.=C2=A0 Documentation of server capabilities the new (N= MDA compatible) yang-library is used, but the simple (non- NMDA) modules-st= ate branch.

=C2= =A0

For the URI method, the rea= der must check for a broken chain of reference and loops.

=

The draft should say the uri references a= cross N files MUST NOT create a loop

(similar language is in YANG wrt import loops).

BALAZS: Someone (don.t know who) asked for long= er reference chains. However, I don=E2=80=99t see them as a common use-case= . IMHO the most common use-case for the URI method will be, when the consum= er knows the content-schema apriori, it only needs a reference to check tha= t the schema is what it expected.

=C2=A0

For con= formance purposes, I think YANG features are appropriate.

=

IMO simplified-inline is mandatory-to-imp= lement but the rest should=C2=A0

be optional. This way a tool can claim conformance and also the st= andard

will provide a mi= nimum level of interoperability.

BA= LAZS: There are very different views about the preferred/required methods. = Also the needs of different use-cases are different. That=E2=80=99s why we = need all 3.

=C2= =A0

=C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

=C2=A0

I think that you are right to b= e concerned that it should not expand into a separate parallel format.=C2= =A0 Overtime, I would like the simple form to be able to use revision label= s instead of revision dates, but beyond this I think that it should just be= a flat list of modules that defines the schema.=C2=A0 If a subset of featu= res, or datastores, or import-only modules are needed then the YANG library= version (or URIs) can and should be used.

=C2=A0

This can be done with augment if and when the versioning draft rea= ches RFC

=C2=A0

Another example of where I expect it= to be useful is in YANG packages.=C2=A0 Looking at the examples at the end= of https://datatracker.ietf.org/doc/html/draft-ie= tf-netmod-yang-packages, then some of those files (which currently aren= 't defining any schema, but should) would almost double in size if they= represented the schema inline using YANG library, which I think would make= the files harder for humans to read/parse.=C2=A0 Using URIs could help mit= igate this, but then we would need to find a place to publish the file cont= aining the YANG package schema (presumably somewhere in IANA), and it not o= bvious to me that adding the dependency on the URL is really as helpful.
Regards,
Rob


> -----Original Message-----
> Fro= m: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>> Sent: 08 July 2021 11:35
> To: Bal=C3=A1zs Lengyel <balazs.lengyel@er= icsson.com>
> Cc: Andy Bierman <andy@yumaworks.com>; Rob Wilton (rwilto= n)
> <rwilt= on@cisco.com>; = netmod@ietf.org; Benoit Claise
> <benoit.claise@huawei.com>
> = Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format
&g= t;
> The question I asked is "how much simpler is it and does t= hat saving
> justify the introduction of a new rather limited format = (that may risk
> to grow over time and become a second citizen)"= .
>
> So lets take your NACM example. ietf-netconf-acm@2018-02= -14 imports
> from ietf-yang-types (at the time of publication that r= esolves to
> ietf-yang-types@2013-07-15. So the YANG Library instance= data would
> roughly look this (please correct what I messed up, I a= m writing this
> by hand):
>
> <yang-library>
&= gt;=C2=A0 =C2=A0<module-set>
>=C2=A0 =C2=A0 =C2=A0<name>m= </name>
>=C2=A0 =C2=A0 =C2=A0<module>
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0<name>ietf-netconf-acm</name>
>=C2=A0 = =C2=A0 =C2=A0 =C2=A0<revision>2018-02-14</revision>
>=C2= =A0 =C2=A0 =C2=A0 =C2=A0<namespace>uri1</namespace>
>=C2= =A0 =C2=A0 =C2=A0</module>
>=C2=A0 =C2=A0 =C2=A0<import-only= -module>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<name>ietf-yang-types&l= t;/name>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<namespace>uri2</nam= espace>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<revision/>
>=C2= =A0 =C2=A0 =C2=A0</import-only-module>
>=C2=A0 =C2=A0</modul= e-set>
>=C2=A0 =C2=A0<schema>
>=C2=A0 =C2=A0 =C2=A0<= ;name>s</name>
>=C2=A0 =C2=A0 =C2=A0<module-set>m</= module-set>
>=C2=A0 =C2=A0</schema>
>=C2=A0 =C2=A0<= datastore>
>=C2=A0 =C2=A0 =C2=A0<name>running</name>>=C2=A0 =C2=A0 =C2=A0<schema>s</schema>
>=C2=A0 =C2= =A0</datastore>
> </yang-library>
>
> Yes, t= his is a bit longer, but it also conveys more information (note
> tha= t your datastore leaf in the header would likely not be needed
> anym= ore).
>
> I am concerned that we start creating another format= to define schemas
> that is very limited and people later come with = extension proposals to
> address some of the limits and at the end we= have multiple formats to
> maintain and deal with. So the question i= s whether people think this
> is worth it. (Note that the felt overhe= ad goes down with every
> additional module used by your instance fil= e, so the example above is
> really the most extreme case. And if you= have many modules defining
> NACM rules, then you put the above into= a separate file and use the
> URI to point to the schema, no?
>= ;
> /js
>
> On Thu, Jul 08, 2021 at 09:27:52AM +0000, B= al=C3=A1zs Lengyel wrote:
> > Hello Jurgen,
> > Inline:> > This complex form of inline was requested and not objected earl= ier by
> other
> > reviewers.
> > Based on Rob'= s and others' proposal inline will be simplified to use only
> &g= t; ietf-yang-library@2019-01-04 as you suggest.
> >
> > S= implified inline:
> > In Ericsson we already use simplified inline= a lot, it is the most common
> > format.
> > If you are = providing data only for one or a few YANG modules and don't
> hav= e,
> >
> > don't care about features/deviations it is= the easiest, shortest method to
> > use.
> >=C2=A0 Our m= ost common use-case is to provide preconfigured access control
> rule= s
> > for new nodes.
> > When a YANG modeler designs a ne= w module, he immediately provides a
> set of
> > NACM rules<= br>> > for the readOnly and the SystemAdmin roles/groups.
> >= ; In this case you only need to specify "ietf-neconf-acm@2012-02-22&qu= ot; No
> > deviations, no features to indicate.
> > Regar= ds Balazs
> >
> > Regards Balazs
> >
> >= ; -----Original Message-----
> > From: Juergen Schoenwaelder <<= a href=3D"mailto:j.schoenwaelder@jacobs-university.de" target=3D"_blank">j.= schoenwaelder@jacobs-university.de>
> > Sent: 2021. j=C3=BA= lius 7., szerda 21:26
> > To: Andy Bierman <andy@yumaworks.com>
> >= ; Cc: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>; Rob Wilton (rwilto= n)
> > <= rwilton@cisco.com>; netmod@ietf.org; Benoit Claise
> > <benoit.claise@huawei.com>= ;
> > Subject: Re: AD review of draft-ietf-netmod-yang-instance-fi= le-format
> >
> > On Wed, Jul 07, 2021 at 11:12:06AM -070= 0, Andy Bierman wrote:
> > >
> > > > Inline meth= od is needed, if you want to indicate that the file was
> > > &= gt; generated by someone who uses some YANG modules with deviations
>= and
> > > > some features are not-supported. There is no wa= y to indicate
> > > > feature-support and deviations with th= e simplified-inline method.
> > >
> > > The Inline = anydata solution is very heavyweight.
> > > Before the YANG lib= rary there was a simple URI that is easier to use
> > > and tak= es up much less storage.
> > >
> >
> > The in= line content schema is super generic since it supports an open ended
>= ; > set of schema defining modules. While you can use it with say
>= ; > ietf-yang-library@2019-01-04, you can use anything else as well. In = other
> > words, two implementations supporting inline content sch= ema may not
> > interoperate. I do not think there is a schema for= mat that is mandatory to
> > implement for inline content schema.<= br>> >
> > So here is my assessment of what we have in terms= of interoperability:
> >
> > - Simplified-Inline comes w= ith notable restrictions, interoperable
> > - Inline is an open en= ded content schema, not necessarily interoperable
> > - URI method= pushes the problem to another instance file, interoperable
> > - = External is by desing not interoperable
> >
> > On the se= rver side, we have YANG Library. Perhaps RFC 8525 has some
> > com= plexity that is useful for supporting large servers with multiple
> &= gt; datastores and not needed for small instance files (I understand that a= n
> > instance file is always tied to a single datastore?).
>= ; >
> > To me, it feels that reusing RFC 8525 design is actuall= y a good thing. Being
> > able to dump a live server datastore int= o an instance file seems like a very
> > valid use case to me and = ideally this is possible without having to rewrite
> > the schema = part. Well, you could go and trim unused datastore schemas
> and
&= gt; > from there unused module sets etc but that can all be done by an e= xternal
> > tool trimming the schema part, i.e., it does not need = to be done by a tool
> > that just dumps a server datastore.
&g= t; >
> > What is the actual value of simplified inline? How muc= h do you really save
> > compared to the simplest equivalent RFC 8= 525 representation? And does
> that
> > saving justify to st= art engineering another schema specification format?
> >
> &= gt; I guess my choice would have been to just have
> >
> >= ;=C2=A0 =C2=A0 =C2=A0 =C2=A0 +-- content-schema
> >=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 +-- (content-schema-spec)?
> >=C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0+--: (yang-library)
> >=C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0+--: (uri)
> >
> &= gt; but others obviously want much more choice (but lets note that everythi= ng
> > sits in a choice, so everything is extensible in case other= schema
> > definition formats are out there).
> >
>= ; > /js
> >
> > --
> > Juergen Schoenwaelder= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH
= > > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R= ing 1 | 28759 Bremen | Germany
> > Fax:=C2=A0 =C2=A0+49 421 200 31= 03
> > <https://protect2.fireeye.com/v1/= url?k=3Dfe85c8e6-a11ef1cd-fe85887d-
> 866038973a
> > 15-= 19e5dad375af0063&q=3D1&e=3D3637406d-f774-4073-80ee-
> a743111= 1e9bc&u=3Dhttps%3A%2F
> > %2Fwww.jacobs-university.de<= /a>%2F>
>
>
>
> --
> Juergen Schoenwael= der=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH<= br>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Rin= g 1 | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.d= e/>

--00000000000036661905c6ae63bd-- From nobody Fri Jul 9 03:41:19 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FA63A1C3A; Fri, 9 Jul 2021 03:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf9gSbIXbD6d; Fri, 9 Jul 2021 03:41:12 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2052.outbound.protection.outlook.com [40.107.21.52]) (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 7B36E3A1C37; Fri, 9 Jul 2021 03:41:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fjkaJx9Hw/kBQrQIoCFTFN9towJcbzFeBd5opK9tJVGYRPazySfPMOovBDUwqyEhJeL8K8ruDfB2+TrYyt1elGKvdDqM8EEQaeLH51P4zAsMAG+h8zgG2Toq/h9Q+wrY286Pyi2LD4LRPdaRdsAkLTSXiXkqSeST+pjC0muoXBzbY3yxFcpYsucUqSingBisKhO1zeh/k9xcIQabxYmItQEX8DoF8gnOiY+RVkkORQK7A4MhbOG/tTKVddN4VX7CHxa7c4QeZa4suOG95XtvnfNQWRrNcoAhnGktACDdHJX582mGjcbWeK9T2DB6wT1tQK2SNHeWLlRxhh9bjossag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QarJfgF9g/5flg1xagl890+J4zMA3W8YVpn0X0P86kI=; b=dWq5qdnHI+gcA0j52k3CvrmyyRvGukg/Etl7qCkz/KyUQOYwLdi+8uf2VDh/9poHIrL2rnwyBgL2t5nYnAR77aQuK0OvaBD9LWKT2CM/9ZGMwEfCuPS+8OqXcBnzQ1CuCF1SF4ZC5VYuDy6GgI6SBuROt+W4PLKhdWdxhiafVlhR0S86//O/Qf5YorqKdU+LeiBaW0IDvGzJKyvl0jB4BKSQYGUKc8e5vMgYG48zF6OIaZ7zCCO59d6C3fdpVeWk66/vkpVTqYo7VOu+yyNQCiqgInVBt9dL8agtFGZmG+qhm3pT7gXqCxJG9gsu6hTITnuPf1RE4f2PuuqVgmgpuw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QarJfgF9g/5flg1xagl890+J4zMA3W8YVpn0X0P86kI=; b=bD+ji3ZxHTE97vq1o9w1cSSj78EjzOAuvdK5UXau4/w4BO1jYompsAKoeo4+fMAyIFfVmY3XdD56US9Lu7tZFq0Wu1mPBe/D3G0xfxuhNkD5+eiZCEr069+QrG1OOBRd6EQwlMsnZAJtKhcm5txfGN2ofzPkHm+iosClkD7wpXI= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8247.eurprd07.prod.outlook.com (2603:10a6:20b:326::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.13; Fri, 9 Jul 2021 10:41:10 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4308.018; Fri, 9 Jul 2021 10:41:09 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: "netmod@ietf.org" , "i-d-announce@ietf.org" , "Rob Wilton (rwilton)" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-15.txt Thread-Index: AQHXdK6R7sCQcxOFREiYRXjU1qJhJqs6c+TA Date: Fri, 9 Jul 2021 10:41:09 +0000 Message-ID: References: <162582703992.23575.3820243303774593093@ietfa.amsl.com> In-Reply-To: <162582703992.23575.3820243303774593093@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 18b50a30-71cc-4df1-51a8-08d942c610a6 x-ms-traffictypediagnostic: AM8PR07MB8247: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hqyxBCdS8as3OTlZginT/tM7259amJNaRXbSAbbmErv1swLRQeNZa9l2adfb+sBE9H2v2BLu8CqwrAAKZQQoUcFVaXB/7Ch+bpycgLVD7fb/ycGau2ro3t/EhiN/eh79epITcDEIhdO7oeavmuSl1DseJl2HyvkrVbZJlLS9Okwz+/JRh4XBRKsPCWGtofWWFPqfdbXCj1p0ZOWyXhf6fgVb3h5Z2X0RUdghUFWf+vllgBPvg+IfMfXQ9fVcyeGv3eOjcXbj1r0wFGAmLLS8Hp1fUgrYOiUr76yyyIMBCbk9IDudV6+4wP38EJdNUYtUHoFnpH2OhhMZYqI27yA0flnr99M7jpzbvjxaNTejtCe2Ewibnaz11QSN3D494/nNmZwW0vCnEv1T1wGzwmeDBaZwesQ8FfW7Ve+iN488uhgSOVWFcft0n6EzgnN87u4JrU2lEFZ1P5zHzPktzLVN5Q9lHmNkYgEDYKpXlRQAPPYGqSnk5KOOjkljB4mycEvSK/Y+VtK+IXbgfoW7loT4e1FkIZQZjZI2Zc7B9C95JPJObB07wfXn9CkgWnp2uty7/i48TfEprrsmkeM9uXor2tsCj4kwfCSUZ4jT/ZGKb+To5ERcaeBXJY6+lDAKHSbnqWoZBaGEFSxbTHvtNYM/lmyH9mE3xhqPkCw8O/2cmUFjN7B3gNqY6B4X1QK6XwW37YtzT0htSS1iJNjKsWa61q4b2lpX2daMnpklPhylGHwbNsaUmka9vfn34WSge+KH9UDunhQVB5dqD87lRGCrMA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(39860400002)(346002)(366004)(136003)(38100700002)(8936002)(478600001)(186003)(66476007)(7696005)(122000001)(83380400001)(52536014)(5660300002)(76116006)(8676002)(66446008)(66574015)(6506007)(9686003)(53546011)(26005)(66556008)(86362001)(71200400001)(64756008)(99936003)(66616009)(55016002)(316002)(2906002)(33656002)(110136005)(66946007)(966005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?P2/uQoi2hXwkHj46mWmbcaLysXH/H+ts7fYC0pwFLGYIs/whc5kNl5GrK0?= =?iso-8859-1?Q?j+dqhPAeb24QKH4MDxIghOqN7Es75zbgYgjXlKeGnjpej6JPuWuRn5ywbH?= =?iso-8859-1?Q?RheqRDR/KYpa0QUFjuZ2yZtH/DUyRBv6TVmSw7Z5nBWph8jEwsUfrs7IuT?= =?iso-8859-1?Q?R5GFHxo1esXXf8HpKYP6EVvsyVszTJat/qyFPWIiA1UNhUs0/1iwdm2kHM?= =?iso-8859-1?Q?u/N3ZRfCw0n79p91iqWuhenSam6F2V5G/pwGVXQyGudXZWX6QUvwZ/mxuz?= =?iso-8859-1?Q?Ngf+ChPSxX/1Duu3fhzeqQb4Avdi6NPfLNSOpHBNT5bxjb9VabUILyxtww?= =?iso-8859-1?Q?I2iegcdqE6ffk00yPdZWKTP6bIflWxNZL7NhctKd3fLYk9WtobLr1ykMnY?= =?iso-8859-1?Q?SP1IbxwgRM5hcFgie8Xdbd+tOFj3YwanwgZ4Dsrqc7InngRMZFv/omCMfL?= =?iso-8859-1?Q?zLEvtvAhY1VhGaPDcntGGSBN7mxFNOYneiBSMXGCdubiUMj5qEN1eWjMSZ?= =?iso-8859-1?Q?vHkwg2p8xWGFk9e4QEyOGEifZqRz44mLF2j9G7pAYHviOQF7eie5KD5yOx?= =?iso-8859-1?Q?ahKlIS/B1n3lo63r8PMLQRPlN3JgiYCKnH//8bWj6JJ1wRnpc014Z9ucaL?= =?iso-8859-1?Q?Nvwnjb4S8p8uiCcJF4e2pcoU4G+2dVcKuUK54OKnogZnLK+sb9FFr7uGgA?= =?iso-8859-1?Q?LZOjOOeCmdFHHc4bBxJnW0pVhEa6NFY9TPWZ2PkSxUtpRRNbQDy97Q1nMQ?= =?iso-8859-1?Q?p1w8md4kpsUXGHGtXq0TkjuOUh7PKS2yWyQl1K60dYZPctwDs+x9l9XK1T?= =?iso-8859-1?Q?KnYmOs5F7yN1cyUCYwyBWoWhIRXojgaph0L22+1qM1hiUrFd3sP1f64Ton?= =?iso-8859-1?Q?CnldH2KqoCIXFbZ63XRqGkX+PYFa/wkfr0+RTGcsW3t8XcxxZH4bp9KzGN?= =?iso-8859-1?Q?RiBNzL3MbRjl6pNzMFR5VqwjaPHFPxRFciL/S48oufx4B/gpPZtJtcvbow?= =?iso-8859-1?Q?/nJtBux5T9o6JVF/TNeti4Pv688albe6DR8f2/EykD5zGcye61DRN4hhd2?= =?iso-8859-1?Q?66mCU6HSyE2JE6nrLxL0hR6wH242fE+rYhRkI+VXSDDDOtDRl2F5VCpD7P?= =?iso-8859-1?Q?SvkmjPAXpjbLGRXg92ZnbXRgXGuRXgeWKdzCabSAteRIQZuiGvaE9sMmP8?= =?iso-8859-1?Q?5se08ppOlJUHbsjddYhMxsEA5nXD5PsPdu5ZtPkxxZ58gHQI5LgOSa5BJC?= =?iso-8859-1?Q?SVzb+PcSBSjxrJDcnbQC8jXqBEBw9YHMEW36i4Gn9BM6qyZKz/0KvyrEvU?= =?iso-8859-1?Q?TJrJevABZaRDR7KdnMmxfE2fiL3fxkXR0IxdRX1Jc0hrigOZi+UpHWy1rM?= =?iso-8859-1?Q?+mKp6thc5a?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_04F8_01D774BF.B07F5770" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 18b50a30-71cc-4df1-51a8-08d942c610a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2021 10:41:09.8515 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dIItjPQkKO2IbrWFIiyNGwQp76kD6gXVdfz6NDelnm0gf8cDAr5YI1/6wVw55vysqbrHveu8x8mbsaXxrydky7zm5Y3HVzTIKSU9LteII0Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8247 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-15.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 10:41:18 -0000 ------=_NextPart_000_04F8_01D774BF.B07F5770 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Rob, I included all comments from the AD review and associated mails. I = stored an updated version of the draft. Thanks for all the comments. Regards Balazs -----Original Message----- From: netmod On Behalf Of = internet-drafts@ietf.org Sent: 2021. j=FAlius 9., p=E9ntek 12:37 To: i-d-announce@ietf.org Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-15.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : YANG Instance Data File Format Authors : Balazs Lengyel Benoit Claise Filename : draft-ietf-netmod-yang-instance-file-format-15.txt Pages : 28 Date : 2021-07-09 Abstract: There is a need to document data defined in YANG models at design, implementation time or when a live server is unavailable. This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models, and annotates it with metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-for= mat / There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-fil= e-f ormat-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-yang-instance-file-= forma t-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_04F8_01D774BF.B07F5770 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDcwOTEwNDEwN1owIwYJKoZIhvcNAQkEMRYEFJunj+nHnbNs Q55lf8yuPbeRWF27MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBABSe SZkrgfWRhmmxcMYc2YN6CYSa9BD057YZpYkQnOPE3ujhhGuUBlicMiNn0nJRX/r7s9au0YUlVMRm idOAwjh2wk3RFdwzZ7jHSD7LGNDAE00PKBPDuRRu98n5GuCAeRJTnk1rfuiICXAB2EH8fME2Tize T0R9IWTvokivZLVLrwtRtkA/HQvw/XciN/cAEvwCSRrvw3lhK3Kn/+6y+BPSbla2uHoN44WIYM94 HG5HYzGKianwodeo0VB2x45ClBYrMRN8gYfdCXBM5h9pgUc3Hl4OAVvgDahEq9WTFgu5610pbL1I Q7oQriNlLyZortGjAK28q+GuwboTdakYpB8AAAAAAAA= ------=_NextPart_000_04F8_01D774BF.B07F5770-- From nobody Fri Jul 9 04:50:00 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A833A1E73 for ; Fri, 9 Jul 2021 04:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.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 QwfSMCDL331i for ; Fri, 9 Jul 2021 04:49:43 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2058.outbound.protection.outlook.com [40.107.22.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 A270B3A1E72 for ; Fri, 9 Jul 2021 04:49:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y+u0tX4y0HGHZoT9JKBf67xbazbGDIdrvclbVdEz5ZVZEfmbLfNnTb9k+Vogjac5J7cNtk9m9CVq1WMfFy7yrHYLnDDH1L2qh83jx9jcrKismDpzPSjKMjMfJcbIwvaXaJlK10iSqURLTaW/fQBV2eqsmlWiNvYTM/GiPCDIkPw1Q9nuJz4umFuKwRi+NKS8FSCJnMzkuIhnhOzaLoUn/r0BGIM1q8WTeo9J8i7OnZx09K+G0bHyBYXeFYO7tchig8GJCG1TJIcRDsToRzBiN2w6b3r/mCGXzjaTAenZl8mqZwsa98iMMyfVeI/XpwqUcyceJQQNZ5zi/s2naYru/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x6u5cxgnuj1Z8V0oHTlBtS72eja4b/vcqR2X2QeM/lw=; b=oc2TwjPAFNf7r+yJnaWbbJ7EEQskBg4m2HeWJVCrG1EHJizbuyn600fHwjnW0z9/FO2sSfOOSEJP8cOx7OKx+qk1A0u+wNokQEaJQ721i/XisxQp0VSLptYBdEbcGi3tu/zboI6Qsk1fWbZR/nPRevswtWRrfTnyaDLh9fYOruldrYkF8h8eOKpq30zOyWMkyO7pet/awBweVWfVzPkzbHrAGk768uaYmGeizsZpn0aGtR967/3DMcju9+PV/ULc8M10vP7jlhFGJJIEfJhXw4HwlyWNyf44+KLHCwOKXO+Qy2JM6e6mu0wx4Z9jXl+8WfnxVK00p3dv6C2ea+fJqQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x6u5cxgnuj1Z8V0oHTlBtS72eja4b/vcqR2X2QeM/lw=; b=n47OJGSS7/qxrD52FvavRrd8EzdiwtqGTxU1cJXVj0+R+YcvB/1pXExj//xQxMd65OfjWjt0uvptCLvGyCnP2k/vPmrPA9cw0I0OG/yKD4VW7eh/y1nmTBDfvPP4jon/27xmeCPMqZCWYJeWPOs/BAVO803s2slZmeJjRtPmNXM= Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1523.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3ee::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.23; Fri, 9 Jul 2021 11:49:40 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::d505:1bab:3e82:6d6b]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::d505:1bab:3e82:6d6b%4]) with mapi id 15.20.4308.023; Fri, 9 Jul 2021 11:49:40 +0000 Date: Fri, 9 Jul 2021 13:49:39 +0200 From: Juergen Schoenwaelder To: "Rob Wilton (rwilton)" Cc: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , Andy Bierman , "netmod@ietf.org" , Benoit Claise Message-ID: <20210709114939.fig4njly5yu6dwce@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Rob Wilton (rwilton)" , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , Andy Bierman , "netmod@ietf.org" , Benoit Claise References: <20210707192534.4emim5a36zyqrktc@anna.jacobs.jacobs-university.de> <20210708103528.6ezr4v5qeltinvmv@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: PR3P193CA0017.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:50::22) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR3P193CA0017.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:50::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.20 via Frontend Transport; Fri, 9 Jul 2021 11:49:40 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 301a7b3f-e0a0-4f52-be0f-08d942cfa291 X-MS-TrafficTypeDiagnostic: AM9P190MB1523: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3xrFivOeCMpzQeIhAnnTTKWoB+4iRGg27OlL9PRjiMRbfmTFQCUBAgqwyyXskfqzd3578uEye+JlPZw8GCxXmXOFSS/AiPpawpQU/G5R53eezB9YXwOuW5j9P0ISo7+gfQktiSg2YP1CbI6tW5JtbTFgEvsrmCBTUMUxlvaIGXAcQzPdfcqntQnBeT+9LRj71dV3ofpdyvvnm42yR6Vaqz3w+sbPfhNXApyxuh1ej7Ya5sabikheAkll2Z83Io/RGgfkCcV3LO6XuEZdK1+kwx8eAfnmnANQCMZjqSnooRG1Jvv5iyhBwlf0HjZzA6c/QfayuAVz563hafEem8w/rOSLStUAWDTkgYRz7CPeT/PielkAJUTvAeiE4UVSShr/voQ+SYthL40fwSWQ6Y7rRVBClaZ5KEBGk8VFDPJbSrz0iNMvkMkAmi9amQ28eSxEpc/5d0ULncTUJ1Tqu0O/sgVb8+JAwqYSx2YHy1WqVCul1omNnpF6wzWd/r4Lryqmwtl7PB3IwbCQ0JyqxrYmGr+S0j3YlB16MEMwHa4hLk2ZbwZvNcdR3Ry6jL+rXS5LHHBAVUNhjKqP7AtFAdRDB+EcZ6ZAh0WTZtAcr7EbDbbMyIyFO4JXqV2KvVashhg67Og7hmcF3UsyJu9KqZtLS3e8SqOhOheEbUUFhpcHt6nmdIAQELqbDQXVvDggvAhKM+0yS+AeRviibi/MPS15xR5WQZEK83D+S7hjkp86dRK8vBMqvauRdWOx65IqLa4hOnj/PsrFnp1811o05FuLcNjVDSLBxLoAcxbVqcDkIbU= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(366004)(396003)(39850400004)(346002)(376002)(66476007)(8676002)(66946007)(66556008)(54906003)(26005)(6916009)(5660300002)(38100700002)(4326008)(38350700002)(316002)(786003)(86362001)(4744005)(2906002)(8936002)(1076003)(3450700001)(186003)(956004)(52116002)(478600001)(6496006)(6486002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?HEW0/AerpmuW5DfMkvvq42Pxh0XMpS1Q2K3P/GSAdeCAwaMikSLew80ryjog?= =?us-ascii?Q?ECFlbEPqd+gf6tK48KZ24QNGY7UTSc7u7A9zpkzrkjgtd9dSdjzXLYShFZbQ?= =?us-ascii?Q?zHyCZWuXjsA76K6YwH4IMu3nl2LagiozhrC+wohurHoKS2in9XQqEUYeUBI9?= =?us-ascii?Q?kX94HpowN76lzKSKuWQmRAINl9qJ07E3Qanz5EDJMX+kaXpp99cGh6wHtyfl?= =?us-ascii?Q?uqhWsBFhYLSnnrZ7wMeXsD3V2SjwcvWzcGLEOdk8pTIS+Zj7h0mW6sc0fhDq?= =?us-ascii?Q?wdYZ+vHa+0rrOr6dTXYsTfeTBc5K8dbDQaoR0Ad9NOe2kNgROoeudOvJ6xRO?= =?us-ascii?Q?A0LhYrXRKfTruys1yhye9VLzlU2u2XR+jrMVA3Js9mdGZEqV1D7rxU7M5ArM?= =?us-ascii?Q?nQmTquLrQuR5qibHgGVdGPWdOeWxb+iWlGbqbmh7EilPsv9vmW7cATeqvOnY?= =?us-ascii?Q?jelm56L4MAldoULpnPmtTa8y7d5kHan3jlyV/VanUNox4LDhinSTgopNdXJH?= =?us-ascii?Q?XdcaLC6Gso+H3F4u5eTvHhoN7wwlgzhorNnI4lzXB9UfG/JuZ710gnttEj5q?= =?us-ascii?Q?ObZIBRKU2KJNUekufaHiYJsTvx3jZWDNydTYi/MUgDe3Qla0y97VtlkVpzV8?= =?us-ascii?Q?Q/9Tn1EDWjlt1SqwNozOevyCi6mY53iOAdKPF9Nw0a7TuDRR/eNQyVh2zAEv?= =?us-ascii?Q?PUOVAjZ9QPwbrcfPmlNgKliHGbkF43Q3gvQ+AipqViGm4cRSkjwRVVs5ewnY?= =?us-ascii?Q?VneKkJ8d3iKoNo5iH51BZ7NYAI3UOEP1xQQekxvJmuNJZNP+OtW5YS2YSKST?= =?us-ascii?Q?BK+6aXVGqpt1FKSyrX+P7iEV1vrdtOv9WqCUGbYzo1/tkrXGHhhmyeFRXdXa?= =?us-ascii?Q?cPwiy3CIvRQPKXWEGNQa+HDxIS4NfUbB1ChjfK3Mhz3a7OA789+YGZhYpJwo?= =?us-ascii?Q?/ANvHEj/SFpWn2XmYBw/fdzpfbZCx8FcSClOzUy6seYqaJLdO8EGvMmsRtR+?= =?us-ascii?Q?iWWhUoz8h+/hwwjNVXZwVCXQUz4zNLnMb0YddvcAaJOlV1Fl9ZdK0Ify609L?= =?us-ascii?Q?XbETJpLzAUSf1C9ZMTPQAXmRvO1Pcg4VNZSsq8bibL3XUS4uNQ1iJPohNYK6?= =?us-ascii?Q?JVttpf6jzfdx4ygnBLlSZ8t5s4oUxIljdSnb0eTH/BRl7ZOwyIQHMXB6A4EM?= =?us-ascii?Q?D0SeNHo155gtDfVIrGaZro2BPlRYkwTczoCekvlM5GR5fcy2xm8mTdnOngE9?= =?us-ascii?Q?q6zjPTMtq1twP1bYybIZ2+nN9+7VXfyIpEMC8AvW6K9tHY88rLQ1vemRxkh6?= =?us-ascii?Q?xYc2B0Xkt2HC96hSc/mVzTrV?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 301a7b3f-e0a0-4f52-be0f-08d942cfa291 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jul 2021 11:49:40.4422 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: K6uupOfpw7r/7xHLnOuPPCsWydrBoozHT7n49s7sfRu5ifmCROwxzQFJmPdmShE3T/E/S4pewqSuEKsSvPneh+EDhrsQk4LjvcZB+RxhJtw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1523 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 11:49:49 -0000 On Fri, Jul 09, 2021 at 09:10:34AM +0000, Rob Wilton (rwilton) wrote: > > "YANG modules that are only required to satisfy import-only dependencies MAY be excluded from the leaf-list. If they are excluded then the consumer of the instance data file can choose any versions of the YANG modules that satisfy the import dependency." > Sorry, this wording is a bit wrong or possibly misleading. I assume your intention was this: OLD: If they are excluded then the consumer of the instance data file can choose any versions of the YANG modules that satisfy the import dependency. NEW: If they are excluded then the consumer of the instance data file has to apply the YANG language rules to resolve the imports. /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 Jul 9 05:01:25 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300A33A1EB9 for ; Fri, 9 Jul 2021 05:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.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 PbhwACzr3iwr for ; Fri, 9 Jul 2021 05:01:18 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on062b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::62b]) (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 AA2A93A1EB6 for ; Fri, 9 Jul 2021 05:01:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eIfsbmAk3SGqXtozmrYxOIYjp8jM4xtCFhFN5D7rD6t0kllksPUiX5ceLG8kPNaGARFf3ybok2fteLdMogoYvBdo4J7LAqr+fijLwDHEgmPNPzxxZMjU0rCj0F1zq4Q7e3BwhkLoA20+ZM47rkEcxajhke1YbSPuYvkJmmZu/bX8fEyXmDom51TBKwtBV8OYIA0JrOxmB46/wauzvxixrRacFPnZBxNOgenXhq2erR7mPBwAq/9lHSK8HikLotzGM0pyjIIDfbZV6WRkFHKjY1nynm6e057iMybSOSuuagw5eJmZ3kqFxsC0eFfs33qJWSPd1Qk+DMd/HHQMLr81iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zCI2q8oz/rpTCQA1q/7GDvYJwGmZTbqvHB/rr+QICWs=; b=G0/xavFUMdkpuyNVUJ17/OIIv49OkfjHjaDik6BE769kRMHcDoJzGJ5BH68LiNBvTjuDINrBDieCO/5t1PXF1xtNWm9VGEoEGHaskjKFGr6cj9iDepMlqHPgRbfcMCMRzZbquGO6j9AxwzBHslpF4i4nvDciSBEJYTTlE30OW5qWQNJcLLQ+MsVmwCzIQTmGPGfX/V84YBQi9omQN5dl9VE/TFpbvhmWeal2dS3pmwnyEMKkM7GywihEXTYoq5EjZ+k29CPKS0qrCtLvfOTKKqCe9byk+tmi7Hv/3EbpQu47N/G24WOyoZzDckE9bQMKPdXjYG9mqU/rPH0E12X5QQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zCI2q8oz/rpTCQA1q/7GDvYJwGmZTbqvHB/rr+QICWs=; b=JJAt3CA6F5TDW5oo6LVL/U3DUqCSdMAtePxqS6pZmK9K3k4Bt/0t4nYOgBYKAj15ASj3wjttJChfspcFVtNV/tLMLWzYUi7kOkqfSDM27NJqd4KJ1AWMUe7I0CZq+eIQpEfoPte7SyG6qOQmnshHXFmlCU81aukmU4ZXEKiGR2U= Authentication-Results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM8P190MB0996.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:1c7::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.23; Fri, 9 Jul 2021 12:01:14 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::d505:1bab:3e82:6d6b]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::d505:1bab:3e82:6d6b%4]) with mapi id 15.20.4308.023; Fri, 9 Jul 2021 12:01:13 +0000 Date: Fri, 9 Jul 2021 14:01:13 +0200 From: Juergen Schoenwaelder To: tom petch Cc: "Rob Wilton (rwilton)" , "netmod@ietf.org" Message-ID: <20210709120113.5wjlywlpuowtkfwc@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: tom petch , "Rob Wilton (rwilton)" , "netmod@ietf.org" References: <20210706174208.4birungsifwtiryq@anna.jacobs.jacobs-university.de> <20210706181933.yodqa2uhnfmas5tb@anna.jacobs.jacobs-university.de> <20210708101326.wuzvtjesghpq5jq7@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ClientProxiedBy: PR0P264CA0250.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100::22) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR0P264CA0250.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.20 via Frontend Transport; Fri, 9 Jul 2021 12:01:13 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3beeb117-3be8-402d-186b-08d942d13fe8 X-MS-TrafficTypeDiagnostic: AM8P190MB0996: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MyUpoQkBtHURpccxl+8qUD/CA7U3HFZSVqxwXo7R1/ZZPHILwrWBn+A0V667tM9KqNSg8f3jXZSeJlLJguhZQDBMSNmODlGUK9KjwenebfGlB6eNAR7JiQrchS5MnYRYrKh6gC7EbMfHkICB7uMC4USF0jxEqe/qstlBw0kbbLheqnLxwpyfvKLQ5at3s689eY5Nb8gDLtW3ekuXmyrMD/lBrFN6tvVAHom2av4C1yWB6hbCLquMPvRxpIZc/ppmPr72Ecz6K4WjuAOhe5hz8lG0VP0N/pbtqrnEbODZJJObkDskLiOtJExvK2F5AlwHC659t+4YijQiLMzikvRm2Imd3Gwa+p35g66lXCKLOjjbbdyH9Ot2dIRWpAWhXaCQJPZg/HHGTHWAsP9s74nPb5lp+Fc3o0kTj5ebNUeGOeb+NPRZj8Ezg6e/i1XIWlINHUbhbegFe2LP5/dPPfUsh6dIEBFGVpdpUA2RLIvpVqdd09uFI4seOEhvmOSJ9p+YxhoEoa3VtdfoKzsLm8tutEzW4lQfhp9rvt19HqxG8Wegs7j7B9UdcjGVSstUMY8d3JtEcpq92YoyGO9QL6y3wjPtkqwLI24BKbNgDlyLWjfp2ClSn0bYs7GKFNwhLAAUDeKkFXgxzQBj+Rf0yy6nvXexbUby0+X4vIiU4e6ny47Fvg1GGKOuZ2ZqJ2lXkGQHOPpPIztIjI7lIKTScoSIelvZMlBT2bY5h4h7U8jBfqQHPrxT1e0bzrUBaFhjlK3M70HK5k1uKgxecRlrCAMLGg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(38350700002)(498600001)(966005)(956004)(186003)(5660300002)(38100700002)(26005)(2906002)(6916009)(6486002)(8936002)(3450700001)(86362001)(66946007)(4326008)(66476007)(66556008)(52116002)(54906003)(1076003)(6496006)(296002)(8676002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?xtX70R8bdYQa/7mrB6Y6j2kF6P3Ki/pbj9oa2DW4KP9YC2eNRGq1dnJBDavB?= =?us-ascii?Q?Xc9zDSiOqaCFAdICgd4ZuityglgTO7zeQlUz8lCooYVoKivJ1PP0d4ZgLZ84?= =?us-ascii?Q?lOjG7str7FkTEwVVf9B8uNbqueXhAGgjRHn95R6RwOUx9cuS9YyFmMEOTykU?= =?us-ascii?Q?uvoa8NmCTdBr71WFIQ7T/u92vgsQ1wwzGoeO55ICE6+1QgUTsE68WpFAdR6U?= =?us-ascii?Q?SjWTSY2vHPbEwYcMrCu0Llt2Aze3j49xGj6bGxGFEqMiRDoEI3fsTHnoEY6u?= =?us-ascii?Q?RJ8Ou1ipd+Rx98OF9oiqS27rNcK/WOYL0DiAE+1qVYRdma33p7yveY5flywt?= =?us-ascii?Q?kTvwbBKtTYIJRUvAYdGRNblLuVplFqVY6+kYC+SanE1ikoMOaETYhXFnnynN?= =?us-ascii?Q?EkjN03cRDa5OAvPvVxqhG9kB2M4OhvERQZ6dV1QadegpVIPg5q4ov61LHmYl?= =?us-ascii?Q?SH1dcGbDOoURIgq9cKLivclvUAx2/yb30YzfhbPUUdgsjiSDs6WYCkoH5cMy?= =?us-ascii?Q?KUJs9OrAEJ+kg+89RETmxWBG2ZbZKw++FTVTqV0DUsz26i92life3L7yZRGL?= =?us-ascii?Q?lhCqCYRNksygofONI5rlgtaTvwRRh0UletSOp6DJToP0SJn3U48MBrecO4RI?= =?us-ascii?Q?kh9pvdWywgC/vdzpostQ487e5Z5Kk4HNY6ODaS2cskEqAfqbdzcGUbWAbzO8?= =?us-ascii?Q?SiK4r5tMlTY+l2c2xjKn/z8efiSKc3NKYFzfZTsvFvbVtcErDyaeIrCwUHyw?= =?us-ascii?Q?8j088br6K3Zxkue733h0foKuVGFu0EAkU7nSGznPSalW56yxQgsyQDVtAT70?= =?us-ascii?Q?zxe2i4Sq3CMP5Bf+Y6iSd6/T+VceEpgTNgowuWZJxnW4TkfZzjQmTAaEjNsK?= =?us-ascii?Q?g/MWyp0Tm42m/btVaCZqFTNPTr4pWbOz8/aDZ//tIzHP3sZouiClsAakUeBj?= =?us-ascii?Q?hMmKew3YyBhURDtJ66B8AObL5ef36Yilf9UuuXADKPV+yhcnPvrg5mQ4S8Ok?= =?us-ascii?Q?cXYQ9N02+07AZWf1b7E1RJ15Zjim51xeTF9C7vl3rX/OnJUyebYa/GshhnbG?= =?us-ascii?Q?yKb/QwjVyL59b1VDo+ocL+78gwE28v+uj4TEUH2He017fryi3XT7YEWeEFGr?= =?us-ascii?Q?8fDAYv+9WDfsOeRkYsRn6DfH8RvCWDx4aX2Z1WO90xYB9I+f6vnlcMaOD/aU?= =?us-ascii?Q?W9Wy8HyPtwTwcUTxd7f7E3XD6WphKrWzaU4RO/EruUc284TQpmz4cHUuYtTI?= =?us-ascii?Q?I1T6gJLNSl8loYtcIuhXu4De3tldg2qL70M2DKiaJWPhb6bNaWISje1lvRHf?= =?us-ascii?Q?UBLYpSz4u6BhMnlQJZFUDGIa?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 3beeb117-3be8-402d-186b-08d942d13fe8 X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Jul 2021 12:01:13.8593 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: gIUDuD6Hu7Nx7pR9mT/j7g7O6TlVhfwUxFNejVc+Q+GyV360lEFDSMP/DgJDxQDqLlSoammLTEtjCh0V5Qe3zdukP4sO8n4ioOLZA7INwdo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8P190MB0996 Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 12:01:24 -0000 On Fri, Jul 09, 2021 at 08:57:34AM +0000, tom petch wrote: > From: netmod on behalf of Juergen Schoenwaelder > Sent: 08 July 2021 11:13 > > On Thu, Jul 08, 2021 at 09:30:27AM +0000, Rob Wilton (rwilton) wrote: > > It is perhaps worth noting that the NETCONF copy-config allows for the configuration to be specified using any URI, but the server capabilities announce which URI schemes are supported. > > > > Hence, I think that it is okay for the YANG model to use URI, but I think the draft, and data node description should constrain the URI schemes that allowed (perhaps file:// and https://). This would allow support for future URI schemes to be added in a future revision of the YANG instance data module, if required. > > > > I think it is not "allowed" but "mandatory to implement". We should > allow implementations to support an ftps:// scheme as long as there > is a common baseline. > > > I am confused. Is ftps: intended to be an existing scheme or a hypothetical one that may appear in the future. I do not see it in the IANA registry > https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml#uri-schemes-1 > > sftp: appears as a provisional entry in the IANA registry but AFACT did not get specified. I recall a debate about ftps: v sftp: I favoured the former but lost but then I did not see any further work on either. > I used 'ftps:' as an example, I should have taken the time to find RFC 4395 and then I should have picked 'example:'. /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 Jul 9 05:23:32 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E1C3A1FDE for ; Fri, 9 Jul 2021 05:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.594 X-Spam-Level: X-Spam-Status: No, score=-9.594 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=l9ZIP8Lu; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LO+yoP4L Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF39qs_ifWRf for ; Fri, 9 Jul 2021 05:23:19 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 371F13A1FA2 for ; Fri, 9 Jul 2021 05:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19356; q=dns/txt; s=iport; t=1625833395; x=1627042995; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=oUWpieuNQfvN00e5h0vc4zwpZcKkt4D8AkoF6d33aTU=; b=l9ZIP8Luto62csQVb10gbN2Vvu+cjwI/ha5jUkcVVPfl+5PjvaMx0Y4g nH046NbZEaC/J1lFRHuB28FFMxLZy5tKW98oDHhjoQxq2ERBUYQ7OfbBY 9sbv9dsTpNj4dk1aoybvxomioANfXxnwCVcTiGZPp6SKHOVUlefG17wnT o=; X-IPAS-Result: =?us-ascii?q?A0ACAwCDPuhgl4wNJK1QCh4BAQsSDIIOC4EjMFF+Wjcxh?= =?us-ascii?q?EiDSAOFOYhcA5UohQCBQoERA1QLAQEBDQEBQQQBAYRTAheCYAIlNwYOAgQBA?= =?us-ascii?q?QEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBAQEBaIVoDYZFAQEBAQMSEQoTA?= =?us-ascii?q?QE4DwIBCBEEAQErAgICMB0IAgQBEggTB4JPAYF+VwMvAZpoAYE6AoofeoEyg?= =?us-ascii?q?QGCBwEBBgQEhSoYgjIJgTqCe4QMAQGCZ4N6JxyBSUSBWIJiPoQXEwIagxU2g?= =?us-ascii?q?gwigmmBGycwl2CIMY0zkhMKgySeSBKmR5YApQACBAIEBQIOAQEGgXIjLYEuc?= =?us-ascii?q?BWDJFAZDo4fGYNXil5zOAIGAQkBAQMJjAEBAQ?= IronPort-PHdr: A9a23:1FzWfh9Ynzv6sv9uWMfoyV9kXcBvk6TpOwcK7YAkkPRFdaHwt5jhP UmK4/JrgReJWIjA8PtLhqLQtLyoQm0P55uN8RVgOJxBXhMIk4MaygonBsPWGFD+JeHtdS8hW s9FUQwt83SyK0MAHsH4ahXbqWGz6jhHHBL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4= IronPort-HdrOrdr: A9a23:GzSLE6DXILM/am/lHeglsceALOsnbusQ8zAXPh9KKCC9I/b3qy nxppsmPEfP+UossQIb6K+90ci7MDzhHPtOgbX5Uo3SJDUO1FHYSb2KqLGSvgEIeBeOuNK1t5 0QCJSWYeeYZTMR4KqKg3jbLz9j+qj8zEnCv5a4854Zd3ASV0gW1XYeNu/0KDwTeCB2Qb4CUL aM7MtOoDStPV4NaN6gO3UDV+/f4/XWiZPPe3c9dl8awTjLqQntxK/xEhCe0BtbeShI260e/W /MlBG8zrm/ssu81gTX2wbontRrcZrau5h+7f63+40owwbX+0KVjUNaKvq/VQUO0aOSAZAR4Z /xSlkbTp1OAjjqDx+ISFPWqnjdOXAVmiffIZvyuwq4nSQ/LwhKUPapzLgpAifx+g4uuspx37 lM2H/cv51LDQnYlCC4/NTQUQp2/3DE6kbKvNRjxkC3a7FuIIO5bLZviH99AdMFBmb3+YonGO 5hAIXV4+tXa0qTazTcsnN0yNKhU3wvFlPeK3Jy9/C9wnxThjR03kEYzMsQkjMJ8488UYBN46 DBPr5znL9DQ8cKZeZ2BfsHQ8GwFmvRKCi8el564W6XYp3vHki956IfzI9Flt1CSaZ4u6fawq 6xI2+wnVRCDn7TNQ== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,226,1620691200"; d="scan'208,217";a="721757336" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Jul 2021 12:23:14 +0000 Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 169CNEdh005214 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 9 Jul 2021 12:23:14 GMT Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 9 Jul 2021 07:23:13 -0500 Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 9 Jul 2021 07:23:13 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 9 Jul 2021 08:23:12 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GZg+bQ8zI9DxirHTq+J93rZ1V/U7F7DBKh+Q/DMXSduDWbm8O9v2aM4NFSFs94fzBY3RuPR/qurlPS5/4bgLPrKPXqKKkGgPEiSb4Lv/DuE3RTxP/HCxzN6kwxDnTEHJIUgrj6p0/C+vgzMtp7dpm1Iqi7hBQMgvtAjV7IJFr6M736ITZ1XyWFWmSi5RS0vU/UqRDhWcMAxFghRgn4vPmkC04yCAPGmS6BG/5YYZ2LIIKqvKFZx9UtVScX3RmukZ/0rYGW+d6pEKPqu6+JAQd8VS/kcoYYyAqlGGV9SyGzwiXsvYPR90HiCi3SOPpo0Ze1ZtMhzYSGczm0ZzXS5QmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oUWpieuNQfvN00e5h0vc4zwpZcKkt4D8AkoF6d33aTU=; b=V8o+5LfV65m2GtlWgg6rza5/RZWhGUXJIFYo04y6fzOKuEbTXyiLBfwR5oK5XNXZKgOw/Qzetj6y1UZewfvuGCSiBVxtIyFrGsy2b9N2xCEX6UUxBd2aPSj68iMTmIM032COMb47aH8Qfg07wvBXmzaFzzXyes1UlAzCoWNKhm/V6zS9uRkoHV2tamOl16+o1c2aZ7QXbLZXPUJne3EkOTGqE4yFvANJfjAYUK4ppMamENtwdzkv7LSLlahlN6PMjRmvnfQw0dFglwD1RNgKqQEfabGCrTsiRTWJDKmyyARQYRAlRUriJd2vG3aiA98TvkFha8N9cepXd6EdNIDaqQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oUWpieuNQfvN00e5h0vc4zwpZcKkt4D8AkoF6d33aTU=; b=LO+yoP4LcE75SA+OXRiI5mt29CGvfe3cCvhsGRrvIsBxvMtRIlEGck2DJsLcCvgukd0cCrqdxIx18UP207JzqCpbC8ORfrXBFrSdwenJXiS1gw6JqUnKdFQ53EhD9LhZjvOtYHLpA4OxepfwIyXpe1LK20QemHX3n/5z+wyTMQY= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM4PR11MB5535.namprd11.prod.outlook.com (2603:10b6:5:398::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.20; Fri, 9 Jul 2021 12:23:11 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12%6]) with mapi id 15.20.4308.023; Fri, 9 Jul 2021 12:23:11 +0000 From: "Rob Wilton (rwilton)" To: Andy Bierman , NetMod WG , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= Thread-Topic: [netmod] yang-instance-file include-defaults leaf Thread-Index: AQHXdB0ZnZibUXpuT0+6mfsyEmKi+6s6kMRw Date: Fri, 9 Jul 2021 12:23:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f0fc9daf-5e3b-4b86-7874-08d942d4518e x-ms-traffictypediagnostic: DM4PR11MB5535: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4uniAf5YP8OvU29CjgVLXZw8MYArGvrV8BSG6ucv6BKr3+60jZZeTEJysfNDCDLNhCZBIgHud38s+UXEsNg1sAfQhUBatcv3PNvltLIwvhWzkCNPwaseUICd/BkANK0FPNniu9m1Ak/2iNrnwVwJQQ2juT1+TvgxF7ZzhMQlsYNyXxPsiWeiPT/mb/0hnSoeRPMyzT0Yfr8HelkEPMv1WYHlIZIHrr4bhHmm9tToNz5/YtdyYxMN6S9XvcRNp3mTJrUOcIZlqlTYCB5teZVc+1H6aRHyG0WNWlFv0r6C2EYN24h2PXBrmel4krP0OsPC9N8QWRl8D4cITwfLosM+mMDxIVZMgRwQBbGGj+oqMBLwnJSTFWnOEZzCIgeiPmEtH4fIDfYhfDoRgRcIuyRvWiQLRa7d9OJs4+0T8A5x8XGoPvIQ5NH9Rsed+FbWAEV+TmyyHKbM0ngWyy3gecakNBLLN5TMxP8og2HGTyWYwl+Eohc3Ry7HWwP/BqD4I6J9DX5AZNATLgzvFBmmF7UQY5ipF6VlKubFQ4ImV033cfdl+x74nA4Mk0qtIe8nzjjOkWyt81GDxd9iRcL3azjFNtWxsxFYEKeMfE3Bs4gZeslBhmgXpqgAT+RbgWrgHRj7b1yr/BnD80x3rgSUZdKR8g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(39860400002)(346002)(396003)(366004)(8936002)(53546011)(6506007)(38100700002)(52536014)(316002)(9686003)(7696005)(86362001)(33656002)(2906002)(71200400001)(186003)(110136005)(26005)(55016002)(122000001)(8676002)(66476007)(76116006)(66556008)(64756008)(66446008)(478600001)(66946007)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ejczM0tCOFI2WDNLVkFVaHFCNnEyQmhDQTJFZFFCRUU4eldjOExwbURrYi9x?= =?utf-8?B?bUVaMGtJZ3lYdFAvdGZ2MlFYbG5PSGFldU1lUTA2ODF2NzR5cXNBeTJKWXYx?= =?utf-8?B?dmQweWVEcjE5bHM4K3V6bjVGVGg2T0ozVHNYZUcwdi9Ya1oySXhScnN2c3dU?= =?utf-8?B?WGdBWWxjR1dUcStHM0FucUI3Tm5TOGp5Qm1kYnlUT0Yzb25Xblg5NUU3Umt1?= =?utf-8?B?SWFWVithWW1SS2VoditIK3c0VHRPa3ZNTDg1ZGpkV243N0xNUEplS1dQNHJZ?= =?utf-8?B?YWpIem15My9ENVFFMUxCbzVqL0ltbzdTWGNFWWxiOSsrS2VIUmFxS1lPMlFG?= =?utf-8?B?bUFwZFVpeHBvVjhrdm9JN0p6TndSR2Y3Nkc2ZmRUcTZDMkc1M0p1d2hoRDM4?= =?utf-8?B?NEF3aXEzc1JJL1dMVzUwNlZhL2pWeVpiVUJRSVhWeXVSRi9Wb2xqbERUNG4v?= =?utf-8?B?Uks4SnhhQ2ZFZE9WdStTRTdzWlhOdFM5RlRQbVBMd29HamhPQ3htWU1tVmhF?= =?utf-8?B?NjRHcTRuYWkrRGUxaTA4YWdtRDlkMmlndUxNNUR6RGdibjFHSHlRaWhEd1R0?= =?utf-8?B?TjhyZ21KY2FLR3gyQlVZbkRUaWczY29ZVE12bTJIdzNPWEZBaDN4QTlaRGJT?= =?utf-8?B?KytkTVI4cU0yR1I1a0dXaC9rZW1VM3ZaNHREcE9HMTZCWlpRVjBCQWVJUmw5?= =?utf-8?B?MllqZTh2eGltUEE3S2xkWkg3bEFxR0ZxNXRDWWt3MmdYVzRBdmpjRXdxZHJK?= =?utf-8?B?SEt4bThheXM5OTg3T0luMCtZUHlsUm5mc1hSRlFkVDd3eWp0MzNobGNwbXNr?= =?utf-8?B?WC9VbmJFTU1SUEFCK3UrT2FTOFgvYjNHTEtmVlJmeUViQzdkS2pjRm5XRWps?= =?utf-8?B?OGJOV2tIcW5qdG5iR0ZnVXZkZFNXaVhncHNRdmpCTWlBT1MyOVRKNGlTOVN3?= =?utf-8?B?VkI1ZTF1TGFLVmloaHJUcXFKTXRGOHdJeENNdVpJQk81RDFDb3NYYVcraEN1?= =?utf-8?B?ZU4zeHNHYWU3Sndpb2tHRk9XS0xjSkd2blN3MTRLYW1BSEFLWFJIL29YMm1y?= =?utf-8?B?T0JkY1pHelJNbGZnU1ppbVZaMXRxZ29FSjhsMGZCMExJZ3FsdEZINGZnREVa?= =?utf-8?B?Y0xqTWxOeGFkZVpBUC95dytEMVAwQURWVVBNRnVlL2MvQjBnYW1EeEh4V0dY?= =?utf-8?B?b2cyZnBwM3A1TW9oMS96QmhMZllnS0VzK2hWMXNJQ0taa2F4SFRNYktoTUhs?= =?utf-8?B?dnZzeHhDcGNMeGJTU0IzdlluY2JieXpyemZoTXBQVHovMWUya1B5V1prbEVH?= =?utf-8?B?VE5wREhRcGQrRzVQMTNxVW9BVXdwVFZzVktSK3NQOFNtcEFGRGRWNTZUQm1I?= =?utf-8?B?aXhINndMc0x4dnZOSDI4YkFERGF5RXZjdEwwVGI4aVZMMkVhTXFhaDl2OTF0?= =?utf-8?B?WVFrMjZLbmFsenY5aWlGb1A4V0hvRUZjdEJCWnNUeXVxYnVpZWFIWVExQnZi?= =?utf-8?B?WXhOSzlVVFJsdHlQbklYbUxhalZISjkrdG5lQ0VQaUhpekU4WUdNcUkwUCto?= =?utf-8?B?bEFHdnl4ZnZJVnZ1YUhmZW9SV1hkTVJFSUkzcmhLdXJFQ04xZ0sxUkFyY3pL?= =?utf-8?B?OEJUQnZudWJvODlUeTZ6ZytEVWNKVkhSLzJFL2FOcE9UUU92QXZIWGYxVDU4?= =?utf-8?B?VlU5cVBqdlpVTGlPc3ZFcFhic1FyNS9XcW5ZaDFuNzhzWCtsUGVjeGRuSkJB?= =?utf-8?Q?K8Y1kKMZr9McmWi05AI4sZf+lpL6KZX6+5tgfSM?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM4PR11MB5438F5874CDEB4D78C9A5695B5189DM4PR11MB5438namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f0fc9daf-5e3b-4b86-7874-08d942d4518e X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2021 12:23:11.6864 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yQolB7Nnec7XuxM+iJd+zHdAcUPBTTtve12eMgmoRhByBlb/zxoR6EjjBEg0IikXiTXQLan7/ofEF5+jX99GDw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR11MB5535 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [netmod] yang-instance-file include-defaults leaf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 12:23:29 -0000 --_000_DM4PR11MB5438F5874CDEB4D78C9A5695B5189DM4PR11MB5438namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW5keSwNCg0KWWVzLCB3aGVuIEkgc3VnZ2VzdGVkIHRoaXMsIEkgd2FzIHRoaW5raW5nIHRoYXQg YSBib29sZWFuIGZsYWcgbWlnaHQgYmUgc3VmZmljaWVudC4gIE15IHBvaW50IGJlaW5nIHRoYXQg YXV0b21hdGljYWxseSBmaWx0ZXJpbmcgb3V0IGRlZmF1bHQgdmFsdWVzIGlzbuKAmXQgYWx3YXlz IHRoZSByaWdodCB0aGluZyB0byBkby4NCg0KRS5nLiwgc29tZXRoaW5nIGFsb25nIHRoZXNlIGxp bmVzOg0KDQpsZWFmIGV4Y2x1ZGUtZGVmYXVsdHMgew0KICB0eXBlIGJvb2xlYW47DQogIGRlZmF1 bHQgdHJ1ZTsNCiAgZGVzY3JpcHRpb24NCiAgICDigJxDYW4gYmUgdXNlZCB0byByZWR1Y2UgdGhl IHNpemUgb2YgdGhlIGNvbnRlbnQgZGF0YSBmaWxlLg0KDQogICAgICBXaGVuIHVuc2V0IG9yIHNl dCB0byB0cnVlLCBkYXRhIG5vZGVzIHRoYXQgaGF2ZSBhIGRlZmF1bHQgZGVmaW5lZCBhbmQNCiAg ICAgIHdoZXJlIHRoZSBhY3R1YWwgdmFsdWUgaXMgdGhlIGRlZmF1bHQgdmFsdWUgYXJlIGV4Y2x1 ZGVkIGZyb20gdGhlIGNvbnRlbnQNCiAgICAgIGRhdGEuDQoNCiAgICAgIFdoZW4gc2V0IHRvIGZh bHNlLCBkYXRhIG5vZGVzIHdpdGggZGVmYXVsdCB2YWx1ZSBhcmUgbm90IGZpbHRlcmVkLCBhbmQN CiAgICAgIG1heSBhcHBlYXIgaW4gdGhlIGNvbnRlbnQgZGF0YS7igJ0NCn0NCg0KV291bGQgdGhp cyBzYXRpc2Z5IHlvdXIgY29uY2Vybj8NCg0KUmVnYXJkcywNClJvYg0KDQoNCkZyb206IG5ldG1v ZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBBbmR5IEJpZXJtYW4NClNl bnQ6IDA4IEp1bHkgMjAyMSAxODoxNg0KVG86IE5ldE1vZCBXRyA8bmV0bW9kQGlldGYub3JnPg0K U3ViamVjdDogW25ldG1vZF0geWFuZy1pbnN0YW5jZS1maWxlIGluY2x1ZGUtZGVmYXVsdHMgbGVh Zg0KDQpIaSwNCg0KVGhlIG1vZHVsZSBoYXMgdGhpcyBvYmplY3Q6DQoNCg0KICAgIGxlYWYgaW5j bHVkZXMtZGVmYXVsdHMgew0KDQogICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQoNCiAgICAgICAg IGVudW0gcmVwb3J0LWFsbCB7DQoNCiAgICAgICAgICAgdmFsdWUgMTsNCg0KICAgICAgICAgICBk ZXNjcmlwdGlvbg0KDQogICAgICAgICAgICAgIkFsbCBkYXRhIG5vZGVzIFNIT1VMRCBiZSBpbmNs dWRlZCBpbmRlcGVuZGVudCBvZg0KDQogICAgICAgICAgICAgICBhbnkgZGVmYXVsdCB2YWx1ZXMu IjsNCg0KICAgICAgICAgfQ0KDQogICAgICAgICBlbnVtIHRyaW0gew0KDQogICAgICAgICAgIHZh bHVlIDI7DQoNCiAgICAgICAgICAgZGVzY3JpcHRpb24NCg0KICAgICAgICAgICAgICJEYXRhIG5v ZGVzIHRoYXQgaGF2ZSBhIGRlZmF1bHQgZGVmaW5lZCBhbmQgd2hlcmUNCg0KICAgICAgICAgICAg ICAgdGhlIGFjdHVhbCB2YWx1ZSBpcyB0aGUgZGVmYXVsdCB2YWx1ZSBTSE9VTEQNCg0KICAgICAg ICAgICAgICAgTk9UIGJlIGluY2x1ZGVkLiI7DQoNCiAgICAgICAgIH0NCg0KICAgICAgICAgZW51 bSBleHBsaWNpdCB7DQoNCiAgICAgICAgICAgdmFsdWUgMzsNCg0KICAgICAgICAgICBkZXNjcmlw dGlvbg0KDQogICAgICAgICAgICAgIkRhdGEgbm9kZXMgdGhhdCBoYXZlIGEgZGVmYXVsdCBkZWZp bmVkIGFuZCB3aGVyZQ0KDQogICAgICAgICAgICAgICB0aGUgYWN0dWFsIHZhbHVlIGlzIHRoZSBk ZWZhdWx0IHZhbHVlIFNIT1VMRCBOT1QgYmUNCg0KICAgICAgICAgICAgICAgaW5jbHVkZWQuIEhv d2V2ZXIsIGlmIHRoZSBhY3R1YWwgdmFsdWUgd2FzIHNldCBieQ0KDQogICAgICAgICAgICAgICBh IE5FVENPTkYgY2xpZW50IG9yIG90aGVyIG1hbmFnZW1lbnQgYXBwbGljYXRpb24NCg0KICAgICAg ICAgICAgICAgYnkgdGhlIHdheSBvZiBhbiBleHBsaWNpdCBtYW5hZ2VtZW50IG9wZXJhdGlvbiB0 aGUNCg0KICAgICAgICAgICAgICAgZGF0YSBub2RlIFNIT1VMRCBiZSBpbmNsdWRlZC4iOw0KDQog ICAgICAgICB9DQoNCiAgICAgICB9DQoNCiAgICAgICBkZWZhdWx0IHRyaW07DQoNCg0KVGhlIGRy YWZ0IGlzIGV4dHJlbWVseSBzZXJ2ZXItY2VudHJpYywgbGlrZSBtb3N0IElFVEYgc3RhbmRhcmRz LCBidXQgdGhpcw0KbGVhZiBpcyB0b28gc2VydmVyLWNlbnRyaWMgdG8gaWdub3JlLg0KDQpDb25z aWRlciB0aGUgcG9zc2liaWxpdHkgdGhhdCB0aGUgc291cmNlIG9mIHRoZSBmaWxlIGlzIE5PVCBh IE5FVENPTkYgc2VydmVyLg0KVGhpcyBkYXRhIG1heSBub3QgYmUga25vd24gc28gdGhlIGRlZmF1 bHQgb2YgInRyaW0iIG1heSBub3QgYmUgY29ycmVjdC4NCg0KSU1PIHRoaXMgbGVhZiBpcyBub2lz ZSBiZWNhdXNlIGFueSB0b29sIHRoYXQga25vd3MgdGhlIHNjaGVtYSB3aWxsIGFsc28NCmtub3cg dGhlIFlBTkcgZGVmYXVsdHMuICBUaGUgc29sdXRpb24gaXMgaW5jb21wbGV0ZSBhbnl3YXkgYmVj YXVzZQ0KdGhlIHByZXNlbmNlIG9mIGEgbGVhZiB0aGF0IGhhcyBhIFlBTkcgZGVmYXVsdCBpcyBu b3QgZW5vdWdoLg0KVGhlICAicmVwb3J0LWFsbC10YWdnZWQiIG1vZGUgbXVzdCBiZSB1c2VkIHRv IGlkZW50aWZ5IGRlZmF1bHRzLg0KSU1PIHRoaXMgbGVhZiBzaG91bGQgYmUgcmVtb3ZlZCwgYnV0 IGF0IGxlYXN0IGFkZCBhbiBlbnVtIGNhbGxlZCAidW5rbm93biIuDQoNCg0KQW5keQ0KDQoNCg== --_000_DM4PR11MB5438F5874CDEB4D78C9A5695B5189DM4PR11MB5438namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcHJlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRl ZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0K CWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCO30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9 IiM5NTRGNzIiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5BbmR5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5ZZXMsIHdoZW4gSSBzdWdnZXN0ZWQgdGhpcywg SSB3YXMgdGhpbmtpbmcgdGhhdCBhIGJvb2xlYW4gZmxhZyBtaWdodCBiZSBzdWZmaWNpZW50LiZu YnNwOyBNeSBwb2ludCBiZWluZyB0aGF0IGF1dG9tYXRpY2FsbHkgZmlsdGVyaW5nIG91dCBkZWZh dWx0IHZhbHVlcyBpc27igJl0IGFsd2F5cyB0aGUgcmlnaHQgdGhpbmcgdG8gZG8uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkUu Zy4sIHNvbWV0aGluZyBhbG9uZyB0aGVzZSBsaW5lczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+bGVhZiBleGNsdWRlLWRlZmF1 bHRzIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyB0eXBlIGJvb2xlYW47PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsgZGVmYXVsdCB0cnVlOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7IGRlc2NyaXB0aW9uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsg4oCcQ2FuIGJlIHVzZWQgdG8gcmVkdWNlIHRoZSBz aXplIG9mIHRoZSBjb250ZW50IGRhdGEgZmlsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFdoZW4gdW5zZXQgb3Igc2V0IHRvIHRydWUsIGRhdGEgbm9kZXMgdGhhdCBoYXZl IGEgZGVmYXVsdCBkZWZpbmVkIGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHdoZXJlIHRoZSBhY3R1YWwgdmFsdWUgaXMgdGhlIGRl ZmF1bHQgdmFsdWUgYXJlIGV4Y2x1ZGVkIGZyb20gdGhlIGNvbnRlbnQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDtkYXRhLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV2hlbiBzZXQgdG8gZmFsc2UsIGRhdGEgbm9k ZXMgd2l0aCBkZWZhdWx0IHZhbHVlIGFyZSBub3QgZmlsdGVyZWQsIGFuZDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1heSBhcHBlYXIg aW4gdGhlIGNvbnRlbnQgZGF0YS7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPn08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+V291bGQgdGhpcyBzYXRpc2Z5IHlvdXIgY29uY2Vybj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8YnI+DQpS b2I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIj4gbmV0bW9kICZsdDtuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFs ZiBPZiA8L2I+QW5keSBCaWVybWFuPGJyPg0KPGI+U2VudDo8L2I+IDA4IEp1bHkgMjAyMSAxODox Njxicj4NCjxiPlRvOjwvYj4gTmV0TW9kIFdHICZsdDtuZXRtb2RAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFtuZXRtb2RdIHlhbmctaW5zdGFuY2UtZmlsZSBpbmNsdWRlLWRlZmF1 bHRzIGxlYWY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGUgbW9kdWxlIGhhcyB0aGlzIG9iamVjdDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHByZSBzdHlsZT0id2hpdGUtc3BhY2U6cHJlLXdyYXAiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgaW5jbHVkZXMtZGVmYXVsdHMgezxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0eXBlIGVudW1lcmF0aW9uIHs8bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW51bSByZXBvcnQtYWxsIHs8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgdmFsdWUgMTs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7QWxsIGRhdGEg bm9kZXMgU0hPVUxEIGJlIGluY2x1ZGVkIGluZGVwZW5kZW50IG9mPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGFueSBkZWZhdWx0IHZhbHVlcy4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgZW51bSB0cmltIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmFsdWUgMjs8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRp b248bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7RGF0YSBub2RlcyB0aGF0IGhhdmUgYSBkZWZhdWx0IGRl ZmluZWQgYW5kIHdoZXJlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBhY3R1YWwgdmFs dWUgaXMgdGhlIGRlZmF1bHQgdmFsdWUgU0hPVUxEPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IE5PVCBiZSBpbmNsdWRlZC4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgZW51bSBleHBsaWNpdCB7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHZhbHVlIDM7PG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0aW9uPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZxdW90O0RhdGEgbm9kZXMgdGhhdCBoYXZlIGEgZGVmYXVsdCBkZWZpbmVkIGFu ZCB3aGVyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgYWN0dWFsIHZhbHVlIGlzIHRo ZSBkZWZhdWx0IHZhbHVlIFNIT1VMRCBOT1QgYmU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg aW5jbHVkZWQuIEhvd2V2ZXIsIGlmIHRoZSBhY3R1YWwgdmFsdWUgd2FzIHNldCBieTxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBhIE5FVENPTkYgY2xpZW50IG9yIG90aGVyIG1hbmFnZW1lbnQg YXBwbGljYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnkgdGhlIHdheSBvZiBhbiBl eHBsaWNpdCBtYW5hZ2VtZW50IG9wZXJhdGlvbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgZGF0YSBub2RlIFNIT1VMRCBiZSBpbmNsdWRlZC4mcXVvdDs7PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWZhdWx0 IHRyaW07PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3aGl0ZS1zcGFjZTpw cmUtd3JhcCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkcmFmdCBpcyBleHRyZW1lbHkgc2Vy dmVyLWNlbnRyaWMsIGxpa2UgbW9zdCBJRVRGIHN0YW5kYXJkcywgYnV0IHRoaXM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmxlYWYgaXMgdG9vIHNl cnZlci1jZW50cmljIHRvIGlnbm9yZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29uc2lkZXIgdGhlIHBvc3NpYmlsaXR5IHRoYXQgdGhlIHNv dXJjZSBvZiB0aGUgZmlsZSBpcyBOT1QgYSBORVRDT05GIHNlcnZlci48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgZGF0YSBtYXkgbm90IGJl IGtub3duIHNvIHRoZSBkZWZhdWx0IG9mICZxdW90O3RyaW0mcXVvdDsgbWF5IG5vdCBiZSBjb3Jy ZWN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JTU8gdGhpcyBsZWFmIGlzIG5vaXNlIGJlY2F1c2UgYW55IHRvb2wgdGhhdCBrbm93cyB0aGUg c2NoZW1hIHdpbGwgYWxzbzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+a25vdyB0aGUgWUFORyBkZWZhdWx0cy4mbmJzcDsgVGhlIHNvbHV0aW9uIGlz IGluY29tcGxldGUgYW55d2F5IGJlY2F1c2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBwcmVzZW5jZSBvZiBhIGxlYWYgdGhhdCBoYXMgYSBZ QU5HIGRlZmF1bHQgaXMgbm90IGVub3VnaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSZuYnNwOyAmcXVvdDtyZXBvcnQtYWxsLXRhZ2dlZCZx dW90OyBtb2RlIG11c3QgYmUgdXNlZCB0byBpZGVudGlmeSBkZWZhdWx0cy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklNTyB0aGlzIGxlYWYgc2hv dWxkIGJlIHJlbW92ZWQsIGJ1dCBhdCBsZWFzdCBhZGQgYW4gZW51bSBjYWxsZWQgJnF1b3Q7dW5r bm93biZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM4PR11MB5438F5874CDEB4D78C9A5695B5189DM4PR11MB5438namp_-- From nobody Fri Jul 9 05:25:53 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28853A1F7A for ; Fri, 9 Jul 2021 05:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=dgiVxhzf; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=bBeq6mRK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewbiunfWoS5Q for ; Fri, 9 Jul 2021 05:25:47 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D07123A1F74 for ; Fri, 9 Jul 2021 05:25:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1529; q=dns/txt; s=iport; t=1625833546; x=1627043146; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BfoalaVWX8iGsxhl6ft14RcUJKte3fZNzTYpY+GpKVg=; b=dgiVxhzfjy7Uf8BzOtKXnz3JgyQiCTdp4jfAeKV7aOucQU4bqrshKG84 h4+7s30PpKoQoNYjQgNv8wQdzvtGqQL6jaUs2fSyY+L1FKTMLwJ/yOVgG D8aoUNqUv3yxmULrH37u06dFqTBl6EXnCXvDjzLyWQYFrFS8Wri3ZuZLL E=; X-IPAS-Result: =?us-ascii?q?A0DFAgDNP+hgl4cNJK1XAx0BAQEBCQESAQUFAUCBWYFTU?= =?us-ascii?q?X5aNzGIEAOFOYhcA5ooglMDVAsBAQENAQExEAQBAYRTAoJ3AiU4EwIEAQEBA?= =?us-ascii?q?QMCAwEBAQEFAQEFAQEBAgEGBBQBAQEBAQEBAWiFaA2GRQEBAQEDEi4BATcBC?= =?us-ascii?q?wICAgEIDgIBBAEBAS4bFx0IAgQOBQgagk8BglUDLwGaZAGBOgKKH3iBNIEBg?= =?us-ascii?q?gcBAQYEBIUqGIIyAwYFgTWCe4pvJxyBSUSBWIJiPoRGHyaDBoIMIoI7gUknL?= =?us-ascii?q?IEYbAQLBp9enWQKgySeSBKmR7sAAgQCBAUCDgEBBoFzIoFbcBU7gmlQGQ6OH?= =?us-ascii?q?xmDVzOKK3M4AgYBCQEBAwmMAQEB?= IronPort-PHdr: A9a23:5qZSjxSgPtrveN4i0FFKcH8xYdpso0nLVj580XJvo7BHeaOp5NH/O k3B6O92jUPYG4nWuLpIiOvT5qbnX2FIoZOMq2sLf5EEURgZwd4XkAotDI/gawX7IffmYjZ8E JFEU1lorHOyOk9fA4PjYVzMr2ep7CIDXBnyZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywBNE6L Bi/oQjL8McMho43IacqwRyPqXxNKIxr IronPort-HdrOrdr: A9a23:X0qvu63NWlqlVu7AV5h5awqjBTRyeYIsimQD101hICG9Lfb4qy n+ppomPEHP5wr5AEtQ5uxpOMG7MBThHO1OkPcs1NCZLUjbUQqTXc9fBO7ZowEIdBeOjdK1uZ 0QFpSWTeeAcWSS7vyKoDVQcexQuuVvmZrA7Yy1ohsdLnAJV0gj1XYFNu/xKDwReOAyP+tAKH Pq3Ls/m9PPQwVyUu2LQl0+G8TTrdzCk5zrJTQcAQQ81QWIhTS0rJbnDhmxxH4lInBy6IZn1V KAvx3y562lvf3+4ATbzXXv45Nfn8ak4sdfBfaLltMeJlzX+0SVjcVaKvi/VQIO0aaSAWUR4Z /xStAbTp1OAkbqDyWISN3WqlHdOXgVmiTfIBSj8AreSITCNUIH4ox69Nhkmt+z0Tt9gDm6u5 g7gl5x/qAnfi/ojWDz4cPFWAptkVfxqX0+kfQLh3gaSocGbqRNxLZvtn+9Pa1wVB4S0rpXW9 WGzfusk8p+YBefdTTUr2NvyNujUjA6GQqHWFELvoiQ3yJNlH50wkMEzIhH901wuK4VWt1B/a DJI65onLZBQosfar98Hv4IRY+yBnbWSRzBPWqOKRDsFb0BOXjKt5nriY9Fqd1CuKZ4hafava 6xH2+wmVRCDn4GOPf+qqGjqCq9MllVdQ6dvv1j2w== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,226,1620691200"; d="scan'208";a="719149898" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Jul 2021 12:25:43 +0000 Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 169CPhKQ010616 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 9 Jul 2021 12:25:43 GMT Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 9 Jul 2021 07:25:43 -0500 Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 9 Jul 2021 08:25:42 -0400 Received: from NAM04-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 9 Jul 2021 07:25:42 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GhgE4XRUOXr1Z53FoJdDfSA64s8fGlz0scLbGUddERsc5NmZqnd9Gyvi6mesvF41wwFFobqrHRarIaQN31lc7Z3HvSphwz0/4Eqi3JGGWHiqRSw2bJOlLKMAiWBhsEeSygaI3wMXmUmFQ4sNlKWdvpyHCj0DP8fXkCF5pGQDaQIjz1RKshbcwjgoECYGR7pQvHo3Wxd7zWJUAXstp8IddTZewKPdM2gyh8aItsoUSCLz4CTBu3ZlwIBVTOXPYQ7wIzuQifrDiLzZA+ejiCw+wJvg2NW4Ify/K7kU5Ve7LDeWRwwAxMc7BTPodifbWMe2RtT0tGFzvqEwTb8RJI1gdQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8E9wU3DSAj7+kbmyAZF8Bd7Mp3HrtX5j7Kb76h1eYqY=; b=KHU0PngZ8zVm8qKrr+ynLXDpy3KcU0pCvDna67up7mPEORu0iIKCmb3iVHMVkU4M89zXxIftFfzZ7IRhVV+Qs3W+duuXrIXQ6HKqlJoF4B4cdSutKz+GSiE9xgBQmU26Lp0Pn4JMN8oYOD/sIiZSDWsGzjEeKK2x18L6IStk2Mvwbzbrd6sSYhyGWu+q2QpBoJPvlYvCyxrA/DkXDKLT5smgnc4C/e0YeF5294X7CYn1hMXs15uXI2f3g9cRVX4zhgL51LDq7D7Od++SuCbH/Rj3F1maPKj/cMcKGBJ530FYfW33kEaVayVBrFHJecQ0sDiRZUv3mV2ViV6rWxsANw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8E9wU3DSAj7+kbmyAZF8Bd7Mp3HrtX5j7Kb76h1eYqY=; b=bBeq6mRKv++dpF/ndp99GZSlgM94vcfHxeB/gGmQuqiufF4eZJqqUmve87S+Xs7jHa2qk9Kuz1BqUvOVDo9aHIo9yvaiS3/n9k37xFEIJXYRuxK+hmHKEk+XXouv0m57TD4+F9g70FD9ouYxiUWWqYPZD82JJ+ZWj4zRr1K3LeA= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM6PR11MB3273.namprd11.prod.outlook.com (2603:10b6:5:56::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.23; Fri, 9 Jul 2021 12:25:40 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12%6]) with mapi id 15.20.4308.023; Fri, 9 Jul 2021 12:25:40 +0000 From: "Rob Wilton (rwilton)" To: Juergen Schoenwaelder CC: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= , "Andy Bierman" , "netmod@ietf.org" , "Benoit Claise" Thread-Topic: AD review of draft-ietf-netmod-yang-instance-file-format Thread-Index: AddmeFKW59UgRm1RQKG2Oq9f4FrzcwHIeW+AAP3GDfAALcrP8AAPXLWAAAIT0wAAAIMhAAAAy2eAAAJlLwAAGf35QAAVpNcAAAKQ2AAAHRePIAACr5QAAAAUxvAAAke7IAAESQ+gACTRU5AAA2B0YAAGCoSAAAE5rjA= Date: Fri, 9 Jul 2021 12:25:40 +0000 Message-ID: References: <20210707192534.4emim5a36zyqrktc@anna.jacobs.jacobs-university.de> <20210708103528.6ezr4v5qeltinvmv@anna.jacobs.jacobs-university.de> <20210709114939.fig4njly5yu6dwce@anna.jacobs.jacobs-university.de> In-Reply-To: <20210709114939.fig4njly5yu6dwce@anna.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: jacobs-university.de; dkim=none (message not signed) header.d=none;jacobs-university.de; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a055e6c7-32ed-4bc1-0dd2-08d942d4aa1d x-ms-traffictypediagnostic: DM6PR11MB3273: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iDoOTk7RBleyMP2kceIA+hUBS3eKwIi79TRfyjNgoH3w5M4En50Yo8SywJ4OvWoU34fAsM2a28p4qhlBmp919pCnHFN46ur8PPQpCreWE6AX5SBAsWcfW+7lxEKpHajGLwqCU4iC7H9wJE8ElWLtNHP7gwQ7RREcyg+BEwq1CKOJ8y5W5gSFywwWFYl9opZYNZO2l0vpZ4T9Xd0brtGQh5HWnUIcqDlizh9Pe6jBaf102OcXRgoNjmAfXZ7gcWMMzqHRmlqbTiavMzqkXzyd+rVDiPqG+t1rQplFQlMHRzy5Adk7/+MQGYAlkRDGwPkNQqXGgt4vPCYUblZ4J9psJuF5xj5vjNJ+x2YoZVRDpJexAA3ecLbRpy6TXSV9OtEH9z3htSyMHRWXtQCDqQfE2jBtTX2/od60Z3Gb3ju+Vjq4cv6u5/pCeUpYqGQJBJBoi/DS+q1n1mbDEZz/dMoIpTirEQ5FBpqw7XNN1rCmu+PuxG52jxK9dAyhA9HJYL+xPkjBNHu5/Jxgdje8mTYp6InMTC5sezUP3H6hqAkOaSROJqUCIxrmApK4/0Ao0Oh0ncsQfgo6Wk8h4/jdrVtOI0RAWGEVy3nw6zi7oXWgZ90c6jOcvOFLqHvCYSXYqDmGRS2WS/2F5uDhd0wDT6QV1U69KVKm3xI7VH3M28KiJFIqHDLSI55IioEB8i0kn4HV5cZk2aFaUAkcyYX+O2+xEVW1HlMLIBf3Xo+MkNP6hHk= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(136003)(396003)(376002)(346002)(66476007)(66946007)(6916009)(55016002)(54906003)(7696005)(38100700002)(33656002)(8676002)(9686003)(86362001)(2906002)(8936002)(83380400001)(6506007)(71200400001)(53546011)(122000001)(52536014)(76116006)(26005)(4326008)(5660300002)(478600001)(66556008)(316002)(186003)(66446008)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?NLKc7jTeBqWGcFVH6Cl6BKB3zp6sfPCilK8CcDdITqm1sNiqGfIv8tuAAG?= =?iso-8859-1?Q?AZcoTCYv1oEI/H9huP3SJt3cTbcfb7m6efzv9l2+nBi6IZgNbtT33eRNmN?= =?iso-8859-1?Q?UrnKnxndjYiLya6qx5N8v1XTUY8rt1q54/JEQXH9imutGvaDwg4cWLF2i/?= =?iso-8859-1?Q?36qWUm+p9J+sqDFmQqDmznuO/CdqMFdVL/hEg47rTM5mo3gnuR/TTrgV1o?= =?iso-8859-1?Q?/AxbMqNZ0hPf0Uf1LS2IpQgGs8byBiYUtxuDYgwX6yNPAHOOpa5+SAnZyE?= =?iso-8859-1?Q?uCxcyZz/36FMk1MsnPsWrm2hBE4s2Fejr8kIufaRlyaRMXAatO1RC+i/Cs?= =?iso-8859-1?Q?q5jI6nmHgv40O+dm2AFW6Hdmcod0R2nEbufAsLpvngit3zigk54dQpW+ZU?= =?iso-8859-1?Q?CKNkyjolAqVAlGe7pRT9UefOmJuzg3Zr9FcTvEWIQvkQUjgcO55rAZkMXd?= =?iso-8859-1?Q?FF07vog2h7rxKUv3NnXMO/kpe1s7vJHTvd18VKXPmgXWPrA8LdI7qjfeXW?= =?iso-8859-1?Q?7t2+cbfuhwuVTSGuRNi0KmaOtnFK+qDtqdPyD9WEPY8Q1ft6KCFjvt6Bdz?= =?iso-8859-1?Q?3hNvNT8s7dtHSymeQ3Sy4toGUfrMWUMYWGNwh/yTbc0TsUjUc6/ewF3EKQ?= =?iso-8859-1?Q?0BPfV/VM54GxQvzt1xoyvELPg80MJnAzu9dR4v4tnMegRvPtQIEkzn58j8?= =?iso-8859-1?Q?95uJHdWPNkekgS3mgz2uNFO3iO5BTnPvuj3/rBz0wRwg7EVuIkUeER3Std?= =?iso-8859-1?Q?TPTNZfIj26mukjc/HecUBTCSxycBWUsolxzgqEz51rIQDWZxCz7vTLHht7?= =?iso-8859-1?Q?5MdWd2Ksd0CZ2KGiY/0icdyCzFqKr99zcC0hlzp+oEQWF+FNnzNnABpawT?= =?iso-8859-1?Q?+9hK1o5W2tOG06HWTrvW3coCWMZxYYjkSKH8BxR0lRHYZQAov+a0hufeYh?= =?iso-8859-1?Q?iF99Kod30w9JpUgkjn0wbDxF7Ym1BerGfBc0UATkU/LWSP8d5Dc9j/J+Q+?= =?iso-8859-1?Q?Njj4pErwyEN9Rjp0wo+ilLlxA7TdaecwbccXu55SIm9vZCspFV7to7BvqG?= =?iso-8859-1?Q?DyUqjSSeAPbjrQMkjhlx1hff/y+a2XCo7K8va6WSuhZ4MCl6+utT6AkYBy?= =?iso-8859-1?Q?/8k+Yu3JsrWAVuZOzZdvbiS/jjj1O35JbEOLmNQdSAWoSRkUceRZDJiCFA?= =?iso-8859-1?Q?jwq5b4OtuKOaGoZo5WLaxMu9yP55K1JF4yZy2KmdgsQsoQs/mqSPamh9Sf?= =?iso-8859-1?Q?V0HkyhfdTKBM40teCyCbf2pIHFdW6bvsxm5EMi5ZmVhSoEE7Dg03j1YVs5?= =?iso-8859-1?Q?OIxSyfLazcWvqF/WWAL6Na8h2sAhFEdS94/gfZXM0Xpjx6xmoVF6jqaI3Z?= =?iso-8859-1?Q?qB8IEIuuDa?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a055e6c7-32ed-4bc1-0dd2-08d942d4aa1d X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2021 12:25:40.3609 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CJUwg1KH1EF736VUNrrWoChowLQqpz7NBvE+H/lvfNBhXGMQTOxXMclGykURZImIWXOsahlWnfHI/T/HoNOlrQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3273 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [netmod] AD review of draft-ietf-netmod-yang-instance-file-format X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 12:25:52 -0000 Juergen, Yes, I agree that is a better phrasing. Thanks for suggesting it. Rob > -----Original Message----- > From: Juergen Schoenwaelder > Sent: 09 July 2021 12:50 > To: Rob Wilton (rwilton) > Cc: Bal=E1zs Lengyel ; Andy Bierman > ; netmod@ietf.org; Benoit Claise > > Subject: Re: AD review of draft-ietf-netmod-yang-instance-file-format >=20 > On Fri, Jul 09, 2021 at 09:10:34AM +0000, Rob Wilton (rwilton) wrote: > > > > "YANG modules that are only required to satisfy import-only dependencie= s > MAY be excluded from the leaf-list. If they are excluded then the consum= er > of the instance data file can choose any versions of the YANG modules tha= t > satisfy the import dependency." > > >=20 > Sorry, this wording is a bit wrong or possibly misleading. I assume > your intention was this: >=20 > OLD: >=20 > If they are excluded then the consumer of the instance data file can > choose any versions of the YANG modules that satisfy the import > dependency. >=20 > NEW: >=20 > If they are excluded then the consumer of the instance data file has > to apply the YANG language rules to resolve the imports. >=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 Fri Jul 9 09:50:24 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5863A2760 for ; Fri, 9 Jul 2021 09:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 lwzrY5fbtCvA for ; Fri, 9 Jul 2021 09:50:17 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 6E1743A2761 for ; Fri, 9 Jul 2021 09:50:17 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id k8so9011127lja.4 for ; Fri, 09 Jul 2021 09:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dP8IOcvVHWRqay9hPJRfi8ULEH18ZKboUouaA8L0ci4=; b=zNGninQnd94v21FtSLUQa266wCaoY/StW8DMJUFY2Six7Ez5IoJe2kKqkt5rk6/dJL iw8YncaWmcsddKa18CKSSwPaFMpnIYtlkrxLjiddFJ0lyrzs/VJfeRH39C/irEx40poq 6ZIU6LWokfj+OTxwBTDdcd1AuLE/33cwm9+In1Am5ObpuH412cicUV2TVZyKog4GkW6M 7oWdEGTRLgLVkrRt1WjU6qcl2LectYqLbPPx1xmGYNRPohCGZGdp/H9Y8b2nEfM9/W6D ReSxcLXLtWj6ICe74kn3oCHtUe/gGPkxK2LwCNvJJZdXrFciQ6QAvYfQUxcXv6Rnu5Qq 9GNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dP8IOcvVHWRqay9hPJRfi8ULEH18ZKboUouaA8L0ci4=; b=Knr06UA9g5SbkDg+nyt/CSRV5n2n4tG9vY4aVBtSVWzF1ZCFcb2e36+fTDuj/PAuiQ ZkX1LjlY8oZdrq9d9qghNe0RT9Pf/3hjRoWsv0pH7e4uft+MzIRsUe2ATzkGXKGLeb2S KnUqNSmm8t3eSlSxsrDaLKVqX2AuwbV0pg4y7hhiX8JWqDmTRAfHcMjJGBAiiMch9xqs ps7mlraRarinxw+9HGTHCrbnI3dRxkUrZQbKZAMpZhOmQgIbFSGKD3R3Rgj2XoHu5j0o kly8uZeemMAPm0MuJJN6rNmtuTrmc7Vny8JupleEuMrRKed0aYStM2ALIkDrgx9Kv2C/ DZxA== X-Gm-Message-State: AOAM532CB4EJyq3Bb58U8RdPSrlUnARhB7SHcsJ+HNpvgctQSvI0bF14 53wgb2MxhQabgUfP/CKhKtO4J2Qs8dvaEQfAmvSoMQ== X-Google-Smtp-Source: ABdhPJwG9tiFkVd+DR/ADtSqA+a1NQCGD22iOuZLoZh8Eu2+xr4YgEQ26ADIc6RYimNBMgkJLKqKbRE+ei3i8Mq5PFA= X-Received: by 2002:a2e:b60c:: with SMTP id r12mr12679688ljn.55.1625849413892; Fri, 09 Jul 2021 09:50:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Fri, 9 Jul 2021 09:50:03 -0700 Message-ID: To: "Rob Wilton (rwilton)" Cc: NetMod WG , =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= Content-Type: multipart/alternative; boundary="000000000000c60c2905c6b39086" Archived-At: Subject: Re: [netmod] yang-instance-file include-defaults leaf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 16:50:23 -0000 --000000000000c60c2905c6b39086 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) wrote: > Andy, > > > > Yes, when I suggested this, I was thinking that a boolean flag might be > sufficient. My point being that automatically filtering out default valu= es > isn=E2=80=99t always the right thing to do. > > > > E.g., something along these lines: > > > > leaf exclude-defaults { > > type boolean; > > default true; > > description > > =E2=80=9CCan be used to reduce the size of the content data file. > > > > When unset or set to true, data nodes that have a default defined a= nd > > where the actual value is the default value are excluded from the > content > > data. > > > > When set to false, data nodes with default value are not filtered, > and > > may appear in the content data.=E2=80=9D > > } > > > > Would this satisfy your concern? > no. I am confused as to what problem you are trying to solve here. There does not seem to be one. Maybe it is "The reader needs to know if the writer reported defaults or not". What problem is solved because the reader knows this info? There has always been confusion between implementing YANG default behavior and a protocol that allows a client to request how defaults are handled in the response. RFC 6243 is a hack needed because the WG never actually agreed on how defaults should be treated within a server. A YANG default is the value that MUST be used in the event the leaf or leaf-list instance does not exist. So the term "defaults present" only really applies to reporting YANG defaults. The YANG default behavior is always in effect. Unlike SMIv2 DEFVAL, it is mandatory to support. The with-defaults parameter is optional to implement, so it is not even true to say that all servers report defaults, let alone say that all YANG instance files are from NC/RC servers. For basic-style=3Dreport-all, there is never any default suppression. Ever= y value, including missing nodes with YANG defaults, are reported as if they are nodes which exist. For this mode, the leafs in this draft are useless. For basic-style=3Dtrim there is default suppression. A node is considered not present if it has the YANG default value, even if a client sets it to the default value. For this mode, the leafs in this draft are useless. Any leaf that contains the default value is a YANG default that is being reported. For basic-style=3Dexplicit there is default suppression. A node is conside= red not present if it has not been set by a client, ignoring the YANG default value. For this mode, the data reported in the content for this draft are useless. Any leaf that contains the default value could be a default but it is not i= f it was set by a client. The 'default' attribute must be added to the node to identify it as a reported default. https://datatracker.ietf.org/doc/html/rfc6243#section-6 > > > Regards, > Rob > > > Andy > > > *From:* netmod *On Behalf Of *Andy Bierman > *Sent:* 08 July 2021 18:16 > *To:* NetMod WG > *Subject:* [netmod] yang-instance-file include-defaults leaf > > > > Hi, > > > > The module has this object: > > > > leaf includes-defaults { > > type enumeration { > > enum report-all { > > value 1; > > description > > "All data nodes SHOULD be included independent of > > any default values."; > > } > > enum trim { > > value 2; > > description > > "Data nodes that have a default defined and where > > the actual value is the default value SHOULD > > NOT be included."; > > } > > enum explicit { > > value 3; > > description > > "Data nodes that have a default defined and where > > the actual value is the default value SHOULD NOT be > > included. However, if the actual value was set by > > a NETCONF client or other management application > > by the way of an explicit management operation the > > data node SHOULD be included."; > > } > > } > > default trim; > > > > The draft is extremely server-centric, like most IETF standards, but this > > leaf is too server-centric to ignore. > > > > Consider the possibility that the source of the file is NOT a NETCONF > server. > > This data may not be known so the default of "trim" may not be correct. > > > > IMO this leaf is noise because any tool that knows the schema will also > > know the YANG defaults. The solution is incomplete anyway because > > the presence of a leaf that has a YANG default is not enough. > > The "report-all-tagged" mode must be used to identify defaults. > > IMO this leaf should be removed, but at least add an enum called "unknown= ". > > > > > > Andy > > > > > --000000000000c60c2905c6b39086 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jul 9, 2021 at 5:23 AM Rob Wi= lton (rwilton) <rwilton@cisco.com> wrote:

Andy,

=C2=A0

Yes, when I suggested this, I was thinking tha= t a boolean flag might be sufficient.=C2=A0 My point being that automatical= ly filtering out default values isn=E2=80=99t always the right thing to do.=

=C2=A0

E.g., something along these lines:

=C2=A0

leaf exclude-defaults {

=C2=A0 type boolean;

=C2=A0 default true;

=C2=A0 description

=C2=A0=C2=A0=C2=A0 =E2=80=9CCan be used to red= uce the size of the content data file.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When unset or s= et to true, data nodes that have a default defined and=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 where the actua= l value is the default value are excluded from the content

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0data.=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When set to fal= se, data nodes with default value are not filtered, and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 may appear in t= he content data.=E2=80=9D

}

=C2=A0

Would this satisfy your concern?



I am confused as to what problem you are trying to solve here.
There does not seem to be one.

Maybe it i= s "The reader needs to know if the writer reported defaults or not&quo= t;.
What problem is solved because the reader knows this info?

There has always been confusion between implementing= YANG default behavior
and a protocol that allows a client to req= uest how defaults are handled in the response.
RFC 6243 is a hack= needed because the WG never actually agreed on how
defaults shou= ld be treated within a server.

A YANG default is t= he value that MUST be used in the event the leaf or leaf-list instance
does not exist.=C2=A0 So the term "defaults present" only r= eally applies to reporting YANG defaults.
The YANG default behavi= or is always in effect. Unlike SMIv2 DEFVAL, it is mandatory to support.

The with-defaults parameter is optional to implement= , so it is not even true to say that
all servers report defaults,= let alone say that all YANG instance files are from NC/RC servers.

For basic-style=3Dreport-all, there is never any default = suppression.=C2=A0 Every value, including
missing nodes with YANG= defaults, are reported as if they are nodes which exist.
For thi= s mode, the leafs in this draft are useless.

= For basic-style=3Dtrim there is default suppression.=C2=A0 A node is consid= ered
not present if it has the YANG default value, even if a clie= nt sets it to the default value.
For this mode, the leafs in this= draft are useless. Any leaf that contains
the default value is a= YANG default that is being reported.=C2=A0

<= div>For basic-style=3Dexplicit there is default suppression.=C2=A0 A node i= s considered
not present if it has not been set by a client, igno= ring the YANG default value.
For this mode, the data reported in = the content for this draft are useless.
Any leaf that contains th= e default value could be a default but it is not if
i= t was set by a client.=C2=A0 The 'default' attribute must be added = to the node to=C2=A0
identify it as a reported default.



=C2=A0

=C2=A0

Regards,
Rob

=C2=A0


Andy
=C2=A0

=C2=A0

From: netmod <netmod-bounces@ietf.org> On Behalf Of Andy Bierman
Sent: 08 July 2021 18:16
To: NetMod WG <netmod@ietf.org>
Subject: [netmod] yang-instance-file include-defaults leaf=

=C2=A0

Hi,

=C2=A0

The module has this object:

=C2=A0

=C2=A0=C2=
=A0=C2=A0 leaf includes-defaults {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type =
enumeration {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 enum report-all {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 value 1;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 description
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "All data nodes SHOULD be included inde=
pendent of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 any default values.";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 enum trim {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 value 2;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 description
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Data nodes that have a default defined=
 and where
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the actual value is the default =
value SHOULD
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NOT be included.";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 enum explicit {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 value 3;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 description
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Data nodes that have a default defined=
 and where
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the actual value is the default =
value SHOULD NOT be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 included. However, if the actual=
 value was set by
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a NETCONF client or other manage=
ment application
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 by the way of an explicit manage=
ment operation the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 data node SHOULD be included.&qu=
ot;;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<=
/u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 defau=
lt trim;
=C2=
=A0

The draft is extremely server-centric, like most IET= F standards, but this

leaf is too server-centric to ignore.<= /p>

=C2=A0

Consider the possibility that the source of the file= is NOT a NETCONF server.

This data may not be known so the default of "t= rim" may not be correct.

=C2=A0

IMO this leaf is noise because any tool that knows t= he schema will also

know the YANG defaults.=C2=A0 The solution is incomp= lete anyway because

the presence of a leaf that has a YANG default is no= t enough.

The=C2=A0 "report-all-tagged" mode must be= used to identify defaults.

IMO this leaf should be removed, but at least add an= enum called "unknown".

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

--000000000000c60c2905c6b39086-- From nobody Fri Jul 9 10:26:13 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 364FD3A288E; Fri, 9 Jul 2021 10:26:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <162585157116.12010.13764789137133860398@ietfa.amsl.com> Date: Fri, 09 Jul 2021 10:26:11 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6991-bis-07.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 17:26:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Common YANG Data Types Author : Juergen Schoenwaelder Filename : draft-ietf-netmod-rfc6991-bis-07.txt Pages : 41 Date : 2021-07-09 Abstract: This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6991. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6991-bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6991-bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6991-bis-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 10 09:41:21 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1B93A16F2 for ; Sat, 10 Jul 2021 09:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 GsrMR-OjImdv for ; Sat, 10 Jul 2021 09:41:15 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65913A16DD for ; Sat, 10 Jul 2021 09:41:14 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id q18so30649609lfc.7 for ; Sat, 10 Jul 2021 09:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2UChUD/QJa00LO1Cz9Ycl37K9hiyUQHWnQ1XBKXq3cw=; b=NVJB+CdwOm/czhXut09YWHZ9IMIZuYntjSKGIytKu4rPSldECuUHPjxIqt3YgI82Qs VtU1/pmmUDTekz57+pqcbnhV7fnwnaqM9tsWB3pVpiw4QqMvd0pen7csTooUWAByDJxW qWtkvggSvgyX78Rq2et/U+UHVTVxbKs3LxD0umUz0Qr6tJKwX4TL2/Un9m0RhMD9tBVR s1hXolaJYu37mAw2PdUggprUIRpmYdcXU01N6Nx1WQlxWm9TUzdF5+B5ofFZk1dsyt9V OUIz/ZWJeNYIqK7TOyJzFueS7ZZrAtlPy0QQ4Z6fjjIBO4Jkh/2NV2tszM6tFWDAxwmb SVCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2UChUD/QJa00LO1Cz9Ycl37K9hiyUQHWnQ1XBKXq3cw=; b=RILT+u3AkuUX3AU7Sv00g3FpObumI9JMeF9LcUxwlTtXZQYBTmZ2AnoiyX4VxI/x4K Y/iEv1d6u7FIO2fBpu5AyY0Sj+uwJDU+rpSgGZMuWP5tnbW60OFCFU+HwWEsUwd6A8qx W2CUqF4aVKFrRwqoF6sQGpEutxWICycxcnx7/3CIR1EE/oVtTqbwjB/d1VSFqCYJY9XM lp8n8nYHhcff56p+cLTHgI+dWtXBxatn51AvoLNPsFEqXApv7dAAcpYmd9lpH4+IL8gy EWcHTsAkltgfAz9AmklUKHty5XPYBEN0VxTE5l0sZhflIm4DFZttoVqSEFzbvb/rup9M mKUg== X-Gm-Message-State: AOAM530MdNTBK+H0KEJiqwdGGuxYZL803oygTTnH1dDsn7HSs7gLCjd3 Tb2sZSEDGTh5cf9w/VxgfjAqkOUgxuvo8tVkG91F2Q== X-Google-Smtp-Source: ABdhPJzgQQtTrtE3/Hc2fRB2bcz4gBsyOOizeQLn6OGRPOhSsEHJQ+f4ieYhco+ikgb+s57kkJCajeLDkkcrzToj9F8= X-Received: by 2002:a05:6512:3745:: with SMTP id a5mr32983800lfs.478.1625935271131; Sat, 10 Jul 2021 09:41:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Sat, 10 Jul 2021 09:41:00 -0700 Message-ID: To: "Rob Wilton (rwilton)" Cc: NetMod WG , =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= Content-Type: multipart/alternative; boundary="00000000000043910e05c6c78e9c" Archived-At: Subject: Re: [netmod] yang-instance-file include-defaults leaf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jul 2021 16:41:20 -0000 --00000000000043910e05c6c78e9c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) wrote: > Andy, > > > > Yes, when I suggested this, I was thinking that a boolean flag might be > sufficient. My point being that automatically filtering out default valu= es > isn=E2=80=99t always the right thing to do. > > > The solution is simple. Get rid of the inappropriate "default trim" statement. If the leaf is present then it identifies the basic-mode that was used to include defaults. If not then the information is either not known, not applicable, or defaults were not added. The "default" statement is a bug because there is no default basic-mode. All of the basic-modes are in use in deployments and no camp has ever been able to convince the others that theirs is right. Andy > E.g., something along these lines: > > > > leaf exclude-defaults { > > type boolean; > > default true; > > description > > =E2=80=9CCan be used to reduce the size of the content data file. > > > > When unset or set to true, data nodes that have a default defined a= nd > > where the actual value is the default value are excluded from the > content > > data. > > > > When set to false, data nodes with default value are not filtered, > and > > may appear in the content data.=E2=80=9D > > } > > > > Would this satisfy your concern? > > > > Regards, > Rob > > > > > > *From:* netmod *On Behalf Of *Andy Bierman > *Sent:* 08 July 2021 18:16 > *To:* NetMod WG > *Subject:* [netmod] yang-instance-file include-defaults leaf > > > > Hi, > > > > The module has this object: > > > > leaf includes-defaults { > > type enumeration { > > enum report-all { > > value 1; > > description > > "All data nodes SHOULD be included independent of > > any default values."; > > } > > enum trim { > > value 2; > > description > > "Data nodes that have a default defined and where > > the actual value is the default value SHOULD > > NOT be included."; > > } > > enum explicit { > > value 3; > > description > > "Data nodes that have a default defined and where > > the actual value is the default value SHOULD NOT be > > included. However, if the actual value was set by > > a NETCONF client or other management application > > by the way of an explicit management operation the > > data node SHOULD be included."; > > } > > } > > default trim; > > > > The draft is extremely server-centric, like most IETF standards, but this > > leaf is too server-centric to ignore. > > > > Consider the possibility that the source of the file is NOT a NETCONF > server. > > This data may not be known so the default of "trim" may not be correct. > > > > IMO this leaf is noise because any tool that knows the schema will also > > know the YANG defaults. The solution is incomplete anyway because > > the presence of a leaf that has a YANG default is not enough. > > The "report-all-tagged" mode must be used to identify defaults. > > IMO this leaf should be removed, but at least add an enum called "unknown= ". > > > > > > Andy > > > > > --00000000000043910e05c6c78e9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jul 9, 2021 at 5:23 AM Rob Wi= lton (rwilton) <rwilton@cisco.com> wrote:

Andy,

=C2=A0

Yes, when I suggested this, I was thinking tha= t a boolean flag might be sufficient.=C2=A0 My point being that automatical= ly filtering out default values isn=E2=80=99t always the right thing to do.=

=C2=A0



The solution is simple.
Get= rid of the inappropriate "default trim" statement.
If the leaf is present then it identifies the basic-mode that w= as used to include defaults.
If not then the information is eithe= r not known, not applicable, or defaults were not added.

The "default" statement is a bug because there is no defau= lt basic-mode.
All of the basic-modes are in use in deployments a= nd no camp has ever
been able to convince the others that theirs = is right.


Andy
=C2=A0

E.g., something along these lines:

=C2=A0

leaf exclude-defaults {

=C2=A0 type boolean;

=C2=A0 default true;

=C2=A0 description

=C2=A0=C2=A0=C2=A0 =E2=80=9CCan be used to red= uce the size of the content data file.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When unset or s= et to true, data nodes that have a default defined and=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 where the actua= l value is the default value are excluded from the content

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0data.=

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When set to fal= se, data nodes with default value are not filtered, and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 may appear in t= he content data.=E2=80=9D

}

=C2=A0

Would this satisfy your concern?=

=C2=A0

Regards,
Rob

=C2=A0

=C2=A0

=C2=A0

Hi,

=C2=A0

The module has this object:

=C2=A0

=C2=A0=C2=
=A0=C2=A0 leaf includes-defaults {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type =
enumeration {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 enum report-all {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 value 1;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 description
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "All data nodes SHOULD be included inde=
pendent of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 any default values.";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 enum trim {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 value 2;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 description
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Data nodes that have a default defined=
 and where
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the actual value is the default =
value SHOULD
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NOT be included.";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 enum explicit {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 value 3;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 description
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Data nodes that have a default defined=
 and where
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the actual value is the default =
value SHOULD NOT be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 included. However, if the actual=
 value was set by
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a NETCONF client or other manage=
ment application
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 by the way of an explicit manage=
ment operation the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 data node SHOULD be included.&qu=
ot;;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<=
/u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 defau=
lt trim;
=C2=
=A0

The draft is extremely server-centric, like most IET= F standards, but this

leaf is too server-centric to ignore.<= /p>

=C2=A0

Consider the possibility that the source of the file= is NOT a NETCONF server.

This data may not be known so the default of "t= rim" may not be correct.

=C2=A0

IMO this leaf is noise because any tool that knows t= he schema will also

know the YANG defaults.=C2=A0 The solution is incomp= lete anyway because

the presence of a leaf that has a YANG default is no= t enough.

The=C2=A0 "report-all-tagged" mode must be= used to identify defaults.

IMO this leaf should be removed, but at least add an= enum called "unknown".

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

--00000000000043910e05c6c78e9c-- From nobody Mon Jul 12 04:49:16 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4212C3A0FC7; Mon, 12 Jul 2021 04:49:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <162609055423.25950.3365211080451483939@ietfa.amsl.com> Date: Mon, 12 Jul 2021 04:49:14 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-16.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 11:49:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : YANG Instance Data File Format Authors : Balazs Lengyel Benoit Claise Filename : draft-ietf-netmod-yang-instance-file-format-16.txt Pages : 28 Date : 2021-07-12 Abstract: There is a need to document data defined in YANG models at design time, implementation time or when a live server is unavailable. This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models, and annotates it with metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 06:28:16 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCD23A177C; Mon, 12 Jul 2021 06:28:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Lars Eggert via Datatracker To: "The IESG" Cc: draft-ietf-netmod-nmda-diff@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, Joel Jaeggli , joelja@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Lars Eggert Message-ID: <162609649382.9016.4775141501794218285@ietfa.amsl.com> Date: Mon, 12 Jul 2021 06:28:14 -0700 Archived-At: Subject: [netmod] Lars Eggert's No Objection on draft-ietf-netmod-nmda-diff-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 13:28:14 -0000 Lars Eggert has entered the following ballot position for draft-ietf-netmod-nmda-diff-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 1. , paragraph 2, nit: > s both applied configuration data as well as status and statistics. As a resu > ^^^^^^^^^^ Probable usage error. Use "and" after "both". Section 6. , paragraph 2, nit: > ormat): HTTP/1.1 200 OK Date: Thu, 26 Jan 2019 20:56:30 GMT Server: example-s > ^^^^^^^^^^^^^^^^ The date 26 Jan 2019 is not a Thursday, but a Saturday. Uncited references: [RFC6991]. These URLs point to tools.ietf.org, which is being deprecated: * http://tools.ietf.org/wg/netconf/ These URLs in the document can probably be converted to HTTPS: * http://tools.ietf.org/wg/netconf/ From nobody Mon Jul 12 06:37:07 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 105BB3A184F; Mon, 12 Jul 2021 06:37:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-netmod-nmda-diff@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, Joel Jaeggli , joelja@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <162609701948.27666.2697145264761217995@ietfa.amsl.com> Date: Mon, 12 Jul 2021 06:37:00 -0700 Archived-At: Subject: [netmod] Roman Danyliw's No Objection on draft-ietf-netmod-nmda-diff-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 13:37:06 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-netmod-nmda-diff-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Alexey Melnikov for the SECDIR review. ** Section 4. “differences†bullet. Per “… defined in RFC8072â€, please make “RFC8072†an reference. ** Section 6. Please review Alexey’s feedback on providing an empty line between the HTTP header and playload. ** Section 6. “same request in RESTCONF (using JSON format)â€. Missing “:†making the JSON invalid. OLD { "ietf-nmda-compare:input" { NEW { "ietf-nmda-compare:input": { ** Section 9. The primary new security issue is definitely the possibility of a denial of service as is documented. I’m not sure what assumption are being made about the datastores -- would it be possible that a user doesn’t have read access to either the source and target of the comparison, but would be able to invoke the RPC? If so, this might leak configuration information. From nobody Mon Jul 12 11:06:24 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EF93A0AA3; Mon, 12 Jul 2021 11:06:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <162611317546.20241.1098970468119145113@ietfa.amsl.com> Date: Mon, 12 Jul 2021 11:06:15 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-yang-module-versioning-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 18:06:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Updated YANG Module Revision Handling Authors : Robert Wilton Reshad Rahman Balazs Lengyel Joe Clarke Jason Sterne Filename : draft-ietf-netmod-yang-module-versioning-03.txt Pages : 40 Date : 2021-07-12 Abstract: This document specifies a new YANG module update procedure that can document when non-backwards-compatible changes have occurred during the evolution of a YANG module. It extends the YANG import statement with an earliest revision filter to better represent inter-module dependencies. It provides help and guidelines for managing the lifecycle of YANG modules and individual schema nodes. It provides a mechanism, via the revision-label YANG extension, to specify a revision identifier for YANG modules and submodules. This document updates RFC 7950, RFC 8407 and RFC 8525. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-module-versioning-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 11:45:48 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0923A0DD3; Mon, 12 Jul 2021 11:45:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <162611554666.12890.8357795529251581151@ietfa.amsl.com> Date: Mon, 12 Jul 2021 11:45:46 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-yang-semver-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 18:45:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : YANG Semantic Versioning Authors : Benoit Claise Joe Clarke Reshad Rahman Robert Wilton Balazs Lengyel Jason Sterne Kevin D'Souza Filename : draft-ietf-netmod-yang-semver-03.txt Pages : 23 Date : 2021-07-12 Abstract: This document specifies a scheme and guidelines for applying a modified set of semantic versioning rules to revisions of YANG modules. Additionally, this document defines a revision-label for this modified semver scheme. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netmod-yang-semver-03.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-semver-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 14:38:58 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5F03A0D74; Mon, 12 Jul 2021 14:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfyzTiiNqb_J; Mon, 12 Jul 2021 14:38:48 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2106.outbound.protection.outlook.com [40.107.223.106]) (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 DF4E53A0D6B; Mon, 12 Jul 2021 14:38:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bdZOio3RiqCddJOzBgPlS94GVt/FfeViEweYVaDty1cIGCutq3hvbJds2jhxzTCZ++Qe9i4YZQEJvw53tNr3Vlmmy647OpF309FhrJB0SXwapshF0X02leK/MZfOmP/wekVcuZuTW3AEIq2+f9FrJH7vdCGMIWIGPxhtRIbqyNAxTXDzp0aqznReZc+nqgSCd/n+wn7gPZLy1FBrU8lc9IpDkP3k/tpqMdp8PpRJvwZ+Ewy3m0qFENuO0eGwsIykgPTI4+JqK7LWkt5i3cVPA1qD4u8zkjNsApF9pPNU0FbBepApgWmUlTEYVDXcEqnbv3WADri7Y5Mqa6Givv5gfw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L60NXmOSckDInA2y3uV9ljvggQEQI8TqdJDMmYwfIEc=; b=T9kr7T0tMOzaj9wi04icrVwjG/iyhlh4nkQNf4b+sW+9zAXb0dAv/itNCD/qiL+oNJlRhwmyrUgcjbmMmvmfhcg9Ch6XsPj3vnBTSUu6gcs5t1C+DK5J0n4ixHzH7uxFRY1FZQoLuTIHwF3PRgHE5H16kJDdc444dAMKSXvjfuUyb6p9mjRAGSEssVViWlMOtrPR618LDufhU+hIGheEKDdQN3Zx5jWpa6MqajnjhqD99cBjgDAuBO9IIC5O7kzsjxRAaAePJB61nUSC2bFr65ODHRsCuos8oUgdnRPdop4jypi7exN5RPu9FNLZ4J/IOSGVJtRvjR05rvblMybMyA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L60NXmOSckDInA2y3uV9ljvggQEQI8TqdJDMmYwfIEc=; b=PRzf7lGMWV5+djYPRfI3W6mlD3pzZ+R8AgFVyrIEMs2kEm+eFJKM7oVLi7uBVz4ArILNGfNkQCbSz1uQuaE8eIOzx7aHwgLzxtqHdoJVESa77MOqVFwTosN6Rtu/zHWVsXY/vy63BmiaMsU71ugw63clyq92wDBeBeKDp03WQ1E= Received: from BY5PR13MB3793.namprd13.prod.outlook.com (2603:10b6:a03:226::15) by BY5PR13MB4437.namprd13.prod.outlook.com (2603:10b6:a03:1de::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.17; Mon, 12 Jul 2021 21:38:44 +0000 Received: from BY5PR13MB3793.namprd13.prod.outlook.com ([fe80::f93b:c5d8:afb4:e7fb]) by BY5PR13MB3793.namprd13.prod.outlook.com ([fe80::f93b:c5d8:afb4:e7fb%9]) with mapi id 15.20.4331.020; Mon, 12 Jul 2021 21:38:44 +0000 From: Alexander Clemm To: Andy Bierman , Shwetha Bhandari CC: Last Call , "ops-dir@ietf.org" , NetMod WG , "draft-ietf-netmod-nmda-diff.all@ietf.org" Thread-Topic: [netmod] Opsdir last call review of draft-ietf-netmod-nmda-diff-09 Thread-Index: AQHXb0JEL/Olq4xYnkeE7hZT/s52sKsvzKEAgBAdJ9A= Date: Mon, 12 Jul 2021 21:38:44 +0000 Message-ID: References: <162523075802.5464.801347526657945@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7f4cef79-a2f8-412e-7215-08d9457d6c6b x-ms-traffictypediagnostic: BY5PR13MB4437: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JlDgmX+kdEzAUNxQ2PeeQQQlmNIVsqCdibU96DwTGAtWiwTMFlWifFD1bTMUiLbxfSiNgFd4/YoTpa7eNW46nljDwRcZ0vQxRwAKAVLFe8F83DnpBsWhFSP7jkkx/E4Tkud48PFKgaD/O0t45EaxS6QU7wuI2oFSUqmncp2GcH9dSrR9tCEd16P3frjD3SshammmxxrfnkDz9VlK6yFbrqhMKp3YIN13nQpFhR7i0laV8XzozMeNcJb0wFt/Fb7ZLr6zB7een8wL3J2MNf1Q2mC2dyxoBZu63PsCsemssExHQsfWTSj2Le8B3YvyezUh/snroj5hV/olGyYMcKc6qbDyyh1Pkf8/dZzxAzjKT7PlcOxP/x+Nhx9VxbdIEhHTAQNWa8Fc9usgZK2z445kBcTQlxEIw7FKmxulMFRc2+Nv3HRQ00qTccEXjnPcmGUmx8hE6VAQ9nKbt4fgyoCf670I0ko2tP8YxeTwxRposIpnm4QsMJhF9SWv+tzm0TqjtIy7l4y0zSCdGAwDBM6xJF7XJ0NCNbbTkhfWhExUCJekwfqj0z7R/Pkw/tODw3ZD9zXkKrpz0CwWCinDcTIfO26Ax3gnbnhtXWeoK0Cf+otfwdoRuX1cs9StlgzaKWhwpVmphZ7WL6/CNZqjmJdciQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR13MB3793.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39840400004)(136003)(366004)(376002)(346002)(396003)(478600001)(110136005)(186003)(4326008)(2906002)(316002)(33656002)(7696005)(8676002)(5660300002)(9326002)(8936002)(86362001)(54906003)(38100700002)(66574015)(122000001)(71200400001)(55016002)(9686003)(26005)(52536014)(53546011)(64756008)(66446008)(66476007)(76116006)(66946007)(83380400001)(6506007)(66556008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?YWtTUE9SZSs1U3VUZ0hwSStlQys1cmJIOUY3MktkYThMQ1hob0h6UE5jc3NM?= =?utf-8?B?NFJCZG00SmVHRU9aYjFBdzdtajdSNDJsU1ZadkFFNTZBVkNqRG9qUjFyRmN3?= =?utf-8?B?QmpraC9QVndJTVArMzQzMVJGVEpZV3FLK0R6amxTYWJBcUEveklxOUxTaklz?= =?utf-8?B?dEhOZmlsT1ArYmQrSERDRm4ySzcvbnl4NmhBNlhac0xoUFBGVU1zd1F1WDlE?= =?utf-8?B?VVdMamNNWlZEcS9GU0d2cFIrV0xzZHdYRGlGN1V3NGc0c0RnQzMxa2dQUXd2?= =?utf-8?B?U3BEemxZbzBsbUZkUmpRWjRvcXM0bXhidlNSODlLVU04WVFOank2Sk9aMmV2?= =?utf-8?B?cnplaHZ6NDhFRm5UaWlxZDJ3a0VNS250aWNRcHZOV1kwNjdaMkhiV3JJQys3?= =?utf-8?B?QmxKVmpXOUpVNkhGdGgvMmlhbWFEQng1YjZhU3dyVHgyTmtYYkVwcWszNVYr?= =?utf-8?B?bXpFbmZ2OVdPVy9VNk91YlNUVWZLdVh4cU9ocG8rNitiN21rb25aUzY1OTgr?= =?utf-8?B?MUJCdDRoYXJveENvYWs3aHV6SVRhY0ZEc2NJRGsvT2F4MjZBOXJXMEptcG5v?= =?utf-8?B?ZEtsOEpYbWYxQ3gzbGRZOWxzS1VVbmRjZndhNXkvaFhqZzRudE9ZdmkzaHds?= =?utf-8?B?YmhlUi9RbE9nY2dTL1JiYXZLTEZiNjlBdFlYb3JsSVh0ZEpLZVQ4S3VYdGpy?= =?utf-8?B?cSt0ZjBxMHhiVmVPMlg2bzFJd0d3VGNBdkptbHRqZit2OHhsMEtha01SVTdD?= =?utf-8?B?MGo2VUE1ZWd2WTgzQ1VjczJHczhKbnR2bCtuUzNSV3E0WWhyVktucnduL0xs?= =?utf-8?B?SDdkWHJtV2NKQm9LWnBGVUdiL3hCK3lGZ3dHKzRScnJEUUUvZVFZdmVUZ1dh?= =?utf-8?B?aXg0aTUxWEhpK20wUHFrSmhyZ0QwV0M0UHVkbktXckJVbzZra0lzNGZ5M29N?= =?utf-8?B?Yi8wNnROWXEzM2ZKK0tqdnFuODhzWklGVVpubWlzNVlmVG9xUW1UNTZqc3A0?= =?utf-8?B?ajZkOHc2OEg0NlB5SUNrSWJrRjZSallNSUl1cFZjT1JnVDhiZ2JGVkFlZ0FK?= =?utf-8?B?a1lHaFNuek56dmgrdHdqZUtwZ1BMRGZNMS9Tb21GbXVKL3FJQmU0UUgvYksz?= =?utf-8?B?QVgzSUtubDZwN1JDV0JnWU1YQTVvQnRieGh0UzJPVkxqNlgvQXVKbW9NSVdz?= =?utf-8?B?M2FkMThuelJITFlUTVEvc2pGWVF4NEw1YUVhZXJzd3hkWk1FRkFVMTBVMGxB?= =?utf-8?B?QXdtRllYZlZlZ0lvSTBtWVFNUzFYRG40eW5GVXpNQ3h5QkN0UmFzUkczWFRC?= =?utf-8?B?R0UxRm04UTF4anNxTXZzVVVEdi9vU3ljNEFTZFFTTHFuVWptTEE1Qm9QQUNN?= =?utf-8?B?WWc1S05oTmIwV0FaaXcxcmJaby9QRkpNYjNZZlJkeWg2ZUNRTkQ1dC9NZzRU?= =?utf-8?B?dlFFbGF2NEVzazVKVTg3dEcyZFJMdUZCc1VuYU5GOFVxK24wcXJldU9XaWN5?= =?utf-8?B?dnJjSGlkdmtiT0kwaEpLS3V3N2c1TDFsNFVkRDlHSVJaRUV5RnlhbnFaaWw2?= =?utf-8?B?dWd1OUtFVHVoNlBqVTRQbld5MUtnd3ZTa3pGOVhsTHpCN0Y0K0F1NDM4dC9H?= =?utf-8?B?cHNMVDFHNk5DazVMOVZpZHRPaVBBOTF2SWtSL3IzSGpNOXVVTU9lejVKTGJ4?= =?utf-8?B?bUxiUzk0dnM1M1REQm13a2RjeEF2dUV6MDJzdzB0ZUNJdFlTaTJnRjg0WTA4?= =?utf-8?Q?2BTEy5nR3MmATeC54c=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR13MB37935ADA83574850B72D4551DB159BY5PR13MB3793namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR13MB3793.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7f4cef79-a2f8-412e-7215-08d9457d6c6b X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2021 21:38:44.0819 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: oCSmNhrJS/yRKrulTBpUg6z2BU2mnKRBFZJ9x0WQlczzgoyF1UwTx+cTKMhxexKQOXvKUJ6k8o3iCGkI1ewd+Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB4437 Archived-At: Subject: Re: [netmod] Opsdir last call review of draft-ietf-netmod-nmda-diff-09 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 21:38:54 -0000 --_000_BY5PR13MB37935ADA83574850B72D4551DB159BY5PR13MB3793namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gU2hldGhhLA0KDQoNCg0KVGhhbmsgeW91IGZvciB5b3VyIHJldmlldy4NCg0KDQoNClRv IHRoZSBvcGVuIHF1ZXN0aW9uIHRvIHRoZSBhdXRob3JzLCBhZGRpbmcgdG8gQW5keeKAmXMgcmVw c29uc2U6DQoNCg0KDQpUaGUgbW9uaXRvcmluZyBvZiByZXNvdXJjZXMgY29uc3VtZWQgYnkgcmVx dWVzdHMsIG1lYXN1cmluZyB0aGUgcmF0ZSBvZiByZXF1ZXN0cyBldGMgaXMgZGVlbWVkIHRvIGdv IGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBJbnRlcm5ldCBEcmFmdC4gIFRoZSBhYmlsaXR5IHRv IG1vbml0b3Igc3VjaCBhc3BlY3RzIGlzIGluZGVlZCBhIHZhbGlkIHN5c3RlbSBtYW5hZ2VtZW50 IGNvbmNlcm4sIGJ1dCBvbmUgdGhhdCBpcyBub3Qgc3BlY2lmaWMgdG8gdGhpcyBkcmFmdCAoYnV0 IGFwcGx5IHRvIG90aGVyIGRyYWZ0cyBkZWZpbmluZyBSUEMgb3BlcmF0aW9ucyBhcyB3ZWxsKS4g IElmIHN1Y2ggYXNwZWN0cyBzaG91bGQgYmUgYWRkcmVzc2VkLCBpdCB3b3VsZCBwcm9iYWJseSBj YWxsIGZvciBhIG1vcmUgZ2VuZXJhbCBtb2RlbCBpbiBpdHMgb3duIHJpZ2h0LiAgVGhhdCBzYWlk LCBTZWN0aW9uIDcgYWN0dWFsbHkgZGlzY3Vzc2VzIHBlcmZvcm1hbmNlIGNvbnNpZGVyYXRpb24u ICBJdCBkb2VzIHN0YXRlIHRoYXQgaW1wbGVtZW50YXRpb25zIG5lZWQgdG8gYmUgYXdhcmUgb2Yg dGhlIGZhY3QgdGhhdCBleGNlc3NpdmUgaW52b2NhdGlvbiBvZiB0aGUgb3BlcmF0aW9uIHdpbGwg YnVyZGVuIHN5c3RlbSByZXNvdXJjZXMsIGFuZCB0aGF0IG1pdGlnYXRpb24gc2NoZW1lcyBpbmNs dWRlIChpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYykgcmF0ZSBsaW1pdGluZyBhbmQgc2VydmVycyBy ZWplY3RpbmcgcmVxdWVzdHMgbWFkZSBhdCBhICAgaGlnaGVyIGZyZXF1ZW5jeSB0aGFuIHRoZSBp bXBsZW1lbnRhdGlvbiBjYW4gcmVhc29uYWJseSBzdXN0YWluLiAgV2UgY291bGQgYWRkIGEgc2Vu dGVuY2UgdG8gdGhlIGVmZmVjdCB0aGF0IOKAnE1vbml0b3Jpbmcgb2Ygc2VydmVyIHJlc291cmNl cyBhbmQgc3RhdGlzdGljcyBhYm91dCBSUEMgcmF0ZXMgd2lsbCBiZSB1c2VmdWwgdG8gcHJvdmlk ZSBvcGVyYXRvcnMgd2l0aCB0b29scyB0aGF0IGFsbG93IHRvIGFzc2VzcyB0aGUgYWN0dWFsIG92 ZXJoZWFkIGltcG9zZWQgb24gdGhlaXIgaW1wbGVtZW50YXRpb24gdGhyb3VnaCB0aGF0IGZlYXR1 cmUuICBIb3dldmVyLCB0aGUgZGVmaW5pdGlvbiBvZiBhbnkgY29ycmVzcG9uZGluZyBZQU5HIGRh dGEgbW9kZWxzIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiAgSWYgZGVm aW5lZCwgYW55IHN1Y2ggbW9kZWwgc2hvdWxkIGJlIG5laXRoZXIgc3BlY2lmaWMgbm9yIHNob3Vs ZCBpdCBiZSBsaW1pdGVkIHRvIHRoZSBSUEMgb3BlcmF0aW9ucyBkZWZpbmVkIGFzIHBhcnQgb2Yg dGhpcyBkb2N1bWVudC7igJ0NCg0KUmU6IHRoZSBuaXQsIHllcywgdGhpcyBzaG91bGQgYmUgYXBw bGljYXRpb24veWFuZy1kYXRhK2pzb24NCg0KV2lsbCB1cGRhdGUgdGhlIGRyYWZ0IHNob3J0bHku DQoNClRoYW5rcw0KLS0tIEFsZXgNCkZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBBbmR5IEJpZXJtYW4NClNlbnQ6IEZyaWRheSwgSnVseSAyLCAyMDIx IDg6MTkgQU0NClRvOiBTaHdldGhhIEJoYW5kYXJpIDxzaHdldGhhLmJoYW5kYXJpQGdtYWlsLmNv bT4NCkNjOiBMYXN0IENhbGwgPGxhc3QtY2FsbEBpZXRmLm9yZz47IG9wcy1kaXJAaWV0Zi5vcmc7 IE5ldE1vZCBXRyA8bmV0bW9kQGlldGYub3JnPjsgZHJhZnQtaWV0Zi1uZXRtb2Qtbm1kYS1kaWZm LmFsbEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIE9wc2RpciBsYXN0IGNhbGwgcmV2 aWV3IG9mIGRyYWZ0LWlldGYtbmV0bW9kLW5tZGEtZGlmZi0wOQ0KDQoNCg0KT24gRnJpLCBKdWwg MiwgMjAyMSBhdCA1OjU5IEFNIFNod2V0aGEgQmhhbmRhcmkgdmlhIERhdGF0cmFja2VyIDxub3Jl cGx5QGlldGYub3JnPG1haWx0bzpub3JlcGx5QGlldGYub3JnPj4gd3JvdGU6DQpSZXZpZXdlcjog U2h3ZXRoYSBCaGFuZGFyaQ0KUmV2aWV3IHJlc3VsdDogSGFzIE5pdHMNCg0KSSBoYXZlIHJldmll d2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgT3BlcmF0aW9uYWwgZGlyZWN0b3JhdGUn cw0Kb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9j ZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZQ0KY29tbWVudHMgd2VyZSB3cml0dGVuIHdpdGggdGhl IGludGVudCBvZiBpbXByb3ZpbmcgdGhlIG9wZXJhdGlvbmFsIGFzcGVjdHMgb2YNCnRoZSBJRVRG IGRyYWZ0cy4gQ29tbWVudHMgdGhhdCBhcmUgbm90IGFkZHJlc3NlZCBpbiBsYXN0IGNhbGwgbWF5 IGJlIGluY2x1ZGVkDQppbiBBRCByZXZpZXdzIGR1cmluZyB0aGUgSUVTRyByZXZpZXcuICBEb2N1 bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkDQp0cmVhdCB0aGVzZSBjb21tZW50cyBq dXN0IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4NCg0KIFN1bW1hcnk6DQpUaGlz IGlzIGEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHRoYXQgZGVmaW5lcyBhbiBSUEMgb3BlcmF0 aW9uIHRvIGNvbXBhcmUNCm1hbmFnZW1lbnQgZGF0YXN0b3JlcyBhbmQgcmV0dXJucyBkaWZmcyBi ZXR3ZWVuIHRoZSBkYXRhc3RvcmVzIGFzIGEgeWFuZy1wYXRjaC4NCg0KV2hpbGUgIG1vc3QgYWNj ZXNzIG1hbmFnZW1lbnQgb2YgdGhlIFJQQywgZW5zdXJpbmcgYXZhaWxhYmlsaXR5IG9mIHRoZSBz ZXJ2ZXINCmJ5IHJhdGUgbGltaXRpbmcgYXJlIGNvbnNpZGVyZWQgSSBoYXZlIGFuIG9wZW4gcXVl c3Rpb24gdG8gYXV0aG9yczogd2hlcmUvaG93DQp3aWxsIG9wZXJhdGlvbmFsIG1ldHJpY3Mgc3Vj aCBhcyByYXRlIG9mIHJlcXVlc3RzIHJlY2VpdmVkLCBlcnJvcnMsIHJhdGUNCmxpbWl0aW5nIGlm IGFwcGxpZWQsIHNlcnZlciByZXNvdXJjZXMgY29uc3VtZWQgdG8gcHJvY2VzcyB0aGUgcmVxdWVz dCBldGMsDQphYm91dCB0aGlzIG5ldyBSUEMgYmUgZGVmaW5lZCBhbmQgcmVwb3J0ZWQ/IFRoaXMg aXMgdXNlZnVsIGluZm9ybWF0aW9uIGZvcg0Kc2VydmVyIG9wZXJhdGlvbiB3aGVyZSB0aGlzIFJQ QyBpcyBlbmFibGVkLg0KDQoNClRoZXJlIGFyZSBubyBzdGFuZGFyZCBZQU5HIG9iamVjdHMgdG8g bW9uaXRvciB0aGUgc2VydmVyIHJlc291cmNlcy4NClRoaXMgbmV3IG9wZXJhdGlvbiBpcyBsaWtl bHkgdG8gY29uc3VtZSBhIGxvdCBvZiByZXNvdXJjZXMgc28gSSB1bmRlcnN0YW5kIHlvdXIgY29u Y2Vybi4NClRoZSBhY3R1YWwgZGlmZiByZXN1bHRzIG1heSBkZXBlbmQgb24gaW1wbGVtZW50YXRp b24gY2hvaWNlcyBhbmQgaW1wYWN0IHJlc291cmNlcyB1c2VkLg0KRS5nLiBjb21wYXJpbmcgMiBk YXRhc3RvcmVzIHRoYXQgYXJlIGNvbnN0YW50bHkgY2hhbmdpbmcgd2hpbGUgdGhleSBhcmUgYmVp bmcgY29tcGFyZWQuDQoNCkkgYW0gbm90IHN1cmUgd2hhdCBjaGFuZ2VzIHRvIHRoZSBkcmFmdCBh cmUgbmVlZGVkIGF0IHRoaXMgdGltZS4NCkEgcmVzb3VyY2UgbW9uaXRvcmluZyBtb2R1bGUgd291 bGQgYmUgYSBnZW5lcmFsaXplZCBzb2x1dGlvbiBidXQgaXQgZG9lcw0Kbm90IGJlbG9uZyBpbiB0 aGlzIGRyYWZ0Lg0KDQpOaXRzOg0KVGhlIFJFU1RDT05GIGV4YW1wbGUgY29udGVudC10eXBlIGlz IGpzb24gYnV0IGl0IGlzIHNldCB0byBhcHBsaWNhdGlvbi95YW5nLWQNCnRoYXQgaXMgbm90IHBy ZXNlbnQgaW4gdGhlIHJlZ2lzdHJ5IC0gc2hvdWxkIGl0IGJlIGFwcGxpY2F0aW9uL3lhbmctcGF0 Y2granNvbj8NCg0KSSB0aGluayBpdCBpcyBzdXBwb3NlZCB0byBiZSBhcHBsaWNhdGlvbi95YW5n LWRhdGEranNvbg0KDQoNCkFuZHkNCg0K --_000_BY5PR13MB37935ADA83574850B72D4551DB159BY5PR13MB3793namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxh aW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4g VGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWst d29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+SGVsbG8gU2hldGhhLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFuayB5b3Ug Zm9yIHlvdXIgcmV2aWV3LiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VG8g dGhlIG9wZW4gcXVlc3Rpb24gdG8gdGhlIGF1dGhvcnMsIGFkZGluZyB0byBBbmR54oCZcyByZXBz b25zZToNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGUgbW9uaXRvcmluZyBvZiBy ZXNvdXJjZXMgY29uc3VtZWQgYnkgcmVxdWVzdHMsIG1lYXN1cmluZyB0aGUgcmF0ZSBvZiByZXF1 ZXN0cyBldGMgaXMgZGVlbWVkIHRvIGdvIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBJbnRlcm5l dCBEcmFmdC4mbmJzcDsgVGhlIGFiaWxpdHkgdG8gbW9uaXRvciBzdWNoIGFzcGVjdHMgaXMgaW5k ZWVkIGEgdmFsaWQgc3lzdGVtIG1hbmFnZW1lbnQgY29uY2VybiwgYnV0IG9uZSB0aGF0DQogaXMg bm90IHNwZWNpZmljIHRvIHRoaXMgZHJhZnQgKGJ1dCBhcHBseSB0byBvdGhlciBkcmFmdHMgZGVm aW5pbmcgUlBDIG9wZXJhdGlvbnMgYXMgd2VsbCkuJm5ic3A7IElmIHN1Y2ggYXNwZWN0cyBzaG91 bGQgYmUgYWRkcmVzc2VkLCBpdCB3b3VsZCBwcm9iYWJseSBjYWxsIGZvciBhIG1vcmUgZ2VuZXJh bCBtb2RlbCBpbiBpdHMgb3duIHJpZ2h0LiZuYnNwOyBUaGF0IHNhaWQsIFNlY3Rpb24gNyBhY3R1 YWxseSBkaXNjdXNzZXMgcGVyZm9ybWFuY2UgY29uc2lkZXJhdGlvbi4mbmJzcDsNCiBJdCBkb2Vz IHN0YXRlIHRoYXQgaW1wbGVtZW50YXRpb25zIG5lZWQgdG8gYmUgYXdhcmUgb2YgdGhlIGZhY3Qg dGhhdCBleGNlc3NpdmUgaW52b2NhdGlvbiBvZiB0aGUgb3BlcmF0aW9uIHdpbGwgYnVyZGVuIHN5 c3RlbSByZXNvdXJjZXMsIGFuZCB0aGF0IG1pdGlnYXRpb24gc2NoZW1lcyBpbmNsdWRlIChpbXBs ZW1lbnRhdGlvbi1zcGVjaWZpYykgcmF0ZSBsaW1pdGluZyBhbmQgc2VydmVycyByZWplY3Rpbmcg cmVxdWVzdHMgbWFkZSBhdCBhICZuYnNwOyZuYnNwO2hpZ2hlcg0KIGZyZXF1ZW5jeSB0aGFuIHRo ZSBpbXBsZW1lbnRhdGlvbiBjYW4gcmVhc29uYWJseSBzdXN0YWluLiAmbmJzcDtXZSBjb3VsZCBh ZGQgYSBzZW50ZW5jZSB0byB0aGUgZWZmZWN0IHRoYXQg4oCcTW9uaXRvcmluZyBvZiBzZXJ2ZXIg cmVzb3VyY2VzIGFuZCBzdGF0aXN0aWNzIGFib3V0IFJQQyByYXRlcyB3aWxsIGJlIHVzZWZ1bCB0 byBwcm92aWRlIG9wZXJhdG9ycyB3aXRoIHRvb2xzIHRoYXQgYWxsb3cgdG8gYXNzZXNzIHRoZSBh Y3R1YWwgb3ZlcmhlYWQgaW1wb3NlZA0KIG9uIHRoZWlyIGltcGxlbWVudGF0aW9uIHRocm91Z2gg dGhhdCBmZWF0dXJlLiZuYnNwOyBIb3dldmVyLCB0aGUgZGVmaW5pdGlvbiBvZiBhbnkgY29ycmVz cG9uZGluZyBZQU5HIGRhdGEgbW9kZWxzIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRv Y3VtZW50LiZuYnNwOyBJZiBkZWZpbmVkLCBhbnkgc3VjaCBtb2RlbCBzaG91bGQgYmUgbmVpdGhl ciBzcGVjaWZpYyBub3Igc2hvdWxkIGl0IGJlIGxpbWl0ZWQgdG8gdGhlIFJQQyBvcGVyYXRpb25z IGRlZmluZWQNCiBhcyBwYXJ0IG9mIHRoaXMgZG9jdW1lbnQu4oCdJm5ic3A7IDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5SZTogdGhlIG5pdCwgeWVzLCB0aGlzIHNob3VsZCBiZSBhcHBsaWNhdGlv bi95YW5nLWRhdGEranNvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaWxsIHVwZGF0ZSB0aGUg ZHJhZnQgc2hvcnRseS4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rczxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tIEFsZXg8bzpwPjwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBu ZXRtb2QgJmx0O25ldG1vZC1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YNCjwv Yj5BbmR5IEJpZXJtYW48YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKdWx5IDIsIDIwMjEgODox OSBBTTxicj4NCjxiPlRvOjwvYj4gU2h3ZXRoYSBCaGFuZGFyaSAmbHQ7c2h3ZXRoYS5iaGFuZGFy aUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBMYXN0IENhbGwgJmx0O2xhc3QtY2FsbEBp ZXRmLm9yZyZndDs7IG9wcy1kaXJAaWV0Zi5vcmc7IE5ldE1vZCBXRyAmbHQ7bmV0bW9kQGlldGYu b3JnJmd0OzsgZHJhZnQtaWV0Zi1uZXRtb2Qtbm1kYS1kaWZmLmFsbEBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW25ldG1vZF0gT3BzZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJh ZnQtaWV0Zi1uZXRtb2Qtbm1kYS1kaWZmLTA5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIEZyaSwgSnVsIDIsIDIwMjEgYXQgNTo1OSBBTSBTaHdldGhhIEJoYW5k YXJpIHZpYSBEYXRhdHJhY2tlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmci Pm5vcmVwbHlAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+UmV2aWV3ZXI6IFNod2V0aGEgQmhhbmRhcmk8YnI+DQpSZXZpZXcgcmVzdWx0OiBIYXMg Tml0czxicj4NCjxicj4NCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2Yg dGhlIE9wZXJhdGlvbmFsIGRpcmVjdG9yYXRlJ3M8YnI+DQpvbmdvaW5nIGVmZm9ydCB0byByZXZp ZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4mbmJzcDsg VGhlc2U8YnI+DQpjb21tZW50cyB3ZXJlIHdyaXR0ZW4gd2l0aCB0aGUgaW50ZW50IG9mIGltcHJv dmluZyB0aGUgb3BlcmF0aW9uYWwgYXNwZWN0cyBvZjxicj4NCnRoZSBJRVRGIGRyYWZ0cy4gQ29t bWVudHMgdGhhdCBhcmUgbm90IGFkZHJlc3NlZCBpbiBsYXN0IGNhbGwgbWF5IGJlIGluY2x1ZGVk PGJyPg0KaW4gQUQgcmV2aWV3cyBkdXJpbmcgdGhlIElFU0cgcmV2aWV3LiZuYnNwOyBEb2N1bWVu dCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkPGJyPg0KdHJlYXQgdGhlc2UgY29tbWVudHMg anVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuPGJyPg0KPGJyPg0KJm5ic3A7 U3VtbWFyeTo8YnI+DQpUaGlzIGlzIGEgU3RhbmRhcmRzIFRyYWNrIGRvY3VtZW50IHRoYXQgZGVm aW5lcyBhbiBSUEMgb3BlcmF0aW9uIHRvIGNvbXBhcmU8YnI+DQptYW5hZ2VtZW50IGRhdGFzdG9y ZXMgYW5kIHJldHVybnMgZGlmZnMgYmV0d2VlbiB0aGUgZGF0YXN0b3JlcyBhcyBhIHlhbmctcGF0 Y2guPGJyPg0KPGJyPg0KV2hpbGUmbmJzcDsgbW9zdCBhY2Nlc3MgbWFuYWdlbWVudCBvZiB0aGUg UlBDLCBlbnN1cmluZyBhdmFpbGFiaWxpdHkgb2YgdGhlIHNlcnZlcjxicj4NCmJ5IHJhdGUgbGlt aXRpbmcgYXJlIGNvbnNpZGVyZWQgSSBoYXZlIGFuIG9wZW4gcXVlc3Rpb24gdG8gYXV0aG9yczog d2hlcmUvaG93PGJyPg0Kd2lsbCBvcGVyYXRpb25hbCBtZXRyaWNzIHN1Y2ggYXMgcmF0ZSBvZiBy ZXF1ZXN0cyByZWNlaXZlZCwgZXJyb3JzLCByYXRlPGJyPg0KbGltaXRpbmcgaWYgYXBwbGllZCwg c2VydmVyIHJlc291cmNlcyBjb25zdW1lZCB0byBwcm9jZXNzIHRoZSByZXF1ZXN0IGV0Yyw8YnI+ DQphYm91dCB0aGlzIG5ldyBSUEMgYmUgZGVmaW5lZCBhbmQgcmVwb3J0ZWQ/IFRoaXMgaXMgdXNl ZnVsIGluZm9ybWF0aW9uIGZvcjxicj4NCnNlcnZlciBvcGVyYXRpb24gd2hlcmUgdGhpcyBSUEMg aXMgZW5hYmxlZC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgYXJlIG5vIHN0YW5kYXJkIFlBTkcgb2JqZWN0cyB0byBt b25pdG9yIHRoZSBzZXJ2ZXIgcmVzb3VyY2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBuZXcgb3BlcmF0aW9uIGlzIGxpa2VseSB0byBj b25zdW1lIGEgbG90IG9mIHJlc291cmNlcyBzbyBJIHVuZGVyc3RhbmQgeW91ciBjb25jZXJuLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGFj dHVhbCBkaWZmIHJlc3VsdHMgbWF5IGRlcGVuZCBvbiBpbXBsZW1lbnRhdGlvbiBjaG9pY2VzIGFu ZCBpbXBhY3QgcmVzb3VyY2VzIHVzZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5FLmcuIGNvbXBhcmluZyAyIGRhdGFzdG9yZXMgdGhhdCBhcmUg Y29uc3RhbnRseSBjaGFuZ2luZyB3aGlsZSB0aGV5IGFyZSBiZWluZyBjb21wYXJlZC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3Qg c3VyZSB3aGF0IGNoYW5nZXMgdG8gdGhlIGRyYWZ0IGFyZSBuZWVkZWQgYXQgdGhpcyB0aW1lLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSByZXNv dXJjZSBtb25pdG9yaW5nIG1vZHVsZSB3b3VsZCBiZSBhIGdlbmVyYWxpemVkIHNvbHV0aW9uIGJ1 dCBpdCBkb2VzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5ub3QgYmVsb25nIGluIHRoaXMgZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+Tml0czo8YnI+DQpUaGUgUkVTVENPTkYgZXhhbXBsZSBjb250ZW50LXR5cGUgaXMganNv biBidXQgaXQgaXMgc2V0IHRvIGFwcGxpY2F0aW9uL3lhbmctZDxicj4NCnRoYXQgaXMgbm90IHBy ZXNlbnQgaW4gdGhlIHJlZ2lzdHJ5IC0gc2hvdWxkIGl0IGJlIGFwcGxpY2F0aW9uL3lhbmctcGF0 Y2granNvbj88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgdGhpbmsgaXQgaXMgc3VwcG9zZWQgdG8gYmUgYXBwbGljYXRpb24veWFu Zy1kYXRhK2pzb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BY5PR13MB37935ADA83574850B72D4551DB159BY5PR13MB3793namp_-- From nobody Mon Jul 12 15:29:03 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF1B3A135B; Mon, 12 Jul 2021 15:28:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <162612893720.22799.792032650893022713@ietfa.amsl.com> Date: Mon, 12 Jul 2021 15:28:57 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-nmda-diff-10.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 22:28:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Comparison of NMDA datastores Authors : Alexander Clemm Yingzhen Qu Jeff Tantsura Andy Bierman Filename : draft-ietf-netmod-nmda-diff-10.txt Pages : 19 Date : 2021-07-12 Abstract: This document defines an RPC operation to compare management datastores that comply with the NMDA architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-nmda-diff-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-nmda-diff-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 12 15:43:06 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557473A14AA for ; Mon, 12 Jul 2021 15:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 LjdDM-w7SA6c for ; Mon, 12 Jul 2021 15:42:53 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753F53A1551 for ; Mon, 12 Jul 2021 15:42:48 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id h9so11492631ljm.5 for ; Mon, 12 Jul 2021 15:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cuy96aELmIGw0NPQxHN0GbNDygwQO1lOsCYgcdyfSy4=; b=IJXBYZZQ2aUYoguDtmdLVQJqkfIRzsoFR0ahdXtJcbEAwTAodIgU3niMopTW1DFCgC eHAe7RsZd9FzjbsTGjmEYgoKjcB2n0H0p2h8y6Oidtf5UE7y8+cN3F6TfmfCCicijk70 eyU1mTR1kzYwML5OTIOitDlcZwq5PUkglbY9c57VxABgY8NZYWFRsYKIT2sTkxUX49id 0lUoExnELlpsmeNSiwlYp63+IGA9VIbEGxwwRIy53kUG7Tn0gkGoxsRwwTZzitt71m8X J+30qQXSZ6hmfpjh9NK6ImxTEqkG07sF/9ZW4DTJG0CNK/m3RHPei/n66L/IdUXFBI3P i9Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cuy96aELmIGw0NPQxHN0GbNDygwQO1lOsCYgcdyfSy4=; b=hkoKGw9aHIWDqMFK6gKHTlBzf0iikyHz1e8MaGfydRlrtpsm8+GV4kw1ce7fgGUoYR P40315C5mJHolpa56YbOgHxN3ufUsB9+XOcmlD1kLoe1YNVHOo2RVfjgk5X376G8n8e1 QxuCmNXUwHzFKFt0Pi73oxUyS18Iq7Ud5ksHXSyzaxw6Ub8njLxNVOAsb1T7aNMq9a5I yxGO6UFB5S3Ode/J0wslU0iUBN13PzB48EOmNxC38vG0u9FlteaDU186ifmvWDOgrA3c WRyfC9V/n+ZbjWBChpnXMeygutCEGA7syjccQOSg7rB+Fl4GWP1loCQryDPhoTx6oAq+ 1olw== X-Gm-Message-State: AOAM532twV27NHwarKcKluDb/iAuiMsY8Z0q6TJay4QXCuDvMPGWgeJw DRcUh1raUyyJldc9KVRU3o0xvapdoYF2vetqKEGX2g== X-Google-Smtp-Source: ABdhPJzgU+amWeHoS8sMlXJCBKTBT5ueSU25LE76rYvcG0GhcgnMdLUGofFYcG+bRQs2sUgbT1iilFiXmL4nMLG0FW8= X-Received: by 2002:a2e:8403:: with SMTP id z3mr208149ljg.298.1626129761476; Mon, 12 Jul 2021 15:42:41 -0700 (PDT) MIME-Version: 1.0 References: <162578071895.23622.6414701243842084826@ietfa.amsl.com> In-Reply-To: <162578071895.23622.6414701243842084826@ietfa.amsl.com> From: Andy Bierman Date: Mon, 12 Jul 2021 15:42:30 -0700 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-netmod-nmda-diff@ietf.org, NetMod WG Chairs , NetMod WG , Joel Jaeggli Content-Type: multipart/alternative; boundary="000000000000cab04705c6f4d620" Archived-At: Subject: Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-nmda-diff-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 22:43:04 -0000 --000000000000cab04705c6f4d620 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 8, 2021 at 2:45 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-netmod-nmda-diff-09: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks to Alexey Melnikov for the secdir review. > > I'm not experienced enough with YANG to know whether or how problematic > it is that the "anydata subtree-filter" node contents are described by > reference to the NETCONF specification, which has a particular (XML) > representation of YANG data and does not give a clear presentation of > the abstract YANG structure/semantics to be used. Is it possible to use > the filter-spec choice option when, for example, RESTCONF is used with > JSON encoding? > > There is not a standard specification for subtree filtering using JSON encoding instead of XML. RESTCONF has its own somewhat compatible filtering mechanism. It would require a new NETCONF work item to officially expand subtree filtering to support JSON. (Unofficially, there is RFC for JSON encoding of YANG data and an implementation could map the RFC 6241 text to JSON). > Section 4 > > o report-origin: When set, this parameter indicates that origin > metadata should be included as part of RPC output. When this > parameter is omitted, origin metadata in comparisons that involve > is by default omitted. > > Why is it important to complicate the semantics of this parameter with a > dependence on the datastore? It seems like it would be simpler to get > this effect by having clients specify report-origin when the target is > not . Note that changing the semantics would require text > changes in subsequent parts of the document for consistency. (If > retaining the current semantics, please clarify whether "comparisons > that involve " applies when operational is source, target, > or either.) > > IMO NMDA is way too complicated, so I cannot argue with that complaint. The origin attribute only applies to the datastore. I think it is not allowed to appear elsewhere. Section 9 > > In addition to noting that the "compare" RPC is sensitive and should be > restricted to authorized parties, I suggest to reiterate that the > "compare" operation should not provide a mechanism to work around access > control on other nodes -- that is, a result should only be returned if > the requestor would be allowed to access both the "source" and "target" > trees independently of the RPC. In particular, even a "no-matches" > output should not be returned, as that might provide a way to determine > the structure of the datastore even without accessing it. > Fortunately the access control model (NACM) is per server and not per datastore so the same access rules apply to all datastores. I agree the no-access subtrees should be silently skipped, the same way that GET operations are treated in NACM. > We might also incorporate by reference the security considerations for > subtree filtering (RFC 6241) and xpath filtering (RFC 6991). > > NITS > > Section 1 > > an unusually long time to do so. This can be the case due to certain > conditions not being met, certain parts of the configuration not > propagating because considered inactive, resource dependencies not > being resolved, or even implementation errors in corner conditions. > > "because considered inactive" seems like an incomplete clause; maybe > "because they are considered inactive"? > > Section 4 > > o differences: This parameter contains the list of differences. > Those differences are encoded per YANG-Patch data model defined in > > s/YANG-Patch/the YANG-Patch/ > I'd also consider s/per/according to/, since this is not exactly a > logic-driven deduction but rather more of a new requirement. > > Section 6 > > for the management of interfaces defined in [RFC8343]. The excerpt > of the data model whose instantiation is the basis of the comparison > is as follows: > > I feel like this phrasing is a little misleading, as not only is the > following snippet only a subset of the nodes contained within "container > interfaces" but the descriptions have been greatly abbreviated as well. > Perhaps we could say something about "for the purposes of understanding > the subsequent example, the following subset of the [RFC8343] data model > is provided". > > Accept: application/yang-d > > (I believe this truncated header field was already noted by another > reviewer.) > > Andy --000000000000cab04705c6f4d620 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jul 8, 2021 at 2:45 PM Benjam= in Kaduk via Datatracker <noreply@ie= tf.org> wrote:
Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-nmda-diff-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-= ietf-netmod-nmda-diff/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Alexey Melnikov for the secdir review.

I'm not experienced enough with YANG to know whether or how problematic=
it is that the "anydata subtree-filter" node contents are describ= ed by
reference to the NETCONF specification, which has a particular (XML)
representation of YANG data and does not give a clear presentation of
the abstract YANG structure/semantics to be used.=C2=A0 Is it possible to u= se
the filter-spec choice option when, for example, RESTCONF is used with
JSON encoding?



There is not a standard= specification for subtree filtering using JSON encoding
instead = of XML. RESTCONF has its own somewhat compatible filtering mechanism.
=
It would require a new NETCONF work item to officially expand subtree = filtering
to support JSON.=C2=A0 (Unofficially, there is RFC for = JSON encoding of YANG data and an
implementation could map the RF= C 6241 text to JSON).

=C2=A0
Section 4

=C2=A0 =C2=A0o=C2=A0 report-origin: When set, this parameter indicates that= origin
=C2=A0 =C2=A0 =C2=A0 metadata should be included as part of RPC output.=C2= =A0 When this
=C2=A0 =C2=A0 =C2=A0 parameter is omitted, origin metadata in comparisons t= hat involve
=C2=A0 =C2=A0 =C2=A0 <operational> is by default omitted.

Why is it important to complicate the semantics of this parameter with a dependence on the datastore?=C2=A0 It seems like it would be simpler to get=
this effect by having clients specify report-origin when the target is
not <operational>.=C2=A0 Note that changing the semantics would requi= re text
changes in subsequent parts of the document for consistency.=C2=A0 (If
retaining the current semantics, please clarify whether "comparisons that involve <operational>" applies when operational is source, = target,
or either.)


IMO NMDA is way too complicated, so I = cannot argue with that complaint.
The origin attribute only appli= es to the <operational> datastore.
I think it is not allowe= d to appear elsewhere.


Section 9

In addition to noting that the "compare" RPC is sensitive and sho= uld be
restricted to authorized parties, I suggest to reiterate that the
"compare" operation should not provide a mechanism to work around= access
control on other nodes -- that is, a result should only be returned if
the requestor would be allowed to access both the "source" and &q= uot;target"
trees independently of the RPC.=C2=A0 In particular, even a "no-matche= s"
output should not be returned, as that might provide a way to determine
the structure of the datastore even without accessing it.
<= div>
Fortunately the access control model (NACM) is per serve= r and not per datastore
so the same access rules apply to all dat= astores. I agree the no-access subtrees
should be silently skippe= d, the same way that GET operations are treated in NACM.



We might also incorporate by reference the security considerations for
subtree filtering (RFC 6241) and xpath filtering (RFC 6991).

NITS

Section 1

=C2=A0 =C2=A0an unusually long time to do so.=C2=A0 This can be the case du= e to certain
=C2=A0 =C2=A0conditions not being met, certain parts of the configuration n= ot
=C2=A0 =C2=A0propagating because considered inactive, resource dependencies= not
=C2=A0 =C2=A0being resolved, or even implementation errors in corner condit= ions.

"because considered inactive" seems like an incomplete clause; ma= ybe
"because they are considered inactive"?

Section 4

=C2=A0 =C2=A0o=C2=A0 differences: This parameter contains the list of diffe= rences.
=C2=A0 =C2=A0 =C2=A0 Those differences are encoded per YANG-Patch data mode= l defined in

s/YANG-Patch/the YANG-Patch/
I'd also consider s/per/according to/, since this is not exactly a
logic-driven deduction but rather more of a new requirement.

Section 6

=C2=A0 =C2=A0for the management of interfaces defined in [RFC8343].=C2=A0 T= he excerpt
=C2=A0 =C2=A0of the data model whose instantiation is the basis of the comp= arison
=C2=A0 =C2=A0is as follows:

I feel like this phrasing is a little misleading, as not only is the
following snippet only a subset of the nodes contained within "contain= er
interfaces" but the descriptions have been greatly abbreviated as well= .
Perhaps we could say something about "for the purposes of understandin= g
the subsequent example, the following subset of the [RFC8343] data model is provided".

=C2=A0 =C2=A0Accept: application/yang-d

(I believe this truncated header field was already noted by another
reviewer.)



Andy
=C2=A0
--000000000000cab04705c6f4d620-- From nobody Mon Jul 12 19:39:14 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C984F3A095A for ; Mon, 12 Jul 2021 19:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmZHV5YMZDSU for ; Mon, 12 Jul 2021 19:39:08 -0700 (PDT) Received: from sonic308-10.consmr.mail.ne1.yahoo.com (sonic308-10.consmr.mail.ne1.yahoo.com [66.163.187.33]) (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 E63223A094A for ; Mon, 12 Jul 2021 19:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1626143947; bh=cD9bseOrqyQ8k0TBUJkq0KbF6nlkJOBP9cDRT+EL24E=; h=Date:Subject:From:To:References:In-Reply-To:From:Subject:Reply-To; b=A4Z/f7z9pocNP2wt2IG4RxAl7RNxxS6UVsxQJjLEgW25TUNpD6lVwaaDQFIccfT3ZTaOSPKS1cx9UkInY2LzoZmD49vCyQCHPh87v2/ADPe4ccSOxDcG5Fkhm+CFzAWPVXwhYAQ2pR/W8pZRqVblo2CL8LfdsNtwgaimSv4hxgoNkwKE9DCNkNQeswvOSK81uq/SS3/3qXPZNY9nIwgoXNDhqvdFlqEwQM+MQIV+Lkb76fPRxAcix/a8hIuol0mW8AVaMHsFnDP2LO23AF7qdFP7nVdfRVga/Jgr7o+leywv55nq+uhgHCBXU6ZpMLsCRwM+qEFY0xUI/INlswpJxg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1626143947; bh=0q65nyygtaYpOwKhsTX4uRAlbFsNoznE7sqOtXJm5nw=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=T0xozXNGvGwJIWW/41JP2k1pPO+yV6nl6Y+l1jDScu9/VaIzpbGhHWCW5B9uTG8ag06S3/nQBjjwFBMqB+APtwg545es6kxdB1qTB95bSNOyCV/pUjM9Ym93h1CIfk9LRmeUHG0DyFp6Ao0jxFtgDMjiy/wE0QiagPhb7TJUC4u58tOhSKMaJJcIxnTrjFSulfFdMXYcwRaEU+T4NCjSvmCVf0a3jHbn0dLYx1kMERig8RXEUx711XggYM6qsqb4Gvy3IzrOq6lwXXDEjznirTPlBFkPPjUpMEUnY/VJEhG5uVHyCqVLU9zUrzvjMZihi1SWfwdTESTdtdGNB/qdyg== X-YMail-OSG: 5sng8IMVM1mghnOF8V0rCMdNwwnaQAIy1nci.iS34BnF1gJcZZsJgKkuuuZ25Mx i54gClXyv885DqkE0ZApiHOL42M9UG15Yit78rbKLaWBTyEFqaa5dwrRbFhX7qsVtIsxVDXTdYr. Nayk7eSfpAFeXjnYIEtM8XDjVPadUc8KXX7i0Npl5AaoHOHhQaRcmB3ZhO_rwh_opTUF6UZJND2b ACWC.VRbeovITufHZKbWuou4TPBsLsyHmhxo.G2Y0.GP3x.vSiPE7mwfw671ThZLShkpF7wkxmP7 RIPwUHk90T5lCBkKpo24VHjJe76uaDVL_DjuHNWJwr6ijCrbl9B3YGABacCROM7GSR5pv06SyVdm 66QXb49TtRjN0MkF1lsa_cGFdoAMdWi7MO8zMDYOXlEgLa8piSRKWMNF4LHsjvt5Lw8SniEg7pCx JyLMGpBQcUMRUcgDl8.oIbPECTdQLpYO1cQdnlILSw4F7_4JrSHGUzKrA6kh5cqaLbUCaDm33ydI tYN9up_llM9utJfr8rC6wC__gAT5E2ry_gQMi.nREarEVKhni26nZL26RkIhT4AIqpnU64oDlrbs zaMIKXNagU0rQ4JM8ZTRevBfjZwlRe999.nVdNnf.xd10CUIsrN71L9T2jLMiTeZeK_jn9MavenX vt4OS9rFzJ5RHSLaer9WfeIHtOsy63DedHi6trk_UiMUBgo.z3.Kr4_8Pr5KIRU6fIwscmi3adhc nTy3tmypw9Ahv7gTRTwvIqI3acBhEvO2_DYcvnMvaz9Whztq6tzOxoDUoLBgbOT8x2B4unaAG0xl krFaKIxUTY8gFHi8.QCflKSsUuNdi0PoXKn4Cu42DEdN1GQkAZSwXjK4WtsTKdsh1hIdIbI1YPTQ amFbnljdCMs4zP1MWcwTaiHrlltKog2DOuNiPQ1e39X42xuSrhxZIrkhH_C63I7vNx7GuvdAxtNc 0M353P_a4FF5yqFM9av0GFL8_ZDz.WlQl3x9Kjkdyr66ZuA_jgIHg6f1_xy3IjD._cvY3j_i7BOn R3ZZIVvEp4Iowks4pRzuyh4jKB1ZfMQYAZzx5IGqPbZ57sjDWLM9LnNXcgKPKdJsxhwhjIJbUbYv Ba1OlKieDXqsweMmimNGo42zFRUv5cPesmNygvzLjLfbXoYmphMAn5OK9o6ZgD3aVaCMnH3rOgOE mIvzffL0.GfvxJWXQzQcbLKgXosfbbvZzeAf48D17wHtuKUeXp7TOZpBwwTpqApkqbl7SSQOZqPG RVMnLf.saD9FDN_ag6_Ea0pYaheYL_C1G1hqcWBYT3fE7hYzgufnw4aunIsdwIfDLgNvhweP_6Zh iAVF3hFNkxS9p0oKorQthkaU3_5V0H7j8sYgJ3dU0SGSWfg.fRu2EEYJV0J18tMv5a7GBPlWnYZ1 Tq7T72OSmeI_b6dDQYh7t74zNH2hmPmy9iHYRFnQnnaGLnJqdY8J97Qf.q2pKtTDd8xQUt8LQ00y FKUDDyHCltPjBCbrC.c4wxzUFp56J7h6zskVEm7eSe74aUvcTop1bfaScPve93.rmh4iY5_Yz2a7 qOgc0nlm0YB2Q3mnZsA4egteynRhOZ4HZvuLk86AoZjtBUNjtL8Qz61Zevosa_oJzrH3ksudUXoA lR814KF.9f.Rm_EQdq.hpnJmk4idM1Rm_ulV3z7JWnrqvCizlIUIk7K3PTQ8VuXj8ccR.4rg9dqT q1ckXfh0W9CTb0h88BqCh9wf2I_GKDKRl_BxW7pRudDA3o99YKBZr9jTGVxIIpJT6Q2wjJAXWON0 8KUsliZgud6rV7WElOBe3sf0TBPpbGqgVz.yS_B9Zsw53J.6ZDnrgAJ18XhuKqRm8vJNF5PCs8v4 1P1kCUSimASvD513NT7l6qPRhOCQNqtAJMnG.9DBVbF.6pBYx47ttjx1FGWJFl4HhdcsSmOKeZnx CgFzxau7AmguEyuk4hdgzHWbKgPtT3wPW_y5nNAYbV5jYGe_fQGrXb2goqRWlSZ6Cmtzqi8IEjHI eyDfw.ZilJshO4GbX1JIHzqbe6MNsTRdz3sKeJnfoRCUmxidntjMLfViekaDXUeIy_HOwFE0NeaN r2nHokVgFIAXtFIXt3bUizsoLGv1CXrsI0bnwFsBXrVmpCtNBVeeNIJVD5GMYTadbSnTBiEeQ01X UkVa1qHijX8Iz2UoSGz_CUiP3brJckN03jLZ5OI4g2D.tgOqodCzLNprwC4uRsECwaXOgIEP.GUP D9.6EEtcXLPRDD2CGQ1ep5YBp2P9RpIZlxQR5NwZv86IL7a2GhjbSko5co_7p2nJ_kk3gWTmCwXa CvdTyLqniB6sFLu.rqXraXltAWZw.L8Y5UtUjPSHB.JZuUKedO8TD_jPwKMXmylKNv8lIfQUThn_ HHKdLANxKZTZ7Muc3l0SQDVqEQzyrcXakEL5vN_hfvI3s8h3HmaXlUjNjbwXMWFKnkMV3q4hrNd0 tMz.nBcLG_AdG1Ah7 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Tue, 13 Jul 2021 02:39:07 +0000 Received: by kubenode540.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID eb9e9214a775a83142732ff4e8fb8bc4; Tue, 13 Jul 2021 02:39:01 +0000 (UTC) User-Agent: Microsoft-MacOutlook/16.49.21050901 Date: Mon, 12 Jul 2021 22:38:59 -0400 From: Reshad Rahman To: Message-ID: <61DB5103-5E58-4CDE-9C30-3139AF9BC6E9@yahoo.com> Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-yang-module-versioning-03.txt References: <162611317546.20241.1098970468119145113@ietfa.amsl.com> In-Reply-To: <162611317546.20241.1098970468119145113@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Mailer: WebService/1.1.18469 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-yang-module-versioning-03.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 02:39:13 -0000 WG, Here is a summary of the changes which went in since last rev: 1) BC/NBC rules for non config data (https://github.com/netmod-wg/yang-ver-= dt/issues/15). We decided, based on WG feedback, that trying to (re)open BC/= NBC for non-config nodes was out of scope for this document. 2) Whitespace changes in a YANG module (https://github.com/netmod-wg/yang-v= er-dt/issues/8). See section 3.1. 3) BC/NBC impact of revision statements (https://github.com/netmod-wg/yang-= ver-dt/issues/12). See section 3.1.1. 4) Renamed extension nbc-changes to non-backwards-compatible 5) Clarify when we can add non-backwards-compatible extension (https://gith= ub.com/netmod-wg/yang-ver-dt/issues/83). See section 7. 6) Mention submodules (instead of just modules) where appropriate: https://= github.com/netmod-wg/yang-ver-dt/issues/95 7) Various editorial changes Regards, Reshad (on behalf of the authors/contributors). =EF=BB=BFOn 2021-07-12, 2:08 PM, "netmod-bounces@ietf.org on behalf of internet-d= rafts@ietf.org" wrote: A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the Network Modeling WG of the IETF. Title : Updated YANG Module Revision Handling Authors : Robert Wilton Reshad Rahman Balazs Lengyel Joe Clarke Jason Sterne Filename : draft-ietf-netmod-yang-module-versioning-03.txt Pages : 40 Date : 2021-07-12 Abstract: This document specifies a new YANG module update procedure that can document when non-backwards-compatible changes have occurred during the evolution of a YANG module. It extends the YANG import statemen= t with an earliest revision filter to better represent inter-module dependencies. It provides help and guidelines for managing the lifecycle of YANG modules and individual schema nodes. It provides = a mechanism, via the revision-label YANG extension, to specify a revision identifier for YANG modules and submodules. This document updates RFC 7950, RFC 8407 and RFC 8525. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioni= ng/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-ver= sioning-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-yang-module-version= ing-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Jul 13 08:07:45 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C96B3A15B6 for ; Tue, 13 Jul 2021 08:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hxim8tkMqUrJ for ; Tue, 13 Jul 2021 08:07:39 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2048.outbound.protection.outlook.com [40.107.21.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 AD5093A15B5 for ; Tue, 13 Jul 2021 08:07:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PJhnqWbB4vhNnWOkQ+OK8WQMZYNQb/RG3OjhJAZWGTfnHcBomy/w7ofX8qVvb+2Y1uBI/xgcKP7IVcqMXwTJLc+JlqSXehvwz8S/ych3CgJ+BH9eSp56Xfa1q9nndn+ny/wR2atqHxb8F3JIHCbLNMjUlnLCvi7HO0BWWeCai9u6g7fky/7uNVHDzdxWdZ8mUQ8tGuJXKswThaJFzz8rZYGuL9TVsSloRznBxE3mDzNyJHVC/eqyPqnh0Csw2crag+Lvykfxvy+MXtFn/qrtmicOxRUSgv9NsYUikwFCvAV+gapxS7Ygtgme+hgfyx1XPTR2efd2hjWIBkd4zdQjQw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BDMRRcS4R7eP6kQK4mKmvVnJewlxJy16dtyMXqgZi1g=; b=hIJfF/qNG/0LQFOcvXtmRyJxBexNDn5gUf9cDKaBHJ2xhx5WbRcdVW8D2JKrzl5Gqm9e7ZAS+325Oj8wH6r8oAO5+BedFCa9mOVMkxPdcsFyItqzOl5sWeg8L1lbrKV7Jm+2RZajzSZP0uRJoT1HwWTD2FoRiHTOdZBDx91CCzcROtR6ov+wGKlRXlsJxoLCPScdNHOw9v8fGdcf+cUCD/sb/8bd2A8LE3HNX8mqlQrlsE9Dkj+tU39ZovNF81DGIzsrXOdfPVG0UmvaLkZrcd3LBGwOt0ct50MUlr9dgwbc+UBckSIqrPZYPfD5WIFUWHCGlEF7GmAGY0ZSdgO6SQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BDMRRcS4R7eP6kQK4mKmvVnJewlxJy16dtyMXqgZi1g=; b=nzSdlYSjeDstda/d03lVhNSrUO9w3PBf2nBk9VAVlsXU2Uf4DIa2U++MWzHBD0EllNBbMBZbLkUwC65Zhbbyqf137k+HxkIkkNMipCs64IX13YSKDj/G3WSM0xMzBfGSUCFeAGM7ZBbT0BdbK+1VbRpyp1PLgGm+wUee18FHfMA= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8189.eurprd07.prod.outlook.com (2603:10a6:20b:320::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.9; Tue, 13 Jul 2021 15:07:35 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4331.021; Tue, 13 Jul 2021 15:07:35 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Andy Bierman , NetMod WG Thread-Topic: [netmod] yang-instance-file include-defaults leaf Thread-Index: AQHXdB0ScDY6rhEwiUCIGrL2qSijE6tA7UVg Date: Tue, 13 Jul 2021 15:07:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; yumaworks.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0e4bb91b-2ec3-44eb-0a42-08d9460ff27b x-ms-traffictypediagnostic: AM8PR07MB8189: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: E2D4955LwMMHgcRioLMV3Do7qUFehjFY27KtTwUODjifYBSG6n0LbTmReNCGbZxDMRTNG2/ZTu7KahoryRzT/nr9zy6NT7uE4TY8SH8CZEAFgcfVz9E5rRtswssSv0WuvtKIHPOIX2iQws1u1/YLGgp/QF8X9b5EViinMPaEruR/Fh2x4R5nit47iI1DOwft7HcRs0VJA1ctlQy16oCRogqMMGSHvVS2dIEuD05/mrxIwrJ1MBgFC4GjgmCtkGsMbbzRaBb/Y/ILiO52+Adjj8KXePqnk/qE5nPq2fv0zS3FptczD4XyzK6USgdQ/EkGQk8tvZ3dW2GT8v4IGMV2qTMlPZ00uOGXEWMSvJ4IX/o0h2KUQJZpGB5fE0fQPXygviiVX5ag5t/7kDuIXx9mTU6Tb2dxkZ43K4Oa7ploccqJjuj9kqrrJqnevVWOXw7W7simFc/PQOCmqM1AMHgMpdfj2X42wLzyMolk4ptNE1TRA51/Yv/bPPxt5PYBCaT8PdRVSs//VAq1Eewy1EXMYQPMVZ3RNJc+kVpvPj1MsxhTp3gKYwCilLFLgfuCAXZQbR2INpnx5mWyM+pZnAMbTYYr9IDtbtwWJHRHH9kSTwNMoD/UrFyX3AZeks7Pb6FLr5hHJDmfZZ8mjXcBlDLv/065K8J3ugsLjWpyGy1Jmyw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(39860400002)(136003)(396003)(366004)(186003)(55016002)(26005)(6506007)(9326002)(110136005)(9686003)(8936002)(66446008)(316002)(85202003)(64756008)(66476007)(85182001)(66946007)(86362001)(66556008)(66616009)(53546011)(76116006)(7696005)(99936003)(122000001)(2906002)(33656002)(8676002)(38100700002)(71200400001)(5660300002)(52536014)(478600001)(66574015); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: RqRvZIQmYQ+0Nh2vttBLNdaDlxaA6e2HGiSpJc24MYnbJyIhxzpzoeQdFeG9eyabgwAHpfOpwf39inR71gMaFjD3LfLkoSIntYrIr1BT6I5nbOoOm6Q0B0bEzddLqHcLj7c4t61NNz/w42QO1C0Iq40ySzad0FFmjcQp/eYx5cGHwA01/dzMTdMdX3VSofKTYRX6msHjnm2txVcSacg+QUdkn/355CpdPQBaBynKYAzOdC20GnRU/kW8sSnKQfekfHDWPnZtaCrJ9yNf2yAjJIZH23wzMnepS7g7R6QI+tFTRy7WomDUHpyeQoZEgKWrbs/+tAgEf+iQwF5gP+1x7si0XhdIOiCY71q5W4cqIeCow7/Z9tCmvMDsClEiQQ9PGBwR9bX6+ufZthUFXTqr3bu5TUlM1Cw6CHQsLAjsKO0Dl6HxQfzv5gm5B/eKW/u4XzoqkfIIBRAuhNUFTcQTJBeMvhTjNDqLLR3vkW6AOd9LmCzHToM7dOaH2roNWcpSxlgTCsl+MZGrweSFiaYG0wBVdvpzQy3a/3BDjVdN4//Y5LnN6DFYhvd6tJRCf64x6MCbewU/IA1hs0D28k4h4x9FpD5fNTO9rWAsuPRp5nZNIRYxWuVEe0k8PU+vHH8KM6RfTOcIIAmgXElqFGL00OegM36L8/L7JoZaC9KLYoaYSjl98s1O9oc1O/ch5jJYXaMt0ng+WcqTGV3OgvbHBOCB3IS06eke5NfqDmTSEQc= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0066_01D77809.91DDCCF0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0e4bb91b-2ec3-44eb-0a42-08d9460ff27b X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2021 15:07:35.5164 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LOKSFOpalzu3mMQZ/ywlKdGDoS+iae/43son62C3aIKrxZzlA65SnvxBoQc8F3B2LnaapU/6KHvTFiHQ76PzqWHVzOKI7vsZ3wVAOwCDfnM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8189 Archived-At: Subject: Re: [netmod] yang-instance-file include-defaults leaf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 15:07:44 -0000 ------=_NextPart_000_0066_01D77809.91DDCCF0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0067_01D77809.91DDCCF0" ------=_NextPart_001_0067_01D77809.91DDCCF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Andy, Looking through the use-cases I think the producer will always know = whether it includes default values or not. This is the case if the = instance data set is produced by the server e.g. in UC4, UC5, or if it = created by some design activity UC1, UC2, UC3, UC8. (UC6 and UC7 are so = broad and loosely defined it is hard to say much about them.) =20 Once the producer knows whether defaults are included or not it can set = the include-defaults accordingly, so the default value for = include-defaults is not so important. However, I chose trim as the = default because: * during the WGLC the draft explicitly stated that defaults SHOULD NOT = be included and the WG was happy/ok with that * IMHO It is better to have short files,=20 =20 Note, I used the term producer, as IMHO the above is true in all cases = whether the server produces the file or some design activity creates the = server. Regards Balazs =20 From: netmod On Behalf Of Andy Bierman Sent: 2021. j=C3=BAlius 8., cs=C3=BCt=C3=B6rt=C3=B6k 19:16 To: NetMod WG Subject: [netmod] yang-instance-file include-defaults leaf =20 Hi, =20 The module has this object: =20 leaf includes-defaults { type enumeration { enum report-all { value 1; description "All data nodes SHOULD be included independent of any default values."; } enum trim { value 2; description "Data nodes that have a default defined and where the actual value is the default value SHOULD NOT be included."; } enum explicit { value 3; description "Data nodes that have a default defined and where the actual value is the default value SHOULD NOT be included. However, if the actual value was set by a NETCONF client or other management application by the way of an explicit management operation the data node SHOULD be included."; } } default trim; =20 The draft is extremely server-centric, like most IETF standards, but = this leaf is too server-centric to ignore. =20 Consider the possibility that the source of the file is NOT a NETCONF = server. This data may not be known so the default of "trim" may not be correct. =20 IMO this leaf is noise because any tool that knows the schema will also know the YANG defaults. The solution is incomplete anyway because the presence of a leaf that has a YANG default is not enough. The "report-all-tagged" mode must be used to identify defaults. IMO this leaf should be removed, but at least add an enum called = "unknown". =20 =20 Andy =20 =20 ------=_NextPart_001_0067_01D77809.91DDCCF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello Andy,

Looking through the use-cases I think the producer = will always know whether it includes default values or not. This is the = case if the instance data set is produced by the server e.g. in UC4, = UC5,=C2=A0 or if it created by some design activity UC1, UC2, UC3, UC8. = (UC6 and UC7 are so broad and loosely defined it is hard to say much = about them.)

 

Once the producer knows whether defaults are included = or not it can set the include-defaults accordingly, so the default value = for include-defaults is not so important. However, I chose trim as the = default because:

  • during the WGLC the = draft explicitly stated that defaults SHOULD NOT be included and the WG = was happy/ok with that
  • IMHO It is better to = have short files,

 

Note, I used = the term producer, as IMHO the above is true in all cases = whether the server produces the file or some design activity creates the = server.

Regards = Balazs

 

From: netmod = <netmod-bounces@ietf.org> On Behalf Of Andy = Bierman
Sent: 2021. j=C3=BAlius 8., cs=C3=BCt=C3=B6rt=C3=B6k = 19:16
To: NetMod WG <netmod@ietf.org>
Subject: = [netmod] yang-instance-file include-defaults leaf

 

Hi,

 

The module has this = object:

 

=C2=A0=C2=A0=C2=A0 leaf includes-defaults =
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type =
enumeration {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
enum report-all {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 value 1;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 description
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 "All data nodes SHOULD be included =
independent of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 any default =
values.";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
}
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
enum trim {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 value 2;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 description
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 "Data nodes that have a default defined and =
where
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the actual value is the default value =
SHOULD
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NOT be =
included.";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
}
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
enum explicit {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 value 3;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 description
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 "Data nodes that have a default defined and =
where
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the actual value is the default value =
SHOULD NOT be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 included. However, if the actual value =
was set by
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a NETCONF client or other management =
application
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 by the way of an explicit management =
operation the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 data node SHOULD be =
included.";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
}
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
}
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 default =
trim;
 

The draft is extremely server-centric, like most IETF = standards, but this

leaf = is too server-centric to ignore.

 

Consider the possibility that the source of the file = is NOT a NETCONF server.

This data may not be known so the default of = "trim" may not be correct.

 

IMO this leaf is noise because any tool that knows the = schema will also

know the = YANG defaults.  The solution is incomplete anyway = because

the presence of a = leaf that has a YANG default is not enough.

The  "report-all-tagged" mode must be = used to identify defaults.

IMO this leaf should be removed, but at least add an = enum called "unknown".

 

 

Andy

 

 

------=_NextPart_001_0067_01D77809.91DDCCF0-- ------=_NextPart_000_0066_01D77809.91DDCCF0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDcxMzE1MDczMlowIwYJKoZIhvcNAQkEMRYEFAY7H5/YBuOV V88pKnYJsfZ7LXFXMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAD7P 1ziCXLNWBqwcfsXKUHiwP20feoRW3uOn2fLkr0AtNxsOD9xD+Al3rpYRqFE2NfcWyZfe9tgpyyES tBU0CLBmYmTNEbM1Q18Sp2UI0bA3oYj+BbCQhJAB9IS/1oUJaeKtRGG9H1WKLJb/IBhBjkBWyE0t inSfG9NrisHgNAsV34LnTPHKSE9pC1khr9MC4RIn0nTuvtJeTUp/CkBWho32uetyLGFVA1huH08Y xSyxflGjTJAe/8NNcb2cdoIo8GzftaEtWdsKvrNlHfWtkJxi5dArI0rJqg8WB0AvbAsjBBlrWhVZ EJIbpUUdJg9R5LKxzUgyc/KTctdgDbw2oWYAAAAAAAA= ------=_NextPart_000_0066_01D77809.91DDCCF0-- From nobody Tue Jul 13 08:31:56 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309413A17D8 for ; Tue, 13 Jul 2021 08:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 Usnqnqzvd6zs for ; Tue, 13 Jul 2021 08:31:49 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DCC23A17DE for ; Tue, 13 Jul 2021 08:31:48 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id v6so13800776lfp.6 for ; Tue, 13 Jul 2021 08:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oRFw+zr6wg/0xrM8ZetDHm6EZ4E9OgUaLIh3YOn8LTs=; b=zepwGrtk2CEQKkTuCCVuboSSQ/YB7Ci8MWWxmcWHmYEwI/1JNFs41AhEotWQ0D/NWg fQ7T3Oqkrm6HvLYuBZZlLA5rZH+cO9narxnYXGKwFvUA/OnxnGC5MGGgWBs7dmZBHj+D tz/8CAFI2z2rfRsLB8YAcCvtyo3Spor4CE8mfknI8jd9HPBQkcJ7Er7wMv03hFuRXadN rJRWeWqs84Ibs7U6OAB2aQfqFmS11Faq3KlAanWruXAQdE745FoPrKgXlWfg069XqmsC xbKcqNHrCMSDfXsOZJLpW1arXtUqYRBjHIqhRos0UDqaDHbHU+8R1Vs0z5WaU5uVecpO DZuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oRFw+zr6wg/0xrM8ZetDHm6EZ4E9OgUaLIh3YOn8LTs=; b=P3gytNiQif8KNF+PY47eoroiixl1TqkOWEQUimArL47rVj0Sf5wlo27wUiNkNHGPq+ wXnhs5A9NqZjV1TLHKlGkZzRyVJo/o/Z9mx/9Wf5PuQywTMAMv7HdbgWUP3K5QfiPo0S ObIms6SsGKIj12qb/ET3yIHC4ReLLgFUrjYoOKBoeN1RHrDbtHy0dYplGV2zpzpHqDUP u7nLFprUGffWwrthVuUBT9WBJy/WuHqSnOO4k1idZohyg3/VoWpiTpCnm7yjHTLygSNh bFJ2/+2f/Q5HMPQH69mL3NqBECGFt8j7fwlfo9d7a4/lk+NNbHYjG2ZhgpfrNx3fPIXP lfgA== X-Gm-Message-State: AOAM5307ulRMTjkxnfARhqTDK+Ok8JWHqwrgEU+gOqIerTkwGSVkzTaj 4xJBcs1GZyPal//gHGrmyNh0Vq0zYkcZ90kXH5836Q== X-Google-Smtp-Source: ABdhPJxQLcBKQqXylz+MoqK0R7lCvOvcAevabV7eBDgDM9c7kWmTBpeMZZko0w7zJ92g67xUSD2O/jLNHPbkhaejW9I= X-Received: by 2002:a05:6512:3c93:: with SMTP id h19mr3853570lfv.512.1626190306149; Tue, 13 Jul 2021 08:31:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Tue, 13 Jul 2021 08:31:35 -0700 Message-ID: To: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= Cc: NetMod WG Content-Type: multipart/alternative; boundary="000000000000891ed905c702efb9" Archived-At: Subject: Re: [netmod] yang-instance-file include-defaults leaf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 15:31:55 -0000 --000000000000891ed905c702efb9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 13, 2021 at 8:07 AM Bal=C3=A1zs Lengyel wrote: > Hello Andy, > > Looking through the use-cases I think the producer will always know > whether it includes default values or not. This is the case if the instan= ce > data set is produced by the server e.g. in UC4, UC5, or if it created by > some design activity UC1, UC2, UC3, UC8. (UC6 and UC7 are so broad and > loosely defined it is hard to say much about them.) > > > > Once the producer knows whether defaults are included or not it can set > the include-defaults accordingly, so the default value for include-defaul= ts > is not so important. However, I chose trim as the default because: > > - during the WGLC the draft explicitly stated that defaults SHOULD NOT > be included and the WG was happy/ok with that > - IMHO It is better to have short files, > > > I strongly object to having a default-stmt since it does matter and the usage is incorrect. If the include-defaults is not set then conveying a default value of 'trim' is incorrect. Leaving it out of a representation does not change the semantics of the model. The consumer will add that leaf =3D "trim" if it is missing. Andy Note, I used the term *producer*, as IMHO the above is true in all cases > whether the server produces the file or some design activity creates the > server. > > Regards Balazs > > > > *From:* netmod *On Behalf Of *Andy Bierman > *Sent:* 2021. j=C3=BAlius 8., cs=C3=BCt=C3=B6rt=C3=B6k 19:16 > *To:* NetMod WG > *Subject:* [netmod] yang-instance-file include-defaults leaf > > > > Hi, > > > > The module has this object: > > > > leaf includes-defaults { > > type enumeration { > > enum report-all { > > value 1; > > description > > "All data nodes SHOULD be included independent of > > any default values."; > > } > > enum trim { > > value 2; > > description > > "Data nodes that have a default defined and where > > the actual value is the default value SHOULD > > NOT be included."; > > } > > enum explicit { > > value 3; > > description > > "Data nodes that have a default defined and where > > the actual value is the default value SHOULD NOT be > > included. However, if the actual value was set by > > a NETCONF client or other management application > > by the way of an explicit management operation the > > data node SHOULD be included."; > > } > > } > > default trim; > > > > The draft is extremely server-centric, like most IETF standards, but this > > leaf is too server-centric to ignore. > > > > Consider the possibility that the source of the file is NOT a NETCONF > server. > > This data may not be known so the default of "trim" may not be correct. > > > > IMO this leaf is noise because any tool that knows the schema will also > > know the YANG defaults. The solution is incomplete anyway because > > the presence of a leaf that has a YANG default is not enough. > > The "report-all-tagged" mode must be used to identify defaults. > > IMO this leaf should be removed, but at least add an enum called "unknown= ". > > > > > > Andy > > > > > --000000000000891ed905c702efb9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 13, 2021 at 8:07 AM Bal= =C3=A1zs Lengyel <balazs.= lengyel@ericsson.com> wrote:

Hello Andy,

Looking through t= he use-cases I think the producer will always know whether it includes defa= ult values or not. This is the case if the instance data set is produced by= the server e.g. in UC4, UC5,=C2=A0 or if it created by some design activit= y UC1, UC2, UC3, UC8. (UC6 and UC7 are so broad and loosely defined it is h= ard to say much about them.)

=C2=A0

Once the producer knows whether de= faults are included or not it can set the include-defaults accordingly, so = the default value for include-defaults is not so important. However, I chos= e trim as the default because:

  • during the WGLC the draft explicitly stated that = defaults SHOULD NOT be included and the WG was happy/ok with that=
  • IMHO It is better to have short files, =

=C2=A0

=



I strongly object to havi= ng a default-stmt since it does matter and the=C2=A0usage is incorrect.
If the include-defaults is not set then conveying a default value of= 'trim' is incorrect.
Leaving it out of a representation = does not change the semantics of the model.
The consumer will add= that leaf =3D "trim" if it is missing.

= Andy

=

Note, I used the term producer, as IMHO t= he above is true in all cases whether the server produces the file or some = design activity creates the server.

Regards Balazs

=C2=A0

From: netmod <netmod-bounces@ietf.org> On Behalf Of Andy Bie= rman
Sent: 2021. j=C3=BAlius 8., cs=C3=BCt=C3=B6rt=C3=B6k 19:16To: NetMod WG <netmod@ietf.org>
Subject: [netmod] yang-instance-file= include-defaults leaf

=C2=A0

Hi,

=C2=A0

The module has this object:

=C2=A0

=C2=A0=C2=A0=C2=A0 leaf includes-defaults {<=
u>
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 type enumeration {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 e=
num report-all {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value 1;
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "All data nodes SHOULD be include=
d independent of
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 any default values.";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }<=
u>
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enum trim {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 value 2;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 descr=
iption
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Data =
nodes that have a default defined and where
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the actual value is the default val=
ue SHOULD
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 NOT be included.";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 enum explicit {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 value 3;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description=

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Data nodes =
that have a default defined and where
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the actual value is the default value SHO=
ULD NOT be
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 included. However, if the actual value was set by
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a NETCONF client or oth=
er management application
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 by the way of an explicit management operation the=

=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 data nod=
e SHOULD be included.";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 }
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 default trim;
<= pre style=3D"white-space:pre-wrap">=C2= =A0

The draft is extremely server= -centric, like most IETF standards, but this

leaf is too server-centric to ignore.

=C2=A0

Consider the possibility that the source of the file is N= OT a NETCONF server.

Thi= s data may not be known so the default of "trim" may not be corre= ct.

=C2=A0=

IMO this leaf is noise because any to= ol that knows the schema will also

know the YANG defaults.=C2=A0 The solution is incomplete anyway = because

the presence of = a leaf that has a YANG default is not enough.

<= p class=3D"MsoNormal">The=C2=A0 "report-all-tagged" mode must be = used to identify defaults.

IMO this leaf should be removed, but at least add an enum called "u= nknown".

=C2= =A0

=C2=A0

Andy

=C2=A0

=C2=A0

--000000000000891ed905c702efb9-- From nobody Tue Jul 13 09:47:52 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BC73A0A04; Tue, 13 Jul 2021 09:47:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matt Joras via Datatracker To: Cc: draft-ietf-netmod-nmda-diff.all@ietf.org, last-call@ietf.org, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162619487072.21095.13102788339863024663@ietfa.amsl.com> Reply-To: Matt Joras Date: Tue, 13 Jul 2021 09:47:50 -0700 Archived-At: Subject: [netmod] Genart last call review of draft-ietf-netmod-nmda-diff-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 16:47:51 -0000 Reviewer: Matt Joras Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-netmod-nmda-diff-?? Reviewer: Matt Joras Review Date: 2021-07-13 IETF LC End Date: 2021-07-02 IESG Telechat date: 2021-07-15 Nits/editorial comments: Consider rewording this sentence in performance considerations: "One possibility for an implementation to mitigate against such a possibility is to limit the number of requests that is served to a client, or to any number of clients, in any one time interval, rejecting requests made at a higher frequency than the implementation can reasonably sustain." It is excessively wordy and uses the word "possibility" twice. I would suggest breaking this into two separate sentences. From nobody Wed Jul 14 04:27:04 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8134D3A0C5D; Wed, 14 Jul 2021 04:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXz5996kdFmP; Wed, 14 Jul 2021 04:26:48 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 4FD813A0C5C; Wed, 14 Jul 2021 04:26:48 -0700 (PDT) Received: from smtpclient.apple (unknown [85.131.57.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 092E660034E; Wed, 14 Jul 2021 14:26:21 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1626261982; bh=ojBBsv+Hf3MVmxcs0C4xsYI5o7A1tP6Nd4ITVbI9l3s=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=NhXiRZQX3x49Cved8R0LqmXwh2YecfV01wV/Q0ooP74rHU5reKQAyIB0kc9eykLEq aqzyXCZD+yE7sdlFObavP1SBvDYVqBFO5TX2wpgq+r19eWWuopxzHkBQNRPI+1qkZz RpZdV3PJ0BW7RwyZqrZPFwoObO+oXS9t7xpOdYxk= From: Lars Eggert Message-Id: <35868D5F-34CC-4144-A68A-232FB138AE7B@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_3FE6DA93-8530-4910-8F5F-B2032213F633"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Wed, 14 Jul 2021 14:26:21 +0300 In-Reply-To: <162619487072.21095.13102788339863024663@ietfa.amsl.com> Cc: General Area Review Team , last-call@ietf.org, netmod@ietf.org, draft-ietf-netmod-nmda-diff.all@ietf.org To: Matt Joras References: <162619487072.21095.13102788339863024663@ietfa.amsl.com> X-MailScanner-ID: 092E660034E.A2EEB X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [netmod] [Gen-art] Genart last call review of draft-ietf-netmod-nmda-diff-10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 11:26:54 -0000 --Apple-Mail=_3FE6DA93-8530-4910-8F5F-B2032213F633 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Matt, thank you for your review. I have entered a No Objection ballot = for this document. Lars > On 2021-7-13, at 19:47, Matt Joras via Datatracker = wrote: >=20 > Reviewer: Matt Joras > Review result: Ready with Nits >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-netmod-nmda-diff-?? > Reviewer: Matt Joras > Review Date: 2021-07-13 > IETF LC End Date: 2021-07-02 > IESG Telechat date: 2021-07-15 >=20 > Nits/editorial comments: >=20 > Consider rewording this sentence in performance considerations: >=20 > "One possibility for an implementation to mitigate against such a = possibility > is to limit the number of requests that is served to a client, or to = any number > of clients, in any one time interval, rejecting requests made at a = higher > frequency than the implementation can reasonably sustain." >=20 > It is excessively wordy and uses the word "possibility" twice. I would = suggest > breaking this into two separate sentences. >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_3FE6DA93-8530-4910-8F5F-B2032213F633 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmDuyd0ACgkQVLXDCb9w wVcT0g//Qjw4ScYP6U7pbjkbYTPnw0lLW/1aNobJhWsAMXm8CBQb1sdxq121HAnQ 02HHNi9PIsxgf+fYFNMEJq8hASSxizSWWpnODFmOx1SSDl2K4MlkmphTtwzyvtOx u+r6fHLLW1JFGMzofEx+GGKVQiI23oAxxBnOxz6fSXlw45pG0TGA/fKqbG/YBcTJ QTRzjtZxsB1pGMVL+I+ltCKU82PnnATcCymSEz1W4a7KRdtwuwgEk7YGNU92wuhA U4aqT6plZPBjRf7N5Xop9X0KJrSXBVoTgvEhFiqAtJNZSocYFnlRt5/pyBJina3Q M4xnmBj9ISJIjmsqorPuQIHdFeARO8aw376ikdkcIHg6FP4LNPNSLPEytw5KwcbI 4AO7aMcNwhnjR7dH+abu1NqTxHxck0vLE5HemL1ouC+nZsEU89tWr0oGYcoU6yJB ULZhZbEvrzs8zRtpWXLvegnBQ5fPHi9vI4lbe7Hej/RZ/BEcKKRGrrPIQsleH0ws NI1JTD//wIvLqCsEXbEkf6SQD9YwttpdBM74YzL6wI3gTamBkK5tC2S1C4ZvVsjb nCJMK+jvXYDyjsf7p/Uv7IlvvZMOH7TDPLbGEytSgtmHA9XTY5uQchoD+sTB8Dn/ inrGHEZorZDzjks6GBOLSRPHX8D00uv02rhyP3gmUMvl1S92Ihs= =i8sd -----END PGP SIGNATURE----- --Apple-Mail=_3FE6DA93-8530-4910-8F5F-B2032213F633-- From nobody Wed Jul 14 09:35:18 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5F73A239D; Wed, 14 Jul 2021 09:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 3Z4I0FanJ472; Wed, 14 Jul 2021 09:35:12 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145E83A239C; Wed, 14 Jul 2021 09:35:11 -0700 (PDT) Received: from jmbp.local ([IPv6:2601:1c0:cb00:5dd1:31a6:d451:e713:681f]) (authenticated bits=0) by nagasaki.bogus.com (8.16.1/8.16.1) with ESMTPSA id 16EGZAwK050669; Wed, 14 Jul 2021 16:35:10 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:1c0:cb00:5dd1:31a6:d451:e713:681f] claimed to be jmbp.local To: "netmod@ietf.org" , "netmod-chairs@ietf.org" From: Joel Jaeggli Message-ID: Date: Wed, 14 Jul 2021 09:35:02 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [netmod] Draft Agenda Posted for IETF 111 - Tuesday, July 27, 2021, Session II (21:30-22:30 UTC, 14:30-15:30 PDT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 16:35:17 -0000 The draft Agenda was posted, Based on currently extant slot requests it is relatively short. Please take a look at whether changes are required. Presenters please remember that Slides would be greatly appreciated not less than 24 hours prior to Tuesday july 27th 21:30 for inclusion in the meeting materials. Thanks Netmod Chairs. ------------------------------------------------------- Agenda for the NETMOD 111 WG Session ------------------------------------------------------- https://datatracker.ietf.org/meeting/111/materials/agenda-111-netmod Session:    Tuesday, July 27, 2021    Session II (21:30-22:30 UTC, 14:30-15:30 PDT) WG Chairs:    Lou Berger    (lberger at labs dot net)    Kent Watsen (kent plus ietf at watsen dot net)    Joel Jaeggli    (joelja at bogus dot com) Available During Session:    WG ICS: https://datatracker.ietf.org/meeting/111/sessions/netmod.ics    ICS: https://datatracker.ietf.org/meeting/111/session/28884.ics    MeetEcho: https://meetings.conf.meetecho.com/ietf111/?group=netmod    Jabber:          xmpp:netmod@jabber.ietf.org?join Available During / After Session:    CodiMD:        https://codimd.ietf.org/notes-ietf-111-netmod    Slides: https://datatracker.ietf.org/meeting/111/session/netmod    Drafts (TGZ): https://datatracker.ietf.org/meeting/111/agenda/netmod-drafts.tgz    Drafts (PDF): https://datatracker.ietf.org/meeting/111/agenda/netmod-drafts.pdf Available After Session:    Recording:     http://www.meetecho.com/ietf111/recordings#NETMOD    Jabber Logs:   https://www.ietf.org/jabber/logs/netmod Introduction    Chairs (10 minutes)    Session Intro & WG Status Chartered items:    YANG Versioning Update (30 min) https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/    https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/    https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-packages/ https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-ver-selection/ https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-schema-comparison/    Overview - Jason Sterne    YANG Module Versioning Draft - Jason Sterne    YANG Semver Draft - Joe Clarke Remaining 20 min. From nobody Wed Jul 14 14:55:59 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 288E83A1038; Wed, 14 Jul 2021 14:55:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-netmod-nmda-diff@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, Joel Jaeggli X-Test-IDTracker: no X-IETF-IDTracker: 7.34.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <162629975266.30955.5971703739690529871@ietfa.amsl.com> Date: Wed, 14 Jul 2021 14:55:53 -0700 Archived-At: Subject: [netmod] Murray Kucherawy's No Objection on draft-ietf-netmod-nmda-diff-10: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 21:55:53 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-netmod-nmda-diff-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 7: "... number of requests that is served to a client ..." -- s/is/are/ Also, it strikes me that some of what's in Section 7 is repeated in the last paragraph of Section 9. I wonder if they could perhaps be merged, or 9 could reference 7, or something. From nobody Wed Jul 14 19:13:46 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C4F3A161E for ; Wed, 14 Jul 2021 19:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5d1ryliiHDf for ; Wed, 14 Jul 2021 19:13:39 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660F43A161D for ; Wed, 14 Jul 2021 19:13:38 -0700 (PDT) Received: from fraeml714-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GQHgh00T0z6L8Jh for ; Thu, 15 Jul 2021 10:02:23 +0800 (CST) Received: from dggeme720-chm.china.huawei.com (10.1.199.116) by fraeml714-chm.china.huawei.com (10.206.15.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2176.2; Thu, 15 Jul 2021 04:13:34 +0200 Received: from dggeme770-chm.china.huawei.com (10.3.19.116) by dggeme720-chm.china.huawei.com (10.1.199.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Thu, 15 Jul 2021 10:13:32 +0800 Received: from dggeme770-chm.china.huawei.com ([10.8.68.58]) by dggeme770-chm.china.huawei.com ([10.8.68.58]) with mapi id 15.01.2176.012; Thu, 15 Jul 2021 10:13:32 +0800 From: "maqiufang (A)" To: Kent Watsen CC: "netmod@ietf.org" Thread-Topic: [netmod] system configuration sync mechanism Thread-Index: Add4ieaMV4M1zhk1St6ROfyHhlohlAAAAuNA Date: Thu, 15 Jul 2021 02:13:32 +0000 Message-ID: <2d1262bc90fc49d08eb641365b959ea4@huawei.com> References: <5b76dae2175545959f0006b036efd647@huawei.com> In-Reply-To: <5b76dae2175545959f0006b036efd647@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.123.93] Content-Type: multipart/alternative; boundary="_000_2d1262bc90fc49d08eb641365b959ea4huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] system configuration sync mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 02:13:45 -0000 --_000_2d1262bc90fc49d08eb641365b959ea4huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi , Kent: Apologies for the delay. I missed your reply and never saw it in my inbox(b= ugs?) :(. Thanks for the detailed examples and explanation, and now I have a better = understanding about your proposal. Please see my reply inline. [likewise snip...] For the second category, imagine containing some predefined object= s. These objects follow the standard data-model allowed by the YANG. Oper= ators could have defined these objects as well but, because there may be hu= ndreds of these objects, and the objects are the same for everyone, the ven= dor decides to pre-define them as a convenience for their customers. This = way, operators only have to define custom objects for what is unique in the= ir environments. By example, imagine this in : system-defined-defaults { applications { application ftp { protocol tcp; destination-port 21; } application tftp { protocol udp; destination-port 69; } application smtp { protocol tcp; destination-port 25; } ... } } And this in # custom objects applications { application my-app-1 { protocol tcp; destination-port 2345; } application my-app-2 { protocol udp; destination-port 69; } } // an ACL policy referencing both sys-defined and custom o= bjects policy from-zone untrust to-zone untrust { policy allow-external-access-to-foobar-app { match { source-address any; destination-address any; application [ ftp tftp, my-app-= 1, my-app-2 ]; } then { permit; } } } [Qiufang Ma] I can understand that the vendors would like to predefine some= common objects for their users' convenience so that the users only have to= define their own objects for what is unique in their environments. What I don't really understand is why these configurations are not applied = immediately but only after they are referenced? Note that, by itself would not pass validation, due to missing le= afrefs. Thankfully, NMDA never says that validation runs on . Bu= t once and have been merged, to become , the r= esult does pass validation. [Qiufang Ma] The referenced instance must also exist for the data to be va= lid since the require-instance defaults to true if not present. Is this wha= t you had in your mind? Yes, NMDA says that it is which is subje= ct to validation. But I also notice that In section 5.1.3 of the NMDA:" MUST always be a valid configuration data tree, as defined in Sectio= n 8.1 of [RFC7950]. " So my thought here is that should also conf= orm to the YANG model constraints and that's to say, a referenced system-de= fined data item should also exists in . Therefore, if system configurations do not exist in , they still n= eed to be configured in manually in order for being referenced. = In this case, the original purpose of predefining some system configuration= s for user convenience is lost. This is the reason why we would like to def= ine some mechanism here to synchronize into . > I am wondering if these configuration will present in the (= which contains all the configuration actually used by the device) before th= ey're referenced. I think that it would depend in the specific server's behavior, regarding i= f *unused* predefine objects are present in . Certainly the u= nused objects would not have to be present in . If I were imp= lementing the server, the unused objects would NOT be present in . [Qiufang Ma] Yes, if the predefined system configurations is unused, then I= also tend to agree that they would not be present in but may= also depend on the vendor implementation. > It would be good if we could determine if there are any other "resource-i= ndependent" configuration categories here. > [Qiufang Ma] Do you think there exists conditional system configuration (= if the preceding configurations you mentioned above is not)? For example, i= f SSH is enabled on a device, SSH-related keys are automatically generated.= Such configurations are generated at the moment when a special functionali= ty is enabled. I'm unsure what you mean in general by "conditional configuration", but I c= an speak to your specific example. Though I must preface my comments that I= imagine there are a number of ways servers might go about enabling `sshd`.= What follows is my personal view, forged by being around systems for awhi= le ;) In general: - `sshd` is NOT enabled by default. - `sshd` is enabled via a configuration knob. - the SSH host key is dynamically generated the first time `sshd` = is enabled. - the SSH host key itself is in (not ) This view is consistent with the first paragraph in Section 3 of the "keyst= ore" draft (reproduced below): 3. Support for Built-in Keys In some implementations, a server may support built-in keys. B= uilt- in keys MAY be set during the manufacturing process or be dynam= ically generated the first time the server is booted or a particular s= ervice (e.g., SSH) is enabled. As a closing thought, this model (which I stated upfront may not be univers= al) would have no presence-in or interaction-with ...though, perhap= s, there may be some predefined values for what key-algorithms and/or key-l= engths to use when generating the SSH host key... [Qiufang Ma] By "conditional system configuration", I was meaning some of t= he system configurations are not generated immediately after the device is = powered on. Instead, they are generated when a specific condition is satisf= ied during the device running(e.g., a functionality is enabled due to some = client configurations). I am not sure if it really exists, maybe not, just = try to explore the possibilities of various resource-independent system con= figurations.:) Firstly, I again have to preface my comment that there are likely many ways= that templating mechanisms can be defined. But, in general, once a temp= lating mechanism has been defined, then it stands to reason that templates = could be defined either in (by operators) or in (by the = manufacturer). In one implementation I'm familiar with, the templates are = objects that are referenced/parameterized by other parts of the configurati= on. (Same as with the predefined objects discussion above.) To answer your questions: 1) Yes, it is my opinion that *activated* templates in will be exp= anded and present in . 2) I would never suggest that the system-defined templates are present in <= running>, though they may be referenced/parameterized by config in . 3) if a config-template is configured in (i.e., it is operator-de= fined) then, yes, the expanded configuration in is "client confi= guration" (note, "client configuration" is not a formal term). That said, = it seems fair to say that a template defined in and then reference= d by "client configuration" in is also expanded as "client config= uration" in . 4) I don't not understand your last sentence, that the expansion of templates are only present in . Maybe you're saying somethi= ng subtle, e.g., that servers currently don't support GET on . B= ut, in theory, the expansion of templates should (IMO) be present = in , so that they may be subject to validation. Of course, all = the configuration (whether originating in or )= that is successfully "applied" will also be present in . [Qiufang Ma] Assume that there is no and this work, the expansion = of system templates are only present in . Because this is comp= atible with system configuration definition in NMDA. But if system configurations are only present in , the predefi= ned system configurations still need to be retrieved and created into explicitly when being referenced. I think we've reached an agreement o= n the need for to exist, and our main point of disagreement is whe= ther should be copied into . Your point is that being mer= ged into is enough to make sure a success validation. But my und= erstanding is that the referenced system configuration data item must also = exist in the to obey the model constraints. > I'm beginning to think that: > * auto-copying into is likely never a good idea, becaus= e it violates the definition of > [Qiufang Ma] I am quite aware that different datastores in NMDA represent= s different views of data nodes. And represents a configuration = datastore holding the current configuration of the device. > Should we consider system configuration also be part of current configura= tion of the device? From my perspective, the difference between system conf= iguration and client-configuration lies only in who provides it. holds the current *operator-specified* configuration of the devic= e. System-provided configuration is NOT specified by operators (though sys= tem-defined objects may be referenced by operator-specified config in ). I believe that this arrangement is consistent with the definition = of . Agreed? [Qiufang Ma] Yes. Actually we are not trying to violate the principles of N= MDA and the definition of . The issue we try to resolve here is t= hat system configurations cannot be used(referenced or overwritten) by the = operators directly and need to be created into explicitly. This a= ctually loses the meaning of "predefining and bringing convenience". If aut= o-copying is not a good idea, what do you think about defining an RPC opera= tion for the operators to do the copy(which is also what Rob suggests at th= e meeting)? > * having in doesn't make sense, since the tweaks wo= uldn't go thru --> validation. > > I'm wondering if a model like below would work for everyone - thoughts? > [Qiufang Ma] represents the configuration after all configurat= ion transformations to have been performed, so I think it is only= coupled to . > Anyway, the should also interacts with . Agreed? I don't agree that must only be coupled to . Specifica= lly, I think that it is okay (compatible with NMDA) to define a th= at also impacts . This is the only (IMO) sane approach, as it e= nables the combination + to be validated. [Qiufang Ma] Please see above. If is OK to miss referenced system= configuration, your proposal makes sense to me. Best Regards, Qiufang Ma > > Best Regards, > Qiufang Ma Cheers, Kent // contributor --_000_2d1262bc90fc49d08eb641365b959ea4huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi , Kent:<= /span>

Apologies for the dela= y. I missed your reply and never saw it in my inbox(bugs?) L.

Thanks  for the d= etailed examples and explanation, and now I have a better understanding abo= ut your proposal.

Please see my reply in= line.

 

[likewise snip…]= 

For the second category, imagine=
 <system> containing some predefined objects.  These objects fol=
low the standard data-model allowed by the YANG.  Operators could have=
 defined these objects as well but, because there may be hundreds of these =
objects, and the objects are the same for everyone, the vendor decides to p=
re-define them as a convenience for their customers.  This way, operat=
ors only have to define custom objects for what is unique in their environm=
ents.    By example, imagine this in <system>:
 
     &n=
bsp;   system-defined-defaults {
     &n=
bsp;           applicatio=
ns {
     &n=
bsp;            =
;        application ftp {
     &n=
bsp;            =
;            &n=
bsp;    protocol tcp;
     &n=
bsp;            =
;            &n=
bsp;    destination-port 21;
     &n=
bsp;            =
;        }
     &n=
bsp;            =
;        application tftp {
     &n=
bsp;            =
;            &n=
bsp;    protocol udp;
     &n=
bsp;            =
;            &n=
bsp;    destination-port 69;
     &n=
bsp;            =
;        }
     &n=
bsp;            =
;        application smtp {
     &n=
bsp;            =
;            &n=
bsp;    protocol tcp;
     &n=
bsp;            =
;            &n=
bsp;    destination-port 25;
     &n=
bsp;            =
;        }
     &n=
bsp;            =
;        ...
     &n=
bsp;            }
     &n=
bsp;   }
 
And this in <running>=

 
     &n=
bsp;           # custom o=
bjects
     &n=
bsp;           applicatio=
ns {
     &n=
bsp;            =
;        application my-app-1 {
     &n=
bsp;            &nbs=
p;            &=
nbsp;  protocol tcp;
     &n=
bsp;            =
;            &n=
bsp;    destination-port 2345;
     &n=
bsp;            =
;        }
     &n=
bsp;            =
;        application my-app-2 {
     &n=
bsp;            =
;            &n=
bsp;    protocol udp;
     &n=
bsp;            =
;            &n=
bsp;    destination-port 69;
     &n=
bsp;            =
;        }
     &n=
bsp;            }
 
     &n=
bsp;           // an ACL =
policy referencing both sys-defined and custom objects

     &n=
bsp;           policy fro=
m-zone untrust to-zone untrust {


     &n=
bsp;            =
;        policy allow-external-access-to=
-foobar-app {


     &n=
bsp;            =
;            &n=
bsp;    match {


     &n=
bsp;            =
;            &n=
bsp;            =
; source-address any;


     &n=
bsp;            =
;            &n=
bsp;            =
; destination-address any;


     &n=
bsp;            =
;            &n=
bsp;            =
; application [ ftp tftp, my-app-1, my-app-2 ];


     &n=
bsp;            =
;            &n=
bsp;    }


     &n=
bsp;            =
;            &n=
bsp;    then {


     &n=
bsp;            =
;            &n=
bsp;            =
; permit;


     &n=
bsp;            =
;            &n=
bsp;    }


     &n=
bsp;            =
;        }


     &n=
bsp;           }


 


[Qiufang Ma] I can und=
erstand that the vendors would like to predefine some common objects for th=
eir users’ convenience so that the users only have to define their ow=
n objects for what is unique in their environments.


What I don't really un=
derstand is why these configurations are not applied immediately but only a=
fter they are referenced?

 


Note that, <running> by it=
self would not pass validation, due to missing leafrefs.  Thankfully, =
NMDA never says that validation runs on <running>.  But once <=
;running> and <system> have been merged, to become <intended>=
;, the result does pass validation.


 [Qiufang Ma] The refe=
renced instance must also exist for the data to be valid since the require-=
instance defaults to true if not present. Is this what you had in your mind=
? Yes, NMDA says that it is <intended> which is subject to validation=
. But I also notice that In section 5.1.3 of the NMDA:”<running>=
; MUST always be a valid configuration data tree, as defined  in Secti=
on 8.1 of [RFC7950]. ” So my thought here is that <running> sho=
uld also conform to the YANG model constraints and that’s to say, a r=
eferenced system-defined data item should also exists in <running>.


Therefore, if system c=
onfigurations do not exist in <running>, they still need to be  =
configured in <running> manually in order for being referenced. In th=
is case, the original purpose of predefining some system configurations for=
 user convenience is lost. This is the reason why we would like to define s=
ome mechanism here to synchronize <system> into <running>. 


 


> I am wondering if these con=
figuration will present in the <operational> (which contains all the =
configuration actually used by the device) before they’re referenced.=



 


I think that it would depend in =
the specific server’s behavior, regarding if *unused* predefine objec=
ts are present in <operational>.  Certainly the unused objects w=
ould not have to be present in <operational>.  If I were impleme=
nting the server, the unused objects would NOT be present in <operationa=
l>.


[Qiufang Ma] Yes, if t=
he predefined system configurations is unused, then I also tend to agree th=
at they would not be present in <operational> but may also depend on =
the vendor implementation.<=
/pre>

 


 


 


> It would be good if we coul=
d determine if there are any other "resource-independent” config=
uration categories here.


> [Qiufang Ma] Do you think t=
here exists conditional system configuration (if the preceding configuratio=
ns you mentioned above is not)? For example, if SSH is enabled on a device,=
 SSH-related keys are automatically generated. Such configurations are gene=
rated at the moment when a special functionality is enabled.


 


I’m unsure what you mean i=
n general by "conditional configuration”, but I can speak to you=
r specific example. Though I must preface my comments that I imagine there =
are a number of ways servers might go about enabling `sshd`.  What fol=
lows is my personal view, forged by being around systems for awhile  ;=
)=



 


In general:

 


     &n=
bsp;   - `sshd` is NOT enabled by default.

     &n=
bsp;   - `sshd` is enabled via a configuration knob.


     &n=
bsp;   - the SSH host key is dynamically generated the first time=
 `sshd` is enabled.


     &n=
bsp;   - the SSH host key itself is in <operational> (not &=
lt;running>)


 


This view is consistent with the=
 first paragraph in Section 3 of the “keystore” draft (reproduc=
ed below):


 


     &n=
bsp;   3.  Support for Built-in Keys


 


     &n=
bsp;      In some implementations, a server may support=
 built-in keys.  Built-


     &n=
bsp;      in keys MAY be set during the manufacturing p=
rocess or be dynamically


     &n=
bsp;      generated the first time the server is booted=
 or a particular service


     &n=
bsp;      (e.g., SSH) is enabled.

 


As a closing thought, this model=
 (which I stated upfront may not be universal) would have no presence-in or=
 interaction-with <system>…though, perhaps, there may be some p=
redefined values for what key-algorithms and/or key-lengths to use when gen=
erating the SSH host key...


[Qiufang Ma] By “=
;conditional system configuration”, I was meaning some of the system =
configurations are not generated immediately after the device is powered on=
. Instead, they are generated when a specific condition is satisfied during=
 the device running(e.g., a functionality is enabled due to some client con=
figurations). I am not sure if it really exists, maybe not, just try to exp=
lore the possibilities of various resource-independent system configuration=
s.:) 


 


 


Firstly, I again have to preface=
 my comment that there are likely many ways that templating mechanisms can =
be defined.    But, in general, once a templating mechanism =
has been defined, then it stands to reason that templates could be defined =
either in <running> (by operators) or in <system> (by the manuf=
acturer).  In one implementation I’m familiar with, the template=
s are objects that are referenced/parameterized by other parts of the confi=
guration.  (Same as with the predefined objects discussion above.)&nbs=
p; 


 


To answer your questions:


 


1) Yes, it is my opinion that *a=
ctivated* templates in <system> will be expanded and present in <i=
ntended>.


 


2) I would never suggest that th=
e system-defined templates are present in <running>, though they may =
be referenced/parameterized by config in <running>.=



 


3) if a config-template is confi=
gured in <running> (i.e., it is operator-defined) then, yes, the expa=
nded configuration in <intended> is "client configuration”=
 (note, "client configuration” is not a formal term).  That=
 said, it seems fair to say that a template defined in <system> and t=
hen referenced by "client configuration” in <running> is a=
lso expanded as "client configuration” in <intended>.=



 


4) I don’t not understand =
your last sentence, that the expansion of <system> templates are only=
 present in <operational>.  Maybe you’re saying something =
subtle, e.g., that servers currently don’t support GET on <intende=
d>.  But, in theory, the expansion of <system> templates shou=
ld (IMO) be present in <intended>, so that they may be subject to val=
idation.   Of course, all the <intended> configuration (whe=
ther originating in <running> or <system>) that is successfully=
 “applied” will also be present in <operational>.


[Qiufang Ma] Assume th=
at there is no <system> and this work, the expansion of system templa=
tes are only present in <operational>. Because this is compatible wit=
h system configuration definition in NMDA.


But if system configur=
ations are only present in <operational>, the predefined system confi=
gurations still need to be retrieved and created into <running> expli=
citly when being referenced. I think we’ve reached an agreement on th=
e need for <system> to exist, and our main point of disagreement is w=
hether <system> should be copied into <running>. Your point is =
that being merged into <intended> is enough to make sure a success va=
lidation. But my understanding is that the referenced system configuration =
data item must also exist in the <running> to obey the model constrai=
nts.


 


 


<big snip>


> I’m beginning to thin=
k that:


> ·   &=
nbsp;     auto-copying into <running> is likely n=
ever a good idea, because it violates the definition of <running>


> [Qiufang Ma] I am quite awa=
re that different datastores in NMDA represents different views of data nod=
es.  And <running> represents a configuration datastore holding =
the current configuration of the device.


> Should we consider system c=
onfiguration also be part of current configuration of the device? From my p=
erspective, the difference between system configuration and  client-co=
nfiguration lies only in who provides it.


 


<running> holds the curren=
t *operator-specified* configuration of the device.  System-provided c=
onfiguration is NOT specified by operators (though system-defined objects m=
ay be referenced by operator-specified config in <running>). &nb=
sp; I believe that this arrangement is consistent with the definition of &l=
t;running>.  Agreed?


[Qiufang Ma] Yes. Actu=
ally we are not trying to violate the principles of NMDA and the definition=
 of <running>.  The issue we try to resolve here is that system =
configurations cannot be used(referenced or overwritten) by the operators d=
irectly and need to be created into <running> explicitly. This actual=
ly loses the meaning of “predefining and bringing convenience”.=
 If auto-copying is not a good idea, what do you think about defining an RP=
C operation for the operators to do the copy(which is also what Rob suggest=
s at the meeting)?


 


 


> ·   &=
nbsp;     having in <operational> doesn’t m=
ake sense, since the tweaks wouldn’t go thru <running> --> &=
lt;intended> validation.


>  

> I’m wondering if a mo=
del like below would work for everyone - thoughts?


> [Qiufang Ma] <intended&g=
t; represents the configuration after all configuration transformations to =
<running> have been performed, so I think it is only coupled to <r=
unning>.


> Anyway, the <system> =
should also interacts with <operational>.  Agreed?


 


I don’t agree that <int=
ended> must only be coupled to <running>.  Specifically, I th=
ink that it is okay (compatible with NMDA) to define a <system> that =
also impacts <intended>.   This is the only (IMO) sane appr=
oach, as it enables the combination <running> + <system> to=
 be validated.


[Qiufang Ma] Please se=
e above. If <running> is OK to miss referenced system configuration, =
your proposal makes sense to me.


 


Best Regards,


Qiufang Ma =



 


 


 


>  

> Best Regards,


> Qiufang Ma


 


Cheers,


Kent // contributor


 
--_000_2d1262bc90fc49d08eb641365b959ea4huaweicom_-- From nobody Thu Jul 15 11:28:08 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE483A058F; Thu, 15 Jul 2021 11:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zuQ8V8NjBni; Thu, 15 Jul 2021 11:27:57 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 1BDD83A0538; Thu, 15 Jul 2021 11:27:56 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16FIRnxC009026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jul 2021 14:27:54 -0400 Date: Thu, 15 Jul 2021 11:27:48 -0700 From: Benjamin Kaduk To: Andy Bierman Cc: The IESG , draft-ietf-netmod-nmda-diff@ietf.org, NetMod WG Chairs , NetMod WG , Joel Jaeggli Message-ID: <20210715182748.GU74365@kduck.mit.edu> References: <162578071895.23622.6414701243842084826@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-nmda-diff-09: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 18:28:02 -0000 Hi Andy, On Mon, Jul 12, 2021 at 03:42:30PM -0700, Andy Bierman wrote: > On Thu, Jul 8, 2021 at 2:45 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-netmod-nmda-diff-09: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks to Alexey Melnikov for the secdir review. > > > > I'm not experienced enough with YANG to know whether or how problematic > > it is that the "anydata subtree-filter" node contents are described by > > reference to the NETCONF specification, which has a particular (XML) > > representation of YANG data and does not give a clear presentation of > > the abstract YANG structure/semantics to be used. Is it possible to use > > the filter-spec choice option when, for example, RESTCONF is used with > > JSON encoding? > > > > > > There is not a standard specification for subtree filtering using JSON > encoding > instead of XML. RESTCONF has its own somewhat compatible filtering > mechanism. > It would require a new NETCONF work item to officially expand subtree > filtering > to support JSON. (Unofficially, there is RFC for JSON encoding of YANG > data and an > implementation could map the RFC 6241 text to JSON). Okay, this sounds a little familiar now that you mention it. Should we mention in a comment of some form that this filtering mechanism is currently only usable with the XML encoding? > > > > Section 4 > > > > o report-origin: When set, this parameter indicates that origin > > metadata should be included as part of RPC output. When this > > parameter is omitted, origin metadata in comparisons that involve > > is by default omitted. > > > > Why is it important to complicate the semantics of this parameter with a > > dependence on the datastore? It seems like it would be simpler to get > > this effect by having clients specify report-origin when the target is > > not . Note that changing the semantics would require text > > changes in subsequent parts of the document for consistency. (If > > retaining the current semantics, please clarify whether "comparisons > > that involve " applies when operational is source, target, > > or either.) > > > > > IMO NMDA is way too complicated, so I cannot argue with that complaint. > The origin attribute only applies to the datastore. > I think it is not allowed to appear elsewhere. Ah, I see what you are saying now (on second read): the "origin" being reported is the origin attribute of the data in the datastore being compared, but only the datastore will every have that attribute available. The text here would be a lot more clear if it reminded the reader that the origin attribute has such a limited scope, perhaps: o report-origin: data in the datastore has an associated "origin" attribute that indicates the origin of the reported value. When set, this parameter indicates that the origin metadata should be included as part of the RPC output. It has no effect when the target datastore is anything other than . When this parameter is omitted, the origin metadata is omitted from the RPC output. > > Section 9 > > > > In addition to noting that the "compare" RPC is sensitive and should be > > restricted to authorized parties, I suggest to reiterate that the > > "compare" operation should not provide a mechanism to work around access > > control on other nodes -- that is, a result should only be returned if > > the requestor would be allowed to access both the "source" and "target" > > trees independently of the RPC. In particular, even a "no-matches" > > output should not be returned, as that might provide a way to determine > > the structure of the datastore even without accessing it. > > > > Fortunately the access control model (NACM) is per server and not per > datastore > so the same access rules apply to all datastores. I agree the no-access > subtrees > should be silently skipped, the same way that GET operations are treated in > NACM. Ah, okay. (I think Roman may have mentioned a similar concern about no-access subtrees, too.) Thanks, Ben > > > > We might also incorporate by reference the security considerations for > > subtree filtering (RFC 6241) and xpath filtering (RFC 6991). > > > > NITS > > > > Section 1 > > > > an unusually long time to do so. This can be the case due to certain > > conditions not being met, certain parts of the configuration not > > propagating because considered inactive, resource dependencies not > > being resolved, or even implementation errors in corner conditions. > > > > "because considered inactive" seems like an incomplete clause; maybe > > "because they are considered inactive"? > > > > Section 4 > > > > o differences: This parameter contains the list of differences. > > Those differences are encoded per YANG-Patch data model defined in > > > > s/YANG-Patch/the YANG-Patch/ > > I'd also consider s/per/according to/, since this is not exactly a > > logic-driven deduction but rather more of a new requirement. > > > > Section 6 > > > > for the management of interfaces defined in [RFC8343]. The excerpt > > of the data model whose instantiation is the basis of the comparison > > is as follows: > > > > I feel like this phrasing is a little misleading, as not only is the > > following snippet only a subset of the nodes contained within "container > > interfaces" but the descriptions have been greatly abbreviated as well. > > Perhaps we could say something about "for the purposes of understanding > > the subsequent example, the following subset of the [RFC8343] data model > > is provided". > > > > Accept: application/yang-d > > > > (I believe this truncated header field was already noted by another > > reviewer.) > > > > > > Andy From nobody Thu Jul 15 11:54:45 2021 Return-Path: <0100017aab854793-eb989e55-8496-451b-84de-7f17cb0720d5-000000@amazonses.watsen.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458E13A0FD1 for ; Thu, 15 Jul 2021 11:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsyMmeiiXM2s for ; Thu, 15 Jul 2021 11:54:38 -0700 (PDT) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408D63A0FCD for ; Thu, 15 Jul 2021 11:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1626375276; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=g1nNUlb/Kq4vY+cgMpRPPWPRPTOdAVqgCn8ofVduszw=; b=jl+olcxc7qJ6t6H6N3ObylRbgutDqhhZ9rX3qe1O3MXbmRsC27KPN9eNIY0ddiaG Yn3GYATHeEmwNeyhh1oqow/SPFZsj7mEfRZBcJB1pLOKNHkKSLYBPxLN4eO3HwdEerx Ee7tWeFmu7ctSy7cZFK3PgEw4ZOjMaxyF1nFQe1I= From: Kent Watsen Message-ID: <0100017aab854793-eb989e55-8496-451b-84de-7f17cb0720d5-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AAD4ECF4-AE7A-4D73-B3BC-473488829AF9" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 15 Jul 2021 18:54:36 +0000 In-Reply-To: <2d1262bc90fc49d08eb641365b959ea4@huawei.com> Cc: "netmod@ietf.org" To: "maqiufang (A)" References: <5b76dae2175545959f0006b036efd647@huawei.com> <2d1262bc90fc49d08eb641365b959ea4@huawei.com> X-Mailer: Apple Mail (2.3654.100.0.2.22) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.07.15-54.240.48.92 Archived-At: Subject: Re: [netmod] system configuration sync mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2021 18:54:43 -0000 --Apple-Mail=_AAD4ECF4-AE7A-4D73-B3BC-473488829AF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Qiufang, > Hi , Kent: > Apologies for the delay. I missed your reply and never saw it in my = inbox(bugs?) L. > Thanks for the detailed examples and explanation, and now I have a = better understanding about your proposal. > Please see my reply inline. No worries about the delay. I didn=E2=80=99t miss it at all ;) > [likewise snip=E2=80=A6] > For the second category, imagine containing some predefined = objects. These objects follow the standard data-model allowed by the = YANG. Operators could have defined these objects as well but, because = there may be hundreds of these objects, and the objects are the same for = everyone, the vendor decides to pre-define them as a convenience for = their customers. This way, operators only have to define custom objects = for what is unique in their environments. By example, imagine this in = : > =20 > system-defined-defaults { > applications { > application ftp { > protocol tcp; > destination-port 21; > } > application tftp { > protocol udp; > destination-port 69; > } > application smtp { > protocol tcp; > destination-port 25; > } > ... > } > } > =20 > And this in > =20 > # custom objects > applications { > application my-app-1 { > protocol tcp; > destination-port 2345; > } > application my-app-2 { > protocol udp; > destination-port 69; > } > } > =20 > // an ACL policy referencing both sys-defined and = custom objects > policy from-zone untrust to-zone trust { > policy allow-external-access-to-foobar-app { > match { > source-address any; > destination-address any; > application [ ftp tftp, = my-app-1, my-app-2 ]; > } > then { > permit; > } > } > } > =20 > [Qiufang Ma] I can understand that the vendors would like to predefine = some common objects for their users=E2=80=99 convenience so that the = users only have to define their own objects for what is unique in their = environments. > What I don't really understand is why these configurations are not = applied immediately but only after they are referenced? The question is if the server implementation prunes dangling/unused = objects when is applied, updating . My = assumption is that the server will discard any object that doesn=E2=80=99t= actually impact the running configuration of the system (i.e., values = are consumed by the underlying operating system, drivers, etc.). = Thusly, it is my opinion that only the referenced objects are applied. = Hence why, to answer your last question, I wrote that these = configurations (manufacturer-defined objects) are not applied = immediately but only after they are referenced. Makes sense? Keep in mind that what is described above is just one aspect of what can = be in . In addition to defining reference-able objects, = can also define/apply configuration immediately (e.g., the = loopback interface). That is, configuration not does not have to be = referenced in order to become activated. > =20 > Note that, by itself would not pass validation, due to = missing leafrefs. Thankfully, NMDA never says that validation runs on = . But once and have been merged, to become = , the result does pass validation. > [Qiufang Ma] The referenced instance must also exist for the data to = be valid since the require-instance defaults to true if not present. Is = this what you had in your mind? Yes, NMDA says that it is = which is subject to validation. But I also notice that In section 5.1.3 = of the NMDA:=E2=80=9D MUST always be a valid configuration data = tree, as defined in Section 8.1 of [RFC7950]. =E2=80=9D So my thought = here is that should also conform to the YANG model constraints = and that=E2=80=99s to say, a referenced system-defined data item should = also exists in . > Therefore, if system configurations do not exist in , they = still need to be configured in manually in order for being = referenced. In this case, the original purpose of predefining some = system configurations for user convenience is lost. This is the reason = why we would like to define some mechanism here to synchronize = into .=20 I see in RFC 8342 " MUST always be a valid configuration data = tree, as defined in Section 8.1 of [RFC7950]=E2=80=9D. But the question remains if it is possible for the system is able to = validate without, e.g., expanding templates. There may be a = 'leafref' or =E2=80=98must=E2=80=99 expression somewhere that will fail = because the evaluation occurs without expanding a template that supplies = the missing parts. If this draft =E2=80=9Cupdates=E2=80=9D RFC 8342 (NMDA), then it can = supply a clarifying statement about what it means that " MUST = always be a valid configuration data tree=E2=80=9D. Either that, or an = Errata if it=E2=80=99s determined that the statement isn=E2=80=99t = correct. You make a good technical point, but I think that we should *want* to = avoid having to copy (or ) configuration into = if we can avoid it. Agreed? FWIW, also in RFC 8342, Section 5.1.4.: is tightly coupled to . Whenever data is written to , the server MUST also immediately update and validate . MAY also be updated independently of if the effect of a configuration transformation changes, but MUST always be a valid configuration data tree, as defined in Section=C2=A08= .1 of [RFC7950] = . > =20 > > I am wondering if these configuration will present in the = (which contains all the configuration actually used by the = device) before they=E2=80=99re referenced. > =20 > I think that it would depend in the specific server=E2=80=99s = behavior, regarding if *unused* predefine objects are present in = . Certainly the unused objects would not have to be = present in . If I were implementing the server, the unused = objects would NOT be present in . > [Qiufang Ma] Yes, if the predefined system configurations is unused, = then I also tend to agree that they would not be present in = but may also depend on the vendor implementation. Yup, this is the same conclusion is in my response above. > > It would be good if we could determine if there are any other = "resource-independent=E2=80=9D configuration categories here. > > [Qiufang Ma] Do you think there exists conditional system = configuration (if the preceding configurations you mentioned above is = not)? For example, if SSH is enabled on a device, SSH-related keys are = automatically generated. Such configurations are generated at the moment = when a special functionality is enabled. > =20 > I=E2=80=99m unsure what you mean in general by "conditional = configuration=E2=80=9D, but I can speak to your specific example. Though = I must preface my comments that I imagine there are a number of ways = servers might go about enabling `sshd`. What follows is my personal = view, forged by being around systems for awhile ;) > =20 > In general: > =20 > - `sshd` is NOT enabled by default. > - `sshd` is enabled via a configuration knob. > - the SSH host key is dynamically generated the first time = `sshd` is enabled. > - the SSH host key itself is in (not ) > =20 > This view is consistent with the first paragraph in Section 3 of the = =E2=80=9Ckeystore=E2=80=9D draft (reproduced below): > =20 > 3. Support for Built-in Keys > =20 > In some implementations, a server may support built-in = keys. Built- > in keys MAY be set during the manufacturing process or be = dynamically > generated the first time the server is booted or a = particular service > (e.g., SSH) is enabled. > =20 > As a closing thought, this model (which I stated upfront may not be = universal) would have no presence-in or interaction-with = =E2=80=A6though, perhaps, there may be some predefined values = for what key-algorithms and/or key-lengths to use when generating the = SSH host key... > [Qiufang Ma] By =E2=80=9Cconditional system configuration=E2=80=9D, I = was meaning some of the system configurations are not generated = immediately after the device is powered on. Instead, they are generated = when a specific condition is satisfied during the device running(e.g., a = functionality is enabled due to some client configurations). I am not = sure if it really exists, maybe not, just try to explore the = possibilities of various resource-independent system configurations.:)=20= To this point I agree..as does RFC 8342 (NMDA), Section 5.3.3.: Sometimes, resources are controlled by the device and the corresponding system-controlled data appears in (and disappears from) dynamically. If a system-controlled resource has matching configuration in when it appears, the system will try to apply the configuration; this causes the configuration to appear in eventually (if application of the configuration was successful). > =20 > =20 > Firstly, I again have to preface my comment that there are likely many = ways that templating mechanisms can be defined. But, in general, once = a templating mechanism has been defined, then it stands to reason that = templates could be defined either in (by operators) or in = (by the manufacturer). In one implementation I=E2=80=99m = familiar with, the templates are objects that are = referenced/parameterized by other parts of the configuration. (Same as = with the predefined objects discussion above.) =20 > =20 > To answer your questions: > =20 > 1) Yes, it is my opinion that *activated* templates in will = be expanded and present in . > =20 > 2) I would never suggest that the system-defined templates are present = in , though they may be referenced/parameterized by config in = . > =20 > 3) if a config-template is configured in (i.e., it is = operator-defined) then, yes, the expanded configuration in is = "client configuration=E2=80=9D (note, "client configuration=E2=80=9D is = not a formal term). That said, it seems fair to say that a template = defined in and then referenced by "client configuration=E2=80=9D = in is also expanded as "client configuration=E2=80=9D in = . > =20 > 4) I don=E2=80=99t not understand your last sentence, that the = expansion of templates are only present in . = Maybe you=E2=80=99re saying something subtle, e.g., that servers = currently don=E2=80=99t support GET on . But, in theory, the = expansion of templates should (IMO) be present in , = so that they may be subject to validation. Of course, all the = configuration (whether originating in or ) = that is successfully =E2=80=9Capplied=E2=80=9D will also be present in = . > [Qiufang Ma] Assume that there is no and this work, the = expansion of system templates are only present in . Because = this is compatible with system configuration definition in NMDA. > But if system configurations are only present in , the = predefined system configurations still need to be retrieved and created = into explicitly when being referenced. I think we=E2=80=99ve = reached an agreement on the need for to exist, and our main = point of disagreement is whether should be copied into = . Your point is that being merged into is enough to = make sure a success validation. But my understanding is that the = referenced system configuration data item must also exist in the = to obey the model constraints. Yes, I believe that you provided an accurate description of the = difference in our opinions. Per my earlier response, you make a valid = technical point, my goal is to waive that interpretation to the side so = that a simpler solution can emerge. It would be good to get other = opinions on list, otherwise we=E2=80=99ll take it into the meeting. [BTW, in keeping with this thread moving from the NETCONF to the NETMOD = mailing lists, would it make sense to move the IETF 111 presentation = slot from NETCONF to NETMOD too? I think it does and, further, it would = help with scheduling (NETCONF is over, NETMOD is under). Would you be = okay with this? AD Rob and the NETCONF chairs discussed this morning, = and think it's okay, but would still need to confirm with the NETMOD = chairs.] > > > I=E2=80=99m beginning to think that: > > =C2=B7 auto-copying into is likely never a good = idea, because it violates the definition of > > [Qiufang Ma] I am quite aware that different datastores in NMDA = represents different views of data nodes. And represents a = configuration datastore holding the current configuration of the device. > > Should we consider system configuration also be part of current = configuration of the device? =46rom my perspective, the difference = between system configuration and client-configuration lies only in who = provides it. > =20 > holds the current *operator-specified* configuration of the = device. System-provided configuration is NOT specified by operators = (though system-defined objects may be referenced by operator-specified = config in ). I believe that this arrangement is consistent = with the definition of . Agreed? > [Qiufang Ma] Yes. Actually we are not trying to violate the principles = of NMDA and the definition of . The issue we try to resolve = here is that system configurations cannot be used(referenced or = overwritten) by the operators directly and need to be created into = explicitly. This actually loses the meaning of =E2=80=9Cpredefin= ing and bringing convenience=E2=80=9D. If auto-copying is not a good = idea, what do you think about defining an RPC operation for the = operators to do the copy(which is also what Rob suggests at the = meeting)? If we have to copy into , then I think that I agree an RPC = (?) would be better. You mention =E2=80=9Coverwritten=E2=80=9D by the operators? Why = wouldn=E2=80=99t the operators just define their own? For instance, if = they don=E2=80=99t like the vendor=E2=80=99s =E2=80=9Cvendor-foobar=E2=80=9D= object, they could copy/paste/edit their own =E2=80=9Cmy-foobar=E2=80=9D = object with the values needed, yes? > =20 > =20 > > =C2=B7 having in doesn=E2=80=99t make sense, = since the tweaks wouldn=E2=80=99t go thru --> = validation. > > =20 > > I=E2=80=99m wondering if a model like below would work for everyone = - thoughts? > > [Qiufang Ma] represents the configuration after all = configuration transformations to have been performed, so I = think it is only coupled to . > > Anyway, the should also interacts with . = Agreed? > =20 > I don=E2=80=99t agree that must only be coupled to = . Specifically, I think that it is okay (compatible with NMDA) = to define a that also impacts . This is the only = (IMO) sane approach, as it enables the combination + = to be validated. > [Qiufang Ma] Please see above. If is OK to miss referenced = system configuration, your proposal makes sense to me. Ack. > Best Regards, > Qiufang Ma=20 Kent // contributor= --Apple-Mail=_AAD4ECF4-AE7A-4D73-B3BC-473488829AF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Qiufang,


Hi , Kent:
Apologies = for the delay. I missed your reply and never saw it in my = inbox(bugs?) L.
Thanks =  for the detailed examples and explanation, and now I have a better = understanding about your proposal.
Please see my reply = inline.

No worries about the delay.  I didn=E2=80=99= t miss it at all  ;)



[likewise = snip=E2=80=A6]
For the second category, imagine =
<system> containing some predefined objects.  These objects =
follow the standard data-model allowed by the YANG.  Operators =
could have defined these objects as well but, because there may be =
hundreds of these objects, and the objects are the same for everyone, =
the vendor decides to pre-define them as a convenience for their =
customers.  This way, operators only have to define custom objects =
for what is unique in their environments.    By example, =
imagine this in <system>:
 
         =
system-defined-defaults {
          &nb=
sp;      applications {
          &nb=
sp;            =
;   application ftp {
          &nb=
sp;            =
;            =
protocol tcp;
          &nb=
sp;            =
;            =
destination-port 21;
          &nb=
sp;            =
;   }
          &nb=
sp;            =
;   application tftp {
          &nb=
sp;            =
;            =
protocol udp;
          &nb=
sp;            =
;            =
destination-port 69;
          &nb=
sp;            =
;   }
          &nb=
sp;            =
;   application smtp {
          &nb=
sp;            =
;            =
protocol tcp;
          &nb=
sp;            =
;            =
destination-port 25;
          &nb=
sp;            =
;   }
          &nb=
sp;            =
;   ...
          &nb=
sp;       }
         }
 
And this in =
<running>
 
          &nb=
sp;      # custom objects
          &nb=
sp;      applications {
          &nb=
sp;            =
;   application my-app-1 {
          &nb=
sp;      =
            &n=
bsp;    protocol tcp;
          &nb=
sp;            =
;            =
destination-port 2345;
          &nb=
sp;            =
;   }
          &nb=
sp;            =
;   application my-app-2 {
          &nb=
sp;            =
;            =
protocol udp;
          &nb=
sp;            =
;            =
destination-port 69;
          &nb=
sp;            =
;   }
          &nb=
sp;       }
 
          &nb=
sp;      // an ACL policy referencing both =
sys-defined and custom objects
          &nb=
sp;      policy from-zone untrust to-zone trust =
{
          &nb=
sp;            =
;   policy allow-external-access-to-foobar-app {
          &nb=
sp;            =
;            =
match {
          &nb=
sp;            =
;            &=
nbsp;        source-address any;
          &nb=
sp;            =
;            &=
nbsp;        destination-address =
any;
          &nb=
sp;            =
;            &=
nbsp;        application [ ftp tftp, =
my-app-1, my-app-2 ];
          &nb=
sp;            =
;            =
}
          &nb=
sp;            =
;            then =
{
          &nb=
sp;            =
;            &=
nbsp;        permit;
          &nb=
sp;            =
;            =
}
          &nb=
sp;            =
;   }
          &nb=
sp;      }
 
[Qiufang Ma] I =
can understand that the vendors would like to predefine some common =
objects for their users=E2=80=99 convenience so that the users only have =
to define their own objects for what is unique in their =
environments.
What I don't =
really understand is why these configurations are not applied =
immediately but only after they are =
referenced?


The question is if the = server implementation prunes dangling/unused objects when = <intended> is applied, updating <operational>.  My = assumption is that the server will discard any object that doesn=E2=80=99t= actually impact the running configuration of the system (i.e., values = are consumed by the underlying operating system, drivers, etc.). =  Thusly, it is my opinion that only the referenced objects are = applied.  Hence why, to answer your last question, I wrote that = these configurations (manufacturer-defined objects) are not applied = immediately but only after they are referenced.  Makes = sense?

Keep in mind that what is = described above is just one aspect of what can be in <system>. =  In addition to defining reference-able objects, <system> can = also define/apply configuration immediately (e.g., the loopback = interface).  That is, configuration not does not have to be = referenced in order to become activated.


 
Note that, =
<running> by itself would not pass validation, due to missing =
leafrefs.  Thankfully, NMDA never says that validation runs on =
<running>.  But once <running> and <system> have =
been merged, to become <intended>, the result does pass =
validation.
 [Qiufang Ma] The referenced instance must =
also exist for the data to be valid since the require-instance defaults =
to true if not present. Is this what you had in your mind? Yes, NMDA =
says that it is <intended> which is subject to validation. But I =
also notice that In section 5.1.3 of the NMDA:=E2=80=9D<running> =
MUST always be a valid configuration data tree, as defined  in =
Section 8.1 of [RFC7950]. =E2=80=9D So my thought here is that =
<running> should also conform to the YANG model constraints and =
that=E2=80=99s to say, a referenced system-defined data item should also =
exists in <running>.
Therefore, if =
system configurations do not exist in <running>, they still need =
to be  configured in <running> manually in order for being =
referenced. In this case, the original purpose of predefining some =
system configurations for user convenience is lost. This is the reason =
why we would like to define some mechanism here to synchronize =
<system> into <running>. =


I see in RFC 8342 = "<running> MUST always be a valid configuration data tree, as = defined in Section 8.1 of [RFC7950]=E2=80=9D.

But the question remains if it is possible for the = system is able to validate <running> without, e.g., expanding = templates.  There may be a 'leafref' or =E2=80=98must=E2=80=99 = expression somewhere that will fail because the evaluation occurs = without expanding a template that supplies the missing = parts.

If this draft =E2=80=9Cupdates=E2= =80=9D RFC 8342 (NMDA), then it can supply a clarifying statement about = what it means that "<running> = MUST always be a valid configuration data tree=E2=80=9D.  Either = that, or an Errata if it=E2=80=99s determined that the statement isn=E2=80= =99t correct.

You make a good = technical point, but I think that we should *want* to avoid having to = copy <system> (or <operational>) configuration into = <running> if we can avoid it.  Agreed?

FWIW, also in RFC 8342, Section = 5.1.4.:

   <intended> is tightly coupled to =
<running>.  Whenever data is written
   to <running>, the server MUST also immediately update and =
validate
   <intended>.

   <intended> MAY also be updated independently of <running> =
if the
   effect of a configuration transformation changes, but =
<intended> MUST
   always be a valid configuration data tree, as defined in Section 8.1
   of [RFC7950].




 
> I am =
wondering if these configuration will present in the <operational> =
(which contains all the configuration actually used by the device) =
before they=E2=80=99re referenced.
 
I think =
that it would depend in the specific server=E2=80=99s behavior, =
regarding if *unused* predefine objects are present in =
<operational>.  Certainly the unused objects would not have =
to be present in <operational>.  If I were implementing the =
server, the unused objects would NOT be present in =
<operational>.
[Qiufang Ma] =
Yes, if the predefined system configurations is unused, then I also tend =
to agree that they would not be present in <operational> but may =
also depend on the vendor =
implementation.


Yup, this is the same = conclusion is in my response above.


> It would =
be good if we could determine if there are any other =
"resource-independent=E2=80=9D configuration categories here.
> [Qiufang =
Ma] Do you think there exists conditional system configuration (if the =
preceding configurations you mentioned above is not)? For example, if =
SSH is enabled on a device, SSH-related keys are automatically =
generated. Such configurations are generated at the moment when a =
special functionality is enabled.
 
I=E2=80=99=
m unsure what you mean in general by "conditional configuration=E2=80=9D, =
but I can speak to your specific example. Though I must preface my =
comments that I imagine there are a number of ways servers might go =
about enabling `sshd`.  What follows is my personal view, forged by =
being around systems for awhile  ;)
 
In =
general:
 
         - `sshd` is =
NOT enabled by default.
         - `sshd` is =
enabled via a configuration knob.
         - the SSH =
host key is dynamically generated the first time `sshd` is enabled.
         - the SSH =
host key itself is in <operational> (not <running>)
 
This view is =
consistent with the first paragraph in Section 3 of the =E2=80=9Ckeystore=E2=
=80=9D draft (reproduced below):
 
         3.  =
Support for Built-in Keys
 
            =
In some implementations, a server may support built-in keys.  =
Built-
            =
in keys MAY be set during the manufacturing process or be =
dynamically
            =
generated the first time the server is booted or a particular =
service
            =
(e.g., SSH) is enabled.
 
As a =
closing thought, this model (which I stated upfront may not be =
universal) would have no presence-in or interaction-with =
<system>=E2=80=A6though, perhaps, there may be some predefined =
values for what key-algorithms and/or key-lengths to use when generating =
the SSH host key...
[Qiufang Ma] =
By =E2=80=9Cconditional system configuration=E2=80=9D, I was meaning =
some of the system configurations are not generated immediately after =
the device is powered on. Instead, they are generated when a specific =
condition is satisfied during the device running(e.g., a functionality =
is enabled due to some client configurations). I am not sure if it =
really exists, maybe not, just try to explore the possibilities of =
various resource-independent system configurations.:) =

To = this point I agree..as does RFC 8342 (NMDA), Section = 5.3.3.:

   Sometimes, resources are controlled by the =
device and the
   corresponding system-controlled data appears in (and disappears from)
   <operational> dynamically.  If a system-controlled resource has
   matching configuration in <intended> when it appears, the =
system will
   try to apply the configuration; this causes the configuration to
   appear in <operational> eventually (if application of the
   configuration was successful).




 
 
Firstly, I =
again have to preface my comment that there are likely many ways that =
templating mechanisms can be defined.    But, in general, =
once a templating mechanism has been defined, then it stands to reason =
that templates could be defined either in <running> (by operators) =
or in <system> (by the manufacturer).  In one implementation =
I=E2=80=99m familiar with, the templates are objects that are =
referenced/parameterized by other parts of the configuration.  =
(Same as with the predefined objects discussion above.)  
 
To answer =
your questions:
 
1) Yes, it is =
my opinion that *activated* templates in <system> will be expanded =
and present in <intended>.
 
2) I =
would never suggest that the system-defined templates are present in =
<running>, though they may be referenced/parameterized by config =
in <running>.
 
3) if a =
config-template is configured in <running> (i.e., it is =
operator-defined) then, yes, the expanded configuration in =
<intended> is "client configuration=E2=80=9D (note, "client =
configuration=E2=80=9D is not a formal term).  That said, it seems =
fair to say that a template defined in <system> and then =
referenced by "client configuration=E2=80=9D in <running> is also =
expanded as "client configuration=E2=80=9D in <intended>.
 
4) I don=E2=80=99=
t not understand your last sentence, that the expansion of =
<system> templates are only present in <operational>.  =
Maybe you=E2=80=99re saying something subtle, e.g., that servers =
currently don=E2=80=99t support GET on <intended>.  But, in =
theory, the expansion of <system> templates should (IMO) be =
present in <intended>, so that they may be subject to =
validation.   Of course, all the <intended> =
configuration (whether originating in <running> or <system>) =
that is successfully =E2=80=9Capplied=E2=80=9D will also be present in =
<operational>.
[Qiufang Ma] =
Assume that there is no <system> and this work, the expansion of =
system templates are only present in <operational>. Because this =
is compatible with system configuration definition in NMDA.
But if system configurations are only =
present in <operational>, the predefined system configurations =
still need to be retrieved and created into <running> explicitly =
when being referenced. I think we=E2=80=99ve reached an agreement on the =
need for <system> to exist, and our main point of disagreement is =
whether <system> should be copied into <running>. Your point =
is that being merged into <intended> is enough to make sure a =
success validation. But my understanding is that the referenced system =
configuration data item must also exist in the <running> to obey =
the model constraints.

Yes, I believe that you provided an accurate = description of the difference in our opinions.  Per my earlier = response, you make a valid technical point, my goal is to waive that = interpretation to the side so that a simpler solution can emerge. =  It would be good to get other opinions on list, otherwise we=E2=80=99= ll take it into the meeting.

[BTW, = in keeping with this thread moving from the NETCONF to the NETMOD = mailing lists, would it make sense to move the IETF 111 presentation = slot from NETCONF to NETMOD too?  I think it does and, further, it = would help with scheduling (NETCONF is over, NETMOD is under). =  Would you be okay with this?   AD Rob and the NETCONF chairs = discussed this morning, and think it's okay, but would still need to = confirm with the NETMOD chairs.]



 <big snip>
> I=E2=80=99=
m beginning to think that:
> =C2=B7         =
auto-copying into <running> is likely never a good idea, because =
it violates the definition of <running>
> [Qiufang =
Ma] I am quite aware that different datastores in NMDA represents =
different views of data nodes.  And <running> represents a =
configuration datastore holding the current configuration of the =
device.
> Should =
we consider system configuration also be part of current configuration =
of the device? =46rom my perspective, the difference between system =
configuration and  client-configuration lies only in who provides =
it.
 
<running>=
 holds the current *operator-specified* configuration of the =
device.  System-provided configuration is NOT specified by =
operators (though system-defined objects may be referenced by =
operator-specified config in <running>).   I believe =
that this arrangement is consistent with the definition of =
<running>.  Agreed?
[Qiufang Ma] =
Yes. Actually we are not trying to violate the principles of NMDA and =
the definition of <running>.  The issue we try to resolve =
here is that system configurations cannot be used(referenced or =
overwritten) by the operators directly and need to be created into =
<running> explicitly. This actually loses the meaning of =
=E2=80=9Cpredefining and bringing convenience=E2=80=9D. If auto-copying =
is not a good idea, what do you think about defining an RPC operation =
for the operators to do the copy(which is also what Rob suggests at the =
meeting)?

If we have to copy into <running>, then I = think that I agree an RPC (<edit-config>?) would be = better.

You mention = =E2=80=9Coverwritten=E2=80=9D by the operators?  Why wouldn=E2=80=99t= the operators just define their own?  For instance, if they = don=E2=80=99t like the vendor=E2=80=99s =E2=80=9Cvendor-foobar=E2=80=9D = object, they could copy/paste/edit their own =E2=80=9Cmy-foobar=E2=80=9D = object with the values needed, yes?


 
 
> =
=C2=B7         having in =
<operational> doesn=E2=80=99t make sense, since the tweaks =
wouldn=E2=80=99t go thru <running> --> <intended> =
validation.
> =
 
> I=E2=80=99=
m wondering if a model like below would work for everyone - =
thoughts?
> =
[Qiufang Ma] <intended> represents the configuration after all =
configuration transformations to <running> have been performed, so =
I think it is only coupled to <running>.
> Anyway, =
the <system> should also interacts with <operational>.  =
Agreed?
 
I don=E2=80=99t=
 agree that <intended> must only be coupled to =
<running>.  Specifically, I think that it is okay (compatible =
with NMDA) to define a <system> that also impacts =
<intended>.   This is the only (IMO) sane approach, as =
it enables the combination <running> + <system> to be =
validated.
[Qiufang Ma] Please see above. If =
<running> is OK to miss referenced system configuration, your =
proposal makes sense to =
me.

Ack.


 Best =
Regards,
Qiufang Ma


Kent // = contributor
= --Apple-Mail=_AAD4ECF4-AE7A-4D73-B3BC-473488829AF9-- From nobody Fri Jul 16 03:24:35 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D021A3A3129 for ; Fri, 16 Jul 2021 03:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlExvutN1nZI for ; Fri, 16 Jul 2021 03:24:28 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 371BF3A3124 for ; Fri, 16 Jul 2021 03:24:28 -0700 (PDT) Received: from fraeml702-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GR6WV4nq9z6H7b6 for ; Fri, 16 Jul 2021 18:13:10 +0800 (CST) Received: from dggeme768-chm.china.huawei.com (10.3.19.114) by fraeml702-chm.china.huawei.com (10.206.15.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Fri, 16 Jul 2021 12:24:24 +0200 Received: from dggeme770-chm.china.huawei.com (10.3.19.116) by dggeme768-chm.china.huawei.com (10.3.19.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Fri, 16 Jul 2021 18:24:22 +0800 Received: from dggeme770-chm.china.huawei.com ([10.8.68.58]) by dggeme770-chm.china.huawei.com ([10.8.68.58]) with mapi id 15.01.2176.012; Fri, 16 Jul 2021 18:24:22 +0800 From: "maqiufang (A)" To: Kent Watsen CC: "netmod@ietf.org" Thread-Topic: [netmod] system configuration sync mechanism Thread-Index: Add4ieaMV4M1zhk1St6ROfyHhlohlAAAAuNAADd2vwAAKFO5cA== Date: Fri, 16 Jul 2021 10:24:22 +0000 Message-ID: References: <5b76dae2175545959f0006b036efd647@huawei.com> <2d1262bc90fc49d08eb641365b959ea4@huawei.com> <0100017aab854793-eb989e55-8496-451b-84de-7f17cb0720d5-000000@email.amazonses.com> In-Reply-To: <0100017aab854793-eb989e55-8496-451b-84de-7f17cb0720d5-000000@email.amazonses.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.123.93] Content-Type: multipart/alternative; boundary="_000_add2ee3bb9094e1da6a3160824d5fdffhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] system configuration sync mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 10:24:34 -0000 --_000_add2ee3bb9094e1da6a3160824d5fdffhuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEtlbnQsDQpQbGVhc2Ugc2VlIG15IHJlcGx5IGlubGluZS4NCg0KRnJvbTogS2VudCBXYXRz ZW4gW21haWx0bzprZW50K2lldGZAd2F0c2VuLm5ldF0NClNlbnQ6IEZyaWRheSwgSnVseSAxNiwg MjAyMSAyOjU1IEFNDQpUbzogbWFxaXVmYW5nIChBKSA8bWFxaXVmYW5nMUBodWF3ZWkuY29tPg0K Q2M6IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIHN5c3RlbSBjb25maWd1 cmF0aW9uIHN5bmMgbWVjaGFuaXNtDQoNCkhpIFFpdWZhbmcsDQoNCiAgICAgICAgICAgIFtzbmlw XQ0KVGhlIHF1ZXN0aW9uIGlzIGlmIHRoZSBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gcHJ1bmVzIGRh bmdsaW5nL3VudXNlZCBvYmplY3RzIHdoZW4gPGludGVuZGVkPiBpcyBhcHBsaWVkLCB1cGRhdGlu ZyA8b3BlcmF0aW9uYWw+LiAgTXkgYXNzdW1wdGlvbiBpcyB0aGF0IHRoZSBzZXJ2ZXIgd2lsbCBk aXNjYXJkIGFueSBvYmplY3QgdGhhdCBkb2VzbuKAmXQgYWN0dWFsbHkgaW1wYWN0IHRoZSBydW5u aW5nIGNvbmZpZ3VyYXRpb24gb2YgdGhlIHN5c3RlbSAoaS5lLiwgdmFsdWVzIGFyZSBjb25zdW1l ZCBieSB0aGUgdW5kZXJseWluZyBvcGVyYXRpbmcgc3lzdGVtLCBkcml2ZXJzLCBldGMuKS4gIFRo dXNseSwgaXQgaXMgbXkgb3BpbmlvbiB0aGF0IG9ubHkgdGhlIHJlZmVyZW5jZWQgb2JqZWN0cyBh cmUgYXBwbGllZC4gIEhlbmNlIHdoeSwgdG8gYW5zd2VyIHlvdXIgbGFzdCBxdWVzdGlvbiwgSSB3 cm90ZSB0aGF0IHRoZXNlIGNvbmZpZ3VyYXRpb25zIChtYW51ZmFjdHVyZXItZGVmaW5lZCBvYmpl Y3RzKSBhcmUgbm90IGFwcGxpZWQgaW1tZWRpYXRlbHkgYnV0IG9ubHkgYWZ0ZXIgdGhleSBhcmUg cmVmZXJlbmNlZC4gIE1ha2VzIHNlbnNlPw0KW1FpdWZhbmcgTWFdIFllcywgdHJ5IHRvIHN1bSB1 cCBvdXIgZGlzY3Vzc2lvbiBhYm91dCB0aGUgY2F0ZWdvcmllcyBvZiB0aGUgc3lzdGVtIGNvbmZp Z3VyYXRpb246DQoNCsK3ICAgICAgICAgUGh5c2ljYWwtcmVzb3VyY2UtZGVwZW5kZW50LS0+IHdo ZXRoZXIgdGhpcyBzb3J0IG9mIHN5c3RlbSBjb25maWd1cmF0aW9uIGV4aXN0cyBpbiA8c3lzdGVt PiBkZXBlbmRlbnRzIG9uIGlmIHRoZSBwaHlzaWNhbCByZXNvdXJjZSBpcyBwcmVzZW50KGUuZy4s IHBoeXNpY2FsIGludGVyZmFjZSkuDQoNCsK3ICAgICAgICAgUGh5c2ljYWwtcmVzb3VyY2UtaW5k ZXBlbmRlbnQtLT53aGljaCBpcyBwcm92aWRlZCBieSB0aGUgZGV2aWNlIHN5c3RlbQ0KDQpvICAg RnVydGhlciBjbGFzc2lmaWNhdGlvbiBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiDigJxhcHBsaWVk 4oCdIHRpbWUoZGVwZW5kZW50cyBvbiB3aGV0aGVyIHRoZSBzeXN0ZW0gY29uZmlndXJhdGlvbiBp bXBhY3RzIHRoZSBydW5uaW5nIG9mIHRoZSBzeXN0ZW0pDQoNCsKnICBDb25maWcgdGhhdCBpcyBh cHBsaWVkIGltbWVkaWF0ZWx5KGUuZy4sIHRoZSBsb29wYmFjaywgdGhlIHByZWRlZmluZWQgbWlu aW11bSBsZW5ndGggb2YgcGFzc3dvcmTigKYpDQoNCsKnICBDb25maWcgdGhhdCBpcyBhcHBsaWVk IG9ubHkgYWZ0ZXIgYmVpbmcgcmVmZXJlbmNlZCBieSBvdGhlciBjb25maWdzKGUuZywgZGVmaW5p dGlvbnMgZm9yIGFwcGxpY2F0aW9ucyBmdHAvdGZ0cOKApikNCg0KbyAgIEZ1cnRoZXIgY2xhc3Np ZmljYXRpb24gZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgZ2VuZXJhdGlvbiB0aW1lDQoNCsKnICBD b25maWcgdGhhdCBpcyBnZW5lcmF0ZWQgdW5jb25kaXRpb25hbGx5IGF0IGVhY2ggYm9vdCB0aW1l KGUuZywgbG9vcGJhY2ssIHByZWRlZmluZWQgbWluaW11bSBsZW5ndGggb2YgcGFzc3dvcmQsIGZ0 cC90ZnRw4oCmKQ0KDQrCpyAgQ29uZmlnIHRoYXQgaXMgZ2VuZXJhdGVkIGNvbmRpdGlvbmFsbHkg ZHVyaW5nIHRoZSBkZXZpY2UgcnVubmluZyhlLmcuLCBzeXN0ZW0tZ2VuZXJhdGVkIGxvY2FsLXBv cnQgYW5kIHJlbW90ZS1wb3J0IGZvciBhIG5ldyBlc3RhYmxpc2hlZCBCR1AgY29ubmVjdGlvbikN Cg0KS2VlcCBpbiBtaW5kIHRoYXQgd2hhdCBpcyBkZXNjcmliZWQgYWJvdmUgaXMganVzdCBvbmUg YXNwZWN0IG9mIHdoYXQgY2FuIGJlIGluIDxzeXN0ZW0+LiAgSW4gYWRkaXRpb24gdG8gZGVmaW5p bmcgcmVmZXJlbmNlLWFibGUgb2JqZWN0cywgPHN5c3RlbT4gY2FuIGFsc28gZGVmaW5lL2FwcGx5 IGNvbmZpZ3VyYXRpb24gaW1tZWRpYXRlbHkgKGUuZy4sIHRoZSBsb29wYmFjayBpbnRlcmZhY2Up LiAgVGhhdCBpcywgY29uZmlndXJhdGlvbiBub3QgZG9lcyBub3QgaGF2ZSB0byBiZSByZWZlcmVu Y2VkIGluIG9yZGVyIHRvIGJlY29tZSBhY3RpdmF0ZWQuDQpbUWl1ZmFuZyBNYV0gTm90ZWQuDQoN Cg0KDQoNCg0KTm90ZSB0aGF0LCA8cnVubmluZz4gYnkgaXRzZWxmIHdvdWxkIG5vdCBwYXNzIHZh bGlkYXRpb24sIGR1ZSB0byBtaXNzaW5nIGxlYWZyZWZzLiAgVGhhbmtmdWxseSwgTk1EQSBuZXZl ciBzYXlzIHRoYXQgdmFsaWRhdGlvbiBydW5zIG9uIDxydW5uaW5nPi4gIEJ1dCBvbmNlIDxydW5u aW5nPiBhbmQgPHN5c3RlbT4gaGF2ZSBiZWVuIG1lcmdlZCwgdG8gYmVjb21lIDxpbnRlbmRlZD4s IHRoZSByZXN1bHQgZG9lcyBwYXNzIHZhbGlkYXRpb24uDQoNCiBbUWl1ZmFuZyBNYV0gVGhlIHJl ZmVyZW5jZWQgaW5zdGFuY2UgbXVzdCBhbHNvIGV4aXN0IGZvciB0aGUgZGF0YSB0byBiZSB2YWxp ZCBzaW5jZSB0aGUgcmVxdWlyZS1pbnN0YW5jZSBkZWZhdWx0cyB0byB0cnVlIGlmIG5vdCBwcmVz ZW50LiBJcyB0aGlzIHdoYXQgeW91IGhhZCBpbiB5b3VyIG1pbmQ/IFllcywgTk1EQSBzYXlzIHRo YXQgaXQgaXMgPGludGVuZGVkPiB3aGljaCBpcyBzdWJqZWN0IHRvIHZhbGlkYXRpb24uIEJ1dCBJ IGFsc28gbm90aWNlIHRoYXQgSW4gc2VjdGlvbiA1LjEuMyBvZiB0aGUgTk1EQTrigJ08cnVubmlu Zz4gTVVTVCBhbHdheXMgYmUgYSB2YWxpZCBjb25maWd1cmF0aW9uIGRhdGEgdHJlZSwgYXMgZGVm aW5lZCAgaW4gU2VjdGlvbiA4LjEgb2YgW1JGQzc5NTBdLiDigJ0gU28gbXkgdGhvdWdodCBoZXJl IGlzIHRoYXQgPHJ1bm5pbmc+IHNob3VsZCBhbHNvIGNvbmZvcm0gdG8gdGhlIFlBTkcgbW9kZWwg Y29uc3RyYWludHMgYW5kIHRoYXTigJlzIHRvIHNheSwgYSByZWZlcmVuY2VkIHN5c3RlbS1kZWZp bmVkIGRhdGEgaXRlbSBzaG91bGQgYWxzbyBleGlzdHMgaW4gPHJ1bm5pbmc+Lg0KDQpUaGVyZWZv cmUsIGlmIHN5c3RlbSBjb25maWd1cmF0aW9ucyBkbyBub3QgZXhpc3QgaW4gPHJ1bm5pbmc+LCB0 aGV5IHN0aWxsIG5lZWQgdG8gYmUgIGNvbmZpZ3VyZWQgaW4gPHJ1bm5pbmc+IG1hbnVhbGx5IGlu IG9yZGVyIGZvciBiZWluZyByZWZlcmVuY2VkLiBJbiB0aGlzIGNhc2UsIHRoZSBvcmlnaW5hbCBw dXJwb3NlIG9mIHByZWRlZmluaW5nIHNvbWUgc3lzdGVtIGNvbmZpZ3VyYXRpb25zIGZvciB1c2Vy IGNvbnZlbmllbmNlIGlzIGxvc3QuIFRoaXMgaXMgdGhlIHJlYXNvbiB3aHkgd2Ugd291bGQgbGlr ZSB0byBkZWZpbmUgc29tZSBtZWNoYW5pc20gaGVyZSB0byBzeW5jaHJvbml6ZSA8c3lzdGVtPiBp bnRvIDxydW5uaW5nPi4NCg0KDQpJIHNlZSBpbiBSRkMgODM0MiAiPHJ1bm5pbmc+IE1VU1QgYWx3 YXlzIGJlIGEgdmFsaWQgY29uZmlndXJhdGlvbiBkYXRhIHRyZWUsIGFzIGRlZmluZWQgaW4gU2Vj dGlvbiA4LjEgb2YgW1JGQzc5NTBd4oCdLg0KDQpCdXQgdGhlIHF1ZXN0aW9uIHJlbWFpbnMgaWYg aXQgaXMgcG9zc2libGUgZm9yIHRoZSBzeXN0ZW0gaXMgYWJsZSB0byB2YWxpZGF0ZSA8cnVubmlu Zz4gd2l0aG91dCwgZS5nLiwgZXhwYW5kaW5nIHRlbXBsYXRlcy4gIFRoZXJlIG1heSBiZSBhICds ZWFmcmVmJyBvciDigJhtdXN04oCZIGV4cHJlc3Npb24gc29tZXdoZXJlIHRoYXQgd2lsbCBmYWls IGJlY2F1c2UgdGhlIGV2YWx1YXRpb24gb2NjdXJzIHdpdGhvdXQgZXhwYW5kaW5nIGEgdGVtcGxh dGUgdGhhdCBzdXBwbGllcyB0aGUgbWlzc2luZyBwYXJ0cy4NCltRaXVmYW5nIE1hXSBPbiBjb25k aXRpb24gdGhhdCA8cnVubmluZz4gc2hvdWxkIGJlIHZhbGlkLCB0aGUgb3BlcmF0b3JzIHdpbGwg bmVlZCB0byByZXRyaWV2ZSBmcm9tIHRoZSA8aW50ZW5kZWQ+IG9yIDxvcGVyYXRpb25hbD4gdG8g Z2V0IHRoZSB0ZW1wbGF0ZS1leHBhbmRlZCBjb25maWd1cmF0aW9ucyBhbmQgdGhlbiBjcmVhdGUg dGhlbSBpbiB0aGUgPHJ1bm5pbmc+LCByaWdodD8NCk15IGZlZWxpbmcgaXMgdGhhdCBpdCBsb3Nl cyB0aGUgbWVhbmluZyBvZiBwcmVkZWZpbmluZyBhbmQgc2VlbXMgbm8gZGlmZmVyZW5jZXMgYmV0 d2VlbiBvcGVyYXRvci1kZWZpbmVkIGNvbmZpZ3VyYXRpb25zIGlmIG9wZXJhdG9ycyBoYXZlIHRv IGNyZWF0ZSBzeXN0ZW0gY29uZmlndXJlcyBpbiA8cnVubmluZz4gYmVmb3JlIHRoZXkgdXNlIHRo ZW0uIFNvIEkgYW0gYmVnaW5uaW5nIHRvIHRoaW5rLCBpZiBpdOKAmXMgcG9zc2libGUgdG8gZXhw YW5kIHRoZSBzeXN0ZW0tZGVmaW5lZCB0ZW1wbGF0ZSBkdXJpbmcgdGhlIGNvcHlpbmcgYmV0d2Vl biA8c3lzdGVtPiBhbmQgPHJ1bm5pbmc+Pw0KDQpJZiB0aGlzIGRyYWZ0IOKAnHVwZGF0ZXPigJ0g UkZDIDgzNDIgKE5NREEpLCB0aGVuIGl0IGNhbiBzdXBwbHkgYSBjbGFyaWZ5aW5nIHN0YXRlbWVu dCBhYm91dCB3aGF0IGl0IG1lYW5zIHRoYXQgIjxydW5uaW5nPiBNVVNUIGFsd2F5cyBiZSBhIHZh bGlkIGNvbmZpZ3VyYXRpb24gZGF0YSB0cmVl4oCdLiAgRWl0aGVyIHRoYXQsIG9yIGFuIEVycmF0 YSBpZiBpdOKAmXMgZGV0ZXJtaW5lZCB0aGF0IHRoZSBzdGF0ZW1lbnQgaXNu4oCZdCBjb3JyZWN0 Lg0KDQpZb3UgbWFrZSBhIGdvb2QgdGVjaG5pY2FsIHBvaW50LCBidXQgSSB0aGluayB0aGF0IHdl IHNob3VsZCAqd2FudCogdG8gYXZvaWQgaGF2aW5nIHRvIGNvcHkgPHN5c3RlbT4gKG9yIDxvcGVy YXRpb25hbD4pIGNvbmZpZ3VyYXRpb24gaW50byA8cnVubmluZz4gaWYgd2UgY2FuIGF2b2lkIGl0 LiAgQWdyZWVkPw0KW1FpdWZhbmcgTWFdIHRlbmQgdG8gYWdyZWUuIE1heWJlIHdlIHNob3VsZCB0 cnkgdG8gYXZvaWQgaXQsIHVubGVzcyB3ZSBoYXZlIHRvLg0KDQpGV0lXLCBhbHNvIGluIFJGQyA4 MzQyLCBTZWN0aW9uIDUuMS40LjoNCg0KDQogICA8aW50ZW5kZWQ+IGlzIHRpZ2h0bHkgY291cGxl ZCB0byA8cnVubmluZz4uICBXaGVuZXZlciBkYXRhIGlzIHdyaXR0ZW4NCg0KICAgdG8gPHJ1bm5p bmc+LCB0aGUgc2VydmVyIE1VU1QgYWxzbyBpbW1lZGlhdGVseSB1cGRhdGUgYW5kIHZhbGlkYXRl DQoNCiAgIDxpbnRlbmRlZD4uDQoNCg0KDQogICA8aW50ZW5kZWQ+IE1BWSBhbHNvIGJlIHVwZGF0 ZWQgaW5kZXBlbmRlbnRseSBvZiA8cnVubmluZz4gaWYgdGhlDQoNCiAgIGVmZmVjdCBvZiBhIGNv bmZpZ3VyYXRpb24gdHJhbnNmb3JtYXRpb24gY2hhbmdlcywgYnV0IDxpbnRlbmRlZD4gTVVTVA0K DQogICBhbHdheXMgYmUgYSB2YWxpZCBjb25maWd1cmF0aW9uIGRhdGEgdHJlZSwgYXMgZGVmaW5l ZCBpbiBTZWN0aW9uIDguMTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL3Jm Yzc5NTAjc2VjdGlvbi04LjE+DQoNCiAgIG9mIFtSRkM3OTUwXTxodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL3JmYzc5NTAjc2VjdGlvbi04LjE+Lg0KDQoNCg0KDQoNCg0KDQo+ IEkgYW0gd29uZGVyaW5nIGlmIHRoZXNlIGNvbmZpZ3VyYXRpb24gd2lsbCBwcmVzZW50IGluIHRo ZSA8b3BlcmF0aW9uYWw+ICh3aGljaCBjb250YWlucyBhbGwgdGhlIGNvbmZpZ3VyYXRpb24gYWN0 dWFsbHkgdXNlZCBieSB0aGUgZGV2aWNlKSBiZWZvcmUgdGhleeKAmXJlIHJlZmVyZW5jZWQuDQoN Cg0KDQpJIHRoaW5rIHRoYXQgaXQgd291bGQgZGVwZW5kIGluIHRoZSBzcGVjaWZpYyBzZXJ2ZXLi gJlzIGJlaGF2aW9yLCByZWdhcmRpbmcgaWYgKnVudXNlZCogcHJlZGVmaW5lIG9iamVjdHMgYXJl IHByZXNlbnQgaW4gPG9wZXJhdGlvbmFsPi4gIENlcnRhaW5seSB0aGUgdW51c2VkIG9iamVjdHMg d291bGQgbm90IGhhdmUgdG8gYmUgcHJlc2VudCBpbiA8b3BlcmF0aW9uYWw+LiAgSWYgSSB3ZXJl IGltcGxlbWVudGluZyB0aGUgc2VydmVyLCB0aGUgdW51c2VkIG9iamVjdHMgd291bGQgTk9UIGJl IHByZXNlbnQgaW4gPG9wZXJhdGlvbmFsPi4NCg0KW1FpdWZhbmcgTWFdIFllcywgaWYgdGhlIHBy ZWRlZmluZWQgc3lzdGVtIGNvbmZpZ3VyYXRpb25zIGlzIHVudXNlZCwgdGhlbiBJIGFsc28gdGVu ZCB0byBhZ3JlZSB0aGF0IHRoZXkgd291bGQgbm90IGJlIHByZXNlbnQgaW4gPG9wZXJhdGlvbmFs PiBidXQgbWF5IGFsc28gZGVwZW5kIG9uIHRoZSB2ZW5kb3IgaW1wbGVtZW50YXRpb24uDQoNCg0K WXVwLCB0aGlzIGlzIHRoZSBzYW1lIGNvbmNsdXNpb24gaXMgaW4gbXkgcmVzcG9uc2UgYWJvdmUu DQpbUWl1ZmFuZyBNYV0gOikNCg0KDQoNCg0KPiBJdCB3b3VsZCBiZSBnb29kIGlmIHdlIGNvdWxk IGRldGVybWluZSBpZiB0aGVyZSBhcmUgYW55IG90aGVyICJyZXNvdXJjZS1pbmRlcGVuZGVudOKA nSBjb25maWd1cmF0aW9uIGNhdGVnb3JpZXMgaGVyZS4NCg0KPiBbUWl1ZmFuZyBNYV0gRG8geW91 IHRoaW5rIHRoZXJlIGV4aXN0cyBjb25kaXRpb25hbCBzeXN0ZW0gY29uZmlndXJhdGlvbiAoaWYg dGhlIHByZWNlZGluZyBjb25maWd1cmF0aW9ucyB5b3UgbWVudGlvbmVkIGFib3ZlIGlzIG5vdCk/ IEZvciBleGFtcGxlLCBpZiBTU0ggaXMgZW5hYmxlZCBvbiBhIGRldmljZSwgU1NILXJlbGF0ZWQg a2V5cyBhcmUgYXV0b21hdGljYWxseSBnZW5lcmF0ZWQuIFN1Y2ggY29uZmlndXJhdGlvbnMgYXJl IGdlbmVyYXRlZCBhdCB0aGUgbW9tZW50IHdoZW4gYSBzcGVjaWFsIGZ1bmN0aW9uYWxpdHkgaXMg ZW5hYmxlZC4NCg0KDQoNCknigJltIHVuc3VyZSB3aGF0IHlvdSBtZWFuIGluIGdlbmVyYWwgYnkg ImNvbmRpdGlvbmFsIGNvbmZpZ3VyYXRpb27igJ0sIGJ1dCBJIGNhbiBzcGVhayB0byB5b3VyIHNw ZWNpZmljIGV4YW1wbGUuIFRob3VnaCBJIG11c3QgcHJlZmFjZSBteSBjb21tZW50cyB0aGF0IEkg aW1hZ2luZSB0aGVyZSBhcmUgYSBudW1iZXIgb2Ygd2F5cyBzZXJ2ZXJzIG1pZ2h0IGdvIGFib3V0 IGVuYWJsaW5nIGBzc2hkYC4gIFdoYXQgZm9sbG93cyBpcyBteSBwZXJzb25hbCB2aWV3LCBmb3Jn ZWQgYnkgYmVpbmcgYXJvdW5kIHN5c3RlbXMgZm9yIGF3aGlsZSAgOykNCg0KDQoNCkluIGdlbmVy YWw6DQoNCg0KDQogICAgICAgICAtIGBzc2hkYCBpcyBOT1QgZW5hYmxlZCBieSBkZWZhdWx0Lg0K DQogICAgICAgICAtIGBzc2hkYCBpcyBlbmFibGVkIHZpYSBhIGNvbmZpZ3VyYXRpb24ga25vYi4N Cg0KICAgICAgICAgLSB0aGUgU1NIIGhvc3Qga2V5IGlzIGR5bmFtaWNhbGx5IGdlbmVyYXRlZCB0 aGUgZmlyc3QgdGltZSBgc3NoZGAgaXMgZW5hYmxlZC4NCg0KICAgICAgICAgLSB0aGUgU1NIIGhv c3Qga2V5IGl0c2VsZiBpcyBpbiA8b3BlcmF0aW9uYWw+IChub3QgPHJ1bm5pbmc+KQ0KDQoNCg0K VGhpcyB2aWV3IGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgZmlyc3QgcGFyYWdyYXBoIGluIFNlY3Rp b24gMyBvZiB0aGUg4oCca2V5c3RvcmXigJ0gZHJhZnQgKHJlcHJvZHVjZWQgYmVsb3cpOg0KDQoN Cg0KICAgICAgICAgMy4gIFN1cHBvcnQgZm9yIEJ1aWx0LWluIEtleXMNCg0KDQoNCiAgICAgICAg ICAgIEluIHNvbWUgaW1wbGVtZW50YXRpb25zLCBhIHNlcnZlciBtYXkgc3VwcG9ydCBidWlsdC1p biBrZXlzLiAgQnVpbHQtDQoNCiAgICAgICAgICAgIGluIGtleXMgTUFZIGJlIHNldCBkdXJpbmcg dGhlIG1hbnVmYWN0dXJpbmcgcHJvY2VzcyBvciBiZSBkeW5hbWljYWxseQ0KDQogICAgICAgICAg ICBnZW5lcmF0ZWQgdGhlIGZpcnN0IHRpbWUgdGhlIHNlcnZlciBpcyBib290ZWQgb3IgYSBwYXJ0 aWN1bGFyIHNlcnZpY2UNCg0KICAgICAgICAgICAgKGUuZy4sIFNTSCkgaXMgZW5hYmxlZC4NCg0K DQoNCkFzIGEgY2xvc2luZyB0aG91Z2h0LCB0aGlzIG1vZGVsICh3aGljaCBJIHN0YXRlZCB1cGZy b250IG1heSBub3QgYmUgdW5pdmVyc2FsKSB3b3VsZCBoYXZlIG5vIHByZXNlbmNlLWluIG9yIGlu dGVyYWN0aW9uLXdpdGggPHN5c3RlbT7igKZ0aG91Z2gsIHBlcmhhcHMsIHRoZXJlIG1heSBiZSBz b21lIHByZWRlZmluZWQgdmFsdWVzIGZvciB3aGF0IGtleS1hbGdvcml0aG1zIGFuZC9vciBrZXkt bGVuZ3RocyB0byB1c2Ugd2hlbiBnZW5lcmF0aW5nIHRoZSBTU0ggaG9zdCBrZXkuLi4NCg0KW1Fp dWZhbmcgTWFdIEJ5IOKAnGNvbmRpdGlvbmFsIHN5c3RlbSBjb25maWd1cmF0aW9u4oCdLCBJIHdh cyBtZWFuaW5nIHNvbWUgb2YgdGhlIHN5c3RlbSBjb25maWd1cmF0aW9ucyBhcmUgbm90IGdlbmVy YXRlZCBpbW1lZGlhdGVseSBhZnRlciB0aGUgZGV2aWNlIGlzIHBvd2VyZWQgb24uIEluc3RlYWQs IHRoZXkgYXJlIGdlbmVyYXRlZCB3aGVuIGEgc3BlY2lmaWMgY29uZGl0aW9uIGlzIHNhdGlzZmll ZCBkdXJpbmcgdGhlIGRldmljZSBydW5uaW5nKGUuZy4sIGEgZnVuY3Rpb25hbGl0eSBpcyBlbmFi bGVkIGR1ZSB0byBzb21lIGNsaWVudCBjb25maWd1cmF0aW9ucykuIEkgYW0gbm90IHN1cmUgaWYg aXQgcmVhbGx5IGV4aXN0cywgbWF5YmUgbm90LCBqdXN0IHRyeSB0byBleHBsb3JlIHRoZSBwb3Nz aWJpbGl0aWVzIG9mIHZhcmlvdXMgcmVzb3VyY2UtaW5kZXBlbmRlbnQgc3lzdGVtIGNvbmZpZ3Vy YXRpb25zLjopDQoNClRvIHRoaXMgcG9pbnQgSSBhZ3JlZS4uYXMgZG9lcyBSRkMgODM0MiAoTk1E QSksIFNlY3Rpb24gNS4zLjMuOg0KDQoNCiAgIFNvbWV0aW1lcywgcmVzb3VyY2VzIGFyZSBjb250 cm9sbGVkIGJ5IHRoZSBkZXZpY2UgYW5kIHRoZQ0KDQogICBjb3JyZXNwb25kaW5nIHN5c3RlbS1j b250cm9sbGVkIGRhdGEgYXBwZWFycyBpbiAoYW5kIGRpc2FwcGVhcnMgZnJvbSkNCg0KICAgPG9w ZXJhdGlvbmFsPiBkeW5hbWljYWxseS4gIElmIGEgc3lzdGVtLWNvbnRyb2xsZWQgcmVzb3VyY2Ug aGFzDQoNCiAgIG1hdGNoaW5nIGNvbmZpZ3VyYXRpb24gaW4gPGludGVuZGVkPiB3aGVuIGl0IGFw cGVhcnMsIHRoZSBzeXN0ZW0gd2lsbA0KDQogICB0cnkgdG8gYXBwbHkgdGhlIGNvbmZpZ3VyYXRp b247IHRoaXMgY2F1c2VzIHRoZSBjb25maWd1cmF0aW9uIHRvDQoNCiAgIGFwcGVhciBpbiA8b3Bl cmF0aW9uYWw+IGV2ZW50dWFsbHkgKGlmIGFwcGxpY2F0aW9uIG9mIHRoZQ0KDQogICBjb25maWd1 cmF0aW9uIHdhcyBzdWNjZXNzZnVsKS4NCg0KW1FpdWZhbmcgTWFdIFNlZSBhYm92ZSwgYXMgSSBz dW1tYXJpemVkIGFzIHRoZSBzeXN0ZW0gY29uZmlndXJhdGlvbnMgdGhhdCBpcyBnZW5lcmF0ZWQg Y29uZGl0aW9uYWxseSBkdXJpbmcgdGhlIGRldmljZSBydW5uaW5nLg0KDQoNCg0KRmlyc3RseSwg SSBhZ2FpbiBoYXZlIHRvIHByZWZhY2UgbXkgY29tbWVudCB0aGF0IHRoZXJlIGFyZSBsaWtlbHkg bWFueSB3YXlzIHRoYXQgdGVtcGxhdGluZyBtZWNoYW5pc21zIGNhbiBiZSBkZWZpbmVkLiAgICBC dXQsIGluIGdlbmVyYWwsIG9uY2UgYSB0ZW1wbGF0aW5nIG1lY2hhbmlzbSBoYXMgYmVlbiBkZWZp bmVkLCB0aGVuIGl0IHN0YW5kcyB0byByZWFzb24gdGhhdCB0ZW1wbGF0ZXMgY291bGQgYmUgZGVm aW5lZCBlaXRoZXIgaW4gPHJ1bm5pbmc+IChieSBvcGVyYXRvcnMpIG9yIGluIDxzeXN0ZW0+IChi eSB0aGUgbWFudWZhY3R1cmVyKS4gIEluIG9uZSBpbXBsZW1lbnRhdGlvbiBJ4oCZbSBmYW1pbGlh ciB3aXRoLCB0aGUgdGVtcGxhdGVzIGFyZSBvYmplY3RzIHRoYXQgYXJlIHJlZmVyZW5jZWQvcGFy YW1ldGVyaXplZCBieSBvdGhlciBwYXJ0cyBvZiB0aGUgY29uZmlndXJhdGlvbi4gIChTYW1lIGFz IHdpdGggdGhlIHByZWRlZmluZWQgb2JqZWN0cyBkaXNjdXNzaW9uIGFib3ZlLikNCg0KDQoNClRv IGFuc3dlciB5b3VyIHF1ZXN0aW9uczoNCg0KDQoNCjEpIFllcywgaXQgaXMgbXkgb3BpbmlvbiB0 aGF0ICphY3RpdmF0ZWQqIHRlbXBsYXRlcyBpbiA8c3lzdGVtPiB3aWxsIGJlIGV4cGFuZGVkIGFu ZCBwcmVzZW50IGluIDxpbnRlbmRlZD4uDQoNCg0KDQoyKSBJIHdvdWxkIG5ldmVyIHN1Z2dlc3Qg dGhhdCB0aGUgc3lzdGVtLWRlZmluZWQgdGVtcGxhdGVzIGFyZSBwcmVzZW50IGluIDxydW5uaW5n PiwgdGhvdWdoIHRoZXkgbWF5IGJlIHJlZmVyZW5jZWQvcGFyYW1ldGVyaXplZCBieSBjb25maWcg aW4gPHJ1bm5pbmc+Lg0KDQoNCg0KMykgaWYgYSBjb25maWctdGVtcGxhdGUgaXMgY29uZmlndXJl ZCBpbiA8cnVubmluZz4gKGkuZS4sIGl0IGlzIG9wZXJhdG9yLWRlZmluZWQpIHRoZW4sIHllcywg dGhlIGV4cGFuZGVkIGNvbmZpZ3VyYXRpb24gaW4gPGludGVuZGVkPiBpcyAiY2xpZW50IGNvbmZp Z3VyYXRpb27igJ0gKG5vdGUsICJjbGllbnQgY29uZmlndXJhdGlvbuKAnSBpcyBub3QgYSBmb3Jt YWwgdGVybSkuICBUaGF0IHNhaWQsIGl0IHNlZW1zIGZhaXIgdG8gc2F5IHRoYXQgYSB0ZW1wbGF0 ZSBkZWZpbmVkIGluIDxzeXN0ZW0+IGFuZCB0aGVuIHJlZmVyZW5jZWQgYnkgImNsaWVudCBjb25m aWd1cmF0aW9u4oCdIGluIDxydW5uaW5nPiBpcyBhbHNvIGV4cGFuZGVkIGFzICJjbGllbnQgY29u ZmlndXJhdGlvbuKAnSBpbiA8aW50ZW5kZWQ+Lg0KDQoNCg0KNCkgSSBkb27igJl0IG5vdCB1bmRl cnN0YW5kIHlvdXIgbGFzdCBzZW50ZW5jZSwgdGhhdCB0aGUgZXhwYW5zaW9uIG9mIDxzeXN0ZW0+ IHRlbXBsYXRlcyBhcmUgb25seSBwcmVzZW50IGluIDxvcGVyYXRpb25hbD4uICBNYXliZSB5b3Xi gJlyZSBzYXlpbmcgc29tZXRoaW5nIHN1YnRsZSwgZS5nLiwgdGhhdCBzZXJ2ZXJzIGN1cnJlbnRs eSBkb27igJl0IHN1cHBvcnQgR0VUIG9uIDxpbnRlbmRlZD4uICBCdXQsIGluIHRoZW9yeSwgdGhl IGV4cGFuc2lvbiBvZiA8c3lzdGVtPiB0ZW1wbGF0ZXMgc2hvdWxkIChJTU8pIGJlIHByZXNlbnQg aW4gPGludGVuZGVkPiwgc28gdGhhdCB0aGV5IG1heSBiZSBzdWJqZWN0IHRvIHZhbGlkYXRpb24u ICAgT2YgY291cnNlLCBhbGwgdGhlIDxpbnRlbmRlZD4gY29uZmlndXJhdGlvbiAod2hldGhlciBv cmlnaW5hdGluZyBpbiA8cnVubmluZz4gb3IgPHN5c3RlbT4pIHRoYXQgaXMgc3VjY2Vzc2Z1bGx5 IOKAnGFwcGxpZWTigJ0gd2lsbCBhbHNvIGJlIHByZXNlbnQgaW4gPG9wZXJhdGlvbmFsPi4NCg0K W1FpdWZhbmcgTWFdIEFzc3VtZSB0aGF0IHRoZXJlIGlzIG5vIDxzeXN0ZW0+IGFuZCB0aGlzIHdv cmssIHRoZSBleHBhbnNpb24gb2Ygc3lzdGVtIHRlbXBsYXRlcyBhcmUgb25seSBwcmVzZW50IGlu IDxvcGVyYXRpb25hbD4uIEJlY2F1c2UgdGhpcyBpcyBjb21wYXRpYmxlIHdpdGggc3lzdGVtIGNv bmZpZ3VyYXRpb24gZGVmaW5pdGlvbiBpbiBOTURBLg0KDQpCdXQgaWYgc3lzdGVtIGNvbmZpZ3Vy YXRpb25zIGFyZSBvbmx5IHByZXNlbnQgaW4gPG9wZXJhdGlvbmFsPiwgdGhlIHByZWRlZmluZWQg c3lzdGVtIGNvbmZpZ3VyYXRpb25zIHN0aWxsIG5lZWQgdG8gYmUgcmV0cmlldmVkIGFuZCBjcmVh dGVkIGludG8gPHJ1bm5pbmc+IGV4cGxpY2l0bHkgd2hlbiBiZWluZyByZWZlcmVuY2VkLiBJIHRo aW5rIHdl4oCZdmUgcmVhY2hlZCBhbiBhZ3JlZW1lbnQgb24gdGhlIG5lZWQgZm9yIDxzeXN0ZW0+ IHRvIGV4aXN0LCBhbmQgb3VyIG1haW4gcG9pbnQgb2YgZGlzYWdyZWVtZW50IGlzIHdoZXRoZXIg PHN5c3RlbT4gc2hvdWxkIGJlIGNvcGllZCBpbnRvIDxydW5uaW5nPi4gWW91ciBwb2ludCBpcyB0 aGF0IGJlaW5nIG1lcmdlZCBpbnRvIDxpbnRlbmRlZD4gaXMgZW5vdWdoIHRvIG1ha2Ugc3VyZSBh IHN1Y2Nlc3MgdmFsaWRhdGlvbi4gQnV0IG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgcmVm ZXJlbmNlZCBzeXN0ZW0gY29uZmlndXJhdGlvbiBkYXRhIGl0ZW0gbXVzdCBhbHNvIGV4aXN0IGlu IHRoZSA8cnVubmluZz4gdG8gb2JleSB0aGUgbW9kZWwgY29uc3RyYWludHMuDQoNClllcywgSSBi ZWxpZXZlIHRoYXQgeW91IHByb3ZpZGVkIGFuIGFjY3VyYXRlIGRlc2NyaXB0aW9uIG9mIHRoZSBk aWZmZXJlbmNlIGluIG91ciBvcGluaW9ucy4gIFBlciBteSBlYXJsaWVyIHJlc3BvbnNlLCB5b3Ug bWFrZSBhIHZhbGlkIHRlY2huaWNhbCBwb2ludCwgbXkgZ29hbCBpcyB0byB3YWl2ZSB0aGF0IGlu dGVycHJldGF0aW9uIHRvIHRoZSBzaWRlIHNvIHRoYXQgYSBzaW1wbGVyIHNvbHV0aW9uIGNhbiBl bWVyZ2UuICBJdCB3b3VsZCBiZSBnb29kIHRvIGdldCBvdGhlciBvcGluaW9ucyBvbiBsaXN0LCBv dGhlcndpc2Ugd2XigJlsbCB0YWtlIGl0IGludG8gdGhlIG1lZXRpbmcuDQpbUWl1ZmFuZyBNYV0g T0suICBIb3BlZnVsbHkgc29tZW9uZSBlbHNlIHdvdWxkIHNoYXJlIHNvbWUgb3BpbmlvbnMgaGVy ZS4gT3RoZXJ3aXNlIGxldOKAmXMgdGFrZSB0aGlzIGludG8gdGhlIElFVEYgbWVldGluZy4NCg0K W0JUVywgaW4ga2VlcGluZyB3aXRoIHRoaXMgdGhyZWFkIG1vdmluZyBmcm9tIHRoZSBORVRDT05G IHRvIHRoZSBORVRNT0QgbWFpbGluZyBsaXN0cywgd291bGQgaXQgbWFrZSBzZW5zZSB0byBtb3Zl IHRoZSBJRVRGIDExMSBwcmVzZW50YXRpb24gc2xvdCBmcm9tIE5FVENPTkYgdG8gTkVUTU9EIHRv bz8gIEkgdGhpbmsgaXQgZG9lcyBhbmQsIGZ1cnRoZXIsIGl0IHdvdWxkIGhlbHAgd2l0aCBzY2hl ZHVsaW5nIChORVRDT05GIGlzIG92ZXIsIE5FVE1PRCBpcyB1bmRlcikuICBXb3VsZCB5b3UgYmUg b2theSB3aXRoIHRoaXM/ICAgQUQgUm9iIGFuZCB0aGUgTkVUQ09ORiBjaGFpcnMgZGlzY3Vzc2Vk IHRoaXMgbW9ybmluZywgYW5kIHRoaW5rIGl0J3Mgb2theSwgYnV0IHdvdWxkIHN0aWxsIG5lZWQg dG8gY29uZmlybSB3aXRoIHRoZSBORVRNT0QgY2hhaXJzLl0NCltRaXVmYW5nIE1hXSBJIGFtIGhh cHB5IHdpdGggdGhlIHByb3Bvc2FsLCBpZiBpdOKAmXMgYWxzbyBva2F5IGZvciBORVRNT0QgY2hh aXJzOi0pLiBJIGhhdmUgc2VudCBhbiBlbWFpbCB0byB0aGUgTkVUTU9EIGNoYWlycyB0byByZXF1 ZXN0IHRvIG1vdmUgdGhpcyBwcmVzZW50YXRpb24gc2xvdCBmcm9tIE5FVENPTkYgdG8gTkVUTU9E Lg0KQSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQgd2lsbCBhbHNvIGJlIHN1Ym1pdHRlZCB0byBO RVRNT0Qgd2hlbiB0aGUgZHJhZnQtc3VibWl0dGluZyB3aW5kb3cgcmVvcGVucy4NCg0KDQoNCiA8 YmlnIHNuaXA+DQoNCj4gSeKAmW0gYmVnaW5uaW5nIHRvIHRoaW5rIHRoYXQ6DQoNCj4gwrcgICAg ICAgICBhdXRvLWNvcHlpbmcgaW50byA8cnVubmluZz4gaXMgbGlrZWx5IG5ldmVyIGEgZ29vZCBp ZGVhLCBiZWNhdXNlIGl0IHZpb2xhdGVzIHRoZSBkZWZpbml0aW9uIG9mIDxydW5uaW5nPg0KDQo+ IFtRaXVmYW5nIE1hXSBJIGFtIHF1aXRlIGF3YXJlIHRoYXQgZGlmZmVyZW50IGRhdGFzdG9yZXMg aW4gTk1EQSByZXByZXNlbnRzIGRpZmZlcmVudCB2aWV3cyBvZiBkYXRhIG5vZGVzLiAgQW5kIDxy dW5uaW5nPiByZXByZXNlbnRzIGEgY29uZmlndXJhdGlvbiBkYXRhc3RvcmUgaG9sZGluZyB0aGUg Y3VycmVudCBjb25maWd1cmF0aW9uIG9mIHRoZSBkZXZpY2UuDQoNCj4gU2hvdWxkIHdlIGNvbnNp ZGVyIHN5c3RlbSBjb25maWd1cmF0aW9uIGFsc28gYmUgcGFydCBvZiBjdXJyZW50IGNvbmZpZ3Vy YXRpb24gb2YgdGhlIGRldmljZT8gRnJvbSBteSBwZXJzcGVjdGl2ZSwgdGhlIGRpZmZlcmVuY2Ug YmV0d2VlbiBzeXN0ZW0gY29uZmlndXJhdGlvbiBhbmQgIGNsaWVudC1jb25maWd1cmF0aW9uIGxp ZXMgb25seSBpbiB3aG8gcHJvdmlkZXMgaXQuDQoNCg0KDQo8cnVubmluZz4gaG9sZHMgdGhlIGN1 cnJlbnQgKm9wZXJhdG9yLXNwZWNpZmllZCogY29uZmlndXJhdGlvbiBvZiB0aGUgZGV2aWNlLiAg U3lzdGVtLXByb3ZpZGVkIGNvbmZpZ3VyYXRpb24gaXMgTk9UIHNwZWNpZmllZCBieSBvcGVyYXRv cnMgKHRob3VnaCBzeXN0ZW0tZGVmaW5lZCBvYmplY3RzIG1heSBiZSByZWZlcmVuY2VkIGJ5IG9w ZXJhdG9yLXNwZWNpZmllZCBjb25maWcgaW4gPHJ1bm5pbmc+KS4gICBJIGJlbGlldmUgdGhhdCB0 aGlzIGFycmFuZ2VtZW50IGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgZGVmaW5pdGlvbiBvZiA8cnVu bmluZz4uICBBZ3JlZWQ/DQoNCltRaXVmYW5nIE1hXSBZZXMuIEFjdHVhbGx5IHdlIGFyZSBub3Qg dHJ5aW5nIHRvIHZpb2xhdGUgdGhlIHByaW5jaXBsZXMgb2YgTk1EQSBhbmQgdGhlIGRlZmluaXRp b24gb2YgPHJ1bm5pbmc+LiAgVGhlIGlzc3VlIHdlIHRyeSB0byByZXNvbHZlIGhlcmUgaXMgdGhh dCBzeXN0ZW0gY29uZmlndXJhdGlvbnMgY2Fubm90IGJlIHVzZWQocmVmZXJlbmNlZCBvciBvdmVy d3JpdHRlbikgYnkgdGhlIG9wZXJhdG9ycyBkaXJlY3RseSBhbmQgbmVlZCB0byBiZSBjcmVhdGVk IGludG8gPHJ1bm5pbmc+IGV4cGxpY2l0bHkuIFRoaXMgYWN0dWFsbHkgbG9zZXMgdGhlIG1lYW5p bmcgb2Yg4oCccHJlZGVmaW5pbmcgYW5kIGJyaW5naW5nIGNvbnZlbmllbmNl4oCdLiBJZiBhdXRv LWNvcHlpbmcgaXMgbm90IGEgZ29vZCBpZGVhLCB3aGF0IGRvIHlvdSB0aGluayBhYm91dCBkZWZp bmluZyBhbiBSUEMgb3BlcmF0aW9uIGZvciB0aGUgb3BlcmF0b3JzIHRvIGRvIHRoZSBjb3B5KHdo aWNoIGlzIGFsc28gd2hhdCBSb2Igc3VnZ2VzdHMgYXQgdGhlIG1lZXRpbmcpPw0KDQpJZiB3ZSBo YXZlIHRvIGNvcHkgaW50byA8cnVubmluZz4sIHRoZW4gSSB0aGluayB0aGF0IEkgYWdyZWUgYW4g UlBDICg8ZWRpdC1jb25maWc+Pykgd291bGQgYmUgYmV0dGVyLg0KW1FpdWZhbmcgTWFdIEZyb20g bXkgcGVyc3BlY3RpdmUsIDxlZGl0LWNvbmZpZz4gaXMgZmVhc2libGUgYnV0IG5vdCBlZmZpY2ll bnQgYmVjYXVzZSBvcGVyYXRvcnMgc3RpbGwgbmVlZCB0byByZXRyaWV2ZSA8c3lzdGVtPi88b3Bl cmF0aW9uYWw+IGZpcnN0bHkuIElmIHdlIGNvdWxkIGRlZmluZSBhIFJQQyB0byBjb3B5IHRoZSBl bnRpcmUgPHN5c3RlbT4gaW50byA8cnVubmluZz4sIGl0IHNlZW1zIG1vcmUgY29udmVuaWVudCBm b3Igb3BlcmF0b3JzLiBIb3dldmVyLCBzb21lIHN5c3RlbSBjb25maWd1cmF0aW9ucyB3aGljaCBh cmUgbm90IGdvaW5nIHRvIGJlIHJlZmVyZW5jZWQgb3IgbW9kaWZpZWQgbWF5IGFsc28gYmUgY29w aWVkIGludG8gPHJ1bm5pbmc+LiBJIGRvbid0IGhhdmUgYSBzdHJvbmcgZmVlbGluZyBhYm91dCB3 aGljaCBvbmUgaXMgcHJlZmVycmVkLiBBbnl3YXksIHdlIG5lZWQgdG8gZmlndXJlIG91dCB3aGV0 aGVyIGl0IHdvdWxkIGJlIGZpbmUgZm9yIDxydW5uaW5nPiB0byBtaXNzaW5nIHJlZmVyZW5jZWQg c3lzdGVtIGNvbmZpZ3VyYXRpb25zLg0KDQpZb3UgbWVudGlvbiDigJxvdmVyd3JpdHRlbuKAnSBi eSB0aGUgb3BlcmF0b3JzPyAgV2h5IHdvdWxkbuKAmXQgdGhlIG9wZXJhdG9ycyBqdXN0IGRlZmlu ZSB0aGVpciBvd24/ICBGb3IgaW5zdGFuY2UsIGlmIHRoZXkgZG9u4oCZdCBsaWtlIHRoZSB2ZW5k b3LigJlzIOKAnHZlbmRvci1mb29iYXLigJ0gb2JqZWN0LCB0aGV5IGNvdWxkIGNvcHkvcGFzdGUv ZWRpdCB0aGVpciBvd24g4oCcbXktZm9vYmFy4oCdIG9iamVjdCB3aXRoIHRoZSB2YWx1ZXMgbmVl ZGVkLCB5ZXM/DQpbUWl1ZmFuZyBNYV0gWWVzLCBkZWZpbmluZyB0aGVpciBvd24gd291bGQgYmUg b2theS4gQnkgb3ZlcndyaXRpbmcsIEkgbWVhbiBzb21ldGltZXMgdGhlIG9wZXJhdG9ycyB3b3Vs ZCBsaWtlIHRvIG1vZGlmeSB0aGUgc3BlY2lmaWMgc3lzdGVtIGNvbmZpZ3VyYXRpb24sIGUuZy4s IHRoZSBNVFUgdmFsdWUgb2YgYSBzcGVjaWZpZWQgaW50ZXJmYWNlKGlkZW50aWZpZWQgYnkgaXRz IG5hbWUpLg0KSWYgdGhlIG9wZXJhdG9ycyB3YW50IHRvIG1vZGlmeSB0aGUgc3lzdGVtIGNvbmZp Z3VyYXRpb25zLCB0aGVyZSBpcyBubyB3YXkgYnV0IHJlZGVmaW5lIHRoZW0gaW4gPHJ1bm5pbmc+ Lg0KDQoNCkJlc3QgUmVnYXJkcywNClFpdWZhbmcgTWENCg0KDQoNCg0KDQoNCg0KDQo+IMK3ICAg ICAgICAgaGF2aW5nIGluIDxvcGVyYXRpb25hbD4gZG9lc27igJl0IG1ha2Ugc2Vuc2UsIHNpbmNl IHRoZSB0d2Vha3Mgd291bGRu4oCZdCBnbyB0aHJ1IDxydW5uaW5nPiAtLT4gPGludGVuZGVkPiB2 YWxpZGF0aW9uLg0KDQo+DQoNCj4gSeKAmW0gd29uZGVyaW5nIGlmIGEgbW9kZWwgbGlrZSBiZWxv dyB3b3VsZCB3b3JrIGZvciBldmVyeW9uZSAtIHRob3VnaHRzPw0KDQo+IFtRaXVmYW5nIE1hXSA8 aW50ZW5kZWQ+IHJlcHJlc2VudHMgdGhlIGNvbmZpZ3VyYXRpb24gYWZ0ZXIgYWxsIGNvbmZpZ3Vy YXRpb24gdHJhbnNmb3JtYXRpb25zIHRvIDxydW5uaW5nPiBoYXZlIGJlZW4gcGVyZm9ybWVkLCBz byBJIHRoaW5rIGl0IGlzIG9ubHkgY291cGxlZCB0byA8cnVubmluZz4uDQoNCj4gQW55d2F5LCB0 aGUgPHN5c3RlbT4gc2hvdWxkIGFsc28gaW50ZXJhY3RzIHdpdGggPG9wZXJhdGlvbmFsPi4gIEFn cmVlZD8NCg0KDQoNCkkgZG9u4oCZdCBhZ3JlZSB0aGF0IDxpbnRlbmRlZD4gbXVzdCBvbmx5IGJl IGNvdXBsZWQgdG8gPHJ1bm5pbmc+LiAgU3BlY2lmaWNhbGx5LCBJIHRoaW5rIHRoYXQgaXQgaXMg b2theSAoY29tcGF0aWJsZSB3aXRoIE5NREEpIHRvIGRlZmluZSBhIDxzeXN0ZW0+IHRoYXQgYWxz byBpbXBhY3RzIDxpbnRlbmRlZD4uICAgVGhpcyBpcyB0aGUgb25seSAoSU1PKSBzYW5lIGFwcHJv YWNoLCBhcyBpdCBlbmFibGVzIHRoZSBjb21iaW5hdGlvbiA8cnVubmluZz4gKyA8c3lzdGVtPiB0 byBiZSB2YWxpZGF0ZWQuDQoNCltRaXVmYW5nIE1hXSBQbGVhc2Ugc2VlIGFib3ZlLiBJZiA8cnVu bmluZz4gaXMgT0sgdG8gbWlzcyByZWZlcmVuY2VkIHN5c3RlbSBjb25maWd1cmF0aW9uLCB5b3Vy IHByb3Bvc2FsIG1ha2VzIHNlbnNlIHRvIG1lLg0KDQpBY2suDQoNCg0KDQoNCiBCZXN0IFJlZ2Fy ZHMsDQoNClFpdWZhbmcgTWENCg0KDQpLZW50IC8vIGNvbnRyaWJ1dG9yDQo= --_000_add2ee3bb9094e1da6a3160824d5fdffhuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0 UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7 DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBj bTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC8 5byPIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCDpooTorr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHls ZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE2OTYwNzYy ODE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE1MzY0 NjM5ODIgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5I aSwgS2VudCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGxlYXNlIHNlZSBteSByZXBseSBpbmxpbmUuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBLZW50IFdhdHNlbiBbbWFpbHRvOmtlbnQmIzQzO2lldGZAd2F0c2VuLm5ldF0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bHkgMTYsIDIwMjEgMjo1NSBBTTxicj4NCjxi PlRvOjwvYj4gbWFxaXVmYW5nIChBKSAmbHQ7bWFxaXVmYW5nMUBodWF3ZWkuY29tJmd0Ozxicj4N CjxiPkNjOjwvYj4gbmV0bW9kQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0 bW9kXSBzeXN0ZW0gY29uZmlndXJhdGlvbiBzeW5jIG1lY2hhbmlzbTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPkhpJm5ic3A7UWl1ZmFuZyw8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBbc25pcF08L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlRoZSBxdWVz dGlvbiBpcyBpZiB0aGUgc2VydmVyIGltcGxlbWVudGF0aW9uIHBydW5lcyBkYW5nbGluZy91bnVz ZWQgb2JqZWN0cyB3aGVuICZsdDtpbnRlbmRlZCZndDsgaXMgYXBwbGllZCwgdXBkYXRpbmcgJmx0 O29wZXJhdGlvbmFsJmd0Oy4gJm5ic3A7TXkgYXNzdW1wdGlvbiBpcyB0aGF0IHRoZSBzZXJ2ZXIg d2lsbCBkaXNjYXJkIGFueSBvYmplY3QgdGhhdCBkb2VzbuKAmXQgYWN0dWFsbHkgaW1wYWN0DQog dGhlIHJ1bm5pbmcgY29uZmlndXJhdGlvbiBvZiB0aGUgc3lzdGVtIChpLmUuLCB2YWx1ZXMgYXJl IGNvbnN1bWVkIGJ5IHRoZSB1bmRlcmx5aW5nIG9wZXJhdGluZyBzeXN0ZW0sIGRyaXZlcnMsIGV0 Yy4pLiAmbmJzcDtUaHVzbHksIGl0IGlzIG15IG9waW5pb24gdGhhdCBvbmx5IHRoZSByZWZlcmVu Y2VkIG9iamVjdHMgYXJlIGFwcGxpZWQuICZuYnNwO0hlbmNlIHdoeSwgdG8gYW5zd2VyIHlvdXIg bGFzdCBxdWVzdGlvbiwgSSB3cm90ZSB0aGF0IHRoZXNlIGNvbmZpZ3VyYXRpb25zDQogKG1hbnVm YWN0dXJlci1kZWZpbmVkIG9iamVjdHMpIGFyZSBub3QgYXBwbGllZCBpbW1lZGlhdGVseSBidXQg b25seSBhZnRlciB0aGV5IGFyZSByZWZlcmVuY2VkLiAmbmJzcDtNYWtlcyBzZW5zZT88bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5bUWl1ZmFuZyBNYV0gWWVzLCB0cnkgdG8gc3VtIHVwIG91ciBkaXNjdXNzaW9u IGFib3V0IHRoZSBjYXRlZ29yaWVzIG9mIHRoZSBzeXN0ZW0gY29uZmlndXJhdGlvbjo8bzpwPjwv bzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3lt Ym9sO2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGh5c2lj YWwtcmVzb3VyY2UtZGVwZW5kZW50LS0mZ3Q7IHdoZXRoZXIgdGhpcyBzb3J0IG9mIHN5c3RlbSBj b25maWd1cmF0aW9uIGV4aXN0cyBpbiAmbHQ7c3lzdGVtJmd0OyBkZXBlbmRlbnRzIG9uIGlmIHRo ZSBwaHlzaWNhbCByZXNvdXJjZSBpcyBwcmVzZW50KGUuZy4sDQogcGh5c2ljYWwgaW50ZXJmYWNl KS48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWlu ZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6 IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QaHlzaWNhbC1yZXNvdXJj ZS1pbmRlcGVuZGVudC0tJmd0O3doaWNoIGlzIHByb3ZpZGVkIGJ5IHRoZSBkZXZpY2Ugc3lzdGVt PC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEiPg0K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+bzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkZ1cnRoZXIgY2xhc3NpZmlj YXRpb24gZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2Yg4oCcYXBwbGllZOKAnSB0aW1lKGRlcGVuZGVu dHMgb24gd2hldGhlciB0aGUgc3lzdGVtIGNvbmZpZ3VyYXRpb24gaW1wYWN0cyB0aGUgcnVubmlu ZyBvZiB0aGUgc3lzdGVtKTwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MCBsZXZlbDMgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+wqc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Db25maWcgdGhhdCBpcyBhcHBs aWVkIGltbWVkaWF0ZWx5KGUuZy4sIHRoZSBsb29wYmFjaywgdGhlIHByZWRlZmluZWQgbWluaW11 bSBsZW5ndGggb2YgcGFzc3dvcmTigKYpPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21z by1saXN0OmwwIGxldmVsMyBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CpzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNvbmZpZyB0aGF0 IGlzIGFwcGxpZWQgb25seSBhZnRlciBiZWluZyByZWZlcmVuY2VkIGJ5IG90aGVyIGNvbmZpZ3Mo ZS5nLCBkZWZpbml0aW9ucyBmb3IgYXBwbGljYXRpb25zIGZ0cC90ZnRw4oCmKTwvc3Bhbj48L2k+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPm88c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5GdXJ0aGVyIGNsYXNzaWZpY2F0aW9uIGZyb20g dGhlIHBlcnNwZWN0aXZlIG9mIGdlbmVyYXRpb24gdGltZTwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7dGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDMgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6 IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wqc8c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5D b25maWcgdGhhdCBpcyBnZW5lcmF0ZWQgdW5jb25kaXRpb25hbGx5IGF0IGVhY2ggYm9vdCB0aW1l KGUuZywgbG9vcGJhY2ssIHByZWRlZmluZWQgbWluaW11bSBsZW5ndGggb2YgcGFzc3dvcmQsIGZ0 cC90ZnRw4oCmKTwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZl bDMgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+wqc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Db25maWcgdGhhdCBpcyBnZW5lcmF0ZWQg Y29uZGl0aW9uYWxseSBkdXJpbmcgdGhlIGRldmljZSBydW5uaW5nKGUuZy4sIHN5c3RlbS1nZW5l cmF0ZWQgbG9jYWwtcG9ydCBhbmQgcmVtb3RlLXBvcnQgZm9yIGEgbmV3IGVzdGFibGlzaGVkIEJH UCBjb25uZWN0aW9uKTwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPktlZXAgaW4gbWluZCB0aGF0IHdoYXQgaXMgZGVzY3JpYmVkIGFib3ZlIGlzIGp1c3Qgb25l IGFzcGVjdCBvZiB3aGF0IGNhbiBiZSBpbiAmbHQ7c3lzdGVtJmd0Oy4gJm5ic3A7SW4gYWRkaXRp b24gdG8gZGVmaW5pbmcgcmVmZXJlbmNlLWFibGUgb2JqZWN0cywgJmx0O3N5c3RlbSZndDsgY2Fu IGFsc28gZGVmaW5lL2FwcGx5IGNvbmZpZ3VyYXRpb24gaW1tZWRpYXRlbHkgKGUuZy4sIHRoZSBs b29wYmFjaw0KIGludGVyZmFjZSkuICZuYnNwO1RoYXQgaXMsIGNvbmZpZ3VyYXRpb24gbm90IGRv ZXMgbm90IGhhdmUgdG8gYmUgcmVmZXJlbmNlZCBpbiBvcmRlciB0byBiZWNvbWUgYWN0aXZhdGVk LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPltRaXVmYW5nIE1hXSBOb3RlZC48L3NwYW4+PC9pPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6IzIxMjUyOSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDo3Mi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij5Ob3RlIHRoYXQsICZs dDtydW5uaW5nJmd0OyBieSBpdHNlbGYgd291bGQgbm90IHBhc3MgdmFsaWRhdGlvbiwgZHVlIHRv IG1pc3NpbmcgbGVhZnJlZnMuJm5ic3A7IFRoYW5rZnVsbHksIE5NREEgbmV2ZXIgc2F5cyB0aGF0 IHZhbGlkYXRpb24gcnVucyBvbiAmbHQ7cnVubmluZyZndDsuJm5ic3A7IEJ1dCBvbmNlICZsdDty dW5uaW5nJmd0OyBhbmQgJmx0O3N5c3RlbSZndDsgaGF2ZSBiZWVuIG1lcmdlZCwgdG8gYmVjb21l ICZsdDtpbnRlbmRlZCZndDssIHRoZSByZXN1bHQgZG9lcyBwYXNzIHZhbGlkYXRpb24uPC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7YmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gW1FpdWZhbmcgTWFdIFRoZSByZWZlcmVuY2Vk IGluc3RhbmNlIG11c3QgYWxzbyBleGlzdCBmb3IgdGhlIGRhdGEgdG8gYmUgdmFsaWQgc2luY2Ug dGhlIHJlcXVpcmUtaW5zdGFuY2UgZGVmYXVsdHMgdG8gdHJ1ZSBpZiBub3QgcHJlc2VudC4gSXMg dGhpcyB3aGF0IHlvdSBoYWQgaW4geW91ciBtaW5kPyBZZXMsIE5NREEgc2F5cyB0aGF0IGl0IGlz ICZsdDtpbnRlbmRlZCZndDsgd2hpY2ggaXMgc3ViamVjdCB0byB2YWxpZGF0aW9uLiBCdXQgSSBh bHNvIG5vdGljZSB0aGF0IEluIHNlY3Rpb24gNS4xLjMgb2YgdGhlIE5NREE64oCdJmx0O3J1bm5p bmcmZ3Q7IE1VU1QgYWx3YXlzIGJlIGEgdmFsaWQgY29uZmlndXJhdGlvbiBkYXRhIHRyZWUsIGFz IGRlZmluZWQmbmJzcDsgaW4gU2VjdGlvbiA4LjEgb2YgW1JGQzc5NTBdLiDigJ0gU28gbXkgdGhv dWdodCBoZXJlIGlzIHRoYXQgJmx0O3J1bm5pbmcmZ3Q7IHNob3VsZCBhbHNvIGNvbmZvcm0gdG8g dGhlIFlBTkcgbW9kZWwgY29uc3RyYWludHMgYW5kIHRoYXTigJlzIHRvIHNheSwgYSByZWZlcmVu Y2VkIHN5c3RlbS1kZWZpbmVkIGRhdGEgaXRlbSBzaG91bGQgYWxzbyBleGlzdHMgaW4gJmx0O3J1 bm5pbmcmZ3Q7Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlcmVmb3JlLCBp ZiBzeXN0ZW0gY29uZmlndXJhdGlvbnMgZG8gbm90IGV4aXN0IGluICZsdDtydW5uaW5nJmd0Oywg dGhleSBzdGlsbCBuZWVkIHRvIGJlICZuYnNwO2NvbmZpZ3VyZWQgaW4gJmx0O3J1bm5pbmcmZ3Q7 IG1hbnVhbGx5IGluIG9yZGVyIGZvciBiZWluZyByZWZlcmVuY2VkLiBJbiB0aGlzIGNhc2UsIHRo ZSBvcmlnaW5hbCBwdXJwb3NlIG9mIHByZWRlZmluaW5nIHNvbWUgc3lzdGVtIGNvbmZpZ3VyYXRp b25zIGZvciB1c2VyIGNvbnZlbmllbmNlIGlzIGxvc3QuIFRoaXMgaXMgdGhlIHJlYXNvbiB3aHkg d2Ugd291bGQgbGlrZSB0byBkZWZpbmUgc29tZSBtZWNoYW5pc20gaGVyZSB0byBzeW5jaHJvbml6 ZSAmbHQ7c3lzdGVtJmd0OyBpbnRvICZsdDtydW5uaW5nJmd0Oy4gPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SSBzZWUgaW4gUkZDIDgzNDIgJnF1b3Q7Jmx0 O3J1bm5pbmcmZ3Q7IE1VU1QgYWx3YXlzIGJlIGEgdmFsaWQgY29uZmlndXJhdGlvbiBkYXRhIHRy ZWUsIGFzIGRlZmluZWQgaW4gU2VjdGlvbiA4LjEgb2YgW1JGQzc5NTBd4oCdLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5CdXQgdGhlIHF1ZXN0aW9u IHJlbWFpbnMgaWYgaXQgaXMgcG9zc2libGUgZm9yIHRoZSBzeXN0ZW0gaXMgYWJsZSB0byB2YWxp ZGF0ZSAmbHQ7cnVubmluZyZndDsgd2l0aG91dCwgZS5nLiwgZXhwYW5kaW5nIHRlbXBsYXRlcy4g Jm5ic3A7VGhlcmUgbWF5IGJlIGEgJ2xlYWZyZWYnIG9yIOKAmG11c3TigJkgZXhwcmVzc2lvbiBz b21ld2hlcmUgdGhhdCB3aWxsIGZhaWwgYmVjYXVzZSB0aGUgZXZhbHVhdGlvbg0KIG9jY3VycyB3 aXRob3V0IGV4cGFuZGluZyBhIHRlbXBsYXRlIHRoYXQgc3VwcGxpZXMgdGhlIG1pc3NpbmcgcGFy dHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+W1FpdWZhbmcgTWFdIE9uIGNvbmRpdGlvbiB0aGF0ICZsdDty dW5uaW5nJmd0OyBzaG91bGQgYmUgdmFsaWQsIHRoZSBvcGVyYXRvcnMgd2lsbCBuZWVkIHRvIHJl dHJpZXZlIGZyb20gdGhlICZsdDtpbnRlbmRlZCZndDsgb3IgJmx0O29wZXJhdGlvbmFsJmd0OyB0 byBnZXQgdGhlIHRlbXBsYXRlLWV4cGFuZGVkDQogY29uZmlndXJhdGlvbnMgYW5kIHRoZW4gY3Jl YXRlIHRoZW0gaW4gdGhlICZsdDtydW5uaW5nJmd0OywgcmlnaHQ/ICZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk15IGZlZWxpbmcgaXMgdGhhdCBpdCBsb3NlcyB0aGUgbWVh bmluZyBvZiBwcmVkZWZpbmluZyBhbmQgc2VlbXMgbm8gZGlmZmVyZW5jZXMgYmV0d2VlbiBvcGVy YXRvci1kZWZpbmVkIGNvbmZpZ3VyYXRpb25zIGlmIG9wZXJhdG9ycyBoYXZlIHRvIGNyZWF0ZSBz eXN0ZW0NCiBjb25maWd1cmVzIGluICZsdDtydW5uaW5nJmd0OyBiZWZvcmUgdGhleSB1c2UgdGhl bS4gU28gSSBhbSBiZWdpbm5pbmcgdG8gdGhpbmssIGlmIGl04oCZcyBwb3NzaWJsZSB0byBleHBh bmQgdGhlIHN5c3RlbS1kZWZpbmVkIHRlbXBsYXRlIGR1cmluZyB0aGUgY29weWluZyBiZXR3ZWVu ICZsdDtzeXN0ZW0mZ3Q7IGFuZCAmbHQ7cnVubmluZyZndDs/PG86cD48L286cD48L3NwYW4+PC9p PjwvYj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPklmIHRoaXMgZHJh ZnQg4oCcdXBkYXRlc+KAnSBSRkMgODM0MiAoTk1EQSksIHRoZW4gaXQgY2FuIHN1cHBseSBhIGNs YXJpZnlpbmcgc3RhdGVtZW50IGFib3V0IHdoYXQgaXQgbWVhbnMgdGhhdA0KPHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mcXVvdDsmbHQ7cnVubmluZyZndDsgTVVTVCBhbHdheXMgYmUgYSB2YWxp ZCBjb25maWd1cmF0aW9uIGRhdGEgdHJlZeKAnS4gJm5ic3A7RWl0aGVyIHRoYXQsIG9yIGFuIEVy cmF0YSBpZiBpdOKAmXMgZGV0ZXJtaW5lZCB0aGF0IHRoZSBzdGF0ZW1lbnQgaXNu4oCZdCBjb3Jy ZWN0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+WW91IG1ha2UgYSBnb29kIHRlY2huaWNhbCBwb2ludCwgYnV0IEkgdGhpbmsgdGhhdCB3 ZSBzaG91bGQgKndhbnQqIHRvIGF2b2lkIGhhdmluZyB0byBjb3B5ICZsdDtzeXN0ZW0mZ3Q7IChv ciAmbHQ7b3BlcmF0aW9uYWwmZ3Q7KSBjb25maWd1cmF0aW9uIGludG8gJmx0O3J1bm5pbmcmZ3Q7 IGlmIHdlIGNhbiBhdm9pZCBpdC4gJm5ic3A7QWdyZWVkPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltRaXVm YW5nIE1hXSB0ZW5kIHRvIGFncmVlLiBNYXliZSB3ZSBzaG91bGQgdHJ5IHRvIGF2b2lkIGl0LCB1 bmxlc3Mgd2UgaGF2ZSB0by48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij5GV0lXLCBhbHNvIGluIFJGQyA4MzQyLCBTZWN0aW9uIDUuMS40Ljo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2JyZWFrLWJlZm9yZTogcGFnZTtmb250LXZhcmlhbnQt bGlnYXR1cmVzOiBub3JtYWw7b3JwaGFuczogMjt3aWRvd3M6IDIiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7ICZsdDtpbnRlbmRlZCZndDsgaXMgdGlnaHRseSBjb3VwbGVk IHRvICZsdDtydW5uaW5nJmd0Oy4mbmJzcDsgV2hlbmV2ZXIgZGF0YSBpcyB3cml0dGVuPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRvICZsdDtydW5uaW5nJmd0OywgdGhl IHNlcnZlciBNVVNUIGFsc28gaW1tZWRpYXRlbHkgdXBkYXRlIGFuZCB2YWxpZGF0ZTxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyAmbHQ7aW50ZW5kZWQmZ3Q7LjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyAmbHQ7aW50ZW5kZWQmZ3Q7IE1BWSBhbHNvIGJlIHVwZGF0ZWQgaW5kZXBlbmRlbnRs eSBvZiAmbHQ7cnVubmluZyZndDsgaWYgdGhlPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IGVmZmVjdCBvZiBhIGNvbmZpZ3VyYXRpb24gdHJhbnNmb3JtYXRpb24gY2hhbmdl cywgYnV0ICZsdDtpbnRlbmRlZCZndDsgTVVTVDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBhbHdheXMgYmUgYSB2YWxpZCBjb25maWd1cmF0aW9uIGRhdGEgdHJlZSwgYXMg ZGVmaW5lZCBpbiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L3JmYzc5NTAjc2VjdGlvbi04LjEiPlNlY3Rpb24mbmJzcDs4LjE8bzpwPjwvbzpwPjwvYT48L3Nw YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGNsYXNzPSJN c29IeXBlcmxpbmsiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvcmZjNzk1MCNzZWN0aW9uLTguMSI+Jm5ic3A7Jm5ic3A7IG9mIFtSRkM3OTUwXTwvYT48L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4uPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7 Y29sb3I6IzIxMjUyOSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDo3Mi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4mZ3Q7IEkgYW0g d29uZGVyaW5nIGlmIHRoZXNlIGNvbmZpZ3VyYXRpb24gd2lsbCBwcmVzZW50IGluIHRoZSAmbHQ7 b3BlcmF0aW9uYWwmZ3Q7ICh3aGljaCBjb250YWlucyBhbGwgdGhlIGNvbmZpZ3VyYXRpb24gYWN0 dWFsbHkgdXNlZCBieSB0aGUgZGV2aWNlKSBiZWZvcmUgdGhleeKAmXJlIHJlZmVyZW5jZWQuPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7YmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjojMjEyNTI5Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1MjkiPkkg dGhpbmsgdGhhdCBpdCB3b3VsZCBkZXBlbmQgaW4gdGhlIHNwZWNpZmljIHNlcnZlcuKAmXMgYmVo YXZpb3IsIHJlZ2FyZGluZyBpZiAqdW51c2VkKiBwcmVkZWZpbmUgb2JqZWN0cyBhcmUgcHJlc2Vu dCBpbiAmbHQ7b3BlcmF0aW9uYWwmZ3Q7LiZuYnNwOyBDZXJ0YWlubHkgdGhlIHVudXNlZCBvYmpl Y3RzIHdvdWxkIG5vdCBoYXZlIHRvIGJlIHByZXNlbnQgaW4gJmx0O29wZXJhdGlvbmFsJmd0Oy4m bmJzcDsgSWYgSSB3ZXJlIGltcGxlbWVudGluZyB0aGUgc2VydmVyLCB0aGUgdW51c2VkIG9iamVj dHMgd291bGQgTk9UIGJlIHByZXNlbnQgaW4gJmx0O29wZXJhdGlvbmFsJmd0Oy48L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltRaXVmYW5nIE1hXSBZZXMsIGlmIHRoZSBwcmVkZWZp bmVkIHN5c3RlbSBjb25maWd1cmF0aW9ucyBpcyB1bnVzZWQsIHRoZW4gSSBhbHNvIHRlbmQgdG8g YWdyZWUgdGhhdCB0aGV5IHdvdWxkIG5vdCBiZSBwcmVzZW50IGluICZsdDtvcGVyYXRpb25hbCZn dDsgYnV0IG1heSBhbHNvIGRlcGVuZCBvbiB0aGUgdmVuZG9yIGltcGxlbWVudGF0aW9uLjwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPll1cCwgdGhpcyBpcyB0 aGUgc2FtZSBjb25jbHVzaW9uIGlzIGluIG15IHJlc3BvbnNlIGFib3ZlLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPltRaXVmYW5nIE1hXSA6KTwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1MjkiPiZndDsgSXQgd291bGQgYmUgZ29vZCBp ZiB3ZSBjb3VsZCBkZXRlcm1pbmUgaWYgdGhlcmUgYXJlIGFueSBvdGhlciAmcXVvdDtyZXNvdXJj ZS1pbmRlcGVuZGVudOKAnSBjb25maWd1cmF0aW9uIGNhdGVnb3JpZXMgaGVyZS48L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOiMyMTI1MjkiPiZndDsgW1FpdWZhbmcgTWFdIERvIHlvdSB0aGluayB0aGVyZSBleGlz dHMgY29uZGl0aW9uYWwgc3lzdGVtIGNvbmZpZ3VyYXRpb24gKGlmIHRoZSBwcmVjZWRpbmcgY29u ZmlndXJhdGlvbnMgeW91IG1lbnRpb25lZCBhYm92ZSBpcyBub3QpPyBGb3IgZXhhbXBsZSwgaWYg U1NIIGlzIGVuYWJsZWQgb24gYSBkZXZpY2UsIFNTSC1yZWxhdGVkIGtleXMgYXJlIGF1dG9tYXRp Y2FsbHkgZ2VuZXJhdGVkLiBTdWNoIGNvbmZpZ3VyYXRpb25zIGFyZSBnZW5lcmF0ZWQgYXQgdGhl IG1vbWVudCB3aGVuIGEgc3BlY2lhbCBmdW5jdGlvbmFsaXR5IGlzIGVuYWJsZWQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7YmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjojMjEyNTI5Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1MjkiPknigJltIHVu c3VyZSB3aGF0IHlvdSBtZWFuIGluIGdlbmVyYWwgYnkgJnF1b3Q7Y29uZGl0aW9uYWwgY29uZmln dXJhdGlvbuKAnSwgYnV0IEkgY2FuIHNwZWFrIHRvIHlvdXIgc3BlY2lmaWMgZXhhbXBsZS4gVGhv dWdoIEkgbXVzdCBwcmVmYWNlIG15IGNvbW1lbnRzIHRoYXQgSSBpbWFnaW5lIHRoZXJlIGFyZSBh IG51bWJlciBvZiB3YXlzIHNlcnZlcnMgbWlnaHQgZ28gYWJvdXQgZW5hYmxpbmcgYHNzaGRgLiZu YnNwOyBXaGF0IGZvbGxvd3MgaXMgbXkgcGVyc29uYWwgdmlldywgZm9yZ2VkIGJ5IGJlaW5nIGFy b3VuZCBzeXN0ZW1zIGZvciBhd2hpbGUmbmJzcDsgOyk8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1Mjki PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+SW4gZ2VuZXJhbDo8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOiMyMTI1MjkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gYHNzaGRgIGlzIE5PVCBlbmFi bGVkIGJ5IGRlZmF1bHQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDo3Mi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBgc3NoZGAgaXMgZW5hYmxlZCB2aWEg YSBjb25maWd1cmF0aW9uIGtub2IuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDo3Mi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSB0aGUgU1NIIGhvc3Qga2V5 IGlzIGR5bmFtaWNhbGx5IGdlbmVyYXRlZCB0aGUgZmlyc3QgdGltZSBgc3NoZGAgaXMgZW5hYmxl ZC48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBw dDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1MjkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAtIHRoZSBTU0ggaG9zdCBrZXkgaXRzZWxmIGlzIGluICZsdDtv cGVyYXRpb25hbCZndDsgKG5vdCAmbHQ7cnVubmluZyZndDspPC9zcGFuPjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEy NTI5Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0OjcyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1MjkiPlRoaXMgdmlldyBpcyBjb25zaXN0 ZW50IHdpdGggdGhlIGZpcnN0IHBhcmFncmFwaCBpbiBTZWN0aW9uIDMgb2YgdGhlIOKAnGtleXN0 b3Jl4oCdIGRyYWZ0IChyZXByb2R1Y2VkIGJlbG93KTo8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1Mjki PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMuJm5ic3A7IFN1cHBvcnQgZm9yIEJ1aWx0LWluIEtl eXM8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBw dDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1MjkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUy OSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNw OyZuYnNwOyBJbiBzb21lIGltcGxlbWVudGF0aW9ucywgYSBzZXJ2ZXIgbWF5IHN1cHBvcnQgYnVp bHQtaW4ga2V5cy4mbmJzcDsgQnVpbHQtPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IGlu IGtleXMgTUFZIGJlIHNldCBkdXJpbmcgdGhlIG1hbnVmYWN0dXJpbmcgcHJvY2VzcyBvciBiZSBk eW5hbWljYWxseTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyBnZW5lcmF0ZWQgdGhlIGZp cnN0IHRpbWUgdGhlIHNlcnZlciBpcyBib290ZWQgb3IgYSBwYXJ0aWN1bGFyIHNlcnZpY2U8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDtiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMyMTI1MjkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgKGUuZy4sIFNTSCkgaXMgZW5hYmxlZC48L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzO2NvbG9yOiMyMTI1MjkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+QXMgYSBj bG9zaW5nIHRob3VnaHQsIHRoaXMgbW9kZWwgKHdoaWNoIEkgc3RhdGVkIHVwZnJvbnQgbWF5IG5v dCBiZSB1bml2ZXJzYWwpIHdvdWxkIGhhdmUgbm8gcHJlc2VuY2UtaW4gb3IgaW50ZXJhY3Rpb24t d2l0aCAmbHQ7c3lzdGVtJmd0O+KApnRob3VnaCwgcGVyaGFwcywgdGhlcmUgbWF5IGJlIHNvbWUg cHJlZGVmaW5lZCB2YWx1ZXMgZm9yIHdoYXQga2V5LWFsZ29yaXRobXMgYW5kL29yIGtleS1sZW5n dGhzIHRvIHVzZSB3aGVuIGdlbmVyYXRpbmcgdGhlIFNTSCBob3N0IGtleS4uLjwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+W1FpdWZhbmcgTWFdIEJ5IOKAnGNvbmRpdGlvbmFsIHN5 c3RlbSBjb25maWd1cmF0aW9u4oCdLCBJIHdhcyBtZWFuaW5nIHNvbWUgb2YgdGhlIHN5c3RlbSBj b25maWd1cmF0aW9ucyBhcmUgbm90IGdlbmVyYXRlZCBpbW1lZGlhdGVseSBhZnRlciB0aGUgZGV2 aWNlIGlzIHBvd2VyZWQgb24uIEluc3RlYWQsIHRoZXkgYXJlIGdlbmVyYXRlZCB3aGVuIGEgc3Bl Y2lmaWMgY29uZGl0aW9uIGlzIHNhdGlzZmllZCBkdXJpbmcgdGhlIGRldmljZSBydW5uaW5nKGUu Zy4sIGEgZnVuY3Rpb25hbGl0eSBpcyBlbmFibGVkIGR1ZSB0byBzb21lIGNsaWVudCBjb25maWd1 cmF0aW9ucykuIEkgYW0gbm90IHN1cmUgaWYgaXQgcmVhbGx5IGV4aXN0cywgbWF5YmUgbm90LCBq dXN0IHRyeSB0byBleHBsb3JlIHRoZSBwb3NzaWJpbGl0aWVzIG9mIHZhcmlvdXMgcmVzb3VyY2Ut aW5kZXBlbmRlbnQgc3lzdGVtIGNvbmZpZ3VyYXRpb25zLjopIDwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VG8gdGhpcyBw b2ludCBJIGFncmVlLi5hcyBkb2VzIFJGQyA4MzQyIChOTURBKSwgU2VjdGlvbiA1LjMuMy46PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDticmVhay1iZWZvcmU6IHBhZ2U7Zm9udC12 YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO29ycGhhbnM6IDI7d2lkb3dzOiAyIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBTb21ldGltZXMsIHJlc291cmNlcyBhcmUgY29u dHJvbGxlZCBieSB0aGUgZGV2aWNlIGFuZCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgY29ycmVzcG9uZGluZyBzeXN0ZW0tY29udHJvbGxlZCBkYXRhIGFwcGVhcnMg aW4gKGFuZCBkaXNhcHBlYXJzIGZyb20pPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7ICZsdDtvcGVyYXRpb25hbCZndDsgZHluYW1pY2FsbHkuJm5ic3A7IElmIGEgc3lzdGVt LWNvbnRyb2xsZWQgcmVzb3VyY2UgaGFzPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IG1hdGNoaW5nIGNvbmZpZ3VyYXRpb24gaW4gJmx0O2ludGVuZGVkJmd0OyB3aGVuIGl0 IGFwcGVhcnMsIHRoZSBzeXN0ZW0gd2lsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyB0cnkgdG8gYXBwbHkgdGhlIGNvbmZpZ3VyYXRpb247IHRoaXMgY2F1c2VzIHRoZSBj b25maWd1cmF0aW9uIHRvPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFw cGVhciBpbiAmbHQ7b3BlcmF0aW9uYWwmZ3Q7IGV2ZW50dWFsbHkgKGlmIGFwcGxpY2F0aW9uIG9m IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjb25maWd1cmF0aW9u IHdhcyBzdWNjZXNzZnVsKS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltRaXVmYW5nIE1hXSBTZWUgYWJvdmUsIGFzIEkg c3VtbWFyaXplZCBhcyB0aGUgc3lzdGVtIGNvbmZpZ3VyYXRpb25zIHRoYXQgaXMgZ2VuZXJhdGVk IGNvbmRpdGlvbmFsbHkgZHVyaW5nIHRoZSBkZXZpY2UgcnVubmluZy48L3NwYW4+PC9pPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 IzIxMjUyOSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDo3Mi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij5GaXJzdGx5LCBJIGFnYWlu IGhhdmUgdG8gcHJlZmFjZSBteSBjb21tZW50IHRoYXQgdGhlcmUgYXJlIGxpa2VseSBtYW55IHdh eXMgdGhhdCB0ZW1wbGF0aW5nIG1lY2hhbmlzbXMgY2FuIGJlIGRlZmluZWQuJm5ic3A7Jm5ic3A7 Jm5ic3A7IEJ1dCwgaW4gZ2VuZXJhbCwgb25jZSBhIHRlbXBsYXRpbmcgbWVjaGFuaXNtIGhhcyBi ZWVuIGRlZmluZWQsIHRoZW4gaXQgc3RhbmRzIHRvIHJlYXNvbiB0aGF0IHRlbXBsYXRlcyBjb3Vs ZCBiZSBkZWZpbmVkIGVpdGhlciBpbiAmbHQ7cnVubmluZyZndDsgKGJ5IG9wZXJhdG9ycykgb3Ig aW4gJmx0O3N5c3RlbSZndDsgKGJ5IHRoZSBtYW51ZmFjdHVyZXIpLiZuYnNwOyBJbiBvbmUgaW1w bGVtZW50YXRpb24gSeKAmW0gZmFtaWxpYXIgd2l0aCwgdGhlIHRlbXBsYXRlcyBhcmUgb2JqZWN0 cyB0aGF0IGFyZSByZWZlcmVuY2VkL3BhcmFtZXRlcml6ZWQgYnkgb3RoZXIgcGFydHMgb2YgdGhl IGNvbmZpZ3VyYXRpb24uJm5ic3A7IChTYW1lIGFzIHdpdGggdGhlIHByZWRlZmluZWQgb2JqZWN0 cyBkaXNjdXNzaW9uIGFib3ZlLikmbmJzcDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBw dDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1MjkiPlRvIGFuc3dlciB5b3VyIHF1ZXN0aW9uczo8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDtiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMyMTI1MjkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+MSkg WWVzLCBpdCBpcyBteSBvcGluaW9uIHRoYXQgKmFjdGl2YXRlZCogdGVtcGxhdGVzIGluICZsdDtz eXN0ZW0mZ3Q7IHdpbGwgYmUgZXhwYW5kZWQgYW5kIHByZXNlbnQgaW4gJmx0O2ludGVuZGVkJmd0 Oy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBw dDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1MjkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUy OSI+MikgSSB3b3VsZCBuZXZlciBzdWdnZXN0IHRoYXQgdGhlIHN5c3RlbS1kZWZpbmVkIHRlbXBs YXRlcyBhcmUgcHJlc2VudCBpbiAmbHQ7cnVubmluZyZndDssIHRob3VnaCB0aGV5IG1heSBiZSBy ZWZlcmVuY2VkL3BhcmFtZXRlcml6ZWQgYnkgY29uZmlnIGluICZsdDtydW5uaW5nJmd0Oy48L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDtiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMyMTI1MjkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Mykg aWYgYSBjb25maWctdGVtcGxhdGUgaXMgY29uZmlndXJlZCBpbiAmbHQ7cnVubmluZyZndDsgKGku ZS4sIGl0IGlzIG9wZXJhdG9yLWRlZmluZWQpIHRoZW4sIHllcywgdGhlIGV4cGFuZGVkIGNvbmZp Z3VyYXRpb24gaW4gJmx0O2ludGVuZGVkJmd0OyBpcyAmcXVvdDtjbGllbnQgY29uZmlndXJhdGlv buKAnSAobm90ZSwgJnF1b3Q7Y2xpZW50IGNvbmZpZ3VyYXRpb27igJ0gaXMgbm90IGEgZm9ybWFs IHRlcm0pLiZuYnNwOyBUaGF0IHNhaWQsIGl0IHNlZW1zIGZhaXIgdG8gc2F5IHRoYXQgYSB0ZW1w bGF0ZSBkZWZpbmVkIGluICZsdDtzeXN0ZW0mZ3Q7IGFuZCB0aGVuIHJlZmVyZW5jZWQgYnkgJnF1 b3Q7Y2xpZW50IGNvbmZpZ3VyYXRpb27igJ0gaW4gJmx0O3J1bm5pbmcmZ3Q7IGlzIGFsc28gZXhw YW5kZWQgYXMgJnF1b3Q7Y2xpZW50IGNvbmZpZ3VyYXRpb27igJ0gaW4gJmx0O2ludGVuZGVkJmd0 Oy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBw dDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1MjkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUy OSI+NCkgSSBkb27igJl0IG5vdCB1bmRlcnN0YW5kIHlvdXIgbGFzdCBzZW50ZW5jZSwgdGhhdCB0 aGUgZXhwYW5zaW9uIG9mICZsdDtzeXN0ZW0mZ3Q7IHRlbXBsYXRlcyBhcmUgb25seSBwcmVzZW50 IGluICZsdDtvcGVyYXRpb25hbCZndDsuJm5ic3A7IE1heWJlIHlvdeKAmXJlIHNheWluZyBzb21l dGhpbmcgc3VidGxlLCBlLmcuLCB0aGF0IHNlcnZlcnMgY3VycmVudGx5IGRvbuKAmXQgc3VwcG9y dCBHRVQgb24gJmx0O2ludGVuZGVkJmd0Oy4mbmJzcDsgQnV0LCBpbiB0aGVvcnksIHRoZSBleHBh bnNpb24gb2YgJmx0O3N5c3RlbSZndDsgdGVtcGxhdGVzIHNob3VsZCAoSU1PKSBiZSBwcmVzZW50 IGluICZsdDtpbnRlbmRlZCZndDssIHNvIHRoYXQgdGhleSBtYXkgYmUgc3ViamVjdCB0byB2YWxp ZGF0aW9uLiZuYnNwOyZuYnNwOyBPZiBjb3Vyc2UsIGFsbCB0aGUgJmx0O2ludGVuZGVkJmd0OyBj b25maWd1cmF0aW9uICh3aGV0aGVyIG9yaWdpbmF0aW5nIGluICZsdDtydW5uaW5nJmd0OyBvciAm bHQ7c3lzdGVtJmd0OykgdGhhdCBpcyBzdWNjZXNzZnVsbHkg4oCcYXBwbGllZOKAnSB3aWxsIGFs c28gYmUgcHJlc2VudCBpbiAmbHQ7b3BlcmF0aW9uYWwmZ3Q7Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+W1FpdWZhbmcgTWFdIEFzc3VtZSB0aGF0IHRoZXJlIGlzIG5vICZsdDtz eXN0ZW0mZ3Q7IGFuZCB0aGlzIHdvcmssIHRoZSBleHBhbnNpb24gb2Ygc3lzdGVtIHRlbXBsYXRl cyBhcmUgb25seSBwcmVzZW50IGluICZsdDtvcGVyYXRpb25hbCZndDsuIEJlY2F1c2UgdGhpcyBp cyBjb21wYXRpYmxlIHdpdGggc3lzdGVtIGNvbmZpZ3VyYXRpb24gZGVmaW5pdGlvbiBpbiBOTURB Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QnV0IGlmIHN5c3RlbSBjb25maWd1 cmF0aW9ucyBhcmUgb25seSBwcmVzZW50IGluICZsdDtvcGVyYXRpb25hbCZndDssIHRoZSBwcmVk ZWZpbmVkIHN5c3RlbSBjb25maWd1cmF0aW9ucyBzdGlsbCBuZWVkIHRvIGJlIHJldHJpZXZlZCBh bmQgY3JlYXRlZCBpbnRvICZsdDtydW5uaW5nJmd0OyBleHBsaWNpdGx5IHdoZW4gYmVpbmcgcmVm ZXJlbmNlZC4gSSB0aGluayB3ZeKAmXZlIHJlYWNoZWQgYW4gYWdyZWVtZW50IG9uIHRoZSBuZWVk IGZvciAmbHQ7c3lzdGVtJmd0OyB0byBleGlzdCwgYW5kIG91ciBtYWluIHBvaW50IG9mIGRpc2Fn cmVlbWVudCBpcyB3aGV0aGVyICZsdDtzeXN0ZW0mZ3Q7IHNob3VsZCBiZSBjb3BpZWQgaW50byAm bHQ7cnVubmluZyZndDsuIFlvdXIgcG9pbnQgaXMgdGhhdCBiZWluZyBtZXJnZWQgaW50byAmbHQ7 aW50ZW5kZWQmZ3Q7IGlzIGVub3VnaCB0byBtYWtlIHN1cmUgYSBzdWNjZXNzIHZhbGlkYXRpb24u IEJ1dCBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIHJlZmVyZW5jZWQgc3lzdGVtIGNvbmZp Z3VyYXRpb24gZGF0YSBpdGVtIG11c3QgYWxzbyBleGlzdCBpbiB0aGUgJmx0O3J1bm5pbmcmZ3Q7 IHRvIG9iZXkgdGhlIG1vZGVsIGNvbnN0cmFpbnRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+WWVzLCBJIGJlbGlldmUg dGhhdCB5b3UgcHJvdmlkZWQgYW4gYWNjdXJhdGUgZGVzY3JpcHRpb24gb2YgdGhlIGRpZmZlcmVu Y2UgaW4gb3VyIG9waW5pb25zLiAmbmJzcDtQZXIgbXkgZWFybGllciByZXNwb25zZSwgeW91IG1h a2UgYSB2YWxpZCB0ZWNobmljYWwgcG9pbnQsIG15IGdvYWwgaXMgdG8gd2FpdmUgdGhhdCBpbnRl cnByZXRhdGlvbiB0byB0aGUgc2lkZSBzbyB0aGF0DQogYSBzaW1wbGVyIHNvbHV0aW9uIGNhbiBl bWVyZ2UuICZuYnNwO0l0IHdvdWxkIGJlIGdvb2QgdG8gZ2V0IG90aGVyIG9waW5pb25zIG9uIGxp c3QsIG90aGVyd2lzZSB3ZeKAmWxsIHRha2UgaXQgaW50byB0aGUgbWVldGluZy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5bUWl1ZmFuZyBNYV0gT0suICZuYnNwO0hvcGVmdWxseSBzb21lb25lIGVsc2Ugd291 bGQgc2hhcmUgc29tZSBvcGluaW9ucyBoZXJlLiBPdGhlcndpc2UgbGV04oCZcyB0YWtlIHRoaXMg aW50byB0aGUgSUVURiBtZWV0aW5nLjwvc3Bhbj48L2k+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPltCVFcsIGluIGtlZXBpbmcgd2l0aCB0aGlzIHRocmVhZCBtb3ZpbmcgZnJv bSB0aGUgTkVUQ09ORiB0byB0aGUgTkVUTU9EIG1haWxpbmcgbGlzdHMsIHdvdWxkIGl0IG1ha2Ug c2Vuc2UgdG8gbW92ZSB0aGUgSUVURiAxMTEgcHJlc2VudGF0aW9uIHNsb3QgZnJvbSBORVRDT05G IHRvIE5FVE1PRCB0b28/ICZuYnNwO0kgdGhpbmsgaXQgZG9lcyBhbmQsIGZ1cnRoZXIsIGl0IHdv dWxkDQogaGVscCB3aXRoIHNjaGVkdWxpbmcgKE5FVENPTkYgaXMgb3ZlciwgTkVUTU9EIGlzIHVu ZGVyKS4gJm5ic3A7V291bGQgeW91IGJlIG9rYXkgd2l0aCB0aGlzPyAmbmJzcDsgQUQgUm9iIGFu ZCB0aGUgTkVUQ09ORiBjaGFpcnMgZGlzY3Vzc2VkIHRoaXMgbW9ybmluZywgYW5kIHRoaW5rIGl0 J3Mgb2theSwgYnV0IHdvdWxkIHN0aWxsIG5lZWQgdG8gY29uZmlybSB3aXRoIHRoZSBORVRNT0Qg Y2hhaXJzLl08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUWl1ZmFuZyBNYV0gSSBhbSBoYXBweSB3aXRoIHRo ZSBwcm9wb3NhbCwgaWYgaXTigJlzIGFsc28gb2theSBmb3IgTkVUTU9EIGNoYWlyczotKS4gSSBo YXZlIHNlbnQgYW4gZW1haWwgdG8gdGhlIE5FVE1PRCBjaGFpcnMgdG8gcmVxdWVzdCB0byBtb3Zl IHRoaXMgcHJlc2VudGF0aW9uDQogc2xvdCBmcm9tIE5FVENPTkYgdG8gTkVUTU9ELiA8bzpwPjwv bzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdCB3aWxs IGFsc28gYmUgc3VibWl0dGVkIHRvIE5FVE1PRCB3aGVuIHRoZSBkcmFmdC1zdWJtaXR0aW5nIHdp bmRvdyByZW9wZW5zLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Jm5ic3A7Jmx0 O2JpZyBzbmlwJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Jmd0OyBJ4oCZbSBiZWdpbm5p bmcgdG8gdGhpbmsgdGhhdDo8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1MjkiPiZndDsgwrcmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXV0by1jb3B5aW5nIGlu dG8gJmx0O3J1bm5pbmcmZ3Q7IGlzIGxpa2VseSBuZXZlciBhIGdvb2QgaWRlYSwgYmVjYXVzZSBp dCB2aW9sYXRlcyB0aGUgZGVmaW5pdGlvbiBvZiAmbHQ7cnVubmluZyZndDs8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOiMyMTI1MjkiPiZndDsgW1FpdWZhbmcgTWFdIEkgYW0gcXVpdGUgYXdhcmUgdGhhdCBkaWZm ZXJlbnQgZGF0YXN0b3JlcyBpbiBOTURBIHJlcHJlc2VudHMgZGlmZmVyZW50IHZpZXdzIG9mIGRh dGEgbm9kZXMuJm5ic3A7IEFuZCAmbHQ7cnVubmluZyZndDsgcmVwcmVzZW50cyBhIGNvbmZpZ3Vy YXRpb24gZGF0YXN0b3JlIGhvbGRpbmcgdGhlIGN1cnJlbnQgY29uZmlndXJhdGlvbiBvZiB0aGUg ZGV2aWNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Jmd0OyBTaG91bGQgd2UgY29uc2lkZXIg c3lzdGVtIGNvbmZpZ3VyYXRpb24gYWxzbyBiZSBwYXJ0IG9mIGN1cnJlbnQgY29uZmlndXJhdGlv biBvZiB0aGUgZGV2aWNlPyBGcm9tIG15IHBlcnNwZWN0aXZlLCB0aGUgZGlmZmVyZW5jZSBiZXR3 ZWVuIHN5c3RlbSBjb25maWd1cmF0aW9uIGFuZCZuYnNwOyBjbGllbnQtY29uZmlndXJhdGlvbiBs aWVzIG9ubHkgaW4gd2hvIHByb3ZpZGVzIGl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4w cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4mbHQ7cnVubmluZyZndDsgaG9sZHMgdGhlIGN1 cnJlbnQgKm9wZXJhdG9yLXNwZWNpZmllZCogY29uZmlndXJhdGlvbiBvZiB0aGUgZGV2aWNlLiZu YnNwOyBTeXN0ZW0tcHJvdmlkZWQgY29uZmlndXJhdGlvbiBpcyBOT1Qgc3BlY2lmaWVkIGJ5IG9w ZXJhdG9ycyAodGhvdWdoIHN5c3RlbS1kZWZpbmVkIG9iamVjdHMgbWF5IGJlIHJlZmVyZW5jZWQg Ynkgb3BlcmF0b3Itc3BlY2lmaWVkIGNvbmZpZyBpbiAmbHQ7cnVubmluZyZndDspLiZuYnNwOyZu YnNwOyBJIGJlbGlldmUgdGhhdCB0aGlzIGFycmFuZ2VtZW50IGlzIGNvbnNpc3RlbnQgd2l0aCB0 aGUgZGVmaW5pdGlvbiBvZiAmbHQ7cnVubmluZyZndDsuJm5ic3A7IEFncmVlZD88L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDtiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltRaXVmYW5nIE1hXSBZZXMuIEFjdHVhbGx5IHdlIGFy ZSBub3QgdHJ5aW5nIHRvIHZpb2xhdGUgdGhlIHByaW5jaXBsZXMgb2YgTk1EQSBhbmQgdGhlIGRl ZmluaXRpb24gb2YgJmx0O3J1bm5pbmcmZ3Q7LiAmbmJzcDtUaGUgaXNzdWUgd2UgdHJ5IHRvIHJl c29sdmUgaGVyZSBpcyB0aGF0IHN5c3RlbSBjb25maWd1cmF0aW9ucyBjYW5ub3QgYmUgdXNlZChy ZWZlcmVuY2VkIG9yIG92ZXJ3cml0dGVuKSBieSB0aGUgb3BlcmF0b3JzIGRpcmVjdGx5IGFuZCBu ZWVkIHRvIGJlIGNyZWF0ZWQgaW50byAmbHQ7cnVubmluZyZndDsgZXhwbGljaXRseS4gVGhpcyBh Y3R1YWxseSBsb3NlcyB0aGUgbWVhbmluZyBvZiDigJxwcmVkZWZpbmluZyBhbmQgYnJpbmdpbmcg Y29udmVuaWVuY2XigJ0uIElmIGF1dG8tY29weWluZyBpcyBub3QgYSBnb29kIGlkZWEsIHdoYXQg ZG8geW91IHRoaW5rIGFib3V0IGRlZmluaW5nIGFuIFJQQyBvcGVyYXRpb24gZm9yIHRoZSBvcGVy YXRvcnMgdG8gZG8gdGhlIGNvcHkod2hpY2ggaXMgYWxzbyB3aGF0IFJvYiBzdWdnZXN0cyBhdCB0 aGUgbWVldGluZyk/PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5JZiB3ZSBoYXZlIHRvIGNvcHkgaW50byAmbHQ7cnVubmlu ZyZndDssIHRoZW4gSSB0aGluayB0aGF0IEkgYWdyZWUgYW4gUlBDICgmbHQ7ZWRpdC1jb25maWcm Z3Q7Pykgd291bGQgYmUgYmV0dGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltRaXVmYW5nIE1hXSBGcm9t IG15IHBlcnNwZWN0aXZlLCAmbHQ7ZWRpdC1jb25maWcmZ3Q7IGlzIGZlYXNpYmxlIGJ1dCBub3Qg ZWZmaWNpZW50IGJlY2F1c2Ugb3BlcmF0b3JzIHN0aWxsIG5lZWQgdG8gcmV0cmlldmUgJmx0O3N5 c3RlbSZndDsvJmx0O29wZXJhdGlvbmFsJmd0OyBmaXJzdGx5LiBJZg0KIHdlIGNvdWxkIGRlZmlu ZSBhIFJQQyB0byBjb3B5IHRoZSBlbnRpcmUgJmx0O3N5c3RlbSZndDsgaW50byAmbHQ7cnVubmlu ZyZndDssIGl0IHNlZW1zIG1vcmUgY29udmVuaWVudCBmb3Igb3BlcmF0b3JzLiBIb3dldmVyLCBz b21lIHN5c3RlbSBjb25maWd1cmF0aW9ucyB3aGljaCBhcmUgbm90IGdvaW5nIHRvIGJlIHJlZmVy ZW5jZWQgb3IgbW9kaWZpZWQgbWF5IGFsc28gYmUgY29waWVkIGludG8gJmx0O3J1bm5pbmcmZ3Q7 LiBJIGRvbid0IGhhdmUgYSBzdHJvbmcgZmVlbGluZw0KIGFib3V0IHdoaWNoIG9uZSBpcyBwcmVm ZXJyZWQuIEFueXdheSwgd2UgbmVlZCB0byBmaWd1cmUgb3V0IHdoZXRoZXIgaXQgd291bGQgYmUg ZmluZSBmb3IgJmx0O3J1bm5pbmcmZ3Q7IHRvIG1pc3NpbmcgcmVmZXJlbmNlZCBzeXN0ZW0gY29u ZmlndXJhdGlvbnMuPC9zcGFuPjwvaT48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+WW91IG1lbnRpb24g4oCcb3ZlcndyaXR0ZW7igJ0gYnkgdGhlIG9wZXJhdG9ycz8gJm5ic3A7 V2h5IHdvdWxkbuKAmXQgdGhlIG9wZXJhdG9ycyBqdXN0IGRlZmluZSB0aGVpciBvd24/ICZuYnNw O0ZvciBpbnN0YW5jZSwgaWYgdGhleSBkb27igJl0IGxpa2UgdGhlIHZlbmRvcuKAmXMg4oCcdmVu ZG9yLWZvb2JhcuKAnSBvYmplY3QsIHRoZXkgY291bGQgY29weS9wYXN0ZS9lZGl0IHRoZWlyIG93 biDigJxteS1mb29iYXLigJ0NCiBvYmplY3Qgd2l0aCB0aGUgdmFsdWVzIG5lZWRlZCwgeWVzPzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPltRaXVmYW5nIE1hXSBZZXMsIGRlZmluaW5nIHRoZWlyIG93biB3b3Vs ZCBiZSBva2F5LiBCeSBvdmVyd3JpdGluZywgSSBtZWFuIHNvbWV0aW1lcyB0aGUgb3BlcmF0b3Jz IHdvdWxkIGxpa2UgdG8gbW9kaWZ5IHRoZSBzcGVjaWZpYyBzeXN0ZW0gY29uZmlndXJhdGlvbiwN CiBlLmcuLCB0aGUgTVRVIHZhbHVlIG9mIGEgc3BlY2lmaWVkIGludGVyZmFjZShpZGVudGlmaWVk IGJ5IGl0cyBuYW1lKS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiB0aGUgb3Bl cmF0b3JzIHdhbnQgdG8gbW9kaWZ5IHRoZSBzeXN0ZW0gY29uZmlndXJhdGlvbnMsIHRoZXJlIGlz IG5vIHdheSBidXQgcmVkZWZpbmUgdGhlbSBpbiAmbHQ7cnVubmluZyZndDsuPG86cD48L286cD48 L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmVzdCBSZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlFpdWZhbmcgTWE8bzpwPjwvbzpwPjwvc3Bh bj48L2k+PC9iPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s YXM7Y29sb3I6IzIxMjUyOSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDti YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OkNvbnNvbGFzO2NvbG9yOiMyMTI1MjkiPiZndDsgwrcmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaGF2aW5nIGluICZsdDtvcGVyYXRpb25hbCZndDsgZG9l c27igJl0IG1ha2Ugc2Vuc2UsIHNpbmNlIHRoZSB0d2Vha3Mgd291bGRu4oCZdCBnbyB0aHJ1ICZs dDtydW5uaW5nJmd0OyAtLSZndDsgJmx0O2ludGVuZGVkJmd0OyB2YWxpZGF0aW9uLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29s YXM7Y29sb3I6IzIxMjUyOSI+Jmd0OyZuYnNwOyA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1MjkiPiZn dDsgSeKAmW0gd29uZGVyaW5nIGlmIGEgbW9kZWwgbGlrZSBiZWxvdyB3b3VsZCB3b3JrIGZvciBl dmVyeW9uZSAtIHRob3VnaHRzPzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Jmd0OyBbUWl1ZmFu ZyBNYV0gJmx0O2ludGVuZGVkJmd0OyByZXByZXNlbnRzIHRoZSBjb25maWd1cmF0aW9uIGFmdGVy IGFsbCBjb25maWd1cmF0aW9uIHRyYW5zZm9ybWF0aW9ucyB0byAmbHQ7cnVubmluZyZndDsgaGF2 ZSBiZWVuIHBlcmZvcm1lZCwgc28gSSB0aGluayBpdCBpcyBvbmx5IGNvdXBsZWQgdG8gJmx0O3J1 bm5pbmcmZ3Q7Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Jmd0OyBBbnl3YXksIHRoZSAmbHQ7 c3lzdGVtJmd0OyBzaG91bGQgYWxzbyBpbnRlcmFjdHMgd2l0aCAmbHQ7b3BlcmF0aW9uYWwmZ3Q7 LiZuYnNwOyBBZ3JlZWQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDo3Mi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOiMyMTI1MjkiPkkgZG9u4oCZdCBhZ3JlZSB0aGF0ICZsdDtpbnRlbmRlZCZndDsgbXVz dCBvbmx5IGJlIGNvdXBsZWQgdG8gJmx0O3J1bm5pbmcmZ3Q7LiZuYnNwOyBTcGVjaWZpY2FsbHks IEkgdGhpbmsgdGhhdCBpdCBpcyBva2F5IChjb21wYXRpYmxlIHdpdGggTk1EQSkgdG8gZGVmaW5l IGEgJmx0O3N5c3RlbSZndDsgdGhhdCBhbHNvIGltcGFjdHMgJmx0O2ludGVuZGVkJmd0Oy4mbmJz cDsmbmJzcDsgVGhpcyBpcyB0aGUgb25seSAoSU1PKSBzYW5lIGFwcHJvYWNoLCBhcyBpdCBlbmFi bGVzIHRoZSA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpD b25zb2xhcyI+Y29tYmluYXRpb24gJmx0O3J1bm5pbmcmZ3Q7ICYjNDM7ICZsdDtzeXN0ZW0mZ3Q7 IHRvIGJlIHZhbGlkYXRlZC48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltRaXVm YW5nIE1hXSBQbGVhc2Ugc2VlIGFib3ZlLiBJZiAmbHQ7cnVubmluZyZndDsgaXMgT0sgdG8gbWlz cyByZWZlcmVuY2VkIHN5c3RlbSBjb25maWd1cmF0aW9uLCB5b3VyIHByb3Bvc2FsIG1ha2VzIHNl bnNlIHRvIG1lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij5BY2suPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PGI+PGk+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwO0Jlc3QgUmVnYXJkcyw8L3NwYW4+PC9pPjwvYj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2JhY2tncm91bmQ6d2hp dGUiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5RaXVmYW5nIE1hIDwvc3Bh bj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5LZW50IC8vIGNvbnRy aWJ1dG9yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_add2ee3bb9094e1da6a3160824d5fdffhuaweicom_-- From nobody Fri Jul 16 03:54:03 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D376F3A3205; Fri, 16 Jul 2021 03:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=b7JOXRBX; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Gj6D9K5Q Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGKxflFVj3Ml; Fri, 16 Jul 2021 03:53:56 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F113A31FF; Fri, 16 Jul 2021 03:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11889; q=dns/txt; s=iport; t=1626432836; x=1627642436; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=O2mj9I98jLfzepjL/jTV+gOQABIllj/sQw0oJ59TCvE=; b=b7JOXRBXFA9hje0dIpxjFwf/vZPCy6b2s2qtbPu4oTFCp3D+R76dOpDP 6V+T7jNqNrx6BBgDacXtYv4HO8GLFeMkp1TEICMijwop3q5j6bGtFILKQ srHGUV2uoK5zcvGshcLtbVWghlt5wuaTkDA6j8PbVpqsKnpyBvwKi9zFS Y=; IronPort-PHdr: =?us-ascii?q?A9a23=3A/rycaR0XbKTUTDDKsmDPt1BlVkEcU/3cNQ4S8?= =?us-ascii?q?oI8zbVUfffr85fjORnZ4vNgxB/MUJ7A4v1Jw+zRr+j7WGMG7JrA1RJKcJFFW?= =?us-ascii?q?xIfz8lDmQsmDZ2OCUrjNOWsaDY1T4xOUVZ/9CS9Nk5YUM/1e1zVpCi06jgfU?= =?us-ascii?q?hXyPAZ4PKL7AInX2s+2zOu1vZbUZlYguQ=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AcwNZP6m9nhunzW6rbD1INE5APxvpDfN0iW?= =?us-ascii?q?dD5ihNYBxZY6Wkfp+V/cjzhCWbtN9OYh4dcIi7Sda9qXO1z+8T3WBjB8bdYO?= =?us-ascii?q?CAghrpEGgC1/qi/9SEIU3DH4FmpNxdmsRFebjN5B1B/LrHCWqDYpUdKbu8gd?= =?us-ascii?q?qVbI7lph8HJ2wHGsIQjTuRSDzrb3GeLzM2Y6bRYaDsnvav0ADQAEj/AP7LYk?= =?us-ascii?q?UtbqzmnZnmhZjmaRkJC1oM8w+Vlw6l77b8Dlyxwgoeeykn+8ZhzUH11yjCoo?= =?us-ascii?q?mzufCyzRHRk0XJ6Y5NpdfnwtxfQOSRl8kuLCn2gArAXvUlZ1TChkFwnAic0i?= =?us-ascii?q?dtrDD+mWZ4Ay210QKIQoiBm2qr5+An6kd015at8y7DvZKpm72JeNtzMbswuW?= =?us-ascii?q?seSGqF16Ll1+sMj56iGAmixsZq5Fr77VfAzsmNWBdwmkWup30+1eYVknxESI?= =?us-ascii?q?MbLKRctIoF4SpuYdo99Q/Bmcsa+dNVfYvhDTdtACSnRmGcunMqzM2nX3w1EB?= =?us-ascii?q?vDSk8eutaN2zwTmHxi1UMXyMEWg39FrfsGOtZ5zvWBNr4tmKBFT8cQY644DO?= =?us-ascii?q?AdQdGvAmiIRR7XKmqdLVnuCalCMXPQrJz85qkz+YiRCdA15Yp3nI6EXEJTtG?= =?us-ascii?q?Y0dU6rAcqS3IdT+hSIW2m5VSSF8LAX23G4gMy0eFPPC1zMdLkDqbrUnxwvOL?= =?us-ascii?q?ysZx/oAuMlPxbKFxqbJbp0?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BXBgAKZPFg/5ldJa1aDg4BAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIFZgVNRB3daNzGIEAOFOYhbA5ovgUKBEQNUCwEBAQ0BATU?= =?us-ascii?q?MBAEBhFQCgnsCJTgTAgQBAQESAQEFAQEBAgEGBHsThWgNhkUBAQEEEigGAQE?= =?us-ascii?q?3AQsEAgEIDgMEAQEfBQsyHQgCBAENBQgaglCCVQMvAQ6bBAGBOgKKH3iBNIE?= =?us-ascii?q?BggcBAQYEBIE2ARNBg0QYgjIDBoE6gnuGdoN4AiccgUlEgRVDgmI+gX9jAgE?= =?us-ascii?q?BAYEoAQsGAgEGHDCDG4IugxUGAQEGNhsLBBgKGQ8HAk4BCScZQh4KAg8ZEQ0?= =?us-ascii?q?tkSoEjC+dfYEWCoMkijWHN4ZwhXYSg2OLXoY+kF+WCIwyk1mEfwIEAgQFAg4?= =?us-ascii?q?BAQaBciRpWBEHcBUagwpQGQ6OHzeDOoUUhQVFcwI2AgYKAQEDCYoSgkcBAQ?= X-IronPort-AV: E=Sophos;i="5.84,244,1620691200"; d="scan'208";a="910833409" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 16 Jul 2021 10:53:54 +0000 Received: from mail.cisco.com (xbe-aln-006.cisco.com [173.36.7.21]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 16GArsaj006374 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 16 Jul 2021 10:53:54 GMT Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xbe-aln-006.cisco.com (173.36.7.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 16 Jul 2021 05:53:54 -0500 Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 16 Jul 2021 05:53:53 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 16 Jul 2021 05:53:53 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y9Y5aV+Ua/8MDziFfuxg+y1n0lQVzojBoRPp7zI49EHOy4GKXSQ22pHXZPdE/Ix2kmgEhYKdBUkqxvtbOQYbZywxbqX/e0e67KLy43OTZaQS4HGnYdXT3PcW818lcCCY1HuVpu9+c13O2lweXIBXT1xTBsC2MtJgTmiF9oOgnMtAmeUkS2Zjl6Yb+/73b+dl9EZdW4Yd6MM+t2MhLCFqHP3JGnsEkJdw7eT51AVUYYcF1PR9diHiLZSepGEpJIvSOMBGPJbrwUycRhiJX3Xr/Pin3QlgzotJq/Kfyb3sCQ/W0B5Qn848rMSEQl4xwXkGsNhOhpC2KN1mMz1xO18Gaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VdnQXrUjwnkFPh4877vyVIhr0XaASHxDPtZPIveJNWs=; b=Sebnu4vmpTqMfvXBuHL8inWK8uMuiJb6V2fZoJpMOT7VU2pjB+YSdNGaNsh9ERX5sRQj4O+c1Nq7POaK7P9CslAQx7SPSdBooAdWGAv+zwuJXziZEzxA5yEYW+7a/RtLkET7kSiFQP7gb13PKZKvzP70WpX3J+hb8j/2S1o8bTUxu+P0daDIG7bZxxP+VPy+dKqPlRqv3QZ+ZBu+Q+em6RicYwsOaiAep4zfJpbjS0PWueVTeQPaXzfUSMebIcMeSumnaB9p3CrTyQP/bw8k+N4PNamtMVYnPsAm1GI6qO2AHJMiFyn4140SCNFvknIEMWplaTTRJRuECG9GBd4O/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VdnQXrUjwnkFPh4877vyVIhr0XaASHxDPtZPIveJNWs=; b=Gj6D9K5QghlxeyzwpxVSXhU51ve3SjUldkb5ZGcglND4HFW8THG/9ZRQvtoVhclzheWN4Ebc7lwC5EKB6kUf1eBNb8mGuYQKIoZRXgzr5lEb801EmOP40h2e9d4jERAw98CLP6N68Y6SIc4GkDZyorF+Wno6hcivUhMkKH7O9P4= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM6PR11MB3772.namprd11.prod.outlook.com (2603:10b6:5:143::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.25; Fri, 16 Jul 2021 10:53:51 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12%6]) with mapi id 15.20.4331.026; Fri, 16 Jul 2021 10:53:51 +0000 From: "Rob Wilton (rwilton)" To: Christian Hopps , Benjamin Kaduk CC: "netmod-chairs@ietf.org" , The IESG , "netmod@ietf.org" , "draft-ietf-netmod-geo-location@ietf.org" Thread-Topic: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT) Thread-Index: AQHXTQd/Yobhg7xpm0ep6/oJkRO62Kr2XEYAgE9pzZA= Date: Fri, 16 Jul 2021 10:53:51 +0000 Message-ID: References: <162146723152.27764.1299479086437558158@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d046ee8e-4517-420b-59b9-08d94847ffb5 x-ms-traffictypediagnostic: DM6PR11MB3772: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8AzkzYuZDedCtdHiopKvbwUw5izM3w2olghRm5otwz+s/Qvo6NPIR1Yhx45zCnMtnk3iYHD7w2iwPHbzPoOFUS+uNVQKq08mJmbg+rlrUyL1UodRmI4pHYNZ37JYw9aPVcbMX9CUeOw3CoK6y+Qn1SwqqevpHS4pVPfZAareu6NxJ1lDAsF+WWLcYDn5yAS9R3zdD7xphPn8yK4cWvVFltUBvJka5qDMT+BUUNQe/sO6Pke8RhPYZbi/hWrpDv3Tj5v7t51Kg7cT8EVRmcrh1WntFKlqjnZJwzWPvaX+Qh+fwNbmn7u3UE51ojsHbXGriyMIp6L7o034boCHU9wP5lVI/Lr/bhG58kviGDhKYqwTphd0ZGKmN+KyO2Bmi4SXfphWaFdA+299nFe2EW7dfXQZ7tTfGQzULoevsjWCRMbmfNw0Vi2TH7OtEjEnzQyoaQSUtORnJg7U69elp2WxAOGRcz475Z18JdEx8lBxwqku2xgHVBXarTGg6hmI0rQvmgKob1fi7TROe431z8E/N9r4CxwGCIjJMmxODRZPM/79BuCg0/EyWpT/MHMl/j6jIPedTzWNFdimtFcPw4wfeV7R8vBNpshBY9rvA7gLmhKSOnSuewRQGLJZzzPkAtQvKmw+IDoWtubPlzxrU/iGS8nqJa4C0Dieu+sL+IjNDg1Drni28okCZXzg3DJeuyGoOzI2zoAV1G/+dQAnBboYftsfXc+wtPBfHg78ghw5WO4IGun+hfKtJQAmIRJK7uK3NDJvhPU45su9mCN7SK9zw1vGlxFR5Bcvu7BMxcN/vERzrk2rtfc3OTrLROn67AUhggE/7ztV66rYz2+UHbxnUA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(136003)(396003)(39860400002)(346002)(366004)(64756008)(66476007)(66556008)(66946007)(8936002)(316002)(76116006)(33656002)(478600001)(4326008)(66446008)(54906003)(110136005)(966005)(7696005)(55016002)(9686003)(86362001)(2906002)(8676002)(52536014)(5660300002)(30864003)(186003)(26005)(38100700002)(122000001)(83380400001)(71200400001)(53546011)(6506007)(38070700004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?xpAf3ajy9iEtNgQ/f0up398Tm1mIHhJBtD13tEs7RWfiESUIplUoQrfqY4LH?= =?us-ascii?Q?sqRuhMpGnZ/rQjJPYszHuVCOAh1jkkC+ZWy0+e6SjC45ID/UXtW834CTKsGm?= =?us-ascii?Q?nTeg94QbNqnZ2YuDgLg1mj2BzZI978zvKgRm/ZCmr9ESqwQzNgVoBtRcQUmH?= =?us-ascii?Q?rWqdtWd8H39IRCgLCUnUrcWm2we1BcaMLNg/XrL38SLER2rn+X4EJa7CBISI?= =?us-ascii?Q?cBy2qi3zJSHuDnRpPOWWs9uPg5ecq53ZorASH/WWHQD7nd4NAVPzw5oJU5vg?= =?us-ascii?Q?2TbIqdmwjq8ni4UXFAqBIzJM7NxKE+0/YMhHDlF7UdIFItivV2PMw54fwFAw?= =?us-ascii?Q?xpi/ws2L2yKg0cHzHiHBASfQOArB5RnGSdgU8Rs7T86WGZlTyOGS+G57IkHJ?= =?us-ascii?Q?KBXpTQ6tamuR6KywbkKf0slsk7uof9Gc5z29C2rPZGVtTa5KBIZze1hO/g/w?= =?us-ascii?Q?nbVcLCEHSV9zZxzRTGKZxf0M3vjwDgGN8ilupFXHkfRJxu6h5Utx99cC9CGG?= =?us-ascii?Q?mr36tCGOuD+GTjl0cH45MgNdbkB2ZmTvETLEq2b45I1kEPYuFrbX8C2ffv5v?= =?us-ascii?Q?9eV68+Nj/2eoWj83gHwOmjPACUsHnD1jDO0iwTwBy7c14JTqewO+jl3Xfp8h?= =?us-ascii?Q?NrmcAr1wKnbiwVmhENq9XOcD2ApqOW/wvjtbtRislwPi/+Efa8hyOy7RNvqg?= =?us-ascii?Q?5mbpm+SzVp+rOILcA8t5w5b0oy9L7Sr1a1DVGUR53EfYPqWfSzKly72nAIeM?= =?us-ascii?Q?RbNRV7kKE15A1izZkNv071v2hn9QHYfpP9q95DPD2UcpVTiWUA6ZLBzXl8+I?= =?us-ascii?Q?7rB7KeAhfFn5Z/KNe6rcIYsqxSzH+7pdsAyoQIGwKMFrcLgCjDBaHBQTjIFz?= =?us-ascii?Q?QmNmb8dluW/TWlQ1xruwpDaAhtmQihKSoEy7lgE8uJdPV1RGvnGhUhUqun+y?= =?us-ascii?Q?bnKVzLv0qm58Kdxgn1EfOfDQPz4O5ehq3PmAFS5DjFxU5jsMrbHhU2sOTTNo?= =?us-ascii?Q?4Vlm1J7AI8DiYXQp//SF5nXKMjFzzt7ncrzh2A7UN3z023TZPTk3NB+r0o5L?= =?us-ascii?Q?eiD6xqMCBiWbSddk+CdDIQB30sryomixtRKN46M9xb/jgxEjsLkMr8FuODv9?= =?us-ascii?Q?OHmcwNtaOzUdh0RFbtgqpLlYQPXGzhxydq9Pcz5YELubWtwOUz/mXRC/UW+i?= =?us-ascii?Q?5WxUGcTZrs259Dr2Qy5IYroXvt0PBDfYcXW2deNp8pSQ16+az3wUxSMeyyVR?= =?us-ascii?Q?WtO3KIHNYQ/cUYMacT38/rQ4AlfijlUpNIXZyEq7EylAw3gDT/bDay23N3hv?= =?us-ascii?Q?tdp+TuK3tVMpKVV1Pag2PesP?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d046ee8e-4517-420b-59b9-08d94847ffb5 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2021 10:53:51.8364 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8LtNqEqqA2AtzTodJfv744B+IIIEjr+dO/6jBlrRNPDIOJENrEnIivjD+VdZaT4jsmsNIjsQkcmuiB5awMYBVw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3772 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xbe-aln-006.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 10:54:01 -0000 Hi Ben, Chris, I wanted to check whether this discussion has progressed at all. This is t= he only remaining discuss after Roman has cleared his based on the IESG tel= echat discussion yesterday (thanks Roman). Regards, Rob > -----Original Message----- > From: netmod On Behalf Of Christian Hopps > Sent: 26 May 2021 23:05 > To: Benjamin Kaduk > Cc: netmod-chairs@ietf.org; The IESG ; netmod@ietf.org; > draft-ietf-netmod-geo-location@ietf.org > Subject: Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo- > location-08: (with DISCUSS and COMMENT) >=20 >=20 > Benjamin Kaduk via Datatracker writes: >=20 > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-netmod-geo-location-08: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > > for more information about DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I think we lack sufficient precision (forgive the pun) in how we talk > > about "accuracy" and "precision". Are the leafs that claim to specify > > "accuracy" specifying a precision? If so, the precision of a specific > > measurement, the precision of the measurements that led to the creation > > of the coordinate frame, or something else? Are they doing so in > > relative terms (e.g., percentage) or absolute terms (e.g., degrees and > > meters)? (There are "units" directives only for "height-accuracy" and > > not the others.) How can we we say that we'll have 16 fraction-digits = of > > precision for lat/long when the maximum accuracy we can say that a > > geodetic-system has only gives us 6 fraction-digits for coord-accuracy? > > When we say that the "precision of this measurement is indicated by the > > reference-frame" is that the same thing as the relevant "-accuracy" > > nodes, or something else? >=20 > Yes, the geodesic-datum is what defines the values and their accuracy. Fo= r > the precision in the value we choose the fractional digits based on what > might be needed, but not to prescribe anything. For decimal degrees e.g.,= we > only need 100s values the rest can be left to the fractional portion. >=20 > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > (I support Roman's Discuss.) > > > > Why do we only define velocity in terms of north/east/up, when we could > > be in x/y/z coordinates where there is no clear "north" or "east"? > > > > It would have been helpful for the shepherd review to point to the > > thread at > > > https://mailarchive.ietf.org/arch/msg/netmod/dA9olZfEVa3clGdfvNYEFXUE > MJw/ > > that attempted to discuss the feedback from the yangdoctor review -- th= e > > mail with the review itself got no direct replies. >=20 > This is a very edge case of this grouping meant really to handle somethin= g > like continental drift with long stored values. One can keep drilling dow= n on > this particular velocity value seemingly forever, but then we aren't gett= ing > our work done. I think it's enough to say that if the usable values don't= work > for a use case at this point, then they don't work. >=20 > > Section 2.1 > > > > In addition to the "geodetic-datum" value, we allow refining the > > coordinate and height accuracy using "coord-accuracy" and "height- > > > > My understanding is that "refine" is a YANG keyword, and the current > > module/tree structure does not seem consistent with this description > > referring to use of the YANG keyword (since we can just set new values > > directly without needing to "refine" the YANG structure itself). A > > different word here might be appropriate. >=20 > Ok changed to "overriding". >=20 >=20 > > Finally, we define an optional feature which allows for changing the > > system for which the above values are defined. This optional featur= e > > adds an "alternate-system" value to the reference frame. This value > > is normally not present which implies the natural universe is the > > system. The use of this value is intended to allow for creating > > virtual realities or perhaps alternate coordinate systems. The > > definition of alternate systems is outside the scope of this > > document. > > > > This paragraph doesn't really convince me that we need to include the > > "alternate-system" capability in the proposed-standard version of this > > YANG module at this time. >=20 > It doesn't hurt anything to include it and it was asked for by the person= who > came up with the shape of this grouping (Peter L.). Unless there's a stro= ng > objection I'd prefer to leave it in deference to the person who asked for= it. >=20 > > Section 2.3 > > > > meters per second. The values "v-north" and "v-east" are relative t= o > > true north as defined by the reference frame for the astronomical > > body, "v-up" is perpendicular to the plane defined by "v-north" and > > "v-east", and is pointed away from the center of mass. > > > > When I read this I wondered if the "plane defined by v-north and v-east= " > > was taken at the initial snapshot position, or continuously updated wit= h > > the effect of v-north and v-east drift. Given the stated application, > > it's unlikely that it actually would matter, though, so it's not clear > > that we should change the text to cover it. > > > > Section 3 > > > > and 91..126). The IANA registry further restricts the > > value by converting all spaces (' ') to dashes ('-')"= ; > > > > Is there a reason why we shouldn't disallow spaces via the regex (and > > obviate the need for special processing at IANA)? >=20 > The thinking is to allow users to do more than what we IANA is limited to= . >=20 > > Section 5.1.2 > > > > The following subsection suggests that there is a "heading" field in th= e > > W3C structure/API, but I don't see one listed in Figure 1. > > > > Section 6.1 > > > > What are suitable references for the "me" and "mola-vik-1" geoedtic > > systems? I do not see how just the listed descriptions provide a "clea= r > > definition" even for the two coordinate values latitude/longitude. > > > > Section 7 > > > > Thanks for using the template for security considerations for YANG > > models! I think that since some of the portions of the template do not > > apply, they can safely be removed. In particular, the "these are the > > subtrees and data nodes and their sensitivity/vulnerability" lines can > > go, and the clause about "can have a negative effect on network > > operations" may be worth tweaking (network operations may not be the > > most likely thing to be impacted). I think it's also okay to drop the > > paragraph/sentence about RPCs. > > > > Section 8 > > > > The [WGS84] and [EGM08] links don't work for me. ([EGM96] does.) >=20 > I've removed the links as they are not stable. Just going with standard t= itle, > author pub date now. >=20 > > Section 9 > > > > It seems like RFC 7950 is more properly classified as normative, since > > you can't really make sense of YANG without ... knowing YANG. I think > > 8340 is sometimes listed as normative as well, but the case is not quit= e > > as clear, here. > > > > NITS > > > > Abstract > > > > This document defines a generic geographical location object YANG > > grouping. [...] > > > > I'm having a hard time seeing what role the word "object" is playing > > here, especially since in the next sentence we just refer to the > > "geographical location grouping". >=20 > Removed "object" >=20 > > Section 3 > > > > description > > "A location on an astronomical body (e.g., 'earth') > > somewhere in a universe."; > > > > I guess in some alternate-systems the "astronomical body" bit may not > > really be accurate. (And possibly in some cartesian coordinate frames, > > too, but that's less clear.) > > > > type string { > > pattern '[ -@\[-\^_-~]*'; > > > > If I'm reading my table correctly, '^' and '_' are adjacent, so this > > rather-reader-unfriendly regex formulation can't even be justified as > > the minimal encoding. >=20 > This has to do with working with limitations in the tools. The minimal > encoding does not work unfortunately. >=20 > > '67p/churyumov-gerasimenko (a comet). The value should > > be comprised of all lower case ASCII characters not > > including control characters (i.e., values 32..64, and > > 91..126). [...] > > > > "all lower case ASCII characters" inherently excludes control > > characters, so "all lower case ASCII characters not including control > > characters" is redundant. > > Also, that doesn't match up the listed range of values (or the regex). > > (Also^2, that doesn't match the given comet name, which has numbers and > > punctuation.) >=20 > Changed to: >=20 > "The ASCII value SHOULD have upper case converted to lower case > characters and not include control characters (i.e., values 32..64, and > 91..126). Any preceding 'the' in the name SHOULD NOT be included."; >=20 > > for Cartesian coordinates. When coord-accuracy is > > specified, it overrides the geodetic-datum implied > > accuracy."; > > [...] > > "The accuracy of height value for ellipsoidal > > coordinates, this value is not used with Cartesian > > coordinates. When specified, it overrides the > > geodetic-datum implied default."; > > > > I suggest using parallel language for "when specified, overrides implie= d > > default". (That is, "coord-accuracy" is currently explicitly named but > > "height-accuracy" is not.) >=20 > Done. >=20 > > > > leaf v-up { > > type decimal64 { > > fraction-digits 12; > > } > > units "meters per second"; > > description > > "v-up is the rate of change (i.e., speed) away from the > > center of mass."; > > > > "center of mass" may not be universally applicable, e.g., to cartesian > > coordinates, binary systems, extremely massive objects that are not the > > astronomical-body of the reference-frame. >=20 > In this case the value is not relevant. Again, this isn't a big part of t= his > specification, it's meant to track things like continental drift. If it's= not useful > as defined then it's simply not useful for that use. >=20 > > Section 4 > > > > We probably should expand CRS at/before first usage. >=20 > Done, just under the table. >=20 > > Section 6.1 > > > > Each entry should be sufficient to define the 3 coordinate values (2 > > if height is not required). So for example the "wgs-84" is defined > > > > I'd suggest flipping the order, for "should be sufficient to define the > > 2 coordinate values, and to define height if height is required". >=20 > Done. From nobody Sat Jul 17 10:33:47 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2F33A194F; Sat, 17 Jul 2021 10:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8QviUVj8T0l; Sat, 17 Jul 2021 10:33:35 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 5C8F23A194D; Sat, 17 Jul 2021 10:33:35 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16HHXLtM027414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 17 Jul 2021 13:33:31 -0400 Date: Sat, 17 Jul 2021 10:33:21 -0700 From: Benjamin Kaduk To: Christian Hopps Cc: The IESG , draft-ietf-netmod-geo-location@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, kent+ietf@watsen.net Message-ID: <20210717173321.GE74365@kduck.mit.edu> References: <162146723152.27764.1299479086437558158@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2021 17:33:41 -0000 Hi Christian, Sorry for the very delayed reply (and thanks to Rob for the nudge). On Wed, May 26, 2021 at 06:04:58PM -0400, Christian Hopps wrote: > > Benjamin Kaduk via Datatracker writes: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-netmod-geo-location-08: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I think we lack sufficient precision (forgive the pun) in how we talk > > about "accuracy" and "precision". Are the leafs that claim to specify > > "accuracy" specifying a precision? If so, the precision of a specific > > measurement, the precision of the measurements that led to the creation > > of the coordinate frame, or something else? Are they doing so in > > relative terms (e.g., percentage) or absolute terms (e.g., degrees and > > meters)? (There are "units" directives only for "height-accuracy" and > > not the others.) How can we we say that we'll have 16 fraction-digits of > > precision for lat/long when the maximum accuracy we can say that a > > geodetic-system has only gives us 6 fraction-digits for coord-accuracy? > > When we say that the "precision of this measurement is indicated by the > > reference-frame" is that the same thing as the relevant "-accuracy" > > nodes, or something else? > > Yes, the geodesic-datum is what defines the values and their accuracy. For the precision in the value we choose the fractional digits based on what might be needed, but not to prescribe anything. For decimal degrees e.g., we only need 100s values the rest can be left to the fractional portion. Unfortunately, even your description here still doesn't help me understand what the intended semantics of these values are. To help illustrate my confusion, here are a few possible things that could be what is intended to be conveyed: - the geodetic-datum description of the object has been measured to be within a known delta of the actual object being described, at all points on the object that the coordinate system can describe - the geodetic-datum description of the object is capable of determining relative differences between points on the object to within a particular delta of precision, but those individual coordinate values may be farther than that delta from the actual point on the object that was referred to - the values that are reported in this YANG module reflect measurements that were made and are known to be within some delta of the coordinate system's value that they are reported as - the values that are reported in this YANG module reflect measurements thare are known to be distinguishable from other measurements to within some delta of other measurements relative to that coordinate system, even though the actual position being indicated may diverge from the reported value by more than that delta - the values that are reported in this YANG module reflect measurements that were made and are known to be within some delta of the actual point on the object that the coordinates refer to - the values that are reported in this YANG module reflect measurements that were and are known to be distinguishable from other measurements of points on that object within some delta, but the actual distance from the measured point to the point on the object indicated by the reported coordinates may be larger than that delta In short, there are at least three classes of things at play here: the actual object itself, the coordinate system used to model the object, and values reported in the YANG module (which are assumed to ultimately derive from some form of measurement). To talk about accuracy or precision implies a relationship between elements of two of those classes, and I don't even know which of those classes you're trying to talk about. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > (I support Roman's Discuss.) > > > > Why do we only define velocity in terms of north/east/up, when we could > > be in x/y/z coordinates where there is no clear "north" or "east"? > > > > It would have been helpful for the shepherd review to point to the > > thread at > > https://mailarchive.ietf.org/arch/msg/netmod/dA9olZfEVa3clGdfvNYEFXUEMJw/ > > that attempted to discuss the feedback from the yangdoctor review -- the > > mail with the review itself got no direct replies. > > This is a very edge case of this grouping meant really to handle something like continental drift with long stored values. One can keep drilling down on this particular velocity value seemingly forever, but then we aren't getting our work done. I think it's enough to say that if the usable values don't work for a use case at this point, then they don't work. Sure, that's most of why this is in the non-blocking COMMENT section. The rest of this (including the follow-up) all looks fine; thanks for the replies and updates! -Ben > > Section 2.1 > > > > In addition to the "geodetic-datum" value, we allow refining the > > coordinate and height accuracy using "coord-accuracy" and "height- > > > > My understanding is that "refine" is a YANG keyword, and the current > > module/tree structure does not seem consistent with this description > > referring to use of the YANG keyword (since we can just set new values > > directly without needing to "refine" the YANG structure itself). A > > different word here might be appropriate. > > Ok changed to "overriding". > > > > Finally, we define an optional feature which allows for changing the > > system for which the above values are defined. This optional feature > > adds an "alternate-system" value to the reference frame. This value > > is normally not present which implies the natural universe is the > > system. The use of this value is intended to allow for creating > > virtual realities or perhaps alternate coordinate systems. The > > definition of alternate systems is outside the scope of this > > document. > > > > This paragraph doesn't really convince me that we need to include the > > "alternate-system" capability in the proposed-standard version of this > > YANG module at this time. > > It doesn't hurt anything to include it and it was asked for by the person who came up with the shape of this grouping (Peter L.). Unless there's a strong objection I'd prefer to leave it in deference to the person who asked for it. > > > Section 2.3 > > > > meters per second. The values "v-north" and "v-east" are relative to > > true north as defined by the reference frame for the astronomical > > body, "v-up" is perpendicular to the plane defined by "v-north" and > > "v-east", and is pointed away from the center of mass. > > > > When I read this I wondered if the "plane defined by v-north and v-east" > > was taken at the initial snapshot position, or continuously updated with > > the effect of v-north and v-east drift. Given the stated application, > > it's unlikely that it actually would matter, though, so it's not clear > > that we should change the text to cover it. > > > > Section 3 > > > > and 91..126). The IANA registry further restricts the > > value by converting all spaces (' ') to dashes ('-')"; > > > > Is there a reason why we shouldn't disallow spaces via the regex (and > > obviate the need for special processing at IANA)? > > The thinking is to allow users to do more than what we IANA is limited to. > > > Section 5.1.2 > > > > The following subsection suggests that there is a "heading" field in the > > W3C structure/API, but I don't see one listed in Figure 1. > > > > Section 6.1 > > > > What are suitable references for the "me" and "mola-vik-1" geoedtic > > systems? I do not see how just the listed descriptions provide a "clear > > definition" even for the two coordinate values latitude/longitude. > > > > Section 7 > > > > Thanks for using the template for security considerations for YANG > > models! I think that since some of the portions of the template do not > > apply, they can safely be removed. In particular, the "these are the > > subtrees and data nodes and their sensitivity/vulnerability" lines can > > go, and the clause about "can have a negative effect on network > > operations" may be worth tweaking (network operations may not be the > > most likely thing to be impacted). I think it's also okay to drop the > > paragraph/sentence about RPCs. > > > > Section 8 > > > > The [WGS84] and [EGM08] links don't work for me. ([EGM96] does.) > > I've removed the links as they are not stable. Just going with standard title, author pub date now. > > > Section 9 > > > > It seems like RFC 7950 is more properly classified as normative, since > > you can't really make sense of YANG without ... knowing YANG. I think > > 8340 is sometimes listed as normative as well, but the case is not quite > > as clear, here. > > > > NITS > > > > Abstract > > > > This document defines a generic geographical location object YANG > > grouping. [...] > > > > I'm having a hard time seeing what role the word "object" is playing > > here, especially since in the next sentence we just refer to the > > "geographical location grouping". > > Removed "object" > > > Section 3 > > > > description > > "A location on an astronomical body (e.g., 'earth') > > somewhere in a universe."; > > > > I guess in some alternate-systems the "astronomical body" bit may not > > really be accurate. (And possibly in some cartesian coordinate frames, > > too, but that's less clear.) > > > > type string { > > pattern '[ -@\[-\^_-~]*'; > > > > If I'm reading my table correctly, '^' and '_' are adjacent, so this > > rather-reader-unfriendly regex formulation can't even be justified as > > the minimal encoding. > > This has to do with working with limitations in the tools. The minimal encoding does not work unfortunately. > > > '67p/churyumov-gerasimenko (a comet). The value should > > be comprised of all lower case ASCII characters not > > including control characters (i.e., values 32..64, and > > 91..126). [...] > > > > "all lower case ASCII characters" inherently excludes control > > characters, so "all lower case ASCII characters not including control > > characters" is redundant. > > Also, that doesn't match up the listed range of values (or the regex). > > (Also^2, that doesn't match the given comet name, which has numbers and > > punctuation.) > > Changed to: > > "The ASCII value SHOULD have upper case converted to lower case characters and not include control characters (i.e., values 32..64, and 91..126). Any preceding 'the' in the name SHOULD NOT be included."; > > > for Cartesian coordinates. When coord-accuracy is > > specified, it overrides the geodetic-datum implied > > accuracy."; > > [...] > > "The accuracy of height value for ellipsoidal > > coordinates, this value is not used with Cartesian > > coordinates. When specified, it overrides the > > geodetic-datum implied default."; > > > > I suggest using parallel language for "when specified, overrides implied > > default". (That is, "coord-accuracy" is currently explicitly named but > > "height-accuracy" is not.) > > Done. > > > > > leaf v-up { > > type decimal64 { > > fraction-digits 12; > > } > > units "meters per second"; > > description > > "v-up is the rate of change (i.e., speed) away from the > > center of mass."; > > > > "center of mass" may not be universally applicable, e.g., to cartesian > > coordinates, binary systems, extremely massive objects that are not the > > astronomical-body of the reference-frame. > > In this case the value is not relevant. Again, this isn't a big part of this specification, it's meant to track things like continental drift. If it's not useful as defined then it's simply not useful for that use. > > > Section 4 > > > > We probably should expand CRS at/before first usage. > > Done, just under the table. > > > Section 6.1 > > > > Each entry should be sufficient to define the 3 coordinate values (2 > > if height is not required). So for example the "wgs-84" is defined > > > > I'd suggest flipping the order, for "should be sufficient to define the > > 2 coordinate values, and to define height if height is required". > > Done. From nobody Sat Jul 17 11:46:50 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4786F3A1C05; Sat, 17 Jul 2021 11:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 lMEiBTQf4Poo; Sat, 17 Jul 2021 11:46:39 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 687FD3A1C04; Sat, 17 Jul 2021 11:46:39 -0700 (PDT) Received: from ja.int.chopps.org.chopps.org (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 62717803DF; Sat, 17 Jul 2021 18:46:38 +0000 (UTC) References: <162146723152.27764.1299479086437558158@ietfa.amsl.com> <20210717173321.GE74365@kduck.mit.edu> User-agent: mu4e 1.5.13; emacs 27.2 From: Christian Hopps To: Benjamin Kaduk Cc: Christian Hopps , The IESG , draft-ietf-netmod-geo-location@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, kent+ietf@watsen.net Date: Sat, 17 Jul 2021 14:38:55 -0400 In-reply-to: <20210717173321.GE74365@kduck.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2021 18:46:44 -0000 --=-=-= Content-Type: text/plain; format=flowed Benjamin Kaduk writes: > Hi Christian, > > Sorry for the very delayed reply (and thanks to Rob for the nudge). > > On Wed, May 26, 2021 at 06:04:58PM -0400, Christian Hopps wrote: >> >> Benjamin Kaduk via Datatracker writes: >> >> > Benjamin Kaduk has entered the following ballot position for >> > draft-ietf-netmod-geo-location-08: Discuss >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut this >> > introductory paragraph, however.) >> > >> > >> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> > for more information about DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > DISCUSS: >> > ---------------------------------------------------------------------- >> > >> > I think we lack sufficient precision (forgive the pun) in how we talk >> > about "accuracy" and "precision". Are the leafs that claim to specify >> > "accuracy" specifying a precision? If so, the precision of a specific >> > measurement, the precision of the measurements that led to the creation >> > of the coordinate frame, or something else? Are they doing so in >> > relative terms (e.g., percentage) or absolute terms (e.g., degrees and >> > meters)? (There are "units" directives only for "height-accuracy" and >> > not the others.) How can we we say that we'll have 16 fraction-digits of >> > precision for lat/long when the maximum accuracy we can say that a >> > geodetic-system has only gives us 6 fraction-digits for coord-accuracy? >> > When we say that the "precision of this measurement is indicated by the >> > reference-frame" is that the same thing as the relevant "-accuracy" >> > nodes, or something else? >> >> Yes, the geodesic-datum is what defines the values and their accuracy. For the >> precision in the value we choose the fractional digits based on what might be >> needed, but not to prescribe anything. For decimal degrees e.g., we only need >> 100s values the rest can be left to the fractional portion. > > Unfortunately, even your description here still doesn't help me understand > what the intended semantics of these values are. > > To help illustrate my confusion, here are a few possible things that could > be what is intended to be conveyed: > > - the geodetic-datum description of the object has been measured to be > within a known delta of the actual object being described, at all points > on the object that the coordinate system can describe > > - the geodetic-datum description of the object is capable of determining > relative differences between points on the object to within a particular > delta of precision, but those individual coordinate values may be farther > than that delta from the actual point on the object that was referred to > > - the values that are reported in this YANG module reflect measurements > that were made and are known to be within some delta of the coordinate > system's value that they are reported as > > - the values that are reported in this YANG module reflect measurements > thare are known to be distinguishable from other measurements to within > some delta of other measurements relative to that coordinate system, even > though the actual position being indicated may diverge from the reported > value by more than that delta > > - the values that are reported in this YANG module reflect measurements > that were made and are known to be within some delta of the actual point > on the object that the coordinates refer to > > - the values that are reported in this YANG module reflect measurements > that were and are known to be distinguishable from other measurements of > points on that object within some delta, but the actual distance from the > measured point to the point on the object indicated by the reported > coordinates may be larger than that delta > > In short, there are at least three classes of things at play here: the > actual object itself, the coordinate system used to model the object, and > values reported in the YANG module (which are assumed to ultimately derive > from some form of measurement). To talk about accuracy or precision > implies a relationship between elements of two of those classes, and I > don't even know which of those classes you're trying to talk about. Let's start with a simple baseline, if you want to dig any deeper than the well understood Lat+Long; do you know what a geodetic datum is? This is required knowledge if you want to get into anything more than the obvious Lat+Long use of this grouping. It defines the coordinates and also the accuracy of measurements. It is out way out of scope for this YANG grouping to try and explain the huge field of geographic locations and geodetic datum and systems. Thanks, Chris. > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > (I support Roman's Discuss.) >> > >> > Why do we only define velocity in terms of north/east/up, when we could >> > be in x/y/z coordinates where there is no clear "north" or "east"? >> > >> > It would have been helpful for the shepherd review to point to the >> > thread at >> > https://mailarchive.ietf.org/arch/msg/netmod/dA9olZfEVa3clGdfvNYEFXUEMJw/ >> > that attempted to discuss the feedback from the yangdoctor review -- the >> > mail with the review itself got no direct replies. >> >> This is a very edge case of this grouping meant really to handle something >> like continental drift with long stored values. One can keep drilling down on >> this particular velocity value seemingly forever, but then we aren't getting >> our work done. I think it's enough to say that if the usable values don't work >> for a use case at this point, then they don't work. > > Sure, that's most of why this is in the non-blocking COMMENT section. > > > The rest of this (including the follow-up) all looks fine; thanks for the > replies and updates! > > -Ben > >> > Section 2.1 >> > >> > In addition to the "geodetic-datum" value, we allow refining the >> > coordinate and height accuracy using "coord-accuracy" and "height- >> > >> > My understanding is that "refine" is a YANG keyword, and the current >> > module/tree structure does not seem consistent with this description >> > referring to use of the YANG keyword (since we can just set new values >> > directly without needing to "refine" the YANG structure itself). A >> > different word here might be appropriate. >> >> Ok changed to "overriding". >> >> >> > Finally, we define an optional feature which allows for changing the >> > system for which the above values are defined. This optional feature >> > adds an "alternate-system" value to the reference frame. This value >> > is normally not present which implies the natural universe is the >> > system. The use of this value is intended to allow for creating >> > virtual realities or perhaps alternate coordinate systems. The >> > definition of alternate systems is outside the scope of this >> > document. >> > >> > This paragraph doesn't really convince me that we need to include the >> > "alternate-system" capability in the proposed-standard version of this >> > YANG module at this time. >> >> It doesn't hurt anything to include it and it was asked for by the person who >> came up with the shape of this grouping (Peter L.). Unless there's a strong >> objection I'd prefer to leave it in deference to the person who asked for it. >> >> > Section 2.3 >> > >> > meters per second. The values "v-north" and "v-east" are relative to >> > true north as defined by the reference frame for the astronomical >> > body, "v-up" is perpendicular to the plane defined by "v-north" and >> > "v-east", and is pointed away from the center of mass. >> > >> > When I read this I wondered if the "plane defined by v-north and v-east" >> > was taken at the initial snapshot position, or continuously updated with >> > the effect of v-north and v-east drift. Given the stated application, >> > it's unlikely that it actually would matter, though, so it's not clear >> > that we should change the text to cover it. >> > >> > Section 3 >> > >> > and 91..126). The IANA registry further restricts the >> > value by converting all spaces (' ') to dashes ('-')"; >> > >> > Is there a reason why we shouldn't disallow spaces via the regex (and >> > obviate the need for special processing at IANA)? >> >> The thinking is to allow users to do more than what we IANA is limited to. >> >> > Section 5.1.2 >> > >> > The following subsection suggests that there is a "heading" field in the >> > W3C structure/API, but I don't see one listed in Figure 1. >> > >> > Section 6.1 >> > >> > What are suitable references for the "me" and "mola-vik-1" geoedtic >> > systems? I do not see how just the listed descriptions provide a "clear >> > definition" even for the two coordinate values latitude/longitude. >> > >> > Section 7 >> > >> > Thanks for using the template for security considerations for YANG >> > models! I think that since some of the portions of the template do not >> > apply, they can safely be removed. In particular, the "these are the >> > subtrees and data nodes and their sensitivity/vulnerability" lines can >> > go, and the clause about "can have a negative effect on network >> > operations" may be worth tweaking (network operations may not be the >> > most likely thing to be impacted). I think it's also okay to drop the >> > paragraph/sentence about RPCs. >> > >> > Section 8 >> > >> > The [WGS84] and [EGM08] links don't work for me. ([EGM96] does.) >> >> I've removed the links as they are not stable. Just going with standard title, author pub date now. >> >> > Section 9 >> > >> > It seems like RFC 7950 is more properly classified as normative, since >> > you can't really make sense of YANG without ... knowing YANG. I think >> > 8340 is sometimes listed as normative as well, but the case is not quite >> > as clear, here. >> > >> > NITS >> > >> > Abstract >> > >> > This document defines a generic geographical location object YANG >> > grouping. [...] >> > >> > I'm having a hard time seeing what role the word "object" is playing >> > here, especially since in the next sentence we just refer to the >> > "geographical location grouping". >> >> Removed "object" >> >> > Section 3 >> > >> > description >> > "A location on an astronomical body (e.g., 'earth') >> > somewhere in a universe."; >> > >> > I guess in some alternate-systems the "astronomical body" bit may not >> > really be accurate. (And possibly in some cartesian coordinate frames, >> > too, but that's less clear.) >> > >> > type string { >> > pattern '[ -@\[-\^_-~]*'; >> > >> > If I'm reading my table correctly, '^' and '_' are adjacent, so this >> > rather-reader-unfriendly regex formulation can't even be justified as >> > the minimal encoding. >> >> This has to do with working with limitations in the tools. The minimal encoding does not work unfortunately. >> >> > '67p/churyumov-gerasimenko (a comet). The value should >> > be comprised of all lower case ASCII characters not >> > including control characters (i.e., values 32..64, and >> > 91..126). [...] >> > >> > "all lower case ASCII characters" inherently excludes control >> > characters, so "all lower case ASCII characters not including control >> > characters" is redundant. >> > Also, that doesn't match up the listed range of values (or the regex). >> > (Also^2, that doesn't match the given comet name, which has numbers and >> > punctuation.) >> >> Changed to: >> >> "The ASCII value SHOULD have upper case converted to lower case characters and not include control characters (i.e., values 32..64, and 91..126). Any preceding 'the' in the name SHOULD NOT be included."; >> >> > for Cartesian coordinates. When coord-accuracy is >> > specified, it overrides the geodetic-datum implied >> > accuracy."; >> > [...] >> > "The accuracy of height value for ellipsoidal >> > coordinates, this value is not used with Cartesian >> > coordinates. When specified, it overrides the >> > geodetic-datum implied default."; >> > >> > I suggest using parallel language for "when specified, overrides implied >> > default". (That is, "coord-accuracy" is currently explicitly named but >> > "height-accuracy" is not.) >> >> Done. >> >> > >> > leaf v-up { >> > type decimal64 { >> > fraction-digits 12; >> > } >> > units "meters per second"; >> > description >> > "v-up is the rate of change (i.e., speed) away from the >> > center of mass."; >> > >> > "center of mass" may not be universally applicable, e.g., to cartesian >> > coordinates, binary systems, extremely massive objects that are not the >> > astronomical-body of the reference-frame. >> >> In this case the value is not relevant. Again, this isn't a big part of this >> specification, it's meant to track things like continental drift. If it's not >> useful as defined then it's simply not useful for that use. >> >> > Section 4 >> > >> > We probably should expand CRS at/before first usage. >> >> Done, just under the table. >> >> > Section 6.1 >> > >> > Each entry should be sufficient to define the 3 coordinate values (2 >> > if height is not required). So for example the "wgs-84" is defined >> > >> > I'd suggest flipping the order, for "should be sufficient to define the >> > 2 coordinate values, and to define height if height is required". >> >> Done. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAmDzJY0ACgkQLh2DDte4 MCWxCQ//eYcjAwHO16lQlmdwk1laXUejsRLmT0WT9pInWqD+yqqhGApm9EW0SbRh INFF7nfq+Vihw7VFm7lanGyUod5PG1oFfXbstquMf8ZNjmHByCBl+epfEDiy6XwH Pd3dXffWazj5weFfS+qMyTGyinyZIaSsw8PpIcfmTYkGX03ysvWj67gncbK18gkT yzH7D6pkoU3ovrjNmTHNGSFrRLAiAJ/PMdoh5x8/MhBgMsSB3NqOAQtHlxFBnyva E50A5aoeAquU7HHPN1g+LHijn9N46kZ771IVVc+1Yxdv5kXCKVbuZ5mdTUrP2UYF LtRgSKBptVTqlNWjXjb37KfREMO5Ebp+PDlvxXu/uLXNB0NXjthlYb+pGt5TlG2V i4MqgoLC/wcwRjG/8tHn9W3WcmSgXlOwzsVCWaz5brTr7p1YfkyHOD54FIwpr2Ik cXeO9zwkq94YShHnhD87HGj5H0QY+u3H0kYLNillbBPWV7/XOtluc9MiKE4JNkFY ynIgGsKe4E3COydx8ys4f3Og52Uw03CUDBcg8Z2ctup/h2ohkcn7Jkgq4TOrFgl8 WTiD6W710aep+Z19iQ8FbLCurpp8JcdZf90oyLiSvmIPLL4s6zg6qJkHrGJAoniM q3B6dBqJkNI70QW0jAsS3NsCh8Hvyo6qxLEGxKXmfKOTk4kjDEA= =hjym -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jul 17 15:14:35 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187CA3A2428; Sat, 17 Jul 2021 15:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 3luMaMNMZMtf; Sat, 17 Jul 2021 15:14:29 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 60A313A2427; Sat, 17 Jul 2021 15:14:28 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16HMEJDH009568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 17 Jul 2021 18:14:24 -0400 Date: Sat, 17 Jul 2021 15:14:18 -0700 From: Benjamin Kaduk To: Christian Hopps Cc: The IESG , draft-ietf-netmod-geo-location@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, kent+ietf@watsen.net Message-ID: <20210717221418.GF74365@kduck.mit.edu> References: <162146723152.27764.1299479086437558158@ietfa.amsl.com> <20210717173321.GE74365@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2021 22:14:34 -0000 On Sat, Jul 17, 2021 at 02:38:55PM -0400, Christian Hopps wrote: > > Benjamin Kaduk writes: > > > Hi Christian, > > > > Sorry for the very delayed reply (and thanks to Rob for the nudge). > > > > On Wed, May 26, 2021 at 06:04:58PM -0400, Christian Hopps wrote: > >> > >> Benjamin Kaduk via Datatracker writes: > >> > >> > Benjamin Kaduk has entered the following ballot position for > >> > draft-ietf-netmod-geo-location-08: Discuss > >> > > >> > When responding, please keep the subject line intact and reply to all > >> > email addresses included in the To and CC lines. (Feel free to cut this > >> > introductory paragraph, however.) > >> > > >> > > >> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > >> > for more information about DISCUSS and COMMENT positions. > >> > > >> > > >> > The document, along with other ballot positions, can be found here: > >> > https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ > >> > > >> > > >> > > >> > ---------------------------------------------------------------------- > >> > DISCUSS: > >> > ---------------------------------------------------------------------- > >> > > >> > I think we lack sufficient precision (forgive the pun) in how we talk > >> > about "accuracy" and "precision". Are the leafs that claim to specify > >> > "accuracy" specifying a precision? If so, the precision of a specific > >> > measurement, the precision of the measurements that led to the creation > >> > of the coordinate frame, or something else? Are they doing so in > >> > relative terms (e.g., percentage) or absolute terms (e.g., degrees and > >> > meters)? (There are "units" directives only for "height-accuracy" and > >> > not the others.) How can we we say that we'll have 16 fraction-digits of > >> > precision for lat/long when the maximum accuracy we can say that a > >> > geodetic-system has only gives us 6 fraction-digits for coord-accuracy? > >> > When we say that the "precision of this measurement is indicated by the > >> > reference-frame" is that the same thing as the relevant "-accuracy" > >> > nodes, or something else? > >> > >> Yes, the geodesic-datum is what defines the values and their accuracy. For the > >> precision in the value we choose the fractional digits based on what might be > >> needed, but not to prescribe anything. For decimal degrees e.g., we only need > >> 100s values the rest can be left to the fractional portion. > > > > Unfortunately, even your description here still doesn't help me understand > > what the intended semantics of these values are. > > > > To help illustrate my confusion, here are a few possible things that could > > be what is intended to be conveyed: > > > > - the geodetic-datum description of the object has been measured to be > > within a known delta of the actual object being described, at all points > > on the object that the coordinate system can describe > > > > - the geodetic-datum description of the object is capable of determining > > relative differences between points on the object to within a particular > > delta of precision, but those individual coordinate values may be farther > > than that delta from the actual point on the object that was referred to > > > > - the values that are reported in this YANG module reflect measurements > > that were made and are known to be within some delta of the coordinate > > system's value that they are reported as > > > > - the values that are reported in this YANG module reflect measurements > > thare are known to be distinguishable from other measurements to within > > some delta of other measurements relative to that coordinate system, even > > though the actual position being indicated may diverge from the reported > > value by more than that delta > > > > - the values that are reported in this YANG module reflect measurements > > that were made and are known to be within some delta of the actual point > > on the object that the coordinates refer to > > > > - the values that are reported in this YANG module reflect measurements > > that were and are known to be distinguishable from other measurements of > > points on that object within some delta, but the actual distance from the > > measured point to the point on the object indicated by the reported > > coordinates may be larger than that delta > > > > In short, there are at least three classes of things at play here: the > > actual object itself, the coordinate system used to model the object, and > > values reported in the YANG module (which are assumed to ultimately derive > > from some form of measurement). To talk about accuracy or precision > > implies a relationship between elements of two of those classes, and I > > don't even know which of those classes you're trying to talk about. > > Let's start with a simple baseline, if you want to dig any deeper than the well understood Lat+Long; do you know what a geodetic datum is? This is required knowledge if you want to get into anything more than the obvious Lat+Long use of this grouping. It defines the coordinates and also the accuracy of measurements. Well, I thought I did, but the fact that you are asking me makes me less sure that I actually do. Limiting just to the Earth for simplicity of discussion, it is "well known" that the earth is not a perfect sphere; it's not even a regular ellipsoid. Even discounting local topography on the surface, "mean sea level" varies due to the differing internal density, angular momentum, and myriad other factors. So if we want to talk about coordinates of a point on the earth, we have to build a model of the earth in which we define what our coordinates mean. We'll have to anchor our coordinate system to actual points on the earth in some way, whether by defining an arbitrary origin at a physical object, using the center of mass (which can at least in theory be measured to very high precision), or some combination thereof. But the coordinate system remains a model of the actual earth, and there will be some skew between them for points that in an ideal coordinate system would match up exactly with the physical object. The coordinate system will have inherent accuracy limits based on how much skew there is between the idealized points in the coordinate system and the actual points on earth they're supposed to represent. When one makes a measurement with respect to a given coordinate system there may also be inherent limits to the precision of measurement that can be made with respect to the coordinate system, e.g., if the coordinate system is defined with respect to GPS points, the limits of GPS resolution are a bound on how precisely one can make a measurement. That's all well and good, but what I describe above is a property of the coordinate system itself, not a property of individual measurements made with reference to that coordinate system. The YANG grouping we define here allows overriding the coord-accuracy and height-accuracy on a per-grouping-instantiation basis, i.e., for a single list of coordinates. But those coordinates in the instantiation are certainly sometimes going to be derived from measurements, and I expect that measurements will be the overwhelming majority of usage. Measurements, however, *also* have accuracy and precision, but this time with respect to the coordinate system they are being measured in. Instrumental error and other factors can introduce a systemtic bias in the measured values, leading to bad accuracy, even if the precision of the group of measurements remains quite good, so that relative comparisons within the dataset are reliable even if the absolute numers are not reliable with respect to the coordinate system. So, when we refine the coord-accuracy and height-accuracy for an instantiation of the grouping, what does that mean? > It is out way out of scope for this YANG grouping to try and explain the huge field of geographic locations and geodetic datum and systems. Of course. But we should have enough of a reference so that people can have a way to read up and understand what the fields we are defining actually mean. -Ben From nobody Sat Jul 17 16:17:23 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881A53A265D; Sat, 17 Jul 2021 16:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 zC2cOG4z_g0g; Sat, 17 Jul 2021 16:17:12 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id B6B803A265C; Sat, 17 Jul 2021 16:17:11 -0700 (PDT) Received: from smtpclient.apple (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 8AFCE803DF; Sat, 17 Jul 2021 23:17:10 +0000 (UTC) From: Christian Hopps Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CF5B26B2-E070-40A3-863C-C212257F49D1" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Sat, 17 Jul 2021 19:17:09 -0400 In-Reply-To: <20210717221418.GF74365@kduck.mit.edu> Cc: The IESG , draft-ietf-netmod-geo-location@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, kent+ietf@watsen.net To: Benjamin Kaduk References: <162146723152.27764.1299479086437558158@ietfa.amsl.com> <20210717173321.GE74365@kduck.mit.edu> <20210717221418.GF74365@kduck.mit.edu> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2021 23:17:17 -0000 --Apple-Mail=_CF5B26B2-E070-40A3-863C-C212257F49D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 17, 2021, at 6:14 PM, Benjamin Kaduk wrote: >=20 > On Sat, Jul 17, 2021 at 02:38:55PM -0400, Christian Hopps wrote: >>=20 >> Benjamin Kaduk writes: >>=20 >>> Hi Christian, >>>=20 >>> Sorry for the very delayed reply (and thanks to Rob for the nudge). >>>=20 >>> On Wed, May 26, 2021 at 06:04:58PM -0400, Christian Hopps wrote: >>>>=20 >>>> Benjamin Kaduk via Datatracker writes: >>>>=20 >>>>> Benjamin Kaduk has entered the following ballot position for >>>>> draft-ietf-netmod-geo-location-08: Discuss >>>>>=20 >>>>> When responding, please keep the subject line intact and reply to = all >>>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>>> introductory paragraph, however.) >>>>>=20 >>>>>=20 >>>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about DISCUSS and COMMENT positions. >>>>>=20 >>>>>=20 >>>>> The document, along with other ballot positions, can be found = here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> I think we lack sufficient precision (forgive the pun) in how we = talk >>>>> about "accuracy" and "precision". Are the leafs that claim to = specify >>>>> "accuracy" specifying a precision? If so, the precision of a = specific >>>>> measurement, the precision of the measurements that led to the = creation >>>>> of the coordinate frame, or something else? Are they doing so in >>>>> relative terms (e.g., percentage) or absolute terms (e.g., degrees = and >>>>> meters)? (There are "units" directives only for "height-accuracy" = and >>>>> not the others.) How can we we say that we'll have 16 = fraction-digits of >>>>> precision for lat/long when the maximum accuracy we can say that a >>>>> geodetic-system has only gives us 6 fraction-digits for = coord-accuracy? >>>>> When we say that the "precision of this measurement is indicated = by the >>>>> reference-frame" is that the same thing as the relevant = "-accuracy" >>>>> nodes, or something else? >>>>=20 >>>> Yes, the geodesic-datum is what defines the values and their = accuracy. For the >>>> precision in the value we choose the fractional digits based on = what might be >>>> needed, but not to prescribe anything. For decimal degrees e.g., we = only need >>>> 100s values the rest can be left to the fractional portion. >>>=20 >>> Unfortunately, even your description here still doesn't help me = understand >>> what the intended semantics of these values are. >>>=20 >>> To help illustrate my confusion, here are a few possible things that = could >>> be what is intended to be conveyed: >>>=20 >>> - the geodetic-datum description of the object has been measured to = be >>> within a known delta of the actual object being described, at all = points >>> on the object that the coordinate system can describe >>>=20 >>> - the geodetic-datum description of the object is capable of = determining >>> relative differences between points on the object to within a = particular >>> delta of precision, but those individual coordinate values may be = farther >>> than that delta from the actual point on the object that was = referred to >>>=20 >>> - the values that are reported in this YANG module reflect = measurements >>> that were made and are known to be within some delta of the = coordinate >>> system's value that they are reported as >>>=20 >>> - the values that are reported in this YANG module reflect = measurements >>> thare are known to be distinguishable from other measurements to = within >>> some delta of other measurements relative to that coordinate = system, even >>> though the actual position being indicated may diverge from the = reported >>> value by more than that delta >>>=20 >>> - the values that are reported in this YANG module reflect = measurements >>> that were made and are known to be within some delta of the actual = point >>> on the object that the coordinates refer to >>>=20 >>> - the values that are reported in this YANG module reflect = measurements >>> that were and are known to be distinguishable from other = measurements of >>> points on that object within some delta, but the actual distance = from the >>> measured point to the point on the object indicated by the reported >>> coordinates may be larger than that delta >>>=20 >>> In short, there are at least three classes of things at play here: = the >>> actual object itself, the coordinate system used to model the = object, and >>> values reported in the YANG module (which are assumed to ultimately = derive >>> from some form of measurement). To talk about accuracy or precision >>> implies a relationship between elements of two of those classes, and = I >>> don't even know which of those classes you're trying to talk about. >>=20 >> Let's start with a simple baseline, if you want to dig any deeper = than the well understood Lat+Long; do you know what a geodetic datum is? = This is required knowledge if you want to get into anything more than = the obvious Lat+Long use of this grouping. It defines the coordinates = and also the accuracy of measurements. >=20 > Well, I thought I did, but the fact that you are asking me makes me = less > sure that I actually do. >=20 > Limiting just to the Earth for simplicity of discussion, it is "well = known" > that the earth is not a perfect sphere; it's not even a regular = ellipsoid. > Even discounting local topography on the surface, "mean sea level" = varies > due to the differing internal density, angular momentum, and myriad = other > factors. So if we want to talk about coordinates of a point on the = earth, > we have to build a model of the earth in which we define what our > coordinates mean. We'll have to anchor our coordinate system to = actual > points on the earth in some way, whether by defining an arbitrary = origin at > a physical object, using the center of mass (which can at least in = theory > be measured to very high precision), or some combination thereof. But = the > coordinate system remains a model of the actual earth, and there will = be > some skew between them for points that in an ideal coordinate system = would > match up exactly with the physical object. >=20 > The coordinate system will have inherent accuracy limits based on how = much > skew there is between the idealized points in the coordinate system = and the > actual points on earth they're supposed to represent. When one makes = a > measurement with respect to a given coordinate system there may also = be > inherent limits to the precision of measurement that can be made with > respect to the coordinate system, e.g., if the coordinate system is = defined > with respect to GPS points, the limits of GPS resolution are a bound = on how > precisely one can make a measurement. >=20 > That's all well and good, but what I describe above is a property of = the > coordinate system itself, not a property of individual measurements = made > with reference to that coordinate system. The YANG grouping we define = here > allows overriding the coord-accuracy and height-accuracy on a > per-grouping-instantiation basis, i.e., for a single list of = coordinates. > But those coordinates in the instantiation are certainly sometimes = going to > be derived from measurements, and I expect that measurements will be = the > overwhelming majority of usage. Measurements, however, *also* have > accuracy and precision, but this time with respect to the coordinate = system > they are being measured in. Instrumental error and other factors can > introduce a systemtic bias in the measured values, leading to bad = accuracy, > even if the precision of the group of measurements remains quite good, = so > that relative comparisons within the dataset are reliable even if the > absolute numers are not reliable with respect to the coordinate = system. >=20 > So, when we refine the coord-accuracy and height-accuracy for an > instantiation of the grouping, what does that mean? It=E2=80=99s supposed to mean the accuracy of the measurement that is = recorded in the grouping. So if the coord-accuracy is .1 and the = measurement is lat/long then the accuracy is within 1/10 of a decimal = degree. if the measurement is in cart coordinates the accuracy would be = 100cm. I don=E2=80=99t think we need to make this anymore complex than = that. Is there some text you would like to see to make that clearer? Thanks, Chris. >=20 >=20 >> It is out way out of scope for this YANG grouping to try and explain = the huge field of geographic locations and geodetic datum and systems. >=20 > Of course. But we should have enough of a reference so that people = can > have a way to read up and understand what the fields we are defining > actually mean. >=20 > -Ben --Apple-Mail=_CF5B26B2-E070-40A3-863C-C212257F49D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 17, 2021, at 6:14 PM, Benjamin Kaduk <kaduk@mit.edu> = wrote:

On Sat, Jul 17, 2021 at 02:38:55PM -0400, Christian Hopps = wrote:

Benjamin Kaduk <kaduk@mit.edu> writes:

Hi Christian,

Sorry for the very delayed reply (and thanks = to Rob for the nudge).

On Wed, May 26, 2021 = at 06:04:58PM -0400, Christian Hopps wrote:

Benjamin Kaduk via Datatracker = <noreply@ietf.org> writes:

Benjamin Kaduk has = entered the following ballot position for
draft-ietf-netmod-geo-location-08: Discuss

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC = lines. (Feel free to cut this
introductory paragraph, = however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-geo-location= /



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

I think we lack sufficient = precision (forgive the pun) in how we talk
about = "accuracy" and "precision".  Are the leafs that claim to specify
"accuracy" specifying a precision?  If so, the precision = of a specific
measurement, the precision of the = measurements that led to the creation
of the coordinate = frame, or something else?  Are they doing so in
relative terms (e.g., percentage) or absolute terms (e.g., = degrees and
meters)?  (There are "units" directives = only for "height-accuracy" and
not the others.)  How = can we we say that we'll have 16 fraction-digits of
precision for lat/long when the maximum accuracy we can say = that a
geodetic-system has only gives us 6 fraction-digits = for coord-accuracy?
When we say that the "precision of = this measurement is indicated by the
reference-frame" is = that the same thing as the relevant "-accuracy"
nodes, or = something else?

Yes, the = geodesic-datum is what defines the values and their accuracy. For the
precision in the value we choose the fractional digits based = on what might be
needed, but not to prescribe anything. = For decimal degrees e.g., we only need
100s values the = rest can be left to the fractional portion.
Unfortunately, even your description here still doesn't help = me understand
what the intended semantics of these values = are.

To help illustrate my confusion, here = are a few possible things that could
be what is intended = to be conveyed:

- the geodetic-datum = description of the object has been measured to be
 within a known delta of the actual object being = described, at all points
 on the object that the = coordinate system can describe

- the = geodetic-datum description of the object is capable of determining
 relative differences between points on the object to = within a particular
 delta of precision, but those = individual coordinate values may be farther
 than = that delta from the actual point on the object that was referred to

- the values that are reported in this YANG = module reflect measurements
 that were made and are = known to be within some delta of the coordinate
 system's value that they are reported as

- the values that are reported in this YANG = module reflect measurements
 thare are known to be = distinguishable from other measurements to within
 some= delta of other measurements relative to that coordinate system, even
 though the actual position being indicated may diverge = from the reported
 value by more than that delta

- the values that are reported in this YANG = module reflect measurements
 that were made and are = known to be within some delta of the actual point
 on = the object that the coordinates refer to

- = the values that are reported in this YANG module reflect measurements
 that were and are known to be distinguishable from = other measurements of
 points on that object within = some delta, but the actual distance from the
 measured = point to the point on the object indicated by the reported
 coordinates may be larger than that delta

In short, there are at least three classes of = things at play here: the
actual object itself, the = coordinate system used to model the object, and
values = reported in the YANG module (which are assumed to ultimately derive
from some form of measurement).  To talk about accuracy = or precision
implies a relationship between elements of = two of those classes, and I
don't even know which of those = classes you're trying to talk about.

Let's start with a simple baseline, if you want to dig any = deeper than the well understood Lat+Long; do you know what a geodetic = datum is? This is required knowledge if you want to get into anything = more than the obvious Lat+Long use of this grouping. It defines the = coordinates and also the accuracy of measurements.

Well, I thought I did, but the fact that you are asking me = makes me less
sure that I = actually do.

Limiting just = to the Earth for simplicity of discussion, it is "well known"
that the = earth is not a perfect sphere; it's not even a regular = ellipsoid.
Even = discounting local topography on the surface, "mean sea level" = varies
due to the = differing internal density, angular momentum, and myriad other
factors. =  So if we want to talk about coordinates of a point on the = earth,
we have to = build a model of the earth in which we define what our
coordinates = mean.  We'll have to anchor our coordinate system to = actual
points on the = earth in some way, whether by defining an arbitrary origin at
a physical = object, using the center of mass (which can at least in theory
be measured = to very high precision), or some combination thereof.  But = the
coordinate = system remains a model of the actual earth, and there will be
some skew = between them for points that in an ideal coordinate system = would
match up = exactly with the physical object.

The coordinate system will have inherent accuracy limits = based on how much
skew there is between the idealized points in the coordinate = system and the
actual points on earth they're supposed to represent. =  When one makes a
measurement with respect to a given coordinate system there = may also be
inherent = limits to the precision of measurement that can be made with
respect to = the coordinate system, e.g., if the coordinate system is = defined
with respect = to GPS points, the limits of GPS resolution are a bound on how
precisely one = can make a measurement.

That's all well and good, but what I describe above is a = property of the
coordinate system itself, not a property of individual = measurements made
with reference to that coordinate system.  The YANG = grouping we define here
allows overriding the coord-accuracy and height-accuracy on = a
per-grouping-instantiation basis, i.e., for a single list of = coordinates.
But those = coordinates in the instantiation are certainly sometimes going = to
be derived = from measurements, and I expect that measurements will be the
overwhelming = majority of usage.  Measurements, however, *also* have
accuracy and = precision, but this time with respect to the coordinate system
they are = being measured in.  Instrumental error and other factors = can
introduce a = systemtic bias in the measured values, leading to bad = accuracy,
even if the = precision of the group of measurements remains quite good, so
that relative = comparisons within the dataset are reliable even if the
absolute = numers are not reliable with respect to the coordinate system.

So, when we = refine the coord-accuracy and height-accuracy for an
instantiation = of the grouping, what does that mean?

It=E2=80=99s supposed to mean the accuracy of the = measurement that is recorded in the grouping. So if the coord-accuracy = is .1 and the measurement is lat/long then the accuracy is within 1/10 = of a decimal degree. if the measurement is in cart coordinates the = accuracy would be 100cm. I don=E2=80=99t think we need to make this = anymore complex than that. Is there some text you would like to see to = make that clearer?

Thanks,
Chris.



It is = out way out of scope for this YANG grouping to try and explain the huge = field of geographic locations and geodetic datum and systems.

Of course.  But we should have enough of a reference so = that people can
have a way to read up and understand what the fields we are = defining
actually = mean.

-Ben

= --Apple-Mail=_CF5B26B2-E070-40A3-863C-C212257F49D1-- From nobody Sat Jul 17 16:25:16 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF083A269F; Sat, 17 Jul 2021 16:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bu0jsmwH1Jqg; Sat, 17 Jul 2021 16:25:05 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 303513A26A4; Sat, 17 Jul 2021 16:25:04 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16HNOuC7027738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 17 Jul 2021 19:25:01 -0400 Date: Sat, 17 Jul 2021 16:24:56 -0700 From: Benjamin Kaduk To: Christian Hopps Cc: The IESG , draft-ietf-netmod-geo-location@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, kent+ietf@watsen.net Message-ID: <20210717232456.GH74365@kduck.mit.edu> References: <162146723152.27764.1299479086437558158@ietfa.amsl.com> <20210717173321.GE74365@kduck.mit.edu> <20210717221418.GF74365@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2021 23:25:11 -0000 On Sat, Jul 17, 2021 at 07:17:09PM -0400, Christian Hopps wrote: > > > > On Jul 17, 2021, at 6:14 PM, Benjamin Kaduk wrote: > > > > So, when we refine the coord-accuracy and height-accuracy for an > > instantiation of the grouping, what does that mean? > > It’s supposed to mean the accuracy of the measurement that is recorded in the grouping. So if the coord-accuracy is .1 and the measurement is lat/long then the accuracy is within 1/10 of a decimal degree. if the measurement is in cart coordinates the accuracy would be 100cm. I don’t think we need to make this anymore complex than that. Is there some text you would like to see to make that clearer? The accuracy of the measurement with respect to what? The coordinate system, or the actual physical object? And, if the concept here is that "I made a measurement, and my measurement device reported a value to 1/10 of a decimal degree", that would typically correspond to a "precision" rather than an "accuracy" (https://en.wikipedia.org/wiki/Accuracy_and_precision). In either case, I think that "accuracy of the measurement recorded in the grouping" is a qualitatively different concept of "accuracy" than the listed accuracy of the geodetic-datum, which (AIUI) relates to the maximum deviation between the model of the object used by the coordinate system and the actual physical object. So it's not really clear that we should be talking the one "overriding" the other. -Ben From nobody Mon Jul 19 09:12:24 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346C73A38CD; Mon, 19 Jul 2021 09:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 vdS5EaciVLZB; Mon, 19 Jul 2021 09:12:11 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6B65F3A38CA; Mon, 19 Jul 2021 09:12:11 -0700 (PDT) Received: from smtpclient.apple (047-026-251-217.res.spectrum.com [47.26.251.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 6FB67803FB; Mon, 19 Jul 2021 16:12:10 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Christian Hopps In-Reply-To: <20210717232456.GH74365@kduck.mit.edu> Date: Mon, 19 Jul 2021 12:12:09 -0400 Cc: The IESG , draft-ietf-netmod-geo-location@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, kent+ietf@watsen.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <162146723152.27764.1299479086437558158@ietfa.amsl.com> <20210717173321.GE74365@kduck.mit.edu> <20210717221418.GF74365@kduck.mit.edu> <20210717232456.GH74365@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 16:12:18 -0000 > On Jul 17, 2021, at 7:24 PM, Benjamin Kaduk wrote: >=20 > On Sat, Jul 17, 2021 at 07:17:09PM -0400, Christian Hopps wrote: >>=20 >>=20 >>> On Jul 17, 2021, at 6:14 PM, Benjamin Kaduk wrote: >>>=20 >>> So, when we refine the coord-accuracy and height-accuracy for an >>> instantiation of the grouping, what does that mean? >>=20 >> It=E2=80=99s supposed to mean the accuracy of the measurement that is = recorded in the grouping. So if the coord-accuracy is .1 and the = measurement is lat/long then the accuracy is within 1/10 of a decimal = degree. if the measurement is in cart coordinates the accuracy would be = 100cm. I don=E2=80=99t think we need to make this anymore complex than = that. Is there some text you would like to see to make that clearer? >=20 > The accuracy of the measurement with respect to what? The coordinate > system, or the actual physical object? I really don=E2=80=99t see how this could be so confusing. This grouping is a location, the accuracy applies to the contained = location data. Consider asking this question about some other field like = the lat/long =E2=80=94 it doesn=E2=80=99t make sense. I can=E2=80=99t say for sure, but I think you=E2=80=99ve discarded the = obvious here and are getting pedantic about something that=E2=80=99s not = actually confusing. Finally, as we (the IETF) are not geo location experts, we had this = grouping reviewed by actual industry experts (thanked in the = acknowledgment section) and they had no issue with these fields. I would = be very hesitant to change what they reviewed as correct at this point = based on pedantic musings. Thanks, Chris. >=20 > And, if the concept here is that "I made a measurement, and my = measurement > device reported a value to 1/10 of a decimal degree", that would = typically > correspond to a "precision" rather than an "accuracy" > (https://en.wikipedia.org/wiki/Accuracy_and_precision). >=20 > In either case, I think that "accuracy of the measurement recorded in = the > grouping" is a qualitatively different concept of "accuracy" than the > listed accuracy of the geodetic-datum, which (AIUI) relates to the = maximum > deviation between the model of the object used by the coordinate = system and > the actual physical object. So it's not really clear that we should = be > talking the one "overriding" the other. >=20 > -Ben >=20 From nobody Mon Jul 19 14:40:56 2021 Return-Path: <0100017ac0b6b49f-81a63800-2569-45f6-8196-9b1c0efe9830-000000@amazonses.watsen.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD42F3A0BB0 for ; Mon, 19 Jul 2021 14:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKQo-j6Y8Fqo for ; Mon, 19 Jul 2021 14:40:38 -0700 (PDT) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE41B3A0BA9 for ; Mon, 19 Jul 2021 14:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1626730837; h=From:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Message-Id:Date:To:Feedback-ID; bh=wGLxJLs2PiaHcsVuqzA+r5v0NiaXHzGj785EJm4w98w=; b=DQ8akc+6nE7DTZ5ZwhIp2LyjDfrPx3E5V0Xm4Q3o4wmPTS0e59CkgdEAf29fHUb4 iEJOCW3LlUHKc8768AjBvlgFoLRj3lv4GHoPzVJBIId26Kn7SQ+KYE8JCbU6aQ34fcs lkJsxsOeeqYaTFcLUwPDLRCQBUrCCFe0EqnPFHj8= From: Kent Watsen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Message-ID: <0100017ac0b6b49f-81a63800-2569-45f6-8196-9b1c0efe9830-000000@email.amazonses.com> Date: Mon, 19 Jul 2021 21:40:37 +0000 To: "netmod@ietf.org" X-Mailer: Apple Mail (2.3654.100.0.2.22) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.07.19-54.240.48.92 Archived-At: Subject: [netmod] The 111 Agenda has been updated X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 21:40:55 -0000 The NETMOD Agenda has been updated. The update is an additional = discussion slot for "draft-ma-netconf-with-system=E2=80=9D, which needs = to be renamed (s/netconf/netmod). As you may recall, this is the draft = that has been discussed on the NETMOD list the last several days. The new/complete agenda is: ------------------------------------------------------- Agenda for the NETMOD 111 WG Session ------------------------------------------------------- https://datatracker.ietf.org/meeting/111/materials/agenda-111-netmod Session: Tuesday, July 27, 2021 Session II (21:30-22:30 UTC, 14:30-15:30 PDT) WG Chairs: Lou Berger (lberger at labs dot net) Kent Watsen (kent plus ietf at watsen dot net) Joel Jaeggli (joelja at bogus dot com) Available During Session: WG ICS: https://datatracker.ietf.org/meeting/111/sessions/netmod.ics ICS: https://datatracker.ietf.org/meeting/111/session/28884.ics MeetEcho: https://meetings.conf.meetecho.com/ietf111/?group=3Dnetmod Jabber: xmpp:netmod@jabber.ietf.org?join Available During / After Session: CodiMD: https://codimd.ietf.org/notes-ietf-111-netmod Slides: https://datatracker.ietf.org/meeting/111/session/netmod Drafts (TGZ): = https://datatracker.ietf.org/meeting/111/agenda/netmod-drafts.tgz Drafts (PDF): = https://datatracker.ietf.org/meeting/111/agenda/netmod-drafts.pdf Available After Session: Recording: http://www.meetecho.com/ietf111/recordings#NETMOD Jabber Logs: https://www.ietf.org/jabber/logs/netmod Introduction Chairs (10 minutes) Session Intro & WG Status Chartered items: YANG Versioning Update (30 min) = https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/= https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/ https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-packages/ = https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-ver-selection/ = https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-schema-comparison/= Overview - Jason Sterne YANG Module Versioning Draft - Jason Sterne YANG Semver Draft - Joe Clarke Non-Chartered items: System Configuration Data Handling Behavior (15 min) https://datatracker.ietf.org/doc/draft-ma-netconf-with-system Discussion Leader: Qiufang Ma Remaining 5 min.=20 From nobody Tue Jul 20 10:00:39 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1F23A2B08 for ; Tue, 20 Jul 2021 10:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JnxtOyg7zRi for ; Tue, 20 Jul 2021 10:00:32 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2101.outbound.protection.outlook.com [40.107.223.101]) (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 0F6EA3A2B06 for ; Tue, 20 Jul 2021 10:00:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D9MoKafdWhNpx+99hgv0lbBBJ4ZSNvhnkQ12dku/D97Hc/zcdvGXTB5F1kw0YRfE6IDkYcmb8gv6F5OTUtHdzVLpTpY9bvJkkkCssYbaa8VM9B5uvWmbfcItcnmhsMUlp3cza7ul9hMGme+mW3Vc4H6CuCO9cY9WUJwYGvOr8wzZf2enVI+dkAz+IZWEs9MGkRQ5x/xKxvqLbye/yA1c+j17C0uMWoISCxn/ozhL80Ow6z/B5LVFtfKSvva3mGEsZNGdNaUFwSb3J+Dod+XtKADq6he1g8HwF8fng55bzqcmqOE/lkXdCBx/5dS1WjRfGGSNvWz11Nx+4OLmjCM05g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zKzLYdtYAz9ycOzC58ZfXL7AkhC2SA1DDa6B3kVdVFs=; b=At+WlKTptD/0B1RUu/RzOfHOQpV2pDzsID1saUvNq595YvGQezndEOc3HkYZd0xdyxqUaZaQkmXQq+/PaBBDWCabXudgJM8vDIdTimZV+kekdxnxRC53QjMBupDVSCPfadP4BX31KXfgQ7WNYDTbr17HgAmefC1kV5nVdv5hxq/abmxag8NVvTyYkbAzMkblkYxUe/isoWBLuauFLHOZW4JbSsDLWHR6pzNvMBmB28xbye/Sl6A7x2nBnbSLccrBArpxjLs28nHjbza8VOvhWWd7voYxdjSi82vWoRqvYWcMhtmCPbr/awNMFV5kpDG2/vw5n+spqHwXWMkA6Rk6zg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zKzLYdtYAz9ycOzC58ZfXL7AkhC2SA1DDa6B3kVdVFs=; b=iNwOxON4AuBG70HE7PfCWgJT9moN+NWIpfyz9q0zq9AQaTjMJPcLXK3V6PExlS4E/9dkI+M1aSjlfx06VfeolQ/5LOYuYnqdP/meJm2Y3nKxBjOvGhYSD8/UfCdsBYneNPmyg7DoMM8WbSWAw4JU3v4JUbmu1mMni7XzU6oCQEs= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB6315.namprd08.prod.outlook.com (2603:10b6:5:1e6::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.23; Tue, 20 Jul 2021 17:00:29 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::1c4f:c615:7111:f171]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::1c4f:c615:7111:f171%5]) with mapi id 15.20.4331.034; Tue, 20 Jul 2021 17:00:29 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG Versioning Weekly Call Minutes - 2021-07-20 Thread-Index: Add9iKXAMbzmDsPxQy66mJgRJL+EQA== Date: Tue, 20 Jul 2021 17:00:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f0c4e888-02f3-4904-02df-08d94b9fe0ac x-ms-traffictypediagnostic: DM6PR08MB6315: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HfcPiUuedKfGx/sRd/W0L/ZRxICGAnG08iKo2f+JCMDAvwlcq/xzu90ZiAy7KYhOrByK3ETHsDUlcTXn/drnC8k5KIs4zVmLiw4Watiib9IoQ2UCu4KCipbMy0Xd6CxafljWvsfh1OKY8PIIfSl/C9hDoFiCuyI6v1ylPWNtytCMcCv5EfLnzP7uNehT4dP56cTsb0pJSUYT8D3AhUw/KMqFunva/xeI2rSRbVKaCQPFdKfI2mNp2F+Bep9IrvEMZJ6hjsYFkiukourd95OePl17RLaPEJNGeEvWLcp4XXAB9T5kSVn+JETJ7uMbmgCdYxw9nwUUX4QN/wTC5f4q7tBg6xZWfjVRjeSygctAFQ31Iit/e9Uq7fs3TA1ZBg0ItDS2Gwszo2R+/TI3eNU6OrwJmodiR1BjVR5Cx7a3g4zbnF3CQx+7kZnqo+OwiMRFxIT8RyefoUeeJqZAIvfwwS3tyrYSwQQauN+tWHlX0+Vm3IBiSJ/v1OjpMTC2f7Rdl45Fm/wNQHSVpugoGS7LTVcfalZ7seUsvOUC5SVEdrlqgv8PE/FvWX2CfKLzZ+CFxnAAHKMT/Bqo3hVdH/DSJES1+q3fbNdRTpywoECfE8XlbKTKsarhBF8h444PeLAV7JnvsqMYhk32npxfblZHbxyvD+eCDjJQactD86wpjj3aYsSXkhsPles2p0zbR5QdfBl7Od0YqDvv/eI0L0J7dvDBvsezT8OGNXSeevNrEJHAANqzRXwLm2AKcMqfSzQQJ2qPkzVdAX9mRKfK8LfZeto9jkobT5DkY3cwDM1Msp8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(136003)(366004)(396003)(376002)(39860400002)(478600001)(6916009)(66476007)(7696005)(8676002)(6506007)(66556008)(26005)(66946007)(86362001)(8936002)(76116006)(33656002)(966005)(122000001)(38100700002)(66446008)(64756008)(316002)(83380400001)(16799955002)(9686003)(55016002)(2906002)(52536014)(5660300002)(186003)(71200400001)(38070700004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?VC2ta6KB5qixH2Ffh+3gsiGzTLVP8WOCoU/LnT+emYJLJ5TnNNBJho+VEgp5?= =?us-ascii?Q?dLjO1aum5k/BuNpmw6L0fvnFlxmaSMYCrCruIO/IWXwBf2iV4gnSHe98Mn2L?= =?us-ascii?Q?zhCWILjrSNnnmTbIo3aAlTVKuJqNatDv5Zf8u+/l3OOg2PkQ0eD6VkP7ft7R?= =?us-ascii?Q?a3iTzRe8qlfUZbkeoUJdQHg605upHxIuyvf0sU96/4Lx9MGTUxlxOf4dMLfR?= =?us-ascii?Q?v7QMtnuQ80nmjvcWHuM4XeMaza8MgI8axrPT5XTDCA1QvvL93iMJPpxvamjB?= =?us-ascii?Q?YIgM7u0M87KdDtWXkl3UIqkh0sfdyiUdVU49Ucri+keeleh5VyPgF4a/tjfO?= =?us-ascii?Q?wIMuFRryU4sBovqfE8vbZNnvkXt+4o1triZk/1hDCGsqXlQ/P0E+MVMeIcg5?= =?us-ascii?Q?IAJXny0v77ZsTcgmK35SgpseNlXdnyLyFdGPYm3HeUHqX5d4Vc8NDMygogwc?= =?us-ascii?Q?TsCpqCz0R6HRz6NuKFq1L+mHim4lxhF+5lHU5wSEedVUPhrdukoRxz/IzzJ4?= =?us-ascii?Q?zls6gB1jBkcXMUZiW6/8c43dYR7RZ+YyLHqJoR0hw9xHOju3qIW001g+RomR?= =?us-ascii?Q?fZ9dGP1Bsw6azx3QDbUnmfLGAjWk9///GeXxitmuLIXNgMUrvXHLdlvYUYTK?= =?us-ascii?Q?lVngJRoR9/3sjzjFmBjQTgcJoYAhLB159JRIx4GGDqVmMLYPzzBKv8c+X7xa?= =?us-ascii?Q?feaazDFoWL9VONKZrGYB9xye86qsd9sGablScZsSEA2K1zUDbxNKiaexXmTD?= =?us-ascii?Q?TS52FO/kH8sJ3M9CkldegSjuQsUycEUZedMui+A8I8/rKREoukbgRxQpJC0c?= =?us-ascii?Q?rV88V8YfAuJ3Ii7xTVXEalwfLcTFPPS6gwCRZwwFZ1AjAOZW6GLKQTO0TcdY?= =?us-ascii?Q?jLM+OzdnpKSl2OROnM4MtQPG4qhkRwRUVSxUIYT7q5fASk2E06cN069U0wP8?= =?us-ascii?Q?Um+x5/pWG2TFucmChRGQYm2a+84OQF54o1jO0WssMnAmiyAUhVWK+okSnsRf?= =?us-ascii?Q?WtXOjDBGA3LQK2J7iigN4tu6TxrlHFQ+5mpDvuhZffTems7JSax/gsPjpI8d?= =?us-ascii?Q?Pqo67bstK06NceJ//k+1E2Jo9mPlLgWSkcfgzqpOGwroX5slLmUJVIs4hGyG?= =?us-ascii?Q?ZkiHYQeL+pzlZmnMoO0E45t0/Ft5h5SK5QdLWtyAbxO6IgjUxTw/NOQ0hvTb?= =?us-ascii?Q?IZalsHfp+WfkeT1LEbRuQ9KTr8CH5McXysPYER/oHYL+pr8vRG3DHw/H6H5q?= =?us-ascii?Q?x8XZlYpLKav+vG5dZM6ehanavA26fwdjSDZNs9GPqNDdzqWLD4Swu6knUZju?= =?us-ascii?Q?qDXR9Hnaeq/vVJ1QWTUJD+pQ?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB508447F35EEE83DC6B819F179BE29DM6PR08MB5084namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f0c4e888-02f3-4904-02df-08d94b9fe0ac X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2021 17:00:29.0088 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZkkLSxBvGQibSnAZqx6sBKCxah94Ju5GNhd3NMZEaShafgYLwO9xakmd5ARft2RDlgl37qb2Gv3mPTF5VhkOtw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB6315 Archived-At: Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-07-20 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2021 17:00:38 -0000 --_000_DM6PR08MB508447F35EEE83DC6B819F179BE29DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YANG Versioning Weekly Call Minutes - 2021-07-20 We reviewed the IETF111 slides. Jason, Reshad, Joe to submit them in the n= ext few days Remaining open issues on Module Versioning & Semver drafts: - include as part of yang 1.1 ? (in Jason's slides) - text for removal of history (Rob) - top down reviews We started going through the open github issues. For next meeting(s): - continue review of open github issues to classify/tag them - plan for Packages work (editing, drafting text) Jason ---------------------------------------------- Weekly webex call details: Meeting number (access code): 171 069 0374 Meeting password: semver? Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, Au= gust 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Cana= da) 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) --_000_DM6PR08MB508447F35EEE83DC6B819F179BE29DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

YANG Versioning Weekly Call Minutes - 2021-07-20

 

We reviewed the IETF111 slides.  Jason, Reshad,= Joe to submit them in the next few days

 

Remaining open issues on Module Versioning & Sem= ver drafts:

    - include as part of yang 1.1 ? (= in Jason's slides)

        &nbs= p;       - text for removal of history (Rob)<= o:p>

        &nbs= p;       - top down reviews

        &nbs= p;      

We started going through the open github issues.

        &nbs= p;      

For next meeting(s):

- continue review of open github issues to classify/= tag them        

- plan for Packages work (editing, drafting text)

 

Jason

 

----------------------------------------------<= /o:p>

Weekly webex call details:

Meeting number (access code): 171 069 0374

Meeting password: semver?

Occurs every Tuesday effective Tuesday, September 1,= 2020 until Tuesday, August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) = Eastern Time (US & Canada)

9:00 am  |  (UTC-04:00) Eastern Time (US &= amp; Canada)  |  1 hr

https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7= b770537cff5f5b89293c70

Tap to join from a mobile device (attendees only)

+1-650-479-3208,,1710690374## Call-in toll number (U= S/Canada)

--_000_DM6PR08MB508447F35EEE83DC6B819F179BE29DM6PR08MB5084namp_-- From nobody Fri Jul 23 12:37:19 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E952A3A14A6 for ; Fri, 23 Jul 2021 12:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmijFg-5STDE for ; Fri, 23 Jul 2021 12:37:14 -0700 (PDT) Received: from sonic314-14.consmr.mail.bf2.yahoo.com (sonic314-14.consmr.mail.bf2.yahoo.com [74.6.132.124]) (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 6B1033A14AB for ; Fri, 23 Jul 2021 12:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1627069032; bh=YeZ+mM/qv8uIGaDHy4ASLKQSxyJDl1gHmVN8tLvNL3A=; h=Date:Subject:From:To:References:From:Subject:Reply-To; b=GH8niL7XfpNGVGf1zJfw0reXxjpaRgU4GzBfq4MjR85bIBFlKJBsnmWU1AIazrkNs3yCu4c4D8BDUOeNRn4hLzF7HuzjVd7LMs1DcFIL4dAfU5304rs2q0rzKE66neJflWM2kZbiyF1LsPqm6vASSNF7vlFYY+cHF3Zg3kLYqJOYOTw1RT5dBpUIYw9H/zTvOyrl2C3MgKQ1oooANAijNyabOxsMBFGlEWTX26lN6VJDf3WACql7fBUsF0RvV6vi9UabEEkOgcgYEvtfi9n+3xFp93BvdG35jDkTBbAMSXTLKr4Sa48qc3pVvTnh7ebtcEwTHGwIvnyIoN+Yacju5A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1627069032; bh=UhgGi7998MhSR0eHxXw3EeOXqWaJ+8gPH+e7BTZStD9=; h=X-Sonic-MF:Date:Subject:From:To:From:Subject; b=PhL21x3tfhfP/50VjfdOatgaAAURBg3pOHT396XzjorpXeFFv+8CSdvL+sSxr4gCv7lu+QRtIGf6ptRNx/UVB5Q0J9ClRnqgk4tT4i9Q+tm+WF5Eg2hP+qjVaUNhcPj/tfy0vJTscXbbUP1kWLiWmkRzv0FFW7aSHjTlpsnEj+S46cHa6xhRDmtaEawMFpW4/OdGwX9zTitw2SZ8H9EFEVBXjW3IvF86Hsv0oguA768OEnp5eFBOaLvj+mZkO4VdiYjDEIATUYLpFegjNqeMS05oUSv5dKylGEg2zf+aLK2TLLFWQnI4VQ5Xnv+q+I22Rv5AvGjANO/MfWd/p2Pjig== X-YMail-OSG: lqLwzAwVM1mEzwnqbX6gVxw4W1Yy78sQHIrW0dW6vKsA0IsFKLSM5xgAyty1wXZ cKxNTpIdS7fLVAj8Yh4Fdu5gIb3_JLkCtDmGhaqnRxAuoeC76bIJDvhtop8ovNf1mlMdcMkyde8W fuGWqlbcMyykBxqoX8VQn5QE6p9KEMzRnfqK5mFXRHJ4Ct.JoxGpgw931xplrUPLGY16we3wUo.P 8eIkqok2No_FuucpCqtqLMGpo9wvupMLBdkIU8qqW6rl0FV2SbnPnaDzUhwpwdbhr5UbnUNBM882 xhLRyqZtR3Ub1yBrXG6addJ03adKEiNEyfKp7ImaktRmR4NDfv_x1uRJQJ.ma6zPudqhqnNKChU. iACDTA8STtnRbPWhNbqxgU4Ds6YkWvJiZqEJJ09lmBPuxEbFWOJlJdr20skjxPtWqp9br7Fh59Or rbhfI1cd7sisi68U7Vdf5YRppe3uD4W6Mj_3EUIvOvVF7r10rAj5W5U5mr9sqmGQAOrtuT_mlddh hctr04FAT8nhVByP1N3Pyz1RgXG87yIjGC2rV8LZpTK5xUvUlKvy6u3dprdhVi7YiaciPlgWBMGH sIwbmhXIRtknU3bLPhon2_NeXZCa_v1Vo4CSMAFa0EddJfLS8UBxlB6X94aKe3eKjgpjXv_UVy5V sDShhoYyJrmrNUJr1iTYa.c4tNohxVr_Lsq6QSLJu9SiIy6EE0hP_NQSy.2ieJYsK3RHHMODmS6a Xdc5.3Jgo4gdlUMTpxRWUxl5tTT9ypewT.tjzLCwmQqt98ZC.vSneNK5ARUlb.PYjhy7s8RuO9Q_ TzU6wu5VCpAQPXINiUwVjryESqwD9._bxz_5cTYeQfLOqja7_w24qQ955xj2XkndJKm6rslXYQjO Q9J95dAdVUvGnxqlsnr4gOBwcIHG5rmqmO8aOsmpghvmcWCHqVI9Bsgejgx6AMpP7ysVdu2Sb2sR CdLLy970mgY3Q65cuWuTQNuWC6Nmb.8pw1jEuVxWR4duTQCp0rZBob1eSGpXUBXkI7341WsRnUZ. IOjdEuPSl51yfCBQ202IZZrfpNyJ2Uq8Ko8DQFGAZ6vJ1lOejkQPamlz678SlBc.riVFPpzt_cXl tVqpVD1NNve.TII.Wi4.WruPZ2VNv9J6GaZuTlo2YpnHEk8j804FCqpgmA9LYEqnKi8l9FfJzUyY k27pTlFll68vaKliZoiPqfTz_bhB_9KjxNahaQ3bB4sPnDnzhxrICBwOqRLSmZ6jlLI8AWTTvllk WckITKgBkXnwEpLWi7qmHD2Wt6GvCidBDDkmplDLqj8xA96XEePQUTOXjHIYyP6s4O5VLUwttMAL frq5s9dBgmg5VM2HsemQrYh3I83CfI_Fuz4g9FcQEI43cWxb.DqYPYXukAkAFaXcqndwGA7pFplo E_cunhLT9SiyaxHzI6dfYpmb4XzwWyc1AK1YgiQBUYFGQDbL9aJlJ7xxFNy_MGCrqmNzB.ijQDsf HjbKbR1jxvrQ4Yug_sJ31HMr2CqPwbCMZy8VD8CSnXVTyBIUHhyLmn3.koSLe7wvHAYea__X7AK2 HIiSI9brEGkdjQI3DxJrb7BpB2ABsM3tEK99YqRovFXUMpAPd4NAzCx227fOhjpFaluQo2lUqMig 1ifbzkI1tt29EzMjK0rAkHHKZloRO6DOmbVHVb8xlgd0sINarmmoxSt5dwzHn5ZCYcXflLEAsxOj oNrvMJ5KJgbna4FzbdeRo12qJ89hitqqbhLz_fmNwExYqY_3ljTdjx0g_ecteIS_JfVtzvc4JapW BK9spjxBVeB6I1rbTcraTZlwv7BuhXmVRDo5qR1avcFnUZ4eRhgTGfUjER0Bof6XKuQT.1QPWA0c 1eispEnbe4bTVlJYQLSozhxyLsqGIWLPukDiamhOKgFF6QrFbDQzT43J0idmigQXMJSIGNmwpsMZ _yPqnakclByhxkTEbbkmn6lQxf6N40qSD9HtL.m6PraU3UggLceLOV_87290nLU8vk4KK0I__ULV DvY6kw4h01Ej.es0mLNFKiEcn.JGFahB6EZe_soDr7PhGCrKi4RjYRoHiLFk8Lc88yUR9mZoKPvk 09Re_VutKdJGiwQGqN7.5gqvPxPiFXVV.DMZZidDH255fEO3NiTioRsPnDo0kRWOuqYpWwkbU0Vf c4WRKtUwKMkziI2yxJdlqkIv6rrFKiCdOVpEN68ZQd9wvSepnOkoc4pGIXMPwFNZhgrLhIUfGYAi wqbhiZgOE03B5oNkcDYhoPvEQ4Ya.0YZXwIMZQSLeL6s5G7pVfWdaNLREbUKtyeLUu_evKNhkIlK hNurrvwbOY7Xn5DFHVk_MJ_CzVKUZ077y1NHm.9DGSm5WrknSnYCfU_zN2Y2ZAF4FKC65nmeLPzQ nS.ox1FhsGyCb2XrHzwPalMnbKM0y.qIzmWY- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Fri, 23 Jul 2021 19:37:12 +0000 Received: by kubenode548.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d41371ff4b793c8a76390976fd1d59e1; Fri, 23 Jul 2021 19:37:10 +0000 (UTC) User-Agent: Microsoft-MacOutlook/16.51.21071101 Date: Fri, 23 Jul 2021 15:37:08 -0400 From: Reshad Rahman To: "'netmod@ietf.org'" Message-ID: <0389F402-269A-4207-85F0-05FF4E793CCF@yahoo.com> Thread-Topic: Link-local address Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3709899430_1339983057" References: <0389F402-269A-4207-85F0-05FF4E793CCF.ref@yahoo.com> X-Mailer: WebService/1.1.18736 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Archived-At: Subject: [netmod] Link-local address X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 19:37:18 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3709899430_1339983057 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi, =20 Are there any defined types for V4 and V6 link-local addresses? Didn=E2=80=99t se= e a definition in ietf-inet-types. =20 Regards, Reshad. --B_3709899430_1339983057 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi,

 

Are there an= y defined types for V4 and V6 link-local addresses? Didn=E2=80=99t see a definitio= n in ietf-inet-types.

 

=

Regards,

Reshad.

--B_3709899430_1339983057-- From nobody Fri Jul 23 13:18:41 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26FA3A16BC for ; Fri, 23 Jul 2021 13:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jacobsuniversity.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 qlXgF_3wBaj0 for ; Fri, 23 Jul 2021 13:18:35 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80058.outbound.protection.outlook.com [40.107.8.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 617043A16B9 for ; Fri, 23 Jul 2021 13:18:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O7Dw5sGqbbD0BqVpbQN3djT7n/3Ag5+HV4rlRxW7vgwtpF+AUJKsALTYPSKLv3Q5W8cRCYxhvrfQkI7Q0l+2fYIg1V/u1t+YO4Qle4YMshXlU/j+F8wYyBimP8o7KUJMkel2lkLAsW1vwRww7QhMRJ5j5FzALL5e8S+7QouO3nma7bKqm5hA7qEKkwZ5B1cUrkoyTxU9FxwW6Kpqnfitv7tAo9ojDp3ZP2/7PRVC148l20LyI3kTVaNhyYlDHVtkTURwQ8m/fKBtHxoHYKkDC25lnmJKd881USVybq4/AOFgQPS7aCbfskTj+hUdOhUeNRU4BzGFvZ1CViro0b5gjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LP8iJJ5Iu8A8QvGum4TADdx3AGHilPjE3H4xWCWtxZ0=; b=kOWDKnwDJKFnP6x65fGxBiET0FCdDdEZQaoTIylP1NN9/Cg7G0XZueP1ZqDgXdj/06nPgsNtY1lFBQKVk3xsqhVxin4F3hqhSJaVcYDd3EC/f+geE20U4LtVDkqm4BEgbPtKoMIHMibVFhUlFKXHskXo5nwjJn+ooThoLq2iUbZdDJrgXQtfKCQyLZzEZC0qr5CemJ3teuPJ1aQ5DqHY+QRmaYL98HHSSHgg8TOmyMgbRuQERTiXmvGEd+4mCBqewY7P6HaRgCyJIJXUsQkfmnuBwdjH5bC95ZsavJ7typMDEc0ThpRHNRcRYOtfkLgWL46zc9NgILAk4EArcISCPQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LP8iJJ5Iu8A8QvGum4TADdx3AGHilPjE3H4xWCWtxZ0=; b=qFm2SDuKPE3jyH1iEbuMwh7YnKhrZIkGKpesSnbWjlUorzFo6vdOchDdQHJLaMnxcGMo6nprrFWKuJTMs4mT/30Y3hV75vXJAlA+MgeQAjr+gR879WB+H+dQ/EsM5j2pTZL0Ju5awY/XWWeTbiWM7pSIrG00xAuOnwEhnRtCngw= Authentication-Results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=jacobs-university.de; Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM9P190MB1428.EURP190.PROD.OUTLOOK.COM (2603:10a6:20b:3b4::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.28; Fri, 23 Jul 2021 20:18:32 +0000 Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::58c1:599a:1d3d:cdeb]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::58c1:599a:1d3d:cdeb%9]) with mapi id 15.20.4352.025; Fri, 23 Jul 2021 20:18:32 +0000 Date: Fri, 23 Jul 2021 22:18:27 +0200 From: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: Reshad Rahman Cc: "'netmod@ietf.org'" Message-ID: <20210723201827.t2aoxkora7uw57le@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Reshad Rahman , "'netmod@ietf.org'" References: <0389F402-269A-4207-85F0-05FF4E793CCF.ref@yahoo.com> <0389F402-269A-4207-85F0-05FF4E793CCF@yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0389F402-269A-4207-85F0-05FF4E793CCF@yahoo.com> X-ClientProxiedBy: PR3P193CA0047.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:51::22) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from localhost (212.201.44.244) by PR3P193CA0047.EURP193.PROD.OUTLOOK.COM (2603:10a6:102:51::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.24 via Frontend Transport; Fri, 23 Jul 2021 20:18:32 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 455d2e07-1289-427f-857d-08d94e170aca X-MS-TrafficTypeDiagnostic: AM9P190MB1428: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: mzF8nsvRL9Df0G+5ZrvFQnlfg+yzCp3AuyFzE7WbnLu4oTZ6YLZSMHsOn66h2D/UdeiE385AvkiHNW432Wmzr3rhG/tcQKBZrUHRLBicO/ojRl9Oed+FezmxswQTDHbWp/D/wNMSsE0MEVx/qZ3BNzfHbjD9J425PBl3E735L4OjTT/wf30U4MaXt9IQVGtmW0JsGfqCZ/DNGXlNeuFGhHlDWwFhqlYn2AWOlkWjaMNVC/mETG1VdflVh9jDB/tOjs2G6BgBjCer5MlA42RGWZlvICjWnKyK4WFOc1+fYXan43W7CV/Mg7F/LDG+9St+H3I4gxhNqUJltwwLwVA1BQBuxe2WWVFTm6ixr19rR8YOwZ6fqr2Vyu958egFsTtKuFbnlkRs+qqeRgjDTJ1+wpfnR35DvVNKdDCWFybNdd+6ZX0iHH9tBHu4Q1yI16MoM3Ss+H76h0kTz9zoOOXOBboPB7eAfJHIt1SJhMfDi6NmkGcWa/oEgghWIPVeuri6sswWXxuq54Pdqt6noqcr2CSc3I+S8xZ8+r2NC1+iZTqFZVT0ZI/Ito7QBt4JWKOGmcDGXoopEEXK5l/sq0kztYbho+QFE3pjf3IQI9ug+hVKD49b9zhDKxMvUcGEDSwFARC7255qbCWEJpidueDrrfYry1jq4BxmHdqCz75g1139GhBi2ZbQOKAO2LfF6qZF3krxmbfO/Ym9LWxh7uDT9OrEc2VOlS09CSjXFjfd86UZccl5VCn5BblzEaTste6imuBRDytmf3VbZuIq9MCSQQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(38350700002)(38100700002)(2906002)(1076003)(66946007)(66476007)(316002)(3450700001)(5660300002)(508600001)(186003)(786003)(52116002)(85202003)(66556008)(6496006)(8676002)(26005)(86362001)(8936002)(4326008)(6486002)(85182001)(956004)(6666004); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZkhXUTN3L2NVVXg1a2ErcHZhdXZ6WFl5RlRQdjZJZ250M3R4ai8wak8ycVBO?= =?utf-8?B?cWl4a3RMcTlYNUlQM1hsSmtqbFN5dzlvcWpNc09kaHc0YTVEWEx0UEkvRUth?= =?utf-8?B?MDJwNldNTVZuTlRTZFdxdWdiMi90amdmbFpqRzI2VExJaWN0dXVOYWJiVVJ3?= =?utf-8?B?Y3FhdWtUSHhaQU11WmdwYk52K2liTXF3Z01UM2RkbHpIcXVkNi9SZ3JVK3A1?= =?utf-8?B?UmpJazNjamhBNENDL05KdkRSSzM1UmtaeU8rYzgzRnJVSzNDU3BkTnFOS1Z2?= =?utf-8?B?UnFFNWh5T1BIelBDMStqbGJzNTRmZytSdTROL29Fd0dMOEFPMWlmWEt5aCtk?= =?utf-8?B?S04yZUloM0FhUThrQmt1dnpKVDV0Vjd2alNHN0NmQVBYN3ZTcE1tMitmMkZH?= =?utf-8?B?eTU4RXhHWUVyNHlPa3VhNVVrdko1TjAveElXeWhZdTBISVJkbnU1Um9XRlA2?= =?utf-8?B?a1Y4cE05bW9KQWZaczRzZjVlM21lZUM2a3pDc1h3MlBSZmZFV0lTckpzZVV0?= =?utf-8?B?ci9HZkVoanBNYnJ2Qk1tdS8xejhkQlYwcndGNDJ2aEN2RmVkeTg3Zk5nQ1Fw?= =?utf-8?B?b1BNZThQUUhBdGcwRHVrdGl1SE4xeWR0dmJMMnVpNktwMXBnSWdYTkxpNTRh?= =?utf-8?B?OVo5Z21mS3VYamY3Wmg0OHdXdktpWHdyU2wwdjRiZEhJYTFpb3JJdllhQTdo?= =?utf-8?B?WVhHdVRnSFN5UlpLaTNOMGlIVWpHWm90by9sMW8yVlpnYnZ5a3R1bDgvdzdQ?= =?utf-8?B?QjdsUlVyNTc0VFVNVFdiRjJVUHY4Ky9jdzcrSlpGY0YxMGJBa3VhRW91M05w?= =?utf-8?B?OGRhcVhsYVpsR1FLc2VlM3NEcng5blBXT3FFd1dtaWt0WjNqNmQ4RGdpd1Fw?= =?utf-8?B?anNuT1FjTnU3T0k1QmZtaDBMSFFXa0ZMa1VCQzFrTjN1bzU5WGNVZHl5OVV4?= =?utf-8?B?UG5KYnpQNStVc2hnVFduR3c1YVJZdUpKTWJpZlpIckdudmgrN3V3SUhIck1W?= =?utf-8?B?TGRHZUo1U2Z1cVZXSmpyRDBtQnN6RkR6RXlCM1Q3dFVxUlF3WFREbEFvRWlv?= =?utf-8?B?QXQ0dllxSTJsNzJiOUhNQThTbUN0SG04M1pGWEVBNFBsbS9kU0lvbENqVnhI?= =?utf-8?B?UDBjd005Q2pKZUFSS2VQdXJOc0xhbXppalBhVVVVU2h2aTVFNEVaQitjMVJR?= =?utf-8?B?TFFRSzBSM2RZa3VqaTBZdWp4dFByTVJzREVwVTRaNDAwV09vRjN2OWxuTzNp?= =?utf-8?B?OFNuU0UxcVU1T3JsNDY3dUhXWERHcFl6dVg4bjhDdDBOa2FoU2tHeXlnNFpM?= =?utf-8?B?aUl1STZMemhCYUJsd3lyVkFwTEQ0QkRjbFpCMWlleUJFeXQwZW1raUQzSVY3?= =?utf-8?B?YlcwN2JnamJydVhwZzVENERIOG5IeW9jS1M5WWtBUzcxMHFOeFA1Wmt6RGxj?= =?utf-8?B?anpCMmZkYkdMc0kwTis0aW8xRVROWTJLZ1pzSHliYVdSMktFMThnMDhDZjRw?= =?utf-8?B?YnNQUU9TMmlXcjBpcFZKajBTOWU1eXNqYzRJdXU1Z1JzMklzbkVjZ1NZamJ5?= =?utf-8?B?ZW1uUHpoRE5xQU16YWpVQTMwcnBxa2dBMkRPYmR6Y3NHMGhyblRtcnJNOVd0?= =?utf-8?B?SkllVlk2UC8rYzhEbnlHU3hIRlpHY242bVdWYmhPQTNlbW1hdjlib1VMbThJ?= =?utf-8?B?YnBLS0QrRUwyUXJlaUVaaVJHamc4L3FoUkkzaUd3bkt4UlJYRk1icDN5TXdH?= =?utf-8?Q?VKY1De/y+KyG+JpF94tYY4eOSytLrIeKfy+t3dy?= X-OriginatorOrg: jacobs-university.de X-MS-Exchange-CrossTenant-Network-Message-Id: 455d2e07-1289-427f-857d-08d94e170aca X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jul 2021 20:18:32.3517 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: yJTnV0WLz4AhCb6illL++A2kzAwmhb0Yy+i6lkO8eiP6BCw+y6yT90F97DYCyPYVO1FB1olqwnppUfickiRsoZLPZNprc5R06wXUIE1R6E0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9P190MB1428 Archived-At: Subject: Re: [netmod] Link-local address X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 20:18:40 -0000 On Fri, Jul 23, 2021 at 03:37:08PM -0400, Reshad Rahman wrote: > Hi, > > Are there any defined types for V4 and V6 link-local addresses? Didn’t see a definition in ietf-inet-types. > So far we stayed away from defining specific types for the different "classes" of IP addresses, such as link-local or multi-cast or private or loopback or ... addresses. Since an ip-address (ipv4-address, ipv6-address) carries an optional zone index, it should be possible to derive further types that add a pattern for the specific prefixes, e.g. something like this: typedef ipv6-address-link-local { type ipv6-address pattern '[fF][eE]80:.*' description "A link-local IPv6 address in the prefix fe80::/10 as defined in section 2.5.6. of RFC 4291." reference "RFC 4291: IP Version 6 Addressing Architecture" } Translating the prefix into a pattern is a bit ugly but doable. The pattern does not try to capture all restrictions but the description clause takes care of this. ;-) /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 Jul 23 14:00:58 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A223A1943; Fri, 23 Jul 2021 14:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft4991094.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 aShBLvjuJAq1; Fri, 23 Jul 2021 14:00:52 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50073.outbound.protection.outlook.com [40.107.5.73]) (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 745003A1946; Fri, 23 Jul 2021 14:00:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kZppZpH+a1uY2l+kcfWI2lgm5ucLoljHjroBRYsIzEsXJGm48+5AuJFx6QS3VXWDZ/wJch7mai/RnKFxgslMjUun66NXSA3ppKxYJNuYJjHBUUmiFZd+LUfT8um4ccXRlUhTh8YKohnO2mxat1WG/sdsjmyaKmjh1NUkoLUp6FHdnTtSrR6NmeRCCBeU6JsJ2+q90y+gjd2x7oxoDX1CZRLPQWn+fW8SD8PUGxmpilJWMqmJvTv9IZvb5F6/eK8vGq0eoLPLH65TTb8paHvJxoYrQspt7nsxWFewQ7Gx9eeas0Dis3pCyy1nwEOrdCXO3Q2M8SCSfkobxil7buDLrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZnHlljuVDa28uWaa6s/IE/7mNnYzkp2z1jiL1aNMdPg=; b=D2iX7ml8Bdbl8ujZr00lfgwFOG3qSDy0WO3AxqnzT1hSUO7/niqqUWT7iKUpAj0q8dx/v/D05cyzHE+9dSQfL4LSbpHL8qjU0rlteH+oX3agsGkcyHzf+R7djsAdNBdAP+lBj2gHXmWs1MVP/zzmr8YCqSVeiZo0ef13jqUsXaTmk+jmkkmUkrkPwxPb1akfa1AarsrBTITFoTI3J10btLhQZDq55fzzuwu7hk4dgJDI7iGDK3B8Q8MMB5JI2R1pu3A3Q8/8V73XjW74YeyG+HDRk9JnxwJw7dXwBV3jrKOPnsDv2vZgPrFFfI321dPzY51vl4+92cmhBQvXQQvk/Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=lightside-instruments.com; dmarc=pass action=none header.from=lightside-instruments.com; dkim=pass header.d=lightside-instruments.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT4991094.onmicrosoft.com; s=selector2-NETORGFT4991094-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZnHlljuVDa28uWaa6s/IE/7mNnYzkp2z1jiL1aNMdPg=; b=lT5NuDG1Sq7qY8gkjI5oOCEclzGXGBHI8tbxRf3CS2ZeuVfOn6YAchWOwjabExfAvV5VfINA5AC6O1voj/4QnXrUVAHQ8CaenI88A3ImWUwpj+3BCZ/0ccAB/LrAJQOVUK+y2qRf6nFyLqWMaEaCbkbASzTakaiuRNdYWRw0FF4= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=lightside-instruments.com; Received: from AM0PR08MB4084.eurprd08.prod.outlook.com (2603:10a6:208:129::25) by AM8PR08MB6530.eurprd08.prod.outlook.com (2603:10a6:20b:315::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.25; Fri, 23 Jul 2021 21:00:47 +0000 Received: from AM0PR08MB4084.eurprd08.prod.outlook.com ([fe80::1cd0:f85e:3adc:1915]) by AM0PR08MB4084.eurprd08.prod.outlook.com ([fe80::1cd0:f85e:3adc:1915%7]) with mapi id 15.20.4352.029; Fri, 23 Jul 2021 21:00:47 +0000 From: Vladimir Vassilev References: <162149702436.31231.10601110335947474104@ietfa.amsl.com> Cc: Murray Kucherawy , "netmod@ietf.org" , draft-ietf-netmod-geo-location@ietf.org, hackathon@ietf.org To: Christian Hopps Message-ID: Date: Fri, 23 Jul 2021 23:00:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-ClientProxiedBy: OL1P279CA0040.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:14::9) To AM0PR08MB4084.eurprd08.prod.outlook.com (2603:10a6:208:129::25) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.0.37] (84.209.6.28) by OL1P279CA0040.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:14::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.22 via Frontend Transport; Fri, 23 Jul 2021 21:00:47 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d7457b1c-c57f-4e2f-e28b-08d94e1cf219 X-MS-TrafficTypeDiagnostic: AM8PR08MB6530: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: g1VnEa3447e6RWZVhdtFtYKl3j8XZTfZwRlYXNN22QuyiRejLqyeNZyrbOT4U5qqSJjsbkKRluWXiRHd/xRGuQ66JuJlodZlw0JUWMChTNegWoyN/C46/n5K9jNUCYLwy73tXWrta6Hl0zaZe1/P1AyLxeyzY2reLOJsWoAV7ogekcikfTyrMlIvmbeGBSV0H2jkBUopRyO1T5rHQ6lkuidj49zpBzAiwkSkbRe/5vv9n5WAq4l8lZ3rVzduccyv+j/birg8YZKyCK2gdMen29iVoCe1502obJgOVwELGRuSCPsZDOT2R2oemvZ8at6PAyqQXehsp/nHFmd0REMQGSzmttiwsNkJYeSZMDDjghcQ+0yVUfdYOjAcfS9kBDrGEnGNQM9LPkdo6vFdMWZCEfF0ClZjNvsfICgLa8zOTWE/W4/ZzXblP7g8M22JeGDLyEKYwlJTC27puZX4feCXC9iTJG6noumTGn2JkQzrIeUoMyIavMOO9ASwnrlkYWwLmTR4z8F2rVy7HGa+jyNaiy5Tkq4k3HTdGRJU3iCEWaiLm3hF7FkYAvQ7j//ftWQmVzRX3Gviw1etxpXnb503taozJffYxYVulgXsNhLciYx7Bt8Jj1Ystfpry4g3juKgwgkgb+Sga3fOIQwfKai4rf90hVBBlNjqcp1ksj38irhdPKemcno7Q+rXKyEacmKdgkpI0KcYxI0RnuFbtHvDCTdka2bKBmo6yHQLufJmSqPlP5vwCI/Qd9726+v8UoEzFeG+QZmNXQHtxGaM9xEJn7gMG+tM69j/MwfhTuOJsIcw5M5hNyRtJN8nf0dwLNihtQwQ8IOTHIqCPkyuqOqtrw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB4084.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(39830400003)(346002)(136003)(376002)(366004)(396003)(478600001)(52116002)(2906002)(956004)(2616005)(31696002)(186003)(26005)(5660300002)(966005)(6916009)(36756003)(38100700002)(316002)(38350700002)(8676002)(16576012)(31686004)(86362001)(4326008)(6486002)(83380400001)(8936002)(66476007)(66556008)(54906003)(66946007)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?VmlzbUFEQW1xUmZpWlNPcVJ1dkNUNDNPQkMvNXltZlF1bDc1eFhKY1NkRGtt?= =?utf-8?B?TW00cDI5bUJ6TWdNT1JqbVNXanVDdUtMR1JERTc2dkF0MFV4dU96T2hYUkxM?= =?utf-8?B?eE1VVm9qV2MrNnlKNFEzV0JlcTlhM2VpcGcwa3AwR0I4SnYwOEVoNW9zbEVD?= =?utf-8?B?bGJoaUU1ek9oR002SUVLYVVZR0c4WTZ4WktzRG1qbHdQMUpTRHZzb0tyT3FD?= =?utf-8?B?cHZrWlFYYjNPYmFQSUs2VjdNZzJYa3Rlc09Rd2d3SUJnaWZNQ2R2aDJpanJl?= =?utf-8?B?MjVEeVp1eHllYVdrZ1Q5dEIzQzhrREFpMXJmQnRyN2lWTHEvay9Fb2x0TEU2?= =?utf-8?B?OXdrQ0FpdUZNdXRVUVFBeU1WNWFXckJsTXN4Wk9WM05QRVh3SytxOVhvN1dt?= =?utf-8?B?ZHRnS3h2aEhsSTFTM0RTWnVGOFJLK1hZMWd3bGo5Rmd5SWwvMzM1Q3RzdGt1?= =?utf-8?B?N1o5UGVJQTVlbzJNSGlIZWQzWGJWVmYwT1VYa3VONFFiWEI2OEM5VlRPbWZr?= =?utf-8?B?MnVMMFByNW0xSlZNNC8wdWp6QnlFem40NmpBR0JRblV0QkJtK1FsS1FQVE5o?= =?utf-8?B?Qlk1VHRoN3pEWmVZSXVGWUdpdDlzN2xNanBPc2xBcHBMc0NFMjRsRHRqV0c4?= =?utf-8?B?OWV3aG1ReXdtdDBxUGlLenZMZHJLcENMeDYreFJXYStBY2tZR0RVeWErM1pU?= =?utf-8?B?V2ZxS0dVOWN5YnBMNDQ4OXppL1RzRlI5VWoyQkE1K29sdDl5bHZmTENxeFFz?= =?utf-8?B?bm1VSXFwaUZ5aitFVWlBUWFKTjd6UW0xbGhmR3ZCMGtnL1c0NU9abFJ0ZVMv?= =?utf-8?B?cFFoZ253MzF0ZzJBQUdDMGI5YUExUU9uQmgzbE15SWU2SDV2QkNON1RGMXdr?= =?utf-8?B?NTJGMWs1cTRxKzBJdVd1MGhJRTVQY0VBNnpsTlhCS1owK0Q0UUVxeVhWWHpZ?= =?utf-8?B?YzlsdVJhWm1BVVNTSkVSaFArbVI4UDZ6Y0VGbDFXME85enFkWUNISGVGRldC?= =?utf-8?B?Y2RtMTNkNU9YNjdYemxOSEk2dXVBUVk2ZkVWVjZrQkpmZzhWSTF1QnNnT0Nx?= =?utf-8?B?dUJaTEErSzV0Y0kzd3B0NlZUOWp0TkFzL25YT0RMY1FhcWxJeXJmSmZJRzlM?= =?utf-8?B?dmFGS2dFTWVZUW1yK0FLLzZZNlFhVDlJUysvaWFOYzQxSUpwM0Y2aE9iYm80?= =?utf-8?B?R2NPaVNUL3QwZHBIcVVlVCs3RVByb0VRRGRIZUFyc0V5Q2lzejcxSnd1d3ph?= =?utf-8?B?Tm54WXdoRkdxTCtpVTU5RUVWbTEyUm9uMmt4YTlGY2VWN1Erbm1KYXZTNDkv?= =?utf-8?B?WmNERVR4MVJ4YTh6MTJBeW9ldTNuSHFwUEQ3THk3RDFPVFJubmRLdUxEQXpm?= =?utf-8?B?eGZwbmZRWFFmaFNwRlZ0ZlZwcFhKK0Zvb2NQVTcvQ2h1N1daUjQvcVF5WkZn?= =?utf-8?B?MjFpYko1dzZRWWtOa2xsQjl2ZmNETHVoRitkS0h0WjdyRktIZWhxMGc1WFVQ?= =?utf-8?B?YkNOYStzc0RaZnQ4V0lidjFVQ09rNVdXZ2p0VUtncFZDUkpxU1Q0Rk91S3pC?= =?utf-8?B?TkNUTXpGb29RRUo4SlBoT1BrOUZCSlJ3cnE3U3I2MlV0OFlLT0s2cldNQ1J4?= =?utf-8?B?cUJvRndmZkw0RUZhbkxVNmRxR25UYmlqQTdiS2FvcDd0ZHBCamVNalE3TzZq?= =?utf-8?B?TkZQa01zOVc4eVJmMmFiKy9rY1RqUWtCOUdSTUk5Q0NlRVlWRjYxaHJLUHlC?= =?utf-8?Q?ooOZY2doOeaGoNTAcN+VcVvyuRnynUPqqkCz4u0?= X-OriginatorOrg: lightside-instruments.com X-MS-Exchange-CrossTenant-Network-Message-Id: d7457b1c-c57f-4e2f-e28b-08d94e1cf219 X-MS-Exchange-CrossTenant-AuthSource: AM0PR08MB4084.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jul 2021 21:00:47.8418 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: c0326317-f373-4461-a96f-7946e0abb603 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: DPIqTEQgW2B7x2pmtRfvKq0Y15e5H8XV+jM43P0jLDnoEQfjfGCXV+bGIU044qpoSpgRI45oQye4iA4X7DYVkdkheyJCzc1BzuhWFD8ZfTGr3IhEKLaOt2ARpH01eyFK X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR08MB6530 Archived-At: Subject: Re: [netmod] Murray Kucherawy's No Objection on draft-ietf-netmod-geo-location-08: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2021 21:00:57 -0000 Hi, So here is the implementation ... $ apt-get install yangcli $ yangcli --server=lightside-instruments.com --ncport=10830 --user=user --password=ietf111 --display-mode=xml --run-command="xget /geo-location" --batch-mode ...             59.9145666710000000       10.7492606760000000       The implementation https://github.com/vlvassilev/yuma123/tree/master/example-modules/geo-location The target system is this https://www.hackster.io/lightside-instruments/network-programmability-kit-for-ultra96-07435c hosted at Bitraf - makerspace in Oslo. /Vladimir On 20/05/2021 11.33, Vladimir Vassilev wrote: > > On 20/05/2021 10.43, Christian Hopps wrote: >> >> Murray Kucherawy via Datatracker writes: >>> >>> I support Lars' and Francesca's DISCUSS positions. >>> >>> The shepherd writeup says: "There are no known implementations known >>> to the >>> Shepherd.  No vendors have indicated their plan to implement the >>> specification. >>>  It was originally forwarded to support DT's Terra Stream project."  >>> I'm >>> tempted to ask why this is slotted for Standards Track publication. >> >> It's a grouping, it's meant to be incorporated into other YANG >> modules rather than have each module come up with their own version >> of a geo-location object. >> >> So, it's wont be "implemented" directly by any vendor until it is >> published and can start to be used in other module definitions. There >> definitely is interest in this use in the netmod WG. >> > Hi, > > I intend to use the grouping in our implementation. We can do that at > the upcoming Hackathon event and validate the module with some running > code. > > /Vladimir > From nobody Tue Jul 27 08:38:14 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DAF3A0E3B for ; Tue, 27 Jul 2021 08:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=h1gaizrA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=UlGl8Afw Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEP8Td18_WA4 for ; Tue, 27 Jul 2021 08:38:06 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F3B3A0E37 for ; Tue, 27 Jul 2021 08:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42902; q=dns/txt; s=iport; t=1627400286; x=1628609886; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lvDvx3/kocaWQQLKy/c7xkWYPI3ERw6AzHAUtv880is=; b=h1gaizrATKduHqggvgeOgJwleyLFNjMVRH9mdPj6P9Gz+sjXrRqUWGsb oogCg6pVOoSHbO/x4vD3jtpRDoa5W7R34bQNEWB9OWMI0L9x75CToTkuf SzIa7D3X9fuAh/O4OsCwr5vVRTOPK2vPeCG2kV2TAxgcyh405q5o404cH I=; X-IPAS-Result: =?us-ascii?q?A0A5AAACJwBhl5JdJa1QCh0BAQEBCQESAQUFAYIGBwELA?= =?us-ascii?q?YEiMCMuflo3MYRHg0gDhTmIXgOaMoEuFIERA1QLAQEBDQEBQQQBAYRYAheCZ?= =?us-ascii?q?wIlNQgOAgQBAQEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBAQEBcoVoDYZCA?= =?us-ascii?q?QEBAQMSEQoTAQE3AQ8CAQgRBAEBIQEGAwICAjAUCQgCBAENBQgTB4JPAYF+V?= =?us-ascii?q?wMvAZxAAYE6AoofeoEygQGCBwEBBgQEhTkYgjQJgToBgnuEDQEBhmMnHIFJR?= =?us-ascii?q?IFYgmI+hBcTAho0gmE2ggwigmmBFwQnMIILkg6DTYg6g2aJVJIWCoMmnlkSp?= =?us-ascii?q?mOWC6AahHQCBAIEBQIOAQEGgWEBNy2BLnAVgyRQGQ6OHwwNCYNPil5zOAIGA?= =?us-ascii?q?QoBAQMJikkBAQ?= IronPort-PHdr: A9a23:g0HX/BY7Z51YN6RM9SaxPJ//LTDLhN3EVzX9orI2lrdHbaO5/I+kN 0vatr1hj17MCIPc7f8My+/bqLvpVmFI55Gd+GsDf5pBW15g640WkgUsDdTDBRj9K/jnPD0nG c1dU0Vm5DewNk0GUMr7bkfZ93u16zNaEx7jNA1zc+LyHIOaj8m+2+2ovZPJZAAdjzumarQ0J xKz/m3s IronPort-HdrOrdr: A9a23:QX2E262H/ivwl+rIhiOsnQqjBJAkLtp133Aq2lEZdPU1SL38qy nKpp536faaslossR0b9uxoQZPwJk80lqQFg7X5X43DYOCOggLBEGgF1+XfKlbbak7DH4BmtJ uIRJIObOEYXWIQsS8j2njDLz/7+qj+zEl0v5am856wd3AQV0i/1XYFNu71encGIjV7OQ== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.84,274,1620691200"; d="scan'208,217";a="720966038" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Jul 2021 15:38:04 +0000 Received: from mail.cisco.com (xbe-aln-005.cisco.com [173.36.7.20]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 16RFc49i027851 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 27 Jul 2021 15:38:04 GMT Received: from xfe-aln-003.cisco.com (173.37.135.123) by xbe-aln-005.cisco.com (173.36.7.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 27 Jul 2021 10:38:04 -0500 Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 27 Jul 2021 10:38:04 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-004.cisco.com (64.101.210.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Tue, 27 Jul 2021 11:38:04 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PwLS1JZzfdJH16NkSCXkGiNkEcFvsYb9aFutxfhOtma8eENRRkpBONrsBoI/2Dl7kYA2toXVytZb4MuUWFxk8Btq9cwgjnzvCTVhdadtK6TDO1+seR1RP60I5QHZEcvvLzeH/snULNLP/gklhneJrh1aQGSy4b6wsjJaXa/NLK7fv0+x1jJxs/L0I8BBjPvREnwSgEtjhJEuknPJcRS8HX8b65MJ3p5RqeWxGqFlB1Pq6sZ2Lkzcncw1annQURGo2SMi79lP2RTNpO6XNG0DYKeinWmhP0GEK0/ePWaVE7fz6ebQhpPbxhO1hQwEfWmrtO/+7i399lOiOzXqnphvtw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lvDvx3/kocaWQQLKy/c7xkWYPI3ERw6AzHAUtv880is=; b=oFpe3XQYO+JdAsSo+GK6p0d6Q6m0OkhuhyvzDdQsLt58Elb0NhJ+XpG4hxVaQFvSlQj/74lI110Z3yrbYMlZbMmphkSW16+1h/kYjiQX673OqBMYXWXJKfEJVWWm8/nvZ5Kv03QelcqajrKed26VcQvpXHKOQkeoc5jr1DeAVnLqTVwODW9UYugvT3J359DsYCgts6A1N6zXql1qYvoJrx7h1GFmgjsu8eDvrusxi/l2DTpfXXHwMm07/9uylUSJ4xpTc1XotO4PQTkwM0et7dLoNf9myaOB0tZd07YPJ8XXgvYMaVWH6K4ID0Rzye8H1/uFVZ2q2Ywq5M8GdX+D2Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lvDvx3/kocaWQQLKy/c7xkWYPI3ERw6AzHAUtv880is=; b=UlGl8AfwxYHpBORjIVhBIflrVd8uv6qfEB21v/twpKSBMx2M9a6OBFRJSnp7A36P+nidjEsM0e1vFsih9hdeboAS6oW7NW23maKbgfcP865iwixIjAAicnePVU86saAHY6knLqsRiIgXrRAdgNg0R/9JCvIadINELRx6STSqU2k= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM5PR11MB1818.namprd11.prod.outlook.com (2603:10b6:3:114::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.29; Tue, 27 Jul 2021 15:37:56 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12%7]) with mapi id 15.20.4373.018; Tue, 27 Jul 2021 15:37:56 +0000 From: "Rob Wilton (rwilton)" To: Andy Bierman , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= CC: NetMod WG Thread-Topic: [netmod] yang-instance-file include-defaults leaf Thread-Index: AQHXdB0ZnZibUXpuT0+6mfsyEmKi+6s6kMRwgAHbvACAGptLcA== Date: Tue, 27 Jul 2021 15:37:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b7fea49c-5e22-4d55-5a21-08d9511481b1 x-ms-traffictypediagnostic: DM5PR11MB1818: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sGAbZGOAiwO2jD/wJPJtkVweHPZs++Rop8r7mVYr3sVUAxqpJ53ejGTb35GJmqDlkZp2CM0ZMJz1pDS/DlvExtLLL0D2rgW42ur+uqAIc3Whqa74sn9vTzlSELHiuXnAZ3M0rV02tWVkXS9b5gZYRKICOztZkDMeqS8Ywz+0+VTOH91dhW5Q6mMWAWrQzj5YTDSvgwAK75nFV8H30Hfr7lpbLHHg+pFintuWu+P8OgLX3XjC6HLZfsknlmSyqe5CscgBc026b+RHVOdf5SEw5pSgyrU3DU9h13hdwOVch2Co7ngsYpWA87LPaIwJacBXA53fJpAzE2R2ag1y9y/92Rt5d3+fykMg3mACKO1tSxfe7+HT/OlqkASU6l8MXpMKRwDf57ZH49AO0uO2IRhDOTp6bpnESLn591xEDjdxSI0K+5IxIAMcXTH7HB16gOlrtlSISonroaKEIu2xPKQUBFU+5HYLLnna3UqH+aHuFQVipqsqGN7DfBN2GEs37Qtuo1cAG7tA44sk2pmqCEZJSFQdln78hZf90JHACiHCKd+pcadOrDdrH0iS9yGy9H4hJM3qd6GYOXMglG0ZpOhoxya0vorsef3kH4jp/hxqfGTgKZrUj+oF2tS7UugYWyZ7wXP+gh8lFMRCLwuu0nX4OWfD9ciuzV4HXguqH4nl4bQ0auo2z5GpaJTMXFMzC93c8fpob6VI+NTVcNeRJJOf3A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(346002)(376002)(39860400002)(366004)(66556008)(26005)(6506007)(53546011)(110136005)(83380400001)(71200400001)(2906002)(55016002)(7696005)(4326008)(5660300002)(8936002)(86362001)(9686003)(38100700002)(316002)(33656002)(478600001)(8676002)(52536014)(122000001)(76116006)(186003)(66476007)(64756008)(66446008)(66946007)(38070700004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WTgzSGJjU3VYVWd1a1RxRVd3MzA3Mm9pK2M4aXg4OTBKaDh5OG1PYlZ3NUwz?= =?utf-8?B?blhmK3owTnlKNzQ3eStDQ05CbWp3VW54Zm1hdmZMZkRYOFNiN2FiU2ZvRzMy?= =?utf-8?B?TE9lOXVGc0M2WXpSc0ZqL0NjSkFzQUFxeVlOZnhxeDFiTVpzWGlaR0VPOFFO?= =?utf-8?B?SlZ3M3ZQU1gxaEk1RUxKeldTeTBCclpFdDlUQitnZmkwUEtmOHJ3TW1abWlt?= =?utf-8?B?VTB4aFp2WHZ1T0Vja1RrM1N6azdhRjNYZ0xmQXlCcE9hTGtpYkt0aTlNdlhk?= =?utf-8?B?RFdUMXNOK0pCakQxWDNNVmVhWXRsQ0prN05XNXlPSzcrVFkybTZmWWlVYlNm?= =?utf-8?B?cTV1Mkl4Z2NvdzBNY2YzZlZBbUpvb1NtNGk3bHg1WWdGS1UvZytnVnMydTBC?= =?utf-8?B?Tk1kM2dvQlc1Qm5xQ0N3NUlFa3dLZFdWendQaVVUTW9XSld0WFkzZWNVREw0?= =?utf-8?B?QndJWlRNVjN4TmtJdjVPSGZSUkIxSUhaMUJBdFpVSGQvNHlxb255dkx4YUQx?= =?utf-8?B?aHNZdmp0enRMWWZTZ1hLR043TzJJQTVsT2F1b1VydEVOR2RIOUFqWmlsNUlJ?= =?utf-8?B?OUVVOGZnanZjWGVCbkduczY0cEppK2htNE5iR1luYlp5ckR6akJMaVd6bi9n?= =?utf-8?B?Zm9OQ2lrbDk0VmF4cXpkMFRxalVoY2JYWVJBeVFNamlLeklXNThqVlBhcHRP?= =?utf-8?B?b0ZLMHhjUmVlNEQzRGdkTEZGSFJoRnVZK04yQldKamgybnVHQlQxbmlkdmhH?= =?utf-8?B?RlovbWdaQlBNR0xwRTgxUERNNnQrbFJCTUJLbnB6bkd5QnVrT3R4emFJTWE0?= =?utf-8?B?cUlMTVJHUkk3ZXBHVU8zZjExZUtsUURLaTJHTVJidVR0UVNTUmFuakcvSDlh?= =?utf-8?B?TEhOUTBSRkl3em5XQmx0TWJGUkNIZUx4MHpQNGJEWk5yYlV2aElVZU9CZ1F3?= =?utf-8?B?bWRjekp3OENKdjc5S1ZINSsvbVVaRzErTzhWQWtoUVFQMSsyd1d3U1JwMndt?= =?utf-8?B?SkgzSzNOc1Y2QVFKcEsrblZET1J1S056WldWOGFnME1jODMvOUpXZlpjVEtm?= =?utf-8?B?V01sOTRUSVpSaVI3djBINWxBOUpsMkYwR0IyelB6aG9oc2VySjAwWWJmdnhw?= =?utf-8?B?R1ZZcUdYb3h0LzlwaVhtMXhNYVByQkNYeElYN3FCMHVKMmVMcGtZRWloTjBB?= =?utf-8?B?dHFaNFMzeGNreXM3a0o4b2MxcStxbmFWTGdsb0xqTzBYZUc1QlVrbktGR3Z4?= =?utf-8?B?YkhlN1BWZ05aRWJNVVFvbzM3UDM2c084eTRaNDJYMjRTM2dZVFBaNG45N2Za?= =?utf-8?B?NDZodnZtSHRuMlhsUTIwVWdqTzR4ZFcrQlZPcnAxcE5HTEx4S1dtVXZicWFL?= =?utf-8?B?dEtVMnE1QUtBZ0h4WjVncjJaRVFJaGJQSWhTZmluU0xwalh6aWRWdTF0eFVV?= =?utf-8?B?YldTVVBZZ2VtaTV4WTMzRW4xYklpbHhCN3dEeE5nYk9PMlE2bEtaRDlDTCs0?= =?utf-8?B?K1BvRGFDc3B5cFlkOExjY0tIYk9MUXpENGdFNnpNTWVoN0xJQlNaYkhzZ3ho?= =?utf-8?B?VlVpYTZXdzlMcyt6VG1FSEMvVDRHbCtFOEgzUmduaWxYMjQzY2FaMG9JMStM?= =?utf-8?B?Tk1rVU4rbnVLR3R1THZIK0lENHIvZms4UURWUTVwaFFkMnR2L09SSFh5UFg1?= =?utf-8?B?a3FLcE51djlIa3JGNXhPSkU5dGJONVp3Um1jT0RBL0hET2haUWU3ZXp0NC8v?= =?utf-8?Q?XdrCwtpTGqeaeMZtamyQRcGr7yc6fHAfHHlrCiD?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM4PR11MB5438FBF7837C1147D786964CB5E99DM4PR11MB5438namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b7fea49c-5e22-4d55-5a21-08d9511481b1 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2021 15:37:56.5062 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: eNUMY3VdXUnMmprBbKLrhJBot9lQz2aVVdeW9FOMCKhjUeovSb9FpYskQpVdchiDhH1/FoeRV1mHvqnfpHXzjQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1818 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xbe-aln-005.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [netmod] yang-instance-file include-defaults leaf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 15:38:11 -0000 --_000_DM4PR11MB5438FBF7837C1147D786964CB5E99DM4PR11MB5438namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwgQmFsYXpzLA0KDQpTbywgdGhlIHJlYXNvbiB0aGF0IEkgd2FudCBhIGZsYWcgdG8g aW5kaWNhdGUgd2hldGhlciBkZWZhdWx0IHZhbHVlcyBhcmUgaW4gdXNlIGlzIGJlY2F1c2Ugb2Yg dGhpcyBkZWZpbml0aW9uIG9mIG9wZXJhdGlvbmFsIGluIFJGQyA4MzQyOg0KDQogICBSZXF1ZXN0 cyB0byByZXRyaWV2ZSBub2RlcyBmcm9tIDxvcGVyYXRpb25hbD4gYWx3YXlzIHJldHVybiB0aGUg dmFsdWUNCiAgIGluIHVzZSBpZiB0aGUgbm9kZSBleGlzdHMsIHJlZ2FyZGxlc3Mgb2YgYW55IGRl ZmF1bHQgdmFsdWUgc3BlY2lmaWVkDQogICBpbiB0aGUgWUFORyBtb2R1bGUuICBJZiBubyB2YWx1 ZSBpcyByZXR1cm5lZCBmb3IgYSBnaXZlbiBub2RlLCB0aGVuDQogICB0aGlzIGltcGxpZXMgdGhh dCB0aGUgbm9kZSBpcyBub3QgdXNlZCBieSB0aGUgZGV2aWNlLg0KDQpJdCB3YXMgd3JpdHRlbiB0 aGlzIHdheSBiZWNhdXNlIG90aGVyd2lzZSBhIGNvbnN1bWVyIG9mIG9wZXJhdGlvbmFsIGRhdGEg Y2Fubm90IGRpZmZlcmVudGlhdGUgYmV0d2VlbjoNCg0KKGkpICAgICAgICAgICAgICAgICAgVGhp cyB2YWx1ZSBpcyBub3QgcHJlc2VudCBiZWNhdXNlIGl0IG1hdGNoZXMgdGhlIGRlZmF1bHQgdmFs dWUgc3BlY2lmaWVkIGluIHRoZSBZQU5HIG1vZHVsZSwgYW5kDQoNCihpaSkgICAgICAgICAgICAg ICAgVGhpcyB2YWx1ZSBpcyBub3QgcHJlc2VudCBiZWNhdXNlIHRoZSBzZXJ2ZXIgaGFzIGZhaWxl ZCB0byByZXR1cm4gaXQgZm9yIHNvbWUgcmVhc29uIChlLmcuLCBwZXJoYXBzIHRoZSBkYWVtb24g dGhhdCB3b3VsZCBoYXZlIHByb3ZpZGVkIHRoaXMgdmFsdWUgaXMgZG93biBvciBub3QgYXZhaWxh YmxlLCBvciBwZXJoYXBzIGl0IGlzIGEgYnVnLCBvciBwZXJoYXBzIGl0IGlzIG5vdCBpbXBsZW1l bnRlZCBhbmQgaXMgYSBtaXNzaW5nIGRldmlhdGlvbikuDQoNClNvLCBJIHRoaW5rIHRoYXQgaW4g c29tZSBjYXNlcywgdGhlIGFic2VuY2Ugb2YgYSBkYXRhIG5vZGUgZG9lcyBub3QgbmVjZXNzYXJp bHkgbWVhbiB0aGF0IHRoZSBkZWZhdWx0IHZhbHVlIGlzIGluIGVmZmVjdCwgYW5kIEkgd2FudGVk IHRoZSBpbnN0YW5jZS1kYXRhIGRvY3VtZW50IHRvIGJlIGFibGUgdG8gY29udGFpbiBhbmQgY29y cmVjdGx5IHJlcG9ydCB0aGlzIGRhdGEuDQoNCkkgdGhpbmsgdGhhdCB0aGlzIGJlaGF2aW91ciBj b3VsZCBiZSBjYXB0dXJlZCBieSBhIHNpbmdsZSBsZWFmLiAgQW5vdGhlciB3YXkgb2YgYXJ0aWN1 bGF0aW5nIHRoaXMgd291bGQgYmU6DQoNCmxlYWYgaW4tdXNlLXZhbHVlcyB7DQogIHR5cGUgYm9v bGVhbjsNCiAgZGVmYXVsdCBmYWxzZTsNCiAgZGVzY3JpcHRpb24NCiAgICDigJxPbmx5IGlmIHNl dCB0byB0cnVlLCB0aGUgYWJzZW5jZSBvZiBhIHZhbHVlIGluIHRoZQ0KICAgICBpbnN0YW5jZSBk YXRhIGZvciBhIGdpdmVuIGRhdGEgbm9kZSBpbXBsaWVzIHRoYXQgdGhlDQogICAgbm9kZSBpcyBu b3QgdXNlZCByYXRoZXIgdGhhbiBpbXBsaWNpdGx5IHRha2luZyB0aGUNCiAgICAgZGVmYXVsdCB2 YWx1ZSBzcGVjaWZpZWQgYnkgYW55IGNvcnJlc3BvbmRpbmcNCiAgICDigJhkZWZhdWx04oCZIHN0 YXRlbWVudCBzcGVjaWZpZWQgaW4gdGhlIFlBTkcgc2NoZW1hLuKAnTsNCn0NCg0KV2l0aCB0aGlz LCBJ4oCZbSBub3Qgc3VyZSB3aGV0aGVyIHdlIG5lZWQgdGhlIOKAnGluY2x1ZGVzLWRlZmF1bHTi gJ0gbGVhZiBjdXJyZW50bHkgc3BlY2lmaWVkIGluIHRoZSBkcmFmdCwgYnV0IGlmIHdlIGRvLCB0 aGVuIEkgd291bGQgdGhpbmsgdGhhdCBsZWFmIHNob3VsZCBiZSBlbnRpcmVseSBvcHRpb25hbCwg aS5lLiwgd2l0aG91dCB0aGUgZGVmYXVsdCDigJx0cmlt4oCdLg0KDQpSZWdhcmRzLA0KUm9iDQoN Cg0KRnJvbTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+DQpTZW50OiAxMCBKdWx5 IDIwMjEgMTc6NDENClRvOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+ DQpDYzogTmV0TW9kIFdHIDxuZXRtb2RAaWV0Zi5vcmc+OyBCYWzDoXpzIExlbmd5ZWwgPGJhbGF6 cy5sZW5neWVsQGVyaWNzc29uLmNvbT4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSB5YW5nLWluc3Rh bmNlLWZpbGUgaW5jbHVkZS1kZWZhdWx0cyBsZWFmDQoNCg0KDQpPbiBGcmksIEp1bCA5LCAyMDIx IGF0IDU6MjMgQU0gUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPG1haWx0 bzpyd2lsdG9uQGNpc2NvLmNvbT4+IHdyb3RlOg0KQW5keSwNCg0KWWVzLCB3aGVuIEkgc3VnZ2Vz dGVkIHRoaXMsIEkgd2FzIHRoaW5raW5nIHRoYXQgYSBib29sZWFuIGZsYWcgbWlnaHQgYmUgc3Vm ZmljaWVudC4gIE15IHBvaW50IGJlaW5nIHRoYXQgYXV0b21hdGljYWxseSBmaWx0ZXJpbmcgb3V0 IGRlZmF1bHQgdmFsdWVzIGlzbuKAmXQgYWx3YXlzIHRoZSByaWdodCB0aGluZyB0byBkby4NCg0K DQoNClRoZSBzb2x1dGlvbiBpcyBzaW1wbGUuDQpHZXQgcmlkIG9mIHRoZSBpbmFwcHJvcHJpYXRl ICJkZWZhdWx0IHRyaW0iIHN0YXRlbWVudC4NCg0KSWYgdGhlIGxlYWYgaXMgcHJlc2VudCB0aGVu IGl0IGlkZW50aWZpZXMgdGhlIGJhc2ljLW1vZGUgdGhhdCB3YXMgdXNlZCB0byBpbmNsdWRlIGRl ZmF1bHRzLg0KSWYgbm90IHRoZW4gdGhlIGluZm9ybWF0aW9uIGlzIGVpdGhlciBub3Qga25vd24s IG5vdCBhcHBsaWNhYmxlLCBvciBkZWZhdWx0cyB3ZXJlIG5vdCBhZGRlZC4NCg0KVGhlICJkZWZh dWx0IiBzdGF0ZW1lbnQgaXMgYSBidWcgYmVjYXVzZSB0aGVyZSBpcyBubyBkZWZhdWx0IGJhc2lj LW1vZGUuDQpBbGwgb2YgdGhlIGJhc2ljLW1vZGVzIGFyZSBpbiB1c2UgaW4gZGVwbG95bWVudHMg YW5kIG5vIGNhbXAgaGFzIGV2ZXINCmJlZW4gYWJsZSB0byBjb252aW5jZSB0aGUgb3RoZXJzIHRo YXQgdGhlaXJzIGlzIHJpZ2h0Lg0KDQoNCkFuZHkNCg0KRS5nLiwgc29tZXRoaW5nIGFsb25nIHRo ZXNlIGxpbmVzOg0KDQpsZWFmIGV4Y2x1ZGUtZGVmYXVsdHMgew0KICB0eXBlIGJvb2xlYW47DQog IGRlZmF1bHQgdHJ1ZTsNCiAgZGVzY3JpcHRpb24NCiAgICDigJxDYW4gYmUgdXNlZCB0byByZWR1 Y2UgdGhlIHNpemUgb2YgdGhlIGNvbnRlbnQgZGF0YSBmaWxlLg0KDQogICAgICBXaGVuIHVuc2V0 IG9yIHNldCB0byB0cnVlLCBkYXRhIG5vZGVzIHRoYXQgaGF2ZSBhIGRlZmF1bHQgZGVmaW5lZCBh bmQNCiAgICAgIHdoZXJlIHRoZSBhY3R1YWwgdmFsdWUgaXMgdGhlIGRlZmF1bHQgdmFsdWUgYXJl IGV4Y2x1ZGVkIGZyb20gdGhlIGNvbnRlbnQNCiAgICAgIGRhdGEuDQoNCiAgICAgIFdoZW4gc2V0 IHRvIGZhbHNlLCBkYXRhIG5vZGVzIHdpdGggZGVmYXVsdCB2YWx1ZSBhcmUgbm90IGZpbHRlcmVk LCBhbmQNCiAgICAgIG1heSBhcHBlYXIgaW4gdGhlIGNvbnRlbnQgZGF0YS7igJ0NCn0NCg0KV291 bGQgdGhpcyBzYXRpc2Z5IHlvdXIgY29uY2Vybj8NCg0KUmVnYXJkcywNClJvYg0KDQoNCkZyb206 IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGll dGYub3JnPj4gT24gQmVoYWxmIE9mIEFuZHkgQmllcm1hbg0KU2VudDogMDggSnVseSAyMDIxIDE4 OjE2DQpUbzogTmV0TW9kIFdHIDxuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9y Zz4+DQpTdWJqZWN0OiBbbmV0bW9kXSB5YW5nLWluc3RhbmNlLWZpbGUgaW5jbHVkZS1kZWZhdWx0 cyBsZWFmDQoNCkhpLA0KDQpUaGUgbW9kdWxlIGhhcyB0aGlzIG9iamVjdDoNCg0KDQogICAgbGVh ZiBpbmNsdWRlcy1kZWZhdWx0cyB7DQoNCiAgICAgICB0eXBlIGVudW1lcmF0aW9uIHsNCg0KICAg ICAgICAgZW51bSByZXBvcnQtYWxsIHsNCg0KICAgICAgICAgICB2YWx1ZSAxOw0KDQogICAgICAg ICAgIGRlc2NyaXB0aW9uDQoNCiAgICAgICAgICAgICAiQWxsIGRhdGEgbm9kZXMgU0hPVUxEIGJl IGluY2x1ZGVkIGluZGVwZW5kZW50IG9mDQoNCiAgICAgICAgICAgICAgIGFueSBkZWZhdWx0IHZh bHVlcy4iOw0KDQogICAgICAgICB9DQoNCiAgICAgICAgIGVudW0gdHJpbSB7DQoNCiAgICAgICAg ICAgdmFsdWUgMjsNCg0KICAgICAgICAgICBkZXNjcmlwdGlvbg0KDQogICAgICAgICAgICAgIkRh dGEgbm9kZXMgdGhhdCBoYXZlIGEgZGVmYXVsdCBkZWZpbmVkIGFuZCB3aGVyZQ0KDQogICAgICAg ICAgICAgICB0aGUgYWN0dWFsIHZhbHVlIGlzIHRoZSBkZWZhdWx0IHZhbHVlIFNIT1VMRA0KDQog ICAgICAgICAgICAgICBOT1QgYmUgaW5jbHVkZWQuIjsNCg0KICAgICAgICAgfQ0KDQogICAgICAg ICBlbnVtIGV4cGxpY2l0IHsNCg0KICAgICAgICAgICB2YWx1ZSAzOw0KDQogICAgICAgICAgIGRl c2NyaXB0aW9uDQoNCiAgICAgICAgICAgICAiRGF0YSBub2RlcyB0aGF0IGhhdmUgYSBkZWZhdWx0 IGRlZmluZWQgYW5kIHdoZXJlDQoNCiAgICAgICAgICAgICAgIHRoZSBhY3R1YWwgdmFsdWUgaXMg dGhlIGRlZmF1bHQgdmFsdWUgU0hPVUxEIE5PVCBiZQ0KDQogICAgICAgICAgICAgICBpbmNsdWRl ZC4gSG93ZXZlciwgaWYgdGhlIGFjdHVhbCB2YWx1ZSB3YXMgc2V0IGJ5DQoNCiAgICAgICAgICAg ICAgIGEgTkVUQ09ORiBjbGllbnQgb3Igb3RoZXIgbWFuYWdlbWVudCBhcHBsaWNhdGlvbg0KDQog ICAgICAgICAgICAgICBieSB0aGUgd2F5IG9mIGFuIGV4cGxpY2l0IG1hbmFnZW1lbnQgb3BlcmF0 aW9uIHRoZQ0KDQogICAgICAgICAgICAgICBkYXRhIG5vZGUgU0hPVUxEIGJlIGluY2x1ZGVkLiI7 DQoNCiAgICAgICAgIH0NCg0KICAgICAgIH0NCg0KICAgICAgIGRlZmF1bHQgdHJpbTsNCg0KDQpU aGUgZHJhZnQgaXMgZXh0cmVtZWx5IHNlcnZlci1jZW50cmljLCBsaWtlIG1vc3QgSUVURiBzdGFu ZGFyZHMsIGJ1dCB0aGlzDQpsZWFmIGlzIHRvbyBzZXJ2ZXItY2VudHJpYyB0byBpZ25vcmUuDQoN CkNvbnNpZGVyIHRoZSBwb3NzaWJpbGl0eSB0aGF0IHRoZSBzb3VyY2Ugb2YgdGhlIGZpbGUgaXMg Tk9UIGEgTkVUQ09ORiBzZXJ2ZXIuDQpUaGlzIGRhdGEgbWF5IG5vdCBiZSBrbm93biBzbyB0aGUg ZGVmYXVsdCBvZiAidHJpbSIgbWF5IG5vdCBiZSBjb3JyZWN0Lg0KDQpJTU8gdGhpcyBsZWFmIGlz IG5vaXNlIGJlY2F1c2UgYW55IHRvb2wgdGhhdCBrbm93cyB0aGUgc2NoZW1hIHdpbGwgYWxzbw0K a25vdyB0aGUgWUFORyBkZWZhdWx0cy4gIFRoZSBzb2x1dGlvbiBpcyBpbmNvbXBsZXRlIGFueXdh eSBiZWNhdXNlDQp0aGUgcHJlc2VuY2Ugb2YgYSBsZWFmIHRoYXQgaGFzIGEgWUFORyBkZWZhdWx0 IGlzIG5vdCBlbm91Z2guDQpUaGUgICJyZXBvcnQtYWxsLXRhZ2dlZCIgbW9kZSBtdXN0IGJlIHVz ZWQgdG8gaWRlbnRpZnkgZGVmYXVsdHMuDQpJTU8gdGhpcyBsZWFmIHNob3VsZCBiZSByZW1vdmVk LCBidXQgYXQgbGVhc3QgYWRkIGFuIGVudW0gY2FsbGVkICJ1bmtub3duIi4NCg0KDQpBbmR5DQoN Cg0K --_000_DM4PR11MB5438FBF7837C1147D786964CB5E99DM4PR11MB5438namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3Jh cGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJn aW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1h cmdpbi1sZWZ0OjM2LjBwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNv bGFzOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo0MzAwNTU0MjU7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0zNzI0NTg1MDAgLTQzMjQ5Mzgx NiAxMzQ4MDc1NzcgMTM0ODA3NTc5IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5IDEzNDgw NzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGV4dDoiXCglMVwpIjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJbWFyZ2luLWxlZnQ6NTQuMHB0Ow0KCXRleHQtaW5kZW50Oi0zNi4wcHQ7fQ0KQGxpc3QgbDA6 bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDps ZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0K CXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXtt YXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEFuZHksIEJhbGF6cyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+U28sIHRo ZSByZWFzb24gdGhhdCBJIHdhbnQgYSBmbGFnIHRvIGluZGljYXRlIHdoZXRoZXIgZGVmYXVsdCB2 YWx1ZXMgYXJlIGluIHVzZSBpcyBiZWNhdXNlIG9mIHRoaXMgZGVmaW5pdGlvbiBvZiBvcGVyYXRp b25hbCBpbiBSRkMgODM0Mjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgUmVxdWVzdHMgdG8gcmV0cmlldmUgbm9kZXMgZnJvbSAmbHQ7b3Bl cmF0aW9uYWwmZ3Q7IGFsd2F5cyByZXR1cm4gdGhlIHZhbHVlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyBpbiB1c2UgaWYgdGhlIG5vZGUgZXhpc3RzLCByZWdhcmRsZXNzIG9mIGFueSBkZWZhdWx0IHZh bHVlIHNwZWNpZmllZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgaW4gdGhlIFlBTkcgbW9kdWxlLiZu YnNwOyBJZiBubyB2YWx1ZSBpcyByZXR1cm5lZCBmb3IgYSBnaXZlbiBub2RlLCB0aGVuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyB0aGlzIGltcGxpZXMgdGhhdCB0aGUgbm9kZSBpcyBub3QgdXNlZCBi eSB0aGUgZGV2aWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5JdCB3YXMgd3JpdHRlbiB0aGlzIHdheSBiZWNhdXNlIG90aGVy d2lzZSBhIGNvbnN1bWVyIG9mIG9wZXJhdGlvbmFsIGRhdGEgY2Fubm90IGRpZmZlcmVudGlhdGUg YmV0d2Vlbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdDt0ZXh0LWluZGVudDotMzYuMHB0O21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+KGkp PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PlRoaXMgdmFsdWUgaXMgbm90IHByZXNlbnQgYmVjYXVzZSBpdCBtYXRjaGVzIHRoZSBkZWZhdWx0 IHZhbHVlIHNwZWNpZmllZCBpbiB0aGUgWUFORyBtb2R1bGUsIGFuZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQu MHB0O3RleHQtaW5kZW50Oi0zNi4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4oaWkpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoaXMgdmFsdWUgaXMgbm90IHByZXNlbnQgYmVjYXVzZSB0 aGUgc2VydmVyIGhhcyBmYWlsZWQgdG8gcmV0dXJuIGl0IGZvciBzb21lIHJlYXNvbiAoZS5nLiwg cGVyaGFwcyB0aGUgZGFlbW9uIHRoYXQgd291bGQgaGF2ZSBwcm92aWRlZCB0aGlzIHZhbHVlIGlz IGRvd24gb3Igbm90IGF2YWlsYWJsZSwgb3IgcGVyaGFwcyBpdA0KIGlzIGEgYnVnLCBvciBwZXJo YXBzIGl0IGlzIG5vdCBpbXBsZW1lbnRlZCBhbmQgaXMgYSBtaXNzaW5nIGRldmlhdGlvbikuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPlNvLCBJIHRoaW5rIHRoYXQgaW4gc29tZSBjYXNlcywgdGhlIGFic2VuY2Ugb2YgYSBkYXRh IG5vZGUgZG9lcyBub3QgbmVjZXNzYXJpbHkgbWVhbiB0aGF0IHRoZSBkZWZhdWx0IHZhbHVlIGlz IGluIGVmZmVjdCwgYW5kIEkgd2FudGVkIHRoZSBpbnN0YW5jZS1kYXRhIGRvY3VtZW50IHRvIGJl IGFibGUgdG8gY29udGFpbiBhbmQgY29ycmVjdGx5DQogcmVwb3J0IHRoaXMgZGF0YS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ SSB0aGluayB0aGF0IHRoaXMgYmVoYXZpb3VyIGNvdWxkIGJlIGNhcHR1cmVkIGJ5IGEgc2luZ2xl IGxlYWYuJm5ic3A7IEFub3RoZXIgd2F5IG9mIGFydGljdWxhdGluZyB0aGlzIHdvdWxkIGJlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPmxlYWYgaW4tdXNlLXZh bHVlcyB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXMiPiZuYnNwOyB0eXBlIGJvb2xlYW47PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyBkZWZh dWx0IGZhbHNlOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsgZGVzY3JpcHRpb248bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7IOKAnE9ubHkgaWYgc2V0IHRvIHRydWUsIHRoZSBhYnNlbmNlIG9mIGEgdmFsdWUg aW4gdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbnN0YW5jZSBkYXRhIGZv ciBhIGdpdmVuIGRhdGEgbm9kZSBpbXBsaWVzIHRoYXQgdGhlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO25vZGUgaXMgbm90IHVzZWQgcmF0aGVyIHRoYW4gaW1wbGljaXRseSB0YWtp bmcgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZWZhdWx0IHZhbHVlIHNw ZWNpZmllZCBieSBhbnkgY29ycmVzcG9uZGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDvigJhkZWZhdWx04oCZIHN0YXRlbWVudCBzcGVjaWZpZWQgaW4gdGhlIFlBTkcgc2NoZW1h LuKAnTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpDb25zb2xhcyI+fTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5XaXRoIHRoaXMsIEnigJltIG5vdCBzdXJlIHdoZXRoZXIg d2UgbmVlZCB0aGUg4oCcaW5jbHVkZXMtZGVmYXVsdOKAnSBsZWFmIGN1cnJlbnRseSBzcGVjaWZp ZWQgaW4gdGhlIGRyYWZ0LCBidXQgaWYgd2UgZG8sIHRoZW4gSSB3b3VsZCB0aGluayB0aGF0IGxl YWYgc2hvdWxkIGJlIGVudGlyZWx5IG9wdGlvbmFsLCBpLmUuLCB3aXRob3V0IHRoZSBkZWZhdWx0 DQog4oCcdHJpbeKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8YnI+DQpSb2I8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEFuZHkgQmllcm1hbiAmbHQ7YW5k eUB5dW1hd29ya3MuY29tJmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IDEwIEp1bHkgMjAyMSAxNzo0 MTxicj4NCjxiPlRvOjwvYj4gUm9iIFdpbHRvbiAocndpbHRvbikgJmx0O3J3aWx0b25AY2lzY28u Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTmV0TW9kIFdHICZsdDtuZXRtb2RAaWV0Zi5vcmcmZ3Q7 OyBCYWzDoXpzIExlbmd5ZWwgJmx0O2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbSZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRtb2RdIHlhbmctaW5zdGFuY2UtZmlsZSBpbmNsdWRl LWRlZmF1bHRzIGxlYWY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi Pk9uIEZyaSwgSnVsIDksIDIwMjEgYXQgNToyMyBBTSBSb2IgV2lsdG9uIChyd2lsdG9uKSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCkFuZHksPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4N CiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjM2LjBwdCI+DQpZZXMsIHdoZW4gSSBzdWdnZXN0ZWQgdGhpcywgSSB3YXMgdGhpbmtpbmcgdGhh dCBhIGJvb2xlYW4gZmxhZyBtaWdodCBiZSBzdWZmaWNpZW50LiZuYnNwOyBNeSBwb2ludCBiZWlu ZyB0aGF0IGF1dG9tYXRpY2FsbHkgZmlsdGVyaW5nIG91dCBkZWZhdWx0IHZhbHVlcyBpc27igJl0 IGFsd2F5cyB0aGUgcmlnaHQgdGhpbmcgdG8gZG8uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhlIHNvbHV0aW9uIGlzIHNpbXBsZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPkdldCByaWQgb2YgdGhlIGluYXBwcm9wcmlhdGUgJnF1b3Q7ZGVm YXVsdCB0cmltJnF1b3Q7IHN0YXRlbWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SWYgdGhlIGxlYWYgaXMgcHJlc2VudCB0aGVuIGl0IGlkZW50 aWZpZXMgdGhlIGJhc2ljLW1vZGUgdGhhdCB3YXMgdXNlZCB0byBpbmNsdWRlIGRlZmF1bHRzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SWYgbm90IHRoZW4gdGhlIGluZm9ybWF0aW9uIGlzIGVpdGhl ciBub3Qga25vd24sIG5vdCBhcHBsaWNhYmxlLCBvciBkZWZhdWx0cyB3ZXJlIG5vdCBhZGRlZC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhlICZx dW90O2RlZmF1bHQmcXVvdDsgc3RhdGVtZW50IGlzIGEgYnVnIGJlY2F1c2UgdGhlcmUgaXMgbm8g ZGVmYXVsdCBiYXNpYy1tb2RlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+QWxsIG9mIHRoZSBiYXNp Yy1tb2RlcyBhcmUgaW4gdXNlIGluIGRlcGxveW1lbnRzIGFuZCBubyBjYW1wIGhhcyBldmVyPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5iZWVuIGFibGUgdG8gY29udmluY2UgdGhlIG90aGVycyB0aGF0 IHRoZWlycyBpcyByaWdodC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5BbmR5PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpF LmcuLCBzb21ldGhpbmcgYWxvbmcgdGhlc2UgbGluZXM6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpsZWFmIGV4Y2x1 ZGUtZGVmYXVsdHMgezxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjM2LjBwdCI+DQombmJzcDsgdHlwZSBib29sZWFuOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDsgZGVmYXVsdCB0 cnVlOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2 LjBwdCI+DQombmJzcDsgZGVzY3JpcHRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnENhbiBi ZSB1c2VkIHRvIHJlZHVjZSB0aGUgc2l6ZSBvZiB0aGUgY29udGVudCBkYXRhIGZpbGUuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2 LjBwdCI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV2hlbiB1bnNldCBvciBzZXQg dG8gdHJ1ZSwgZGF0YSBub2RlcyB0aGF0IGhhdmUgYSBkZWZhdWx0IGRlZmluZWQgYW5kPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aGVyZSB0aGUgYWN0dWFsIHZhbHVlIGlzIHRo ZSBkZWZhdWx0IHZhbHVlIGFyZSBleGNsdWRlZCBmcm9tIHRoZSBjb250ZW50PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDtkYXRhLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFdoZW4gc2V0IHRvIGZhbHNlLCBkYXRhIG5vZGVzIHdpdGggZGVmYXVs dCB2YWx1ZSBhcmUgbm90IGZpbHRlcmVkLCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IG1heSBhcHBlYXIgaW4gdGhlIGNvbnRlbnQgZGF0YS7igJ08bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KfTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQi Pg0KV291bGQgdGhpcyBzYXRpc2Z5IHlvdXIgY29uY2Vybj88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NClJlZ2FyZHMs PGJyPg0KUm9iPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8Yj48c3BhbiBsYW5nPSJFTi1VUyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gbmV0bW9kICZsdDs8YSBocmVmPSJt YWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2QtYm91 bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHkgQmllcm1hbjxi cj4NCjxiPlNlbnQ6PC9iPiAwOCBKdWx5IDIwMjEgMTg6MTY8YnI+DQo8Yj5Ubzo8L2I+IE5ldE1v ZCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtuZXRtb2RdIHlh bmctaW5zdGFuY2UtZmlsZSBpbmNsdWRlLWRlZmF1bHRzIGxlYWY8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2 LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYu MHB0Ij4NClRoZSBtb2R1bGUgaGFzIHRoaXMgb2JqZWN0OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM2LjBwdDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBpbmNsdWRlcy1kZWZhdWx0cyB7PC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUgZW51 bWVyYXRpb24gezwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbnVtIHJlcG9ydC1hbGwgezwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB2YWx1ZSAxOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBkZXNjcmlwdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm cXVvdDtBbGwgZGF0YSBub2RlcyBTSE9VTEQgYmUgaW5jbHVkZWQgaW5kZXBlbmRlbnQgb2Y8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW55IGRl ZmF1bHQgdmFsdWVzLiZxdW90Ozs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBlbnVtIHRyaW0gezwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2YWx1ZSAyOzwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtEYXRhIG5vZGVzIHRoYXQgaGF2ZSBhIGRlZmF1 bHQgZGVmaW5lZCBhbmQgd2hlcmU8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgdGhlIGFjdHVhbCB2YWx1ZSBpcyB0aGUgZGVmYXVsdCB2YWx1ZSBT SE9VTEQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgTk9UIGJlIGluY2x1ZGVkLiZxdW90Ozs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBlbnVtIGV4cGxpY2l0IHs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmFs dWUgMzs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb248L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7RGF0YSBub2RlcyB0aGF0IGhh dmUgYSBkZWZhdWx0IGRlZmluZWQgYW5kIHdoZXJlPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBhY3R1YWwgdmFsdWUgaXMgdGhlIGRlZmF1 bHQgdmFsdWUgU0hPVUxEIE5PVCBiZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBpbmNsdWRlZC4gSG93ZXZlciwgaWYgdGhlIGFjdHVhbCB2YWx1 ZSB3YXMgc2V0IGJ5PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGEgTkVUQ09ORiBjbGllbnQgb3Igb3RoZXIgbWFuYWdlbWVudCBhcHBsaWNhdGlv bjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBi eSB0aGUgd2F5IG9mIGFuIGV4cGxpY2l0IG1hbmFnZW1lbnQgb3BlcmF0aW9uIHRoZTwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkYXRhIG5vZGUg U0hPVUxEIGJlIGluY2x1ZGVkLiZxdW90Ozs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGRlZmF1bHQgdHJpbTs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KVGhlIGRyYWZ0IGlzIGV4dHJlbWVseSBzZXJ2ZXIt Y2VudHJpYywgbGlrZSBtb3N0IElFVEYgc3RhbmRhcmRzLCBidXQgdGhpczxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBw dCI+DQpsZWFmIGlzIHRvbyBzZXJ2ZXItY2VudHJpYyB0byBpZ25vcmUuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0 Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpDb25zaWRlciB0aGUgcG9zc2liaWxpdHkgdGhh dCB0aGUgc291cmNlIG9mIHRoZSBmaWxlIGlzIE5PVCBhIE5FVENPTkYgc2VydmVyLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjM2LjBwdCI+DQpUaGlzIGRhdGEgbWF5IG5vdCBiZSBrbm93biBzbyB0aGUgZGVmYXVsdCBvZiAm cXVvdDt0cmltJnF1b3Q7IG1heSBub3QgYmUgY29ycmVjdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCklNTyB0aGlzIGxlYWYgaXMgbm9pc2UgYmVjYXVzZSBhbnkg dG9vbCB0aGF0IGtub3dzIHRoZSBzY2hlbWEgd2lsbCBhbHNvPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCmtu b3cgdGhlIFlBTkcgZGVmYXVsdHMuJm5ic3A7IFRoZSBzb2x1dGlvbiBpcyBpbmNvbXBsZXRlIGFu eXdheSBiZWNhdXNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCnRoZSBwcmVzZW5jZSBvZiBhIGxlYWYgdGhh dCBoYXMgYSBZQU5HIGRlZmF1bHQgaXMgbm90IGVub3VnaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KVGhl Jm5ic3A7ICZxdW90O3JlcG9ydC1hbGwtdGFnZ2VkJnF1b3Q7IG1vZGUgbXVzdCBiZSB1c2VkIHRv IGlkZW50aWZ5IGRlZmF1bHRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpJTU8gdGhpcyBsZWFmIHNob3Vs ZCBiZSByZW1vdmVkLCBidXQgYXQgbGVhc3QgYWRkIGFuIGVudW0gY2FsbGVkICZxdW90O3Vua25v d24mcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDozNi4wcHQiPg0KQW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDozNi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_DM4PR11MB5438FBF7837C1147D786964CB5E99DM4PR11MB5438namp_-- From nobody Tue Jul 27 10:00:20 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C803A0AA9 for ; Tue, 27 Jul 2021 10:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 TZf41qJZmkzx for ; Tue, 27 Jul 2021 10:00:08 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E833A0AA3 for ; Tue, 27 Jul 2021 10:00:08 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id d17so22949027lfv.0 for ; Tue, 27 Jul 2021 10:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iweCKyIJIzvC8D49/mCpF8w0JyRB6opt8xougkrSg/4=; b=Jy611O75ycCJT12R4peiiAPyfYtyUiifEdTrOwdJG8sV7k85xQibhOhjtPL3T5IgcJ F/WkLxtv6yGud20F/PYUCpuzHJ8SqoLB3CWwBFEootqRHPasVr3xj2L9jyiSz/5wP49O gz4E+cPUJdgECBoELww1r6VqKMN37tplDbcEptncbcrIbjwC8BOjhX35l3OVKYoKTw8K 3ocrE/MF7db7wBWYWQQybTbfWcCgVgPbHd2Clgq7s2UAfx9mTe41Boz99BZYR0zMpBl3 tq2t1uHeNF6JEOwOxSHOEVhuPKipKzeS7FDhxMxddjmG4H2pcjHcw8f6GoUoGGabTZaI dRFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iweCKyIJIzvC8D49/mCpF8w0JyRB6opt8xougkrSg/4=; b=UT1ocA0OPKbZoX4ijAEfZGKnRgc0htSVffhPTZ8y777mRno0z1vd5W9gmvMNAKiN06 hza1yYIjHuiy2aemiHLCMrdxI7XdG8aEJ3dD6olLvn0bMzkWV/NFGQul9dqRO5iZIZ2f 5GmjK24GHlBLcjMLtJ17SOdwChpnS9jddVNV/VXKkuX4o3rEUC2tbKCJCh1hd8hA0FdM Pt9uwFd/Lo/Nz+4uALB903c5zP8yEt02q3/lrUAnvQq5sb01/9xG/CyRZNW9c9HCOm0k xCjin+uN4kG6p9p1QJGvIVIUl2jy3XkqFk+epTnIRj8MTnX8hVe035kKiLMeXVJBywfP xDgg== X-Gm-Message-State: AOAM5317DZpuD4uDSdG9TBw6k13q8yMur29kbrBsMzZBNzcrkVAYBe6y sFnQP5YaViCybo2zfudWSdM2FnsBtYYKlgY3s/i76A== X-Google-Smtp-Source: ABdhPJyJwTKqiYhBZehPxRuJqBf+pV8Daqpiju7Opa4N1u6AIiVgv8pQq8TI76lxejk72oZRJJeMKtOWbMxm4/cguew= X-Received: by 2002:ac2:44ad:: with SMTP id c13mr16891944lfm.377.1627405206201; Tue, 27 Jul 2021 10:00:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Tue, 27 Jul 2021 09:59:55 -0700 Message-ID: To: "Rob Wilton (rwilton)" Cc: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= , NetMod WG Content-Type: multipart/alternative; boundary="00000000000038bb0805c81dcd62" Archived-At: Subject: Re: [netmod] yang-instance-file include-defaults leaf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 17:00:15 -0000 --00000000000038bb0805c81dcd62 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, None of this addresses my point that a default value of "trim" is not appropriate. Simply remove the default-stmt so that a missing leaf instance means that no information is provided, rather than meaning defaults were added for basic-mode=3Dtrim. Andy On Tue, Jul 27, 2021 at 8:38 AM Rob Wilton (rwilton) wrote: > Hi Andy, Balazs, > > > > So, the reason that I want a flag to indicate whether default values are > in use is because of this definition of operational in RFC 8342: > > > > Requests to retrieve nodes from always return the value > > in use if the node exists, regardless of any default value specified > > in the YANG module. If no value is returned for a given node, then > > this implies that the node is not used by the device. > > > > It was written this way because otherwise a consumer of operational data > cannot differentiate between: > > (i) This value is not present because it matches the > default value specified in the YANG module, and > > (ii) This value is not present because the server has > failed to return it for some reason (e.g., perhaps the daemon that would > have provided this value is down or not available, or perhaps it is a bug= , > or perhaps it is not implemented and is a missing deviation). > > > > So, I think that in some cases, the absence of a data node does not > necessarily mean that the default value is in effect, and I wanted the > instance-data document to be able to contain and correctly report this da= ta. > > > > I think that this behaviour could be captured by a single leaf. Another > way of articulating this would be: > > > > leaf in-use-values { > > type boolean; > > default false; > > description > > =E2=80=9COnly if set to true, the absence of a value in the > > instance data for a given data node implies that the > > node is not used rather than implicitly taking the > > default value specified by any corresponding > > =E2=80=98default=E2=80=99 statement specified in the YANG schema.=E2= =80=9D; > > } > > > > With this, I=E2=80=99m not sure whether we need the =E2=80=9Cincludes-def= ault=E2=80=9D leaf > currently specified in the draft, but if we do, then I would think that > leaf should be entirely optional, i.e., without the default =E2=80=9Ctrim= =E2=80=9D. > > > > Regards, > Rob > > > > > > *From:* Andy Bierman > *Sent:* 10 July 2021 17:41 > *To:* Rob Wilton (rwilton) > *Cc:* NetMod WG ; Bal=C3=A1zs Lengyel < > balazs.lengyel@ericsson.com> > *Subject:* Re: [netmod] yang-instance-file include-defaults leaf > > > > > > > > On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) > wrote: > > Andy, > > > > Yes, when I suggested this, I was thinking that a boolean flag might be > sufficient. My point being that automatically filtering out default valu= es > isn=E2=80=99t always the right thing to do. > > > > > > > > The solution is simple. > > Get rid of the inappropriate "default trim" statement. > > > > If the leaf is present then it identifies the basic-mode that was used to > include defaults. > > If not then the information is either not known, not applicable, or > defaults were not added. > > > > The "default" statement is a bug because there is no default basic-mode. > > All of the basic-modes are in use in deployments and no camp has ever > > been able to convince the others that theirs is right. > > > > > > Andy > > > > E.g., something along these lines: > > > > leaf exclude-defaults { > > type boolean; > > default true; > > description > > =E2=80=9CCan be used to reduce the size of the content data file. > > > > When unset or set to true, data nodes that have a default defined a= nd > > where the actual value is the default value are excluded from the > content > > data. > > > > When set to false, data nodes with default value are not filtered, > and > > may appear in the content data.=E2=80=9D > > } > > > > Would this satisfy your concern? > > > > Regards, > Rob > > > > > > *From:* netmod *On Behalf Of *Andy Bierman > *Sent:* 08 July 2021 18:16 > *To:* NetMod WG > *Subject:* [netmod] yang-instance-file include-defaults leaf > > > > Hi, > > > > The module has this object: > > > > leaf includes-defaults { > > type enumeration { > > enum report-all { > > value 1; > > description > > "All data nodes SHOULD be included independent of > > any default values."; > > } > > enum trim { > > value 2; > > description > > "Data nodes that have a default defined and where > > the actual value is the default value SHOULD > > NOT be included."; > > } > > enum explicit { > > value 3; > > description > > "Data nodes that have a default defined and where > > the actual value is the default value SHOULD NOT be > > included. However, if the actual value was set by > > a NETCONF client or other management application > > by the way of an explicit management operation the > > data node SHOULD be included."; > > } > > } > > default trim; > > > > The draft is extremely server-centric, like most IETF standards, but this > > leaf is too server-centric to ignore. > > > > Consider the possibility that the source of the file is NOT a NETCONF > server. > > This data may not be known so the default of "trim" may not be correct. > > > > IMO this leaf is noise because any tool that knows the schema will also > > know the YANG defaults. The solution is incomplete anyway because > > the presence of a leaf that has a YANG default is not enough. > > The "report-all-tagged" mode must be used to identify defaults. > > IMO this leaf should be removed, but at least add an enum called "unknown= ". > > > > > > Andy > > > > > > --00000000000038bb0805c81dcd62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

None of this addresses m= y point that a default value of "trim" is not appropriate.
<= div>Simply remove the default-stmt so that a missing leaf instance means th= at
no information is provided, rather than meaning defaults were = added for basic-mode=3Dtrim.


Andy


On Tue, Jul 27, 2021 at 8:38 AM Rob Wilton (rwilton) <rwilton@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

Hi Andy, Balazs,

=C2=A0

So, the reason that I want a flag to indicate = whether default values are in use is because of this definition of operatio= nal in RFC 8342:

=C2=A0

=C2=A0=C2=A0 Requests to retrieve nodes from <= ;operational> always return the value

=C2=A0=C2=A0 in use if the node exists, regardle= ss of any default value specified

=C2=A0=C2=A0 in the YANG module.=C2=A0 If no val= ue is returned for a given node, then

=C2=A0=C2=A0 this implies that the node is not u= sed by the device.

=C2=A0

It was written this way because otherwise a co= nsumer of operational data cannot differentiate between:

(i)= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 This value is not present because it matc= hes the default value specified in the YANG module, and

(ii)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 This value is not present because the ser= ver has failed to return it for some reason (e.g., perhaps the daemon that = would have provided this value is down or not available, or perhaps it is a bug, or perhaps it is not implemented and is a missing deviation).=

=C2=A0

So, I think that in some cases, the absence of= a data node does not necessarily mean that the default value is in effect,= and I wanted the instance-data document to be able to contain and correctl= y report this data.

=C2=A0

I think that this behaviour could be captured = by a single leaf.=C2=A0 Another way of articulating this would be:

=C2=A0

leaf in-use-values {

=C2=A0 type boolean;

=C2=A0 default false;

=C2=A0 description

=C2=A0=C2=A0=C2=A0 =E2=80=9COnly if set to true,= the absence of a value in the

=C2=A0=C2=A0=C2=A0=C2=A0 instance data for a giv= en data node implies that the

=C2=A0=C2=A0=C2=A0=C2=A0node is not used rather = than implicitly taking the

=C2=A0=C2=A0=C2=A0=C2=A0 default value specified= by any corresponding

=C2=A0=C2=A0=C2=A0=C2=A0=E2=80=98default=E2=80= =99 statement specified in the YANG schema.=E2=80=9D;<= /p>

}

=C2=A0

With this, I=E2=80=99m not sure whether we nee= d the =E2=80=9Cincludes-default=E2=80=9D leaf currently specified in the dr= aft, but if we do, then I would think that leaf should be entirely optional= , i.e., without the default =E2=80=9Ctrim=E2=80=9D.

=C2=A0

Regards,
Rob

=C2=A0

=C2=A0

F= rom: Andy Bierman <andy@yumaworks.com>
Sent: 10 July 2021 17:41
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: NetMod WG <netmod@ietf.org>; Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com&g= t;
Subject: Re: [netmod] yang-instance-file include-defaults leaf

=C2=A0

=C2=A0

=C2=A0

On Fri, Jul 9, 2021 at 5:= 23 AM Rob Wilton (rwilton) <rwilton@cisco.com> wrote:

Andy,

=C2=A0

Yes, when I suggested this, I was thinking that a boolean flag might be suf= ficient.=C2=A0 My point being that automatically filtering out default valu= es isn=E2=80=99t always the right thing to do.

=C2=A0

=C2=A0

=C2=A0

The solution is simple.

Get rid of the inappropri= ate "default trim" statement.

=C2=A0

If the leaf is present th= en it identifies the basic-mode that was used to include defaults.

If not then the informati= on is either not known, not applicable, or defaults were not added.<= u>

=C2=A0

The "default" s= tatement is a bug because there is no default basic-mode.

All of the basic-modes ar= e in use in deployments and no camp has ever

been able to convince the= others that theirs is right.

=C2=A0

=C2=A0

Andy

=C2=A0

E.g., something along these lines:

=C2=A0

leaf exclude-defaults {

=C2=A0 type boolean;

=C2=A0 default true;

=C2=A0 description

=C2=A0=C2=A0=C2=A0 =E2=80=9CCan be used to reduce the size of the content d= ata file.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When unset or set to true, data nodes that h= ave a default defined and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 where the actual value is the default value = are excluded from the content

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0data.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When set to false, data nodes with default v= alue are not filtered, and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 may appear in the content data.=E2=80=9D<= /u>

}

=C2=A0

Would this satisfy your concern?

=C2=A0

Regards,
Rob

=C2=A0

=C2=A0

From: netmod <netmod-bounces@i= etf.org> On Behalf Of Andy Bierman
Sent: 08 July 2021 18:16
To: NetMod WG <netmod@ietf.org>
Subject: [netmod] yang-instance-file include-defaults leaf=

=C2=A0

Hi,

=C2=A0

The module has this object:

=C2=A0

=C2=A0=C2=A0=C2=A0 leaf includes-defaults {

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 type enumeration {


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enum report-all {

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value 1;=



=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "All data no=
des SHOULD be included independent of


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 any d=
efault values.";


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


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enum trim {


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value 2;=



=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Data nodes =
that have a default defined and where


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the a=
ctual value is the default value SHOULD


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NOT b=
e included.";


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


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enum explicit {

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value 3;=



=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Data nodes =
that have a default defined and where


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the a=
ctual value is the default value SHOULD NOT be


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inclu=
ded. However, if the actual value was set by


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a NET=
CONF client or other management application


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 by th=
e way of an explicit management operation the


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 data =
node SHOULD be included.";


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


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


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 default trim;


=C2=A0



The draft is extremely server-centric, like most IETF standards, but this

leaf is too server-centric to ignore.

=C2=A0

Consider the possibility that the source of the file is NOT a NETCONF serve= r.

This data may not be known so the default of "trim" may not be co= rrect.

=C2=A0

IMO this leaf is noise because any tool that knows the schema will also<= /u>

know the YANG defaults.=C2=A0 The solution is incomplete anyway because<= /u>

the presence of a leaf that has a YANG default is not enough.=

The=C2=A0 "report-all-tagged" mode must be used to identify defau= lts.

IMO this leaf should be removed, but at least add an enum called "unkn= own".

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

--00000000000038bb0805c81dcd62-- From nobody Tue Jul 27 10:47:20 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C543A0DBC for ; Tue, 27 Jul 2021 10:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=ZMdWkbqa; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=No82mSX7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3MNSBjUayZm for ; Tue, 27 Jul 2021 10:47:12 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007A83A0DB7 for ; Tue, 27 Jul 2021 10:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=50098; q=dns/txt; s=iport; t=1627408031; x=1628617631; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=koRsFCOZxwhl8fKgm4V0zri45IfscNUlUih8qmVgS00=; b=ZMdWkbqaH+r/TcK/7us7ZVyMVqnKt7eDGwbH7Ds5496AiRj+B9F3kiGo AKfXEKzGzT983lZ5Pif9PszI9n6jHKAc5Aohgx3qm8hyf1yI4N0il04zi j9TYUbdsjdZlw94IRfxC14nLPgcl/w0TSQURBgsmWw/CUo/JMoBL+nevJ U=; IronPort-PHdr: =?us-ascii?q?A9a23=3ARLgpcx31eDDwA5MpsmDPTVBlVkEcU/3cLxMQ4?= =?us-ascii?q?4UgkbFVNK+k+seqME/e4KBri1nEFcXe5ulfguXb+6bnRSQb4JmHvXxDFf4EV?= =?us-ascii?q?xIMhcgM2QB1BsmDBB7qMfvjcCsgH98EX1hgrDm3NEFPE5P4YFvf6nS58T8VH?= =?us-ascii?q?ED5Mgx4buT4E4LflYK5zee3rpbSeA5PwjG6ZOAaEQ=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A6XAbb6HREhppJWNdpLqFSpHXdLJyesId70?= =?us-ascii?q?hD6qkvc31om52j+fxGws516fatskdvZJkh8erwX5VoMkmsi6KdgLNhfItKOT?= =?us-ascii?q?OHhILGFvAY0WKP+UyEJ8S6zJ8g6U4CSdk/NDSTNykBsS+S2mDReLxMrKjlgc?= =?us-ascii?q?KVbKXlvgpQpGpRGsddBnJCe36m+zpNNXB77PQCZf6hz/sCgwDlVWUcb8y9CH?= =?us-ascii?q?VAdfPEvcf3mJXvZgNDLwI76SGV5AnYq4LSIly95FMzQjlPybAt/SzuiAri/J?= =?us-ascii?q?iutPm911v1y3LT1ZJLg9Hso+EzRvBky/JlbwkEuDzYI7iJaIfy+gzdZ9vfsW?= =?us-ascii?q?rCpeO85yvI+f4Ds085MFvF+icFkDOQoQrGo0WSuWNwx0GT+/AQgFkBepZ8bU?= =?us-ascii?q?UzSGqF16NohqAO7Itbm22erJZZFhXGgWD04MXJTQhjkg6urWMlivN7tQ0TbW?= =?us-ascii?q?IyUs4bkWUkxjIeLH7AJlOM1Kk3VO11SM3M7vdfdl2XK3jfo2l02dSpGnA+BA?= =?us-ascii?q?2PTEQOstGcl2E+pgE382IIgMgE2nsQ/pM0TJdJo+zCL6RzjblLCssbd7h0Cu?= =?us-ascii?q?sNSda+TmbNXRXPOmSPJkmPLtBKB1vd75rspLkl7uCjf5IFiJM0hZTaSVtd8X?= =?us-ascii?q?U/fkr/YPf+lKGjMiq9CVlVeA6dhP22y6IJz4EUdYCbRxFrEmpe4fdIi89vdv?= =?us-ascii?q?HmZw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIGQDZRQBh/5xdJa1QCh4BAQsSDII?= =?us-ascii?q?OC4EjMCMuB3daNzGER4NIA4U5iF4DmjKBLhSBEQNUCwEBAQ0BAUEEAQGEWAI?= =?us-ascii?q?XgmcCJTUIDgIEAQEBEgEBBQEBAQIBBgR7E4VoDYZCAQEBAQMSEQoTAQE3AQ8?= =?us-ascii?q?CAQYCEQQBASEBBgMCAgIwFAkIAgQOBQgTB4JQgX5XAy8BjRSPNAGBOgKKH3q?= =?us-ascii?q?BMoEBggcBAQYEBIUwGII0CYE6gnyEDQEBhmMnHIFJRIFYgmI+hA8IEwIaNIJ?= =?us-ascii?q?hNoIMIoJpgRcEJzCBeRKSDoNNiDqDZolUkhYKgyaeWRKmY7YlhHQCBAIEBQI?= =?us-ascii?q?OAQEGgWEBOSs+cHAVgyRQGQ6OHwwWg0+KXnM4AgYBCgEBAwmKSQEB?= X-IronPort-AV: E=Sophos;i="5.84,274,1620691200"; d="scan'208,217";a="899108454" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Jul 2021 17:47:09 +0000 Received: from mail.cisco.com (xbe-rcd-004.cisco.com [173.37.102.19]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 16RHl9Hn021939 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 27 Jul 2021 17:47:09 GMT Received: from xfe-aln-001.cisco.com (173.37.135.121) by xbe-rcd-004.cisco.com (173.37.102.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 27 Jul 2021 12:47:09 -0500 Received: from xfe-aln-002.cisco.com (173.37.135.122) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 27 Jul 2021 12:47:08 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Tue, 27 Jul 2021 12:47:08 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OYgJqSYbt7D5gV7UBlGqG2jhNMPKVishGq3IDk6Ypz1t5Knd6T4nH5DrEzZtLxe5WOr0Z/kFwnsHU2hPJwQLSHluOSm8dmSYJStYQxpyZ4/tzy29DejUOKKyCxZ3jYz51b6PLe1KdPApSFH20dG8g4LLJB9glbpe4tlsJUv6AQ+AjlafyUDV9MMW18rLwX3DNNK0AMri0xwJWFx74AReEWxbPkEUzhKkZsMksn2JjyliBT1krxeEIS3H91d7Vk6YZfPqvgXGazjFvfn62M1+2XuYDZAD8BtbIijwU0Y11gUUTqxo/+idenpCdro/iRmWicuooWfujs/ovCz8WLLL5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=koRsFCOZxwhl8fKgm4V0zri45IfscNUlUih8qmVgS00=; b=MnbH8asZzrj6UgtTyXUcbWMYFXIW1byviDp3FMVg7McpbdmIaRrhT0Ov8oyfQ/z/1iUrfbIPi6N6dkZaEU82IC4h3PpSmEEuhau2yV6NOSZgXp/XqHGvvtdONSDFlz/UNSk9W3f0LyhGxsBvSsq4PaNX9rnimrhCMjR+OX+2jQPo7kAC24CQwWcDp2oboStC1nMGCU9171kUd/8SL4Rg9gF6xCqHrGcVlgVDrRZM+mkx4eIFU6/iX3NFd0KHOS/Euwn6YjH0Pm0VN6L0abI0m59bLcVlvwujXOaifjhGkzgDEd0kgcXesK3OedsoO+e4iebyzX+2Aw48SfXMH6v3lw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=koRsFCOZxwhl8fKgm4V0zri45IfscNUlUih8qmVgS00=; b=No82mSX7SzGXfDo55uPBNBRrx44Z4Y6nixErg6JRafiyQRaDbf/o9HYBpZ1+Fj5K87Tuw1M2NH3BIwLN+O78NtfYFoUcuNR3aP5Fcvo0KIO0/dRPGYT+8YDrzPxmdId6FI9IxjZ9NQloqVcijkmC4AjOHpvTnF6z82/+5iEckFg= Received: from DM4PR11MB5438.namprd11.prod.outlook.com (2603:10b6:5:399::21) by DM6PR11MB3691.namprd11.prod.outlook.com (2603:10b6:5:146::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.18; Tue, 27 Jul 2021 17:47:07 +0000 Received: from DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12]) by DM4PR11MB5438.namprd11.prod.outlook.com ([fe80::a85a:cb8b:2d73:5e12%7]) with mapi id 15.20.4373.018; Tue, 27 Jul 2021 17:47:07 +0000 From: "Rob Wilton (rwilton)" To: Andy Bierman CC: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , NetMod WG Thread-Topic: [netmod] yang-instance-file include-defaults leaf Thread-Index: AQHXdB0ZnZibUXpuT0+6mfsyEmKi+6s6kMRwgAHbvACAGptLcIAAIaCAgAAMfYA= Date: Tue, 27 Jul 2021 17:47:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none;yumaworks.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5f2227c3-b1f4-446f-5bbe-08d951268d6d x-ms-traffictypediagnostic: DM6PR11MB3691: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Jo7HMmjKO7YZepj0QTWsc9Sl85ovYzHYSo679w+Fvh9W00zuq3cxZurkeyh85+0oRLV8Do7ko+szXmuUNkoN/P8uEtQA1KhNLh6k8tAioOPkqipVue8GniWD9IY24Y4GcilfvzjkKyI2vyMG2nn/PrGYEy9ICAEVMBf/kL/OBVnewD49BN0S111pi4hbo9YKW7wAG2rXWTD210zCB3RPKTQSMTHiXujVKjzf3aPcFVSGQdRIzziCK1Y8gjweXBVi+jKUqc9PsYXcB/RoT0Dt2ElrjXyAufgRnmQmrxvnInvv6X7bIUoxdPXNkFBD1BH5I+auNm2A3P4uGl0EP9blSZ/fUBZtxO9ThTH85V21w05LVZgaef9JqgkWCXJAJuCqj7XUZNuC7ax2mc8yds8d/fPmXKBJNfMPkJF0UE49L6LeG+SGplufMYpckq3jlU6/N8K2ijBaH5u+pnhsRJQfGTXUbNaWgPZxMuOqMHz7xLHNGCVOUbr0L5YVxqL+qFMIxc1nFWtgA1sbOgMzv94J6Ftvv9+mAMKsnE0krUkmYS+dZdkCpSAPfRInzROdi4BUx2+s9yC4PGk6vUvML6L2rbr2PNEr5oHfE36md1OHyWCq1BsQWLHJxcPFKrhyTQDqw4iGcNYxkp9QS8vGjYB+vnph/S8ShalBIe9rViD/fujw1aHW16AnlFSQg7jBWSDKOZqp8DRyClGMrazU1FHy8g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5438.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(346002)(376002)(366004)(39860400002)(122000001)(7696005)(52536014)(55016002)(38100700002)(33656002)(6506007)(53546011)(26005)(5660300002)(71200400001)(4326008)(86362001)(54906003)(186003)(9326002)(76116006)(66476007)(83380400001)(8936002)(64756008)(66556008)(66446008)(2906002)(478600001)(6916009)(9686003)(316002)(66946007)(8676002)(38070700004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Ny82M0o5eE82c0FOZzdTajZhaUZoUm5YKytVaWhXQW5KRFZFT2hTZ1UyZHRD?= =?utf-8?B?dXdVWDFNaWlmek0rSDdPMGdFMXZ1NXgrRUtIWnVnb1F2a1VlMnN2OFlVWk5r?= =?utf-8?B?aTA1czRIR0owNTloYnI3K3l6UjZ2ZVF0NDlOK3hkV0hOWHZ5eHlPMkFmOXdX?= =?utf-8?B?NjU0aW5CanFGZ2JjZXZNU05EQ2h6bzlMbXlYZmdMNHM4ZFppQUxiVVRFa0hG?= =?utf-8?B?ZFRpSmN2RENGSXAxYldJVXUrQWlGTUJTcy9tOEhydkNBUWRST3g4ZW9IZ2tk?= =?utf-8?B?N3lrVnJGb1loQzlKSGVNU3NNbTArOTNGOFVKQWRrYzVsdDdsUlhnQUtaTEhk?= =?utf-8?B?YzN4U1ZqdE8wS09uTS9hOGN0bGxYU09IMFU0cmluZ1NQcCs1V2Vsa2JqSXhl?= =?utf-8?B?dFYyWWRoYmRxT0hibEViUDFBUmpYVWljT0h2U3R0b0txb1lpRW1hL09yTGtY?= =?utf-8?B?NDJUT2FYR3VTTmVoNU9XQnNSY0VWK2VockFrNStOZFdPVnhUc2daaXczZ0Nw?= =?utf-8?B?VGhUa01NalV6NUh3ZmJEczNDVEJlU3J2NlV5VGJlMDBwWmtHbVRXMERxQm5z?= =?utf-8?B?b0dqdUlldHNpY29pQWxTeVJNREloWVpVME9mMDBLYzdPbGhFUWYrYjdBTmV6?= =?utf-8?B?VzNxc2l2dzZWSUdnVENUWUxqTkJZUUdPUjh3Zkl3QmhGdDJTaDkxVnErYWNs?= =?utf-8?B?WEgwVDI4djUvQVNNM1hHaG5FUFlPakwrellZV3hrWWRGNnRRRUFkZ01ZRWRQ?= =?utf-8?B?Mk84eU1IRmkwSDk4RUhMVGFoUWNBR3gzUkpFQ0JmMGc5aDdtVGRQdEU5TytM?= =?utf-8?B?QzNhcHRtdzE1bzR0NFR6em1kb3dlWENYL3RONGlad3VwQ3BHVFdMSjcvWkRr?= =?utf-8?B?TjNXNUdsTytTa2tvMklwcWRJcW1BNmFwWjJDSlY3OGRFTWZqTFk5UWN2dXpv?= =?utf-8?B?SXhNOStab1loRVpsTjEyYlRuRE1IMzdoZEt5SnU2T0lPVWxZUjdSaWJsWERD?= =?utf-8?B?WDJMdmFzTEJuUm5tVkVWSFhQcTF2SnY0OTM5UXJnSU9sV0VhMWhjMjUvOTBC?= =?utf-8?B?OUQ0cnNyVXF5MmJOYWx6aXhieGhLN3FwY2FwOEovcHhaQjJtRFVSaldoTUs0?= =?utf-8?B?QXlaRW9Zd3AyaCt2SzhINWF1b29GdHFqbDRyb0NXektqbHErZzNWNkpPcStX?= =?utf-8?B?UTBnS1ZGNXN0bWxaeW5jc3NrT3dMRlJqZ1F6OXl2WXBCUUpQOXNMMTB3RnZr?= =?utf-8?B?REhLRk5MZVdmVnNUdU1aZTBaNXNPVHBBVE12NHNPNWxZTWlEVzRmVzNkUDFo?= =?utf-8?B?cURBQmR4QnI5MWE2WXk3Y21nZGZ4RXY3dkhhY3g3aGpLWEJvczB3NThuTURI?= =?utf-8?B?bXVXKzYxbjkxZTBKUVVyMnloL2prOVp2WXNXNzFidFVOMHRUWkkwMk16cUM2?= =?utf-8?B?T0N3Zm4zejdWcmJJSU11KzRWTWVWUWZmM2hoUWl6akVQd1NkT2FTNzNySk9F?= =?utf-8?B?Z3c5Ujg3ZHNQOEFaMEQ1b1pHWXJkVTRzVnMrNmVhRDljYkJyYndXc0lxZDBx?= =?utf-8?B?RkhVckZTU0prNjdLbDF6a3NGMnFiYXdmSTIwN3lUWUpRRlNqa2ttYitnTFV4?= =?utf-8?B?UVZKcGlVUk9pRVBRSzc3ZkxNMkFlMVNNMTZ3R2EwOCtxSzdGUmhuc3VFQ1Jo?= =?utf-8?B?SnVPdnBFMEpXMDByVURuVFhlcUk0TTlGTHkrY214RzRyT3dNMXhIa3d1bG5M?= =?utf-8?Q?yNWFwsVlzBHLK138B1Z78lhdYIK9RVMKNjYl5QD?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM4PR11MB5438E049D0AAE4184F5F2B8FB5E99DM4PR11MB5438namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5438.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5f2227c3-b1f4-446f-5bbe-08d951268d6d X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2021 17:47:07.1503 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hbUbUzZRGtTXnNILwexnl1z2Je4cK1ZfVV+GDDwrEHU0zGmpzIMe6K6ohmtn51Y87IjxRBx/aylD2fq8HusGlQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3691 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xbe-rcd-004.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [netmod] yang-instance-file include-defaults leaf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 17:47:18 -0000 --_000_DM4PR11MB5438E049D0AAE4184F5F2B8FB5E99DM4PR11MB5438namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KVGhlIGNvbW1lbnQgYXQgdGhlIGVuZCBvZiBteSBlbWFpbCB3YXM6DQrigJxX aXRoIHRoaXMsIEnigJltIG5vdCBzdXJlIHdoZXRoZXIgd2UgbmVlZCB0aGUg4oCcaW5jbHVkZXMt ZGVmYXVsdOKAnSBsZWFmIGN1cnJlbnRseSBzcGVjaWZpZWQgaW4gdGhlIGRyYWZ0LCBidXQgaWYg d2UgZG8sIHRoZW4gSSB3b3VsZCB0aGluayB0aGF0IGxlYWYgc2hvdWxkIGJlIGVudGlyZWx5IG9w dGlvbmFsLCBpLmUuLCB3aXRob3V0IHRoZSBkZWZhdWx0IOKAnHRyaW3igJ0u4oCdDQpSZWdhcmRz LA0KUm9iDQoNCg0KRnJvbTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+DQpTZW50 OiAyNyBKdWx5IDIwMjEgMTg6MDANClRvOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBj aXNjby5jb20+DQpDYzogQmFsw6F6cyBMZW5neWVsIDxiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5j b20+OyBOZXRNb2QgV0cgPG5ldG1vZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSB5 YW5nLWluc3RhbmNlLWZpbGUgaW5jbHVkZS1kZWZhdWx0cyBsZWFmDQoNCkhpLA0KDQpOb25lIG9m IHRoaXMgYWRkcmVzc2VzIG15IHBvaW50IHRoYXQgYSBkZWZhdWx0IHZhbHVlIG9mICJ0cmltIiBp cyBub3QgYXBwcm9wcmlhdGUuDQpTaW1wbHkgcmVtb3ZlIHRoZSBkZWZhdWx0LXN0bXQgc28gdGhh dCBhIG1pc3NpbmcgbGVhZiBpbnN0YW5jZSBtZWFucyB0aGF0DQpubyBpbmZvcm1hdGlvbiBpcyBw cm92aWRlZCwgcmF0aGVyIHRoYW4gbWVhbmluZyBkZWZhdWx0cyB3ZXJlIGFkZGVkIGZvciBiYXNp Yy1tb2RlPXRyaW0uDQoNCg0KQW5keQ0KDQoNCk9uIFR1ZSwgSnVsIDI3LCAyMDIxIGF0IDg6Mzgg QU0gUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2lsdG9u QGNpc2NvLmNvbT4+IHdyb3RlOg0KSGkgQW5keSwgQmFsYXpzLA0KDQpTbywgdGhlIHJlYXNvbiB0 aGF0IEkgd2FudCBhIGZsYWcgdG8gaW5kaWNhdGUgd2hldGhlciBkZWZhdWx0IHZhbHVlcyBhcmUg aW4gdXNlIGlzIGJlY2F1c2Ugb2YgdGhpcyBkZWZpbml0aW9uIG9mIG9wZXJhdGlvbmFsIGluIFJG QyA4MzQyOg0KDQogICBSZXF1ZXN0cyB0byByZXRyaWV2ZSBub2RlcyBmcm9tIDxvcGVyYXRpb25h bD4gYWx3YXlzIHJldHVybiB0aGUgdmFsdWUNCiAgIGluIHVzZSBpZiB0aGUgbm9kZSBleGlzdHMs IHJlZ2FyZGxlc3Mgb2YgYW55IGRlZmF1bHQgdmFsdWUgc3BlY2lmaWVkDQogICBpbiB0aGUgWUFO RyBtb2R1bGUuICBJZiBubyB2YWx1ZSBpcyByZXR1cm5lZCBmb3IgYSBnaXZlbiBub2RlLCB0aGVu DQogICB0aGlzIGltcGxpZXMgdGhhdCB0aGUgbm9kZSBpcyBub3QgdXNlZCBieSB0aGUgZGV2aWNl Lg0KDQpJdCB3YXMgd3JpdHRlbiB0aGlzIHdheSBiZWNhdXNlIG90aGVyd2lzZSBhIGNvbnN1bWVy IG9mIG9wZXJhdGlvbmFsIGRhdGEgY2Fubm90IGRpZmZlcmVudGlhdGUgYmV0d2VlbjoNCg0KKGkp ICAgICAgICAgICAgICAgICAgVGhpcyB2YWx1ZSBpcyBub3QgcHJlc2VudCBiZWNhdXNlIGl0IG1h dGNoZXMgdGhlIGRlZmF1bHQgdmFsdWUgc3BlY2lmaWVkIGluIHRoZSBZQU5HIG1vZHVsZSwgYW5k DQoNCihpaSkgICAgICAgICAgICAgICAgVGhpcyB2YWx1ZSBpcyBub3QgcHJlc2VudCBiZWNhdXNl IHRoZSBzZXJ2ZXIgaGFzIGZhaWxlZCB0byByZXR1cm4gaXQgZm9yIHNvbWUgcmVhc29uIChlLmcu LCBwZXJoYXBzIHRoZSBkYWVtb24gdGhhdCB3b3VsZCBoYXZlIHByb3ZpZGVkIHRoaXMgdmFsdWUg aXMgZG93biBvciBub3QgYXZhaWxhYmxlLCBvciBwZXJoYXBzIGl0IGlzIGEgYnVnLCBvciBwZXJo YXBzIGl0IGlzIG5vdCBpbXBsZW1lbnRlZCBhbmQgaXMgYSBtaXNzaW5nIGRldmlhdGlvbikuDQoN ClNvLCBJIHRoaW5rIHRoYXQgaW4gc29tZSBjYXNlcywgdGhlIGFic2VuY2Ugb2YgYSBkYXRhIG5v ZGUgZG9lcyBub3QgbmVjZXNzYXJpbHkgbWVhbiB0aGF0IHRoZSBkZWZhdWx0IHZhbHVlIGlzIGlu IGVmZmVjdCwgYW5kIEkgd2FudGVkIHRoZSBpbnN0YW5jZS1kYXRhIGRvY3VtZW50IHRvIGJlIGFi bGUgdG8gY29udGFpbiBhbmQgY29ycmVjdGx5IHJlcG9ydCB0aGlzIGRhdGEuDQoNCkkgdGhpbmsg dGhhdCB0aGlzIGJlaGF2aW91ciBjb3VsZCBiZSBjYXB0dXJlZCBieSBhIHNpbmdsZSBsZWFmLiAg QW5vdGhlciB3YXkgb2YgYXJ0aWN1bGF0aW5nIHRoaXMgd291bGQgYmU6DQoNCmxlYWYgaW4tdXNl LXZhbHVlcyB7DQogIHR5cGUgYm9vbGVhbjsNCiAgZGVmYXVsdCBmYWxzZTsNCiAgZGVzY3JpcHRp b24NCiAgICDigJxPbmx5IGlmIHNldCB0byB0cnVlLCB0aGUgYWJzZW5jZSBvZiBhIHZhbHVlIGlu IHRoZQ0KICAgICBpbnN0YW5jZSBkYXRhIGZvciBhIGdpdmVuIGRhdGEgbm9kZSBpbXBsaWVzIHRo YXQgdGhlDQogICAgbm9kZSBpcyBub3QgdXNlZCByYXRoZXIgdGhhbiBpbXBsaWNpdGx5IHRha2lu ZyB0aGUNCiAgICAgZGVmYXVsdCB2YWx1ZSBzcGVjaWZpZWQgYnkgYW55IGNvcnJlc3BvbmRpbmcN CiAgICDigJhkZWZhdWx04oCZIHN0YXRlbWVudCBzcGVjaWZpZWQgaW4gdGhlIFlBTkcgc2NoZW1h LuKAnTsNCn0NCg0KV2l0aCB0aGlzLCBJ4oCZbSBub3Qgc3VyZSB3aGV0aGVyIHdlIG5lZWQgdGhl IOKAnGluY2x1ZGVzLWRlZmF1bHTigJ0gbGVhZiBjdXJyZW50bHkgc3BlY2lmaWVkIGluIHRoZSBk cmFmdCwgYnV0IGlmIHdlIGRvLCB0aGVuIEkgd291bGQgdGhpbmsgdGhhdCBsZWFmIHNob3VsZCBi ZSBlbnRpcmVseSBvcHRpb25hbCwgaS5lLiwgd2l0aG91dCB0aGUgZGVmYXVsdCDigJx0cmlt4oCd Lg0KDQpSZWdhcmRzLA0KUm9iDQoNCg0KRnJvbTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jr cy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+DQpTZW50OiAxMCBKdWx5IDIwMjEgMTc6 NDENClRvOiBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb208bWFpbHRvOnJ3 aWx0b25AY2lzY28uY29tPj4NCkNjOiBOZXRNb2QgV0cgPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86 bmV0bW9kQGlldGYub3JnPj47IEJhbMOhenMgTGVuZ3llbCA8YmFsYXpzLmxlbmd5ZWxAZXJpY3Nz b24uY29tPG1haWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20+Pg0KU3ViamVjdDogUmU6 IFtuZXRtb2RdIHlhbmctaW5zdGFuY2UtZmlsZSBpbmNsdWRlLWRlZmF1bHRzIGxlYWYNCg0KDQoN Ck9uIEZyaSwgSnVsIDksIDIwMjEgYXQgNToyMyBBTSBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndp bHRvbkBjaXNjby5jb208bWFpbHRvOnJ3aWx0b25AY2lzY28uY29tPj4gd3JvdGU6DQpBbmR5LA0K DQpZZXMsIHdoZW4gSSBzdWdnZXN0ZWQgdGhpcywgSSB3YXMgdGhpbmtpbmcgdGhhdCBhIGJvb2xl YW4gZmxhZyBtaWdodCBiZSBzdWZmaWNpZW50LiAgTXkgcG9pbnQgYmVpbmcgdGhhdCBhdXRvbWF0 aWNhbGx5IGZpbHRlcmluZyBvdXQgZGVmYXVsdCB2YWx1ZXMgaXNu4oCZdCBhbHdheXMgdGhlIHJp Z2h0IHRoaW5nIHRvIGRvLg0KDQoNCg0KVGhlIHNvbHV0aW9uIGlzIHNpbXBsZS4NCkdldCByaWQg b2YgdGhlIGluYXBwcm9wcmlhdGUgImRlZmF1bHQgdHJpbSIgc3RhdGVtZW50Lg0KDQpJZiB0aGUg bGVhZiBpcyBwcmVzZW50IHRoZW4gaXQgaWRlbnRpZmllcyB0aGUgYmFzaWMtbW9kZSB0aGF0IHdh cyB1c2VkIHRvIGluY2x1ZGUgZGVmYXVsdHMuDQpJZiBub3QgdGhlbiB0aGUgaW5mb3JtYXRpb24g aXMgZWl0aGVyIG5vdCBrbm93biwgbm90IGFwcGxpY2FibGUsIG9yIGRlZmF1bHRzIHdlcmUgbm90 IGFkZGVkLg0KDQpUaGUgImRlZmF1bHQiIHN0YXRlbWVudCBpcyBhIGJ1ZyBiZWNhdXNlIHRoZXJl IGlzIG5vIGRlZmF1bHQgYmFzaWMtbW9kZS4NCkFsbCBvZiB0aGUgYmFzaWMtbW9kZXMgYXJlIGlu IHVzZSBpbiBkZXBsb3ltZW50cyBhbmQgbm8gY2FtcCBoYXMgZXZlcg0KYmVlbiBhYmxlIHRvIGNv bnZpbmNlIHRoZSBvdGhlcnMgdGhhdCB0aGVpcnMgaXMgcmlnaHQuDQoNCg0KQW5keQ0KDQpFLmcu LCBzb21ldGhpbmcgYWxvbmcgdGhlc2UgbGluZXM6DQoNCmxlYWYgZXhjbHVkZS1kZWZhdWx0cyB7 DQogIHR5cGUgYm9vbGVhbjsNCiAgZGVmYXVsdCB0cnVlOw0KICBkZXNjcmlwdGlvbg0KICAgIOKA nENhbiBiZSB1c2VkIHRvIHJlZHVjZSB0aGUgc2l6ZSBvZiB0aGUgY29udGVudCBkYXRhIGZpbGUu DQoNCiAgICAgIFdoZW4gdW5zZXQgb3Igc2V0IHRvIHRydWUsIGRhdGEgbm9kZXMgdGhhdCBoYXZl IGEgZGVmYXVsdCBkZWZpbmVkIGFuZA0KICAgICAgd2hlcmUgdGhlIGFjdHVhbCB2YWx1ZSBpcyB0 aGUgZGVmYXVsdCB2YWx1ZSBhcmUgZXhjbHVkZWQgZnJvbSB0aGUgY29udGVudA0KICAgICAgZGF0 YS4NCg0KICAgICAgV2hlbiBzZXQgdG8gZmFsc2UsIGRhdGEgbm9kZXMgd2l0aCBkZWZhdWx0IHZh bHVlIGFyZSBub3QgZmlsdGVyZWQsIGFuZA0KICAgICAgbWF5IGFwcGVhciBpbiB0aGUgY29udGVu dCBkYXRhLuKAnQ0KfQ0KDQpXb3VsZCB0aGlzIHNhdGlzZnkgeW91ciBjb25jZXJuPw0KDQpSZWdh cmRzLA0KUm9iDQoNCg0KRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgQW5keSBCaWVybWFuDQpT ZW50OiAwOCBKdWx5IDIwMjEgMTg6MTYNClRvOiBOZXRNb2QgV0cgPG5ldG1vZEBpZXRmLm9yZzxt YWlsdG86bmV0bW9kQGlldGYub3JnPj4NClN1YmplY3Q6IFtuZXRtb2RdIHlhbmctaW5zdGFuY2Ut ZmlsZSBpbmNsdWRlLWRlZmF1bHRzIGxlYWYNCg0KSGksDQoNClRoZSBtb2R1bGUgaGFzIHRoaXMg b2JqZWN0Og0KDQoNCiAgICBsZWFmIGluY2x1ZGVzLWRlZmF1bHRzIHsNCg0KICAgICAgIHR5cGUg ZW51bWVyYXRpb24gew0KDQogICAgICAgICBlbnVtIHJlcG9ydC1hbGwgew0KDQogICAgICAgICAg IHZhbHVlIDE7DQoNCiAgICAgICAgICAgZGVzY3JpcHRpb24NCg0KICAgICAgICAgICAgICJBbGwg ZGF0YSBub2RlcyBTSE9VTEQgYmUgaW5jbHVkZWQgaW5kZXBlbmRlbnQgb2YNCg0KICAgICAgICAg ICAgICAgYW55IGRlZmF1bHQgdmFsdWVzLiI7DQoNCiAgICAgICAgIH0NCg0KICAgICAgICAgZW51 bSB0cmltIHsNCg0KICAgICAgICAgICB2YWx1ZSAyOw0KDQogICAgICAgICAgIGRlc2NyaXB0aW9u DQoNCiAgICAgICAgICAgICAiRGF0YSBub2RlcyB0aGF0IGhhdmUgYSBkZWZhdWx0IGRlZmluZWQg YW5kIHdoZXJlDQoNCiAgICAgICAgICAgICAgIHRoZSBhY3R1YWwgdmFsdWUgaXMgdGhlIGRlZmF1 bHQgdmFsdWUgU0hPVUxEDQoNCiAgICAgICAgICAgICAgIE5PVCBiZSBpbmNsdWRlZC4iOw0KDQog ICAgICAgICB9DQoNCiAgICAgICAgIGVudW0gZXhwbGljaXQgew0KDQogICAgICAgICAgIHZhbHVl IDM7DQoNCiAgICAgICAgICAgZGVzY3JpcHRpb24NCg0KICAgICAgICAgICAgICJEYXRhIG5vZGVz IHRoYXQgaGF2ZSBhIGRlZmF1bHQgZGVmaW5lZCBhbmQgd2hlcmUNCg0KICAgICAgICAgICAgICAg dGhlIGFjdHVhbCB2YWx1ZSBpcyB0aGUgZGVmYXVsdCB2YWx1ZSBTSE9VTEQgTk9UIGJlDQoNCiAg ICAgICAgICAgICAgIGluY2x1ZGVkLiBIb3dldmVyLCBpZiB0aGUgYWN0dWFsIHZhbHVlIHdhcyBz ZXQgYnkNCg0KICAgICAgICAgICAgICAgYSBORVRDT05GIGNsaWVudCBvciBvdGhlciBtYW5hZ2Vt ZW50IGFwcGxpY2F0aW9uDQoNCiAgICAgICAgICAgICAgIGJ5IHRoZSB3YXkgb2YgYW4gZXhwbGlj aXQgbWFuYWdlbWVudCBvcGVyYXRpb24gdGhlDQoNCiAgICAgICAgICAgICAgIGRhdGEgbm9kZSBT SE9VTEQgYmUgaW5jbHVkZWQuIjsNCg0KICAgICAgICAgfQ0KDQogICAgICAgfQ0KDQogICAgICAg ZGVmYXVsdCB0cmltOw0KDQoNClRoZSBkcmFmdCBpcyBleHRyZW1lbHkgc2VydmVyLWNlbnRyaWMs IGxpa2UgbW9zdCBJRVRGIHN0YW5kYXJkcywgYnV0IHRoaXMNCmxlYWYgaXMgdG9vIHNlcnZlci1j ZW50cmljIHRvIGlnbm9yZS4NCg0KQ29uc2lkZXIgdGhlIHBvc3NpYmlsaXR5IHRoYXQgdGhlIHNv dXJjZSBvZiB0aGUgZmlsZSBpcyBOT1QgYSBORVRDT05GIHNlcnZlci4NClRoaXMgZGF0YSBtYXkg bm90IGJlIGtub3duIHNvIHRoZSBkZWZhdWx0IG9mICJ0cmltIiBtYXkgbm90IGJlIGNvcnJlY3Qu DQoNCklNTyB0aGlzIGxlYWYgaXMgbm9pc2UgYmVjYXVzZSBhbnkgdG9vbCB0aGF0IGtub3dzIHRo ZSBzY2hlbWEgd2lsbCBhbHNvDQprbm93IHRoZSBZQU5HIGRlZmF1bHRzLiAgVGhlIHNvbHV0aW9u IGlzIGluY29tcGxldGUgYW55d2F5IGJlY2F1c2UNCnRoZSBwcmVzZW5jZSBvZiBhIGxlYWYgdGhh dCBoYXMgYSBZQU5HIGRlZmF1bHQgaXMgbm90IGVub3VnaC4NClRoZSAgInJlcG9ydC1hbGwtdGFn Z2VkIiBtb2RlIG11c3QgYmUgdXNlZCB0byBpZGVudGlmeSBkZWZhdWx0cy4NCklNTyB0aGlzIGxl YWYgc2hvdWxkIGJlIHJlbW92ZWQsIGJ1dCBhdCBsZWFzdCBhZGQgYW4gZW51bSBjYWxsZWQgInVu a25vd24iLg0KDQoNCkFuZHkNCg0KDQo= --_000_DM4PR11MB5438E049D0AAE4184F5F2B8FB5E99DM4PR11MB5438namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpwLmdtYWlsLW0tMjI1NzE2NjUxMjgwNjg2ODY5NG1zb2xpc3Rw YXJhZ3JhcGgsIGxpLmdtYWlsLW0tMjI1NzE2NjUxMjgwNjg2ODY5NG1zb2xpc3RwYXJhZ3JhcGgs IGRpdi5nbWFpbC1tLTIyNTcxNjY1MTI4MDY4Njg2OTRtc29saXN0cGFyYWdyYXBoDQoJe21zby1z dHlsZS1uYW1lOmdtYWlsLW1fLTIyNTcxNjY1MTI4MDY4Njg2OTRtc29saXN0cGFyYWdyYXBoOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tR0I7fQ0K c3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3 Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+SGkgQW5keSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIGNvbW1lbnQgYXQgdGhlIGVuZCBvZiBt eSBlbWFpbCB3YXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPuKAnDwvc3Bhbj5XaXRo IHRoaXMsIEnigJltIG5vdCBzdXJlIHdoZXRoZXIgd2UgbmVlZCB0aGUg4oCcaW5jbHVkZXMtZGVm YXVsdOKAnSBsZWFmIGN1cnJlbnRseSBzcGVjaWZpZWQgaW4gdGhlIGRyYWZ0LCBidXQgaWYgd2Ug ZG8sIHRoZW4gSSB3b3VsZA0KIHRoaW5rIHRoYXQgbGVhZiBzaG91bGQgYmUgZW50aXJlbHkgb3B0 aW9uYWwsIGkuZS4sIHdpdGhvdXQgdGhlIGRlZmF1bHQg4oCcdHJpbeKAnS7igJ08bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJvYjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3Bh biBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gQW5keSBC aWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMjcg SnVseSAyMDIxIDE4OjAwPGJyPg0KPGI+VG86PC9iPiBSb2IgV2lsdG9uIChyd2lsdG9uKSAmbHQ7 cndpbHRvbkBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBCYWzDoXpzIExlbmd5ZWwgJmx0 O2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbSZndDs7IE5ldE1vZCBXRyAmbHQ7bmV0bW9kQGll dGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW25ldG1vZF0geWFuZy1pbnN0YW5j ZS1maWxlIGluY2x1ZGUtZGVmYXVsdHMgbGVhZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij5Ob25lIG9mIHRoaXMgYWRkcmVzc2VzIG15IHBvaW50IHRoYXQg YSBkZWZhdWx0IHZhbHVlIG9mICZxdW90O3RyaW0mcXVvdDsgaXMgbm90IGFwcHJvcHJpYXRlLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+U2ltcGx5IHJlbW92ZSB0aGUgZGVmYXVsdC1zdG10IHNvIHRo YXQgYSBtaXNzaW5nIGxlYWYgaW5zdGFuY2UgbWVhbnMgdGhhdDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+bm8gaW5mb3JtYXRpb24gaXMgcHJvdmlkZWQsIHJhdGhlciB0aGFuIG1lYW5pbmcgZGVmYXVs dHMgd2VyZSBhZGRlZCBmb3IgYmFzaWMtbW9kZT10cmltLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gVHVlLCBKdWwgMjcsIDIwMjEgYXQgODozOCBBTSBSb2Ig V2lsdG9uIChyd2lsdG9uKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIj5y d2lsdG9uQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MzYuMHB0Ij4NCkhpIEFuZHksIEJhbGF6cyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NClNvLCB0aGUgcmVhc29u IHRoYXQgSSB3YW50IGEgZmxhZyB0byBpbmRpY2F0ZSB3aGV0aGVyIGRlZmF1bHQgdmFsdWVzIGFy ZSBpbiB1c2UgaXMgYmVjYXVzZSBvZiB0aGlzIGRlZmluaXRpb24gb2Ygb3BlcmF0aW9uYWwgaW4g UkZDIDgzNDI6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IFJlcXVlc3RzIHRvIHJldHJpZXZlIG5vZGVzIGZyb20gJmx0O29wZXJhdGlvbmFsJmd0OyBhbHdh eXMgcmV0dXJuIHRoZSB2YWx1ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBpbiB1c2UgaWYgdGhlIG5vZGUgZXhpc3RzLCByZWdhcmRsZXNzIG9mIGFueSBkZWZh dWx0IHZhbHVlIHNwZWNpZmllZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBpbiB0aGUgWUFORyBtb2R1bGUuJm5ic3A7IElmIG5vIHZhbHVlIGlzIHJldHVybmVk IGZvciBhIGdpdmVuIG5vZGUsIHRoZW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgdGhpcyBpbXBsaWVzIHRoYXQgdGhlIG5vZGUgaXMgbm90IHVzZWQgYnkgdGhl IGRldmljZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpJdCB3YXMgd3JpdHRlbiB0aGlzIHdheSBiZWNh dXNlIG90aGVyd2lzZSBhIGNvbnN1bWVyIG9mIG9wZXJhdGlvbmFsIGRhdGEgY2Fubm90IGRpZmZl cmVudGlhdGUgYmV0d2Vlbjo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTIyNTcx NjY1MTI4MDY4Njg2OTRtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTAuMHB0 Ij4NCihpKTxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj5UaGlzIHZhbHVlIGlzIG5vdCBwcmVzZW50IGJlY2F1c2Ug aXQgbWF0Y2hlcyB0aGUgZGVmYXVsdCB2YWx1ZSBzcGVjaWZpZWQgaW4gdGhlIFlBTkcgbW9kdWxl LCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tLTIyNTcxNjY1MTI4MDY4Njg2 OTRtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6OTAuMHB0Ij4NCihpaSk8c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ VGhpcyB2YWx1ZSBpcyBub3QgcHJlc2VudCBiZWNhdXNlIHRoZSBzZXJ2ZXIgaGFzIGZhaWxlZCB0 byByZXR1cm4gaXQgZm9yIHNvbWUgcmVhc29uIChlLmcuLCBwZXJoYXBzIHRoZSBkYWVtb24gdGhh dCB3b3VsZCBoYXZlIHByb3ZpZGVkIHRoaXMgdmFsdWUgaXMgZG93biBvciBub3QgYXZhaWxhYmxl LCBvciBwZXJoYXBzIGl0IGlzIGEgYnVnLCBvciBwZXJoYXBzIGl0IGlzIG5vdCBpbXBsZW1lbnRl ZCBhbmQgaXMgYSBtaXNzaW5nIGRldmlhdGlvbikuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQpTbywgSSB0aGluayB0 aGF0IGluIHNvbWUgY2FzZXMsIHRoZSBhYnNlbmNlIG9mIGEgZGF0YSBub2RlIGRvZXMgbm90IG5l Y2Vzc2FyaWx5IG1lYW4gdGhhdCB0aGUgZGVmYXVsdCB2YWx1ZSBpcyBpbiBlZmZlY3QsIGFuZCBJ IHdhbnRlZCB0aGUgaW5zdGFuY2UtZGF0YSBkb2N1bWVudCB0byBiZSBhYmxlIHRvIGNvbnRhaW4g YW5kIGNvcnJlY3RseSByZXBvcnQgdGhpcyBkYXRhLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KSSB0aGluayB0aGF0 IHRoaXMgYmVoYXZpb3VyIGNvdWxkIGJlIGNhcHR1cmVkIGJ5IGEgc2luZ2xlIGxlYWYuJm5ic3A7 IEFub3RoZXIgd2F5IG9mIGFydGljdWxhdGluZyB0aGlzIHdvdWxkIGJlOjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPmxlYWYg aW4tdXNlLXZhbHVlcyB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpDb25zb2xhcyI+Jm5ic3A7IHR5cGUgYm9vbGVhbjs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsgZGVm YXVsdCBmYWxzZTs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsgZGVzY3JpcHRpb248L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzIj4mbmJzcDsmbmJzcDsmbmJz cDsg4oCcT25seSBpZiBzZXQgdG8gdHJ1ZSwgdGhlIGFic2VuY2Ugb2YgYSB2YWx1ZSBpbiB0aGU8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 NzIuMHB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv bGFzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW5zdGFuY2UgZGF0YSBmb3IgYSBnaXZlbiBk YXRhIG5vZGUgaW1wbGllcyB0aGF0IHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO25v ZGUgaXMgbm90IHVzZWQgcmF0aGVyIHRoYW4gaW1wbGljaXRseSB0YWtpbmcgdGhlPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlZmF1bHQgdmFsdWUgc3BlY2lmaWVkIGJ5IGFueSBjb3Jy ZXNwb25kaW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjcyLjBwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpDb25zb2xhcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A74oCYZGVmYXVsdOKAmSBzdGF0 ZW1lbnQgc3BlY2lmaWVkIGluIHRoZSBZQU5HIHNjaGVtYS7igJ07PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpDb25zb2xhcyI+fTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0K Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MzYuMHB0Ij4NCldpdGggdGhpcywgSeKAmW0gbm90IHN1cmUgd2hldGhlciB3ZSBuZWVkIHRoZSDi gJxpbmNsdWRlcy1kZWZhdWx04oCdIGxlYWYgY3VycmVudGx5IHNwZWNpZmllZCBpbiB0aGUgZHJh ZnQsIGJ1dCBpZiB3ZSBkbywgdGhlbiBJIHdvdWxkIHRoaW5rIHRoYXQgbGVhZiBzaG91bGQgYmUg ZW50aXJlbHkgb3B0aW9uYWwsIGkuZS4sIHdpdGhvdXQgdGhlIGRlZmF1bHQg4oCcdHJpbeKAnS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQi Pg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MzYuMHB0Ij4NClJlZ2FyZHMsPGJyPg0KUm9iPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQombmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KPGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEFuZHkgQmllcm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmFuZHlAeXVtYXdvcmtzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFuZHlAeXVtYXdvcmtzLmNvbTwv YT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMTAgSnVseSAyMDIxIDE3OjQxPGJyPg0KPGI+VG86 PC9iPiBSb2IgV2lsdG9uIChyd2lsdG9uKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lz Y28uY29tIiB0YXJnZXQ9Il9ibGFuayI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxi PkNjOjwvYj4gTmV0TW9kIFdHICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPiZndDs7IEJhbMOhenMgTGVuZ3llbCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbbmV0bW9kXSB5YW5nLWluc3RhbmNlLWZpbGUgaW5jbHVkZS1kZWZhdWx0cyBs ZWFmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIu MHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCk9uIEZyaSwgSnVsIDksIDIwMjEgYXQgNToy MyBBTSBSb2IgV2lsdG9uIChyd2lsdG9uKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lz Y28uY29tIiB0YXJnZXQ9Il9ibGFuayI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDo3Mi4wcHQiPg0KQW5keSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NClllcywgd2hlbiBJIHN1Z2dlc3Rl ZCB0aGlzLCBJIHdhcyB0aGlua2luZyB0aGF0IGEgYm9vbGVhbiBmbGFnIG1pZ2h0IGJlIHN1ZmZp Y2llbnQuJm5ic3A7IE15IHBvaW50IGJlaW5nIHRoYXQgYXV0b21hdGljYWxseSBmaWx0ZXJpbmcg b3V0IGRlZmF1bHQgdmFsdWVzIGlzbuKAmXQgYWx3YXlzIHRoZSByaWdodCB0aGluZyB0byBkby48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQi Pg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6NzIuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQpUaGUgc29sdXRpb24g aXMgc2ltcGxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQpHZXQgcmlkIG9mIHRoZSBpbmFwcHJvcHJpYXRl ICZxdW90O2RlZmF1bHQgdHJpbSZxdW90OyBzdGF0ZW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjcyLjBwdCI+DQpJZiB0aGUgbGVhZiBpcyBwcmVzZW50IHRoZW4gaXQgaWRl bnRpZmllcyB0aGUgYmFzaWMtbW9kZSB0aGF0IHdhcyB1c2VkIHRvIGluY2x1ZGUgZGVmYXVsdHMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6NzIuMHB0Ij4NCklmIG5vdCB0aGVuIHRoZSBpbmZvcm1hdGlvbiBpcyBlaXRoZXIg bm90IGtub3duLCBub3QgYXBwbGljYWJsZSwgb3IgZGVmYXVsdHMgd2VyZSBub3QgYWRkZWQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6NzIuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQpUaGUgJnF1b3Q7ZGVmYXVs dCZxdW90OyBzdGF0ZW1lbnQgaXMgYSBidWcgYmVjYXVzZSB0aGVyZSBpcyBubyBkZWZhdWx0IGJh c2ljLW1vZGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCkFsbCBvZiB0aGUgYmFzaWMtbW9kZXMgYXJlIGlu IHVzZSBpbiBkZXBsb3ltZW50cyBhbmQgbm8gY2FtcCBoYXMgZXZlcjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+ DQpiZWVuIGFibGUgdG8gY29udmluY2UgdGhlIG90aGVycyB0aGF0IHRoZWlycyBpcyByaWdodC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDo3Mi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjcyLjBwdCI+DQpBbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+ DQpFLmcuLCBzb21ldGhpbmcgYWxvbmcgdGhlc2UgbGluZXM6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQpsZWFmIGV4 Y2x1ZGUtZGVmYXVsdHMgezxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjcyLjBwdCI+DQombmJzcDsgdHlwZSBib29sZWFuOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQombmJzcDsgZGVmYXVs dCB0cnVlOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjcyLjBwdCI+DQombmJzcDsgZGVzY3JpcHRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnENh biBiZSB1c2VkIHRvIHJlZHVjZSB0aGUgc2l6ZSBvZiB0aGUgY29udGVudCBkYXRhIGZpbGUuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4N CiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjcyLjBwdCI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgV2hlbiB1bnNldCBvciBz ZXQgdG8gdHJ1ZSwgZGF0YSBub2RlcyB0aGF0IGhhdmUgYSBkZWZhdWx0IGRlZmluZWQgYW5kPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aGVyZSB0aGUgYWN0dWFsIHZhbHVlIGlz IHRoZSBkZWZhdWx0IHZhbHVlIGFyZSBleGNsdWRlZCBmcm9tIHRoZSBjb250ZW50PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCiZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDtkYXRhLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdoZW4gc2V0IHRvIGZhbHNlLCBkYXRhIG5vZGVzIHdpdGggZGVm YXVsdCB2YWx1ZSBhcmUgbm90IGZpbHRlcmVkLCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG1heSBhcHBlYXIgaW4gdGhlIGNvbnRlbnQgZGF0YS7igJ08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KfTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQombmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4w cHQiPg0KV291bGQgdGhpcyBzYXRpc2Z5IHlvdXIgY29uY2Vybj88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KJm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NClJlZ2Fy ZHMsPGJyPg0KUm9iPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6NzIuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20g MGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8Yj48c3BhbiBsYW5nPSJFTi1V UyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gbmV0bW9kICZsdDs8YSBocmVm PSJtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2Qt Ym91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHkgQmllcm1h bjxicj4NCjxiPlNlbnQ6PC9iPiAwOCBKdWx5IDIwMjEgMTg6MTY8YnI+DQo8Yj5Ubzo8L2I+IE5l dE1vZCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtuZXRtb2Rd IHlhbmctaW5zdGFuY2UtZmlsZSBpbmNsdWRlLWRlZmF1bHRzIGxlYWY8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjcyLjBwdCI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 NzIuMHB0Ij4NClRoZSBtb2R1bGUgaGFzIHRoaXMgb2JqZWN0OjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQom bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0OjcyLjBwdDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBpbmNsdWRlcy1kZWZhdWx0cyB7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHR5cGUg ZW51bWVyYXRpb24gezwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbnVtIHJlcG9ydC1hbGwgezwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2YWx1ZSAxOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBkZXNjcmlwdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmcXVvdDtBbGwgZGF0YSBub2RlcyBTSE9VTEQgYmUgaW5jbHVkZWQgaW5kZXBlbmRlbnQgb2Y8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYW55 IGRlZmF1bHQgdmFsdWVzLiZxdW90Ozs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBlbnVtIHRyaW0gezwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB2YWx1ZSAyOzwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbjwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtEYXRhIG5vZGVzIHRoYXQgaGF2ZSBhIGRl ZmF1bHQgZGVmaW5lZCBhbmQgd2hlcmU8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIGFjdHVhbCB2YWx1ZSBpcyB0aGUgZGVmYXVsdCB2YWx1 ZSBTSE9VTEQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgTk9UIGJlIGluY2x1ZGVkLiZxdW90Ozs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBlbnVtIGV4cGxpY2l0IHs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg dmFsdWUgMzs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb248L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7RGF0YSBub2RlcyB0aGF0 IGhhdmUgYSBkZWZhdWx0IGRlZmluZWQgYW5kIHdoZXJlPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBhY3R1YWwgdmFsdWUgaXMgdGhlIGRl ZmF1bHQgdmFsdWUgU0hPVUxEIE5PVCBiZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbmNsdWRlZC4gSG93ZXZlciwgaWYgdGhlIGFjdHVhbCB2 YWx1ZSB3YXMgc2V0IGJ5PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGEgTkVUQ09ORiBjbGllbnQgb3Igb3RoZXIgbWFuYWdlbWVudCBhcHBsaWNh dGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIu MHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBieSB0aGUgd2F5IG9mIGFuIGV4cGxpY2l0IG1hbmFnZW1lbnQgb3BlcmF0aW9uIHRoZTwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkYXRhIG5v ZGUgU0hPVUxEIGJlIGluY2x1ZGVkLiZxdW90Ozs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9 PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGRlZmF1bHQgdHJpbTs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjcyLjBwdDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KVGhlIGRyYWZ0IGlzIGV4dHJlbWVseSBzZXJ2 ZXItY2VudHJpYywgbGlrZSBtb3N0IElFVEYgc3RhbmRhcmRzLCBidXQgdGhpczxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Ojcy LjBwdCI+DQpsZWFmIGlzIHRvbyBzZXJ2ZXItY2VudHJpYyB0byBpZ25vcmUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIu MHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQpDb25zaWRlciB0aGUgcG9zc2liaWxpdHkg dGhhdCB0aGUgc291cmNlIG9mIHRoZSBmaWxlIGlzIE5PVCBhIE5FVENPTkYgc2VydmVyLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjcyLjBwdCI+DQpUaGlzIGRhdGEgbWF5IG5vdCBiZSBrbm93biBzbyB0aGUgZGVmYXVsdCBv ZiAmcXVvdDt0cmltJnF1b3Q7IG1heSBub3QgYmUgY29ycmVjdC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0K Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCklNTyB0aGlzIGxlYWYgaXMgbm9pc2UgYmVjYXVzZSBh bnkgdG9vbCB0aGF0IGtub3dzIHRoZSBzY2hlbWEgd2lsbCBhbHNvPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4N Cmtub3cgdGhlIFlBTkcgZGVmYXVsdHMuJm5ic3A7IFRoZSBzb2x1dGlvbiBpcyBpbmNvbXBsZXRl IGFueXdheSBiZWNhdXNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCnRoZSBwcmVzZW5jZSBvZiBhIGxlYWYg dGhhdCBoYXMgYSBZQU5HIGRlZmF1bHQgaXMgbm90IGVub3VnaC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0K VGhlJm5ic3A7ICZxdW90O3JlcG9ydC1hbGwtdGFnZ2VkJnF1b3Q7IG1vZGUgbXVzdCBiZSB1c2Vk IHRvIGlkZW50aWZ5IGRlZmF1bHRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQpJTU8gdGhpcyBsZWFmIHNo b3VsZCBiZSByZW1vdmVkLCBidXQgYXQgbGVhc3QgYWRkIGFuIGVudW0gY2FsbGVkICZxdW90O3Vu a25vd24mcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQom bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDo3Mi4wcHQiPg0KQW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdCI+DQombmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDo3Mi4wcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_DM4PR11MB5438E049D0AAE4184F5F2B8FB5E99DM4PR11MB5438namp_-- From nobody Tue Jul 27 11:11:50 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D720B3A0544 for ; Tue, 27 Jul 2021 11:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 u0CtpLneOKRf for ; Tue, 27 Jul 2021 11:11:42 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B5323A0538 for ; Tue, 27 Jul 2021 11:11:41 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id u3so23225724lff.9 for ; Tue, 27 Jul 2021 11:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i3ZcMhD5+ugC/Myd953ikrvaxqQOoL9edh3IDlhqYNA=; b=QFFZaGBtvnZ59TeiosGDSzvDZfdk49qzbJT4RlAJmYnxrppHRTWjQmYvsWHZFA5lX9 MeIF6Y9ESm6Lj5DhRTyr+KdpsKMvJTZg6KtlrFUrX62WQr5F2UwDkdSCi4CUrkw2RAh1 bich3yWVNn0D6EL+Z//lSv8maHn2ofF7B6KFfDuQXp05q2BknsmZ+N/HKdczUw8097eA L8OJofJfiP/Bwwj5k4cSu6qL7s6nV4XZGDv5roOZgYuKlSnjKz2db9UeYD3jTQEHn8jM 4z7f6Wd31x3dgLvG1gP4lL3JfidK3cP70zMXjgORWBFsecHSHe/r5scJU+t/0aV4tUwZ JD/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i3ZcMhD5+ugC/Myd953ikrvaxqQOoL9edh3IDlhqYNA=; b=S/1mRnp0ey0KBhTkh+GB2Txa/fuVmWQJuEkxo73hEpixl3N49iYHbrQr3i3lthZZw6 Z47xcY5TIi40jmlhCZYs/IqCXmFq79uBQm4uKoh0f7Xj5anfCrshIBDj70pt/dDaPicT qd3k+6oJnKmQGiA4vCY0CJuZaqdMK/uAYmT8MI7ihewi/RbgTRqBe5ww2fxOQakOTzqa eHEhbwg20Kkp5n5o5oBItwqKMv98HaoR/OLiKcSnHVZ3+T0FMO7iWPXFBVLJWqmrWQ2G cuQrmTID6S5HMJLDyFUptINVRv8yT7ziRWLRIiNC81ZVM7rVt2JFuVIkBy5jF7RoNxXJ 1oOQ== X-Gm-Message-State: AOAM531mli4FRYTPolZUXWcsKtlKSPkg5nJSO3aqqopGZkH8prfPM1TA WgSfGLWqmAbknHvrwsLe2C6nj9MwDXD17kJfXAY2Ug== X-Google-Smtp-Source: ABdhPJzDwJzmEgzokJl+0INwjD/4FK9+yC3jztOHQPCR7QPk9QiWIKQ8jWiCNtDq5CAnRFXuTgmwcZZqBbi8UsFQxIE= X-Received: by 2002:a05:6512:3745:: with SMTP id a5mr16933445lfs.478.1627409499442; Tue, 27 Jul 2021 11:11:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Bierman Date: Tue, 27 Jul 2021 11:11:28 -0700 Message-ID: To: "Rob Wilton (rwilton)" Cc: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= , NetMod WG Content-Type: multipart/alternative; boundary="0000000000001e666f05c81ecd56" Archived-At: Subject: Re: [netmod] yang-instance-file include-defaults leaf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 18:11:48 -0000 --0000000000001e666f05c81ecd56 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 27, 2021 at 10:47 AM Rob Wilton (rwilton) wrote: > Hi Andy, > > > > The comment at the end of my email was: > > =E2=80=9CWith this, I=E2=80=99m not sure whether we need the =E2=80=9Cinc= ludes-default=E2=80=9D leaf > currently specified in the draft, but if we do, then I would think that > leaf should be entirely optional, i.e., without the default =E2=80=9Ctrim= =E2=80=9D.=E2=80=9D > OK then we are in agreement about the default-stmt. WRT: the absence of a data node does not necessarily mean that the default value is in effect, Agreed. However this is not a server-wide corner-case, so a global flag does not really help. Even if the server is adding defaults, it may not know the current "in-use" value for 1 leaf. Following NMDA rules, the server does not report anything. Note that this is a corner-case within NMDA and has nothing whatsoever to do with the YANG instance file RFC. The solution to this NMDA problem is to report the unknown leaf with an attribute that indicates "no-data". Otherwise a missing leaf with a YANG default will be incorrectly interpreted as an "in-use" value. > Regards, > > Rob > > > Andy > > > *From:* Andy Bierman > *Sent:* 27 July 2021 18:00 > *To:* Rob Wilton (rwilton) > *Cc:* Bal=C3=A1zs Lengyel ; NetMod WG < > netmod@ietf.org> > *Subject:* Re: [netmod] yang-instance-file include-defaults leaf > > > > Hi, > > > > None of this addresses my point that a default value of "trim" is not > appropriate. > > Simply remove the default-stmt so that a missing leaf instance means that > > no information is provided, rather than meaning defaults were added for > basic-mode=3Dtrim. > > > > > > Andy > > > > > > On Tue, Jul 27, 2021 at 8:38 AM Rob Wilton (rwilton) > wrote: > > Hi Andy, Balazs, > > > > So, the reason that I want a flag to indicate whether default values are > in use is because of this definition of operational in RFC 8342: > > > > Requests to retrieve nodes from always return the value > > in use if the node exists, regardless of any default value specified > > in the YANG module. If no value is returned for a given node, then > > this implies that the node is not used by the device. > > > > It was written this way because otherwise a consumer of operational data > cannot differentiate between: > > (i) This value is not present because it matches the > default value specified in the YANG module, and > > (ii) This value is not present because the server has > failed to return it for some reason (e.g., perhaps the daemon that would > have provided this value is down or not available, or perhaps it is a bug= , > or perhaps it is not implemented and is a missing deviation). > > > > So, I think that in some cases, the absence of a data node does not > necessarily mean that the default value is in effect, and I wanted the > instance-data document to be able to contain and correctly report this da= ta. > > > > I think that this behaviour could be captured by a single leaf. Another > way of articulating this would be: > > > > leaf in-use-values { > > type boolean; > > default false; > > description > > =E2=80=9COnly if set to true, the absence of a value in the > > instance data for a given data node implies that the > > node is not used rather than implicitly taking the > > default value specified by any corresponding > > =E2=80=98default=E2=80=99 statement specified in the YANG schema.=E2= =80=9D; > > } > > > > With this, I=E2=80=99m not sure whether we need the =E2=80=9Cincludes-def= ault=E2=80=9D leaf > currently specified in the draft, but if we do, then I would think that > leaf should be entirely optional, i.e., without the default =E2=80=9Ctrim= =E2=80=9D. > > > > Regards, > Rob > > > > > > *From:* Andy Bierman > *Sent:* 10 July 2021 17:41 > *To:* Rob Wilton (rwilton) > *Cc:* NetMod WG ; Bal=C3=A1zs Lengyel < > balazs.lengyel@ericsson.com> > *Subject:* Re: [netmod] yang-instance-file include-defaults leaf > > > > > > > > On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) > wrote: > > Andy, > > > > Yes, when I suggested this, I was thinking that a boolean flag might be > sufficient. My point being that automatically filtering out default valu= es > isn=E2=80=99t always the right thing to do. > > > > > > > > The solution is simple. > > Get rid of the inappropriate "default trim" statement. > > > > If the leaf is present then it identifies the basic-mode that was used to > include defaults. > > If not then the information is either not known, not applicable, or > defaults were not added. > > > > The "default" statement is a bug because there is no default basic-mode. > > All of the basic-modes are in use in deployments and no camp has ever > > been able to convince the others that theirs is right. > > > > > > Andy > > > > E.g., something along these lines: > > > > leaf exclude-defaults { > > type boolean; > > default true; > > description > > =E2=80=9CCan be used to reduce the size of the content data file. > > > > When unset or set to true, data nodes that have a default defined a= nd > > where the actual value is the default value are excluded from the > content > > data. > > > > When set to false, data nodes with default value are not filtered, > and > > may appear in the content data.=E2=80=9D > > } > > > > Would this satisfy your concern? > > > > Regards, > Rob > > > > > > *From:* netmod *On Behalf Of *Andy Bierman > *Sent:* 08 July 2021 18:16 > *To:* NetMod WG > *Subject:* [netmod] yang-instance-file include-defaults leaf > > > > Hi, > > > > The module has this object: > > > > leaf includes-defaults { > > type enumeration { > > enum report-all { > > value 1; > > description > > "All data nodes SHOULD be included independent of > > any default values."; > > } > > enum trim { > > value 2; > > description > > "Data nodes that have a default defined and where > > the actual value is the default value SHOULD > > NOT be included."; > > } > > enum explicit { > > value 3; > > description > > "Data nodes that have a default defined and where > > the actual value is the default value SHOULD NOT be > > included. However, if the actual value was set by > > a NETCONF client or other management application > > by the way of an explicit management operation the > > data node SHOULD be included."; > > } > > } > > default trim; > > > > The draft is extremely server-centric, like most IETF standards, but this > > leaf is too server-centric to ignore. > > > > Consider the possibility that the source of the file is NOT a NETCONF > server. > > This data may not be known so the default of "trim" may not be correct. > > > > IMO this leaf is noise because any tool that knows the schema will also > > know the YANG defaults. The solution is incomplete anyway because > > the presence of a leaf that has a YANG default is not enough. > > The "report-all-tagged" mode must be used to identify defaults. > > IMO this leaf should be removed, but at least add an enum called "unknown= ". > > > > > > Andy > > > > > > --0000000000001e666f05c81ecd56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 27, 2021 at 10:47 AM Rob = Wilton (rwilton) <rwilton@cisco.com> wrote:

Hi Andy,

=C2=A0

The comment at the end of my email was:=

=E2=80=9CWith this, I=E2=80=99m not sur= e whether we need the =E2=80=9Cincludes-default=E2=80=9D leaf currently spe= cified in the draft, but if we do, then I would think that leaf should be entirely optional, i.e., without the default =E2= =80=9Ctrim=E2=80=9D.=E2=80=9D


OK then we are in agreement about the default-stmt.

=

WRT:

=C2=A0 =C2=A0 =C2=A0the a= bsence of a data node does not necessarily mean that the default value is i= n effect,

Agreed. However this is not a server= -wide corner-case, so a global=C2=A0flag does not really help.
Ev= en if the server is adding defaults, it may not know the current "in-u= se" value for 1 leaf.
Following NMDA rules, the server does = not report anything.=C2=A0 Note that this is a corner-case within
NMDA <operational> and has nothing whatsoever to do with the YANG in= stance file RFC.

The solution to this NMDA problem= is to report the unknown leaf with an attribute that indicates "no-da= ta".
Otherwise a missing leaf with a YANG default will be in= correctly interpreted as an "in-use" value.

<= div>
=C2=A0=C2=A0
=C2=A0

Regards,

Rob

=C2=A0


Andy
=C2=A0

=C2=A0

F= rom: Andy Bierman <andy@yumaworks.com>
Sent: 27 July 2021 18:00
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>; NetMod WG <= ;netmod@ietf.org&g= t;
Subject: Re: [netmod] yang-instance-file include-defaults leaf

=C2=A0

Hi,

=C2=A0

None of this addresses my= point that a default value of "trim" is not appropriate.<= u>

Simply remove the default= -stmt so that a missing leaf instance means that

no information is provide= d, rather than meaning defaults were added for basic-mode=3Dtrim.=

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

On Tue, Jul 27, 2021 at 8= :38 AM Rob Wilton (rwilton) <rwilton@cisco.com> wrote:

Hi Andy, Balazs,

=C2=A0

So, the reason that I want a flag to indicate whether default values are in= use is because of this definition of operational in RFC 8342:

=C2=A0

=C2=A0=C2=A0 Requests to retrieve nodes from <operational> always= return the value

=C2=A0=C2=A0 in use if the node exists, regardless of any default value= specified

=C2=A0=C2=A0 in the YANG module.=C2=A0 If no value is returned for a gi= ven node, then

=C2=A0=C2=A0 this implies that the node is not used by the device.

=C2=A0

It was written this way because otherwise a consumer of operational data ca= nnot differentiate between:

(i)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This value is not present because it matches the default value speci= fied in the YANG module, and

(ii)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 This value is not present because the server has failed to return it= for some reason (e.g., perhaps the daemon that would have provided this va= lue is down or not available, or perhaps it is a bug, or perhaps it is not = implemented and is a missing deviation).

=C2=A0

So, I think that in some cases, the absence of a data node does not necessa= rily mean that the default value is in effect, and I wanted the instance-da= ta document to be able to contain and correctly report this data.=

=C2=A0

I think that this behaviour could be captured by a single leaf.=C2=A0 Anoth= er way of articulating this would be:

=C2=A0

leaf in-use-values {

=C2=A0 type boolean;

=C2=A0 default false;

=C2=A0 description

=C2=A0=C2=A0=C2=A0 =E2= =80=9COnly if set to true, the absence of a value in the

=C2=A0=C2=A0=C2=A0=C2= =A0 instance data for a given data node implies that the

=C2=A0=C2=A0=C2=A0=C2= =A0node is not used rather than implicitly taking the<= /p>

=C2=A0=C2=A0=C2=A0=C2= =A0 default value specified by any corresponding

=C2=A0=C2=A0=C2=A0=C2= =A0=E2=80=98default=E2=80=99 statement specified in the YANG schema.=E2=80= =9D;

}<= /p>

=C2=A0

With this, I=E2=80=99m not sure whether we need the =E2=80=9Cincludes-defau= lt=E2=80=9D leaf currently specified in the draft, but if we do, then I wou= ld think that leaf should be entirely optional, i.e., without the default = =E2=80=9Ctrim=E2=80=9D.

=C2=A0

Regards,
Rob

=C2=A0

=C2=A0

From: Andy Bierman = <andy@yumaworks.= com>
Sent: 10 July 2021 17:41
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: NetMod WG <netmod@ietf.org>; Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com&g= t;
Subject: Re: [netmod] yang-instance-file include-defaults leaf

=C2=A0

=C2=A0

=C2=A0

On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) <rwilton@cisco.com> wrote:=

Andy,

=C2=A0

Yes, when I suggested this, I was thinking that a boolean flag might be suf= ficient.=C2=A0 My point being that automatically filtering out default valu= es isn=E2=80=99t always the right thing to do.

=C2=A0

=C2=A0

=C2=A0

The solution is simple.

Get rid of the inappropriate "default trim" statement.<= /u>

=C2=A0

If the leaf is present then it identifies the basic-mode that was used to i= nclude defaults.

If not then the information is either not known, not applicable, or default= s were not added.

=C2=A0

The "default" statement is a bug because there is no default basi= c-mode.

All of the basic-modes are in use in deployments and no camp has ever

been able to convince the others that theirs is right.

=C2=A0

=C2=A0

Andy

=C2=A0

E.g., something along these lines:

=C2=A0

leaf exclude-defaults {

=C2=A0 type boolean;

=C2=A0 default true;

=C2=A0 description

=C2=A0=C2=A0=C2=A0 =E2=80=9CCan be used to reduce the size of the content d= ata file.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When unset or set to true, data nodes that h= ave a default defined and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 where the actual value is the default value = are excluded from the content

=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0data.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When set to false, data nodes with default v= alue are not filtered, and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 may appear in the content data.=E2=80=9D<= /u>

}

=C2=A0

Would this satisfy your concern?

=C2=A0

Regards,
Rob

=C2=A0

=C2=A0

From: netmod <netmod-bounces@i= etf.org> On Behalf Of Andy Bierman
Sent: 08 July 2021 18:16
To: NetMod WG <netmod@ietf.org>
Subject: [netmod] yang-instance-file include-defaults leaf=

=C2=A0

Hi,

=C2=A0

The module has this object:

=C2=A0

=C2=A0=C2=A0=C2=A0 leaf includes-defaults {

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 type enumeration {


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enum report-all {

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value 1;=



=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "All data no=
des SHOULD be included independent of


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 any d=
efault values.";


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


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enum trim {


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value 2;=



=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Data nodes =
that have a default defined and where


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the a=
ctual value is the default value SHOULD


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 NOT b=
e included.";


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


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enum explicit {

=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value 3;=



=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 description<=
/u>


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "Data nodes =
that have a default defined and where


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the a=
ctual value is the default value SHOULD NOT be


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inclu=
ded. However, if the actual value was set by


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 a NET=
CONF client or other management application


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 by th=
e way of an explicit management operation the


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 data =
node SHOULD be included.";


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


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


=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 default trim;


=C2=A0



The draft is extremely server-centric, like most IETF standards, but this

leaf is too server-centric to ignore.

=C2=A0

Consider the possibility that the source of the file is NOT a NETCONF serve= r.

This data may not be known so the default of "trim" may not be co= rrect.

=C2=A0

IMO this leaf is noise because any tool that knows the schema will also<= /u>

know the YANG defaults.=C2=A0 The solution is incomplete anyway because<= /u>

the presence of a leaf that has a YANG default is not enough.=

The=C2=A0 "report-all-tagged" mode must be used to identify defau= lts.

IMO this leaf should be removed, but at least add an enum called "unkn= own".

=C2=A0

=C2=A0

Andy

=C2=A0

=C2=A0

--0000000000001e666f05c81ecd56-- From nobody Tue Jul 27 14:10:25 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA2D3A0736; Tue, 27 Jul 2021 14:10:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <162742021977.10305.514348907622278479@ietfa.amsl.com> Date: Tue, 27 Jul 2021 14:10:19 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-nmda-diff-11.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 21:10:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Comparison of NMDA datastores Authors : Alexander Clemm Yingzhen Qu Jeff Tantsura Andy Bierman Filename : draft-ietf-netmod-nmda-diff-11.txt Pages : 19 Date : 2021-07-27 Abstract: This document defines an RPC operation to compare management datastores that comply with the NMDA architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-nmda-diff/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-nmda-diff-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-nmda-diff-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 28 07:11:54 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA11A3A11EC for ; Wed, 28 Jul 2021 07:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22kbpRNSM7vr for ; Wed, 28 Jul 2021 07:11:48 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2103.outbound.protection.outlook.com [40.107.243.103]) (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 3EC213A11F2 for ; Wed, 28 Jul 2021 07:11:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RhJV1JkfRMmEfUwcDFJVlC07dWSce1JDOUXvR+Ud76oaZ7g0TV6jnKRQc8OYdPwxknhaJUURbaFv3x23yjEer1kxmmKnoz/0jnfk3MLpkA9Kwce/gEsgmCGeOQQy9SlZYIqW6ABagJpFEPee3tz1raOqzwZdKudTPUkU4AiJfM4xUhQJjXuw3pRH2C2fvFO5V+z4vjofhKePwSUP7AsGAE3gbE81lWNLtcmnF7W6mmqF4CyY4EJs4Y61qCersHgKi/0ZRxAudw4O1nzJvHtU5153YtpyKS7El/R93TMT1/LEIi8HZZxWTHh0n7KzWrPBb2j76bOgP6IbURfKptlQ1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lrGso1AB+FU5nthfSLQ81Gu3dP9eZIriaQwNMQQxhSM=; b=SmW9uWEECqsABRkS9pz/UOrcaNYmeodYRGx0/JbpZEyQuwM631gh7mC3hjRnRJpTqjsvgMBw8Q5THz4mFN/+XrvDVgfZalzQ0Zileyle+2x4MnIJ2VPDUaqwcsNmhyD/EhQxV5De33Z0JHxvFrM3HMiwbp/FSv7M1W8Gkh8DJCmZCrzlrKGnzx/n/i3V/+zvwUyWkvyqpMRwxe3v2D4uYJKw8GOxLd7MjkbQdwJrSVo3PX19waUxF6zcIMezZ5Gqx6uMUgmaZ6Ty+ghMy+/HhdN9ehcGN1i9LaOK7U3C6cnSYeaenuVELrsF9HBTpLnqQqA5dkyn4HykvQBLrD0rYg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lrGso1AB+FU5nthfSLQ81Gu3dP9eZIriaQwNMQQxhSM=; b=orbDg2wCA2z1UCp44HFt3P4s4/l74EXZrL/Qvdjd4ZIOlU1Rxuvoz7nJIcFo+UAb6d9FojEveLcKWzUr+dHWB+lvWlh77av7gqKcGIw2IIrkVGZjMDBWTtXaN2EaXXlSjwio5v1u0l/yi6spVBS6Mt/XN061fb02nMQpvjXsJ9w= Received: from DM6PR08MB5084.namprd08.prod.outlook.com (2603:10b6:5:41::29) by DM6PR08MB5547.namprd08.prod.outlook.com (2603:10b6:5:109::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.29; Wed, 28 Jul 2021 14:11:46 +0000 Received: from DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::1c4f:c615:7111:f171]) by DM6PR08MB5084.namprd08.prod.outlook.com ([fe80::1c4f:c615:7111:f171%5]) with mapi id 15.20.4352.033; Wed, 28 Jul 2021 14:11:46 +0000 From: "Sterne, Jason (Nokia - CA/Ottawa)" To: "netmod@ietf.org" Thread-Topic: YANG Versioning Weekly Call Minutes - 2021-07-27 Thread-Index: AdeDue+MCgxlPfcVRNmxrDfgO3cC/Q== Date: Wed, 28 Jul 2021 14:11:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d203d969-ce22-4403-aaa0-08d951d1a25a x-ms-traffictypediagnostic: DM6PR08MB5547: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 895N9AuUb3ITF+5pkxTRObkyMgvfeVo+NU0uG0zA9/tego0MQdi5v3mUVl1/3+u2R7aKKOA7hl4m6QsI9IjJ73jUfgITGdgBY6Dma47Y+BVTHSMD7TW18bNSt0Fuib5jk8Jxadoux2V1JHoTZcgwUpkQmQieNGr12z4tD0vpDj8xjDzCpzWNQDCbX9CJyogbSkHG97c+HELFHI3qT3a+PoSSSdwQVXijjw4ZzR3z7+li200mdLRy+7O/ThTmb0ugEGY0xCyjycdbZ4QjSchcduD8Nqyqc/fJe3s2YwBJExce+LzKPAE12snDcHpwJBtHw2x2jrpOYgd/dAWUcjxUt9ZPAYGd5tXixTfpZQ93gkWUpF2aG0qeQ+vqFsMCncIY2zjZ62RItKhVMdf61nGZFJC0PSVD9FliYDK62COxkaEm4D0b35NUcUAFYnkGFlZVqN3r+g6yEJliXbTfdqWaDaRYxHDkPHhhHdPOC+f58AOpvMEHprwdt2O2JTX1uWgsIPPHsvzzu/IN5xrm+xkHvzReo20yoM+pjAsX1Xd5N0P1SXU44DC4YMq3N8fOqxaI2PiqGelTGdFnoNSnhWZ8SO/ix8HnEFm7AC0aevZ1aqUlhaaYLtT8AZJs0Rmg2IQneVqj+7EvAds7EaYBqMooOTfgwN9cVW4VBVrb+3k4zD2bitO7ubjWiVGn5yWmqnkzO2XRhuAMDtQrcY2K2kcCkY4uedcSbe1cGGURKm82WKxy4tx1IC4pHRmkbc5aU0FFott982A+PpjnIzUnHYbJNkxjSCZCixUc9Az5KmcRT6c6xnx5IxgtoLjjIAi0XtiQ x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR08MB5084.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(346002)(396003)(39850400004)(376002)(83380400001)(86362001)(52536014)(6916009)(6506007)(38070700005)(9686003)(966005)(2906002)(8676002)(16799955002)(478600001)(33656002)(26005)(66556008)(186003)(8936002)(7696005)(5660300002)(122000001)(66446008)(76116006)(71200400001)(66476007)(316002)(38100700002)(64756008)(55016002)(66946007)(357404004); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?DQO1dAQ3Bc6WDx6B7LKiy7EX/7aQeSoyV5shMRnT2UnLwZD5jvZRSFeyN2eI?= =?us-ascii?Q?hP2IaYrGOlkObJXvU8myVJ6bMsp8O596QXRInm1Zab+lab6Ghl6iStrAsgrv?= =?us-ascii?Q?+nECQPMxKL9awW9a/AactUkCefn80JijS3O19pCeZpigX0xiOIk1LcWLIA9Z?= =?us-ascii?Q?e47MkBJFQEPcyW30KaUFLvs/as2WA3diTN9WPC2qw/D83XW0Li21VgP3JygS?= =?us-ascii?Q?Xics0MASxsEyCL9ryPRybUghtr8Z9Tlkp6uIhrUg7qEYkeTB8w9hlq2u7UvL?= =?us-ascii?Q?Pin8L2RhA+rkUhPStcWKuRjzU9dF04PcO7G5yaZnJWMJYvJp9kX9eKfKlMtR?= =?us-ascii?Q?v9cC66hjvvglFTIXw2MnYSAnMNw7BcrupGo9rRes5YWP7mrVuUwOfN0onFaj?= =?us-ascii?Q?lj0Qqex33SY9sM9Qg3PHUbg40MpUx3+dpDmy3ogDAGCPyiAqCMXPt9m13DHX?= =?us-ascii?Q?On5ANepAeKWQvmleqjp31dm8qZx630786nYRcw5MK1JYAFnbAg0h6NFAyv9f?= =?us-ascii?Q?gc8+jJmu9eOnVSDOm+8LDqlLBp/N1tBcyC/RMLhsI2wFjUlbCq37ZQRPf64J?= =?us-ascii?Q?Gp5tkCv2HIchIWaO9ePZNPsL3Tz4S+Da6qrUJQR9OjYGFesLmEPRkzEYH9+g?= =?us-ascii?Q?g4K+WbbxLM5S5gjFjvK+hlDam6LMRiVAeYN6Imt+G4lMb4f4PELOp293vxRm?= =?us-ascii?Q?bIkvzSzwRRG1S/cHyL+CN8yi5tXAFuHCYkY/xLU8o2lbhRHuZ19dzwoSNay6?= =?us-ascii?Q?u1sTknNuoI5AApXySM/EJItXRP8MlJRxI98m47RaV1R0aWPU65yq6YTrO4xT?= =?us-ascii?Q?Nw0ocubE8/GXh5a3/7HLKaPDVK9yAG4FmAHsYONb/G6eIWvd7evYOogQS7oW?= =?us-ascii?Q?99zrQslPasltYzkg41ewycxdQeDf3Sz7r+0IL4lqXKUYW2L/4GzIhwlt2mWb?= =?us-ascii?Q?QXA+yOFMEcshAa44QxUYtFl6DHLj60PfNi3N7n7xuWSrwr2EygjYaQEsWBja?= =?us-ascii?Q?dhZiecESBEf2Z7G/9ytYVvHAnGaRNGNOLEY7D9x4J+G7IcDS/SnSVlC2Efgp?= =?us-ascii?Q?yU8OU3dHuE+fSDmzxJLT9CpplRZrzMQoMw3qsVzzzxHwd33D3OOoa+aHRRzZ?= =?us-ascii?Q?MhmBKJ2ollw6LJZSp7bEOJ2Ho/MeJR9ILLbzG6th+T2CrtzGPW7gBOxjcX46?= =?us-ascii?Q?TTLOhri6nwc/yE0gb/a+YqblsWaS+CFoKCHV+W3BoQc2scLQQ5dZrfr8BtNo?= =?us-ascii?Q?ZnbigWRxskXBYQ0wuEkOBhF4Wz7F37LdTE0VfuoRQx6Hjb0WrTHFIkQ0aIjP?= =?us-ascii?Q?3rIGi2gDYeNIC653EPc47eF/?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR08MB508454036658DAB81C9056899BEA9DM6PR08MB5084namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR08MB5084.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d203d969-ce22-4403-aaa0-08d951d1a25a X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2021 14:11:46.1922 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: EXXxCue/hKflAvgA/uVOchVwzAPWXTGWRLtEV2k3iGxhTZBaEZKXrgJvcNoc1hQm+IFtmR1sJIpbyCBECFznPA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB5547 Archived-At: Subject: [netmod] YANG Versioning Weekly Call Minutes - 2021-07-27 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 14:11:53 -0000 --_000_DM6PR08MB508454036658DAB81C9056899BEA9DM6PR08MB5084namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YANG Versioning Weekly Call Minutes - 2021-07-27 We reviewed and updated the IETF111 slides - moved discussion of the main open issue (YANG 1.1 vs 1.2 vs 2.0) to the e= nd - added summary slides of 1st two drafts Reconfirmed reasons why we propose these drafts as part of YANG 1.1: - no real harm for anyone who doesn't use them (or tools that don't supp= ort them) - imports today are ambiguous - file names are optional (can be mitigated, minor effort= to update tooling for this) - adds value for something happening today (vendors are already doing pr= oprietary work arounds,IETF models have had some NBC changes) - NBC changes in IETF models: IANA (AFI/SAFIs removed). L3SM. Other ca= ses are likely coming up as more YANG RFCs get published - IEEE dot1q may have some NBC changes they want to do Next steps: - drive issues to closure on 1st two drafts (+ text for removing history) - author top down reviews (should occur before formal WG LC) ---------------------------------------------- Weekly webex call details: Meeting number (access code): 171 069 0374 Meeting password: semver? Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, Au= gust 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Cana= da) 9:00 am | (UTC-04:00) Eastern Time (US & Canada) | 1 hr https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7b770537cff5f5b89293c70 Tap to join from a mobile device (attendees only) +1-650-479-3208,,1710690374## Call-in toll number (US/Canada) --_000_DM6PR08MB508454036658DAB81C9056899BEA9DM6PR08MB5084namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

YANG Versioning Weekly Call Minutes - 2021-07-27

 

We reviewed and updated the IETF111 slides

- moved discussion of the main open issue (YANG 1.1 = vs 1.2 vs 2.0) to the end

- added summary slides of 1st two drafts<= /p>

 

Reconfirmed reasons why we propose these drafts as p= art of YANG 1.1:

   - no real harm for anyone who doesn't u= se them (or tools that don't support them)

       - imports today= are ambiguous

        &nbs= p;         - file names are optional (ca= n be mitigated, minor effort to update tooling for this)

   - adds value for something happening to= day (vendors are already doing proprietary work arounds,IETF models have ha= d some NBC changes)

   - NBC changes in IETF models: IANA (AFI= /SAFIs removed).  L3SM.  Other cases are likely coming up as more= YANG RFCs get published

   - IEEE dot1q may have some NBC changes = they want to do

 

Next steps:

- drive issues to closure on 1st two drafts (+ text = for removing history)

- author top down reviews (should occur before forma= l WG LC)

 

----------------------------------------------<= /o:p>

Weekly webex call details:

Meeting number (access code): 171 069 0374

Meeting password: semver?

Occurs every Tuesday effective Tuesday, September 1,= 2020 until Tuesday, August 24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) = Eastern Time (US & Canada)

9:00 am  |  (UTC-04:00) Eastern Time (US &= amp; Canada)  |  1 hr

https://ietf.webex.com/ietf/j.php?MTID=3Dma7627a2ae7= b770537cff5f5b89293c70

Tap to join from a mobile device (attendees only)

+1-650-479-3208,,1710690374## Call-in toll number (U= S/Canada)

--_000_DM6PR08MB508454036658DAB81C9056899BEA9DM6PR08MB5084namp_-- From nobody Wed Jul 28 09:47:14 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BA13A189C; Wed, 28 Jul 2021 09:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 yOh5en3ZdDag; Wed, 28 Jul 2021 09:46:58 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7B34F3A187D; Wed, 28 Jul 2021 09:46:41 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 16SGkWlw011177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Jul 2021 12:46:37 -0400 Date: Wed, 28 Jul 2021 09:46:32 -0700 From: Benjamin Kaduk To: Christian Hopps Cc: The IESG , draft-ietf-netmod-geo-location@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, kent+ietf@watsen.net Message-ID: <20210728164632.GM3932@kduck.mit.edu> References: <162146723152.27764.1299479086437558158@ietfa.amsl.com> <20210717173321.GE74365@kduck.mit.edu> <20210717221418.GF74365@kduck.mit.edu> <20210717232456.GH74365@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [netmod] Benjamin Kaduk's Discuss on draft-ietf-netmod-geo-location-08: (with DISCUSS and COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 16:47:09 -0000 On Mon, Jul 19, 2021 at 12:12:09PM -0400, Christian Hopps wrote: > > > > On Jul 17, 2021, at 7:24 PM, Benjamin Kaduk wrote: > > > > On Sat, Jul 17, 2021 at 07:17:09PM -0400, Christian Hopps wrote: > >> > >> > >>> On Jul 17, 2021, at 6:14 PM, Benjamin Kaduk wrote: > >>> > >>> So, when we refine the coord-accuracy and height-accuracy for an > >>> instantiation of the grouping, what does that mean? > >> > >> It’s supposed to mean the accuracy of the measurement that is recorded in the grouping. So if the coord-accuracy is .1 and the measurement is lat/long then the accuracy is within 1/10 of a decimal degree. if the measurement is in cart coordinates the accuracy would be 100cm. I don’t think we need to make this anymore complex than that. Is there some text you would like to see to make that clearer? > > > > The accuracy of the measurement with respect to what? The coordinate > > system, or the actual physical object? > > I really don’t see how this could be so confusing. > > This grouping is a location, the accuracy applies to the contained location data. Consider asking this question about some other field like the lat/long — it doesn’t make sense. It's confusing because there's a type mismatch between what the actual words on the page say and what you're describing in the email thread. > I can’t say for sure, but I think you’ve discarded the obvious here and are getting pedantic about something that’s not actually confusing. > > Finally, as we (the IETF) are not geo location experts, we had this grouping reviewed by actual industry experts (thanked in the acknowledgment section) and they had no issue with these fields. I would be very hesitant to change what they reviewed as correct at this point based on pedantic musings. I'm confident that the actual fields in the model can provide the needed information. We just need to clearly describe what information they are conveying. So, if we look at the OLD: leaf geodetic-datum { type string { pattern '[ -@\[-\^_-~]*'; } description "A geodetic-datum defining the meaning of latitude, longitude and height. The default when the astronomical body is 'earth' is 'wgs-84' which is used by the Global Positioning System (GPS). The ASCII value SHOULD have upper case converted to lower case and not include control characters (i.e., values 32..64, and 91..126). The IANA registry further restricts the value by converting all spaces (' ') to dashes ('-')"; [...] leaf coord-accuracy { type decimal64 { fraction-digits 6; } description "The accuracy of the latitude longitude pair for ellipsoidal coordinates, or the X, Y and Z components for Cartesian coordinates. When coord-accuracy is specified, it overrides the geodetic-datum implied accuracy."; } this is indicating that the geodetic datum has some intrinsic default for accuracy of latitude/longitude (not quoted, there is also some default for height accuracy intrinsic to the geodetic datum). If I were holding the pen, I might consider things like the following NEW1: leaf geodetic-datum { type string { pattern '[ -@\[-\^_-~]*'; } description "A geodetic-datum defining the meaning of latitude, longitude and height. The default when the astronomical body is 'earth' is 'wgs-84' which is used by the Global Positioning System (GPS). The ASCII value SHOULD have upper case converted to lower case and not include control characters (i.e., values 32..64, and 91..126). The IANA registry further restricts the value by converting all spaces (' ') to dashes ('-')"; The specification for the geodetic-datum indicates how accurately it models the astronomical body in question, both for the "horizontal" latitude/longitude coordinates and for height coordinates, typically as a maximum deviation across the entire astronomical object. NEW2: leaf coord-accuracy { type decimal64 { fraction-digits 6; } description "The accuracy of the latitude longitude pair for ellipsoidal coordinates, or the X, Y and Z components for Cartesian coordinates. When coord-accuracy is specified, it overrides the geodetic-datum implied accuracy. This might be used, for example, when the particular coordinates in the sibling list of locations are all located in a region of the astronomical object where the model used by the geodetic-datum is a particularly good representation of the actual astronomical object"; } NEW3: leaf coord-accuracy { type decimal64 { fraction-digits 6; } description "The accuracy of the latitude longitude pair for ellipsoidal coordinates, or the X, Y and Z components for Cartesian coordinates. When coord-accuracy is specified, it indiates how precisely the coordinates in the associated list of locations have been determined with respect to the coordinate system defined by the geodetic-datum. For example, this might be uncertainty due to measurement error if an experimental measurement was made to determine each location."; } In particular, what the actual words on the page are currently telling me is what I think NEW2 says -- to "override" (or "refine") a given value inherently must be of the same type as that value. What you've told me in this email thread is more like NEW3, and if the NEW3 sense is intended, then we shouldn't use the word "override". -Ben From nobody Wed Jul 28 10:09:11 2021 Return-Path: <0100017aee17493f-6b9b747c-f0f1-4a70-b929-aaa0350a555f-000000@amazonses.watsen.net> X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FDF3A1899 for ; Wed, 28 Jul 2021 10:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.894 X-Spam-Level: X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FY1_MOkpZu3 for ; Wed, 28 Jul 2021 10:09:03 -0700 (PDT) Received: from a48-92.smtp-out.amazonses.com (a48-92.smtp-out.amazonses.com [54.240.48.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A8723A1897 for ; Wed, 28 Jul 2021 10:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1627492142; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id:Feedback-ID; bh=b56hOBSRSttoM7HuBnm3h1+lg5z6m6o3DHBLuzlfphU=; b=H8FIV3biiu2sON9QLb+aIU9aBEdVDafbxZ/+WhsUvjs8FOB6dZEC7QvJdo94UcQK EhTdPv22uFI/wwAb/q71D0peLY6wlRxPNhA2Bp64bbxnk6Tan6HTRPYrxj56KZLMXju cHcX6tKUllJJip4wBgz0iL20ZuknMnuIQL38IVCY= From: Kent Watsen Content-Type: multipart/alternative; boundary="Apple-Mail=_D4B9C52C-4F05-493C-8854-9B3019338292" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Wed, 28 Jul 2021 17:09:01 +0000 References: <5b76dae2175545959f0006b036efd647@huawei.com> <2d1262bc90fc49d08eb641365b959ea4@huawei.com> <0100017aab854793-eb989e55-8496-451b-84de-7f17cb0720d5-000000@email.amazonses.com> To: "netmod@ietf.org" In-Reply-To: Message-ID: <0100017aee17493f-6b9b747c-f0f1-4a70-b929-aaa0350a555f-000000@email.amazonses.com> X-Mailer: Apple Mail (2.3654.100.0.2.22) Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES X-SES-Outgoing: 2021.07.28-54.240.48.92 Archived-At: Subject: Re: [netmod] system configuration sync mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 17:09:09 -0000 --Apple-Mail=_D4B9C52C-4F05-493C-8854-9B3019338292 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 WG, Regarding yesterday=E2=80=99s datastore presentation, there = seemed to be support for "Option #2=E2=80=9D, which is to have = merge into . It was noted that this then would mean that client-validation of = would necessitate understanding how the merge works, to expand = templates, resolve leafrefs, etc. My thoughts are, so? =20 Firstly, a client that doesn=E2=80=99t understand that there may be some = defined configuration will, for the most part, be none the = wiser. The client *will* discover configuration in = , but this is already the case today. One new thing is = that should use =E2=80=9Corigin:system=E2=80=9D for = configuration originating from the datastore. This last point = might surprise clients=E2=80=A6as the definition of =E2=80=9Cwith-origin=E2= =80=9D doesn=E2=80=99t state that clients must ignore any unrecognized = =E2=80=9Corigin=E2=80=9D identities: = https://datatracker.ietf.org/doc/html/rfc8527#section-3.2.2. Secondly, no shared object defined in will be activated until = client-supplied config references it. But any client able to do this = already knows how merges into and is accounting for = it. Thoughts? Kent > On Jul 16, 2021, at 6:24 AM, maqiufang (A) = wrote: >=20 > Hi, Kent, > Please see my reply inline. > =20 > From: Kent Watsen [mailto:kent+ietf@watsen.net]=20 > Sent: Friday, July 16, 2021 2:55 AM > To: maqiufang (A) > Cc: netmod@ietf.org > Subject: Re: [netmod] system configuration sync mechanism > =20 > Hi Qiufang, > =20 > [snip] > The question is if the server implementation prunes dangling/unused = objects when is applied, updating . My = assumption is that the server will discard any object that doesn=E2=80=99t= actually impact the running configuration of the system (i.e., values = are consumed by the underlying operating system, drivers, etc.). = Thusly, it is my opinion that only the referenced objects are applied. = Hence why, to answer your last question, I wrote that these = configurations (manufacturer-defined objects) are not applied = immediately but only after they are referenced. Makes sense? > [Qiufang Ma] Yes, try to sum up our discussion about the categories of = the system configuration: > =C2=B7 Physical-resource-dependent--> whether this sort of = system configuration exists in dependents on if the physical = resource is present(e.g., physical interface). > =C2=B7 Physical-resource-independent-->which is provided by = the device system > o Further classification from the perspective of =E2=80=9Capplied=E2=80= =9D time(dependents on whether the system configuration impacts the = running of the system) > =C2=A7 Config that is applied immediately(e.g., the loopback, the = predefined minimum length of password=E2=80=A6) > =C2=A7 Config that is applied only after being referenced by other = configs(e.g, definitions for applications ftp/tftp=E2=80=A6) > o Further classification from the perspective of generation time > =C2=A7 Config that is generated unconditionally at each boot = time(e.g, loopback, predefined minimum length of password, ftp/tftp=E2=80=A6= ) > =C2=A7 Config that is generated conditionally during the device = running(e.g., system-generated local-port and remote-port for a new = established BGP connection) > =20 > Keep in mind that what is described above is just one aspect of what = can be in . In addition to defining reference-able objects, = can also define/apply configuration immediately (e.g., the = loopback interface). That is, configuration not does not have to be = referenced in order to become activated. > [Qiufang Ma] Noted. > =20 > =20 > =20 > Note that, by itself would not pass validation, due to = missing leafrefs. Thankfully, NMDA never says that validation runs on = . But once and have been merged, to become = , the result does pass validation. > [Qiufang Ma] The referenced instance must also exist for the data to = be valid since the require-instance defaults to true if not present. Is = this what you had in your mind? Yes, NMDA says that it is = which is subject to validation. But I also notice that In section 5.1.3 = of the NMDA:=E2=80=9D MUST always be a valid configuration data = tree, as defined in Section 8.1 of [RFC7950]. =E2=80=9D So my thought = here is that should also conform to the YANG model constraints = and that=E2=80=99s to say, a referenced system-defined data item should = also exists in . > Therefore, if system configurations do not exist in , they = still need to be configured in manually in order for being = referenced. In this case, the original purpose of predefining some = system configurations for user convenience is lost. This is the reason = why we would like to define some mechanism here to synchronize = into .=20 > =20 > =20 > I see in RFC 8342 " MUST always be a valid configuration data = tree, as defined in Section 8.1 of [RFC7950]=E2=80=9D. > =20 > But the question remains if it is possible for the system is able to = validate without, e.g., expanding templates. There may be a = 'leafref' or =E2=80=98must=E2=80=99 expression somewhere that will fail = because the evaluation occurs without expanding a template that supplies = the missing parts. > [Qiufang Ma] On condition that should be valid, the = operators will need to retrieve from the or to = get the template-expanded configurations and then create them in the = , right? =20 > My feeling is that it loses the meaning of predefining and seems no = differences between operator-defined configurations if operators have to = create system configures in before they use them. So I am = beginning to think, if it=E2=80=99s possible to expand the = system-defined template during the copying between and = ? > =20 > If this draft =E2=80=9Cupdates=E2=80=9D RFC 8342 (NMDA), then it can = supply a clarifying statement about what it means that " MUST = always be a valid configuration data tree=E2=80=9D. Either that, or an = Errata if it=E2=80=99s determined that the statement isn=E2=80=99t = correct. > =20 > You make a good technical point, but I think that we should *want* to = avoid having to copy (or ) configuration into = if we can avoid it. Agreed? > [Qiufang Ma] tend to agree. Maybe we should try to avoid it, unless we = have to. > =20 > FWIW, also in RFC 8342, Section 5.1.4.: > =20 > is tightly coupled to . Whenever data is = written > to , the server MUST also immediately update and validate > . > =20 > MAY also be updated independently of if the > effect of a configuration transformation changes, but = MUST > always be a valid configuration data tree, as defined in = Section=C2=A08.1 = > =C2=A0=C2=A0 of [RFC7950] = . > =20 > =20 >=20 >=20 > =20 > > I am wondering if these configuration will present in the = (which contains all the configuration actually used by the = device) before they=E2=80=99re referenced. > =20 > I think that it would depend in the specific server=E2=80=99s = behavior, regarding if *unused* predefine objects are present in = . Certainly the unused objects would not have to be = present in . If I were implementing the server, the unused = objects would NOT be present in . > [Qiufang Ma] Yes, if the predefined system configurations is unused, = then I also tend to agree that they would not be present in = but may also depend on the vendor implementation. > =20 > =20 > Yup, this is the same conclusion is in my response above. > [Qiufang Ma] :) > =20 >=20 >=20 > > It would be good if we could determine if there are any other = "resource-independent=E2=80=9D configuration categories here. > > [Qiufang Ma] Do you think there exists conditional system = configuration (if the preceding configurations you mentioned above is = not)? For example, if SSH is enabled on a device, SSH-related keys are = automatically generated. Such configurations are generated at the moment = when a special functionality is enabled. > =20 > I=E2=80=99m unsure what you mean in general by "conditional = configuration=E2=80=9D, but I can speak to your specific example. Though = I must preface my comments that I imagine there are a number of ways = servers might go about enabling `sshd`. What follows is my personal = view, forged by being around systems for awhile ;) > =20 > In general: > =20 > - `sshd` is NOT enabled by default. > - `sshd` is enabled via a configuration knob. > - the SSH host key is dynamically generated the first time = `sshd` is enabled. > - the SSH host key itself is in (not ) > =20 > This view is consistent with the first paragraph in Section 3 of the = =E2=80=9Ckeystore=E2=80=9D draft (reproduced below): > =20 > 3. Support for Built-in Keys > =20 > In some implementations, a server may support built-in = keys. Built- > in keys MAY be set during the manufacturing process or be = dynamically > generated the first time the server is booted or a = particular service > (e.g., SSH) is enabled. > =20 > As a closing thought, this model (which I stated upfront may not be = universal) would have no presence-in or interaction-with = =E2=80=A6though, perhaps, there may be some predefined values = for what key-algorithms and/or key-lengths to use when generating the = SSH host key... > [Qiufang Ma] By =E2=80=9Cconditional system configuration=E2=80=9D, I = was meaning some of the system configurations are not generated = immediately after the device is powered on. Instead, they are generated = when a specific condition is satisfied during the device running(e.g., a = functionality is enabled due to some client configurations). I am not = sure if it really exists, maybe not, just try to explore the = possibilities of various resource-independent system configurations.:)=20= > =20 > To this point I agree..as does RFC 8342 (NMDA), Section 5.3.3.: > =20 > Sometimes, resources are controlled by the device and the > corresponding system-controlled data appears in (and disappears = from) > dynamically. If a system-controlled resource has > matching configuration in when it appears, the system = will > try to apply the configuration; this causes the configuration to > appear in eventually (if application of the > configuration was successful). > [Qiufang Ma] See above, as I summarized as the system configurations = that is generated conditionally during the device running. > =20 > Firstly, I again have to preface my comment that there are likely many = ways that templating mechanisms can be defined. But, in general, once = a templating mechanism has been defined, then it stands to reason that = templates could be defined either in (by operators) or in = (by the manufacturer). In one implementation I=E2=80=99m = familiar with, the templates are objects that are = referenced/parameterized by other parts of the configuration. (Same as = with the predefined objects discussion above.) =20 > =20 > To answer your questions: > =20 > 1) Yes, it is my opinion that *activated* templates in will = be expanded and present in . > =20 > 2) I would never suggest that the system-defined templates are present = in , though they may be referenced/parameterized by config in = . > =20 > 3) if a config-template is configured in (i.e., it is = operator-defined) then, yes, the expanded configuration in is = "client configuration=E2=80=9D (note, "client configuration=E2=80=9D is = not a formal term). That said, it seems fair to say that a template = defined in and then referenced by "client configuration=E2=80=9D = in is also expanded as "client configuration=E2=80=9D in = . > =20 > 4) I don=E2=80=99t not understand your last sentence, that the = expansion of templates are only present in . = Maybe you=E2=80=99re saying something subtle, e.g., that servers = currently don=E2=80=99t support GET on . But, in theory, the = expansion of templates should (IMO) be present in , = so that they may be subject to validation. Of course, all the = configuration (whether originating in or ) = that is successfully =E2=80=9Capplied=E2=80=9D will also be present in = . > [Qiufang Ma] Assume that there is no and this work, the = expansion of system templates are only present in . Because = this is compatible with system configuration definition in NMDA. > But if system configurations are only present in , the = predefined system configurations still need to be retrieved and created = into explicitly when being referenced. I think we=E2=80=99ve = reached an agreement on the need for to exist, and our main = point of disagreement is whether should be copied into = . Your point is that being merged into is enough to = make sure a success validation. But my understanding is that the = referenced system configuration data item must also exist in the = to obey the model constraints. > =20 > Yes, I believe that you provided an accurate description of the = difference in our opinions. Per my earlier response, you make a valid = technical point, my goal is to waive that interpretation to the side so = that a simpler solution can emerge. It would be good to get other = opinions on list, otherwise we=E2=80=99ll take it into the meeting. > [Qiufang Ma] OK. Hopefully someone else would share some opinions = here. Otherwise let=E2=80=99s take this into the IETF meeting. > =20 > [BTW, in keeping with this thread moving from the NETCONF to the = NETMOD mailing lists, would it make sense to move the IETF 111 = presentation slot from NETCONF to NETMOD too? I think it does and, = further, it would help with scheduling (NETCONF is over, NETMOD is = under). Would you be okay with this? AD Rob and the NETCONF chairs = discussed this morning, and think it's okay, but would still need to = confirm with the NETMOD chairs.] > [Qiufang Ma] I am happy with the proposal, if it=E2=80=99s also okay = for NETMOD chairs:-). I have sent an email to the NETMOD chairs to = request to move this presentation slot from NETCONF to NETMOD. > A new version of the draft will also be submitted to NETMOD when the = draft-submitting window reopens. >=20 >=20 > > > I=E2=80=99m beginning to think that: > > =C2=B7 auto-copying into is likely never a good = idea, because it violates the definition of > > [Qiufang Ma] I am quite aware that different datastores in NMDA = represents different views of data nodes. And represents a = configuration datastore holding the current configuration of the device. > > Should we consider system configuration also be part of current = configuration of the device? =46rom my perspective, the difference = between system configuration and client-configuration lies only in who = provides it. > =20 > holds the current *operator-specified* configuration of the = device. System-provided configuration is NOT specified by operators = (though system-defined objects may be referenced by operator-specified = config in ). I believe that this arrangement is consistent = with the definition of . Agreed? > [Qiufang Ma] Yes. Actually we are not trying to violate the principles = of NMDA and the definition of . The issue we try to resolve = here is that system configurations cannot be used(referenced or = overwritten) by the operators directly and need to be created into = explicitly. This actually loses the meaning of =E2=80=9Cpredefin= ing and bringing convenience=E2=80=9D. If auto-copying is not a good = idea, what do you think about defining an RPC operation for the = operators to do the copy(which is also what Rob suggests at the = meeting)? > =20 > If we have to copy into , then I think that I agree an RPC = (?) would be better. > [Qiufang Ma] =46rom my perspective, is feasible but not = efficient because operators still need to retrieve = / firstly. If we could define a RPC to copy the = entire into , it seems more convenient for operators. = However, some system configurations which are not going to be referenced = or modified may also be copied into . I don't have a strong = feeling about which one is preferred. Anyway, we need to figure out = whether it would be fine for to missing referenced system = configurations. > =20 > You mention =E2=80=9Coverwritten=E2=80=9D by the operators? Why = wouldn=E2=80=99t the operators just define their own? For instance, if = they don=E2=80=99t like the vendor=E2=80=99s =E2=80=9Cvendor-foobar=E2=80=9D= object, they could copy/paste/edit their own =E2=80=9Cmy-foobar=E2=80=9D = object with the values needed, yes? > [Qiufang Ma] Yes, defining their own would be okay. By overwriting, I = mean sometimes the operators would like to modify the specific system = configuration, e.g., the MTU value of a specified interface(identified = by its name). > If the operators want to modify the system configurations, there is no = way but redefine them in . > =20 > =20 > Best Regards, > Qiufang Ma > =20 >=20 >=20 > =20 > =20 > > =C2=B7 having in doesn=E2=80=99t make sense, = since the tweaks wouldn=E2=80=99t go thru --> = validation. > > =20 > > I=E2=80=99m wondering if a model like below would work for everyone = - thoughts? > > [Qiufang Ma] represents the configuration after all = configuration transformations to have been performed, so I = think it is only coupled to . > > Anyway, the should also interacts with . = Agreed? > =20 > I don=E2=80=99t agree that must only be coupled to = . Specifically, I think that it is okay (compatible with NMDA) = to define a that also impacts . This is the only = (IMO) sane approach, as it enables the combination + = to be validated. > [Qiufang Ma] Please see above. If is OK to miss referenced = system configuration, your proposal makes sense to me. > =20 > Ack. > =20 >=20 >=20 > Best Regards, > Qiufang Ma=20 > =20 > =20 > Kent // contributor --Apple-Mail=_D4B9C52C-4F05-493C-8854-9B3019338292 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
WG,

Regarding = yesterday=E2=80=99s <system> datastore presentation, there seemed = to be support for "Option #2=E2=80=9D, which is to have <system> = merge into <intended>.

It was noted that this then would mean that client-validation = of <running> would necessitate understanding how the merge works, = to expand templates, resolve leafrefs, etc.

My thoughts are, so? =   

Firstly, a client that doesn=E2=80=99t understand that there = may be some <system> defined configuration will, for the most = part, be none the wiser.   The client *will* discover = <system> configuration in <operational>, but this is already = the case today.  One new thing is that <operational> should = use =E2=80=9Corigin:system=E2=80=9D for configuration originating from = the <system> datastore.  This last point might surprise = clients=E2=80=A6as the definition of =E2=80=9Cwith-origin=E2=80=9D = doesn=E2=80=99t state that clients must ignore any unrecognized = =E2=80=9Corigin=E2=80=9D identities: https://datatracker.ietf.org/doc/html/rfc8527#section-3.2.2= .

Secondly, no = shared object defined in <system> will be activated until = client-supplied config references it.  But any client able to do = this already knows how <system> merges into <intended> and = is accounting for it.

Thoughts?

Kent


On Jul 16, 2021, at 6:24 AM, maqiufang (A) = <maqiufang1@huawei.com> wrote:

Hi, Kent,

Please see my reply inline.

 

From: Kent Watsen [mailto:kent+ietf@watsen.net]
Sent: Friday, July 16, 2021 2:55 AM
To: maqiufang (A) <maqiufang1@huawei.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] system configuration sync = mechanism

 

Hi Qiufang,

 

          &nb= sp; [snip]

The = question is if the server implementation prunes dangling/unused objects = when <intended> is applied, updating <operational>.  My = assumption is that the server will discard any object that doesn=E2=80=99t= actually impact the running configuration of the system (i.e., values are consumed by = the underlying operating system, drivers, etc.).  Thusly, it is my = opinion that only the referenced objects are applied.  Hence why, = to answer your last question, I wrote that these configurations (manufacturer-defined objects) are not applied immediately but only = after they are referenced.  Makes sense?

[Qiufang Ma] Yes, try to sum up our discussion = about the categories of the system configuration:

=C2=B7         Physical-resource-dependent--> whether this sort = of system configuration exists in <system> dependents on if the = physical resource is present(e.g., physical interface).

=C2=B7         Physical-resource-independent-->which is = provided by the device system

o   Further classification from the perspective of = =E2=80=9Capplied=E2=80=9D time(dependents on whether the system = configuration impacts the running of the system)

=C2=A7  Config that is applied immediately(e.g., the = loopback, the predefined minimum length of = password=E2=80=A6)

=C2=A7  Config that is applied only after being referenced = by other configs(e.g, definitions for applications = ftp/tftp=E2=80=A6)

o   Further classification from the perspective of = generation time

=C2=A7  Config that is generated unconditionally at each = boot time(e.g, loopback, predefined minimum length of password, = ftp/tftp=E2=80=A6)

=C2=A7  Config that is generated conditionally during the = device running(e.g., system-generated local-port and remote-port for a = new established BGP connection)

 

Keep = in mind that what is described above is just one aspect of what can be = in <system>.  In addition to defining reference-able objects, = <system> can also define/apply configuration immediately (e.g., = the loopback interface).  That is, configuration not does not have to be = referenced in order to become activated.

[Qiufang Ma] Noted.

 

 

 
Note that, <running> by itself would not pass =
validation, due to missing leafrefs.  Thankfully, NMDA never says =
that validation runs on <running>.  But once <running> =
and <system> have been merged, to become <intended>, the =
result does pass validation.
 [Qiufang Ma] The referenced instance must also exist for the =
data to be valid since the require-instance defaults to true if not =
present. Is this what you had in your mind? Yes, NMDA says that it is =
<intended> which is subject to validation. But I also notice that =
In section 5.1.3 of the NMDA:=E2=80=9D<running> MUST always be a =
valid configuration data tree, as defined  in Section 8.1 of =
[RFC7950]. =E2=80=9D So my thought here is that <running> should =
also conform to the YANG model constraints and that=E2=80=99s to say, a =
referenced system-defined data item should also exists in =
<running>.
Therefore, if system configurations do not exist in =
<running>, they still need to be  configured in =
<running> manually in order for being referenced. In this case, =
the original purpose of predefining some system configurations for user =
convenience is lost. This is the reason why we would like to define some =
mechanism here to synchronize <system> into <running>. =

 

 

I = see in RFC 8342 "<running> MUST always be a valid configuration = data tree, as defined in Section 8.1 of [RFC7950]=E2=80=9D.

 

But = the question remains if it is possible for the system is able to = validate <running> without, e.g., expanding templates.  There = may be a 'leafref' or =E2=80=98must=E2=80=99 expression somewhere that = will fail because the evaluation occurs without expanding a template that supplies the missing = parts.

[Qiufang Ma] On condition that <running> = should be valid, the operators will need to retrieve from the = <intended> or <operational> to get the template-expanded configurations and then create them in the <running>, right? =  

My feeling is that it loses the meaning of = predefining and seems no differences between operator-defined = configurations if operators have to create system configures in <running> before they use them. So I am beginning = to think, if it=E2=80=99s possible to expand the system-defined template = during the copying between <system> and <running>?

 

If = this draft =E2=80=9Cupdates=E2=80=9D RFC 8342 (NMDA), then it can supply = a clarifying statement about what it means that "<running> MUST always be a valid = configuration data tree=E2=80=9D.  Either that, or an Errata if = it=E2=80=99s determined that the statement isn=E2=80=99t = correct.

 

You = make a good technical point, but I think that we should *want* to avoid = having to copy <system> (or <operational>) configuration = into <running> if we can avoid it.  Agreed?

[Qiufang Ma] tend to agree. Maybe we should try to = avoid it, unless we have to.

 

FWIW, = also in RFC 8342, Section 5.1.4.:

 

   <intended> is tightly coupled =
to <running>.  Whenever data is written
   to <running>, the server MUST also =
immediately update and validate
   <intended>.
 
   <intended> MAY also be updated =
independently of <running> if the
= 
   effect of a configuration transformation =
changes, but <intended> MUST
   always be a valid configuration data tree, as =
defined in Section 8.1
   of [RFC7950].

 

 



 
> I am wondering if these configuration will present in =
the <operational> (which contains all the configuration actually =
used by the device) before they=E2=80=99re referenced.
 
I =
think that it would depend in the specific server=E2=80=99s behavior, =
regarding if *unused* predefine objects are present in =
<operational>.  Certainly the unused objects would not have =
to be present in <operational>.  If I were implementing the =
server, the unused objects would NOT be present in =
<operational>.
[Qiufang Ma] Yes, if the predefined system configurations is =
unused, then I also tend to agree that they would not be present in =
<operational> but may also depend on the vendor =
implementation.

 

 

Yup, = this is the same conclusion is in my response above.

[Qiufang Ma] :)

 



> It would be good if we could determine if there are any =
other "resource-independent=E2=80=9D configuration categories =
here.
> [Qiufang Ma] Do you think there exists conditional =
system configuration (if the preceding configurations you mentioned =
above is not)? For example, if SSH is enabled on a device, SSH-related =
keys are automatically generated. Such configurations are generated at =
the moment when a special functionality is enabled.
 
I=E2=80=99m unsure what you mean in general by "conditional =
configuration=E2=80=9D, but I can speak to your specific example. Though =
I must preface my comments that I imagine there are a number of ways =
servers might go about enabling `sshd`.  What follows is my =
personal view, forged by being around systems for awhile  =
;)
 
In=
 general:
 
         - `sshd` is =
NOT enabled by default.
         - `sshd` is =
enabled via a configuration knob.
         - the SSH =
host key is dynamically generated the first time `sshd` is =
enabled.
         - the SSH =
host key itself is in <operational> (not =
<running>)
 
This view is consistent with the first paragraph in Section 3 =
of the =E2=80=9Ckeystore=E2=80=9D draft (reproduced below):
 
         3.  =
Support for Built-in Keys
 
            =
In some implementations, a server may support built-in keys.  =
Built-
            =
in keys MAY be set during the manufacturing process or be =
dynamically
            =
generated the first time the server is booted or a particular =
service
            =
(e.g., SSH) is enabled.
 
As=
 a closing thought, this model (which I stated upfront may not be =
universal) would have no presence-in or interaction-with =
<system>=E2=80=A6though, perhaps, there may be some predefined =
values for what key-algorithms and/or key-lengths to use when generating =
the SSH host key...
[Qiufang Ma] By =E2=80=9Cconditional system configuration=E2=80=
=9D, I was meaning some of the system configurations are not generated =
immediately after the device is powered on. Instead, they are generated =
when a specific condition is satisfied during the device running(e.g., a =
functionality is enabled due to some client configurations). I am not =
sure if it really exists, maybe not, just try to explore the =
possibilities of various resource-independent system configurations.:) =

 

To = this point I agree..as does RFC 8342 (NMDA), Section 5.3.3.:

 

   Sometimes, resources are controlled =
by the device and the
   corresponding system-controlled data appears in =
(and disappears from)
   <operational> dynamically.  If a =
system-controlled resource has
   matching configuration in <intended> when =
it appears, the system will
   try to apply the configuration; this causes the =
configuration to
   appear in <operational> eventually (if =
application of the
   configuration was successful).
[Qiufang Ma] See above, as I summarized as the =
system configurations that is generated conditionally during the device =
running.
 
Firstly, I again have to preface my comment that there are =
likely many ways that templating mechanisms can be =
defined.    But, in general, once a templating mechanism =
has been defined, then it stands to reason that templates could be =
defined either in <running> (by operators) or in <system> =
(by the manufacturer).  In one implementation I=E2=80=99m familiar =
with, the templates are objects that are referenced/parameterized by =
other parts of the configuration.  (Same as with the predefined =
objects discussion above.)  
 
To=
 answer your questions:
 
1)=
 Yes, it is my opinion that *activated* templates in <system> will =
be expanded and present in <intended>.
 
2)=
 I would never suggest that the system-defined templates are present in =
<running>, though they may be referenced/parameterized by config =
in <running>.
 
3)=
 if a config-template is configured in <running> (i.e., it is =
operator-defined) then, yes, the expanded configuration in =
<intended> is "client configuration=E2=80=9D (note, "client =
configuration=E2=80=9D is not a formal term).  That said, it seems =
fair to say that a template defined in <system> and then =
referenced by "client configuration=E2=80=9D in <running> is also =
expanded as "client configuration=E2=80=9D in =
<intended>.
 
4)=
 I don=E2=80=99t not understand your last sentence, that the expansion =
of <system> templates are only present in =
<operational>.  Maybe you=E2=80=99re saying something subtle, =
e.g., that servers currently don=E2=80=99t support GET on =
<intended>.  But, in theory, the expansion of <system> =
templates should (IMO) be present in <intended>, so that they may =
be subject to validation.   Of course, all the =
<intended> configuration (whether originating in <running> =
or <system>) that is successfully =E2=80=9Capplied=E2=80=9D will =
also be present in <operational>.
= 
[Qiufang Ma] Assume that there is no <system> and this =
work, the expansion of system templates are only present in =
<operational>. Because this is compatible with system =
configuration definition in NMDA.
But if system configurations are only present in =
<operational>, the predefined system configurations still need to =
be retrieved and created into <running> explicitly when being =
referenced. I think we=E2=80=99ve reached an agreement on the need for =
<system> to exist, and our main point of disagreement is whether =
<system> should be copied into <running>. Your point is that =
being merged into <intended> is enough to make sure a success =
validation. But my understanding is that the referenced system =
configuration data item must also exist in the <running> to obey =
the model constraints.

 

Yes, = I believe that you provided an accurate description of the difference in = our opinions.  Per my earlier response, you make a valid technical = point, my goal is to waive that interpretation to the side so that a simpler solution can emerge.  It would be good to get other = opinions on list, otherwise we=E2=80=99ll take it into the meeting.

[Qiufang Ma] OK.  Hopefully someone else would = share some opinions here. Otherwise let=E2=80=99s take this into the = IETF meeting.

 

[BTW, = in keeping with this thread moving from the NETCONF to the NETMOD = mailing lists, would it make sense to move the IETF 111 presentation = slot from NETCONF to NETMOD too?  I think it does and, further, it = would help with scheduling (NETCONF is over, NETMOD is under).  Would = you be okay with this?   AD Rob and the NETCONF chairs discussed = this morning, and think it's okay, but would still need to confirm with = the NETMOD chairs.]

[Qiufang Ma] I am happy with the proposal, if = it=E2=80=99s also okay for NETMOD chairs:-). I have sent an email to the = NETMOD chairs to request to move this presentation slot from NETCONF to NETMOD.

A new version of the draft will also be submitted = to NETMOD when the draft-submitting window reopens.



 <big snip>
> I=E2=80=99m beginning to think that:
> =C2=B7         =
auto-copying into <running> is likely never a good idea, because =
it violates the definition of <running>
> [Qiufang Ma] I am quite aware that different datastores =
in NMDA represents different views of data nodes.  And =
<running> represents a configuration datastore holding the current =
configuration of the device.
> Should we consider system configuration also be part of =
current configuration of the device? =46rom my perspective, the =
difference between system configuration and  client-configuration =
lies only in who provides it.
 
<running> holds the current *operator-specified* =
configuration of the device.  System-provided configuration is NOT =
specified by operators (though system-defined objects may be referenced =
by operator-specified config in <running>).   I believe =
that this arrangement is consistent with the definition of =
<running>.  Agreed?
[Qiufang Ma] Yes. Actually we are not trying to violate the =
principles of NMDA and the definition of <running>.  The =
issue we try to resolve here is that system configurations cannot be =
used(referenced or overwritten) by the operators directly and need to be =
created into <running> explicitly. This actually loses the meaning =
of =E2=80=9Cpredefining and bringing convenience=E2=80=9D. If =
auto-copying is not a good idea, what do you think about defining an RPC =
operation for the operators to do the copy(which is also what Rob =
suggests at the meeting)?

 

If = we have to copy into <running>, then I think that I agree an RPC = (<edit-config>?) would be better.

[Qiufang Ma] =46rom my perspective, = <edit-config> is feasible but not efficient because operators = still need to retrieve <system>/<operational> firstly. If we could define a RPC to copy the entire <system> into = <running>, it seems more convenient for operators. However, some = system configurations which are not going to be referenced or modified = may also be copied into <running>. I don't have a strong feeling about which one is preferred. Anyway, we need to figure out whether it = would be fine for <running> to missing referenced system = configurations.

 

You = mention =E2=80=9Coverwritten=E2=80=9D by the operators?  Why = wouldn=E2=80=99t the operators just define their own?  For = instance, if they don=E2=80=99t like the vendor=E2=80=99s = =E2=80=9Cvendor-foobar=E2=80=9D object, they could copy/paste/edit their = own =E2=80=9Cmy-foobar=E2=80=9D object with the values needed, yes?

[Qiufang Ma] Yes, defining their own would be okay. = By overwriting, I mean sometimes the operators would like to modify the = specific system configuration, e.g., the MTU value of a specified interface(identified by its = name).

If the operators want to modify the system = configurations, there is no way but redefine them in = <running>.

 

 

Best Regards,

Qiufang Ma

 



 
 
> =C2=B7         =
having in <operational> doesn=E2=80=99t make sense, since the =
tweaks wouldn=E2=80=99t go thru <running> --> <intended> =
validation.
>  
> I=E2=80=99m wondering if a model like below would work =
for everyone - thoughts?
> [Qiufang Ma] <intended> represents the =
configuration after all configuration transformations to <running> =
have been performed, so I think it is only coupled to =
<running>.
> Anyway, the <system> should also interacts with =
<operational>.  Agreed?
 
I =
don=E2=80=99t agree that <intended> must only be coupled to =
<running>.  Specifically, I think that it is okay (compatible =
with NMDA) to define a <system> that also impacts =
<intended>.   This is the only (IMO) sane approach, as =
it enables the combination <running> + <system> to be =
validated.
[Qiufang Ma] Please see above. If <running> is OK to =
miss referenced system configuration, your proposal makes sense to =
me.

 

Ack.

 



 Best Regards,
Qiufang Ma

 

 

Kent = // contributor


= --Apple-Mail=_D4B9C52C-4F05-493C-8854-9B3019338292-- From nobody Wed Jul 28 14:56:54 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5257F3A2309 for ; Wed, 28 Jul 2021 14:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn1Cf-6Rn-af for ; Wed, 28 Jul 2021 14:56:45 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2061.outbound.protection.outlook.com [40.107.21.61]) (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 5F9DA3A2303 for ; Wed, 28 Jul 2021 14:56:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VytC/UG61srSFiIH/0eYFKrHNhXimVcDlssz9Tj6CnWghqyqnPtqb+pmWLBWKUM1NFyBOG2K1VkYEKhnorp01BU+0sgvMTp5Fz3ohAL5nQtRBuuORBJF8gkPGjnqcVcfNnwKSbMeIOKRc7F1PvuaZtRcxoKGc0qO65XfjSCGR59nSDptAH5eBWOxewLbUyPmI0hphkn4tUGd1I5N7fCLbb6OsFxv0OtKsyqikjp2B9Jd61XhbPQXkK0zqq6gEqQb7S9pC8agGLl/EOZB/273slvgqXOVY6fTfcerCwX3QrM8ooc+eoipF5B981K/zSieV84/rqsuxzjNruS3GwRRJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mFkGYUM5prqytjzGneVqqO9YPIqTNHlXhy9Y/Vrgevg=; b=bIpxOtGDYWsAXyp+SORGlfIQKoWP6oxc7R/b0roPGCXj/Mf7NHkntjCVyppFGgcGkhS/QP+Cx0cKwO5in3Sl1/Vkgviw4UMlbjcWox5/aVYr0smJLfgr4jTPWV0vIlrOL07FZYD7d58Pe3PCl9XTTZLsbFtvPS6Uqnrlo0y07robNqtMcfIpJ/he7dwilBXrTOO7AwoqV449B5l3WklIfAdF1CxiRoKOgFAxlJTvA1c2cH8eNWitXernj0q3XE9HsZpYbn/4xvxWVGl8dxttqLUdUSIkZOX5Hhw6MQB/FCL4ylPbdif12E0yKZ+bT4EnzO1no/uwn8UyrwJHzyU4zg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mFkGYUM5prqytjzGneVqqO9YPIqTNHlXhy9Y/Vrgevg=; b=VOC/ncUHX8+xDZoChceR+rkkfxUNDreozHxstX9BdK40fMMGmomaNq6c8bbXeCFB7gxfKl3YhxT0mZuBzSzXqzt/IsPvRybrHb5d3G7pPglrpZXy206jHS9RF6l3wcBe24QKbuU9LQKu4c8fm0PODzkGNxmeGT/i6BkeFfstdaQ= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8171.eurprd07.prod.outlook.com (2603:10a6:20b:322::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.11; Wed, 28 Jul 2021 21:56:42 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4373.018; Wed, 28 Jul 2021 21:56:42 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Andy Bierman , "Rob Wilton (rwilton)" CC: NetMod WG Thread-Topic: [netmod] yang-instance-file include-defaults leaf Thread-Index: AQHXdB0ScDY6rhEwiUCIGrL2qSijE6s6kiOAgAHaXQCAGqYDAIAAFuiAgAHkeYA= Date: Wed, 28 Jul 2021 21:56:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: yumaworks.com; dkim=none (message not signed) header.d=none; yumaworks.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d7b0bbfa-47e5-4d21-41b7-08d952129582 x-ms-traffictypediagnostic: AM8PR07MB8171: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1775; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Pxn2rUsXkGJbadbmNng14HQLsOpWTqzSUa13wWfqfBq0absI+ZDYoqcK5PiMWCgrz2ZY2qMErlMfH7SYM1rItg/N2lGqoKm0qYcrfyItFJQwXvln8Z5h/t7Zb5AODzFj1bJAxHWxaWPsGfZWXgw2N76fPmvhZ3cd8kodgirutnvR6/Jozh8gEzhSdvDQPYG0f0IYviPnIyqbS1XjttcGFD+931lLQx+m+WZaeeoBQ1oQM57EF1wS0yOR9WAEHQ93BiSaIRYR1eFHE/BcRNwBVtVChwX0EidmdGcTmPWWmJ6Dudz/Rk/M42gjWUlFTKl7y0Cupo3eszeMb06cZDgZywzqeXZO4/ENtqFeXQqgiGkTx3A22ST/PQtwEHht/FWNrgOf+By2snep69/JJs2vhlcO6ZdIePCvThfsenW6AElsRFGgMvY/JPV3pvRp93yynRtmh7PEdYwOb733QhrTio4cq2fUNfSh0xkj2QAP3MjlhVOWoITZb9mn6KyuoQOOVx2AL/k2B2qtcOztNzCMHjrUpMc+vyauelKfgwSWD1WqS9BM/4NMJoqPZ7ISGGXpbzYyH0Da0LHUZGOX8UQRu0Y7MyZ0ygPPu8p7gEDdqf9TagM1UCP8RrRN00floYd587lFW5pxwk7wi3ATdZUoemFiSax5DU/uPetgN3NbPRySIs6GKnXuy7sGHJ5d7mIf6wSYqQTz7QPHzIALv8kuxg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8936002)(6506007)(53546011)(186003)(66556008)(66616009)(66946007)(66476007)(85182001)(26005)(66446008)(64756008)(316002)(110136005)(9326002)(99936003)(4326008)(71200400001)(8676002)(76116006)(508600001)(7696005)(122000001)(2906002)(9686003)(66574015)(33656002)(5660300002)(55016002)(83380400001)(86362001)(38100700002)(85202003)(38070700005)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?QUVFcE5Nb1B1dlkyYW45RHBQWnpvSWxpL1JRQjdSTVFVYkFXSDJPY05ZMVpw?= =?utf-8?B?SWJrZHhuZ3lUTWlyRDNDNHV4bzQvay9kUW91K0k5THpsK2U5djU3SlQrVVUv?= =?utf-8?B?dlZ1R3FlRzBtbGcveTNrQXMrT3g3b0tDdnlwYSt6emIxOThUd0I4SUMvc0Fy?= =?utf-8?B?OUYrUS9kS0JKcTd1cmhUV0JyZFZWTTJZK1lSdHBmemNsZjZsWW9zWnkzOWxW?= =?utf-8?B?bEMycWVNd0FsL2wxQ1lVNDJzeGt2c0tSWWlOdStQSXVyblVHc0xPV2tMQTcy?= =?utf-8?B?NVNMN0tsR0J4d3paMlZPNUQ4U2tlUVNMR3lWOGNGWlVpT1RYY2xTRGwxeFhi?= =?utf-8?B?a09sQW5CT3h2YzNLUUlsc2QzdUREU3pRVHFUOGlEeC9VdWRvNnNRWFd6aEdt?= =?utf-8?B?VnhsWGFoeHZBY2Y0VFBkQ2pEeFNkZjFIeEY0KzlLWU9uQmJ4SzFhb0MvcFVX?= =?utf-8?B?bytqbXlhT1dpeHJqZll1OFFzRCtYQzdHRmR6OU5pYmJQcEZWbHhXNE9BK2FP?= =?utf-8?B?TlpQVU1LRkhydzNSc1haUEZBVjBLbDB3aTJQU0pTU09Qbzl5RGFJMHpvQVo1?= =?utf-8?B?WmZDWUtCcldwbWcyakx5OWVXM1BHQnE1clZJWUZVT1JKYUNxVG9qbkIxcVY2?= =?utf-8?B?OWlaUVpHWmR4UzE5enhsODVZK2pFN1p1cThYU2pyeFdrRnVKY0w5Vk5INkx5?= =?utf-8?B?VjJIU2VoQkpDaDNWU0Uxcm1JVzN0RGR4R25ZTDlQak81UFBuNXg4dDJKUkZY?= =?utf-8?B?NzExYU1YTExweTVTQ2V4c0VsbU9GNlNGVWc4ODhQcnRnMUFSMWg5eHhoeUdQ?= =?utf-8?B?UitYQUkyKy9QVXY1MHFYTEZWUG43OEZqNjJNMlJnSUxNM1dTNFliOENPM25U?= =?utf-8?B?RlZqeFhmK0xHSmN1bWYrQzZuWTg3U0ZNM25LOE02U0xrZW9RWVdIbDR0bDVP?= =?utf-8?B?d1RGTDNhUWdLOWxMeExDaktPNlJzWHNJVmpkUmRzZHNOdkpBTVc1aWhMOEQr?= =?utf-8?B?aGd6MHdlaUh4Q0RrTWFGWGZjUS9ic0JnazhLOFM0WmVLbER2RjF3UWJuaTJG?= =?utf-8?B?TWNncHF6TzJZMUJPSmVCeTFsT3hKNmZWV3BCWWp0cGJyL1RNMDNZc0V3VGxS?= =?utf-8?B?NzdTS0ZKYlZSVTVJakRLeWZiTWJPNmhUSHVJL3Vtbm1PZC9CWnhETHB4b3Bq?= =?utf-8?B?aHpWZG44eEM4bU1iNXY3cTM1T2xoOGVhR1hUSGNta3J1UzVTNkVoY3ZMTjFD?= =?utf-8?B?QzExUXFRczM4VXVWVmFZQVFpcitEK2dYY1BnNDBnbjNNd2IzalRKRmhxMUgx?= =?utf-8?B?OXNkbWFaK0NGbWF0VmptVExxdHo4YWlCUDZkSlRSam51Uzd6UkpCOSthUWVr?= =?utf-8?B?V1hXWGVjQ3pXd2RpREdvSVVlb2NuTTAwNjlmTFlHN1F5NjhkektYcE1YQjdt?= =?utf-8?B?RkhhQ3VFMWN0NGIxUVFDTlZtSDZla3gvb1dhVjRRWTg0WCt0VHJIMFd6cFB1?= =?utf-8?B?QTFsbXNpbXBCNUZ2c1JqMlZRdnk1N05DcW02SVdwOXExMFZoZHV2VjVkL2hD?= =?utf-8?B?cGczNkNPMlRiL3J3aTNWUjE1WGdtMzRnQXA1V216RlByek5leFFvdWUvbStG?= =?utf-8?B?b0xGSC9qa2p1YXBCOU5Eenh5S291MHlLNDg2c2c2Q3o2TEY2UzhROHMvd2s2?= =?utf-8?B?dUx2QWlIeENXZ0o2SUY3dy9SUlVLMmM5bHFOM3c5M0gzZlRjU2NncmJwSmw0?= =?utf-8?Q?CbY24iN8bSoNU1hcM8Qful9QQazC5ZtzSmO4bM0?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0008_01D7840C.3577DA00" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d7b0bbfa-47e5-4d21-41b7-08d952129582 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2021 21:56:41.9602 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: M6fnazdAUzOgJLYByuABjsD+oHv6f5eiIqsuFpG+1+eTpurSvCagHXe11vzfgCG9UYoHLT5zzbCDX7bZiL/YAIMPadsi6kqTHsfnmNX/P6E= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8171 Archived-At: Subject: Re: [netmod] yang-instance-file include-defaults leaf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 21:56:52 -0000 ------=_NextPart_000_0008_01D7840C.3577DA00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0009_01D7840C.3577DA00" ------=_NextPart_001_0009_01D7840C.3577DA00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Andy, I will remove the =E2=80=9Cdefault trim; =E2=80=9C Balazs =20 From: Andy Bierman =20 Sent: 2021. j=C3=BAlius 27., kedd 19:00 To: Rob Wilton (rwilton) Cc: Bal=C3=A1zs Lengyel ; NetMod WG = Subject: Re: [netmod] yang-instance-file include-defaults leaf =20 Hi, =20 None of this addresses my point that a default value of "trim" is not = appropriate. Simply remove the default-stmt so that a missing leaf instance means = that no information is provided, rather than meaning defaults were added for = basic-mode=3Dtrim. =20 =20 Andy =20 =20 On Tue, Jul 27, 2021 at 8:38 AM Rob Wilton (rwilton) > wrote: Hi Andy, Balazs, =20 So, the reason that I want a flag to indicate whether default values are = in use is because of this definition of operational in RFC 8342: =20 Requests to retrieve nodes from always return the value in use if the node exists, regardless of any default value specified in the YANG module. If no value is returned for a given node, then this implies that the node is not used by the device. =20 It was written this way because otherwise a consumer of operational data = cannot differentiate between: (i) This value is not present because it matches the = default value specified in the YANG module, and (ii) This value is not present because the server has = failed to return it for some reason (e.g., perhaps the daemon that would = have provided this value is down or not available, or perhaps it is a = bug, or perhaps it is not implemented and is a missing deviation). =20 So, I think that in some cases, the absence of a data node does not = necessarily mean that the default value is in effect, and I wanted the = instance-data document to be able to contain and correctly report this = data. =20 I think that this behaviour could be captured by a single leaf. Another = way of articulating this would be: =20 leaf in-use-values { type boolean; default false; description =E2=80=9COnly if set to true, the absence of a value in the instance data for a given data node implies that the node is not used rather than implicitly taking the default value specified by any corresponding =E2=80=98default=E2=80=99 statement specified in the YANG = schema.=E2=80=9D; } =20 With this, I=E2=80=99m not sure whether we need the = =E2=80=9Cincludes-default=E2=80=9D leaf currently specified in the = draft, but if we do, then I would think that leaf should be entirely = optional, i.e., without the default =E2=80=9Ctrim=E2=80=9D. =20 Regards, Rob =20 =20 From: Andy Bierman >=20 Sent: 10 July 2021 17:41 To: Rob Wilton (rwilton) > Cc: NetMod WG >; Bal=C3=A1zs = Lengyel > Subject: Re: [netmod] yang-instance-file include-defaults leaf =20 =20 =20 On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) > wrote: Andy, =20 Yes, when I suggested this, I was thinking that a boolean flag might be = sufficient. My point being that automatically filtering out default = values isn=E2=80=99t always the right thing to do. =20 =20 =20 The solution is simple. Get rid of the inappropriate "default trim" statement. =20 If the leaf is present then it identifies the basic-mode that was used = to include defaults. If not then the information is either not known, not applicable, or = defaults were not added. =20 The "default" statement is a bug because there is no default basic-mode. All of the basic-modes are in use in deployments and no camp has ever been able to convince the others that theirs is right. =20 =20 Andy =20 E.g., something along these lines: =20 leaf exclude-defaults { type boolean; default true; description =E2=80=9CCan be used to reduce the size of the content data file. =20 When unset or set to true, data nodes that have a default defined = and where the actual value is the default value are excluded from the = content data. =20 When set to false, data nodes with default value are not filtered, = and may appear in the content data.=E2=80=9D } =20 Would this satisfy your concern? =20 Regards, Rob =20 =20 From: netmod > = On Behalf Of Andy Bierman Sent: 08 July 2021 18:16 To: NetMod WG > Subject: [netmod] yang-instance-file include-defaults leaf =20 Hi, =20 The module has this object: =20 leaf includes-defaults { type enumeration { enum report-all { value 1; description "All data nodes SHOULD be included independent of any default values."; } enum trim { value 2; description "Data nodes that have a default defined and where the actual value is the default value SHOULD NOT be included."; } enum explicit { value 3; description "Data nodes that have a default defined and where the actual value is the default value SHOULD NOT be included. However, if the actual value was set by a NETCONF client or other management application by the way of an explicit management operation the data node SHOULD be included."; } } default trim; =20 The draft is extremely server-centric, like most IETF standards, but = this leaf is too server-centric to ignore. =20 Consider the possibility that the source of the file is NOT a NETCONF = server. This data may not be known so the default of "trim" may not be correct. =20 IMO this leaf is noise because any tool that knows the schema will also know the YANG defaults. The solution is incomplete anyway because the presence of a leaf that has a YANG default is not enough. The "report-all-tagged" mode must be used to identify defaults. IMO this leaf should be removed, but at least add an enum called = "unknown". =20 =20 Andy =20 =20 ------=_NextPart_001_0009_01D7840C.3577DA00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello Andy,

I will remove the =E2=80=9Cdefault trim; = =E2=80=9C

Balazs

 

From: Andy Bierman = <andy@yumaworks.com>
Sent: 2021. j=C3=BAlius 27., kedd = 19:00
To: Rob Wilton (rwilton) = <rwilton@cisco.com>
Cc: Bal=C3=A1zs Lengyel = <balazs.lengyel@ericsson.com>; NetMod WG = <netmod@ietf.org>
Subject: Re: [netmod] = yang-instance-file include-defaults leaf

 

Hi,

 

None of this addresses my point that a default value = of "trim" is not appropriate.

Simply remove the default-stmt so that a missing leaf = instance means that

no = information is provided, rather than meaning defaults were added for = basic-mode=3Dtrim.

 

 

Andy

 

 

On = Tue, Jul 27, 2021 at 8:38 AM Rob Wilton (rwilton) <rwilton@cisco.com> = wrote:

Hi Andy, Balazs,

 

So, the reason that I want a flag to indicate whether = default values are in use is because of this definition of operational = in RFC 8342:

 

   Requests to retrieve nodes from = <operational> always return the value

   in use if the node exists, regardless of = any default value specified

   in the YANG module.  If no value is = returned for a given node, then

   this implies that the node is not used by = the device.

 

It was written this way because otherwise a consumer of = operational data cannot differentiate between:

(i)          = ;        This value is not present because it matches the default = value specified in the YANG module, and

(ii)          = ;      This value is = not present because the server has failed to return it for some reason = (e.g., perhaps the daemon that would have provided this value is down or = not available, or perhaps it is a bug, or perhaps it is not implemented = and is a missing deviation).

 

So, I think that in some cases, the absence of a data node = does not necessarily mean that the default value is in effect, and I = wanted the instance-data document to be able to contain and correctly = report this data.

 

I think that this behaviour could be captured by a single = leaf.  Another way of articulating this would = be:

 

leaf in-use-values = {

  type = boolean;

  default = false;

  = description

    = =E2=80=9COnly if set to true, the absence of a value in the

     = instance data for a given data node implies that the

    n= ode is not used rather than implicitly taking the

     = default value specified by any corresponding

    =E2= =80=98default=E2=80=99 statement specified in the YANG = schema.=E2=80=9D;

}

 

With this, I=E2=80=99m not sure whether we need the = =E2=80=9Cincludes-default=E2=80=9D leaf currently specified in the = draft, but if we do, then I would think that leaf should be entirely = optional, i.e., without the default = =E2=80=9Ctrim=E2=80=9D.

 

Regards,
Rob

 

 

From: Andy Bierman <andy@yumaworks.com>
Sent: 10 July = 2021 17:41
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: NetMod WG = <netmod@ietf.org>; Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com>
Subject: = Re: [netmod] yang-instance-file include-defaults leaf

 

 

 

On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton = (rwilton) <rwilton@cisco.com> = wrote:

Andy,

 

Yes, when I suggested this, I was thinking = that a boolean flag might be sufficient.  My point being that = automatically filtering out default values isn=E2=80=99t always the = right thing to do.

 

 

 

The solution is = simple.

Get rid of the inappropriate "default = trim" statement.

 

If the leaf is present then it identifies the = basic-mode that was used to include = defaults.

If not then the information is either not = known, not applicable, or defaults were not = added.

 

The "default" statement is a bug = because there is no default = basic-mode.

All of the basic-modes are in use in = deployments and no camp has ever

been able to convince the others that theirs = is right.

 

 

Andy

 

E.g., something along these = lines:

 

leaf exclude-defaults = {

  type boolean;

  default true;

  description

    =E2=80=9CCan be used to = reduce the size of the content data file.

 

      When unset or = set to true, data nodes that have a default defined = and

      where the = actual value is the default value are excluded from the = content

    =   data.

 

      When set to = false, data nodes with default value are not filtered, = and

      may appear in = the content data.=E2=80=9D

}

 

Would this satisfy your = concern?

 

Regards,
Rob

 

 

From: netmod <netmod-bounces@ietf.org> On Behalf Of = Andy Bierman
Sent: 08 July 2021 18:16
To: NetMod = WG <netmod@ietf.org>
Subject: [netmod] = yang-instance-file include-defaults leaf

 

Hi,

 

The module has this = object:

 

    leaf includes-defaults =
{
       type =
enumeration {
         =
enum report-all {
        &nb=
sp;  value 1;
        &nb=
sp;  description
        &nb=
sp;    "All data nodes SHOULD be included =
independent of
        &nb=
sp;      any default values.";
         =
}
         =
enum trim {
        &nb=
sp;  value 2;
        &nb=
sp;  description
        &nb=
sp;    "Data nodes that have a default defined and =
where
        &nb=
sp;      the actual value is the default value =
SHOULD
        &nb=
sp;      NOT be included.";
         =
}
         =
enum explicit {
        &nb=
sp;  value 3;
        &nb=
sp;  description
        &nb=
sp;    "Data nodes that have a default defined and =
where
        &nb=
sp;      the actual value is the default value =
SHOULD NOT be
        &nb=
sp;      included. However, if the actual value =
was set by
        &nb=
sp;      a NETCONF client or other management =
application
        &nb=
sp;      by the way of an explicit management =
operation the
        &nb=
sp;      data node SHOULD be =
included.";
         =
}
       }
       default =
trim;
 

The draft is extremely server-centric, like = most IETF standards, but this

leaf is too server-centric to = ignore.

 

Consider the possibility that the source of = the file is NOT a NETCONF server.

This data may not be known so the default of = "trim" may not be correct.

 

IMO this leaf is noise because any tool that = knows the schema will also

know the YANG defaults.  The solution is = incomplete anyway because

the presence of a leaf that has a YANG default = is not enough.

The  "report-all-tagged" mode = must be used to identify defaults.

IMO this leaf should be removed, but at least = add an enum called = "unknown".

 

 

Andy

 

 

= ------=_NextPart_001_0009_01D7840C.3577DA00-- ------=_NextPart_000_0008_01D7840C.3577DA00 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDcyODIxNTY0MFowIwYJKoZIhvcNAQkEMRYEFJ+e+uEEXFQU z2LaaqchNpNJBrLUMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAGgX J6zwWEAjN7d3mfZxZ1MXuVgb/vPMcToIdz6D9IwVqgDH6eaC2BkzGqQKmwWZDL6mlCES5QhwhLsn GusRgu90Nvw5vEfxp54WJo9U5uwu26ZZVTujKBQoa09pnzJyBqRlZwTK+cgM3ETGiwSsXXFp++3Z YJNfqXST9iUgaN4X4rAVowzGwLhFds1fE1RBZ/c4H/Fo0tyrDTZ5bmP6MCpgr4mR+4gkxb2VFrTJ kT4Km/HJAoDzQtASCTfCBWBPFfap6j7s8A3rBG5amEu6Xx+7ycFnWjBSFKqAdRE4vI3Fa/JDGvsl aRcZvRFdfJahs5Eprnnag13adr5omDLY5a0AAAAAAAA= ------=_NextPart_000_0008_01D7840C.3577DA00-- From nobody Wed Jul 28 15:08:30 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7272D3A238C for ; Wed, 28 Jul 2021 15:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDyNE_Ed3sJV for ; Wed, 28 Jul 2021 15:08:22 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2057.outbound.protection.outlook.com [40.107.20.57]) (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 6ED883A238F for ; Wed, 28 Jul 2021 15:08:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CpadaiAnv0Us6j57sJ69ssTVXcr3E4tb/A3ZOf6N9lTJDyFypxVnBKlPtsJ066tvCHrHwqjZASLkitl75NE/5dCwtqzPRn4ttR2+EjRXRfkgqbgomADTSFn09t+S0L2qALCgyZlfEOy/JLiyGjLddR2jWKZSuv4vGu4GXfjoF175EtTv1skQM8bZyyh5WQynRY5PUkHZl/gbdDcKBSAJlQferpBKN49EzrSWlMoaTcWDCJUJbt/oaV4yBwJuqp+Kv1rqFO8g++DVnvnGMfcRbMpOBOfpzvzWsbZWcH3hxC7Y26QSmvtMRLwWu123gH4/KBo6UKc/foxxGWtWS6sw8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WmZrpM4KSsBrwN3AqIdV/4eIe9RaB2yWxOmuKXQ9omU=; b=TgmJigcdqa78RpAhNS0f84pjCf8eLJKQG6fDlhEb8RA1WsIcUZqOAeVjqCu98rVZJE6EvvIuSOy+MIwV22dqqWxtZgTiIqYxW14CN57XTIUM330AQMiuxZC5dAogkoiGj3c0kBCI/rtwe87pgv/JfZQLOpzWEdtqrQsDMrXGdyVBBLppxrCm7HITh8JhBLabn9g7ihitapPyk720kgSihNT2rk2rpp6158A62lTNhmobe+L4RClf2AGvUSMXeubabQIZ5JuyQPwOR8N/L056gIXaSlYDn1Mri/5gHeO8nGKmFM4dGWK6hxVQgWmHQGQrvkkRFnpbIYR80EuoEFVgtw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WmZrpM4KSsBrwN3AqIdV/4eIe9RaB2yWxOmuKXQ9omU=; b=nYkBL345uh2pyVR60kFRSzqYv0qssFrrODEeNu8CXB+iFhZgKgUG/efdwz9/IVAolXVCPvGCTgfbOhS3bZoCs0GAyCquJp0AZvPCfomRx064/mPwEQLiqOKYmNtNWuNokdIpfwcrhAv0fZYmCRrZ5C7MD8Ljcuola/UX2s5xBJo= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8105.eurprd07.prod.outlook.com (2603:10a6:20b:36c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.12; Wed, 28 Jul 2021 22:07:48 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4373.018; Wed, 28 Jul 2021 22:07:48 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: "Rob Wilton (rwilton)" , Andy Bierman CC: NetMod WG Thread-Topic: [netmod] yang-instance-file include-defaults leaf Thread-Index: AQHXdB0ScDY6rhEwiUCIGrL2qSijE6s6kiOAgAHaXQCAGqYDAIAB/JVw Date: Wed, 28 Jul 2021 22:07:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8bca7535-3109-4b14-508a-08d9521422b1 x-ms-traffictypediagnostic: AM8PR07MB8105: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1122; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: X2k2ypHEL01rkSGaSqxgqKibOkEu+9VdwjJhDDX3tOPxbunsvrihaIaJ6bU3PbQncj9RG0eG7NC+c3DZ+VRcpxxcMT5lBJaLBHt40vMt4uEv/48roXtj5P9VOsskZ+/6ULp++oY6OiGsbaTw5MoQWwM7jNoJxbmgDhtQ6xcJJ8BadgFp/G/KlS0Lqxi55lUPoLa1s2BH3jyj3PX7PSFTw3hc3+/OPIBf0zYYaicZdnbkECm+anefolLcM46VBb+EwDAO65VCAL+A34qn2FocHw3iibOK1tX0Yxx9r6qRv0EK86fajdnut3+W23/8qd4ovrXDkKxfUAomL1tZnMWBnih7SEgQdT4VhTksRSeN79anJjxeDWTBofJz+b0dzd5GbA6An69NAzlY1QCbUcZLYM/WVkLAoPeNZxcwAJhC07fsnXbzDZBjX4a+bc9Vp5a5zVv6eHpJbNGiBm26yhYxgAI2NpwqW5xAhraY6RuUVsQXXuamwvPBiyhvxld2L8xX4rjPijJ/kcyPnmVK5j7k9sUKWKtfxrHWprqEDgdyDWIhJ79RzZ5v76Ar/4yAxuxpUaiFOzlUON73qF5sbmAR3Ifjbfu/DqFP9AOyMC5/40zzlYXVTZna7DAvfYkYyFocDvU1XsdR5noNw8a9Y1JGCOesn+z9PFpKeH9C8mNJjqwk4KwSAhGoEQJMl7TUBblS+094CbvcCmbG5p8Jzc/djQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(316002)(71200400001)(86362001)(5660300002)(55016002)(64756008)(66476007)(66556008)(66946007)(9686003)(66446008)(110136005)(122000001)(76116006)(38100700002)(85182001)(83380400001)(52536014)(4326008)(186003)(33656002)(26005)(53546011)(6506007)(99936003)(66616009)(8676002)(2906002)(9326002)(85202003)(508600001)(8936002)(7696005)(38070700005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?SDlWNTJpSFlWVGZGM0xJTE9CWDJDVjlVNWpvYncwM0t5b29JUXoyQXo0RnA5?= =?utf-8?B?ZlpzOFNscFk3YTNRcDBpNDFuNmRIbmlkZFJTMTQ1RmVXb2ViUmZvQmVCOG00?= =?utf-8?B?VWFYVjF3MkUxSnd1MjhCQlp1Y2NNSTBxVkxEc25Zc1BBRGdpU0dSallGNmRW?= =?utf-8?B?SDJQT0h3UHdheWxlbTBNdnM3Njdjb3hhRHBvL3o5Mm1rTlJJenQ4R2o1Nk1s?= =?utf-8?B?T2JtbUlkdjgxZmdoMjFvak1XeE5CZGdJV3VQNkFEdEVpdlUvVHlDbFpoMzRM?= =?utf-8?B?a1lsNksya1hkNUlVZW9mTHl5alh4QUVscjhPL3B3RHZVb3Q3VkFnWlBRaU1U?= =?utf-8?B?SDNsT0lHNlE5eEpONzJqT1h3SGdtU0dtZisrQXY1ZDFQZzBJc3c0MU51RkUv?= =?utf-8?B?RHlIZEZ2d1VYY3lCQzJKZDhNZDVWSUg0Y0hwdnk1YWtsQUpiRnVHSG8xcGhD?= =?utf-8?B?ZHNpaWpQcWM5dHJIcURRSDI0blV3SXhxenpZN3JZZDQxK21TUXJxOEtueTg5?= =?utf-8?B?b3ZoaXZad0lyQldXS2pvNDE1elhMc2lTSXJlYnNpWlNZYTc5bWY0WGRzZVhm?= =?utf-8?B?YjJ6aDZ6RzNJWGRtbnM5bHZoQnkrelY4bXhKU3AxaHZ0RlFlQU5RYXFyVU4y?= =?utf-8?B?YmE0ZkZvZnhKM1hjb003Mzh6Z1RlbHZiazVYVEtrZ1BlUnZSaWJEVGdDaVRG?= =?utf-8?B?RGpYUkdwdDBuSVBidW5tQkgvTFZ4ODVCRWZudkFORU4wOFNWMDdkalBqeFlh?= =?utf-8?B?V0xUNFJNUkx5akhyNmNZSTB4UGZxZUkvaSsyZVlhUDNBMjAxcnYxeUIwS0s1?= =?utf-8?B?UHlHUlNpQWsvd0pYK3NBaCtHUngxWVRHaHh3WVE2LzBuRUFlSUZlbHc5Nm14?= =?utf-8?B?eTlrOWcxRjlBalBIZEtCK2Q1TU1zUHRRZHJOcmxScnY3bk1lakE3SVR6R3lO?= =?utf-8?B?Rks4dDhKSDdVWE1rcGpidzczbHFqd044cU5NcklRckNDQnhva1dCa2p2SUVF?= =?utf-8?B?c0J0ajFaVHhrd1Zza2dCWkorWDJRSzdZRkdlQTc5OG1aZXNHNFM3OHloemNp?= =?utf-8?B?eXo3eUIwU3BudzhKaVpjSnpKcjVNdGNnbkFrcVFybXR5RWh0cldYNVBpZ01h?= =?utf-8?B?L3YyRVZMS0FxUko5L3loc29YU3hVc01yODVHekY2dUNLMTVjUnFteXJka3ZE?= =?utf-8?B?aFRaQmkxOVE3cHRIYi9vd3lOamdKYkx2bHFURzU2eHhCTUpIZUIyZTk0THdU?= =?utf-8?B?b1RqbXlEN2xsMk43MURmdHhJZW5haEsxQW4vckVLcGhmanhINms0YXo5Z2FM?= =?utf-8?B?RnUwMGp2S3pwY3YvUTVUWmRzMjBvejVEbG9CYmJCaVphMTh5M2RIK0twdEZl?= =?utf-8?B?YXlnSjl3VG44T0ZPWk9wazQzT2ZwN1lya1JFRWxJN3JBQUlxeklXUjJSMDdk?= =?utf-8?B?bjI3WHRFb211Z29yalZydllIMEt6UVdvWGoyQVpvMWdwOEc2TDlGRVFtTUtX?= =?utf-8?B?ZGd0M2xzdlo3eGMyckprMWN6MEZ4WjlBYVFKM0NZY3RBUktmL3psUWl1Lzdi?= =?utf-8?B?NUsvMHFsU0N4Mm5nRGh2dzlPYkpxdXBWNk1Rc0FlMXMrRFNLQVhXK1NoUVds?= =?utf-8?B?TkRQYmpldzBTNk9vLzg2Z2JyM3U5cFhHS3l4ZGgyUmpVb2ViZk1uM05Demt3?= =?utf-8?B?VjYvQjI1eXZtZ25DemtLdnRUenUvenJTRkdIUm5sY0RYWlY1TTZaOCtvZ2Vj?= =?utf-8?Q?Nemg3Qku7ay+JMyXnqf6KAEMHFUgQRacR9yLMcA?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000F_01D7840D.C2EDE1D0" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8bca7535-3109-4b14-508a-08d9521422b1 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2021 22:07:48.3380 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: CCVYBeIY9E5E5ksyg2lR2jv+0m04zPPIO+tZD7w1PJlJ19NagVdnK9cX0b55IrmJZk3DcFc5cM0sgmMvWQVZzteCzQTlegF/tOv3nU6fsRw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8105 Archived-At: Subject: Re: [netmod] yang-instance-file include-defaults leaf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 22:08:29 -0000 ------=_NextPart_000_000F_01D7840D.C2EDE1D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0010_01D7840D.C2EDE1D0" ------=_NextPart_001_0010_01D7840D.C2EDE1D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Rob, Removing the =E2=80=9Cdefault trim;=E2=80=9D will address Andy=E2=80=99s = comment. =20 Your in-use-values is very specific to one of the use-cases: = reading/documenting operational values. It is not useful for the other = use-cases. I think the =E2=80=9Cdocumenting operational = datastore=E2=80=9D use-case could be handled by indicating the = includes-defaults=3Dreport-all. Case (i) would contain the value case = (ii) will not. Regards Balazs =20 From: Rob Wilton (rwilton) =20 Sent: 2021. j=C3=BAlius 27., kedd 17:38 To: Andy Bierman ; Bal=C3=A1zs Lengyel = Cc: NetMod WG Subject: RE: [netmod] yang-instance-file include-defaults leaf =20 Hi Andy, Balazs, =20 So, the reason that I want a flag to indicate whether default values are = in use is because of this definition of operational in RFC 8342: =20 Requests to retrieve nodes from always return the value in use if the node exists, regardless of any default value specified in the YANG module. If no value is returned for a given node, then this implies that the node is not used by the device. =20 It was written this way because otherwise a consumer of operational data = cannot differentiate between: (i) This value is not present because it matches the = default value specified in the YANG module, and (ii) This value is not present because the server has = failed to return it for some reason (e.g., perhaps the daemon that would = have provided this value is down or not available, or perhaps it is a = bug, or perhaps it is not implemented and is a missing deviation). =20 So, I think that in some cases, the absence of a data node does not = necessarily mean that the default value is in effect, and I wanted the = instance-data document to be able to contain and correctly report this = data. =20 I think that this behaviour could be captured by a single leaf. Another = way of articulating this would be: =20 leaf in-use-values { type boolean; default false; description =E2=80=9COnly if set to true, the absence of a value in the instance data for a given data node implies that the node is not used rather than implicitly taking the default value specified by any corresponding =E2=80=98default=E2=80=99 statement specified in the YANG = schema.=E2=80=9D; } =20 With this, I=E2=80=99m not sure whether we need the = =E2=80=9Cincludes-default=E2=80=9D leaf currently specified in the = draft, but if we do, then I would think that leaf should be entirely = optional, i.e., without the default =E2=80=9Ctrim=E2=80=9D. =20 Regards, Rob =20 =20 From: Andy Bierman >=20 Sent: 10 July 2021 17:41 To: Rob Wilton (rwilton) > Cc: NetMod WG >; Bal=C3=A1zs = Lengyel > Subject: Re: [netmod] yang-instance-file include-defaults leaf =20 =20 =20 On Fri, Jul 9, 2021 at 5:23 AM Rob Wilton (rwilton) > wrote: Andy, =20 Yes, when I suggested this, I was thinking that a boolean flag might be = sufficient. My point being that automatically filtering out default = values isn=E2=80=99t always the right thing to do. =20 =20 =20 The solution is simple. Get rid of the inappropriate "default trim" statement. =20 If the leaf is present then it identifies the basic-mode that was used = to include defaults. If not then the information is either not known, not applicable, or = defaults were not added. =20 The "default" statement is a bug because there is no default basic-mode. All of the basic-modes are in use in deployments and no camp has ever been able to convince the others that theirs is right. =20 =20 Andy =20 E.g., something along these lines: =20 leaf exclude-defaults { type boolean; default true; description =E2=80=9CCan be used to reduce the size of the content data file. =20 When unset or set to true, data nodes that have a default defined = and where the actual value is the default value are excluded from the = content data. =20 When set to false, data nodes with default value are not filtered, = and may appear in the content data.=E2=80=9D } =20 Would this satisfy your concern? =20 Regards, Rob =20 =20 From: netmod > = On Behalf Of Andy Bierman Sent: 08 July 2021 18:16 To: NetMod WG > Subject: [netmod] yang-instance-file include-defaults leaf =20 Hi, =20 The module has this object: =20 leaf includes-defaults { type enumeration { enum report-all { value 1; description "All data nodes SHOULD be included independent of any default values."; } enum trim { value 2; description "Data nodes that have a default defined and where the actual value is the default value SHOULD NOT be included."; } enum explicit { value 3; description "Data nodes that have a default defined and where the actual value is the default value SHOULD NOT be included. However, if the actual value was set by a NETCONF client or other management application by the way of an explicit management operation the data node SHOULD be included."; } } default trim; =20 The draft is extremely server-centric, like most IETF standards, but = this leaf is too server-centric to ignore. =20 Consider the possibility that the source of the file is NOT a NETCONF = server. This data may not be known so the default of "trim" may not be correct. =20 IMO this leaf is noise because any tool that knows the schema will also know the YANG defaults. The solution is incomplete anyway because the presence of a leaf that has a YANG default is not enough. The "report-all-tagged" mode must be used to identify defaults. IMO this leaf should be removed, but at least add an enum called = "unknown". =20 =20 Andy =20 =20 ------=_NextPart_001_0010_01D7840D.C2EDE1D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello Rob,

Removing the =E2=80=9Cdefault trim;=E2=80=9D will = address Andy=E2=80=99s comment.

 

Your = in-use-values is very specific to one of the use-cases: = reading/documenting operational values. It is not useful for the other = use-cases. I think the =E2=80=9Cdocumenting operational = datastore=E2=80=9D use-case could be handled by indicating the = includes-defaults=3Dreport-all. Case (i) would contain the value = case (ii) will not.

Regards = Balazs

 

From: Rob Wilton (rwilton) = <rwilton@cisco.com>
Sent: 2021. j=C3=BAlius 27., kedd = 17:38
To: Andy Bierman <andy@yumaworks.com>; Bal=C3=A1zs = Lengyel <balazs.lengyel@ericsson.com>
Cc: NetMod WG = <netmod@ietf.org>
Subject: RE: [netmod] = yang-instance-file include-defaults leaf

 

Hi Andy, Balazs,

 

So, the reason that I want a flag = to indicate whether default values are in use is because of this = definition of operational in RFC 8342:

 

   Requests to retrieve nodes from = <operational> always return the value

   in use if the node exists, regardless of = any default value specified

   in the YANG module.  If no value is = returned for a given node, then

   this implies that the node is not used by = the device.

 

It was written this way because otherwise a consumer of = operational data cannot differentiate between:

(i)           = ;    This value is not present because it matches the default = value specified in the YANG module, and

(ii)           = ;   This = value is not present because the server has failed to return it for some = reason (e.g., perhaps the daemon that would have provided this value is = down or not available, or perhaps it is a bug, or perhaps it is not = implemented and is a missing deviation).

 

So, I think that in some cases, the = absence of a data node does not necessarily mean that the default value = is in effect, and I wanted the instance-data document to be able to = contain and correctly report this data.

 

I think that this behaviour could = be captured by a single leaf.  Another way of articulating this = would be:

 

leaf in-use-values = {

  type = boolean;

  default = false;

  = description

    = =E2=80=9COnly if set to true, the absence of a value in = the

     = instance data for a given data node implies that = the

    n= ode is not used rather than implicitly taking = the

     = default value specified by any corresponding

    =E2= =80=98default=E2=80=99 statement specified in the YANG = schema.=E2=80=9D;

}

 

With this, I=E2=80=99m not sure = whether we need the =E2=80=9Cincludes-default=E2=80=9D leaf currently = specified in the draft, but if we do, then I would think that leaf = should be entirely optional, i.e., without the default = =E2=80=9Ctrim=E2=80=9D.

 

Regards,
Rob

 

 

From: = Andy Bierman <andy@yumaworks.com> =
Sent: 10 July 2021 17:41
To: Rob Wilton (rwilton) = <rwilton@cisco.com>
Cc:= NetMod WG <netmod@ietf.org>; Bal=C3=A1zs = Lengyel <balazs.lengyel@ericsson.com>
Subject: Re: [netmod] yang-instance-file = include-defaults leaf

 

 

Andy,

 

Yes, when I suggested this, I was thinking = that a boolean flag might be sufficient.  My point being that = automatically filtering out default values isn=E2=80=99t always the = right thing to do.

 

 

 

The solution is = simple.

Get rid of the = inappropriate "default trim" = statement.

 

If the leaf is present = then it identifies the basic-mode that was used to include = defaults.

If not then the = information is either not known, not applicable, or defaults were not = added.

 

The "default" = statement is a bug because there is no default = basic-mode.

All of the basic-modes = are in use in deployments and no camp has = ever

been able to convince = the others that theirs is right.

 

 

Andy

 

E.g., something along these = lines:

 

leaf exclude-defaults = {

  type boolean;

  default true;

  description

    =E2=80=9CCan be used to = reduce the size of the content data file.

 

      When unset or = set to true, data nodes that have a default defined = and

      where the = actual value is the default value are excluded from the = content

    =   data.

 

      When set to = false, data nodes with default value are not filtered, = and

      may appear in = the content data.=E2=80=9D

}

 

Would this satisfy your = concern?

 

Regards,
Rob

 

 

From: netmod <netmod-bounces@ietf.org> On Behalf Of = Andy Bierman
Sent: 08 July 2021 18:16
To: NetMod = WG <netmod@ietf.org>
Subject: [netmod] = yang-instance-file include-defaults leaf

 

Hi,

 

The module has this = object:

 

    leaf includes-defaults =
{
       type =
enumeration {
         =
enum report-all {
        &nb=
sp;  value 1;
        &nb=
sp;  description
        &nb=
sp;    "All data nodes SHOULD be included =
independent of
        &nb=
sp;      any default values.";
         =
}
         =
enum trim {
        &nb=
sp;  value 2;
        &nb=
sp;  description
        &nb=
sp;    "Data nodes that have a default defined and =
where
        &nb=
sp;      the actual value is the default value =
SHOULD
        &nb=
sp;      NOT be included.";
         =
}
         =
enum explicit {
        &nb=
sp;  value 3;
        &nb=
sp;  description
        &nb=
sp;    "Data nodes that have a default defined and =
where
        &nb=
sp;      the actual value is the default value =
SHOULD NOT be
        &nb=
sp;      included. However, if the actual value =
was set by
        &nb=
sp;      a NETCONF client or other management =
application
        &nb=
sp;      by the way of an explicit management =
operation the
        &nb=
sp;      data node SHOULD be =
included.";
         =
}
       }
       default =
trim;
 

The draft is extremely server-centric, like = most IETF standards, but this

leaf is too server-centric to = ignore.

 

Consider the possibility that the source of = the file is NOT a NETCONF server.

This data may not be known so the default of = "trim" may not be correct.

 

IMO this leaf is noise because any tool that = knows the schema will also

know the YANG defaults.  The solution is = incomplete anyway because

the presence of a leaf that has a YANG default = is not enough.

The  "report-all-tagged" mode = must be used to identify defaults.

IMO this leaf should be removed, but at least = add an enum called = "unknown".

 

 

Andy

 

 

------=_NextPart_001_0010_01D7840D.C2EDE1D0-- ------=_NextPart_000_000F_01D7840D.C2EDE1D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDcyODIyMDc0N1owIwYJKoZIhvcNAQkEMRYEFFGdWY/LtdFg gRUfKS2LxTbAcvZrMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBABCi u9VVaRge5Dblvkz22KtUniq+BIE+YGtLVyBBjTLfQSQBamnd7kIYp8Cl+0Q6Elv6gT7JMgt1g2zW or/1qCb0w6BKmTDh4e0uuTOaNgzvCRkWnqDD9pr6F67rilLERz0B7CjOPCLuA1GD5y6StupD8sDQ +f8EThtzEUm5/pEBEeGTMlhBV4/0hcaMc36C3HhBrC8irE7crG25TKFD/ARHoeU2luXNon4UFTog fK1Sjn3uEF0+X40NnkxDg8o2UyrslQiMo2KaP54lpDem6XgT7UTJJh8/9jO+KKb9wh0xSAVxwc5/ 6yrwmyRxBj/pqKFLNdZpAa9jljHCPIjhCoIAAAAAAAA= ------=_NextPart_000_000F_01D7840D.C2EDE1D0-- From nobody Wed Jul 28 15:32:49 2021 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4627F3A24AE; Wed, 28 Jul 2021 15:32:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.35.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <162751156423.20442.9609855233715552640@ietfa.amsl.com> Date: Wed, 28 Jul 2021 15:32:44 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-17.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 22:32:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : YANG Instance Data File Format Authors : Balazs Lengyel Benoit Claise Filename : draft-ietf-netmod-yang-instance-file-format-17.txt Pages : 28 Date : 2021-07-28 Abstract: There is a need to document data defined in YANG models at design time, implementation time or when a live server is unavailable. This document specifies a standard file format for YANG instance data, which follows the syntax and semantics of existing YANG models, and annotates it with metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-17 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 31 05:32:52 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18A03A249C for ; Sat, 31 Jul 2021 05:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6C2REzFJlk9L for ; Sat, 31 Jul 2021 05:32:38 -0700 (PDT) Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7103A2493 for ; Sat, 31 Jul 2021 05:32:37 -0700 (PDT) Received: from fraeml704-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4GcNvL4y88z6L9Ps for ; Sat, 31 Jul 2021 20:32:30 +0800 (CST) Received: from dggeme720-chm.china.huawei.com (10.1.199.116) by fraeml704-chm.china.huawei.com (10.206.15.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Sat, 31 Jul 2021 14:32:32 +0200 Received: from dggeme770-chm.china.huawei.com (10.3.19.116) by dggeme720-chm.china.huawei.com (10.1.199.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Sat, 31 Jul 2021 20:32:30 +0800 Received: from dggeme770-chm.china.huawei.com ([10.8.68.58]) by dggeme770-chm.china.huawei.com ([10.8.68.58]) with mapi id 15.01.2176.012; Sat, 31 Jul 2021 20:32:30 +0800 From: "maqiufang (A)" To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] system configuration sync mechanism Thread-Index: Add4ieaMV4M1zhk1St6ROfyHhlohlAAAAuNAADd2vwAAKFO5cAJhxiGAAJuFmrA= Date: Sat, 31 Jul 2021 12:32:30 +0000 Message-ID: References: <5b76dae2175545959f0006b036efd647@huawei.com> <2d1262bc90fc49d08eb641365b959ea4@huawei.com> <0100017aab854793-eb989e55-8496-451b-84de-7f17cb0720d5-000000@email.amazonses.com> <0100017aee17493f-6b9b747c-f0f1-4a70-b929-aaa0350a555f-000000@email.amazonses.com> In-Reply-To: <0100017aee17493f-6b9b747c-f0f1-4a70-b929-aaa0350a555f-000000@email.amazonses.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.123.93] Content-Type: multipart/alternative; boundary="_000_aa3dfdb471f0430aa50c4e35b9672fb1huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] system configuration sync mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2021 12:32:51 -0000 --_000_aa3dfdb471f0430aa50c4e35b9672fb1huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEtlbnQsDQpUaGFua3MgZm9yIGhlbHBpbmcgbWUgcmV2aXZlIHRoaXMgdGhyZWFkLCB3aGlj aCBpcyBleGFjdGx5IHdoYXQgSSB3YW50IHRvIGRvLjopDQpUaGVyZSB3YXMgbm90IGEgdmVyeSBm dWxseSBkaXNjdXNzaW9uIGR1ZSB0byB0aW1lIGNvbnN0cmFpbnRzLCBidXQgd2UgZGlkIHNlZSBz b21lIHZhbHVhYmxlIHBvaW50cyBoZXJlLCB0aGFuayB5b3UgZXZlcnlvbmUgZm9yIHNoYXJpbmcg eW91ciB2aWV3cy4NCg0KUmVnYXJkaW5nIG9wdGlvbjIsICBJIGFtIHN0aWxsIHVuc3VyZSBob3cg d2lsbCB0aGluZ3MgZ28gaWYgdGhlcmUgaXMgbm8gPGludGVuZGVkPihJIHRoaW5rIGl0IHdhcyBy YWlzZWQgYnkgQmFsYXpzLCBob3BlZnVsbHkgQmFsYXpzIGNhbiBhbHNvIGFkZCBzb21ldGhpbmcg aGVyZSk/IFNob3VsZCA8c3lzdGVtPiBiZSBpbXBsZW1lbnRlZCBhbG9uZyB3aXRoIDxpbnRlbmRl ZD4/DQoNCk9wdGlvbiAzIGlzIHN0aWxsIHVuY2xlYXIsIGUuZy4sIHdoZXRoZXIgdGhlIDxzeXN0 ZW0+IGlzIGNvcGllZCBpbnRvIDxydW5uaW5nPiBhdXRvbWF0aWNhbGx5IG9yIG1hbnVhbGx5PyBJ ZiBhdXRvLWNvcHkgaXMgbm90IGEgZ29vZCBpZGVhIGJlY2F1c2UgaXQgdmlvbGF0ZXMgdGhlIGRl ZmluaXRpb24gb2YgPHJ1bm5pbmc+LCB3aGV0aGVyIG1hbnVhbC1jb3B5IGlzIHBlcmZvcm1lZCB0 b3dhcmRzIHBhcnQgb3IgYWxsIG9mIHRoZSBzeXN0ZW0gY29uZmlndXJhdGlvbnMgY3JlYXRlZCBp biA8c3lzdGVtPj8NClNob3VsZCB3ZSBjb3B5IHRoZSBlbnRpcmUgPHN5c3RlbT4gaW50byA8cnVu bmluZz4/IE9yIHNob3VsZCB0aGVyZSBiZSBhcyBmZXcgc3lzdGVtIGNvbmZpZ3VyYXRpb24gZGF0 YSBpdGVtcyBpbiA8cnVubmluZz4gYXMgcG9zc2libGU/DQpBbnl3YXksIEkgYWdyZWUgdGhhdCBv cHRpb24zIG1heSBzdGlsbCBpbmN1ciBhIGZhaWxlZCB2YWxpZGF0aW9uIG9mIDxydW5uaW5nPiB3 aGVuIHRoZSBvcGVyYXRvcnMgcmVmZXJlbmNlIHRoZSBzeXN0ZW0gY29uZmlndXJhdGlvbiB3aGlj aCBpcyBwcm9kdWNlZCB0aHJvdWdoIHRoZSBleHBhbnNpb24gb2YgdGhlIHN5c3RlbS1kZWZpbmVk IHRlbXBsYXRlcy4NCklmIHRoZSBleGlzdGluZyBtZWNoYW5pc20oZS5nLiwgZWRpdC1jb25maWcp aXMgc3VmZmljaWVudCB0byBkZWZpbmUgcmVmZXJlbmNlZCBzeXN0ZW0gZGF0YSBpdGVtIGluIDxy dW5uaW5nPiwgaXQgc2VlbXMgdGhhdCB0aGUgZmxvdyBtYXJrZWQgaW4gb3B0aW9uMyBmcm9tIDxz eXN0ZW0+IHRvIDxydW5uaW5nPiBjYW4gYmUgcmVtb3ZlZCwgdGhlbiBpdCBsb29rcyBubyBkaWZm ZXJlbmNlIGJldHdlZW4gb3B0aW9uMSBhbmQgb3B0aW9uMy4NCg0KQmVzdCBSZWdhcmRzLA0KUWl1 ZmFuZyBNYQ0KDQpGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEtlbnQgV2F0c2VuDQpTZW50OiBUaHVyc2RheSwgSnVseSAyOSwgMjAyMSAx OjA5IEFNDQpUbzogbmV0bW9kQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW25ldG1vZF0gc3lzdGVt IGNvbmZpZ3VyYXRpb24gc3luYyBtZWNoYW5pc20NCg0KV0csDQoNClJlZ2FyZGluZyB5ZXN0ZXJk YXnigJlzIDxzeXN0ZW0+IGRhdGFzdG9yZSBwcmVzZW50YXRpb24sIHRoZXJlIHNlZW1lZCB0byBi ZSBzdXBwb3J0IGZvciAiT3B0aW9uICMy4oCdLCB3aGljaCBpcyB0byBoYXZlIDxzeXN0ZW0+IG1l cmdlIGludG8gPGludGVuZGVkPi4NCg0KSXQgd2FzIG5vdGVkIHRoYXQgdGhpcyB0aGVuIHdvdWxk IG1lYW4gdGhhdCBjbGllbnQtdmFsaWRhdGlvbiBvZiA8cnVubmluZz4gd291bGQgbmVjZXNzaXRh dGUgdW5kZXJzdGFuZGluZyBob3cgdGhlIG1lcmdlIHdvcmtzLCB0byBleHBhbmQgdGVtcGxhdGVz LCByZXNvbHZlIGxlYWZyZWZzLCBldGMuDQoNCk15IHRob3VnaHRzIGFyZSwgc28/DQoNCkZpcnN0 bHksIGEgY2xpZW50IHRoYXQgZG9lc27igJl0IHVuZGVyc3RhbmQgdGhhdCB0aGVyZSBtYXkgYmUg c29tZSA8c3lzdGVtPiBkZWZpbmVkIGNvbmZpZ3VyYXRpb24gd2lsbCwgZm9yIHRoZSBtb3N0IHBh cnQsIGJlIG5vbmUgdGhlIHdpc2VyLiAgIFRoZSBjbGllbnQgKndpbGwqIGRpc2NvdmVyIDxzeXN0 ZW0+IGNvbmZpZ3VyYXRpb24gaW4gPG9wZXJhdGlvbmFsPiwgYnV0IHRoaXMgaXMgYWxyZWFkeSB0 aGUgY2FzZSB0b2RheS4gIE9uZSBuZXcgdGhpbmcgaXMgdGhhdCA8b3BlcmF0aW9uYWw+IHNob3Vs ZCB1c2Ug4oCcb3JpZ2luOnN5c3RlbeKAnSBmb3IgY29uZmlndXJhdGlvbiBvcmlnaW5hdGluZyBm cm9tIHRoZSA8c3lzdGVtPiBkYXRhc3RvcmUuICBUaGlzIGxhc3QgcG9pbnQgbWlnaHQgc3VycHJp c2UgY2xpZW50c+KApmFzIHRoZSBkZWZpbml0aW9uIG9mIOKAnHdpdGgtb3JpZ2lu4oCdIGRvZXNu 4oCZdCBzdGF0ZSB0aGF0IGNsaWVudHMgbXVzdCBpZ25vcmUgYW55IHVucmVjb2duaXplZCDigJxv cmlnaW7igJ0gaWRlbnRpdGllczogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9yZmM4NTI3I3NlY3Rpb24tMy4yLjIuDQoNClNlY29uZGx5LCBubyBzaGFyZWQgb2JqZWN0IGRl ZmluZWQgaW4gPHN5c3RlbT4gd2lsbCBiZSBhY3RpdmF0ZWQgdW50aWwgY2xpZW50LXN1cHBsaWVk IGNvbmZpZyByZWZlcmVuY2VzIGl0LiAgQnV0IGFueSBjbGllbnQgYWJsZSB0byBkbyB0aGlzIGFs cmVhZHkga25vd3MgaG93IDxzeXN0ZW0+IG1lcmdlcyBpbnRvIDxpbnRlbmRlZD4gYW5kIGlzIGFj Y291bnRpbmcgZm9yIGl0Lg0KDQpUaG91Z2h0cz8NCg0KS2VudA0KDQoNCg0KT24gSnVsIDE2LCAy MDIxLCBhdCA2OjI0IEFNLCBtYXFpdWZhbmcgKEEpIDxtYXFpdWZhbmcxQGh1YXdlaS5jb208bWFp bHRvOm1hcWl1ZmFuZzFAaHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpIaSwgS2VudCwNClBsZWFzZSBz ZWUgbXkgcmVwbHkgaW5saW5lLg0KDQpGcm9tOiBLZW50IFdhdHNlbiBbbWFpbHRvOmtlbnQraWV0 ZkB3YXRzZW4ubmV0XQ0KU2VudDogRnJpZGF5LCBKdWx5IDE2LCAyMDIxIDI6NTUgQU0NClRvOiBt YXFpdWZhbmcgKEEpIDxtYXFpdWZhbmcxQGh1YXdlaS5jb208bWFpbHRvOm1hcWl1ZmFuZzFAaHVh d2VpLmNvbT4+DQpDYzogbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW25ldG1vZF0gc3lzdGVtIGNvbmZpZ3VyYXRpb24gc3luYyBtZWNoYW5pc20N Cg0KSGkgUWl1ZmFuZywNCg0KICAgICAgICAgICAgW3NuaXBdDQpUaGUgcXVlc3Rpb24gaXMgaWYg dGhlIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBwcnVuZXMgZGFuZ2xpbmcvdW51c2VkIG9iamVjdHMg d2hlbiA8aW50ZW5kZWQ+IGlzIGFwcGxpZWQsIHVwZGF0aW5nIDxvcGVyYXRpb25hbD4uICBNeSBh c3N1bXB0aW9uIGlzIHRoYXQgdGhlIHNlcnZlciB3aWxsIGRpc2NhcmQgYW55IG9iamVjdCB0aGF0 IGRvZXNu4oCZdCBhY3R1YWxseSBpbXBhY3QgdGhlIHJ1bm5pbmcgY29uZmlndXJhdGlvbiBvZiB0 aGUgc3lzdGVtIChpLmUuLCB2YWx1ZXMgYXJlIGNvbnN1bWVkIGJ5IHRoZSB1bmRlcmx5aW5nIG9w ZXJhdGluZyBzeXN0ZW0sIGRyaXZlcnMsIGV0Yy4pLiAgVGh1c2x5LCBpdCBpcyBteSBvcGluaW9u IHRoYXQgb25seSB0aGUgcmVmZXJlbmNlZCBvYmplY3RzIGFyZSBhcHBsaWVkLiAgSGVuY2Ugd2h5 LCB0byBhbnN3ZXIgeW91ciBsYXN0IHF1ZXN0aW9uLCBJIHdyb3RlIHRoYXQgdGhlc2UgY29uZmln dXJhdGlvbnMgKG1hbnVmYWN0dXJlci1kZWZpbmVkIG9iamVjdHMpIGFyZSBub3QgYXBwbGllZCBp bW1lZGlhdGVseSBidXQgb25seSBhZnRlciB0aGV5IGFyZSByZWZlcmVuY2VkLiAgTWFrZXMgc2Vu c2U/DQpbUWl1ZmFuZyBNYV0gWWVzLCB0cnkgdG8gc3VtIHVwIG91ciBkaXNjdXNzaW9uIGFib3V0 IHRoZSBjYXRlZ29yaWVzIG9mIHRoZSBzeXN0ZW0gY29uZmlndXJhdGlvbjoNCg0KwrcgICAgICAg ICBQaHlzaWNhbC1yZXNvdXJjZS1kZXBlbmRlbnQtLT4gd2hldGhlciB0aGlzIHNvcnQgb2Ygc3lz dGVtIGNvbmZpZ3VyYXRpb24gZXhpc3RzIGluIDxzeXN0ZW0+IGRlcGVuZGVudHMgb24gaWYgdGhl IHBoeXNpY2FsIHJlc291cmNlIGlzIHByZXNlbnQoZS5nLiwgcGh5c2ljYWwgaW50ZXJmYWNlKS4N Cg0KwrcgICAgICAgICBQaHlzaWNhbC1yZXNvdXJjZS1pbmRlcGVuZGVudC0tPndoaWNoIGlzIHBy b3ZpZGVkIGJ5IHRoZSBkZXZpY2Ugc3lzdGVtDQoNCm8gICBGdXJ0aGVyIGNsYXNzaWZpY2F0aW9u IGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIOKAnGFwcGxpZWTigJ0gdGltZShkZXBlbmRlbnRzIG9u IHdoZXRoZXIgdGhlIHN5c3RlbSBjb25maWd1cmF0aW9uIGltcGFjdHMgdGhlIHJ1bm5pbmcgb2Yg dGhlIHN5c3RlbSkNCg0KwqcgIENvbmZpZyB0aGF0IGlzIGFwcGxpZWQgaW1tZWRpYXRlbHkoZS5n LiwgdGhlIGxvb3BiYWNrLCB0aGUgcHJlZGVmaW5lZCBtaW5pbXVtIGxlbmd0aCBvZiBwYXNzd29y ZOKApikNCg0KwqcgIENvbmZpZyB0aGF0IGlzIGFwcGxpZWQgb25seSBhZnRlciBiZWluZyByZWZl cmVuY2VkIGJ5IG90aGVyIGNvbmZpZ3MoZS5nLCBkZWZpbml0aW9ucyBmb3IgYXBwbGljYXRpb25z IGZ0cC90ZnRw4oCmKQ0KDQpvICAgRnVydGhlciBjbGFzc2lmaWNhdGlvbiBmcm9tIHRoZSBwZXJz cGVjdGl2ZSBvZiBnZW5lcmF0aW9uIHRpbWUNCg0KwqcgIENvbmZpZyB0aGF0IGlzIGdlbmVyYXRl ZCB1bmNvbmRpdGlvbmFsbHkgYXQgZWFjaCBib290IHRpbWUoZS5nLCBsb29wYmFjaywgcHJlZGVm aW5lZCBtaW5pbXVtIGxlbmd0aCBvZiBwYXNzd29yZCwgZnRwL3RmdHDigKYpDQoNCsKnICBDb25m aWcgdGhhdCBpcyBnZW5lcmF0ZWQgY29uZGl0aW9uYWxseSBkdXJpbmcgdGhlIGRldmljZSBydW5u aW5nKGUuZy4sIHN5c3RlbS1nZW5lcmF0ZWQgbG9jYWwtcG9ydCBhbmQgcmVtb3RlLXBvcnQgZm9y IGEgbmV3IGVzdGFibGlzaGVkIEJHUCBjb25uZWN0aW9uKQ0KDQpLZWVwIGluIG1pbmQgdGhhdCB3 aGF0IGlzIGRlc2NyaWJlZCBhYm92ZSBpcyBqdXN0IG9uZSBhc3BlY3Qgb2Ygd2hhdCBjYW4gYmUg aW4gPHN5c3RlbT4uICBJbiBhZGRpdGlvbiB0byBkZWZpbmluZyByZWZlcmVuY2UtYWJsZSBvYmpl Y3RzLCA8c3lzdGVtPiBjYW4gYWxzbyBkZWZpbmUvYXBwbHkgY29uZmlndXJhdGlvbiBpbW1lZGlh dGVseSAoZS5nLiwgdGhlIGxvb3BiYWNrIGludGVyZmFjZSkuICBUaGF0IGlzLCBjb25maWd1cmF0 aW9uIG5vdCBkb2VzIG5vdCBoYXZlIHRvIGJlIHJlZmVyZW5jZWQgaW4gb3JkZXIgdG8gYmVjb21l IGFjdGl2YXRlZC4NCltRaXVmYW5nIE1hXSBOb3RlZC4NCg0KDQoNCg0KDQpOb3RlIHRoYXQsIDxy dW5uaW5nPiBieSBpdHNlbGYgd291bGQgbm90IHBhc3MgdmFsaWRhdGlvbiwgZHVlIHRvIG1pc3Np bmcgbGVhZnJlZnMuICBUaGFua2Z1bGx5LCBOTURBIG5ldmVyIHNheXMgdGhhdCB2YWxpZGF0aW9u IHJ1bnMgb24gPHJ1bm5pbmc+LiAgQnV0IG9uY2UgPHJ1bm5pbmc+IGFuZCA8c3lzdGVtPiBoYXZl IGJlZW4gbWVyZ2VkLCB0byBiZWNvbWUgPGludGVuZGVkPiwgdGhlIHJlc3VsdCBkb2VzIHBhc3Mg dmFsaWRhdGlvbi4NCg0KIFtRaXVmYW5nIE1hXSBUaGUgcmVmZXJlbmNlZCBpbnN0YW5jZSBtdXN0 IGFsc28gZXhpc3QgZm9yIHRoZSBkYXRhIHRvIGJlIHZhbGlkIHNpbmNlIHRoZSByZXF1aXJlLWlu c3RhbmNlIGRlZmF1bHRzIHRvIHRydWUgaWYgbm90IHByZXNlbnQuIElzIHRoaXMgd2hhdCB5b3Ug aGFkIGluIHlvdXIgbWluZD8gWWVzLCBOTURBIHNheXMgdGhhdCBpdCBpcyA8aW50ZW5kZWQ+IHdo aWNoIGlzIHN1YmplY3QgdG8gdmFsaWRhdGlvbi4gQnV0IEkgYWxzbyBub3RpY2UgdGhhdCBJbiBz ZWN0aW9uIDUuMS4zIG9mIHRoZSBOTURBOuKAnTxydW5uaW5nPiBNVVNUIGFsd2F5cyBiZSBhIHZh bGlkIGNvbmZpZ3VyYXRpb24gZGF0YSB0cmVlLCBhcyBkZWZpbmVkICBpbiBTZWN0aW9uIDguMSBv ZiBbUkZDNzk1MF0uIOKAnSBTbyBteSB0aG91Z2h0IGhlcmUgaXMgdGhhdCA8cnVubmluZz4gc2hv dWxkIGFsc28gY29uZm9ybSB0byB0aGUgWUFORyBtb2RlbCBjb25zdHJhaW50cyBhbmQgdGhhdOKA mXMgdG8gc2F5LCBhIHJlZmVyZW5jZWQgc3lzdGVtLWRlZmluZWQgZGF0YSBpdGVtIHNob3VsZCBh bHNvIGV4aXN0cyBpbiA8cnVubmluZz4uDQoNClRoZXJlZm9yZSwgaWYgc3lzdGVtIGNvbmZpZ3Vy YXRpb25zIGRvIG5vdCBleGlzdCBpbiA8cnVubmluZz4sIHRoZXkgc3RpbGwgbmVlZCB0byBiZSAg Y29uZmlndXJlZCBpbiA8cnVubmluZz4gbWFudWFsbHkgaW4gb3JkZXIgZm9yIGJlaW5nIHJlZmVy ZW5jZWQuIEluIHRoaXMgY2FzZSwgdGhlIG9yaWdpbmFsIHB1cnBvc2Ugb2YgcHJlZGVmaW5pbmcg c29tZSBzeXN0ZW0gY29uZmlndXJhdGlvbnMgZm9yIHVzZXIgY29udmVuaWVuY2UgaXMgbG9zdC4g VGhpcyBpcyB0aGUgcmVhc29uIHdoeSB3ZSB3b3VsZCBsaWtlIHRvIGRlZmluZSBzb21lIG1lY2hh bmlzbSBoZXJlIHRvIHN5bmNocm9uaXplIDxzeXN0ZW0+IGludG8gPHJ1bm5pbmc+Lg0KDQoNCkkg c2VlIGluIFJGQyA4MzQyICI8cnVubmluZz4gTVVTVCBhbHdheXMgYmUgYSB2YWxpZCBjb25maWd1 cmF0aW9uIGRhdGEgdHJlZSwgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDguMSBvZiBbUkZDNzk1MF3i gJ0uDQoNCkJ1dCB0aGUgcXVlc3Rpb24gcmVtYWlucyBpZiBpdCBpcyBwb3NzaWJsZSBmb3IgdGhl IHN5c3RlbSBpcyBhYmxlIHRvIHZhbGlkYXRlIDxydW5uaW5nPiB3aXRob3V0LCBlLmcuLCBleHBh bmRpbmcgdGVtcGxhdGVzLiAgVGhlcmUgbWF5IGJlIGEgJ2xlYWZyZWYnIG9yIOKAmG11c3TigJkg ZXhwcmVzc2lvbiBzb21ld2hlcmUgdGhhdCB3aWxsIGZhaWwgYmVjYXVzZSB0aGUgZXZhbHVhdGlv biBvY2N1cnMgd2l0aG91dCBleHBhbmRpbmcgYSB0ZW1wbGF0ZSB0aGF0IHN1cHBsaWVzIHRoZSBt aXNzaW5nIHBhcnRzLg0KW1FpdWZhbmcgTWFdIE9uIGNvbmRpdGlvbiB0aGF0IDxydW5uaW5nPiBz aG91bGQgYmUgdmFsaWQsIHRoZSBvcGVyYXRvcnMgd2lsbCBuZWVkIHRvIHJldHJpZXZlIGZyb20g dGhlIDxpbnRlbmRlZD4gb3IgPG9wZXJhdGlvbmFsPiB0byBnZXQgdGhlIHRlbXBsYXRlLWV4cGFu ZGVkIGNvbmZpZ3VyYXRpb25zIGFuZCB0aGVuIGNyZWF0ZSB0aGVtIGluIHRoZSA8cnVubmluZz4s IHJpZ2h0Pw0KTXkgZmVlbGluZyBpcyB0aGF0IGl0IGxvc2VzIHRoZSBtZWFuaW5nIG9mIHByZWRl ZmluaW5nIGFuZCBzZWVtcyBubyBkaWZmZXJlbmNlcyBiZXR3ZWVuIG9wZXJhdG9yLWRlZmluZWQg Y29uZmlndXJhdGlvbnMgaWYgb3BlcmF0b3JzIGhhdmUgdG8gY3JlYXRlIHN5c3RlbSBjb25maWd1 cmVzIGluIDxydW5uaW5nPiBiZWZvcmUgdGhleSB1c2UgdGhlbS4gU28gSSBhbSBiZWdpbm5pbmcg dG8gdGhpbmssIGlmIGl04oCZcyBwb3NzaWJsZSB0byBleHBhbmQgdGhlIHN5c3RlbS1kZWZpbmVk IHRlbXBsYXRlIGR1cmluZyB0aGUgY29weWluZyBiZXR3ZWVuIDxzeXN0ZW0+IGFuZCA8cnVubmlu Zz4/DQoNCklmIHRoaXMgZHJhZnQg4oCcdXBkYXRlc+KAnSBSRkMgODM0MiAoTk1EQSksIHRoZW4g aXQgY2FuIHN1cHBseSBhIGNsYXJpZnlpbmcgc3RhdGVtZW50IGFib3V0IHdoYXQgaXQgbWVhbnMg dGhhdCAiPHJ1bm5pbmc+IE1VU1QgYWx3YXlzIGJlIGEgdmFsaWQgY29uZmlndXJhdGlvbiBkYXRh IHRyZWXigJ0uICBFaXRoZXIgdGhhdCwgb3IgYW4gRXJyYXRhIGlmIGl04oCZcyBkZXRlcm1pbmVk IHRoYXQgdGhlIHN0YXRlbWVudCBpc27igJl0IGNvcnJlY3QuDQoNCllvdSBtYWtlIGEgZ29vZCB0 ZWNobmljYWwgcG9pbnQsIGJ1dCBJIHRoaW5rIHRoYXQgd2Ugc2hvdWxkICp3YW50KiB0byBhdm9p ZCBoYXZpbmcgdG8gY29weSA8c3lzdGVtPiAob3IgPG9wZXJhdGlvbmFsPikgY29uZmlndXJhdGlv biBpbnRvIDxydW5uaW5nPiBpZiB3ZSBjYW4gYXZvaWQgaXQuICBBZ3JlZWQ/DQpbUWl1ZmFuZyBN YV0gdGVuZCB0byBhZ3JlZS4gTWF5YmUgd2Ugc2hvdWxkIHRyeSB0byBhdm9pZCBpdCwgdW5sZXNz IHdlIGhhdmUgdG8uDQoNCkZXSVcsIGFsc28gaW4gUkZDIDgzNDIsIFNlY3Rpb24gNS4xLjQuOg0K DQoNCiAgIDxpbnRlbmRlZD4gaXMgdGlnaHRseSBjb3VwbGVkIHRvIDxydW5uaW5nPi4gIFdoZW5l dmVyIGRhdGEgaXMgd3JpdHRlbg0KDQogICB0byA8cnVubmluZz4sIHRoZSBzZXJ2ZXIgTVVTVCBh bHNvIGltbWVkaWF0ZWx5IHVwZGF0ZSBhbmQgdmFsaWRhdGUNCg0KICAgPGludGVuZGVkPi4NCg0K DQoNCiAgIDxpbnRlbmRlZD4gTUFZIGFsc28gYmUgdXBkYXRlZCBpbmRlcGVuZGVudGx5IG9mIDxy dW5uaW5nPiBpZiB0aGUNCg0KICAgZWZmZWN0IG9mIGEgY29uZmlndXJhdGlvbiB0cmFuc2Zvcm1h dGlvbiBjaGFuZ2VzLCBidXQgPGludGVuZGVkPiBNVVNUDQoNCiAgIGFsd2F5cyBiZSBhIHZhbGlk IGNvbmZpZ3VyYXRpb24gZGF0YSB0cmVlLCBhcyBkZWZpbmVkIGluIFNlY3Rpb24gOC4xPGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjNzk1MCNzZWN0aW9uLTguMT4NCg0K ICAgb2YgW1JGQzc5NTBdPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZj Nzk1MCNzZWN0aW9uLTguMT4uDQoNCg0KDQoNCg0KDQoNCg0KPiBJIGFtIHdvbmRlcmluZyBpZiB0 aGVzZSBjb25maWd1cmF0aW9uIHdpbGwgcHJlc2VudCBpbiB0aGUgPG9wZXJhdGlvbmFsPiAod2hp Y2ggY29udGFpbnMgYWxsIHRoZSBjb25maWd1cmF0aW9uIGFjdHVhbGx5IHVzZWQgYnkgdGhlIGRl dmljZSkgYmVmb3JlIHRoZXnigJlyZSByZWZlcmVuY2VkLg0KDQoNCg0KSSB0aGluayB0aGF0IGl0 IHdvdWxkIGRlcGVuZCBpbiB0aGUgc3BlY2lmaWMgc2VydmVy4oCZcyBiZWhhdmlvciwgcmVnYXJk aW5nIGlmICp1bnVzZWQqIHByZWRlZmluZSBvYmplY3RzIGFyZSBwcmVzZW50IGluIDxvcGVyYXRp b25hbD4uICBDZXJ0YWlubHkgdGhlIHVudXNlZCBvYmplY3RzIHdvdWxkIG5vdCBoYXZlIHRvIGJl IHByZXNlbnQgaW4gPG9wZXJhdGlvbmFsPi4gIElmIEkgd2VyZSBpbXBsZW1lbnRpbmcgdGhlIHNl cnZlciwgdGhlIHVudXNlZCBvYmplY3RzIHdvdWxkIE5PVCBiZSBwcmVzZW50IGluIDxvcGVyYXRp b25hbD4uDQoNCltRaXVmYW5nIE1hXSBZZXMsIGlmIHRoZSBwcmVkZWZpbmVkIHN5c3RlbSBjb25m aWd1cmF0aW9ucyBpcyB1bnVzZWQsIHRoZW4gSSBhbHNvIHRlbmQgdG8gYWdyZWUgdGhhdCB0aGV5 IHdvdWxkIG5vdCBiZSBwcmVzZW50IGluIDxvcGVyYXRpb25hbD4gYnV0IG1heSBhbHNvIGRlcGVu ZCBvbiB0aGUgdmVuZG9yIGltcGxlbWVudGF0aW9uLg0KDQoNCll1cCwgdGhpcyBpcyB0aGUgc2Ft ZSBjb25jbHVzaW9uIGlzIGluIG15IHJlc3BvbnNlIGFib3ZlLg0KW1FpdWZhbmcgTWFdIDopDQoN Cg0KDQoNCg0KPiBJdCB3b3VsZCBiZSBnb29kIGlmIHdlIGNvdWxkIGRldGVybWluZSBpZiB0aGVy ZSBhcmUgYW55IG90aGVyICJyZXNvdXJjZS1pbmRlcGVuZGVudOKAnSBjb25maWd1cmF0aW9uIGNh dGVnb3JpZXMgaGVyZS4NCg0KPiBbUWl1ZmFuZyBNYV0gRG8geW91IHRoaW5rIHRoZXJlIGV4aXN0 cyBjb25kaXRpb25hbCBzeXN0ZW0gY29uZmlndXJhdGlvbiAoaWYgdGhlIHByZWNlZGluZyBjb25m aWd1cmF0aW9ucyB5b3UgbWVudGlvbmVkIGFib3ZlIGlzIG5vdCk/IEZvciBleGFtcGxlLCBpZiBT U0ggaXMgZW5hYmxlZCBvbiBhIGRldmljZSwgU1NILXJlbGF0ZWQga2V5cyBhcmUgYXV0b21hdGlj YWxseSBnZW5lcmF0ZWQuIFN1Y2ggY29uZmlndXJhdGlvbnMgYXJlIGdlbmVyYXRlZCBhdCB0aGUg bW9tZW50IHdoZW4gYSBzcGVjaWFsIGZ1bmN0aW9uYWxpdHkgaXMgZW5hYmxlZC4NCg0KDQoNCkni gJltIHVuc3VyZSB3aGF0IHlvdSBtZWFuIGluIGdlbmVyYWwgYnkgImNvbmRpdGlvbmFsIGNvbmZp Z3VyYXRpb27igJ0sIGJ1dCBJIGNhbiBzcGVhayB0byB5b3VyIHNwZWNpZmljIGV4YW1wbGUuIFRo b3VnaCBJIG11c3QgcHJlZmFjZSBteSBjb21tZW50cyB0aGF0IEkgaW1hZ2luZSB0aGVyZSBhcmUg YSBudW1iZXIgb2Ygd2F5cyBzZXJ2ZXJzIG1pZ2h0IGdvIGFib3V0IGVuYWJsaW5nIGBzc2hkYC4g IFdoYXQgZm9sbG93cyBpcyBteSBwZXJzb25hbCB2aWV3LCBmb3JnZWQgYnkgYmVpbmcgYXJvdW5k IHN5c3RlbXMgZm9yIGF3aGlsZSAgOykNCg0KDQoNCkluIGdlbmVyYWw6DQoNCg0KDQogICAgICAg ICAtIGBzc2hkYCBpcyBOT1QgZW5hYmxlZCBieSBkZWZhdWx0Lg0KDQogICAgICAgICAtIGBzc2hk YCBpcyBlbmFibGVkIHZpYSBhIGNvbmZpZ3VyYXRpb24ga25vYi4NCg0KICAgICAgICAgLSB0aGUg U1NIIGhvc3Qga2V5IGlzIGR5bmFtaWNhbGx5IGdlbmVyYXRlZCB0aGUgZmlyc3QgdGltZSBgc3No ZGAgaXMgZW5hYmxlZC4NCg0KICAgICAgICAgLSB0aGUgU1NIIGhvc3Qga2V5IGl0c2VsZiBpcyBp biA8b3BlcmF0aW9uYWw+IChub3QgPHJ1bm5pbmc+KQ0KDQoNCg0KVGhpcyB2aWV3IGlzIGNvbnNp c3RlbnQgd2l0aCB0aGUgZmlyc3QgcGFyYWdyYXBoIGluIFNlY3Rpb24gMyBvZiB0aGUg4oCca2V5 c3RvcmXigJ0gZHJhZnQgKHJlcHJvZHVjZWQgYmVsb3cpOg0KDQoNCg0KICAgICAgICAgMy4gIFN1 cHBvcnQgZm9yIEJ1aWx0LWluIEtleXMNCg0KDQoNCiAgICAgICAgICAgIEluIHNvbWUgaW1wbGVt ZW50YXRpb25zLCBhIHNlcnZlciBtYXkgc3VwcG9ydCBidWlsdC1pbiBrZXlzLiAgQnVpbHQtDQoN CiAgICAgICAgICAgIGluIGtleXMgTUFZIGJlIHNldCBkdXJpbmcgdGhlIG1hbnVmYWN0dXJpbmcg cHJvY2VzcyBvciBiZSBkeW5hbWljYWxseQ0KDQogICAgICAgICAgICBnZW5lcmF0ZWQgdGhlIGZp cnN0IHRpbWUgdGhlIHNlcnZlciBpcyBib290ZWQgb3IgYSBwYXJ0aWN1bGFyIHNlcnZpY2UNCg0K ICAgICAgICAgICAgKGUuZy4sIFNTSCkgaXMgZW5hYmxlZC4NCg0KDQoNCkFzIGEgY2xvc2luZyB0 aG91Z2h0LCB0aGlzIG1vZGVsICh3aGljaCBJIHN0YXRlZCB1cGZyb250IG1heSBub3QgYmUgdW5p dmVyc2FsKSB3b3VsZCBoYXZlIG5vIHByZXNlbmNlLWluIG9yIGludGVyYWN0aW9uLXdpdGggPHN5 c3RlbT7igKZ0aG91Z2gsIHBlcmhhcHMsIHRoZXJlIG1heSBiZSBzb21lIHByZWRlZmluZWQgdmFs dWVzIGZvciB3aGF0IGtleS1hbGdvcml0aG1zIGFuZC9vciBrZXktbGVuZ3RocyB0byB1c2Ugd2hl biBnZW5lcmF0aW5nIHRoZSBTU0ggaG9zdCBrZXkuLi4NCg0KW1FpdWZhbmcgTWFdIEJ5IOKAnGNv bmRpdGlvbmFsIHN5c3RlbSBjb25maWd1cmF0aW9u4oCdLCBJIHdhcyBtZWFuaW5nIHNvbWUgb2Yg dGhlIHN5c3RlbSBjb25maWd1cmF0aW9ucyBhcmUgbm90IGdlbmVyYXRlZCBpbW1lZGlhdGVseSBh ZnRlciB0aGUgZGV2aWNlIGlzIHBvd2VyZWQgb24uIEluc3RlYWQsIHRoZXkgYXJlIGdlbmVyYXRl ZCB3aGVuIGEgc3BlY2lmaWMgY29uZGl0aW9uIGlzIHNhdGlzZmllZCBkdXJpbmcgdGhlIGRldmlj ZSBydW5uaW5nKGUuZy4sIGEgZnVuY3Rpb25hbGl0eSBpcyBlbmFibGVkIGR1ZSB0byBzb21lIGNs aWVudCBjb25maWd1cmF0aW9ucykuIEkgYW0gbm90IHN1cmUgaWYgaXQgcmVhbGx5IGV4aXN0cywg bWF5YmUgbm90LCBqdXN0IHRyeSB0byBleHBsb3JlIHRoZSBwb3NzaWJpbGl0aWVzIG9mIHZhcmlv dXMgcmVzb3VyY2UtaW5kZXBlbmRlbnQgc3lzdGVtIGNvbmZpZ3VyYXRpb25zLjopDQoNClRvIHRo aXMgcG9pbnQgSSBhZ3JlZS4uYXMgZG9lcyBSRkMgODM0MiAoTk1EQSksIFNlY3Rpb24gNS4zLjMu Og0KDQoNCiAgIFNvbWV0aW1lcywgcmVzb3VyY2VzIGFyZSBjb250cm9sbGVkIGJ5IHRoZSBkZXZp Y2UgYW5kIHRoZQ0KDQogICBjb3JyZXNwb25kaW5nIHN5c3RlbS1jb250cm9sbGVkIGRhdGEgYXBw ZWFycyBpbiAoYW5kIGRpc2FwcGVhcnMgZnJvbSkNCg0KICAgPG9wZXJhdGlvbmFsPiBkeW5hbWlj YWxseS4gIElmIGEgc3lzdGVtLWNvbnRyb2xsZWQgcmVzb3VyY2UgaGFzDQoNCiAgIG1hdGNoaW5n IGNvbmZpZ3VyYXRpb24gaW4gPGludGVuZGVkPiB3aGVuIGl0IGFwcGVhcnMsIHRoZSBzeXN0ZW0g d2lsbA0KDQogICB0cnkgdG8gYXBwbHkgdGhlIGNvbmZpZ3VyYXRpb247IHRoaXMgY2F1c2VzIHRo ZSBjb25maWd1cmF0aW9uIHRvDQoNCiAgIGFwcGVhciBpbiA8b3BlcmF0aW9uYWw+IGV2ZW50dWFs bHkgKGlmIGFwcGxpY2F0aW9uIG9mIHRoZQ0KDQogICBjb25maWd1cmF0aW9uIHdhcyBzdWNjZXNz ZnVsKS4NCg0KW1FpdWZhbmcgTWFdIFNlZSBhYm92ZSwgYXMgSSBzdW1tYXJpemVkIGFzIHRoZSBz eXN0ZW0gY29uZmlndXJhdGlvbnMgdGhhdCBpcyBnZW5lcmF0ZWQgY29uZGl0aW9uYWxseSBkdXJp bmcgdGhlIGRldmljZSBydW5uaW5nLg0KDQoNCg0KRmlyc3RseSwgSSBhZ2FpbiBoYXZlIHRvIHBy ZWZhY2UgbXkgY29tbWVudCB0aGF0IHRoZXJlIGFyZSBsaWtlbHkgbWFueSB3YXlzIHRoYXQgdGVt cGxhdGluZyBtZWNoYW5pc21zIGNhbiBiZSBkZWZpbmVkLiAgICBCdXQsIGluIGdlbmVyYWwsIG9u Y2UgYSB0ZW1wbGF0aW5nIG1lY2hhbmlzbSBoYXMgYmVlbiBkZWZpbmVkLCB0aGVuIGl0IHN0YW5k cyB0byByZWFzb24gdGhhdCB0ZW1wbGF0ZXMgY291bGQgYmUgZGVmaW5lZCBlaXRoZXIgaW4gPHJ1 bm5pbmc+IChieSBvcGVyYXRvcnMpIG9yIGluIDxzeXN0ZW0+IChieSB0aGUgbWFudWZhY3R1cmVy KS4gIEluIG9uZSBpbXBsZW1lbnRhdGlvbiBJ4oCZbSBmYW1pbGlhciB3aXRoLCB0aGUgdGVtcGxh dGVzIGFyZSBvYmplY3RzIHRoYXQgYXJlIHJlZmVyZW5jZWQvcGFyYW1ldGVyaXplZCBieSBvdGhl ciBwYXJ0cyBvZiB0aGUgY29uZmlndXJhdGlvbi4gIChTYW1lIGFzIHdpdGggdGhlIHByZWRlZmlu ZWQgb2JqZWN0cyBkaXNjdXNzaW9uIGFib3ZlLikNCg0KDQoNClRvIGFuc3dlciB5b3VyIHF1ZXN0 aW9uczoNCg0KDQoNCjEpIFllcywgaXQgaXMgbXkgb3BpbmlvbiB0aGF0ICphY3RpdmF0ZWQqIHRl bXBsYXRlcyBpbiA8c3lzdGVtPiB3aWxsIGJlIGV4cGFuZGVkIGFuZCBwcmVzZW50IGluIDxpbnRl bmRlZD4uDQoNCg0KDQoyKSBJIHdvdWxkIG5ldmVyIHN1Z2dlc3QgdGhhdCB0aGUgc3lzdGVtLWRl ZmluZWQgdGVtcGxhdGVzIGFyZSBwcmVzZW50IGluIDxydW5uaW5nPiwgdGhvdWdoIHRoZXkgbWF5 IGJlIHJlZmVyZW5jZWQvcGFyYW1ldGVyaXplZCBieSBjb25maWcgaW4gPHJ1bm5pbmc+Lg0KDQoN Cg0KMykgaWYgYSBjb25maWctdGVtcGxhdGUgaXMgY29uZmlndXJlZCBpbiA8cnVubmluZz4gKGku ZS4sIGl0IGlzIG9wZXJhdG9yLWRlZmluZWQpIHRoZW4sIHllcywgdGhlIGV4cGFuZGVkIGNvbmZp Z3VyYXRpb24gaW4gPGludGVuZGVkPiBpcyAiY2xpZW50IGNvbmZpZ3VyYXRpb27igJ0gKG5vdGUs ICJjbGllbnQgY29uZmlndXJhdGlvbuKAnSBpcyBub3QgYSBmb3JtYWwgdGVybSkuICBUaGF0IHNh aWQsIGl0IHNlZW1zIGZhaXIgdG8gc2F5IHRoYXQgYSB0ZW1wbGF0ZSBkZWZpbmVkIGluIDxzeXN0 ZW0+IGFuZCB0aGVuIHJlZmVyZW5jZWQgYnkgImNsaWVudCBjb25maWd1cmF0aW9u4oCdIGluIDxy dW5uaW5nPiBpcyBhbHNvIGV4cGFuZGVkIGFzICJjbGllbnQgY29uZmlndXJhdGlvbuKAnSBpbiA8 aW50ZW5kZWQ+Lg0KDQoNCg0KNCkgSSBkb27igJl0IG5vdCB1bmRlcnN0YW5kIHlvdXIgbGFzdCBz ZW50ZW5jZSwgdGhhdCB0aGUgZXhwYW5zaW9uIG9mIDxzeXN0ZW0+IHRlbXBsYXRlcyBhcmUgb25s eSBwcmVzZW50IGluIDxvcGVyYXRpb25hbD4uICBNYXliZSB5b3XigJlyZSBzYXlpbmcgc29tZXRo aW5nIHN1YnRsZSwgZS5nLiwgdGhhdCBzZXJ2ZXJzIGN1cnJlbnRseSBkb27igJl0IHN1cHBvcnQg R0VUIG9uIDxpbnRlbmRlZD4uICBCdXQsIGluIHRoZW9yeSwgdGhlIGV4cGFuc2lvbiBvZiA8c3lz dGVtPiB0ZW1wbGF0ZXMgc2hvdWxkIChJTU8pIGJlIHByZXNlbnQgaW4gPGludGVuZGVkPiwgc28g dGhhdCB0aGV5IG1heSBiZSBzdWJqZWN0IHRvIHZhbGlkYXRpb24uICAgT2YgY291cnNlLCBhbGwg dGhlIDxpbnRlbmRlZD4gY29uZmlndXJhdGlvbiAod2hldGhlciBvcmlnaW5hdGluZyBpbiA8cnVu bmluZz4gb3IgPHN5c3RlbT4pIHRoYXQgaXMgc3VjY2Vzc2Z1bGx5IOKAnGFwcGxpZWTigJ0gd2ls bCBhbHNvIGJlIHByZXNlbnQgaW4gPG9wZXJhdGlvbmFsPi4NCg0KW1FpdWZhbmcgTWFdIEFzc3Vt ZSB0aGF0IHRoZXJlIGlzIG5vIDxzeXN0ZW0+IGFuZCB0aGlzIHdvcmssIHRoZSBleHBhbnNpb24g b2Ygc3lzdGVtIHRlbXBsYXRlcyBhcmUgb25seSBwcmVzZW50IGluIDxvcGVyYXRpb25hbD4uIEJl Y2F1c2UgdGhpcyBpcyBjb21wYXRpYmxlIHdpdGggc3lzdGVtIGNvbmZpZ3VyYXRpb24gZGVmaW5p dGlvbiBpbiBOTURBLg0KDQpCdXQgaWYgc3lzdGVtIGNvbmZpZ3VyYXRpb25zIGFyZSBvbmx5IHBy ZXNlbnQgaW4gPG9wZXJhdGlvbmFsPiwgdGhlIHByZWRlZmluZWQgc3lzdGVtIGNvbmZpZ3VyYXRp b25zIHN0aWxsIG5lZWQgdG8gYmUgcmV0cmlldmVkIGFuZCBjcmVhdGVkIGludG8gPHJ1bm5pbmc+ IGV4cGxpY2l0bHkgd2hlbiBiZWluZyByZWZlcmVuY2VkLiBJIHRoaW5rIHdl4oCZdmUgcmVhY2hl ZCBhbiBhZ3JlZW1lbnQgb24gdGhlIG5lZWQgZm9yIDxzeXN0ZW0+IHRvIGV4aXN0LCBhbmQgb3Vy IG1haW4gcG9pbnQgb2YgZGlzYWdyZWVtZW50IGlzIHdoZXRoZXIgPHN5c3RlbT4gc2hvdWxkIGJl IGNvcGllZCBpbnRvIDxydW5uaW5nPi4gWW91ciBwb2ludCBpcyB0aGF0IGJlaW5nIG1lcmdlZCBp bnRvIDxpbnRlbmRlZD4gaXMgZW5vdWdoIHRvIG1ha2Ugc3VyZSBhIHN1Y2Nlc3MgdmFsaWRhdGlv bi4gQnV0IG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgcmVmZXJlbmNlZCBzeXN0ZW0gY29u ZmlndXJhdGlvbiBkYXRhIGl0ZW0gbXVzdCBhbHNvIGV4aXN0IGluIHRoZSA8cnVubmluZz4gdG8g b2JleSB0aGUgbW9kZWwgY29uc3RyYWludHMuDQoNClllcywgSSBiZWxpZXZlIHRoYXQgeW91IHBy b3ZpZGVkIGFuIGFjY3VyYXRlIGRlc2NyaXB0aW9uIG9mIHRoZSBkaWZmZXJlbmNlIGluIG91ciBv cGluaW9ucy4gIFBlciBteSBlYXJsaWVyIHJlc3BvbnNlLCB5b3UgbWFrZSBhIHZhbGlkIHRlY2hu aWNhbCBwb2ludCwgbXkgZ29hbCBpcyB0byB3YWl2ZSB0aGF0IGludGVycHJldGF0aW9uIHRvIHRo ZSBzaWRlIHNvIHRoYXQgYSBzaW1wbGVyIHNvbHV0aW9uIGNhbiBlbWVyZ2UuICBJdCB3b3VsZCBi ZSBnb29kIHRvIGdldCBvdGhlciBvcGluaW9ucyBvbiBsaXN0LCBvdGhlcndpc2Ugd2XigJlsbCB0 YWtlIGl0IGludG8gdGhlIG1lZXRpbmcuDQpbUWl1ZmFuZyBNYV0gT0suICBIb3BlZnVsbHkgc29t ZW9uZSBlbHNlIHdvdWxkIHNoYXJlIHNvbWUgb3BpbmlvbnMgaGVyZS4gT3RoZXJ3aXNlIGxldOKA mXMgdGFrZSB0aGlzIGludG8gdGhlIElFVEYgbWVldGluZy4NCg0KW0JUVywgaW4ga2VlcGluZyB3 aXRoIHRoaXMgdGhyZWFkIG1vdmluZyBmcm9tIHRoZSBORVRDT05GIHRvIHRoZSBORVRNT0QgbWFp bGluZyBsaXN0cywgd291bGQgaXQgbWFrZSBzZW5zZSB0byBtb3ZlIHRoZSBJRVRGIDExMSBwcmVz ZW50YXRpb24gc2xvdCBmcm9tIE5FVENPTkYgdG8gTkVUTU9EIHRvbz8gIEkgdGhpbmsgaXQgZG9l cyBhbmQsIGZ1cnRoZXIsIGl0IHdvdWxkIGhlbHAgd2l0aCBzY2hlZHVsaW5nIChORVRDT05GIGlz IG92ZXIsIE5FVE1PRCBpcyB1bmRlcikuICBXb3VsZCB5b3UgYmUgb2theSB3aXRoIHRoaXM/ICAg QUQgUm9iIGFuZCB0aGUgTkVUQ09ORiBjaGFpcnMgZGlzY3Vzc2VkIHRoaXMgbW9ybmluZywgYW5k IHRoaW5rIGl0J3Mgb2theSwgYnV0IHdvdWxkIHN0aWxsIG5lZWQgdG8gY29uZmlybSB3aXRoIHRo ZSBORVRNT0QgY2hhaXJzLl0NCltRaXVmYW5nIE1hXSBJIGFtIGhhcHB5IHdpdGggdGhlIHByb3Bv c2FsLCBpZiBpdOKAmXMgYWxzbyBva2F5IGZvciBORVRNT0QgY2hhaXJzOi0pLiBJIGhhdmUgc2Vu dCBhbiBlbWFpbCB0byB0aGUgTkVUTU9EIGNoYWlycyB0byByZXF1ZXN0IHRvIG1vdmUgdGhpcyBw cmVzZW50YXRpb24gc2xvdCBmcm9tIE5FVENPTkYgdG8gTkVUTU9ELg0KQSBuZXcgdmVyc2lvbiBv ZiB0aGUgZHJhZnQgd2lsbCBhbHNvIGJlIHN1Ym1pdHRlZCB0byBORVRNT0Qgd2hlbiB0aGUgZHJh ZnQtc3VibWl0dGluZyB3aW5kb3cgcmVvcGVucy4NCg0KDQoNCg0KIDxiaWcgc25pcD4NCg0KPiBJ 4oCZbSBiZWdpbm5pbmcgdG8gdGhpbmsgdGhhdDoNCg0KPiDCtyAgICAgICAgIGF1dG8tY29weWlu ZyBpbnRvIDxydW5uaW5nPiBpcyBsaWtlbHkgbmV2ZXIgYSBnb29kIGlkZWEsIGJlY2F1c2UgaXQg dmlvbGF0ZXMgdGhlIGRlZmluaXRpb24gb2YgPHJ1bm5pbmc+DQoNCj4gW1FpdWZhbmcgTWFdIEkg YW0gcXVpdGUgYXdhcmUgdGhhdCBkaWZmZXJlbnQgZGF0YXN0b3JlcyBpbiBOTURBIHJlcHJlc2Vu dHMgZGlmZmVyZW50IHZpZXdzIG9mIGRhdGEgbm9kZXMuICBBbmQgPHJ1bm5pbmc+IHJlcHJlc2Vu dHMgYSBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSBob2xkaW5nIHRoZSBjdXJyZW50IGNvbmZpZ3Vy YXRpb24gb2YgdGhlIGRldmljZS4NCg0KPiBTaG91bGQgd2UgY29uc2lkZXIgc3lzdGVtIGNvbmZp Z3VyYXRpb24gYWxzbyBiZSBwYXJ0IG9mIGN1cnJlbnQgY29uZmlndXJhdGlvbiBvZiB0aGUgZGV2 aWNlPyBGcm9tIG15IHBlcnNwZWN0aXZlLCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHN5c3RlbSBj b25maWd1cmF0aW9uIGFuZCAgY2xpZW50LWNvbmZpZ3VyYXRpb24gbGllcyBvbmx5IGluIHdobyBw cm92aWRlcyBpdC4NCg0KDQoNCjxydW5uaW5nPiBob2xkcyB0aGUgY3VycmVudCAqb3BlcmF0b3It c3BlY2lmaWVkKiBjb25maWd1cmF0aW9uIG9mIHRoZSBkZXZpY2UuICBTeXN0ZW0tcHJvdmlkZWQg Y29uZmlndXJhdGlvbiBpcyBOT1Qgc3BlY2lmaWVkIGJ5IG9wZXJhdG9ycyAodGhvdWdoIHN5c3Rl bS1kZWZpbmVkIG9iamVjdHMgbWF5IGJlIHJlZmVyZW5jZWQgYnkgb3BlcmF0b3Itc3BlY2lmaWVk IGNvbmZpZyBpbiA8cnVubmluZz4pLiAgIEkgYmVsaWV2ZSB0aGF0IHRoaXMgYXJyYW5nZW1lbnQg aXMgY29uc2lzdGVudCB3aXRoIHRoZSBkZWZpbml0aW9uIG9mIDxydW5uaW5nPi4gIEFncmVlZD8N Cg0KW1FpdWZhbmcgTWFdIFllcy4gQWN0dWFsbHkgd2UgYXJlIG5vdCB0cnlpbmcgdG8gdmlvbGF0 ZSB0aGUgcHJpbmNpcGxlcyBvZiBOTURBIGFuZCB0aGUgZGVmaW5pdGlvbiBvZiA8cnVubmluZz4u ICBUaGUgaXNzdWUgd2UgdHJ5IHRvIHJlc29sdmUgaGVyZSBpcyB0aGF0IHN5c3RlbSBjb25maWd1 cmF0aW9ucyBjYW5ub3QgYmUgdXNlZChyZWZlcmVuY2VkIG9yIG92ZXJ3cml0dGVuKSBieSB0aGUg b3BlcmF0b3JzIGRpcmVjdGx5IGFuZCBuZWVkIHRvIGJlIGNyZWF0ZWQgaW50byA8cnVubmluZz4g ZXhwbGljaXRseS4gVGhpcyBhY3R1YWxseSBsb3NlcyB0aGUgbWVhbmluZyBvZiDigJxwcmVkZWZp bmluZyBhbmQgYnJpbmdpbmcgY29udmVuaWVuY2XigJ0uIElmIGF1dG8tY29weWluZyBpcyBub3Qg YSBnb29kIGlkZWEsIHdoYXQgZG8geW91IHRoaW5rIGFib3V0IGRlZmluaW5nIGFuIFJQQyBvcGVy YXRpb24gZm9yIHRoZSBvcGVyYXRvcnMgdG8gZG8gdGhlIGNvcHkod2hpY2ggaXMgYWxzbyB3aGF0 IFJvYiBzdWdnZXN0cyBhdCB0aGUgbWVldGluZyk/DQoNCklmIHdlIGhhdmUgdG8gY29weSBpbnRv IDxydW5uaW5nPiwgdGhlbiBJIHRoaW5rIHRoYXQgSSBhZ3JlZSBhbiBSUEMgKDxlZGl0LWNvbmZp Zz4/KSB3b3VsZCBiZSBiZXR0ZXIuDQpbUWl1ZmFuZyBNYV0gRnJvbSBteSBwZXJzcGVjdGl2ZSwg PGVkaXQtY29uZmlnPiBpcyBmZWFzaWJsZSBidXQgbm90IGVmZmljaWVudCBiZWNhdXNlIG9wZXJh dG9ycyBzdGlsbCBuZWVkIHRvIHJldHJpZXZlIDxzeXN0ZW0+LzxvcGVyYXRpb25hbD4gZmlyc3Rs eS4gSWYgd2UgY291bGQgZGVmaW5lIGEgUlBDIHRvIGNvcHkgdGhlIGVudGlyZSA8c3lzdGVtPiBp bnRvIDxydW5uaW5nPiwgaXQgc2VlbXMgbW9yZSBjb252ZW5pZW50IGZvciBvcGVyYXRvcnMuIEhv d2V2ZXIsIHNvbWUgc3lzdGVtIGNvbmZpZ3VyYXRpb25zIHdoaWNoIGFyZSBub3QgZ29pbmcgdG8g YmUgcmVmZXJlbmNlZCBvciBtb2RpZmllZCBtYXkgYWxzbyBiZSBjb3BpZWQgaW50byA8cnVubmlu Zz4uIEkgZG9uJ3QgaGF2ZSBhIHN0cm9uZyBmZWVsaW5nIGFib3V0IHdoaWNoIG9uZSBpcyBwcmVm ZXJyZWQuIEFueXdheSwgd2UgbmVlZCB0byBmaWd1cmUgb3V0IHdoZXRoZXIgaXQgd291bGQgYmUg ZmluZSBmb3IgPHJ1bm5pbmc+IHRvIG1pc3NpbmcgcmVmZXJlbmNlZCBzeXN0ZW0gY29uZmlndXJh dGlvbnMuDQoNCllvdSBtZW50aW9uIOKAnG92ZXJ3cml0dGVu4oCdIGJ5IHRoZSBvcGVyYXRvcnM/ ICBXaHkgd291bGRu4oCZdCB0aGUgb3BlcmF0b3JzIGp1c3QgZGVmaW5lIHRoZWlyIG93bj8gIEZv ciBpbnN0YW5jZSwgaWYgdGhleSBkb27igJl0IGxpa2UgdGhlIHZlbmRvcuKAmXMg4oCcdmVuZG9y LWZvb2JhcuKAnSBvYmplY3QsIHRoZXkgY291bGQgY29weS9wYXN0ZS9lZGl0IHRoZWlyIG93biDi gJxteS1mb29iYXLigJ0gb2JqZWN0IHdpdGggdGhlIHZhbHVlcyBuZWVkZWQsIHllcz8NCltRaXVm YW5nIE1hXSBZZXMsIGRlZmluaW5nIHRoZWlyIG93biB3b3VsZCBiZSBva2F5LiBCeSBvdmVyd3Jp dGluZywgSSBtZWFuIHNvbWV0aW1lcyB0aGUgb3BlcmF0b3JzIHdvdWxkIGxpa2UgdG8gbW9kaWZ5 IHRoZSBzcGVjaWZpYyBzeXN0ZW0gY29uZmlndXJhdGlvbiwgZS5nLiwgdGhlIE1UVSB2YWx1ZSBv ZiBhIHNwZWNpZmllZCBpbnRlcmZhY2UoaWRlbnRpZmllZCBieSBpdHMgbmFtZSkuDQpJZiB0aGUg b3BlcmF0b3JzIHdhbnQgdG8gbW9kaWZ5IHRoZSBzeXN0ZW0gY29uZmlndXJhdGlvbnMsIHRoZXJl IGlzIG5vIHdheSBidXQgcmVkZWZpbmUgdGhlbSBpbiA8cnVubmluZz4uDQoNCg0KQmVzdCBSZWdh cmRzLA0KUWl1ZmFuZyBNYQ0KDQoNCg0KDQoNCg0KDQoNCg0KPiDCtyAgICAgICAgIGhhdmluZyBp biA8b3BlcmF0aW9uYWw+IGRvZXNu4oCZdCBtYWtlIHNlbnNlLCBzaW5jZSB0aGUgdHdlYWtzIHdv dWxkbuKAmXQgZ28gdGhydSA8cnVubmluZz4gLS0+IDxpbnRlbmRlZD4gdmFsaWRhdGlvbi4NCg0K Pg0KDQo+IEnigJltIHdvbmRlcmluZyBpZiBhIG1vZGVsIGxpa2UgYmVsb3cgd291bGQgd29yayBm b3IgZXZlcnlvbmUgLSB0aG91Z2h0cz8NCg0KPiBbUWl1ZmFuZyBNYV0gPGludGVuZGVkPiByZXBy ZXNlbnRzIHRoZSBjb25maWd1cmF0aW9uIGFmdGVyIGFsbCBjb25maWd1cmF0aW9uIHRyYW5zZm9y bWF0aW9ucyB0byA8cnVubmluZz4gaGF2ZSBiZWVuIHBlcmZvcm1lZCwgc28gSSB0aGluayBpdCBp cyBvbmx5IGNvdXBsZWQgdG8gPHJ1bm5pbmc+Lg0KDQo+IEFueXdheSwgdGhlIDxzeXN0ZW0+IHNo b3VsZCBhbHNvIGludGVyYWN0cyB3aXRoIDxvcGVyYXRpb25hbD4uICBBZ3JlZWQ/DQoNCg0KDQpJ IGRvbuKAmXQgYWdyZWUgdGhhdCA8aW50ZW5kZWQ+IG11c3Qgb25seSBiZSBjb3VwbGVkIHRvIDxy dW5uaW5nPi4gIFNwZWNpZmljYWxseSwgSSB0aGluayB0aGF0IGl0IGlzIG9rYXkgKGNvbXBhdGli bGUgd2l0aCBOTURBKSB0byBkZWZpbmUgYSA8c3lzdGVtPiB0aGF0IGFsc28gaW1wYWN0cyA8aW50 ZW5kZWQ+LiAgIFRoaXMgaXMgdGhlIG9ubHkgKElNTykgc2FuZSBhcHByb2FjaCwgYXMgaXQgZW5h YmxlcyB0aGUgY29tYmluYXRpb24gPHJ1bm5pbmc+ICsgPHN5c3RlbT4gdG8gYmUgdmFsaWRhdGVk Lg0KDQpbUWl1ZmFuZyBNYV0gUGxlYXNlIHNlZSBhYm92ZS4gSWYgPHJ1bm5pbmc+IGlzIE9LIHRv IG1pc3MgcmVmZXJlbmNlZCBzeXN0ZW0gY29uZmlndXJhdGlvbiwgeW91ciBwcm9wb3NhbCBtYWtl cyBzZW5zZSB0byBtZS4NCg0KQWNrLg0KDQoNCg0KDQoNCiBCZXN0IFJlZ2FyZHMsDQoNClFpdWZh bmcgTWENCg0KDQpLZW50IC8vIGNvbnRyaWJ1dG9yDQoNCg== --_000_aa3dfdb471f0430aa50c4e35b9672fb1huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0 UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7 DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBj bTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bh bi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8 jyI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UN Cgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHls ZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTY5NjA3NjI4MTsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTUzNjQ2Mzk4MiA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJn aW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLCBLZW50LA0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBmb3IgaGVscGluZyBtZSByZXZpdmUgdGhpcyB0aHJlYWQs IHdoaWNoIGlzIGV4YWN0bHkgd2hhdCBJIHdhbnQgdG8gZG8uOik8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ VGhlcmUgd2FzIG5vdCBhIHZlcnkgZnVsbHkgZGlzY3Vzc2lvbiBkdWUgdG8gdGltZSBjb25zdHJh aW50cywgYnV0IHdlIGRpZCBzZWUgc29tZSB2YWx1YWJsZSBwb2ludHMgaGVyZSwgdGhhbmsgeW91 IGV2ZXJ5b25lIGZvciBzaGFyaW5nIHlvdXIgdmlld3MuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5SZWdhcmRpbmcgb3B0aW9uMiwgJm5ic3A7SSBhbSBzdGlsbCB1 bnN1cmUgaG93IHdpbGwgdGhpbmdzIGdvIGlmIHRoZXJlIGlzIG5vICZsdDtpbnRlbmRlZCZndDso SSB0aGluayBpdCB3YXMgcmFpc2VkIGJ5IEJhbGF6cywgaG9wZWZ1bGx5IEJhbGF6cyBjYW4gYWxz byBhZGQgc29tZXRoaW5nIGhlcmUpPw0KIFNob3VsZCAmbHQ7c3lzdGVtJmd0OyBiZSBpbXBsZW1l bnRlZCBhbG9uZyB3aXRoICZsdDtpbnRlbmRlZCZndDs/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5PcHRpb24gMyBpcyBzdGlsbCB1bmNsZWFyLCBlLmcuLCB3aGV0 aGVyIHRoZSAmbHQ7c3lzdGVtJmd0OyBpcyBjb3BpZWQgaW50byAmbHQ7cnVubmluZyZndDsgYXV0 b21hdGljYWxseSBvciBtYW51YWxseT8gSWYgYXV0by1jb3B5IGlzIG5vdCBhIGdvb2QgaWRlYSBi ZWNhdXNlIGl0IHZpb2xhdGVzDQogdGhlIGRlZmluaXRpb24gb2YgJmx0O3J1bm5pbmcmZ3Q7LCB3 aGV0aGVyIG1hbnVhbC1jb3B5IGlzIHBlcmZvcm1lZCB0b3dhcmRzIHBhcnQgb3IgYWxsIG9mIHRo ZSBzeXN0ZW0gY29uZmlndXJhdGlvbnMgY3JlYXRlZCBpbiAmbHQ7c3lzdGVtJmd0Oz88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+U2hvdWxkIHdlIGNvcHkgdGhlIGVudGlyZSAmbHQ7c3lzdGVtJmd0OyBpbnRv ICZsdDtydW5uaW5nJmd0Oz8gT3Igc2hvdWxkIHRoZXJlIGJlIGFzIGZldyBzeXN0ZW0gY29uZmln dXJhdGlvbiBkYXRhIGl0ZW1zIGluICZsdDtydW5uaW5nJmd0OyBhcyBwb3NzaWJsZT88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+QW55d2F5LCBJIGFncmVlIHRoYXQgb3B0aW9uMyBtYXkgc3RpbGwgaW5jdXIg YSBmYWlsZWQgdmFsaWRhdGlvbiBvZiAmbHQ7cnVubmluZyZndDsgd2hlbiB0aGUgb3BlcmF0b3Jz IHJlZmVyZW5jZSB0aGUgc3lzdGVtIGNvbmZpZ3VyYXRpb24gd2hpY2ggaXMgcHJvZHVjZWQgdGhy b3VnaA0KIHRoZSBleHBhbnNpb24gb2YgdGhlIHN5c3RlbS1kZWZpbmVkIHRlbXBsYXRlcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SWYgdGhlIGV4aXN0aW5nIG1lY2hhbmlzbShlLmcuLCBlZGl0LWNvbmZp ZylpcyBzdWZmaWNpZW50IHRvIGRlZmluZSByZWZlcmVuY2VkIHN5c3RlbSBkYXRhIGl0ZW0gaW4g Jmx0O3J1bm5pbmcmZ3Q7LCBpdCBzZWVtcyB0aGF0IHRoZSBmbG93IG1hcmtlZCBpbiBvcHRpb24z IGZyb20gJmx0O3N5c3RlbSZndDsNCiB0byAmbHQ7cnVubmluZyZndDsgY2FuIGJlIHJlbW92ZWQs IHRoZW4gaXQgbG9va3Mgbm8gZGlmZmVyZW5jZSBiZXR3ZWVuIG9wdGlvbjEgYW5kIG9wdGlvbjMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZXN0IFJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlFpdWZhbmcgTWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IG5ldG1vZCBbbWFpbHRv Om5ldG1vZC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5LZW50IFdhdHNl bjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAyOSwgMjAyMSAxOjA5IEFNPGJyPg0K PGI+VG86PC9iPiBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRt b2RdIHN5c3RlbSBjb25maWd1cmF0aW9uIHN5bmMgbWVjaGFuaXNtPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPldHLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPlJlZ2FyZGluZyB5ZXN0ZXJkYXnigJlzICZsdDtzeXN0 ZW0mZ3Q7IGRhdGFzdG9yZSBwcmVzZW50YXRpb24sIHRoZXJlIHNlZW1lZCB0byBiZSBzdXBwb3J0 IGZvciAmcXVvdDtPcHRpb24gIzLigJ0sIHdoaWNoIGlzIHRvIGhhdmUgJmx0O3N5c3RlbSZndDsg bWVyZ2UgaW50byAmbHQ7aW50ZW5kZWQmZ3Q7LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+SXQgd2FzIG5vdGVkIHRoYXQgdGhpcyB0aGVuIHdvdWxkIG1lYW4gdGhh dCBjbGllbnQtdmFsaWRhdGlvbiBvZiAmbHQ7cnVubmluZyZndDsgd291bGQgbmVjZXNzaXRhdGUg dW5kZXJzdGFuZGluZyBob3cgdGhlIG1lcmdlIHdvcmtzLCB0byBleHBhbmQgdGVtcGxhdGVzLCBy ZXNvbHZlIGxlYWZyZWZzLCBldGMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPk15IHRob3VnaHRzIGFyZSwgc28/ICZuYnNwOyZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5GaXJzdGx5LCBhIGNs aWVudCB0aGF0IGRvZXNu4oCZdCB1bmRlcnN0YW5kIHRoYXQgdGhlcmUgbWF5IGJlIHNvbWUgJmx0 O3N5c3RlbSZndDsgZGVmaW5lZCBjb25maWd1cmF0aW9uIHdpbGwsIGZvciB0aGUgbW9zdCBwYXJ0 LCBiZSBub25lIHRoZSB3aXNlci4gJm5ic3A7IFRoZSBjbGllbnQgKndpbGwqIGRpc2NvdmVyICZs dDtzeXN0ZW0mZ3Q7IGNvbmZpZ3VyYXRpb24gaW4gJmx0O29wZXJhdGlvbmFsJmd0OywNCiBidXQg dGhpcyBpcyBhbHJlYWR5IHRoZSBjYXNlIHRvZGF5LiAmbmJzcDtPbmUgbmV3IHRoaW5nIGlzIHRo YXQgJmx0O29wZXJhdGlvbmFsJmd0OyBzaG91bGQgdXNlIOKAnG9yaWdpbjpzeXN0ZW3igJ0gZm9y IGNvbmZpZ3VyYXRpb24gb3JpZ2luYXRpbmcgZnJvbSB0aGUgJmx0O3N5c3RlbSZndDsgZGF0YXN0 b3JlLiAmbmJzcDtUaGlzIGxhc3QgcG9pbnQgbWlnaHQgc3VycHJpc2UgY2xpZW50c+KApmFzIHRo ZSBkZWZpbml0aW9uIG9mIOKAnHdpdGgtb3JpZ2lu4oCdIGRvZXNu4oCZdCBzdGF0ZSB0aGF0IGNs aWVudHMNCiBtdXN0Jm5ic3A7aWdub3JlIGFueSB1bnJlY29nbml6ZWQg4oCcb3JpZ2lu4oCdIGlk ZW50aXRpZXM6IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwv cmZjODUyNyNzZWN0aW9uLTMuMi4yIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvcmZjODUyNyNzZWN0aW9uLTMuMi4yPC9hPi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+U2Vjb25kbHksIG5vIHNoYXJlZCBvYmplY3QgZGVm aW5lZCBpbiAmbHQ7c3lzdGVtJmd0OyB3aWxsIGJlIGFjdGl2YXRlZCB1bnRpbCBjbGllbnQtc3Vw cGxpZWQgY29uZmlnIHJlZmVyZW5jZXMgaXQuICZuYnNwO0J1dCBhbnkgY2xpZW50IGFibGUgdG8g ZG8gdGhpcyBhbHJlYWR5IGtub3dzIGhvdyAmbHQ7c3lzdGVtJmd0OyBtZXJnZXMgaW50byAmbHQ7 aW50ZW5kZWQmZ3Q7IGFuZCBpcyBhY2NvdW50aW5nDQogZm9yIGl0LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5UaG91Z2h0cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPktlbnQ8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGJyPg0KPGJyPg0KPG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij5PbiBKdWwgMTYsIDIwMjEsIGF0IDY6MjQgQU0sIG1hcWl1ZmFuZyAoQSkgJmx0Ozxh IGhyZWY9Im1haWx0bzptYXFpdWZhbmcxQGh1YXdlaS5jb20iPm1hcWl1ZmFuZzFAaHVhd2VpLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLCBLZW50LDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5QbGVhc2Ugc2VlIG15IHJlcGx5IGlubGlu ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEtlbnQgV2F0c2VuIFs8 YSBocmVmPSJtYWlsdG86a2VudCYjNDM7aWV0ZkB3YXRzZW4ubmV0Ij5tYWlsdG86a2VudCYjNDM7 aWV0ZkB3YXRzZW4ubmV0PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEp1bHkgMTYs IDIwMjEgMjo1NSBBTTxicj4NCjxiPlRvOjwvYj4gbWFxaXVmYW5nIChBKSAmbHQ7PGEgaHJlZj0i bWFpbHRvOm1hcWl1ZmFuZzFAaHVhd2VpLmNvbSI+bWFxaXVmYW5nMUBodWF3ZWkuY29tPC9hPiZn dDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1v ZEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtuZXRtb2RdIHN5c3RlbSBj b25maWd1cmF0aW9uIHN5bmMgbWVjaGFuaXNtPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjcyLjBwdCI+SGkmbmJzcDtRaXVmYW5nLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFtzbmlwXTwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Ojcy LjBwdCI+VGhlIHF1ZXN0aW9uIGlzIGlmIHRoZSBzZXJ2ZXIgaW1wbGVtZW50YXRpb24gcHJ1bmVz IGRhbmdsaW5nL3VudXNlZCBvYmplY3RzIHdoZW4gJmx0O2ludGVuZGVkJmd0OyBpcyBhcHBsaWVk LCB1cGRhdGluZyAmbHQ7b3BlcmF0aW9uYWwmZ3Q7LiAmbmJzcDtNeSBhc3N1bXB0aW9uIGlzIHRo YXQgdGhlIHNlcnZlciB3aWxsIGRpc2NhcmQgYW55IG9iamVjdCB0aGF0IGRvZXNu4oCZdCBhY3R1 YWxseSBpbXBhY3QNCiB0aGUgcnVubmluZyBjb25maWd1cmF0aW9uIG9mIHRoZSBzeXN0ZW0gKGku ZS4sIHZhbHVlcyBhcmUgY29uc3VtZWQgYnkgdGhlIHVuZGVybHlpbmcgb3BlcmF0aW5nIHN5c3Rl bSwgZHJpdmVycywgZXRjLikuICZuYnNwO1RodXNseSwgaXQgaXMgbXkgb3BpbmlvbiB0aGF0IG9u bHkgdGhlIHJlZmVyZW5jZWQgb2JqZWN0cyBhcmUgYXBwbGllZC4gJm5ic3A7SGVuY2Ugd2h5LCB0 byBhbnN3ZXIgeW91ciBsYXN0IHF1ZXN0aW9uLCBJIHdyb3RlIHRoYXQgdGhlc2UgY29uZmlndXJh dGlvbnMNCiAobWFudWZhY3R1cmVyLWRlZmluZWQgb2JqZWN0cykgYXJlIG5vdCBhcHBsaWVkIGlt bWVkaWF0ZWx5IGJ1dCBvbmx5IGFmdGVyIHRoZXkgYXJlIHJlZmVyZW5jZWQuICZuYnNwO01ha2Vz IHNlbnNlPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltRaXVm YW5nIE1hXSBZZXMsIHRyeSB0byBzdW0gdXAgb3VyIGRpc2N1c3Npb24gYWJvdXQgdGhlIGNhdGVn b3JpZXMgb2YgdGhlIHN5c3RlbSBjb25maWd1cmF0aW9uOjwvc3Bhbj48L2k+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3 Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PGI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlBoeXNpY2FsLXJlc291cmNlLWRlcGVuZGVudC0tJmd0 OyB3aGV0aGVyIHRoaXMgc29ydCBvZiBzeXN0ZW0gY29uZmlndXJhdGlvbiBleGlzdHMgaW4gJmx0 O3N5c3RlbSZndDsgZGVwZW5kZW50cyBvbiBpZiB0aGUgcGh5c2ljYWwgcmVzb3VyY2UgaXMgcHJl c2VudChlLmcuLA0KIHBoeXNpY2FsIGludGVyZmFjZSkuPC9zcGFuPjwvaT48L2I+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Ojcy LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGh5c2ljYWwtcmVzb3VyY2UtaW5kZXBlbmRlbnQtLSZn dDt3aGljaCBpcyBwcm92aWRlZCBieSB0aGUgZGV2aWNlIHN5c3RlbTwvc3Bhbj48L2k+PC9iPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDoxMDguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzIi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5vPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+RnVydGhlciBjbGFzc2lmaWNhdGlvbiBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBv ZiDigJxhcHBsaWVk4oCdIHRpbWUoZGVwZW5kZW50cyBvbiB3aGV0aGVyIHRoZSBzeXN0ZW0gY29u ZmlndXJhdGlvbiBpbXBhY3RzIHRoZSBydW5uaW5nIG9mIHRoZSBzeXN0ZW0pPC9zcGFuPjwvaT48 L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjE0NC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDMg bGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2lu Z2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CpzxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNv bmZpZyB0aGF0IGlzIGFwcGxpZWQgaW1tZWRpYXRlbHkoZS5nLiwgdGhlIGxvb3BiYWNrLCB0aGUg cHJlZGVmaW5lZCBtaW5pbXVtIGxlbmd0aCBvZiBwYXNzd29yZOKApik8L3NwYW4+PC9pPjwvYj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MTQ0LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMyBsZm8y Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGlu Z3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsKnPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q29uZmln IHRoYXQgaXMgYXBwbGllZCBvbmx5IGFmdGVyIGJlaW5nIHJlZmVyZW5jZWQgYnkgb3RoZXIgY29u ZmlncyhlLmcsIGRlZmluaXRpb25zIGZvciBhcHBsaWNhdGlvbnMgZnRwL3RmdHDigKYpPC9zcGFu PjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBs ZXZlbDIgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi Pm88c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxiPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5GdXJ0aGVyIGNsYXNzaWZpY2F0aW9uIGZyb20gdGhlIHBl cnNwZWN0aXZlIG9mIGdlbmVyYXRpb24gdGltZTwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxNDQuMHB0 O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwzIGxmbzIiPg0KPCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+wqc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Db25maWcgdGhhdCBpcyBnZW5l cmF0ZWQgdW5jb25kaXRpb25hbGx5IGF0IGVhY2ggYm9vdCB0aW1lKGUuZywgbG9vcGJhY2ssIHBy ZWRlZmluZWQgbWluaW11bSBsZW5ndGggb2YgcGFzc3dvcmQsIGZ0cC90ZnRw4oCmKTwvc3Bhbj48 L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDoxNDQuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2 ZWwzIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wqc8c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5Db25maWcgdGhhdCBpcyBnZW5lcmF0ZWQgY29uZGl0aW9uYWxseSBkdXJpbmcgdGhlIGRldmlj ZSBydW5uaW5nKGUuZy4sIHN5c3RlbS1nZW5lcmF0ZWQgbG9jYWwtcG9ydCBhbmQgcmVtb3RlLXBv cnQgZm9yIGEgbmV3IGVzdGFibGlzaGVkIEJHUCBjb25uZWN0aW9uKTwvc3Bhbj48L2k+PC9iPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjkwLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij5LZWVwIGlu IG1pbmQgdGhhdCB3aGF0IGlzIGRlc2NyaWJlZCBhYm92ZSBpcyBqdXN0IG9uZSBhc3BlY3Qgb2Yg d2hhdCBjYW4gYmUgaW4gJmx0O3N5c3RlbSZndDsuICZuYnNwO0luIGFkZGl0aW9uIHRvIGRlZmlu aW5nIHJlZmVyZW5jZS1hYmxlIG9iamVjdHMsICZsdDtzeXN0ZW0mZ3Q7IGNhbiBhbHNvIGRlZmlu ZS9hcHBseSBjb25maWd1cmF0aW9uIGltbWVkaWF0ZWx5IChlLmcuLCB0aGUgbG9vcGJhY2sNCiBp bnRlcmZhY2UpLiAmbmJzcDtUaGF0IGlzLCBjb25maWd1cmF0aW9uIG5vdCBkb2VzIG5vdCBoYXZl IHRvIGJlIHJlZmVyZW5jZWQgaW4gb3JkZXIgdG8gYmVjb21lIGFjdGl2YXRlZC48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bUWl1ZmFuZyBNYV0gTm90ZWQuPC9z cGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3 Mi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDoxMDguMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O2Jh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Tm90ZSB0aGF0LCAmbHQ7cnVubmluZyZndDsgYnkgaXRz ZWxmIHdvdWxkIG5vdCBwYXNzIHZhbGlkYXRpb24sIGR1ZSB0byBtaXNzaW5nIGxlYWZyZWZzLiZu YnNwOyBUaGFua2Z1bGx5LCBOTURBIG5ldmVyIHNheXMgdGhhdCB2YWxpZGF0aW9uIHJ1bnMgb24g Jmx0O3J1bm5pbmcmZ3Q7LiZuYnNwOyBCdXQgb25jZSAmbHQ7cnVubmluZyZndDsgYW5kICZsdDtz eXN0ZW0mZ3Q7IGhhdmUgYmVlbiBtZXJnZWQsIHRvIGJlY29tZSAmbHQ7aW50ZW5kZWQmZ3Q7LCB0 aGUgcmVzdWx0IGRvZXMgcGFzcyB2YWxpZGF0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IFtRaXVmYW5nIE1hXSBUaGUgcmVmZXJlbmNlZCBpbnN0YW5jZSBtdXN0IGFsc28g ZXhpc3QgZm9yIHRoZSBkYXRhIHRvIGJlIHZhbGlkIHNpbmNlIHRoZSByZXF1aXJlLWluc3RhbmNl IGRlZmF1bHRzIHRvIHRydWUgaWYgbm90IHByZXNlbnQuIElzIHRoaXMgd2hhdCB5b3UgaGFkIGlu IHlvdXIgbWluZD8gWWVzLCBOTURBIHNheXMgdGhhdCBpdCBpcyAmbHQ7aW50ZW5kZWQmZ3Q7IHdo aWNoIGlzIHN1YmplY3QgdG8gdmFsaWRhdGlvbi4gQnV0IEkgYWxzbyBub3RpY2UgdGhhdCBJbiBz ZWN0aW9uIDUuMS4zIG9mIHRoZSBOTURBOuKAnSZsdDtydW5uaW5nJmd0OyBNVVNUIGFsd2F5cyBi ZSBhIHZhbGlkIGNvbmZpZ3VyYXRpb24gZGF0YSB0cmVlLCBhcyBkZWZpbmVkJm5ic3A7IGluIFNl Y3Rpb24gOC4xIG9mIFtSRkM3OTUwXS4g4oCdIFNvIG15IHRob3VnaHQgaGVyZSBpcyB0aGF0ICZs dDtydW5uaW5nJmd0OyBzaG91bGQgYWxzbyBjb25mb3JtIHRvIHRoZSBZQU5HIG1vZGVsIGNvbnN0 cmFpbnRzIGFuZCB0aGF04oCZcyB0byBzYXksIGEgcmVmZXJlbmNlZCBzeXN0ZW0tZGVmaW5lZCBk YXRhIGl0ZW0gc2hvdWxkIGFsc28gZXhpc3RzIGluICZsdDtydW5uaW5nJmd0Oy48L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZXJlZm9yZSwgaWYgc3lzdGVtIGNvbmZpZ3VyYXRp b25zIGRvIG5vdCBleGlzdCBpbiAmbHQ7cnVubmluZyZndDssIHRoZXkgc3RpbGwgbmVlZCB0byBi ZSAmbmJzcDtjb25maWd1cmVkIGluICZsdDtydW5uaW5nJmd0OyBtYW51YWxseSBpbiBvcmRlciBm b3IgYmVpbmcgcmVmZXJlbmNlZC4gSW4gdGhpcyBjYXNlLCB0aGUgb3JpZ2luYWwgcHVycG9zZSBv ZiBwcmVkZWZpbmluZyBzb21lIHN5c3RlbSBjb25maWd1cmF0aW9ucyBmb3IgdXNlciBjb252ZW5p ZW5jZSBpcyBsb3N0LiBUaGlzIGlzIHRoZSByZWFzb24gd2h5IHdlIHdvdWxkIGxpa2UgdG8gZGVm aW5lIHNvbWUgbWVjaGFuaXNtIGhlcmUgdG8gc3luY2hyb25pemUgJmx0O3N5c3RlbSZndDsgaW50 byAmbHQ7cnVubmluZyZndDsuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDo3Mi4wcHQiPkkgc2VlIGluIFJGQyA4MzQyICZxdW90OyZsdDtydW5uaW5nJmd0OyBNVVNUIGFs d2F5cyBiZSBhIHZhbGlkIGNvbmZpZ3VyYXRpb24gZGF0YSB0cmVlLCBhcyBkZWZpbmVkIGluIFNl Y3Rpb24gOC4xIG9mIFtSRkM3OTUwXeKAnS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjcyLjBwdCI+QnV0IHRoZSBxdWVzdGlvbiByZW1haW5zIGlmIGl0IGlzIHBv c3NpYmxlIGZvciB0aGUgc3lzdGVtIGlzIGFibGUgdG8gdmFsaWRhdGUgJmx0O3J1bm5pbmcmZ3Q7 IHdpdGhvdXQsIGUuZy4sIGV4cGFuZGluZyB0ZW1wbGF0ZXMuICZuYnNwO1RoZXJlIG1heSBiZSBh ICdsZWFmcmVmJyBvciDigJhtdXN04oCZIGV4cHJlc3Npb24gc29tZXdoZXJlIHRoYXQgd2lsbCBm YWlsIGJlY2F1c2UgdGhlIGV2YWx1YXRpb24NCiBvY2N1cnMgd2l0aG91dCBleHBhbmRpbmcgYSB0 ZW1wbGF0ZSB0aGF0IHN1cHBsaWVzIHRoZSBtaXNzaW5nIHBhcnRzLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltRaXVmYW5nIE1hXSBPbiBjb25kaXRpb24gdGhh dCAmbHQ7cnVubmluZyZndDsgc2hvdWxkIGJlIHZhbGlkLCB0aGUgb3BlcmF0b3JzIHdpbGwgbmVl ZCB0byByZXRyaWV2ZSBmcm9tIHRoZSAmbHQ7aW50ZW5kZWQmZ3Q7IG9yICZsdDtvcGVyYXRpb25h bCZndDsNCiB0byBnZXQgdGhlIHRlbXBsYXRlLWV4cGFuZGVkIGNvbmZpZ3VyYXRpb25zIGFuZCB0 aGVuIGNyZWF0ZSB0aGVtIGluIHRoZSAmbHQ7cnVubmluZyZndDssIHJpZ2h0PyAmbmJzcDs8L3Nw YW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5N eSBmZWVsaW5nIGlzIHRoYXQgaXQgbG9zZXMgdGhlIG1lYW5pbmcgb2YgcHJlZGVmaW5pbmcgYW5k IHNlZW1zIG5vIGRpZmZlcmVuY2VzIGJldHdlZW4gb3BlcmF0b3ItZGVmaW5lZCBjb25maWd1cmF0 aW9ucyBpZiBvcGVyYXRvcnMNCiBoYXZlIHRvIGNyZWF0ZSBzeXN0ZW0gY29uZmlndXJlcyBpbiAm bHQ7cnVubmluZyZndDsgYmVmb3JlIHRoZXkgdXNlIHRoZW0uIFNvIEkgYW0gYmVnaW5uaW5nIHRv IHRoaW5rLCBpZiBpdOKAmXMgcG9zc2libGUgdG8gZXhwYW5kIHRoZSBzeXN0ZW0tZGVmaW5lZCB0 ZW1wbGF0ZSBkdXJpbmcgdGhlIGNvcHlpbmcgYmV0d2VlbiAmbHQ7c3lzdGVtJmd0OyBhbmQgJmx0 O3J1bm5pbmcmZ3Q7Pzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij5JZiB0aGlzIGRyYWZ0IOKAnHVwZGF0ZXPigJ0gUkZDIDgz NDIgKE5NREEpLCB0aGVuIGl0IGNhbiBzdXBwbHkgYSBjbGFyaWZ5aW5nIHN0YXRlbWVudCBhYm91 dCB3aGF0IGl0IG1lYW5zIHRoYXQgJnF1b3Q7Jmx0O3J1bm5pbmcmZ3Q7IE1VU1QgYWx3YXlzIGJl IGEgdmFsaWQgY29uZmlndXJhdGlvbiBkYXRhIHRyZWXigJ0uICZuYnNwO0VpdGhlciB0aGF0LCBv ciBhbiBFcnJhdGEgaWYgaXTigJlzIGRldGVybWluZWQNCiB0aGF0IHRoZSBzdGF0ZW1lbnQgaXNu 4oCZdCBjb3JyZWN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 NzIuMHB0Ij5Zb3UgbWFrZSBhIGdvb2QgdGVjaG5pY2FsIHBvaW50LCBidXQgSSB0aGluayB0aGF0 IHdlIHNob3VsZCAqd2FudCogdG8gYXZvaWQgaGF2aW5nIHRvIGNvcHkgJmx0O3N5c3RlbSZndDsg KG9yICZsdDtvcGVyYXRpb25hbCZndDspIGNvbmZpZ3VyYXRpb24gaW50byAmbHQ7cnVubmluZyZn dDsgaWYgd2UgY2FuIGF2b2lkIGl0LiAmbmJzcDtBZ3JlZWQ/PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1FpdWZhbmcgTWFdIHRlbmQgdG8gYWdyZWUuIE1heWJl IHdlIHNob3VsZCB0cnkgdG8gYXZvaWQgaXQsIHVubGVzcyB3ZSBoYXZlIHRvLjwvc3Bhbj48L2k+ PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij5G V0lXLCBhbHNvIGluIFJGQyA4MzQyLCBTZWN0aW9uIDUuMS40Ljo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4w cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6NzIuMHB0O2JyZWFrLWJlZm9yZTogcGFnZTtmb250LXZhcmlhbnQtbGlnYXR1cmVz OiBub3JtYWw7b3JwaGFuczogMjt3aWRvd3M6IDIiPiZuYnNwOyZuYnNwOyAmbHQ7aW50ZW5kZWQm Z3Q7IGlzIHRpZ2h0bHkgY291cGxlZCB0byAmbHQ7cnVubmluZyZndDsuJm5ic3A7IFdoZW5ldmVy IGRhdGEgaXMgd3JpdHRlbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDo3Mi4wcHQiPiZuYnNwOyZuYnNwOyB0byAmbHQ7cnVubmluZyZndDssIHRoZSBzZXJ2ZXIgTVVT VCBhbHNvIGltbWVkaWF0ZWx5IHVwZGF0ZSBhbmQgdmFsaWRhdGU8bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDsmbmJzcDsgJmx0O2ludGVuZGVk Jmd0Oy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4m bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4m bmJzcDsmbmJzcDsgJmx0O2ludGVuZGVkJmd0OyBNQVkgYWxzbyBiZSB1cGRhdGVkIGluZGVwZW5k ZW50bHkgb2YgJmx0O3J1bm5pbmcmZ3Q7IGlmIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0 eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPiZuYnNwOyZuYnNwOyBlZmZlY3Qgb2YgYSBjb25maWd1 cmF0aW9uIHRyYW5zZm9ybWF0aW9uIGNoYW5nZXMsIGJ1dCAmbHQ7aW50ZW5kZWQmZ3Q7IE1VU1Q8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDsm bmJzcDsgYWx3YXlzIGJlIGEgdmFsaWQgY29uZmlndXJhdGlvbiBkYXRhIHRyZWUsIGFzIGRlZmlu ZWQgaW4gPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9yZmM3 OTUwI3NlY3Rpb24tOC4xIj5TZWN0aW9uJm5ic3A7OC4xPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIGNsYXNzPSJNc29IeXBlcmxpbmsi PjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjNzk1MCNz ZWN0aW9uLTguMSI+Jm5ic3A7Jm5ic3A7IG9mIFtSRkM3OTUwXTwvYT48L3NwYW4+LjxvOnA+PC9v OnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6NzIuMHB0Ij48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEw OC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4mZ3Q7IEkgYW0gd29uZGVyaW5nIGlmIHRo ZXNlIGNvbmZpZ3VyYXRpb24gd2lsbCBwcmVzZW50IGluIHRoZSAmbHQ7b3BlcmF0aW9uYWwmZ3Q7 ICh3aGljaCBjb250YWlucyBhbGwgdGhlIGNvbmZpZ3VyYXRpb24gYWN0dWFsbHkgdXNlZCBieSB0 aGUgZGV2aWNlKSBiZWZvcmUgdGhleeKAmXJlIHJlZmVyZW5jZWQuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O2JhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 IzIxMjUyOSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDoxMDguMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+SSB0aGluayB0aGF0IGl0 IHdvdWxkIGRlcGVuZCBpbiB0aGUgc3BlY2lmaWMgc2VydmVy4oCZcyBiZWhhdmlvciwgcmVnYXJk aW5nIGlmICp1bnVzZWQqIHByZWRlZmluZSBvYmplY3RzIGFyZSBwcmVzZW50IGluICZsdDtvcGVy YXRpb25hbCZndDsuJm5ic3A7IENlcnRhaW5seSB0aGUgdW51c2VkIG9iamVjdHMgd291bGQgbm90 IGhhdmUgdG8gYmUgcHJlc2VudCBpbiAmbHQ7b3BlcmF0aW9uYWwmZ3Q7LiZuYnNwOyBJZiBJIHdl cmUgaW1wbGVtZW50aW5nIHRoZSBzZXJ2ZXIsIHRoZSB1bnVzZWQgb2JqZWN0cyB3b3VsZCBOT1Qg YmUgcHJlc2VudCBpbiAmbHQ7b3BlcmF0aW9uYWwmZ3Q7Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+W1FpdWZhbmcgTWFdIFllcywgaWYgdGhlIHByZWRlZmluZWQgc3lzdGVtIGNv bmZpZ3VyYXRpb25zIGlzIHVudXNlZCwgdGhlbiBJIGFsc28gdGVuZCB0byBhZ3JlZSB0aGF0IHRo ZXkgd291bGQgbm90IGJlIHByZXNlbnQgaW4gJmx0O29wZXJhdGlvbmFsJmd0OyBidXQgbWF5IGFs c28gZGVwZW5kIG9uIHRoZSB2ZW5kb3IgaW1wbGVtZW50YXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+WXVwLCB0aGlzIGlzIHRoZSBzYW1lIGNvbmNs dXNpb24gaXMgaW4gbXkgcmVzcG9uc2UgYWJvdmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+W1FpdWZhbmcgTWFdIDopPC9zcGFuPjwvaT48L2I+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6NzIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7YmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xh cztjb2xvcjojMjEyNTI5Ij4mZ3Q7IEl0IHdvdWxkIGJlIGdvb2QgaWYgd2UgY291bGQgZGV0ZXJt aW5lIGlmIHRoZXJlIGFyZSBhbnkgb3RoZXIgJnF1b3Q7cmVzb3VyY2UtaW5kZXBlbmRlbnTigJ0g Y29uZmlndXJhdGlvbiBjYXRlZ29yaWVzIGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+ Jmd0OyBbUWl1ZmFuZyBNYV0gRG8geW91IHRoaW5rIHRoZXJlIGV4aXN0cyBjb25kaXRpb25hbCBz eXN0ZW0gY29uZmlndXJhdGlvbiAoaWYgdGhlIHByZWNlZGluZyBjb25maWd1cmF0aW9ucyB5b3Ug bWVudGlvbmVkIGFib3ZlIGlzIG5vdCk/IEZvciBleGFtcGxlLCBpZiBTU0ggaXMgZW5hYmxlZCBv biBhIGRldmljZSwgU1NILXJlbGF0ZWQga2V5cyBhcmUgYXV0b21hdGljYWxseSBnZW5lcmF0ZWQu IFN1Y2ggY29uZmlndXJhdGlvbnMgYXJlIGdlbmVyYXRlZCBhdCB0aGUgbW9tZW50IHdoZW4gYSBz cGVjaWFsIGZ1bmN0aW9uYWxpdHkgaXMgZW5hYmxlZC48L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjEwOC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij5J4oCZbSB1bnN1cmUgd2hhdCB5b3Ug bWVhbiBpbiBnZW5lcmFsIGJ5ICZxdW90O2NvbmRpdGlvbmFsIGNvbmZpZ3VyYXRpb27igJ0sIGJ1 dCBJIGNhbiBzcGVhayB0byB5b3VyIHNwZWNpZmljIGV4YW1wbGUuIFRob3VnaCBJIG11c3QgcHJl ZmFjZSBteSBjb21tZW50cyB0aGF0IEkgaW1hZ2luZSB0aGVyZSBhcmUgYSBudW1iZXIgb2Ygd2F5 cyBzZXJ2ZXJzIG1pZ2h0IGdvIGFib3V0IGVuYWJsaW5nIGBzc2hkYC4mbmJzcDsgV2hhdCBmb2xs b3dzIGlzIG15IHBlcnNvbmFsIHZpZXcsIGZvcmdlZCBieSBiZWluZyBhcm91bmQgc3lzdGVtcyBm b3IgYXdoaWxlJm5ic3A7IDspPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDoxMDguMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O2JhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6IzIxMjUyOSI+SW4gZ2VuZXJhbDo8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjEwOC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBgc3NoZGAgaXMgTk9UIGVuYWJsZWQgYnkgZGVm YXVsdC48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEw OC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBgc3NoZGAgaXMgZW5hYmxlZCB2aWEgYSBjb25maWd1 cmF0aW9uIGtub2IuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDoxMDguMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gdGhlIFNTSCBob3N0IGtleSBpcyBkeW5h bWljYWxseSBnZW5lcmF0ZWQgdGhlIGZpcnN0IHRpbWUgYHNzaGRgIGlzIGVuYWJsZWQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O2JhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6IzIxMjUyOSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IC0gdGhlIFNTSCBob3N0IGtleSBpdHNlbGYgaXMgaW4gJmx0O29wZXJhdGlv bmFsJmd0OyAobm90ICZsdDtydW5uaW5nJmd0Oyk8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEw OC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij5UaGlzIHZpZXcgaXMgY29uc2lzdGVudCB3 aXRoIHRoZSBmaXJzdCBwYXJhZ3JhcGggaW4gU2VjdGlvbiAzIG9mIHRoZSDigJxrZXlzdG9yZeKA nSBkcmFmdCAocmVwcm9kdWNlZCBiZWxvdyk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDgu MHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDMuJm5ic3A7IFN1cHBvcnQgZm9yIEJ1aWx0LWluIEtleXM8 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7 YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7IEluIHNvbWUgaW1wbGVtZW50YXRpb25zLCBhIHNlcnZlciBtYXkgc3VwcG9ydCBidWls dC1pbiBrZXlzLiZuYnNwOyBCdWlsdC08L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7IGlu IGtleXMgTUFZIGJlIHNldCBkdXJpbmcgdGhlIG1hbnVmYWN0dXJpbmcgcHJvY2VzcyBvciBiZSBk eW5hbWljYWxseTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MTA4LjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1MjkiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsgZ2VuZXJhdGVkIHRoZSBm aXJzdCB0aW1lIHRoZSBzZXJ2ZXIgaXMgYm9vdGVkIG9yIGEgcGFydGljdWxhciBzZXJ2aWNlPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O2Jh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyAoZS5nLiwgU1NIKSBpcyBlbmFibGVkLjwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdDtiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNv bnNvbGFzO2NvbG9yOiMyMTI1MjkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1MjkiPkFz IGEgY2xvc2luZyB0aG91Z2h0LCB0aGlzIG1vZGVsICh3aGljaCBJIHN0YXRlZCB1cGZyb250IG1h eSBub3QgYmUgdW5pdmVyc2FsKSB3b3VsZCBoYXZlIG5vIHByZXNlbmNlLWluIG9yIGludGVyYWN0 aW9uLXdpdGggJmx0O3N5c3RlbSZndDvigKZ0aG91Z2gsIHBlcmhhcHMsIHRoZXJlIG1heSBiZSBz b21lIHByZWRlZmluZWQgdmFsdWVzIGZvciB3aGF0IGtleS1hbGdvcml0aG1zIGFuZC9vciBrZXkt bGVuZ3RocyB0byB1c2Ugd2hlbiBnZW5lcmF0aW5nIHRoZSBTU0ggaG9zdCBrZXkuLi48L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltRaXVmYW5nIE1hXSBCeSDigJxjb25kaXRpb25h bCBzeXN0ZW0gY29uZmlndXJhdGlvbuKAnSwgSSB3YXMgbWVhbmluZyBzb21lIG9mIHRoZSBzeXN0 ZW0gY29uZmlndXJhdGlvbnMgYXJlIG5vdCBnZW5lcmF0ZWQgaW1tZWRpYXRlbHkgYWZ0ZXIgdGhl IGRldmljZSBpcyBwb3dlcmVkIG9uLiBJbnN0ZWFkLCB0aGV5IGFyZSBnZW5lcmF0ZWQgd2hlbiBh IHNwZWNpZmljIGNvbmRpdGlvbiBpcyBzYXRpc2ZpZWQgZHVyaW5nIHRoZSBkZXZpY2UgcnVubmlu ZyhlLmcuLCBhIGZ1bmN0aW9uYWxpdHkgaXMgZW5hYmxlZCBkdWUgdG8gc29tZSBjbGllbnQgY29u ZmlndXJhdGlvbnMpLiBJIGFtIG5vdCBzdXJlIGlmIGl0IHJlYWxseSBleGlzdHMsIG1heWJlIG5v dCwganVzdCB0cnkgdG8gZXhwbG9yZSB0aGUgcG9zc2liaWxpdGllcyBvZiB2YXJpb3VzIHJlc291 cmNlLWluZGVwZW5kZW50IHN5c3RlbSBjb25maWd1cmF0aW9ucy46KSA8L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPlRvIHRo aXMgcG9pbnQgSSBhZ3JlZS4uYXMgZG9lcyBSRkMgODM0MiAoTk1EQSksIFNlY3Rpb24gNS4zLjMu OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7YnJlYWstYmVmb3JlOiBwYWdlO2Zv bnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtvcnBoYW5zOiAyO3dpZG93czogMiI+Jm5ic3A7 Jm5ic3A7IFNvbWV0aW1lcywgcmVzb3VyY2VzIGFyZSBjb250cm9sbGVkIGJ5IHRoZSBkZXZpY2Ug YW5kIHRoZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQi PiZuYnNwOyZuYnNwOyBjb3JyZXNwb25kaW5nIHN5c3RlbS1jb250cm9sbGVkIGRhdGEgYXBwZWFy cyBpbiAoYW5kIGRpc2FwcGVhcnMgZnJvbSk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDsmbmJzcDsgJmx0O29wZXJhdGlvbmFsJmd0OyBkeW5h bWljYWxseS4mbmJzcDsgSWYgYSBzeXN0ZW0tY29udHJvbGxlZCByZXNvdXJjZSBoYXM8bzpwPjwv bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDsmbmJzcDsg bWF0Y2hpbmcgY29uZmlndXJhdGlvbiBpbiAmbHQ7aW50ZW5kZWQmZ3Q7IHdoZW4gaXQgYXBwZWFy cywgdGhlIHN5c3RlbSB3aWxsPG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0OjcyLjBwdCI+Jm5ic3A7Jm5ic3A7IHRyeSB0byBhcHBseSB0aGUgY29uZmlndXJhdGlvbjsg dGhpcyBjYXVzZXMgdGhlIGNvbmZpZ3VyYXRpb24gdG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDsmbmJzcDsgYXBwZWFyIGluICZsdDtvcGVy YXRpb25hbCZndDsgZXZlbnR1YWxseSAoaWYgYXBwbGljYXRpb24gb2YgdGhlPG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+Jm5ic3A7Jm5ic3A7IGNvbmZp Z3VyYXRpb24gd2FzIHN1Y2Nlc3NmdWwpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5b UWl1ZmFuZyBNYV0gU2VlIGFib3ZlLCBhcyBJIHN1bW1hcml6ZWQgYXMgdGhlIHN5c3RlbSBjb25m aWd1cmF0aW9ucyB0aGF0IGlzIGdlbmVyYXRlZCBjb25kaXRpb25hbGx5IGR1cmluZyB0aGUgZGV2 aWNlIHJ1bm5pbmcuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEw OC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij5GaXJzdGx5LCBJIGFnYWluIGhhdmUgdG8g cHJlZmFjZSBteSBjb21tZW50IHRoYXQgdGhlcmUgYXJlIGxpa2VseSBtYW55IHdheXMgdGhhdCB0 ZW1wbGF0aW5nIG1lY2hhbmlzbXMgY2FuIGJlIGRlZmluZWQuJm5ic3A7Jm5ic3A7Jm5ic3A7IEJ1 dCwgaW4gZ2VuZXJhbCwgb25jZSBhIHRlbXBsYXRpbmcgbWVjaGFuaXNtIGhhcyBiZWVuIGRlZmlu ZWQsIHRoZW4gaXQgc3RhbmRzIHRvIHJlYXNvbiB0aGF0IHRlbXBsYXRlcyBjb3VsZCBiZSBkZWZp bmVkIGVpdGhlciBpbiAmbHQ7cnVubmluZyZndDsgKGJ5IG9wZXJhdG9ycykgb3IgaW4gJmx0O3N5 c3RlbSZndDsgKGJ5IHRoZSBtYW51ZmFjdHVyZXIpLiZuYnNwOyBJbiBvbmUgaW1wbGVtZW50YXRp b24gSeKAmW0gZmFtaWxpYXIgd2l0aCwgdGhlIHRlbXBsYXRlcyBhcmUgb2JqZWN0cyB0aGF0IGFy ZSByZWZlcmVuY2VkL3BhcmFtZXRlcml6ZWQgYnkgb3RoZXIgcGFydHMgb2YgdGhlIGNvbmZpZ3Vy YXRpb24uJm5ic3A7IChTYW1lIGFzIHdpdGggdGhlIHByZWRlZmluZWQgb2JqZWN0cyBkaXNjdXNz aW9uIGFib3ZlLikmbmJzcDsgPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDoxMDguMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O2JhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6IzIxMjUyOSI+VG8gYW5zd2VyIHlvdXIgcXVlc3Rpb25zOjwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdDtiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOiMyMTI1MjkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHls ZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1MjkiPjEpIFllcywg aXQgaXMgbXkgb3BpbmlvbiB0aGF0ICphY3RpdmF0ZWQqIHRlbXBsYXRlcyBpbiAmbHQ7c3lzdGVt Jmd0OyB3aWxsIGJlIGV4cGFuZGVkIGFuZCBwcmVzZW50IGluICZsdDtpbnRlbmRlZCZndDsuPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O2Jh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6IzIxMjUyOSI+ MikgSSB3b3VsZCBuZXZlciBzdWdnZXN0IHRoYXQgdGhlIHN5c3RlbS1kZWZpbmVkIHRlbXBsYXRl cyBhcmUgcHJlc2VudCBpbiAmbHQ7cnVubmluZyZndDssIHRob3VnaCB0aGV5IG1heSBiZSByZWZl cmVuY2VkL3BhcmFtZXRlcml6ZWQgYnkgY29uZmlnIGluICZsdDtydW5uaW5nJmd0Oy48L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7YmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25z b2xhcztjb2xvcjojMjEyNTI5Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4zKSBp ZiBhIGNvbmZpZy10ZW1wbGF0ZSBpcyBjb25maWd1cmVkIGluICZsdDtydW5uaW5nJmd0OyAoaS5l LiwgaXQgaXMgb3BlcmF0b3ItZGVmaW5lZCkgdGhlbiwgeWVzLCB0aGUgZXhwYW5kZWQgY29uZmln dXJhdGlvbiBpbiAmbHQ7aW50ZW5kZWQmZ3Q7IGlzICZxdW90O2NsaWVudCBjb25maWd1cmF0aW9u 4oCdIChub3RlLCAmcXVvdDtjbGllbnQgY29uZmlndXJhdGlvbuKAnSBpcyBub3QgYSBmb3JtYWwg dGVybSkuJm5ic3A7IFRoYXQgc2FpZCwgaXQgc2VlbXMgZmFpciB0byBzYXkgdGhhdCBhIHRlbXBs YXRlIGRlZmluZWQgaW4gJmx0O3N5c3RlbSZndDsgYW5kIHRoZW4gcmVmZXJlbmNlZCBieSAmcXVv dDtjbGllbnQgY29uZmlndXJhdGlvbuKAnSBpbiAmbHQ7cnVubmluZyZndDsgaXMgYWxzbyBleHBh bmRlZCBhcyAmcXVvdDtjbGllbnQgY29uZmlndXJhdGlvbuKAnSBpbiAmbHQ7aW50ZW5kZWQmZ3Q7 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBw dDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1MjkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1 MjkiPjQpIEkgZG9u4oCZdCBub3QgdW5kZXJzdGFuZCB5b3VyIGxhc3Qgc2VudGVuY2UsIHRoYXQg dGhlIGV4cGFuc2lvbiBvZiAmbHQ7c3lzdGVtJmd0OyB0ZW1wbGF0ZXMgYXJlIG9ubHkgcHJlc2Vu dCBpbiAmbHQ7b3BlcmF0aW9uYWwmZ3Q7LiZuYnNwOyBNYXliZSB5b3XigJlyZSBzYXlpbmcgc29t ZXRoaW5nIHN1YnRsZSwgZS5nLiwgdGhhdCBzZXJ2ZXJzIGN1cnJlbnRseSBkb27igJl0IHN1cHBv cnQgR0VUIG9uICZsdDtpbnRlbmRlZCZndDsuJm5ic3A7IEJ1dCwgaW4gdGhlb3J5LCB0aGUgZXhw YW5zaW9uIG9mICZsdDtzeXN0ZW0mZ3Q7IHRlbXBsYXRlcyBzaG91bGQgKElNTykgYmUgcHJlc2Vu dCBpbiAmbHQ7aW50ZW5kZWQmZ3Q7LCBzbyB0aGF0IHRoZXkgbWF5IGJlIHN1YmplY3QgdG8gdmFs aWRhdGlvbi4mbmJzcDsmbmJzcDsgT2YgY291cnNlLCBhbGwgdGhlICZsdDtpbnRlbmRlZCZndDsg Y29uZmlndXJhdGlvbiAod2hldGhlciBvcmlnaW5hdGluZyBpbiAmbHQ7cnVubmluZyZndDsgb3Ig Jmx0O3N5c3RlbSZndDspIHRoYXQgaXMgc3VjY2Vzc2Z1bGx5IOKAnGFwcGxpZWTigJ0gd2lsbCBh bHNvIGJlIHByZXNlbnQgaW4gJmx0O29wZXJhdGlvbmFsJmd0Oy48L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPltRaXVmYW5nIE1hXSBBc3N1bWUgdGhhdCB0aGVyZSBpcyBubyAmbHQ7 c3lzdGVtJmd0OyBhbmQgdGhpcyB3b3JrLCB0aGUgZXhwYW5zaW9uIG9mIHN5c3RlbSB0ZW1wbGF0 ZXMgYXJlIG9ubHkgcHJlc2VudCBpbiAmbHQ7b3BlcmF0aW9uYWwmZ3Q7LiBCZWNhdXNlIHRoaXMg aXMgY29tcGF0aWJsZSB3aXRoIHN5c3RlbSBjb25maWd1cmF0aW9uIGRlZmluaXRpb24gaW4gTk1E QS48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBw dDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJ1dCBpZiBzeXN0ZW0gY29uZmln dXJhdGlvbnMgYXJlIG9ubHkgcHJlc2VudCBpbiAmbHQ7b3BlcmF0aW9uYWwmZ3Q7LCB0aGUgcHJl ZGVmaW5lZCBzeXN0ZW0gY29uZmlndXJhdGlvbnMgc3RpbGwgbmVlZCB0byBiZSByZXRyaWV2ZWQg YW5kIGNyZWF0ZWQgaW50byAmbHQ7cnVubmluZyZndDsgZXhwbGljaXRseSB3aGVuIGJlaW5nIHJl ZmVyZW5jZWQuIEkgdGhpbmsgd2XigJl2ZSByZWFjaGVkIGFuIGFncmVlbWVudCBvbiB0aGUgbmVl ZCBmb3IgJmx0O3N5c3RlbSZndDsgdG8gZXhpc3QsIGFuZCBvdXIgbWFpbiBwb2ludCBvZiBkaXNh Z3JlZW1lbnQgaXMgd2hldGhlciAmbHQ7c3lzdGVtJmd0OyBzaG91bGQgYmUgY29waWVkIGludG8g Jmx0O3J1bm5pbmcmZ3Q7LiBZb3VyIHBvaW50IGlzIHRoYXQgYmVpbmcgbWVyZ2VkIGludG8gJmx0 O2ludGVuZGVkJmd0OyBpcyBlbm91Z2ggdG8gbWFrZSBzdXJlIGEgc3VjY2VzcyB2YWxpZGF0aW9u LiBCdXQgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSByZWZlcmVuY2VkIHN5c3RlbSBjb25m aWd1cmF0aW9uIGRhdGEgaXRlbSBtdXN0IGFsc28gZXhpc3QgaW4gdGhlICZsdDtydW5uaW5nJmd0 OyB0byBvYmV5IHRoZSBtb2RlbCBjb25zdHJhaW50cy48L3NwYW4+PG86cD48L286cD48L3ByZT4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6NzIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPlllcywgSSBiZWxpZXZl IHRoYXQgeW91IHByb3ZpZGVkIGFuIGFjY3VyYXRlIGRlc2NyaXB0aW9uIG9mIHRoZSBkaWZmZXJl bmNlIGluIG91ciBvcGluaW9ucy4gJm5ic3A7UGVyIG15IGVhcmxpZXIgcmVzcG9uc2UsIHlvdSBt YWtlIGEgdmFsaWQgdGVjaG5pY2FsIHBvaW50LCBteSBnb2FsIGlzIHRvIHdhaXZlIHRoYXQgaW50 ZXJwcmV0YXRpb24gdG8gdGhlIHNpZGUgc28gdGhhdA0KIGEgc2ltcGxlciBzb2x1dGlvbiBjYW4g ZW1lcmdlLiAmbmJzcDtJdCB3b3VsZCBiZSBnb29kIHRvIGdldCBvdGhlciBvcGluaW9ucyBvbiBs aXN0LCBvdGhlcndpc2Ugd2XigJlsbCB0YWtlIGl0IGludG8gdGhlIG1lZXRpbmcuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W1FpdWZhbmcgTWFdIE9LLiAmbmJz cDtIb3BlZnVsbHkgc29tZW9uZSBlbHNlIHdvdWxkIHNoYXJlIHNvbWUgb3BpbmlvbnMgaGVyZS4g T3RoZXJ3aXNlIGxldOKAmXMgdGFrZSB0aGlzIGludG8gdGhlIElFVEYgbWVldGluZy48L3NwYW4+ PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBw dCI+W0JUVywgaW4ga2VlcGluZyB3aXRoIHRoaXMgdGhyZWFkIG1vdmluZyBmcm9tIHRoZSBORVRD T05GIHRvIHRoZSBORVRNT0QgbWFpbGluZyBsaXN0cywgd291bGQgaXQgbWFrZSBzZW5zZSB0byBt b3ZlIHRoZSBJRVRGIDExMSBwcmVzZW50YXRpb24gc2xvdCBmcm9tIE5FVENPTkYgdG8gTkVUTU9E IHRvbz8gJm5ic3A7SSB0aGluayBpdCBkb2VzIGFuZCwgZnVydGhlciwgaXQgd291bGQNCiBoZWxw IHdpdGggc2NoZWR1bGluZyAoTkVUQ09ORiBpcyBvdmVyLCBORVRNT0QgaXMgdW5kZXIpLiAmbmJz cDtXb3VsZCB5b3UgYmUgb2theSB3aXRoIHRoaXM/ICZuYnNwOyBBRCBSb2IgYW5kIHRoZSBORVRD T05GIGNoYWlycyBkaXNjdXNzZWQgdGhpcyBtb3JuaW5nLCBhbmQgdGhpbmsgaXQncyBva2F5LCBi dXQgd291bGQgc3RpbGwgbmVlZCB0byBjb25maXJtIHdpdGggdGhlIE5FVE1PRCBjaGFpcnMuXTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltRaXVmYW5nIE1hXSBJ IGFtIGhhcHB5IHdpdGggdGhlIHByb3Bvc2FsLCBpZiBpdOKAmXMgYWxzbyBva2F5IGZvciBORVRN T0QgY2hhaXJzOi0pLiBJIGhhdmUgc2VudCBhbiBlbWFpbCB0byB0aGUgTkVUTU9EIGNoYWlycw0K IHRvIHJlcXVlc3QgdG8gbW92ZSB0aGlzIHByZXNlbnRhdGlvbiBzbG90IGZyb20gTkVUQ09ORiB0 byBORVRNT0QuIDwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0IHdpbGwgYWxzbyBiZSBzdWJt aXR0ZWQgdG8gTkVUTU9EIHdoZW4gdGhlIGRyYWZ0LXN1Ym1pdHRpbmcgd2luZG93IHJlb3BlbnMu PC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O2JhY2tncm91bmQ6d2hp dGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29s b3I6IzIxMjUyOSI+Jm5ic3A7Jmx0O2JpZyBzbmlwJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1 MjkiPiZndDsgSeKAmW0gYmVnaW5uaW5nIHRvIHRoaW5rIHRoYXQ6PC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0O2JhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6 IzIxMjUyOSI+Jmd0OyDCtyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBhdXRvLWNvcHlpbmcgaW50byAmbHQ7cnVubmluZyZndDsgaXMgbGlrZWx5IG5ldmVy IGEgZ29vZCBpZGVhLCBiZWNhdXNlIGl0IHZpb2xhdGVzIHRoZSBkZWZpbml0aW9uIG9mICZsdDty dW5uaW5nJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6MTA4LjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1MjkiPiZndDsgW1FpdWZhbmcgTWFdIEkg YW0gcXVpdGUgYXdhcmUgdGhhdCBkaWZmZXJlbnQgZGF0YXN0b3JlcyBpbiBOTURBIHJlcHJlc2Vu dHMgZGlmZmVyZW50IHZpZXdzIG9mIGRhdGEgbm9kZXMuJm5ic3A7IEFuZCAmbHQ7cnVubmluZyZn dDsgcmVwcmVzZW50cyBhIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlIGhvbGRpbmcgdGhlIGN1cnJl bnQgY29uZmlndXJhdGlvbiBvZiB0aGUgZGV2aWNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMyMTI1Mjki PiZndDsgU2hvdWxkIHdlIGNvbnNpZGVyIHN5c3RlbSBjb25maWd1cmF0aW9uIGFsc28gYmUgcGFy dCBvZiBjdXJyZW50IGNvbmZpZ3VyYXRpb24gb2YgdGhlIGRldmljZT8gRnJvbSBteSBwZXJzcGVj dGl2ZSwgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBzeXN0ZW0gY29uZmlndXJhdGlvbiBhbmQmbmJz cDsgY2xpZW50LWNvbmZpZ3VyYXRpb24gbGllcyBvbmx5IGluIHdobyBwcm92aWRlcyBpdC48L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7YmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpD b25zb2xhcztjb2xvcjojMjEyNTI5Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4m bHQ7cnVubmluZyZndDsgaG9sZHMgdGhlIGN1cnJlbnQgKm9wZXJhdG9yLXNwZWNpZmllZCogY29u ZmlndXJhdGlvbiBvZiB0aGUgZGV2aWNlLiZuYnNwOyBTeXN0ZW0tcHJvdmlkZWQgY29uZmlndXJh dGlvbiBpcyBOT1Qgc3BlY2lmaWVkIGJ5IG9wZXJhdG9ycyAodGhvdWdoIHN5c3RlbS1kZWZpbmVk IG9iamVjdHMgbWF5IGJlIHJlZmVyZW5jZWQgYnkgb3BlcmF0b3Itc3BlY2lmaWVkIGNvbmZpZyBp biAmbHQ7cnVubmluZyZndDspLiZuYnNwOyZuYnNwOyBJIGJlbGlldmUgdGhhdCB0aGlzIGFycmFu Z2VtZW50IGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgZGVmaW5pdGlvbiBvZiAmbHQ7cnVubmluZyZn dDsuJm5ic3A7IEFncmVlZD88L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPltRaXVm YW5nIE1hXSBZZXMuIEFjdHVhbGx5IHdlIGFyZSBub3QgdHJ5aW5nIHRvIHZpb2xhdGUgdGhlIHBy aW5jaXBsZXMgb2YgTk1EQSBhbmQgdGhlIGRlZmluaXRpb24gb2YgJmx0O3J1bm5pbmcmZ3Q7LiAm bmJzcDtUaGUgaXNzdWUgd2UgdHJ5IHRvIHJlc29sdmUgaGVyZSBpcyB0aGF0IHN5c3RlbSBjb25m aWd1cmF0aW9ucyBjYW5ub3QgYmUgdXNlZChyZWZlcmVuY2VkIG9yIG92ZXJ3cml0dGVuKSBieSB0 aGUgb3BlcmF0b3JzIGRpcmVjdGx5IGFuZCBuZWVkIHRvIGJlIGNyZWF0ZWQgaW50byAmbHQ7cnVu bmluZyZndDsgZXhwbGljaXRseS4gVGhpcyBhY3R1YWxseSBsb3NlcyB0aGUgbWVhbmluZyBvZiDi gJxwcmVkZWZpbmluZyBhbmQgYnJpbmdpbmcgY29udmVuaWVuY2XigJ0uIElmIGF1dG8tY29weWlu ZyBpcyBub3QgYSBnb29kIGlkZWEsIHdoYXQgZG8geW91IHRoaW5rIGFib3V0IGRlZmluaW5nIGFu IFJQQyBvcGVyYXRpb24gZm9yIHRoZSBvcGVyYXRvcnMgdG8gZG8gdGhlIGNvcHkod2hpY2ggaXMg YWxzbyB3aGF0IFJvYiBzdWdnZXN0cyBhdCB0aGUgbWVldGluZyk/PC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjcyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij5JZiB3ZSBo YXZlIHRvIGNvcHkgaW50byAmbHQ7cnVubmluZyZndDssIHRoZW4gSSB0aGluayB0aGF0IEkgYWdy ZWUgYW4gUlBDICgmbHQ7ZWRpdC1jb25maWcmZ3Q7Pykgd291bGQgYmUgYmV0dGVyLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltRaXVmYW5nIE1hXSBGcm9tIG15 IHBlcnNwZWN0aXZlLCAmbHQ7ZWRpdC1jb25maWcmZ3Q7IGlzIGZlYXNpYmxlIGJ1dCBub3QgZWZm aWNpZW50IGJlY2F1c2Ugb3BlcmF0b3JzIHN0aWxsIG5lZWQgdG8gcmV0cmlldmUgJmx0O3N5c3Rl bSZndDsvJmx0O29wZXJhdGlvbmFsJmd0Ow0KIGZpcnN0bHkuIElmIHdlIGNvdWxkIGRlZmluZSBh IFJQQyB0byBjb3B5IHRoZSBlbnRpcmUgJmx0O3N5c3RlbSZndDsgaW50byAmbHQ7cnVubmluZyZn dDssIGl0IHNlZW1zIG1vcmUgY29udmVuaWVudCBmb3Igb3BlcmF0b3JzLiBIb3dldmVyLCBzb21l IHN5c3RlbSBjb25maWd1cmF0aW9ucyB3aGljaCBhcmUgbm90IGdvaW5nIHRvIGJlIHJlZmVyZW5j ZWQgb3IgbW9kaWZpZWQgbWF5IGFsc28gYmUgY29waWVkIGludG8gJmx0O3J1bm5pbmcmZ3Q7LiBJ IGRvbid0IGhhdmUgYSBzdHJvbmcNCiBmZWVsaW5nIGFib3V0IHdoaWNoIG9uZSBpcyBwcmVmZXJy ZWQuIEFueXdheSwgd2UgbmVlZCB0byBmaWd1cmUgb3V0IHdoZXRoZXIgaXQgd291bGQgYmUgZmlu ZSBmb3IgJmx0O3J1bm5pbmcmZ3Q7IHRvIG1pc3NpbmcgcmVmZXJlbmNlZCBzeXN0ZW0gY29uZmln dXJhdGlvbnMuPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDo3Mi4wcHQiPllvdSBtZW50aW9uIOKAnG92ZXJ3cml0dGVu4oCdIGJ5IHRoZSBv cGVyYXRvcnM/ICZuYnNwO1doeSB3b3VsZG7igJl0IHRoZSBvcGVyYXRvcnMganVzdCBkZWZpbmUg dGhlaXIgb3duPyAmbmJzcDtGb3IgaW5zdGFuY2UsIGlmIHRoZXkgZG9u4oCZdCBsaWtlIHRoZSB2 ZW5kb3LigJlzIOKAnHZlbmRvci1mb29iYXLigJ0gb2JqZWN0LCB0aGV5IGNvdWxkIGNvcHkvcGFz dGUvZWRpdCB0aGVpciBvd24g4oCcbXktZm9vYmFy4oCdDQogb2JqZWN0IHdpdGggdGhlIHZhbHVl cyBuZWVkZWQsIHllcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5bUWl1ZmFuZyBNYV0gWWVzLCBkZWZpbmluZyB0aGVpciBvd24gd291bGQgYmUgb2theS4gQnkg b3ZlcndyaXRpbmcsIEkgbWVhbiBzb21ldGltZXMgdGhlIG9wZXJhdG9ycyB3b3VsZCBsaWtlIHRv IG1vZGlmeSB0aGUgc3BlY2lmaWMNCiBzeXN0ZW0gY29uZmlndXJhdGlvbiwgZS5nLiwgdGhlIE1U VSB2YWx1ZSBvZiBhIHNwZWNpZmllZCBpbnRlcmZhY2UoaWRlbnRpZmllZCBieSBpdHMgbmFtZSku PC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SWYgdGhlIG9wZXJhdG9ycyB3YW50IHRvIG1vZGlmeSB0aGUgc3lzdGVtIGNvbmZpZ3VyYXRp b25zLCB0aGVyZSBpcyBubyB3YXkgYnV0IHJlZGVmaW5lIHRoZW0gaW4gJmx0O3J1bm5pbmcmZ3Q7 Ljwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlc3QgUmVnYXJkcyw8L3NwYW4+PC9pPjwvYj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5RaXVmYW5nIE1hPC9zcGFuPjwv aT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PGJyPg0K PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEw OC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjoj MjEyNTI5Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjEwOC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4mZ3Q7IMK3Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhhdmluZyBpbiAmbHQ7b3Bl cmF0aW9uYWwmZ3Q7IGRvZXNu4oCZdCBtYWtlIHNlbnNlLCBzaW5jZSB0aGUgdHdlYWtzIHdvdWxk buKAmXQgZ28gdGhydSAmbHQ7cnVubmluZyZndDsgLS0mZ3Q7ICZsdDtpbnRlbmRlZCZndDsgdmFs aWRhdGlvbi48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjEwOC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4mZ3Q7Jm5ic3A7IDwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdDtiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOiMyMTI1MjkiPiZndDsgSeKAmW0gd29uZGVyaW5nIGlmIGEgbW9kZWwgbGlrZSBiZWxv dyB3b3VsZCB3b3JrIGZvciBldmVyeW9uZSAtIHRob3VnaHRzPzwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA4LjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMy MTI1MjkiPiZndDsgW1FpdWZhbmcgTWFdICZsdDtpbnRlbmRlZCZndDsgcmVwcmVzZW50cyB0aGUg Y29uZmlndXJhdGlvbiBhZnRlciBhbGwgY29uZmlndXJhdGlvbiB0cmFuc2Zvcm1hdGlvbnMgdG8g Jmx0O3J1bm5pbmcmZ3Q7IGhhdmUgYmVlbiBwZXJmb3JtZWQsIHNvIEkgdGhpbmsgaXQgaXMgb25s eSBjb3VwbGVkIHRvICZsdDtydW5uaW5nJmd0Oy48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij4m Z3Q7IEFueXdheSwgdGhlICZsdDtzeXN0ZW0mZ3Q7IHNob3VsZCBhbHNvIGludGVyYWN0cyB3aXRo ICZsdDtvcGVyYXRpb25hbCZndDsuJm5ic3A7IEFncmVlZD88L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEy NTI5Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0OjEwOC4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMjEyNTI5Ij5JIGRvbuKAmXQgYWdyZWUgdGhh dCAmbHQ7aW50ZW5kZWQmZ3Q7IG11c3Qgb25seSBiZSBjb3VwbGVkIHRvICZsdDtydW5uaW5nJmd0 Oy4mbmJzcDsgU3BlY2lmaWNhbGx5LCBJIHRoaW5rIHRoYXQgaXQgaXMgb2theSAoY29tcGF0aWJs ZSB3aXRoIE5NREEpIHRvIGRlZmluZSBhICZsdDtzeXN0ZW0mZ3Q7IHRoYXQgYWxzbyBpbXBhY3Rz ICZsdDtpbnRlbmRlZCZndDsuJm5ic3A7Jm5ic3A7IFRoaXMgaXMgdGhlIG9ubHkgKElNTykgc2Fu ZSBhcHByb2FjaCwgYXMgaXQgZW5hYmxlcyB0aGUgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6Q29uc29sYXMiPmNvbWJpbmF0aW9uICZsdDtydW5uaW5nJmd0 OyAmIzQzOyAmbHQ7c3lzdGVtJmd0OyB0byBiZSB2YWxpZGF0ZWQuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5bUWl1ZmFuZyBNYV0gUGxlYXNlIHNlZSBhYm92ZS4gSWYgJmx0O3J1 bm5pbmcmZ3Q7IGlzIE9LIHRvIG1pc3MgcmVmZXJlbmNlZCBzeXN0ZW0gY29uZmlndXJhdGlvbiwg eW91ciBwcm9wb3NhbCBtYWtlcyBzZW5zZSB0byBtZS48L3NwYW4+PG86cD48L286cD48L3ByZT4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6NzIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+QWNrLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Ojcy LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48YnI+DQo8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O2JhY2tncm91bmQ6 d2hpdGUiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDtCZXN0IFJl Z2FyZHMsPC9zcGFuPjwvaT48L2I+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjcyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+UWl1ZmFuZyBNYSA8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcHJlPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Ojcy LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjcyLjBwdCI+S2VudCAvLyBjb250cmlidXRvcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_aa3dfdb471f0430aa50c4e35b9672fb1huaweicom_-- From nobody Sat Jul 31 09:01:18 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605C43A0AB4 for ; Sat, 31 Jul 2021 09:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98c6I_CZghNy for ; Sat, 31 Jul 2021 09:01:11 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80080.outbound.protection.outlook.com [40.107.8.80]) (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 63DCB3A0AB0 for ; Sat, 31 Jul 2021 09:01:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DYBPPu5SBdkP7rkUrMDclcH2fcvrAKz39zLACRQG2XYJqaB0UXmsN1OqRJPxxIi2TxhpZC8BkejlAgPaudIYnj230MM87pzG0eqk87O5JBGuhRQrKCyCbdpuDjPv4WqKdyJ5ZLcgcODh2bkOGeM3KLt3dBfeRfCfYXXaMF4OMJNdK/2zOjMzyYUnOUhZyLFcJBeogjVm4Jw3lOK8Pc7y45MKp2Sj8yyEmQbjd/BRUYcuqrlXGwo9TbRQ4QmT1loWjSoSh7JiY6dDeVvb4mJ/s/wPcsvh3Oo19TPFxatzwzysYAPBBOkvZxFp5Abjk58kUNsY2dGwWJ4oIQPCO1GOAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q+iixTMyZE95Ywn9kZ4zjZj1Q8ZDeIBiqS1b8NW32IY=; b=HRBaJd3/TiixwettiWsPhhEKNdX/RdsGM5l3LgRhhnfA0tI9vBkaBET0KKnVy+tj82qOwe8j1VAZjV40Awq64Cm/JQ8vIbjK0GA4zW96OHXBQxvgiG8cbrDHWTJf8qsQopDPmE1jWZzOJUuI0TbfkhyNRWfDWpFXH+YNtAeFPL2I2ZpLR5j9nLKcpZFYKoO1aBjRntSfhS/Oe2UBKScZfuUGbZXeQt9KzmxwxBXUXX5qwBfkS5HdTvYdoHSgCbmd5cw6Iw6NXn0lC+eMr2DyTr+fy0ci+22Lg5UnIu8eZTr/yiqlElBUMXz0fl7l0r+kwRjjktRW9nfmHS7Whxvu9w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q+iixTMyZE95Ywn9kZ4zjZj1Q8ZDeIBiqS1b8NW32IY=; b=lwZjMSaLOw1+W6qY+b+/hCsemzhtYF8y9vsmd05dQKWxPbWmJ2PlpC0P4GdOCBZvqZTPv08YmbtAp//2djMbG267LvMra6kiERF4otSb9hCQ+GwnqzkTOdFgh5d5+WCmOWhkOzqZWlMjUMwJmTi9lPI/QvFNwr+uJtwhNkd0sZg= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8140.eurprd07.prod.outlook.com (2603:10a6:20b:36f::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.15; Sat, 31 Jul 2021 16:01:08 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4373.018; Sat, 31 Jul 2021 16:01:08 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Lengyel?= To: "'netmod@ietf.org'" Thread-Topic: Comments on draft-ma-netconf-with-system-02 Thread-Index: AdeF/1pqKZkIs+uyRwqKwRPtF511NA== Date: Sat, 31 Jul 2021 16:01:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fe2e4b29-06e9-4c36-7e3f-08d9543c68ed x-ms-traffictypediagnostic: AM8PR07MB8140: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: C3t3Uf/Y3nLPbHkSQqA+Wo/tjg2qZ1WhkCT7vneKsut+/2cU5yKpQiDa+C3EYhk9JEnB0WXWM3lokdn4aWFrurQqflTtD8/rPicSkI0GtALqcpxjkdXY3CLIaQGBqnPfbluY7Qo1/CoiNWiPckLrPXPIm98wgvTY+05OWZy7FuJ9Ofrw6ZpHO5lwUEKMUOBbqjdgqXWBsWI012hex6Y87Z772I2NOx/JWBORd3hNShlxvpa6FMcuTHmohWnF32c/WUProVvYqlkNAXywfNlEz6dcBU8LqKvySCaigTgFEHkIG8TWXPcp+ZrzJ6h5I9IR97Db+yp+vBI6Ze989MgcrSAHAygCwtFU1241mK+387QQspwZ1j3TKmZyYNleUbh/vF9JVwY3yX6NRtCqt3Ouf2KdEDKa2yG9io9trFjrDUpPxUhl4JYvYbTe1Jh9Jg6Uumjgr5w/7nMngaFwJYU9nXkfFIPRJPdUqjvpyuTCZ7GS9um5A02cVHAIvfUNASLCB/Q5oPKyfqg45yBgjWPl+72V1bLP9MRRstQ+u5QrJ39yKqS3aSQEmdt2x8gNpM0ZNlxa569D4eBFwUeCtw2ax24A6UhYe6kXuJTdJWkrMnQtdUCutM3Xxvbg46N8ZK/onfxkAFB5Dgd8hWy+mg3a6Is5ZUJoI8zsO5SileXjCCONjPF3ioQ5zquLrI9woyTvdTv4+53bXf/oOosHXDeeE3s2NMqAlQ6ihw58yGx4msFs2fg19kjmCymYePlHEgPF/V35i8E3FWQOUHRhu7DOhR2Wuwy2gqzOcSm13XYcWqy6hVUvZ4g09DcZZ9UOcE1o50xhEiUsVBV6Wpm2Up2AYTVM/lyHug1WtyEnc0UuiKw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(396003)(39860400002)(136003)(376002)(33656002)(99936003)(26005)(8936002)(5660300002)(71200400001)(86362001)(478600001)(6916009)(9686003)(166002)(6506007)(7696005)(8676002)(966005)(66616009)(316002)(55016002)(66446008)(38070700005)(9326002)(186003)(52536014)(2906002)(76116006)(122000001)(66476007)(64756008)(66556008)(38100700002)(83380400001)(66946007)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?LTs6vLnDygZYCeXkaYadJS/tgxsh93DmA5Zd8rnECaAG8ekTJRdD1VDTsd?= =?iso-8859-1?Q?Kepwy00wLa4+gad3UjPB/biHZV/shAwBKU9HoEVxUP7zwivR7WTspHroHa?= =?iso-8859-1?Q?x/B3vfGJGxX9CD0KOZSCS2SK/Aqyn8taYIAz/jYDah+rJXGeQREjT5jm3E?= =?iso-8859-1?Q?4R4hWi2jxmq2LG5a7/VmN1WwBnx95ODOJrh4HXi2IQsqK4K2KGFbQ7o1sc?= =?iso-8859-1?Q?ygcm4+1sKkaR0Xvf6fjFtnjkLbPnRnVDQyoh20zTjv0/dxyMpG6q5EH5Hg?= =?iso-8859-1?Q?GQjaEIaUYChp/L80G5hNDxpLSlaxkIcuT0e0mwpblFqoADsrR26XSmAr4m?= =?iso-8859-1?Q?Cj8YbZDqZg4Ze9eKFIgvhqrtgIuM+cmSmW60GPxznv+Rnf8vniYDTyOJRK?= =?iso-8859-1?Q?82s+boDJHAlnQV1oZD/9aJkZeNr/2q70yOF2K6XbGxUFZDrzr2Fhtm/gF4?= =?iso-8859-1?Q?Y52wvYaXl2wbnDXl3LkCutSkTHLV55pqmfMByMAVCf0W8j+mbzBq4xh8wm?= =?iso-8859-1?Q?xF7OJMH1zkInyQob+XuMEVdXYvdzimyZ2evd8P8zukfSMGEvtedBBnYxIJ?= =?iso-8859-1?Q?Cnwu0dgumCMNVpmEFMiYZwYterdexxxfBHfehARV6DMXcSpGPPtve17S58?= =?iso-8859-1?Q?mYxOCh4SBE4rcqfmtejc95Vk8fMWCmp9Gp0/710y0oVk1fH/r1YgoZx2e0?= =?iso-8859-1?Q?oeCDY0i/jIGamAEDAX1U//uPeMINroEn1Fg1fRkQ2IMB9AQVDRBziMIu4Z?= =?iso-8859-1?Q?Rfn0/46ph/fIrz6q0pjchIBbMwXOy/YnvdvXZxKIKZDD3tk8ViPcD3rX9g?= =?iso-8859-1?Q?qphUDvF5b9Z3eercl66Rd7itkuj+WfqbDNBNyp22i9lRT1rnEByhOzJRWm?= =?iso-8859-1?Q?TEoXm6EPUP9rAzIka8bIo3Q9qhZdA2VBIdnnVN77Qa8hovNYIHRG+XI2cv?= =?iso-8859-1?Q?IqBSdToL+QoIjiFU19vrv66Blaw8vqQWLt1d3cKFRwiWt+GBF7LRzveQXi?= =?iso-8859-1?Q?db8tO5ZZZ6LCXU0lHZjFAPyKE/lkQyPl+UWwyYtHkI4IgLRcSj+eaZZe6U?= =?iso-8859-1?Q?xWS7iD18r8nkJwhWvuFMXbb1rHmEHRqV/wNwUP7F0PjWcmVR0KXY0GJYJq?= =?iso-8859-1?Q?UkFxDaeuzCqleN/feDEnu/biGZZivLlZ7peGg956bBQ74PG0oC2FOsjCW8?= =?iso-8859-1?Q?90jbHkASSqOV4I4x3u0wYpUmXWaKc8FOayyeKEdLIEbr6P78iL+NbYu0JV?= =?iso-8859-1?Q?4TApQeJ2PWvlhEoX5NHn6EbAbeCMvQ1OAJg2IxCaFlTAT3pxNFgbT6eDXi?= =?iso-8859-1?Q?29HwTuwa1txJVaN0X/Rk+NvutHxQ9JUyIfq2lqxS/hv7EPA=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0079_01D78635.CBE0B950" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fe2e4b29-06e9-4c36-7e3f-08d9543c68ed X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2021 16:01:08.3905 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qu6zAfZTTxilFq9W5iA4EHHouNcqFefGbwtRvNrSCwvMJq0W2jUzcPfI4QcWGczxue4iG7b+mel+0Hi8+WglC7IffmkI/NRgDymzKIS1nDw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8140 Archived-At: Subject: [netmod] Comments on draft-ma-netconf-with-system-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2021 16:01:17 -0000 ------=_NextPart_000_0079_01D78635.CBE0B950 Content-Type: multipart/alternative; boundary="----=_NextPart_001_007A_01D78635.CBE0E060" ------=_NextPart_001_007A_01D78635.CBE0E060 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, MAJOR:=20 The purpose of the draft (the purpose of creating a new datastore) = should be clearly stated. In my view: =93There is a need to validate configuration data against data created = by the system.=94 =20 What is the purpose of system-configuration Use-case A) The system sets some values because it knows what they = shall be. In this case the client must not be allowed to modify these values. = We want to check configuration data against these values. E.g., = AcmeHomeRouter has 5 interfaces called eth0, eth1, eth,2, eth3 and WAN. The client = should not try to add or remove interfaces to this set. Use-case B) The system provides initial values for something that can = be configured in many ways. In this case the client is free to modify the system-defined values. E.g., an initial set of NACM rules is provided. = In this case any constraints based on the system data are very weak, as the user can change the system-data itself. =20 Use-case a) is very interesting and we actually implemented non-standard support for it. I would welcome it in an RFC.=20 I, myself tried to address this in https://github.com/netmod-wg/yang-next/issues/41 Use-case b) IMHO does not require any special support. I will just load = the initial configuration as a last step of a reset, upgrade etc.=20 =20 =20 Can a client remove or change a system-configuration data-node that is automatically or manually copied to running/intended? In use-case A) = NO. In use case B) yes. Allowing some modifications, but not others is IMHO misleading and not acceptable. Assuming that additions are OK while delete is not could be incorrect if, the absence of some data node is important for the network node. =20 =20 =20 =20 Ch.2.2) =93 should also immediately reset to its factory default state.=94 What is this state? It is undefined. I would rather say: should = be reloaded or recreated. Factory-reset may or may not remove results of an upgrade. =20 Ch.3) =93Update with the system configuration change=93 The auto-update should either be allowed to modify running or not, but = this idea of allowing create but not allowing delete is wrong. You may easily have a =93must=94 or =93when=94 statement that checks that something = does not exist, in which case the current proposed behavior can lead to invalid configuration. Also, the current behavior does not state whether a = =93case=94 in a choice statement can be added? If you add one =93case=94 the other is = deleted. So, can I add a =93case=94? =20 Ch 3.1 ) =93If there exists any conflict, the configuration in the = should succeed.=94 It is hard to define what is a conflict. E.g. If the user deletes a data node, but it comes back when loading system, how do we know if this is a conflict because the user deleted it or if this is a new node that we = can be freely loaded into running/intended./intended. IMHO one more reason why system-data must not be modified in running/intended; then we don=92t = have this conflict.=20 =20 CH.3.2) Allowing a delete and then automatically reloading it is a very = bad idea. It is misleading for the user that a data node is in place after a successful delete. Also, after delete, it is reloaded; so, between a successful delete and the reloading there is a short interval where the = data node is not present? Dangerous. =20 Why don=92t we have a auto-reload after merge? Either allow Netconf/CLI/Restconf to modify such system data or not. A mixed approach = is not acceptable.=20 =20 Ch 5.3.2) So if I have a model Container aaa { Presence aaa; Leaf bbb {} } Where bbb is system data, but aaa is not then the following 2 = operations might lead to different results ? IMHO that is not acceptable: - Delete bbb - Replace aaa with an empty aaa container =20 Regards Balazs =20 P.S. I am partly new to the topic, so sorry if I repeat some questions. =20 --=20 Balazs Lengyel Senior Specialist Ericsson Hungary Ltd.=20 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com =20 ------=_NextPart_001_007A_01D78635.CBE0E060 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

MAJOR: =

The purpose of the draft = (the purpose of creating a new datastore) should be clearly stated. In = my view:

“There is a need to = validate configuration data against data created by the = system.”

 

What is the = purpose of system-configuration

Use-case A) =A0=A0=A0The system sets some values = because it knows what they shall be. In this case the client must not be = allowed to modify these values. We want to check configuration data = against these values. =A0E.g., AcmeHomeRouter has 5 interfaces called = eth0, eth1, eth,2, eth3 and WAN. The client should not try to add or = remove interfaces to this set.

Use-case B)=A0 =A0=A0The system provides initial = values for something that can be configured in many ways. In this case = the client is free to modify the system-defined values. E.g., an initial = set of NACM rules is provided. In this case any constraints based on the = system data are very weak, as the user can change the system-data = itself.

 

Use-case a) is very interesting and we actually = implemented non-standard support for it. I would welcome it in an RFC. =

I, myself tried to address this in = https://github.= com/netmod-wg/yang-next/issues/41

Use-case b) IMHO does not require any special support. = I will just load the initial configuration as a last step of a reset, = upgrade etc.

 

 

Can a client = remove or change a system-configuration data-node that is automatically = or manually copied to running/intended? =A0In use-case A) NO. In use = case B) yes.

Allowing some = modifications, but not others is IMHO misleading and not acceptable. = Assuming that additions are OK while delete is not could be incorrect = if, the absence of some data node is important for the network = node.

 

 

 

 

Ch.2.2) = “<system> should also immediately reset to its factory = default state.”

What is this =
state? It is undefined. I would rather say: <system> should be =
reloaded or recreated.

Factory-reset may or may not remove results of an = upgrade.

 

Ch.3)

“Update <running> =
with the system configuration change“
The =
auto-update should either be allowed to modify running or not, but this =
idea of allowing create but not allowing delete is wrong. You may easily =
have a “must” or “when” statement that checks =
that something does not exist, in which case the current proposed =
behavior can lead to invalid configuration. Also, the current behavior =
does not state whether a “case” in a choice statement can be =
added? If you add one “case” the other is deleted. So, can I =
add a “case”?
 
Ch 3.1 =
)
“If there exists any conflict, the =
configuration in the <running> should =
succeed.”
It is hard =
to define what is a conflict. E.g. If the user deletes a data node, but =
it comes back when loading system, how do we know if this is a conflict =
because the user deleted it or if this is a new node that we can be =
freely loaded into running/intended./intended. IMHO one more reason why =
system-data must not be modified in running/intended; then we =
don’t have this conflict. 
 
CH.3.2) =
Allowing a delete and then automatically reloading it is a very bad =
idea. It is misleading for the user that a data node is in place after a =
successful delete. Also, after delete, it is reloaded; so, between a =
successful delete and the reloading there is a short interval where the =
data node is not present? Dangerous.
 
Why =
don’t we have a auto-reload after merge? =A0Either allow =
Netconf/CLI/Restconf to modify such system data or not. A mixed approach =
is not acceptable. 
 
Ch 5.3.2) So =
if I have a model
Container =
aaa {
=A0 Presence =
aaa;
=A0 Leaf bbb =
{}
}<=
/span>
Where bbb is =
system data, but aaa is not then=A0 the following 2 operations might =
lead to different results ? IMHO that is not =
acceptable:
-        =
Delete =
bbb
-        =
Replace aaa =
with an empty aaa container
 

Regards Balazs

 

P.S. I am = partly new to the topic, so sorry if I repeat some = questions.

 

--

Balazs = Lengyel=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Senior = Specialist=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Ericsson Hungary Ltd.

Mobile: = +36-70-330-7909=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 email: = Balazs.Lengyel@ericsson.com

 

------=_NextPart_001_007A_01D78635.CBE0E060-- ------=_NextPart_000_0079_01D78635.CBE0B950 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDczMTE1NTkyNFowIwYJKoZIhvcNAQkEMRYEFETonObNuLmv 3rtLxBGeaLXywrFxMGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAG1U NWFNLNV9zzr7YOlcf3mdbbHjIBBBQE8mmDHPl+EjQbDDosXuTphHtxcpNmZdaoFnQdwMZNQPd4f0 K6J9zCEGbdkhDcVi5ad7XHW1BNCHEBg7y5MJV02oHPK6PEpVKFGHSpr7E+7yCCnpo9ejtg4JnhD9 yA9NwEGtv/gzAUz7AwTetpYw/2zaR2pETKE1xf7SXwEfNFQAHMI6Lw1Ay5OK89IiJC3L18SUsv9X JWQuRkXb9YV416OQiDf0n3cmp06blzkUk6zLgcDLDQI9p3W48Z2atVRwqM5WLdaSyye8CGkXaelw Cm4/g2HbgoHB5sAqSKfY6buAOXZ8aalsJsgAAAAAAAA= ------=_NextPart_000_0079_01D78635.CBE0B950-- From nobody Sat Jul 31 09:26:33 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D723E3A0C3E for ; Sat, 31 Jul 2021 09:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QejzKN9mOS1c for ; Sat, 31 Jul 2021 09:26:26 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on062d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::62d]) (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 C13263A0C3B for ; Sat, 31 Jul 2021 09:26:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MjwqAU2ehFWp/HISiqAGilHkPZgzU7cqiLVsuw5+EqyMHriy0XYqLQ7iSIs3/bEGyCLHrBnJrl3G+UMOo8rZxJc0tZBycmgK8UDxyThr6ivWcBwNalS4tIki+gAKPbi0RwochZgZCQJMq7fZBJzG9T10BB99cA5SZlNt5AdakYRHRnLFhcIZWr9pbXImO2Vme1gM3jX+8jhMDY+PfUxmcP8SbsoSzTHr7Ol1LQybrfbHSuIkIUzd4TwURZWQRamv96rdKkrlNpmdPhSAd5Ae1pHC23thflgcXWg3Ktv/n6CdTLHBn/nbCrcvBFv5BoXWgIMmBa/u7pt/FOaksHO6sg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=no5fwpKnDyahwiyw0888z3RB9BYW8mDPImrKIcrb0c8=; b=ZCsK+5AW7/lhSz6DwTgqH4xoWvmpLHOQvuwAbeiD1w7p5oi+m7pJGtE7vhHqK+gSHRRZ5488wSPThbiry+oKEu44nJ3hIqF5GhQ5Qr5lLd9Qw/i4XZqcavjmkOKf8Vx49gnOLOXlUN0ksGJYgDE8Kpz8XsIH3Dx24EsRY8aC3dbuK0cHnlcQcl6ehmFyTR3a+t7MTTN+co1y38CbDNyP2pP9odK9rguVUsEfgqwjfbjCoWhuKuNCGHIk0FHGBjsLFPOq9jK8OvTtuM5iWk+6bC9bIjNZGUXIw1n0+6VP6ivF6yVxx8w2pAFLpoWTGRMBoOCLs9LNEFN1gU5si3wdPQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=no5fwpKnDyahwiyw0888z3RB9BYW8mDPImrKIcrb0c8=; b=DnRykost/uUPjvWjyhqGNfB39tseZMzdhtjR1l0DDh0sy8oEqcktXAwLeaUBHDAUBsFXrFnAue2fggr4KIOKsM3tmjCa90PT49VB87lX6n5279jAkVL/4Ou5LAAYE0ZbYcJ3lzOejqwi/WHJR/KA4D4J8q8ee0mlWoxcvrVJLPo= Received: from AM8PR07MB8230.eurprd07.prod.outlook.com (2603:10a6:20b:325::15) by AM8PR07MB8122.eurprd07.prod.outlook.com (2603:10a6:20b:36d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4352.11; Sat, 31 Jul 2021 16:26:07 +0000 Received: from AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625]) by AM8PR07MB8230.eurprd07.prod.outlook.com ([fe80::dd5e:8a67:d8c3:4625%9]) with mapi id 15.20.4373.018; Sat, 31 Jul 2021 16:26:07 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: "maqiufang (A)" , Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] system configuration sync mechanism Thread-Index: Add4ieaMV4M1zhk1St6ROfyHhlohlAAAAuNAAEg6RwAAIHjEAAJpoReAAI03jwAAB2jE4A== Date: Sat, 31 Jul 2021 16:26:07 +0000 Message-ID: References: <5b76dae2175545959f0006b036efd647@huawei.com> <2d1262bc90fc49d08eb641365b959ea4@huawei.com> <0100017aab854793-eb989e55-8496-451b-84de-7f17cb0720d5-000000@email.amazonses.com> <0100017aee17493f-6b9b747c-f0f1-4a70-b929-aaa0350a555f-000000@email.amazonses.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 835bb2de-0f17-4453-0025-08d9543fe67c x-ms-traffictypediagnostic: AM8PR07MB8122: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oGEGzmduf9OjUyUsIkR+19M2vCSODkfsRFHR7uuwAxTXsjkQUQBrGx9nYyVwRPb2jr5rsEhssUGzRE7+ulZcNcj5slWpYWHdH7qR12dCxWkUfcmtoLfMqcvthXmqYbW0MxHO3T8l6sDIRGnXJ8RIlabVy+tPYgcU+E1T41WBTpAGES+Aukf1yoQB+YWjY2a/CLEcnbWtFewPstnCQEBDU9vU5P8AhvVZEbJQS3KGEuJfh0JJlstwEKa+6cTwvgm8t1YYm2mxAkSVlTU7u9CRn8QYY1cgZC0XjSROHxABpAoGLQE8GM73zVZGs0ULT90yocjfT0vQrbQ/xMkRSHAagikO6LAQfJGQAIQ3SvyySlRtz3aIfA0fy1xIt64hUIkgs/Fjwu41GtqC/gXioQixon/PLYK6Gb6BPmRgv2miWk0Dqt57ZSUGDD2yCbpQ2JHMUn3sOU8tOMTVTPtLrH02P/5eaLwdst8NLBwdHFRutTD3OOIOkS5q6oHWJ0kbGlMQrf6uJb99+u9fhDB3VZxYH69xcs+r2h6wupjnbqznQCBmJFERrUoJtBNlx6Wxs/HekAdnJiH8U5S2gbYuXpcFdXwTjMGGM3EibfSL9gsbLQ37OHqoO85hK2COQx8L/fptx5wDRkT4xFhcC3m4sq+CF42RaAQrYWuhAofGt5kyAkaHSKwmDeaxdpENEjIExUOVuQxDVVGqDQVzxeE95wWXuzjHOHJwgks+sQqy0p0/MzKGuE3kI11bOURWG1FgVzhnobLfgPYgy7Q5ulUIhiA2/gJv1ZxDSoo4wBZjyFBKL6750Z0RAu9WDXBVILZTCToKRV1uGY/KS6F7qt3TMi/WdQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8230.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(5660300002)(71200400001)(66446008)(186003)(7696005)(85202003)(6506007)(9686003)(85182001)(316002)(83380400001)(38100700002)(38070700005)(9326002)(64756008)(8676002)(110136005)(99936003)(966005)(66574015)(76116006)(66616009)(26005)(18074004)(508600001)(30864003)(33656002)(8936002)(53546011)(86362001)(66556008)(122000001)(2906002)(166002)(66476007)(52536014)(55016002)(66946007)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bmFDZXZZaXBraWtYL3NVZFBlSE5iejZwelJ5NHBuSktneGhFUngzdDJlK3U2?= =?utf-8?B?djRIaUhDUjY3YkRwY0FOSnhuQ3hBcG9paU5DNEgxdlRrRDgxTitXZWU5eGE3?= =?utf-8?B?RzhBaHNGT0VzbmJhSXJSY1UvOHR5cFJLcDExeEZ0dERXMW9LOGFwcXhJdUVj?= =?utf-8?B?YmNRVnhPRW9reXEvTEhJb28zTmp0UjZZNVROeElnbXp4TllpZ1hqRG9ndUhB?= =?utf-8?B?SGN3ejcvamFraWtQeXRPOEVEdFJvdGl3R3p4Z2ZEdG1SUlNsNjZWZjdSYXRB?= =?utf-8?B?QndFNUZZaTdFMm1Yd0lxbHVlNVEzQ0JsMXkvZ0hDZnV1NTFUdUxJb1RKM0VD?= =?utf-8?B?Rk9zMnNYNFlOY29sVTNlUFJ3MThUUzVuQlAwbldYR0lsUXdveHNmcFBabnh6?= =?utf-8?B?dW5qZllJTkEzTkdMZVRoVXM0TjFNVTJzZ2t3S3RPb085MEx5cytJRWV2Z0tH?= =?utf-8?B?c05KZUZSczUvYnlpZTBwS3pndlJQOWppZUEwNGNmVERuOThYY2ZiQVd5RGJy?= =?utf-8?B?NkpFbytrZUd4RXBtVWNRTGYzUTF6WlNXK1FHYXpDWGRNcWRTeTI5a3gvTTRl?= =?utf-8?B?dk5GeTN3alkwbCt1MTNUb1cvd1MvcWRiSEdRYzNvS2hJWU1sbkw1RnV6RVFM?= =?utf-8?B?bk53TWpabTk2cnY5aWtmMjJ4MEtnYmdnWUdDVGVycWNyVStMKzBtSXFMSFZt?= =?utf-8?B?ejFkZXBETmNidVNCV0N5T0dqMklzbWNHWkNRTUptZmN2UzJ3ZjFqSXRCdnhW?= =?utf-8?B?MUI5WjdjK1VYcUt3azJIVFFBdVVKK3cxa2h1N3RRQWFpenJybHBCT1l6VFQ4?= =?utf-8?B?OXNwWUtyRkt4Q0wvbkh2QnFNY0h3OWJpVEpiVDgyQlA2OXp6SmVab2E2WXdt?= =?utf-8?B?MCtJZWZaamN1QzlJSlNBdnVMQUppcmFWU3U2OEpWUWtnYmxTRzBsalY4U3Vh?= =?utf-8?B?bk10d1pwbkh4S1cxdGRlejI4NE1oTzBxNjc5dXRPNDhWTnJva1doTDFjV3JL?= =?utf-8?B?YUlKSU5QaytGbXhRKzhjbEhLUFRBcklCYW9RUjZ1dUIzMjJyMFVqNVRxV0tp?= =?utf-8?B?TXNnYlNBMXhhYzRTaGJSR0FPMGNERGJhWDJWWnFyVVRaTWV0WmNDMWhGb1M4?= =?utf-8?B?Q0dnaFpmRTYwRFZEZUs1OVZZQ1lIMEc2OFNUcmRyL2pBRkZvNlBOTEFiS0VG?= =?utf-8?B?YjdMcmQ0S2UyMnM3T05veHZXcTV6UnB3eFBWNGFhUlNkbU0wYWsraGthWTQ3?= =?utf-8?B?bEhWQ0hHTzJpVWFtZTVhYzFuL0hrbDhCTUNZZVBZSWFYd2pVY2NUR3ROVEhy?= =?utf-8?B?TVljUmUrVG9OR0p2UERRS1cybWd6ZTBVUGp5enhuVCtlM1FIbk1VN1VORmd4?= =?utf-8?B?K1hubzZWR1FFYnYyV0NOb243aTV4WWZiZ2JIRm9JQnNCQURLQlRkeisxcXc1?= =?utf-8?B?T2NqeFUvVFRrcnJDOXFWTXkrcnh1dGdMR24vQXduWkRZd2tVNTZOaklhdFZ4?= =?utf-8?B?MFl2U3VDODVaajlxZmhYbnFWc2RtZUFPTVJ2WUYrM2cvMlhKeGpsLzhrdnpX?= =?utf-8?B?UUdzNXdpamRtcU8wcWwydWpKSnp2L1ozZFZtRUFBcXc4RFFPREVhd2FjeGNi?= =?utf-8?B?ZVgzZDVSSGhZUzIwZXpxV0cxRk1sK05GdzR1cUJEcmM4SFpFS2xYY3Zhejky?= =?utf-8?B?YTF2RjNqWk9ZZHo1dGUyYXN4bkJmOCsxdEJRbGhUbnR1OUxwSGhkbUJBUWRY?= =?utf-8?Q?OnKDD3Hses2Ngm7vn0=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A3_01D78639.7EE5B480" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8230.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 835bb2de-0f17-4453-0025-08d9543fe67c X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2021 16:26:07.4661 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: W2hFcaWnGnj/Cff2iAwk82K2p8U2h1F2JseTX6kRnBPfXKQy/Bze/y8smnTeICiJUfNt75LvaVMqrER9fHeLGVBO+lAr0B62qEAGKgET/I0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB8122 Archived-At: Subject: Re: [netmod] system configuration sync mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2021 16:26:32 -0000 ------=_NextPart_000_00A3_01D78639.7EE5B480 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00A4_01D78639.7EE5B480" ------=_NextPart_001_00A4_01D78639.7EE5B480 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, Sorry for going back to the basics, but IMHO it is needed here. So as I = see understand the problem: The purpose of the draft and some principles should be clearly stated. = In my view:=20 =20 P1) =E2=80=9CThere is a need to validate configuration data against data = created by the system.=E2=80=9D =20 We also have some principles: P2) We want the running datastore to contain exactly what the operator = has written there =20 >From this it flows that=20 P3) the running/intended configuration MAY become invalid if the = system-data changes.=20 But P4) rfc8342#section-5.3.4 MUST always be valid =20 P3 and P4 contradict each other. The only way to resolve this IMHO is to = say that system-data changes only at upgrade. If the upgrade = can=E2=80=99t end up with a valid configuration (after whatever = processing) then it MUST fail. =20 IMHO If we move the system-data into a separate datastore that does not help. = When I update the running configuration the validation will depend on = system-data either in the system or in the intended datastore. Debugging = a configuration distributed over multiple datastores is difficult. IMHO we should just introduce a new datatype beside config=3Dtrue and = config=3Dfalse, let=E2=80=99s call it system-data or = read-only-config=3Dtrue. System-data would be the same type as config=3Dtrue except it is not = writable by Netconf/Restconf/CLI/SNMP, etc. only by the system itself. This would allow us to define and populate system-data in both = running/intended datastores. It would be visible in the same context.=20 System-data would be static, the operator would not be able to modify = it, so impact on netconf/Restconf operations would be trivial. =20 As I see it this is the same problem that we discussed in = https://github.com/netmod-wg/yang-next/issues/41. =20 I know this is a radical change, but I think using a new YANG extension = to create a read-only config=3Dtrue datatype is a much cleaner solution. = One which some companies have already implemented. If I misunderstood your intent, then sorry. =20 Regards Balazs =20 From: netmod On Behalf Of maqiufang (A) Sent: 2021. j=C3=BAlius 31., szombat 14:33 To: Kent Watsen ; netmod@ietf.org Subject: Re: [netmod] system configuration sync mechanism =20 Hi, Kent,=20 Thanks for helping me revive this thread, which is exactly what I want = to do.:) There was not a very fully discussion due to time constraints, but we = did see some valuable points here, thank you everyone for sharing your = views. =20 Regarding option2, I am still unsure how will things go if there is no = (I think it was raised by Balazs, hopefully Balazs can also = add something here)? Should be implemented along with = ? =20 Option 3 is still unclear, e.g., whether the is copied into = automatically or manually? If auto-copy is not a good idea = because it violates the definition of , whether manual-copy is = performed towards part or all of the system configurations created in = ? Should we copy the entire into ? Or should there be as = few system configuration data items in as possible? Anyway, I agree that option3 may still incur a failed validation of = when the operators reference the system configuration which is = produced through the expansion of the system-defined templates. If the existing mechanism(e.g., edit-config)is sufficient to define = referenced system data item in , it seems that the flow marked = in option3 from to can be removed, then it looks no = difference between option1 and option3. =20 Best Regards, Qiufang Ma =20 From: netmod [ = mailto:netmod-bounces@ietf.org] On Behalf Of Kent Watsen Sent: Thursday, July 29, 2021 1:09 AM To: netmod@ietf.org Subject: Re: [netmod] system configuration sync mechanism =20 WG, =20 Regarding yesterday=E2=80=99s datastore presentation, there = seemed to be support for "Option #2=E2=80=9D, which is to have = merge into . =20 It was noted that this then would mean that client-validation of = would necessitate understanding how the merge works, to expand = templates, resolve leafrefs, etc. =20 My thoughts are, so? =20 =20 Firstly, a client that doesn=E2=80=99t understand that there may be some = defined configuration will, for the most part, be none the = wiser. The client *will* discover configuration in = , but this is already the case today. One new thing is = that should use =E2=80=9Corigin:system=E2=80=9D for = configuration originating from the datastore. This last point = might surprise clients=E2=80=A6as the definition of = =E2=80=9Cwith-origin=E2=80=9D doesn=E2=80=99t state that clients must = ignore any unrecognized =E2=80=9Corigin=E2=80=9D identities: = https://datatracker.ietf.org/doc/html/rfc8527#section-3.2.2. =20 Secondly, no shared object defined in will be activated until = client-supplied config references it. But any client able to do this = already knows how merges into and is accounting for = it. =20 Thoughts? =20 Kent =20 =20 On Jul 16, 2021, at 6:24 AM, maqiufang (A) > wrote: =20 Hi, Kent, Please see my reply inline. =20 From: Kent Watsen [ = mailto:kent+ietf@watsen.net]=20 Sent: Friday, July 16, 2021 2:55 AM To: maqiufang (A) < = maqiufang1@huawei.com> Cc: netmod@ietf.org Subject: Re: [netmod] system configuration sync mechanism =20 Hi Qiufang, =20 [snip] The question is if the server implementation prunes dangling/unused = objects when is applied, updating . My = assumption is that the server will discard any object that = doesn=E2=80=99t actually impact the running configuration of the system = (i.e., values are consumed by the underlying operating system, drivers, = etc.). Thusly, it is my opinion that only the referenced objects are = applied. Hence why, to answer your last question, I wrote that these = configurations (manufacturer-defined objects) are not applied = immediately but only after they are referenced. Makes sense? [Qiufang Ma] Yes, try to sum up our discussion about the categories of = the system configuration: * Physical-resource-dependent--> whether this sort of system = configuration exists in dependents on if the physical resource = is present(e.g., physical interface). * Physical-resource-independent-->which is provided by the device = system o Further classification from the perspective of = =E2=80=9Capplied=E2=80=9D time(dependents on whether the system = configuration impacts the running of the system) * Config that is applied immediately(e.g., the loopback, the predefined = minimum length of password=E2=80=A6) * Config that is applied only after being referenced by other = configs(e.g, definitions for applications ftp/tftp=E2=80=A6) o Further classification from the perspective of generation time * Config that is generated unconditionally at each boot time(e.g, = loopback, predefined minimum length of password, ftp/tftp=E2=80=A6) * Config that is generated conditionally during the device = running(e.g., system-generated local-port and remote-port for a new = established BGP connection) =20 Keep in mind that what is described above is just one aspect of what can = be in . In addition to defining reference-able objects, = can also define/apply configuration immediately (e.g., the = loopback interface). That is, configuration not does not have to be = referenced in order to become activated. [Qiufang Ma] Noted. =20 =20 =20 Note that, by itself would not pass validation, due to missing = leafrefs. Thankfully, NMDA never says that validation runs on = . But once and have been merged, to become = , the result does pass validation. [Qiufang Ma] The referenced instance must also exist for the data to be = valid since the require-instance defaults to true if not present. Is = this what you had in your mind? Yes, NMDA says that it is = which is subject to validation. But I also notice that In section 5.1.3 = of the NMDA:=E2=80=9D MUST always be a valid configuration data = tree, as defined in Section 8.1 of [RFC7950]. =E2=80=9D So my thought = here is that should also conform to the YANG model constraints = and that=E2=80=99s to say, a referenced system-defined data item should = also exists in . Therefore, if system configurations do not exist in , they = still need to be configured in manually in order for being = referenced. In this case, the original purpose of predefining some = system configurations for user convenience is lost. This is the reason = why we would like to define some mechanism here to synchronize = into .=20 =20 =20 I see in RFC 8342 " MUST always be a valid configuration data = tree, as defined in Section 8.1 of [RFC7950]=E2=80=9D. =20 But the question remains if it is possible for the system is able to = validate without, e.g., expanding templates. There may be a = 'leafref' or =E2=80=98must=E2=80=99 expression somewhere that will fail = because the evaluation occurs without expanding a template that supplies = the missing parts. [Qiufang Ma] On condition that should be valid, the operators = will need to retrieve from the or to get the = template-expanded configurations and then create them in the , = right? =20 My feeling is that it loses the meaning of predefining and seems no = differences between operator-defined configurations if operators have to = create system configures in before they use them. So I am = beginning to think, if it=E2=80=99s possible to expand the = system-defined template during the copying between and = ? =20 If this draft =E2=80=9Cupdates=E2=80=9D RFC 8342 (NMDA), then it can = supply a clarifying statement about what it means that " MUST = always be a valid configuration data tree=E2=80=9D. Either that, or an = Errata if it=E2=80=99s determined that the statement isn=E2=80=99t = correct. =20 You make a good technical point, but I think that we should *want* to = avoid having to copy (or ) configuration into = if we can avoid it. Agreed? [Qiufang Ma] tend to agree. Maybe we should try to avoid it, unless we = have to. =20 FWIW, also in RFC 8342, Section 5.1.4.: =20 is tightly coupled to . Whenever data is written to , the server MUST also immediately update and validate . =20 MAY also be updated independently of if the effect of a configuration transformation changes, but MUST always be a valid configuration data tree, as defined in Section = 8.1 of = [RFC7950]. =20 =20 =20 > I am wondering if these configuration will present in the = (which contains all the configuration actually used by the = device) before they=E2=80=99re referenced. =20 I think that it would depend in the specific server=E2=80=99s behavior, = regarding if *unused* predefine objects are present in . = Certainly the unused objects would not have to be present in = . If I were implementing the server, the unused objects = would NOT be present in . [Qiufang Ma] Yes, if the predefined system configurations is unused, = then I also tend to agree that they would not be present in = but may also depend on the vendor implementation. =20 =20 Yup, this is the same conclusion is in my response above. [Qiufang Ma] :) =20 > It would be good if we could determine if there are any other = "resource-independent=E2=80=9D configuration categories here. > [Qiufang Ma] Do you think there exists conditional system = configuration (if the preceding configurations you mentioned above is = not)? For example, if SSH is enabled on a device, SSH-related keys are = automatically generated. Such configurations are generated at the moment = when a special functionality is enabled. =20 I=E2=80=99m unsure what you mean in general by "conditional = configuration=E2=80=9D, but I can speak to your specific example. Though = I must preface my comments that I imagine there are a number of ways = servers might go about enabling `sshd`. What follows is my personal = view, forged by being around systems for awhile ;) =20 In general: =20 - `sshd` is NOT enabled by default. - `sshd` is enabled via a configuration knob. - the SSH host key is dynamically generated the first time = `sshd` is enabled. - the SSH host key itself is in (not ) =20 This view is consistent with the first paragraph in Section 3 of the = =E2=80=9Ckeystore=E2=80=9D draft (reproduced below): =20 3. Support for Built-in Keys =20 In some implementations, a server may support built-in keys. = Built- in keys MAY be set during the manufacturing process or be = dynamically generated the first time the server is booted or a = particular service (e.g., SSH) is enabled. =20 As a closing thought, this model (which I stated upfront may not be = universal) would have no presence-in or interaction-with = =E2=80=A6though, perhaps, there may be some predefined values = for what key-algorithms and/or key-lengths to use when generating the = SSH host key... [Qiufang Ma] By =E2=80=9Cconditional system configuration=E2=80=9D, I = was meaning some of the system configurations are not generated = immediately after the device is powered on. Instead, they are generated = when a specific condition is satisfied during the device running(e.g., a = functionality is enabled due to some client configurations). I am not = sure if it really exists, maybe not, just try to explore the = possibilities of various resource-independent system configurations.:)=20 =20 To this point I agree..as does RFC 8342 (NMDA), Section 5.3.3.: =20 Sometimes, resources are controlled by the device and the corresponding system-controlled data appears in (and disappears from) dynamically. If a system-controlled resource has matching configuration in when it appears, the system will try to apply the configuration; this causes the configuration to appear in eventually (if application of the configuration was successful). [Qiufang Ma] See above, as I summarized as the system configurations = that is generated conditionally during the device running. =20 Firstly, I again have to preface my comment that there are likely many = ways that templating mechanisms can be defined. But, in general, once = a templating mechanism has been defined, then it stands to reason that = templates could be defined either in (by operators) or in = (by the manufacturer). In one implementation I=E2=80=99m = familiar with, the templates are objects that are = referenced/parameterized by other parts of the configuration. (Same as = with the predefined objects discussion above.) =20 =20 To answer your questions: =20 1) Yes, it is my opinion that *activated* templates in will be = expanded and present in . =20 2) I would never suggest that the system-defined templates are present = in , though they may be referenced/parameterized by config in = . =20 3) if a config-template is configured in (i.e., it is = operator-defined) then, yes, the expanded configuration in is = "client configuration=E2=80=9D (note, "client configuration=E2=80=9D is = not a formal term). That said, it seems fair to say that a template = defined in and then referenced by "client = configuration=E2=80=9D in is also expanded as "client = configuration=E2=80=9D in . =20 4) I don=E2=80=99t not understand your last sentence, that the expansion = of templates are only present in . Maybe = you=E2=80=99re saying something subtle, e.g., that servers currently = don=E2=80=99t support GET on . But, in theory, the expansion = of templates should (IMO) be present in , so that = they may be subject to validation. Of course, all the = configuration (whether originating in or ) that is = successfully =E2=80=9Capplied=E2=80=9D will also be present in = . [Qiufang Ma] Assume that there is no and this work, the = expansion of system templates are only present in . Because = this is compatible with system configuration definition in NMDA. But if system configurations are only present in , the = predefined system configurations still need to be retrieved and created = into explicitly when being referenced. I think we=E2=80=99ve = reached an agreement on the need for to exist, and our main = point of disagreement is whether should be copied into = . Your point is that being merged into is enough to = make sure a success validation. But my understanding is that the = referenced system configuration data item must also exist in the = to obey the model constraints. =20 Yes, I believe that you provided an accurate description of the = difference in our opinions. Per my earlier response, you make a valid = technical point, my goal is to waive that interpretation to the side so = that a simpler solution can emerge. It would be good to get other = opinions on list, otherwise we=E2=80=99ll take it into the meeting. [Qiufang Ma] OK. Hopefully someone else would share some opinions here. = Otherwise let=E2=80=99s take this into the IETF meeting. =20 [BTW, in keeping with this thread moving from the NETCONF to the NETMOD = mailing lists, would it make sense to move the IETF 111 presentation = slot from NETCONF to NETMOD too? I think it does and, further, it would = help with scheduling (NETCONF is over, NETMOD is under). Would you be = okay with this? AD Rob and the NETCONF chairs discussed this morning, = and think it's okay, but would still need to confirm with the NETMOD = chairs.] [Qiufang Ma] I am happy with the proposal, if it=E2=80=99s also okay for = NETMOD chairs:-). I have sent an email to the NETMOD chairs to request = to move this presentation slot from NETCONF to NETMOD.=20 A new version of the draft will also be submitted to NETMOD when the = draft-submitting window reopens. > I=E2=80=99m beginning to think that: > =C2=B7 auto-copying into is likely never a good = idea, because it violates the definition of > [Qiufang Ma] I am quite aware that different datastores in NMDA = represents different views of data nodes. And represents a = configuration datastore holding the current configuration of the device. > Should we consider system configuration also be part of current = configuration of the device? From my perspective, the difference between = system configuration and client-configuration lies only in who provides = it. =20 holds the current *operator-specified* configuration of the = device. System-provided configuration is NOT specified by operators = (though system-defined objects may be referenced by operator-specified = config in ). I believe that this arrangement is consistent = with the definition of . Agreed? [Qiufang Ma] Yes. Actually we are not trying to violate the principles = of NMDA and the definition of . The issue we try to resolve = here is that system configurations cannot be used(referenced or = overwritten) by the operators directly and need to be created into = explicitly. This actually loses the meaning of = =E2=80=9Cpredefining and bringing convenience=E2=80=9D. If auto-copying = is not a good idea, what do you think about defining an RPC operation = for the operators to do the copy(which is also what Rob suggests at the = meeting)? =20 If we have to copy into , then I think that I agree an RPC = (?) would be better. [Qiufang Ma] From my perspective, is feasible but not = efficient because operators still need to retrieve = / firstly. If we could define a RPC to copy the = entire into , it seems more convenient for operators. = However, some system configurations which are not going to be referenced = or modified may also be copied into . I don't have a strong = feeling about which one is preferred. Anyway, we need to figure out = whether it would be fine for to missing referenced system = configurations. =20 You mention =E2=80=9Coverwritten=E2=80=9D by the operators? Why = wouldn=E2=80=99t the operators just define their own? For instance, if = they don=E2=80=99t like the vendor=E2=80=99s = =E2=80=9Cvendor-foobar=E2=80=9D object, they could copy/paste/edit their = own =E2=80=9Cmy-foobar=E2=80=9D object with the values needed, yes? [Qiufang Ma] Yes, defining their own would be okay. By overwriting, I = mean sometimes the operators would like to modify the specific system = configuration, e.g., the MTU value of a specified interface(identified = by its name). If the operators want to modify the system configurations, there is no = way but redefine them in . =20 =20 Best Regards, Qiufang Ma =20 =20 =20 > =C2=B7 having in doesn=E2=80=99t make sense, = since the tweaks wouldn=E2=80=99t go thru --> = validation. > =20 > I=E2=80=99m wondering if a model like below would work for everyone - = thoughts? > [Qiufang Ma] represents the configuration after all = configuration transformations to have been performed, so I = think it is only coupled to . > Anyway, the should also interacts with . = Agreed? =20 I don=E2=80=99t agree that must only be coupled to . = Specifically, I think that it is okay (compatible with NMDA) to define = a that also impacts . This is the only (IMO) sane = approach, as it enables the combination + to be = validated. [Qiufang Ma] Please see above. If is OK to miss referenced = system configuration, your proposal makes sense to me. =20 Ack. =20 Best Regards, Qiufang Ma=20 =20 =20 Kent // contributor =20 ------=_NextPart_001_00A4_01D78639.7EE5B480 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello,

Sorry for = going back to the basics, but IMHO it is needed here. So as I see = understand the problem:

The = purpose of the draft and some principles should be clearly stated. In my = view:

 

P1) =E2=80=9CThere is a need to validate = configuration data against data created by the = system.=E2=80=9D

 

We also have = some principles:

P2) We want the running datastore to contain = exactly what the operator has written = there

 

From this it = flows that

P3) the running/intended configuration MAY = become invalid if the system-data changes. =

But

P4) rfc8342#section-5.3.4 MUST always be = valid

 

P3 and P4 = contradict each other. The only way to resolve this IMHO is to say that = system-data changes only at upgrade. If the upgrade can=E2=80=99t end up = with a valid configuration (after whatever processing) then it MUST = fail.

 

IMHO

If we move = the system-data into a separate datastore that does not help. When I = update the running configuration the validation will depend on = system-data either in the system or in the intended datastore. Debugging = a configuration distributed over multiple datastores is = difficult.

IMHO we = should just introduce a new datatype beside config=3Dtrue and = config=3Dfalse, let=E2=80=99s call it system-data or = read-only-config=3Dtrue.

System-data = would be the same type as config=3Dtrue except it is not writable by = Netconf/Restconf/CLI/SNMP, etc. only by the system = itself.

This would = allow us to define and populate system-data in both running/intended = datastores. It would be visible in the same context. =

System-data = would be static, the operator would not be able to modify it, so impact = on netconf/Restconf operations would be trivial.

 

As I see it = this is the same problem that we discussed in https://github.= com/netmod-wg/yang-next/issues/41.

 

I know this = is a radical change, but I think using a new YANG extension to create a = read-only config=3Dtrue datatype is a much cleaner solution. One which = some companies have already implemented.

If I = misunderstood your intent, then sorry.

 

Regards = Balazs

 

From:<= /b> = netmod <netmod-bounces@ietf.org> On Behalf Of maqiufang = (A)
Sent: 2021. j=C3=BAlius 31., szombat 14:33
To: = Kent Watsen <kent+ietf@watsen.net>; = netmod@ietf.org
Subject: Re: [netmod] system configuration = sync mechanism

 

Hi, Kent,

Thanks for helping me revive this thread, which is exactly what I want = to do.:)

There was not a very fully discussion due to time constraints, but we = did see some valuable points here, thank you everyone for sharing your = views.

 

Regarding option2,  I am still unsure how will things go if there = is no <intended>(I think it was raised by Balazs, hopefully Balazs = can also add something here)? Should <system> be implemented along = with <intended>?

 

Option 3 is still unclear, e.g., whether the <system> is copied = into <running> automatically or manually? If auto-copy is not a = good idea because it violates the definition of <running>, whether = manual-copy is performed towards part or all of the system = configurations created in <system>?

Should we copy the entire <system> into <running>? Or = should there be as few system configuration data items in = <running> as possible?

Anyway, I agree that option3 may still incur a failed validation of = <running> when the operators reference the system configuration = which is produced through the expansion of the system-defined = templates.

If the existing mechanism(e.g., edit-config)is sufficient to define = referenced system data item in <running>, it seems that the flow = marked in option3 from <system> to <running> can be removed, = then it looks no difference between option1 and = option3.

 

Best Regards,

Qiufang Ma

 

From:<= /b> = netmod [mailto:netmod= -bounces@ietf.org] On = Behalf Of Kent Watsen
Sent: Thursday, July 29, 2021 1:09 = AM
To: netmod@ietf.o= rg
Subjec= t: Re: [netmod] system configuration sync = mechanism

 

WG,

 

Regarding = yesterday=E2=80=99s <system> datastore presentation, there seemed = to be support for "Option #2=E2=80=9D, which is to have = <system> merge into <intended>.

 

It was noted that this = then would mean that client-validation of <running> would = necessitate understanding how the merge works, to expand templates, = resolve leafrefs, etc.

 

My thoughts are, so? =   

 

Firstly, a client that = doesn=E2=80=99t understand that there may be some <system> defined = configuration will, for the most part, be none the wiser.   The = client *will* discover <system> configuration in = <operational>, but this is already the case today.  One new = thing is that <operational> should use = =E2=80=9Corigin:system=E2=80=9D for configuration originating from the = <system> datastore.  This last point might surprise = clients=E2=80=A6as the definition of =E2=80=9Cwith-origin=E2=80=9D = doesn=E2=80=99t state that clients must ignore any unrecognized = =E2=80=9Corigin=E2=80=9D identities: http= s://datatracker.ietf.org/doc/html/rfc8527#section-3.2.2.

 

Secondly, no shared = object defined in <system> will be activated until client-supplied = config references it.  But any client able to do this already knows = how <system> merges into <intended> and is accounting for = it.

 

Thoughts?

 

Kent

 

 

On Jul 16, 2021, at 6:24 AM, maqiufang (A) = <maqiufang1@huawei.com> = wrote:

 

Hi, Kent,

Please see my reply inline.

 

From:<= /b> = Kent Watsen [mailto:kent+i= etf@watsen.net] =
Sent: Friday, July 16, 2021 2:55 AM
To: maqiufang = (A) <maqiufang1@hu= awei.com>
Cc= : netmod@ietf.o= rg
Subjec= t: Re: [netmod] system configuration sync = mechanism

 

Hi Qiufang,

 

        &= nbsp;   [snip]

The question is if the = server implementation prunes dangling/unused objects when = <intended> is applied, updating <operational>.  My = assumption is that the server will discard any object that = doesn=E2=80=99t actually impact the running configuration of the system = (i.e., values are consumed by the underlying operating system, drivers, = etc.).  Thusly, it is my opinion that only the referenced objects = are applied.  Hence why, to answer your last question, I wrote that = these configurations (manufacturer-defined objects) are not applied = immediately but only after they are referenced.  Makes = sense?

[Qiufang Ma] Yes, try to sum up our discussion about the categories of = the system configuration:

=C2=B7       = Physical-resource-dependent--> whether this sort of system = configuration exists in <system> dependents on if the physical = resource is present(e.g., physical = interface).

=C2=B7       = Physical-resource-independent-->which is provided by the device = system

o   Further classification from the perspective of = =E2=80=9Capplied=E2=80=9D time(dependents on whether the system = configuration impacts the running of the = system)

=C2=A7  Config that is applied immediately(e.g., the loopback, the predefined = minimum length of password=E2=80=A6)

=C2=A7  Config that is applied only after being referenced by other = configs(e.g, definitions for applications = ftp/tftp=E2=80=A6)

o   Further classification from the perspective of generation = time

=C2=A7  Config that is generated unconditionally at each boot time(e.g, = loopback, predefined minimum length of password, = ftp/tftp=E2=80=A6)

=C2=A7  Config that is generated conditionally during the device running(e.g., = system-generated local-port and remote-port for a new established BGP = connection)

 

Keep in mind that what is = described above is just one aspect of what can be in <system>. =  In addition to defining reference-able objects, <system> can = also define/apply configuration immediately (e.g., the loopback = interface).  That is, configuration not does not have to be = referenced in order to become activated.

[Qiufang Ma] Noted.

 

 

 
Note that, =
<running> by itself would not pass validation, due to missing =
leafrefs.  Thankfully, NMDA never says that validation runs on =
<running>.  But once <running> and <system> have =
been merged, to become <intended>, the result does pass =
validation.
 =
[Qiufang Ma] The referenced instance must also exist for the data to be =
valid since the require-instance defaults to true if not present. Is =
this what you had in your mind? Yes, NMDA says that it is =
<intended> which is subject to validation. But I also notice that =
In section 5.1.3 of the NMDA:=E2=80=9D<running> MUST always be a =
valid configuration data tree, as defined  in Section 8.1 of =
[RFC7950]. =E2=80=9D So my thought here is that <running> should =
also conform to the YANG model constraints and that=E2=80=99s to say, a =
referenced system-defined data item should also exists in =
<running>.
T=
herefore, if system configurations do not exist in <running>, they =
still need to be  configured in <running> manually in order =
for being referenced. In this case, the original purpose of predefining =
some system configurations for user convenience is lost. This is the =
reason why we would like to define some mechanism here to synchronize =
<system> into <running>. =

 

 

I see in RFC 8342 = "<running> MUST always be a valid configuration data tree, as = defined in Section 8.1 of = [RFC7950]=E2=80=9D.

 

But the question remains = if it is possible for the system is able to validate <running> = without, e.g., expanding templates.  There may be a 'leafref' or = =E2=80=98must=E2=80=99 expression somewhere that will fail because the = evaluation occurs without expanding a template that supplies the missing = parts.

[Qiufang Ma] On condition that <running> should be valid, the = operators will need to retrieve from the <intended> or = <operational> to get the template-expanded configurations and then = create them in the <running>, right? =  

My feeling is that it loses the meaning of predefining and seems no = differences between operator-defined configurations if operators have to = create system configures in <running> before they use them. So I = am beginning to think, if it=E2=80=99s possible to expand the = system-defined template during the copying between <system> and = <running>?

 

If this draft = =E2=80=9Cupdates=E2=80=9D RFC 8342 (NMDA), then it can supply a = clarifying statement about what it means that "<running> MUST = always be a valid configuration data tree=E2=80=9D.  Either that, = or an Errata if it=E2=80=99s determined that the statement isn=E2=80=99t = correct.

 

You make a good technical = point, but I think that we should *want* to avoid having to copy = <system> (or <operational>) configuration into = <running> if we can avoid it.  Agreed?

[Qiufang Ma] tend to agree. Maybe we should try to avoid it, unless we = have to.

 

FWIW, also in RFC 8342, = Section 5.1.4.:

 

   <intended> is tightly =
coupled to <running>.  Whenever data is =
written
   =
to <running>, the server MUST also immediately update and =
validate
   =
<intended>.
 
   <intended> MAY also be =
updated independently of <running> if the
   effect of a configuration =
transformation changes, but <intended> MUST
   always be a valid =
configuration data tree, as defined in Sectio=
n 8.1
 =
  of [RFC7950].

 

 



 
> I am =
wondering if these configuration will present in the <operational> =
(which contains all the configuration actually used by the device) =
before they=E2=80=99re referenced.
 
I think =
that it would depend in the specific server=E2=80=99s behavior, =
regarding if *unused* predefine objects are present in =
<operational>.  Certainly the unused objects would not have =
to be present in <operational>.  If I were implementing the =
server, the unused objects would NOT be present in =
<operational>.
[=
Qiufang Ma] Yes, if the predefined system configurations is unused, then =
I also tend to agree that they would not be present in =
<operational> but may also depend on the vendor =
implementation.

 

 

Yup, this is the same = conclusion is in my response above.

[Qiufang Ma] :)

 



> It =
would be good if we could determine if there are any other =
"resource-independent=E2=80=9D configuration categories =
here.
> =
[Qiufang Ma] Do you think there exists conditional system configuration =
(if the preceding configurations you mentioned above is not)? For =
example, if SSH is enabled on a device, SSH-related keys are =
automatically generated. Such configurations are generated at the moment =
when a special functionality is enabled.
 
I=E2=80=99m =
unsure what you mean in general by "conditional =
configuration=E2=80=9D, but I can speak to your specific example. Though =
I must preface my comments that I imagine there are a number of ways =
servers might go about enabling `sshd`.  What follows is my =
personal view, forged by being around systems for awhile  =
;)
 
In =
general:
 
  =
       - `sshd` is NOT enabled by =
default.
  =
       - `sshd` is enabled via a =
configuration knob.
  =
       - the SSH host key is dynamically =
generated the first time `sshd` is enabled.
  =
       - the SSH host key itself is in =
<operational> (not <running>)
 
This view =
is consistent with the first paragraph in Section 3 of the =
=E2=80=9Ckeystore=E2=80=9D draft (reproduced =
below):
 
  =
       3.  Support for Built-in =
Keys
 
  =
          In some =
implementations, a server may support built-in keys.  =
Built-
  =
          in keys MAY be set =
during the manufacturing process or be =
dynamically
  =
          generated the first =
time the server is booted or a particular =
service
  =
          (e.g., SSH) is =
enabled.
 
As a =
closing thought, this model (which I stated upfront may not be =
universal) would have no presence-in or interaction-with =
<system>=E2=80=A6though, perhaps, there may be some predefined =
values for what key-algorithms and/or key-lengths to use when generating =
the SSH host key...
[=
Qiufang Ma] By =E2=80=9Cconditional system configuration=E2=80=9D, I was =
meaning some of the system configurations are not generated immediately =
after the device is powered on. Instead, they are generated when a =
specific condition is satisfied during the device running(e.g., a =
functionality is enabled due to some client configurations). I am not =
sure if it really exists, maybe not, just try to explore the =
possibilities of various resource-independent system configurations.:) =

 

To this point I agree..as = does RFC 8342 (NMDA), Section 5.3.3.:

 

   Sometimes, resources are =
controlled by the device and the
   corresponding =
system-controlled data appears in (and disappears =
from)
   =
<operational> dynamically.  If a system-controlled resource =
has
   =
matching configuration in <intended> when it appears, the system =
will
   try =
to apply the configuration; this causes the configuration =
to
   appear =
in <operational> eventually (if application of =
the
   =
configuration was successful).
[Qiufang Ma] See above, as I summarized as the system configurations =
that is generated conditionally during the device =
running.
 
Firstly, I =
again have to preface my comment that there are likely many ways that =
templating mechanisms can be defined.    But, in general, =
once a templating mechanism has been defined, then it stands to reason =
that templates could be defined either in <running> (by operators) =
or in <system> (by the manufacturer).  In one implementation =
I=E2=80=99m familiar with, the templates are objects that are =
referenced/parameterized by other parts of the configuration.  =
(Same as with the predefined objects discussion above.)  =

 
To answer =
your questions:
 
1) Yes, it =
is my opinion that *activated* templates in <system> will be =
expanded and present in <intended>.
 
2) I would =
never suggest that the system-defined templates are present in =
<running>, though they may be referenced/parameterized by config =
in <running>.
 
3) if a =
config-template is configured in <running> (i.e., it is =
operator-defined) then, yes, the expanded configuration in =
<intended> is "client configuration=E2=80=9D (note, =
"client configuration=E2=80=9D is not a formal term).  That =
said, it seems fair to say that a template defined in <system> and =
then referenced by "client configuration=E2=80=9D in =
<running> is also expanded as "client configuration=E2=80=9D =
in <intended>.
 
4) I =
don=E2=80=99t not understand your last sentence, that the expansion of =
<system> templates are only present in <operational>.  =
Maybe you=E2=80=99re saying something subtle, e.g., that servers =
currently don=E2=80=99t support GET on <intended>.  But, in =
theory, the expansion of <system> templates should (IMO) be =
present in <intended>, so that they may be subject to =
validation.   Of course, all the <intended> =
configuration (whether originating in <running> or <system>) =
that is successfully =E2=80=9Capplied=E2=80=9D will also be present in =
<operational>.
[=
Qiufang Ma] Assume that there is no <system> and this work, the =
expansion of system templates are only present in <operational>. =
Because this is compatible with system configuration definition in =
NMDA.
B=
ut if system configurations are only present in <operational>, the =
predefined system configurations still need to be retrieved and created =
into <running> explicitly when being referenced. I think =
we=E2=80=99ve reached an agreement on the need for <system> to =
exist, and our main point of disagreement is whether <system> =
should be copied into <running>. Your point is that being merged =
into <intended> is enough to make sure a success validation. But =
my understanding is that the referenced system configuration data item =
must also exist in the <running> to obey the model =
constraints.

 

Yes, I believe that you = provided an accurate description of the difference in our opinions. =  Per my earlier response, you make a valid technical point, my goal = is to waive that interpretation to the side so that a simpler solution = can emerge.  It would be good to get other opinions on list, = otherwise we=E2=80=99ll take it into the meeting.

[Qiufang Ma] OK.  Hopefully someone else would share some opinions = here. Otherwise let=E2=80=99s take this into the IETF = meeting.

 

[BTW, in keeping with = this thread moving from the NETCONF to the NETMOD mailing lists, would = it make sense to move the IETF 111 presentation slot from NETCONF to = NETMOD too?  I think it does and, further, it would help with = scheduling (NETCONF is over, NETMOD is under).  Would you be okay = with this?   AD Rob and the NETCONF chairs discussed this morning, = and think it's okay, but would still need to confirm with the NETMOD = chairs.]

[Qiufang Ma] I am happy with the proposal, if it=E2=80=99s also okay = for NETMOD chairs:-). I have sent an email to the NETMOD chairs to = request to move this presentation slot from NETCONF to NETMOD. =

A new version of the draft will also be submitted to NETMOD when the = draft-submitting window reopens.



 <bi=
g snip>
> =
I=E2=80=99m beginning to think that:
> =
=C2=B7         auto-copying into =
<running> is likely never a good idea, because it violates the =
definition of <running>
> =
[Qiufang Ma] I am quite aware that different datastores in NMDA =
represents different views of data nodes.  And <running> =
represents a configuration datastore holding the current configuration =
of the device.
> Should =
we consider system configuration also be part of current configuration =
of the device? From my perspective, the difference between system =
configuration and  client-configuration lies only in who provides =
it.
 
<running&=
gt; holds the current *operator-specified* configuration of the =
device.  System-provided configuration is NOT specified by =
operators (though system-defined objects may be referenced by =
operator-specified config in <running>).   I believe =
that this arrangement is consistent with the definition of =
<running>.  Agreed?
[=
Qiufang Ma] Yes. Actually we are not trying to violate the principles of =
NMDA and the definition of <running>.  The issue we try to =
resolve here is that system configurations cannot be used(referenced or =
overwritten) by the operators directly and need to be created into =
<running> explicitly. This actually loses the meaning of =
=E2=80=9Cpredefining and bringing convenience=E2=80=9D. If auto-copying =
is not a good idea, what do you think about defining an RPC operation =
for the operators to do the copy(which is also what Rob suggests at the =
meeting)?

 

If we have to copy into = <running>, then I think that I agree an RPC (<edit-config>?) = would be better.

[Qiufang Ma] From my perspective, <edit-config> is feasible but = not efficient because operators still need to retrieve = <system>/<operational> firstly. If we could define a RPC to = copy the entire <system> into <running>, it seems more = convenient for operators. However, some system configurations which are = not going to be referenced or modified may also be copied into = <running>. I don't have a strong feeling about which one is = preferred. Anyway, we need to figure out whether it would be fine for = <running> to missing referenced system = configurations.

 

You mention = =E2=80=9Coverwritten=E2=80=9D by the operators?  Why = wouldn=E2=80=99t the operators just define their own?  For = instance, if they don=E2=80=99t like the vendor=E2=80=99s = =E2=80=9Cvendor-foobar=E2=80=9D object, they could copy/paste/edit their = own =E2=80=9Cmy-foobar=E2=80=9D object with the values needed, = yes?

[Qiufang Ma] Yes, defining their own would be okay. By overwriting, I = mean sometimes the operators would like to modify the specific system = configuration, e.g., the MTU value of a specified interface(identified = by its name).

If the operators want to modify the system configurations, there is no = way but redefine them in = <running>.

 

 

Best Regards,

Qiufang Ma

 



 
 
> =
=C2=B7         having in =
<operational> doesn=E2=80=99t make sense, since the tweaks =
wouldn=E2=80=99t go thru <running> --> <intended> =
validation.
>  =

> =
I=E2=80=99m wondering if a model like below would work for everyone - =
thoughts?
> =
[Qiufang Ma] <intended> represents the configuration after all =
configuration transformations to <running> have been performed, so =
I think it is only coupled to =
<running>.
> =
Anyway, the <system> should also interacts with =
<operational>.  Agreed?
 
I =
don=E2=80=99t agree that <intended> must only be coupled to =
<running>.  Specifically, I think that it is okay (compatible =
with NMDA) to define a <system> that also impacts =
<intended>.   This is the only (IMO) sane approach, as =
it enables the combination =
<running> + <system> to be =
validated.
[=
Qiufang Ma] Please see above. If <running> is OK to miss =
referenced system configuration, your proposal makes sense to =
me.

 

Ack.

 



 Best Regards,
Qiufang Ma

 

 

Kent // = contributor

 

------=_NextPart_001_00A4_01D78639.7EE5B480-- ------=_NextPart_000_00A3_01D78639.7EE5B480 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8jCCBTgw ggMgoAMCAQICEQCVvhag9y5G8Xs5gnL6i82WMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1Rl bGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTA3MTAxODEyMDA1 MFoXDTMyMTAxODEyMDA1MFowNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlh U29uZXJhIFJvb3QgQ0EgdjEwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDCvusn8CGj 82kmVX6dxVUWkVz97yG/U4B6LdKRjGMx8Owk8MOl0nJ8EG30N7fl5nx56oy1gouuSLasANxldewq TV/Bh/UgZSuBqEc+iSOVMBaQf+hXB0jnGa6/RWexNxsGKv7e+ax9g/teuuSPl2e+S46NZAdXOFVp NDY9E0jvT+LTZh6kzxq3XjYz1LQGvRgB/XeEUABF9Yxd6CO8fv414e1Qe6kwjRnTCY5oZ12/PJcY U7spYsXKXnLBx5bU2y2gtB9pA+zq4lDxDDzwrPNTLfAc9e1sOTlzgBbIUrAjzeA+3N08R6C7NYri mGiLvuW/cu7S+qXtEu38mBipJnbcKEsQIBzTfxZ3Le1vgPdJu1MFu11ox9TIdRY/iVqL9xdH1Ezx 0ol5Pk09mKhh3joe0vheA+DByRyM041N05U2szdfY2ObMxTwLSZrU3yJjDLCbuw9IQA5yaFo4lCD LrA6K/M2oKwv5G9hwlEJOT6LU7m7Z9rcU7l2WTadQ+Ug4D0yYIUiUbfHM7vdFS+keKYHe4FGNgSG 3Xk1x5UsO7CjFzXlcx+0XFnv2uoQZXt60H+fs7QqNztwi5tbuSu37LJREpdTKVrU8BIQ3E8CuxKS L2LUP2lDfA3W/Fh1AYidWBZL3rqQ/0cBiQZq9l+ykGqzAqYCiL+zR34q2dX6aHg1TQIDAQABoz8w PTAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAL7kXGJOJPQMCP/w0wxo5JNJIj9EJ2+7bd6DZs6ozA38 9ZoG5XcUkeudQXuZKoTl//whwV3w5B9Xt3WpoV8CJv/Xx/dO3k/49xxGwHpPQCwiNfAZsdBrZyyw qODAQDc19oRcXOOvQnj+p8kNUOoNhHb2Ue+DU8Z6/w5WSS6PetYM5idU400KYHJizZEH1qW/yJlr 7cQZ5qtMETjFbzHibknIP3aAJgMmKeA29vYgU+MXcDQXnWNoHmvsw02GuBMwL11GDUdD1RuqWQ65 XI0GSK10h1/H/DFUQRPixyEOnuAeDeHAe0OFkMWKWMZlCnhX8sYjDwHZIEveD/uShXUqXHONbXsl kcruRa4GSwDM07FZUNo6iDspQ0ZelytUzlNvjUrnlvq/cQ5Ci3z9KKDQSMraxIFMu6JzkybI6wzW Joi2wCTPu71b63V96QiOhjMseXcJaaWJ/LNwkId2j9Miu0LOvXMLICYq0Js9cB4kbM2HdqkXlrfP DZL7jhipmEnRnv5gRHIhuRntwvUx8TlIiJAkdVQWrc70+GkUZDn7o7i6cEDHJxy/xFZT+mNl0PMc Dhb1a4ZYTRjU5A2OpZ1bkdx2JFA/xir72bectdbm0NnoGYsVcUitt+rYWYjUkL8Ws9nprFlhVMgc usrByuG5IEyPOpOJpaDMv9P2daR1lm1WMIIF7DCCA9SgAwIBAgIPAXUc1ROE7L9MPfu7eEiGMA0G CSqGSIb3DQEBCwUAMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwc RXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MzAeFw0yMDEwMTIxMjQyMDVaFw0yMzEwMTMxMjQy MDRaMFkxETAPBgNVBAoMCEVyaWNzc29uMRgwFgYDVQQDDA9CYWzDoXpzIExlbmd5ZWwxKjAoBgkq hkiG9w0BCQEWG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAIY9tW43KkX0v7F/PJBbw9U3ygqpHruC1COfeak4TXgZkHPCY+wATiveaId4 y8GstEVH3spxA+G4B5r4+wqbEEPJSjf6pRgOkdE6ORwlApyIJeWHPSC+NN8IeyErzZNIrZli3vpU V236s4Z8CL05QeXg6OnO8vIPzjKqOmNSxlSlFnxiBK1Tj+4lMqZmI9xyaQ+RRJyaWTQKOkEeaa6V 2i4N1Gicr7/5IJdoBB+oT5vCV3tO+B0ubC40f4vdVwu7nLgAgDJOBL4j7Op8BvNmLBmKdnlK0Vj+ nW1kFgCSNepVO7Fx08n4UEOufAp0RPI3z0AcnOwMJT5khqdz08xoI1kCAwEAAaOCAcEwggG9MB8G A1UdIwQYMBaAFBx7GZ6XnHasID3Y3OORauPbLaZTMB0GA1UdDgQWBBQQoIERhKwaNK1dOsySWsLF ygxQPTAOBgNVHQ8BAf8EBAMCBaAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBARIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwJgYDVR0R BB8wHYEbYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tMEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6 Ly9jcmwudHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMIGCBggrBgEFBQcBAQR2MHQwKAYIKwYBBQUHMAGGHGh0 dHA6Ly9vY3NwMi50cnVzdC50ZWxpYS5jb20wSAYIKwYBBQUHMAKGPGh0dHA6Ly9jYS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYzLmNlcjANBgkqhkiG9w0BAQsF AAOCAgEAMyuEx/Jnxv1chc1eA81RXqFyxv7056cNkVGgRJP5j9kNAFNreHI3yY6folHuWMrIeE7p ad1YZ87UrWiBU97CbV+zrOc2EqnlcLfBCKMT24gGw8jTcE+KeNPoh5QKBYNYf+evBhITv16N4N8B eU3hRCHHGvQiKow/aaWqsQcgDtQdTIzDpw8cNB6UzSzqwtmtVERsnNzVbp3Bv4/SbLB9TP+YZPKm Bw8jgNQ4w42O6vYhhtNLsGvDswJ/f1bYwfa50b99o14Pz23oGDYcWDOQ2snUXq/FlMxj4oJ0EbHY mzHiJe6rQMSyl6iMb6HZ+S8Syzf84hmlRHtVr8/t/6Jz3DxSE4dlS5fORnKXbAPdEHk9558SJcQp I9zgXsOzNw5O1Btu3Cb4URv1ycf43Km25PRHjoNiXjkOgig58tIOeWwxtTiSWGYLckpTlmw1Papz VlhBzEs302V+cFo2xHADqoGfoHHpJcUATonJgSzscVMGauKhaujqRte5NBVcysJPvxFjTThhOaA6 JrqboqyTpToAJ8Rz/PF8o8zpX5Or1yJ9LfNoT3Q6hSJsBE7nDyDylaeibvqo0MLFtvx+RguycgnC sJvnuy28hDilBxytQR7nuNWR6/6IDy5ZNSaY7/oksleJNAiUZ7A51mjoJvqHA2xCMKb5SzxywsBt 70MMJigwggbCMIIEqqADAgECAhBTuH6D4ZyZKJOwm0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDAS BgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1 MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0B AQEFAAOCAg8AMIICCgKCAgEA7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJ fpWKrNM30k5vu5norG4ZKlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxA vWVW1yC5S4Ubppk3Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX 6VXYgrpT05ZrJldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1J hNK4bvmbNJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2N S8CXs/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4DrwaOS0V NXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28MeMqku+/zR zdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5AuyCoqCEyn32C7U /V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+MHwwLQYIKwYBBQUH MAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggrBgEFBQcwAoY/aHR0cDov L3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY2Vy MBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMBAQIwOjA4BggrBgEF BQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJhLmNvbS9DUFMwSwYDVR0f BEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVy YXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBQcexmel5x2rCA92NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qW DNXr+nuqF+gTEjANBgkqhkiG9w0BAQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjp HUCyhltoFS7Q1CUBD0bOULWmYjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/ jqDMqBARxr8OUWOr0ZWa49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udG ZAamJ55drdw96AV9jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8 H4sVprPgvLBdK/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQC o6swZy0rI0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lD GJtepti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoqqJFB V9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwiNJjw5GRq Yb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggNQMIIDTAIBATBaMEcxCzAJBgNVBAYTAlNF MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MwIPAXUc1ROE7L9MPfu7eEiGMAkGBSsOAwIaBQCgggHLMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTIxMDczMTE2MjU1M1owIwYJKoZIhvcNAQkEMRYEFFRGk4kfe8Bn PfKmLDUS5lNjdeu4MGkGCSsGAQQBgjcQBDFcMFowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVy aWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAg8BdRzVE4Tsv0w9 +7t4SIYwawYLKoZIhvcNAQkQAgsxXKBaMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3Nv bjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIPAXUc1ROE7L9MPfu7eEiG MIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0D BzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIaMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqGSIb3DQEBAQUABIIBAATQ JPDOYcMsBC+6Np8WPyyI2EByFfsWnqLNNDRUtXB5c5zaSCtulH18MlAiCUgpri0YN+4Cn15mTcAg SuDegw2a0RFQC98Zv7FgBmdv+Zf5Lzh69rBgIOIHG1hVIZeZ0l9Lp7vkVxhSLXfLyhTP+oYj3xPH lQtYb0t7RceBk3M+R+QR5de/ACl8gqgeVFB8lrnji+dgH1x9v/bwvqTF65AJT79DHQsuPx3v2OPO OvaEsp8tBeA9ZU0o53WHGLJbX/9y8AN0mEk0VazwzFSMTVqZjnUXWXOVNCzsqQgitI040g/NcQoc R61vcM2UFAelRXJYcKQv6Rd0EDD8nVN5pR0AAAAAAAA= ------=_NextPart_000_00A3_01D78639.7EE5B480-- From nobody Sat Jul 31 09:54:25 2021 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2253A0DE9 for ; Sat, 31 Jul 2021 09:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.645 X-Spam-Level: X-Spam-Status: No, score=-0.645 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 6qpg_TycpsVJ for ; Sat, 31 Jul 2021 09:54:20 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3349E3A0DEC for ; Sat, 31 Jul 2021 09:54:18 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id b6so1964341lff.10 for ; Sat, 31 Jul 2021 09:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J/sa3xAKNbrWNKNo1IWJeeIoGPbeIYDhN6N+yv6Gabw=; b=E4phVt3iHfRCOi5yJcQjbgDWfVxtJsJDopNZ8uJbcRXcvhgbCyVoctFTDTd84SAdfG 6b2dzLO24JxnW/fYsQLwN3PRqCCVdu2mvT0fOERb0OGYlGQGDLOqZVd0oWppHpCa6Sfe DMVaSxpUmrkV9SV8AimDaMlpvqrPc4aIm3u0lQvdsre0Tw7wnS4XIxFqAWSt4Kda6s/z JqyYc8IpLwqCukUw2E7vVvNP/GE0pkUn3THWaR0dIafd6rB3vFvdULe36QwG7pQWrmLJ m5TymzGvUeUIeAoIgzGeRCWsNkQFcTnPHdBc02F/XE/GZUAvVmonGIdhn69wBhx+L3rG uvOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J/sa3xAKNbrWNKNo1IWJeeIoGPbeIYDhN6N+yv6Gabw=; b=Eg/eZfZDG6GC122UhnfknxJsjgDWq9+zekjPFaLXdoHwoas8JmngGt6l/UkHQFqtv2 KUiopLLHkgZi9YkV64U8SDz3EgqFC6xIT1aiPGBbPmVTGNilQ98S76u3oEkT0SniCkST CQQWwgdxtYHM8JSCcSwcXkqDudMpCPccK0tt8bn1W9NhXcOfZxrlX1r5ptKaM0JVJY7v F9xGwmx1daIQYJD1jprWM5OJ5a+k6bsNfeaz8rg4A4VwwtnHNHj0JUNCKnEKwLeMCDJ1 mm5jqR7tkY9VxTtB2oo+uH+DkxOKOkxszZWZoDz5xerg+iupaFjugZQMm17OhRNVq9Pt iR4A== X-Gm-Message-State: AOAM5316zixSgdp3ST/AXiaGrk0tV1KKjt9Wzpc4GIo2ZjxjDxZ52P1K f9JkW66somKg/Z4RYZpMRuE2mJDT6BPk2stVdsR+5g== X-Google-Smtp-Source: ABdhPJyeRSOatZGBRTbBK0lQOI41/OwIzsE1iQauGYXSBwld5a4Fhim3+J+RNu0Gom9MhurTUoHAbbx2ZAZvdgh9xKs= X-Received: by 2002:ac2:4824:: with SMTP id 4mr6245226lft.553.1627750451446; Sat, 31 Jul 2021 09:54:11 -0700 (PDT) MIME-Version: 1.0 References: <5b76dae2175545959f0006b036efd647@huawei.com> <2d1262bc90fc49d08eb641365b959ea4@huawei.com> <0100017aab854793-eb989e55-8496-451b-84de-7f17cb0720d5-000000@email.amazonses.com> <0100017aee17493f-6b9b747c-f0f1-4a70-b929-aaa0350a555f-000000@email.amazonses.com> In-Reply-To: From: Andy Bierman Date: Sat, 31 Jul 2021 09:53:59 -0700 Message-ID: To: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= Cc: "maqiufang (A)" , Kent Watsen , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007116f605c86e2f1e" Archived-At: Subject: Re: [netmod] system configuration sync mechanism X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2021 16:54:25 -0000 --0000000000007116f605c86e2f1e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jul 31, 2021 at 9:26 AM Bal=C3=A1zs Lengyel wrote: > Hello, > > Sorry for going back to the basics, but IMHO it is needed here. So as I > see understand the problem: > > The purpose of the draft and some principles should be clearly stated. In > my view: > > > > *P1) =E2=80=9CThere is a need to validate configuration data against data= created > by the system.=E2=80=9D* > > > > We also have some principles: > > *P2) We want the running datastore to contain exactly what the operator > has written there* > > > > From this it flows that > > *P3) the running/intended configuration MAY become invalid if the > system-data changes. * > > But > > *P4) rfc8342#section-5.3.4 MUST always be valid* > > > > P3 and P4 contradict each other. The only way to resolve this IMHO is to > say that system-data changes only at upgrade. If the upgrade can=E2=80=99= t end up > with a valid configuration (after whatever processing) then it MUST fail. > > > > IMHO > > If we move the system-data into a separate datastore that does not help. > When I update the running configuration the validation will depend on > system-data either in the system or in the intended datastore. Debugging = a > configuration distributed over multiple datastores is difficult. > > IMHO we should just introduce a new datatype beside config=3Dtrue and > config=3Dfalse, let=E2=80=99s call it system-data or read-only-config=3Dt= rue. > > System-data would be the same type as config=3Dtrue except it is not > writable by Netconf/Restconf/CLI/SNMP, etc. only by the system itself. > > This would allow us to define and populate system-data in both > running/intended datastores. It would be visible in the same context. > > System-data would be static, the operator would not be able to modify it, > so impact on netconf/Restconf operations would be trivial. > > > I agree a new datastore will just add complexity without any value. Your solution approach is better, but I think it would require a new YANG version to allow config node XPath to reference non-config nodes. Another solution is to model the referenced node as config=3Dtrue, but setu= p automatic NACM rules so no user editing is allowed. This works well for setting up an initial config that gets saved and not changed unless a reset is done. What if is what is NV-stored? When that occurs, the config changes from system to user config. Routers have been saving the combined config for decades. IMO the standards intentionally avoid discussing the conversion of a datastore to/from NV-storage. As I see it this is the same problem that we discussed in > https://github.com/netmod-wg/yang-next/issues/41. > > > > I know this is a radical change, but I think using a new YANG extension t= o > create a read-only config=3Dtrue datatype is a much cleaner solution. One > which some companies have already implemented. > +1 Actually, separate running and system would be a radical change, not this. Cleaner and less disruptive. If I misunderstood your intent, then sorry. > > > > Regards Balazs > > > Andy > *From:* netmod *On Behalf Of *maqiufang (A) > *Sent:* 2021. j=C3=BAlius 31., szombat 14:33 > *To:* Kent Watsen ; netmod@ietf.org > *Subject:* Re: [netmod] system configuration sync mechanism > > > > Hi, Kent, > > Thanks for helping me revive this thread, which is exactly what I want to > do.:) > > There was not a very fully discussion due to time constraints, but we did > see some valuable points here, thank you everyone for sharing your views. > > > > Regarding option2, I am still unsure how will things go if there is no > (I think it was raised by Balazs, hopefully Balazs can also add > something here)? Should be implemented along with ? > > > > Option 3 is still unclear, e.g., whether the is copied into > automatically or manually? If auto-copy is not a good idea > because it violates the definition of , whether manual-copy is > performed towards part or all of the system configurations created in > ? > > Should we copy the entire into ? Or should there be as > few system configuration data items in as possible? > > Anyway, I agree that option3 may still incur a failed validation of > when the operators reference the system configuration which is > produced through the expansion of the system-defined templates. > > If the existing mechanism(e.g., edit-config)is sufficient to define > referenced system data item in , it seems that the flow marked i= n > option3 from to can be removed, then it looks no > difference between option1 and option3. > > > > Best Regards, > > Qiufang Ma > > > > *From:* netmod [mailto:netmod-bounces@ietf.org ]= *On > Behalf Of *Kent Watsen > *Sent:* Thursday, July 29, 2021 1:09 AM > *To:* netmod@ietf.org > *Subject:* Re: [netmod] system configuration sync mechanism > > > > WG, > > > > Regarding yesterday=E2=80=99s datastore presentation, there seem= ed to be > support for "Option #2=E2=80=9D, which is to have merge into . > > > > It was noted that this then would mean that client-validation of > would necessitate understanding how the merge works, to expand templates, > resolve leafrefs, etc. > > > > My thoughts are, so? > > > > Firstly, a client that doesn=E2=80=99t understand that there may be some = > defined configuration will, for the most part, be none the wiser. The > client *will* discover configuration in , but this = is > already the case today. One new thing is that should use > =E2=80=9Corigin:system=E2=80=9D for configuration originating from the datastore. > This last point might surprise clients=E2=80=A6as the definition of =E2= =80=9Cwith-origin=E2=80=9D > doesn=E2=80=99t state that clients must ignore any unrecognized =E2=80=9C= origin=E2=80=9D > identities: https://datatracker.ietf.org/doc/html/rfc8527#section-3.2.2. > > > > Secondly, no shared object defined in will be activated until > client-supplied config references it. But any client able to do this > already knows how merges into and is accounting for i= t. > > > > Thoughts? > > > > Kent > > > > > > On Jul 16, 2021, at 6:24 AM, maqiufang (A) wrote: > > > > Hi, Kent, > > Please see my reply inline. > > > > *From:* Kent Watsen [mailto:kent+ietf@watsen.net ] > *Sent:* Friday, July 16, 2021 2:55 AM > *To:* maqiufang (A) > *Cc:* netmod@ietf.org > *Subject:* Re: [netmod] system configuration sync mechanism > > > > Hi Qiufang, > > > > * [snip]* > > The question is if the server implementation prunes dangling/unused > objects when is applied, updating . My assumptio= n > is that the server will discard any object that doesn=E2=80=99t actually = impact the > running configuration of the system (i.e., values are consumed by the > underlying operating system, drivers, etc.). Thusly, it is my opinion th= at > only the referenced objects are applied. Hence why, to answer your last > question, I wrote that these configurations (manufacturer-defined objects= ) > are not applied immediately but only after they are referenced. Makes > sense? > > *[Qiufang Ma] Yes, try to sum up our discussion about the categories of > the system configuration:* > > =C2=B7 *Physical-resource-dependent--> whether this sort of system > configuration exists in dependents on if the physical resource i= s > present(e.g., physical interface).* > > =C2=B7 *Physical-resource-independent-->which is provided by the de= vice > system* > > o *Further classification from the perspective of =E2=80=9Capplied=E2= =80=9D > time(dependents on whether the system configuration impacts the running o= f > the system)* > > =C2=A7 *Config that is applied immediately(e.g., the loopback, the prede= fined > minimum length of password=E2=80=A6)* > > =C2=A7 *Config that is applied only after being referenced by other > configs(e.g, definitions for applications ftp/tftp=E2=80=A6)* > > o *Further classification from the perspective of generation time* > > =C2=A7 *Config that is generated unconditionally at each boot time(e.g, > loopback, predefined minimum length of password, ftp/tftp=E2=80=A6)* > > =C2=A7 *Config that is generated conditionally during the device > running(e.g., system-generated local-port and remote-port for a new > established BGP connection)* > > > > Keep in mind that what is described above is just one aspect of what can > be in . In addition to defining reference-able objects, > can also define/apply configuration immediately (e.g., the loopback > interface). That is, configuration not does not have to be referenced in > order to become activated. > > *[Qiufang Ma] Noted.* > > > > > > > > Note that, by itself would not pass validation, due to missing = leafrefs. Thankfully, NMDA never says that validation runs on . = But once and have been merged, to become , the= result does pass validation. > > [Qiufang Ma] The referenced instance must also exist for the data to be = valid since the require-instance defaults to true if not present. Is this w= hat you had in your mind? Yes, NMDA says that it is which is sub= ject to validation. But I also notice that In section 5.1.3 of the NMDA:=E2= =80=9D MUST always be a valid configuration data tree, as defined = in Section 8.1 of [RFC7950]. =E2=80=9D So my thought here is that should also conform to the YANG model constraints and that=E2=80=99s to s= ay, a referenced system-defined data item should also exists in . > > Therefore, if system configurations do not exist in , they still= need to be configured in manually in order for being referenced= . In this case, the original purpose of predefining some system configurati= ons for user convenience is lost. This is the reason why we would like to d= efine some mechanism here to synchronize into . > > > > > > I see in RFC 8342 " MUST always be a valid configuration data > tree, as defined in Section 8.1 of [RFC7950]=E2=80=9D. > > > > But the question remains if it is possible for the system is able to > validate without, e.g., expanding templates. There may be a > 'leafref' or =E2=80=98must=E2=80=99 expression somewhere that will fail b= ecause the > evaluation occurs without expanding a template that supplies the missing > parts. > > *[Qiufang Ma] On condition that should be valid, the operators > will need to retrieve from the or to get the > template-expanded configurations and then create them in the , > right? * > > *My feeling is that it loses the meaning of predefining and seems no > differences between operator-defined configurations if operators have to > create system configures in before they use them. So I am > beginning to think, if it=E2=80=99s possible to expand the system-defined= template > during the copying between and ?* > > > > If this draft =E2=80=9Cupdates=E2=80=9D RFC 8342 (NMDA), then it can supp= ly a clarifying > statement about what it means that " MUST always be a valid > configuration data tree=E2=80=9D. Either that, or an Errata if it=E2=80= =99s determined > that the statement isn=E2=80=99t correct. > > > > You make a good technical point, but I think that we should *want* to > avoid having to copy (or ) configuration into > if we can avoid it. Agreed? > > *[Qiufang Ma] tend to agree. Maybe we should try to avoid it, unless we > have to.* > > > > FWIW, also in RFC 8342, Section 5.1.4.: > > > > is tightly coupled to . Whenever data is written > > to , the server MUST also immediately update and validate > > . > > > > MAY also be updated independently of if the > > effect of a configuration transformation changes, but MUST > > always be a valid configuration data tree, as defined in Section 8.1 <= https://datatracker.ietf.org/doc/html/rfc7950#section-8.1> > > of [RFC7950] . > > > > > > > > > > > I am wondering if these configuration will present in the = (which contains all the configuration actually used by the device) before = they=E2=80=99re referenced. > > > > I think that it would depend in the specific server=E2=80=99s behavior, r= egarding if *unused* predefine objects are present in . Certa= inly the unused objects would not have to be present in . If = I were implementing the server, the unused objects would NOT be present in = . > > [Qiufang Ma] Yes, if the predefined system configurations is unused, then= I also tend to agree that they would not be present in but m= ay also depend on the vendor implementation. > > > > > > Yup, this is the same conclusion is in my response above. > > *[Qiufang Ma] :)* > > > > > > > It would be good if we could determine if there are any other "resource= -independent=E2=80=9D configuration categories here. > > > [Qiufang Ma] Do you think there exists conditional system configuration= (if the preceding configurations you mentioned above is not)? For example,= if SSH is enabled on a device, SSH-related keys are automatically generate= d. Such configurations are generated at the moment when a special functiona= lity is enabled. > > > > I=E2=80=99m unsure what you mean in general by "conditional configuration= =E2=80=9D, but I can speak to your specific example. Though I must preface = my comments that I imagine there are a number of ways servers might go abou= t enabling `sshd`. What follows is my personal view, forged by being aroun= d systems for awhile ;) > > > > In general: > > > > - `sshd` is NOT enabled by default. > > - `sshd` is enabled via a configuration knob. > > - the SSH host key is dynamically generated the first time `sshd= ` is enabled. > > - the SSH host key itself is in (not ) > > > > This view is consistent with the first paragraph in Section 3 of the =E2= =80=9Ckeystore=E2=80=9D draft (reproduced below): > > > > 3. Support for Built-in Keys > > > > In some implementations, a server may support built-in keys. = Built- > > in keys MAY be set during the manufacturing process or be dyn= amically > > generated the first time the server is booted or a particular= service > > (e.g., SSH) is enabled. > > > > As a closing thought, this model (which I stated upfront may not be unive= rsal) would have no presence-in or interaction-with =E2=80=A6though= , perhaps, there may be some predefined values for what key-algorithms and/= or key-lengths to use when generating the SSH host key... > > [Qiufang Ma] By =E2=80=9Cconditional system configuration=E2=80=9D, I was= meaning some of the system configurations are not generated immediately af= ter the device is powered on. Instead, they are generated when a specific c= ondition is satisfied during the device running(e.g., a functionality is en= abled due to some client configurations). I am not sure if it really exists= , maybe not, just try to explore the possibilities of various resource-inde= pendent system configurations.:) > > > > To this point I agree..as does RFC 8342 (NMDA), Section 5.3.3.: > > > > Sometimes, resources are controlled by the device and the > > corresponding system-controlled data appears in (and disappears from) > > dynamically. If a system-controlled resource has > > matching configuration in when it appears, the system will > > try to apply the configuration; this causes the configuration to > > appear in eventually (if application of the > > configuration was successful). > > *[Qiufang Ma] See above, as I summarized as the system configurations tha= t is generated conditionally during the device running.* > > > > Firstly, I again have to preface my comment that there are likely many wa= ys that templating mechanisms can be defined. But, in general, once a te= mplating mechanism has been defined, then it stands to reason that template= s could be defined either in (by operators) or in (by th= e manufacturer). In one implementation I=E2=80=99m familiar with, the temp= lates are objects that are referenced/parameterized by other parts of the c= onfiguration. (Same as with the predefined objects discussion above.) > > > > To answer your questions: > > > > 1) Yes, it is my opinion that *activated* templates in will be e= xpanded and present in . > > > > 2) I would never suggest that the system-defined templates are present in= , though they may be referenced/parameterized by config in . > > > > 3) if a config-template is configured in (i.e., it is operator-= defined) then, yes, the expanded configuration in is "client con= figuration=E2=80=9D (note, "client configuration=E2=80=9D is not a formal t= erm). That said, it seems fair to say that a template defined in = and then referenced by "client configuration=E2=80=9D in is also = expanded as "client configuration=E2=80=9D in . > > > > 4) I don=E2=80=99t not understand your last sentence, that the expansion = of templates are only present in . Maybe you=E2=80= =99re saying something subtle, e.g., that servers currently don=E2=80=99t s= upport GET on . But, in theory, the expansion of templa= tes should (IMO) be present in , so that they may be subject to v= alidation. Of course, all the configuration (whether originati= ng in or ) that is successfully =E2=80=9Capplied=E2=80=9D= will also be present in . > > [Qiufang Ma] Assume that there is no and this work, the expansio= n of system templates are only present in . Because this is co= mpatible with system configuration definition in NMDA. > > But if system configurations are only present in , the prede= fined system configurations still need to be retrieved and created into explicitly when being referenced. I think we=E2=80=99ve reached an a= greement on the need for to exist, and our main point of disagreem= ent is whether should be copied into . Your point is that= being merged into is enough to make sure a success validation. = But my understanding is that the referenced system configuration data item = must also exist in the to obey the model constraints. > > > > Yes, I believe that you provided an accurate description of the differenc= e > in our opinions. Per my earlier response, you make a valid technical > point, my goal is to waive that interpretation to the side so that a > simpler solution can emerge. It would be good to get other opinions on > list, otherwise we=E2=80=99ll take it into the meeting. > > *[Qiufang Ma] OK. Hopefully someone else would share some opinions here. > Otherwise let=E2=80=99s take this into the IETF meeting.* > > > > [BTW, in keeping with this thread moving from the NETCONF to the NETMOD > mailing lists, would it make sense to move the IETF 111 presentation slot > from NETCONF to NETMOD too? I think it does and, further, it would help > with scheduling (NETCONF is over, NETMOD is under). Would you be okay wi= th > this? AD Rob and the NETCONF chairs discussed this morning, and think > it's okay, but would still need to confirm with the NETMOD chairs.] > > *[Qiufang Ma] I am happy with the proposal, if it=E2=80=99s also okay for= NETMOD > chairs:-). I have sent an email to the NETMOD chairs to request to move > this presentation slot from NETCONF to NETMOD. * > > *A new version of the draft will also be submitted to NETMOD when the > draft-submitting window reopens.* > > > > > > > I=E2=80=99m beginning to think that: > > > =C2=B7 auto-copying into is likely never a good idea,= because it violates the definition of > > > [Qiufang Ma] I am quite aware that different datastores in NMDA represe= nts different views of data nodes. And represents a configuratio= n datastore holding the current configuration of the device. > > > Should we consider system configuration also be part of current configu= ration of the device? From my perspective, the difference between system co= nfiguration and client-configuration lies only in who provides it. > > > > holds the current *operator-specified* configuration of the dev= ice. System-provided configuration is NOT specified by operators (though s= ystem-defined objects may be referenced by operator-specified config in ). I believe that this arrangement is consistent with the definitio= n of . Agreed? > > [Qiufang Ma] Yes. Actually we are not trying to violate the principles of= NMDA and the definition of . The issue we try to resolve here is= that system configurations cannot be used(referenced or overwritten) by th= e operators directly and need to be created into explicitly. This= actually loses the meaning of =E2=80=9Cpredefining and bringing convenienc= e=E2=80=9D. If auto-copying is not a good idea, what do you think about def= ining an RPC operation for the operators to do the copy(which is also what = Rob suggests at the meeting)? > > > > If we have to copy into , then I think that I agree an RPC > (?) would be better. > > *[Qiufang Ma] From my perspective, is feasible but not > efficient because operators still need to retrieve / > firstly. If we could define a RPC to copy the entire into > , it seems more convenient for operators. However, some system > configurations which are not going to be referenced or modified may also = be > copied into . I don't have a strong feeling about which one is > preferred. Anyway, we need to figure out whether it would be fine for > to missing referenced system configurations.* > > > > You mention =E2=80=9Coverwritten=E2=80=9D by the operators? Why wouldn= =E2=80=99t the operators > just define their own? For instance, if they don=E2=80=99t like the vend= or=E2=80=99s > =E2=80=9Cvendor-foobar=E2=80=9D object, they could copy/paste/edit their = own =E2=80=9Cmy-foobar=E2=80=9D > object with the values needed, yes? > > *[Qiufang Ma] Yes, defining their own would be okay. By overwriting, I > mean sometimes the operators would like to modify the specific system > configuration, e.g., the MTU value of a specified interface(identified by > its name).* > > *If the operators want to modify the system configurations, there is no > way but redefine them in .* > > > > > > *Best Regards,* > > *Qiufang Ma* > > > > > > > > > > > =C2=B7 having in doesn=E2=80=99t make sense, sinc= e the tweaks wouldn=E2=80=99t go thru --> validation. > > > > > > I=E2=80=99m wondering if a model like below would work for everyone - t= houghts? > > > [Qiufang Ma] represents the configuration after all configur= ation transformations to have been performed, so I think it is on= ly coupled to . > > > Anyway, the should also interacts with . Agreed? > > > > I don=E2=80=99t agree that must only be coupled to . = Specifically, I think that it is okay (compatible with NMDA) to define a <= system> that also impacts . This is the only (IMO) sane approac= h, as it enables the combination + to be validated. > > [Qiufang Ma] Please see above. If is OK to miss referenced syst= em configuration, your proposal makes sense to me. > > > > Ack. > > > > > > * Best Regards,* > > *Qiufang Ma * > > > > > > Kent // contributor > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --0000000000007116f605c86e2f1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jul 31, 2021 at 9:26 AM Bal= =C3=A1zs Lengyel <balazs.lengyel=3D40ericsson.com@dmarc.ietf.org> wrote:

Hello,

Sorry for going back = to the basics, but IMHO it is needed here. So as I see understand the probl= em:

The purpose of the draft= and some principles should be clearly stated. In my view:

=C2=A0

= P1) =E2=80=9CThere is a need to validate configuration data against data= created by the system.=E2=80=9D

=C2=A0

We also have some principles:

P2) We want the running datastore to contain exactly what the operator = has written there

=C2=A0

From this it flows that

=

P3) the running= /intended configuration MAY become invalid if the system-data changes. <= /u>

But

P4) rfc8342#section-5.3= .4 MUST always be valid

= =C2=A0

P3 and P4 contradict each other. The only= way to resolve this IMHO is to say that system-data changes only at upgrad= e. If the upgrade can=E2=80=99t end up with a valid configuration (after wh= atever processing) then it MUST fail.

= =C2=A0

IMHO

If we move the system-data into a separate datastore that does not help. = When I update the running configuration the validation will depend on syste= m-data either in the system or in the intended datastore. Debugging a confi= guration distributed over multiple datastores is difficult.

IMHO we should just introduce a new datatype beside conf= ig=3Dtrue and config=3Dfalse, let=E2=80=99s call it system-data or read-onl= y-config=3Dtrue.

System-data would be the= same type as config=3Dtrue except it is not writable by Netconf/Restconf/C= LI/SNMP, etc. only by the system itself.

This would allow us to define and populate system-data in both running/in= tended datastores. It would be visible in the same context. <= /span>

System-data would be static, the operator would not be = able to modify it, so impact on netconf/Restconf operations would be trivia= l.

=C2=A0



I agree a new datastore will = just add complexity without any value.
Your solution approach is = better, but I think it would require a new YANG version
to allow = config node XPath to reference non-config nodes.

Another solution is to model the referenced node as config=3Dtrue, but s= etup
automatic NACM rules so no user editing is allowed. This wor= ks well for
setting up an initial config that gets saved and not = changed unless a reset is done.

What if <intend= ed> is what is NV-stored?=C2=A0 When that occurs, the config changes fro= m system to user config.
Routers have been saving the combined co= nfig for decades. IMO the standards
intentionally avoid discussin= g the conversion of a datastore to/from NV-storage.


= As I see it t= his is the same problem that we discussed in https://github.com/netmod-= wg/yang-next/issues/41.

= =C2=A0=

I know this is a radical change, but I think us= ing a new YANG extension to create a read-only config=3Dtrue datatype is a = much cleaner solution. One which some companies have already implemented.



+1

Actually, separate running and=C2=A0system would be a= =C2=A0radical change, not this.
Cleaner and less disruptive.=C2= =A0


<= span style=3D"font-size:11pt;font-family:Calibri,sans-serif">=

If I misunderstood your intent, then sorry.<= /u>

=C2=A0

Regards Ba= lazs

=C2=A0

=


Andy
=C2=A0
=

From: netmod <netmod-bounces@ietf.org> On B= ehalf Of maqiufang (A)
Sent: 2021. j=C3=BAlius 31., szombat 1= 4:33
To: Kent Watsen <kent+ietf@watsen.net>; netmod@ietf.org
Subject: Re: [net= mod] system configuration sync mechanism

=C2=A0

Hi, Kent,

Tha= nks for helping me revive this thread, which is exactly what I want to do.:= )

There was not a ve= ry fully discussion due to time constraints, but we did see some valuable p= oints here, thank you everyone for sharing your views.=

=C2=A0

Regarding option2, =C2=A0I am still unsure how will = things go if there is no <intended>(I think it was raised by Balazs, = hopefully Balazs can also add something here)? Should <system> be imp= lemented along with <intended>?

=C2=A0

Option 3 is still unclear, e.g., whether the <system> is copied = into <running> automatically or manually? If auto-copy is not a good = idea because it violates the definition of <running>, whether manual-= copy is performed towards part or all of the system configurations created = in <system>?

S= hould we copy the entire <system> into <running>? Or should the= re be as few system configuration data items in <running> as possible= ?

Anyway, I agree th= at option3 may still incur a failed validation of <running> when the = operators reference the system configuration which is produced through the = expansion of the system-defined templates.

If the existing mechanism(e.g., edit-config)is suffi= cient to define referenced system data item in <running>, it seems th= at the flow marked in option3 from <system> to <running> can be= removed, then it looks no difference between option1 and option3.

=C2=A0<= /p>

Best Regards,

Qiufang Ma

=C2=A0

Fro= m:= netmod [mailto:netm= od-bounces@ietf.org] On Behalf Of Kent Watsen
Sent: Thursday= , July 29, 2021 1:09 AM
To: netmod@ietf.org
Subject: Re: [netmod] system configuratio= n sync mechanism

=C2=A0

WG,

=C2=A0

Regarding yesterday=E2=80=99s &= lt;system> datastore presentation, there seemed to be support for "= Option #2=E2=80=9D, which is to have <system> merge into <intended= >.

=C2=A0

It was noted that this then would mean that client-validation = of <running> would necessitate understanding how the merge works, to = expand templates, resolve leafrefs, etc.

=C2=A0

<= div>

My thoughts are, so? = =C2=A0=C2=A0

=C2=A0

Firstly, a client that doesn=E2=80=99t understand= that there may be some <system> defined configuration will, for the = most part, be none the wiser. =C2=A0 The client *will* discover <system&= gt; configuration in <operational>, but this is already the case toda= y.=C2=A0 One new thing is that <operational> should use =E2=80=9Corig= in:system=E2=80=9D for configuration originating from the <system> da= tastore.=C2=A0 This last point might surprise clients=E2=80=A6as the defini= tion of =E2=80=9Cwith-origin=E2=80=9D doesn=E2=80=99t state that clients mu= st=C2=A0ignore any unrecognized =E2=80=9Corigin=E2=80=9D identities: https://datatracker.ietf.org/doc/html/rfc8527#section-3.2.2.

=C2=A0

Secondly, no shared object defined in <system> will be ac= tivated until client-supplied config references it.=C2=A0 But any client ab= le to do this already knows how <system> merges into <intended>= and is accounting for it.

=C2=A0

Th= oughts?

=C2=A0

Kent

=C2=A0

=C2=A0

On Jul 16, 2021, at 6:24 AM, maqiufang (A) <maqiufang1@huawei.com> wrote:

= =C2=A0

Hi, Kent,

Please see my reply inline.=

=C2=A0=

=

From: Kent Watsen [mailto:kent+ietf@watsen.net]
Sent: Friday, July 16, 2021 2:55 AM
To: maqiufang (A) <maqiufang1@huawei.com= >
Cc= : netmod@ietf.org=
Su= bject: Re: [netmod] system configuration sync mechanism

=C2= =A0

Hi= =C2=A0Qiufang,

=C2=A0

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [snip]

The question is if the server implementation prunes dangli= ng/unused objects when <intended> is applied, updating <operationa= l>.=C2=A0 My assumption is that the server will discard any object that = doesn=E2=80=99t actually impact the running configuration of the system (i.= e., values are consumed by the underlying operating system, drivers, etc.).= =C2=A0 Thusly, it is my opinion that only the referenced objects are applie= d.=C2=A0 Hence why, to answer your last question, I wrote that these config= urations (manufacturer-defined objects) are not applied immediately but onl= y after they are referenced.=C2=A0 Makes sense?

[Qiufang Ma] Yes, t= ry to sum up our discussion about the categories of the system configuratio= n:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Physical-resource-dependent--> whether this sort of system configur= ation exists in <system> dependents on if the physical resource is pr= esent(e.g., physical interface).

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Physical-resource-independent-->whi= ch is provided by the device system

o=C2=A0=C2=A0 <= /span>Further classification from the perspective of = =E2=80=9Capplied=E2=80=9D time(dependents on whether the system configurati= on impacts the running of the system)

=C2=A7=C2=A0 Config that is applied immediately(e.g., the loopback, the = predefined minimum length of password=E2=80=A6)

=C2=A7=C2=A0 Config that is applied only after being referenced = by other configs(e.g, definitions for applications ftp/tftp=E2=80=A6)

o=C2=A0=C2=A0 Further classi= fication from the perspective of generation time

=C2=A7=C2=A0 Config that is generated unconditionally at each b= oot time(e.g, loopback, predefined minimum length of password, ftp/tftp=E2= =80=A6)

=C2=A7=C2=A0 Config that is g= enerated conditionally during the device running(e.g., system-generated loc= al-port and remote-port for a new established BGP connection)

=C2=A0

Keep in mind that what is described above is just one aspect= of what can be in <system>.=C2=A0 In addition to defining reference-= able objects, <system> can also define/apply configuration immediatel= y (e.g., the loopback interface).=C2=A0 That is, configuration not does not= have to be referenced in order to become activated.

[Qiufang Ma] Not= ed.

=C2=A0

=C2=A0

=C2=A0
Note that, <running> by itself would not pass v=
alidation, due to missing leafrefs.=C2=A0 Thankfully, NMDA never says that =
validation runs on <running>.=C2=A0 But once <running> and <=
system> have been merged, to become <intended>, the result does pa=
ss validation.
 [Qiufang Ma] The referenced instance must also exist for the=
 data to be valid since the require-instance defaults to true if not presen=
t. Is this what you had in your mind? Yes, NMDA says that it is <intende=
d> which is subject to validation. But I also notice that In section 5.1=
.3 of the NMDA:=E2=80=9D<running> MUST always be a valid configuratio=
n data tree, as defined=C2=A0 in Section 8.1 of [RFC7950]. =E2=80=9D So my =
thought here is that <running> should also conform to the YANG model =
constraints and that=E2=80=99s to say, a referenced system-defined data ite=
m should also exists in <running>.
Therefore, if system configurations=
 do not exist in <running>, they still need to be =C2=A0configured in=
 <running> manually in order for being referenced. In this case, the =
original purpose of predefining some system configurations for user conveni=
ence is lost. This is the reason why we would like to define some mechanism=
 here to synchronize <system> into <running>. =

=C2=A0

=C2=A0

I see in RFC 8342 "<running> MUST a= lways be a valid configuration data tree, as defined in Section 8.1 of [RFC= 7950]=E2=80=9D.

=C2=A0

But the question remains if it is possible for= the system is able to validate <running> without, e.g., expanding te= mplates.=C2=A0 There may be a 'leafref' or =E2=80=98must=E2=80=99 e= xpression somewhere that will fail because the evaluation occurs without ex= panding a template that supplies the missing parts.

[Qiufang Ma] On c= ondition that <running> should be valid, the operators will need to r= etrieve from the <intended> or <operational> to get the templat= e-expanded configurations and then create them in the <running>, righ= t? =C2=A0

My feeling is that it loses the meaning of p= redefining and seems no differences between operator-defined configurations= if operators have to create system configures in <running> before th= ey use them. So I am beginning to think, if it=E2=80=99s possible to expand= the system-defined template during the copying between <system> and = <running>?

=C2=A0

If this draft =E2=80=9Cupdates= =E2=80=9D RFC 8342 (NMDA), then it can supply a clarifying statement about = what it means that "<running> MUST always be a valid configurati= on data tree=E2=80=9D.=C2=A0 Either that, or an Errata if it=E2=80=99s dete= rmined that the statement isn=E2=80=99t correct.

=C2=A0

You make a go= od technical point, but I think that we should *want* to avoid having to co= py <system> (or <operational>) configuration into <running&g= t; if we can avoid it.=C2=A0 Agreed?

[Qiufang Ma] tend to agree. Mayb= e we should try to avoid it, unless we have to.

=C2=A0=

FWIW, also in RFC 8342, Section 5.1.4.:

=C2=A0

=C2=A0=C2=A0 <i=
ntended> is tightly coupled to <running>.=C2=A0 Whenever data is w=
ritten
=C2=A0=C2=A0 to &=
lt;running>, the server MUST also immediately update and validate=

=C2=A0=C2=A0 <intended>.=

=C2=A0
=C2=A0=C2=A0 <intended> MAY also b=
e updated independently of <running> if the
=C2=A0=C2=A0 effect of a configuration transforma=
tion changes, but <intended> MUST
=C2=A0=C2=A0 always be a valid configuration data tree, as =
defined in Section=C2=A08.1
=C2=A0=C2=A0 of [RFC7950].=

=C2=A0<=
/u>

=C2=A0



=C2=A0
> I am wondering if these configuration=
 will present in the <operational> (which contains all the configurat=
ion actually used by the device) before they=E2=80=99re referenced.<=
u>
=C2=A0
I thin=
k that it would depend in the specific server=E2=80=99s behavior, regarding=
 if *unused* predefine objects are present in <operational>.=C2=A0 Ce=
rtainly the unused objects would not have to be present in <operational&=
gt;.=C2=A0 If I were implementing the server, the unused objects would NOT =
be present in <operational>.
[Qiufang Ma] Yes, if the predefined syste=
m configurations is unused, then I also tend to agree that they would not b=
e present in <operational> but may also depend on the vendor implemen=
tation.

=C2=A0

=C2=A0

Yup, this is the same = conclusion is in my response above.

[Qiufang Ma] :)=

=C2=A0



> It would be good if we could determine if there are=
 any other "resource-independent=E2=80=9D configuration categories her=
e.
=
> [Qiufang Ma] Do you think there exists conditional system configuratio=
n (if the preceding configurations you mentioned above is not)? For example=
, if SSH is enabled on a device, SSH-related keys are automatically generat=
ed. Such configurations are generated at the moment when a special function=
ality is enabled.
=C2=A0
I=E2=80=99m unsure what you mean in general by "con=
ditional configuration=E2=80=9D, but I can speak to your specific example. =
Though I must preface my comments that I imagine there are a number of ways=
 servers might go about enabling `sshd`.=C2=A0 What follows is my personal =
view, forged by being around systems for awhile=C2=A0 ;)
=C2=A0<=
u>
In general:
=C2=A0=

=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - `sshd` is NOT enabled by=
 default.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - `sshd` is enabled=
 via a configuration knob.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - =
the SSH host key is dynamically generated the first time `sshd` is enabled.=

=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - the SSH host key itself =
is in <operational> (not <running>)
<= pre style=3D"margin-left:108pt;background:white">=C2=A0
This view is consistent wi=
th the first paragraph in Section 3 of the =E2=80=9Ckeystore=E2=80=9D draft=
 (reproduced below):
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 3.=
=C2=A0 Support for Built-in Keys
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 =C2=A0=C2=A0 In some implementations, a server may support built-=
in keys.=C2=A0 Built-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=
=C2=A0 in keys MAY be set during the manufacturing process or be dynamicall=
y
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 generated the=
 first time the server is booted or a particular service
=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 (e.g., SSH) is enabled.<=
/u>
=C2=A0=

As a clos=
ing thought, this model (which I stated upfront may not be universal) would=
 have no presence-in or interaction-with <system>=E2=80=A6though, per=
haps, there may be some predefined values for what key-algorithms and/or ke=
y-lengths to use when generating the SSH host key...
[Qiufang Ma] By =E2=80=
=9Cconditional system configuration=E2=80=9D, I was meaning some of the sys=
tem configurations are not generated immediately after the device is powere=
d on. Instead, they are generated when a specific condition is satisfied du=
ring the device running(e.g., a functionality is enabled due to some client=
 configurations). I am not sure if it really exists, maybe not, just try to=
 explore the possibilities of various resource-independent system configura=
tions.:)

=C2=A0

To this point I agree..as does RFC 8= 342 (NMDA), Section 5.3.3.:=

=C2=A0

=C2=A0=C2=A0 Sometimes, resourc=
es are controlled by the device and the
=C2=A0=C2=A0 corresponding system-controlled data appears i=
n (and disappears from)
=
=C2=A0=C2=A0 <operational> dynamically.=C2=A0 If a system-controlled =
resource has
=C2=A0=C2=
=A0 matching configuration in <intended> when it appears, the system =
will
=C2=A0=C2=A0 try to=
 apply the configuration; this causes the configuration to
=C2=A0=C2=A0 appear in <operational&g=
t; eventually (if application of the
=C2=A0=C2=A0 configuration was successful).
[Qiufang Ma] See above, as I=
 summarized as the system configurations that is generated conditionally du=
ring the device running.
=C2=A0
Firstly, I again have to preface my comment that there a=
re likely many ways that templating mechanisms can be defined.=C2=A0=C2=A0=
=C2=A0 But, in general, once a templating mechanism has been defined, then =
it stands to reason that templates could be defined either in <running&g=
t; (by operators) or in <system> (by the manufacturer).=C2=A0 In one =
implementation I=E2=80=99m familiar with, the templates are objects that ar=
e referenced/parameterized by other parts of the configuration.=C2=A0 (Same=
 as with the predefined objects discussion above.)=C2=A0 <=
/u>
=C2=A0=

To answer your =
questions:
=C2=A0
1) Yes, it is my opinion that *activated* templates in <syst=
em> will be expanded and present in <intended>.
=C2=A0<=
u>
2) I would neve=
r suggest that the system-defined templates are present in <running>,=
 though they may be referenced/parameterized by config in <running>.<=
/span>
=C2=
=A0
3) if a config-template is configured in <running> (i.e., it is oper=
ator-defined) then, yes, the expanded configuration in <intended> is =
"client configuration=E2=80=9D (note, "client configuration=E2=80=
=9D is not a formal term).=C2=A0 That said, it seems fair to say that a tem=
plate defined in <system> and then referenced by "client configu=
ration=E2=80=9D in <running> is also expanded as "client configu=
ration=E2=80=9D in <intended>.
=C2=A0
4) I don=E2=80=99t not understand y=
our last sentence, that the expansion of <system> templates are only =
present in <operational>.=C2=A0 Maybe you=E2=80=99re saying something=
 subtle, e.g., that servers currently don=E2=80=99t support GET on <inte=
nded>.=C2=A0 But, in theory, the expansion of <system> templates s=
hould (IMO) be present in <intended>, so that they may be subject to =
validation.=C2=A0=C2=A0 Of course, all the <intended> configuration (=
whether originating in <running> or <system>) that is successfu=
lly =E2=80=9Capplied=E2=80=9D will also be present in <operational>.<=
/span>
=
[=
Qiufang Ma] Assume that there is no <system> and this work, the expan=
sion of system templates are only present in <operational>. Because t=
his is compatible with system configuration definition in NMDA.
But if syste=
m configurations are only present in <operational>, the predefined sy=
stem configurations still need to be retrieved and created into <running=
> explicitly when being referenced. I think we=E2=80=99ve reached an agr=
eement on the need for <system> to exist, and our main point of disag=
reement is whether <system> should be copied into <running>. Yo=
ur point is that being merged into <intended> is enough to make sure =
a success validation. But my understanding is that the referenced system co=
nfiguration data item must also exist in the <running> to obey the mo=
del constraints.

=C2=A0

Yes, I believe that you provi= ded an accurate description of the difference in our opinions.=C2=A0 Per my= earlier response, you make a valid technical point, my goal is to waive th= at interpretation to the side so that a simpler solution can emerge.=C2=A0 = It would be good to get other opinions on list, otherwise we=E2=80=99ll tak= e it into the meeting.

[Qiufang Ma] OK.=C2=A0 Hopefully someone else = would share some opinions here. Otherwise let=E2=80=99s take this into the = IETF meeting.

=C2=A0

[BTW, in keeping with this thread= moving from the NETCONF to the NETMOD mailing lists, would it make sense t= o move the IETF 111 presentation slot from NETCONF to NETMOD too?=C2=A0 I t= hink it does and, further, it would help with scheduling (NETCONF is over, = NETMOD is under).=C2=A0 Would you be okay with this? =C2=A0 AD Rob and the = NETCONF chairs discussed this morning, and think it's okay, but would s= till need to confirm with the NETMOD chairs.]

[Qiufang Ma] I am happy= with the proposal, if it=E2=80=99s also okay for NETMOD chairs:-). I have = sent an email to the NETMOD chairs to request to move this presentation slo= t from NETCONF to NETMOD.

A new version of the draft = will also be submitted to NETMOD when the draft-submitting window reopens.<= /span>



= 
=C2=A0<big snip>
= 
> I=E2=80=99m beginning to=
 think that:
> =C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto-=
copying into <running> is likely never a good idea, because it violat=
es the definition of <running>
> [Qiufang Ma] I am quite aware that=
 different datastores in NMDA represents different views of data nodes.=C2=
=A0 And <running> represents a configuration datastore holding the cu=
rrent configuration of the device.
> Should we consider system configuratio=
n also be part of current configuration of the device? From my perspective,=
 the difference between system configuration and=C2=A0 client-configuration=
 lies only in who provides it.
=C2=A0
<running> holds the current *operator=
-specified* configuration of the device.=C2=A0 System-provided configuratio=
n is NOT specified by operators (though system-defined objects may be refer=
enced by operator-specified config in <running>).=C2=A0=C2=A0 I belie=
ve that this arrangement is consistent with the definition of <running&g=
t;.=C2=A0 Agreed?
[Qiufang Ma] Yes. Actually we are not trying to violate th=
e principles of NMDA and the definition of <running>.=C2=A0 The issue=
 we try to resolve here is that system configurations cannot be used(refere=
nced or overwritten) by the operators directly and need to be created into =
<running> explicitly. This actually loses the meaning of =E2=80=9Cpre=
defining and bringing convenience=E2=80=9D. If auto-copying is not a good i=
dea, what do you think about defining an RPC operation for the operators to=
 do the copy(which is also what Rob suggests at the meeting)?=

=C2=A0

If we have to copy into <running>, then I think that = I agree an RPC (<edit-config>?) would be better.

[Qiufang Ma] F= rom my perspective, <edit-config> is feasible but not efficient becau= se operators still need to retrieve <system>/<operational> firs= tly. If we could define a RPC to copy the entire <system> into <ru= nning>, it seems more convenient for operators. However, some system con= figurations which are not going to be referenced or modified may also be co= pied into <running>. I don't have a strong feeling about which on= e is preferred. Anyway, we need to figure out whether it would be fine for = <running> to missing referenced system configurations.=

=C2=A0

You mention =E2=80=9Coverwritten=E2=80=9D by the operators?= =C2=A0 Why wouldn=E2=80=99t the operators just define their own?=C2=A0 For = instance, if they don=E2=80=99t like the vendor=E2=80=99s =E2=80=9Cvendor-f= oobar=E2=80=9D object, they could copy/paste/edit their own =E2=80=9Cmy-foo= bar=E2=80=9D object with the values needed, yes?

[Qiufang Ma] Yes, d= efining their own would be okay. By overwriting, I mean sometimes the opera= tors would like to modify the specific system configuration, e.g., the MTU = value of a specified interface(identified by its name).

If the operators want to modify the system configurations, there is no wa= y but redefine them in <running>.

=C2=A0<= /i>

= =C2=A0

Best Regards,

Qiufang Ma

=C2=A0


=C2=A0
=C2=A0
> =C2=B7=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 having in <operational> do=
esn=E2=80=99t make sense, since the tweaks wouldn=E2=80=99t go thru <run=
ning> --> <intended> validation.
>=C2=A0 <= /pre>
> I=E2=80=99m wonderi=
ng if a model like below would work for everyone - thoughts?<=
u>
> [Qiufang M=
a] <intended> represents the configuration after all configuration tr=
ansformations to <running> have been performed, so I think it is only=
 coupled to <running>.
> Anyway, the <system> should also inter=
acts with <operational>.=C2=A0 Agreed?
=C2=A0= 
I don=E2=80=99t agree that &l=
t;intended> must only be coupled to <running>.=C2=A0 Specifically,=
 I think that it is okay (compatible with NMDA) to define a <system> =
that also impacts <intended>.=C2=A0=C2=A0 This is the only (IMO) sane=
 approach, as it enables the combination <running> + <system> to be =
validated.
[Qiufang Ma] Please see above. If <running> is OK to miss r=
eferenced system configuration, your proposal makes sense to me.<=
/u>

=C2=A0

Ack.

=C2=A0


<= pre style=3D"margin-left:72pt;background:white">=C2=A0Best Re= gards,
Qiufang Ma
=

=C2=A0

=C2=A0

Kent // contributor

=C2= =A0

___________________________________________= ____
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
--0000000000007116f605c86e2f1e--