From nobody Sat Dec 1 01:28:53 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF532129C6B for ; Sat, 1 Dec 2018 01:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.058 X-Spam-Level: X-Spam-Status: No, score=-4.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=MvLl8IEy; dkim=pass (1024-bit key) header.d=ericsson.com header.b=adhgJISm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4QS0SxxeSKF for ; Sat, 1 Dec 2018 01:28:50 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7C612426E for ; Sat, 1 Dec 2018 01:28:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1543656527; x=1546248527; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FKbwovdU6uMLK2YBfJgh1v0rW6ARngrEd9u8t898qpY=; b=MvLl8IEyy4fmxNECh0oQ9TkJFr8fWQJ5Gstc6Ee98PLksGJAuTQaoOxfbU9BMSMv EesQpWMn7armnIgpBfwQXoMMG98m+N0+DYX6160iLG36I/lmiqep8uYLe39QQ9iz BfKj0DNlXJCI4PSSZ40rjpD4vUKeUQDyMNcozn2y3Ug=; X-AuditID: c1b4fb2d-f61ff70000007af1-da-5c02544fb0c4 Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id FD.05.31473.F44520C5; Sat, 1 Dec 2018 10:28:47 +0100 (CET) Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 1 Dec 2018 10:28:47 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sat, 1 Dec 2018 10:28:47 +0100 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=Mid9V679FzFsgeRnwkPAdxnSjXh7qLtk6jhHb4sn4Rk=; b=adhgJISmIASBS624MpIcwJeOXICpnuwRdSDHqiNAp193qYJWWnoMtutv0RqaTMM1bBZFzrjpIjmY5sIk5Dj7DNHckAc+xBgTxHhld+/vczXNVrjyBNC/vBXJxcwugw7v+PMEU3rF15zHiubAkcFFNp+PWjhocrxLYDCmHpQUBQA= Received: from DB7PR07MB4935.eurprd07.prod.outlook.com (20.177.192.212) by DB7PR07MB5468.eurprd07.prod.outlook.com (20.178.47.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.7; Sat, 1 Dec 2018 09:28:46 +0000 Received: from DB7PR07MB4935.eurprd07.prod.outlook.com ([fe80::c8ee:97bb:db28:7003]) by DB7PR07MB4935.eurprd07.prod.outlook.com ([fe80::c8ee:97bb:db28:7003%2]) with mapi id 15.20.1404.011; Sat, 1 Dec 2018 09:28:46 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: Andy Bierman , NetMod WG Thread-Topic: [netmod] instance file parsing - what is the target YANG module set Thread-Index: AQHUiVhC4+mtJwiKYka2yEI30+GqwA== Date: Sat, 1 Dec 2018 09:28:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 x-clientproxiedby: HE1PR05CA0182.eurprd05.prod.outlook.com (2603:10a6:3:f8::30) To DB7PR07MB4935.eurprd07.prod.outlook.com (2603:10a6:10:5b::20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR07MB5468; 6:OeUOBIveyCVaiOaWOTA/PxnpksPI1KoS/P4BxXo3cOhD0BHAZO8vrXikyxUvrrdshLgZLtIxCjRRNgOTCXrDRHeY+s4OBgOQYYwNVu6UHHY/3D68nnuQjugLZX9ZFSNmK0Sm/QfMEuZH6JlPuX3323AhfS7K2yqGQKJBAxj2V1cjFsejotGj6t80ktCpNs0EyBF9jeenGcGW48QlGKLdZGZPFZKXzdqoV6hPRGqRJ6pay2+uTLe7LHngtlPuW94wKvftyjhBbufbwoX8iNTRWc7LuWLhZKPGakz83umLfS1RVDtqGJh0ju114l4R8EnXAyMUWnC7HRp16TE1kL9BAVo3JEozTfcBLsAMiwY8wwnFSNPe60GIpu1ZLCv7bBYAQWBc0JpF34Ah2yRevnjPo6/bfqarCn/JCZCHVPSYm//pIl8JN09kNJNVWq/Poc7NHTaZ4yKUDLRa1I4hzuCZFw==; 5:ysiu/N4h/aLQGalXoOeFr5t4BuDlp6C3yYmOnxxtitRcq6JOtIgnzcEloKYw/nafEXV6+/0oRy9NCFJHLhljsQKY7wTAPsdMvJiBfXFWJY5D5U1xPJUSThs6qmnCzfavff4D5T2e1NLfVJU6T2HXXwTArUe/bjMooNgXEjXD+Zg=; 7:luimDRU0yUBdh1S/AlwWI7dgBt5wF1/x4tSWKQleHmpL6MUJ9pZhWRU60OaOUzoaDLWSxMYDdx2UEG59fV6UYOhyLF6xtGopTVkRFXA/t6REhe9CYT1RKHirbIEwv5R+nUkG4ZRxkgdC/rGyYy4tcA== x-ms-office365-filtering-correlation-id: 75bcc524-a330-4c98-0055-08d6576f6422 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:DB7PR07MB5468; x-ms-traffictypediagnostic: DB7PR07MB5468: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(3231454)(999002)(944501475)(4983020)(52105112)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB5468; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB5468; x-forefront-prvs: 087396016C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(39860400002)(346002)(396003)(136003)(252514010)(189003)(199004)(105586002)(6246003)(53936002)(256004)(14454004)(99936001)(31686004)(316002)(36756003)(58126008)(6306002)(54896002)(6512007)(68736007)(110136005)(236005)(6436002)(8676002)(64126003)(6116002)(3846002)(5660300001)(65826007)(7736002)(8936002)(81166006)(97736004)(81156014)(25786009)(85202003)(85182001)(106356001)(478600001)(2906002)(6486002)(966005)(229853002)(99286004)(26005)(186003)(31696002)(2616005)(386003)(6506007)(486006)(102836004)(76176011)(476003)(11346002)(66066001)(71190400001)(65806001)(86362001)(446003)(71200400001)(65956001)(606006)(52116002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5468; H:DB7PR07MB4935.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 1+N02uyPveK/DckII76hU1Df74Uh+bVDu36ZuhGT/4vNvABay7HCQRn+yuB0QSLuYGFrGSV2OOhNKGBgpfIISA0wLKHlwewHigY0wV9pkLDHj6sjZl8wuadDOG2Mmx/I+044pi5boo8MFO3kpgpjak3CB2CogcvLR4MlNNz/LzDjyqxvKvS4uRBBNCoC00Ir9OSspKMkS8KgkIDHWVunHsz7yeJfF5OVev4jZuLeVicXDDWx/nPCQwwDV73/mIXyTjacrHtZlrswNN6V296CgSYtX2dhPeAIReTtGBf3ywFt4sv7JUbcg6NiWKpC4UlWllCuPKhu0ak1nxKuVG/41g/weBOfJuetPS3gSzVUV6Y= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040000010805030905050505" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 75bcc524-a330-4c98-0055-08d6576f6422 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2018 09:28:46.5009 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5468 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA2XSe0hTYRQA8L67u+vdcPG1fBwUi6ZIWM5MK63whVAEomaBhT1mXtTUKbsm WUZahq9ZFpq6AtPUYsuUktIwQ1FCI3BKGiLmcgY+UlOzh6Vt+xYE/fc75/vOOd+5XFYgfS90 YhOV6ZxKqUiWMWK6Mvp5hmf4ESpmR+OIl99Yl8bGr0qfIwyiDtbW/qAO5t7Q0xHUcfH+OC45 MYNTeQWcFifM/moUpg0eON+qqxRmI3VQIRKxgH1hrU0nKERiVoq7EDS1qoUk+IpgcnGAIsF9 ChY6blkCGpcIYEJbx5CTmxSMt2qE5mZSbEDQX2BrNoNDIW/2FWW2HQ6Bms9lpiEsuxEfhivD e0g6Cu7WvbNekcP3EQ1jNo3dYHnmJW22BAeCptnAkPYRMNIyhcwW4Ujoncm31CLsAN96H1ks wI4wbKyiyG52YNC/YYjtYXJ8VUgsg4qpYYvt8Qkor1Uj8y6AS037Ny/QpOlJaBvNtxZvh7dD RkTsAv1VRdaCQQbu1KxR5sUAh8H11wzJDyPQq59Zp3lAw8RXAXESGHO6rPlNoC020CVoh+af hxMXIOiu9tBYPsAG6Kk00hrTCAF2h/prsv+vb4P66mkB8T6o+NnBEG+B0iKDDfEumO7+goh9 oP7xb+YeEmuRPc/xfEr8Th85p0o8w/OpSrmSS3+CTP9YR/OKZwvSTQd3Iswima0kNJSKkQoV GXxmSidyM/X52KTrQ060MlXJyewkXSsoRiqJU2Re4FSpp1Tnkjm+EzmztMxRIte2HZfieEU6 l8RxaZzq7ynFipyy0frF6I2uWfR88a3ghLaO5NGxUW8R1+6wPtbVv9/vcnuuXPyh59KAXuyp dqjWBbgg7cPyqN1Py5yKtxxdsp3Ge/vWhYeUz0XkP3AObJCIIuyW40Zj13wCDyUsJdaG3J7v 3bq9/QWS+8YNGbPywhcij/mfdby6ee5i8Gr8p6Aw+TZ3Gc0nKLw9BCpe8Qe1MSpDawMAAA== Archived-At: Subject: Re: [netmod] instance file parsing - what is the target YANG module set X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Dec 2018 09:28:52 -0000 --------------ms040000010805030905050505 Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable

Hello Andy,

Give me a few days and I will come out with -01 version of the draft that addresses this issue. We propose 3 options:

  • Include the needed information as part of instance data as defined by ietf-yang-library, that documents module name, revision, supported features, deviations
  • Include a URI that points to the same information (if you don't want to repeat the info again and again)
  • Include nothing as the target YANG module set may already be known, or the information is available through external documents.

I also see a major reason for this draft: once it is agreed we can use instance data to document other standard things, like server capabilities.

regards Balazs

On 2018. 11. 30. 18:48, Andy Bierman wrote:
Hi,

I don't see much standards value in this draft so far.
=
It seems the parser of the file needs to know the YANG library information
for the instance file data in some out-of-scope non-standard manner.
This is what we already have today just by naming the file in a specific way.

Is the intent that the instance-data-set leafs will be used to determine
the module revisions, features, and deviations used in the children
or the 'data' node?

Andy



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

--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20
--------------ms040000010805030905050505 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20 wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4 ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9 ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9 YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF 1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6 EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0 NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+ MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9 2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTIwMTA5Mjg0MVow LwYJKoZIhvcNAQkEMSIEIKVuRpTjJhZI0zluxONjY0a47+vNMHUrCSF5bQcSVh+MMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAB1W7eh8mpzWvsOQYcogS7rhBM4PP5OHafknJxU1VUcoSHD+ vq12HdC5cSXB3MMdCT4Q/k/6Scbv03uL2PpdiOBbikGa7o1wHJXXxWd3OLzVPMPt8ixR43sh B4wxfybvQntmMLnJ+6mWlkw/jIKYcwEjfdEJfIS/+/hZdSLg1mgj1B0D0kaulEyKV2X1+QaT mxq3EvjEbAmnwXMCODdMvGHdYyo9NsxDtRPsb3PKXk1/8/D9wRPckYL3GGc0h8FaIDc6nRAH ocxFx7StS2/f7gXflEss5BKp64CToRiJbXRtXyfDmd/PyCn+ovcLVrzL/woWj1dxqtXVEEiD H5bGBgcAAAAAAAA= --------------ms040000010805030905050505-- From nobody Sun Dec 2 21:03:26 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF13A130DEE for ; Sun, 2 Dec 2018 21:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnyBDcU0Yp36 for ; Sun, 2 Dec 2018 21:03:23 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4D912896A for ; Sun, 2 Dec 2018 21:03:22 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 6136A292DD781; Mon, 3 Dec 2018 05:03:17 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 3 Dec 2018 05:03:18 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.69]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Mon, 3 Dec 2018 13:03:15 +0800 From: Qin Wu To: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , Joe Clarke , "netmod@ietf.org" Thread-Topic: yang-instance-file-format - do we need a special file extension ? Thread-Index: AQHUiKyfuVCXBMdAaUydTo3SCBgaZqVsdyZw Date: Mon, 3 Dec 2018 05:03:14 +0000 Message-ID: References: <154147032474.4217.10743411700898817061.idtracker@ietfa.amsl.com> <07b9bcea-72e3-9986-7d42-303c4797f13a@ericsson.com> <2a796f78-41b7-376c-8f51-215d14cc4e2c@cisco.com> <1727baad-06a5-d3e8-dce5-48f211b45644@cisco.com> <4daec669-eae3-871f-d37b-f09be43f8795@ericsson.com> In-Reply-To: <4daec669-eae3-871f-d37b-f09be43f8795@ericsson.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.33.244] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [netmod] yang-instance-file-format - do we need a special file extension ? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 05:03:25 -0000 TXkgaWRlYSBpcyBzaW1pbGFyIHRvIHNlY3Rpb24gNC4yIG9mIFJGQzgwNzIsIGkuZS4sIGRlZmlu ZSBzdWJ0eXBlIG5hbWUsZS5nLiwNCnlhbmctaW5zdGFuY2UreG1sLCB5YW5nLWluc3RhbmNlK2pz b24NCg0KLVFpbg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBCYWzDoXpzIExl bmd5ZWwgW21haWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb21dIA0K5Y+R6YCB5pe26Ze0 OiAyMDE45bm0MTHmnIgzMOaXpSAyMTowMA0K5pS25Lu25Lq6OiBRaW4gV3U7IEpvZSBDbGFya2U7 IG5ldG1vZEBpZXRmLm9yZw0K5Li76aKYOiB5YW5nLWluc3RhbmNlLWZpbGUtZm9ybWF0IC0gZG8g d2UgbmVlZCBhIHNwZWNpYWwgZmlsZSBleHRlbnNpb24gPw0KDQpIZWxsbyBRaW4sDQoNCkRvIHlv dSBoYXZlIGEgYmV0dGVyIHN1Z2dlc3Rpb24gZm9yIHRoZSBmaWxlIGV4dGVuc2lvbj8NCg0KcmVn YXJkcyBCYWxhenMNCg0KT24gMjAxOC4gMTEuIDI5LiAyOjUzLCBRaW4gV3Ugd3JvdGU6DQo+IFRo ZSBhYmJyZXZpYXRpb24gb2YgWUFORyBpbnN0YW5jZSBkYXRhIHlpZCBtYXkgY29uZnVzZSB3aXRo IFlBTkcgaWRlbnRpdGlmZXIgc2hvcnQgbmFtZQ0KPiAiDQo+ICAgICBZQU5HIElkZW50aWZpZXI6 ICBOdW1lcmljIG9iamVjdCBpZGVudGlmaWVyLCB3aGljaCBpcyBhIGZpeGVkLWxlbmd0aA0KPiAg ICAgICAgbnVtZXJpYyB2YWx1ZSB0aGF0IHJlcHJlc2VudHMgYSBwYXJ0aWN1bGFyIHNjaGVtYSBu b2RlIHdpdGhpbiBhDQo+ICAgICAgICBZQU5HIG1vZHVsZSBzY2hlbWEgdHJlZS4gIFRoZSBsZW5n dGggYW5kIGZvcm1hdCBvZiBhIFlBTkcNCj4gICAgICAgIGlkZW50aWZpZXIgYXJlIGRlZmluZWQg aW4gdGhlIFlBTkcgSWRlbnRpZmllciBSZWdpc3RyeS4gIEFsc28NCj4gICAgICAgIGNhbGxlZCBh ICJZSUQiLg0KPiAiDQo+IEkgYmVsaWV2ZSB0aGV5IGFyZSBub3Qgc2FtZSB0aGluZy4NCj4NCj4g LVFpbg0KPiAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQo+IOWPkeS7tuS6ujogbmV0bW9kIFttYWls dG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBKb2UgQ2xhcmtlDQo+IOWPkemAgeaX tumXtDogMjAxOOW5tDEx5pyIMjjml6UgMjI6MzYNCj4g5pS25Lu25Lq6OiBCYWzDoXpzIExlbmd5 ZWw7IG5ldG1vZEBpZXRmLm9yZw0KPiDkuLvpopg6IFJlOiBbbmV0bW9kXSBGd2Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy1pbnN0YW5jZS1maWxl LWZvcm1hdC0wMC50eHQNCj4NCj4gT24gMTEvMjMvMTggMDc6NDgsIEJhbMOhenMgTGVuZ3llbCB3 cm90ZToNCj4+PiBEbyB5b3UgaGF2ZSB0byByZWdpc3RlciB0aGUgIi55aWQiIGZpbGUgZXh0ZW5z aW9uIGFzIHdlbGw/DQo+PiBCQUxBWlM6IElzIHRoZXJlIGEgcmVnaXN0cnkgZm9yIGZpbGUgZXh0 ZW5zaW9ucz8gSSB3YXMgbm90IGF3YXJlLg0KPiBSRkM2MDIwIHNlY3Rpb24gMTQgcmVnaXN0ZXJz IG1lZGlhIHR5cGVzIHRoYXQgaW5jbHVkZSBmaWxlIGV4dGVuc2lvbnMgZm9yIC55aW4gYW5kIC55 YW5nLiAgSSBhbSBhc2tpbmcgYXJlIHlvdSBwcm9wb3NpbmcgdG8gZG8gdGhlIHNhbWUgYW5kIHJl Z2lzdGVyaW5nIHNvbWV0aGluZyBsaWtlIGFwcGxpY2F0aW9uL3lhbmctaW5zdGFuY2UtZGF0YSB3 aXRoIGEgLnlpZCBleHRlbnNpb24/DQo+DQo+IEpvZQ0KPg0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5l dG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dG1vZA0KDQotLSANCkJhbGF6cyBMZW5neWVsICAgICAgICAgICAgICAgICAgICAgICBFcmljc3Nv biBIdW5nYXJ5IEx0ZC4NClNlbmlvciBTcGVjaWFsaXN0DQpNb2JpbGU6ICszNi03MC0zMzAtNzkw OSAgICAgICAgICAgICAgZW1haWw6IEJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbQ0KDQoNCg== From nobody Mon Dec 3 02:21:26 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6E9130E19 for ; Mon, 3 Dec 2018 02:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.961 X-Spam-Level: X-Spam-Status: No, score=-15.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6qDnPsIY_mm for ; Mon, 3 Dec 2018 02:21:23 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AADAD12875B for ; Mon, 3 Dec 2018 02:21:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3703; q=dns/txt; s=iport; t=1543832482; x=1545042082; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=CXMKJ76/CoujFQLdwI7lRe1HWcl+x8QtkWozBOwqMKk=; b=Ek4RpsLwfWUvvYy4OA4yeJkb4krDyfCc+hA1bBFDw8E6Pf5sSrLLRlVC Vmj7kEJqpOo1e16qeKgTWZo2D+2hGP1+riMvYEz28aWySU42UzwTJ35eO +CMVRzVPzRpqkhYqeNtva7yqY82TaAdqzFOR9dTv5aXQDCgWsDpZ6kJgl w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAABoAgVc/xbLJq1iGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgmlwEieDeYh3jQoIJZdIgXoNGAuEA0Y?= =?us-ascii?q?Cg2M2Bw0BAwEBAgEBAm0cDIU8AQEBAwEBASEPAQU2EAsLGAICJgICJzAGAQw?= =?us-ascii?q?GAgEBgx0BgXkID6RggS+FQIRZBYELiyiBQD+BOAyCX4MeAQGBS4MagjUiAol?= =?us-ascii?q?ehVCREgmRNgYYiWuHO4kEiQGGaIFNByqBVTMaCBsVO4JsixyFPz8DMItzAQE?= X-IronPort-AV: E=Sophos;i="5.56,310,1539648000"; d="scan'208";a="8487774" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Dec 2018 10:21:20 +0000 Received: from [10.63.23.68] (dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com [10.63.23.68]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id wB3ALKdT015466; Mon, 3 Dec 2018 10:21:20 GMT To: Andy Bierman , NetMod WG References: <20181130192830.g2622izshwn4f55z@anna.jacobs.jacobs-university.de> From: Robert Wilton Message-ID: <6281fd79-2284-46c0-350c-770dcdade29d@cisco.com> Date: Mon, 3 Dec 2018 10:21:20 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <20181130192830.g2622izshwn4f55z@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.68, dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [netmod] instance file parsing X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 03 Dec 2018 10:21:25 -0000 On 30/11/2018 19:28, Juergen Schoenwaelder wrote: > I doubt it makes sense to carry an entire yang library schema with the > instance data. The modules are actually known via the namespaces. Knowing the module name or namespace isn't sufficient to be able to parse the data:  - E.g. if the contents are in the format of RFC7895bis, but the client tries to parse it using the schema from RFC7895, then it will fail.  - Once NBC changes are allowed via YANG versioning it will become more necessary to know the revision or version of the modules to be able to parse the data.  E.g. not even just the latest module revision will necessarily work.   It is entirely plausible that different server revisions may be generating instance data using slightly different schema. If the server has deviations then the client may also need to know those deviations to correctly parse the file. So, I think that it is pretty clear that knowing the right schema is required to be able to correctly parse and interpret the instance data. I think that there are 4 ways that this can be achieved:  1) embedded the necessary schema information into the YANG instance data.  2) put the necessary schema information online somewhere and have a URI reference to it.  3) some combination of (1) and (2), e.g. packages defined centrally, with deviations listed in the file.  4) the schema is determined using some out of bound mechanism, or possibly it is hard coded. I don't think that there is a one size fits all answer here.  I think that that it depends on the use case.  Certainly, I think that facilitating 1 -3 is useful, but they should be optional rather than mandatory.  I.e. defining nodes for these doesn't seem to cost much if a server isn't obliged to populate them. I do think that YANG packages (themselves defined in instance data documents) could be very helpful here.  I.e. rather than listing all the modules, instead list the packages + any deviations from that.  I'm presuming here that the definitions of the packages are available via a URI. > If > you want to capture the schema, dump the relevant yang library into > another instance file. That just means another file to carry around and manage. Thanks, Rob > > /js > > On Fri, Nov 30, 2018 at 07:07:03PM +0000, Robert Wilton wrote: >> I also think that the instance data header needs to have a way of indicating >> which modules (and versions/revisions) the instance data applies to. >> >> It can be optional, so producers that know it is not required can leave it >> out.  But I think that it is required, at least for situations where being >> able to programmatically consume the instance data in a robust way is >> important. >> >> Thanks, >> Rob >> >> >> On 30/11/2018 17:48, Andy Bierman wrote: >>> Hi, >>> >>> I don't see much standards value in this draft so far. >>> It seems the parser of the file needs to know the YANG library information >>> for the instance file data in some out-of-scope non-standard manner. >>> This is what we already have today just by naming the file in a specific >>> way. >>> >>> Is the intent that the instance-data-set leafs will be used to determine >>> the module revisions, features, and deviations used in the children >>> or the 'data' node? >>> >>> Andy >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > From nobody Mon Dec 3 03:36:41 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C9412D7F8 for ; Mon, 3 Dec 2018 03:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zf0wdu7nO2oA for ; Mon, 3 Dec 2018 03:36:38 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9AE129C6B for ; Mon, 3 Dec 2018 03:36:38 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D162ADAE; Mon, 3 Dec 2018 12:36:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id wVAuKddUCfdK; Mon, 3 Dec 2018 12:36:36 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 3 Dec 2018 12:36:36 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F4DF20044; Mon, 3 Dec 2018 12:36:36 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ncwuYj6rqvGS; Mon, 3 Dec 2018 12:36:36 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id EFADA20043; Mon, 3 Dec 2018 12:36:35 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Mon, 3 Dec 2018 12:36:34 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 24A1C30048D98F; Mon, 3 Dec 2018 12:36:33 +0100 (CET) Date: Mon, 3 Dec 2018 12:36:33 +0100 From: Juergen Schoenwaelder To: Robert Wilton CC: Andy Bierman , NetMod WG Message-ID: <20181203113633.v3nfuen66ngjjp6l@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Robert Wilton , Andy Bierman , NetMod WG References: <20181130192830.g2622izshwn4f55z@anna.jacobs.jacobs-university.de> <6281fd79-2284-46c0-350c-770dcdade29d@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <6281fd79-2284-46c0-350c-770dcdade29d@cisco.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] instance file parsing X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 03 Dec 2018 11:36:40 -0000 On Mon, Dec 03, 2018 at 10:21:20AM +0000, Robert Wilton wrote: > > On 30/11/2018 19:28, Juergen Schoenwaelder wrote: > > I doubt it makes sense to carry an entire yang library schema with the > > instance data. The modules are actually known via the namespaces. > > Knowing the module name or namespace isn't sufficient to be able to parse > the data: > - E.g. if the contents are in the format of RFC7895bis, but the client > tries to parse it using the schema from RFC7895, then it will fail. > - Once NBC changes are allowed via YANG versioning it will become more > necessary to know the revision or version of the modules to be able to parse > the data. E.g. not even just the latest module revision will necessarily > work. It is entirely plausible that different server revisions may be > generating instance data using slightly different schema. Perhaps this is a problem of the versioning solution then. ;-) > If the server has deviations then the client may also need to know those > deviations to correctly parse the file. > > So, I think that it is pretty clear that knowing the right schema is > required to be able to correctly parse and interpret the instance data. > > I think that there are 4 ways that this can be achieved: > 1) embedded the necessary schema information into the YANG instance data. > 2) put the necessary schema information online somewhere and have a URI > reference to it. > 3) some combination of (1) and (2), e.g. packages defined centrally, with > deviations listed in the file. > 4) the schema is determined using some out of bound mechanism, or possibly > it is hard coded. Perhaps we need to define first what "parse" means. I am not sure parsing requires to know all schema details. Anyway, if all schema details are needed, then the simplest solution seems to be to read the schema from another instance file. This then only requires to bootstrap the schema model version. > I don't think that there is a one size fits all answer here. I think that > that it depends on the use case. Certainly, I think that facilitating 1 -3 > is useful, but they should be optional rather than mandatory. I.e. defining > nodes for these doesn't seem to cost much if a server isn't obliged to > populate them. > > I do think that YANG packages (themselves defined in instance data > documents) could be very helpful here. I.e. rather than listing all the > modules, instead list the packages + any deviations from that. I'm > presuming here that the definitions of the packages are available via a URI. > > If > > you want to capture the schema, dump the relevant yang library into > > another instance file. > > That just means another file to carry around and manage. Yes, but compared to solutions that require new and/or much more elaborate data formats, this is very cheap and efficient, in particular for systems where the schema itself is relatively static. Also in terms of engineering time this is a rather cheap solution since you do not need to invent a new way to document and communicate a schema. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Dec 3 09:57:06 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9B91271FF for ; Mon, 3 Dec 2018 09:57:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06TIJ6fCnMZv for ; Mon, 3 Dec 2018 09:57:02 -0800 (PST) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 3CAEB124BE5 for ; Mon, 3 Dec 2018 09:57:02 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id e26so9867344lfc.2 for ; Mon, 03 Dec 2018 09:57:02 -0800 (PST) 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=P8kh8MTedmZdX/RWT9EiXGq0WuRF8IJlPSnM9E1eQqA=; b=IW+Q0oP7v1FcFS1RnjTBQ5sy7BK7Du44iaulDgtv31jXMhzu6F/eeq3bLSZ+fhBsGK 8mFrr+UvqJNMy4X2cLIzs9cnkObSFyWmvDlCWdl00BcAwNaAMuaB53rB9f4pH2GgMks5 Lg85t9rn9iSc4iVFcmsztMQ9lhsb1nISIDbMGcT/afLVZM/z/hXb9OYosa4Qqnn9t3Uf /BsmSa8pyBNYdVUki/fHBpbIIeNrlP+Tsebbwh1MXxThqhzdUio/5WUFoLFvs7Rj+FOs dE8NrBNq3/6ZCVI4Uem/U6Ib+lFDERvucA0XB3Npd1Ip16ajU0I52VQXBkA1Jou1PyWG jXVA== 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=P8kh8MTedmZdX/RWT9EiXGq0WuRF8IJlPSnM9E1eQqA=; b=AXdg8iwYz8ZQij3d29GANmLa9/yy51Tk+8MyWCdH3nFdTj3DVpLBxifEaWh+eQP5ms h3LDuOE01eiHAqS0XsCWkCkDerr1GA7n7tRkQewq9pD8GyXO2oLgFbzb+tW0iZVODTkL hoLHbRNt2V65/M5OyVjCdoJs9yqjIZzDXNf04d19qbmCeGmsk/Xl1ya3za10rJjglxqp 8uzcul0+y9V0yRTUSRt7XO9R8VlYaq2x7EHA4wd7WyoZme3a57REzzUpl01Mjm7kP0r3 HbGC03a+uAIEyfupxDzdq+SyUvUuku07phuIHbcrrN7Rs1fFyoX5qFY4w2MlesSKwRpM 1hkA== X-Gm-Message-State: AA+aEWZpsgfhJWK+muisgLQL6wBg0v7GKt29e2d40TKgafE6BP1oCnqt O0jaHv0AMVs5Kk5JDTOQqIj6IjseGNc8ivYUCuhm2A== X-Google-Smtp-Source: AFSGD/Vcc+45vAOZNIY3IRkShRzfUUNszhHUqRj1TRMxmhi2nnlWM+1qIQpNC/crtlZ3ayya8NIi7GlIc8huBYNUc3w= X-Received: by 2002:a19:d58e:: with SMTP id m136mr10470335lfg.70.1543859820025; Mon, 03 Dec 2018 09:57:00 -0800 (PST) MIME-Version: 1.0 References: <20181130192830.g2622izshwn4f55z@anna.jacobs.jacobs-university.de> <6281fd79-2284-46c0-350c-770dcdade29d@cisco.com> <20181203113633.v3nfuen66ngjjp6l@anna.jacobs.jacobs-university.de> In-Reply-To: <20181203113633.v3nfuen66ngjjp6l@anna.jacobs.jacobs-university.de> From: Andy Bierman Date: Mon, 3 Dec 2018 09:56:48 -0800 Message-ID: To: Juergen Schoenwaelder , Robert Wilton , NetMod WG Content-Type: multipart/alternative; boundary="00000000000027fffb057c21e0da" Archived-At: Subject: Re: [netmod] instance file parsing X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 03 Dec 2018 17:57:05 -0000 --00000000000027fffb057c21e0da Content-Type: text/plain; charset="UTF-8" On Mon, Dec 3, 2018 at 3:36 AM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Dec 03, 2018 at 10:21:20AM +0000, Robert Wilton wrote: > > > > On 30/11/2018 19:28, Juergen Schoenwaelder wrote: > > > I doubt it makes sense to carry an entire yang library schema with the > > > instance data. The modules are actually known via the namespaces. > > > > Knowing the module name or namespace isn't sufficient to be able to parse > > the data: > > - E.g. if the contents are in the format of RFC7895bis, but the client > > tries to parse it using the schema from RFC7895, then it will fail. > > - Once NBC changes are allowed via YANG versioning it will become more > > necessary to know the revision or version of the modules to be able to > parse > > the data. E.g. not even just the latest module revision will necessarily > > work. It is entirely plausible that different server revisions may be > > generating instance data using slightly different schema. > > Perhaps this is a problem of the versioning solution then. ;-) > > > If the server has deviations then the client may also need to know those > > deviations to correctly parse the file. > > > > So, I think that it is pretty clear that knowing the right schema is > > required to be able to correctly parse and interpret the instance data. > > > > I think that there are 4 ways that this can be achieved: > > 1) embedded the necessary schema information into the YANG instance > data. > > 2) put the necessary schema information online somewhere and have a URI > > reference to it. > > 3) some combination of (1) and (2), e.g. packages defined centrally, > with > > deviations listed in the file. > > 4) the schema is determined using some out of bound mechanism, or > possibly > > it is hard coded. > > Perhaps we need to define first what "parse" means. I am not sure > parsing requires to know all schema details. Anyway, if all schema > details are needed, then the simplest solution seems to be to read the > schema from another instance file. This then only requires to > bootstrap the schema model version. > > I agree with Rob. The solution has to support accurate parsing of the instance data. This means that the parser has the correct schema tree to use for validating an instance document against the schema. Since the new yang-library can have a different schema tree for each datastore, clearly the option of specifying the datastore is needed. > > I don't think that there is a one size fits all answer here. I think > that > > that it depends on the use case. Certainly, I think that facilitating 1 > -3 > > is useful, but they should be optional rather than mandatory. I.e. > defining > > nodes for these doesn't seem to cost much if a server isn't obliged to > > populate them. > > > > I do think that YANG packages (themselves defined in instance data > > documents) could be very helpful here. I.e. rather than listing all the > > modules, instead list the packages + any deviations from that. I'm > > presuming here that the definitions of the packages are available via a > URI. > > Yes -- this has been my goal for YANG Packages since the start. By using nested packages and offline caching, the entire YANG library for a device could be recognized in a few URIs. > > > If > > > you want to capture the schema, dump the relevant yang library into > > > another instance file. > > > > That just means another file to carry around and manage. > > Yes, but compared to solutions that require new and/or much more > elaborate data formats, this is very cheap and efficient, in > particular for systems where the schema itself is relatively > static. Also in terms of engineering time this is a rather cheap > solution since you do not need to invent a new way to document and > communicate a schema. > > I agree the cost of an extra instance document is not a problem, especially since it would be optional and only used if the defaults are not sufficient: - latest revision of module will be OK - assume all features present will be OK - assume no deviations will be OK If the defaults are not OK, then the parser will incorrectly accept or reject certain instance data, unless the correct schema tree is obtained somehow. /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --00000000000027fffb057c21e0da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Dec 3, 2018 at 3:36 AM Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>= ; wrote:
On Mon, Dec 03, 2018 at 10= :21:20AM +0000, Robert Wilton wrote:
>
> On 30/11/2018 19:28, Juergen Schoenwaelder wrote:
> > I doubt it makes sense to carry an entire yang library schema wit= h the
> > instance data. The modules are actually known via the namespaces.=
>
> Knowing the module name or namespace isn't sufficient to be able t= o parse
> the data:
> =C2=A0- E.g. if the contents are in the format of RFC7895bis, but the = client
> tries to parse it using the schema from RFC7895, then it will fail. > =C2=A0- Once NBC changes are allowed via YANG versioning it will becom= e more
> necessary to know the revision or version of the modules to be able to= parse
> the data.=C2=A0 E.g. not even just the latest module revision will nec= essarily
> work.=C2=A0=C2=A0 It is entirely plausible that different server revis= ions may be
> generating instance data using slightly different schema.

Perhaps this is a problem of the versioning solution then. ;-)

> If the server has deviations then the client may also need to know tho= se
> deviations to correctly parse the file.
>
> So, I think that it is pretty clear that knowing the right schema is > required to be able to correctly parse and interpret the instance data= .
>
> I think that there are 4 ways that this can be achieved:
> =C2=A01) embedded the necessary schema information into the YANG insta= nce data.
> =C2=A02) put the necessary schema information online somewhere and hav= e a URI
> reference to it.
> =C2=A03) some combination of (1) and (2), e.g. packages defined centra= lly, with
> deviations listed in the file.
> =C2=A04) the schema is determined using some out of bound mechanism, o= r possibly
> it is hard coded.

Perhaps we need to define first what "parse" means. I am not sure=
parsing requires to know all schema details. Anyway, if all schema
details are needed, then the simplest solution seems to be to read the
schema from another instance file. This then only requires to
bootstrap the schema model version.



I agree with Rob.
=
The solution has to support accurate parsing of the instance data.
This means that the parser has the correct schema tree to use for
validating an instance document against the schema.

<= /div>
Since the new yang-library can have a different schema tree for e= ach datastore,
clearly the option of specifying the datastore is = needed.

=C2=A0
> I don't think that there is a one size fits all answer here.=C2=A0= I think that
> that it depends on the use case.=C2=A0 Certainly, I think that facilit= ating 1 -3
> is useful, but they should be optional rather than mandatory.=C2=A0 I.= e. defining
> nodes for these doesn't seem to cost much if a server isn't ob= liged to
> populate them.
>
> I do think that YANG packages (themselves defined in instance data
> documents) could be very helpful here.=C2=A0 I.e. rather than listing = all the
> modules, instead list the packages + any deviations from that.=C2=A0 I= 'm
> presuming here that the definitions of the packages are available via = a URI.



Yes -- this has been my= goal for YANG Packages since the start.
By using nested packages= and offline caching, the entire YANG library for a device
could = be recognized in a few URIs.

=C2=A0
> >=C2=A0 =C2=A0If
> > you want to capture the schema, dump the relevant yang library in= to
> > another instance file.
>
> That just means another file to carry around and manage.

Yes, but compared to solutions that require new and/or much more
elaborate data formats, this is very cheap and efficient, in
particular for systems where the schema itself is relatively
static. Also in terms of engineering time this is a rather cheap
solution since you do not need to invent a new way to document and
communicate a schema.


I agree the cost of an extra instance = document is not a problem, especially since
it would be optio= nal and only used if the defaults are not sufficient:
=C2=A0 =C2= =A0- latest revision of module will be OK
=C2=A0 =C2=A0- assume a= ll features present will be OK
=C2=A0 =C2=A0- assume no deviation= s will be OK

If the defaults are not OK, then the = parser will incorrectly accept or reject certain instance data,
u= nless the correct schema tree is obtained somehow.



/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/>
--00000000000027fffb057c21e0da-- From nobody Mon Dec 3 10:13:33 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D07E1277D2 for ; Mon, 3 Dec 2018 10:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOWfE5Or8p3Q for ; Mon, 3 Dec 2018 10:13:29 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD08124BE5 for ; Mon, 3 Dec 2018 10:13:29 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id AF3C3BBC; Mon, 3 Dec 2018 19:13:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id QLI3ES-I1QLl; Mon, 3 Dec 2018 19:13:26 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 3 Dec 2018 19:13:26 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9165420043; Mon, 3 Dec 2018 19:13:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fKlCf-ISOy9m; Mon, 3 Dec 2018 19:13:25 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id A7D8B2003F; Mon, 3 Dec 2018 19:13:25 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Mon, 3 Dec 2018 19:13:24 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 2B82130048FD55; Mon, 3 Dec 2018 19:13:23 +0100 (CET) Date: Mon, 3 Dec 2018 19:13:23 +0100 From: Juergen Schoenwaelder To: Andy Bierman CC: Robert Wilton , NetMod WG Message-ID: <20181203181323.dfbtlkumwp7ui5m6@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Robert Wilton , NetMod WG References: <20181130192830.g2622izshwn4f55z@anna.jacobs.jacobs-university.de> <6281fd79-2284-46c0-350c-770dcdade29d@cisco.com> <20181203113633.v3nfuen66ngjjp6l@anna.jacobs.jacobs-university.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] instance file parsing X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 03 Dec 2018 18:13:32 -0000 On Mon, Dec 03, 2018 at 09:56:48AM -0800, Andy Bierman wrote: > On Mon, Dec 3, 2018 at 3:36 AM Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Mon, Dec 03, 2018 at 10:21:20AM +0000, Robert Wilton wrote: > > > > > > On 30/11/2018 19:28, Juergen Schoenwaelder wrote: > > > > I doubt it makes sense to carry an entire yang library schema with the > > > > instance data. The modules are actually known via the namespaces. > > > > > > Knowing the module name or namespace isn't sufficient to be able to parse > > > the data: > > > - E.g. if the contents are in the format of RFC7895bis, but the client > > > tries to parse it using the schema from RFC7895, then it will fail. > > > - Once NBC changes are allowed via YANG versioning it will become more > > > necessary to know the revision or version of the modules to be able to > > parse > > > the data. E.g. not even just the latest module revision will necessarily > > > work. It is entirely plausible that different server revisions may be > > > generating instance data using slightly different schema. > > > > Perhaps this is a problem of the versioning solution then. ;-) > > > > > If the server has deviations then the client may also need to know those > > > deviations to correctly parse the file. > > > > > > So, I think that it is pretty clear that knowing the right schema is > > > required to be able to correctly parse and interpret the instance data. > > > > > > I think that there are 4 ways that this can be achieved: > > > 1) embedded the necessary schema information into the YANG instance > > data. > > > 2) put the necessary schema information online somewhere and have a URI > > > reference to it. > > > 3) some combination of (1) and (2), e.g. packages defined centrally, > > with > > > deviations listed in the file. > > > 4) the schema is determined using some out of bound mechanism, or > > possibly > > > it is hard coded. > > > > Perhaps we need to define first what "parse" means. I am not sure > > parsing requires to know all schema details. Anyway, if all schema > > details are needed, then the simplest solution seems to be to read the > > schema from another instance file. This then only requires to > > bootstrap the schema model version. > > > > > > I agree with Rob. > The solution has to support accurate parsing of the instance data. > This means that the parser has the correct schema tree to use for > validating an instance document against the schema. > > Since the new yang-library can have a different schema tree for each > datastore, > clearly the option of specifying the datastore is needed. We need to get the terminology straight. I can parse XML and JSON files without the need to have schema information available. So I think the word 'parsing' is quite misleading here. And I can extract data out of XML and JSON files that I find interesting without schema information as well. So its a certain type of tools that may take advantage of being schema aware but not all tools need to be schema aware. > > > I don't think that there is a one size fits all answer here. I think > > that > > > that it depends on the use case. Certainly, I think that facilitating 1 > > -3 > > > is useful, but they should be optional rather than mandatory. I.e. > > defining > > > nodes for these doesn't seem to cost much if a server isn't obliged to > > > populate them. > > > > > > I do think that YANG packages (themselves defined in instance data > > > documents) could be very helpful here. I.e. rather than listing all the > > > modules, instead list the packages + any deviations from that. I'm > > > presuming here that the definitions of the packages are available via a > > URI. > > > > > > Yes -- this has been my goal for YANG Packages since the start. > By using nested packages and offline caching, the entire YANG library for a > device > could be recognized in a few URIs. An instance file storing the schema tree is an offline cache. It falls out of the instance file format for free. Yes, packages are yet something entirely different but so far no work in this direction is chartered so we should get instance file formats defined without solving another bigger problem first. > > > > If > > > > you want to capture the schema, dump the relevant yang library into > > > > another instance file. > > > > > > That just means another file to carry around and manage. > > > > Yes, but compared to solutions that require new and/or much more > > elaborate data formats, this is very cheap and efficient, in > > particular for systems where the schema itself is relatively > > static. Also in terms of engineering time this is a rather cheap > > solution since you do not need to invent a new way to document and > > communicate a schema. > > > > > I agree the cost of an extra instance document is not a problem, especially > since > it would be optional and only used if the defaults are not sufficient: > - latest revision of module will be OK > - assume all features present will be OK > - assume no deviations will be OK > > If the defaults are not OK, then the parser will incorrectly accept or > reject certain instance data, > unless the correct schema tree is obtained somehow. Or the tool processing instance file content just does not care about the schema and it simply assumes that a certain (module,path) combination has fixed semantics. I am big fan of being able to use generic tools to filter and process XML or JSON encoded data. /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 Dec 4 09:15:01 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2481130F65 for ; Tue, 4 Dec 2018 09:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.959 X-Spam-Level: X-Spam-Status: No, score=-15.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvmgmhEmFAwe for ; Tue, 4 Dec 2018 09:14:57 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB01130EC9 for ; Tue, 4 Dec 2018 09:14:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5968; q=dns/txt; s=iport; t=1543943697; x=1545153297; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=mAD/Hnl6fpF3hOco4ybtkg3RiYcd7C35FCNyT8FswL0=; b=H71GlhhfcKEPDtWpn+TPt6igmJntni6a3QxSFKEQEef2xVnC/3WqplZn 2NXb37EzLiKcAM4a1iWvzo5o4/AqQhmDO6zt+b8wOtq6h//RQb4WC6dUV lHGWOa5wLh/mxy0uD/6hkTrmnUx8R4A+71mDCcQeEViny6c0Z2hAEAuNH U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAC1tAZc/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBg1kSJ4N5iHiNEAgll0mBeg2EbAKDLDY?= =?us-ascii?q?HDQEDAQECAQECbSiFPQEFIw8BBVELEAgCAiYCAlcGAQwGAgEBF4MGggKlHYE?= =?us-ascii?q?vhUCEb4ELiyqBQD+BOAyCX4RrgxqCNSICiR8+hVWRFwmROwYYgVuIECaHFYk?= =?us-ascii?q?GiQiGaYFNCCmBVTMaCBsVO4JskFs/AzCJHiuCIAEB?= X-IronPort-AV: E=Sophos;i="5.56,314,1539648000"; d="scan'208";a="8576701" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Dec 2018 17:14:54 +0000 Received: from [10.63.23.68] (dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com [10.63.23.68]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id wB4HEs85000913; Tue, 4 Dec 2018 17:14:54 GMT To: Andy Bierman , NetMod WG References: <20181130192830.g2622izshwn4f55z@anna.jacobs.jacobs-university.de> <6281fd79-2284-46c0-350c-770dcdade29d@cisco.com> <20181203113633.v3nfuen66ngjjp6l@anna.jacobs.jacobs-university.de> <20181203181323.dfbtlkumwp7ui5m6@anna.jacobs.jacobs-university.de> From: Robert Wilton Message-ID: <357e815d-cf6e-c093-0212-947fc8c7344d@cisco.com> Date: Tue, 4 Dec 2018 17:14:54 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 In-Reply-To: <20181203181323.dfbtlkumwp7ui5m6@anna.jacobs.jacobs-university.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.68, dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [netmod] instance file parsing X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2018 17:14:59 -0000 On 03/12/2018 18:13, Juergen Schoenwaelder wrote: > On Mon, Dec 03, 2018 at 09:56:48AM -0800, Andy Bierman wrote: >> On Mon, Dec 3, 2018 at 3:36 AM Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >> >>> On Mon, Dec 03, 2018 at 10:21:20AM +0000, Robert Wilton wrote: >>>> On 30/11/2018 19:28, Juergen Schoenwaelder wrote: >>>>> I doubt it makes sense to carry an entire yang library schema with the >>>>> instance data. The modules are actually known via the namespaces. >>>> Knowing the module name or namespace isn't sufficient to be able to parse >>>> the data: >>>> - E.g. if the contents are in the format of RFC7895bis, but the client >>>> tries to parse it using the schema from RFC7895, then it will fail. >>>> - Once NBC changes are allowed via YANG versioning it will become more >>>> necessary to know the revision or version of the modules to be able to >>> parse >>>> the data. E.g. not even just the latest module revision will necessarily >>>> work. It is entirely plausible that different server revisions may be >>>> generating instance data using slightly different schema. >>> Perhaps this is a problem of the versioning solution then. ;-) >>> >>>> If the server has deviations then the client may also need to know those >>>> deviations to correctly parse the file. >>>> >>>> So, I think that it is pretty clear that knowing the right schema is >>>> required to be able to correctly parse and interpret the instance data. >>>> >>>> I think that there are 4 ways that this can be achieved: >>>> 1) embedded the necessary schema information into the YANG instance >>> data. >>>> 2) put the necessary schema information online somewhere and have a URI >>>> reference to it. >>>> 3) some combination of (1) and (2), e.g. packages defined centrally, >>> with >>>> deviations listed in the file. >>>> 4) the schema is determined using some out of bound mechanism, or >>> possibly >>>> it is hard coded. >>> Perhaps we need to define first what "parse" means. I am not sure >>> parsing requires to know all schema details. Anyway, if all schema >>> details are needed, then the simplest solution seems to be to read the >>> schema from another instance file. This then only requires to >>> bootstrap the schema model version. >>> >>> >> I agree with Rob. >> The solution has to support accurate parsing of the instance data. >> This means that the parser has the correct schema tree to use for >> validating an instance document against the schema. >> >> Since the new yang-library can have a different schema tree for each >> datastore, >> clearly the option of specifying the datastore is needed. > We need to get the terminology straight. I can parse XML and JSON > files without the need to have schema information available. So I > think the word 'parsing' is quite misleading here. And I can extract > data out of XML and JSON files that I find interesting without schema > information as well. So its a certain type of tools that may take > advantage of being schema aware but not all tools need to be schema > aware. > >>>> I don't think that there is a one size fits all answer here. I think >>> that >>>> that it depends on the use case. Certainly, I think that facilitating 1 >>> -3 >>>> is useful, but they should be optional rather than mandatory. I.e. >>> defining >>>> nodes for these doesn't seem to cost much if a server isn't obliged to >>>> populate them. >>>> >>>> I do think that YANG packages (themselves defined in instance data >>>> documents) could be very helpful here. I.e. rather than listing all the >>>> modules, instead list the packages + any deviations from that. I'm >>>> presuming here that the definitions of the packages are available via a >>> URI. >>> >>> >> Yes -- this has been my goal for YANG Packages since the start. >> By using nested packages and offline caching, the entire YANG library for a >> device >> could be recognized in a few URIs. > An instance file storing the schema tree is an offline cache. It falls > out of the instance file format for free. Yes, packages are yet > something entirely different but so far no work in this direction is > chartered so we should get instance file formats defined without > solving another bigger problem first. In the IETF 103 discussion on YANG versioning, it seemed to be the consensus in the room that the versioning design team need to consider also versioning of sets of modules, rather than just individual modules.  I.e. something along the lines of YANG packaging. Thanks, Rob > > >>>>> If >>>>> you want to capture the schema, dump the relevant yang library into >>>>> another instance file. >>>> That just means another file to carry around and manage. >>> Yes, but compared to solutions that require new and/or much more >>> elaborate data formats, this is very cheap and efficient, in >>> particular for systems where the schema itself is relatively >>> static. Also in terms of engineering time this is a rather cheap >>> solution since you do not need to invent a new way to document and >>> communicate a schema. >>> >>> >> I agree the cost of an extra instance document is not a problem, especially >> since >> it would be optional and only used if the defaults are not sufficient: >> - latest revision of module will be OK >> - assume all features present will be OK >> - assume no deviations will be OK >> >> If the defaults are not OK, then the parser will incorrectly accept or >> reject certain instance data, >> unless the correct schema tree is obtained somehow. > Or the tool processing instance file content just does not care about > the schema and it simply assumes that a certain (module,path) > combination has fixed semantics. I am big fan of being able to use > generic tools to filter and process XML or JSON encoded data. > > /js > From nobody Tue Dec 4 09:23:50 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2053A130F78 for ; Tue, 4 Dec 2018 09:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0l9jicD1pzR for ; Tue, 4 Dec 2018 09:23:44 -0800 (PST) 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 28CC5130F46 for ; Tue, 4 Dec 2018 09:23:44 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id b20so12540762lfa.12 for ; Tue, 04 Dec 2018 09:23:43 -0800 (PST) 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=0h9c1csCX5i1W7dLtfrrNIQcbB2sqzRDuaUmm0fYjgY=; b=Noo82Z8mkjnJZXka8ST/kv1tZcT754yVwEob9bab4B8rvgU9f2ex2pxMvO9U1+bY8L F5Yd06xOTaLiSI6mJqkI/ckPhdCNkUZcq1lveztJU43Y1vQ5dkbQElepAdtlTsuGx10j GWyP0I2k6FVJ3VePR1rkIG9ldQCfHqz6mhI8zkyNPZ47flwUS41CNLuOQEBtDMMRLkFe zwrAgmFuJWp8VzcKpLo9AFImTPGk6Ba5l332zVKmyvZNOgvKtyNSRAhTzc0ec3DCAejM l6XjnHUriyDQMkVRuDOk8i5rh1eM87xxBGgirUQH6+VHv+X62mctfavSfYcqEvdPJoxC XWGA== 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=0h9c1csCX5i1W7dLtfrrNIQcbB2sqzRDuaUmm0fYjgY=; b=B0qbZutwxwp/fMmb46LpJKaryTH2CVfGWCbA5HWd/vNJg0HULK1wdZW0IC8AAN/Vmm bRG2mWAw8tx+Vuh/athGJdJwj7DMmIX1hGHFY5AtHFbgrW5TjLtqLq/QwKRpJLt37swZ Lcv0f7vtpa9X4Fy9GpKCWl5tNl1nZVjh6IxtRD3V2r2Lp381W2TmX7+yt6eBiDNg+7UG OHF3NKNPCc+zOF1WmuuXqHL/zoeV+KJaF9GEwWBCyxlSKBowQTK9rf/pfs1iVKFzWvA2 epnR0gvfi+OEK5oYeUvk5trCgs9Rozk4OUmyONJMeeNOONKQD85vABfuLK2+/WEMNfh1 +0XQ== X-Gm-Message-State: AA+aEWbicJISTr25mzsV012ac/CnOMr32x91DmYBdeQn9bv8J2zNFyNb P6Ah9KOEhYzFCr+73N5DJDGYSq1TsJTtSya40RdWfA== X-Google-Smtp-Source: AFSGD/VNUoqc8efPPbbUrw6GMx7NBDj0JS9XUnO0XKubcB8XdcaoPCf/9klpxjc23E82ddHKbY5lSil9WPdDSjp6g5M= X-Received: by 2002:a19:d58e:: with SMTP id m136mr13173984lfg.70.1543944221923; Tue, 04 Dec 2018 09:23:41 -0800 (PST) MIME-Version: 1.0 References: <20181130192830.g2622izshwn4f55z@anna.jacobs.jacobs-university.de> <6281fd79-2284-46c0-350c-770dcdade29d@cisco.com> <20181203113633.v3nfuen66ngjjp6l@anna.jacobs.jacobs-university.de> <20181203181323.dfbtlkumwp7ui5m6@anna.jacobs.jacobs-university.de> <357e815d-cf6e-c093-0212-947fc8c7344d@cisco.com> In-Reply-To: <357e815d-cf6e-c093-0212-947fc8c7344d@cisco.com> From: Andy Bierman Date: Tue, 4 Dec 2018 09:23:30 -0800 Message-ID: To: Robert Wilton Cc: NetMod WG Content-Type: multipart/alternative; boundary="000000000000e6b45c057c3586ae" Archived-At: Subject: Re: [netmod] instance file parsing X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 04 Dec 2018 17:23:48 -0000 --000000000000e6b45c057c3586ae Content-Type: text/plain; charset="UTF-8" On Tue, Dec 4, 2018 at 9:14 AM Robert Wilton wrote: > > On 03/12/2018 18:13, Juergen Schoenwaelder wrote: > > On Mon, Dec 03, 2018 at 09:56:48AM -0800, Andy Bierman wrote: > >> On Mon, Dec 3, 2018 at 3:36 AM Juergen Schoenwaelder < > >> j.schoenwaelder@jacobs-university.de> wrote: > >> > >>> On Mon, Dec 03, 2018 at 10:21:20AM +0000, Robert Wilton wrote: > >>>> On 30/11/2018 19:28, Juergen Schoenwaelder wrote: > >>>>> I doubt it makes sense to carry an entire yang library schema with > the > >>>>> instance data. The modules are actually known via the namespaces. > >>>> Knowing the module name or namespace isn't sufficient to be able to > parse > >>>> the data: > >>>> - E.g. if the contents are in the format of RFC7895bis, but the > client > >>>> tries to parse it using the schema from RFC7895, then it will fail. > >>>> - Once NBC changes are allowed via YANG versioning it will become > more > >>>> necessary to know the revision or version of the modules to be able to > >>> parse > >>>> the data. E.g. not even just the latest module revision will > necessarily > >>>> work. It is entirely plausible that different server revisions may > be > >>>> generating instance data using slightly different schema. > >>> Perhaps this is a problem of the versioning solution then. ;-) > >>> > >>>> If the server has deviations then the client may also need to know > those > >>>> deviations to correctly parse the file. > >>>> > >>>> So, I think that it is pretty clear that knowing the right schema is > >>>> required to be able to correctly parse and interpret the instance > data. > >>>> > >>>> I think that there are 4 ways that this can be achieved: > >>>> 1) embedded the necessary schema information into the YANG instance > >>> data. > >>>> 2) put the necessary schema information online somewhere and have a > URI > >>>> reference to it. > >>>> 3) some combination of (1) and (2), e.g. packages defined centrally, > >>> with > >>>> deviations listed in the file. > >>>> 4) the schema is determined using some out of bound mechanism, or > >>> possibly > >>>> it is hard coded. > >>> Perhaps we need to define first what "parse" means. I am not sure > >>> parsing requires to know all schema details. Anyway, if all schema > >>> details are needed, then the simplest solution seems to be to read the > >>> schema from another instance file. This then only requires to > >>> bootstrap the schema model version. > >>> > >>> > >> I agree with Rob. > >> The solution has to support accurate parsing of the instance data. > >> This means that the parser has the correct schema tree to use for > >> validating an instance document against the schema. > >> > >> Since the new yang-library can have a different schema tree for each > >> datastore, > >> clearly the option of specifying the datastore is needed. > > We need to get the terminology straight. I can parse XML and JSON > > files without the need to have schema information available. So I > > think the word 'parsing' is quite misleading here. And I can extract > > data out of XML and JSON files that I find interesting without schema > > information as well. So its a certain type of tools that may take > > advantage of being schema aware but not all tools need to be schema > > aware. > > > >>>> I don't think that there is a one size fits all answer here. I think > >>> that > >>>> that it depends on the use case. Certainly, I think that > facilitating 1 > >>> -3 > >>>> is useful, but they should be optional rather than mandatory. I.e. > >>> defining > >>>> nodes for these doesn't seem to cost much if a server isn't obliged to > >>>> populate them. > >>>> > >>>> I do think that YANG packages (themselves defined in instance data > >>>> documents) could be very helpful here. I.e. rather than listing all > the > >>>> modules, instead list the packages + any deviations from that. I'm > >>>> presuming here that the definitions of the packages are available via > a > >>> URI. > >>> > >>> > >> Yes -- this has been my goal for YANG Packages since the start. > >> By using nested packages and offline caching, the entire YANG library > for a > >> device > >> could be recognized in a few URIs. > > An instance file storing the schema tree is an offline cache. It falls > > out of the instance file format for free. Yes, packages are yet > > something entirely different but so far no work in this direction is > > chartered so we should get instance file formats defined without > > solving another bigger problem first. > > In the IETF 103 discussion on YANG versioning, it seemed to be the > consensus in the room that the versioning design team need to consider > also versioning of sets of modules, rather than just individual > modules. I.e. something along the lines of YANG packaging. > > I am not suggesting YANG Packages has to be solved in order to work on this instance document format. The IETF thinks YANG modules are the appropriate level of abstraction. Issues like "the extra metadata takes up too much space" are entirely subjective. Obviously a parser does not need any schema to parse anydata. This is only needed if there is a real schema expected within the anydata. It is optional for the writer to add the extra metadata. It is optional for the reader to use the extra metadata. Not sure why the solution should forbid this functionality. > Thanks, > Rob > Andy > > > > > > > >>>>> If > >>>>> you want to capture the schema, dump the relevant yang library into > >>>>> another instance file. > >>>> That just means another file to carry around and manage. > >>> Yes, but compared to solutions that require new and/or much more > >>> elaborate data formats, this is very cheap and efficient, in > >>> particular for systems where the schema itself is relatively > >>> static. Also in terms of engineering time this is a rather cheap > >>> solution since you do not need to invent a new way to document and > >>> communicate a schema. > >>> > >>> > >> I agree the cost of an extra instance document is not a problem, > especially > >> since > >> it would be optional and only used if the defaults are not sufficient: > >> - latest revision of module will be OK > >> - assume all features present will be OK > >> - assume no deviations will be OK > >> > >> If the defaults are not OK, then the parser will incorrectly accept or > >> reject certain instance data, > >> unless the correct schema tree is obtained somehow. > > Or the tool processing instance file content just does not care about > > the schema and it simply assumes that a certain (module,path) > > combination has fixed semantics. I am big fan of being able to use > > generic tools to filter and process XML or JSON encoded data. > > > > /js > > > --000000000000e6b45c057c3586ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue= , Dec 4, 2018 at 9:14 AM Robert Wilton <rwilton@cisco.com> wrote:

On 03/12/2018 18:13, Juergen Schoenwaelder wrote:
> On Mon, Dec 03, 2018 at 09:56:48AM -0800, Andy Bierman wrote:
>> On Mon, Dec 3, 2018 at 3:36 AM Juergen Schoenwaelder <
>> j.schoenwaelder@jacobs-university.de> wrote:
>>
>>> On Mon, Dec 03, 2018 at 10:21:20AM +0000, Robert Wilton wrote:=
>>>> On 30/11/2018 19:28, Juergen Schoenwaelder wrote:
>>>>> I doubt it makes sense to carry an entire yang library= schema with the
>>>>> instance data. The modules are actually known via the = namespaces.
>>>> Knowing the module name or namespace isn't sufficient = to be able to parse
>>>> the data:
>>>>=C2=A0 =C2=A0- E.g. if the contents are in the format of RF= C7895bis, but the client
>>>> tries to parse it using the schema from RFC7895, then it w= ill fail.
>>>>=C2=A0 =C2=A0- Once NBC changes are allowed via YANG versio= ning it will become more
>>>> necessary to know the revision or version of the modules t= o be able to
>>> parse
>>>> the data.=C2=A0 E.g. not even just the latest module revis= ion will necessarily
>>>> work.=C2=A0 =C2=A0It is entirely plausible that different = server revisions may be
>>>> generating instance data using slightly different schema.<= br> >>> Perhaps this is a problem of the versioning solution then. ;-)=
>>>
>>>> If the server has deviations then the client may also need= to know those
>>>> deviations to correctly parse the file.
>>>>
>>>> So, I think that it is pretty clear that knowing the right= schema is
>>>> required to be able to correctly parse and interpret the i= nstance data.
>>>>
>>>> I think that there are 4 ways that this can be achieved: >>>>=C2=A0 =C2=A01) embedded the necessary schema information i= nto the YANG instance
>>> data.
>>>>=C2=A0 =C2=A02) put the necessary schema information online= somewhere and have a URI
>>>> reference to it.
>>>>=C2=A0 =C2=A03) some combination of (1) and (2), e.g. packa= ges defined centrally,
>>> with
>>>> deviations listed in the file.
>>>>=C2=A0 =C2=A04) the schema is determined using some out of = bound mechanism, or
>>> possibly
>>>> it is hard coded.
>>> Perhaps we need to define first what "parse" means. = I am not sure
>>> parsing requires to know all schema details. Anyway, if all sc= hema
>>> details are needed, then the simplest solution seems to be to = read the
>>> schema from another instance file. This then only requires to<= br> >>> bootstrap the schema model version.
>>>
>>>
>> I agree with Rob.
>> The solution has to support accurate parsing of the instance data.=
>> This means that the parser has the correct schema tree to use for<= br> >> validating an instance document against the schema.
>>
>> Since the new yang-library can have a different schema tree for ea= ch
>> datastore,
>> clearly the option of specifying the datastore is needed.
> We need to get the terminology straight. I can parse XML and JSON
> files without the need to have schema information available. So I
> think the word 'parsing' is quite misleading here. And I can e= xtract
> data out of XML and JSON files that I find interesting without schema<= br> > information as well. So its a certain type of tools that may take
> advantage of being schema aware but not all tools need to be schema > aware.
>
>>>> I don't think that there is a one size fits all answer= here.=C2=A0 I think
>>> that
>>>> that it depends on the use case.=C2=A0 Certainly, I think = that facilitating 1
>>> -3
>>>> is useful, but they should be optional rather than mandato= ry.=C2=A0 I.e.
>>> defining
>>>> nodes for these doesn't seem to cost much if a server = isn't obliged to
>>>> populate them.
>>>>
>>>> I do think that YANG packages (themselves defined in insta= nce data
>>>> documents) could be very helpful here.=C2=A0 I.e. rather t= han listing all the
>>>> modules, instead list the packages + any deviations from t= hat.=C2=A0 I'm
>>>> presuming here that the definitions of the packages are av= ailable via a
>>> URI.
>>>
>>>
>> Yes -- this has been my goal for YANG Packages since the start. >> By using nested packages and offline caching, the entire YANG libr= ary for a
>> device
>> could be recognized in a few URIs.
> An instance file storing the schema tree is an offline cache. It falls=
> out of the instance file format for free. Yes, packages are yet
> something entirely different but so far no work in this direction is > chartered so we should get instance file formats defined without
> solving another bigger problem first.

In the IETF 103 discussion on YANG versioning, it seemed to be the
consensus in the room that the versioning design team need to consider
also versioning of sets of modules, rather than just individual
modules.=C2=A0 I.e. something along the lines of YANG packaging.



I am not suggesting YAN= G Packages has to be solved in order to
work on this instance doc= ument format. The IETF thinks YANG modules
are the appropriate le= vel of abstraction.

Issues like "the extra me= tadata takes up too much space" are entirely subjective.
Obv= iously a parser does not need any schema to parse anydata.
This i= s only needed if there is a real schema expected within the anydata.
<= div>
It is optional for the writer to add the extra metadata.=
It is optional for the reader to use the extra metadata.
Not sure why the solution should forbid this functionality.
=C2=A0
Thanks,
Rob


Andy

<= /div>

=C2=A0


>
>
>>>>>=C2=A0 =C2=A0 If
>>>>> you want to capture the schema, dump the relevant yang= library into
>>>>> another instance file.
>>>> That just means another file to carry around and manage. >>> Yes, but compared to solutions that require new and/or much mo= re
>>> elaborate data formats, this is very cheap and efficient, in >>> particular for systems where the schema itself is relatively >>> static. Also in terms of engineering time this is a rather che= ap
>>> solution since you do not need to invent a new way to document= and
>>> communicate a schema.
>>>
>>>
>> I agree the cost of an extra instance document is not a problem, e= specially
>> since
>> it would be optional and only used if the defaults are not suffici= ent:
>>=C2=A0 =C2=A0 =C2=A0- latest revision of module will be OK
>>=C2=A0 =C2=A0 =C2=A0- assume all features present will be OK
>>=C2=A0 =C2=A0 =C2=A0- assume no deviations will be OK
>>
>> If the defaults are not OK, then the parser will incorrectly accep= t or
>> reject certain instance data,
>> unless the correct schema tree is obtained somehow.
> Or the tool processing instance file content just does not care about<= br> > the schema and it simply assumes that a certain (module,path)
> combination has fixed semantics. I am big fan of being able to use
> generic tools to filter and process XML or JSON encoded data.
>
> /js
>
--000000000000e6b45c057c3586ae-- From nobody Wed Dec 5 07:46:55 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC09130E1B for ; Wed, 5 Dec 2018 07:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHiiJ9XwynY3 for ; Wed, 5 Dec 2018 07:46:51 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 32780126CB6 for ; Wed, 5 Dec 2018 07:46:51 -0800 (PST) Received: by trail.lhotka.name (Postfix, from userid 109) id 3975B1821356; Wed, 5 Dec 2018 16:55:05 +0100 (CET) Received: from localhost (unknown [195.113.220.122]) by trail.lhotka.name (Postfix) with ESMTPSA id 3A9041820056 for ; Wed, 5 Dec 2018 16:55:03 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org Mail-Followup-To: netmod@ietf.org Date: Wed, 05 Dec 2018 16:46:47 +0100 Message-ID: <871s6wt1qw.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [netmod] status terms in YANG and IANA registries X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Dec 2018 15:46:54 -0000 Hi, sec. 7.21.2 of RFC 7950 defines the "deprecated" and "obsolete" statuses as follows: o "deprecated" indicates an obsolete definition, but it permits new/continued implementation in order to foster interoperability with older/existing implementations. o "obsolete" means that the definition is obsolete and SHOULD NOT be implemented and/or can be removed from implementations. Then, RFC 7224 contains these instructions in the IANA Considerations section: "status": Include only if a registration has been deprecated (use the value "deprecated") or obsoleted (use the value "obsolete"). However, RFC 8126 defines the meaning of the status terms in IANA registries (sec. 9.6) in the following way: Specific entries in a registry can be marked as "obsolete" (no longer in use) or "deprecated" (use is not recommended). I would say that "deprecated" means something else here than in YANG. For example, the RSA/MD5 algorithm in [1] is marked as "deprecated" because it was found weak, and implementing it to "foster interoperability" can hardly be recommended. Instead, "SHOULD NOT implement" applies here, too. I think it would be good to either align the semantics of "deprecated" in YANG with IANA registries, or at least map both IANA terms to "obsolete" in YANG. Lada [1] https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Dec 5 12:21:01 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8DB130E58 for ; Wed, 5 Dec 2018 12:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.161 X-Spam-Level: X-Spam-Status: No, score=-4.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMkolpeZcSqa for ; Wed, 5 Dec 2018 12:20:57 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1235130EA1 for ; Wed, 5 Dec 2018 12:20:56 -0800 (PST) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id wB5KJklV011013 for ; Wed, 5 Dec 2018 12:20:56 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=M2LAX7aF2OLhny5xe/Po5VP/SEDVV7i3zNHMXcMv3qw=; b=NQDJMnsvBQHzGDb4P5mQNxDBkZJ+BamnEOiS/CCRYsfNEJItYTQd065Zk09nliWvf3aQ Ngl9blMH5qEDzf4bhTQY35xHq+hIdjwIE/W9+9abVnR8oW+Qx9b2RqNa1h1rsb5DnfPO Z2NFjdNo39LDw8sAuS4VPlooprJFT8dOmGVLoNEQSvDvu8fO3in3X4RRHQ5oem5gH7TH nkr95GFj/CzuITW9SzurlANwQ40b9ll+Ql+hkz4H8doP1gTAYz3qIjXfheirD4ISxlPD EandGGX/Wln0YWV4z9NicPSgDasHO0lag0+ZPyB5geV27evKu4nevX3o2fHb+3gkiTDX Gg== Received: from nam05-dm3-obe.outbound.protection.outlook.com (mail-dm3nam05lp2059.outbound.protection.outlook.com [104.47.49.59]) by mx0a-00273201.pphosted.com with ESMTP id 2p6msug3tc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 05 Dec 2018 12:20:56 -0800 Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB5740.namprd05.prod.outlook.com (20.178.24.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.8; Wed, 5 Dec 2018 20:20:54 +0000 Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::f0f3:20f0:2104:638c]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::f0f3:20f0:2104:638c%2]) with mapi id 15.20.1404.020; Wed, 5 Dec 2018 20:20:54 +0000 From: Kent Watsen To: NETMOD Working Group Thread-Topic: Draft meeting minutes posted Thread-Index: AQHUjNgGgEkU0OliIkKpl4ip/HQ4LA== Date: Wed, 5 Dec 2018 20:20:54 +0000 Message-ID: <615CF5F2-6657-483C-BA5C-F1217291E8B9@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.4.181110 x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR05MB5740; 6:M7Pj4R9ovRpDxpK7MBjCaQOY9S1Bff4Sl8JmX3ux/6D9ztO1zFiOMyST32HIgervq3Ep++cLSiG9dZ/dui+3aXiUN95wG5nh4y3/VvKwkcFCkU95HtcHYNf3D7TJLtPaRbN38PvYMwLZgzL1yWg/JWUGWkssFXuIHoQAsGBD4HE9dXqZvNNEEMSXJO1uz5jvmkqIQZaeIe9fNs8L9EX2QDBoUNQE8LXO6pLAIhtzxYwqAp8KEg+ceopVgLKRJQQq/1MHA+GKzgDnBZZHWcUJwqKW0QAFUHx4pZYEMli9HjGX0gTzS651hPEkGOPamXqAbD2akj6l9hWpbYXCoc2/Kn/biE3S14DAxiSETYrGFFm12vrsn0Q8Cutr1e61mgDwrAVaN9CqNvtTb4Fi5UW4teKdGrI0NRT/lHdHQoP9wnRADInvMo84pjvvqT7bdopr1SSYYCJXAdyzDNfp8OAidA==; 5:yUMzQNOyTU7HPcFFhTkhzeJC2ZyDY86kRnUI3MrbPF7HDub+uFDPhnriyR6jTLnqiCFBOoxfkDR5PTQNrJaF94L+BigUkSq/oF3gtaDVtYdIuzXAaXj9VGpxCP/+ejvoXqrxdSuJQWyw6B/bXe1dCFYKUqqT63htkT6zTKYv1Ew=; 7:94ViEInXG8lJCphVLXSzKx9R16iZkEKmXd+To+D+J0TTRbbV/FjjqD6SFmUPqy3ELpL6Niw2VDsaXgokIabWxwWbcb64q/OX5RyP6AEZT/JzJnZyOw0YFX2ON99J/fHETydRIE2B2A8nOo188tFo1g== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 02fb6ce0-0059-47aa-b83b-08d65aef28a2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB5740; x-ms-traffictypediagnostic: DM6PR05MB5740: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231455)(999002)(944501520)(52105112)(10201501046)(93006095)(93001095)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:DM6PR05MB5740; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB5740; x-forefront-prvs: 08770259B4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(346002)(136003)(376002)(366004)(199004)(189003)(6916009)(6116002)(478600001)(966005)(3846002)(305945005)(82746002)(81166006)(81156014)(8936002)(71190400001)(83716004)(8676002)(7736002)(71200400001)(3480700005)(2906002)(5660300001)(68736007)(86362001)(66066001)(6506007)(97736004)(6436002)(26005)(102836004)(106356001)(14454004)(36756003)(105586002)(53936002)(6486002)(476003)(186003)(58126008)(256004)(6306002)(99286004)(486006)(25786009)(2616005)(6512007)(316002)(558084003)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB5740; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: 2YIJyH9FkUuNSFEX2JVpQNkBuxoXKZAvifF3yfKZzWynNCwFckN8HEoaZmQV3WK1lY4jFQdtgQjLGhT2RxpVbyHYUjfi8baHuW7C+KX0CEETMMGtTQoDewT77P0InIVga0qokxyoG4Mp95l8AUTPja8AfFVQKH3bcbI2meNs8VCobHNwzAi6SqGajEBGqsqt4SuRZSF7eF9xpLmJ7h24NmuRmvEzhKICTTyFJe7IUcAF26C39BM4opIRVuMbDxkr+MjeSbx1ae0fT0wNMj+t0uUPVKXtQPjewc6qXTnW6iknL/Y5gDLJGC79AsEoL/xkBR+n7GnQnKOi/jPFr93ZIlDqJl5HLwqi+xL/fOFw0Uk= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8669FD8CF354DB4A8C4114A84B2DE96B@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 02fb6ce0-0059-47aa-b83b-08d65aef28a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Dec 2018 20:20:54.3846 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5740 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-05_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812050178 Archived-At: Subject: [netmod] Draft meeting minutes posted X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 05 Dec 2018 20:21:00 -0000 DQpUaGUgZHJhZnQgbWludXRlcywgaW5jbHVkaW5nIGtleSBkZWNpc2lvbnMsIGZvciB0aGUgTkVU TU9EIFdHDQptZWV0aW5nIGhhdmUgYmVlbiBwb3N0ZWQuICBQbGVhc2UgcmV2aWV3IGFuZCBwcm92 aWRlIGNvcnJlY3Rpb25zDQphcyBuZWVkZWQuDQoNCiAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvbWludXRlcy0xMDMtbmV0bW9kDQoNCktlbnQgKGFuZCBKb2VsIGFuZCBMb3UpDQoN Cg0KDQo= From nobody Thu Dec 6 02:12:21 2018 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4906130DCE; Thu, 6 Dec 2018 02:12:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: netmod@ietf.org Message-ID: <154409113279.3479.12709386345803519413@ietfa.amsl.com> Date: Thu, 06 Dec 2018 02:12:12 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-01.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: Thu, 06 Dec 2018 10:12:13 -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-01.txt Pages : 21 Date : 2018-12-06 Abstract: There is a need to document data defined in YANG models when a live YANG server is not available. Data is often needed already in design time or needed by groups that do not have a live running YANG server available. This document specifies a standard file format for YANG instance data, which follows the syntax and semantic from existing YANG models, re-using existing formats from operation/request and decorates them with metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-01 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-instance-file-format-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 6 02:15:45 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D895131186 for ; Thu, 6 Dec 2018 02:15:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.057 X-Spam-Level: X-Spam-Status: No, score=-4.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=ZJw+tO3o; dkim=pass (1024-bit key) header.d=ericsson.com header.b=AI6UJD68 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXjcNMS9_4bD for ; Thu, 6 Dec 2018 02:15:36 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A4B513114A for ; Thu, 6 Dec 2018 02:15:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1544091334; x=1546683334; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tz4SKAdAFSlRRjUa3RHGf5bq1dbunHa21rTQFy9/I+g=; b=ZJw+tO3oir+OIwJJ2iWWMEsUZJAh5Q+zb/k0X1Xyi5rwB+LsThFsidmtHZ3PjkPA eKT2TtR6UhIp/j4VwdeMomJyfaD46HUC2QXFsqIplQK9bOmwk2v8lusKlti/6URq GJEzZa/r3RYiCPoRADaad/MFrhAbqn5zhB2HelCFpuY=; X-AuditID: c1b4fb3a-8d8849e000002747-63-5c08f6c6842f Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 1D.DC.10055.6C6F80C5; Thu, 6 Dec 2018 11:15:34 +0100 (CET) Received: from ESESBMR502.ericsson.se (153.88.183.134) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 6 Dec 2018 11:15:31 +0100 Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESBMR502.ericsson.se (153.88.183.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 6 Dec 2018 11:15:31 +0100 Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 6 Dec 2018 11:15:31 +0100 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=IS8XFo/ngf4FE1ig8y39vcIN0ht1C2+NPUJzLbgKqeg=; b=AI6UJD68Jg0ZmXecXEEYxq+Pf+4D7rLTW6clNTSpH6HEeEw/zwob9Iee9MkUgYtnyT1v0rM+kUGeoPjdDIca7dj/jP6pTAdP7gHfqM//Rf/xa1PtvCydRkjimM6UF23wjBKOfl3TQnCP72XNJiGVZih7ApV7TQu1ZbUVlaQxbg0= Received: from DB7PR07MB4935.eurprd07.prod.outlook.com (20.177.192.212) by DB7PR07MB5016.eurprd07.prod.outlook.com (20.177.193.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.14; Thu, 6 Dec 2018 10:15:30 +0000 Received: from DB7PR07MB4935.eurprd07.prod.outlook.com ([fe80::c8ee:97bb:db28:7003]) by DB7PR07MB4935.eurprd07.prod.outlook.com ([fe80::c8ee:97bb:db28:7003%2]) with mapi id 15.20.1404.021; Thu, 6 Dec 2018 10:15:30 +0000 From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= To: "netmod@ietf.org" Thread-Topic: New Version Notification for draft-ietf-netmod-yang-instance-file-format-01.txt Thread-Index: AQHUjUw5mF7qxDuqckaqOirCD9H9ZaVxfp0A Date: Thu, 6 Dec 2018 10:15:30 +0000 Message-ID: <35a31eae-9a4f-7d20-a9d3-6b0b60ac8a34@ericsson.com> References: <154409113299.3479.15867089668746650774.idtracker@ietfa.amsl.com> In-Reply-To: <154409113299.3479.15867089668746650774.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] x-forwarded-message-id: <154409113299.3479.15867089668746650774.idtracker@ietfa.amsl.com> user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 x-clientproxiedby: AM6P192CA0055.EURP192.PROD.OUTLOOK.COM (2603:10a6:209:82::32) To DB7PR07MB4935.eurprd07.prod.outlook.com (2603:10a6:10:5b::20) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB7PR07MB5016; 6:dohfTgu25k3Hj3IabWOYiTDo3NgIj+u9YfI825IfK2wnnzoNCNjT/nmAxwCr9ZZk1UnN5S/Xocvgfm9dIP/6SZ/JpxKllRHiYmL4AvCwe+dF6uZkCLtdnir4eWj6kmfv2zZONq+OhS1wGFbG6riy5fQziw1AsrEMXU1Mvccc+yK1LVPaVoBuuVFSXi65FCzF+0Y4t7+eJkhzFMdYgu/GAdgpGW8DLCNr6YBfYKlY5WJCoZKwzKNVYr5Hp498Xvv4ZJzc4fS3lX4st4ld9BBPG1E8jWWTNreBfO0Fq4zIkZGhN1CgMiDqLdCs7yy9qLHl/aFgJ9iTc63bkIO+YUMl98WLNCpe9GX/czHx81HeiUGWqhCr9o3wJEx6FHhE0SHcInknF6Y0E6v/BCKtSmvAFh7p02kGUQJOmL71Z5EbSLySpaSifdexbO1UuD2z8fCQc58J4xE88uT5d8527R4osQ==; 5:iAwRyxx44EgiGzEVtxBcK1TefzDK3lzOCu6SFSHK4sZll/VVHj1Zvi8Nssz1od/wh9UNjiakohzY42lk9d9hB1ZTfjfo3bRgHFDJ9cpGcbAd24fG09Oi9ALEJR7+ReRQMtrQw1JGdMDCz/kOZANgLyLiVFQ1XZ842I95JS8aY8U=; 7:VLogtABO8LhhMGqumkoEJQ86EJFozUaEb5GEaHTSoLij6MtDYHM/jMXY/c2NTeNImVxwTA2vnyfoK5d+AZgRyHTK5msK1ycUfD/GjvE9qTBMa4fSLupd0bkezdPqlXVNqV2tCDxeAV7ymS8HTPgnwA== x-ms-office365-filtering-correlation-id: c1d5be58-8b64-4043-fc06-08d65b63bf04 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:DB7PR07MB5016; x-ms-traffictypediagnostic: DB7PR07MB5016: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231455)(999002)(944501520)(4983020)(52105112)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB5016; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB5016; x-forefront-prvs: 087894CD3C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(136003)(376002)(346002)(252514010)(199004)(189003)(5640700003)(68736007)(3846002)(6116002)(65826007)(8676002)(31686004)(25786009)(1730700003)(99936001)(81166006)(81156014)(97736004)(7736002)(478600001)(606006)(105586002)(966005)(53936002)(2473003)(5660300001)(6512007)(85182001)(6306002)(54896002)(14444005)(236005)(15650500001)(106356001)(85202003)(6436002)(256004)(229853002)(6486002)(8936002)(52116002)(76176011)(99286004)(26005)(316002)(6506007)(386003)(186003)(14454004)(102836004)(58126008)(66066001)(65956001)(65806001)(86362001)(2501003)(36756003)(66574009)(6916009)(2906002)(2351001)(2616005)(31696002)(486006)(476003)(446003)(71200400001)(11346002)(71190400001)(64126003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5016; H:DB7PR07MB4935.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: qvSBC85tU9xJcBuv48FAqVCdSBIe55/kYaqF+gsbQv5ufCllD5jBfZneIukJ8ZC61Hr2NpWJNmF+qpmg4H79Il5iFCpkF5En1lLR3IhXvLvb4zIQjVD5ZjKSpb1IONG8vOa185WM5viZjuTuw3KVM47sYZ433WmW018MOWOZ7sFpHZrW0UetUXiOjBKRSIAgp7DTx80YxJar29nGDkyjaZq3d+SK7DatymEVCO8Dta6D6ajyiuYvJ9fMj0TpZs1BshYW84wD1fsgYtLc4YRYEOWikpbXWMKBRe9EqUtpaWSpGDH30VpeAnBiHygBYXDxHU48t2rjVakdMGKCKHDHslHvMT2+zFZKXWNjRq6xra8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050703020803090505060500" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c1d5be58-8b64-4043-fc06-08d65b63bf04 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Dec 2018 10:15:30.2321 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5016 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA2WSfSxVcRjH/c459zhu7vy63p6pxJ20FHnJZpXIsFrTmq15mXDHCYtL92C0 Voom1NDYUO16m1VMWEli7XqNaGghbeZik26zVOSt1j333Fpb/32e7/Pd93me7WFI6bDIhklQ pLJKhTxRRoup8tBnqc59q0yE68P2bV6q0WsiX3SitnadOIPCxUdj2cSEdFZ58Fi0OL50eI5M 6Y/KaJ1soLPQUHA+MmEAHwJN9yydj8SMFPcgGP5WSQrFCoK3OeXob1GU3UUJRQ0BNQOF+g6F i0jIK6wwBJQQcF89ZiwUGgSDg08pfgyN/SF36SXBswXeC+XPH9M8m+MoePNeq9MZnR4FVa2+ gsUdljRaipcp7ACDtXt4WYJ9oCVHQ/KyFAdB/uhuXjbBp6G5vVIfiLAV/Bhs0A8isTVMzasI 4U4L0Iy+pgW2hMW5XyKBZVD2aUrERwIOgxf10bxsic9BztCM/kTApQgmJ7+Tgv8ADE/MI4F3 wZiqwGAap+Fu6ZqhEQSVCxsGnkLQ22cY5gT9nR0iYdFI6Ji+SRch94p/dhU4D8H0xysV+pO3 w0D5PFWh24/EjlB3Q/a/fT/UVWlJgY9A2YaaFtgeSgo0xgJ7grZ3GQnsAXWNP+lKJH6ELDmW 45Li3N1dWGVCDMclK1wUbGoL0j2W+snm4TakXjjehTCDZKYS0DARUpE8nctM6kIOupzZpvoR ZEMpkhWszEJi5KJrS2LlmZdYZXKUMi2R5brQDoaSWUv8znuFS3GcPJW9wLIprPJPl2BMbLJQ sMdJuy8rAc3Zi+NGnuSkVYZ/82iwvbNf8SZ3W93gc9F7rWFikTRzbXdcz+veakoz4bRXjS4T /SEhdrZnH4wsrEdmvDPP6bEN2TmTcMdudSnGbKt3uS1XGnDPlPXe5zunrf5q1dnaSLyqtgy7 nrh4SlU8FhjaXsfF3qoiPrt9CJRRXLzczYlUcvLfKRAo3GADAAA= Archived-At: Subject: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 10:15:44 -0000 --------------ms050703020803090505060500 Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable

Hello,

We uploaded a new version of the instance data draft. We tried to address all comments and also to rework the format chapter to make it easier to read. We omitted 2 comments:

Rob commented that YANG packages could be used for defining the target modules for instance data: I would like to avoid that because:

  • Packages are not defined for YANG. Currently they are not part of the versioning solution even though they were discussed and are generally a good idea.
  • IMHO as deviations/features are set on module level, just specifying packages would not be enough. If we start using package+module level deviations/features we may end up with a more complicated hybrid solution.
  • Module level YANG target definitions as described in the draft are simple and need no new design

J=C3=BCrgen stated that it would be better to use the YANG XML/JSO= N encoding as a format instead of referencing the get operation/request. I might even agree with him, but for 2 reasons I did not follow his idea:

  • Currently there is no RFC I could reference either for XML or JSON. AFAIK even RFC7951 does not define how multiple modules should be encoded side by side.
  • It is not the job of the instance data draft to dictate how to encode YANG data generally e.g. on the wire.
  • The contents of the get operation/request are well defined

regards Balazs



-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-ietf-netmod-yang-instance-file-format-01.txt
Dat= e: Thu, 6 Dec 2018 02:12:12 -0800
Fro= m: internet-drafts@ietf.org
To:= Benoit Claise <bclaise@cisco.com>, Balazs Lengyel <balazs.lengyel@ericsson.com>



A new version of I-D, draft-ietf-netmod-yang-instance-file-format-01.txt
has been successfully submitted by Balazs Lengyel and posted to the
IETF repository.

Name: draft-ietf-netmod-yang-instance-file-format
Revision: 01
Title: YANG Instance Data File Format
Document date: 2018-12-06
Group: netmod
Pages: 21
URL: https://www.ie= tf.org/internet-drafts/draft-ietf-netmod-yang-instance-file-format-01.txt=
Status: https://datatracker.ietf= =2Eorg/doc/draft-ietf-netmod-yang-instance-file-format/
Htmlized: https://tools.ietf.org/html= /draft-ietf-netmod-yang-instance-file-format-01
Htmlized: https://datatracker.= ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format
Diff: https://www.ietf.or= g/rfcdiff?url2=3Ddraft-ietf-netmod-yang-instance-file-format-01

Abstract:
There is a need to document data defined in YANG models when a live
YANG server is not available. Data is often needed already in design
time or needed by groups that do not have a live running YANG server
available. This document specifies a standard file format for YANG<= br> instance data, which follows the syntax and semantic from existing<= br> YANG models, re-using existing formats from <get> operation/request
and decorates them with metadata.



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

The IETF Secretariat

--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@erics=
son.com=20
--------------ms050703020803090505060500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20 wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4 ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9 ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9 YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF 1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6 EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0 NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA 7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3 Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5 lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+ MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0 LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9 2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa 49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9 jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTIwNjEwMTUyNlow LwYJKoZIhvcNAQkEMSIEIPCRpyqHP85dFFnN4Ibrxy9Gr+ncw4aTuKwyaHFBUXnlMGsGCSsG AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh MA0GCSqGSIb3DQEBAQUABIIBAMaaqz23IyXd+/KjbSx/cvS+rKZC0Qz2aaUvEht/R6O2QlIN UsHvaLBFOhPHYaOEsb69nCSi9XNWx6lTOWLrUna2I54somKr47lJD2gzDzIqT0B1duWD8kkp zgzAcgrplbaPOzrPGdP1oFZm25G/dk9yHHQfoEOh8bjSpkyq6mx0fAUGC9/Mb3eVdSN2/fOc boRBds79MLJe6WXBLt3AuUPdXJUHMKQwZDKVv0htYDbjSV+Mkml5cZkVbIRd79z3nJN9iB9P VEKr82yWpG7Hjydw66J9tyaI27LO+CtC+4MIcBzDEfuwKWPODAzWtFnR2jKAyPOzHa3OPHbK iFJSrGAAAAAAAAA= --------------ms050703020803090505060500-- From nobody Thu Dec 6 04:25:31 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84152130DCC for ; Thu, 6 Dec 2018 04:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW8uACtAkXOq for ; Thu, 6 Dec 2018 04:25:26 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AEBD1286E7 for ; Thu, 6 Dec 2018 04:25:26 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 0A548FB4; Thu, 6 Dec 2018 13:25:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id aH7v_NTjESO2; Thu, 6 Dec 2018 13:25:25 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 6 Dec 2018 13:25:25 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E8E6D20044; Thu, 6 Dec 2018 13:25:24 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id L1cyvZ5iXvpV; Thu, 6 Dec 2018 13:25:24 +0100 (CET) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 6E1D22003F; Thu, 6 Dec 2018 13:25:24 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Thu, 6 Dec 2018 13:25:24 +0100 Received: by anna.localdomain (Postfix, from userid 501) id CAAD630049707A; Thu, 6 Dec 2018 13:25:23 +0100 (CET) Date: Thu, 6 Dec 2018 13:25:23 +0100 From: Juergen Schoenwaelder To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel CC: "netmod@ietf.org" Message-ID: <20181206122523.o3o7m5qbtuceevap@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod@ietf.org" References: <154409113299.3479.15867089668746650774.idtracker@ietfa.amsl.com> <35a31eae-9a4f-7d20-a9d3-6b0b60ac8a34@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <35a31eae-9a4f-7d20-a9d3-6b0b60ac8a34@ericsson.com> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 12:25:30 -0000 On Thu, Dec 06, 2018 at 10:15:30AM +0000, Balázs Lengyel wrote: > > Jrgen stated that it would be better to use the YANG XML/JSON encoding as > a format instead of referencing the get operation/request. I might even > agree with him, but for 2 reasons I did not follow his idea: > > * Currently there is no RFC I could reference either for XML or JSON. > AFAIK even RFC7951 does not define how multiple modules should be > encoded side by side. > * It is not the job of the instance data draft to dictate how to encode > YANG data generally e.g. on the wire. > * The contents of the get operation/request are well defined > The first bullet needs to be taken care of but it is not too difficult I think. I fail to understand what bullet two is about or why it matters. We are talking about the instance file format, no more and no less. Yes, the contents of the get operation/request are well defined but the definitions are not generically applicable to define instance file formats and the dependincy of the instance file format on protocols is problematic from a maintenance perspective. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Dec 6 04:41:09 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D325131173 for ; Thu, 6 Dec 2018 04:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 pU4k6T9Vhmqv for ; Thu, 6 Dec 2018 04:41:00 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 79F5C130EF5 for ; Thu, 6 Dec 2018 04:41:00 -0800 (PST) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 5F4251AE0383; Thu, 6 Dec 2018 13:40:59 +0100 (CET) Date: Thu, 06 Dec 2018 13:40:58 +0100 (CET) Message-Id: <20181206.134058.1870987445768444391.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: balazs.lengyel@ericsson.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20181206122523.o3o7m5qbtuceevap@anna.jacobs.jacobs-university.de> References: <154409113299.3479.15867089668746650774.idtracker@ietfa.amsl.com> <35a31eae-9a4f-7d20-a9d3-6b0b60ac8a34@ericsson.com> <20181206122523.o3o7m5qbtuceevap@anna.jacobs.jacobs-university.de> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-01.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 12:41:08 -0000 Juergen Schoenwaelder wrote: > On Thu, Dec 06, 2018 at 10:15:30AM +0000, Bal=C3=A1zs Lengyel wrote: > > = > > J=FCrgen stated that it would be better to use the YANG XML/JSON= encoding as > > a format instead of referencing the get operation/request. I mig= ht even > > agree with him, but for 2 reasons I did not follow his idea: > > = > > * Currently there is no RFC I could reference either for XML o= r JSON. > > AFAIK even RFC7951 does not define how multiple modules shou= ld be > > encoded side by side. > > * It is not the job of the instance data draft to dictate how = to encode > > YANG data generally e.g. on the wire. > > * The contents of the get operation/request are well defined > > > = > The first bullet needs to be taken care of but it is not too difficul= t > I think. > = > I fail to understand what bullet two is about or why it matters. We > are talking about the instance file format, no more and no less. > = > Yes, the contents of the get operation/request are well defined but > the definitions are not generically applicable to define instance fil= e > formats and the dependincy of the instance file format on protocols > is problematic from a maintenance perspective. I agree. I'm not even convinced that the current text is clear and correct: The content-data part of the XML format SHALL follow the format returned for a NETCONF GET operation. The anydata node SHALL contain all elements that would be inside the wrapper element of a reply to the operation. What exactly does "all elements that would be inside the " mean? Does it mean that if a server supports 10 modules, all 10 modules MUST be part of all instance files? Probably not. Since the "content-data" is of type "anydata", I think that we don't need much additional text. Maybe something like: The "content-data" part may contain data from multiple modules, in any order. For any node in "content-data", the path from the data model root node down to the node, including any elements necessary to uniquely identify the node, is included in the response message. /martin From nobody Fri Dec 7 00:21:07 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00F112875B for ; Fri, 7 Dec 2018 00:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zay6bjPD1VPC for ; Fri, 7 Dec 2018 00:21:02 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 54B5512426A for ; Fri, 7 Dec 2018 00:21:02 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E0ABAAF; Fri, 7 Dec 2018 09:20:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1544170859; bh=KMKO+V7JYdt5emjWaLHI8wF2hDrpl2At06dolBKAtmk=; h=Date:From:To:Subject:From; b=vMezcUpkcwwubUWZGqJjzFAbFGwJxm+Im2N4jjrt6v4abNiZR2RS0Wxx3QV0F1Yic BppeSaeEkumYNtp7ibWJJgChaC+YLJly1s+Oq0UIpSEnvmIlW+o43bORjY++JkKXYr +t2sd+6nZ7iJ7Q0TBKPZfzgycuj0NFYQIDHTBFAE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DC98E9F for ; Fri, 7 Dec 2018 09:20:59 +0100 (CET) Date: Fri, 7 Dec 2018 09:20:59 +0100 (CET) From: Mikael Abrahamsson To: netmod@ietf.org Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [netmod] question regarding IPv6 address format / canonical X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2018 08:21:05 -0000 Hi, we've had an interesting interop problem, and we don't know if this is a client, server, or just interop problem. However, I thought I'd bring it to the attention here. The server produced an output that was in the format of: 2a00:db8:1:2:3::5:0 When the client then asked for information about this object it used: 2a00:db8:1:2:3:0:5:0 The netconf server then returned no answer, because it didn't consider these to be the same (string match). I have included what I think is relevant text below, it seems the client reformatted the address into canonical format. However, the description below seems to indicate that all those IPv6 types are ok. If the server must use canonical format, is there a MUST somewhere that says so? What does it mean that something is a "canonical format"? https://tools.ietf.org/html/rfc6021 typedef ipv6-address { type string { ... } description "The ipv6-address type represents an IPv6 address in full, mixed, shortened, and shortened-mixed notation. The IPv6 address may include a zone index, separated by a % sign. The zone index is used to disambiguate identical address values. For link-local addresses, the zone index will typically be the interface index number or the name of an interface. If the zone index is not present, the default zone of the device will be used. The canonical format of IPv6 addresses uses the compressed format described in RFC 4291, Section 2.2, item 2 with the following additional rules: the :: substitution must be applied to the longest sequence of all-zero 16-bit chunks in an IPv6 address. If there is a tie, the first sequence of all-zero 16-bit chunks is replaced by ::. Single all-zero 16-bit chunks are not compressed. The canonical format uses lowercase characters and leading zeros are not allowed. The canonical format for the zone index is the numerical format as described in RFC 4007, Section 11.2."; reference "RFC 4291: IP Version 6 Addressing Architecture RFC 4007: IPv6 Scoped Address Architecture RFC 5952: A Recommendation for IPv6 Address Text Representation"; } -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Dec 7 00:46:38 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458E312875B for ; Fri, 7 Dec 2018 00:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOobAKJob5yc for ; Fri, 7 Dec 2018 00:46:33 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ECB5124BF6 for ; Fri, 7 Dec 2018 00:46:33 -0800 (PST) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id CF16A62679 for ; Fri, 7 Dec 2018 09:46:31 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1544172391; bh=G6ZOMnvJgi3DGmcLhxh8QqsimvCLOPGXzaOOFptCJEI=; h=From:To:Date; b=VMzXwNtGQzLuMtwj0Saydex/qXHckOIkaWID/+Gs23sfngN20/Jwe4QxRh1Azqh8Q H5pa7806JeUlZixNqM4fzjU4hZTfK7ZonBGcTpgBNDCHERoGAbJ1jveXT3rVS2VTvC 8kf+PgD9S4wAtm9vexBblUvfABIyluxm5KDJWYdw= Message-ID: <5ea8671bd7642bb39732dd60d3077c5642f435a5.camel@nic.cz> From: Ladislav Lhotka To: netmod@ietf.org Date: Fri, 07 Dec 2018 09:46:31 +0100 In-Reply-To: References: Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] question regarding IPv6 address format / canonical X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2018 08:46:36 -0000 Hi Mikael, On Fri, 2018-12-07 at 09:20 +0100, Mikael Abrahamsson wrote: > Hi, > > we've had an interesting interop problem, and we don't know if this is a > client, server, or just interop problem. However, I thought I'd bring it > to the attention here. > > The server produced an output that was in the format of: > > 2a00:db8:1:2:3::5:0 Correct - this is the canonical value. > > When the client then asked for information about this object it used: > > 2a00:db8:1:2:3:0:5:0 > > The netconf server then returned no answer, because it didn't consider > these to be the same (string match). This is a bug in server implementation. > > I have included what I think is relevant text below, it seems the client > reformatted the address into canonical format. However, the description > below seems to indicate that all those IPv6 types are ok. If the server > must use canonical format, is there a MUST somewhere that says so? > > What does it mean that something is a "canonical format"? It is the value that the server (conceptually) uses internally. See sec. 9.1 in RFC 7950. Lada > > https://tools.ietf.org/html/rfc6021 > > typedef ipv6-address { > type string { > .... > } > description > "The ipv6-address type represents an IPv6 address in full, > mixed, shortened, and shortened-mixed notation. The IPv6 > address may include a zone index, separated by a % sign. > The zone index is used to disambiguate identical address > values. For link-local addresses, the zone index will > typically be the interface index number or the name of an > interface. If the zone index is not present, the default > zone of the device will be used. > > The canonical format of IPv6 addresses uses the compressed > format described in RFC 4291, Section 2.2, item 2 with the > following additional rules: the :: substitution must be > applied to the longest sequence of all-zero 16-bit chunks > in an IPv6 address. If there is a tie, the first sequence > of all-zero 16-bit chunks is replaced by ::. Single > all-zero 16-bit chunks are not compressed. The canonical > format uses lowercase characters and leading zeros are > not allowed. The canonical format for the zone index is > the numerical format as described in RFC 4007, Section > 11.2."; > reference > "RFC 4291: IP Version 6 Addressing Architecture > RFC 4007: IPv6 Scoped Address Architecture > RFC 5952: A Recommendation for IPv6 Address Text Representation"; > } > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Dec 7 00:52:03 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A3B130DD4 for ; Fri, 7 Dec 2018 00:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV4xuTK4VFyC for ; Fri, 7 Dec 2018 00:51:55 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 5EF7C129C6B for ; Fri, 7 Dec 2018 00:51:55 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5919FAF; Fri, 7 Dec 2018 09:51:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1544172713; bh=z07fh7dG7nSqM9bs6rrx6tKYyZoY75tB/De+EYwJEEk=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=bv8X63LwWaJ+ccqIi9uDas1sRqtzGzPo+BUuDsqmDLdq0+iwiuW+Nts7ZkK9UO6/r qwJm5wXWveiEN1bGMrbfTuvYBqhzv4ghJhEUo8gWgeEGe/NSoseMSl3hJ6GVCUQ8P+ u5JT8bVaK4vmY8f128uMgp+37GVBfi5jCNjIdcZ8= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 56FCC9F; Fri, 7 Dec 2018 09:51:53 +0100 (CET) Date: Fri, 7 Dec 2018 09:51:53 +0100 (CET) From: Mikael Abrahamsson To: Ladislav Lhotka cc: netmod@ietf.org In-Reply-To: <5ea8671bd7642bb39732dd60d3077c5642f435a5.camel@nic.cz> Message-ID: References: <5ea8671bd7642bb39732dd60d3077c5642f435a5.camel@nic.cz> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [netmod] question regarding IPv6 address format / canonical X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2018 08:52:02 -0000 On Fri, 7 Dec 2018, Ladislav Lhotka wrote: > Hi Mikael, > > On Fri, 2018-12-07 at 09:20 +0100, Mikael Abrahamsson wrote: >> Hi, >> >> we've had an interesting interop problem, and we don't know if this is a >> client, server, or just interop problem. However, I thought I'd bring it >> to the attention here. >> >> The server produced an output that was in the format of: >> >> 2a00:db8:1:2:3::5:0 > > Correct - this is the canonical value. "Single all-zero 16-bit chunks are not compressed. " So that doesn't seem like the canonical value to me? >> >> When the client then asked for information about this object it used: >> >> 2a00:db8:1:2:3:0:5:0 This is the canonical value according to my interpretation. >> The netconf server then returned no answer, because it didn't consider >> these to be the same (string match). > > This is a bug in server implementation. Can you please elaborate? What is the bug here? >> >> I have included what I think is relevant text below, it seems the client >> reformatted the address into canonical format. However, the description >> below seems to indicate that all those IPv6 types are ok. If the server >> must use canonical format, is there a MUST somewhere that says so? >> >> What does it mean that something is a "canonical format"? > > It is the value that the server (conceptually) uses internally. See sec. 9.1 in > RFC 7950. Ok, so if the server doesn't re-format and always uses string in the canonical format, that's a clear bug? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Dec 7 01:11:51 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AF4127333 for ; Fri, 7 Dec 2018 01:11:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcHxfPADu5Wi for ; Fri, 7 Dec 2018 01:11:47 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553D4124BF6 for ; Fri, 7 Dec 2018 01:11:47 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 8E597FC5; Fri, 7 Dec 2018 10:11:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id TzBocYLJflFR; Fri, 7 Dec 2018 10:11:45 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 7 Dec 2018 10:11:45 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 78B1720043; Fri, 7 Dec 2018 10:11:45 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id K9dpqckYhj4S; Fri, 7 Dec 2018 10:11:45 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 2C5892003F; Fri, 7 Dec 2018 10:11:45 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Fri, 7 Dec 2018 10:11:44 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 89CE2300498CDF; Fri, 7 Dec 2018 10:11:44 +0100 (CET) Date: Fri, 7 Dec 2018 10:11:44 +0100 From: Juergen Schoenwaelder To: Mikael Abrahamsson CC: Ladislav Lhotka , Message-ID: <20181207091144.22bhdvp6q26wregm@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Mikael Abrahamsson , Ladislav Lhotka , netmod@ietf.org References: <5ea8671bd7642bb39732dd60d3077c5642f435a5.camel@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] question regarding IPv6 address format / canonical X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2018 09:11:50 -0000 On Fri, Dec 07, 2018 at 09:51:53AM +0100, Mikael Abrahamsson wrote: > > > > It is the value that the server (conceptually) uses internally. See sec. 9.1 in > > RFC 7950. > > Ok, so if the server doesn't re-format and always uses string in the > canonical format, that's a clear bug? > Yes. How the server does things internally does not matter but comparisons must conceptually use the canonical format (and this is why it is so important to define the canonical representation in type definitions). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Dec 7 09:41:25 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8E2130F20 for ; Fri, 7 Dec 2018 09:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOnyOsyNVamD for ; Fri, 7 Dec 2018 09:41:20 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14EB130F0A for ; Fri, 7 Dec 2018 09:41:20 -0800 (PST) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id wB7HeSB3001552 for ; Fri, 7 Dec 2018 09:41:19 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=CM+ngUTU25YY65jZBK+9x7tB+J8JXzkiED485/wKs9s=; b=zc2xw7roRjuDndvCcLIjK2v/FfPlYKlXB6LoLBMFuf7dc1jUnB9sZCK9KMbLPAXPceeG +sDZadE2ZHRP+tn57Oppd/7Ds8NUBkxY0WlF60bezkidNNB+9Ze8V8gkXJZdw9NktczA 2d1iCAAcYkR39ulN4IdIwnXuPDloX1bv8t8o5Ku4/t/q22I+vnkmgoVjhHFHPxeoNCJa ntvOpLrwADOGAs4Lb8NCYtp7p07AEYcbsOKf63u0aV7xnSGsiX0VxXf+z8qZfbZU+NvD coKLqPMMvdC9XpogCAwSggYnnPeTgP+FplIMhAzEttugyU3zzFw2WFpYgCsUpK35QWVS iA== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2053.outbound.protection.outlook.com [104.47.36.53]) by mx0a-00273201.pphosted.com with ESMTP id 2p7ves03wn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 07 Dec 2018 09:41:19 -0800 Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4043.namprd05.prod.outlook.com (20.176.71.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.8; Fri, 7 Dec 2018 17:41:17 +0000 Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::f0f3:20f0:2104:638c]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::f0f3:20f0:2104:638c%2]) with mapi id 15.20.1404.021; Fri, 7 Dec 2018 17:41:17 +0000 From: Kent Watsen To: NETMOD Working Group Thread-Topic: Comments on draft-ietf-netconf-keystore-07 Thread-Index: AdSNTY3WYTbcD2eSQECPpWnErs7VugA3JcYA Date: Fri, 7 Dec 2018 17:41:17 +0000 Message-ID: <96290FC7-159F-42D4-BD6B-9159EEA8A447@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.4.181110 x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM6PR05MB4043; 6:oyrg01TW1j2VwzcR9xJAkowgi/JaCh7GL6rIyTN4RACfFoOib+dRngF8Itq5Zt6e7PYz7TnD9iffjDF3YpxLUKAmLGNzUvyXBbpfc1BiuUmCSOwsDmMVFRBkC14lmkxy6hLCvv77scf8g3QPJErFo/ZCVn6YZRIKiZmP68AWarGB/AHHtkhAyNIQ1f3UtoHVxRZZqtDrvdsbI7vJF6gIxjgMxYjg7qTUdeJF9VSavaK3T9EWQgtpdL6L85Gjxnfd4ZQPyZAC3frKrETsPaw2IiWG9Jx4kM6edh/6Mp3cMwB+if03cloRbwXwrk9cwRtPokBa/0y4H3QvjtD5abFGC8Fms8rav6+2w7gh5ennsv7B/sxMqHTrfneDQ6wNn8/cNT21Ef70MABLhhYHxVUnZJp/tJ3e8d0qUze+pCY0j1ZWG0yQXNW16wIpH120dlTcxZ6s2L40dtWhoPAJHGS8gw==; 5:POoGw1hn4hTag8gUjAQ4IZ5kqKmIU8pzPsPssahSiwVN2fddaLANUdODpk/AqxqtC7eMC+ztUZSGoaUdpLzDpwzpFc7T13YhlocHkleI/UJyjuh9sN6KIUx8DRvx6O8A8nrAUiyFGKMk52IRS9QdodRlmUEEXUiLTdbyWto+exg=; 7:mg1EhLfmrFvf4hFz8jsK+RZUa7z0FyEiXbszsHMWq1c37bNfpgugjcUG7DjEJPNJ1psPJXsrmdybz9NFNBcUx6jKgTnyJdVXoDouo2ZyrxczW4eEd6kNgCjLqiyAhR800mcfrsHdI4InokIh3aArVA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: dd4aa429-73f0-4795-8d1e-08d65c6b3134 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:DM6PR05MB4043; x-ms-traffictypediagnostic: DM6PR05MB4043: x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230011)(999002)(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231466)(944501520)(52105112)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:DM6PR05MB4043; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4043; x-forefront-prvs: 0879599414 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(136003)(39860400002)(366004)(376002)(189003)(199004)(8676002)(5660300001)(99286004)(606006)(71190400001)(71200400001)(58126008)(81166006)(81156014)(316002)(6916009)(6506007)(8936002)(66066001)(33656002)(82746002)(76176011)(102836004)(53546011)(83716004)(14444005)(256004)(5024004)(229853002)(3846002)(6486002)(6306002)(446003)(2616005)(11346002)(2473003)(790700001)(106356001)(6116002)(236005)(6512007)(54896002)(68736007)(14454004)(105586002)(36756003)(86362001)(476003)(25786009)(97736004)(186003)(2906002)(26005)(7736002)(53936002)(6436002)(966005)(478600001)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4043; H:DM6PR05MB4665.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: uAl9/eyGCctHxNNWZrZUPtCiYnm8t1htvTQe0EbYzauwv3IVDZ8XGJgtzI3y8PY0+84priR3ivPQcxBw3IgtFK7MR8UHW/bqEeCbky7Sn4NEqLBhEMQW7StjVnTC2llNKCC5ujkxLeYRPXC6n8v4/mAfUj8t1r9MyImwuNA0K7KcFfzHuneRfNwlW1474Y6nzOSYc282nCiO0UNQLSo44KlHNw7hweyOCYIOacSuwefj/hMQovEof7F9v1TDD7M/B1HEcdWXXQnKfbTnEn8g+J0ARFPKT9xeTAL3pU9ZHzx74ZcYkbLO1wy38hLNUJBZB1OtaIpACnnkR1J5tg7P3NfCVSWTX7ps8jcEFcpTb2E= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_96290FC7159F42D4BD6B9159EEA8A447junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: dd4aa429-73f0-4795-8d1e-08d65c6b3134 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2018 17:41:17.5193 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4043 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-07_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812070141 Archived-At: Subject: [netmod] FW: Comments on draft-ietf-netconf-keystore-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 07 Dec 2018 17:41:24 -0000 --_000_96290FC7159F42D4BD6B9159EEA8A447junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WUFORyBleHBlcnRzLA0KDQpXaHkgYXJlIGFjdGlvbi9ub3RpZmljYXRpb24gc3RhdGVtZW50cyBu b3QgYWxsb3dlZCB1bmRlciBhIGNhc2Ugc3RhdGVtZW50PyAgWWVzLCBpdOKAmXMgc2ltcGxlIHRv IGFzc2VydCwgYnV0IHdhcyBpdCBjb25zaWRlcmVkLCBpbiBzdWNoIGNhc2VzLCB0byBpbnN0ZWFk IGFsbG93IHRoZW0gdG8gYXR0YWNoL2JpbmQgdG8gdGhlIGNsb3Nlc3QgbGVnYWwgYW5jZXN0b3I/ ICBXb3VsZCBpdCBtYWtlIHNlbnNlPw0KDQpOaXQ6IEl0IHdvdWxk4oCZdmUgYmVlbiBoZWxwZnVs IGlmIHRoZSDigJxTaW5jZSBh4oCdIHBhcmFncmFwaHMgcXVvdGVkIGJlbG93IHJlZmVyZW5jZWQg c2VjdGlvbnMgNy4xLjEgKFRoZSBtb2R1bGUncyBTdWJzdGF0ZW1lbnRzKSBhbmQgNy45LjIuMSAo VGhlIGNhc2UncyBTdWJzdGF0ZW1lbnRzKS4uLg0KDQpQUzogTmVpdGhlciBgcHlhbmdgIG5vciBg eWFuZ2xpbnRgIGNhdGNoIHRoaXMgbWlzdXNlLg0KDQpLZW50IC8vIGNvbnRyaWJ1dG9yDQoNCg0K T24gMTIvNi8xOCwgNTozOSBBTSwgIkRoYW5hcGFsLCBSYW1rdW1hciAoTm9raWEgLSBJTi9DaGVu bmFpKSIgPHJhbWt1bWFyLmRoYW5hcGFsQG5va2lhLmNvbTxtYWlsdG86cmFta3VtYXIuZGhhbmFw YWxAbm9raWEuY29tPj4gd3JvdGU6DQoNCkhpIEtlbnQsDQpXZSBzZWUgdGhlIGZvbGxvd2luZyBk ZWZpbml0aW9uIGluIGRyYWZ0LWlldGYtbmV0Y29uZi1rZXlzdG9yZS0wNy4NCg0KZ3JvdXBpbmcg bG9jYWwtb3Ita2V5c3RvcmUtZW5kLWVudGl0eS1jZXJ0LXdpdGgta2V5LWdyb3VwaW5nIHsNCiAg ICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgIkEgZ3JvdXBpbmcgdGhhdCBleHBhbmRzIHRvIGFs bG93IGFuIGVuZC1lbnRpdHkgY2VydGlmaWNhdGUNCiAgICAgICAgICAoYW5kIGl0cyBhc3NvY2lh dGVkIHByaXZhdGUga2V5KSB0byBiZSBlaXRoZXIgc3RvcmVkIGxvY2FsbHksDQogICAgICAgICB3 aXRoaW4gdGhlIHVzaW5nIGRhdGEgbW9kZWwsIG9yIGJlIGEgcmVmZXJlbmNlIHRvIGEgc3BlY2lm aWMNCiAgICAgICAgICBjZXJ0aWZpY2F0ZSBpbiB0aGUga2V5c3RvcmUuIjsNCiAgICAgICBjaG9p Y2UgbG9jYWwtb3Ita2V5c3RvcmUgew0KICAgICAgICAgbWFuZGF0b3J5IHRydWU7DQogICAgICAg ICBjYXNlIGxvY2FsIHsNCiAgICAgICAgICAgaWYtZmVhdHVyZSAibG9jYWwta2V5cy1zdXBwb3J0 ZWQiOw0KICAgICAgICAgICB1c2VzIGN0OmFzeW1tZXRyaWMta2V5LXBhaXItZ3JvdXBpbmc7DQog ICAgICAgICAgIHVzZXMgY3Q6ZW5kLWVudGl0eS1jZXJ0LWdyb3VwaW5nOw0KICAgICAgICAgfQ0K ICAgICAgICAgY2FzZSBrZXlzdG9yZSB7DQogICAgICAgICAgIGlmLWZlYXR1cmUgImtleXN0b3Jl LXN1cHBvcnRlZCI7DQogICAgICAgICAgIGxlYWYgcmVmZXJlbmNlIHsNCiAgICAgICAgICAgICB0 eXBlIGtzOmFzeW1tZXRyaWMta2V5LWNlcnRpZmljYXRlLXJlZjsNCiAgICAgICAgICAgICBkZXNj cmlwdGlvbg0KICAgICAgICAgICAgICAgIkEgcmVmZXJlbmNlIHRvIGEgc3BlY2lmaWMgY2VydGlm aWNhdGUsIGFuZCBpdHMNCiAgICAgICAgICAgICAgICBhc3NvY2lhdGVkIHByaXZhdGUga2V5LCBz dG9yZWQgaW4gdGhlIGtleXN0b3JlLiI7DQogICAgICAgICAgIH0NCiAgICAgICAgIH0NCiAgICAg ICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICJBIGNob2ljZSBiZXR3ZWVuIGFuIGlubGluZWQg ZGVmaW5pdGlvbiBhbmQgYSBkZWZpbml0aW9uDQogICAgICAgICAgICB0aGF0IGV4aXN0cyBpbiB0 aGUga2V5c3RvcmUuIjsNCiAgICAgICB9DQogICAgIH0NCg0KSW4gY3Q6YXN5bW1ldHJpYy1rZXkt cGFpci1ncm91cGluZywgMiBhY3Rpb25zIGFyZSBkZWZpbmVkLg0KSW4gY3Q6ZW5kLWVudGl0eS1j ZXJ0LWdyb3VwaW5nLCAxIG5vdGlmaWNhdGlvbiBpcyBkZWZpbmVkLg0KDQpCdXQgdy5yLnQuIFJG Qzc5NTAgcmVmZXJlbmNlcyBiZWxvdywgbG9va3MgbGlrZSBpdCBpcyBub3Qgb2theSB0byBoYXZl IGVpdGhlciBhY3Rpb25zIG9yIG5vdGlmaWNhdGlvbnMgaW4g4oCcY2FzZeKAnSBzdGF0ZW1lbnRz Lg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzk1MCNzZWN0aW9uLTcuMTU8aHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5p ZXRmLm9yZ19odG1sX3JmYzc5NTAtMjNzZWN0aW9uLTJENy4xNSZkPUR3TUZBZyZjPUhBa1l1aDYz cnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09I N1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09NU1kU2RsaVA5SjNoZ3ZHaGtHQ2N0MlhjS3BaMDIt RXZCaDctMVhndUJwYyZzPVVOdmZaRmpwbUZhSTdlc2dqSHhyb2NCWnR0Z2pRNXZ5Zm4yRV9Ua3J4 Rm8mZT0+DQoNCiAgICAgICAgU2luY2UgYW4gYWN0aW9uIGNhbm5vdCBiZSBkZWZpbmVkIGF0IHRo ZSB0b3AgbGV2ZWwgb2YgYSBtb2R1bGUgb3IgaW4NCg0KICAgICAgICBhICJjYXNlIiBzdGF0ZW1l bnQsIGl0IGlzIGFuIGVycm9yIGlmIGEgZ3JvdXBpbmcgdGhhdCBjb250YWlucyBhbg0KDQogICAg ICAgIGFjdGlvbiBhdCB0aGUgdG9wIG9mIGl0cyBub2RlIGhpZXJhcmNoeSBpcyB1c2VkIGF0IHRo ZSB0b3AgbGV2ZWwgb2YgYQ0KDQogICAgICAgIG1vZHVsZSBvciBpbiBhIGNhc2UgZGVmaW5pdGlv bg0KDQoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc5NTAjc2VjdGlvbi03LjE2 PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9v bHMuaWV0Zi5vcmdfaHRtbF9yZmM3OTUwLTIzc2VjdGlvbi0yRDcuMTYmZD1Ed01GQWcmYz1IQWtZ dWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlF UG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPTVNZFNkbGlQOUozaGd2R2hrR0NjdDJYY0tw WjAyLUV2Qmg3LTFYZ3VCcGMmcz1yUU5CcUxQZXRfdkViM0ZZZzBFMDFCaG54ZE5RMHUyMWI0ZnJN WjZXb2RNJmU9Pg0KDQogICAgICAgIFNpbmNlIGEgbm90aWZpY2F0aW9uIGNhbm5vdCBiZSBkZWZp bmVkIGluIGEgImNhc2UiIHN0YXRlbWVudCwgaXQgaXMNCg0KICAgICAgICBhbiBlcnJvciBpZiBh IGdyb3VwaW5nIHRoYXQgY29udGFpbnMgYSBub3RpZmljYXRpb24gYXQgdGhlIHRvcCBvZiBpdHMN Cg0KICAgICAgICBub2RlIGhpZXJhcmNoeSBpcyB1c2VkIGluIGEgY2FzZSBkZWZpbml0aW9uLg0K DQoNCg0KQ2FuIHlvdSBwbGVhc2UgY2hlY2sgYW5kIHByb3ZpZGUgeW91ciBmZWVkYmFjaz8gT3Ig QW0gSSBtaXNzaW5nIHNvbWV0aGluZyBoZXJlPw0KDQoNCg0KVGhhbmtzICYgUmVnYXJkcywNCg0K UmFta3VtYXINCg0K --_000_96290FC7159F42D4BD6B9159EEA8A447junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <57A154B4619B164BBCCE455F2655DB0E@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAuTXNvTGlzdFBh cmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNv LXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJY29sb3I6YmxhY2s7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tSU47fQ0Kc3Bhbi5FbWFp bFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29sb3I6d2lu ZG93dGV4dDsNCgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5v bmU7DQoJdmVydGljYWwtYWxpZ246YmFzZWxpbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+WUFORyBleHBlcnRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+V2h5IGFyZSBhY3Rpb24vbm90aWZpY2F0aW9uIHN0YXRlbWVu dHMgbm90IGFsbG93ZWQgdW5kZXIgYSBjYXNlIHN0YXRlbWVudD8mbmJzcDsgWWVzLCBpdOKAmXMg c2ltcGxlIHRvIGFzc2VydCwgYnV0IHdhcyBpdCBjb25zaWRlcmVkLCBpbiBzdWNoIGNhc2VzLCB0 byBpbnN0ZWFkIGFsbG93IHRoZW0gdG8gYXR0YWNoL2JpbmQgdG8gdGhlIGNsb3Nlc3QgbGVnYWwg YW5jZXN0b3I/Jm5ic3A7DQogV291bGQgaXQgbWFrZSBzZW5zZT88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk5pdDogSXQgd291bGTigJl2ZSBiZWVuIGhlbHBmdWwg aWYgdGhlIOKAnFNpbmNlIGHigJ0gcGFyYWdyYXBocyBxdW90ZWQgYmVsb3cgcmVmZXJlbmNlZCBz ZWN0aW9ucyA3LjEuMSAoVGhlIG1vZHVsZSdzIFN1YnN0YXRlbWVudHMpIGFuZCA3LjkuMi4xIChU aGUgY2FzZSdzIFN1YnN0YXRlbWVudHMpLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5QUzogTmVpdGhlciBgcHlhbmdgIG5vciBgeWFuZ2xpbnRgIGNhdGNoIHRo aXMgbWlzdXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+S2Vu dCAvLyBjb250cmlidXRvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiAxMi82LzE4LCA1OjM5IEFNLCAmcXVvdDtEaGFuYXBhbCwgUmFta3VtYXIg KE5va2lhIC0gSU4vQ2hlbm5haSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyYW1rdW1hci5k aGFuYXBhbEBub2tpYS5jb20iPnJhbWt1bWFyLmRoYW5hcGFsQG5va2lhLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgS2VudCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHNlZSB0 aGUgZm9sbG93aW5nIGRlZmluaXRpb24gaW4gZHJhZnQtaWV0Zi1uZXRjb25mLWtleXN0b3JlLTA3 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ncm91cGluZyBsb2NhbC1vci1rZXlzdG9yZS1lbmQt ZW50aXR5LWNlcnQtd2l0aC1rZXktZ3JvdXBpbmcgezxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlc2NyaXB0 aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7QSBncm91cGluZyB0aGF0IGV4 cGFuZHMgdG8gYWxsb3cgYW4gZW5kLWVudGl0eSBjZXJ0aWZpY2F0ZTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IChhbmQgaXRzIGFzc29jaWF0ZWQgcHJpdmF0ZSBrZXkpIHRvIGJl IGVpdGhlciBzdG9yZWQgbG9jYWxseSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O3dpdGhpbiB0aGUgdXNpbmcgZGF0YSBtb2RlbCwgb3IgYmUgYSByZWZlcmVuY2UgdG8gYSBzcGVj aWZpYzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNlcnRpZmljYXRlIGluIHRo ZSBrZXlzdG9yZS4mcXVvdDs7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgY2hvaWNlIGxvY2FsLW9yLWtleXN0 b3JlIHs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtYW5kYXRvcnkgdHJ1ZTs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjYXNlIGxvY2FsIHs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBpZi1mZWF0dXJlICZxdW90O2xvY2FsLWtleXMtc3VwcG9ydGVk JnF1b3Q7OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVzZXMgPHNw YW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij4NCmN0OmFz eW1tZXRyaWMta2V5LXBhaXItZ3JvdXBpbmc7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVzZXM8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNv LWhpZ2hsaWdodDp5ZWxsb3ciPiBjdDplbmQtZW50aXR5LWNlcnQtZ3JvdXBpbmc7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBjYXNlIGtleXN0b3JlIHs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBpZi1mZWF0dXJlICZxdW90O2tleXN0b3JlLXN1cHBvcnRlZCZxdW90Ozs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsZWFmIHJlZmVyZW5jZSB7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBrczphc3ltbWV0 cmljLWtleS1jZXJ0aWZpY2F0ZS1yZWY7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgZGVzY3JpcHRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtBIHJlZmVyZW5j ZSB0byBhIHNwZWNpZmljIGNlcnRpZmljYXRlLCBhbmQgaXRzPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXNzb2Np YXRlZCBwcml2YXRlIGtleSwgc3RvcmVkIGluIHRoZSBrZXlzdG9yZS4mcXVvdDs7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkZXNjcmlwdGlvbjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O0EgY2hvaWNlIGJldHdlZW4g YW4gaW5saW5lZCBkZWZpbml0aW9uIGFuZCBhIGRlZmluaXRpb248bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGF0IGV4aXN0cyBpbiB0aGUga2V5c3RvcmUu JnF1b3Q7OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkluIDxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+ Y3Q6YXN5bW1ldHJpYy1rZXktcGFpci1ncm91cGluZzwvc3Bhbj4sIDIgYWN0aW9ucyBhcmUgZGVm aW5lZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIDxzcGFuIHN0eWxl PSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGlnaGxpZ2h0OnllbGxvdyI+Y3Q6ZW5kLWVudGl0eS1j ZXJ0LWdyb3VwaW5nPC9zcGFuPiwgMSBub3RpZmljYXRpb24gaXMgZGVmaW5lZC48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QnV0IHcuci50LiBSRkM3OTUwIHJlZmVyZW5jZXMgYmVsb3csIGxvb2tz IGxpa2UgaXQgaXMgbm90IG9rYXkgdG8gaGF2ZSBlaXRoZXIgYWN0aW9ucyBvciBub3RpZmljYXRp b25zIGluIOKAnGNhc2XigJ0gc3RhdGVtZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwcmU+PHNwYW4g Y2xhc3M9Ik1zb0h5cGVybGluayI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX3JmYzc5NTAtMjNz ZWN0aW9uLTJENy4xNSZhbXA7ZD1Ed01GQWcmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJY ZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFH VHZqSVNsYUpkY1pvJmFtcDttPTVNZFNkbGlQOUozaGd2R2hrR0NjdDJYY0twWjAyLUV2Qmg3LTFY Z3VCcGMmYW1wO3M9VU52ZlpGanBtRmFJN2VzZ2pIeHJvY0JadHRnalE1dnlmbjJFX1RrcnhGbyZh bXA7ZT0iPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3OTUwI3NlY3Rpb24tNy4xNTwv YT48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNpbmNlIGFuIGFjdGlvbiBjYW5ub3QgYmUgZGVmaW5lZCBhdCB0 aGUgdG9wIGxldmVsIG9mIGEgbW9kdWxlIG9yIGluPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGEgJnF1b3Q7Y2FzZSZxdW90 OyBzdGF0ZW1lbnQsIGl0IGlzIGFuIGVycm9yIGlmIGEgZ3JvdXBpbmcgdGhhdCBjb250YWlucyBh bjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBhY3Rpb24gYXQgdGhlIHRvcCBvZiBpdHMgbm9kZSBoaWVyYXJjaHkgaXMgdXNl ZCBhdCB0aGUgdG9wIGxldmVsIG9mIGE8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbW9kdWxlIG9yIGluIGEgY2FzZSBkZWZp bml0aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw cmU+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX3JmYzc5NTAtMjNzZWN0aW9uLTJENy4xNiZhbXA7 ZD1Ed01GQWcmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9D SSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDtt PTVNZFNkbGlQOUozaGd2R2hrR0NjdDJYY0twWjAyLUV2Qmg3LTFYZ3VCcGMmYW1wO3M9clFOQnFM UGV0X3ZFYjNGWWcwRTAxQmhueGROUTB1MjFiNGZyTVo2V29kTSZhbXA7ZT0iPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM3OTUwI3NlY3Rpb24tNy4xNjwvYT48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2luY2Ug YSBub3RpZmljYXRpb24gY2Fubm90IGJlIGRlZmluZWQgaW4gYSAmcXVvdDtjYXNlJnF1b3Q7IHN0 YXRlbWVudCwgaXQgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFuIGVycm9yIGlmIGEgZ3JvdXBpbmcgdGhhdCBjb250YWlucyBh IG5vdGlmaWNhdGlvbiBhdCB0aGUgdG9wIG9mIGl0czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbm9kZSBoaWVyYXJjaHkgaXMgdXNl ZCBpbiBhIGNhc2UgZGVmaW5pdGlvbi48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Q2Fu IHlvdSBwbGVhc2UgY2hlY2sgYW5kIHByb3ZpZGUgeW91ciBmZWVkYmFjaz8gT3IgQW0gSSBtaXNz aW5nIHNvbWV0aGluZyBoZXJlPzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5UaGFua3MgJmFtcDsgUmVn YXJkcyw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OndpbmRvd3RleHQiPlJhbWt1bWFyPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_96290FC7159F42D4BD6B9159EEA8A447junipernet_-- From nobody Mon Dec 10 02:13:59 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF33130F12 for ; Mon, 10 Dec 2018 02:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3srVGps8j4q for ; Mon, 10 Dec 2018 02:13:55 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9237A130F00 for ; Mon, 10 Dec 2018 02:13:53 -0800 (PST) Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id C1A141AE034F; Mon, 10 Dec 2018 11:13:50 +0100 (CET) Date: Mon, 10 Dec 2018 11:13:50 +0100 (CET) Message-Id: <20181210.111350.1275704126944823868.mbj@tail-f.com> To: kwatsen@juniper.net Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <96290FC7-159F-42D4-BD6B-9159EEA8A447@juniper.net> References: <96290FC7-159F-42D4-BD6B-9159EEA8A447@juniper.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] FW: Comments on draft-ietf-netconf-keystore-07 X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Dec 2018 10:13:58 -0000 S2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPiBZQU5HIGV4cGVydHMs DQo+IA0KPiBXaHkgYXJlIGFjdGlvbi9ub3RpZmljYXRpb24gc3RhdGVtZW50cyBub3QgYWxsb3dl ZCB1bmRlciBhIGNhc2UNCj4gc3RhdGVtZW50PyAgWWVzLCBpdOKAmXMgc2ltcGxlIHRvIGFzc2Vy dCwgYnV0IHdhcyBpdCBjb25zaWRlcmVkLCBpbiBzdWNoDQo+IGNhc2VzLCB0byBpbnN0ZWFkIGFs bG93IHRoZW0gdG8gYXR0YWNoL2JpbmQgdG8gdGhlIGNsb3Nlc3QgbGVnYWwNCj4gYW5jZXN0b3I/ ICBXb3VsZCBpdCBtYWtlIHNlbnNlPw0KDQpUaGVyZSBhcmUgc29tZSBjb3JuZXIgY2FzZXMgdGhh dCBkb24ndCBtYWtlIHNlbnNlLCBlLmcuOg0KDQogIGNob2ljZSBhIHsNCiAgICBjYXNlIGIgew0K ICAgICAgYWN0aW9uIGZvbzsNCiAgICB9DQogICAgLi4uDQogIH0NCg0KU28gd2Ugd291bGQgaGF2 ZSB0byBzYXkgdGhhdCB0aGUgY2FzZSBtdXN0IGhhdmUgYXQgbGVhc3Qgc29tZSBvdGhlcg0Kbm9k ZSBhcyB3ZWxsLCBlLmcuOg0KDQogIGNob2ljZSBhIHsNCiAgICBjYXNlIGIgew0KICAgICAgbGVh ZiBiYXIgew0KICAgICAgICB0eXBlIHN0cmluZzsNCiAgICAgIH0NCiAgICAgIGFjdGlvbiBmb287 DQogICAgfQ0KICAgIC4uLg0KICB9DQoNCkJ1dCB0aGUgc2VtYW50aWNzIGFyZSBub3QgcXVpdGUg Y2xlYXIsIGltby4NCg0KPiBOaXQ6IEl0IHdvdWxk4oCZdmUgYmVlbiBoZWxwZnVsIGlmIHRoZSDi gJxTaW5jZSBh4oCdIHBhcmFncmFwaHMgcXVvdGVkIGJlbG93DQo+IHJlZmVyZW5jZWQgc2VjdGlv bnMgNy4xLjEgKFRoZSBtb2R1bGUncyBTdWJzdGF0ZW1lbnRzKSBhbmQgNy45LjIuMQ0KPiAoVGhl IGNhc2UncyBTdWJzdGF0ZW1lbnRzKS4uLg0KPiANCj4gUFM6IE5laXRoZXIgYHB5YW5nYCBub3Ig YHlhbmdsaW50YCBjYXRjaCB0aGlzIG1pc3VzZS4NCg0KVGhhbmtzLCBub3cgZml4ZWQgaW4gcHlh bmcuDQoNCg0KL21hcnRpbg0KDQoNCj4gDQo+IEtlbnQgLy8gY29udHJpYnV0b3INCj4gDQo+IA0K PiBPbiAxMi82LzE4LCA1OjM5IEFNLCAiRGhhbmFwYWwsIFJhbWt1bWFyIChOb2tpYSAtIElOL0No ZW5uYWkpIg0KPiA8cmFta3VtYXIuZGhhbmFwYWxAbm9raWEuY29tPG1haWx0bzpyYW1rdW1hci5k aGFuYXBhbEBub2tpYS5jb20+Pg0KPiB3cm90ZToNCj4gDQo+IEhpIEtlbnQsDQo+IFdlIHNlZSB0 aGUgZm9sbG93aW5nIGRlZmluaXRpb24gaW4gZHJhZnQtaWV0Zi1uZXRjb25mLWtleXN0b3JlLTA3 Lg0KPiANCj4gZ3JvdXBpbmcgbG9jYWwtb3Ita2V5c3RvcmUtZW5kLWVudGl0eS1jZXJ0LXdpdGgt a2V5LWdyb3VwaW5nIHsNCj4gICAgICAgIGRlc2NyaXB0aW9uDQo+ICAgICAgICAgICJBIGdyb3Vw aW5nIHRoYXQgZXhwYW5kcyB0byBhbGxvdyBhbiBlbmQtZW50aXR5IGNlcnRpZmljYXRlDQo+ICAg ICAgICAgICAoYW5kIGl0cyBhc3NvY2lhdGVkIHByaXZhdGUga2V5KSB0byBiZSBlaXRoZXIgc3Rv cmVkIGxvY2FsbHksDQo+ICAgICAgICAgIHdpdGhpbiB0aGUgdXNpbmcgZGF0YSBtb2RlbCwgb3Ig YmUgYSByZWZlcmVuY2UgdG8gYSBzcGVjaWZpYw0KPiAgICAgICAgICAgY2VydGlmaWNhdGUgaW4g dGhlIGtleXN0b3JlLiI7DQo+ICAgICAgICBjaG9pY2UgbG9jYWwtb3Ita2V5c3RvcmUgew0KPiAg ICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsNCj4gICAgICAgICAgY2FzZSBsb2NhbCB7DQo+ICAgICAg ICAgICAgaWYtZmVhdHVyZSAibG9jYWwta2V5cy1zdXBwb3J0ZWQiOw0KPiAgICAgICAgICAgIHVz ZXMgY3Q6YXN5bW1ldHJpYy1rZXktcGFpci1ncm91cGluZzsNCj4gICAgICAgICAgICB1c2VzIGN0 OmVuZC1lbnRpdHktY2VydC1ncm91cGluZzsNCj4gICAgICAgICAgfQ0KPiAgICAgICAgICBjYXNl IGtleXN0b3JlIHsNCj4gICAgICAgICAgICBpZi1mZWF0dXJlICJrZXlzdG9yZS1zdXBwb3J0ZWQi Ow0KPiAgICAgICAgICAgIGxlYWYgcmVmZXJlbmNlIHsNCj4gICAgICAgICAgICAgIHR5cGUga3M6 YXN5bW1ldHJpYy1rZXktY2VydGlmaWNhdGUtcmVmOw0KPiAgICAgICAgICAgICAgZGVzY3JpcHRp b24NCj4gICAgICAgICAgICAgICAgIkEgcmVmZXJlbmNlIHRvIGEgc3BlY2lmaWMgY2VydGlmaWNh dGUsIGFuZCBpdHMNCj4gICAgICAgICAgICAgICAgIGFzc29jaWF0ZWQgcHJpdmF0ZSBrZXksIHN0 b3JlZCBpbiB0aGUga2V5c3RvcmUuIjsNCj4gICAgICAgICAgICB9DQo+ICAgICAgICAgIH0NCj4g ICAgICAgICAgZGVzY3JpcHRpb24NCj4gICAgICAgICAgICAiQSBjaG9pY2UgYmV0d2VlbiBhbiBp bmxpbmVkIGRlZmluaXRpb24gYW5kIGEgZGVmaW5pdGlvbg0KPiAgICAgICAgICAgICB0aGF0IGV4 aXN0cyBpbiB0aGUga2V5c3RvcmUuIjsNCj4gICAgICAgIH0NCj4gICAgICB9DQo+IA0KPiBJbiBj dDphc3ltbWV0cmljLWtleS1wYWlyLWdyb3VwaW5nLCAyIGFjdGlvbnMgYXJlIGRlZmluZWQuDQo+ IEluIGN0OmVuZC1lbnRpdHktY2VydC1ncm91cGluZywgMSBub3RpZmljYXRpb24gaXMgZGVmaW5l ZC4NCj4gDQo+IEJ1dCB3LnIudC4gUkZDNzk1MCByZWZlcmVuY2VzIGJlbG93LCBsb29rcyBsaWtl IGl0IGlzIG5vdCBva2F5IHRvIGhhdmUNCj4gZWl0aGVyIGFjdGlvbnMgb3Igbm90aWZpY2F0aW9u cyBpbiDigJxjYXNl4oCdIHN0YXRlbWVudHMuDQo+IA0KPiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNzk1MCNzZWN0aW9uLTcuMTU8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX3JmYzc5NTAtMjNzZWN0 aW9uLTJENy4xNSZkPUR3TUZBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9E VFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09 NU1kU2RsaVA5SjNoZ3ZHaGtHQ2N0MlhjS3BaMDItRXZCaDctMVhndUJwYyZzPVVOdmZaRmpwbUZh STdlc2dqSHhyb2NCWnR0Z2pRNXZ5Zm4yRV9Ua3J4Rm8mZT0+DQo+IA0KPiAgICAgICAgIFNpbmNl IGFuIGFjdGlvbiBjYW5ub3QgYmUgZGVmaW5lZCBhdCB0aGUgdG9wIGxldmVsIG9mIGEgbW9kdWxl IG9yIGluDQo+IA0KPiAgICAgICAgIGEgImNhc2UiIHN0YXRlbWVudCwgaXQgaXMgYW4gZXJyb3Ig aWYgYSBncm91cGluZyB0aGF0IGNvbnRhaW5zIGFuDQo+IA0KPiAgICAgICAgIGFjdGlvbiBhdCB0 aGUgdG9wIG9mIGl0cyBub2RlIGhpZXJhcmNoeSBpcyB1c2VkIGF0IHRoZSB0b3AgbGV2ZWwgb2Yg YQ0KPiANCj4gICAgICAgICBtb2R1bGUgb3IgaW4gYSBjYXNlIGRlZmluaXRpb24NCj4gDQo+IA0K PiANCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc5NTAjc2VjdGlvbi03LjE2PGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMu aWV0Zi5vcmdfaHRtbF9yZmM3OTUwLTIzc2VjdGlvbi0yRDcuMTYmZD1Ed01GQWcmYz1IQWtZdWg2 M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9P SDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPTVNZFNkbGlQOUozaGd2R2hrR0NjdDJYY0twWjAy LUV2Qmg3LTFYZ3VCcGMmcz1yUU5CcUxQZXRfdkViM0ZZZzBFMDFCaG54ZE5RMHUyMWI0ZnJNWjZX b2RNJmU9Pg0KPiANCj4gICAgICAgICBTaW5jZSBhIG5vdGlmaWNhdGlvbiBjYW5ub3QgYmUgZGVm aW5lZCBpbiBhICJjYXNlIiBzdGF0ZW1lbnQsIGl0IGlzDQo+IA0KPiAgICAgICAgIGFuIGVycm9y IGlmIGEgZ3JvdXBpbmcgdGhhdCBjb250YWlucyBhIG5vdGlmaWNhdGlvbiBhdCB0aGUgdG9wIG9m IGl0cw0KPiANCj4gICAgICAgICBub2RlIGhpZXJhcmNoeSBpcyB1c2VkIGluIGEgY2FzZSBkZWZp bml0aW9uLg0KPiANCj4gDQo+IA0KPiBDYW4geW91IHBsZWFzZSBjaGVjayBhbmQgcHJvdmlkZSB5 b3VyIGZlZWRiYWNrPyBPciBBbSBJIG1pc3NpbmcNCj4gc29tZXRoaW5nIGhlcmU/DQo+IA0KPiAN Cj4gDQo+IFRoYW5rcyAmIFJlZ2FyZHMsDQo+IA0KPiBSYW1rdW1hcg0KPiANCg== From nobody Mon Dec 10 05:46:40 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E52130EA5 for ; Mon, 10 Dec 2018 05:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFC6s_iOnCpf for ; Mon, 10 Dec 2018 05:46:36 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 36B1B130E3C for ; Mon, 10 Dec 2018 05:46:35 -0800 (PST) Received: by trail.lhotka.name (Postfix, from userid 109) id 6D340182015F; Mon, 10 Dec 2018 14:46:26 +0100 (CET) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 0158F1820053; Mon, 10 Dec 2018 14:46:22 +0100 (CET) From: Ladislav Lhotka To: Juergen Schoenwaelder , Mikael Abrahamsson Cc: netmod@ietf.org In-Reply-To: <20181207091144.22bhdvp6q26wregm@anna.jacobs.jacobs-university.de> References: <5ea8671bd7642bb39732dd60d3077c5642f435a5.camel@nic.cz> <20181207091144.22bhdvp6q26wregm@anna.jacobs.jacobs-university.de> Mail-Followup-To: Juergen Schoenwaelder , Mikael Abrahamsson , netmod@ietf.org Date: Mon, 10 Dec 2018 14:46:29 +0100 Message-ID: <87wooh1olm.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [netmod] question regarding IPv6 address format / canonical X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 10 Dec 2018 13:46:39 -0000 Juergen Schoenwaelder writes: > On Fri, Dec 07, 2018 at 09:51:53AM +0100, Mikael Abrahamsson wrote: >> > >> > It is the value that the server (conceptually) uses internally. See sec. 9.1 in >> > RFC 7950. >> >> Ok, so if the server doesn't re-format and always uses string in the >> canonical format, that's a clear bug? >> > > Yes. How the server does things internally does not matter but > comparisons must conceptually use the canonical format (and this is > why it is so important to define the canonical representation in type > definitions). When we are at it: defining the canonical format for a derived type so that it differs from the base type (as it is here) is problematic because it is specified only in a description and tools thus cannot take it into account automatically. So I expect problems like the one reported by Mikael to be quite common - and if not for the IPv6 address, then certainly for other derived types. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Tue Dec 11 06:17:15 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3EC127333 for ; Tue, 11 Dec 2018 06:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l61GfLo90QXu for ; Tue, 11 Dec 2018 06:17:09 -0800 (PST) Received: from mail3.belden.com (mail3.belden.com [12.168.192.246]) (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 985BA126F72 for ; Tue, 11 Dec 2018 06:17:09 -0800 (PST) Received: from pps.filterd (dcric1ppa03pa.mcp.local [127.0.0.1]) by dcric1ppa03pa.mcp.local (8.16.0.22/8.16.0.22) with SMTP id wBBEF4oU022980 for ; Tue, 11 Dec 2018 09:17:08 -0500 Received: from dcric1exc03pa.mcp.local (dcric1exc03pa.mcp.local [10.10.181.23]) by dcric1ppa03pa.mcp.local with ESMTP id 2pa3sbtqsa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL) for ; Tue, 11 Dec 2018 09:17:08 -0500 Received: from DCRIC1EXC03PA.mcp.local (10.10.181.23) by DCRIC1EXC03PA.mcp.local (10.10.181.23) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 11 Dec 2018 09:17:07 -0500 Received: from DCRIC1EXC03PA.mcp.local ([172.16.254.23]) by DCRIC1EXC03PA.mcp.local ([172.16.254.23]) with mapi id 15.00.1367.000; Tue, 11 Dec 2018 09:17:07 -0500 From: "Seehofer, Markus" To: "netmod@ietf.org" Thread-Topic: Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf) Thread-Index: AdSRW5qHNYi/eHfrTieT+mUbUnzcbQ== Date: Tue, 11 Dec 2018 14:17:07 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [46.5.19.128] x-c2processedorg: 157cf0a0-3349-4636-89a5-bb6917ccdf3c Content-Type: multipart/alternative; boundary="_000_dee9854618dc46088972a34926c104c1DCRIC1EXC03PAmcplocal_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-11_04:, , signatures=0 Archived-At: Subject: [netmod] Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2018 14:17:13 -0000 --_000_dee9854618dc46088972a34926c104c1DCRIC1EXC03PAmcplocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Reading RFC 8342 along with draft-ietf-netconf-nmda-restconf-05 I've some q= uestions or comprehension problems with the text. 1. RFC 8342 (NMDA) Chapter 5.3. The Operational State Datastore () says: "The operational state datastore () is a read-only datastore .= .. " Chapter 6.2. Invocation of Actions and RPCs says: "Actions are always invoked in the context of the operational state datasto= re. The node for which the action is invoked MUST exist in the operational = state datastore." Chapter 3.1 in https://tools.ietf.org/pdf/draft-ietf-netconf-nmda-restconf-= 05 says: "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operati= onal." Question: How can one invoke an action in a as read-only defined datastore?= Or am I missing something? 2. The NMDA is a huge step forward for NC and RC, thanks for that. NM= DA in combination with the new RESTCONF extensions let one now select one o= f the named datastores in RFC 8342. Reading the RFC and draft I'm still missing (or even more over= look I guess) the following. RFC 8040 Chapter 4.5 says: "A PUT on the datastore resource is used to replace the entire contents of = the datastore...". So does this mean one can have the same behavior as in N= ETCONF where you can copy the "running" config to "startup" or "candidate" config to "running" if a R= ESTCONF server would support them? Is there any example how this would look= like if it is allowed? 3. Typo in https://tools.ietf.org/pdf/draft-ietf-netconf-nmda-restcon= f-05 Chapter 3.1 "the server would implement the resource {+restconf}/ds/ex= ample- ds-ephemeral:ds-ephemeral." There is a space in between "example-" and "ds-ephemeral:ds-ephemeral". Best Regards, Markus Seehofer ---------------------------------------------------------------------------= --------- Dipl.-Ing. (FH) Markus Seehofer - markus.seehofer@belden.com ********************************************************************** DISCLAIMER: Privileged and/or Confidential information may be contained in this message= . If you are not the addressee of this message, you may not copy, use or de= liver this message to anyone. In such event, you should destroy the message= and kindly notify the sender by reply e-mail. It is understood that opinio= ns or conclusions that do not relate to the official business of the compan= y are neither given nor endorsed by the company. Thank You. --_000_dee9854618dc46088972a34926c104c1DCRIC1EXC03PAmcplocal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Reading RFC 8342 along with dra= ft-ietf-netconf-nmda-restconf-05 I’ve some questions or comprehension= problems with the text.

 

1. &nbs= p;     RFC 8342 (NMDA)
Chapter 5.3.  The Operational State Datastore (<operational>) sa= ys:
“The operational state datastore (<operational>) is a read-only= datastore … “
Chapter 6.2. Invocation of Actions and RPCs says:
“Actions are always invoked in the context of the operational state d= atastore. The node for which the action is invoked MUST exist in the operat= ional state datastore.“

Chapter 3.1 in https://tools.ietf.org/pdf/draft-ietf-netconf-nmda-restconf-05 says:
“YANG actions can only be invoked in {+restconf}/ds/ietf-datastor= es:operational.”


Question: How can one invoke an action in a as read-only defined datastore?= Or am I missing something?

 =

2. &nbs= p;     The NMDA is a huge step= forward for NC and RC, thanks for that. NMDA in combination with the new R= ESTCONF extensions let one now select one of the named datastores
in RFC 8342. Reading the RFC and draft I’m still missing (or even mor= e overlook I guess) the following. RFC 8040 Chapter 4.5 says:
“A PUT on the datastore resource is used to replace the entire conten= ts of the datastore…”. So does this mean one can have the same = behavior as in NETCONF where you can copy
the “running” config to “startup” or “candida= te” config to “running” if a RESTCONF server would suppor= t them? Is there any example how this would look like if it is allowed?

 

3. &nbs= p;     Typo in https://tools.ietf.org/pdf/draft-ietf-netconf-nmda-restconf-05 Chapter = 3.1 “the server would implement the resource {+restconf}/ds/examp= le- ds-ephemeral:ds-ephemeral.”
There is a space in between “example-“ and “ds-ephemeral:= ds-ephemeral”.

 =

Best Regards,=

Markus Seehofer

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

Dipl.-Ing. (FH) Markus S= eehofer - markus.seehofer@belden.com

 

DISCLAIMER:
Privileged and/or Confidential information may be contained in this message= . If you are not the addressee of this message, you may not copy, use or de= liver this message to anyone. In such event, you should destroy the message= and kindly notify the sender by reply e-mail. It is understood that opinio= ns or conclusions that do not relate to the official business of the compan= y are neither given nor endorsed by the company. Thank You.
--_000_dee9854618dc46088972a34926c104c1DCRIC1EXC03PAmcplocal_-- From nobody Tue Dec 11 06:33:22 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED60126C7E for ; Tue, 11 Dec 2018 06:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3On8fGb5sShp for ; Tue, 11 Dec 2018 06:33:18 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C435124BF6 for ; Tue, 11 Dec 2018 06:33:17 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 0B4C0EDD; Tue, 11 Dec 2018 15:33:16 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id V6JviGV1OpSA; Tue, 11 Dec 2018 15:33:15 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 11 Dec 2018 15:33:15 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DFA1120044; Tue, 11 Dec 2018 15:33:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UJzaHIkNnnYa; Tue, 11 Dec 2018 15:33:15 +0100 (CET) Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 67A1020043; Tue, 11 Dec 2018 15:33:15 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Tue, 11 Dec 2018 15:33:14 +0100 Received: by anna.localdomain (Postfix, from userid 501) id 9EBA93004E544D; Tue, 11 Dec 2018 15:33:14 +0100 (CET) Date: Tue, 11 Dec 2018 15:33:13 +0100 From: Juergen Schoenwaelder To: "Seehofer, Markus" CC: "netmod@ietf.org" Message-ID: <20181211143313.xouvshwdtakmkdz4@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Seehofer, Markus" , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2018 14:33:21 -0000 On Tue, Dec 11, 2018 at 02:17:07PM +0000, Seehofer, Markus wrote: > Hello, > > Reading RFC 8342 along with draft-ietf-netconf-nmda-restconf-05 I've some questions or comprehension problems with the text. > > > 1. RFC 8342 (NMDA) > Chapter 5.3. The Operational State Datastore () says: > "The operational state datastore () is a read-only datastore .... " > Chapter 6.2. Invocation of Actions and RPCs says: > "Actions are always invoked in the context of the operational state datastore. The node for which the action is invoked MUST exist in the operational state datastore." > > Chapter 3.1 in https://tools.ietf.org/pdf/draft-ietf-netconf-nmda-restconf-05 says: > "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational." > > Question: How can one invoke an action in a as read-only defined datastore? Or am I missing something? Why do you expect that a datastore has to be writable in order to invoke an action? RFC 7950 has the example of a ping action tied to an interface. (You ping a remote system from that specific interface.) In general, actions are understood as being tied to real resources and hence to the operational datastore. (For example, you can't ping from an interface that is configured but not physically present.) > 2. The NMDA is a huge step forward for NC and RC, thanks for that. NMDA in combination with the new RESTCONF extensions let one now select one of the named datastores > in RFC 8342. Reading the RFC and draft I'm still missing (or even more overlook I guess) the following. RFC 8040 Chapter 4.5 says: > "A PUT on the datastore resource is used to replace the entire contents of the datastore...". So does this mean one can have the same behavior as in NETCONF where you can copy > the "running" config to "startup" or "candidate" config to "running" if a RESTCONF server would support them? Is there any example how this would look like if it is allowed? A PUT does not really get you there, to copy a datastore to another you want an operation on the server. > 3. Typo in https://tools.ietf.org/pdf/draft-ietf-netconf-nmda-restconf-05 Chapter 3.1 "the server would implement the resource {+restconf}/ds/example- ds-ephemeral:ds-ephemeral." > There is a space in between "example-" and "ds-ephemeral:ds-ephemeral". Lets hope we get this fixed with the help of the RFC editor. /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 Dec 11 06:55:22 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BEF130DD1 for ; Tue, 11 Dec 2018 06:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0XaOsvZGdF0 for ; Tue, 11 Dec 2018 06:55:13 -0800 (PST) Received: from mail1.belden.com (mail1.belden.com [12.168.192.252]) (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 61B94126F72 for ; Tue, 11 Dec 2018 06:55:13 -0800 (PST) Received: from pps.filterd (dcric1ppa01pa.mcp.local [127.0.0.1]) by dcric1ppa01pa.mcp.local (8.16.0.22/8.16.0.22) with SMTP id wBBEn70p004981; Tue, 11 Dec 2018 09:55:10 -0500 Received: from dcric1exc05pa.mcp.local (dcric1exc05pa.mcp.local [10.10.181.25]) by dcric1ppa01pa.mcp.local with ESMTP id 2pae8wre2w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 11 Dec 2018 09:55:10 -0500 Received: from DCRIC1EXC03PA.mcp.local (10.10.181.23) by DCRIC1EXC05PA.mcp.local (10.10.181.25) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 11 Dec 2018 09:55:10 -0500 Received: from DCRIC1EXC03PA.mcp.local ([172.16.254.23]) by DCRIC1EXC03PA.mcp.local ([172.16.254.23]) with mapi id 15.00.1367.000; Tue, 11 Dec 2018 09:55:10 -0500 From: "Seehofer, Markus" To: Juergen Schoenwaelder CC: "netmod@ietf.org" Thread-Topic: [EXTERNAL] Re: [netmod] Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf) Thread-Index: AdSRW5qHNYi/eHfrTieT+mUbUnzcbQALMCKAAAo1hoA= Date: Tue, 11 Dec 2018 14:55:10 +0000 Message-ID: <9d40f9ad4b494e67ba2808341dc82e4d@DCRIC1EXC03PA.mcp.local> References: <20181211143313.xouvshwdtakmkdz4@anna.jacobs.jacobs-university.de> In-Reply-To: <20181211143313.xouvshwdtakmkdz4@anna.jacobs.jacobs-university.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [46.5.19.128] x-c2processedorg: 157cf0a0-3349-4636-89a5-bb6917ccdf3c Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-11_04:, , signatures=0 Archived-At: Subject: Re: [netmod] [EXTERNAL] Re: Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2018 14:55:20 -0000 SGVsbG8gSnVlcmdlbiwNCg0Kc2VlIG15IGNvbW1lbnRzIGlubGluZSBiZWxvdy4gQXMgYmVpbmcg cXVpdGUgbmV3IHRvIHRoZSB0b3BpYywgZ29pbmcgdGhyb3VnaCBhbGwgdGhlIG9sZCBhbmQgY3Vy cmVudCBSRkNzIGFuZCBkcmFmdHMgaXMgcXVpdGUgY2hhbGxlbmdpbmcuDQpTbyBwbGVhc2UgYXBv bG9naXplIGZvciAic2ltcGxlIiBxdWVzdGlvbnMgb3Igb25lcyBtYXliZSBhbHJlYWR5IHJhaXNl ZC4NCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBKdWVyZ2VuIFNj aG9lbndhZWxkZXIgW21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGVd DQpHZXNlbmRldDogRGllbnN0YWcsIDExLiBEZXplbWJlciAyMDE4IDE1OjMzDQpBbjogU2VlaG9m ZXIsIE1hcmt1cw0KQ2M6IG5ldG1vZEBpZXRmLm9yZw0KQmV0cmVmZjogW0VYVEVSTkFMXSBSZTog W25ldG1vZF0gUXVlc3Rpb24gb24gUkZDODM0MiArIFJFU1RDT05GIGV4dGVuc2lvbiAoZHJhZnQt aWV0Zi1uZXRjb25mLW5tZGEtcmVzdGNvbmYpDQoNCg0KDQpPbiBUdWUsIERlYyAxMSwgMjAxOCBh dCAwMjoxNzowN1BNICswMDAwLCBTZWVob2ZlciwgTWFya3VzIHdyb3RlOg0KPiBIZWxsbywNCj4N Cj4gUmVhZGluZyBSRkMgODM0MiBhbG9uZyB3aXRoIGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJl c3Rjb25mLTA1IEkndmUgc29tZSBxdWVzdGlvbnMgb3IgY29tcHJlaGVuc2lvbiBwcm9ibGVtcyB3 aXRoIHRoZSB0ZXh0Lg0KPg0KPg0KPiAxLiAgICAgICBSRkMgODM0MiAoTk1EQSkNCj4gQ2hhcHRl ciA1LjMuICBUaGUgT3BlcmF0aW9uYWwgU3RhdGUgRGF0YXN0b3JlICg8b3BlcmF0aW9uYWw+KSBz YXlzOg0KPiAiVGhlIG9wZXJhdGlvbmFsIHN0YXRlIGRhdGFzdG9yZSAoPG9wZXJhdGlvbmFsPikg aXMgYSByZWFkLW9ubHkgZGF0YXN0b3JlIC4uLi4gIg0KPiBDaGFwdGVyIDYuMi4gSW52b2NhdGlv biBvZiBBY3Rpb25zIGFuZCBSUENzIHNheXM6DQo+ICJBY3Rpb25zIGFyZSBhbHdheXMgaW52b2tl ZCBpbiB0aGUgY29udGV4dCBvZiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlLiBUaGUg bm9kZSBmb3Igd2hpY2ggdGhlIGFjdGlvbiBpcyBpbnZva2VkIE1VU1QgZXhpc3QgaW4gdGhlIG9w ZXJhdGlvbmFsIHN0YXRlIGRhdGFzdG9yZS4iDQo+DQo+IENoYXB0ZXIgMy4xIGluIGh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5v cmdfcGRmX2RyYWZ0LTJEaWV0Zi0yRG5ldGNvbmYtMkRubWRhLTJEcmVzdGNvbmYtMkQwNSZkPUR3 SUJBZyZjPUJnNVhVTERaUjhHaU9TU1dObHBrQ3NSZVBuR0RrS2NJNm9ZTDl4djFNblEmcj0yWEVL VllrUWptTEhpMlRPSnAxVlN6aWVMWlZxZXdJcGotUnhtUmdQZnNNJm09Q0RLMjhYOGtPMndSVkRs YTk3UF9XcUJJaEYzT0F6YldTR0VtVGVMZHh3VSZzPUJTeVktR0J1enpEcnk2b0loZy1tZ3dNQXlT YmhKRU85SW0zWjRQRF9jXzQmZT0gc2F5czoNCj4gIllBTkcgYWN0aW9ucyBjYW4gb25seSBiZSBp bnZva2VkIGluIHsrcmVzdGNvbmZ9L2RzL2lldGYtZGF0YXN0b3JlczpvcGVyYXRpb25hbC4iDQo+ DQo+IFF1ZXN0aW9uOiBIb3cgY2FuIG9uZSBpbnZva2UgYW4gYWN0aW9uIGluIGEgYXMgcmVhZC1v bmx5IGRlZmluZWQgZGF0YXN0b3JlPyBPciBhbSBJIG1pc3Npbmcgc29tZXRoaW5nPw0KDQpXaHkg ZG8geW91IGV4cGVjdCB0aGF0IGEgZGF0YXN0b3JlIGhhcyB0byBiZSB3cml0YWJsZSBpbiBvcmRl ciB0byBpbnZva2UgYW4gYWN0aW9uPyBSRkMgNzk1MCBoYXMgdGhlIGV4YW1wbGUgb2YgYSBwaW5n IGFjdGlvbiB0aWVkIHRvIGFuIGludGVyZmFjZS4gKFlvdSBwaW5nIGEgcmVtb3RlIHN5c3RlbSBm cm9tIHRoYXQgc3BlY2lmaWMgaW50ZXJmYWNlLikgSW4gZ2VuZXJhbCwgYWN0aW9ucyBhcmUgdW5k ZXJzdG9vZCBhcyBiZWluZyB0aWVkIHRvIHJlYWwgcmVzb3VyY2VzIGFuZCBoZW5jZSB0byB0aGUg b3BlcmF0aW9uYWwgZGF0YXN0b3JlLiAoRm9yIGV4YW1wbGUsIHlvdSBjYW4ndCBwaW5nIGZyb20g YW4gaW50ZXJmYWNlIHRoYXQgaXMgY29uZmlndXJlZCBidXQgbm90IHBoeXNpY2FsbHkgcHJlc2Vu dC4pDQoNCltNU0VFXTogSSBkbyBub3QgZXhwZWN0IHRoYXQgYSBkYXRhc3RvcmUgaGFzIHRvIGJl IHdyaXRlYWJsZSB0byBpbnZva2UgYW4gYWN0aW9uLCBidXQgSSBkbyBleHBlY3QgdGhhdCBhICJy ZWFkLW9ubHkiIGRhdGFzdG9yZSBpcyBub3Qgd3JpdGVhYmxlIGFuZCBSRkMgODM0MiBzYXlzIGNs ZWFybHkgb3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlIGlzICJyZWFkLW9ubHkiLg0KDQo+IDIu ICAgICAgIFRoZSBOTURBIGlzIGEgaHVnZSBzdGVwIGZvcndhcmQgZm9yIE5DIGFuZCBSQywgdGhh bmtzIGZvciB0aGF0LiBOTURBIGluIGNvbWJpbmF0aW9uIHdpdGggdGhlIG5ldyBSRVNUQ09ORiBl eHRlbnNpb25zIGxldCBvbmUgbm93IHNlbGVjdCBvbmUgb2YgdGhlIG5hbWVkIGRhdGFzdG9yZXMN Cj4gaW4gUkZDIDgzNDIuIFJlYWRpbmcgdGhlIFJGQyBhbmQgZHJhZnQgSSdtIHN0aWxsIG1pc3Np bmcgKG9yIGV2ZW4gbW9yZSBvdmVybG9vayBJIGd1ZXNzKSB0aGUgZm9sbG93aW5nLiBSRkMgODA0 MCBDaGFwdGVyIDQuNSBzYXlzOg0KPiAiQSBQVVQgb24gdGhlIGRhdGFzdG9yZSByZXNvdXJjZSBp cyB1c2VkIHRvIHJlcGxhY2UgdGhlIGVudGlyZQ0KPiBjb250ZW50cyBvZiB0aGUgZGF0YXN0b3Jl Li4uIi4gU28gZG9lcyB0aGlzIG1lYW4gb25lIGNhbiBoYXZlIHRoZSBzYW1lIGJlaGF2aW9yIGFz IGluIE5FVENPTkYgd2hlcmUgeW91IGNhbiBjb3B5IHRoZSAicnVubmluZyIgY29uZmlnIHRvICJz dGFydHVwIiBvciAiY2FuZGlkYXRlIiBjb25maWcgdG8gInJ1bm5pbmciIGlmIGEgUkVTVENPTkYg c2VydmVyIHdvdWxkIHN1cHBvcnQgdGhlbT8gSXMgdGhlcmUgYW55IGV4YW1wbGUgaG93IHRoaXMg d291bGQgbG9vayBsaWtlIGlmIGl0IGlzIGFsbG93ZWQ/DQoNCkEgUFVUIGRvZXMgbm90IHJlYWxs eSBnZXQgeW91IHRoZXJlLCB0byBjb3B5IGEgZGF0YXN0b3JlIHRvIGFub3RoZXIgeW91IHdhbnQg YW4gb3BlcmF0aW9uIG9uIHRoZSBzZXJ2ZXIuDQoNCltNU0VFXTogRXhhY3RseSB0aGlzIGlzIHdo YXQgSSB3YW50LiBORVRDT05GIHNwZWNpZmllcyB0aGlzIGNsZWFybHkgaW4gdGhlIFJGQ3Mgd2l0 aCA8Y29weS1jb25maWc+IGJ1dCBob3cgZG9lcyBvbmUgdHJpZ2dlciB0aGlzIHdpdGggUkVTVENP TkY/IEkgaGFkIHRoZSBob3BlIHdpdGggTk1EQSArIFJFU1RDT05GIGV4dGVuc2lvbnMgdGhpcyB3 b3VsZA0KICAgICAgICAgICAgICAgYmUgcG9zc2libGUgdG9vLiBPciBkbyBJIHN0aWxsIG1pc3Mg c29tZXRoaW5nPw0KDQo+IDMuICAgICAgIFR5cG8gaW4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19wZGZfZHJhZnQtMkRp ZXRmLTJEbmV0Y29uZi0yRG5tZGEtMkRyZXN0Y29uZi0yRDA1JmQ9RHdJQkFnJmM9Qmc1WFVMRFpS OEdpT1NTV05scGtDc1JlUG5HRGtLY0k2b1lMOXh2MU1uUSZyPTJYRUtWWWtRam1MSGkyVE9KcDFW U3ppZUxaVnFld0lwai1SeG1SZ1Bmc00mbT1DREsyOFg4a08yd1JWRGxhOTdQX1dxQkloRjNPQXpi V1NHRW1UZUxkeHdVJnM9QlN5WS1HQnV6ekRyeTZvSWhnLW1nd01BeVNiaEpFTzlJbTNaNFBEX2Nf NCZlPSBDaGFwdGVyIDMuMSAidGhlIHNlcnZlciB3b3VsZCBpbXBsZW1lbnQgdGhlIHJlc291cmNl IHsrcmVzdGNvbmZ9L2RzL2V4YW1wbGUtIGRzLWVwaGVtZXJhbDpkcy1lcGhlbWVyYWwuIg0KPiBU aGVyZSBpcyBhIHNwYWNlIGluIGJldHdlZW4gImV4YW1wbGUtIiBhbmQgImRzLWVwaGVtZXJhbDpk cy1lcGhlbWVyYWwiLg0KDQpMZXRzIGhvcGUgd2UgZ2V0IHRoaXMgZml4ZWQgd2l0aCB0aGUgaGVs cCBvZiB0aGUgUkZDIGVkaXRvci4NCg0KL2pzDQoNCi0tDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIg ICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0MjEg MjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0K RmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuamFjb2JzLTJEdW5pdmVyc2l0eS5kZV8m ZD1Ed0lCQWcmYz1CZzVYVUxEWlI4R2lPU1NXTmxwa0NzUmVQbkdEa0tjSTZvWUw5eHYxTW5RJnI9 MlhFS1ZZa1FqbUxIaTJUT0pwMVZTemllTFpWcWV3SXBqLVJ4bVJnUGZzTSZtPUNESzI4WDhrTzJ3 UlZEbGE5N1BfV3FCSWhGM09BemJXU0dFbVRlTGR4d1Umcz13MzhzZVdpNkZONDhPalBmSm45Mi0t ZW1pM3JFekVpRFRIc0tMeEVuc3JnJmU9Pg0K From nobody Tue Dec 11 08:05:41 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29FE130DDB for ; Tue, 11 Dec 2018 08:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.96 X-Spam-Level: X-Spam-Status: No, score=-15.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05ktHG__CWYM for ; Tue, 11 Dec 2018 08:05:34 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C57D712DDA3 for ; Tue, 11 Dec 2018 08:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5599; q=dns/txt; s=iport; t=1544544334; x=1545753934; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=0SLPDpj6EHxBQHCKEWAE8w13s2hvYQBSCH5vw+0m54M=; b=AMyExzCliGoafN7Dd+hZoUxEHHsp4a99VmYg6461ujD2BTJ5cUQslM3r xWr13XNKhn4rGtp3LVXVIATij5afHkJk7Kmty4Jbe6nUNPh8IryX+ieJy QfmqGWvQEWWeOB5tJujeNGNL0T7JFAGDs42yHIrP2KCx2ZwWr3NcW+h2W w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACo3w9c/xbLJq1hAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYJpcBIng3uIGV+NEQgll1KBeg0YC4Q?= =?us-ascii?q?DRgKDDjQJDQEDAQECAQECbRwMhTwBAQEBAgEBASEPAQU2Cw4CCxAIAgIfBAM?= =?us-ascii?q?CAhsMHxEGDQYCAQGDHQGBeQgPpVaBL4VAhGwFgQaLR4FAP4ERJwyCX4FBgV0?= =?us-ascii?q?BAYFLNyaCPYJXAqAmVQmHCYM8hwYGGIFcTYRKgwMmhySSSoZpgUY4gVYzGgg?= =?us-ascii?q?bFTuCbAmCKh2DOIUUhT8/AzCLaAEB?= X-IronPort-AV: E=Sophos;i="5.56,342,1539648000"; d="scan'208";a="8772404" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Dec 2018 16:05:31 +0000 Received: from [10.63.23.68] (dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com [10.63.23.68]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id wBBG5VPS010506; Tue, 11 Dec 2018 16:05:31 GMT To: "Seehofer, Markus" Cc: "netmod@ietf.org" References: <20181211143313.xouvshwdtakmkdz4@anna.jacobs.jacobs-university.de> <9d40f9ad4b494e67ba2808341dc82e4d@DCRIC1EXC03PA.mcp.local> From: Robert Wilton Message-ID: Date: Tue, 11 Dec 2018 16:05:30 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <9d40f9ad4b494e67ba2808341dc82e4d@DCRIC1EXC03PA.mcp.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.68, dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [netmod] [EXTERNAL] Re: Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2018 16:05:41 -0000 Hi Seehofer, Please see inline ... On 11/12/2018 14:55, Seehofer, Markus wrote: > Hello Juergen, > > see my comments inline below. As being quite new to the topic, going through all the old and current RFCs and drafts is quite challenging. > So please apologize for "simple" questions or ones maybe already raised. > > -----Ursprüngliche Nachricht----- > Von: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Gesendet: Dienstag, 11. Dezember 2018 15:33 > An: Seehofer, Markus > Cc: netmod@ietf.org > Betreff: [EXTERNAL] Re: [netmod] Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf) > > > > On Tue, Dec 11, 2018 at 02:17:07PM +0000, Seehofer, Markus wrote: >> Hello, >> >> Reading RFC 8342 along with draft-ietf-netconf-nmda-restconf-05 I've some questions or comprehension problems with the text. >> >> >> 1. RFC 8342 (NMDA) >> Chapter 5.3. The Operational State Datastore () says: >> "The operational state datastore () is a read-only datastore ...." >> Chapter 6.2. Invocation of Actions and RPCs says: >> "Actions are always invoked in the context of the operational state datastore. The node for which the action is invoked MUST exist in the operational state datastore." >> >> Chapter 3.1 in https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_pdf_draft-2Dietf-2Dnetconf-2Dnmda-2Drestconf-2D05&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=BSyY-GBuzzDry6oIhg-mgwMAySbhJEO9Im3Z4PD_c_4&e= says: >> "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational." >> >> Question: How can one invoke an action in a as read-only defined datastore? Or am I missing something? > Why do you expect that a datastore has to be writable in order to invoke an action? RFC 7950 has the example of a ping action tied to an interface. (You ping a remote system from that specific interface.) In general, actions are understood as being tied to real resources and hence to the operational datastore. (For example, you can't ping from an interface that is configured but not physically present.) > > [MSEE]: I do not expect that a datastore has to be writeable to invoke an action, but I do expect that a "read-only" datastore is not writeable and RFC 8342 says clearly operational state datastore is "read-only". RPCs and actions don't modify the operational state datastore as such, instead they modify the properties of the underlying system, and the operational state datastore provides a read-only view onto the state of the system.  So is only being updated as a side effect of reflecting the changes to the underlying system. This contrasts with writable configuration datastores (e.g. or ), where the client can modify the configuration in those datastores directly which will then attempt to change the behavior of the system as the config is applied. > >> 2. The NMDA is a huge step forward for NC and RC, thanks for that. NMDA in combination with the new RESTCONF extensions let one now select one of the named datastores >> in RFC 8342. Reading the RFC and draft I'm still missing (or even more overlook I guess) the following. RFC 8040 Chapter 4.5 says: >> "A PUT on the datastore resource is used to replace the entire >> contents of the datastore...". So does this mean one can have the same behavior as in NETCONF where you can copy the "running" config to "startup" or "candidate" config to "running" if a RESTCONF server would support them? Is there any example how this would look like if it is allowed? > A PUT does not really get you there, to copy a datastore to another you want an operation on the server. > > [MSEE]: Exactly this is what I want. NETCONF specifies this clearly in the RFCs with but how does one trigger this with RESTCONF? I had the hope with NMDA + RESTCONF extensions this would > be possible too. Or do I still miss something? I think that it is theoretically possible to invoke the NETCONF RPCs (e.g. the copy-config RPC defined in ietf-netconf.yang, RFC 6241) from RESTCONF (e.g. section 3.6 of RFC 8040). Whether this is actually a good thing to do/encourage I'm not so sure. Thanks, Rob > >> 3. Typo in https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_pdf_draft-2Dietf-2Dnetconf-2Dnmda-2Drestconf-2D05&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=BSyY-GBuzzDry6oIhg-mgwMAySbhJEO9Im3Z4PD_c_4&e= Chapter 3.1 "the server would implement the resource {+restconf}/ds/example- ds-ephemeral:ds-ephemeral." >> There is a space in between "example-" and "ds-ephemeral:ds-ephemeral". > Lets hope we get this fixed with the help of the RFC editor. > > /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 From nobody Tue Dec 11 08:14:53 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70368130E0C for ; Tue, 11 Dec 2018 08:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djqJsURIQ52Y for ; Tue, 11 Dec 2018 08:14:50 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81810124C04 for ; Tue, 11 Dec 2018 08:14:50 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 44305DC1; Tue, 11 Dec 2018 17:14:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 9mnEv8EAx0r7; Tue, 11 Dec 2018 17:14:49 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 11 Dec 2018 17:14:49 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CCC620044; Tue, 11 Dec 2018 17:14:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id HkIJxZLFM9Pe; Tue, 11 Dec 2018 17:14:48 +0100 (CET) Received: from exchange.jacobs-university.de (SXCHMB01.jacobs.jacobs-university.de [10.70.0.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 90AA520043; Tue, 11 Dec 2018 17:14:48 +0100 (CET) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Tue, 11 Dec 2018 17:14:48 +0100 Received: by anna.localdomain (Postfix, from userid 501) id C72153004E6548; Tue, 11 Dec 2018 17:14:47 +0100 (CET) Date: Tue, 11 Dec 2018 17:14:47 +0100 From: Juergen Schoenwaelder To: "Seehofer, Markus" CC: "netmod@ietf.org" Message-ID: <20181211161447.2pvfug5q6z3iqvam@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Seehofer, Markus" , "netmod@ietf.org" References: <20181211143313.xouvshwdtakmkdz4@anna.jacobs.jacobs-university.de> <9d40f9ad4b494e67ba2808341dc82e4d@DCRIC1EXC03PA.mcp.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <9d40f9ad4b494e67ba2808341dc82e4d@DCRIC1EXC03PA.mcp.local> User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) Archived-At: Subject: Re: [netmod] [EXTERNAL] Re: Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2018 16:14:52 -0000 On Tue, Dec 11, 2018 at 02:55:10PM +0000, Seehofer, Markus wrote: > Hello Juergen, > > see my comments inline below. As being quite new to the topic, going through all the old and current RFCs and drafts is quite challenging. > So please apologize for "simple" questions or ones maybe already raised. > > > 1. RFC 8342 (NMDA) > > Chapter 5.3. The Operational State Datastore () says: > > "The operational state datastore () is a read-only datastore .... " > > Chapter 6.2. Invocation of Actions and RPCs says: > > "Actions are always invoked in the context of the operational state datastore. The node for which the action is invoked MUST exist in the operational state datastore." > > > > "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational." > > > > Question: How can one invoke an action in a as read-only defined datastore? Or am I missing something? > > Why do you expect that a datastore has to be writable in order to invoke an action? RFC 7950 has the example of a ping action tied to an interface. (You ping a remote system from that specific interface.) In general, actions are understood as being tied to real resources and hence to the operational datastore. (For example, you can't ping from an interface that is configured but not physically present.) > > [MSEE]: I do not expect that a datastore has to be writeable to invoke an action, but I do expect that a "read-only" datastore is not writeable and RFC 8342 says clearly operational state datastore is "read-only". > Is your question 'how do I do actuall invoke an operation/action'? Well, RFC 8040 talks about 'operation resource' and that you POST to them. What NMDA RESTCONF I think says is that such an invocation is executed in the context of the operational state datastore. > > 2. The NMDA is a huge step forward for NC and RC, thanks for that. NMDA in combination with the new RESTCONF extensions let one now select one of the named datastores > > in RFC 8342. Reading the RFC and draft I'm still missing (or even more overlook I guess) the following. RFC 8040 Chapter 4.5 says: > > "A PUT on the datastore resource is used to replace the entire > > contents of the datastore...". So does this mean one can have the same behavior as in NETCONF where you can copy the "running" config to "startup" or "candidate" config to "running" if a RESTCONF server would support them? Is there any example how this would look like if it is allowed? > > A PUT does not really get you there, to copy a datastore to another you want an operation on the server. > > [MSEE]: Exactly this is what I want. NETCONF specifies this clearly in the RFCs with but how does one trigger this with RESTCONF? I had the hope with NMDA + RESTCONF extensions this would > be possible too. Or do I still miss something? > I think this was discussed at some point but then dropped. It may work to implement ietf-netconf (or the copy-config defined in there) to get direct access to NETCONF operations. /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 Dec 11 09:11:23 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D91130EA1 for ; Tue, 11 Dec 2018 09:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLW0YXLM8XJ8 for ; Tue, 11 Dec 2018 09:11:19 -0800 (PST) Received: from mail3.belden.com (mail3.belden.com [12.168.192.246]) (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 271BC130E9E for ; Tue, 11 Dec 2018 09:11:19 -0800 (PST) Received: from pps.filterd (dcric1ppa03pa.mcp.local [127.0.0.1]) by dcric1ppa03pa.mcp.local (8.16.0.22/8.16.0.22) with SMTP id wBBH7LIw026967; Tue, 11 Dec 2018 12:11:18 -0500 Received: from dcric1exc01pa.mcp.local (dcric1exc01pa.mcp.local [10.10.181.21]) by dcric1ppa03pa.mcp.local with ESMTP id 2pag538e2k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 11 Dec 2018 12:11:17 -0500 Received: from DCRIC1EXC03PA.mcp.local (10.10.181.23) by DCRIC1EXC01PA.mcp.local (10.10.181.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 11 Dec 2018 12:11:17 -0500 Received: from DCRIC1EXC03PA.mcp.local ([172.16.254.23]) by DCRIC1EXC03PA.mcp.local ([172.16.254.23]) with mapi id 15.00.1367.000; Tue, 11 Dec 2018 12:11:17 -0500 From: "Seehofer, Markus" To: Juergen Schoenwaelder CC: "netmod@ietf.org" Thread-Topic: [EXTERNAL] Re: [netmod] Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf) Thread-Index: AdSRW5qHNYi/eHfrTieT+mUbUnzcbQALMCKAAAo1hoD//8q0gIAAS0Xg Date: Tue, 11 Dec 2018 17:11:16 +0000 Message-ID: <5527d148dc3d4a9996a1e2298537105f@DCRIC1EXC03PA.mcp.local> References: <20181211143313.xouvshwdtakmkdz4@anna.jacobs.jacobs-university.de> <9d40f9ad4b494e67ba2808341dc82e4d@DCRIC1EXC03PA.mcp.local> <20181211161447.2pvfug5q6z3iqvam@anna.jacobs.jacobs-university.de> In-Reply-To: <20181211161447.2pvfug5q6z3iqvam@anna.jacobs.jacobs-university.de> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [46.5.19.128] x-c2processedorg: 157cf0a0-3349-4636-89a5-bb6917ccdf3c Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-11_05:, , signatures=0 Content-Type: text/plain; charset="iso-8859-1" Archived-At: Subject: Re: [netmod] Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2018 17:11:21 -0000 Hello Juergen, comments inline below. -----Urspr=FCngliche Nachricht----- Von: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Gesendet: Dienstag, 11. Dezember 2018 17:15 An: Seehofer, Markus Cc: netmod@ietf.org Betreff: Re: [EXTERNAL] Re: [netmod] Question on RFC8342 + RESTCONF extensi= on (draft-ietf-netconf-nmda-restconf) On Tue, Dec 11, 2018 at 02:55:10PM +0000, Seehofer, Markus wrote: > Hello Juergen, >=20 > see my comments inline below. As being quite new to the topic, going thro= ugh all the old and current RFCs and drafts is quite challenging. > So please apologize for "simple" questions or ones maybe already raised. >=20 > > 1. RFC 8342 (NMDA) > > Chapter 5.3. The Operational State Datastore () says: > > "The operational state datastore () is a read-only datasto= re .... " > > Chapter 6.2. Invocation of Actions and RPCs says: > > "Actions are always invoked in the context of the operational state dat= astore. The node for which the action is invoked MUST exist in the operatio= nal state datastore." > > > > "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:ope= rational." > > > > Question: How can one invoke an action in a as read-only defined datast= ore? Or am I missing something? >=20 > Why do you expect that a datastore has to be writable in order to=20 > invoke an action? RFC 7950 has the example of a ping action tied to an=20 > interface. (You ping a remote system from that specific interface.) In=20 > general, actions are understood as being tied to real resources and=20 > hence to the operational datastore. (For example, you can't ping from=20 > an interface that is configured but not physically present.) >=20 > [MSEE]: I do not expect that a datastore has to be writeable to invoke an= action, but I do expect that a "read-only" datastore is not writeable and = RFC 8342 says clearly operational state datastore is "read-only". > Is your question 'how do I do actuall invoke an operation/action'? Well, RFC 8040 talks about 'operation resource' and that you POST to them. = What NMDA RESTCONF I think says is that such an invocation is executed in t= he context of the operational state datastore. [MSEE]: No I guess I understood how to invoke an operation/action but I'm s= tuck with the following statements: - draft-ietf-netconf-nmda-restconf-05 says in Chapter 3.1: "= YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operatio= nal" with "The resource {+restconf}/ds/ietf-datastores:operational = refers to the operational state datastore" and "The operational state datas= tore () is a read-only datastore" - RFC 8040 says in Chapter 3.6 " Operation resources represe= nting YANG actions are not identified in this subtree, since they are invok= ed using a URI within the '{+restconf}/data' subtree" and "An action is invoked as: POST {+restconf}/data//" So without NMDA it was clear, invoke an action using {+restc= onf}/data}. With NMDA what is the correct way to trigger an action as the d= raft says "YANG actions can only be invoked in {+restconf}/ds/ietf-datastor= es:operational"? =20=20=20=20=20=20=20=20=20=20=20=20=20=20 > > 2. The NMDA is a huge step forward for NC and RC, thanks for that= . NMDA in combination with the new RESTCONF extensions let one now select o= ne of the named datastores > > in RFC 8342. Reading the RFC and draft I'm still missing (or even more = overlook I guess) the following. RFC 8040 Chapter 4.5 says: > > "A PUT on the datastore resource is used to replace the entire=20 > > contents of the datastore...". So does this mean one can have the same = behavior as in NETCONF where you can copy the "running" config to "startup"= or "candidate" config to "running" if a RESTCONF server would support them= ? Is there any example how this would look like if it is allowed? >=20 > A PUT does not really get you there, to copy a datastore to another you w= ant an operation on the server. >=20 > [MSEE]: Exactly this is what I want. NETCONF specifies this clearly in th= e RFCs with but how does one trigger this with RESTCONF? I ha= d the hope with NMDA + RESTCONF extensions this would > be possible too. Or do I still miss something? > I think this was discussed at some point but then dropped. It may work to i= mplement ietf-netconf (or the copy-config defined in there) to get direct a= ccess to NETCONF operations. [MSEE]: Thanks, this could work. Haven't thought about that. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 ********************************************************************** DISCLAIMER: Privileged and/or Confidential information may be contained in this message= . If you are not the addressee of this message, you may not copy, use or de= liver this message to anyone. In such event, you should destroy the message= and kindly notify the sender by reply e-mail. It is understood that opinio= ns or conclusions that do not relate to the official business of the compan= y are neither given nor endorsed by the company. Thank You. From nobody Tue Dec 11 09:21:58 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8DB130EB8 for ; Tue, 11 Dec 2018 09:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztMIbx1dqknI for ; Tue, 11 Dec 2018 09:21:54 -0800 (PST) Received: from mail1.belden.com (mail1.belden.com [12.168.192.252]) (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 1E62E130EB4 for ; Tue, 11 Dec 2018 09:21:54 -0800 (PST) Received: from pps.filterd (dcric1ppa01pa.mcp.local [127.0.0.1]) by dcric1ppa01pa.mcp.local (8.16.0.22/8.16.0.22) with SMTP id wBBHJqiW024618; Tue, 11 Dec 2018 12:21:51 -0500 Received: from dcric1exc04pa.mcp.local (dcric1exc04pa.mcp.local [10.10.181.24]) by dcric1ppa01pa.mcp.local with ESMTP id 2pae8ws6kn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Tue, 11 Dec 2018 12:21:51 -0500 Received: from DCRIC1EXC03PA.mcp.local (10.10.181.23) by DCRIC1EXC04PA.mcp.local (10.10.181.24) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 11 Dec 2018 12:21:51 -0500 Received: from DCRIC1EXC03PA.mcp.local ([172.16.254.23]) by DCRIC1EXC03PA.mcp.local ([172.16.254.23]) with mapi id 15.00.1367.000; Tue, 11 Dec 2018 12:21:51 -0500 From: "Seehofer, Markus" To: Robert Wilton CC: "netmod@ietf.org" Thread-Topic: [netmod] [EXTERNAL] Re: Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf) Thread-Index: AQHUkWt3Jd7rLHDQF0Ouuz6iJvf3s6V5xxIA Date: Tue, 11 Dec 2018 17:21:50 +0000 Message-ID: <532b30422c7a4e77972181c32eaa8ff8@DCRIC1EXC03PA.mcp.local> References: <20181211143313.xouvshwdtakmkdz4@anna.jacobs.jacobs-university.de> <9d40f9ad4b494e67ba2808341dc82e4d@DCRIC1EXC03PA.mcp.local> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [46.5.19.128] x-c2processedorg: 157cf0a0-3349-4636-89a5-bb6917ccdf3c Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-11_05:, , signatures=0 Content-Type: text/plain; charset="utf-8" Archived-At: Subject: Re: [netmod] Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 11 Dec 2018 17:21:56 -0000 SGVsbG8gUm9iZXJ0LA0KDQpjb21tZW50cyBpbmxpbmUgYmVsb3cuDQoNCkJSDQogTWFya3VzIA0K DQotLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQpWb246IFJvYmVydCBXaWx0b24g W21haWx0bzpyd2lsdG9uQGNpc2NvLmNvbV0gDQpHZXNlbmRldDogRGllbnN0YWcsIDExLiBEZXpl bWJlciAyMDE4IDE3OjA2DQpBbjogU2VlaG9mZXIsIE1hcmt1cw0KQ2M6IG5ldG1vZEBpZXRmLm9y Zw0KQmV0cmVmZjogUmU6IFtuZXRtb2RdIFtFWFRFUk5BTF0gUmU6IFF1ZXN0aW9uIG9uIFJGQzgz NDIgKyBSRVNUQ09ORiBleHRlbnNpb24gKGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJlc3Rjb25m KQ0KDQpIaSBTZWVob2ZlciwNCg0KUGxlYXNlIHNlZSBpbmxpbmUgLi4uDQoNCk9uIDExLzEyLzIw MTggMTQ6NTUsIFNlZWhvZmVyLCBNYXJrdXMgd3JvdGU6DQo+IEhlbGxvIEp1ZXJnZW4sDQo+DQo+ IHNlZSBteSBjb21tZW50cyBpbmxpbmUgYmVsb3cuIEFzIGJlaW5nIHF1aXRlIG5ldyB0byB0aGUg dG9waWMsIGdvaW5nIHRocm91Z2ggYWxsIHRoZSBvbGQgYW5kIGN1cnJlbnQgUkZDcyBhbmQgZHJh ZnRzIGlzIHF1aXRlIGNoYWxsZW5naW5nLg0KPiBTbyBwbGVhc2UgYXBvbG9naXplIGZvciAic2lt cGxlIiBxdWVzdGlvbnMgb3Igb25lcyBtYXliZSBhbHJlYWR5IHJhaXNlZC4NCj4NCj4gLS0tLS1V cnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPiBWb246IEp1ZXJnZW4gU2Nob2Vud2FlbGRl ciANCj4gW21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGVdDQo+IEdl c2VuZGV0OiBEaWVuc3RhZywgMTEuIERlemVtYmVyIDIwMTggMTU6MzMNCj4gQW46IFNlZWhvZmVy LCBNYXJrdXMNCj4gQ2M6IG5ldG1vZEBpZXRmLm9yZw0KPiBCZXRyZWZmOiBbRVhURVJOQUxdIFJl OiBbbmV0bW9kXSBRdWVzdGlvbiBvbiBSRkM4MzQyICsgUkVTVENPTkYgDQo+IGV4dGVuc2lvbiAo ZHJhZnQtaWV0Zi1uZXRjb25mLW5tZGEtcmVzdGNvbmYpDQo+DQo+DQo+DQo+IE9uIFR1ZSwgRGVj IDExLCAyMDE4IGF0IDAyOjE3OjA3UE0gKzAwMDAsIFNlZWhvZmVyLCBNYXJrdXMgd3JvdGU6DQo+ PiBIZWxsbywNCj4+DQo+PiBSZWFkaW5nIFJGQyA4MzQyIGFsb25nIHdpdGggZHJhZnQtaWV0Zi1u ZXRjb25mLW5tZGEtcmVzdGNvbmYtMDUgSSd2ZSBzb21lIHF1ZXN0aW9ucyBvciBjb21wcmVoZW5z aW9uIHByb2JsZW1zIHdpdGggdGhlIHRleHQuDQo+Pg0KPj4NCj4+IDEuICAgICAgIFJGQyA4MzQy IChOTURBKQ0KPj4gQ2hhcHRlciA1LjMuICBUaGUgT3BlcmF0aW9uYWwgU3RhdGUgRGF0YXN0b3Jl ICg8b3BlcmF0aW9uYWw+KSBzYXlzOg0KPj4gIlRoZSBvcGVyYXRpb25hbCBzdGF0ZSBkYXRhc3Rv cmUgKDxvcGVyYXRpb25hbD4pIGlzIGEgcmVhZC1vbmx5IGRhdGFzdG9yZSAuLi4uIg0KPj4gQ2hh cHRlciA2LjIuIEludm9jYXRpb24gb2YgQWN0aW9ucyBhbmQgUlBDcyBzYXlzOg0KPj4gIkFjdGlv bnMgYXJlIGFsd2F5cyBpbnZva2VkIGluIHRoZSBjb250ZXh0IG9mIHRoZSBvcGVyYXRpb25hbCBz dGF0ZSBkYXRhc3RvcmUuIFRoZSBub2RlIGZvciB3aGljaCB0aGUgYWN0aW9uIGlzIGludm9rZWQg TVVTVCBleGlzdCBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlLiINCj4+DQo+PiBD aGFwdGVyIDMuMSBpbiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX3BkZl9kcmFmdC0yRGlldGYtMkRuZXRjb25mLTJEbm1k YS0yRHJlc3Rjb25mLTJEMDUmZD1Ed0lCQWcmYz1CZzVYVUxEWlI4R2lPU1NXTmxwa0NzUmVQbkdE a0tjSTZvWUw5eHYxTW5RJnI9MlhFS1ZZa1FqbUxIaTJUT0pwMVZTemllTFpWcWV3SXBqLVJ4bVJn UGZzTSZtPUNESzI4WDhrTzJ3UlZEbGE5N1BfV3FCSWhGM09BemJXU0dFbVRlTGR4d1Umcz1CU3lZ LUdCdXp6RHJ5Nm9JaGctbWd3TUF5U2JoSkVPOUltM1o0UERfY180JmU9IHNheXM6DQo+PiAiWUFO RyBhY3Rpb25zIGNhbiBvbmx5IGJlIGludm9rZWQgaW4geytyZXN0Y29uZn0vZHMvaWV0Zi1kYXRh c3RvcmVzOm9wZXJhdGlvbmFsLiINCj4+DQo+PiBRdWVzdGlvbjogSG93IGNhbiBvbmUgaW52b2tl IGFuIGFjdGlvbiBpbiBhIGFzIHJlYWQtb25seSBkZWZpbmVkIGRhdGFzdG9yZT8gT3IgYW0gSSBt aXNzaW5nIHNvbWV0aGluZz8NCj4gV2h5IGRvIHlvdSBleHBlY3QgdGhhdCBhIGRhdGFzdG9yZSBo YXMgdG8gYmUgd3JpdGFibGUgaW4gb3JkZXIgdG8gDQo+IGludm9rZSBhbiBhY3Rpb24/IFJGQyA3 OTUwIGhhcyB0aGUgZXhhbXBsZSBvZiBhIHBpbmcgYWN0aW9uIHRpZWQgdG8gYW4gDQo+IGludGVy ZmFjZS4gKFlvdSBwaW5nIGEgcmVtb3RlIHN5c3RlbSBmcm9tIHRoYXQgc3BlY2lmaWMgaW50ZXJm YWNlLikgSW4gDQo+IGdlbmVyYWwsIGFjdGlvbnMgYXJlIHVuZGVyc3Rvb2QgYXMgYmVpbmcgdGll ZCB0byByZWFsIHJlc291cmNlcyBhbmQgDQo+IGhlbmNlIHRvIHRoZSBvcGVyYXRpb25hbCBkYXRh c3RvcmUuIChGb3IgZXhhbXBsZSwgeW91IGNhbid0IHBpbmcgZnJvbSANCj4gYW4gaW50ZXJmYWNl IHRoYXQgaXMgY29uZmlndXJlZCBidXQgbm90IHBoeXNpY2FsbHkgcHJlc2VudC4pDQo+DQo+IFtN U0VFXTogSSBkbyBub3QgZXhwZWN0IHRoYXQgYSBkYXRhc3RvcmUgaGFzIHRvIGJlIHdyaXRlYWJs ZSB0byBpbnZva2UgYW4gYWN0aW9uLCBidXQgSSBkbyBleHBlY3QgdGhhdCBhICJyZWFkLW9ubHki IGRhdGFzdG9yZSBpcyBub3Qgd3JpdGVhYmxlIGFuZCBSRkMgODM0MiBzYXlzIGNsZWFybHkgb3Bl cmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlIGlzICJyZWFkLW9ubHkiLg0KDQpSUENzIGFuZCBhY3Rp b25zIGRvbid0IG1vZGlmeSB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlIGFzIHN1Y2gs IGluc3RlYWQgdGhleSBtb2RpZnkgdGhlIHByb3BlcnRpZXMgb2YgdGhlIHVuZGVybHlpbmcgc3lz dGVtLCBhbmQgdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGRhdGFzdG9yZSBwcm92aWRlcyBhIHJlYWQt b25seSB2aWV3IG9udG8gdGhlIHN0YXRlIG9mIHRoZSBzeXN0ZW0uwqAgU28gPG9wZXJhdGlvbmFs PiBpcyBvbmx5IGJlaW5nIHVwZGF0ZWQgYXMgYSBzaWRlIGVmZmVjdCBvZiByZWZsZWN0aW5nIHRo ZSBjaGFuZ2VzIHRvIHRoZSB1bmRlcmx5aW5nIHN5c3RlbS4NCg0KVGhpcyBjb250cmFzdHMgd2l0 aCB3cml0YWJsZSBjb25maWd1cmF0aW9uIGRhdGFzdG9yZXMgKGUuZy4gPGNhbmRpZGF0ZT4gb3Ig PHJ1bm5pbmc+KSwgd2hlcmUgdGhlIGNsaWVudCBjYW4gbW9kaWZ5IHRoZSBjb25maWd1cmF0aW9u IGluIHRob3NlIGRhdGFzdG9yZXMgZGlyZWN0bHkgd2hpY2ggd2lsbCB0aGVuIGF0dGVtcHQgdG8g Y2hhbmdlIHRoZSBiZWhhdmlvciBvZiB0aGUgc3lzdGVtIGFzIHRoZSBjb25maWcgaXMgYXBwbGll ZC4NCg0KW01TRUVdOiBJIGFncmVlIGJ1dCBJJ20gc3RpbGwgc3R1Y2sgd2l0aCB0aGUgZm9sbG93 aW5nIHRleHQuDQogICAgICAgICAgICAgICAtIGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJlc3Rj b25mLTA1IHNheXMgaW4gQ2hhcHRlciAzLjE6ICJZQU5HIGFjdGlvbnMgY2FuIG9ubHkgYmUgaW52 b2tlZCBpbiB7K3Jlc3Rjb25mfS9kcy9pZXRmLWRhdGFzdG9yZXM6b3BlcmF0aW9uYWwiIHdpdGgN CiAgICAgICAgICAgICAgICAgICJUaGUgcmVzb3VyY2UgeytyZXN0Y29uZn0vZHMvaWV0Zi1kYXRh c3RvcmVzOm9wZXJhdGlvbmFsIHJlZmVycyB0byB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0 b3JlIiBhbmQgIlRoZSBvcGVyYXRpb25hbCBzdGF0ZSBkYXRhc3RvcmUgKDxvcGVyYXRpb25hbD4p IGlzIGEgcmVhZC1vbmx5IGRhdGFzdG9yZSINCiAgICAgICAgICAgICAgIC0gUkZDIDgwNDAgc2F5 cyBpbiBDaGFwdGVyIDMuNiAiIE9wZXJhdGlvbiByZXNvdXJjZXMgcmVwcmVzZW50aW5nIFlBTkcg YWN0aW9ucyBhcmUgbm90IGlkZW50aWZpZWQgaW4gdGhpcyBzdWJ0cmVlLCBzaW5jZSB0aGV5IGFy ZSBpbnZva2VkIHVzaW5nIGEgVVJJIHdpdGhpbiB0aGUgJ3srcmVzdGNvbmZ9L2RhdGEnIHN1YnRy ZWUiIGFuZA0KICAgICAgICAgICAgICAgICAiQW4gYWN0aW9uIGlzIGludm9rZWQgYXM6IFBPU1Qg eytyZXN0Y29uZn0vZGF0YS88ZGF0YS1yZXNvdXJjZS1pZGVudGlmaWVyPi88YWN0aW9uPiINCg0K ICAgICAgICAgICAgICAgU28gd2l0aG91dCBOTURBIGl0IHdhcyBjbGVhciwgaW52b2tlIGFuIGFj dGlvbiB1c2luZyB7K3Jlc3Rjb25mfS9kYXRhfS4gV2l0aCBOTURBIHdoYXQgaXMgdGhlIGNvcnJl Y3Qgd2F5IHRvIHRyaWdnZXIgYW4gYWN0aW9uIGFzIHRoZSBkcmFmdCBzYXlzICJZQU5HIGFjdGlv bnMgY2FuIG9ubHkgYmUgaW52b2tlZCBpbiB7K3Jlc3Rjb25mfS9kcy9pZXRmLWRhdGFzdG9yZXM6 b3BlcmF0aW9uYWwiPw0KDQo+DQo+PiAyLiAgICAgICBUaGUgTk1EQSBpcyBhIGh1Z2Ugc3RlcCBm b3J3YXJkIGZvciBOQyBhbmQgUkMsIHRoYW5rcyBmb3IgdGhhdC4gTk1EQSBpbiBjb21iaW5hdGlv biB3aXRoIHRoZSBuZXcgUkVTVENPTkYgZXh0ZW5zaW9ucyBsZXQgb25lIG5vdyBzZWxlY3Qgb25l IG9mIHRoZSBuYW1lZCBkYXRhc3RvcmVzDQo+PiBpbiBSRkMgODM0Mi4gUmVhZGluZyB0aGUgUkZD IGFuZCBkcmFmdCBJJ20gc3RpbGwgbWlzc2luZyAob3IgZXZlbiBtb3JlIG92ZXJsb29rIEkgZ3Vl c3MpIHRoZSBmb2xsb3dpbmcuIFJGQyA4MDQwIENoYXB0ZXIgNC41IHNheXM6DQo+PiAiQSBQVVQg b24gdGhlIGRhdGFzdG9yZSByZXNvdXJjZSBpcyB1c2VkIHRvIHJlcGxhY2UgdGhlIGVudGlyZSAN Cj4+IGNvbnRlbnRzIG9mIHRoZSBkYXRhc3RvcmUuLi4iLiBTbyBkb2VzIHRoaXMgbWVhbiBvbmUg Y2FuIGhhdmUgdGhlIHNhbWUgYmVoYXZpb3IgYXMgaW4gTkVUQ09ORiB3aGVyZSB5b3UgY2FuIGNv cHkgdGhlICJydW5uaW5nIiBjb25maWcgdG8gInN0YXJ0dXAiIG9yICJjYW5kaWRhdGUiIGNvbmZp ZyB0byAicnVubmluZyIgaWYgYSBSRVNUQ09ORiBzZXJ2ZXIgd291bGQgc3VwcG9ydCB0aGVtPyBJ cyB0aGVyZSBhbnkgZXhhbXBsZSBob3cgdGhpcyB3b3VsZCBsb29rIGxpa2UgaWYgaXQgaXMgYWxs b3dlZD8NCj4gQSBQVVQgZG9lcyBub3QgcmVhbGx5IGdldCB5b3UgdGhlcmUsIHRvIGNvcHkgYSBk YXRhc3RvcmUgdG8gYW5vdGhlciB5b3Ugd2FudCBhbiBvcGVyYXRpb24gb24gdGhlIHNlcnZlci4N Cj4NCj4gW01TRUVdOiBFeGFjdGx5IHRoaXMgaXMgd2hhdCBJIHdhbnQuIE5FVENPTkYgc3BlY2lm aWVzIHRoaXMgY2xlYXJseSBpbiB0aGUgUkZDcyB3aXRoIDxjb3B5LWNvbmZpZz4gYnV0IGhvdyBk b2VzIG9uZSB0cmlnZ2VyIHRoaXMgd2l0aCBSRVNUQ09ORj8gSSBoYWQgdGhlIGhvcGUgd2l0aCBO TURBICsgUkVTVENPTkYgZXh0ZW5zaW9ucyB0aGlzIHdvdWxkDQo+ICAgICAgICAgICAgICAgICBi ZSBwb3NzaWJsZSB0b28uIE9yIGRvIEkgc3RpbGwgbWlzcyBzb21ldGhpbmc/DQoNCkkgdGhpbmsg dGhhdCBpdCBpcyB0aGVvcmV0aWNhbGx5IHBvc3NpYmxlIHRvIGludm9rZSB0aGUgTkVUQ09ORiBS UENzIChlLmcuIHRoZSBjb3B5LWNvbmZpZyBSUEMgZGVmaW5lZCBpbiBpZXRmLW5ldGNvbmYueWFu ZywgUkZDIDYyNDEpIGZyb20gUkVTVENPTkYgKGUuZy4gc2VjdGlvbiAzLjYgb2YgUkZDIDgwNDAp Lg0KDQpXaGV0aGVyIHRoaXMgaXMgYWN0dWFsbHkgYSBnb29kIHRoaW5nIHRvIGRvL2VuY291cmFn ZSBJJ20gbm90IHNvIHN1cmUuDQoNCltNU0VFXTogT0suIEJ1dCB3aGF0IGlzIHRoZSBwcmVmZXJy ZWQgd2F5IGZvciBzb21lb25lIGltcGxlbWVudGluZyBSRVNUQ09ORiBvbiBhIGRldmljZSB3aG8g d291bGQgbGlrZSB0byBoYXZlIHRoZSBzdXBwb3J0IG9mIDxjYW5kaWRhdGU+LCA8c3RhcnR1cD4s IDxydW5uaW5nPiBhbmQgdGhlIG5ldyBvbmVzIGRlZmluZWQgaW4gTk1EQS4NCiAgICAgICAgICAg ICAgIEhvdyBkb2VzIG9uZSBjb3B5IHRoZSBkYXRhIGZyb20gPHJ1bm5pbmc+IHRvIGUuZy4gPHN0 YXJ0dXA+IHVzaW5nIHRoZSBtZWNoYW5pc21zIFJFU1RDT05GIGhhcyBkZWZpbmVkIGluIFJGQyA4 MDQwPyBGcm9tIHJlYWRpbmcgdGhlIFJGQyBpdCBzZWVtcyBpcyBvdXQgb2Ygc2NvcGUgb2YgUkZD IDgwNDAgYnV0IGlzIHRoaXMgcmVhbGx5IGludGVuZGVkPyANCiAgICAgICAgICAgICAgIEltcGxl bWVudGluZyBpZXRmLW5ldGNvbmYueWFuZyBvZiBjb3Vyc2UgY291bGQgYmUgYW4gb3B0aW9uLiAN Cg0KVGhhbmtzLA0KUm9iDQoNCj4NCj4+IDMuICAgICAgIFR5cG8gaW4gaHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19wZGZf ZHJhZnQtMkRpZXRmLTJEbmV0Y29uZi0yRG5tZGEtMkRyZXN0Y29uZi0yRDA1JmQ9RHdJQkFnJmM9 Qmc1WFVMRFpSOEdpT1NTV05scGtDc1JlUG5HRGtLY0k2b1lMOXh2MU1uUSZyPTJYRUtWWWtRam1M SGkyVE9KcDFWU3ppZUxaVnFld0lwai1SeG1SZ1Bmc00mbT1DREsyOFg4a08yd1JWRGxhOTdQX1dx QkloRjNPQXpiV1NHRW1UZUxkeHdVJnM9QlN5WS1HQnV6ekRyeTZvSWhnLW1nd01BeVNiaEpFTzlJ bTNaNFBEX2NfNCZlPSBDaGFwdGVyIDMuMSAidGhlIHNlcnZlciB3b3VsZCBpbXBsZW1lbnQgdGhl IHJlc291cmNlIHsrcmVzdGNvbmZ9L2RzL2V4YW1wbGUtIGRzLWVwaGVtZXJhbDpkcy1lcGhlbWVy YWwuIg0KPj4gVGhlcmUgaXMgYSBzcGFjZSBpbiBiZXR3ZWVuICJleGFtcGxlLSIgYW5kICJkcy1l cGhlbWVyYWw6ZHMtZXBoZW1lcmFsIi4NCj4gTGV0cyBob3BlIHdlIGdldCB0aGlzIGZpeGVkIHdp dGggdGhlIGhlbHAgb2YgdGhlIFJGQyBlZGl0b3IuDQo+DQo+IC9qcw0KPg0KPiAtLQ0KPiBKdWVy Z2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21i SA0KPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1 OSBCcmVtZW4gfCBHZXJtYW55DQo+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmph Y29icy0yRHVuaXZlcnNpdHkuZGVfJmQ9RHdJQkFnJmM9Qmc1WFVMRFpSOEdpT1NTV05scGtDc1Jl UG5HRGtLY0k2b1lMOXh2MU1uUSZyPTJYRUtWWWtRam1MSGkyVE9KcDFWU3ppZUxaVnFld0lwai1S eG1SZ1Bmc00mbT1DREsyOFg4a08yd1JWRGxhOTdQX1dxQkloRjNPQXpiV1NHRW1UZUxkeHdVJnM9 dzM4c2VXaTZGTjQ4T2pQZkpuOTItLWVtaTNyRXpFaURUSHNLTHhFbnNyZyZlPT4NCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxp bmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbA0KPiBtYW5fbGlzdGlu Zm9fbmV0bW9kJmQ9RHdJRGFRJmM9Qmc1WFVMRFpSOEdpT1NTV05scGtDc1JlUG5HRGtLY0k2b1lM OXh2DQo+IDFNblEmcj0yWEVLVllrUWptTEhpMlRPSnAxVlN6aWVMWlZxZXdJcGotUnhtUmdQZnNN Jm09VHJQTVZYUTVJb3ZGbTA4QlMNCj4gYmJYYTJFLUhuU09feXpIUnkwR1I5ZGpUMk0mcz1zZDEx b25IQTQyT0RueXN6OVpPSVppa1dXUU1Ia0h3VVNlTC1sTldjaw0KPiBERSZlPQ0KCioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioKRElTQ0xBSU1FUjoKUHJpdmlsZWdlZCBhbmQvb3IgQ29uZmlkZW50aWFsIGluZm9ybWF0 aW9uIG1heSBiZSBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUg YWRkcmVzc2VlIG9mIHRoaXMgbWVzc2FnZSwgeW91IG1heSBub3QgY29weSwgdXNlIG9yIGRlbGl2 ZXIgdGhpcyBtZXNzYWdlIHRvIGFueW9uZS4gSW4gc3VjaCBldmVudCwgeW91IHNob3VsZCBkZXN0 cm95IHRoZSBtZXNzYWdlIGFuZCBraW5kbHkgbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVwbHkgZS1t YWlsLiBJdCBpcyB1bmRlcnN0b29kIHRoYXQgb3BpbmlvbnMgb3IgY29uY2x1c2lvbnMgdGhhdCBk byBub3QgcmVsYXRlIHRvIHRoZSBvZmZpY2lhbCBidXNpbmVzcyBvZiB0aGUgY29tcGFueSBhcmUg bmVpdGhlciBnaXZlbiBub3IgZW5kb3JzZWQgYnkgdGhlIGNvbXBhbnkuIFRoYW5rIFlvdS4K From nobody Wed Dec 12 02:12:51 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7E412777C for ; Wed, 12 Dec 2018 02:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wp8qqW-j_M0j for ; Wed, 12 Dec 2018 02:12:47 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479AD12F18C for ; Wed, 12 Dec 2018 02:12:47 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 387478179EFFC for ; Wed, 12 Dec 2018 10:12:41 +0000 (GMT) Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 12 Dec 2018 10:12:42 +0000 Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.202]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0415.000; Wed, 12 Dec 2018 18:12:29 +0800 From: Rohit R Ranade To: "netmod@ietf.org" Thread-Topic: Schema Mount Terminology Clarification Thread-Index: AdSSAHJMd79djmViQCOmlgelvyOoWA== Date: Wed, 12 Dec 2018 10:12:29 +0000 Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCA7DE4@dggeml510-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.150.121] Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BCA7DE4dggeml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [netmod] Schema Mount Terminology Clarification X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Dec 2018 10:12:49 -0000 --_000_991B70D8B4112A4699D5C00DDBBF878A6BCA7DE4dggeml510mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, 1. The term "data model" is used many times in this document, but it = is not defined in this document but defined in RFC 7950. I think it should = be added under the "following terms are defined in [RFC7950]" part. 2. The term "This document allows mounting of complete data models on= ly" is used in Section 1. I think here "complete data model" should be repl= aced by "schema tree" as it is more precise? a) RFC 7950 , schema tree: The definition hierarchy specified withi= n a module b) RFC7950, data model: A data model describes how data is represented an= d accessed 3. The "data model" term is used many times Eg: "LNE's data model", "= share the same data model", "NI data model", "mounting one data model consi= sting of any number of YANG modules" etc, sometimes using the term "data = model" as a collection of YANG modules and sometimes for a single Yang modu= le. I feel, where-ever we refer to single Module, we need to use the term "= schema tree" and when we refer to collection of YANG modules, we can refer = to as Data Model.. Please provide your opinions. With Regards, Rohit --_000_991B70D8B4112A4699D5C00DDBBF878A6BCA7DE4dggeml510mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

 

1= .   &= nbsp;   The term “data mo= del” is used many times in this document, but it is not defined in th= is document but defined in RFC 7950. I think it should be added under the &= #8220;following terms are defined in [RFC7950]” part.

 

2= .   &= nbsp;   The term “= This document allows mounting of complete data models = only” is used in Section 1. I think here “complete data model” should be replaced by ̶= 0;schema tree” as it is more precise?

 =

a= )   &= nbsp;     RFC 7950 , schema tree: The definition hierarchy specified within a mo= dule

b= )   RFC7950, data model: A = data model describes how data is represented and accessed=

=  

3= .   &= nbsp;   The “data model&#= 8221; term is used many times Eg: “LNE's data model”, “sh= are the same data model”, “NI data model”, “mountin= g one data model consisting of any number of YANG modules”  = ; etc, sometimes using the term “data model” as a collection of YANG modules and sometimes for= a single Yang module. I feel, where-ever we refer to single Module, we nee= d to use the term “schema tree” and when we refer to collection= of YANG modules, we can refer to as Data Model.. Please provide your opinions.

 

With Regards,=

Rohit  <= /p>

--_000_991B70D8B4112A4699D5C00DDBBF878A6BCA7DE4dggeml510mbxchi_-- From nobody Wed Dec 12 02:21:18 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C41130DC6 for ; Wed, 12 Dec 2018 02:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.958 X-Spam-Level: X-Spam-Status: No, score=-15.958 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01RjLxKetOTI for ; Wed, 12 Dec 2018 02:21:12 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E63AD12F18C for ; Wed, 12 Dec 2018 02:21:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28720; q=dns/txt; s=iport; t=1544610072; x=1545819672; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=hqi83Pq9nRvd8RNefc+Y3sKQ6r7kh/EZQF2UfansR9M=; b=QUTKLZYmsCMHPoEZKDmXnU6tBRLarGhk/dz5oyOiV/1VcQZXsmpsCWYQ 6PdSMN+XbP5yzuZ3FB/6FnrWTD3MK8gy+lFlWwciY44hqa3tDgjKypXfz wwkeSetM/3kDO/eFmtV5Cmyv0YHphY5fcuVwMiEMh8XUVSpOK33NN5bMr 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAAAE4BBc/xbLJq1gAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVIDAQEBAQELAYENTYEPTyESJ4N7iHiNEwglfJZXFIF?= =?us-ascii?q?mDSKBdoJUAoMbNQgNAQMBAQIBAQJtHAyFPAEBAQECARoJSxkCCxAIIAcDAgI?= =?us-ascii?q?bKxEGAQwGAgEBglJLAYF5CA+lWIEvH4UhhHAFixqBNIFAP4ERJwyBYUk1gUG?= =?us-ascii?q?BXQQYgTABNyaCPYJXAokgARmWeFUJhwqDPoRngiAGGIFcTYRNgwMmhyWJJoR?= =?us-ascii?q?zhDeGaYFHATaBVjMaCBsVO4JsCYIqHYM4ilM/AzABAYthK4IgAQE?= X-IronPort-AV: E=Sophos;i="5.56,344,1539648000"; d="scan'208,217";a="8802583" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2018 10:21:09 +0000 Received: from [10.63.23.68] (dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com [10.63.23.68]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id wBCAL8Mc003744; Wed, 12 Dec 2018 10:21:09 GMT To: "Seehofer, Markus" , "netmod@ietf.org" References: <20181211143313.xouvshwdtakmkdz4@anna.jacobs.jacobs-university.de> <9d40f9ad4b494e67ba2808341dc82e4d@DCRIC1EXC03PA.mcp.local> <532b30422c7a4e77972181c32eaa8ff8@DCRIC1EXC03PA.mcp.local> From: Robert Wilton Message-ID: <3db5de24-5168-0065-be9e-94f0b57cf06f@cisco.com> Date: Wed, 12 Dec 2018 10:21:08 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <532b30422c7a4e77972181c32eaa8ff8@DCRIC1EXC03PA.mcp.local> Content-Type: multipart/alternative; boundary="------------DD0B454E7B5B76706436B746" Content-Language: en-US X-Outbound-SMTP-Client: 10.63.23.68, dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [netmod] Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf) X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 12 Dec 2018 10:21:15 -0000 This is a multi-part message in MIME format. --------------DD0B454E7B5B76706436B746 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Markus, On 11/12/2018 17:21, Seehofer, Markus wrote: > Hello Robert, > > comments inline below. > > BR > Markus > > -----Ursprüngliche Nachricht----- > Von: Robert Wilton [mailto:rwilton@cisco.com] > Gesendet: Dienstag, 11. Dezember 2018 17:06 > An: Seehofer, Markus > Cc: netmod@ietf.org > Betreff: Re: [netmod] [EXTERNAL] Re: Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf) > > Hi Seehofer, > > Please see inline ... > > On 11/12/2018 14:55, Seehofer, Markus wrote: >> Hello Juergen, >> >> see my comments inline below. As being quite new to the topic, going through all the old and current RFCs and drafts is quite challenging. >> So please apologize for "simple" questions or ones maybe already raised. >> >> -----Ursprüngliche Nachricht----- >> Von: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Gesendet: Dienstag, 11. Dezember 2018 15:33 >> An: Seehofer, Markus >> Cc: netmod@ietf.org >> Betreff: [EXTERNAL] Re: [netmod] Question on RFC8342 + RESTCONF >> extension (draft-ietf-netconf-nmda-restconf) >> >> >> >> On Tue, Dec 11, 2018 at 02:17:07PM +0000, Seehofer, Markus wrote: >>> Hello, >>> >>> Reading RFC 8342 along with draft-ietf-netconf-nmda-restconf-05 I've some questions or comprehension problems with the text. >>> >>> >>> 1. RFC 8342 (NMDA) >>> Chapter 5.3. The Operational State Datastore () says: >>> "The operational state datastore () is a read-only datastore ...." >>> Chapter 6.2. Invocation of Actions and RPCs says: >>> "Actions are always invoked in the context of the operational state datastore. The node for which the action is invoked MUST exist in the operational state datastore." >>> >>> Chapter 3.1 in https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_pdf_draft-2Dietf-2Dnetconf-2Dnmda-2Drestconf-2D05&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=BSyY-GBuzzDry6oIhg-mgwMAySbhJEO9Im3Z4PD_c_4&e= says: >>> "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational." >>> >>> Question: How can one invoke an action in a as read-only defined datastore? Or am I missing something? >> Why do you expect that a datastore has to be writable in order to >> invoke an action? RFC 7950 has the example of a ping action tied to an >> interface. (You ping a remote system from that specific interface.) In >> general, actions are understood as being tied to real resources and >> hence to the operational datastore. (For example, you can't ping from >> an interface that is configured but not physically present.) >> >> [MSEE]: I do not expect that a datastore has to be writeable to invoke an action, but I do expect that a "read-only" datastore is not writeable and RFC 8342 says clearly operational state datastore is "read-only". > RPCs and actions don't modify the operational state datastore as such, instead they modify the properties of the underlying system, and the operational state datastore provides a read-only view onto the state of the system.  So is only being updated as a side effect of reflecting the changes to the underlying system. > > This contrasts with writable configuration datastores (e.g. or ), where the client can modify the configuration in those datastores directly which will then attempt to change the behavior of the system as the config is applied. > > [MSEE]: I agree but I'm still stuck with the following text. > - draft-ietf-netconf-nmda-restconf-05 says in Chapter 3.1: "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational" with > "The resource {+restconf}/ds/ietf-datastores:operational refers to the operational state datastore" and "The operational state datastore () is a read-only datastore" > - RFC 8040 says in Chapter 3.6 " Operation resources representing YANG actions are not identified in this subtree, since they are invoked using a URI within the '{+restconf}/data' subtree" and > "An action is invoked as: POST {+restconf}/data//" > > So without NMDA it was clear, invoke an action using {+restconf}/data}. With NMDA what is the correct way to trigger an action as the draft says "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational"? So, you invoke it on the equivalent path using the operational datastore. E.g. to take the example from RFC 8040 3.6.2, the request pre NMDA is this: POST /restconf/data/example-actions:interfaces/\ interface=eth0/get-last-reset-time HTTP/1.1 Host: example.com Accept: application/yang-data+json The equivalent path on a NMDA server is this: POST /restconf/ds/ietf-datastores:operational/\ example-actions:interfaces/\ interface=eth0/get-last-reset-time HTTP/1.1 Host: example.com Accept: application/yang-data+json I think that your concern might be: why is it right/OK to invoke a action on what is defined as a read only structure? The answer to this is that the action isn't acting on , it is acting on the underlying system and has the remit to change any of the system behavior. However, before the action can be processed, the system must validate that the data node that it is acting on exists, and the parameters are valid.  This validation is performed against the systems operational state, and hence is validated against . Again, considering the example above, it wouldn't make sense to get the last reset time of an interface that existed in configuration, and hence was present in /, but was not in . In future we may need actions that are validated against other datastores, but when the authors were discussing this it was unclear whether proper use cases for such actions exist, and hence we decided that this could be deferred to future work, which would presumably come along with a concrete use case. >>> 2. The NMDA is a huge step forward for NC and RC, thanks for that. NMDA in combination with the new RESTCONF extensions let one now select one of the named datastores >>> in RFC 8342. Reading the RFC and draft I'm still missing (or even more overlook I guess) the following. RFC 8040 Chapter 4.5 says: >>> "A PUT on the datastore resource is used to replace the entire >>> contents of the datastore...". So does this mean one can have the same behavior as in NETCONF where you can copy the "running" config to "startup" or "candidate" config to "running" if a RESTCONF server would support them? Is there any example how this would look like if it is allowed? >> A PUT does not really get you there, to copy a datastore to another you want an operation on the server. >> >> [MSEE]: Exactly this is what I want. NETCONF specifies this clearly in the RFCs with but how does one trigger this with RESTCONF? I had the hope with NMDA + RESTCONF extensions this would >> be possible too. Or do I still miss something? > I think that it is theoretically possible to invoke the NETCONF RPCs (e.g. the copy-config RPC defined in ietf-netconf.yang, RFC 6241) from RESTCONF (e.g. section 3.6 of RFC 8040). > > Whether this is actually a good thing to do/encourage I'm not so sure. > > [MSEE]: OK. But what is the preferred way for someone implementing RESTCONF on a device who would like to have the support of , , and the new ones defined in NMDA. > How does one copy the data from to e.g. using the mechanisms RESTCONF has defined in RFC 8040? From reading the RFC it seems is out of scope of RFC 8040 but is this really intended? > Implementing ietf-netconf.yang of course could be an option. I agree that this isn't really specified. IIRC our initial focus was to effectively get parity with RFC 8040.  I.e. my working assumption is that (if present) would be handled automatically and similarly updates to would be handled automatically.  E.g. broadly equivalent to the /data resource in RESTCONF.  So in essence this boils down to clients interacting with /ds/ietf-datastores:running, /ds/ietf-datastores:operational and /ds/ietf-datastores:intended. No new RESTCONF operations should be necessary here. I'm also not really convinced that independently controllable and is really a great idea. Given that is meant to represent persistent configuration, then automatically updating as a side effect of updating seems like the most sensible behavior.  If the desire is for some ephemeral type configuration then that would be better modeled via an explicit dynamic configuration datastore (e.g. a bit like what I2RS were trying to do). Similarly, instead of a shared candidate datastore, there is some work investigating private candidate datastores. draft-lhotka-netconf-restconf-transactions-00 gives some ideas of what this could look like, but further work is required. If there is a strong requirement to allow full explicit manipulation of configuration datastores then I think that we should probably define explicit RPCs for these operations (modeled on the NETCONF ones).  Ideally, these could be defined in a protocol neutral format so that they can work with any YANG based management protocols.  In the interim, using the NETCONF RPCs from RESTCONF seems like a reasonable stopgap measure. Thanks, Rob > > > Thanks, > Rob > >>> 3. Typo in https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_pdf_draft-2Dietf-2Dnetconf-2Dnmda-2Drestconf-2D05&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=BSyY-GBuzzDry6oIhg-mgwMAySbhJEO9Im3Z4PD_c_4&e= Chapter 3.1 "the server would implement the resource {+restconf}/ds/example- ds-ephemeral:ds-ephemeral." >>> There is a space in between "example-" and "ds-ephemeral:ds-ephemeral". >> Lets hope we get this fixed with the help of the RFC editor. >> >> /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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail >> man_listinfo_netmod&d=DwIDaQ&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv >> 1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=TrPMVXQ5IovFm08BS >> bbXa2E-HnSO_yzHRy0GR9djT2M&s=sd11onHA42ODnysz9ZOIZikWWQMHkHwUSeL-lNWck >> DE&e= > ********************************************************************** > DISCLAIMER: > Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You. --------------DD0B454E7B5B76706436B746 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Markus,

On 11/12/2018 17:21, Seehofer, Markus wrote:
Hello Robert,

comments inline below.

BR
 Markus 

-----Ursprüngliche Nachricht-----
Von: Robert Wilton [mailto:rwilton@cisco.com] 
Gesendet: Dienstag, 11. Dezember 2018 17:06
An: Seehofer, Markus
Cc: netmod@ietf.org
Betreff: Re: [netmod] [EXTERNAL] Re: Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)

Hi Seehofer,

Please see inline ...

On 11/12/2018 14:55, Seehofer, Markus wrote:

Hello Juergen,

see my comments inline below. As being quite new to the topic, going through all the old and current RFCs and drafts is quite challenging.
So please apologize for "simple" questions or ones maybe already raised.

-----Ursprüngliche Nachricht-----
Von: Juergen Schoenwaelder 
[mailto:j.schoenwaelder@jacobs-university.de]
Gesendet: Dienstag, 11. Dezember 2018 15:33
An: Seehofer, Markus
Cc: netmod@ietf.org
Betreff: [EXTERNAL] Re: [netmod] Question on RFC8342 + RESTCONF 
extension (draft-ietf-netconf-nmda-restconf)



On Tue, Dec 11, 2018 at 02:17:07PM +0000, Seehofer, Markus wrote:

Hello,

Reading RFC 8342 along with draft-ietf-netconf-nmda-restconf-05 I've some questions or comprehension problems with the text.


1.       RFC 8342 (NMDA)
Chapter 5.3.  The Operational State Datastore (<operational>) says:
"The operational state datastore (<operational>) is a read-only datastore ...."
Chapter 6.2. Invocation of Actions and RPCs says:
"Actions are always invoked in the context of the operational state datastore. The node for which the action is invoked MUST exist in the operational state datastore."

Chapter 3.1 in https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_pdf_draft-2Dietf-2Dnetconf-2Dnmda-2Drestconf-2D05&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=BSyY-GBuzzDry6oIhg-mgwMAySbhJEO9Im3Z4PD_c_4&e= says:
"YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational."

Question: How can one invoke an action in a as read-only defined datastore? Or am I missing something?

Why do you expect that a datastore has to be writable in order to 
invoke an action? RFC 7950 has the example of a ping action tied to an 
interface. (You ping a remote system from that specific interface.) In 
general, actions are understood as being tied to real resources and 
hence to the operational datastore. (For example, you can't ping from 
an interface that is configured but not physically present.)

[MSEE]: I do not expect that a datastore has to be writeable to invoke an action, but I do expect that a "read-only" datastore is not writeable and RFC 8342 says clearly operational state datastore is "read-only".

RPCs and actions don't modify the operational state datastore as such, instead they modify the properties of the underlying system, and the operational state datastore provides a read-only view onto the state of the system.  So <operational> is only being updated as a side effect of reflecting the changes to the underlying system.

This contrasts with writable configuration datastores (e.g. <candidate> or <running>), where the client can modify the configuration in those datastores directly which will then attempt to change the behavior of the system as the config is applied.

[MSEE]: I agree but I'm still stuck with the following text.
               - draft-ietf-netconf-nmda-restconf-05 says in Chapter 3.1: "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational" with
                  "The resource {+restconf}/ds/ietf-datastores:operational refers to the operational state datastore" and "The operational state datastore (<operational>) is a read-only datastore"
               - RFC 8040 says in Chapter 3.6 " Operation resources representing YANG actions are not identified in this subtree, since they are invoked using a URI within the '{+restconf}/data' subtree" and
                 "An action is invoked as: POST {+restconf}/data/<data-resource-identifier>/<action>"

               So without NMDA it was clear, invoke an action using {+restconf}/data}. With NMDA what is the correct way to trigger an action as the draft says "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational"?

So, you invoke it on the equivalent path using the operational datastore.

E.g. to take the example from RFC 8040 3.6.2, the request pre NMDA is this: 

      POST /restconf/data/example-actions:interfaces/\
         interface=eth0/get-last-reset-time HTTP/1.1
      Host: example.com
      Accept: application/yang-data+json

The equivalent path on a NMDA server is this: 

      POST /restconf/ds/ietf-datastores:operational/\
         example-actions:interfaces/\
         interface=eth0/get-last-reset-time HTTP/1.1
      Host: example.com
      Accept: application/yang-data+json

I think that your concern might be: why is it right/OK to invoke a action on what is defined as a read only structure?

The answer to this is that the action isn't acting on <operational>, it is acting on the underlying system and has the remit to change any of the system behavior.

However, before the action can be processed, the system must validate that the data node that it is acting on exists, and the parameters are valid.  This validation is performed against the systems operational state, and hence is validated against <operational>.

Again, considering the example above, it wouldn't make sense to get the last reset time of an interface that existed in configuration, and hence was present in <running>/<intended>, but was not in <operational>.

In future we may need actions that are validated against other datastores, but when the authors were discussing this it was unclear whether proper use cases for such actions exist, and hence we decided that this could be deferred to future work, which would presumably come along with a concrete use case.


      

        

        

          
2.       The NMDA is a huge step forward for NC and RC, thanks for that. NMDA in combination with the new RESTCONF extensions let one now select one of the named datastores
in RFC 8342. Reading the RFC and draft I'm still missing (or even more overlook I guess) the following. RFC 8040 Chapter 4.5 says:
"A PUT on the datastore resource is used to replace the entire 
contents of the datastore...". So does this mean one can have the same behavior as in NETCONF where you can copy the "running" config to "startup" or "candidate" config to "running" if a RESTCONF server would support them? Is there any example how this would look like if it is allowed?


        

        
A PUT does not really get you there, to copy a datastore to another you want an operation on the server.

[MSEE]: Exactly this is what I want. NETCONF specifies this clearly in the RFCs with <copy-config> but how does one trigger this with RESTCONF? I had the hope with NMDA + RESTCONF extensions this would
                be possible too. Or do I still miss something?


      

      
I think that it is theoretically possible to invoke the NETCONF RPCs (e.g. the copy-config RPC defined in ietf-netconf.yang, RFC 6241) from RESTCONF (e.g. section 3.6 of RFC 8040).

Whether this is actually a good thing to do/encourage I'm not so sure.

[MSEE]: OK. But what is the preferred way for someone implementing RESTCONF on a device who would like to have the support of <candidate>, <startup>, <running> and the new ones defined in NMDA.
               How does one copy the data from <running> to e.g. <startup> using the mechanisms RESTCONF has defined in RFC 8040? From reading the RFC it seems is out of scope of RFC 8040 but is this really intended? 
               Implementing ietf-netconf.yang of course could be an option.

    

    
I agree that this isn't really specified.

    
IIRC our initial focus was to effectively get parity with RFC
      8040.  I.e. my working assumption is that <candidate> (if
      present) would be handled automatically and similarly updates to
      <startup> would be handled automatically.  E.g. broadly
      equivalent to the /data resource in RESTCONF.  So in essence this
      boils down to clients interacting with /ds/ietf-datastores:running,
      /ds/ietf-datastores:operational and /ds/ietf-datastores:intended. 
      No new RESTCONF operations should be necessary here.

    

    
I'm also not really convinced that independently controllable
      <startup> and <candidate> is really a great idea.

    
Given that <running> is meant to represent persistent
      configuration, then automatically updating <startup> as a
      side effect of updating <running> seems like the most
      sensible behavior.  If the desire is for some ephemeral type
      configuration then that would be better modeled via an explicit
      dynamic configuration datastore (e.g. a bit like what I2RS were
      trying to do).

    
Similarly, instead of a shared candidate datastore, there is some
      work investigating private candidate datastores. 
      draft-lhotka-netconf-restconf-transactions-00 gives some ideas of
      what this could look like, but further work is required.

    

    
If there is a strong requirement to allow full explicit
      manipulation of configuration datastores then I think that we
      should probably define explicit RPCs for these operations (modeled
      on the NETCONF ones).  Ideally, these could be defined in a
      protocol neutral format so that they can work with any YANG based
      management protocols.  In the interim, using the NETCONF RPCs from
      RESTCONF seems like a reasonable stopgap measure.

    

    
Thanks,

      Rob

    


    

    

      
 

Thanks,
Rob



      

        

        

          
3.       Typo in https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_pdf_draft-2Dietf-2Dnetconf-2Dnmda-2Drestconf-2D05&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=BSyY-GBuzzDry6oIhg-mgwMAySbhJEO9Im3Z4PD_c_4&e= Chapter 3.1 "the server would implement the resource {+restconf}/ds/example- ds-ephemeral:ds-ephemeral."
There is a space in between "example-" and "ds-ephemeral:ds-ephemeral".


        

        
Lets hope we get this fixed with the help of the RFC editor.

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=w38seWi6FN48OjPfJn92--emi3rEzEiDTHsKLxEnsrg&e=>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
man_listinfo_netmod&d=DwIDaQ&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv
1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=TrPMVXQ5IovFm08BS
bbXa2E-HnSO_yzHRy0GR9djT2M&s=sd11onHA42ODnysz9ZOIZikWWQMHkHwUSeL-lNWck
DE&e=


      

      
**********************************************************************
DISCLAIMER:
Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.


    

  


--------------DD0B454E7B5B76706436B746--


From nobody Wed Dec 12 02:44:10 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9507112F1AC for ; Wed, 12 Dec 2018 02:44:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YM7f_LC0tD0T for ; Wed, 12 Dec 2018 02:44:06 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62FAC12777C for ; Wed, 12 Dec 2018 02:44:05 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:d850:7cff:fe67:4574]) by mail.nic.cz (Postfix) with ESMTPSA id 681BD616C4 for ; Wed, 12 Dec 2018 11:44:02 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1544611442; bh=O2sWOZor+Nfy1Msk7bppCLUwDb9USjubfDjLOrk+loY=; h=From:To:Date; b=eSo3PK2DVo0YHGqNzGt/nD0JnkgZDpcka1tDQEE3p32txyziZBZ8gh2xnMlI24MIH bzgBPMXnSL73bu3zRc8vppRy2RvN0EJHy5JkL7lXr4kmLrH+rkSCJkZMH5hb8wGnBT 2aGye+CIUqYwV7oWnyZMTKaSDRqNGbw85OY1sRGQ=
Message-ID: <4ddfe88336e6528d079eb583dec7faa95ccf9a2d.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Wed, 12 Dec 2018 11:44:02 +0100
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BCA7DE4@dggeml510-mbx.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BCA7DE4@dggeml510-mbx.china.huawei.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.3 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Schema Mount Terminology Clarification
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Dec 2018 10:44:09 -0000

Hi Rehat,

On Wed, 2018-12-12 at 10:12 +0000, Rohit R Ranade wrote:
> Hi,
>  
>  
> 1..       The term “data model” is used many times in this document, but it is
> not defined in this document but defined in RFC 7950. I think it should be
> added under the “following terms are defined in [RFC7950]” part.

The definition of "data model" in RFC 7950 is too informal. What is meant by it
in the schema mount document is basically "datastore schema" as defined in RFC
8342. Perhaps a better term would just be "schema".

>  
> 2..       The term “This document allows mounting of complete data models
> only” is used in Section 1. I think here “complete data model” should be
> replaced by “schema tree” as it is more precise?

No, "schema tree" is only for a single module, accrding to the definition in
7950. What is meant here is a schema of multiple modules, as defined by YANG
library.

>  
> a)         RFC 7950 , schema tree: The definition hierarchy specified within a
> module
> b)   RFC7950, data model: A data model describes how data is represented and
> accessed
>  
> 3..       The “data model” term is used many times Eg: “LNE's data model”,
> “share the same data model”, “NI data model”, “mounting one data model
> consisting of any number of YANG modules”   etc, sometimes using the term
> “data model” as a collection of YANG modules and sometimes for a single Yang
> module. I feel, where-ever we refer to single Module, we need to use the term
> “schema tree” and when we refer to collection of YANG modules, we can refer to
> as Data Model.. Please provide your opinions.

This was my original idea, but maybe it is better to use "schema" or "datastore
schema" for the latter.

Lada

>  
> With Regards,
> Rohit  
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Dec 12 03:08:41 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85640130DBE for ; Wed, 12 Dec 2018 03:08:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHHBBY3IZy56 for ; Wed, 12 Dec 2018 03:08:32 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE88B12D4E8 for ; Wed, 12 Dec 2018 03:08:32 -0800 (PST)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1B8BEAEEA96C0; Wed, 12 Dec 2018 11:08:27 +0000 (GMT)
Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 12 Dec 2018 11:08:27 +0000
Received: from DGGEML510-MBX.china.huawei.com ([169.254.2.202]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0415.000; Wed, 12 Dec 2018 19:08:16 +0800
From: Rohit R Ranade 
To: Ladislav Lhotka , "netmod@ietf.org" 
Thread-Topic: [netmod] Schema Mount Terminology Clarification
Thread-Index: AdSSAHJMd79djmViQCOmlgelvyOoWP//iC8A//9140A=
Date: Wed, 12 Dec 2018 11:08:16 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCA7E45@dggeml510-mbx.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BCA7DE4@dggeml510-mbx.china.huawei.com> <4ddfe88336e6528d079eb583dec7faa95ccf9a2d.camel@nic.cz>
In-Reply-To: <4ddfe88336e6528d079eb583dec7faa95ccf9a2d.camel@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Schema Mount Terminology Clarification
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Dec 2018 11:08:39 -0000

SGkgTGFkYSwNCg0KVGhhbmsgeW91IGZvciB5b3VyIHJlc3BvbnNlLg0KUGxlYXNlIGZpbmQgc29t
ZSByZXNwb25zZXMgaW5saW5lLg0KDQpXaXRoIFJlZ2FyZHMsDQpSb2hpdA0KDQotLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0
Zi5vcmddIE9uIEJlaGFsZiBPZiBMYWRpc2xhdiBMaG90a2ENClNlbnQ6IDEyIERlY2VtYmVyIDIw
MTggMTY6MTQNClRvOiBuZXRtb2RAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBTY2hl
bWEgTW91bnQgVGVybWlub2xvZ3kgQ2xhcmlmaWNhdGlvbg0KDQpIaSBSZWhhdCwNCg0KT24gV2Vk
LCAyMDE4LTEyLTEyIGF0IDEwOjEyICswMDAwLCBSb2hpdCBSIFJhbmFkZSB3cm90ZToNCj4gSGks
DQo+ICANCj4gIA0KPiAxLi4gICAgICAgVGhlIHRlcm0g4oCcZGF0YSBtb2RlbOKAnSBpcyB1c2Vk
IG1hbnkgdGltZXMgaW4gdGhpcyBkb2N1bWVudCwgYnV0IGl0IGlzDQo+IG5vdCBkZWZpbmVkIGlu
IHRoaXMgZG9jdW1lbnQgYnV0IGRlZmluZWQgaW4gUkZDIDc5NTAuIEkgdGhpbmsgaXQgDQo+IHNo
b3VsZCBiZSBhZGRlZCB1bmRlciB0aGUg4oCcZm9sbG93aW5nIHRlcm1zIGFyZSBkZWZpbmVkIGlu
IFtSRkM3OTUwXeKAnSBwYXJ0Lg0KDQpUaGUgZGVmaW5pdGlvbiBvZiAiZGF0YSBtb2RlbCIgaW4g
UkZDIDc5NTAgaXMgdG9vIGluZm9ybWFsLiBXaGF0IGlzIG1lYW50IGJ5IGl0IGluIHRoZSBzY2hl
bWEgbW91bnQgZG9jdW1lbnQgaXMgYmFzaWNhbGx5ICJkYXRhc3RvcmUgc2NoZW1hIiBhcyBkZWZp
bmVkIGluIFJGQyA4MzQyLiBQZXJoYXBzIGEgYmV0dGVyIHRlcm0gd291bGQganVzdCBiZSAic2No
ZW1hIi4NCg0KPiAgDQo+IDIuLiAgICAgICBUaGUgdGVybSDigJxUaGlzIGRvY3VtZW50IGFsbG93
cyBtb3VudGluZyBvZiBjb21wbGV0ZSBkYXRhIG1vZGVscw0KPiBvbmx54oCdIGlzIHVzZWQgaW4g
U2VjdGlvbiAxLiBJIHRoaW5rIGhlcmUg4oCcY29tcGxldGUgZGF0YSBtb2RlbOKAnSBzaG91bGQg
DQo+IGJlIHJlcGxhY2VkIGJ5IOKAnHNjaGVtYSB0cmVl4oCdIGFzIGl0IGlzIG1vcmUgcHJlY2lz
ZT8NCg0KTm8sICJzY2hlbWEgdHJlZSIgaXMgb25seSBmb3IgYSBzaW5nbGUgbW9kdWxlLCBhY2Ny
ZGluZyB0byB0aGUgZGVmaW5pdGlvbiBpbiA3OTUwLiBXaGF0IGlzIG1lYW50IGhlcmUgaXMgYSBz
Y2hlbWEgb2YgbXVsdGlwbGUgbW9kdWxlcywgYXMgZGVmaW5lZCBieSBZQU5HIGxpYnJhcnkuDQpb
Um9oaXQgUiBSYW5hZGVdIEkgYWdyZWUuIE1heWJlICJjb21wbGV0ZSBzY2hlbWEgdHJlZXMiIGlz
IGJldHRlciBhcyBtb3VudGluZyBzdWItaGllcmFyY2hpZXMgaXMgbm90IGluIHNjb3BlIGZvciB0
aGlzIGRvY3VtZW50LiBJIHNlZSB0aGF0IGl0IGhhcyBiZWVuIHVzZWQgaW4gU2VjdGlvbiAxIGlu
IHRoZSBiZWxvdyBzdGF0ZW1lbnQgLiANCiIgV2l0aCB0aGUgInVzZXMiIGFwcHJvYWNoLCB0aGUg
Y29tcGxldGUgc2NoZW1hIHRyZWUgb2YgImlldGYtaW50ZXJmYWNlcyIgd291bGQgaGF2ZSB0byBi
ZSB3cmFwcGVkIGluIGEgZ3JvdXBpbmcgLi4uLi4uICINCg0KPiAgDQo+IGEpICAgICAgICAgUkZD
IDc5NTAgLCBzY2hlbWEgdHJlZTogVGhlIGRlZmluaXRpb24gaGllcmFyY2h5IHNwZWNpZmllZCB3
aXRoaW4gYQ0KPiBtb2R1bGUNCj4gYikgICBSRkM3OTUwLCBkYXRhIG1vZGVsOiBBIGRhdGEgbW9k
ZWwgZGVzY3JpYmVzIGhvdyBkYXRhIGlzIHJlcHJlc2VudGVkIGFuZA0KPiBhY2Nlc3NlZA0KPiAg
DQo+IDMuLiAgICAgICBUaGUg4oCcZGF0YSBtb2RlbOKAnSB0ZXJtIGlzIHVzZWQgbWFueSB0aW1l
cyBFZzog4oCcTE5FJ3MgZGF0YSBtb2RlbOKAnSwNCj4g4oCcc2hhcmUgdGhlIHNhbWUgZGF0YSBt
b2RlbOKAnSwg4oCcTkkgZGF0YSBtb2RlbOKAnSwg4oCcbW91bnRpbmcgb25lIGRhdGEgbW9kZWwN
Cj4gY29uc2lzdGluZyBvZiBhbnkgbnVtYmVyIG9mIFlBTkcgbW9kdWxlc+KAnSAgIGV0Yywgc29t
ZXRpbWVzIHVzaW5nIHRoZSB0ZXJtDQo+IOKAnGRhdGEgbW9kZWzigJ0gYXMgYSBjb2xsZWN0aW9u
IG9mIFlBTkcgbW9kdWxlcyBhbmQgc29tZXRpbWVzIGZvciBhIA0KPiBzaW5nbGUgWWFuZyBtb2R1
bGUuIEkgZmVlbCwgd2hlcmUtZXZlciB3ZSByZWZlciB0byBzaW5nbGUgTW9kdWxlLCB3ZSANCj4g
bmVlZCB0byB1c2UgdGhlIHRlcm0g4oCcc2NoZW1hIHRyZWXigJ0gYW5kIHdoZW4gd2UgcmVmZXIg
dG8gY29sbGVjdGlvbiBvZiANCj4gWUFORyBtb2R1bGVzLCB3ZSBjYW4gcmVmZXIgdG8gYXMgRGF0
YSBNb2RlbC4uIFBsZWFzZSBwcm92aWRlIHlvdXIgb3BpbmlvbnMuDQoNClRoaXMgd2FzIG15IG9y
aWdpbmFsIGlkZWEsIGJ1dCBtYXliZSBpdCBpcyBiZXR0ZXIgdG8gdXNlICJzY2hlbWEiIG9yICJk
YXRhc3RvcmUgc2NoZW1hIiBmb3IgdGhlIGxhdHRlci4NCltSb2hpdCBSIFJhbmFkZV0gSSBhZ3Jl
ZSB0aGF0IHRlcm0gInNjaGVtYSIgaXMgaW5kZWVkIGJldHRlci4gDQoNCkxhZGENCg0KPiAgDQo+
IFdpdGggUmVnYXJkcywNCj4gUm9oaXQNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5v
cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCi0tDQpM
YWRpc2xhdiBMaG90a2ENCkhlYWQsIENaLk5JQyBMYWJzDQpQR1AgS2V5IElEOiAweEI4RjkyQjA4
QTlGNzZDNjcNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg==


From nobody Wed Dec 12 06:33:22 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD5E1276D0 for ; Wed, 12 Dec 2018 06:33:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E76EY9QUJM2r for ; Wed, 12 Dec 2018 06:33:19 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 263AE127133 for ; Wed, 12 Dec 2018 06:33:19 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 30B1A182015D; Wed, 12 Dec 2018 15:42:08 +0100 (CET)
Received: from localhost (unknown [195.113.220.122]) by trail.lhotka.name (Postfix) with ESMTPSA id D07D11820053 for ; Wed, 12 Dec 2018 15:42:06 +0100 (CET)
From: Ladislav Lhotka 
To: netmod@ietf.org
Mail-Followup-To: netmod@ietf.org
Date: Wed, 12 Dec 2018 15:33:15 +0100
Message-ID: <87zhtan7bo.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: [netmod] datastore-specific constraints
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Dec 2018 14:33:21 -0000

Hi,

in some cases, constraints expressed with "when" or "must" may only be
intended for configuration datastores. A typical example is an
auto-negotiable parameter:

leaf auto-foo {
  type boolean;
  default true;
  description "If true, parameter 'foo' will be auto-negotiated.";
}
leaf foo {
  when "../auto-foo = 'false'";
  ...
}

This means that if auto-foo is true, it is impossible to configure the
foo parameter. However, even with auto-foo = true, it is desirable to
see the auto-negotiated value in , so, ideally, the "when"
constraint should not apply in .

How can this logic be modelled under NMDA? Is an extra leaf
"foo-operational" needed?

Thanks, Lada

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


From nobody Wed Dec 12 06:40:48 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96D2127133 for ; Wed, 12 Dec 2018 06:40:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level: 
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9W_KfpxyRkJ for ; Wed, 12 Dec 2018 06:40:42 -0800 (PST)
Received: from mail1.belden.com (mail1.belden.com [12.168.192.252]) (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 9E604130DC1 for ; Wed, 12 Dec 2018 06:40:40 -0800 (PST)
Received: from pps.filterd (dcric1ppa01pa.mcp.local [127.0.0.1]) by dcric1ppa01pa.mcp.local (8.16.0.22/8.16.0.22) with SMTP id wBCEY182031604;  Wed, 12 Dec 2018 09:40:38 -0500
Received: from dcric1exc01pa.mcp.local (dcric1exc01pa.mcp.local [10.10.181.21]) by dcric1ppa01pa.mcp.local with ESMTP id 2paxj4hc29-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 12 Dec 2018 09:40:38 -0500
Received: from DCRIC1EXC03PA.mcp.local (10.10.181.23) by DCRIC1EXC01PA.mcp.local (10.10.181.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 12 Dec 2018 09:40:37 -0500
Received: from DCRIC1EXC03PA.mcp.local ([172.16.254.23]) by DCRIC1EXC03PA.mcp.local ([172.16.254.23]) with mapi id 15.00.1367.000; Wed, 12 Dec 2018 09:40:37 -0500
From: "Seehofer, Markus" 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [EXTERNAL] Re: AW: [netmod] Re: Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)
Thread-Index: AQHUkgRonWXhlfpjPkezsrdYR4eIAKV7FDSw
Date: Wed, 12 Dec 2018 14:40:36 +0000
Message-ID: 
References:  <20181211143313.xouvshwdtakmkdz4@anna.jacobs.jacobs-university.de> <9d40f9ad4b494e67ba2808341dc82e4d@DCRIC1EXC03PA.mcp.local>  <532b30422c7a4e77972181c32eaa8ff8@DCRIC1EXC03PA.mcp.local> <3db5de24-5168-0065-be9e-94f0b57cf06f@cisco.com>
In-Reply-To: <3db5de24-5168-0065-be9e-94f0b57cf06f@cisco.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.115.35.153]
x-c2processedorg: 157cf0a0-3349-4636-89a5-bb6917ccdf3c
Content-Type: multipart/alternative; boundary="_000_bebb6cfd66884c68bac3635d6b0832eaDCRIC1EXC03PAmcplocal_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-12_04:, , signatures=0
Archived-At: 
Subject: Re: [netmod] Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Dec 2018 14:40:46 -0000

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

SGVsbG8gUm9iZXJ0LA0KDQpWb246IFJvYmVydCBXaWx0b24gW21haWx0bzpyd2lsdG9uQGNpc2Nv
LmNvbV0NCkdlc2VuZGV0OiBNaXR0d29jaCwgMTIuIERlemVtYmVyIDIwMTggMTE6MjENCkFuOiBT
ZWVob2ZlciwgTWFya3VzOyBuZXRtb2RAaWV0Zi5vcmcNCkJldHJlZmY6IFtFWFRFUk5BTF0gUmU6
IEFXOiBbbmV0bW9kXSBSZTogUXVlc3Rpb24gb24gUkZDODM0MiArIFJFU1RDT05GIGV4dGVuc2lv
biAoZHJhZnQtaWV0Zi1uZXRjb25mLW5tZGEtcmVzdGNvbmYpDQoNCg0KDQoNCkhpIE1hcmt1cywN
Ck9uIDExLzEyLzIwMTggMTc6MjEsIFNlZWhvZmVyLCBNYXJrdXMgd3JvdGU6DQoNCkhlbGxvIFJv
YmVydCwNCg0KDQoNCmNvbW1lbnRzIGlubGluZSBiZWxvdy4NCg0KDQoNCkJSDQoNCiBNYXJrdXMN
Cg0KDQoNCi0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCg0KVm9uOiBSb2JlcnQg
V2lsdG9uIFttYWlsdG86cndpbHRvbkBjaXNjby5jb21dDQoNCkdlc2VuZGV0OiBEaWVuc3RhZywg
MTEuIERlemVtYmVyIDIwMTggMTc6MDYNCg0KQW46IFNlZWhvZmVyLCBNYXJrdXMNCg0KQ2M6IG5l
dG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KDQpCZXRyZWZmOiBSZTogW25l
dG1vZF0gW0VYVEVSTkFMXSBSZTogUXVlc3Rpb24gb24gUkZDODM0MiArIFJFU1RDT05GIGV4dGVu
c2lvbiAoZHJhZnQtaWV0Zi1uZXRjb25mLW5tZGEtcmVzdGNvbmYpDQoNCg0KDQpIaSBTZWVob2Zl
ciwNCg0KDQoNClBsZWFzZSBzZWUgaW5saW5lIC4uLg0KDQoNCg0KT24gMTEvMTIvMjAxOCAxNDo1
NSwgU2VlaG9mZXIsIE1hcmt1cyB3cm90ZToNCg0KSGVsbG8gSnVlcmdlbiwNCg0KDQoNCnNlZSBt
eSBjb21tZW50cyBpbmxpbmUgYmVsb3cuIEFzIGJlaW5nIHF1aXRlIG5ldyB0byB0aGUgdG9waWMs
IGdvaW5nIHRocm91Z2ggYWxsIHRoZSBvbGQgYW5kIGN1cnJlbnQgUkZDcyBhbmQgZHJhZnRzIGlz
IHF1aXRlIGNoYWxsZW5naW5nLg0KDQpTbyBwbGVhc2UgYXBvbG9naXplIGZvciAic2ltcGxlIiBx
dWVzdGlvbnMgb3Igb25lcyBtYXliZSBhbHJlYWR5IHJhaXNlZC4NCg0KDQoNCi0tLS0tVXJzcHLD
vG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCg0KVm9uOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCg0K
W21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGVdDQoNCkdlc2VuZGV0
OiBEaWVuc3RhZywgMTEuIERlemVtYmVyIDIwMTggMTU6MzMNCg0KQW46IFNlZWhvZmVyLCBNYXJr
dXMNCg0KQ2M6IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KDQpCZXRy
ZWZmOiBbRVhURVJOQUxdIFJlOiBbbmV0bW9kXSBRdWVzdGlvbiBvbiBSRkM4MzQyICsgUkVTVENP
TkYNCg0KZXh0ZW5zaW9uIChkcmFmdC1pZXRmLW5ldGNvbmYtbm1kYS1yZXN0Y29uZikNCg0KDQoN
Cg0KDQoNCg0KT24gVHVlLCBEZWMgMTEsIDIwMTggYXQgMDI6MTc6MDdQTSArMDAwMCwgU2VlaG9m
ZXIsIE1hcmt1cyB3cm90ZToNCg0KSGVsbG8sDQoNCg0KDQpSZWFkaW5nIFJGQyA4MzQyIGFsb25n
IHdpdGggZHJhZnQtaWV0Zi1uZXRjb25mLW5tZGEtcmVzdGNvbmYtMDUgSSd2ZSBzb21lIHF1ZXN0
aW9ucyBvciBjb21wcmVoZW5zaW9uIHByb2JsZW1zIHdpdGggdGhlIHRleHQuDQoNCg0KDQoNCg0K
MS4gICAgICAgUkZDIDgzNDIgKE5NREEpDQoNCkNoYXB0ZXIgNS4zLiAgVGhlIE9wZXJhdGlvbmFs
IFN0YXRlIERhdGFzdG9yZSAoPG9wZXJhdGlvbmFsPikgc2F5czoNCg0KIlRoZSBvcGVyYXRpb25h
bCBzdGF0ZSBkYXRhc3RvcmUgKDxvcGVyYXRpb25hbD4pIGlzIGEgcmVhZC1vbmx5IGRhdGFzdG9y
ZSAuLi4uIg0KDQpDaGFwdGVyIDYuMi4gSW52b2NhdGlvbiBvZiBBY3Rpb25zIGFuZCBSUENzIHNh
eXM6DQoNCiJBY3Rpb25zIGFyZSBhbHdheXMgaW52b2tlZCBpbiB0aGUgY29udGV4dCBvZiB0aGUg
b3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlLiBUaGUgbm9kZSBmb3Igd2hpY2ggdGhlIGFjdGlv
biBpcyBpbnZva2VkIE1VU1QgZXhpc3QgaW4gdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGRhdGFzdG9y
ZS4iDQoNCg0KDQpDaGFwdGVyIDMuMSBpbiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j
b20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX3BkZl9kcmFmdC0yRGlldGYtMkRu
ZXRjb25mLTJEbm1kYS0yRHJlc3Rjb25mLTJEMDUmZD1Ed0lCQWcmYz1CZzVYVUxEWlI4R2lPU1NX
Tmxwa0NzUmVQbkdEa0tjSTZvWUw5eHYxTW5RJnI9MlhFS1ZZa1FqbUxIaTJUT0pwMVZTemllTFpW
cWV3SXBqLVJ4bVJnUGZzTSZtPUNESzI4WDhrTzJ3UlZEbGE5N1BfV3FCSWhGM09BemJXU0dFbVRl
TGR4d1Umcz1CU3lZLUdCdXp6RHJ5Nm9JaGctbWd3TUF5U2JoSkVPOUltM1o0UERfY180JmU9IHNh
eXM6DQoNCiJZQU5HIGFjdGlvbnMgY2FuIG9ubHkgYmUgaW52b2tlZCBpbiB7K3Jlc3Rjb25mfS9k
cy9pZXRmLWRhdGFzdG9yZXM6b3BlcmF0aW9uYWwuIg0KDQoNCg0KUXVlc3Rpb246IEhvdyBjYW4g
b25lIGludm9rZSBhbiBhY3Rpb24gaW4gYSBhcyByZWFkLW9ubHkgZGVmaW5lZCBkYXRhc3RvcmU/
IE9yIGFtIEkgbWlzc2luZyBzb21ldGhpbmc/DQoNCldoeSBkbyB5b3UgZXhwZWN0IHRoYXQgYSBk
YXRhc3RvcmUgaGFzIHRvIGJlIHdyaXRhYmxlIGluIG9yZGVyIHRvDQoNCmludm9rZSBhbiBhY3Rp
b24/IFJGQyA3OTUwIGhhcyB0aGUgZXhhbXBsZSBvZiBhIHBpbmcgYWN0aW9uIHRpZWQgdG8gYW4N
Cg0KaW50ZXJmYWNlLiAoWW91IHBpbmcgYSByZW1vdGUgc3lzdGVtIGZyb20gdGhhdCBzcGVjaWZp
YyBpbnRlcmZhY2UuKSBJbg0KDQpnZW5lcmFsLCBhY3Rpb25zIGFyZSB1bmRlcnN0b29kIGFzIGJl
aW5nIHRpZWQgdG8gcmVhbCByZXNvdXJjZXMgYW5kDQoNCmhlbmNlIHRvIHRoZSBvcGVyYXRpb25h
bCBkYXRhc3RvcmUuIChGb3IgZXhhbXBsZSwgeW91IGNhbid0IHBpbmcgZnJvbQ0KDQphbiBpbnRl
cmZhY2UgdGhhdCBpcyBjb25maWd1cmVkIGJ1dCBub3QgcGh5c2ljYWxseSBwcmVzZW50LikNCg0K
DQoNCltNU0VFXTogSSBkbyBub3QgZXhwZWN0IHRoYXQgYSBkYXRhc3RvcmUgaGFzIHRvIGJlIHdy
aXRlYWJsZSB0byBpbnZva2UgYW4gYWN0aW9uLCBidXQgSSBkbyBleHBlY3QgdGhhdCBhICJyZWFk
LW9ubHkiIGRhdGFzdG9yZSBpcyBub3Qgd3JpdGVhYmxlIGFuZCBSRkMgODM0MiBzYXlzIGNsZWFy
bHkgb3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlIGlzICJyZWFkLW9ubHkiLg0KDQoNCg0KUlBD
cyBhbmQgYWN0aW9ucyBkb24ndCBtb2RpZnkgdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGRhdGFzdG9y
ZSBhcyBzdWNoLCBpbnN0ZWFkIHRoZXkgbW9kaWZ5IHRoZSBwcm9wZXJ0aWVzIG9mIHRoZSB1bmRl
cmx5aW5nIHN5c3RlbSwgYW5kIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBkYXRhc3RvcmUgcHJvdmlk
ZXMgYSByZWFkLW9ubHkgdmlldyBvbnRvIHRoZSBzdGF0ZSBvZiB0aGUgc3lzdGVtLiAgU28gPG9w
ZXJhdGlvbmFsPiBpcyBvbmx5IGJlaW5nIHVwZGF0ZWQgYXMgYSBzaWRlIGVmZmVjdCBvZiByZWZs
ZWN0aW5nIHRoZSBjaGFuZ2VzIHRvIHRoZSB1bmRlcmx5aW5nIHN5c3RlbS4NCg0KDQoNClRoaXMg
Y29udHJhc3RzIHdpdGggd3JpdGFibGUgY29uZmlndXJhdGlvbiBkYXRhc3RvcmVzIChlLmcuIDxj
YW5kaWRhdGU+IG9yIDxydW5uaW5nPiksIHdoZXJlIHRoZSBjbGllbnQgY2FuIG1vZGlmeSB0aGUg
Y29uZmlndXJhdGlvbiBpbiB0aG9zZSBkYXRhc3RvcmVzIGRpcmVjdGx5IHdoaWNoIHdpbGwgdGhl
biBhdHRlbXB0IHRvIGNoYW5nZSB0aGUgYmVoYXZpb3Igb2YgdGhlIHN5c3RlbSBhcyB0aGUgY29u
ZmlnIGlzIGFwcGxpZWQuDQoNCg0KDQpbTVNFRV06IEkgYWdyZWUgYnV0IEknbSBzdGlsbCBzdHVj
ayB3aXRoIHRoZSBmb2xsb3dpbmcgdGV4dC4NCg0KICAgICAgICAgICAgICAgLSBkcmFmdC1pZXRm
LW5ldGNvbmYtbm1kYS1yZXN0Y29uZi0wNSBzYXlzIGluIENoYXB0ZXIgMy4xOiAiWUFORyBhY3Rp
b25zIGNhbiBvbmx5IGJlIGludm9rZWQgaW4geytyZXN0Y29uZn0vZHMvaWV0Zi1kYXRhc3RvcmVz
Om9wZXJhdGlvbmFsIiB3aXRoDQoNCiAgICAgICAgICAgICAgICAgICJUaGUgcmVzb3VyY2Ugeyty
ZXN0Y29uZn0vZHMvaWV0Zi1kYXRhc3RvcmVzOm9wZXJhdGlvbmFsIHJlZmVycyB0byB0aGUgb3Bl
cmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlIiBhbmQgIlRoZSBvcGVyYXRpb25hbCBzdGF0ZSBkYXRh
c3RvcmUgKDxvcGVyYXRpb25hbD4pIGlzIGEgcmVhZC1vbmx5IGRhdGFzdG9yZSINCg0KICAgICAg
ICAgICAgICAgLSBSRkMgODA0MCBzYXlzIGluIENoYXB0ZXIgMy42ICIgT3BlcmF0aW9uIHJlc291
cmNlcyByZXByZXNlbnRpbmcgWUFORyBhY3Rpb25zIGFyZSBub3QgaWRlbnRpZmllZCBpbiB0aGlz
IHN1YnRyZWUsIHNpbmNlIHRoZXkgYXJlIGludm9rZWQgdXNpbmcgYSBVUkkgd2l0aGluIHRoZSAn
eytyZXN0Y29uZn0vZGF0YScgc3VidHJlZSIgYW5kDQoNCiAgICAgICAgICAgICAgICAgIkFuIGFj
dGlvbiBpcyBpbnZva2VkIGFzOiBQT1NUIHsrcmVzdGNvbmZ9L2RhdGEvPGRhdGEtcmVzb3VyY2Ut
aWRlbnRpZmllcj4vPGFjdGlvbj4iDQoNCg0KDQogICAgICAgICAgICAgICBTbyB3aXRob3V0IE5N
REEgaXQgd2FzIGNsZWFyLCBpbnZva2UgYW4gYWN0aW9uIHVzaW5nIHsrcmVzdGNvbmZ9L2RhdGF9
LiBXaXRoIE5NREEgd2hhdCBpcyB0aGUgY29ycmVjdCB3YXkgdG8gdHJpZ2dlciBhbiBhY3Rpb24g
YXMgdGhlIGRyYWZ0IHNheXMgIllBTkcgYWN0aW9ucyBjYW4gb25seSBiZSBpbnZva2VkIGluIHsr
cmVzdGNvbmZ9L2RzL2lldGYtZGF0YXN0b3JlczpvcGVyYXRpb25hbCI/DQoNClNvLCB5b3UgaW52
b2tlIGl0IG9uIHRoZSBlcXVpdmFsZW50IHBhdGggdXNpbmcgdGhlIG9wZXJhdGlvbmFsIGRhdGFz
dG9yZS4NCg0KRS5nLiB0byB0YWtlIHRoZSBleGFtcGxlIGZyb20gUkZDIDgwNDAgMy42LjIsIHRo
ZSByZXF1ZXN0IHByZSBOTURBIGlzIHRoaXM6DQoNCiAgICAgIFBPU1QgL3Jlc3Rjb25mL2RhdGEv
ZXhhbXBsZS1hY3Rpb25zOmludGVyZmFjZXMvXA0KDQogICAgICAgICBpbnRlcmZhY2U9ZXRoMC9n
ZXQtbGFzdC1yZXNldC10aW1lIEhUVFAvMS4xDQoNCiAgICAgIEhvc3Q6IGV4YW1wbGUuY29tDQoN
CiAgICAgIEFjY2VwdDogYXBwbGljYXRpb24veWFuZy1kYXRhK2pzb24NCg0KVGhlIGVxdWl2YWxl
bnQgcGF0aCBvbiBhIE5NREEgc2VydmVyIGlzIHRoaXM6DQoNCiAgICAgIFBPU1QgL3Jlc3Rjb25m
L2RzL2lldGYtZGF0YXN0b3JlczpvcGVyYXRpb25hbC9cDQoNCiAgICAgICAgIGV4YW1wbGUtYWN0
aW9uczppbnRlcmZhY2VzL1wNCg0KICAgICAgICAgaW50ZXJmYWNlPWV0aDAvZ2V0LWxhc3QtcmVz
ZXQtdGltZSBIVFRQLzEuMQ0KDQogICAgICBIb3N0OiBleGFtcGxlLmNvbQ0KDQogICAgICBBY2Nl
cHQ6IGFwcGxpY2F0aW9uL3lhbmctZGF0YStqc29uDQoNCkkgdGhpbmsgdGhhdCB5b3VyIGNvbmNl
cm4gbWlnaHQgYmU6IHdoeSBpcyBpdCByaWdodC9PSyB0byBpbnZva2UgYSBhY3Rpb24gb24gd2hh
dCBpcyBkZWZpbmVkIGFzIGEgcmVhZCBvbmx5IHN0cnVjdHVyZT8NCg0KW01TRUVdOiAgRXhhY3Rs
eS4gQnkganVzdCByZWFkaW5nICJUaGUgb3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlICg8b3Bl
cmF0aW9uYWw+KSBpcyBhIHJlYWQtb25seSBkYXRhc3RvcmUgLi4uLiIgbWF5IGJlIGNvbmZ1c2lu
Zy4gSSBzdGlsbCBzdHJ1Z2dsZSB3aXRoIHRoZSB0ZXh0Lg0KDQpUaGUgYW5zd2VyIHRvIHRoaXMg
aXMgdGhhdCB0aGUgYWN0aW9uIGlzbid0IGFjdGluZyBvbiA8b3BlcmF0aW9uYWw+LCBpdCBpcyBh
Y3Rpbmcgb24gdGhlIHVuZGVybHlpbmcgc3lzdGVtIGFuZCBoYXMgdGhlIHJlbWl0IHRvIGNoYW5n
ZSBhbnkgb2YgdGhlIHN5c3RlbSBiZWhhdmlvci4NCg0KSG93ZXZlciwgYmVmb3JlIHRoZSBhY3Rp
b24gY2FuIGJlIHByb2Nlc3NlZCwgdGhlIHN5c3RlbSBtdXN0IHZhbGlkYXRlIHRoYXQgdGhlIGRh
dGEgbm9kZSB0aGF0IGl0IGlzIGFjdGluZyBvbiBleGlzdHMsIGFuZCB0aGUgcGFyYW1ldGVycyBh
cmUgdmFsaWQuICBUaGlzIHZhbGlkYXRpb24gaXMgcGVyZm9ybWVkIGFnYWluc3QgdGhlIHN5c3Rl
bXMgb3BlcmF0aW9uYWwgc3RhdGUsIGFuZCBoZW5jZSBpcyB2YWxpZGF0ZWQgYWdhaW5zdCA8b3Bl
cmF0aW9uYWw+Lg0KDQpbTVNFRV06IEkgYWdyZWUsIHRoaXMgb2YgY291cnNlIG1ha2VzIHNlbnNl
IGFzIG9ubHkgdGhlIDxvcGVyYXRpb25hbD4gZGF0YXN0b3JlIGhhcyB0aGUgaW5mb3JtYXRpb25z
IHdoaWNoIG5vZGVzIGFyZSBpbiB1c2UgYW5kIHRoZXJlZm9yZSBhcmUgYXZhaWxhYmxlIGZvciB1
c2FnZS4NCg0KQWdhaW4sIGNvbnNpZGVyaW5nIHRoZSBleGFtcGxlIGFib3ZlLCBpdCB3b3VsZG4n
dCBtYWtlIHNlbnNlIHRvIGdldCB0aGUgbGFzdCByZXNldCB0aW1lIG9mIGFuIGludGVyZmFjZSB0
aGF0IGV4aXN0ZWQgaW4gY29uZmlndXJhdGlvbiwgYW5kIGhlbmNlIHdhcyBwcmVzZW50IGluIDxy
dW5uaW5nPi88aW50ZW5kZWQ+LCBidXQgd2FzIG5vdCBpbiA8b3BlcmF0aW9uYWw+Lg0KDQpbTVNF
RV06IFllcywgSSBhZ3JlZS4NCg0KSW4gZnV0dXJlIHdlIG1heSBuZWVkIGFjdGlvbnMgdGhhdCBh
cmUgdmFsaWRhdGVkIGFnYWluc3Qgb3RoZXIgZGF0YXN0b3JlcywgYnV0IHdoZW4gdGhlIGF1dGhv
cnMgd2VyZSBkaXNjdXNzaW5nIHRoaXMgaXQgd2FzIHVuY2xlYXIgd2hldGhlciBwcm9wZXIgdXNl
IGNhc2VzIGZvciBzdWNoIGFjdGlvbnMgZXhpc3QsIGFuZCBoZW5jZSB3ZSBkZWNpZGVkIHRoYXQg
dGhpcyBjb3VsZCBiZSBkZWZlcnJlZCB0byBmdXR1cmUgd29yaywgd2hpY2ggd291bGQgcHJlc3Vt
YWJseSBjb21lIGFsb25nIHdpdGggYSBjb25jcmV0ZSB1c2UgY2FzZS4NCg0KW01TRUVdOiBPSy4N
Cg0KW01TRUVdOiBBbG9uZyB3aXRoIHRoZSBhYm92ZSBxdWVzdGlvbnMgYW5kIGFuc3dlcnMvc3Rh
dGVtZW50cyAodGhhbmtzIGZvciB0aGlzKSBJIHByb2JhYmx5IHN0aWxsIGhhdmUgbW9yZSBxdWVz
dGlvbnMgdGhhbiBhbnN3ZXJzIGZyb20gcmVhZGluZyB0aGUgUkZDcyBhbmQgZHJhZnRzLg0KDQot
ICAgICAgICAgIERyYWZ0IGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJlc3Rjb25mLTA1IHNheXM6
DQrigJxBbiBOTURBLWNvbXBsaWFudCBzZXJ2ZXIgTVVTVCBpbXBsZW1lbnQgeytyZXN0Y29uZn0v
ZHMvaWV0Zi1kYXRhc3RvcmVzOm9wZXJhdGlvbmFsLiAgT3RoZXIgZGF0YXN0b3JlIHJlc291cmNl
cyBNQVkgYmUgaW1wbGVtZW50ZWTigJ0uDQpEb2VzIHRoaXMgbWVhbiBhIEdFVCB0byB7K3Jlc3Rj
b25mfS9kYXRhfSAod2hpY2ggaXMgc3RpbGwgdmFsaWQpIHJldHVybnMgdGhlIHNhbWUgZGF0YSBh
cyBhIEdFVCB0byB7K3Jlc3Rjb25mfS9kcy9pZXRmLWRhdGFzdG9yZXM6b3BlcmF0aW9uYWwgaWYg
aXQgaXMgTk1EQSBjb21wbGlhbnQ/DQoNCg0KLSAgICAgICAgICBJZiBzdWNoIGEgTk1EQSBjb21w
bGlhbnQgUkVTVENPTkYgc2VydmVyIGhhcyBlLmcuIOKAnGV4YW1wbGUtanVrZWJveOKAnSBpbXBs
ZW1lbnRlZCwgYXJlIGJvdGggb2YgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnRzIGNvcnJlY3Q/DQoN
CiAgICAgUEFUQ0ggL3Jlc3Rjb25mL2RhdGEvZXhhbXBsZS1qdWtlYm94Omp1a2Vib3gvXA0KICAg
ICAgICAgbGlicmFyeS9hcnRpc3Q9Rm9vJTIwRmlnaHRlcnMvYWxidW09V2FzdGluZyUyMExpZ2h0
IEhUVFAvMS4xDQogICAgIEhvc3Q6IGV4YW1wbGUuY29tDQogICAgIElmLU1hdGNoOiAiYjgzODky
MzNhNGMiDQogICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veWFuZy1kYXRhK3htbA0KICAg
ICA8YWxidW0geG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9ucy9leGFtcGxlLWp1a2Vib3giPg0K
ICAgICAgPHllYXI+MjAxMTwveWVhcj4NCiAgICAgPC9hbGJ1bT4NCg0KYW5kDQoNClBBVENIIC9y
ZXN0Y29uZi9kcy9pZXRmLWRhdGFzdG9yZXM6b3BlcmF0aW9uYWwvZXhhbXBsZS1qdWtlYm94Omp1
a2Vib3gvXA0KICAgbGlicmFyeS9hcnRpc3Q9Rm9vJTIwRmlnaHRlcnMvYWxidW09V2FzdGluZyUy
MExpZ2h0IEhUVFAvMS4xDQpIb3N0OiBleGFtcGxlLmNvbQ0KSWYtTWF0Y2g6ICJiODM4OTIzM2E0
YyINCkNvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veWFuZy1kYXRhK3htbA0KPGFsYnVtIHhtbG5z
PSJodHRwOi8vZXhhbXBsZS5jb20vbnMvZXhhbXBsZS1qdWtlYm94Ij4NCjx5ZWFyPjIwMTE8L3ll
YXI+DQo8L2FsYnVtPg0KDQotICAgICAgICBEcmFmdCBkcmFmdC1pZXRmLW5ldGNvbmYtbm1kYS1y
ZXN0Y29uZi0wNSBzYXlzOg0KICAgICAgICAgIOKAnCBZQU5HIGFjdGlvbnMgY2FuIG9ubHkgYmUg
aW52b2tlZCBpbiB7K3Jlc3Rjb25mfS9kcy9pZXRmLWRhdGFzdG9yZXM6b3BlcmF0aW9uYWzigJ0N
CiAgICAgICAgICBJbiBzdWNoIGEgTk1EQSBjb21wbGlhbnQgUkVTVENPTkYgc2VydmVyLCBpcyB7
K3Jlc3Rjb25mfS9vcGVyYXRpb25zIChSRkM4MDQwIC0gMy42IE9wZXJhdGlvbiBSZXNvdXJjZSAp
c3RpbGwgdmFsaWQ/IEJlY2F1c2UgdGhlIGFib3ZlIHN0YXRlbWVudCBzYXlzIOKAnOKApmNhbiBv
bmx54oCm4oCdIG9yIGRvZXMgb25lIGhhdmUgdG8gdXNlOg0KDQpQT1NUIHsrcmVzdGNvbmZ9L2Rz
L2lldGYtZGF0YXN0b3JlczpvcGVyYXRpb25hbCAvPG9wZXJhdGlvbj4NCmFuZA0KUE9TVCB7K3Jl
c3Rjb25mfS9kcy9pZXRmLWRhdGFzdG9yZXM6b3BlcmF0aW9uYWwgLzxkYXRhLXJlc291cmNlLWlk
ZW50aWZpZXI+LzxhY3Rpb24+DQpvbiBhIE5NREEgY29tcGxpYW50IHNlcnZlciBvbmx5Pw0KDQoy
LiAgICAgICBUaGUgTk1EQSBpcyBhIGh1Z2Ugc3RlcCBmb3J3YXJkIGZvciBOQyBhbmQgUkMsIHRo
YW5rcyBmb3IgdGhhdC4gTk1EQSBpbiBjb21iaW5hdGlvbiB3aXRoIHRoZSBuZXcgUkVTVENPTkYg
ZXh0ZW5zaW9ucyBsZXQgb25lIG5vdyBzZWxlY3Qgb25lIG9mIHRoZSBuYW1lZCBkYXRhc3RvcmVz
DQoNCmluIFJGQyA4MzQyLiBSZWFkaW5nIHRoZSBSRkMgYW5kIGRyYWZ0IEknbSBzdGlsbCBtaXNz
aW5nIChvciBldmVuIG1vcmUgb3Zlcmxvb2sgSSBndWVzcykgdGhlIGZvbGxvd2luZy4gUkZDIDgw
NDAgQ2hhcHRlciA0LjUgc2F5czoNCg0KIkEgUFVUIG9uIHRoZSBkYXRhc3RvcmUgcmVzb3VyY2Ug
aXMgdXNlZCB0byByZXBsYWNlIHRoZSBlbnRpcmUNCg0KY29udGVudHMgb2YgdGhlIGRhdGFzdG9y
ZS4uLiIuIFNvIGRvZXMgdGhpcyBtZWFuIG9uZSBjYW4gaGF2ZSB0aGUgc2FtZSBiZWhhdmlvciBh
cyBpbiBORVRDT05GIHdoZXJlIHlvdSBjYW4gY29weSB0aGUgInJ1bm5pbmciIGNvbmZpZyB0byAi
c3RhcnR1cCIgb3IgImNhbmRpZGF0ZSIgY29uZmlnIHRvICJydW5uaW5nIiBpZiBhIFJFU1RDT05G
IHNlcnZlciB3b3VsZCBzdXBwb3J0IHRoZW0/IElzIHRoZXJlIGFueSBleGFtcGxlIGhvdyB0aGlz
IHdvdWxkIGxvb2sgbGlrZSBpZiBpdCBpcyBhbGxvd2VkPw0KDQpBIFBVVCBkb2VzIG5vdCByZWFs
bHkgZ2V0IHlvdSB0aGVyZSwgdG8gY29weSBhIGRhdGFzdG9yZSB0byBhbm90aGVyIHlvdSB3YW50
IGFuIG9wZXJhdGlvbiBvbiB0aGUgc2VydmVyLg0KDQoNCg0KW01TRUVdOiBFeGFjdGx5IHRoaXMg
aXMgd2hhdCBJIHdhbnQuIE5FVENPTkYgc3BlY2lmaWVzIHRoaXMgY2xlYXJseSBpbiB0aGUgUkZD
cyB3aXRoIDxjb3B5LWNvbmZpZz4gYnV0IGhvdyBkb2VzIG9uZSB0cmlnZ2VyIHRoaXMgd2l0aCBS
RVNUQ09ORj8gSSBoYWQgdGhlIGhvcGUgd2l0aCBOTURBICsgUkVTVENPTkYgZXh0ZW5zaW9ucyB0
aGlzIHdvdWxkDQoNCiAgICAgICAgICAgICAgICBiZSBwb3NzaWJsZSB0b28uIE9yIGRvIEkgc3Rp
bGwgbWlzcyBzb21ldGhpbmc/DQoNCg0KDQpJIHRoaW5rIHRoYXQgaXQgaXMgdGhlb3JldGljYWxs
eSBwb3NzaWJsZSB0byBpbnZva2UgdGhlIE5FVENPTkYgUlBDcyAoZS5nLiB0aGUgY29weS1jb25m
aWcgUlBDIGRlZmluZWQgaW4gaWV0Zi1uZXRjb25mLnlhbmcsIFJGQyA2MjQxKSBmcm9tIFJFU1RD
T05GIChlLmcuIHNlY3Rpb24gMy42IG9mIFJGQyA4MDQwKS4NCg0KDQoNCldoZXRoZXIgdGhpcyBp
cyBhY3R1YWxseSBhIGdvb2QgdGhpbmcgdG8gZG8vZW5jb3VyYWdlIEknbSBub3Qgc28gc3VyZS4N
Cg0KDQoNCltNU0VFXTogT0suIEJ1dCB3aGF0IGlzIHRoZSBwcmVmZXJyZWQgd2F5IGZvciBzb21l
b25lIGltcGxlbWVudGluZyBSRVNUQ09ORiBvbiBhIGRldmljZSB3aG8gd291bGQgbGlrZSB0byBo
YXZlIHRoZSBzdXBwb3J0IG9mIDxjYW5kaWRhdGU+LCA8c3RhcnR1cD4sIDxydW5uaW5nPiBhbmQg
dGhlIG5ldyBvbmVzIGRlZmluZWQgaW4gTk1EQS4NCg0KICAgICAgICAgICAgICAgSG93IGRvZXMg
b25lIGNvcHkgdGhlIGRhdGEgZnJvbSA8cnVubmluZz4gdG8gZS5nLiA8c3RhcnR1cD4gdXNpbmcg
dGhlIG1lY2hhbmlzbXMgUkVTVENPTkYgaGFzIGRlZmluZWQgaW4gUkZDIDgwNDA/IEZyb20gcmVh
ZGluZyB0aGUgUkZDIGl0IHNlZW1zIGlzIG91dCBvZiBzY29wZSBvZiBSRkMgODA0MCBidXQgaXMg
dGhpcyByZWFsbHkgaW50ZW5kZWQ/DQoNCiAgICAgICAgICAgICAgIEltcGxlbWVudGluZyBpZXRm
LW5ldGNvbmYueWFuZyBvZiBjb3Vyc2UgY291bGQgYmUgYW4gb3B0aW9uLg0KDQpJIGFncmVlIHRo
YXQgdGhpcyBpc24ndCByZWFsbHkgc3BlY2lmaWVkLg0KDQpJSVJDIG91ciBpbml0aWFsIGZvY3Vz
IHdhcyB0byBlZmZlY3RpdmVseSBnZXQgcGFyaXR5IHdpdGggUkZDIDgwNDAuICBJLmUuIG15IHdv
cmtpbmcgYXNzdW1wdGlvbiBpcyB0aGF0IDxjYW5kaWRhdGU+IChpZiBwcmVzZW50KSB3b3VsZCBi
ZSBoYW5kbGVkIGF1dG9tYXRpY2FsbHkgYW5kIHNpbWlsYXJseSB1cGRhdGVzIHRvIDxzdGFydHVw
PiB3b3VsZCBiZSBoYW5kbGVkIGF1dG9tYXRpY2FsbHkuICBFLmcuIGJyb2FkbHkgZXF1aXZhbGVu
dCB0byB0aGUgL2RhdGEgcmVzb3VyY2UgaW4gUkVTVENPTkYuICBTbyBpbiBlc3NlbmNlIHRoaXMg
Ym9pbHMgZG93biB0byBjbGllbnRzIGludGVyYWN0aW5nIHdpdGggL2RzL2lldGYtZGF0YXN0b3Jl
czpydW5uaW5nLCAvZHMvaWV0Zi1kYXRhc3RvcmVzOm9wZXJhdGlvbmFsIGFuZCAvZHMvaWV0Zi1k
YXRhc3RvcmVzOmludGVuZGVkLiAgTm8gbmV3IFJFU1RDT05GIG9wZXJhdGlvbnMgc2hvdWxkIGJl
IG5lY2Vzc2FyeSBoZXJlLg0KDQpJJ20gYWxzbyBub3QgcmVhbGx5IGNvbnZpbmNlZCB0aGF0IGlu
ZGVwZW5kZW50bHkgY29udHJvbGxhYmxlIDxzdGFydHVwPiBhbmQgPGNhbmRpZGF0ZT4gaXMgcmVh
bGx5IGEgZ3JlYXQgaWRlYS4NCg0KR2l2ZW4gdGhhdCA8cnVubmluZz4gaXMgbWVhbnQgdG8gcmVw
cmVzZW50IHBlcnNpc3RlbnQgY29uZmlndXJhdGlvbiwgdGhlbiBhdXRvbWF0aWNhbGx5IHVwZGF0
aW5nIDxzdGFydHVwPiBhcyBhIHNpZGUgZWZmZWN0IG9mIHVwZGF0aW5nIDxydW5uaW5nPiBzZWVt
cyBsaWtlIHRoZSBtb3N0IHNlbnNpYmxlIGJlaGF2aW9yLiAgSWYgdGhlIGRlc2lyZSBpcyBmb3Ig
c29tZSBlcGhlbWVyYWwgdHlwZSBjb25maWd1cmF0aW9uIHRoZW4gdGhhdCB3b3VsZCBiZSBiZXR0
ZXIgbW9kZWxlZCB2aWEgYW4gZXhwbGljaXQgZHluYW1pYyBjb25maWd1cmF0aW9uIGRhdGFzdG9y
ZSAoZS5nLiBhIGJpdCBsaWtlIHdoYXQgSTJSUyB3ZXJlIHRyeWluZyB0byBkbykuDQoNClNpbWls
YXJseSwgaW5zdGVhZCBvZiBhIHNoYXJlZCBjYW5kaWRhdGUgZGF0YXN0b3JlLCB0aGVyZSBpcyBz
b21lIHdvcmsgaW52ZXN0aWdhdGluZyBwcml2YXRlIGNhbmRpZGF0ZSBkYXRhc3RvcmVzLiAgZHJh
ZnQtbGhvdGthLW5ldGNvbmYtcmVzdGNvbmYtdHJhbnNhY3Rpb25zLTAwIGdpdmVzIHNvbWUgaWRl
YXMgb2Ygd2hhdCB0aGlzIGNvdWxkIGxvb2sgbGlrZSwgYnV0IGZ1cnRoZXIgd29yayBpcyByZXF1
aXJlZC4NCg0KSWYgdGhlcmUgaXMgYSBzdHJvbmcgcmVxdWlyZW1lbnQgdG8gYWxsb3cgZnVsbCBl
eHBsaWNpdCBtYW5pcHVsYXRpb24gb2YgY29uZmlndXJhdGlvbiBkYXRhc3RvcmVzIHRoZW4gSSB0
aGluayB0aGF0IHdlIHNob3VsZCBwcm9iYWJseSBkZWZpbmUgZXhwbGljaXQgUlBDcyBmb3IgdGhl
c2Ugb3BlcmF0aW9ucyAobW9kZWxlZCBvbiB0aGUgTkVUQ09ORiBvbmVzKS4gIElkZWFsbHksIHRo
ZXNlIGNvdWxkIGJlIGRlZmluZWQgaW4gYSBwcm90b2NvbCBuZXV0cmFsIGZvcm1hdCBzbyB0aGF0
IHRoZXkgY2FuIHdvcmsgd2l0aCBhbnkgWUFORyBiYXNlZCBtYW5hZ2VtZW50IHByb3RvY29scy4g
IEluIHRoZSBpbnRlcmltLCB1c2luZyB0aGUgTkVUQ09ORiBSUENzIGZyb20gUkVTVENPTkYgc2Vl
bXMgbGlrZSBhIHJlYXNvbmFibGUgc3RvcGdhcCBtZWFzdXJlLg0KDQpbTVNFRV06IEkgYWdyZWUs
IHRoaXMgd291bGQgYmUgaGVscGZ1bC4NCg0KQlINCk1hcmt1cw0KDQpUaGFua3MsDQpSb2INCg0K
DQoNCg0KDQpUaGFua3MsDQoNClJvYg0KDQoNCg0KDQoNCjMuICAgICAgIFR5cG8gaW4gaHR0cHM6
Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRm
Lm9yZ19wZGZfZHJhZnQtMkRpZXRmLTJEbmV0Y29uZi0yRG5tZGEtMkRyZXN0Y29uZi0yRDA1JmQ9
RHdJQkFnJmM9Qmc1WFVMRFpSOEdpT1NTV05scGtDc1JlUG5HRGtLY0k2b1lMOXh2MU1uUSZyPTJY
RUtWWWtRam1MSGkyVE9KcDFWU3ppZUxaVnFld0lwai1SeG1SZ1Bmc00mbT1DREsyOFg4a08yd1JW
RGxhOTdQX1dxQkloRjNPQXpiV1NHRW1UZUxkeHdVJnM9QlN5WS1HQnV6ekRyeTZvSWhnLW1nd01B
eVNiaEpFTzlJbTNaNFBEX2NfNCZlPSBDaGFwdGVyIDMuMSAidGhlIHNlcnZlciB3b3VsZCBpbXBs
ZW1lbnQgdGhlIHJlc291cmNlIHsrcmVzdGNvbmZ9L2RzL2V4YW1wbGUtIGRzLWVwaGVtZXJhbDpk
cy1lcGhlbWVyYWwuIg0KDQpUaGVyZSBpcyBhIHNwYWNlIGluIGJldHdlZW4gImV4YW1wbGUtIiBh
bmQgImRzLWVwaGVtZXJhbDpkcy1lcGhlbWVyYWwiLg0KDQpMZXRzIGhvcGUgd2UgZ2V0IHRoaXMg
Zml4ZWQgd2l0aCB0aGUgaGVscCBvZiB0aGUgUkZDIGVkaXRvci4NCg0KDQoNCi9qcw0KDQoNCg0K
LS0NCg0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBC
cmVtZW4gZ0dtYkgNCg0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmlu
ZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KDQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAg
ICAgICAgIDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt
M0FfX3d3dy5qYWNvYnMtMkR1bml2ZXJzaXR5LmRlXyZkPUR3SUJBZyZjPUJnNVhVTERaUjhHaU9T
U1dObHBrQ3NSZVBuR0RrS2NJNm9ZTDl4djFNblEmcj0yWEVLVllrUWptTEhpMlRPSnAxVlN6aWVM
WlZxZXdJcGotUnhtUmdQZnNNJm09Q0RLMjhYOGtPMndSVkRsYTk3UF9XcUJJaEYzT0F6YldTR0Vt
VGVMZHh3VSZzPXczOHNlV2k2Rk40OE9qUGZKbjkyLS1lbWkzckV6RWlEVEhzS0x4RW5zcmcmZT0+
PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3
LmphY29icy0yRHVuaXZlcnNpdHkuZGVfJmQ9RHdJQkFnJmM9Qmc1WFVMRFpSOEdpT1NTV05scGtD
c1JlUG5HRGtLY0k2b1lMOXh2MU1uUSZyPTJYRUtWWWtRam1MSGkyVE9KcDFWU3ppZUxaVnFld0lw
ai1SeG1SZ1Bmc00mbT1DREsyOFg4a08yd1JWRGxhOTdQX1dxQkloRjNPQXpiV1NHRW1UZUxkeHdV
JnM9dzM4c2VXaTZGTjQ4T2pQZkpuOTItLWVtaTNyRXpFaURUSHNLTHhFbnNyZyZlPT4NCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KbmV0bW9kIG1h
aWxpbmcgbGlzdA0KDQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCg0K
aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu
aWV0Zi5vcmdfbWFpbA0KDQptYW5fbGlzdGluZm9fbmV0bW9kJmQ9RHdJRGFRJmM9Qmc1WFVMRFpS
OEdpT1NTV05scGtDc1JlUG5HRGtLY0k2b1lMOXh2DQoNCjFNblEmcj0yWEVLVllrUWptTEhpMlRP
SnAxVlN6aWVMWlZxZXdJcGotUnhtUmdQZnNNJm09VHJQTVZYUTVJb3ZGbTA4QlMNCg0KYmJYYTJF
LUhuU09feXpIUnkwR1I5ZGpUMk0mcz1zZDExb25IQTQyT0RueXN6OVpPSVppa1dXUU1Ia0h3VVNl
TC1sTldjaw0KDQpERSZlPQ0KDQoNCg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KDQpESVNDTEFJTUVSOg0KDQpQ
cml2aWxlZ2VkIGFuZC9vciBDb25maWRlbnRpYWwgaW5mb3JtYXRpb24gbWF5IGJlIGNvbnRhaW5l
ZCBpbiB0aGlzIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBhZGRyZXNzZWUgb2YgdGhpcyBt
ZXNzYWdlLCB5b3UgbWF5IG5vdCBjb3B5LCB1c2Ugb3IgZGVsaXZlciB0aGlzIG1lc3NhZ2UgdG8g
YW55b25lLiBJbiBzdWNoIGV2ZW50LCB5b3Ugc2hvdWxkIGRlc3Ryb3kgdGhlIG1lc3NhZ2UgYW5k
IGtpbmRseSBub3RpZnkgdGhlIHNlbmRlciBieSByZXBseSBlLW1haWwuIEl0IGlzIHVuZGVyc3Rv
b2QgdGhhdCBvcGluaW9ucyBvciBjb25jbHVzaW9ucyB0aGF0IGRvIG5vdCByZWxhdGUgdG8gdGhl
IG9mZmljaWFsIGJ1c2luZXNzIG9mIHRoZSBjb21wYW55IGFyZSBuZWl0aGVyIGdpdmVuIG5vciBl
bmRvcnNlZCBieSB0aGUgY29tcGFueS4gVGhhbmsgWW91Lg0KCioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioKRElTQ0xB
SU1FUjoKUHJpdmlsZWdlZCBhbmQvb3IgQ29uZmlkZW50aWFsIGluZm9ybWF0aW9uIG1heSBiZSBj
b250YWluZWQgaW4gdGhpcyBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUgYWRkcmVzc2VlIG9m
IHRoaXMgbWVzc2FnZSwgeW91IG1heSBub3QgY29weSwgdXNlIG9yIGRlbGl2ZXIgdGhpcyBtZXNz
YWdlIHRvIGFueW9uZS4gSW4gc3VjaCBldmVudCwgeW91IHNob3VsZCBkZXN0cm95IHRoZSBtZXNz
YWdlIGFuZCBraW5kbHkgbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVwbHkgZS1tYWlsLiBJdCBpcyB1
bmRlcnN0b29kIHRoYXQgb3BpbmlvbnMgb3IgY29uY2x1c2lvbnMgdGhhdCBkbyBub3QgcmVsYXRl
IHRvIHRoZSBvZmZpY2lhbCBidXNpbmVzcyBvZiB0aGUgY29tcGFueSBhcmUgbmVpdGhlciBnaXZl
biBub3IgZW5kb3JzZWQgYnkgdGhlIGNvbXBhbnkuIFRoYW5rIFlvdS4K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbGlicmkgTGlnaHQiOw0KCXBhbm9z
ZS0xOjIgMTUgMyAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2Fs
aWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv
bnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8q
IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv
Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6
ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCgljb2xv
cjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp
dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln
aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN
Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp
ZiI7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t
c3R5bGUtbGluazoiSFRNTCBWb3Jmb3JtYXRpZXJ0IFpjaG4iOw0KCW1hcmdpbjowY207DQoJbWFy
Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv
dXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxWb3Jmb3JtYXRpZXJ0WmNobg0K
CXttc28tc3R5bGUtbmFtZToiSFRNTCBWb3Jmb3JtYXRpZXJ0IFpjaG4iOw0KCW1zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBWb3Jmb3JtYXRpZXJ0IjsNCglmb250
LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxh
Z2UyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs
aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7
bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX
b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAu
ODVwdCAyLjBjbSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv
bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MzEz
ODAyOTYzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot
Njg1MzQ2NzMwIC0yNTYxMTI5MTYgNjc1Njc2MTkgNjc1Njc2MjEgNjc1Njc2MTcgNjc1Njc2MTkg
Njc1Njc2MjEgNjc1Njc2MTcgNjc1Njc2MTkgNjc1Njc2MjE7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ
e21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2Fs
aWJyaTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m
YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z
by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv
LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K
CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl
dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6
bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u
OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci
O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt
aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u
ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw
dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt
c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu
dDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs
aXN0IGwxDQoJe21zby1saXN0LWlkOjY0OTAxNzI5NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsN
Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE5MzkxOTg3NzAgNjc1Njc2MzEgNjc1Njc2NDEgNjc1
Njc2NDMgNjc1Njc2MzEgNjc1Njc2NDEgNjc1Njc2NDMgNjc1Njc2MzEgNjc1Njc2NDEgNjc1Njc2
NDM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0
IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl
ci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl
dmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3Qg
bDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNQ0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t
YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w
b3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJ
e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwt
bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt
c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA
bGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ
bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo
dDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6Njc1MDM4
Nzc2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo4Mzk4
MjI2MzQgLTI1NjExMjkxNiA2NzU2NzYxOSA2NzU2NzYyMSA2NzU2NzYxNyA2NzU2NzYxOSA2NzU2
NzYyMSA2NzU2NzYxNyA2NzU2NzYxOSA2NzU2NzYyMTt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNv
LWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51
bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0Oi00My4ycHQ7DQoJdGV4dC1pbmRlbnQ6
LTE4LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJl
YXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt
c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVm
dDotNy4ycHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO
ZXciO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7
DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s
ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyOC44cHQ7DQoJdGV4dC1p
bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw0
DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7
DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCW1hcmdpbi1sZWZ0OjY0LjhwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQt
ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt
YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEwMC44cHQ7
DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs
aXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl
dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i
ZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxMzYuOHB0Ow0KCXRleHQtaW5kZW50Oi0x
OC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCglt
YXJnaW4tbGVmdDoxNzIuOHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6
U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs
ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjA4LjhwdDsNCgl0ZXh0
LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6
bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4
dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np
dGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI0NC44cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN
Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTQ4NTEx
OTU0MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6Mjg4
OTM4MTkyIC0xNzI0ODk1MDY0IDY3NTY3NjE5IDY3NTY3NjIxIDY3NTY3NjE3IDY3NTY3NjE5IDY3
NTY3NjIxIDY3NTY3NjE3IDY3NTY3NjE5IDY3NTY3NjIxO30NCkBsaXN0IGwzOmxldmVsMQ0KCXtt
c28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGli
cmk7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w
Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x
OC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZl
bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87
DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9
DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls
eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7
DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwzOmxldmVsOQ0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K
CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0K
CXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0
eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PCFb
ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iREUiIGxpbms9
ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE
O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IZWxsbyBSb2JlcnQsPC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF
MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPlZvbjo8
L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4g
Um9iZXJ0IFdpbHRvbiBbbWFpbHRvOnJ3aWx0b25AY2lzY28uY29tXQ0KPGJyPg0KPGI+R2VzZW5k
ZXQ6PC9iPiBNaXR0d29jaCwgMTIuIERlemVtYmVyIDIwMTggMTE6MjE8YnI+DQo8Yj5Bbjo8L2I+
IFNlZWhvZmVyLCBNYXJrdXM7IG5ldG1vZEBpZXRmLm9yZzxicj4NCjxiPkJldHJlZmY6PC9iPiBb
RVhURVJOQUxdIFJlOiBBVzogW25ldG1vZF0gUmU6IFF1ZXN0aW9uIG9uIFJGQzgzNDIgJiM0Mzsg
UkVTVENPTkYgZXh0ZW5zaW9uIChkcmFmdC1pZXRmLW5ldGNvbmYtbm1kYS1yZXN0Y29uZik8L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPGRpdj4NCjxwPjxiPiZuYnNwOzwvYj48L3A+DQo8L2Rpdj4NCjxwPkhpIE1h
cmt1cyw8L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTEvMTIvMjAxOCAxNzoy
MSwgU2VlaG9mZXIsIE1hcmt1cyB3cm90ZTo8L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5IZWxsbyBSb2Jl
cnQsPC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPmNvbW1lbnRzIGlu
bGluZSBiZWxvdy48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QlI8
L3ByZT4NCjxwcmU+IE1hcmt1cyA8L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N
CjxwcmU+LS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLTwvcHJlPg0KPHByZT5Wb246
IFJvYmVydCBXaWx0b24gWzxhIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbSI+bWFpbHRv
OnJ3aWx0b25AY2lzY28uY29tPC9hPl0gPC9wcmU+DQo8cHJlPkdlc2VuZGV0OiBEaWVuc3RhZywg
MTEuIERlemVtYmVyIDIwMTggMTc6MDY8L3ByZT4NCjxwcmU+QW46IFNlZWhvZmVyLCBNYXJrdXM8
L3ByZT4NCjxwcmU+Q2M6IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBp
ZXRmLm9yZzwvYT48L3ByZT4NCjxwcmU+QmV0cmVmZjogUmU6IFtuZXRtb2RdIFtFWFRFUk5BTF0g
UmU6IFF1ZXN0aW9uIG9uIFJGQzgzNDIgJiM0MzsgUkVTVENPTkYgZXh0ZW5zaW9uIChkcmFmdC1p
ZXRmLW5ldGNvbmYtbm1kYS1yZXN0Y29uZik8L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+SGkgU2VlaG9mZXIsPC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlPlBsZWFzZSBzZWUgaW5saW5lIC4uLjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZT5PbiAxMS8xMi8yMDE4IDE0OjU1LCBTZWVob2ZlciwgTWFya3VzIHdy
b3RlOjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv
dHRvbTo1LjBwdCI+DQo8cHJlPkhlbGxvIEp1ZXJnZW4sPC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8cHJlPnNlZSBteSBjb21tZW50cyBpbmxpbmUgYmVsb3cuIEFzIGJlaW5n
IHF1aXRlIG5ldyB0byB0aGUgdG9waWMsIGdvaW5nIHRocm91Z2ggYWxsIHRoZSBvbGQgYW5kIGN1
cnJlbnQgUkZDcyBhbmQgZHJhZnRzIGlzIHF1aXRlIGNoYWxsZW5naW5nLjwvcHJlPg0KPHByZT5T
byBwbGVhc2UgYXBvbG9naXplIGZvciAmcXVvdDtzaW1wbGUmcXVvdDsgcXVlc3Rpb25zIG9yIG9u
ZXMgbWF5YmUgYWxyZWFkeSByYWlzZWQuPC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlPi0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS08L3ByZT4NCjxwcmU+
Vm9uOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPC9wcmU+DQo8cHJlPls8YSBocmVmPSJtYWlsdG86
ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlIj5tYWlsdG86ai5zY2hvZW53YWVs
ZGVyQGphY29icy11bml2ZXJzaXR5LmRlPC9hPl08L3ByZT4NCjxwcmU+R2VzZW5kZXQ6IERpZW5z
dGFnLCAxMS4gRGV6ZW1iZXIgMjAxOCAxNTozMzwvcHJlPg0KPHByZT5BbjogU2VlaG9mZXIsIE1h
cmt1czwvcHJlPg0KPHByZT5DYzogPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0
bW9kQGlldGYub3JnPC9hPjwvcHJlPg0KPHByZT5CZXRyZWZmOiBbRVhURVJOQUxdIFJlOiBbbmV0
bW9kXSBRdWVzdGlvbiBvbiBSRkM4MzQyICYjNDM7IFJFU1RDT05GIDwvcHJlPg0KPHByZT5leHRl
bnNpb24gKGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJlc3Rjb25mKTwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5PbiBUdWUsIERlYyAxMSwgMjAxOCBhdCAwMjox
NzowN1BNICYjNDM7MDAwMCwgU2VlaG9mZXIsIE1hcmt1cyB3cm90ZTo8L3ByZT4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5I
ZWxsbyw8L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+UmVhZGluZyBS
RkMgODM0MiBhbG9uZyB3aXRoIGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJlc3Rjb25mLTA1IEkn
dmUgc29tZSBxdWVzdGlvbnMgb3IgY29tcHJlaGVuc2lvbiBwcm9ibGVtcyB3aXRoIHRoZSB0ZXh0
LjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv
bzpwPjwvcHJlPg0KPHByZT4xLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBS
RkMgODM0MiAoTk1EQSk8L3ByZT4NCjxwcmU+Q2hhcHRlciA1LjMuJm5ic3A7IFRoZSBPcGVyYXRp
b25hbCBTdGF0ZSBEYXRhc3RvcmUgKCZsdDtvcGVyYXRpb25hbCZndDspIHNheXM6PC9wcmU+DQo8
cHJlPiZxdW90O1RoZSBvcGVyYXRpb25hbCBzdGF0ZSBkYXRhc3RvcmUgKCZsdDtvcGVyYXRpb25h
bCZndDspIGlzIGEgcmVhZC1vbmx5IGRhdGFzdG9yZSAuLi4uJnF1b3Q7PC9wcmU+DQo8cHJlPkNo
YXB0ZXIgNi4yLiBJbnZvY2F0aW9uIG9mIEFjdGlvbnMgYW5kIFJQQ3Mgc2F5czo8L3ByZT4NCjxw
cmU+JnF1b3Q7QWN0aW9ucyBhcmUgYWx3YXlzIGludm9rZWQgaW4gdGhlIGNvbnRleHQgb2YgdGhl
IG9wZXJhdGlvbmFsIHN0YXRlIGRhdGFzdG9yZS4gVGhlIG5vZGUgZm9yIHdoaWNoIHRoZSBhY3Rp
b24gaXMgaW52b2tlZCBNVVNUIGV4aXN0IGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBkYXRhc3Rv
cmUuJnF1b3Q7PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkNoYXB0
ZXIgMy4xIGluIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91
cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfcGRmX2RyYWZ0LTJEaWV0Zi0yRG5ldGNvbmYt
MkRubWRhLTJEcmVzdGNvbmYtMkQwNSZhbXA7ZD1Ed0lCQWcmYW1wO2M9Qmc1WFVMRFpSOEdpT1NT
V05scGtDc1JlUG5HRGtLY0k2b1lMOXh2MU1uUSZhbXA7cj0yWEVLVllrUWptTEhpMlRPSnAxVlN6
aWVMWlZxZXdJcGotUnhtUmdQZnNNJmFtcDttPUNESzI4WDhrTzJ3UlZEbGE5N1BfV3FCSWhGM09B
emJXU0dFbVRlTGR4d1UmYW1wO3M9QlN5WS1HQnV6ekRyeTZvSWhnLW1nd01BeVNiaEpFTzlJbTNa
NFBEX2NfNCZhbXA7ZT0iPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/
dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfcGRmX2RyYWZ0LTJEaWV0Zi0yRG5ldGNvbmYtMkRu
bWRhLTJEcmVzdGNvbmYtMkQwNSZhbXA7ZD1Ed0lCQWcmYW1wO2M9Qmc1WFVMRFpSOEdpT1NTV05s
cGtDc1JlUG5HRGtLY0k2b1lMOXh2MU1uUSZhbXA7cj0yWEVLVllrUWptTEhpMlRPSnAxVlN6aWVM
WlZxZXdJcGotUnhtUmdQZnNNJmFtcDttPUNESzI4WDhrTzJ3UlZEbGE5N1BfV3FCSWhGM09BemJX
U0dFbVRlTGR4d1UmYW1wO3M9QlN5WS1HQnV6ekRyeTZvSWhnLW1nd01BeVNiaEpFTzlJbTNaNFBE
X2NfNCZhbXA7ZT08L2E+IHNheXM6PC9wcmU+DQo8cHJlPiZxdW90O1lBTkcgYWN0aW9ucyBjYW4g
b25seSBiZSBpbnZva2VkIGluIHsmIzQzO3Jlc3Rjb25mfS9kcy9pZXRmLWRhdGFzdG9yZXM6b3Bl
cmF0aW9uYWwuJnF1b3Q7PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl
PlF1ZXN0aW9uOiBIb3cgY2FuIG9uZSBpbnZva2UgYW4gYWN0aW9uIGluIGEgYXMgcmVhZC1vbmx5
IGRlZmluZWQgZGF0YXN0b3JlPyBPciBhbSBJIG1pc3Npbmcgc29tZXRoaW5nPzwvcHJlPg0KPC9i
bG9ja3F1b3RlPg0KPHByZT5XaHkgZG8geW91IGV4cGVjdCB0aGF0IGEgZGF0YXN0b3JlIGhhcyB0
byBiZSB3cml0YWJsZSBpbiBvcmRlciB0byA8L3ByZT4NCjxwcmU+aW52b2tlIGFuIGFjdGlvbj8g
UkZDIDc5NTAgaGFzIHRoZSBleGFtcGxlIG9mIGEgcGluZyBhY3Rpb24gdGllZCB0byBhbiA8L3By
ZT4NCjxwcmU+aW50ZXJmYWNlLiAoWW91IHBpbmcgYSByZW1vdGUgc3lzdGVtIGZyb20gdGhhdCBz
cGVjaWZpYyBpbnRlcmZhY2UuKSBJbiA8L3ByZT4NCjxwcmU+Z2VuZXJhbCwgYWN0aW9ucyBhcmUg
dW5kZXJzdG9vZCBhcyBiZWluZyB0aWVkIHRvIHJlYWwgcmVzb3VyY2VzIGFuZCA8L3ByZT4NCjxw
cmU+aGVuY2UgdG8gdGhlIG9wZXJhdGlvbmFsIGRhdGFzdG9yZS4gKEZvciBleGFtcGxlLCB5b3Ug
Y2FuJ3QgcGluZyBmcm9tIDwvcHJlPg0KPHByZT5hbiBpbnRlcmZhY2UgdGhhdCBpcyBjb25maWd1
cmVkIGJ1dCBub3QgcGh5c2ljYWxseSBwcmVzZW50Lik8L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8
L286cD48L3ByZT4NCjxwcmU+W01TRUVdOiBJIGRvIG5vdCBleHBlY3QgdGhhdCBhIGRhdGFzdG9y
ZSBoYXMgdG8gYmUgd3JpdGVhYmxlIHRvIGludm9rZSBhbiBhY3Rpb24sIGJ1dCBJIGRvIGV4cGVj
dCB0aGF0IGEgJnF1b3Q7cmVhZC1vbmx5JnF1b3Q7IGRhdGFzdG9yZSBpcyBub3Qgd3JpdGVhYmxl
IGFuZCBSRkMgODM0MiBzYXlzIGNsZWFybHkgb3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlIGlz
ICZxdW90O3JlYWQtb25seSZxdW90Oy48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxwcmU+UlBDcyBhbmQgYWN0aW9ucyBkb24ndCBtb2RpZnkgdGhl
IG9wZXJhdGlvbmFsIHN0YXRlIGRhdGFzdG9yZSBhcyBzdWNoLCBpbnN0ZWFkIHRoZXkgbW9kaWZ5
IHRoZSBwcm9wZXJ0aWVzIG9mIHRoZSB1bmRlcmx5aW5nIHN5c3RlbSwgYW5kIHRoZSBvcGVyYXRp
b25hbCBzdGF0ZSBkYXRhc3RvcmUgcHJvdmlkZXMgYSByZWFkLW9ubHkgdmlldyBvbnRvIHRoZSBz
dGF0ZSBvZiB0aGUgc3lzdGVtLiZuYnNwOyBTbyAmbHQ7b3BlcmF0aW9uYWwmZ3Q7IGlzIG9ubHkg
YmVpbmcgdXBkYXRlZCBhcyBhIHNpZGUgZWZmZWN0IG9mIHJlZmxlY3RpbmcgdGhlIGNoYW5nZXMg
dG8gdGhlIHVuZGVybHlpbmcgc3lzdGVtLjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwv
cHJlPg0KPHByZT5UaGlzIGNvbnRyYXN0cyB3aXRoIHdyaXRhYmxlIGNvbmZpZ3VyYXRpb24gZGF0
YXN0b3JlcyAoZS5nLiAmbHQ7Y2FuZGlkYXRlJmd0OyBvciAmbHQ7cnVubmluZyZndDspLCB3aGVy
ZSB0aGUgY2xpZW50IGNhbiBtb2RpZnkgdGhlIGNvbmZpZ3VyYXRpb24gaW4gdGhvc2UgZGF0YXN0
b3JlcyBkaXJlY3RseSB3aGljaCB3aWxsIHRoZW4gYXR0ZW1wdCB0byBjaGFuZ2UgdGhlIGJlaGF2
aW9yIG9mIHRoZSBzeXN0ZW0gYXMgdGhlIGNvbmZpZyBpcyBhcHBsaWVkLjwvcHJlPg0KPHByZT48
bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5bTVNFRV06IEkgYWdyZWUgYnV0IEknbSBzdGls
bCBzdHVjayB3aXRoIHRoZSBmb2xsb3dpbmcgdGV4dC48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IC0gZHJhZnQtaWV0Zi1uZXRjb25mLW5tZGEtcmVzdGNvbmYtMDUgc2F5
cyBpbiBDaGFwdGVyIDMuMTogJnF1b3Q7WUFORyBhY3Rpb25zIGNhbiBvbmx5IGJlIGludm9rZWQg
aW4geyYjNDM7cmVzdGNvbmZ9L2RzL2lldGYtZGF0YXN0b3JlczpvcGVyYXRpb25hbCZxdW90OyB3
aXRoPC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyAmcXVvdDtUaGUgcmVzb3VyY2UgeyYjNDM7cmVzdGNvbmZ9L2RzL2lldGYtZGF0YXN0b3Jl
czpvcGVyYXRpb25hbCByZWZlcnMgdG8gdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGRhdGFzdG9yZSZx
dW90OyBhbmQgJnF1b3Q7VGhlIG9wZXJhdGlvbmFsIHN0YXRlIGRhdGFzdG9yZSAoJmx0O29wZXJh
dGlvbmFsJmd0OykgaXMgYSByZWFkLW9ubHkgZGF0YXN0b3JlJnF1b3Q7PC9wcmU+DQo8cHJlPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIFJGQyA4MDQwIHNheXMgaW4gQ2hhcHRlciAzLjYg
JnF1b3Q7IE9wZXJhdGlvbiByZXNvdXJjZXMgcmVwcmVzZW50aW5nIFlBTkcgYWN0aW9ucyBhcmUg
bm90IGlkZW50aWZpZWQgaW4gdGhpcyBzdWJ0cmVlLCBzaW5jZSB0aGV5IGFyZSBpbnZva2VkIHVz
aW5nIGEgVVJJIHdpdGhpbiB0aGUgJ3smIzQzO3Jlc3Rjb25mfS9kYXRhJyBzdWJ0cmVlJnF1b3Q7
IGFuZDwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
JnF1b3Q7QW4gYWN0aW9uIGlzIGludm9rZWQgYXM6IFBPU1QgeyYjNDM7cmVzdGNvbmZ9L2RhdGEv
Jmx0O2RhdGEtcmVzb3VyY2UtaWRlbnRpZmllciZndDsvJmx0O2FjdGlvbiZndDsmcXVvdDs8L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IFNvIHdpdGhvdXQgTk1EQSBpdCB3YXMgY2xlYXIsIGludm9rZSBhbiBhY3Rpb24g
dXNpbmcgeyYjNDM7cmVzdGNvbmZ9L2RhdGF9LiBXaXRoIE5NREEgd2hhdCBpcyB0aGUgY29ycmVj
dCB3YXkgdG8gdHJpZ2dlciBhbiBhY3Rpb24gYXMgdGhlIGRyYWZ0IHNheXMgJnF1b3Q7WUFORyBh
Y3Rpb25zIGNhbiBvbmx5IGJlIGludm9rZWQgaW4geyYjNDM7cmVzdGNvbmZ9L2RzL2lldGYtZGF0
YXN0b3JlczpvcGVyYXRpb25hbCZxdW90Oz88L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwPlNvLCB5
b3UgaW52b2tlIGl0IG9uIHRoZSBlcXVpdmFsZW50IHBhdGggdXNpbmcgdGhlIG9wZXJhdGlvbmFs
IGRhdGFzdG9yZS48L3A+DQo8cD5FLmcuIHRvIHRha2UgdGhlIGV4YW1wbGUgZnJvbSBSRkMgODA0
MCAzLjYuMiwgdGhlIHJlcXVlc3QgcHJlIE5NREEgaXMgdGhpczogPC9wPg0KPHByZSBzdHlsZT0i
YnJlYWstYmVmb3JlOiBwYWdlO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDtmb250LXZh
cmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IDI7dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IDI7
LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3RleHQtZGVjb3JhdGlvbi1zdHlsZTogaW5p
dGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6IGluaXRpYWw7d29yZC1zcGFjaW5nOjBweCI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7UE9TVCAvcmVzdGNvbmYvZGF0YS9leGFt
cGxlLWFjdGlvbnM6aW50ZXJmYWNlcy9cPC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbnRlcmZhY2U9ZXRoMC9nZXQtbGFzdC1yZXNl
dC10aW1lIEhUVFAvMS4xPC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBIb3N0OiBleGFtcGxlLmNvbTwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgQWNjZXB0OiBhcHBsaWNhdGlvbi95YW5nLWRhdGEmIzQzO2pzb248L3ByZT4NCjxwPlRo
ZSBlcXVpdmFsZW50IHBhdGggb24gYSBOTURBIHNlcnZlciBpcyB0aGlzOiA8L3A+DQo8cHJlIHN0
eWxlPSJicmVhay1iZWZvcmU6IHBhZ2U7Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2Zv
bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogMjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93
czogMjstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7dGV4dC1kZWNvcmF0aW9uLXN0eWxl
OiBpbml0aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDt3b3JkLXNwYWNpbmc6MHB4
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtQT1NUIC9yZXN0Y29uZi9kcy9p
ZXRmLWRhdGFzdG9yZXM6b3BlcmF0aW9uYWwvXDwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZXhhbXBsZS1hY3Rpb25zOmludGVyZmFj
ZXMvXDwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgaW50ZXJmYWNlPWV0aDAvZ2V0LWxhc3QtcmVzZXQtdGltZSBIVFRQLzEuMTwvcHJl
Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSG9zdDogZXhhbXBsZS5jb208
L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO0FjY2VwdDogYXBwbGlj
YXRpb24veWFuZy1kYXRhJiM0Mztqc29uPC9wcmU+DQo8cD5JIHRoaW5rIHRoYXQgeW91ciBjb25j
ZXJuIG1pZ2h0IGJlOiB3aHkgaXMgaXQgcmlnaHQvT0sgdG8gaW52b2tlIGEgYWN0aW9uIG9uIHdo
YXQgaXMgZGVmaW5lZCBhcyBhIHJlYWQgb25seSBzdHJ1Y3R1cmU/PC9wPg0KPHA+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bTVNFRV06ICZu
YnNwO0V4YWN0bHkuIEJ5IGp1c3QgcmVhZGluZyAmcXVvdDtUaGUgb3BlcmF0aW9uYWwgc3RhdGUg
ZGF0YXN0b3JlICgmbHQ7b3BlcmF0aW9uYWwmZ3Q7KSBpcyBhIHJlYWQtb25seSBkYXRhc3RvcmUg
Li4uLiZxdW90OyBtYXkgYmUgY29uZnVzaW5nLiBJIHN0aWxsIHN0cnVnZ2xlIHdpdGggdGhlIHRl
eHQuPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgYW5zd2VyIHRvIHRo
aXMgaXMgdGhhdCB0aGUgYWN0aW9uIGlzbid0IGFjdGluZyBvbiAmbHQ7b3BlcmF0aW9uYWwmZ3Q7
LCBpdCBpcyBhY3Rpbmcgb24gdGhlIHVuZGVybHlpbmcgc3lzdGVtIGFuZCBoYXMgdGhlIHJlbWl0
IHRvIGNoYW5nZSBhbnkgb2YgdGhlIHN5c3RlbSBiZWhhdmlvci48L3NwYW4+PC9wPg0KPHA+PHNw
YW4gbGFuZz0iRU4tVVMiPkhvd2V2ZXIsIGJlZm9yZSB0aGUgYWN0aW9uIGNhbiBiZSBwcm9jZXNz
ZWQsIHRoZSBzeXN0ZW0gbXVzdCB2YWxpZGF0ZSB0aGF0IHRoZSBkYXRhIG5vZGUgdGhhdCBpdCBp
cyBhY3Rpbmcgb24gZXhpc3RzLCBhbmQgdGhlDQo8L3NwYW4+cGFyYW1ldGVycyBhcmUgdmFsaWQu
Jm5ic3A7IFRoaXMgdmFsaWRhdGlvbiBpcyBwZXJmb3JtZWQgYWdhaW5zdCB0aGUgc3lzdGVtcyBv
cGVyYXRpb25hbCBzdGF0ZSwgYW5kIGhlbmNlIGlzIHZhbGlkYXRlZCBhZ2FpbnN0ICZsdDtvcGVy
YXRpb25hbCZndDsuPC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5bTVNFRV06IEkgYWdyZWUsIHRoaXMgb2YgY291cnNlIG1ha2Vz
IHNlbnNlIGFzIG9ubHkgdGhlICZsdDtvcGVyYXRpb25hbCZndDsgZGF0YXN0b3JlIGhhcyB0aGUg
aW5mb3JtYXRpb25zIHdoaWNoIG5vZGVzIGFyZSBpbiB1c2UgYW5kIHRoZXJlZm9yZSBhcmUgYXZh
aWxhYmxlIGZvciB1c2FnZS48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkFnYWlu
LCBjb25zaWRlcmluZyB0aGUgZXhhbXBsZSBhYm92ZSwgaXQgd291bGRuJ3QgbWFrZSBzZW5zZSB0
byBnZXQgdGhlIGxhc3QgcmVzZXQgdGltZSBvZiBhbiBpbnRlcmZhY2UgdGhhdCBleGlzdGVkIGlu
IGNvbmZpZ3VyYXRpb24sIGFuZCBoZW5jZSB3YXMgcHJlc2VudCBpbiAmbHQ7cnVubmluZyZndDsv
Jmx0O2ludGVuZGVkJmd0OywgYnV0IHdhcyBub3QgaW4gJmx0O29wZXJhdGlvbmFsJmd0Oy48L3Nw
YW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5bTVNFRV06IFllcywgSSBhZ3JlZS48L3NwYW4+PC9wPg0KPHA+SW4gZnV0dXJl
IHdlIG1heSBuZWVkIGFjdGlvbnMgdGhhdCBhcmUgdmFsaWRhdGVkIGFnYWluc3Qgb3RoZXIgZGF0
YXN0b3JlcywgYnV0IHdoZW4gdGhlIGF1dGhvcnMgd2VyZSBkaXNjdXNzaW5nIHRoaXMgaXQgd2Fz
IHVuY2xlYXIgd2hldGhlciBwcm9wZXIgdXNlIGNhc2VzIGZvciBzdWNoIGFjdGlvbnMgZXhpc3Qs
IGFuZCBoZW5jZSB3ZSBkZWNpZGVkIHRoYXQgdGhpcyBjb3VsZCBiZSBkZWZlcnJlZCB0byBmdXR1
cmUgd29yaywgd2hpY2ggd291bGQNCiBwcmVzdW1hYmx5IGNvbWUgYWxvbmcgd2l0aCBhIGNvbmNy
ZXRlIHVzZSBjYXNlLjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+W01TRUVdOiBPSy48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFu
Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bTVNFRV06IEFs
b25nIHdpdGggdGhlIGFib3ZlIHF1ZXN0aW9ucyBhbmQgYW5zd2Vycy9zdGF0ZW1lbnRzICh0aGFu
a3MgZm9yIHRoaXMpIEkgcHJvYmFibHkgc3RpbGwgaGF2ZSBtb3JlIHF1ZXN0aW9ucyB0aGFuIGFu
c3dlcnMgZnJvbSByZWFkaW5nIHRoZSBSRkNzIGFuZCBkcmFmdHMuPC9zcGFuPjwvcD4NCjxwIHN0
eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBs
ZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu
b3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN
Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRyYWZ0IGRyYWZ0LWlldGYtbmV0Y29uZi1u
bWRhLXJlc3Rjb25mLTA1IHNheXM6PGJyPg0K4oCcQW4gTk1EQS1jb21wbGlhbnQgc2VydmVyIE1V
U1QgaW1wbGVtZW50IHsmIzQzO3Jlc3Rjb25mfS9kcy9pZXRmLWRhdGFzdG9yZXM6b3BlcmF0aW9u
YWwuJm5ic3A7IE90aGVyIGRhdGFzdG9yZSByZXNvdXJjZXMgTUFZIGJlIGltcGxlbWVudGVk4oCd
Ljxicj4NCkRvZXMgdGhpcyBtZWFuIGEgR0VUIHRvIHsmIzQzO3Jlc3Rjb25mfS9kYXRhfSAod2hp
Y2ggaXMgc3RpbGwgdmFsaWQpIHJldHVybnMgdGhlIHNhbWUgZGF0YSBhcyBhIEdFVCB0byB7JiM0
MztyZXN0Y29uZn0vZHMvaWV0Zi1kYXRhc3RvcmVzOm9wZXJhdGlvbmFsIGlmIGl0IGlzIE5NREEg
Y29tcGxpYW50Pzxicj4NCjxicj4NCjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6
MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lm
ICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxl
PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv
c3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5JZiBzdWNoIGEgTk1EQSBjb21wbGlhbnQgUkVTVENPTkYgc2VydmVyIGhh
cyBlLmcuIOKAnGV4YW1wbGUtanVrZWJveOKAnSBpbXBsZW1lbnRlZCwgYXJlIGJvdGggb2YgdGhl
IGZvbGxvd2luZyBzdGF0ZW1lbnRzIGNvcnJlY3Q/PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy
IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUEFUQ0gg
L3Jlc3Rjb25mL2RhdGEvZXhhbXBsZS1qdWtlYm94Omp1a2Vib3gvXDxicj4NCiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtsaWJyYXJ5L2FydGlzdD1Gb28l
MjBGaWdodGVycy9hbGJ1bT1XYXN0aW5nJTIwTGlnaHQgSFRUUC8xLjE8YnI+DQombmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgSG9zdDogZXhhbXBsZS5jb208YnI+DQombmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgSWYtTWF0Y2g6ICZxdW90O2I4Mzg5MjMzYTRjJnF1b3Q7PGJyPg0KJm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veWFuZy1kYXRhJiM0Mzt4bWw8
YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2FsYnVtIHhtbG5zPSZxdW90O2h0dHA6
Ly9leGFtcGxlLmNvbS9ucy9leGFtcGxlLWp1a2Vib3gmcXVvdDsmZ3Q7PGJyPg0KJm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZsdDt5ZWFyJmd0OzIwMTEmbHQ7L3llYXImZ3Q7PGJyPg0K
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsvYWxidW0mZ3Q7PC9zcGFuPjwvcD4NCjxwIHN0
eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YW5kPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj
b2xvcjojMUY0OTdEIj48YnI+DQo8YnI+DQpQQVRDSCAvcmVzdGNvbmYvZHMvaWV0Zi1kYXRhc3Rv
cmVzOm9wZXJhdGlvbmFsL2V4YW1wbGUtanVrZWJveDpqdWtlYm94L1w8YnI+DQombmJzcDsmbmJz
cDsgbGlicmFyeS9hcnRpc3Q9Rm9vJTIwRmlnaHRlcnMvYWxidW09V2FzdGluZyUyMExpZ2h0IEhU
VFAvMS4xPGJyPg0KSG9zdDogZXhhbXBsZS5jb208YnI+DQpJZi1NYXRjaDogJnF1b3Q7YjgzODky
MzNhNGMmcXVvdDs8YnI+DQpDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3lhbmctZGF0YSYjNDM7
eG1sPGJyPg0KJmx0O2FsYnVtIHhtbG5zPSZxdW90O2h0dHA6Ly9leGFtcGxlLmNvbS9ucy9leGFt
cGxlLWp1a2Vib3gmcXVvdDsmZ3Q7PGJyPg0KJmx0O3llYXImZ3Q7MjAxMSZsdDsveWVhciZndDs8
YnI+DQombHQ7L2FsYnVtJmd0Ozwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu
LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tJm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERyYWZ0IGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJl
c3Rjb25mLTA1IHNheXM6PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnCBZQU5HIGFjdGlvbnMgY2FuIG9ubHkgYmUgaW52b2tlZCBp
biB7JiM0MztyZXN0Y29uZn0vZHMvaWV0Zi1kYXRhc3RvcmVzOm9wZXJhdGlvbmFs4oCdPGJyPg0K
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElu
IHN1Y2ggYSBOTURBIGNvbXBsaWFudCBSRVNUQ09ORiBzZXJ2ZXIsIGlzIHsmIzQzO3Jlc3Rjb25m
fS9vcGVyYXRpb25zIChSRkM4MDQwIC0gMy42IE9wZXJhdGlvbiBSZXNvdXJjZSApc3RpbGwgdmFs
aWQ/IEJlY2F1c2UgdGhlIGFib3ZlIHN0YXRlbWVudCBzYXlzIOKAnOKApmNhbiBvbmx54oCm4oCd
IG9yIGRvZXMgb25lIGhhdmUgdG8gdXNlOjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBPU1QgeyYjNDM7cmVzdGNv
bmZ9L2RzL2lldGYtZGF0YXN0b3JlczpvcGVyYXRpb25hbCAvJmx0O29wZXJhdGlvbiZndDs8YnI+
DQphbmQ8YnI+DQpQT1NUIHsmIzQzO3Jlc3Rjb25mfS9kcy9pZXRmLWRhdGFzdG9yZXM6b3BlcmF0
aW9uYWwgLyZsdDtkYXRhLXJlc291cmNlLWlkZW50aWZpZXImZ3Q7LyZsdDthY3Rpb24mZ3Q7PGJy
Pg0Kb24gYSBOTURBIGNvbXBsaWFudCBzZXJ2ZXIgb25seT88L3NwYW4+PC9wPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxz
cGFuIGxhbmc9IkVOLVVTIj4yLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBU
aGUgTk1EQSBpcyBhIGh1Z2Ugc3RlcCBmb3J3YXJkIGZvciBOQyBhbmQgUkMsIHRoYW5rcyBmb3Ig
dGhhdC4gTk1EQSBpbiBjb21iaW5hdGlvbiB3aXRoIHRoZSBuZXcgUkVTVENPTkYgZXh0ZW5zaW9u
cyBsZXQgb25lIG5vdyA8L3NwYW4+c2VsZWN0IG9uZSBvZiB0aGUgbmFtZWQgZGF0YXN0b3Jlczwv
cHJlPg0KPHByZT5pbiBSRkMgODM0Mi4gUmVhZGluZyB0aGUgUkZDIGFuZCBkcmFmdCBJJ20gc3Rp
bGwgbWlzc2luZyAob3IgZXZlbiBtb3JlIG92ZXJsb29rIEkgZ3Vlc3MpIHRoZSBmb2xsb3dpbmcu
IFJGQyA4MDQwIENoYXB0ZXIgNC41IHNheXM6PC9wcmU+DQo8cHJlPiZxdW90O0EgUFVUIG9uIHRo
ZSBkYXRhc3RvcmUgcmVzb3VyY2UgaXMgdXNlZCB0byByZXBsYWNlIHRoZSBlbnRpcmUgPC9wcmU+
DQo8cHJlPmNvbnRlbnRzIG9mIHRoZSBkYXRhc3RvcmUuLi4mcXVvdDsuIFNvIGRvZXMgdGhpcyBt
ZWFuIG9uZSBjYW4gaGF2ZSB0aGUgc2FtZSBiZWhhdmlvciBhcyBpbiBORVRDT05GIHdoZXJlIHlv
dSBjYW4gY29weSB0aGUgJnF1b3Q7cnVubmluZyZxdW90OyBjb25maWcgdG8gJnF1b3Q7c3RhcnR1
cCZxdW90OyBvciAmcXVvdDtjYW5kaWRhdGUmcXVvdDsgY29uZmlnIHRvICZxdW90O3J1bm5pbmcm
cXVvdDsgaWYgYSBSRVNUQ09ORiBzZXJ2ZXIgd291bGQgc3VwcG9ydCB0aGVtPyBJcyB0aGVyZSBh
bnkgZXhhbXBsZSBob3cgdGhpcyB3b3VsZCBsb29rIGxpa2UgaWYgaXQgaXMgYWxsb3dlZD88L3By
ZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+QSBQVVQgZG9lcyBub3QgcmVhbGx5IGdldCB5b3UgdGhl
cmUsIHRvIGNvcHkgYSBkYXRhc3RvcmUgdG8gYW5vdGhlciB5b3Ugd2FudCBhbiBvcGVyYXRpb24g
b24gdGhlIHNlcnZlci48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+
W01TRUVdOiBFeGFjdGx5IHRoaXMgaXMgd2hhdCBJIHdhbnQuIE5FVENPTkYgc3BlY2lmaWVzIHRo
aXMgY2xlYXJseSBpbiB0aGUgUkZDcyB3aXRoICZsdDtjb3B5LWNvbmZpZyZndDsgYnV0IGhvdyBk
b2VzIG9uZSB0cmlnZ2VyIHRoaXMgd2l0aCBSRVNUQ09ORj8gSSBoYWQgdGhlIGhvcGUgd2l0aCBO
TURBICYjNDM7IFJFU1RDT05GIGV4dGVuc2lvbnMgdGhpcyB3b3VsZDwvcHJlPg0KPHByZT4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmUgcG9zc2libGUgdG9vLiBPciBkbyBJIHN0
aWxsIG1pc3Mgc29tZXRoaW5nPzwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT5JIHRoaW5rIHRoYXQgaXQgaXMgdGhlb3JldGljYWxseSBwb3Nz
aWJsZSB0byBpbnZva2UgdGhlIE5FVENPTkYgUlBDcyAoZS5nLiB0aGUgY29weS1jb25maWcgUlBD
IGRlZmluZWQgaW4gaWV0Zi1uZXRjb25mLnlhbmcsIFJGQyA2MjQxKSBmcm9tIFJFU1RDT05GIChl
LmcuIHNlY3Rpb24gMy42IG9mIFJGQyA4MDQwKS48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286
cD48L3ByZT4NCjxwcmU+V2hldGhlciB0aGlzIGlzIGFjdHVhbGx5IGEgZ29vZCB0aGluZyB0byBk
by9lbmNvdXJhZ2UgSSdtIG5vdCBzbyBzdXJlLjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw
PjwvcHJlPg0KPHByZT5bTVNFRV06IE9LLiBCdXQgd2hhdCBpcyB0aGUgcHJlZmVycmVkIHdheSBm
b3Igc29tZW9uZSBpbXBsZW1lbnRpbmcgUkVTVENPTkYgb24gYSBkZXZpY2Ugd2hvIHdvdWxkIGxp
a2UgdG8gaGF2ZSB0aGUgc3VwcG9ydCBvZiAmbHQ7Y2FuZGlkYXRlJmd0OywgJmx0O3N0YXJ0dXAm
Z3Q7LCAmbHQ7cnVubmluZyZndDsgYW5kIHRoZSBuZXcgb25lcyBkZWZpbmVkIGluIE5NREEuPC9w
cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBIb3cgZG9lcyBvbmUgY29weSB0
aGUgZGF0YSBmcm9tICZsdDtydW5uaW5nJmd0OyB0byBlLmcuICZsdDtzdGFydHVwJmd0OyB1c2lu
ZyB0aGUgbWVjaGFuaXNtcyBSRVNUQ09ORiBoYXMgZGVmaW5lZCBpbiBSRkMgODA0MD8gRnJvbSBy
ZWFkaW5nIHRoZSBSRkMgaXQgc2VlbXMgaXMgb3V0IG9mIHNjb3BlIG9mIFJGQyA4MDQwIGJ1dCBp
cyB0aGlzIHJlYWxseSBpbnRlbmRlZD8gPC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwO0ltcGxlbWVudGluZyBpZXRmLW5ldGNvbmYueWFuZyBvZiBjb3Vyc2UgY291
bGQgYmUgYW4gb3B0aW9uLjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHA+SSBhZ3JlZSB0aGF0IHRo
aXMgaXNuJ3QgcmVhbGx5IHNwZWNpZmllZC48L3A+DQo8cD5JSVJDIG91ciBpbml0aWFsIGZvY3Vz
IHdhcyB0byBlZmZlY3RpdmVseSBnZXQgcGFyaXR5IHdpdGggUkZDIDgwNDAuJm5ic3A7IEkuZS4g
bXkgd29ya2luZyBhc3N1bXB0aW9uIGlzIHRoYXQgJmx0O2NhbmRpZGF0ZSZndDsgKGlmIHByZXNl
bnQpIHdvdWxkIGJlIGhhbmRsZWQgYXV0b21hdGljYWxseSBhbmQgc2ltaWxhcmx5IHVwZGF0ZXMg
dG8gJmx0O3N0YXJ0dXAmZ3Q7IHdvdWxkIGJlIGhhbmRsZWQgYXV0b21hdGljYWxseS4mbmJzcDsg
RS5nLiBicm9hZGx5IGVxdWl2YWxlbnQgdG8NCiB0aGUgL2RhdGEgcmVzb3VyY2UgaW4gUkVTVENP
TkYuJm5ic3A7IFNvIGluIGVzc2VuY2UgdGhpcyBib2lscyBkb3duIHRvIGNsaWVudHMgaW50ZXJh
Y3Rpbmcgd2l0aCAvZHMvaWV0Zi1kYXRhc3RvcmVzOnJ1bm5pbmcsIC9kcy9pZXRmLWRhdGFzdG9y
ZXM6b3BlcmF0aW9uYWwgYW5kIC9kcy9pZXRmLWRhdGFzdG9yZXM6aW50ZW5kZWQuJm5ic3A7IE5v
IG5ldyBSRVNUQ09ORiBvcGVyYXRpb25zIHNob3VsZCBiZSBuZWNlc3NhcnkgaGVyZS48L3A+DQo8
cD5JJ20gYWxzbyBub3QgcmVhbGx5IGNvbnZpbmNlZCB0aGF0IGluZGVwZW5kZW50bHkgY29udHJv
bGxhYmxlICZsdDtzdGFydHVwJmd0OyBhbmQgJmx0O2NhbmRpZGF0ZSZndDsgaXMgcmVhbGx5IGEg
Z3JlYXQgaWRlYS48L3A+DQo8cD5HaXZlbiB0aGF0ICZsdDtydW5uaW5nJmd0OyBpcyBtZWFudCB0
byByZXByZXNlbnQgcGVyc2lzdGVudCBjb25maWd1cmF0aW9uLCB0aGVuIGF1dG9tYXRpY2FsbHkg
dXBkYXRpbmcgJmx0O3N0YXJ0dXAmZ3Q7IGFzIGEgc2lkZSBlZmZlY3Qgb2YgdXBkYXRpbmcgJmx0
O3J1bm5pbmcmZ3Q7IHNlZW1zIGxpa2UgdGhlIG1vc3Qgc2Vuc2libGUgYmVoYXZpb3IuJm5ic3A7
IElmIHRoZSBkZXNpcmUgaXMgZm9yIHNvbWUgZXBoZW1lcmFsIHR5cGUgY29uZmlndXJhdGlvbiB0
aGVuIHRoYXQgd291bGQNCiBiZSBiZXR0ZXIgbW9kZWxlZCB2aWEgYW4gZXhwbGljaXQgZHluYW1p
YyBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSAoZS5nLiBhIGJpdCBsaWtlIHdoYXQgSTJSUyB3ZXJl
IHRyeWluZyB0byBkbykuPC9wPg0KPHA+U2ltaWxhcmx5LCBpbnN0ZWFkIG9mIGEgc2hhcmVkIGNh
bmRpZGF0ZSBkYXRhc3RvcmUsIHRoZXJlIGlzIHNvbWUgd29yayBpbnZlc3RpZ2F0aW5nIHByaXZh
dGUgY2FuZGlkYXRlIGRhdGFzdG9yZXMuJm5ic3A7IGRyYWZ0LWxob3RrYS1uZXRjb25mLXJlc3Rj
b25mLXRyYW5zYWN0aW9ucy0wMCBnaXZlcyBzb21lIGlkZWFzIG9mIHdoYXQgdGhpcyBjb3VsZCBs
b29rIGxpa2UsIGJ1dCBmdXJ0aGVyIHdvcmsgaXMgcmVxdWlyZWQuPC9wPg0KPHA+SWYgdGhlcmUg
aXMgYSBzdHJvbmcgcmVxdWlyZW1lbnQgdG8gYWxsb3cgZnVsbCBleHBsaWNpdCBtYW5pcHVsYXRp
b24gb2YgY29uZmlndXJhdGlvbiBkYXRhc3RvcmVzIHRoZW4gSSB0aGluayB0aGF0IHdlIHNob3Vs
ZCBwcm9iYWJseSBkZWZpbmUgZXhwbGljaXQgUlBDcyBmb3IgdGhlc2Ugb3BlcmF0aW9ucyAobW9k
ZWxlZCBvbiB0aGUgTkVUQ09ORiBvbmVzKS4mbmJzcDsgSWRlYWxseSwgdGhlc2UgY291bGQgYmUg
ZGVmaW5lZCBpbiBhIHByb3RvY29sDQogbmV1dHJhbCBmb3JtYXQgc28gdGhhdCB0aGV5IGNhbiB3
b3JrIHdpdGggYW55IFlBTkcgYmFzZWQgbWFuYWdlbWVudCBwcm90b2NvbHMuJm5ic3A7IEluIHRo
ZSBpbnRlcmltLCB1c2luZyB0aGUgTkVUQ09ORiBSUENzIGZyb20gUkVTVENPTkYgc2VlbXMgbGlr
ZSBhIHJlYXNvbmFibGUgc3RvcGdhcCBtZWFzdXJlLjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W01TRUVdOiBJIGFncmVlLCB0
aGlzIHdvdWxkIGJlIGhlbHBmdWwuDQo8L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CUjxicj4NCk1hcmt1cyA8L3Nw
YW4+PC9wPg0KPHA+VGhhbmtzLDxicj4NClJvYjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rcyw8L3ByZT4NCjxw
cmU+Um9iPC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4m
bmJzcDs8L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4zLiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBUeXBvIGluIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv
bS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfcGRmX2RyYWZ0LTJEaWV0Zi0yRG5l
dGNvbmYtMkRubWRhLTJEcmVzdGNvbmYtMkQwNSZhbXA7ZD1Ed0lCQWcmYW1wO2M9Qmc1WFVMRFpS
OEdpT1NTV05scGtDc1JlUG5HRGtLY0k2b1lMOXh2MU1uUSZhbXA7cj0yWEVLVllrUWptTEhpMlRP
SnAxVlN6aWVMWlZxZXdJcGotUnhtUmdQZnNNJmFtcDttPUNESzI4WDhrTzJ3UlZEbGE5N1BfV3FC
SWhGM09BemJXU0dFbVRlTGR4d1UmYW1wO3M9QlN5WS1HQnV6ekRyeTZvSWhnLW1nd01BeVNiaEpF
TzlJbTNaNFBEX2NfNCZhbXA7ZT0iPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92
Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfcGRmX2RyYWZ0LTJEaWV0Zi0yRG5ldGNv
bmYtMkRubWRhLTJEcmVzdGNvbmYtMkQwNSZhbXA7ZD1Ed0lCQWcmYW1wO2M9Qmc1WFVMRFpSOEdp
T1NTV05scGtDc1JlUG5HRGtLY0k2b1lMOXh2MU1uUSZhbXA7cj0yWEVLVllrUWptTEhpMlRPSnAx
VlN6aWVMWlZxZXdJcGotUnhtUmdQZnNNJmFtcDttPUNESzI4WDhrTzJ3UlZEbGE5N1BfV3FCSWhG
M09BemJXU0dFbVRlTGR4d1UmYW1wO3M9QlN5WS1HQnV6ekRyeTZvSWhnLW1nd01BeVNiaEpFTzlJ
bTNaNFBEX2NfNCZhbXA7ZT08L2E+IENoYXB0ZXIgMy4xICZxdW90O3RoZSBzZXJ2ZXIgd291bGQg
aW1wbGVtZW50IHRoZSByZXNvdXJjZSB7JiM0MztyZXN0Y29uZn0vZHMvZXhhbXBsZS0gZHMtZXBo
ZW1lcmFsOmRzLWVwaGVtZXJhbC4mcXVvdDs8L3ByZT4NCjxwcmU+VGhlcmUgaXMgYSBzcGFjZSBp
biBiZXR3ZWVuICZxdW90O2V4YW1wbGUtJnF1b3Q7IGFuZCAmcXVvdDtkcy1lcGhlbWVyYWw6ZHMt
ZXBoZW1lcmFsJnF1b3Q7LjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5MZXRzIGhvcGUgd2Ug
Z2V0IHRoaXMgZml4ZWQgd2l0aCB0aGUgaGVscCBvZiB0aGUgUkZDIGVkaXRvci48L3ByZT4NCjxw
cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+L2pzPC9wcmU+DQo8cHJlPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wcmU+DQo8cHJlPi0tPC9wcmU+DQo8cHJlPkp1ZXJnZW4gU2Nob2Vud2FlbGRl
ciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkg8L3ByZT4NCjxwcmU+UGhvbmU6ICYj
NDM7NDkgNDIxIDIwMCAzNTg3Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55PC9wcmU+DQo8
cHJlPkZheDombmJzcDsmbmJzcDsgJiM0Mzs0OSA0MjEgMjAwIDMxMDMmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZl
bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuamFjb2JzLTJEdW5pdmVy
c2l0eS5kZV8mYW1wO2Q9RHdJQkFnJmFtcDtjPUJnNVhVTERaUjhHaU9TU1dObHBrQ3NSZVBuR0Rr
S2NJNm9ZTDl4djFNblEmYW1wO3I9MlhFS1ZZa1FqbUxIaTJUT0pwMVZTemllTFpWcWV3SXBqLVJ4
bVJnUGZzTSZhbXA7bT1DREsyOFg4a08yd1JWRGxhOTdQX1dxQkloRjNPQXpiV1NHRW1UZUxkeHdV
JmFtcDtzPXczOHNlV2k2Rk40OE9qUGZKbjkyLS1lbWkzckV6RWlEVEhzS0x4RW5zcmcmYW1wO2U9
Ij4mbHQ7aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB
X193d3cuamFjb2JzLTJEdW5pdmVyc2l0eS5kZV8mYW1wO2Q9RHdJQkFnJmFtcDtjPUJnNVhVTERa
UjhHaU9TU1dObHBrQ3NSZVBuR0RrS2NJNm9ZTDl4djFNblEmYW1wO3I9MlhFS1ZZa1FqbUxIaTJU
T0pwMVZTemllTFpWcWV3SXBqLVJ4bVJnUGZzTSZhbXA7bT1DREsyOFg4a08yd1JWRGxhOTdQX1dx
QkloRjNPQXpiV1NHRW1UZUxkeHdVJmFtcDtzPXczOHNlV2k2Rk40OE9qUGZKbjkyLS1lbWkzckV6
RWlEVEhzS0x4RW5zcmcmYW1wO2U9Jmd0OzwvYT48L3ByZT4NCjxwcmU+X19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3ByZT4NCjxwcmU+bmV0bW9kIG1haWxp
bmcgbGlzdDwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRt
b2RAaWV0Zi5vcmc8L2E+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5w
cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWwiPmh0dHBz
Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu
b3JnX21haWw8L2E+PC9wcmU+DQo8cHJlPm1hbl9saXN0aW5mb19uZXRtb2QmYW1wO2Q9RHdJRGFR
JmFtcDtjPUJnNVhVTERaUjhHaU9TU1dObHBrQ3NSZVBuR0RrS2NJNm9ZTDl4djwvcHJlPg0KPHBy
ZT4xTW5RJmFtcDtyPTJYRUtWWWtRam1MSGkyVE9KcDFWU3ppZUxaVnFld0lwai1SeG1SZ1Bmc00m
YW1wO209VHJQTVZYUTVJb3ZGbTA4QlM8L3ByZT4NCjxwcmU+YmJYYTJFLUhuU09feXpIUnkwR1I5
ZGpUMk0mYW1wO3M9c2QxMW9uSEE0Mk9EbnlzejlaT0laaWtXV1FNSGtId1VTZUwtbE5XY2s8L3By
ZT4NCjxwcmU+REUmYW1wO2U9PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wcmU+DQo8cHJlPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKio8L3ByZT4NCjxwcmU+RElTQ0xBSU1FUjo8
L3ByZT4NCjxwcmU+UHJpdmlsZWdlZCBhbmQvb3IgQ29uZmlkZW50aWFsIGluZm9ybWF0aW9uIG1h
eSBiZSBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUgYWRkcmVz
c2VlIG9mIHRoaXMgbWVzc2FnZSwgeW91IG1heSBub3QgY29weSwgdXNlIG9yIGRlbGl2ZXIgdGhp
cyBtZXNzYWdlIHRvIGFueW9uZS4gSW4gc3VjaCBldmVudCwgeW91IHNob3VsZCBkZXN0cm95IHRo
ZSBtZXNzYWdlIGFuZCBraW5kbHkgbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVwbHkgZS1tYWlsLiBJ
dCBpcyB1bmRlcnN0b29kIHRoYXQgb3BpbmlvbnMgb3IgY29uY2x1c2lvbnMgdGhhdCBkbyBub3Qg
cmVsYXRlIHRvIHRoZSBvZmZpY2lhbCBidXNpbmVzcyBvZiB0aGUgY29tcGFueSBhcmUgbmVpdGhl
ciBnaXZlbiBub3IgZW5kb3JzZWQgYnkgdGhlIGNvbXBhbnkuIFRoYW5rIFlvdS48L3ByZT4NCjwv
YmxvY2txdW90ZT4NCjwvZGl2Pg0KCjxIUj5ESVNDTEFJTUVSOjxCUj4KUHJpdmlsZWdlZCBhbmQv
b3IgQ29uZmlkZW50aWFsIGluZm9ybWF0aW9uIG1heSBiZSBjb250YWluZWQgaW4gdGhpcyBtZXNz
YWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUgYWRkcmVzc2VlIG9mIHRoaXMgbWVzc2FnZSwgeW91IG1h
eSBub3QgY29weSwgdXNlIG9yIGRlbGl2ZXIgdGhpcyBtZXNzYWdlIHRvIGFueW9uZS4gSW4gc3Vj
aCBldmVudCwgeW91IHNob3VsZCBkZXN0cm95IHRoZSBtZXNzYWdlIGFuZCBraW5kbHkgbm90aWZ5
IHRoZSBzZW5kZXIgYnkgcmVwbHkgZS1tYWlsLiBJdCBpcyB1bmRlcnN0b29kIHRoYXQgb3Bpbmlv
bnMgb3IgY29uY2x1c2lvbnMgdGhhdCBkbyBub3QgcmVsYXRlIHRvIHRoZSBvZmZpY2lhbCBidXNp
bmVzcyBvZiB0aGUgY29tcGFueSBhcmUgbmVpdGhlciBnaXZlbiBub3IgZW5kb3JzZWQgYnkgdGhl
IGNvbXBhbnkuIFRoYW5rIFlvdS48QlI+CjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_bebb6cfd66884c68bac3635d6b0832eaDCRIC1EXC03PAmcplocal_--


From nobody Wed Dec 12 06:52:53 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67A7F128C65 for ; Wed, 12 Dec 2018 06:52:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 HQCpuM4Kanrg for ; Wed, 12 Dec 2018 06:52:50 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA8B1288BD for ; Wed, 12 Dec 2018 06:52:50 -0800 (PST)
Received: from [10.147.40.248] (unknown [173.38.220.48]) by mail.tail-f.com (Postfix) with ESMTPSA id D26E61AE0351; Wed, 12 Dec 2018 15:52:48 +0100 (CET)
From: Jan Lindblad 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_EC7D00FA-0EA6-4679-89AA-F79359795BAE"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 12 Dec 2018 15:52:47 +0100
In-Reply-To: <87zhtan7bo.fsf@nic.cz>
Cc: netmod@ietf.org
To: Ladislav Lhotka 
References: <87zhtan7bo.fsf@nic.cz>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: Re: [netmod] datastore-specific constraints
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Dec 2018 14:52:53 -0000

--Apple-Mail=_EC7D00FA-0EA6-4679-89AA-F79359795BAE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Lada,

Maybe you could just skip the when and explain the behavior in the =
description? E.g.

leaf foo {
 ...
 description "Foo controls bla, bla.=20
  Any configured value will be ignored when auto-foo is true.";
}

Best Regards,
/jan

> On 12 Dec 2018, at 15:33, Ladislav Lhotka  wrote:
>=20
> Hi,
>=20
> in some cases, constraints expressed with "when" or "must" may only be
> intended for configuration datastores. A typical example is an
> auto-negotiable parameter:
>=20
> leaf auto-foo {
>  type boolean;
>  default true;
>  description "If true, parameter 'foo' will be auto-negotiated.";
> }
> leaf foo {
>  when "../auto-foo =3D 'false'";
>  ...
> }
>=20
> This means that if auto-foo is true, it is impossible to configure the
> foo parameter. However, even with auto-foo =3D true, it is desirable =
to
> see the auto-negotiated value in , so, ideally, the =
"when"
> constraint should not apply in .
>=20
> How can this logic be modelled under NMDA? Is an extra leaf
> "foo-operational" needed?
>=20
> Thanks, Lada
>=20
> --=20
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20


--Apple-Mail=_EC7D00FA-0EA6-4679-89AA-F79359795BAE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Lada,

Maybe=
 you could just skip the when and explain the behavior in the =
description? E.g.

leaf foo {
 ...
 description "Foo =
controls bla, bla. 
  Any configured value will be ignored =
when auto-foo is true.";
}





Best =
Regards,
/jan

On 12 Dec 2018, at 15:33, Ladislav Lhotka =
<lhotka@nic.cz> =
wrote:

Hi,

in some cases, constraints =
expressed with "when" or "must" may only be
intended for =
configuration datastores. A typical example is an
auto-negotiable parameter:

leaf =
auto-foo {
  type boolean;
 =
 default true;
  description "If true, parameter =
'foo' will be auto-negotiated.";
}
leaf foo =
{
  when "../auto-foo =3D 'false'";
 =
 ...
}

This means that =
if auto-foo is true, it is impossible to configure the
foo =
parameter. However, even with auto-foo =3D true, it is desirable to
see the auto-negotiated value in <operational>, so, =
ideally, the "when"
constraint should not apply in =
<operational>.

How can this logic be =
modelled under NMDA? Is an extra leaf
"foo-operational" =
needed?

Thanks, Lada

-- 
Ladislav Lhotka
Head, CZ.NIC =
Labs
PGP Key ID: 0xB8F92B08A9F76C67

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


=

--Apple-Mail=_EC7D00FA-0EA6-4679-89AA-F79359795BAE--


From nobody Wed Dec 12 07:10:25 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4F2127333 for ; Wed, 12 Dec 2018 07:10:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.948
X-Spam-Level: 
X-Spam-Status: No, score=-15.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqwpCxRZuI2k for ; Wed, 12 Dec 2018 07:10:19 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119AC127133 for ; Wed, 12 Dec 2018 07:10:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=60247; q=dns/txt; s=iport; t=1544627418; x=1545837018; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=t/vxEMetBj6ogGLOVMDVTQDPs6uS69ePlYbXoJaXCLU=; b=hpXI8P3l1Q7BxUmyFVICf4+zCUSZu7Zo/AKGqvlK/dGhD0eDfIs1ja5s vBnEvV1AnH0I4hmzXWbbH+aUh1JKiX5I73x0YuJ8aMzt9TNSpYH2Q6pu/ AX92WD36xU2AiEz+xTt/Bcrgvjo9EUj2awI5D0VmTTUHqwuqDE8bnuQgw U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAAqJBFc/xbLJq1hAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYENTYEPcBIng3uIGV+NEy18jUaJERS?= =?us-ascii?q?BZg0ihEoCgx40CQ0BAwEBAgEBAm0cDIU8AQEBAwEaAQgKQRAJAgkCEAggAQI?= =?us-ascii?q?EAwICGysRBgEMBgIBAYJSSwGBeQgPig2bUIEvH4UhhG8FixqBNIFAP4ERJ4F?= =?us-ascii?q?tSTWBQYFdBBiBMAEbAxcCBg8Rgj2CVwKJIAEYAQMJjDiKOVUJhklCgz+EZ4I?= =?us-ascii?q?gBhiBXE2ETYMDJocniSmBBYNvhDmGaYFGOIFWMxoIGxU7gmwJgiodgziKUz8?= =?us-ascii?q?DMAEBizYrgiABAQ?=
X-IronPort-AV: E=Sophos;i="5.56,344,1539648000"; d="scan'208,217";a="8811746"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2018 15:10:14 +0000
Received: from [10.63.23.68] (dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com [10.63.23.68]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id wBCFAEDE011792; Wed, 12 Dec 2018 15:10:14 GMT
To: "Seehofer, Markus" , "netmod@ietf.org" 
References:  <20181211143313.xouvshwdtakmkdz4@anna.jacobs.jacobs-university.de> <9d40f9ad4b494e67ba2808341dc82e4d@DCRIC1EXC03PA.mcp.local>  <532b30422c7a4e77972181c32eaa8ff8@DCRIC1EXC03PA.mcp.local> <3db5de24-5168-0065-be9e-94f0b57cf06f@cisco.com> 
From: Robert Wilton 
Message-ID: <552c4033-e46f-6f0d-470f-24bb590e5890@cisco.com>
Date: Wed, 12 Dec 2018 15:10:14 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------949434CD4F37A5C8F3B75038"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.68, dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: 
Subject: Re: [netmod] Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Dec 2018 15:10:24 -0000

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

Hi Markus,

On 12/12/2018 14:40, Seehofer, Markus wrote:
>
> Hello Robert,
>
> *Von:*Robert Wilton [mailto:rwilton@cisco.com]
> *Gesendet:* Mittwoch, 12. Dezember 2018 11:21
> *An:* Seehofer, Markus; netmod@ietf.org
> *Betreff:* [EXTERNAL] Re: AW: [netmod] Re: Question on RFC8342 + 
> RESTCONF extension (draft-ietf-netconf-nmda-restconf)
>
> **
>
> Hi Markus,
>
> On 11/12/2018 17:21, Seehofer, Markus wrote:
>
>     Hello Robert,
>
>     comments inline below.
>
>     BR
>
>       Markus
>
>     -----Ursprüngliche Nachricht-----
>
>     Von: Robert Wilton [mailto:rwilton@cisco.com]
>
>     Gesendet: Dienstag, 11. Dezember 2018 17:06
>
>     An: Seehofer, Markus
>
>     Cc:netmod@ietf.org  
>
>     Betreff: Re: [netmod] [EXTERNAL] Re: Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)
>
>     Hi Seehofer,
>
>     Please see inline ...
>
>     On 11/12/2018 14:55, Seehofer, Markus wrote:
>
>         Hello Juergen,
>
>         see my comments inline below. As being quite new to the topic, going through all the old and current RFCs and drafts is quite challenging.
>
>         So please apologize for "simple" questions or ones maybe already raised.
>
>         -----Ursprüngliche Nachricht-----
>
>         Von: Juergen Schoenwaelder
>
>         [mailto:j.schoenwaelder@jacobs-university.de]
>
>         Gesendet: Dienstag, 11. Dezember 2018 15:33
>
>         An: Seehofer, Markus
>
>         Cc:netmod@ietf.org  
>
>         Betreff: [EXTERNAL] Re: [netmod] Question on RFC8342 + RESTCONF
>
>         extension (draft-ietf-netconf-nmda-restconf)
>
>         On Tue, Dec 11, 2018 at 02:17:07PM +0000, Seehofer, Markus wrote:
>
>             Hello,
>
>             Reading RFC 8342 along with draft-ietf-netconf-nmda-restconf-05 I've some questions or comprehension problems with the text.
>
>             1.       RFC 8342 (NMDA)
>
>             Chapter 5.3.  The Operational State Datastore () says:
>
>             "The operational state datastore () is a read-only datastore ...."
>
>             Chapter 6.2. Invocation of Actions and RPCs says:
>
>             "Actions are always invoked in the context of the operational state datastore. The node for which the action is invoked MUST exist in the operational state datastore."
>
>             Chapter 3.1 inhttps://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_pdf_draft-2Dietf-2Dnetconf-2Dnmda-2Drestconf-2D05&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=BSyY-GBuzzDry6oIhg-mgwMAySbhJEO9Im3Z4PD_c_4&e=  says:
>
>             "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational."
>
>             Question: How can one invoke an action in a as read-only defined datastore? Or am I missing something?
>
>         Why do you expect that a datastore has to be writable in order to
>
>         invoke an action? RFC 7950 has the example of a ping action tied to an
>
>         interface. (You ping a remote system from that specific interface.) In
>
>         general, actions are understood as being tied to real resources and
>
>         hence to the operational datastore. (For example, you can't ping from
>
>         an interface that is configured but not physically present.)
>
>         [MSEE]: I do not expect that a datastore has to be writeable to invoke an action, but I do expect that a "read-only" datastore is not writeable and RFC 8342 says clearly operational state datastore is "read-only".
>
>     RPCs and actions don't modify the operational state datastore as such, instead they modify the properties of the underlying system, and the operational state datastore provides a read-only view onto the state of the system.  So  is only being updated as a side effect of reflecting the changes to the underlying system.
>
>     This contrasts with writable configuration datastores (e.g.  or ), where the client can modify the configuration in those datastores directly which will then attempt to change the behavior of the system as the config is applied.
>
>     [MSEE]: I agree but I'm still stuck with the following text.
>
>                     - draft-ietf-netconf-nmda-restconf-05 says in Chapter 3.1: "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational" with
>
>                        "The resource {+restconf}/ds/ietf-datastores:operational refers to the operational state datastore" and "The operational state datastore () is a read-only datastore"
>
>                     - RFC 8040 says in Chapter 3.6 " Operation resources representing YANG actions are not identified in this subtree, since they are invoked using a URI within the '{+restconf}/data' subtree" and
>
>                       "An action is invoked as: POST {+restconf}/data//"
>
>                     So without NMDA it was clear, invoke an action using {+restconf}/data}. With NMDA what is the correct way to trigger an action as the draft says "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational"?
>
> So, you invoke it on the equivalent path using the operational datastore.
>
> E.g. to take the example from RFC 8040 3.6.2, the request pre NMDA is 
> this:
>
>        POST /restconf/data/example-actions:interfaces/\
>           interface=eth0/get-last-reset-time HTTP/1.1
>        Host: example.com
>        Accept: application/yang-data+json
>
> The equivalent path on a NMDA server is this:
>
>        POST /restconf/ds/ietf-datastores:operational/\
>           example-actions:interfaces/\
>           interface=eth0/get-last-reset-time HTTP/1.1
>        Host: example.com
>        Accept: application/yang-data+json
>
> I think that your concern might be: why is it right/OK to invoke a 
> action on what is defined as a read only structure?
>
> [MSEE]:  Exactly. By just reading "The operational state datastore 
> () is a read-only datastore ...." may be confusing. I 
> still struggle with the text.
>
RW: I guess that you can think of  just being a view on to 
the underlying system state.  I.e. you are allowed to use an action to 
modify the underlying state which, as a side effect, updates 
 (because it always reflects the system state), but you 
cannot write to  as an attempt to update the underlying 
system state.


>
> The answer to this is that the action isn't acting on , 
> it is acting on the underlying system and has the remit to change any 
> of the system behavior.
>
> However, before the action can be processed, the system must validate 
> that the data node that it is acting on exists, and the parameters are 
> valid.  This validation is performed against the systems operational 
> state, and hence is validated against .
>
> [MSEE]: I agree, this of course makes sense as only the  
> datastore has the informations which nodes are in use and therefore 
> are available for usage.
>
> Again, considering the example above, it wouldn't make sense to get 
> the last reset time of an interface that existed in configuration, and 
> hence was present in /, but was not in .
>
> [MSEE]: Yes, I agree.
>
> In future we may need actions that are validated against other 
> datastores, but when the authors were discussing this it was unclear 
> whether proper use cases for such actions exist, and hence we decided 
> that this could be deferred to future work, which would presumably 
> come along with a concrete use case.
>
> [MSEE]: OK.
>
> [MSEE]: Along with the above questions and answers/statements (thanks 
> for this) I probably still have more questions than answers from 
> reading the RFCs and drafts.
>
> -Draft draft-ietf-netconf-nmda-restconf-05 says:
> “An NMDA-compliant server MUST implement 
> {+restconf}/ds/ietf-datastores:operational.  Other datastore resources 
> MAY be implemented”.
> Does this mean a GET to {+restconf}/data} (which is still valid) 
> returns the same data as a GET to 
> {+restconf}/ds/ietf-datastores:operational if it is NMDA compliant?
>
RW: The definition of {+restconf}/data} has not changed in any way.  So, 
the contents/behavior of {+restconf}/data} should match what is 
specified by RFC 8040.

But this is tricky (because /data mixes intended configuration with 
operational state).

Hence, I wouldn't be surprised if some implementations either:
(1) don't implement /data at all, or
(2) handle DELETE/POST/PATCH/PUT operations as if the operation was made 
against {+restconf}/ds/ietf-datastores:running, handle GET requests as 
if they the operation was made against on 
{+restconf}/ds/ietf-datastores:operational.  This would be non-standard 
behavior though ....

A future version of RESTCONF, as opposed to an extension (i.e. 
draft-ietf-netconf-nmda-restconf-05), may remove support for 
{+restconf}/data}.


>
> -If such a NMDA compliant RESTCONF server has e.g. “example-jukebox” 
> implemented, are both of the following statements correct?
>
>      PATCH /restconf/data/example-jukebox:jukebox/\
>          library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
>      Host: example.com
>      If-Match: "b8389233a4c"
>      Content-Type: application/yang-data+xml
>      
>       2011
>      
>
> and
>
> PATCH /restconf/ds/ietf-datastores:operational/example-jukebox:jukebox/\
>    library/artist=Foo%20Fighters/album=Wasting%20Light HTTP/1.1
> Host: example.com
> If-Match: "b8389233a4c"
> Content-Type: application/yang-data+xml
> 
> 2011
> 
>
>         -        Draft draft-ietf-netconf-nmda-restconf-05 says:
>                   “ YANG actions can only be invoked in
>         {+restconf}/ds/ietf-datastores:operational”
>                   In such a NMDA compliant RESTCONF server, is
>         {+restconf}/operations (RFC8040 - 3.6 Operation Resource
>         )still valid? Because the above statement says “…can only…” or
>         does one have to use:
>
RW:

No, you can't PATCH against .  PATCH is not a YANG action, 
it is a RESTCONF method.

It is covered by draft-ietf-netconf-nmda-restconf-05, section 3.2:

    o  Some datastores are read-only by nature (e.g., ), and
       hence any attempt to modify these datastores will fail.  A server
       MUST return a response with a "405 Method Not Allowed" status-line
       and error-tag value "operation-not-supported".


>         POST {+restconf}/ds/ietf-datastores:operational /
>         and
>         POST {+restconf}/ds/ietf-datastores:operational
>         //
>         on a NMDA compliant server only?
>
You can only POST against editable configuration datastores, e.g. 
, ,, and only then if the server allows this.

Thanks,
Rob


>             2.       The NMDA is a huge step forward for NC and RC,
>             thanks for that. NMDA in combination with the new RESTCONF
>             extensions let one now select one of the named datastores
>
>             in RFC 8342. Reading the RFC and draft I'm still missing (or even more overlook I guess) the following. RFC 8040 Chapter 4.5 says:
>
>             "A PUT on the datastore resource is used to replace the entire
>
>             contents of the datastore...". So does this mean one can have the same behavior as in NETCONF where you can copy the "running" config to "startup" or "candidate" config to "running" if a RESTCONF server would support them? Is there any example how this would look like if it is allowed?
>
>         A PUT does not really get you there, to copy a datastore to another you want an operation on the server.
>
>         [MSEE]: Exactly this is what I want. NETCONF specifies this clearly in the RFCs with  but how does one trigger this with RESTCONF? I had the hope with NMDA + RESTCONF extensions this would
>
>                          be possible too. Or do I still miss something?
>
>     I think that it is theoretically possible to invoke the NETCONF RPCs (e.g. the copy-config RPC defined in ietf-netconf.yang, RFC 6241) from RESTCONF (e.g. section 3.6 of RFC 8040).
>
>     Whether this is actually a good thing to do/encourage I'm not so sure.
>
>     [MSEE]: OK. But what is the preferred way for someone implementing RESTCONF on a device who would like to have the support of , ,  and the new ones defined in NMDA.
>
>                     How does one copy the data from  to e.g.  using the mechanisms RESTCONF has defined in RFC 8040? From reading the RFC it seems is out of scope of RFC 8040 but is this really intended?
>
>                     Implementing ietf-netconf.yang of course could be an option.
>
> I agree that this isn't really specified.
>
> IIRC our initial focus was to effectively get parity with RFC 8040.  
> I.e. my working assumption is that  (if present) would be 
> handled automatically and similarly updates to  would be 
> handled automatically. E.g. broadly equivalent to the /data resource 
> in RESTCONF.  So in essence this boils down to clients interacting 
> with /ds/ietf-datastores:running, /ds/ietf-datastores:operational and 
> /ds/ietf-datastores:intended.  No new RESTCONF operations should be 
> necessary here.
>
> I'm also not really convinced that independently controllable 
>  and  is really a great idea.
>
> Given that  is meant to represent persistent configuration, 
> then automatically updating  as a side effect of updating 
>  seems like the most sensible behavior.  If the desire is for 
> some ephemeral type configuration then that would be better modeled 
> via an explicit dynamic configuration datastore (e.g. a bit like what 
> I2RS were trying to do).
>
> Similarly, instead of a shared candidate datastore, there is some work 
> investigating private candidate datastores. 
> draft-lhotka-netconf-restconf-transactions-00 gives some ideas of what 
> this could look like, but further work is required.
>
> If there is a strong requirement to allow full explicit manipulation 
> of configuration datastores then I think that we should probably 
> define explicit RPCs for these operations (modeled on the NETCONF 
> ones).  Ideally, these could be defined in a protocol neutral format 
> so that they can work with any YANG based management protocols.  In 
> the interim, using the NETCONF RPCs from RESTCONF seems like a 
> reasonable stopgap measure.
>
> [MSEE]: I agree, this would be helpful.
>
> BR
> Markus
>
> Thanks,
> Rob
>
>     Thanks,
>
>     Rob
>
>             3.       Typo inhttps://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_pdf_draft-2Dietf-2Dnetconf-2Dnmda-2Drestconf-2D05&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=BSyY-GBuzzDry6oIhg-mgwMAySbhJEO9Im3Z4PD_c_4&e=  Chapter 3.1 "the server would implement the resource {+restconf}/ds/example- ds-ephemeral:ds-ephemeral."
>
>             There is a space in between "example-" and "ds-ephemeral:ds-ephemeral".
>
>         Lets hope we get this fixed with the help of the RFC editor.
>
>         /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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
>
>         man_listinfo_netmod&d=DwIDaQ&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv
>
>         1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=TrPMVXQ5IovFm08BS
>
>         bbXa2E-HnSO_yzHRy0GR9djT2M&s=sd11onHA42ODnysz9ZOIZikWWQMHkHwUSeL-lNWck
>
>         DE&e=
>
>     **********************************************************************
>
>     DISCLAIMER:
>
>     Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
>
> ------------------------------------------------------------------------
> DISCLAIMER:
> Privileged and/or Confidential information may be contained in this 
> message. If you are not the addressee of this message, you may not 
> copy, use or deliver this message to anyone. In such event, you should 
> destroy the message and kindly notify the sender by reply e-mail. It 
> is understood that opinions or conclusions that do not relate to the 
> official business of the company are neither given nor endorsed by the 
> company. Thank You.

--------------949434CD4F37A5C8F3B75038
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Markus,

    

    
On 12/12/2018 14:40, Seehofer, Markus
      wrote:

    

    

      
      
      
      

        
Hello
            Robert,

        
 

        

          

            
Von:
                Robert Wilton [mailto:rwilton@cisco.com]
                

                Gesendet: Mittwoch, 12. Dezember 2018 11:21

                An: Seehofer, Markus; netmod@ietf.org

                Betreff: [EXTERNAL] Re: AW: [netmod] Re: Question
                on RFC8342 + RESTCONF extension
                (draft-ietf-netconf-nmda-restconf)

          

        

        
 

        

          
 

        

        
Hi Markus,

        

          
On 11/12/2018 17:21, Seehofer, Markus
            wrote:

        

        

          
Hello Robert,

          
 

          
comments inline below.

          
 

          
BR

          
 Markus 

          
 

          
-----Ursprüngliche Nachricht-----

          
Von: Robert Wilton [mailto:rwilton@cisco.com] 

          
Gesendet: Dienstag, 11. Dezember 2018 17:06

          
An: Seehofer, Markus

          
Cc: netmod@ietf.org

          
Betreff: Re: [netmod] [EXTERNAL] Re: Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)

          
 

          
Hi Seehofer,

          
 

          
Please see inline ...

          
 

          
On 11/12/2018 14:55, Seehofer, Markus wrote:

          

            
Hello Juergen,

            
 

            
see my comments inline below. As being quite new to the topic, going through all the old and current RFCs and drafts is quite challenging.

            
So please apologize for "simple" questions or ones maybe already raised.

            
 

            
-----Ursprüngliche Nachricht-----

            
Von: Juergen Schoenwaelder 

            
[mailto:j.schoenwaelder@jacobs-university.de]

            
Gesendet: Dienstag, 11. Dezember 2018 15:33

            
An: Seehofer, Markus

            
Cc: netmod@ietf.org

            
Betreff: [EXTERNAL] Re: [netmod] Question on RFC8342 + RESTCONF 

            
extension (draft-ietf-netconf-nmda-restconf)

            
 

            
 

            
 

            
On Tue, Dec 11, 2018 at 02:17:07PM +0000, Seehofer, Markus wrote:

            

              
Hello,

              
 

              
Reading RFC 8342 along with draft-ietf-netconf-nmda-restconf-05 I've some questions or comprehension problems with the text.

              
 

              
 

              
1.       RFC 8342 (NMDA)

              
Chapter 5.3.  The Operational State Datastore (<operational>) says:

              
"The operational state datastore (<operational>) is a read-only datastore ...."

              
Chapter 6.2. Invocation of Actions and RPCs says:

              
"Actions are always invoked in the context of the operational state datastore. The node for which the action is invoked MUST exist in the operational state datastore."

              
 

              
Chapter 3.1 in https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_pdf_draft-2Dietf-2Dnetconf-2Dnmda-2Drestconf-2D05&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=BSyY-GBuzzDry6oIhg-mgwMAySbhJEO9Im3Z4PD_c_4&e= says:

              
"YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational."

              
 

              
Question: How can one invoke an action in a as read-only defined datastore? Or am I missing something?

            

            
Why do you expect that a datastore has to be writable in order to 

            
invoke an action? RFC 7950 has the example of a ping action tied to an 

            
interface. (You ping a remote system from that specific interface.) In 

            
general, actions are understood as being tied to real resources and 

            
hence to the operational datastore. (For example, you can't ping from 

            
an interface that is configured but not physically present.)

            
 

            
[MSEE]: I do not expect that a datastore has to be writeable to invoke an action, but I do expect that a "read-only" datastore is not writeable and RFC 8342 says clearly operational state datastore is "read-only".

          

          
 

          
RPCs and actions don't modify the operational state datastore as such, instead they modify the properties of the underlying system, and the operational state datastore provides a read-only view onto the state of the system.  So <operational> is only being updated as a side effect of reflecting the changes to the underlying system.

          
 

          
This contrasts with writable configuration datastores (e.g. <candidate> or <running>), where the client can modify the configuration in those datastores directly which will then attempt to change the behavior of the system as the config is applied.

          
 

          
[MSEE]: I agree but I'm still stuck with the following text.

          
               - draft-ietf-netconf-nmda-restconf-05 says in Chapter 3.1: "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational" with

          
                  "The resource {+restconf}/ds/ietf-datastores:operational refers to the operational state datastore" and "The operational state datastore (<operational>) is a read-only datastore"

          
               - RFC 8040 says in Chapter 3.6 " Operation resources representing YANG actions are not identified in this subtree, since they are invoked using a URI within the '{+restconf}/data' subtree" and

          
                 "An action is invoked as: POST {+restconf}/data/<data-resource-identifier>/<action>"

          
 

          
               So without NMDA it was clear, invoke an action using {+restconf}/data}. With NMDA what is the correct way to trigger an action as the draft says "YANG actions can only be invoked in {+restconf}/ds/ietf-datastores:operational"?

        

        
So, you invoke it on the equivalent path using the
          operational datastore.

        
E.g. to take the example from RFC 8040 3.6.2, the request pre
          NMDA is this: 

        
      POST /restconf/data/example-actions:interfaces/\

        
         interface=eth0/get-last-reset-time HTTP/1.1

        
      Host: example.com

        
      Accept: application/yang-data+json

        
The equivalent path on a NMDA server is this: 

        
      POST /restconf/ds/ietf-datastores:operational/\

        
         example-actions:interfaces/\

        
         interface=eth0/get-last-reset-time HTTP/1.1

        
      Host: example.com

        
      Accept: application/yang-data+json

        
I think that your concern might be: why is it right/OK to
          invoke a action on what is defined as a read only structure?

        
[MSEE]:  Exactly. By just reading "The
            operational state datastore (<operational>) is a
            read-only datastore ...." may be confusing. I still struggle
            with the text.

          

      

    

    
RW: I guess that you can think of <operational> just being
      a view on to the underlying system state.  I.e. you are allowed to
      use an action to modify the underlying state which, as a side
      effect, updates <operational> (because it always reflects
      the system state), but you cannot write to <operational> as
      an attempt to update the underlying system state.

    


    

    

      

        

            

          The answer to this is that the
            action isn't acting on <operational>, it is acting on
            the underlying system and has the remit to change any of the
            system behavior.

        
However, before the action can be
            processed, the system must validate that the data node that
            it is acting on exists, and the
          parameters are valid.  This validation is performed
          against the systems operational state, and hence is validated
          against <operational>.

        
[MSEE]: I agree, this of course makes sense as
            only the <operational> datastore has the informations
            which nodes are in use and therefore are available for
            usage.

        
Again, considering the example above, it
            wouldn't make sense to get the last reset time of an
            interface that existed in configuration, and hence was
            present in <running>/<intended>, but was not in
            <operational>.

        
[MSEE]: Yes, I agree.

        
In future we may need actions that are validated against
          other datastores, but when the authors were discussing this it
          was unclear whether proper use cases for such actions exist,
          and hence we decided that this could be deferred to future
          work, which would presumably come along with a concrete use
          case.

        
[MSEE]: OK.

        
[MSEE]: Along with the above questions and
            answers/statements (thanks for this) I probably still have
            more questions than answers from reading the RFCs and
            drafts.

        
-         
              Draft draft-ietf-netconf-nmda-restconf-05 says:

            “An NMDA-compliant server MUST implement
            {+restconf}/ds/ietf-datastores:operational.  Other datastore
            resources MAY be implemented”.

            Does this mean a GET to {+restconf}/data} (which is still
            valid) returns the same data as a GET to
            {+restconf}/ds/ietf-datastores:operational if it is NMDA
            compliant?

          

      

    

    
RW: The definition of {+restconf}/data} has not changed in any
      way.  So, the contents/behavior of {+restconf}/data} should match
      what is specified by RFC 8040.

    
But this is tricky (because /data mixes intended configuration
      with operational state).

    
Hence, I wouldn't be surprised if some implementations either:

      (1) don't implement /data at all, or

      (2) handle DELETE/POST/PATCH/PUT operations as if the operation
      was made against {+restconf}/ds/ietf-datastores:running, handle
      GET requests as if they the operation was made against on
      {+restconf}/ds/ietf-datastores:operational.  This would be
      non-standard behavior though ....

    

    
A future version of RESTCONF, as opposed to an extension (i.e.
      draft-ietf-netconf-nmda-restconf-05), may remove support for
      {+restconf}/data}.

    

    


    

    

      

        

            

          

        
-         
              If such a NMDA compliant RESTCONF server has
            e.g. “example-jukebox” implemented, are both of the
            following statements correct?

        
     PATCH
            /restconf/data/example-jukebox:jukebox/\

                     library/artist=Foo%20Fighters/album=Wasting%20Light
            HTTP/1.1

                 Host: example.com

                 If-Match: "b8389233a4c"

                 Content-Type: application/yang-data+xml

                 <album
            xmlns="http://example.com/ns/example-jukebox">

                  <year>2011</year>

                 </album>

        
and

            

            PATCH
            /restconf/ds/ietf-datastores:operational/example-jukebox:jukebox/\

               library/artist=Foo%20Fighters/album=Wasting%20Light
            HTTP/1.1

            Host: example.com

            If-Match: "b8389233a4c"

            Content-Type: application/yang-data+xml

            <album xmlns="http://example.com/ns/example-jukebox">

            <year>2011</year>

            </album>

        

          

            
-        Draft
                draft-ietf-netconf-nmda-restconf-05 says:

                          “ YANG actions can only be invoked in
                {+restconf}/ds/ietf-datastores:operational”

                          In such a NMDA compliant RESTCONF server, is
                {+restconf}/operations (RFC8040 - 3.6 Operation Resource
                )still valid? Because the above statement says “…can
                only…” or does one have to use:

          

        

      

    

    
RW:

    
No, you can't PATCH against <operational>.  PATCH is not a
      YANG action, it is a RESTCONF method.

    
It is covered by draft-ietf-netconf-nmda-restconf-05, section
      3.2:

    

    
   o  Some datastores are read-only by nature (e.g., <intended>), and
      hence any attempt to modify these datastores will fail.  A server
      MUST return a response with a "405 Method Not Allowed" status-line
      and error-tag value "operation-not-supported".

    


    

    

      

        

          

            
POST
                {+restconf}/ds/ietf-datastores:operational
                /<operation>

                and

                POST {+restconf}/ds/ietf-datastores:operational
                /<data-resource-identifier>/<action>

                on a NMDA compliant server only?

          

        

      

    

    
You can only POST against editable configuration datastores, e.g.
      <candidate>, <running>,<startup>, and only then
      if the server allows this.

    

    
Thanks,

      Rob

    

    


    

    

      

        

          

            

              
2.       The NMDA is a huge step forward for NC and RC, thanks for that. NMDA in combination with the new RESTCONF extensions let one now select one of the named datastores

              
in RFC 8342. Reading the RFC and draft I'm still missing (or even more overlook I guess) the following. RFC 8040 Chapter 4.5 says:

              
"A PUT on the datastore resource is used to replace the entire 

              
contents of the datastore...". So does this mean one can have the same behavior as in NETCONF where you can copy the "running" config to "startup" or "candidate" config to "running" if a RESTCONF server would support them? Is there any example how this would look like if it is allowed?

            

            
A PUT does not really get you there, to copy a datastore to another you want an operation on the server.

            
 

            
[MSEE]: Exactly this is what I want. NETCONF specifies this clearly in the RFCs with <copy-config> but how does one trigger this with RESTCONF? I had the hope with NMDA + RESTCONF extensions this would

            
                be possible too. Or do I still miss something?

          

          
 

          
I think that it is theoretically possible to invoke the NETCONF RPCs (e.g. the copy-config RPC defined in ietf-netconf.yang, RFC 6241) from RESTCONF (e.g. section 3.6 of RFC 8040).

          
 

          
Whether this is actually a good thing to do/encourage I'm not so sure.

          
 

          
[MSEE]: OK. But what is the preferred way for someone implementing RESTCONF on a device who would like to have the support of <candidate>, <startup>, <running> and the new ones defined in NMDA.

          
               How does one copy the data from <running> to e.g. <startup> using the mechanisms RESTCONF has defined in RFC 8040? From reading the RFC it seems is out of scope of RFC 8040 but is this really intended? 

          
               Implementing ietf-netconf.yang of course could be an option.

        

        
I agree that this isn't really specified.

        
IIRC our initial focus was to effectively get parity with RFC
          8040.  I.e. my working assumption is that <candidate>
          (if present) would be handled automatically and similarly
          updates to <startup> would be handled automatically. 
          E.g. broadly equivalent to the /data resource in RESTCONF.  So
          in essence this boils down to clients interacting with
          /ds/ietf-datastores:running, /ds/ietf-datastores:operational
          and /ds/ietf-datastores:intended.  No new RESTCONF operations
          should be necessary here.

        
I'm also not really convinced that independently controllable
          <startup> and <candidate> is really a great idea.

        
Given that <running> is meant to represent persistent
          configuration, then automatically updating <startup> as
          a side effect of updating <running> seems like the most
          sensible behavior.  If the desire is for some ephemeral type
          configuration then that would be better modeled via an
          explicit dynamic configuration datastore (e.g. a bit like what
          I2RS were trying to do).

        
Similarly, instead of a shared candidate datastore, there is
          some work investigating private candidate datastores. 
          draft-lhotka-netconf-restconf-transactions-00 gives some ideas
          of what this could look like, but further work is required.

        
If there is a strong requirement to allow full explicit
          manipulation of configuration datastores then I think that we
          should probably define explicit RPCs for these operations
          (modeled on the NETCONF ones).  Ideally, these could be
          defined in a protocol neutral format so that they can work
          with any YANG based management protocols.  In the interim,
          using the NETCONF RPCs from RESTCONF seems like a reasonable
          stopgap measure.

        
[MSEE]: I agree, this would be helpful.
          

        
BR

            Markus 

        
Thanks,

          Rob

        
 

        

          
 

          
Thanks,

          
Rob

          
 

          

            
 

            

              
3.       Typo in https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_pdf_draft-2Dietf-2Dnetconf-2Dnmda-2Drestconf-2D05&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=BSyY-GBuzzDry6oIhg-mgwMAySbhJEO9Im3Z4PD_c_4&e= Chapter 3.1 "the server would implement the resource {+restconf}/ds/example- ds-ephemeral:ds-ephemeral."

              
There is a space in between "example-" and "ds-ephemeral:ds-ephemeral".

            

            
Lets hope we get this fixed with the help of the RFC editor.

            
 

            
/js

            
 

            
--

            
Juergen Schoenwaelder           Jacobs University Bremen gGmbH

            
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany

            
Fax:   +49 421 200 3103         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.jacobs-2Duniversity.de_&d=DwIBAg&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=CDK28X8kO2wRVDla97P_WqBIhF3OAzbWSGEmTeLdxwU&s=w38seWi6FN48OjPfJn92--emi3rEzEiDTHsKLxEnsrg&e=>

            
_______________________________________________

            
netmod mailing list

            
netmod@ietf.org

            
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail

            
man_listinfo_netmod&d=DwIDaQ&c=Bg5XULDZR8GiOSSWNlpkCsRePnGDkKcI6oYL9xv

            
1MnQ&r=2XEKVYkQjmLHi2TOJp1VSzieLZVqewIpj-RxmRgPfsM&m=TrPMVXQ5IovFm08BS

            
bbXa2E-HnSO_yzHRy0GR9djT2M&s=sd11onHA42ODnysz9ZOIZikWWQMHkHwUSeL-lNWck

            
DE&e=

          

          
 

          
**********************************************************************

          
DISCLAIMER:

          
Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.

        

      

      
DISCLAIMER:

      Privileged and/or Confidential information may be contained in
      this message. If you are not the addressee of this message, you
      may not copy, use or deliver this message to anyone. In such
      event, you should destroy the message and kindly notify the sender
      by reply e-mail. It is understood that opinions or conclusions
      that do not relate to the official business of the company are
      neither given nor endorsed by the company. Thank You.

    

  


--------------949434CD4F37A5C8F3B75038--


From nobody Wed Dec 12 07:21:25 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493F51252B7 for ; Wed, 12 Dec 2018 07:21:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Level: 
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAU6qQRjCV4U for ; Wed, 12 Dec 2018 07:21:02 -0800 (PST)
Received: from mail2.belden.com (mail2.belden.com [12.168.192.245]) (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 76193130E17 for ; Wed, 12 Dec 2018 07:21:02 -0800 (PST)
Received: from pps.filterd (dcric1ppa02pa.mcp.local [127.0.0.1]) by dcric1ppa02pa.mcp.local (8.16.0.22/8.16.0.22) with SMTP id wBCFEQfU009533;  Wed, 12 Dec 2018 10:21:00 -0500
Received: from dcric1exc01pa.mcp.local (dcric1exc01pa.mcp.local [10.10.181.21]) by dcric1ppa02pa.mcp.local with ESMTP id 2pb1curuxa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 12 Dec 2018 10:20:59 -0500
Received: from DCRIC1EXC03PA.mcp.local (10.10.181.23) by DCRIC1EXC01PA.mcp.local (10.10.181.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 12 Dec 2018 10:20:59 -0500
Received: from DCRIC1EXC03PA.mcp.local ([172.16.254.23]) by DCRIC1EXC03PA.mcp.local ([172.16.254.23]) with mapi id 15.00.1367.000; Wed, 12 Dec 2018 10:20:59 -0500
From: "Seehofer, Markus" 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [EXTERNAL] Re: AW: Re: AW: [netmod] Re: Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)
Thread-Index: AQHUkizM9F+Vno9s60OKfNvr71LFjKV7N/UA
Date: Wed, 12 Dec 2018 15:20:59 +0000
Message-ID: 
References:  <20181211143313.xouvshwdtakmkdz4@anna.jacobs.jacobs-university.de> <9d40f9ad4b494e67ba2808341dc82e4d@DCRIC1EXC03PA.mcp.local>  <532b30422c7a4e77972181c32eaa8ff8@DCRIC1EXC03PA.mcp.local> <3db5de24-5168-0065-be9e-94f0b57cf06f@cisco.com>  <552c4033-e46f-6f0d-470f-24bb590e5890@cisco.com>
In-Reply-To: <552c4033-e46f-6f0d-470f-24bb590e5890@cisco.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.115.35.153]
x-c2processedorg: 157cf0a0-3349-4636-89a5-bb6917ccdf3c
Content-Type: multipart/alternative; boundary="_000_e1e9865cb1784062a1a8fdd0cd2756b8DCRIC1EXC03PAmcplocal_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-12_04:, , signatures=0
Archived-At: 
Subject: Re: [netmod] Question on RFC8342 + RESTCONF extension (draft-ietf-netconf-nmda-restconf)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Dec 2018 15:21:23 -0000

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

VGhhbmsgeW91IHZlcnkgbXVjaCBSb2JlcnQuIFlvdXIgYW5zd2VycyBhcmUgcmVhbGx5IGhlbHBm
dWwuDQoNCkJSDQpNYXJrdXMNCg0KVm9uOiBSb2JlcnQgV2lsdG9uIFttYWlsdG86cndpbHRvbkBj
aXNjby5jb21dDQpHZXNlbmRldDogTWl0dHdvY2gsIDEyLiBEZXplbWJlciAyMDE4IDE2OjEwDQpB
bjogU2VlaG9mZXIsIE1hcmt1czsgbmV0bW9kQGlldGYub3JnDQpCZXRyZWZmOiBbRVhURVJOQUxd
IFJlOiBBVzogUmU6IEFXOiBbbmV0bW9kXSBSZTogUXVlc3Rpb24gb24gUkZDODM0MiArIFJFU1RD
T05GIGV4dGVuc2lvbiAoZHJhZnQtaWV0Zi1uZXRjb25mLW5tZGEtcmVzdGNvbmYpDQoNCg0KDQoN
CkhpIE1hcmt1cywNCk9uIDEyLzEyLzIwMTggMTQ6NDAsIFNlZWhvZmVyLCBNYXJrdXMgd3JvdGU6
DQpIZWxsbyBSb2JlcnQsDQoNClZvbjogUm9iZXJ0IFdpbHRvbiBbbWFpbHRvOnJ3aWx0b25AY2lz
Y28uY29tXQ0KR2VzZW5kZXQ6IE1pdHR3b2NoLCAxMi4gRGV6ZW1iZXIgMjAxOCAxMToyMQ0KQW46
IFNlZWhvZmVyLCBNYXJrdXM7IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3Jn
Pg0KQmV0cmVmZjogW0VYVEVSTkFMXSBSZTogQVc6IFtuZXRtb2RdIFJlOiBRdWVzdGlvbiBvbiBS
RkM4MzQyICsgUkVTVENPTkYgZXh0ZW5zaW9uIChkcmFmdC1pZXRmLW5ldGNvbmYtbm1kYS1yZXN0
Y29uZikNCg0KDQoNCg0KSGkgTWFya3VzLA0KT24gMTEvMTIvMjAxOCAxNzoyMSwgU2VlaG9mZXIs
IE1hcmt1cyB3cm90ZToNCg0KSGVsbG8gUm9iZXJ0LA0KDQoNCg0KY29tbWVudHMgaW5saW5lIGJl
bG93Lg0KDQoNCg0KQlINCg0KIE1hcmt1cw0KDQoNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNo
cmljaHQtLS0tLQ0KDQpWb246IFJvYmVydCBXaWx0b24gW21haWx0bzpyd2lsdG9uQGNpc2NvLmNv
bV0NCg0KR2VzZW5kZXQ6IERpZW5zdGFnLCAxMS4gRGV6ZW1iZXIgMjAxOCAxNzowNg0KDQpBbjog
U2VlaG9mZXIsIE1hcmt1cw0KDQpDYzogbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0
Zi5vcmc+DQoNCkJldHJlZmY6IFJlOiBbbmV0bW9kXSBbRVhURVJOQUxdIFJlOiBRdWVzdGlvbiBv
biBSRkM4MzQyICsgUkVTVENPTkYgZXh0ZW5zaW9uIChkcmFmdC1pZXRmLW5ldGNvbmYtbm1kYS1y
ZXN0Y29uZikNCg0KDQoNCkhpIFNlZWhvZmVyLA0KDQoNCg0KUGxlYXNlIHNlZSBpbmxpbmUgLi4u
DQoNCg0KDQpPbiAxMS8xMi8yMDE4IDE0OjU1LCBTZWVob2ZlciwgTWFya3VzIHdyb3RlOg0KDQpI
ZWxsbyBKdWVyZ2VuLA0KDQoNCg0Kc2VlIG15IGNvbW1lbnRzIGlubGluZSBiZWxvdy4gQXMgYmVp
bmcgcXVpdGUgbmV3IHRvIHRoZSB0b3BpYywgZ29pbmcgdGhyb3VnaCBhbGwgdGhlIG9sZCBhbmQg
Y3VycmVudCBSRkNzIGFuZCBkcmFmdHMgaXMgcXVpdGUgY2hhbGxlbmdpbmcuDQoNClNvIHBsZWFz
ZSBhcG9sb2dpemUgZm9yICJzaW1wbGUiIHF1ZXN0aW9ucyBvciBvbmVzIG1heWJlIGFscmVhZHkg
cmFpc2VkLg0KDQoNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KDQpWb246
IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0KDQpbbWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMt
dW5pdmVyc2l0eS5kZV0NCg0KR2VzZW5kZXQ6IERpZW5zdGFnLCAxMS4gRGV6ZW1iZXIgMjAxOCAx
NTozMw0KDQpBbjogU2VlaG9mZXIsIE1hcmt1cw0KDQpDYzogbmV0bW9kQGlldGYub3JnPG1haWx0
bzpuZXRtb2RAaWV0Zi5vcmc+DQoNCkJldHJlZmY6IFtFWFRFUk5BTF0gUmU6IFtuZXRtb2RdIFF1
ZXN0aW9uIG9uIFJGQzgzNDIgKyBSRVNUQ09ORg0KDQpleHRlbnNpb24gKGRyYWZ0LWlldGYtbmV0
Y29uZi1ubWRhLXJlc3Rjb25mKQ0KDQoNCg0KDQoNCg0KDQpPbiBUdWUsIERlYyAxMSwgMjAxOCBh
dCAwMjoxNzowN1BNICswMDAwLCBTZWVob2ZlciwgTWFya3VzIHdyb3RlOg0KDQpIZWxsbywNCg0K
DQoNClJlYWRpbmcgUkZDIDgzNDIgYWxvbmcgd2l0aCBkcmFmdC1pZXRmLW5ldGNvbmYtbm1kYS1y
ZXN0Y29uZi0wNSBJJ3ZlIHNvbWUgcXVlc3Rpb25zIG9yIGNvbXByZWhlbnNpb24gcHJvYmxlbXMg
d2l0aCB0aGUgdGV4dC4NCg0KDQoNCg0KDQoxLiAgICAgICBSRkMgODM0MiAoTk1EQSkNCg0KQ2hh
cHRlciA1LjMuICBUaGUgT3BlcmF0aW9uYWwgU3RhdGUgRGF0YXN0b3JlICg8b3BlcmF0aW9uYWw+
KSBzYXlzOg0KDQoiVGhlIG9wZXJhdGlvbmFsIHN0YXRlIGRhdGFzdG9yZSAoPG9wZXJhdGlvbmFs
PikgaXMgYSByZWFkLW9ubHkgZGF0YXN0b3JlIC4uLi4iDQoNCkNoYXB0ZXIgNi4yLiBJbnZvY2F0
aW9uIG9mIEFjdGlvbnMgYW5kIFJQQ3Mgc2F5czoNCg0KIkFjdGlvbnMgYXJlIGFsd2F5cyBpbnZv
a2VkIGluIHRoZSBjb250ZXh0IG9mIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBkYXRhc3RvcmUuIFRo
ZSBub2RlIGZvciB3aGljaCB0aGUgYWN0aW9uIGlzIGludm9rZWQgTVVTVCBleGlzdCBpbiB0aGUg
b3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlLiINCg0KDQoNCkNoYXB0ZXIgMy4xIGluIGh0dHBz
Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0
Zi5vcmdfcGRmX2RyYWZ0LTJEaWV0Zi0yRG5ldGNvbmYtMkRubWRhLTJEcmVzdGNvbmYtMkQwNSZk
PUR3SUJBZyZjPUJnNVhVTERaUjhHaU9TU1dObHBrQ3NSZVBuR0RrS2NJNm9ZTDl4djFNblEmcj0y
WEVLVllrUWptTEhpMlRPSnAxVlN6aWVMWlZxZXdJcGotUnhtUmdQZnNNJm09Q0RLMjhYOGtPMndS
VkRsYTk3UF9XcUJJaEYzT0F6YldTR0VtVGVMZHh3VSZzPUJTeVktR0J1enpEcnk2b0loZy1tZ3dN
QXlTYmhKRU85SW0zWjRQRF9jXzQmZT0gc2F5czoNCg0KIllBTkcgYWN0aW9ucyBjYW4gb25seSBi
ZSBpbnZva2VkIGluIHsrcmVzdGNvbmZ9L2RzL2lldGYtZGF0YXN0b3JlczpvcGVyYXRpb25hbC4i
DQoNCg0KDQpRdWVzdGlvbjogSG93IGNhbiBvbmUgaW52b2tlIGFuIGFjdGlvbiBpbiBhIGFzIHJl
YWQtb25seSBkZWZpbmVkIGRhdGFzdG9yZT8gT3IgYW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCg0K
V2h5IGRvIHlvdSBleHBlY3QgdGhhdCBhIGRhdGFzdG9yZSBoYXMgdG8gYmUgd3JpdGFibGUgaW4g
b3JkZXIgdG8NCg0KaW52b2tlIGFuIGFjdGlvbj8gUkZDIDc5NTAgaGFzIHRoZSBleGFtcGxlIG9m
IGEgcGluZyBhY3Rpb24gdGllZCB0byBhbg0KDQppbnRlcmZhY2UuIChZb3UgcGluZyBhIHJlbW90
ZSBzeXN0ZW0gZnJvbSB0aGF0IHNwZWNpZmljIGludGVyZmFjZS4pIEluDQoNCmdlbmVyYWwsIGFj
dGlvbnMgYXJlIHVuZGVyc3Rvb2QgYXMgYmVpbmcgdGllZCB0byByZWFsIHJlc291cmNlcyBhbmQN
Cg0KaGVuY2UgdG8gdGhlIG9wZXJhdGlvbmFsIGRhdGFzdG9yZS4gKEZvciBleGFtcGxlLCB5b3Ug
Y2FuJ3QgcGluZyBmcm9tDQoNCmFuIGludGVyZmFjZSB0aGF0IGlzIGNvbmZpZ3VyZWQgYnV0IG5v
dCBwaHlzaWNhbGx5IHByZXNlbnQuKQ0KDQoNCg0KW01TRUVdOiBJIGRvIG5vdCBleHBlY3QgdGhh
dCBhIGRhdGFzdG9yZSBoYXMgdG8gYmUgd3JpdGVhYmxlIHRvIGludm9rZSBhbiBhY3Rpb24sIGJ1
dCBJIGRvIGV4cGVjdCB0aGF0IGEgInJlYWQtb25seSIgZGF0YXN0b3JlIGlzIG5vdCB3cml0ZWFi
bGUgYW5kIFJGQyA4MzQyIHNheXMgY2xlYXJseSBvcGVyYXRpb25hbCBzdGF0ZSBkYXRhc3RvcmUg
aXMgInJlYWQtb25seSIuDQoNCg0KDQpSUENzIGFuZCBhY3Rpb25zIGRvbid0IG1vZGlmeSB0aGUg
b3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlIGFzIHN1Y2gsIGluc3RlYWQgdGhleSBtb2RpZnkg
dGhlIHByb3BlcnRpZXMgb2YgdGhlIHVuZGVybHlpbmcgc3lzdGVtLCBhbmQgdGhlIG9wZXJhdGlv
bmFsIHN0YXRlIGRhdGFzdG9yZSBwcm92aWRlcyBhIHJlYWQtb25seSB2aWV3IG9udG8gdGhlIHN0
YXRlIG9mIHRoZSBzeXN0ZW0uICBTbyA8b3BlcmF0aW9uYWw+IGlzIG9ubHkgYmVpbmcgdXBkYXRl
ZCBhcyBhIHNpZGUgZWZmZWN0IG9mIHJlZmxlY3RpbmcgdGhlIGNoYW5nZXMgdG8gdGhlIHVuZGVy
bHlpbmcgc3lzdGVtLg0KDQoNCg0KVGhpcyBjb250cmFzdHMgd2l0aCB3cml0YWJsZSBjb25maWd1
cmF0aW9uIGRhdGFzdG9yZXMgKGUuZy4gPGNhbmRpZGF0ZT4gb3IgPHJ1bm5pbmc+KSwgd2hlcmUg
dGhlIGNsaWVudCBjYW4gbW9kaWZ5IHRoZSBjb25maWd1cmF0aW9uIGluIHRob3NlIGRhdGFzdG9y
ZXMgZGlyZWN0bHkgd2hpY2ggd2lsbCB0aGVuIGF0dGVtcHQgdG8gY2hhbmdlIHRoZSBiZWhhdmlv
ciBvZiB0aGUgc3lzdGVtIGFzIHRoZSBjb25maWcgaXMgYXBwbGllZC4NCg0KDQoNCltNU0VFXTog
SSBhZ3JlZSBidXQgSSdtIHN0aWxsIHN0dWNrIHdpdGggdGhlIGZvbGxvd2luZyB0ZXh0Lg0KDQog
ICAgICAgICAgICAgICAtIGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJlc3Rjb25mLTA1IHNheXMg
aW4gQ2hhcHRlciAzLjE6ICJZQU5HIGFjdGlvbnMgY2FuIG9ubHkgYmUgaW52b2tlZCBpbiB7K3Jl
c3Rjb25mfS9kcy9pZXRmLWRhdGFzdG9yZXM6b3BlcmF0aW9uYWwiIHdpdGgNCg0KICAgICAgICAg
ICAgICAgICAgIlRoZSByZXNvdXJjZSB7K3Jlc3Rjb25mfS9kcy9pZXRmLWRhdGFzdG9yZXM6b3Bl
cmF0aW9uYWwgcmVmZXJzIHRvIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBkYXRhc3RvcmUiIGFuZCAi
VGhlIG9wZXJhdGlvbmFsIHN0YXRlIGRhdGFzdG9yZSAoPG9wZXJhdGlvbmFsPikgaXMgYSByZWFk
LW9ubHkgZGF0YXN0b3JlIg0KDQogICAgICAgICAgICAgICAtIFJGQyA4MDQwIHNheXMgaW4gQ2hh
cHRlciAzLjYgIiBPcGVyYXRpb24gcmVzb3VyY2VzIHJlcHJlc2VudGluZyBZQU5HIGFjdGlvbnMg
YXJlIG5vdCBpZGVudGlmaWVkIGluIHRoaXMgc3VidHJlZSwgc2luY2UgdGhleSBhcmUgaW52b2tl
ZCB1c2luZyBhIFVSSSB3aXRoaW4gdGhlICd7K3Jlc3Rjb25mfS9kYXRhJyBzdWJ0cmVlIiBhbmQN
Cg0KICAgICAgICAgICAgICAgICAiQW4gYWN0aW9uIGlzIGludm9rZWQgYXM6IFBPU1QgeytyZXN0
Y29uZn0vZGF0YS88ZGF0YS1yZXNvdXJjZS1pZGVudGlmaWVyPi88YWN0aW9uPiINCg0KDQoNCiAg
ICAgICAgICAgICAgIFNvIHdpdGhvdXQgTk1EQSBpdCB3YXMgY2xlYXIsIGludm9rZSBhbiBhY3Rp
b24gdXNpbmcgeytyZXN0Y29uZn0vZGF0YX0uIFdpdGggTk1EQSB3aGF0IGlzIHRoZSBjb3JyZWN0
IHdheSB0byB0cmlnZ2VyIGFuIGFjdGlvbiBhcyB0aGUgZHJhZnQgc2F5cyAiWUFORyBhY3Rpb25z
IGNhbiBvbmx5IGJlIGludm9rZWQgaW4geytyZXN0Y29uZn0vZHMvaWV0Zi1kYXRhc3RvcmVzOm9w
ZXJhdGlvbmFsIj8NCg0KU28sIHlvdSBpbnZva2UgaXQgb24gdGhlIGVxdWl2YWxlbnQgcGF0aCB1
c2luZyB0aGUgb3BlcmF0aW9uYWwgZGF0YXN0b3JlLg0KDQpFLmcuIHRvIHRha2UgdGhlIGV4YW1w
bGUgZnJvbSBSRkMgODA0MCAzLjYuMiwgdGhlIHJlcXVlc3QgcHJlIE5NREEgaXMgdGhpczoNCg0K
ICAgICAgUE9TVCAvcmVzdGNvbmYvZGF0YS9leGFtcGxlLWFjdGlvbnM6aW50ZXJmYWNlcy9cDQoN
CiAgICAgICAgIGludGVyZmFjZT1ldGgwL2dldC1sYXN0LXJlc2V0LXRpbWUgSFRUUC8xLjENCg0K
ICAgICAgSG9zdDogZXhhbXBsZS5jb20NCg0KICAgICAgQWNjZXB0OiBhcHBsaWNhdGlvbi95YW5n
LWRhdGEranNvbg0KDQpUaGUgZXF1aXZhbGVudCBwYXRoIG9uIGEgTk1EQSBzZXJ2ZXIgaXMgdGhp
czoNCg0KICAgICAgUE9TVCAvcmVzdGNvbmYvZHMvaWV0Zi1kYXRhc3RvcmVzOm9wZXJhdGlvbmFs
L1wNCg0KICAgICAgICAgZXhhbXBsZS1hY3Rpb25zOmludGVyZmFjZXMvXA0KDQogICAgICAgICBp
bnRlcmZhY2U9ZXRoMC9nZXQtbGFzdC1yZXNldC10aW1lIEhUVFAvMS4xDQoNCiAgICAgIEhvc3Q6
IGV4YW1wbGUuY29tDQoNCiAgICAgIEFjY2VwdDogYXBwbGljYXRpb24veWFuZy1kYXRhK2pzb24N
Cg0KSSB0aGluayB0aGF0IHlvdXIgY29uY2VybiBtaWdodCBiZTogd2h5IGlzIGl0IHJpZ2h0L09L
IHRvIGludm9rZSBhIGFjdGlvbiBvbiB3aGF0IGlzIGRlZmluZWQgYXMgYSByZWFkIG9ubHkgc3Ry
dWN0dXJlPw0KDQpbTVNFRV06ICBFeGFjdGx5LiBCeSBqdXN0IHJlYWRpbmcgIlRoZSBvcGVyYXRp
b25hbCBzdGF0ZSBkYXRhc3RvcmUgKDxvcGVyYXRpb25hbD4pIGlzIGEgcmVhZC1vbmx5IGRhdGFz
dG9yZSAuLi4uIiBtYXkgYmUgY29uZnVzaW5nLiBJIHN0aWxsIHN0cnVnZ2xlIHdpdGggdGhlIHRl
eHQuDQoNClJXOiBJIGd1ZXNzIHRoYXQgeW91IGNhbiB0aGluayBvZiA8b3BlcmF0aW9uYWw+IGp1
c3QgYmVpbmcgYSB2aWV3IG9uIHRvIHRoZSB1bmRlcmx5aW5nIHN5c3RlbSBzdGF0ZS4gIEkuZS4g
eW91IGFyZSBhbGxvd2VkIHRvIHVzZSBhbiBhY3Rpb24gdG8gbW9kaWZ5IHRoZSB1bmRlcmx5aW5n
IHN0YXRlIHdoaWNoLCBhcyBhIHNpZGUgZWZmZWN0LCB1cGRhdGVzIDxvcGVyYXRpb25hbD4gKGJl
Y2F1c2UgaXQgYWx3YXlzIHJlZmxlY3RzIHRoZSBzeXN0ZW0gc3RhdGUpLCBidXQgeW91IGNhbm5v
dCB3cml0ZSB0byA8b3BlcmF0aW9uYWw+IGFzIGFuIGF0dGVtcHQgdG8gdXBkYXRlIHRoZSB1bmRl
cmx5aW5nIHN5c3RlbSBzdGF0ZS4NCg0KDQoNClRoZSBhbnN3ZXIgdG8gdGhpcyBpcyB0aGF0IHRo
ZSBhY3Rpb24gaXNuJ3QgYWN0aW5nIG9uIDxvcGVyYXRpb25hbD4sIGl0IGlzIGFjdGluZyBvbiB0
aGUgdW5kZXJseWluZyBzeXN0ZW0gYW5kIGhhcyB0aGUgcmVtaXQgdG8gY2hhbmdlIGFueSBvZiB0
aGUgc3lzdGVtIGJlaGF2aW9yLg0KDQpIb3dldmVyLCBiZWZvcmUgdGhlIGFjdGlvbiBjYW4gYmUg
cHJvY2Vzc2VkLCB0aGUgc3lzdGVtIG11c3QgdmFsaWRhdGUgdGhhdCB0aGUgZGF0YSBub2RlIHRo
YXQgaXQgaXMgYWN0aW5nIG9uIGV4aXN0cywgYW5kIHRoZSBwYXJhbWV0ZXJzIGFyZSB2YWxpZC4g
IFRoaXMgdmFsaWRhdGlvbiBpcyBwZXJmb3JtZWQgYWdhaW5zdCB0aGUgc3lzdGVtcyBvcGVyYXRp
b25hbCBzdGF0ZSwgYW5kIGhlbmNlIGlzIHZhbGlkYXRlZCBhZ2FpbnN0IDxvcGVyYXRpb25hbD4u
DQoNCltNU0VFXTogSSBhZ3JlZSwgdGhpcyBvZiBjb3Vyc2UgbWFrZXMgc2Vuc2UgYXMgb25seSB0
aGUgPG9wZXJhdGlvbmFsPiBkYXRhc3RvcmUgaGFzIHRoZSBpbmZvcm1hdGlvbnMgd2hpY2ggbm9k
ZXMgYXJlIGluIHVzZSBhbmQgdGhlcmVmb3JlIGFyZSBhdmFpbGFibGUgZm9yIHVzYWdlLg0KDQpB
Z2FpbiwgY29uc2lkZXJpbmcgdGhlIGV4YW1wbGUgYWJvdmUsIGl0IHdvdWxkbid0IG1ha2Ugc2Vu
c2UgdG8gZ2V0IHRoZSBsYXN0IHJlc2V0IHRpbWUgb2YgYW4gaW50ZXJmYWNlIHRoYXQgZXhpc3Rl
ZCBpbiBjb25maWd1cmF0aW9uLCBhbmQgaGVuY2Ugd2FzIHByZXNlbnQgaW4gPHJ1bm5pbmc+Lzxp
bnRlbmRlZD4sIGJ1dCB3YXMgbm90IGluIDxvcGVyYXRpb25hbD4uDQoNCltNU0VFXTogWWVzLCBJ
IGFncmVlLg0KDQpJbiBmdXR1cmUgd2UgbWF5IG5lZWQgYWN0aW9ucyB0aGF0IGFyZSB2YWxpZGF0
ZWQgYWdhaW5zdCBvdGhlciBkYXRhc3RvcmVzLCBidXQgd2hlbiB0aGUgYXV0aG9ycyB3ZXJlIGRp
c2N1c3NpbmcgdGhpcyBpdCB3YXMgdW5jbGVhciB3aGV0aGVyIHByb3BlciB1c2UgY2FzZXMgZm9y
IHN1Y2ggYWN0aW9ucyBleGlzdCwgYW5kIGhlbmNlIHdlIGRlY2lkZWQgdGhhdCB0aGlzIGNvdWxk
IGJlIGRlZmVycmVkIHRvIGZ1dHVyZSB3b3JrLCB3aGljaCB3b3VsZCBwcmVzdW1hYmx5IGNvbWUg
YWxvbmcgd2l0aCBhIGNvbmNyZXRlIHVzZSBjYXNlLg0KDQpbTVNFRV06IE9LLg0KDQpbTVNFRV06
IEFsb25nIHdpdGggdGhlIGFib3ZlIHF1ZXN0aW9ucyBhbmQgYW5zd2Vycy9zdGF0ZW1lbnRzICh0
aGFua3MgZm9yIHRoaXMpIEkgcHJvYmFibHkgc3RpbGwgaGF2ZSBtb3JlIHF1ZXN0aW9ucyB0aGFu
IGFuc3dlcnMgZnJvbSByZWFkaW5nIHRoZSBSRkNzIGFuZCBkcmFmdHMuDQoNCi0gICAgICAgICAg
RHJhZnQgZHJhZnQtaWV0Zi1uZXRjb25mLW5tZGEtcmVzdGNvbmYtMDUgc2F5czoNCuKAnEFuIE5N
REEtY29tcGxpYW50IHNlcnZlciBNVVNUIGltcGxlbWVudCB7K3Jlc3Rjb25mfS9kcy9pZXRmLWRh
dGFzdG9yZXM6b3BlcmF0aW9uYWwuICBPdGhlciBkYXRhc3RvcmUgcmVzb3VyY2VzIE1BWSBiZSBp
bXBsZW1lbnRlZOKAnS4NCkRvZXMgdGhpcyBtZWFuIGEgR0VUIHRvIHsrcmVzdGNvbmZ9L2RhdGF9
ICh3aGljaCBpcyBzdGlsbCB2YWxpZCkgcmV0dXJucyB0aGUgc2FtZSBkYXRhIGFzIGEgR0VUIHRv
IHsrcmVzdGNvbmZ9L2RzL2lldGYtZGF0YXN0b3JlczpvcGVyYXRpb25hbCBpZiBpdCBpcyBOTURB
IGNvbXBsaWFudD8NCg0KUlc6IFRoZSBkZWZpbml0aW9uIG9mIHsrcmVzdGNvbmZ9L2RhdGF9IGhh
cyBub3QgY2hhbmdlZCBpbiBhbnkgd2F5LiAgU28sIHRoZSBjb250ZW50cy9iZWhhdmlvciBvZiB7
K3Jlc3Rjb25mfS9kYXRhfSBzaG91bGQgbWF0Y2ggd2hhdCBpcyBzcGVjaWZpZWQgYnkgUkZDIDgw
NDAuDQoNCkJ1dCB0aGlzIGlzIHRyaWNreSAoYmVjYXVzZSAvZGF0YSBtaXhlcyBpbnRlbmRlZCBj
b25maWd1cmF0aW9uIHdpdGggb3BlcmF0aW9uYWwgc3RhdGUpLg0KDQpIZW5jZSwgSSB3b3VsZG4n
dCBiZSBzdXJwcmlzZWQgaWYgc29tZSBpbXBsZW1lbnRhdGlvbnMgZWl0aGVyOg0KKDEpIGRvbid0
IGltcGxlbWVudCAvZGF0YSBhdCBhbGwsIG9yDQooMikgaGFuZGxlIERFTEVURS9QT1NUL1BBVENI
L1BVVCBvcGVyYXRpb25zIGFzIGlmIHRoZSBvcGVyYXRpb24gd2FzIG1hZGUgYWdhaW5zdCB7K3Jl
c3Rjb25mfS9kcy9pZXRmLWRhdGFzdG9yZXM6cnVubmluZywgaGFuZGxlIEdFVCByZXF1ZXN0cyBh
cyBpZiB0aGV5IHRoZSBvcGVyYXRpb24gd2FzIG1hZGUgYWdhaW5zdCBvbiB7K3Jlc3Rjb25mfS9k
cy9pZXRmLWRhdGFzdG9yZXM6b3BlcmF0aW9uYWwuICBUaGlzIHdvdWxkIGJlIG5vbi1zdGFuZGFy
ZCBiZWhhdmlvciB0aG91Z2ggLi4uLg0KDQpBIGZ1dHVyZSB2ZXJzaW9uIG9mIFJFU1RDT05GLCBh
cyBvcHBvc2VkIHRvIGFuIGV4dGVuc2lvbiAoaS5lLiBkcmFmdC1pZXRmLW5ldGNvbmYtbm1kYS1y
ZXN0Y29uZi0wNSksIG1heSByZW1vdmUgc3VwcG9ydCBmb3IgeytyZXN0Y29uZn0vZGF0YX0uDQoN
Cg0KDQotDQoNCi0gICAgICAgICAgSWYgc3VjaCBhIE5NREEgY29tcGxpYW50IFJFU1RDT05GIHNl
cnZlciBoYXMgZS5nLiDigJxleGFtcGxlLWp1a2Vib3jigJ0gaW1wbGVtZW50ZWQsIGFyZSBib3Ro
IG9mIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50cyBjb3JyZWN0Pw0KDQogICAgIFBBVENIIC9yZXN0
Y29uZi9kYXRhL2V4YW1wbGUtanVrZWJveDpqdWtlYm94L1wNCiAgICAgICAgIGxpYnJhcnkvYXJ0
aXN0PUZvbyUyMEZpZ2h0ZXJzL2FsYnVtPVdhc3RpbmclMjBMaWdodCBIVFRQLzEuMQ0KICAgICBI
b3N0OiBleGFtcGxlLmNvbQ0KICAgICBJZi1NYXRjaDogImI4Mzg5MjMzYTRjIg0KICAgICBDb250
ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3lhbmctZGF0YSt4bWwNCiAgICAgPGFsYnVtIHhtbG5zPSJo
dHRwOi8vZXhhbXBsZS5jb20vbnMvZXhhbXBsZS1qdWtlYm94IjxodHRwczovL3VybGRlZmVuc2Uu
cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fZXhhbXBsZS5jb21fbnNfZXhhbXBsZS0y
RGp1a2Vib3gmZD1Ed01EYVEmYz1CZzVYVUxEWlI4R2lPU1NXTmxwa0NzUmVQbkdEa0tjSTZvWUw5
eHYxTW5RJnI9MlhFS1ZZa1FqbUxIaTJUT0pwMVZTemllTFpWcWV3SXBqLVJ4bVJnUGZzTSZtPUlR
WjNnVmI1U2xrUTBTb3JKUWVJRzlEM3RyZlFyTmgybXRTQ1N0WEpmOFUmcz0waWZjamdXRHJnbTJj
U1N1aTlFNElRTEhLM3kyZTEtenNySm9fOW9sNlJ3JmU9Pj4NCiAgICAgIDx5ZWFyPjIwMTE8L3ll
YXI+DQogICAgIDwvYWxidW0+DQoNCmFuZA0KDQpQQVRDSCAvcmVzdGNvbmYvZHMvaWV0Zi1kYXRh
c3RvcmVzOm9wZXJhdGlvbmFsL2V4YW1wbGUtanVrZWJveDpqdWtlYm94L1wNCiAgIGxpYnJhcnkv
YXJ0aXN0PUZvbyUyMEZpZ2h0ZXJzL2FsYnVtPVdhc3RpbmclMjBMaWdodCBIVFRQLzEuMQ0KSG9z
dDogZXhhbXBsZS5jb20NCklmLU1hdGNoOiAiYjgzODkyMzNhNGMiDQpDb250ZW50LVR5cGU6IGFw
cGxpY2F0aW9uL3lhbmctZGF0YSt4bWwNCjxhbGJ1bSB4bWxucz0iaHR0cDovL2V4YW1wbGUuY29t
L25zL2V4YW1wbGUtanVrZWJveCI8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy
L3VybD91PWh0dHAtM0FfX2V4YW1wbGUuY29tX25zX2V4YW1wbGUtMkRqdWtlYm94JmQ9RHdNRGFR
JmM9Qmc1WFVMRFpSOEdpT1NTV05scGtDc1JlUG5HRGtLY0k2b1lMOXh2MU1uUSZyPTJYRUtWWWtR
am1MSGkyVE9KcDFWU3ppZUxaVnFld0lwai1SeG1SZ1Bmc00mbT1JUVozZ1ZiNVNsa1EwU29ySlFl
SUc5RDN0cmZRck5oMm10U0NTdFhKZjhVJnM9MGlmY2pnV0RyZ20yY1NTdWk5RTRJUUxISzN5MmUx
LXpzckpvXzlvbDZSdyZlPT4+DQo8eWVhcj4yMDExPC95ZWFyPg0KPC9hbGJ1bT4NCg0KLSAgICAg
ICAgRHJhZnQgZHJhZnQtaWV0Zi1uZXRjb25mLW5tZGEtcmVzdGNvbmYtMDUgc2F5czoNCiAgICAg
ICAgICDigJwgWUFORyBhY3Rpb25zIGNhbiBvbmx5IGJlIGludm9rZWQgaW4geytyZXN0Y29uZn0v
ZHMvaWV0Zi1kYXRhc3RvcmVzOm9wZXJhdGlvbmFs4oCdDQogICAgICAgICAgSW4gc3VjaCBhIE5N
REEgY29tcGxpYW50IFJFU1RDT05GIHNlcnZlciwgaXMgeytyZXN0Y29uZn0vb3BlcmF0aW9ucyAo
UkZDODA0MCAtIDMuNiBPcGVyYXRpb24gUmVzb3VyY2UgKXN0aWxsIHZhbGlkPyBCZWNhdXNlIHRo
ZSBhYm92ZSBzdGF0ZW1lbnQgc2F5cyDigJzigKZjYW4gb25seeKApuKAnSBvciBkb2VzIG9uZSBo
YXZlIHRvIHVzZToNCg0KUlc6DQoNCk5vLCB5b3UgY2FuJ3QgUEFUQ0ggYWdhaW5zdCA8b3BlcmF0
aW9uYWw+LiAgUEFUQ0ggaXMgbm90IGEgWUFORyBhY3Rpb24sIGl0IGlzIGEgUkVTVENPTkYgbWV0
aG9kLg0KDQpJdCBpcyBjb3ZlcmVkIGJ5IGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJlc3Rjb25m
LTA1LCBzZWN0aW9uIDMuMjoNCg0KICAgbyAgU29tZSBkYXRhc3RvcmVzIGFyZSByZWFkLW9ubHkg
YnkgbmF0dXJlIChlLmcuLCA8aW50ZW5kZWQ+KSwgYW5kDQoNCiAgICAgIGhlbmNlIGFueSBhdHRl
bXB0IHRvIG1vZGlmeSB0aGVzZSBkYXRhc3RvcmVzIHdpbGwgZmFpbC4gIEEgc2VydmVyDQoNCiAg
ICAgIE1VU1QgcmV0dXJuIGEgcmVzcG9uc2Ugd2l0aCBhICI0MDUgTWV0aG9kIE5vdCBBbGxvd2Vk
IiBzdGF0dXMtbGluZQ0KDQogICAgICBhbmQgZXJyb3ItdGFnIHZhbHVlICJvcGVyYXRpb24tbm90
LXN1cHBvcnRlZCIuDQoNCg0KDQpQT1NUIHsrcmVzdGNvbmZ9L2RzL2lldGYtZGF0YXN0b3Jlczpv
cGVyYXRpb25hbCAvPG9wZXJhdGlvbj4NCmFuZA0KUE9TVCB7K3Jlc3Rjb25mfS9kcy9pZXRmLWRh
dGFzdG9yZXM6b3BlcmF0aW9uYWwgLzxkYXRhLXJlc291cmNlLWlkZW50aWZpZXI+LzxhY3Rpb24+
DQpvbiBhIE5NREEgY29tcGxpYW50IHNlcnZlciBvbmx5Pw0KDQpZb3UgY2FuIG9ubHkgUE9TVCBh
Z2FpbnN0IGVkaXRhYmxlIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlcywgZS5nLiA8Y2FuZGlkYXRl
PiwgPHJ1bm5pbmc+LDxzdGFydHVwPiwgYW5kIG9ubHkgdGhlbiBpZiB0aGUgc2VydmVyIGFsbG93
cyB0aGlzLg0KDQpUaGFua3MsDQpSb2INCg0KDQoNCjIuICAgICAgIFRoZSBOTURBIGlzIGEgaHVn
ZSBzdGVwIGZvcndhcmQgZm9yIE5DIGFuZCBSQywgdGhhbmtzIGZvciB0aGF0LiBOTURBIGluIGNv
bWJpbmF0aW9uIHdpdGggdGhlIG5ldyBSRVNUQ09ORiBleHRlbnNpb25zIGxldCBvbmUgbm93IHNl
bGVjdCBvbmUgb2YgdGhlIG5hbWVkIGRhdGFzdG9yZXMNCg0KaW4gUkZDIDgzNDIuIFJlYWRpbmcg
dGhlIFJGQyBhbmQgZHJhZnQgSSdtIHN0aWxsIG1pc3NpbmcgKG9yIGV2ZW4gbW9yZSBvdmVybG9v
ayBJIGd1ZXNzKSB0aGUgZm9sbG93aW5nLiBSRkMgODA0MCBDaGFwdGVyIDQuNSBzYXlzOg0KDQoi
QSBQVVQgb24gdGhlIGRhdGFzdG9yZSByZXNvdXJjZSBpcyB1c2VkIHRvIHJlcGxhY2UgdGhlIGVu
dGlyZQ0KDQpjb250ZW50cyBvZiB0aGUgZGF0YXN0b3JlLi4uIi4gU28gZG9lcyB0aGlzIG1lYW4g
b25lIGNhbiBoYXZlIHRoZSBzYW1lIGJlaGF2aW9yIGFzIGluIE5FVENPTkYgd2hlcmUgeW91IGNh
biBjb3B5IHRoZSAicnVubmluZyIgY29uZmlnIHRvICJzdGFydHVwIiBvciAiY2FuZGlkYXRlIiBj
b25maWcgdG8gInJ1bm5pbmciIGlmIGEgUkVTVENPTkYgc2VydmVyIHdvdWxkIHN1cHBvcnQgdGhl
bT8gSXMgdGhlcmUgYW55IGV4YW1wbGUgaG93IHRoaXMgd291bGQgbG9vayBsaWtlIGlmIGl0IGlz
IGFsbG93ZWQ/DQoNCkEgUFVUIGRvZXMgbm90IHJlYWxseSBnZXQgeW91IHRoZXJlLCB0byBjb3B5
IGEgZGF0YXN0b3JlIHRvIGFub3RoZXIgeW91IHdhbnQgYW4gb3BlcmF0aW9uIG9uIHRoZSBzZXJ2
ZXIuDQoNCg0KDQpbTVNFRV06IEV4YWN0bHkgdGhpcyBpcyB3aGF0IEkgd2FudC4gTkVUQ09ORiBz
cGVjaWZpZXMgdGhpcyBjbGVhcmx5IGluIHRoZSBSRkNzIHdpdGggPGNvcHktY29uZmlnPiBidXQg
aG93IGRvZXMgb25lIHRyaWdnZXIgdGhpcyB3aXRoIFJFU1RDT05GPyBJIGhhZCB0aGUgaG9wZSB3
aXRoIE5NREEgKyBSRVNUQ09ORiBleHRlbnNpb25zIHRoaXMgd291bGQNCg0KICAgICAgICAgICAg
ICAgIGJlIHBvc3NpYmxlIHRvby4gT3IgZG8gSSBzdGlsbCBtaXNzIHNvbWV0aGluZz8NCg0KDQoN
CkkgdGhpbmsgdGhhdCBpdCBpcyB0aGVvcmV0aWNhbGx5IHBvc3NpYmxlIHRvIGludm9rZSB0aGUg
TkVUQ09ORiBSUENzIChlLmcuIHRoZSBjb3B5LWNvbmZpZyBSUEMgZGVmaW5lZCBpbiBpZXRmLW5l
dGNvbmYueWFuZywgUkZDIDYyNDEpIGZyb20gUkVTVENPTkYgKGUuZy4gc2VjdGlvbiAzLjYgb2Yg
UkZDIDgwNDApLg0KDQoNCg0KV2hldGhlciB0aGlzIGlzIGFjdHVhbGx5IGEgZ29vZCB0aGluZyB0
byBkby9lbmNvdXJhZ2UgSSdtIG5vdCBzbyBzdXJlLg0KDQoNCg0KW01TRUVdOiBPSy4gQnV0IHdo
YXQgaXMgdGhlIHByZWZlcnJlZCB3YXkgZm9yIHNvbWVvbmUgaW1wbGVtZW50aW5nIFJFU1RDT05G
IG9uIGEgZGV2aWNlIHdobyB3b3VsZCBsaWtlIHRvIGhhdmUgdGhlIHN1cHBvcnQgb2YgPGNhbmRp
ZGF0ZT4sIDxzdGFydHVwPiwgPHJ1bm5pbmc+IGFuZCB0aGUgbmV3IG9uZXMgZGVmaW5lZCBpbiBO
TURBLg0KDQogICAgICAgICAgICAgICBIb3cgZG9lcyBvbmUgY29weSB0aGUgZGF0YSBmcm9tIDxy
dW5uaW5nPiB0byBlLmcuIDxzdGFydHVwPiB1c2luZyB0aGUgbWVjaGFuaXNtcyBSRVNUQ09ORiBo
YXMgZGVmaW5lZCBpbiBSRkMgODA0MD8gRnJvbSByZWFkaW5nIHRoZSBSRkMgaXQgc2VlbXMgaXMg
b3V0IG9mIHNjb3BlIG9mIFJGQyA4MDQwIGJ1dCBpcyB0aGlzIHJlYWxseSBpbnRlbmRlZD8NCg0K
ICAgICAgICAgICAgICAgSW1wbGVtZW50aW5nIGlldGYtbmV0Y29uZi55YW5nIG9mIGNvdXJzZSBj
b3VsZCBiZSBhbiBvcHRpb24uDQoNCkkgYWdyZWUgdGhhdCB0aGlzIGlzbid0IHJlYWxseSBzcGVj
aWZpZWQuDQoNCklJUkMgb3VyIGluaXRpYWwgZm9jdXMgd2FzIHRvIGVmZmVjdGl2ZWx5IGdldCBw
YXJpdHkgd2l0aCBSRkMgODA0MC4gIEkuZS4gbXkgd29ya2luZyBhc3N1bXB0aW9uIGlzIHRoYXQg
PGNhbmRpZGF0ZT4gKGlmIHByZXNlbnQpIHdvdWxkIGJlIGhhbmRsZWQgYXV0b21hdGljYWxseSBh
bmQgc2ltaWxhcmx5IHVwZGF0ZXMgdG8gPHN0YXJ0dXA+IHdvdWxkIGJlIGhhbmRsZWQgYXV0b21h
dGljYWxseS4gIEUuZy4gYnJvYWRseSBlcXVpdmFsZW50IHRvIHRoZSAvZGF0YSByZXNvdXJjZSBp
biBSRVNUQ09ORi4gIFNvIGluIGVzc2VuY2UgdGhpcyBib2lscyBkb3duIHRvIGNsaWVudHMgaW50
ZXJhY3Rpbmcgd2l0aCAvZHMvaWV0Zi1kYXRhc3RvcmVzOnJ1bm5pbmcsIC9kcy9pZXRmLWRhdGFz
dG9yZXM6b3BlcmF0aW9uYWwgYW5kIC9kcy9pZXRmLWRhdGFzdG9yZXM6aW50ZW5kZWQuICBObyBu
ZXcgUkVTVENPTkYgb3BlcmF0aW9ucyBzaG91bGQgYmUgbmVjZXNzYXJ5IGhlcmUuDQoNCkknbSBh
bHNvIG5vdCByZWFsbHkgY29udmluY2VkIHRoYXQgaW5kZXBlbmRlbnRseSBjb250cm9sbGFibGUg
PHN0YXJ0dXA+IGFuZCA8Y2FuZGlkYXRlPiBpcyByZWFsbHkgYSBncmVhdCBpZGVhLg0KDQpHaXZl
biB0aGF0IDxydW5uaW5nPiBpcyBtZWFudCB0byByZXByZXNlbnQgcGVyc2lzdGVudCBjb25maWd1
cmF0aW9uLCB0aGVuIGF1dG9tYXRpY2FsbHkgdXBkYXRpbmcgPHN0YXJ0dXA+IGFzIGEgc2lkZSBl
ZmZlY3Qgb2YgdXBkYXRpbmcgPHJ1bm5pbmc+IHNlZW1zIGxpa2UgdGhlIG1vc3Qgc2Vuc2libGUg
YmVoYXZpb3IuICBJZiB0aGUgZGVzaXJlIGlzIGZvciBzb21lIGVwaGVtZXJhbCB0eXBlIGNvbmZp
Z3VyYXRpb24gdGhlbiB0aGF0IHdvdWxkIGJlIGJldHRlciBtb2RlbGVkIHZpYSBhbiBleHBsaWNp
dCBkeW5hbWljIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlIChlLmcuIGEgYml0IGxpa2Ugd2hhdCBJ
MlJTIHdlcmUgdHJ5aW5nIHRvIGRvKS4NCg0KU2ltaWxhcmx5LCBpbnN0ZWFkIG9mIGEgc2hhcmVk
IGNhbmRpZGF0ZSBkYXRhc3RvcmUsIHRoZXJlIGlzIHNvbWUgd29yayBpbnZlc3RpZ2F0aW5nIHBy
aXZhdGUgY2FuZGlkYXRlIGRhdGFzdG9yZXMuICBkcmFmdC1saG90a2EtbmV0Y29uZi1yZXN0Y29u
Zi10cmFuc2FjdGlvbnMtMDAgZ2l2ZXMgc29tZSBpZGVhcyBvZiB3aGF0IHRoaXMgY291bGQgbG9v
ayBsaWtlLCBidXQgZnVydGhlciB3b3JrIGlzIHJlcXVpcmVkLg0KDQpJZiB0aGVyZSBpcyBhIHN0
cm9uZyByZXF1aXJlbWVudCB0byBhbGxvdyBmdWxsIGV4cGxpY2l0IG1hbmlwdWxhdGlvbiBvZiBj
b25maWd1cmF0aW9uIGRhdGFzdG9yZXMgdGhlbiBJIHRoaW5rIHRoYXQgd2Ugc2hvdWxkIHByb2Jh
Ymx5IGRlZmluZSBleHBsaWNpdCBSUENzIGZvciB0aGVzZSBvcGVyYXRpb25zIChtb2RlbGVkIG9u
IHRoZSBORVRDT05GIG9uZXMpLiAgSWRlYWxseSwgdGhlc2UgY291bGQgYmUgZGVmaW5lZCBpbiBh
IHByb3RvY29sIG5ldXRyYWwgZm9ybWF0IHNvIHRoYXQgdGhleSBjYW4gd29yayB3aXRoIGFueSBZ
QU5HIGJhc2VkIG1hbmFnZW1lbnQgcHJvdG9jb2xzLiAgSW4gdGhlIGludGVyaW0sIHVzaW5nIHRo
ZSBORVRDT05GIFJQQ3MgZnJvbSBSRVNUQ09ORiBzZWVtcyBsaWtlIGEgcmVhc29uYWJsZSBzdG9w
Z2FwIG1lYXN1cmUuDQoNCltNU0VFXTogSSBhZ3JlZSwgdGhpcyB3b3VsZCBiZSBoZWxwZnVsLg0K
DQpCUg0KTWFya3VzDQoNClRoYW5rcywNClJvYg0KDQoNCg0KDQoNClRoYW5rcywNCg0KUm9iDQoN
Cg0KDQoNCg0KMy4gICAgICAgVHlwbyBpbiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j
b20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX3BkZl9kcmFmdC0yRGlldGYtMkRu
ZXRjb25mLTJEbm1kYS0yRHJlc3Rjb25mLTJEMDUmZD1Ed0lCQWcmYz1CZzVYVUxEWlI4R2lPU1NX
Tmxwa0NzUmVQbkdEa0tjSTZvWUw5eHYxTW5RJnI9MlhFS1ZZa1FqbUxIaTJUT0pwMVZTemllTFpW
cWV3SXBqLVJ4bVJnUGZzTSZtPUNESzI4WDhrTzJ3UlZEbGE5N1BfV3FCSWhGM09BemJXU0dFbVRl
TGR4d1Umcz1CU3lZLUdCdXp6RHJ5Nm9JaGctbWd3TUF5U2JoSkVPOUltM1o0UERfY180JmU9IENo
YXB0ZXIgMy4xICJ0aGUgc2VydmVyIHdvdWxkIGltcGxlbWVudCB0aGUgcmVzb3VyY2UgeytyZXN0
Y29uZn0vZHMvZXhhbXBsZS0gZHMtZXBoZW1lcmFsOmRzLWVwaGVtZXJhbC4iDQoNClRoZXJlIGlz
IGEgc3BhY2UgaW4gYmV0d2VlbiAiZXhhbXBsZS0iIGFuZCAiZHMtZXBoZW1lcmFsOmRzLWVwaGVt
ZXJhbCIuDQoNCkxldHMgaG9wZSB3ZSBnZXQgdGhpcyBmaXhlZCB3aXRoIHRoZSBoZWxwIG9mIHRo
ZSBSRkMgZWRpdG9yLg0KDQoNCg0KL2pzDQoNCg0KDQotLQ0KDQpKdWVyZ2VuIFNjaG9lbndhZWxk
ZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KDQpQaG9uZTogKzQ5
IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJt
YW55DQoNCkZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vdXJsZGVmZW5z
ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmphY29icy0yRHVuaXZlcnNp
dHkuZGVfJmQ9RHdJQkFnJmM9Qmc1WFVMRFpSOEdpT1NTV05scGtDc1JlUG5HRGtLY0k2b1lMOXh2
MU1uUSZyPTJYRUtWWWtRam1MSGkyVE9KcDFWU3ppZUxaVnFld0lwai1SeG1SZ1Bmc00mbT1DREsy
OFg4a08yd1JWRGxhOTdQX1dxQkloRjNPQXpiV1NHRW1UZUxkeHdVJnM9dzM4c2VXaTZGTjQ4T2pQ
ZkpuOTItLWVtaTNyRXpFaURUSHNLTHhFbnNyZyZlPT48aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m
cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuamFjb2JzLTJEdW5pdmVyc2l0eS5kZV8m
ZD1Ed0lCQWcmYz1CZzVYVUxEWlI4R2lPU1NXTmxwa0NzUmVQbkdEa0tjSTZvWUw5eHYxTW5RJnI9
MlhFS1ZZa1FqbUxIaTJUT0pwMVZTemllTFpWcWV3SXBqLVJ4bVJnUGZzTSZtPUNESzI4WDhrTzJ3
UlZEbGE5N1BfV3FCSWhGM09BemJXU0dFbVRlTGR4d1Umcz13MzhzZVdpNkZONDhPalBmSm45Mi0t
ZW1pM3JFekVpRFRIc0tMeEVuc3JnJmU9Pg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KDQpuZXRtb2QgbWFpbGluZyBsaXN0DQoNCm5ldG1vZEBpZXRm
Lm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zw
b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsDQoNCm1hbl9saXN0
aW5mb19uZXRtb2QmZD1Ed0lEYVEmYz1CZzVYVUxEWlI4R2lPU1NXTmxwa0NzUmVQbkdEa0tjSTZv
WUw5eHYNCg0KMU1uUSZyPTJYRUtWWWtRam1MSGkyVE9KcDFWU3ppZUxaVnFld0lwai1SeG1SZ1Bm
c00mbT1UclBNVlhRNUlvdkZtMDhCUw0KDQpiYlhhMkUtSG5TT195ekhSeTBHUjlkalQyTSZzPXNk
MTFvbkhBNDJPRG55c3o5Wk9JWmlrV1dRTUhrSHdVU2VMLWxOV2NrDQoNCkRFJmU9DQoNCg0KDQoq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqDQoNCkRJU0NMQUlNRVI6DQoNClByaXZpbGVnZWQgYW5kL29yIENvbmZpZGVu
dGlhbCBpbmZvcm1hdGlvbiBtYXkgYmUgY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZS4gSWYgeW91
IGFyZSBub3QgdGhlIGFkZHJlc3NlZSBvZiB0aGlzIG1lc3NhZ2UsIHlvdSBtYXkgbm90IGNvcHks
IHVzZSBvciBkZWxpdmVyIHRoaXMgbWVzc2FnZSB0byBhbnlvbmUuIEluIHN1Y2ggZXZlbnQsIHlv
dSBzaG91bGQgZGVzdHJveSB0aGUgbWVzc2FnZSBhbmQga2luZGx5IG5vdGlmeSB0aGUgc2VuZGVy
IGJ5IHJlcGx5IGUtbWFpbC4gSXQgaXMgdW5kZXJzdG9vZCB0aGF0IG9waW5pb25zIG9yIGNvbmNs
dXNpb25zIHRoYXQgZG8gbm90IHJlbGF0ZSB0byB0aGUgb2ZmaWNpYWwgYnVzaW5lc3Mgb2YgdGhl
IGNvbXBhbnkgYXJlIG5laXRoZXIgZ2l2ZW4gbm9yIGVuZG9yc2VkIGJ5IHRoZSBjb21wYW55LiBU
aGFuayBZb3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpESVNDTEFJTUVS
Og0KUHJpdmlsZWdlZCBhbmQvb3IgQ29uZmlkZW50aWFsIGluZm9ybWF0aW9uIG1heSBiZSBjb250
YWluZWQgaW4gdGhpcyBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUgYWRkcmVzc2VlIG9mIHRo
aXMgbWVzc2FnZSwgeW91IG1heSBub3QgY29weSwgdXNlIG9yIGRlbGl2ZXIgdGhpcyBtZXNzYWdl
IHRvIGFueW9uZS4gSW4gc3VjaCBldmVudCwgeW91IHNob3VsZCBkZXN0cm95IHRoZSBtZXNzYWdl
IGFuZCBraW5kbHkgbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVwbHkgZS1tYWlsLiBJdCBpcyB1bmRl
cnN0b29kIHRoYXQgb3BpbmlvbnMgb3IgY29uY2x1c2lvbnMgdGhhdCBkbyBub3QgcmVsYXRlIHRv
IHRoZSBvZmZpY2lhbCBidXNpbmVzcyBvZiB0aGUgY29tcGFueSBhcmUgbmVpdGhlciBnaXZlbiBu
b3IgZW5kb3JzZWQgYnkgdGhlIGNvbXBhbnkuIFRoYW5rIFlvdS4NCgoqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCkRJ
U0NMQUlNRVI6ClByaXZpbGVnZWQgYW5kL29yIENvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBtYXkg
YmUgY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGFkZHJlc3Nl
ZSBvZiB0aGlzIG1lc3NhZ2UsIHlvdSBtYXkgbm90IGNvcHksIHVzZSBvciBkZWxpdmVyIHRoaXMg
bWVzc2FnZSB0byBhbnlvbmUuIEluIHN1Y2ggZXZlbnQsIHlvdSBzaG91bGQgZGVzdHJveSB0aGUg
bWVzc2FnZSBhbmQga2luZGx5IG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJlcGx5IGUtbWFpbC4gSXQg
aXMgdW5kZXJzdG9vZCB0aGF0IG9waW5pb25zIG9yIGNvbmNsdXNpb25zIHRoYXQgZG8gbm90IHJl
bGF0ZSB0byB0aGUgb2ZmaWNpYWwgYnVzaW5lc3Mgb2YgdGhlIGNvbXBhbnkgYXJlIG5laXRoZXIg
Z2l2ZW4gbm9yIGVuZG9yc2VkIGJ5IHRoZSBjb21wYW55LiBUaGFuayBZb3UuCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp
ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7
YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0
I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9PC9zdHlsZT48IVtl
bmRpZl0tLT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg
NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FsaWJyaSBM
aWdodCI7DQoJcGFub3NlLTE6MiAxNSAzIDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm
b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAy
IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291cmllciBOZXcgXDtjb2xv
clw6XCMxRjQ5N0QiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUg
RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN
Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw
dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiOw0KCWNvbG9yOmJsYWNr
O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw
YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y
OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207
DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt
c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjsNCglj
b2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s
aW5rOiJIVE1MIFZvcmZvcm1hdGllcnQgWmNobiI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO
ZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uSFRNTFZvcmZvcm1hdGllcnRaY2huDQoJe21zby1z
dHlsZS1uYW1lOiJIVE1MIFZvcmZvcm1hdGllcnQgWmNobiI7DQoJbXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFZvcmZvcm1hdGllcnQiOw0KCWZvbnQtZmFtaWx5
OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFnZTIwDQoJ
e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UyMQ0KCXtt
c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh
bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv
bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAyLjBj
bSA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyog
TGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MzEzODAyOTYzOw0K
CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNjg1MzQ2NzMw
IC0yNTYxMTI5MTYgNjc1Njc2MTkgNjc1Njc2MjEgNjc1Njc2MTcgNjc1Njc2MTkgNjc1Njc2MjEg
Njc1Njc2MTcgNjc1Njc2MTkgNjc1Njc2MjE7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZl
bC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2
ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpA
bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s
ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl
ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv
dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6
YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN
Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN
Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1u
dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh
Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k
ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXtt
c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t
bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ
dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0
IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt
cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk
aW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0
Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t
bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250
LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y
bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l
Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0
Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1s
ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl
dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl
eHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdp
bi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEt
LVtpZiBndGUgbXNvIDldPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48IVtlbmRpZl0t
LT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJERSIgbGluaz0iYmx1ZSIg
dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFuayB5b3UgdmVyeSBtdWNoIFJv
YmVydC4gWW91ciBhbnN3ZXJzIGFyZSByZWFsbHkgaGVscGZ1bC48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t
VVMiPkJSPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn
ZTpFTi1VUyI+TWFya3VzPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz
dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk
aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij5Wb246PC9zcGFuPjwvYj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IFJvYmVydCBXaWx0b24g
W21haWx0bzpyd2lsdG9uQGNpc2NvLmNvbV0NCjxicj4NCjxiPkdlc2VuZGV0OjwvYj4gTWl0dHdv
Y2gsIDEyLiBEZXplbWJlciAyMDE4IDE2OjEwPGJyPg0KPGI+QW46PC9iPiBTZWVob2ZlciwgTWFy
a3VzOyBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8Yj5CZXRyZWZmOjwvYj4gW0VYVEVSTkFMXSBSZTog
QVc6IFJlOiBBVzogW25ldG1vZF0gUmU6IFF1ZXN0aW9uIG9uIFJGQzgzNDIgJiM0MzsgUkVTVENP
TkYgZXh0ZW5zaW9uIChkcmFmdC1pZXRmLW5ldGNvbmYtbm1kYS1yZXN0Y29uZik8L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPGRpdj4NCjxwPjxiPiZuYnNwOzwvYj48L3A+DQo8L2Rpdj4NCjxwPkhpIE1hcmt1cyw8
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTIvMTIvMjAxOCAxNDo0MCwgU2Vl
aG9mZXIsIE1hcmt1cyB3cm90ZTo8L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu
Z3VhZ2U6RU4tVVMiPkhlbGxvIFJvYmVydCw8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt
bGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt
IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPlZvbjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0Ij4gUm9iZXJ0IFdpbHRvbiBbPGEgaHJlZj0ibWFp
bHRvOnJ3aWx0b25AY2lzY28uY29tIj5tYWlsdG86cndpbHRvbkBjaXNjby5jb208L2E+XQ0KPGJy
Pg0KPGI+R2VzZW5kZXQ6PC9iPiBNaXR0d29jaCwgMTIuIERlemVtYmVyIDIwMTggMTE6MjE8YnI+
DQo8Yj5Bbjo8L2I+IFNlZWhvZmVyLCBNYXJrdXM7IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0
Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5CZXRyZWZmOjwvYj4gW0VYVEVSTkFM
XSBSZTogQVc6IFtuZXRtb2RdIFJlOiBRdWVzdGlvbiBvbiBSRkM4MzQyICYjNDM7IFJFU1RDT05G
IGV4dGVuc2lvbiAoZHJhZnQtaWV0Zi1uZXRjb25mLW5tZGEtcmVzdGNvbmYpPC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8ZGl2Pg0K
PHA+PGI+Jm5ic3A7PC9iPjwvcD4NCjwvZGl2Pg0KPHA+SGkgTWFya3VzLDwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMS8xMi8yMDE4IDE3OjIxLCBTZWVob2ZlciwgTWFya3Vz
IHdyb3RlOjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPkhlbGxvIFJvYmVydCw8L3ByZT4NCjxwcmU+Jm5i
c3A7PC9wcmU+DQo8cHJlPmNvbW1lbnRzIGlubGluZSBiZWxvdy48L3ByZT4NCjxwcmU+Jm5ic3A7
PC9wcmU+DQo8cHJlPkJSPC9wcmU+DQo8cHJlPiBNYXJrdXMgPC9wcmU+DQo8cHJlPiZuYnNwOzwv
cHJlPg0KPHByZT4tLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tPC9wcmU+DQo8cHJl
PlZvbjogUm9iZXJ0IFdpbHRvbiBbPGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIj5t
YWlsdG86cndpbHRvbkBjaXNjby5jb208L2E+XSA8L3ByZT4NCjxwcmU+R2VzZW5kZXQ6IERpZW5z
dGFnLCAxMS4gRGV6ZW1iZXIgMjAxOCAxNzowNjwvcHJlPg0KPHByZT5BbjogU2VlaG9mZXIsIE1h
cmt1czwvcHJlPg0KPHByZT5DYzogPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0
bW9kQGlldGYub3JnPC9hPjwvcHJlPg0KPHByZT5CZXRyZWZmOiBSZTogW25ldG1vZF0gW0VYVEVS
TkFMXSBSZTogUXVlc3Rpb24gb24gUkZDODM0MiAmIzQzOyBSRVNUQ09ORiBleHRlbnNpb24gKGRy
YWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJlc3Rjb25mKTwvcHJlPg0KPHByZT4mbmJzcDs8L3ByZT4N
CjxwcmU+SGkgU2VlaG9mZXIsPC9wcmU+DQo8cHJlPiZuYnNwOzwvcHJlPg0KPHByZT5QbGVhc2Ug
c2VlIGlubGluZSAuLi48L3ByZT4NCjxwcmU+Jm5ic3A7PC9wcmU+DQo8cHJlPk9uIDExLzEyLzIw
MTggMTQ6NTUsIFNlZWhvZmVyLCBNYXJrdXMgd3JvdGU6PC9wcmU+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+SGVsbG8gSnVl
cmdlbiw8L3ByZT4NCjxwcmU+Jm5ic3A7PC9wcmU+DQo8cHJlPnNlZSBteSBjb21tZW50cyBpbmxp
bmUgYmVsb3cuIEFzIGJlaW5nIHF1aXRlIG5ldyB0byB0aGUgdG9waWMsIGdvaW5nIHRocm91Z2gg
YWxsIHRoZSBvbGQgYW5kIGN1cnJlbnQgUkZDcyBhbmQgZHJhZnRzIGlzIHF1aXRlIGNoYWxsZW5n
aW5nLjwvcHJlPg0KPHByZT5TbyBwbGVhc2UgYXBvbG9naXplIGZvciAmcXVvdDtzaW1wbGUmcXVv
dDsgcXVlc3Rpb25zIG9yIG9uZXMgbWF5YmUgYWxyZWFkeSByYWlzZWQuPC9wcmU+DQo8cHJlPiZu
YnNwOzwvcHJlPg0KPHByZT4tLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tPC9wcmU+
DQo8cHJlPlZvbjogSnVlcmdlbiBTY2hvZW53YWVsZGVyIDwvcHJlPg0KPHByZT5bPGEgaHJlZj0i
bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSI+bWFpbHRvOmouc2No
b2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT5dPC9wcmU+DQo8cHJlPkdlc2VuZGV0
OiBEaWVuc3RhZywgMTEuIERlemVtYmVyIDIwMTggMTU6MzM8L3ByZT4NCjxwcmU+QW46IFNlZWhv
ZmVyLCBNYXJrdXM8L3ByZT4NCjxwcmU+Q2M6IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5v
cmciPm5ldG1vZEBpZXRmLm9yZzwvYT48L3ByZT4NCjxwcmU+QmV0cmVmZjogW0VYVEVSTkFMXSBS
ZTogW25ldG1vZF0gUXVlc3Rpb24gb24gUkZDODM0MiAmIzQzOyBSRVNUQ09ORiA8L3ByZT4NCjxw
cmU+ZXh0ZW5zaW9uIChkcmFmdC1pZXRmLW5ldGNvbmYtbm1kYS1yZXN0Y29uZik8L3ByZT4NCjxw
cmU+Jm5ic3A7PC9wcmU+DQo8cHJlPiZuYnNwOzwvcHJlPg0KPHByZT4mbmJzcDs8L3ByZT4NCjxw
cmU+T24gVHVlLCBEZWMgMTEsIDIwMTggYXQgMDI6MTc6MDdQTSAmIzQzOzAwMDAsIFNlZWhvZmVy
LCBNYXJrdXMgd3JvdGU6PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw
dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+SGVsbG8sPC9wcmU+DQo8cHJlPiZuYnNwOzwv
cHJlPg0KPHByZT5SZWFkaW5nIFJGQyA4MzQyIGFsb25nIHdpdGggZHJhZnQtaWV0Zi1uZXRjb25m
LW5tZGEtcmVzdGNvbmYtMDUgSSd2ZSBzb21lIHF1ZXN0aW9ucyBvciBjb21wcmVoZW5zaW9uIHBy
b2JsZW1zIHdpdGggdGhlIHRleHQuPC9wcmU+DQo8cHJlPiZuYnNwOzwvcHJlPg0KPHByZT4mbmJz
cDs8L3ByZT4NCjxwcmU+MS4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUkZD
IDgzNDIgKE5NREEpPC9wcmU+DQo8cHJlPkNoYXB0ZXIgNS4zLiZuYnNwOyBUaGUgT3BlcmF0aW9u
YWwgU3RhdGUgRGF0YXN0b3JlICgmbHQ7b3BlcmF0aW9uYWwmZ3Q7KSBzYXlzOjwvcHJlPg0KPHBy
ZT4mcXVvdDtUaGUgb3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlICgmbHQ7b3BlcmF0aW9uYWwm
Z3Q7KSBpcyBhIHJlYWQtb25seSBkYXRhc3RvcmUgLi4uLiZxdW90OzwvcHJlPg0KPHByZT5DaGFw
dGVyIDYuMi4gSW52b2NhdGlvbiBvZiBBY3Rpb25zIGFuZCBSUENzIHNheXM6PC9wcmU+DQo8cHJl
PiZxdW90O0FjdGlvbnMgYXJlIGFsd2F5cyBpbnZva2VkIGluIHRoZSBjb250ZXh0IG9mIHRoZSBv
cGVyYXRpb25hbCBzdGF0ZSBkYXRhc3RvcmUuIFRoZSBub2RlIGZvciB3aGljaCB0aGUgYWN0aW9u
IGlzIGludm9rZWQgTVVTVCBleGlzdCBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0b3Jl
LiZxdW90OzwvcHJlPg0KPHByZT4mbmJzcDs8L3ByZT4NCjxwcmU+Q2hhcHRlciAzLjEgaW4gPGEg
aHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB
X190b29scy5pZXRmLm9yZ19wZGZfZHJhZnQtMkRpZXRmLTJEbmV0Y29uZi0yRG5tZGEtMkRyZXN0
Y29uZi0yRDA1JmFtcDtkPUR3SUJBZyZhbXA7Yz1CZzVYVUxEWlI4R2lPU1NXTmxwa0NzUmVQbkdE
a0tjSTZvWUw5eHYxTW5RJmFtcDtyPTJYRUtWWWtRam1MSGkyVE9KcDFWU3ppZUxaVnFld0lwai1S
eG1SZ1Bmc00mYW1wO209Q0RLMjhYOGtPMndSVkRsYTk3UF9XcUJJaEYzT0F6YldTR0VtVGVMZHh3
VSZhbXA7cz1CU3lZLUdCdXp6RHJ5Nm9JaGctbWd3TUF5U2JoSkVPOUltM1o0UERfY180JmFtcDtl
PSI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190
b29scy5pZXRmLm9yZ19wZGZfZHJhZnQtMkRpZXRmLTJEbmV0Y29uZi0yRG5tZGEtMkRyZXN0Y29u
Zi0yRDA1JmFtcDtkPUR3SUJBZyZhbXA7Yz1CZzVYVUxEWlI4R2lPU1NXTmxwa0NzUmVQbkdEa0tj
STZvWUw5eHYxTW5RJmFtcDtyPTJYRUtWWWtRam1MSGkyVE9KcDFWU3ppZUxaVnFld0lwai1SeG1S
Z1Bmc00mYW1wO209Q0RLMjhYOGtPMndSVkRsYTk3UF9XcUJJaEYzT0F6YldTR0VtVGVMZHh3VSZh
bXA7cz1CU3lZLUdCdXp6RHJ5Nm9JaGctbWd3TUF5U2JoSkVPOUltM1o0UERfY180JmFtcDtlPTwv
YT4gc2F5czo8L3ByZT4NCjxwcmU+JnF1b3Q7WUFORyBhY3Rpb25zIGNhbiBvbmx5IGJlIGludm9r
ZWQgaW4geyYjNDM7cmVzdGNvbmZ9L2RzL2lldGYtZGF0YXN0b3JlczpvcGVyYXRpb25hbC4mcXVv
dDs8L3ByZT4NCjxwcmU+Jm5ic3A7PC9wcmU+DQo8cHJlPlF1ZXN0aW9uOiBIb3cgY2FuIG9uZSBp
bnZva2UgYW4gYWN0aW9uIGluIGEgYXMgcmVhZC1vbmx5IGRlZmluZWQgZGF0YXN0b3JlPyBPciBh
bSBJIG1pc3Npbmcgc29tZXRoaW5nPzwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5XaHkgZG8g
eW91IGV4cGVjdCB0aGF0IGEgZGF0YXN0b3JlIGhhcyB0byBiZSB3cml0YWJsZSBpbiBvcmRlciB0
byA8L3ByZT4NCjxwcmU+aW52b2tlIGFuIGFjdGlvbj8gUkZDIDc5NTAgaGFzIHRoZSBleGFtcGxl
IG9mIGEgcGluZyBhY3Rpb24gdGllZCB0byBhbiA8L3ByZT4NCjxwcmU+aW50ZXJmYWNlLiAoWW91
IHBpbmcgYSByZW1vdGUgc3lzdGVtIGZyb20gdGhhdCBzcGVjaWZpYyBpbnRlcmZhY2UuKSBJbiA8
L3ByZT4NCjxwcmU+Z2VuZXJhbCwgYWN0aW9ucyBhcmUgdW5kZXJzdG9vZCBhcyBiZWluZyB0aWVk
IHRvIHJlYWwgcmVzb3VyY2VzIGFuZCA8L3ByZT4NCjxwcmU+aGVuY2UgdG8gdGhlIG9wZXJhdGlv
bmFsIGRhdGFzdG9yZS4gKEZvciBleGFtcGxlLCB5b3UgY2FuJ3QgcGluZyBmcm9tIDwvcHJlPg0K
PHByZT5hbiBpbnRlcmZhY2UgdGhhdCBpcyBjb25maWd1cmVkIGJ1dCBub3QgcGh5c2ljYWxseSBw
cmVzZW50Lik8L3ByZT4NCjxwcmU+Jm5ic3A7PC9wcmU+DQo8cHJlPltNU0VFXTogSSBkbyBub3Qg
ZXhwZWN0IHRoYXQgYSBkYXRhc3RvcmUgaGFzIHRvIGJlIHdyaXRlYWJsZSB0byBpbnZva2UgYW4g
YWN0aW9uLCBidXQgSSBkbyBleHBlY3QgdGhhdCBhICZxdW90O3JlYWQtb25seSZxdW90OyBkYXRh
c3RvcmUgaXMgbm90IHdyaXRlYWJsZSBhbmQgUkZDIDgzNDIgc2F5cyBjbGVhcmx5IG9wZXJhdGlv
bmFsIHN0YXRlIGRhdGFzdG9yZSBpcyAmcXVvdDtyZWFkLW9ubHkmcXVvdDsuPC9wcmU+DQo8L2Js
b2NrcXVvdGU+DQo8cHJlPiZuYnNwOzwvcHJlPg0KPHByZT5SUENzIGFuZCBhY3Rpb25zIGRvbid0
IG1vZGlmeSB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlIGFzIHN1Y2gsIGluc3RlYWQg
dGhleSBtb2RpZnkgdGhlIHByb3BlcnRpZXMgb2YgdGhlIHVuZGVybHlpbmcgc3lzdGVtLCBhbmQg
dGhlIG9wZXJhdGlvbmFsIHN0YXRlIGRhdGFzdG9yZSBwcm92aWRlcyBhIHJlYWQtb25seSB2aWV3
IG9udG8gdGhlIHN0YXRlIG9mIHRoZSBzeXN0ZW0uJm5ic3A7IFNvICZsdDtvcGVyYXRpb25hbCZn
dDsgaXMgb25seSBiZWluZyB1cGRhdGVkIGFzIGEgc2lkZSBlZmZlY3Qgb2YgcmVmbGVjdGluZyB0
aGUgY2hhbmdlcyB0byB0aGUgdW5kZXJseWluZyBzeXN0ZW0uPC9wcmU+DQo8cHJlPiZuYnNwOzwv
cHJlPg0KPHByZT5UaGlzIGNvbnRyYXN0cyB3aXRoIHdyaXRhYmxlIGNvbmZpZ3VyYXRpb24gZGF0
YXN0b3JlcyAoZS5nLiAmbHQ7Y2FuZGlkYXRlJmd0OyBvciAmbHQ7cnVubmluZyZndDspLCB3aGVy
ZSB0aGUgY2xpZW50IGNhbiBtb2RpZnkgdGhlIGNvbmZpZ3VyYXRpb24gaW4gdGhvc2UgZGF0YXN0
b3JlcyBkaXJlY3RseSB3aGljaCB3aWxsIHRoZW4gYXR0ZW1wdCB0byBjaGFuZ2UgdGhlIGJlaGF2
aW9yIG9mIHRoZSBzeXN0ZW0gYXMgdGhlIGNvbmZpZyBpcyBhcHBsaWVkLjwvcHJlPg0KPHByZT4m
bmJzcDs8L3ByZT4NCjxwcmU+W01TRUVdOiBJIGFncmVlIGJ1dCBJJ20gc3RpbGwgc3R1Y2sgd2l0
aCB0aGUgZm9sbG93aW5nIHRleHQuPC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyAtIGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJlc3Rjb25mLTA1IHNheXMgaW4gQ2hhcHRl
ciAzLjE6ICZxdW90O1lBTkcgYWN0aW9ucyBjYW4gb25seSBiZSBpbnZva2VkIGluIHsmIzQzO3Jl
c3Rjb25mfS9kcy9pZXRmLWRhdGFzdG9yZXM6b3BlcmF0aW9uYWwmcXVvdDsgd2l0aDwvcHJlPg0K
PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7
VGhlIHJlc291cmNlIHsmIzQzO3Jlc3Rjb25mfS9kcy9pZXRmLWRhdGFzdG9yZXM6b3BlcmF0aW9u
YWwgcmVmZXJzIHRvIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBkYXRhc3RvcmUmcXVvdDsgYW5kICZx
dW90O1RoZSBvcGVyYXRpb25hbCBzdGF0ZSBkYXRhc3RvcmUgKCZsdDtvcGVyYXRpb25hbCZndDsp
IGlzIGEgcmVhZC1vbmx5IGRhdGFzdG9yZSZxdW90OzwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgLSBSRkMgODA0MCBzYXlzIGluIENoYXB0ZXIgMy42ICZxdW90OyBPcGVy
YXRpb24gcmVzb3VyY2VzIHJlcHJlc2VudGluZyBZQU5HIGFjdGlvbnMgYXJlIG5vdCBpZGVudGlm
aWVkIGluIHRoaXMgc3VidHJlZSwgc2luY2UgdGhleSBhcmUgaW52b2tlZCB1c2luZyBhIFVSSSB3
aXRoaW4gdGhlICd7JiM0MztyZXN0Y29uZn0vZGF0YScgc3VidHJlZSZxdW90OyBhbmQ8L3ByZT4N
CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90O0FuIGFj
dGlvbiBpcyBpbnZva2VkIGFzOiBQT1NUIHsmIzQzO3Jlc3Rjb25mfS9kYXRhLyZsdDtkYXRhLXJl
c291cmNlLWlkZW50aWZpZXImZ3Q7LyZsdDthY3Rpb24mZ3Q7JnF1b3Q7PC9wcmU+DQo8cHJlPiZu
YnNwOzwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU28gd2l0aG91dCBO
TURBIGl0IHdhcyBjbGVhciwgaW52b2tlIGFuIGFjdGlvbiB1c2luZyB7JiM0MztyZXN0Y29uZn0v
ZGF0YX0uIFdpdGggTk1EQSB3aGF0IGlzIHRoZSBjb3JyZWN0IHdheSB0byB0cmlnZ2VyIGFuIGFj
dGlvbiBhcyB0aGUgZHJhZnQgc2F5cyAmcXVvdDtZQU5HIGFjdGlvbnMgY2FuIG9ubHkgYmUgaW52
b2tlZCBpbiB7JiM0MztyZXN0Y29uZn0vZHMvaWV0Zi1kYXRhc3RvcmVzOm9wZXJhdGlvbmFsJnF1
b3Q7PzwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHA+U28sIHlvdSBpbnZva2UgaXQgb24gdGhlIGVx
dWl2YWxlbnQgcGF0aCB1c2luZyB0aGUgb3BlcmF0aW9uYWwgZGF0YXN0b3JlLjwvcD4NCjxwPkUu
Zy4gdG8gdGFrZSB0aGUgZXhhbXBsZSBmcm9tIFJGQyA4MDQwIDMuNi4yLCB0aGUgcmVxdWVzdCBw
cmUgTk1EQSBpcyB0aGlzOiA8L3A+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6IHBhZ2U7Zm9u
dC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3Jw
aGFuczogMjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOiBpbml0aWFsO3RleHQtZGVjb3JhdGlvbi1j
b2xvcjogaW5pdGlhbDt3b3JkLXNwYWNpbmc6MHB4Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDtQT1NUIC9yZXN0Y29uZi9kYXRhL2V4YW1wbGUtYWN0aW9uczppbnRlcmZhY2Vz
L1w8L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IGludGVyZmFjZT1ldGgwL2dldC1sYXN0LXJlc2V0LXRpbWUgSFRUUC8xLjE8L3ByZT4N
CjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhvc3Q6IGV4YW1wbGUuY29tPC9w
cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBY2NlcHQ6IGFwcGxpY2F0
aW9uL3lhbmctZGF0YSYjNDM7anNvbjwvcHJlPg0KPHA+VGhlIGVxdWl2YWxlbnQgcGF0aCBvbiBh
IE5NREEgc2VydmVyIGlzIHRoaXM6IDwvcD4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTogcGFn
ZTtmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1h
bDtvcnBoYW5zOiAyO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiAyOy13ZWJraXQtdGV4dC1zdHJv
a2Utd2lkdGg6IDBweDt0ZXh0LWRlY29yYXRpb24tc3R5bGU6IGluaXRpYWw7dGV4dC1kZWNvcmF0
aW9uLWNvbG9yOiBpbml0aWFsO3dvcmQtc3BhY2luZzowcHgiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO1BPU1QgL3Jlc3Rjb25mL2RzL2lldGYtZGF0YXN0b3JlczpvcGVyYXRp
b25hbC9cPC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBleGFtcGxlLWFjdGlvbnM6aW50ZXJmYWNlcy9cPC9wcmU+DQo8cHJlPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbnRlcmZhY2U9ZXRo
MC9nZXQtbGFzdC1yZXNldC10aW1lIEhUVFAvMS4xPC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBIb3N0OiBleGFtcGxlLmNvbTwvcHJlPg0KPHByZT4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgJm5ic3A7QWNjZXB0OiBhcHBsaWNhdGlvbi95YW5nLWRhdGEmIzQzO2pz
b248L3ByZT4NCjxwPkkgdGhpbmsgdGhhdCB5b3VyIGNvbmNlcm4gbWlnaHQgYmU6IHdoeSBpcyBp
dCByaWdodC9PSyB0byBpbnZva2UgYSBhY3Rpb24gb24gd2hhdCBpcyBkZWZpbmVkIGFzIGEgcmVh
ZCBvbmx5IHN0cnVjdHVyZT88L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNU0VFXTogJm5ic3A7RXhhY3RseS4gQnkganVzdCBy
ZWFkaW5nICZxdW90O1RoZSBvcGVyYXRpb25hbCBzdGF0ZSBkYXRhc3RvcmUgKCZsdDtvcGVyYXRp
b25hbCZndDspIGlzIGEgcmVhZC1vbmx5IGRhdGFzdG9yZSAuLi4uJnF1b3Q7IG1heSBiZSBjb25m
dXNpbmcuIEkgc3RpbGwgc3RydWdnbGUgd2l0aCB0aGUgdGV4dC48L3NwYW4+PC9wPg0KPC9ibG9j
a3F1b3RlPg0KPHA+Ulc6IEkgZ3Vlc3MgdGhhdCB5b3UgY2FuIHRoaW5rIG9mICZsdDtvcGVyYXRp
b25hbCZndDsganVzdCBiZWluZyBhIHZpZXcgb24gdG8gdGhlIHVuZGVybHlpbmcgc3lzdGVtIHN0
YXRlLiZuYnNwOyBJLmUuIHlvdSBhcmUgYWxsb3dlZCB0byB1c2UgYW4gYWN0aW9uIHRvIG1vZGlm
eSB0aGUgdW5kZXJseWluZyBzdGF0ZSB3aGljaCwgYXMgYSBzaWRlIGVmZmVjdCwgdXBkYXRlcyAm
bHQ7b3BlcmF0aW9uYWwmZ3Q7IChiZWNhdXNlIGl0IGFsd2F5cyByZWZsZWN0cyB0aGUgc3lzdGVt
DQogc3RhdGUpLCBidXQgeW91IGNhbm5vdCB3cml0ZSB0byAmbHQ7b3BlcmF0aW9uYWwmZ3Q7IGFz
IGFuIGF0dGVtcHQgdG8gdXBkYXRlIHRoZSB1bmRlcmx5aW5nIHN5c3RlbSBzdGF0ZS48L3A+DQo8
cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4t
VVMiPlRoZSBhbnN3ZXIgdG8gdGhpcyBpcyB0aGF0IHRoZSBhY3Rpb24gaXNuJ3QgYWN0aW5nIG9u
ICZsdDtvcGVyYXRpb25hbCZndDssIGl0IGlzIGFjdGluZyBvbiB0aGUgdW5kZXJseWluZyBzeXN0
ZW0gYW5kIGhhcyB0aGUgcmVtaXQgdG8gY2hhbmdlIGFueSBvZiB0aGUgc3lzdGVtIGJlaGF2aW9y
Ljwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+SG93ZXZlciwgYmVmb3JlIHRoZSBh
Y3Rpb24gY2FuIGJlIHByb2Nlc3NlZCwgdGhlIHN5c3RlbSBtdXN0IHZhbGlkYXRlIHRoYXQgdGhl
IGRhdGEgbm9kZSB0aGF0IGl0IGlzIGFjdGluZyBvbiBleGlzdHMsIGFuZCB0aGUNCjwvc3Bhbj5w
YXJhbWV0ZXJzIGFyZSB2YWxpZC4mbmJzcDsgVGhpcyB2YWxpZGF0aW9uIGlzIHBlcmZvcm1lZCBh
Z2FpbnN0IHRoZSBzeXN0ZW1zIG9wZXJhdGlvbmFsIHN0YXRlLCBhbmQgaGVuY2UgaXMgdmFsaWRh
dGVkIGFnYWluc3QgJmx0O29wZXJhdGlvbmFsJmd0Oy48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNU0VFXTogSSBhZ3JlZSwg
dGhpcyBvZiBjb3Vyc2UgbWFrZXMgc2Vuc2UgYXMgb25seSB0aGUgJmx0O29wZXJhdGlvbmFsJmd0
OyBkYXRhc3RvcmUgaGFzIHRoZSBpbmZvcm1hdGlvbnMgd2hpY2ggbm9kZXMgYXJlIGluIHVzZSBh
bmQgdGhlcmVmb3JlIGFyZSBhdmFpbGFibGUgZm9yIHVzYWdlLjwvc3Bhbj48L3A+DQo8cD48c3Bh
biBsYW5nPSJFTi1VUyI+QWdhaW4sIGNvbnNpZGVyaW5nIHRoZSBleGFtcGxlIGFib3ZlLCBpdCB3
b3VsZG4ndCBtYWtlIHNlbnNlIHRvIGdldCB0aGUgbGFzdCByZXNldCB0aW1lIG9mIGFuIGludGVy
ZmFjZSB0aGF0IGV4aXN0ZWQgaW4gY29uZmlndXJhdGlvbiwgYW5kIGhlbmNlIHdhcyBwcmVzZW50
IGluICZsdDtydW5uaW5nJmd0Oy8mbHQ7aW50ZW5kZWQmZ3Q7LCBidXQgd2FzIG5vdCBpbiAmbHQ7
b3BlcmF0aW9uYWwmZ3Q7Ljwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltNU0VFXTogWWVzLCBJIGFncmVlLjwvc3Bh
bj48L3A+DQo8cD5JbiBmdXR1cmUgd2UgbWF5IG5lZWQgYWN0aW9ucyB0aGF0IGFyZSB2YWxpZGF0
ZWQgYWdhaW5zdCBvdGhlciBkYXRhc3RvcmVzLCBidXQgd2hlbiB0aGUgYXV0aG9ycyB3ZXJlIGRp
c2N1c3NpbmcgdGhpcyBpdCB3YXMgdW5jbGVhciB3aGV0aGVyIHByb3BlciB1c2UgY2FzZXMgZm9y
IHN1Y2ggYWN0aW9ucyBleGlzdCwgYW5kIGhlbmNlIHdlIGRlY2lkZWQgdGhhdCB0aGlzIGNvdWxk
IGJlIGRlZmVycmVkIHRvIGZ1dHVyZSB3b3JrLCB3aGljaCB3b3VsZA0KIHByZXN1bWFibHkgY29t
ZSBhbG9uZyB3aXRoIGEgY29uY3JldGUgdXNlIGNhc2UuPC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bTVNFRV06IE9LLjwvc3Bh
bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPltNU0VFXTogQWxvbmcgd2l0aCB0aGUgYWJvdmUgcXVlc3Rpb25zIGFuZCBhbnN3
ZXJzL3N0YXRlbWVudHMgKHRoYW5rcyBmb3IgdGhpcykgSSBwcm9iYWJseSBzdGlsbCBoYXZlIG1v
cmUgcXVlc3Rpb25zIHRoYW4gYW5zd2VycyBmcm9tIHJlYWRpbmcgdGhlIFJGQ3MgYW5kIGRyYWZ0
cy48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDot
MTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6
Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh
W2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPkRyYWZ0IGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJlc3Rjb25mLTA1IHNheXM6PGJy
Pg0K4oCcQW4gTk1EQS1jb21wbGlhbnQgc2VydmVyIE1VU1QgaW1wbGVtZW50IHsmIzQzO3Jlc3Rj
b25mfS9kcy9pZXRmLWRhdGFzdG9yZXM6b3BlcmF0aW9uYWwuJm5ic3A7IE90aGVyIGRhdGFzdG9y
ZSByZXNvdXJjZXMgTUFZIGJlIGltcGxlbWVudGVk4oCdLjxicj4NCkRvZXMgdGhpcyBtZWFuIGEg
R0VUIHRvIHsmIzQzO3Jlc3Rjb25mfS9kYXRhfSAod2hpY2ggaXMgc3RpbGwgdmFsaWQpIHJldHVy
bnMgdGhlIHNhbWUgZGF0YSBhcyBhIEdFVCB0byB7JiM0MztyZXN0Y29uZn0vZHMvaWV0Zi1kYXRh
c3RvcmVzOm9wZXJhdGlvbmFsIGlmIGl0IGlzIE5NREEgY29tcGxpYW50Pzwvc3Bhbj48L3A+DQo8
L2Jsb2NrcXVvdGU+DQo8cD5SVzogVGhlIGRlZmluaXRpb24gb2YgeyYjNDM7cmVzdGNvbmZ9L2Rh
dGF9IGhhcyBub3QgY2hhbmdlZCBpbiBhbnkgd2F5LiZuYnNwOyBTbywgdGhlIGNvbnRlbnRzL2Jl
aGF2aW9yIG9mIHsmIzQzO3Jlc3Rjb25mfS9kYXRhfSBzaG91bGQgbWF0Y2ggd2hhdCBpcyBzcGVj
aWZpZWQgYnkgUkZDIDgwNDAuPC9wPg0KPHA+QnV0IHRoaXMgaXMgdHJpY2t5IChiZWNhdXNlIC9k
YXRhIG1peGVzIGludGVuZGVkIGNvbmZpZ3VyYXRpb24gd2l0aCBvcGVyYXRpb25hbCBzdGF0ZSku
PC9wPg0KPHA+SGVuY2UsIEkgd291bGRuJ3QgYmUgc3VycHJpc2VkIGlmIHNvbWUgaW1wbGVtZW50
YXRpb25zIGVpdGhlcjo8YnI+DQooMSkgZG9uJ3QgaW1wbGVtZW50IC9kYXRhIGF0IGFsbCwgb3I8
YnI+DQooMikgaGFuZGxlIERFTEVURS9QT1NUL1BBVENIL1BVVCBvcGVyYXRpb25zIGFzIGlmIHRo
ZSBvcGVyYXRpb24gd2FzIG1hZGUgYWdhaW5zdCB7JiM0MztyZXN0Y29uZn0vZHMvaWV0Zi1kYXRh
c3RvcmVzOnJ1bm5pbmcsIGhhbmRsZSBHRVQgcmVxdWVzdHMgYXMgaWYgdGhleSB0aGUgb3BlcmF0
aW9uIHdhcyBtYWRlIGFnYWluc3Qgb24geyYjNDM7cmVzdGNvbmZ9L2RzL2lldGYtZGF0YXN0b3Jl
czpvcGVyYXRpb25hbC4mbmJzcDsgVGhpcyB3b3VsZCBiZSBub24tc3RhbmRhcmQNCiBiZWhhdmlv
ciB0aG91Z2ggLi4uLjwvcD4NCjxwPkEgZnV0dXJlIHZlcnNpb24gb2YgUkVTVENPTkYsIGFzIG9w
cG9zZWQgdG8gYW4gZXh0ZW5zaW9uIChpLmUuIGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJlc3Rj
b25mLTA1KSwgbWF5IHJlbW92ZSBzdXBwb3J0IGZvciB7JiM0MztyZXN0Y29uZn0vZGF0YX0uPC9w
Pg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w
cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1
cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxz
cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+
PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBzdHlsZT0i
bWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwx
IGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28t
bGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t
YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVT
IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgc3VjaCBhIE5NREEgY29t
cGxpYW50IFJFU1RDT05GIHNlcnZlciBoYXMgZS5nLiDigJxleGFtcGxlLWp1a2Vib3jigJ0gaW1w
bGVtZW50ZWQsIGFyZSBib3RoIG9mIHRoZSBmb2xsb3dpbmcgc3RhdGVtZW50cyBjb3JyZWN0Pzwv
c3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgO2NvbG9yOiMxRjQ5N0QmcXVvdDssJnF1b3Q7
c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQQVRDSCAvcmVzdGNvbmYvZGF0
YS9leGFtcGxlLWp1a2Vib3g6anVrZWJveC9cPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2xpYnJhcnkvYXJ0aXN0PUZvbyUyMEZpZ2h0ZXJzL2Fs
YnVtPVdhc3RpbmclMjBMaWdodCBIVFRQLzEuMTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBIb3N0OiBleGFtcGxlLmNvbTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJZi1NYXRj
aDogJnF1b3Q7YjgzODkyMzNhNGMmcXVvdDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
Q29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi95YW5nLWRhdGEmIzQzO3htbDxicj4NCiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyAmbHQ7YWxidW0geG1sbnM9PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZl
bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX2V4YW1wbGUuY29tX25zX2V4YW1w
bGUtMkRqdWtlYm94JmFtcDtkPUR3TURhUSZhbXA7Yz1CZzVYVUxEWlI4R2lPU1NXTmxwa0NzUmVQ
bkdEa0tjSTZvWUw5eHYxTW5RJmFtcDtyPTJYRUtWWWtRam1MSGkyVE9KcDFWU3ppZUxaVnFld0lw
ai1SeG1SZ1Bmc00mYW1wO209SVFaM2dWYjVTbGtRMFNvckpRZUlHOUQzdHJmUXJOaDJtdFNDU3RY
SmY4VSZhbXA7cz0waWZjamdXRHJnbTJjU1N1aTlFNElRTEhLM3kyZTEtenNySm9fOW9sNlJ3JmFt
cDtlPSI+JnF1b3Q7aHR0cDovL2V4YW1wbGUuY29tL25zL2V4YW1wbGUtanVrZWJveCZxdW90Ozwv
YT4mZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZsdDt5ZWFyJmd0OzIw
MTEmbHQ7L3llYXImZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsvYWxidW0m
Z3Q7PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+YW5kPC9zcGFuPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyA7Y29sb3I6IzFGNDk3RCZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJy
Pg0KPGJyPg0KUEFUQ0ggL3Jlc3Rjb25mL2RzL2lldGYtZGF0YXN0b3JlczpvcGVyYXRpb25hbC9l
eGFtcGxlLWp1a2Vib3g6anVrZWJveC9cPGJyPg0KJm5ic3A7Jm5ic3A7IGxpYnJhcnkvYXJ0aXN0
PUZvbyUyMEZpZ2h0ZXJzL2FsYnVtPVdhc3RpbmclMjBMaWdodCBIVFRQLzEuMTxicj4NCkhvc3Q6
IGV4YW1wbGUuY29tPGJyPg0KSWYtTWF0Y2g6ICZxdW90O2I4Mzg5MjMzYTRjJnF1b3Q7PGJyPg0K
Q29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi95YW5nLWRhdGEmIzQzO3htbDxicj4NCiZsdDthbGJ1
bSB4bWxucz08YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs
P3U9aHR0cC0zQV9fZXhhbXBsZS5jb21fbnNfZXhhbXBsZS0yRGp1a2Vib3gmYW1wO2Q9RHdNRGFR
JmFtcDtjPUJnNVhVTERaUjhHaU9TU1dObHBrQ3NSZVBuR0RrS2NJNm9ZTDl4djFNblEmYW1wO3I9
MlhFS1ZZa1FqbUxIaTJUT0pwMVZTemllTFpWcWV3SXBqLVJ4bVJnUGZzTSZhbXA7bT1JUVozZ1Zi
NVNsa1EwU29ySlFlSUc5RDN0cmZRck5oMm10U0NTdFhKZjhVJmFtcDtzPTBpZmNqZ1dEcmdtMmNT
U3VpOUU0SVFMSEszeTJlMS16c3JKb185b2w2UncmYW1wO2U9Ij4mcXVvdDtodHRwOi8vZXhhbXBs
ZS5jb20vbnMvZXhhbXBsZS1qdWtlYm94JnF1b3Q7PC9hPiZndDs8YnI+DQombHQ7eWVhciZndDsy
MDExJmx0Oy95ZWFyJmd0Ozxicj4NCiZsdDsvYWxidW0mZ3Q7PC9zcGFuPjwvcD4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cD48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi0m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRHJhZnQgZHJhZnQtaWV0
Zi1uZXRjb25mLW5tZGEtcmVzdGNvbmYtMDUgc2F5czo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg4oCcIFlBTkcgYWN0aW9ucyBjYW4g
b25seSBiZSBpbnZva2VkIGluIHsmIzQzO3Jlc3Rjb25mfS9kcy9pZXRmLWRhdGFzdG9yZXM6b3Bl
cmF0aW9uYWzigJ08YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgSW4gc3VjaCBhIE5NREEgY29tcGxpYW50IFJFU1RDT05GIHNlcnZlciwg
aXMgeyYjNDM7cmVzdGNvbmZ9L29wZXJhdGlvbnMgKFJGQzgwNDAgLSAzLjYgT3BlcmF0aW9uIFJl
c291cmNlIClzdGlsbCB2YWxpZD8gQmVjYXVzZSB0aGUgYWJvdmUgc3RhdGVtZW50IHNheXMg4oCc
4oCmY2FuIG9ubHnigKbigJ0gb3IgZG9lcyBvbmUgaGF2ZSB0byB1c2U6PC9zcGFuPjwvcD4NCjwv
YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwPlJXOjwvcD4NCjxw
Pk5vLCB5b3UgY2FuJ3QgUEFUQ0ggYWdhaW5zdCAmbHQ7b3BlcmF0aW9uYWwmZ3Q7LiZuYnNwOyBQ
QVRDSCBpcyBub3QgYSBZQU5HIGFjdGlvbiwgaXQgaXMgYSBSRVNUQ09ORiBtZXRob2QuPC9wPg0K
PHA+SXQgaXMgY292ZXJlZCBieSBkcmFmdC1pZXRmLW5ldGNvbmYtbm1kYS1yZXN0Y29uZi0wNSwg
c2VjdGlvbiAzLjI6PC9wPg0KPGRpdiBzdHlsZT0ibXNvLWVsZW1lbnQ6cGFyYS1ib3JkZXItZGl2
O2JvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6OC4wcHQgOC4wcHQgOC4wcHQgOC4w
cHQ7YmFja2dyb3VuZDojRkZGREY1Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7
YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRp
bmc6MGNtO2JveC1zaXppbmc6IGJvcmRlci1ib3g7b3ZlcmZsb3ctd3JhcDogYnJlYWstd29yZDti
b3JkZXItcmFkaXVzOiA0cHg7Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFy
aWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogMjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjst
d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOiBpbml0
aWFsO3RleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDtvdmVyZmxvdzphdXRvO3dvcmQtc3Bh
Y2luZzowcHgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsmbmJzcDsgbyZu
YnNwOyBTb21lIGRhdGFzdG9yZXMgYXJlIHJlYWQtb25seSBieSBuYXR1cmUgKGUuZy4sICZsdDtp
bnRlbmRlZCZndDspLCBhbmQ8L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tYm90dG9t
OjcuOXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3JkZXI6bm9u
ZTtwYWRkaW5nOjBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBoZW5jZSBhbnkgYXR0ZW1wdCB0byBtb2RpZnkgdGhlc2UgZGF0
YXN0b3JlcyB3aWxsIGZhaWwuJm5ic3A7IEEgc2VydmVyPC9zcGFuPjwvcHJlPg0KPHByZSBzdHls
ZT0ibWFyZ2luLWJvdHRvbTo3LjlwdDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVh
ay1hbGw7Ym9yZGVyOm5vbmU7cGFkZGluZzowY20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
NXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTVVTVCByZXR1cm4gYSByZXNwb25z
ZSB3aXRoIGEgJnF1b3Q7NDA1IE1ldGhvZCBOb3QgQWxsb3dlZCZxdW90OyBzdGF0dXMtbGluZTwv
c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1ib3R0b206Ny45cHQ7YmFja2dyb3VuZDoj
RkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JvcmRlcjpub25lO3BhZGRpbmc6MGNtIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IGFuZCBlcnJvci10YWcgdmFsdWUgJnF1b3Q7b3BlcmF0aW9uLW5vdC1zdXBwb3J0ZWQmcXVvdDsu
PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
UE9TVCB7JiM0MztyZXN0Y29uZn0vZHMvaWV0Zi1kYXRhc3RvcmVzOm9wZXJhdGlvbmFsIC8mbHQ7
b3BlcmF0aW9uJmd0Ozxicj4NCmFuZDxicj4NClBPU1QgeyYjNDM7cmVzdGNvbmZ9L2RzL2lldGYt
ZGF0YXN0b3JlczpvcGVyYXRpb25hbCAvJmx0O2RhdGEtcmVzb3VyY2UtaWRlbnRpZmllciZndDsv
Jmx0O2FjdGlvbiZndDs8YnI+DQpvbiBhIE5NREEgY29tcGxpYW50IHNlcnZlciBvbmx5Pzwvc3Bh
bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cD5Z
b3UgY2FuIG9ubHkgUE9TVCBhZ2FpbnN0IGVkaXRhYmxlIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3Jl
cywgZS5nLiAmbHQ7Y2FuZGlkYXRlJmd0OywgJmx0O3J1bm5pbmcmZ3Q7LCZsdDtzdGFydHVwJmd0
OywgYW5kIG9ubHkgdGhlbiBpZiB0aGUgc2VydmVyIGFsbG93cyB0aGlzLjwvcD4NCjxwPlRoYW5r
cyw8YnI+DQpSb2I8L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg
c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90
ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48
c3BhbiBsYW5nPSJFTi1VUyI+Mi4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
VGhlIE5NREEgaXMgYSBodWdlIHN0ZXAgZm9yd2FyZCBmb3IgTkMgYW5kIFJDLCB0aGFua3MgZm9y
IHRoYXQuIE5NREEgaW4gY29tYmluYXRpb24gd2l0aCB0aGUgbmV3IFJFU1RDT05GIGV4dGVuc2lv
bnMgbGV0IG9uZSBub3cgPC9zcGFuPnNlbGVjdCBvbmUgb2YgdGhlIG5hbWVkIGRhdGFzdG9yZXM8
L3ByZT4NCjxwcmU+aW4gUkZDIDgzNDIuIFJlYWRpbmcgdGhlIFJGQyBhbmQgZHJhZnQgSSdtIHN0
aWxsIG1pc3NpbmcgKG9yIGV2ZW4gbW9yZSBvdmVybG9vayBJIGd1ZXNzKSB0aGUgZm9sbG93aW5n
LiBSRkMgODA0MCBDaGFwdGVyIDQuNSBzYXlzOjwvcHJlPg0KPHByZT4mcXVvdDtBIFBVVCBvbiB0
aGUgZGF0YXN0b3JlIHJlc291cmNlIGlzIHVzZWQgdG8gcmVwbGFjZSB0aGUgZW50aXJlIDwvcHJl
Pg0KPHByZT5jb250ZW50cyBvZiB0aGUgZGF0YXN0b3JlLi4uJnF1b3Q7LiBTbyBkb2VzIHRoaXMg
bWVhbiBvbmUgY2FuIGhhdmUgdGhlIHNhbWUgYmVoYXZpb3IgYXMgaW4gTkVUQ09ORiB3aGVyZSB5
b3UgY2FuIGNvcHkgdGhlICZxdW90O3J1bm5pbmcmcXVvdDsgY29uZmlnIHRvICZxdW90O3N0YXJ0
dXAmcXVvdDsgb3IgJnF1b3Q7Y2FuZGlkYXRlJnF1b3Q7IGNvbmZpZyB0byAmcXVvdDtydW5uaW5n
JnF1b3Q7IGlmIGEgUkVTVENPTkYgc2VydmVyIHdvdWxkIHN1cHBvcnQgdGhlbT8gSXMgdGhlcmUg
YW55IGV4YW1wbGUgaG93IHRoaXMgd291bGQgbG9vayBsaWtlIGlmIGl0IGlzIGFsbG93ZWQ/PC9w
cmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPkEgUFVUIGRvZXMgbm90IHJlYWxseSBnZXQgeW91IHRo
ZXJlLCB0byBjb3B5IGEgZGF0YXN0b3JlIHRvIGFub3RoZXIgeW91IHdhbnQgYW4gb3BlcmF0aW9u
IG9uIHRoZSBzZXJ2ZXIuPC9wcmU+DQo8cHJlPiZuYnNwOzwvcHJlPg0KPHByZT5bTVNFRV06IEV4
YWN0bHkgdGhpcyBpcyB3aGF0IEkgd2FudC4gTkVUQ09ORiBzcGVjaWZpZXMgdGhpcyBjbGVhcmx5
IGluIHRoZSBSRkNzIHdpdGggJmx0O2NvcHktY29uZmlnJmd0OyBidXQgaG93IGRvZXMgb25lIHRy
aWdnZXIgdGhpcyB3aXRoIFJFU1RDT05GPyBJIGhhZCB0aGUgaG9wZSB3aXRoIE5NREEgJiM0Mzsg
UkVTVENPTkYgZXh0ZW5zaW9ucyB0aGlzIHdvdWxkPC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBiZSBwb3NzaWJsZSB0b28uIE9yIGRvIEkgc3RpbGwgbWlzcyBz
b21ldGhpbmc/PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPiZuYnNwOzwvcHJlPg0KPHByZT5J
IHRoaW5rIHRoYXQgaXQgaXMgdGhlb3JldGljYWxseSBwb3NzaWJsZSB0byBpbnZva2UgdGhlIE5F
VENPTkYgUlBDcyAoZS5nLiB0aGUgY29weS1jb25maWcgUlBDIGRlZmluZWQgaW4gaWV0Zi1uZXRj
b25mLnlhbmcsIFJGQyA2MjQxKSBmcm9tIFJFU1RDT05GIChlLmcuIHNlY3Rpb24gMy42IG9mIFJG
QyA4MDQwKS48L3ByZT4NCjxwcmU+Jm5ic3A7PC9wcmU+DQo8cHJlPldoZXRoZXIgdGhpcyBpcyBh
Y3R1YWxseSBhIGdvb2QgdGhpbmcgdG8gZG8vZW5jb3VyYWdlIEknbSBub3Qgc28gc3VyZS48L3By
ZT4NCjxwcmU+Jm5ic3A7PC9wcmU+DQo8cHJlPltNU0VFXTogT0suIEJ1dCB3aGF0IGlzIHRoZSBw
cmVmZXJyZWQgd2F5IGZvciBzb21lb25lIGltcGxlbWVudGluZyBSRVNUQ09ORiBvbiBhIGRldmlj
ZSB3aG8gd291bGQgbGlrZSB0byBoYXZlIHRoZSBzdXBwb3J0IG9mICZsdDtjYW5kaWRhdGUmZ3Q7
LCAmbHQ7c3RhcnR1cCZndDssICZsdDtydW5uaW5nJmd0OyBhbmQgdGhlIG5ldyBvbmVzIGRlZmlu
ZWQgaW4gTk1EQS48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhvdyBk
b2VzIG9uZSBjb3B5IHRoZSBkYXRhIGZyb20gJmx0O3J1bm5pbmcmZ3Q7IHRvIGUuZy4gJmx0O3N0
YXJ0dXAmZ3Q7IHVzaW5nIHRoZSBtZWNoYW5pc21zIFJFU1RDT05GIGhhcyBkZWZpbmVkIGluIFJG
QyA4MDQwPyBGcm9tIHJlYWRpbmcgdGhlIFJGQyBpdCBzZWVtcyBpcyBvdXQgb2Ygc2NvcGUgb2Yg
UkZDIDgwNDAgYnV0IGlzIHRoaXMgcmVhbGx5IGludGVuZGVkPyA8L3ByZT4NCjxwcmU+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SW1wbGVtZW50aW5nIGlldGYtbmV0Y29uZi55YW5n
IG9mIGNvdXJzZSBjb3VsZCBiZSBhbiBvcHRpb24uPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cD5J
IGFncmVlIHRoYXQgdGhpcyBpc24ndCByZWFsbHkgc3BlY2lmaWVkLjwvcD4NCjxwPklJUkMgb3Vy
IGluaXRpYWwgZm9jdXMgd2FzIHRvIGVmZmVjdGl2ZWx5IGdldCBwYXJpdHkgd2l0aCBSRkMgODA0
MC4mbmJzcDsgSS5lLiBteSB3b3JraW5nIGFzc3VtcHRpb24gaXMgdGhhdCAmbHQ7Y2FuZGlkYXRl
Jmd0OyAoaWYgcHJlc2VudCkgd291bGQgYmUgaGFuZGxlZCBhdXRvbWF0aWNhbGx5IGFuZCBzaW1p
bGFybHkgdXBkYXRlcyB0byAmbHQ7c3RhcnR1cCZndDsgd291bGQgYmUgaGFuZGxlZCBhdXRvbWF0
aWNhbGx5LiZuYnNwOyBFLmcuIGJyb2FkbHkgZXF1aXZhbGVudCB0bw0KIHRoZSAvZGF0YSByZXNv
dXJjZSBpbiBSRVNUQ09ORi4mbmJzcDsgU28gaW4gZXNzZW5jZSB0aGlzIGJvaWxzIGRvd24gdG8g
Y2xpZW50cyBpbnRlcmFjdGluZyB3aXRoIC9kcy9pZXRmLWRhdGFzdG9yZXM6cnVubmluZywgL2Rz
L2lldGYtZGF0YXN0b3JlczpvcGVyYXRpb25hbCBhbmQgL2RzL2lldGYtZGF0YXN0b3JlczppbnRl
bmRlZC4mbmJzcDsgTm8gbmV3IFJFU1RDT05GIG9wZXJhdGlvbnMgc2hvdWxkIGJlIG5lY2Vzc2Fy
eSBoZXJlLjwvcD4NCjxwPkknbSBhbHNvIG5vdCByZWFsbHkgY29udmluY2VkIHRoYXQgaW5kZXBl
bmRlbnRseSBjb250cm9sbGFibGUgJmx0O3N0YXJ0dXAmZ3Q7IGFuZCAmbHQ7Y2FuZGlkYXRlJmd0
OyBpcyByZWFsbHkgYSBncmVhdCBpZGVhLjwvcD4NCjxwPkdpdmVuIHRoYXQgJmx0O3J1bm5pbmcm
Z3Q7IGlzIG1lYW50IHRvIHJlcHJlc2VudCBwZXJzaXN0ZW50IGNvbmZpZ3VyYXRpb24sIHRoZW4g
YXV0b21hdGljYWxseSB1cGRhdGluZyAmbHQ7c3RhcnR1cCZndDsgYXMgYSBzaWRlIGVmZmVjdCBv
ZiB1cGRhdGluZyAmbHQ7cnVubmluZyZndDsgc2VlbXMgbGlrZSB0aGUgbW9zdCBzZW5zaWJsZSBi
ZWhhdmlvci4mbmJzcDsgSWYgdGhlIGRlc2lyZSBpcyBmb3Igc29tZSBlcGhlbWVyYWwgdHlwZSBj
b25maWd1cmF0aW9uIHRoZW4gdGhhdCB3b3VsZA0KIGJlIGJldHRlciBtb2RlbGVkIHZpYSBhbiBl
eHBsaWNpdCBkeW5hbWljIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlIChlLmcuIGEgYml0IGxpa2Ug
d2hhdCBJMlJTIHdlcmUgdHJ5aW5nIHRvIGRvKS48L3A+DQo8cD5TaW1pbGFybHksIGluc3RlYWQg
b2YgYSBzaGFyZWQgY2FuZGlkYXRlIGRhdGFzdG9yZSwgdGhlcmUgaXMgc29tZSB3b3JrIGludmVz
dGlnYXRpbmcgcHJpdmF0ZSBjYW5kaWRhdGUgZGF0YXN0b3Jlcy4mbmJzcDsgZHJhZnQtbGhvdGth
LW5ldGNvbmYtcmVzdGNvbmYtdHJhbnNhY3Rpb25zLTAwIGdpdmVzIHNvbWUgaWRlYXMgb2Ygd2hh
dCB0aGlzIGNvdWxkIGxvb2sgbGlrZSwgYnV0IGZ1cnRoZXIgd29yayBpcyByZXF1aXJlZC48L3A+
DQo8cD5JZiB0aGVyZSBpcyBhIHN0cm9uZyByZXF1aXJlbWVudCB0byBhbGxvdyBmdWxsIGV4cGxp
Y2l0IG1hbmlwdWxhdGlvbiBvZiBjb25maWd1cmF0aW9uIGRhdGFzdG9yZXMgdGhlbiBJIHRoaW5r
IHRoYXQgd2Ugc2hvdWxkIHByb2JhYmx5IGRlZmluZSBleHBsaWNpdCBSUENzIGZvciB0aGVzZSBv
cGVyYXRpb25zIChtb2RlbGVkIG9uIHRoZSBORVRDT05GIG9uZXMpLiZuYnNwOyBJZGVhbGx5LCB0
aGVzZSBjb3VsZCBiZSBkZWZpbmVkIGluIGEgcHJvdG9jb2wNCiBuZXV0cmFsIGZvcm1hdCBzbyB0
aGF0IHRoZXkgY2FuIHdvcmsgd2l0aCBhbnkgWUFORyBiYXNlZCBtYW5hZ2VtZW50IHByb3RvY29s
cy4mbmJzcDsgSW4gdGhlIGludGVyaW0sIHVzaW5nIHRoZSBORVRDT05GIFJQQ3MgZnJvbSBSRVNU
Q09ORiBzZWVtcyBsaWtlIGEgcmVhc29uYWJsZSBzdG9wZ2FwIG1lYXN1cmUuPC9wPg0KPHA+PHNw
YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bTVNF
RV06IEkgYWdyZWUsIHRoaXMgd291bGQgYmUgaGVscGZ1bC4NCjwvc3Bhbj48L3A+DQo8cD48c3Bh
biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSPGJy
Pg0KTWFya3VzIDwvc3Bhbj48L3A+DQo8cD5UaGFua3MsPGJyPg0KUm9iPC9wPg0KPHA+Jm5ic3A7
PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8cHJlPiZuYnNwOzwvcHJlPg0KPHByZT5UaGFua3MsPC9wcmU+DQo8cHJlPlJvYjwv
cHJlPg0KPHByZT4mbmJzcDs8L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4mbmJzcDs8L3ByZT4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4zLiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUeXBvIGluIDxhIGhyZWY9Imh0dHBz
Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0
Zi5vcmdfcGRmX2RyYWZ0LTJEaWV0Zi0yRG5ldGNvbmYtMkRubWRhLTJEcmVzdGNvbmYtMkQwNSZh
bXA7ZD1Ed0lCQWcmYW1wO2M9Qmc1WFVMRFpSOEdpT1NTV05scGtDc1JlUG5HRGtLY0k2b1lMOXh2
MU1uUSZhbXA7cj0yWEVLVllrUWptTEhpMlRPSnAxVlN6aWVMWlZxZXdJcGotUnhtUmdQZnNNJmFt
cDttPUNESzI4WDhrTzJ3UlZEbGE5N1BfV3FCSWhGM09BemJXU0dFbVRlTGR4d1UmYW1wO3M9QlN5
WS1HQnV6ekRyeTZvSWhnLW1nd01BeVNiaEpFTzlJbTNaNFBEX2NfNCZhbXA7ZT0iPmh0dHBzOi8v
dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5v
cmdfcGRmX2RyYWZ0LTJEaWV0Zi0yRG5ldGNvbmYtMkRubWRhLTJEcmVzdGNvbmYtMkQwNSZhbXA7
ZD1Ed0lCQWcmYW1wO2M9Qmc1WFVMRFpSOEdpT1NTV05scGtDc1JlUG5HRGtLY0k2b1lMOXh2MU1u
USZhbXA7cj0yWEVLVllrUWptTEhpMlRPSnAxVlN6aWVMWlZxZXdJcGotUnhtUmdQZnNNJmFtcDtt
PUNESzI4WDhrTzJ3UlZEbGE5N1BfV3FCSWhGM09BemJXU0dFbVRlTGR4d1UmYW1wO3M9QlN5WS1H
QnV6ekRyeTZvSWhnLW1nd01BeVNiaEpFTzlJbTNaNFBEX2NfNCZhbXA7ZT08L2E+IENoYXB0ZXIg
My4xICZxdW90O3RoZSBzZXJ2ZXIgd291bGQgaW1wbGVtZW50IHRoZSByZXNvdXJjZSB7JiM0Mzty
ZXN0Y29uZn0vZHMvZXhhbXBsZS0gZHMtZXBoZW1lcmFsOmRzLWVwaGVtZXJhbC4mcXVvdDs8L3By
ZT4NCjxwcmU+VGhlcmUgaXMgYSBzcGFjZSBpbiBiZXR3ZWVuICZxdW90O2V4YW1wbGUtJnF1b3Q7
IGFuZCAmcXVvdDtkcy1lcGhlbWVyYWw6ZHMtZXBoZW1lcmFsJnF1b3Q7LjwvcHJlPg0KPC9ibG9j
a3F1b3RlPg0KPHByZT5MZXRzIGhvcGUgd2UgZ2V0IHRoaXMgZml4ZWQgd2l0aCB0aGUgaGVscCBv
ZiB0aGUgUkZDIGVkaXRvci48L3ByZT4NCjxwcmU+Jm5ic3A7PC9wcmU+DQo8cHJlPi9qczwvcHJl
Pg0KPHByZT4mbmJzcDs8L3ByZT4NCjxwcmU+LS08L3ByZT4NCjxwcmU+SnVlcmdlbiBTY2hvZW53
YWVsZGVyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSDwvcHJlPg0KPHByZT5QaG9u
ZTogJiM0Mzs0OSA0MjEgMjAwIDM1ODcmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnk8L3By
ZT4NCjxwcmU+RmF4OiZuYnNwOyZuYnNwOyAmIzQzOzQ5IDQyMSAyMDAgMzEwMyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3Vy
bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5qYWNvYnMtMkR1
bml2ZXJzaXR5LmRlXyZhbXA7ZD1Ed0lCQWcmYW1wO2M9Qmc1WFVMRFpSOEdpT1NTV05scGtDc1Jl
UG5HRGtLY0k2b1lMOXh2MU1uUSZhbXA7cj0yWEVLVllrUWptTEhpMlRPSnAxVlN6aWVMWlZxZXdJ
cGotUnhtUmdQZnNNJmFtcDttPUNESzI4WDhrTzJ3UlZEbGE5N1BfV3FCSWhGM09BemJXU0dFbVRl
TGR4d1UmYW1wO3M9dzM4c2VXaTZGTjQ4T2pQZkpuOTItLWVtaTNyRXpFaURUSHNLTHhFbnNyZyZh
bXA7ZT0iPiZsdDtodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0
cHMtM0FfX3d3dy5qYWNvYnMtMkR1bml2ZXJzaXR5LmRlXyZhbXA7ZD1Ed0lCQWcmYW1wO2M9Qmc1
WFVMRFpSOEdpT1NTV05scGtDc1JlUG5HRGtLY0k2b1lMOXh2MU1uUSZhbXA7cj0yWEVLVllrUWpt
TEhpMlRPSnAxVlN6aWVMWlZxZXdJcGotUnhtUmdQZnNNJmFtcDttPUNESzI4WDhrTzJ3UlZEbGE5
N1BfV3FCSWhGM09BemJXU0dFbVRlTGR4d1UmYW1wO3M9dzM4c2VXaTZGTjQ4T2pQZkpuOTItLWVt
aTNyRXpFaURUSHNLTHhFbnNyZyZhbXA7ZT0mZ3Q7PC9hPjwvcHJlPg0KPHByZT5fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvcHJlPg0KPHByZT5uZXRtb2Qg
bWFpbGluZyBsaXN0PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmci
Pm5ldG1vZEBpZXRmLm9yZzwvYT48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZl
bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbCI+
aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu
aWV0Zi5vcmdfbWFpbDwvYT48L3ByZT4NCjxwcmU+bWFuX2xpc3RpbmZvX25ldG1vZCZhbXA7ZD1E
d0lEYVEmYW1wO2M9Qmc1WFVMRFpSOEdpT1NTV05scGtDc1JlUG5HRGtLY0k2b1lMOXh2PC9wcmU+
DQo8cHJlPjFNblEmYW1wO3I9MlhFS1ZZa1FqbUxIaTJUT0pwMVZTemllTFpWcWV3SXBqLVJ4bVJn
UGZzTSZhbXA7bT1UclBNVlhRNUlvdkZtMDhCUzwvcHJlPg0KPHByZT5iYlhhMkUtSG5TT195ekhS
eTBHUjlkalQyTSZhbXA7cz1zZDExb25IQTQyT0RueXN6OVpPSVppa1dXUU1Ia0h3VVNlTC1sTldj
azwvcHJlPg0KPHByZT5ERSZhbXA7ZT08L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+Jm5ic3A7
PC9wcmU+DQo8cHJlPioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKio8L3ByZT4NCjxwcmU+RElTQ0xBSU1FUjo8L3ByZT4N
CjxwcmU+UHJpdmlsZWdlZCBhbmQvb3IgQ29uZmlkZW50aWFsIGluZm9ybWF0aW9uIG1heSBiZSBj
b250YWluZWQgaW4gdGhpcyBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUgYWRkcmVzc2VlIG9m
IHRoaXMgbWVzc2FnZSwgeW91IG1heSBub3QgY29weSwgdXNlIG9yIGRlbGl2ZXIgdGhpcyBtZXNz
YWdlIHRvIGFueW9uZS4gSW4gc3VjaCBldmVudCwgeW91IHNob3VsZCBkZXN0cm95IHRoZSBtZXNz
YWdlIGFuZCBraW5kbHkgbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVwbHkgZS1tYWlsLiBJdCBpcyB1
bmRlcnN0b29kIHRoYXQgb3BpbmlvbnMgb3IgY29uY2x1c2lvbnMgdGhhdCBkbyBub3QgcmVsYXRl
IHRvIHRoZSBvZmZpY2lhbCBidXNpbmVzcyBvZiB0aGUgY29tcGFueSBhcmUgbmVpdGhlciBnaXZl
biBub3IgZW5kb3JzZWQgYnkgdGhlIGNvbXBhbnkuIFRoYW5rIFlvdS48L3ByZT4NCjwvYmxvY2tx
dW90ZT4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQt
YWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRJU0NMQUlNRVI6PGJyPg0KUHJpdmlsZWdl
ZCBhbmQvb3IgQ29uZmlkZW50aWFsIGluZm9ybWF0aW9uIG1heSBiZSBjb250YWluZWQgaW4gdGhp
cyBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUgYWRkcmVzc2VlIG9mIHRoaXMgbWVzc2FnZSwg
eW91IG1heSBub3QgY29weSwgdXNlIG9yIGRlbGl2ZXIgdGhpcyBtZXNzYWdlIHRvIGFueW9uZS4g
SW4gc3VjaCBldmVudCwgeW91IHNob3VsZCBkZXN0cm95IHRoZSBtZXNzYWdlIGFuZCBraW5kbHkg
bm90aWZ5IHRoZSBzZW5kZXIgYnkNCiByZXBseSBlLW1haWwuIEl0IGlzIHVuZGVyc3Rvb2QgdGhh
dCBvcGluaW9ucyBvciBjb25jbHVzaW9ucyB0aGF0IGRvIG5vdCByZWxhdGUgdG8gdGhlIG9mZmlj
aWFsIGJ1c2luZXNzIG9mIHRoZSBjb21wYW55IGFyZSBuZWl0aGVyIGdpdmVuIG5vciBlbmRvcnNl
ZCBieSB0aGUgY29tcGFueS4gVGhhbmsgWW91LjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K
CjxIUj5ESVNDTEFJTUVSOjxCUj4KUHJpdmlsZWdlZCBhbmQvb3IgQ29uZmlkZW50aWFsIGluZm9y
bWF0aW9uIG1heSBiZSBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0
aGUgYWRkcmVzc2VlIG9mIHRoaXMgbWVzc2FnZSwgeW91IG1heSBub3QgY29weSwgdXNlIG9yIGRl
bGl2ZXIgdGhpcyBtZXNzYWdlIHRvIGFueW9uZS4gSW4gc3VjaCBldmVudCwgeW91IHNob3VsZCBk
ZXN0cm95IHRoZSBtZXNzYWdlIGFuZCBraW5kbHkgbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVwbHkg
ZS1tYWlsLiBJdCBpcyB1bmRlcnN0b29kIHRoYXQgb3BpbmlvbnMgb3IgY29uY2x1c2lvbnMgdGhh
dCBkbyBub3QgcmVsYXRlIHRvIHRoZSBvZmZpY2lhbCBidXNpbmVzcyBvZiB0aGUgY29tcGFueSBh
cmUgbmVpdGhlciBnaXZlbiBub3IgZW5kb3JzZWQgYnkgdGhlIGNvbXBhbnkuIFRoYW5rIFlvdS48
QlI+CjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_e1e9865cb1784062a1a8fdd0cd2756b8DCRIC1EXC03PAmcplocal_--


From nobody Wed Dec 12 07:24:15 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29A2130DFF for ; Wed, 12 Dec 2018 07:24:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.959
X-Spam-Level: 
X-Spam-Status: No, score=-15.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mDp268O3w_q for ; Wed, 12 Dec 2018 07:24:00 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD501130DF9 for ; Wed, 12 Dec 2018 07:23:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8247; q=dns/txt; s=iport; t=1544628240; x=1545837840; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=bTm99cKykeUYyzNKvq0bMtTbViU/bTpv3UI2jvw+Tbg=; b=SGWMKpMFk0UnqwK2jMW376Oh4uV0wdX1sQE7R+mmjvhNIwNMqep2F8El 1xIx4hWmz0vMpFWIVbyqw7HuevgyYy4X5CGH+eRcEi49LEPGYyUVn64aI GHXSP/KVv8BGCAXaIaDytOVZfRmgfBy8HyZPB2lcyI1vg73mbq5Wrxn5H g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ARAAC3JhFc/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgmlwEieMc40TLZF6hVmBeg0YAQqEA0Y?= =?us-ascii?q?Cgx42Bw0BAwEBAgEBAm0cDIU9AQEEAQFsGwsYJwcnHxEGAQwGAgEBgx0BggE?= =?us-ascii?q?Ppw8fhSGEaQWMU4FAP4ERJ4Jrgx4BAYFLhXECoQwJkVEGGIl5h02JKYkthmm?= =?us-ascii?q?BTQonKIEuMxoIGxU7gmyLHIU/PwMwjgMBAQ?=
X-IronPort-AV: E=Sophos;i="5.56,344,1539648000"; d="scan'208,217";a="8752018"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2018 15:23:54 +0000
Received: from [10.63.23.68] (dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com [10.63.23.68]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id wBCFNqUv017017; Wed, 12 Dec 2018 15:23:52 GMT
To: Jan Lindblad , Ladislav Lhotka , netmod@ietf.org
References: <87zhtan7bo.fsf@nic.cz> 
From: Robert Wilton 
Message-ID: <2c2eff9a-4cdb-d755-dc2b-05c01d8c8d1d@cisco.com>
Date: Wed, 12 Dec 2018 15:23:52 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------4B656F997B2E1AC819AF956B"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.68, dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [netmod] datastore-specific constraints
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Dec 2018 15:24:12 -0000

This is a multi-part message in MIME format.
--------------4B656F997B2E1AC819AF956B
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Lada,

I basically agree with Jan's suggestion.

I don't think that I would use a when statement for this scenario since 
you want a leaf to report the operational value that is in effect, and 
one of the aims of NMDA is to try and get the configured and operational 
value onto the same path wherever possible.

But, I think that the question about validity of must statements is more 
interesting. RFC 8342 states that these can be violated in operational, 
but the intention is that the constraints in  should 
generally apply (but never be actually checked by the server). In this 
case, it might be useful to be able to annotate a must statement to 
indicate that it only applies to configuration data and not operational 
data.

Thanks,
Rob


On 12/12/2018 14:52, Jan Lindblad wrote:
> Lada,
>
> Maybe you could just skip the when and explain the behavior in the 
> description? E.g.
>
> leaf foo {
> ...
> description "Foo controls bla, bla.
>  Any configured value will be ignored when auto-foo is true.";
> }
>
> Best Regards,
> /jan
>
>> On 12 Dec 2018, at 15:33, Ladislav Lhotka > > wrote:
>>
>> Hi,
>>
>> in some cases, constraints expressed with "when" or "must" may only be
>> intended for configuration datastores. A typical example is an
>> auto-negotiable parameter:
>>
>> leaf auto-foo {
>> type boolean;
>> default true;
>> description "If true, parameter 'foo' will be auto-negotiated.";
>> }
>> leaf foo {
>> when "../auto-foo = 'false'";
>> ...
>> }
>>
>> This means that if auto-foo is true, it is impossible to configure the
>> foo parameter. However, even with auto-foo = true, it is desirable to
>> see the auto-negotiated value in , so, ideally, the "when"
>> constraint should not apply in .
>>
>> How can this logic be modelled under NMDA? Is an extra leaf
>> "foo-operational" needed?
>>
>> Thanks, Lada
>>
>> -- 
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--------------4B656F997B2E1AC819AF956B
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Lada,

    
I basically agree with Jan's suggestion.

    
I don't think that I would use a when statement for this scenario
      since you want a leaf to report the operational value that is in
      effect, and one of the aims of NMDA is to try and get the
      configured and operational value onto the same path wherever
      possible.

    

    
But, I think that the question about validity of must statements
      is more interesting. RFC 8342 states that these can be violated
      in operational, but the intention is that the constraints in
      <operational> should generally apply (but never be actually
      checked by the server). In this case, it might be useful to be
      able to annotate a must statement to indicate that it only applies
      to configuration data and not operational data.

    

    
Thanks,

      Rob

    


    

    
On 12/12/2018 14:52, Jan Lindblad
      wrote:

    

    

      
      Lada,
      


      

      
Maybe you could just skip the when and explain the
        behavior in the description? E.g.

      


        

      
leaf foo {

      
...

        
        
description "Foo
            controls bla, bla.

        
 Any configured
            value will be ignored when auto-foo is true.";

            }

          

        


        

        
Best Regards,

        
/jan

        


          

            
On 12 Dec 2018, at 15:33, Ladislav Lhotka <lhotka@nic.cz> wrote:

            

            

              
Hi,

                

                in some cases, constraints expressed with "when" or
                "must" may only be

                intended for configuration datastores. A typical example
                is an

                auto-negotiable parameter:

                

                leaf auto-foo {

                type boolean;

                default true;

                description "If true, parameter 'foo' will be
                auto-negotiated.";

                }

                leaf foo {

                when "../auto-foo = 'false'";

                ...

                }

                

                This means that if auto-foo is true, it is impossible to
                configure the

                foo parameter. However, even with auto-foo = true, it is
                desirable to

                see the auto-negotiated value in <operational>,
                so, ideally, the "when"

                constraint should not apply in <operational>.

                

                How can this logic be modelled under NMDA? Is an extra
                leaf

                "foo-operational" needed?

                

                Thanks, Lada

                

                -- 

                Ladislav Lhotka

                Head, CZ.NIC Labs

                PGP Key ID: 0xB8F92B08A9F76C67

                

                _______________________________________________

                netmod mailing list

                netmod@ietf.org

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

                

              

            

          

        

        

      

      

      

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


    

  


--------------4B656F997B2E1AC819AF956B--


From nobody Wed Dec 12 07:31:01 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2337130934 for ; Wed, 12 Dec 2018 07:31:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.958
X-Spam-Level: 
X-Spam-Status: No, score=-15.958 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkftOpXeBC7d for ; Wed, 12 Dec 2018 07:30:59 -0800 (PST)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5A9F128C65 for ; Wed, 12 Dec 2018 07:30:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10896; q=dns/txt; s=iport; t=1544628658; x=1545838258; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AlpCOznQMa+opDiLAbvJHkBiRRl1cRMreWhjKpY05wI=; b=B3I6i8CFsR0GdSBwFYW3sp3CPUNvOjmwWVCt4pBubBHfM3PbxqUfWwmH o7Ghgzz7zvturbL2pdq8wR0dgluxYiCgG1atme9RbvcshG7v/hVKVQW4p Sbt6odcPYKGsreTHkYoE8I7A+H3HUL/DLt1+8RbBCowK0mCCLXALcbIDf 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAAPKRFc/5tdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBgQ12ZoECJwqDcZQrgg2ReoVZgXoLAQE?= =?us-ascii?q?YAQoJg3pGAheCZSI1CA0BAwEBAgEBAm0cDIU8AQEBBAEBIUsLEAIBCBEDAQI?= =?us-ascii?q?oAwICAiULFAkIAgQBDQWDIQGBHWQPpWiBL4VAhGgFjDwXgUA/gREnH4JMgx4?= =?us-ascii?q?BAYIBFoJOMYImAoljhUqBZ4Rqiw4JApFVEgaRRokpj28CERSBJyEBNSiBLnA?= =?us-ascii?q?VOyoBgkGLHIU/coEoizwBgR4BAQ?=
X-IronPort-AV: E=Sophos;i="5.56,344,1539648000";  d="scan'208,217";a="211459101"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2018 15:30:57 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id wBCFUvqO021660 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Dec 2018 15:30:57 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 12 Dec 2018 09:30:56 -0600
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Wed, 12 Dec 2018 09:30:56 -0600
From: "Reshad Rahman (rrahman)" 
To: Jan Lindblad , Ladislav Lhotka 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] datastore-specific constraints
Thread-Index: AQHUkieq8fXp6Xl9HkyjD+ZFsNb77qV7lPaA//+21wA=
Date: Wed, 12 Dec 2018 15:30:56 +0000
Message-ID: 
References: <87zhtan7bo.fsf@nic.cz> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.4.181110
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.42]
Content-Type: multipart/alternative; boundary="_000_E80F6591EBBE417BA2E6F03319DB4E45ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] datastore-specific constraints
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Dec 2018 15:31:01 -0000

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

SGksDQoNClNob3VsZCBpdCBiZSBpZ25vcmVkIG9yIHJlamVjdGVkPw0KDQpBbHNvIG5vdCBrZWVu
IGluIGZvby1vcGVyYXRpb25hbCwgc2luY2UgaXTigJlzIGluIGNvbnRyYWRpY3Rpb24gdG8gTk1E
QeKAmXMgZ29hbHMuDQoNClJlZ2FyZHMsDQpSZXNoYWQuDQoNCkZyb206IG5ldG1vZCA8bmV0bW9k
LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBKYW4gTGluZGJsYWQgPGphbmxAdGFpbC1m
LmNvbT4NCkRhdGU6IFdlZG5lc2RheSwgRGVjZW1iZXIgMTIsIDIwMTggYXQgOTo1MyBBTQ0KVG86
IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jej4NCkNjOiAibmV0bW9kQGlldGYub3JnIiA8
bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIGRhdGFzdG9yZS1zcGVjaWZp
YyBjb25zdHJhaW50cw0KDQpMYWRhLA0KDQpNYXliZSB5b3UgY291bGQganVzdCBza2lwIHRoZSB3
aGVuIGFuZCBleHBsYWluIHRoZSBiZWhhdmlvciBpbiB0aGUgZGVzY3JpcHRpb24/IEUuZy4NCg0K
bGVhZiBmb28gew0KIC4uLg0KIGRlc2NyaXB0aW9uICJGb28gY29udHJvbHMgYmxhLCBibGEuDQog
IEFueSBjb25maWd1cmVkIHZhbHVlIHdpbGwgYmUgaWdub3JlZCB3aGVuIGF1dG8tZm9vIGlzIHRy
dWUuIjsNCn0NCg0KQmVzdCBSZWdhcmRzLA0KL2phbg0KDQoNCk9uIDEyIERlYyAyMDE4LCBhdCAx
NTozMywgTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PG1haWx0bzpsaG90a2FAbmljLmN6
Pj4gd3JvdGU6DQoNCkhpLA0KDQppbiBzb21lIGNhc2VzLCBjb25zdHJhaW50cyBleHByZXNzZWQg
d2l0aCAid2hlbiIgb3IgIm11c3QiIG1heSBvbmx5IGJlDQppbnRlbmRlZCBmb3IgY29uZmlndXJh
dGlvbiBkYXRhc3RvcmVzLiBBIHR5cGljYWwgZXhhbXBsZSBpcyBhbg0KYXV0by1uZWdvdGlhYmxl
IHBhcmFtZXRlcjoNCg0KbGVhZiBhdXRvLWZvbyB7DQogdHlwZSBib29sZWFuOw0KIGRlZmF1bHQg
dHJ1ZTsNCiBkZXNjcmlwdGlvbiAiSWYgdHJ1ZSwgcGFyYW1ldGVyICdmb28nIHdpbGwgYmUgYXV0
by1uZWdvdGlhdGVkLiI7DQp9DQpsZWFmIGZvbyB7DQogd2hlbiAiLi4vYXV0by1mb28gPSAnZmFs
c2UnIjsNCiAuLi4NCn0NCg0KVGhpcyBtZWFucyB0aGF0IGlmIGF1dG8tZm9vIGlzIHRydWUsIGl0
IGlzIGltcG9zc2libGUgdG8gY29uZmlndXJlIHRoZQ0KZm9vIHBhcmFtZXRlci4gSG93ZXZlciwg
ZXZlbiB3aXRoIGF1dG8tZm9vID0gdHJ1ZSwgaXQgaXMgZGVzaXJhYmxlIHRvDQpzZWUgdGhlIGF1
dG8tbmVnb3RpYXRlZCB2YWx1ZSBpbiA8b3BlcmF0aW9uYWw+LCBzbywgaWRlYWxseSwgdGhlICJ3
aGVuIg0KY29uc3RyYWludCBzaG91bGQgbm90IGFwcGx5IGluIDxvcGVyYXRpb25hbD4uDQoNCkhv
dyBjYW4gdGhpcyBsb2dpYyBiZSBtb2RlbGxlZCB1bmRlciBOTURBPyBJcyBhbiBleHRyYSBsZWFm
DQoiZm9vLW9wZXJhdGlvbmFsIiBuZWVkZWQ/DQoNClRoYW5rcywgTGFkYQ0KDQotLQ0KTGFkaXNs
YXYgTGhvdGthDQpIZWFkLCBDWi5OSUMgTGFicw0KUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2
QzY3DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpu
ZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9y
Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q291cmllcjsNCglwYW5vc2UtMToyIDAgNSAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7
Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg
NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1
IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIFwoQm9keSBDU1wpIjsNCglwYW5vc2UtMToyIDIgNiAzIDUgNCA1IDIgMyA0O30NCi8qIFN0
eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y
bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox
MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu
Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0
ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG
b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu
bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At
YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi
Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlw
ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj
b2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1h
bDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250
LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw
dDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlv
bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh
bmc9IkVOLUNBIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT
ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si
PkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5TaG91bGQgaXQgYmUgaWdub3Jl
ZCBvciByZWplY3RlZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImNvbG9yOmJsYWNrIj5BbHNvIG5vdCBrZWVuIGluIGZvby1vcGVyYXRpb25hbCwgc2luY2Ug
aXTigJlzIGluIGNvbnRyYWRpY3Rpb24gdG8gTk1EQeKAmXMgZ29hbHMuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj
b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+UmVnYXJkcyw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5SZXNoYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE
RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5uZXRtb2Qg
Jmx0O25ldG1vZC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgSmFuIExpbmRibGFk
ICZsdDtqYW5sQHRhaWwtZi5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgRGVj
ZW1iZXIgMTIsIDIwMTggYXQgOTo1MyBBTTxicj4NCjxiPlRvOiA8L2I+TGFkaXNsYXYgTGhvdGth
ICZsdDtsaG90a2FAbmljLmN6Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7bmV0bW9kQGlldGYu
b3JnJnF1b3Q7ICZsdDtuZXRtb2RAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJl
OiBbbmV0bW9kXSBkYXRhc3RvcmUtc3BlY2lmaWMgY29uc3RyYWludHM8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGFkYSwgPG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXliZSB5b3UgY291bGQganVzdCBz
a2lwIHRoZSB3aGVuIGFuZCBleHBsYWluIHRoZSBiZWhhdmlvciBpbiB0aGUgZGVzY3JpcHRpb24/
IEUuZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPmxlYWYgZm9vIHs8L3NwYW4+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6Q291cmllciI+Jm5ic3A7Li4uPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD
b3VyaWVyIj4mbmJzcDtkZXNjcmlwdGlvbiAmcXVvdDtGb28gY29udHJvbHMgYmxhLCBibGEuJm5i
c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNvdXJpZXIiPiZuYnNwOyBBbnkgY29uZmln
dXJlZCB2YWx1ZSB3aWxsIGJlIGlnbm9yZWQgd2hlbiBhdXRvLWZvbyBpcyB0cnVlLiZxdW90Ozs8
YnI+DQp9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4vamFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEyIERlYyAyMDE4LCBhdCAxNTozMywgTGFkaXNsYXYg
TGhvdGthICZsdDs8YSBocmVmPSJtYWlsdG86bGhvdGthQG5pYy5jeiI+bGhvdGthQG5pYy5jejwv
YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSw8YnI+DQo8YnI+DQppbiBzb21lIGNh
c2VzLCBjb25zdHJhaW50cyBleHByZXNzZWQgd2l0aCAmcXVvdDt3aGVuJnF1b3Q7IG9yICZxdW90
O211c3QmcXVvdDsgbWF5IG9ubHkgYmU8YnI+DQppbnRlbmRlZCBmb3IgY29uZmlndXJhdGlvbiBk
YXRhc3RvcmVzLiBBIHR5cGljYWwgZXhhbXBsZSBpcyBhbjxicj4NCmF1dG8tbmVnb3RpYWJsZSBw
YXJhbWV0ZXI6PGJyPg0KPGJyPg0KbGVhZiBhdXRvLWZvbyB7PGJyPg0KJm5ic3A7dHlwZSBib29s
ZWFuOzxicj4NCiZuYnNwO2RlZmF1bHQgdHJ1ZTs8YnI+DQombmJzcDtkZXNjcmlwdGlvbiAmcXVv
dDtJZiB0cnVlLCBwYXJhbWV0ZXIgJ2Zvbycgd2lsbCBiZSBhdXRvLW5lZ290aWF0ZWQuJnF1b3Q7
Ozxicj4NCn08YnI+DQpsZWFmIGZvbyB7PGJyPg0KJm5ic3A7d2hlbiAmcXVvdDsuLi9hdXRvLWZv
byA9ICdmYWxzZScmcXVvdDs7PGJyPg0KJm5ic3A7Li4uPGJyPg0KfTxicj4NCjxicj4NClRoaXMg
bWVhbnMgdGhhdCBpZiBhdXRvLWZvbyBpcyB0cnVlLCBpdCBpcyBpbXBvc3NpYmxlIHRvIGNvbmZp
Z3VyZSB0aGU8YnI+DQpmb28gcGFyYW1ldGVyLiBIb3dldmVyLCBldmVuIHdpdGggYXV0by1mb28g
PSB0cnVlLCBpdCBpcyBkZXNpcmFibGUgdG88YnI+DQpzZWUgdGhlIGF1dG8tbmVnb3RpYXRlZCB2
YWx1ZSBpbiAmbHQ7b3BlcmF0aW9uYWwmZ3Q7LCBzbywgaWRlYWxseSwgdGhlICZxdW90O3doZW4m
cXVvdDs8YnI+DQpjb25zdHJhaW50IHNob3VsZCBub3QgYXBwbHkgaW4gJmx0O29wZXJhdGlvbmFs
Jmd0Oy48YnI+DQo8YnI+DQpIb3cgY2FuIHRoaXMgbG9naWMgYmUgbW9kZWxsZWQgdW5kZXIgTk1E
QT8gSXMgYW4gZXh0cmEgbGVhZjxicj4NCiZxdW90O2Zvby1vcGVyYXRpb25hbCZxdW90OyBuZWVk
ZWQ/PGJyPg0KPGJyPg0KVGhhbmtzLCBMYWRhPGJyPg0KPGJyPg0KLS0gPGJyPg0KTGFkaXNsYXYg
TGhvdGthPGJyPg0KSGVhZCwgQ1ouTklDIExhYnM8YnI+DQpQR1AgS2V5IElEOiAweEI4RjkyQjA4
QTlGNzZDNjc8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86
bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_E80F6591EBBE417BA2E6F03319DB4E45ciscocom_--


From nobody Wed Dec 12 07:36:19 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BB812777C for ; Wed, 12 Dec 2018 07:36:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 iVxd34ss0nv5 for ; Wed, 12 Dec 2018 07:36:13 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5CD130DDF for ; Wed, 12 Dec 2018 07:36:12 -0800 (PST)
Received: from [10.147.40.248] (unknown [173.38.220.48]) by mail.tail-f.com (Postfix) with ESMTPSA id 131311AE0351; Wed, 12 Dec 2018 16:36:11 +0100 (CET)
From: Jan Lindblad 
Message-Id: <364AFCA9-7486-4CF3-8B5F-0D712C8276CE@tail-f.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7086E4A2-5FB4-4233-B4DA-4628D81172B5"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 12 Dec 2018 16:36:09 +0100
In-Reply-To: 
Cc: Ladislav Lhotka , "netmod@ietf.org" 
To: "Reshad Rahman (rrahman)" 
References: <87zhtan7bo.fsf@nic.cz>  
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: Re: [netmod] datastore-specific constraints
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Dec 2018 15:36:17 -0000

--Apple-Mail=_7086E4A2-5FB4-4233-B4DA-4628D81172B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Reshad,

> Should it be ignored or rejected?

Ignored, IMO. A rejection policy would bring little value, but lead to =
complications for clients and servers alike.

> Also not keen in foo-operational, since it=E2=80=99s in contradiction =
to NMDA=E2=80=99s goals.

+1

/jan

=20
> From: netmod  on behalf of Jan Lindblad =

> Date: Wednesday, December 12, 2018 at 9:53 AM
> To: Ladislav Lhotka 
> Cc: "netmod@ietf.org" 
> Subject: Re: [netmod] datastore-specific constraints
> =20
> Lada,=20
> =20
> Maybe you could just skip the when and explain the behavior in the =
description? E.g.
> =20
> leaf foo {
>  ...
>  description "Foo controls bla, bla.=20
>   Any configured value will be ignored when auto-foo is true.";
> }
> =20
> Best Regards,
> /jan
>=20
>=20
>> On 12 Dec 2018, at 15:33, Ladislav Lhotka > wrote:
>> =20
>> Hi,
>>=20
>> in some cases, constraints expressed with "when" or "must" may only =
be
>> intended for configuration datastores. A typical example is an
>> auto-negotiable parameter:
>>=20
>> leaf auto-foo {
>>  type boolean;
>>  default true;
>>  description "If true, parameter 'foo' will be auto-negotiated.";
>> }
>> leaf foo {
>>  when "../auto-foo =3D 'false'";
>>  ...
>> }
>>=20
>> This means that if auto-foo is true, it is impossible to configure =
the
>> foo parameter. However, even with auto-foo =3D true, it is desirable =
to
>> see the auto-negotiated value in , so, ideally, the =
"when"
>> constraint should not apply in .
>>=20
>> How can this logic be modelled under NMDA? Is an extra leaf
>> "foo-operational" needed?
>>=20
>> Thanks, Lada
>>=20
>> --=20
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod
>>=20


--Apple-Mail=_7086E4A2-5FB4-4233-B4DA-4628D81172B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Reshad,

Should it =
be ignored or rejected?

Ignored, IMO. A rejection policy would bring =
little value, but lead to complications for clients and servers =
alike.

Also not keen in foo-operational, =
since it=E2=80=99s in contradiction to NMDA=E2=80=99s =
goals.

+1

/jan

 
From: netmod <netmod-bounces@ietf.org> on behalf of Jan Lindblad =
<janl@tail-f.com>
Date: Wednesday, December 12, =
2018 at 9:53 AM
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] =
datastore-specific constraints
 
Lada, 
 
Maybe you could just skip the when and =
explain the behavior in the description? E.g.
 
leaf foo {
 ...
 description "Foo controls bla, =
bla. 
  Any configured value will be ignored when auto-foo is =
true.";
}
 
Best Regards,
/jan


On 12 Dec 2018, at 15:33, Ladislav =
Lhotka <lhotka@nic.cz> wrote:
 
Hi,

in =
some cases, constraints expressed with "when" or "must" may only be
intended for configuration datastores. A typical example is =
an
auto-negotiable parameter:

leaf auto-foo {
 type boolean;
 default true;
 description "If true, =
parameter 'foo' will be auto-negotiated.";
}
leaf foo {
 when "../auto-foo =3D =
'false'";
 ...
}

This means that if auto-foo is true, it is impossible to =
configure the
foo parameter. However, even with auto-foo =3D=
 true, it is desirable to
see the auto-negotiated value in =
<operational>, so, ideally, the "when"
constraint =
should not apply in <operational>.

How =
can this logic be modelled under NMDA? Is an extra leaf
"foo-operational" needed?

Thanks, =
Lada

-- 
Ladislav =
Lhotka
Head, CZ.NIC Labs
PGP Key ID: =
0xB8F92B08A9F76C67

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

=

--Apple-Mail=_7086E4A2-5FB4-4233-B4DA-4628D81172B5--


From nobody Wed Dec 12 07:52:38 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6287130DEE for ; Wed, 12 Dec 2018 07:52:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3azfn2nJpawC for ; Wed, 12 Dec 2018 07:52:34 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88FF612D84C for ; Wed, 12 Dec 2018 07:52:33 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:e43e:c5ff:fe5f:8969]) by mail.nic.cz (Postfix) with ESMTPSA id 2C4606079C; Wed, 12 Dec 2018 16:52:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1544629951; bh=drHEHOSFJcZ02WfVfWatFPyE75jar20B5qQ52Ln8KHw=; h=From:To:Date; b=hkYN3iC9fKOrKFP7DAA2Kw5Bhai7z7dejkXi9+Dm9g0qGEiYJD8D/J8cySsKleOio xouZOBRNWg6YWI7YtUWf/HE6xAiJHFbF9dReAEWmaf75JvwXcE6U33lrnoTLxr3ehI +9pmgLY3RvEYZZB0IMWNGSStOrrICOTa8l6o7yiQ=
Message-ID: 
From: Ladislav Lhotka 
To: Robert Wilton , Jan Lindblad ,  netmod@ietf.org
Date: Wed, 12 Dec 2018 16:52:30 +0100
In-Reply-To: <2c2eff9a-4cdb-d755-dc2b-05c01d8c8d1d@cisco.com>
References: <87zhtan7bo.fsf@nic.cz>  <2c2eff9a-4cdb-d755-dc2b-05c01d8c8d1d@cisco.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.3 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] datastore-specific constraints
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Dec 2018 15:52:37 -0000

On Wed, 2018-12-12 at 15:23 +0000, Robert Wilton wrote:
> Hi Lada,
> I basically agree with Jan's suggestion.
> I don't think that I would use a when statement for this scenario since you
> want a leaf to report the operational value that is in effect, and one of the
> aims of NMDA is to try and get the configured and operational value onto the
> same path wherever possible.
> But, I think that the question about validity of must statements is more
> interesting.  RFC 8342 states that these can be violated in operational, but
> the intention is that the constraints in  should generally apply
> (but never be actually checked by the server).  In this case, it might be
> useful to be able to annotate a must statement to indicate that it only
> applies to configuration data and not operational data.

Another option could be that "must" constraints on config data do not apply in
, whereas constraints on "config false" data serve as binding
guidelines for implementors.

Anyway, the logic of my example could then be implemented using "must". I agree
though that ignoring the configured value if auto-foo is true may be preferable.

Lada


> Thanks,
> Rob
> 
> On 12/12/2018 14:52, Jan Lindblad wrote:
> > Lada,
> > 
> > Maybe you could just skip the when and explain the behavior in the
> > description? E.g.
> > 
> > leaf foo {
> >  ...
> >  description "Foo controls bla, bla. 
> >   Any configured value will be ignored when auto-foo is true.";
> > }
> > 
> > Best Regards,
> > /jan
> > 
> > > On 12 Dec 2018, at 15:33, Ladislav Lhotka  wrote:
> > > 
> > > Hi,
> > > 
> > > in some cases, constraints expressed with "when" or "must" may only be
> > > intended for configuration datastores. A typical example is an
> > > auto-negotiable parameter:
> > > 
> > > leaf auto-foo {
> > >  type boolean;
> > >  default true;
> > >  description "If true, parameter 'foo' will be auto-negotiated.";
> > > }
> > > leaf foo {
> > >  when "../auto-foo = 'false'";
> > >  ...
> > > }
> > > 
> > > This means that if auto-foo is true, it is impossible to configure the
> > > foo parameter. However, even with auto-foo = true, it is desirable to
> > > see the auto-negotiated value in , so, ideally, the "when"
> > > constraint should not apply in .
> > > 
> > > How can this logic be modelled under NMDA? Is an extra leaf
> > > "foo-operational" needed?
> > > 
> > > Thanks, Lada
> > > 
> > > -- 
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > > 
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > > 
> > 
> > 
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Dec 12 09:13:06 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B75130F34 for ; Wed, 12 Dec 2018 09:13:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sid-QEOZ2QaA for ; Wed, 12 Dec 2018 09:13:01 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9E1F130F27 for ; Wed, 12 Dec 2018 09:13:00 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 40651E71 for ; Wed, 12 Dec 2018 18:12:59 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Vgo9-aMhLrfw for ; Wed, 12 Dec 2018 18:12:59 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 12 Dec 2018 18:12:59 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0244320044 for ; Wed, 12 Dec 2018 18:12:59 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id I26_ejgcjAYc for ; Wed, 12 Dec 2018 18:12:58 +0100 (CET)
Received: from exchange.jacobs-university.de (sxchmb04.jacobs.jacobs-university.de [10.70.0.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id A54BA20043 for ; Wed, 12 Dec 2018 18:12:58 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Wed, 12 Dec 2018 18:12:58 +0100
Received: by anna.localdomain (Postfix, from userid 501) id DAF4E3004E8444; Wed, 12 Dec 2018 18:12:57 +0100 (CET)
Date: Wed, 12 Dec 2018 18:12:57 +0100
From: Juergen Schoenwaelder 
To: 
Message-ID: <20181212171257.fu4r4nk76wy3m7aw@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: netmod@ietf.org
References: <87zhtan7bo.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87zhtan7bo.fsf@nic.cz>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] datastore-specific constraints
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 12 Dec 2018 17:13:05 -0000

On Wed, Dec 12, 2018 at 03:33:15PM +0100, Ladislav Lhotka wrote:
> Hi,
> 
> in some cases, constraints expressed with "when" or "must" may only be
> intended for configuration datastores. A typical example is an
> auto-negotiable parameter:
> 
> leaf auto-foo {
>   type boolean;
>   default true;
>   description "If true, parameter 'foo' will be auto-negotiated.";
> }
> leaf foo {
>   when "../auto-foo = 'false'";
>   ...
> }
> 
> This means that if auto-foo is true, it is impossible to configure the
> foo parameter. However, even with auto-foo = true, it is desirable to
> see the auto-negotiated value in , so, ideally, the "when"
> constraint should not apply in .
> 
> How can this logic be modelled under NMDA? Is an extra leaf
> "foo-operational" needed?

I think the later is the cleanest solution if the modeler insists on
the when statement, even if people do not like this. We discussed
cases like this a lot, the common example was Ethernet auto
negotiation of link speeds. And as far as I recall, the conclusion was
to handle these corner cases properly by defining additional suitable
config false objects that always report the negotiated value in use.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Thu Dec 13 00:51:57 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B852130FA9 for ; Thu, 13 Dec 2018 00:51:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdpkOcrGeItZ for ; Thu, 13 Dec 2018 00:51:45 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0ED130FD3 for ; Thu, 13 Dec 2018 00:51:44 -0800 (PST)
Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id A11CF1AE034F; Thu, 13 Dec 2018 09:51:40 +0100 (CET)
Date: Thu, 13 Dec 2018 09:51:39 +0100 (CET)
Message-Id: <20181213.095139.2195805691286738924.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: rwilton@cisco.com, janl@tail-f.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <2c2eff9a-4cdb-d755-dc2b-05c01d8c8d1d@cisco.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] datastore-specific constraints
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 13 Dec 2018 08:51:55 -0000

Ladislav Lhotka  wrote:
> On Wed, 2018-12-12 at 15:23 +0000, Robert Wilton wrote:
> > Hi Lada,
> > I basically agree with Jan's suggestion.
> > I don't think that I would use a when statement for this scenario since you
> > want a leaf to report the operational value that is in effect, and one of the
> > aims of NMDA is to try and get the configured and operational value onto the
> > same path wherever possible.
> > But, I think that the question about validity of must statements is more
> > interesting.  RFC 8342 states that these can be violated in operational, but
> > the intention is that the constraints in  should generally apply
> > (but never be actually checked by the server).  In this case, it might be
> > useful to be able to annotate a must statement to indicate that it only
> > applies to configuration data and not operational data.
> 
> Another option could be that "must" constraints on config data do not apply in
> , whereas constraints on "config false" data serve as binding
> guidelines for implementors.

Not sure what "binding guideline" means, but note that RFC 8342 says
for :

    SHOULD conform to any constraints specified in the data
   model, but given the principal aim of returning "in use" values, it
   is possible that constraints MAY be violated [...]

   Only semantic constraints MAY be violated.  These are the YANG
   "when", "must", "mandatory", "unique", "min-elements", and
   "max-elements" statements; and the uniqueness of key values.

It would be useful with a YANG statement that indicates when the
modeller's intention is that a constraint doesn't apply to
.  For now, this can be indicated in the description
statement, for example:

  leaf foo {
    when "../auto-foo = 'false'" {
      description
        "This when expression does not apply to .";
    }
    ...
  }



/martin



> 
> Anyway, the logic of my example could then be implemented using "must". I agree
> though that ignoring the configured value if auto-foo is true may be preferable.
> 
> Lada
> 
> 
> > Thanks,
> > Rob
> > 
> > On 12/12/2018 14:52, Jan Lindblad wrote:
> > > Lada,
> > > 
> > > Maybe you could just skip the when and explain the behavior in the
> > > description? E.g.
> > > 
> > > leaf foo {
> > >  ...
> > >  description "Foo controls bla, bla. 
> > >   Any configured value will be ignored when auto-foo is true.";
> > > }
> > > 
> > > Best Regards,
> > > /jan
> > > 
> > > > On 12 Dec 2018, at 15:33, Ladislav Lhotka  wrote:
> > > > 
> > > > Hi,
> > > > 
> > > > in some cases, constraints expressed with "when" or "must" may only be
> > > > intended for configuration datastores. A typical example is an
> > > > auto-negotiable parameter:
> > > > 
> > > > leaf auto-foo {
> > > >  type boolean;
> > > >  default true;
> > > >  description "If true, parameter 'foo' will be auto-negotiated.";
> > > > }
> > > > leaf foo {
> > > >  when "../auto-foo = 'false'";
> > > >  ...
> > > > }
> > > > 
> > > > This means that if auto-foo is true, it is impossible to configure the
> > > > foo parameter. However, even with auto-foo = true, it is desirable to
> > > > see the auto-negotiated value in , so, ideally, the "when"
> > > > constraint should not apply in .
> > > > 
> > > > How can this logic be modelled under NMDA? Is an extra leaf
> > > > "foo-operational" needed?
> > > > 
> > > > Thanks, Lada
> > > > 
> > > > -- 
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > 
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > 
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Thu Dec 13 01:59:01 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD53C130FD4 for ; Thu, 13 Dec 2018 01:58:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJijL-SABABp for ; Thu, 13 Dec 2018 01:58:48 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD913130F8B for ; Thu, 13 Dec 2018 01:58:46 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 47EFF629F2; Thu, 13 Dec 2018 10:58:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1544695123; bh=OWOVic3YyXC9xLV+A0K2R0zp/i4gF7IlN5CVJwNuRKs=; h=From:To:Date; b=MJXoDBU9PlP6CuRRR0Ft4djIV7Adug0LhF5/GIYQiVSm2UbVAvRZkostD8GEy9Pxl MQo+kXABlVN3nLgv68p7rvc73J36hsy7xhnzLPsUt28QMX+hD8MLheNOtMgF0M7QJp P2P1Lr6dcXIbBiVXV531x6DK4XKj71WQ91lp7C2M=
Message-ID: 
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: rwilton@cisco.com, janl@tail-f.com, netmod@ietf.org
Date: Thu, 13 Dec 2018 10:58:43 +0100
In-Reply-To: <20181213.095139.2195805691286738924.mbj@tail-f.com>
References:  <2c2eff9a-4cdb-d755-dc2b-05c01d8c8d1d@cisco.com>  <20181213.095139.2195805691286738924.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.3 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] datastore-specific constraints
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 13 Dec 2018 09:59:00 -0000

On Thu, 2018-12-13 at 09:51 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > On Wed, 2018-12-12 at 15:23 +0000, Robert Wilton wrote:
> > > Hi Lada,
> > > I basically agree with Jan's suggestion.
> > > I don't think that I would use a when statement for this scenario since
> you
> > > want a leaf to report the operational value that is in effect, and one of
> the
> > > aims of NMDA is to try and get the configured and operational value onto
> the
> > > same path wherever possible.
> > > But, I think that the question about validity of must statements is more
> > > interesting.  RFC 8342 states that these can be violated in operational,
> but
> > > the intention is that the constraints in  should generally
> apply
> > > (but never be actually checked by the server).  In this case, it might be
> > > useful to be able to annotate a must statement to indicate that it only
> > > applies to configuration data and not operational data.
> > 
> > Another option could be that "must" constraints on config data do not apply
> in
> > , whereas constraints on "config false" data serve as binding
> > guidelines for implementors.
> 
> Not sure what "binding guideline" means, but note that RFC 8342 says
> for :
> 
>     SHOULD conform to any constraints specified in the data
>    model, but given the principal aim of returning "in use" values, it
>    is possible that constraints MAY be violated [...]

According to the definition of SHOULD and MAY in RFC 2119, this sentence
contradicts itself.

> 
>    Only semantic constraints MAY be violated.  These are the YANG
>    "when", "must", "mandatory", "unique", "min-elements", and
>    "max-elements" statements; and the uniqueness of key values.

It is nice to see "when" listed among semantic constraints. Note, however, that
in sec. 8.1 of RFC 7950, "when" ended up among the constraints that are true in
all data trees (despite my hefty protests in the past). So this is really weird.

Lada

> 
> It would be useful with a YANG statement that indicates when the
> modeller's intention is that a constraint doesn't apply to
> .  For now, this can be indicated in the description
> statement, for example:
> 
>   leaf foo {
>     when "../auto-foo = 'false'" {
>       description
>         "This when expression does not apply to .";
>     }
>     ...
>   }
> 
> 
> 
> /martin
> 
> 
> 
> > 
> > Anyway, the logic of my example could then be implemented using "must". I
> agree
> > though that ignoring the configured value if auto-foo is true may be
> preferable.
> > 
> > Lada
> > 
> > 
> > > Thanks,
> > > Rob
> > > 
> > > On 12/12/2018 14:52, Jan Lindblad wrote:
> > > > Lada,
> > > > 
> > > > Maybe you could just skip the when and explain the behavior in the
> > > > description? E.g.
> > > > 
> > > > leaf foo {
> > > >  ...
> > > >  description "Foo controls bla, bla. 
> > > >   Any configured value will be ignored when auto-foo is true.";
> > > > }
> > > > 
> > > > Best Regards,
> > > > /jan
> > > > 
> > > > > On 12 Dec 2018, at 15:33, Ladislav Lhotka  wrote:
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > in some cases, constraints expressed with "when" or "must" may only be
> > > > > intended for configuration datastores. A typical example is an
> > > > > auto-negotiable parameter:
> > > > > 
> > > > > leaf auto-foo {
> > > > >  type boolean;
> > > > >  default true;
> > > > >  description "If true, parameter 'foo' will be auto-negotiated.";
> > > > > }
> > > > > leaf foo {
> > > > >  when "../auto-foo = 'false'";
> > > > >  ...
> > > > > }
> > > > > 
> > > > > This means that if auto-foo is true, it is impossible to configure the
> > > > > foo parameter. However, even with auto-foo = true, it is desirable to
> > > > > see the auto-negotiated value in , so, ideally, the
> "when"
> > > > > constraint should not apply in .
> > > > > 
> > > > > How can this logic be modelled under NMDA? Is an extra leaf
> > > > > "foo-operational" needed?
> > > > > 
> > > > > Thanks, Lada
> > > > > 
> > > > > -- 
> > > > > Ladislav Lhotka
> > > > > Head, CZ.NIC Labs
> > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > 
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Thu Dec 13 02:25:02 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64570128CFD for ; Thu, 13 Dec 2018 02:25:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVV2-hpsG-LC for ; Thu, 13 Dec 2018 02:24:59 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D3E4E1286E3 for ; Thu, 13 Dec 2018 02:24:58 -0800 (PST)
Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id 6BAB21AE034F; Thu, 13 Dec 2018 11:24:55 +0100 (CET)
Date: Thu, 13 Dec 2018 11:24:54 +0100 (CET)
Message-Id: <20181213.112454.11250508028477040.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: rwilton@cisco.com, janl@tail-f.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <20181213.095139.2195805691286738924.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] datastore-specific constraints
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 13 Dec 2018 10:25:00 -0000

Ladislav Lhotka  wrote:
> On Thu, 2018-12-13 at 09:51 +0100, Martin Bjorklund wrote:
> > Ladislav Lhotka  wrote:
> > > On Wed, 2018-12-12 at 15:23 +0000, Robert Wilton wrote:
> > > > Hi Lada,
> > > > I basically agree with Jan's suggestion.
> > > > I don't think that I would use a when statement for this scenario since
> > you
> > > > want a leaf to report the operational value that is in effect, and one of
> > the
> > > > aims of NMDA is to try and get the configured and operational value onto
> > the
> > > > same path wherever possible.
> > > > But, I think that the question about validity of must statements is more
> > > > interesting.  RFC 8342 states that these can be violated in operational,
> > but
> > > > the intention is that the constraints in  should generally
> > apply
> > > > (but never be actually checked by the server).  In this case, it might be
> > > > useful to be able to annotate a must statement to indicate that it only
> > > > applies to configuration data and not operational data.
> > > 
> > > Another option could be that "must" constraints on config data do not apply
> > in
> > > , whereas constraints on "config false" data serve as binding
> > > guidelines for implementors.
> > 
> > Not sure what "binding guideline" means, but note that RFC 8342 says
> > for :
> > 
> >     SHOULD conform to any constraints specified in the data
> >    model, but given the principal aim of returning "in use" values, it
> >    is possible that constraints MAY be violated [...]
> 
> According to the definition of SHOULD and MAY in RFC 2119, this sentence
> contradicts itself.

It should probably have been "may" then...?

> >    Only semantic constraints MAY be violated.  These are the YANG
> >    "when", "must", "mandatory", "unique", "min-elements", and
> >    "max-elements" statements; and the uniqueness of key values.
> 
> It is nice to see "when" listed among semantic constraints.

Yeah, I was a bit surprised that this sentence classifies "when" as a
semantic constraint...

> Note, however, that
> in sec. 8.1 of RFC 7950, "when" ended up among the constraints that
> are true in 
> all data trees (despite my hefty protests in the past).

Note that also uniqueness of keys is listed in 8.1 as true all data
trees, but relaxed by 8342.


/martin


From nobody Thu Dec 13 02:49:00 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7430512D7F8 for ; Thu, 13 Dec 2018 02:48:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVpOuBXQzK8M for ; Thu, 13 Dec 2018 02:48:55 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63DE1286E3 for ; Thu, 13 Dec 2018 02:48:54 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id E5DF9629A7; Thu, 13 Dec 2018 11:48:52 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1544698132; bh=t/PqsngIo8+cp5PZK2bozgClo9JX0wmSUHq4CHYRrvs=; h=From:To:Date; b=ag2mNhw+3YiX50xz4gfuDH/JS1Ss+nTA607zQxVETXGxvSo97zeHOftuI6aS1qRwg HZyM+b46gQTCGQSJLrUHQzHRdjRcR6FY+K6O0OLWlk+1CJPtmNJCZBPuN1Gwgw4WQ3 SFsTl5JrQ2tBsOYyM1EFEfhchruqodPG/NZafkAo=
Message-ID: <90745533ba7f58415402badb681c43bad797d4a4.camel@nic.cz>
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: rwilton@cisco.com, janl@tail-f.com, netmod@ietf.org
Date: Thu, 13 Dec 2018 11:48:52 +0100
In-Reply-To: <20181213.112454.11250508028477040.mbj@tail-f.com>
References:  <20181213.095139.2195805691286738924.mbj@tail-f.com>  <20181213.112454.11250508028477040.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.3 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] datastore-specific constraints
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 13 Dec 2018 10:48:58 -0000

On Thu, 2018-12-13 at 11:24 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > On Thu, 2018-12-13 at 09:51 +0100, Martin Bjorklund wrote:
> > > Ladislav Lhotka  wrote:
> > > > On Wed, 2018-12-12 at 15:23 +0000, Robert Wilton wrote:
> > > > > Hi Lada,
> > > > > I basically agree with Jan's suggestion.
> > > > > I don't think that I would use a when statement for this scenario
> since
> > > you
> > > > > want a leaf to report the operational value that is in effect, and one
> of
> > > the
> > > > > aims of NMDA is to try and get the configured and operational value
> onto
> > > the
> > > > > same path wherever possible.
> > > > > But, I think that the question about validity of must statements is
> more
> > > > > interesting.  RFC 8342 states that these can be violated in
> operational,
> > > but
> > > > > the intention is that the constraints in  should
> generally
> > > apply
> > > > > (but never be actually checked by the server).  In this case, it might
> be
> > > > > useful to be able to annotate a must statement to indicate that it
> only
> > > > > applies to configuration data and not operational data.
> > > > 
> > > > Another option could be that "must" constraints on config data do not
> apply
> > > in
> > > > , whereas constraints on "config false" data serve as
> binding
> > > > guidelines for implementors.
> > > 
> > > Not sure what "binding guideline" means, but note that RFC 8342 says
> > > for :
> > > 
> > >     SHOULD conform to any constraints specified in the data
> > >    model, but given the principal aim of returning "in use" values, it
> > >    is possible that constraints MAY be violated [...]
> > 
> > According to the definition of SHOULD and MAY in RFC 2119, this sentence
> > contradicts itself.
> 
> It should probably have been "may" then...?

With a sound definition of syntactic and semantic constraints, we could state
that data in 

- MUST satisfy syntactic constraints
- SHOULD satisfy semantic constraints that apply to config=false data

(semantic constraints on config=true data are checked before the data get into
)

> 
> > >    Only semantic constraints MAY be violated.  These are the YANG
> > >    "when", "must", "mandatory", "unique", "min-elements", and
> > >    "max-elements" statements; and the uniqueness of key values.
> > 
> > It is nice to see "when" listed among semantic constraints.
> 
> Yeah, I was a bit surprised that this sentence classifies "when" as a
> semantic constraint...

Every truth will eventually be revealed. :-) 

> 
> > Note, however, that
> > in sec. 8.1 of RFC 7950, "when" ended up among the constraints that
> > are true in 
> > all data trees (despite my hefty protests in the past).
> 
> Note that also uniqueness of keys is listed in 8.1 as true all data
> trees, but relaxed by 8342.

Well, section 8.1 only says this about keys:

   o  All key leafs MUST be present for all list entries.

Their uniqueness is not mentioned (an omission?). Anyway, it is IMO a typical
semantic constraint that shouldn't be enforced in , but due to the
limitations of the NETCONF protocol it has to be.

Lada

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


From nobody Thu Dec 13 03:08:50 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9D11294D7 for ; Thu, 13 Dec 2018 03:08:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.961
X-Spam-Level: 
X-Spam-Status: No, score=-15.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4vREuw2me7V for ; Thu, 13 Dec 2018 03:08:46 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF641286E3 for ; Thu, 13 Dec 2018 03:08:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5171; q=dns/txt; s=iport; t=1544699325; x=1545908925; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ySclL5U0CwAa4Z0joW1WUew8VexAzVj/Ji1hQnDFiV0=; b=TCMRgc5Uhh/WpXssMOVSFejUEF9ovy3wVX4c41iDxxGmZKkVoleQkxry pFCIMRu+1YRlVIGED/cu+OcIkKNl49Gqec7XIU2SiUKNQXp3PAAAG4H3l t2BTb2V36/jjNh1vPHizI4BTrp5DcFk+Dl7mAcKKKff57cM7JeO58N8ZP U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BTAAA2PRJc/xbLJq1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYJqcBIng3yIeI0TLZlODRgLhANGAoMkOBIBAwEBAgE?= =?us-ascii?q?BAm0cDIU8AQEBAQIBAQEhFTYLEAsYAgImAgInMAYBDAYCAQGDHQGBeAgPpmC?= =?us-ascii?q?BL4VAhG8FgQuLSIFAP4ERJ4Jrgx4BAYFLgxqCVwKQDpAsVQmRUwYYiXyHTok?= =?us-ascii?q?uiTGGaoFdIYFWMxoIGxU7gmyLHIU/PwMwjVgBAQ?=
X-IronPort-AV: E=Sophos;i="5.56,348,1539648000";  d="scan'208";a="8837118"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2018 11:08:43 +0000
Received: from [10.63.23.68] (dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com [10.63.23.68]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id wBDB8gHv017628; Thu, 13 Dec 2018 11:08:42 GMT
To: Ladislav Lhotka , Martin Bjorklund 
Cc: janl@tail-f.com, netmod@ietf.org
References:  <2c2eff9a-4cdb-d755-dc2b-05c01d8c8d1d@cisco.com>  <20181213.095139.2195805691286738924.mbj@tail-f.com> 
From: Robert Wilton 
Message-ID: 
Date: Thu, 13 Dec 2018 11:08:42 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.68, dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] datastore-specific constraints
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 13 Dec 2018 11:08:48 -0000

Hi Lada,

On 13/12/2018 09:58, Ladislav Lhotka wrote:
> On Thu, 2018-12-13 at 09:51 +0100, Martin Bjorklund wrote:
>> Ladislav Lhotka  wrote:
>>> On Wed, 2018-12-12 at 15:23 +0000, Robert Wilton wrote:
>>>> Hi Lada,
>>>> I basically agree with Jan's suggestion.
>>>> I don't think that I would use a when statement for this scenario since
>> you
>>>> want a leaf to report the operational value that is in effect, and one of
>> the
>>>> aims of NMDA is to try and get the configured and operational value onto
>> the
>>>> same path wherever possible.
>>>> But, I think that the question about validity of must statements is more
>>>> interesting.  RFC 8342 states that these can be violated in operational,
>> but
>>>> the intention is that the constraints in  should generally
>> apply
>>>> (but never be actually checked by the server).  In this case, it might be
>>>> useful to be able to annotate a must statement to indicate that it only
>>>> applies to configuration data and not operational data.
>>> Another option could be that "must" constraints on config data do not apply
>> in
>>> , whereas constraints on "config false" data serve as binding
>>> guidelines for implementors.
>> Not sure what "binding guideline" means, but note that RFC 8342 says
>> for :
>>
>>      SHOULD conform to any constraints specified in the data
>>     model, but given the principal aim of returning "in use" values, it
>>     is possible that constraints MAY be violated [...]
> According to the definition of SHOULD and MAY in RFC 2119, this sentence
> contradicts itself.

I don't actually see the contradiction here.

- SHOULD can be violated if there are good reasons to do so (otherwise 
it is a MUST)
- The MAY, and its associated condition, explains some conditions under 
which it is reasonable for the SHOULD to be violated.

Thanks,
Rob


>
>>     Only semantic constraints MAY be violated.  These are the YANG
>>     "when", "must", "mandatory", "unique", "min-elements", and
>>     "max-elements" statements; and the uniqueness of key values.
> It is nice to see "when" listed among semantic constraints. Note, however, that
> in sec. 8.1 of RFC 7950, "when" ended up among the constraints that are true in
> all data trees (despite my hefty protests in the past). So this is really weird.
>
> Lada
>
>> It would be useful with a YANG statement that indicates when the
>> modeller's intention is that a constraint doesn't apply to
>> .  For now, this can be indicated in the description
>> statement, for example:
>>
>>    leaf foo {
>>      when "../auto-foo = 'false'" {
>>        description
>>          "This when expression does not apply to .";
>>      }
>>      ...
>>    }
>>
>>
>>
>> /martin
>>
>>
>>
>>> Anyway, the logic of my example could then be implemented using "must". I
>> agree
>>> though that ignoring the configured value if auto-foo is true may be
>> preferable.
>>> Lada
>>>
>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>> On 12/12/2018 14:52, Jan Lindblad wrote:
>>>>> Lada,
>>>>>
>>>>> Maybe you could just skip the when and explain the behavior in the
>>>>> description? E.g.
>>>>>
>>>>> leaf foo {
>>>>>   ...
>>>>>   description "Foo controls bla, bla.
>>>>>    Any configured value will be ignored when auto-foo is true.";
>>>>> }
>>>>>
>>>>> Best Regards,
>>>>> /jan
>>>>>
>>>>>> On 12 Dec 2018, at 15:33, Ladislav Lhotka  wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> in some cases, constraints expressed with "when" or "must" may only be
>>>>>> intended for configuration datastores. A typical example is an
>>>>>> auto-negotiable parameter:
>>>>>>
>>>>>> leaf auto-foo {
>>>>>>   type boolean;
>>>>>>   default true;
>>>>>>   description "If true, parameter 'foo' will be auto-negotiated.";
>>>>>> }
>>>>>> leaf foo {
>>>>>>   when "../auto-foo = 'false'";
>>>>>>   ...
>>>>>> }
>>>>>>
>>>>>> This means that if auto-foo is true, it is impossible to configure the
>>>>>> foo parameter. However, even with auto-foo = true, it is desirable to
>>>>>> see the auto-negotiated value in , so, ideally, the
>> "when"
>>>>>> constraint should not apply in .
>>>>>>
>>>>>> How can this logic be modelled under NMDA? Is an extra leaf
>>>>>> "foo-operational" needed?
>>>>>>
>>>>>> Thanks, Lada
>>>>>>
>>>>>> -- 
>>>>>> Ladislav Lhotka
>>>>>> Head, CZ.NIC Labs
>>>>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> -- 
>>> Ladislav Lhotka
>>> Head, CZ.NIC Labs
>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>


From nobody Thu Dec 13 03:58:56 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF1D12D4E8 for ; Thu, 13 Dec 2018 03:58:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-fOYx0Rkxj8 for ; Thu, 13 Dec 2018 03:58:51 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F182123FFD for ; Thu, 13 Dec 2018 03:58:50 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 6063D60882; Thu, 13 Dec 2018 12:58:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1544702327; bh=bw0aoeFSGU1mDjtE4nwZzqY2OfEXbn7RJGwwj5z6L34=; h=From:To:Date; b=j2yGKL1Dk++5n5vyjqOY6LK4OMKKlhee84LKZoWpXb5RfoK0DTI5BjLorgAWoG5OM MPS/n8j/OWzhgFMXRxw65umS9LYOCsbCh7uBpuRF1sJw3+2sHy24rRv+pWZTADs0GW PJwf6mLAD5Z57JRvwPnYANFXEBlXev+dSS/1z6kc=
Message-ID: <4adac832a12e852e6fc3ad5a11e19085a991e257.camel@nic.cz>
From: Ladislav Lhotka 
To: Robert Wilton , Martin Bjorklund 
Cc: janl@tail-f.com, netmod@ietf.org
Date: Thu, 13 Dec 2018 12:58:47 +0100
In-Reply-To: 
References:  <2c2eff9a-4cdb-d755-dc2b-05c01d8c8d1d@cisco.com>  <20181213.095139.2195805691286738924.mbj@tail-f.com>  
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.3 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] datastore-specific constraints
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 13 Dec 2018 11:58:55 -0000

On Thu, 2018-12-13 at 11:08 +0000, Robert Wilton wrote:
> Hi Lada,
> 
> On 13/12/2018 09:58, Ladislav Lhotka wrote:
> > On Thu, 2018-12-13 at 09:51 +0100, Martin Bjorklund wrote:
> > > Ladislav Lhotka  wrote:
> > > > On Wed, 2018-12-12 at 15:23 +0000, Robert Wilton wrote:
> > > > > Hi Lada,
> > > > > I basically agree with Jan's suggestion.
> > > > > I don't think that I would use a when statement for this scenario
> > > > > since
> > > you
> > > > > want a leaf to report the operational value that is in effect, and one
> > > > > of
> > > the
> > > > > aims of NMDA is to try and get the configured and operational value
> > > > > onto
> > > the
> > > > > same path wherever possible.
> > > > > But, I think that the question about validity of must statements is
> > > > > more
> > > > > interesting.  RFC 8342 states that these can be violated in
> > > > > operational,
> > > but
> > > > > the intention is that the constraints in  should
> > > > > generally
> > > apply
> > > > > (but never be actually checked by the server).  In this case, it might
> > > > > be
> > > > > useful to be able to annotate a must statement to indicate that it
> > > > > only
> > > > > applies to configuration data and not operational data.
> > > > Another option could be that "must" constraints on config data do not
> > > > apply
> > > in
> > > > , whereas constraints on "config false" data serve as
> > > > binding
> > > > guidelines for implementors.
> > > Not sure what "binding guideline" means, but note that RFC 8342 says
> > > for :
> > > 
> > >      SHOULD conform to any constraints specified in the data
> > >     model, but given the principal aim of returning "in use" values, it
> > >     is possible that constraints MAY be violated [...]
> > According to the definition of SHOULD and MAY in RFC 2119, this sentence
> > contradicts itself.
> 
> I don't actually see the contradiction here.
> 
> - SHOULD can be violated if there are good reasons to do so (otherwise 
> it is a MUST)
> - The MAY, and its associated condition, explains some conditions under 
> which it is reasonable for the SHOULD to be violated.

MAY means "truly optional" (e.g. "because the vendor feels that it enhances the
product"). Combining different RFC2119 terms is generally problematic.

Lada

> 
> Thanks,
> Rob
> 
> 
> > >     Only semantic constraints MAY be violated.  These are the YANG
> > >     "when", "must", "mandatory", "unique", "min-elements", and
> > >     "max-elements" statements; and the uniqueness of key values.
> > It is nice to see "when" listed among semantic constraints. Note, however,
> > that
> > in sec. 8.1 of RFC 7950, "when" ended up among the constraints that are true
> > in
> > all data trees (despite my hefty protests in the past). So this is really
> > weird.
> > 
> > Lada
> > 
> > > It would be useful with a YANG statement that indicates when the
> > > modeller's intention is that a constraint doesn't apply to
> > > .  For now, this can be indicated in the description
> > > statement, for example:
> > > 
> > >    leaf foo {
> > >      when "../auto-foo = 'false'" {
> > >        description
> > >          "This when expression does not apply to .";
> > >      }
> > >      ...
> > >    }
> > > 
> > > 
> > > 
> > > /martin
> > > 
> > > 
> > > 
> > > > Anyway, the logic of my example could then be implemented using "must".
> > > > I
> > > agree
> > > > though that ignoring the configured value if auto-foo is true may be
> > > preferable.
> > > > Lada
> > > > 
> > > > 
> > > > > Thanks,
> > > > > Rob
> > > > > 
> > > > > On 12/12/2018 14:52, Jan Lindblad wrote:
> > > > > > Lada,
> > > > > > 
> > > > > > Maybe you could just skip the when and explain the behavior in the
> > > > > > description? E.g.
> > > > > > 
> > > > > > leaf foo {
> > > > > >   ...
> > > > > >   description "Foo controls bla, bla.
> > > > > >    Any configured value will be ignored when auto-foo is true.";
> > > > > > }
> > > > > > 
> > > > > > Best Regards,
> > > > > > /jan
> > > > > > 
> > > > > > > On 12 Dec 2018, at 15:33, Ladislav Lhotka  wrote:
> > > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > in some cases, constraints expressed with "when" or "must" may
> > > > > > > only be
> > > > > > > intended for configuration datastores. A typical example is an
> > > > > > > auto-negotiable parameter:
> > > > > > > 
> > > > > > > leaf auto-foo {
> > > > > > >   type boolean;
> > > > > > >   default true;
> > > > > > >   description "If true, parameter 'foo' will be auto-negotiated.";
> > > > > > > }
> > > > > > > leaf foo {
> > > > > > >   when "../auto-foo = 'false'";
> > > > > > >   ...
> > > > > > > }
> > > > > > > 
> > > > > > > This means that if auto-foo is true, it is impossible to configure
> > > > > > > the
> > > > > > > foo parameter. However, even with auto-foo = true, it is desirable
> > > > > > > to
> > > > > > > see the auto-negotiated value in , so, ideally, the
> > > "when"
> > > > > > > constraint should not apply in .
> > > > > > > 
> > > > > > > How can this logic be modelled under NMDA? Is an extra leaf
> > > > > > > "foo-operational" needed?
> > > > > > > 
> > > > > > > Thanks, Lada
> > > > > > > 
> > > > > > > -- 
> > > > > > > Ladislav Lhotka
> > > > > > > Head, CZ.NIC Labs
> > > > > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > netmod mailing list
> > > > > > > netmod@ietf.org
> > > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > netmod mailing list
> > > > > > netmod@ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > -- 
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > 
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Thu Dec 13 18:13:48 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F977130F7C for ; Thu, 13 Dec 2018 18:13:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 8315voC9bh06 for ; Thu, 13 Dec 2018 18:13:44 -0800 (PST)
Received: from mail-pf1-f179.google.com (mail-pf1-f179.google.com [209.85.210.179]) (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 663F4130F74 for ; Thu, 13 Dec 2018 18:13:44 -0800 (PST)
Received: by mail-pf1-f179.google.com with SMTP id q1so2040182pfi.5 for ; Thu, 13 Dec 2018 18:13:44 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xuhG6VqeV0tADn5VHjeMkLyAkB5KI799KfPkmX0/jJI=; b=FR4qVewIaLrcbXqfobp3NGzkNHP3ha7IQd5EMsiUhLcr+xhtwQ+VG5tfq4zuDqdkpZ rasr7EGDtwC2yhaCpVcXsDgm6JqYE0hplP+2W8HCP9StMLxueL8M4o6zX0mnU4T8IKkp 0E7La0BGHLJRr+I3IEdTUB4GNKuYmZBwour7hxXIiLlK3utvMZ/myJ4yZI0fmW0T6pHl 0bpqxHlE6S1GDXLv3nk4quOMwG1xgBrRzertbkeR+5k1O4/jzKoxOXl7+rRL+9//PyfZ DvJE/g/xJdqM1NHPvRih0SA81x5ZFlX9pAHtMFmN9X82e1S7oEoYH4saEr66L2iuCWQS 4vIw==
X-Gm-Message-State: AA+aEWZBxcQsKJNuXUvB/CpSv9YJC6I5hXsVpV1pv45kivudq3wuTbAe sIWDskopFCZZPk9DrvB8+fqXcJBDlVY=
X-Google-Smtp-Source: AFSGD/W/Kglb1NnR4N+cAl5R677SMDAXPNoEsl4OMzvmesTHEeyXluDP1sV0yWhzV8TJGL755/k9dQ==
X-Received: by 2002:a63:194f:: with SMTP id 15mr1124074pgz.192.1544753623311;  Thu, 13 Dec 2018 18:13:43 -0800 (PST)
Received: from [192.168.1.103] (c-69-181-241-121.hsd1.ca.comcast.net. [69.181.241.121]) by smtp.gmail.com with ESMTPSA id r66sm4371042pfk.157.2018.12.13.18.13.42 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Dec 2018 18:13:42 -0800 (PST)
To: netmod@ietf.org
References:  <2c2eff9a-4cdb-d755-dc2b-05c01d8c8d1d@cisco.com>  <20181213.095139.2195805691286738924.mbj@tail-f.com>   <4adac832a12e852e6fc3ad5a11e19085a991e257.camel@nic.cz>
From: Randy Presuhn 
Message-ID: 
Date: Thu, 13 Dec 2018 18:13:42 -0800
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <4adac832a12e852e6fc3ad5a11e19085a991e257.camel@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] datastore-specific constraints
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 14 Dec 2018 02:13:46 -0000

Hi -

On 12/13/2018 3:58 AM, Ladislav Lhotka wrote:
....
>>>>       SHOULD conform to any constraints specified in the data
>>>>      model, but given the principal aim of returning "in use" values, it
>>>>      is possible that constraints MAY be violated [...]
>>> According to the definition of SHOULD and MAY in RFC 2119, this sentence
>>> contradicts itself.
>>
>> I don't actually see the contradiction here.
>>
>> - SHOULD can be violated if there are good reasons to do so (otherwise
>> it is a MUST)
>> - The MAY, and its associated condition, explains some conditions under
>> which it is reasonable for the SHOULD to be violated.
> 
> MAY means "truly optional" (e.g. "because the vendor feels that it enhances the
> product"). Combining different RFC2119 terms is generally problematic.

 From the perspective of the receiver, there is no difference.
"Good reasons" tend to be subjective and there's generally no
way for the receiver to know whether those conditions are true
for the sender or its implementer.

Consequently, for the code processing a protocol stream, a "SHOULD"
describing that stream is equivalent to a "MAY", since it only
says that the behaviour described is *possible*, and, that under
conditions to which the receiver will not be privy, other things
may happen.

Randy


From nobody Fri Dec 14 09:53:10 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94821130E37; Fri, 14 Dec 2018 09:53:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.36
X-Spam-Level: 
X-Spam-Status: No, score=-3.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Lsjk4Gcyoff; Fri, 14 Dec 2018 09:52:59 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150093.outbound.protection.outlook.com [40.107.15.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C92B130DF9; Fri, 14 Dec 2018 09:52:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kQUgBmDRq0B7fMldeCv55dpy3Xem/NV1g3oA/AtRvws=; b=I3ZIBVcbVY1o0PQaQB8NRadrgZbunhCXsqd7VhsWBulJSC7STb41oNYRmmIIyuCsCL4sFqZup50Ke5ehvblH+BzgBWs6AF6qJ8XvvlgcmmN9t/c8c70kntSAzQWzfRxKUOE+uvH2KJT1/aRuVByWC5Cs9L0V51jQrOqe8eX2xnw=
Received: from VI1PR07MB3981.eurprd07.prod.outlook.com (52.134.28.141) by VI1PR07MB5424.eurprd07.prod.outlook.com (20.178.15.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1425.9; Fri, 14 Dec 2018 17:52:56 +0000
Received: from VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::85f6:118d:d689:232a]) by VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::85f6:118d:d689:232a%2]) with mapi id 15.20.1446.010; Fri, 14 Dec 2018 17:52:56 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: "netmod@ietf.org" , "netconf@ietf.org" 
Thread-Topic: magic leaf 'type' in IETF interfaces
Thread-Index: AdST1E2jOdI/metmQeWzMudzc2MYTQ==
Date: Fri, 14 Dec 2018 17:52:56 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.245.20.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB5424; 6:pU6jHCQ02h6ov+J65oElREhY83Qt8qKopgY5SAKPPQ/uzCmJiXONyGPH5XMRO41fIU3gY3YyF0l6gkIOBbp10EoNU7Qu+aP6I0GAnK0SBAoT56aFUpOWIPxfKPxk2Maer3XEsTtjmhpqCzQXFwzvhJoUOJRQasRIZvJIUlqaHRYLn/rpu7WNlfm6r88aTBZvxSpUGrmnmIO8fLMh+qKtkLPTEvwSBBFNM7so2mOBAV5gsNduH82Oqplcc1QBagUyVgewJ5qbPml2HsoidSPyW4DviLQR7w3e95oKLyhzHn5RqEKmoqugqu1r7aPaxy5AdsWPiGBHuY3yTqNq0x6w+IBzzY5aQQiKMKLfCoBX4l0RrmTDYCzpoKUnc9LBwBkZF1erFd+IM1KkazDkiDjXeEYIH196fMaBvjwL+S3r8JoGqOVE4udRy+lvwkfsf+ZLRvUyTIVAqUn/hu88FkUhPQ==; 5:jW7nvVIf/LeGMImEy1lZRln0HNhs0+YLitfLKzKDTT24yg0pot1C9SEJz+7tCswu4rtB1UwbB4iWHZXobLiJyztqBzT68dvoHbh48DsYFWu4+RDc/O32BOW9FgYp43KhEirdbFdfsaT7gmARsHa/ObbOY0C0NKJDFbdjDlMlbe0=; 7:T4eYHW1nno5Mk6Z+HcJbTqaNN8meMci530raECvS40M05+gQvy5Na3HnMRzT2JgFxs+em0Lom+Si8HFXqmfDO7ImqoQyYy8ZQiBSsG4kIGuk+JSuvHvL9zNtmdkBALrGDZuVg0eaG8oeun0Pg/lS6A==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: a8ce0273-7651-477a-5553-08d661ecfa7e
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1PR07MB5424; 
x-ms-traffictypediagnostic: VI1PR07MB5424:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(11241501185)(806100)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231475)(944501520)(52105112)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB5424; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB5424; 
x-forefront-prvs: 08864C38AC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(39860400002)(346002)(366004)(376002)(53754006)(199004)(189003)(476003)(450100002)(14454004)(316002)(486006)(6306002)(55016002)(97736004)(66066001)(9686003)(110136005)(54896002)(25786009)(2501003)(14444005)(106356001)(478600001)(81166006)(6116002)(81156014)(6346003)(86362001)(26005)(71200400001)(3846002)(8936002)(71190400001)(8676002)(6436002)(68736007)(256004)(53936002)(105586002)(5660300001)(6506007)(2906002)(99286004)(186003)(102836004)(790700001)(7736002)(7696005)(33656002)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5424; H:VI1PR07MB3981.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com; 
x-microsoft-antispam-message-info: p5o3iVr2n97z32gTnKlZ/ObKEAgTFf+JZVizcnIFeFtr0/HMv6cgKMpcQIIA28eEWNUc0HJ0JSBiQeYMHWs4OQ5+bJSEAUOCt1LxSF8YAydggjUrBmgldf7X2Rvr8BWkirnA5OmUlyjqSCqQa/22aT6TZiXbrwkk7M7AOsRRcXU4/TvsvSA5d3UHdCUntnozedHfJpX5ZhOyJFMLTvr9jKrDZIqniS3k3+ztQpUmvKBB9GYrDmrkoXHtRqN8vaUCsh9PvoPZEsayTqlgVF23JI7CDFnhxUxVqe2mdEJvJ2/gJU1gSGjiWF3lvr+6qTfx
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB39818BD20967B36B8F24DBA69BA10VI1PR07MB3981eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a8ce0273-7651-477a-5553-08d661ecfa7e
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Dec 2018 17:52:56.1950 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5424
Archived-At: 
Subject: [netmod] magic leaf 'type' in IETF interfaces
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 14 Dec 2018 17:53:03 -0000

--_000_VI1PR07MB39818BD20967B36B8F24DBA69BA10VI1PR07MB3981eurp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

Cross posting because I'm not sure whether this is more of interest to NETC=
ONF clients or a general YANG & datastore question.

In IETF Interfaces there is a leaf 'type'. Here is a snippet of the model:

      leaf type {
        type identityref {
          base interface-type;
        }
        mandatory true;
        description
          "The type of the interface.

           When an interface entry is created, a server MAY
           initialize the type leaf with a valid value

This says that although the leaf is mandatory, a NETCONF client creating a =
new interface does not have to specify/provide that leaf. That strikes me a=
s the first unusual point.

Secondly -> this also means that a NETCONF client may send a config with el=
ements X, Y, and Z, but then later read back the config to see X, Y, Z and =
T  (e.g. type). But they never configured the type leaf.

Shouldn't most clients generally assume that what they write, they read bac=
k (unless there are 'choice' or 'when' statements involved of course, but t=
hat are part of the YANG and any auto-clearing behavior from those would be=
 expected)?

Or does 'anything go' / 'market decides' when it comes to behavior like thi=
s explained in 'description' statements?

Is it just fine that some NETCONF servers auto-magically create some (extra=
) data nodes inside a list entry that a client created? (would like to see =
opinions from multiple people on this - especially client developers).

I would think that each and every magic creation/deletion/changes done by a=
 server (i.e. that aren't part of the YANG, except perhaps part of a human-=
readable (non-machine parsable) 'description' statement) would require some=
 special handling code on the client (or app above the client) side.

I can imagine several alternatives to the way it was modelled above:
1) NMDA approach: make the leaf optional. If the operator doesn't set that =
leaf, then reading the conventional datastores doesn't return that leaf. Bu=
t reading the operational DS could return the actual system selected value.
2) separate config & state leafs for 'type':  make the leaf optional. If th=
e operator doesn't set that leaf, then reading the conventional datastores =
doesn't return that leaf. But have another state leaf called 'oper-type'.

I'm not proposing to re-open the IETF Interface model. Just using it to ask=
 questions about server created config data and explore alternatives.

Jason

--_000_VI1PR07MB39818BD20967B36B8F24DBA69BA10VI1PR07MB3981eurp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all,


 


Cross posting because I'm not s=
ure whether this is more of interest to NETCONF clients or a general YANG &=
amp; datastore question.


 


In IETF Interfaces there is a l=
eaf 'type'. Here is a snippet of the model:


 


      =
leaf type {


     &=
nbsp;  type identityref {


     &=
nbsp;    base interface-type;


     &=
nbsp;  }


     &=
nbsp;  mandatory true;


     &=
nbsp;  description


     &=
nbsp;    "The type of the interface.<=
/p>

 


     &=
nbsp;     When an interface entry is created, a server =
MAY


     &=
nbsp;     initialize the type leaf with a valid value


 


This says that although the lea=
f is mandatory, a NETCONF client creating a new interface does not have to =
specify/provide that leaf. That strikes me as the first unusual point.=



 


Secondly -> this also means =
that a NETCONF client may send a config with elements X, Y, and Z, but then=
 later read back the config to see X, Y, Z and T  (e.g. type). But the=
y never configured the type leaf.


 


Shouldn't most clients generall=
y assume that what they write, they read back (unless there are 'choice' or=
 'when' statements involved of course, but that are part of the YANG and an=
y auto-clearing behavior from those
 would be expected)?


 


Or does 'anything go' / 'market=
 decides' when it comes to behavior like this explained in 'description' st=
atements?


 


Is it just fine that some NETCO=
NF servers auto-magically create some (extra) data nodes inside a list entr=
y that a client created? (would like to see opinions from multiple people o=
n this - especially client developers).


 


I would think that each and eve=
ry magic creation/deletion/changes done by a server (i.e. that aren't part =
of the YANG, except perhaps part of a human-readable (non-machine parsable)=
 'description' statement) would require
 some special handling code on the client (or app above the client) side.


 


I can imagine several alternati=
ves to the way it was modelled above:


1) NMDA approach: make the leaf=
 optional. If the operator doesn't set that leaf, then reading the conventi=
onal datastores doesn't return that leaf. But reading the operational DS co=
uld return the actual system selected
 value.


2) separate config & state =
leafs for 'type':  make the leaf optional. If the operator doesn't set=
 that leaf, then reading the conventional datastores doesn't return that le=
af. But have another state leaf called 'oper-type'.


 


I'm not proposing to re-open th=
e IETF Interface model. Just using it to ask questions about server created=
 config data and explore alternatives.


 


Jason






--_000_VI1PR07MB39818BD20967B36B8F24DBA69BA10VI1PR07MB3981eurp_--


From nobody Fri Dec 14 10:12:51 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FD2131203 for ; Fri, 14 Dec 2018 10:12:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.358
X-Spam-Level: 
X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7oia7r67Cvg for ; Fri, 14 Dec 2018 10:12:46 -0800 (PST)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 133381311FD for ; Fri, 14 Dec 2018 10:12:45 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id a16so4942068lfg.3 for ; Fri, 14 Dec 2018 10:12:45 -0800 (PST)
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=rrjGOZJVxlzP8n48x9BaksrsPcV1mGpw8eeXmMk9Gu4=; b=eXQdsS6MyNY6RM1uEs7J9hvdt+K5eq3jEVJsispOaWQ+dUDVC3oHr0oisCYrmKaKeJ y5nFD3iz9NUw4yrsD72cCzOj5wDm0wxtppH5icAvrkWJZdcga4qoi55pVtRAfKJM+Is2 SkUkwHN58CPKkkl79NKGUasUp1zzP0Rd4RFcaFIp8IAzhRxclprUfCun6qP4+rjLvcAN LvHRLcUcR5NmW3xNcQFlWFR1zplUYVC9xAfwj0n+5bw/iVqkNS1etSPWFk1TPbaxI2eq F9UsKCayxD0nrDmBn+qQfgJ9OH7Kl0lNPoYIAp0OehG8f0GHjpCWzxbutnQBqdZBjSQR xMcw==
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=rrjGOZJVxlzP8n48x9BaksrsPcV1mGpw8eeXmMk9Gu4=; b=oCie+lVTYoCaCrFW7d+pp8eYQKDcMMsqzgyR2xtoC7ldL7jFrEdOCUhECNFVGxUolM UjtpqokyG48ODskX11QCLMDp0VyymQR5WUqhelig2bPRdrtlxWIqIQl9BwBjMTITkdw8 GmK2i+EB3SPC8UH84208k8cZKYzX9pMKimdxlvxcXTyXnqGPkOhbpixqN/nQSDtmwM0Z aMUeUIrtgcosBifg91z0gzatigxS28DAyl11ntk4fZ8lgK7dfmm5fxiTL8i1veig1+3+ 2DFklAexn31XG5BHRiq9zMb3mXqup4Wq8ATANrUFAgPO9KH5pOGutQdyzs7QWD4ZYLs9 DTuA==
X-Gm-Message-State: AA+aEWZV2Qg2CPNF3yB60i/pUdFkaUzyIqBBglvBOc9Ul3ICIuRMND/M zrEz2bPsJCb8NNQGFiGGeRfGtCq5d/Zt046AL0lprQ==
X-Google-Smtp-Source: AFSGD/XMffVVOYurNzUAl/ElVckLCYusWGxCcmMcBT7t8JvjFaeufm71AnKBRs/gMmFbByb+/7vFGK8n2lAf+ftg7eI=
X-Received: by 2002:a19:750a:: with SMTP id y10mr2389859lfe.43.1544811163974;  Fri, 14 Dec 2018 10:12:43 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Andy Bierman 
Date: Fri, 14 Dec 2018 10:12:32 -0800
Message-ID: 
To: "Sterne, Jason (Nokia - CA)" 
Cc: NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000ac991c057cff6048"
Archived-At: 
Subject: Re: [netmod] [Netconf] magic leaf 'type' in IETF interfaces
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 14 Dec 2018 18:12:50 -0000

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

On Fri, Dec 14, 2018 at 9:53 AM Sterne, Jason (Nokia - CA/Ottawa) <
jason.sterne@nokia.com> wrote:

> Hi all,
>
>
>
> Cross posting because I'm not sure whether this is more of interest to
> NETCONF clients or a general YANG & datastore question.
>
>
>
> In IETF Interfaces there is a leaf 'type'. Here is a snippet of the model:
>
>
>
>       leaf type {
>
>         type identityref {
>
>           base interface-type;
>
>         }
>
>         mandatory true;
>
>         description
>
>           "The type of the interface.
>
>
>
>            When an interface entry is created, a server MAY
>
>            initialize the type leaf with a valid value
>
>
>
> This says that although the leaf is mandatory, a NETCONF client creating a
> new interface does not have to specify/provide that leaf. That strikes me
> as the first unusual point.
>
>
>
> Secondly -> this also means that a NETCONF client may send a config with
> elements X, Y, and Z, but then later read back the config to see X, Y, Z
> and T  (e.g. type). But they never configured the type leaf.
>
>
>
> Shouldn't most clients generally assume that what they write, they read
> back (unless there are 'choice' or 'when' statements involved of course,
> but that are part of the YANG and any auto-clearing behavior from those
> would be expected)?
>
>
>
> Or does 'anything go' / 'market decides' when it comes to behavior like
> this explained in 'description' statements?
>
>
>
> Is it just fine that some NETCONF servers auto-magically create some
> (extra) data nodes inside a list entry that a client created? (would like
> to see opinions from multiple people on this - especially client
> developers).
>
>
>
> I would think that each and every magic creation/deletion/changes done by
> a server (i.e. that aren't part of the YANG, except perhaps part of a
> human-readable (non-machine parsable) 'description' statement) would
> require some special handling code on the client (or app above the client)
> side.
>
>
>
> I can imagine several alternatives to the way it was modelled above:
>
> 1) NMDA approach: make the leaf optional. If the operator doesn't set that
> leaf, then reading the conventional datastores doesn't return that leaf.
> But reading the operational DS could return the actual system selected
> value.
>
> 2) separate config & state leafs for 'type':  make the leaf optional. If
> the operator doesn't set that leaf, then reading the conventional
> datastores doesn't return that leaf. But have another state leaf called
> 'oper-type'.
>
>
>
> I'm not proposing to re-open the IETF Interface model. Just using it to
> ask questions about server created config data and explore alternatives.
>
>
>

I think NMDA says the "type" leaf is mandatory in  not .
I agree that YANG could be a lot more expressive about the auto-magic
server behavior
between  and . Any YANG client will see "mandatory true"
and
assume a value needs to be provided.



> Jason
>

Andy


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

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




On Fri=
, Dec 14, 2018 at 9:53 AM Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com> wrote:











Hi all,

=C2=A0


Cross posting because I'm n=
ot sure whether this is more of interest to NETCONF clients or a general YA=
NG & datastore question.


=C2=A0


In IETF Interfaces there is a l=
eaf 'type'. Here is a snippet of the model:

=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
leaf type {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 type identityref {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 base interface-type;


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


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 mandatory true;


=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 "The type of the interface.


=C2=A0


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 When an interface entry is created, a server=
 MAY


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 initialize the type leaf with a valid value<=
u>


=C2=A0


This says that although the lea=
f is mandatory, a NETCONF client creating a new interface does not have to =
specify/provide that leaf. That strikes me as the first unusual point.


=C2=A0


Secondly -> this also means =
that a NETCONF client may send a config with elements X, Y, and Z, but then=
 later read back the config to see X, Y, Z and T=C2=A0 (e.g. type). But the=
y never configured the type leaf.


=C2=A0


Shouldn't most clients gene=
rally assume that what they write, they read back (unless there are 'ch=
oice' or 'when' statements involved of course, but that are par=
t of the YANG and any auto-clearing behavior from those
 would be expected)?


=C2=A0


Or does 'anything go' /=
 'market decides' when it comes to behavior like this explained in =
'description' statements?


=C2=A0


Is it just fine that some NETCO=
NF servers auto-magically create some (extra) data nodes inside a list entr=
y that a client created? (would like to see opinions from multiple people o=
n this - especially client developers).


=C2=A0


I would think that each and eve=
ry magic creation/deletion/changes done by a server (i.e. that aren't p=
art of the YANG, except perhaps part of a human-readable (non-machine parsa=
ble) 'description' statement) would require
 some special handling code on the client (or app above the client) side.


=C2=A0


I can imagine several alternati=
ves to the way it was modelled above:


1) NMDA approach: make the leaf=
 optional. If the operator doesn't set that leaf, then reading the conv=
entional datastores doesn't return that leaf. But reading the operation=
al DS could return the actual system selected
 value.


2) separate config & state =
leafs for 'type':=C2=A0 make the leaf optional. If the operator doe=
sn't set that leaf, then reading the conventional datastores doesn'=
t return that leaf. But have another state leaf called 'oper-type'.=



=C2=A0


I'm not proposing to re-ope=
n the IETF Interface model. Just using it to ask questions about server cre=
ated config data and explore alternatives.


=C2=A0
<=
/div>

I think NMDA says the "type"=
; leaf is mandatory in <intended> not <running>.
I ag=
ree that YANG could be a lot more expressive about the auto-magic server be=
havior
between <running> and <intended>. Any YANG cli=
ent will see "mandatory true" and
assume a value needs =
to be provided.

=C2=A0
=



Jason

Andy
=C2=A0






_______________________________________________

Netconf mailing list

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




--000000000000ac991c057cff6048--


From nobody Mon Dec 17 00:15:11 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D028F128CE4; Mon, 17 Dec 2018 00:15:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SKYOnq6LX6H; Mon, 17 Dec 2018 00:15:08 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 27369128BCC; Mon, 17 Dec 2018 00:15:08 -0800 (PST)
Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id B1FF21AE0397; Mon, 17 Dec 2018 09:15:06 +0100 (CET)
Date: Mon, 17 Dec 2018 09:15:05 +0100 (CET)
Message-Id: <20181217.091505.218628572185200621.mbj@tail-f.com>
To: jason.sterne@nokia.com
Cc: netmod@ietf.org, netconf@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Netconf] magic leaf 'type' in IETF interfaces
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Dec 2018 08:15:10 -0000

Hi,

"Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> Hi all,
> 
> Cross posting because I'm not sure whether this is more of interest to
> NETCONF clients or a general YANG & datastore question.
> 
> In IETF Interfaces there is a leaf 'type'. Here is a snippet of the
> model:
> 
>       leaf type {
>         type identityref {
>           base interface-type;
>         }
>         mandatory true;
>         description
>           "The type of the interface.
> 
>            When an interface entry is created, a server MAY
>            initialize the type leaf with a valid value
> 
> This says that although the leaf is mandatory, a NETCONF client
> creating a new interface does not have to specify/provide that
> leaf. That strikes me as the first unusual point.

Yes, unusual, but "safe" in the sense that a client that doesn't have
code for this special case will just see the "mandatory true" and
provide a value for the type as well.

> Secondly -> this also means that a NETCONF client may send a config
> with elements X, Y, and Z, but then later read back the config to see
> X, Y, Z and T (e.g. type). But they never configured the type leaf.

Right, but again this only happens for clients that know this special
rule.

> Shouldn't most clients generally assume that what they write, they
> read back (unless there are 'choice' or 'when' statements involved of
> course, but that are part of the YANG and any auto-clearing behavior
> from those would be expected)?
> 
> Or does 'anything go' / 'market decides' when it comes to behavior
> like this explained in 'description' statements?
> 
> Is it just fine that some NETCONF servers auto-magically create some
> (extra) data nodes inside a list entry that a client created? (would
> like to see opinions from multiple people on this - especially client
> developers).

In general, my reply is "no, that is not fine".

The reason for this unusual design is that most existing systems code
type-info into the name of an interface ("ethX", "ge-X/Y/Z",
"GigabitEthernet-X/Y" etc), and having to provide the type in the name
and in a special leaf would just be redundant and error prone.  The
thinking at the time was that the interface model that we designed had
to adapt to how existing systems behave.

> I would think that each and every magic creation/deletion/changes done
> by a server (i.e. that aren't part of the YANG, except perhaps part of
> a human-readable (non-machine parsable) 'description' statement) would
> require some special handling code on the client (or app above the
> client) side.

Yes.  But as long as this special handling is optional in the client I
think it is ok.

> I can imagine several alternatives to the way it was modelled above:
> 1) NMDA approach: make the leaf optional. If the operator doesn't set
> that leaf, then reading the conventional datastores doesn't return
> that leaf. But reading the operational DS could return the actual
> system selected value.
>
> 2) separate config & state leafs for 'type': make the leaf
> optional. If the operator doesn't set that leaf, then reading the
> conventional datastores doesn't return that leaf. But have another
> state leaf called 'oper-type'.

Both these cases assume that the type can be derived from the name.

> I'm not proposing to re-open the IETF Interface model. Just using it
> to ask questions about server created config data and explore
> alternatives.

The rule of thumb is to avoid server created config as much as
possible.


/martin


From nobody Mon Dec 17 01:06:06 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236D11294D7 for ; Mon, 17 Dec 2018 01:06:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.058
X-Spam-Level: 
X-Spam-Status: No, score=-4.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=bPsQBFCk; dkim=pass (1024-bit key) header.d=ericsson.com header.b=RoCwl6T+
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akFfrzfyrl3r for ; Mon, 17 Dec 2018 01:06:03 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96344128BCC for ; Mon, 17 Dec 2018 01:06:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1545037560; x=1547629560; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BIJoJrwfmNge57lMx1ibO6KY5q4WxAwFAWDgpqYr5Jg=; b=bPsQBFCkt8UAR+xeCcqF9x1QL7va63yQkSuB756rWClIqhv2SjKDHo0gsg2/ilwi Fzcspn+Jr7ugm+9EBu+pQETY2BkOyCYNPAjdMOrNyaigHPUUbbTPN6ZVZ/StmmjU k0EDAoKkouYnrmQ60nlh63YSuWBEnhpBhFA74X8lZvQ=;
X-AuditID: c1b4fb25-da1ff70000005ff7-56-5c1766f85a64
Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F5.C0.24567.8F6671C5; Mon, 17 Dec 2018 10:06:00 +0100 (CET)
Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Mon, 17 Dec 2018 10:06:00 +0100
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Mon, 17 Dec 2018 10:06:00 +0100
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=MpIzUzKYaTXUl9h6pIrM7hvvfznm4kicMWU6y3lnfoE=; b=RoCwl6T+VKxHobYsHq7j48ybJrA9bZfb114inyJREaADv1ygu0B5lHwuewgC2iFrWxRb65D0/l2eKblRkuOfAezvaDxUSxswFXeBRCUMc73ZunvN8mbvrgdGWX7gHsIFt4j1Vo9WeH6WFn0FeeEx22Fw5DZoJ6oJgvoaWn7eLLU=
Received: from VI1PR07MB5568.eurprd07.prod.outlook.com (20.178.80.94) by VI1PR07MB5726.eurprd07.prod.outlook.com (20.178.121.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.9; Mon, 17 Dec 2018 09:05:59 +0000
Received: from VI1PR07MB5568.eurprd07.prod.outlook.com ([fe80::e4b9:de8d:5325:e729]) by VI1PR07MB5568.eurprd07.prod.outlook.com ([fe80::e4b9:de8d:5325:e729%5]) with mapi id 15.20.1446.015; Mon, 17 Dec 2018 09:05:59 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Martin Bjorklund , "jason.sterne@nokia.com" 
CC: "netconf@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [netmod] [Netconf] magic leaf 'type' in IETF interfaces
Thread-Index: AdST1E2jOdI/metmQeWzMudzc2MYTQCDE/6AAAHFl4A=
Date: Mon, 17 Dec 2018 09:05:59 +0000
Message-ID: <83b139a1-a0ab-5fbc-f702-7f0d50a46864@ericsson.com>
References:  <20181217.091505.218628572185200621.mbj@tail-f.com>
In-Reply-To: <20181217.091505.218628572185200621.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [89.135.192.225]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
x-clientproxiedby: HE1PR0502CA0020.eurprd05.prod.outlook.com (2603:10a6:3:e3::30) To VI1PR07MB5568.eurprd07.prod.outlook.com (2603:10a6:803:c1::30)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB5726; 6:FJU3hQbXZp/katRt+vpLcFTFHrgZRP0i7smxyoJ/kDJiNqIMNThFcGEhunoTNSAl/+nkxDw8tyuIBGmoDxa4oweNZlL//BDOslVPcMyZvCAfwbTDs0SzD2EXa8EBu86+IoePg7vJL31alD8ZTZtLZ+s87RyfQXBGbz1jh92L9UDPPrkgt9Kquj8kXiXoZoLbXbpmaM9QbvH0guA0l/Y/6Nzoag2RlbfpwneGbc9P6FTCn4sOEJlj8Ayb0jlrTM2+MafLpHlfpWmumyaWhHH/gYortzqu9gfCzjaR5x5BzUUVNiRdNZPdZWZFq8mvfvJnRtogHVXbhK2Gh8lNPMVyrmXrkUg/ZQxGfUuv7i60QUFokkcMzWIaQgC/ZfEaWaCt3kgMAW9vlm0QpAiYcCITnf5Sh6SlJ40SeN2pzfi6Q7WpeGPWultko8YCWSpShd1HSFOil0CBx9ZH+jq8FUNwKw==; 5:RM5abbuyRVIhFUfmKSdOTMgm898SHAtXdpfWXMfpXtH6giyj56g2sS1UIPaJZqfwI8n79ALWuWlKZolFA89Z4L0t2TZZhwn1LXQbeksKYPj8VmRIUfQs2ArK/Z9FCVm7lXtV7jzkbdF0siR60K1GTKtPyKf3ktPSEEdxpMnQpQY=; 7:WTWskPriQb25dcszReZs+Q85rwmtpLHWjlCp5Y3cc7oBtzeotOmscWj8eAN/3IE0S7QvmY4/n42eqVo5cWPP+F6iIa+ABlBUJnEyF+bkAouhKw6FsvqUtmTW6R+iKhV5wP5dMmE9pDvXQvcfQjf0og==
x-ms-office365-filtering-correlation-id: a4bb469e-e4bf-4735-9869-08d663fedc66
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR07MB5726; 
x-ms-traffictypediagnostic: VI1PR07MB5726:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(102415395)(6040522)(2401047)(5005006)(8121501046)(3231475)(944501520)(4983020)(52105112)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB5726; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB5726; 
x-forefront-prvs: 08897B549D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(136003)(366004)(39860400002)(189003)(199004)(102836004)(8936002)(81166006)(54896002)(386003)(6506007)(6512007)(186003)(8676002)(26005)(81156014)(64126003)(236005)(71200400001)(71190400001)(65826007)(6486002)(99286004)(99936001)(53936002)(5660300001)(52116002)(76176011)(2906002)(25786009)(66066001)(65806001)(6436002)(7736002)(68736007)(65956001)(476003)(2616005)(11346002)(486006)(446003)(256004)(14444005)(36756003)(54906003)(86362001)(85182001)(3846002)(2501003)(6116002)(85202003)(106356001)(110136005)(14454004)(105586002)(58126008)(316002)(31696002)(31686004)(4326008)(478600001)(97736004)(6246003)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5726; H:VI1PR07MB5568.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 0yQfBMFp2nWsDSCfviSnjYKuZynBxulXcFwt4Zr2GCJViD/p2dTXYsDyldp59E1wZY8HM7syWuCa9SmHkzz9XuY/CH+KV5sIYqESdIa7Cjbk6bkeWFcHs5HHiEc3h24pWEQrQyRB8+ZvS0h0x2VrsiPiDuiPyRAJ1zpxkmVn5R/xiOt8h4bcsWSHTeRM6/7P/agFMw+M6GIkTKXAblZ82PZ/NVreaWtC9lxk+Puo8Rl1eYRYHKZCr34LUas4TCwjsdTAnhColTwrXXt4PdfD+QUg7KXuhy1sNHRe1O/vI3si1ZvI1ikLUPlhiqy3j1fI
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060507050409070400090809"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a4bb469e-e4bf-4735-9869-08d663fedc66
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2018 09:05:59.3300 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5726
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA2WSa0hTYRjHe3fOzuahwXFN92D0wYP6YZU1u7gyzMrIAq2gIGRpK082XZvt qGRfXEp4GdLFJBVJpTEyh5cVJZaY4qUrpaHVTFNnoqldIe/Wttcg6Nvvef///3OBV0xIx4V+ Yq0+lTPqNTqWosmSYw/S18+clqs32mwhKvvNJkJlNo+KVEX2PqGqvOuiMIKMslhmBVH9jm5B VP3cLfIQEUvvSOB02nTOuCH8BH3mSY+TTPkWdv5ydyVlQo2h+chLDMxmyB26K8pHtFjKtCFo fPyDxMUvBO2lUwgXFgG8q832KCRzhYDsxbblzFUBFI72E7gYRvC7zEK5O1NMJOR8aRa4WcbE QtVkK+lmgomBbtNboZtXuTzTTXYCe/ZC4cKka57Yxduho2OP+5lkAuH2hwpPVMLshK8v6oR4 1jUE483zyC14MRFQPT/hMSHGF6af2QR4lhwcI+UCfKkMhrqeU5h9YNy5JMTMQvFnh4d9mONQ lJflOQaYGwgGc2pFuGkcPBrIXQ6vg5dvRxDmNdBdbkY40EtBVcPgctdocIzdJrHgcK36MY/E ggKmsloI95nAJMPAovYKUpb+syzmPAR2W0ip52pveFoyQpa6EgQTBNZL7P/2tWCtnCAwh0Hx XAuF2R+um4dEmLfARPt3hHkTWGsWqQpE30E+PMefPJsYsimYM2pP8bxBH6znUu3I9ela7s0H NqA3k7taESNG7ErJgTi5WirUpPMZZ1tRgKvPcF31a+RH6g16jpVJCrb5qqWSBE3GBc5oiDem 6Ti+Fa0Wk6xcsiD1VkuZRE0ql8xxKZzxryoQe/mZEKV4MZYUP5k8lJEpPedMCdEfNtBWRVRv JiFiD+pmjoTTs9YwzrnE9Q3u3ncw7Nt+mX/o0c445U96w7MeHpRbV/TIYsIVhnp4WKarMZuK zBpa1RcRpFP3Kc3T1b+S899P2dWmzQHFQnNawKdODTyILEgKvpDDxkV3nX51nyX5MxqlgjDy mj9MnCA9fAMAAA==
Archived-At: 
Subject: Re: [netmod] [Netconf] magic leaf 'type' in IETF interfaces
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Dec 2018 09:06:05 -0000

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


  
    
  
  
    
Hello,

    
While I agree with Martin, in our systems we have a number of
      places, where the system does create configuration in running, due
      to

    
    
      
  • different levels of automation and autonomous algorithms
        kick-in
    • 
      
  • the created config needs to be possible to be further modified
        by the operator
    • 
      
  • the created config needs to be referenced from operator
        created config
    • 
      
  • the created config is not always ephemeral, it might need to
        be part of backup/restore
    • 
    

    
regards Balazs

    

    
On 2018. 12. 17. 9:15, Martin Bjorklun=
d
      wrote:

    

    

      
The rule of thumb is to avoi=
d server created config as much as
possible.


/martin


    

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


  



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

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DMkwggX/MIID56ADAgECAhEA6b7XEWzAzOaLFTWM1P8xITANBgkqhkiG9w0BAQsFADBHMQsw
CQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIElu
ZGl2aWR1YWwgQ0EgdjMwHhcNMTcxMDA5MTUyNDU4WhcNMjAxMDA5MTUyNDU3WjBqMREwDwYD
VQQKDAhFcmljc3NvbjEYMBYGA1UEAwwPQmFsw6F6cyBMZW5neWVsMSowKAYJKoZIhvcNAQkB
FhtiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20xDzANBgNVBAUTBkVUSEJMTDCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBANRS2ed5R8eLjbxg+S9b4CwI14oIIqrvZLNRmkGC
CKPL6gtU7RyBNdcfKCtn4pPxNvISQ/C4eL5XhNDFYDIyEZqdZkdZld72CERmskMlsLMUwc6p
H7AQOcjW8zex9BDryJKxZAt32imdvb+KGImW326nvlVGnKPmV5pu/PE4tCKYmBmJdpnOw89P
adE7LK0rE6wTkpt9PeY2h/dswbVuCBm0YYDUYElyHB0UnBAohKF89WbUJ26W8lXWE9V5zG20
wk0/NJ9J+vJv9vrhCdHnJz+lLHxLEPSHSuc1PvcCXcB/aJGCF1c3iiYMplg5x0r+wTkdOYtM
W5ahkCcv9Ge04r0CAwEAAaOCAcEwggG9MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwu
dHJ1c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUF
BwEBBHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggr
BgEFBQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5k
aXZpZHVhbGNhdjMuY2VyMCYGA1UdEQQfMB2BG2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv
bTBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3Jl
cG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcD
BAYIKwYBBQUHAwIwHQYDVR0OBBYEFKQnDa9vIwWZ/21jW6uT015h+IyBMB8GA1UdIwQYMBaA
FBx7GZ6XnHasID3Y3OORauPbLaZTMA4GA1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQsFAAOC
AgEAPVEJV/kN/a4JfA+95fMsEYiOzPeTaVrlRSWKgL6Lgyzq8ay2pchfsrbj5ZzjWemL4bnE
WG+QCSa5M/+Pb0XnEkm4lzLc5wvRuvTa8p7ZYkmeWK8H5f2mU+DSQxQFLSUuruQc9Ss78Et4
ggVG5qTLTl5mVOcY1wtuflWll2NfghxdlXvyqlkjcvrs+jVSAfM5OJaiVzvmOso7HdQ7D3x9
ZGuAk8FQh6oN4PU0N8Xs+UzgKqVp3TrajouUz3B8CegvPPTPTh09e0mQ5xOJmA4t0+goibst
HXBn1zqZjDiyC2hUCzXpjZwI8HGpamxb71kJwMo89nN4F7MIrKJykMltOoJUwgt3ePfwdZQ9
YW5UhNk2AA3MdbUKmCqaIsgAAOLOcIK251MT59wHc712667/K4QwTXsszLUZgwpezVAJeZOr
aGupMlDYADZOxZm2jGXdWKomA0FaOdCIzB0KXkO6tqXaNk/+JToyaJq5Q1if1hb9WJSW6gEF
1pQcymc//uQzRaTyPdbOFyCDH4GKaXaAKikxorUQliNAf/Yn3k0YSRJ1l9XMVSbBXfIx3iY6
EhrFbRISr1vV5YgJn8EBxUGlLJTSwTWCmcE7nAvGP4ilJ2IaVLiNzfuoKv/f3F2/VSe73eCU
KYerTGBfng3wSzIwE8Lf7NJK7WqEJtTtUlYjPZowggbCMIIEqqADAgECAhBTuH6D4ZyZKJOw
m0kc7LjrMA0GCSqGSIb3DQEBCwUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD
DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE1MTAyNzEyMTY0NloXDTI1MTAyNzEyMTY0
NlowRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3Nv
biBOTCBJbmRpdmlkdWFsIENBIHYzMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA
7PLfAAC4UPKnu9hUt8aT9+PBqjvUw0Y0tLPOXkO2NC0y2XZks9nJfpWKrNM30k5vu5norG4Z
KlF5C+3xc6HuIiGQof1bmFGluNOwmZQwl3rOJ+E6k0rqJJTerjj4WOxAvWVW1yC5S4Ubppk3
Q3cYVVuC3qNGsBIXy3/fDL1sc8Ah8zI/JumDpjY8fn/U3CRN6mgNKYrr0sZX6VXYgrpT05Zr
JldkUgUgMKgbIWWEXEASA36pnb5GqD/RMzSgIe8o7YQtIaYB2cmTCLNHjaOL9j1JhNK4bvmb
NJ7o58IZYzwNv/G/L/bRosQ9c27U+86DNjrdZnpyaRaeMyVUn3SlYLaFqoObdh/xNF2NS8CX
s/PVtO57HBKHMgZqQvsyQJisSocxFqiMj9VK2WhCBbvoTvrNDZvLDlDGuE5RuKwFIpHOVOU5
lCBgUUBsbpWIXwM6kmH/KC1DC5MtQzmvXkbt7KdBXUAxM0JZxf4dS+ACtTDpF9b0vny4Drwa
OS0VNXyz1GUOxSqw1wup5dpXbxLZYx1rLRgZqr9uWhLwAPsq66ZQof5GL0gY72Ym8/Tm28Me
Mqku+/zRzdYsmclT9rOdgdgS3b6OMoc5Op0ZPEv/Mx2lFJAVK674ozw2hiuRTVUmoqBr5Auy
CoqCEyn32C7U/V7oqyqx5Yd1c5GsxuOqQFcCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcBAQR+
MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr
BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlh
c29uZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwr
BgEEAYIPAgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRl
bGlhc29uZXJhLmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0
LnRlbGlhc29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggr
BgEFBQcDAgYIKwYBBQUHAwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQcexmel5x2rCA9
2NzjkWrj2y2mUzAfBgNVHSMEGDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0B
AQsFAAOCAgEAUFhr8dWMO7Quq1dDyIynw8sWmpyF/jWSxBjpHUCyhltoFS7Q1CUBD0bOULWm
YjmzRwme5pkjTFXpOJZLf9Han1SBbrVcP0JMhRsAvfWZjcF0l/c/jqDMqBARxr8OUWOr0ZWa
49Lir3QEs2C+CjGge5tzcLqzQ5pjWxudrLkSGe+sAThDnXUWXGYk8udGZAamJ55drdw96AV9
jWQkMrLIVHKkXVG5Etdx0wiAoTLk1fVtLcz11DiaCZSZVPZ3fdSIpIRhDqz8H4sVprPgvLBd
K/ajdbiRsehCzzohay3zbXDDTDGwKkR8KUi8Xt8HDZCRsb/U/C7MC4tVK0SEPOQCo6swZy0r
I0RoGzICfsSrZ4JrxANeeSZqCn1A+w0Wz+iqdeP2PVxW0f1rg4/OG2DSl3uB3Q3NT/lDGJte
pti+i5CCKEZcdAOZoviu43sLhqsxSpGjzZidESwovuHeP+O2bNwwtz1DTsXThBB3+JJHVjmk
iLo900GITb/i7IBdLoo4gZms9s1BQ2tm3CJCmpA2XwBTOB6B8/CtgWUWhyloXd3Wbmv7ZUoq
qJFBV9g8Zh5mdZ+RzPTomgCFz/2aNsddI/2G9ZjN4tG6hmocZR2M5f0MhBv3bo6d5XsLlYwi
NJjw5GRqYb8cqqeCaPKkveBJzqgb8ToH7WLoOzmPRCmPlpAxggM+MIIDOgIBATBcMEcxCzAJ
BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k
aXZpZHVhbCBDQSB2MwIRAOm+1xFswMzmixU1jNT/MSEwDQYJYIZIAWUDBAIBBQCgggGzMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTIxNzA5MDU0OVow
LwYJKoZIhvcNAQkEMSIEIAHLuf12Rg2tcHyWXMknop3eoLYb/RXKsSV8BRa1wOR5MGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAKvcrM+Qz99Rojoqg24RQSE8s2b7NdHupT8I/TBTaF2nIgUV
rhCcCmAmPfsA6oIlJjjXNoUXAJwoltsruLveTapdXWH0lyI1qGAS8OQWNH0WMDOSmERjzFRl
Frp5sBuqJJYBHQIVMjgL9nq8vcxAyZ4G60OTrB48fV/rqx1mV1T+lutp1vNfw6KDpzpW8z7q
+Kk2d97Zq9buQJBDwUQlB4wuzBs/yGf+Bj+QG8LGGbz/Cz8xwEC0GoC9SOflRWhhTlY79ed0
hmhe1DGIGzKbJCo+z+wK0ACgFG2iMZqE7M0PSy//8We6a9gHFdJiGO0zkNDLOJ9vr/QCNMBz
rd2Lt8YAAAAAAAA=

--------------ms060507050409070400090809--


From nobody Tue Dec 18 05:36:53 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E966124BE5; Tue, 18 Dec 2018 05:36:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxoohyhdOmOo; Tue, 18 Dec 2018 05:36:49 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AD4021200B3; Tue, 18 Dec 2018 05:36:49 -0800 (PST)
Received: from [10.147.40.113] (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id 284EB1B03C8A; Tue, 18 Dec 2018 14:36:47 +0100 (CET)
From: Jan Lindblad 
Message-Id: <90DB3C3B-FD52-4903-81B0-93985E6F74FE@tail-f.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_78C8BFD7-5283-42AA-BB1B-CB25D5BA2C9C"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Tue, 18 Dec 2018 14:36:44 +0100
In-Reply-To: <83b139a1-a0ab-5fbc-f702-7f0d50a46864@ericsson.com>
Cc: Martin Bjorklund , "jason.sterne@nokia.com" , "netconf@ietf.org" , "netmod@ietf.org" 
To: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= 
References:  <20181217.091505.218628572185200621.mbj@tail-f.com> <83b139a1-a0ab-5fbc-f702-7f0d50a46864@ericsson.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: Re: [netmod] [Netconf]   magic leaf 'type' in IETF interfaces
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Dec 2018 13:36:51 -0000

--Apple-Mail=_78C8BFD7-5283-42AA-BB1B-CB25D5BA2C9C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,
> While I agree with Martin, in our systems we have a number of places, =
where the system does create configuration in running, due to
>=20
> different levels of automation and autonomous algorithms kick-in
> the created config needs to be possible to be further modified by the =
operator
> the created config needs to be referenced from operator created config
> the created config is not always ephemeral, it might need to be part =
of backup/restore
This is only a sampling from "the list of excuses". I have heard many =
more. The road to hell is paved with good intentions, however. If we =
want to build automation based on sound theory, clearly separating the =
orders from managers from a system's own operational view is key, IMO. =
Reliability, security, accountability are growing in importance, and =
they all play in this direction.

We may not need to standardize rules to outlaw the above; the market =
will take care of that. What we need to ensure is that it is possible to =
be standards compliant without having to implement design excuses like =
these.

Best Regards,
/jan


--Apple-Mail=_78C8BFD7-5283-42AA-BB1B-CB25D5BA2C9C
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

Hi,
While I agree with Martin, in our systems we have a number of
      places, where the system does create configuration in running, due
      to

    
    
      
  • different levels of automation and autonomous algorithms
        kick-in
    • 
      
  • the created config needs to be possible to be further modified
        by the operator
    • 
      
  • the created config needs to be referenced from operator
        created config
    • 
      
  • the created config is not always ephemeral, it might need to
        be part of backup/restore
This is only a sampling from "the list of excuses". I have heard many more. The road to hell is paved with good intentions, however. If we want to build automation based on sound theory, clearly separating the orders from managers from a system's own operational view is key, IMO. Reliability, security, accountability are growing in importance, and they all play in this direction.

We may not need to standardize rules to outlaw the above; the market will take care of that. What we need to ensure is that it is possible to be standards compliant without having to implement design excuses like these.

Best Regards,
/jan


--Apple-Mail=_78C8BFD7-5283-42AA-BB1B-CB25D5BA2C9C--


From nobody Tue Dec 18 06:57:23 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8CC126CC7 for ; Tue, 18 Dec 2018 06:57:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.781
X-Spam-Level: 
X-Spam-Status: No, score=-4.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=WyHuGEXj; dkim=pass (1024-bit key) header.d=ericsson.com header.b=R9Zdz7g2
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fywEKAmOI5k7 for ; Tue, 18 Dec 2018 06:57:18 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13F19126DBF for ; Tue, 18 Dec 2018 06:57:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1545145035; x=1547737035; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=CRfoirUeKRRkOV2w5y7Td23xiWsfxLeUB1TQC+Lx0BE=; b=WyHuGEXjoTMGA4W4RhSGZ4Qg2wwNpA9jm+Szrs2tLoKeiYzGXIJQS0iUXDs3xMge hUP1lxw4YE2JIL+sU/se9Ef/H5B+KSmIvn6McesPI5OL9sklpzJuD8B/yi+eGkAC BwAzOfn1JbE+A2SH6iEX3JfXxhFUDAXGC/VsyLcKP4Q=;
X-AuditID: c1b4fb30-f93ff7000000355c-c4-5c190acb0db7
Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 15.E6.13660.BCA091C5; Tue, 18 Dec 2018 15:57:15 +0100 (CET)
Received: from ESESBMR505.ericsson.se (153.88.183.201) by ESESBMB502.ericsson.se (153.88.183.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 18 Dec 2018 15:57:15 +0100
Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMR505.ericsson.se (153.88.183.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 18 Dec 2018 15:57:15 +0100
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 18 Dec 2018 15:57:15 +0100
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=FSJ/tnAGg4iXKCRkDAZgYKFT6+Pnm5XaA9AXQgu8B5E=; b=R9Zdz7g2xIt4TzxfWx6xIjvULTw1g0r+I23rfmzhZxoHg/ClQ3wOLXivtu87I7uWOCh0J6I/w5F36N6SfYYZCPeFSHr15t+clPP7+ZKFLXawcy/45wv0Asots0iugP0mxFJqr6HRH9ZAFNkLdWXlZDebjFpTZSvugIKYG4y1gQA=
Received: from VI1PR07MB5568.eurprd07.prod.outlook.com (20.178.80.94) by VI1PR07MB5456.eurprd07.prod.outlook.com (20.178.14.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.12; Tue, 18 Dec 2018 14:57:12 +0000
Received: from VI1PR07MB5568.eurprd07.prod.outlook.com ([fe80::e4b9:de8d:5325:e729]) by VI1PR07MB5568.eurprd07.prod.outlook.com ([fe80::e4b9:de8d:5325:e729%5]) with mapi id 15.20.1446.015; Tue, 18 Dec 2018 14:57:12 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: "netmod@ietf.org" 
Thread-Topic: Any implementation of ietf-snmp.yang RFC 7407
Thread-Index: AQHUluH1+ZPg2oT3eU2kR3/biyw72g==
Date: Tue, 18 Dec 2018 14:57:12 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [89.135.192.225]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
x-clientproxiedby: AM6PR05CA0025.eurprd05.prod.outlook.com (2603:10a6:20b:2e::38) To VI1PR07MB5568.eurprd07.prod.outlook.com (2603:10a6:803:c1::30)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB5456; 6:UZUZhwKmPqagv/esR9LbnQ/1vVtVPlnvnJWasE4gypEpmvpuWjee6FMxci2W9th4/Ncwm5wy7sFsq4rpQW7B9Wiq1X3EtEjcbRYBrq/TFe5oLsMcSpDc5ZB9ttgvkc4p8mmkrCjr39zVY8i7bMyXY5AmrktNv+Nh+H2PeJlC6of4QUF0GBy8rlqt54K918urym0E/GbaooFWKAXEnIgeMYY4tQ7C99XaNVGWiPZsoMiMJCJ1fvuHWPPZzXHt5BNc27HM6Gl5GtH+Ytoa0bWxf5KwaefmEEhaOjB6lw0pOlO06GvbE50Nm64A0XMHWCKoc+iJ0by1hnViCeQH2RskvywEeOHqBBLaYLJ610gO7F7kZ2wf3bHgMI3s9nxoVDrw8SIZtDL2umhQ6Kxd8S20gHShFa6I7Plvn1SM/Eh2bKm9VMqjJfGcm8bQeduzkDDfyNu+c1MMUJyBRl6/27Q/DA==; 5:GluAjUYotU26ucIVqRK7zJjTZ+y13XnRgrk27aISR1pOJ8WIzAa2fqrQI4fwIoKAC7HMKOlC/ugI/9d91z2JJv8HbM9hqJK9/8zCIBdyQzfwDVHXFL0Z5xzWixue8MOL6C+sXoCcH3zUH3UdkmK+2GSl6rj56qBnRCpACBHUvN0=; 7:uG512fmczbh2WWPKQjhsnrffVj/5XKs1oOTg1KlwDdnWrMdiuIGjNwRQho7VReo/jDWbeV9EagU3g04jzJNkdv/FbgBOVTVx4KGgZK0CFdxlPu/xs+Ki+J2CkD6sZ6X8uoHWKk6HJ7AellDGYF4PsA==
x-ms-office365-filtering-correlation-id: cb8883e8-1a5e-4011-3284-08d664f9177d
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR07MB5456; 
x-ms-traffictypediagnostic: VI1PR07MB5456:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(102415395)(6040522)(2401047)(5005006)(8121501046)(3231475)(944501520)(4983020)(52105112)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB5456; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB5456; 
x-forefront-prvs: 08902E536D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(346002)(376002)(136003)(396003)(199004)(189003)(64126003)(85182001)(2616005)(5660300001)(53936002)(31686004)(7736002)(316002)(58126008)(31696002)(478600001)(86362001)(71190400001)(5640700003)(71200400001)(6512007)(25786009)(305945005)(99936001)(14454004)(6486002)(6436002)(68736007)(81166006)(1730700003)(81156014)(8676002)(106356001)(85202003)(105586002)(2351001)(26005)(65826007)(36756003)(8936002)(97736004)(186003)(2906002)(99286004)(65806001)(65956001)(66066001)(2501003)(386003)(6116002)(3846002)(256004)(102836004)(476003)(6916009)(486006)(52116002)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5456; H:VI1PR07MB5568.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: zsR51B427zkMtpbAs8uH8MaRakUndIiMvN/Msd7FdXOBq3kJIJEmaOI7tFgzEuSMlxTDFR3zAIhE5NnHMHhTphW85h6Vle49bSJ1bIPFxK/ketFjv5eI/BhRwXW2jEOC/Dj13ULr2wOLU062EyxZFz6pYXwGeml1WA91Wxo2niyhY686lu8cvpDQ2k4f0LerosqkX7ucRclZvuA6KlOhfHD22acjNzy0+1yezUOjClBtdRNNsSW1bZc6rg3XRB8A8ReI4/qjY3YjsipBtV0y0Sdy5Aidja4YCdvZphko9+nSV2htQO2FTLA+/LsoZbff
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060709060201070508030608"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: cb8883e8-1a5e-4011-3284-08d664f9177d
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2018 14:57:12.5470 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5456
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTYRjG+XbOzo6jwXF5eVVSGl2G1bwsrdC0QsjESIgixC5TDyrOzXbm yK5LE29FCopOITMv5RKvXYxMceofJtGU0hDTNsW8FYRRaGZt+yzqv9/z3p7vgY8mxGa+J52i 0rIalUIpoYSk4dRTbteg0CPOv+aJdG/V0HX+ARRZW7vMi0GxwtBEVpmiYzV+YeeEySPZ76n0 d/ILlqVretQQUICcaGB2Q+NykaAACWkx04egsrKVh8U3BC2Dy+iveDyhp7Co5cHAvW6HIJki AoaXzCTuFPPgbVM1HwsrgsGi26TdhmIiIPdzN8/OLsx2MDxrpuy8kQmGlYZCmwltq4dAXwvg ERn0Z9c4RkhmKzS3lgnsLGLCoc3S4TiDGDf4/rLRwQTjDmPTVTycyAUsQ4MUZleYm1rjY5ZA +fyYg12Z01Can0XY3wlMGQJju5GPj56Bzom89eWd8Gp0GmHeBMNVhQgvjFBgzTMIcOMo5JSY 1x3GEJhf0/YwwPjC87pUXE6FFyWfCMzeYLxlITEvEnCjmy1CfhX/ZKiwWRBMPoLigZuowhHa GQYM0yQeCoY77RYC8w6or14g/l+2cwiUr/RQmDdDSaFFgDkIFvq/IMxyqG/6Sd1FQiNy5Vgu Pi0pMFDGalISOE6tkqlYbRuy/a2eRz/8O9Dcx4MmxNBIskEkEnjEifkKHZeZZkJbbHesLQ/N yJNUqVWsxEU0lgFxYlGiIvMiq1Gf1WQoWc6EvGhS4i5aFTvHiZkkhZZNZdl0VvOny6OdPPVI 0B0dMbVUEq5RhsayelPtnFdkeP++cX2F1PlYavsD76DDnerxrK9uWqmsyutDfJpPr7l+9ore V37f6Jq0X/vGf3Z+RrftyNzJ0tbLPpdOdEWdl0ZNmmNGZB6xq2HBhl55yCGdx+Ri/56l47l+ zlejg3JmJhPoul/1VtPoWoFvl4TkkhUBvoSGU/wGk6BmpWMDAAA=
Archived-At: 
Subject: [netmod] Any implementation of ietf-snmp.yang RFC 7407
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Dec 2018 14:57:21 -0000

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

Hello,

Does anyone know about implementations of the ietf-snmp YANG model?
As far as I could find none of the SW/vendors yumapro, tailf/confd,=20
snmp-research, adventnet, netsnmp, snmp4j, Cisco, Huawei, Nokia, Juniper =

have implemented it.

regards Balazs

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



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

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

--------------ms060709060201070508030608--


From nobody Tue Dec 18 08:10:25 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E8A130EDA for ; Tue, 18 Dec 2018 08:10:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[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 x2EEH6ngJBOP for ; Tue, 18 Dec 2018 08:10:22 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4C372130EAF for ; Tue, 18 Dec 2018 08:10:22 -0800 (PST)
Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id 2C3CA1B03C8C; Tue, 18 Dec 2018 17:10:19 +0100 (CET)
Date: Tue, 18 Dec 2018 17:10:18 +0100 (CET)
Message-Id: <20181218.171018.1430858087061589506.mbj@tail-f.com>
To: balazs.lengyel@ericsson.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] Any implementation of ietf-snmp.yang RFC 7407
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Dec 2018 16:10:24 -0000

Bal=E1zs Lengyel  wrote:
> Hello,
> =

> Does anyone know about implementations of the ietf-snmp YANG model?
> As far as I could find none of the SW/vendors yumapro, tailf/confd,
> snmp-research, adventnet, netsnmp, snmp4j, Cisco, Huawei, Nokia,
> Juniper have implemented it.

We shave an implementation that isn't exactly the model in the RFC,
but close.  Did you ask b/c you have found some issue with the model?


/martin


From nobody Tue Dec 18 08:21:54 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138A4130F07 for ; Tue, 18 Dec 2018 08:21:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.361
X-Spam-Level: 
X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.105, RCVD_IN_DNSWL_MED=-2.3, 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 header.b=W4rD6gs3; dkim=pass (1024-bit key) header.d=ericsson.com header.b=OVm1GQ9I
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOcEE_0ki1QN for ; Tue, 18 Dec 2018 08:21:51 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0322130EFF for ; Tue, 18 Dec 2018 08:21:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1545150108; x=1547742108; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=c/D2FXfMdxQhMvjpEp5YL3CxbdLMu7/g7plzymIyT+Y=; b=W4rD6gs39CZMs8MIobzEHiaECH1C1uwfj2CgfAzyWVzZxN9Qf/JB2IB/mKhkWmFL 17X4lisXdetvGNBX8xtt5X8LRYwYcTnsYNSAops0n0rVqnSxX4SOu85pLOJ8EQd+ h4Mag5jWSZxDJ29873ZZzsIhkInDrLzVI7bMa+NQ8pA=;
X-AuditID: c1b4fb3a-167ff7000000672c-d2-5c191e9c3400
Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 7C.1A.26412.C9E191C5; Tue, 18 Dec 2018 17:21:48 +0100 (CET)
Received: from ESESBMR503.ericsson.se (153.88.183.135) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 18 Dec 2018 17:21:48 +0100
Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESBMR503.ericsson.se (153.88.183.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 18 Dec 2018 17:21:48 +0100
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 18 Dec 2018 17:21:48 +0100
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=aYTNNTCXGoVRu1hMps9RmxwAZEkTUHzBZdbjG6CRWNY=; b=OVm1GQ9IxFABppBsriPOn0qJYB6WyVUvItKid1SRpHk8yhURvyVEQG4dKAPYrrFjEMbkwV1Td0qaY+ALIPRKwI4+lDTf4D0yvy+7O+bPT2q/fM2bXUFZtSHsKfxfHwqN/HrsREZvUuvKV8lidMXyc/3Bf3mfu7KWJTNnzaIJxUE=
Received: from VI1PR07MB5568.eurprd07.prod.outlook.com (20.178.80.94) by VI1PR07MB4125.eurprd07.prod.outlook.com (52.134.21.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.8; Tue, 18 Dec 2018 16:21:45 +0000
Received: from VI1PR07MB5568.eurprd07.prod.outlook.com ([fe80::e4b9:de8d:5325:e729]) by VI1PR07MB5568.eurprd07.prod.outlook.com ([fe80::e4b9:de8d:5325:e729%5]) with mapi id 15.20.1446.015; Tue, 18 Dec 2018 16:21:45 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: "netmod@ietf.org" , Martin Bjorklund 
Thread-Topic: [netmod] Any implementation of ietf-snmp.yang RFC 7407
Thread-Index: AQHUluH1+ZPg2oT3eU2kR3/biyw72qWEqpIAgAADLwA=
Date: Tue, 18 Dec 2018 16:21:45 +0000
Message-ID: 
References:  <20181218.171018.1430858087061589506.mbj@tail-f.com>
In-Reply-To: <20181218.171018.1430858087061589506.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [89.135.192.225]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
x-clientproxiedby: AM6P194CA0096.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:8f::37) To VI1PR07MB5568.eurprd07.prod.outlook.com (2603:10a6:803:c1::30)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB4125; 6:atzUcF2265WIh/tX7gDCL2qzMS+qyBv7iBh1837zLMOWpFx/nKjbw2Uy8NucEdfvITj87ifnWrWksX/WcIcuy+XA+ywUAZ60D2DIOo8Yeuq77uZUh1Zba6FqjmLK/IDkm8i3sn/1uA96cPmxHjfOXfK2l4WvaRhIc6DdIOMv2qlkCGJfCq5pWb7um+JLMP5A1Z9W+TK6AwNo6IflP10tZLbDxUiQNAsSK6/svndEWuvT5gF0AyPw9TV+UXVKVpF2/gnvQL6RaVsyFt/OQnm0FrPPr6xmtGAh1TmMa+QMcJ+GIvcgsPXABqEEQfyEVI5vR9J16aaKVPjG9GlFVa7hNqw/y+ZJ448GA8jnwOUjUQdInA3O+VOd+Jh0t/C/eT4NGw1ho/Sy+QeSo+LK24CZOxSXqjUR62JVebZBXawNgoeuTGjx/pB6dc76gSQYYIP5dl2fI9qRU9lKEENEuvOUcw==; 5:2JWm7kpHgR81Ar2X+5O5TtuEzJcFnmZ7TatSLi691ZNifM//zIcQgGkgQa7m/UeBGGnGrJdHfKwd/IlMo3gYj/CGhPYhv2+i98IMPpHlQBlWwP1vKg50k+pqumnAKnLEToP3X2kI/qryK7drLYbp/TtX2PoAgu+aubfSEPPQgfM=; 7:6cjvEwA9VEMDh2L3h5JNVZxfbt7kfynfYfXE3EcJbPcrIHij0WTz331MuRJqH/wuM+YWKLA/F3CEahBYAbwv98jQufZarH+oz5EvhS5Uc/ExY+k1VC/Z0gjJ19GrdxOMwu20zEPH32MeLKQpgJqg6w==
x-ms-office365-filtering-correlation-id: c4bec7cc-b13f-4db8-3643-08d66504e710
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR07MB4125; 
x-ms-traffictypediagnostic: VI1PR07MB4125:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(102415395)(6040522)(2401047)(5005006)(8121501046)(3231475)(944501520)(4983020)(52105112)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB4125; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4125; 
x-forefront-prvs: 08902E536D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(346002)(136003)(396003)(376002)(199004)(189003)(97736004)(8676002)(76176011)(6512007)(81166006)(68736007)(65826007)(99936001)(26005)(81156014)(6506007)(386003)(102836004)(186003)(5660300001)(58126008)(110136005)(316002)(31686004)(64126003)(52116002)(2501003)(105586002)(85202003)(106356001)(99286004)(8936002)(36756003)(6436002)(71200400001)(71190400001)(53936002)(85182001)(6246003)(6116002)(305945005)(25786009)(14454004)(65806001)(65956001)(66066001)(3846002)(478600001)(256004)(14444005)(7736002)(6486002)(31696002)(229853002)(486006)(476003)(86362001)(446003)(11346002)(2616005)(66574012)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4125; H:VI1PR07MB5568.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 7fVjcMgAfeXuttCf9kXdOcBC9OXjZ7LD6VUvfhMMLgd28clM45dZQdOn1TdRZo2NAz4D7VrRGbW1dtfJ37FutIP4OCPrnx550Pl1dqyIGWDPuJnWZxn69lVcwBCe2tdQ/7hXViYcN282zmd5Rh8LXFESQiuIPS68E6SJbfyUxWROW4y7Eg/yvp9FQD1eTZOpvgNPBmKg0V/n3AtikfjxQSBgXYQqSefs/mhgjuWhDcTO74L0r2zX6/1qcroPBkRCRe10huFydLmP8N6o29LyPPhBayk4uGK+afrrt//NbAD4lZyT2VtLGenivihlwLdz
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090600080105030300040304"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c4bec7cc-b13f-4db8-3643-08d66504e710
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2018 16:21:45.2569 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4125
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSfyzUcRjH+3y/3/vh6tbHIY9rtXVTfyBF+ZEsKX9YW1urtUWoK98h3Om+ XMgMS36cxR8lzNLNTSs/SilqSg6F/KyGrq12EvMjK6JC6u4+avXf6/k8z/v9fp7tI6Qlb3hS YZQinlUp5DEyvogpPlav3lq60SFke3ueq7dGMyrwLutP5+2lAnW6H1Rg7UI5c4gKFvmGszFR ala1bc9JUWSRLoOJq/FO1GZ4paEcj1xkJQS8ExZ6PvJykUgowa0Ihp5N8Ukxj6B3rov6W8wY LglIoaPgoraJMesZXEDDVEMqaRRQ8GuxBZFiGMF8YTdlnuLjAMiabrKwLT4A5T0tFrbB+6Hr c5uAvAfA1eZHNGEfGLg/LiAJm+FV5ntLmhj7QU/TkGlGaApQw1Od0vxshf2htuM5z8wIr4Nv nVUWexrbg2GkjCKH2oKx/wWfsB2Mf1jmEZZB0YTBwnY4FK7kZNDm/QEXIshuqRMQ0zBofJe9 InaB7sERRHgDvCzTrPAAHy70BRM+CHlZVYgYGRDkPBlbSXOCpu/5yHwA4GgoeptSgNxK/tm1 xCShcQ6C5TE9VWK52Ro6ikcYMuQJ1+4ZacLOUKGdpP8Xm3k3FC008wlvgssao4CwB0y2fUGE d0BFzU/+dSS6hew4luNiI9zdXVlV1GmOUypcFWz8XWT6ZM11iz4NqHnMX4+wEMnWiJf5DiES nlzNJcXqkaPJZ/hOZR+SMgqlgpXZig0JECIRh8uTklmV8oQqIYbl9Gi9kJHZi5ck1iESHCGP Z6NZNo5V/elSQitpGpJOhK4+jI66bGl7yPgZcv3W+sfotWNxSiVOnC4MLIxsnFM7VmkGFUOa M9Wo1claSicz1e1W+ecqZ0/x9q16fdZz7nji3ONd6biO9+lGmE2vd0PpzNqUeiVqz8fnnbVB wV87HjTclDJLQamjSUY3gddE5pHS2dKkTt+u27I2hYzhIuVuTrSKk/8GDyfbpWwDAAA=
Archived-At: 
Subject: Re: [netmod] Any implementation of ietf-snmp.yang RFC 7407
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Dec 2018 16:21:53 -0000

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

On 2018. 12. 18. 17:10, Martin Bjorklund wrote:
> Bal=C3=A1zs Lengyel  wrote:
>> Hello,
>>
>> Does anyone know about implementations of the ietf-snmp YANG model?
>> As far as I could find none of the SW/vendors yumapro, tailf/confd,
>> snmp-research, adventnet, netsnmp, snmp4j, Cisco, Huawei, Nokia,
>> Juniper have implemented it.
> We shave an implementation that isn't exactly the model in the RFC,
> but close.  Did you ask b/c you have found some issue with the model?
>
>
> /martin

I asked, because I see so little uptake for the model, I am starting to=20
wonder, if this is a dead RFC no one cares about, or whether it just=20
takes time for people to implement it. Whether ONAP that requires this=20
RFC really wants this, or they just listed all finalized YANG models=20
sonetime earlier.

regards Balazs

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



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

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

--------------ms090600080105030300040304--


From nobody Tue Dec 18 09:24:50 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA68131164; Tue, 18 Dec 2018 09:24:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goDM6MOpin0c; Tue, 18 Dec 2018 09:24:33 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 47076130EB8; Tue, 18 Dec 2018 09:24:33 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id A9858182015F; Tue, 18 Dec 2018 18:32:44 +0100 (CET)
Received: from localhost (unknown [172.29.2.111]) by trail.lhotka.name (Postfix) with ESMTPSA id 6AAB21820053; Tue, 18 Dec 2018 18:32:41 +0100 (CET)
From: Ladislav Lhotka 
To: Jan Lindblad , =?utf-8?Q?Bal=C3=A1zs?= Lengyel 
Cc: "netconf\@ietf.org" , "netmod\@ietf.org" 
In-Reply-To: <90DB3C3B-FD52-4903-81B0-93985E6F74FE@tail-f.com>
References:  <20181217.091505.218628572185200621.mbj@tail-f.com> <83b139a1-a0ab-5fbc-f702-7f0d50a46864@ericsson.com> <90DB3C3B-FD52-4903-81B0-93985E6F74FE@tail-f.com>
Mail-Followup-To: Jan Lindblad , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netconf\@ietf.org" , "netmod\@ietf.org" 
Date: Tue, 18 Dec 2018 18:24:28 +0100
Message-ID: <8736quu4s3.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] [Netconf]   magic leaf 'type' in IETF interfaces
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Dec 2018 17:24:36 -0000

Jan Lindblad  writes:

> Hi,
>> While I agree with Martin, in our systems we have a number of places, where the system does create configuration in running, due to
>> 
>> different levels of automation and autonomous algorithms kick-in
>> the created config needs to be possible to be further modified by the operator
>> the created config needs to be referenced from operator created config
>> the created config is not always ephemeral, it might need to be part of backup/restore
> This is only a sampling from "the list of excuses". I have heard many more. The road to hell is paved with good intentions, however. If we want to build automation based on sound theory, clearly separating the orders from managers from a system's own operational view is key, IMO. Reliability, security, accountability are growing in importance, and they all play in this direction.
>
> We may not need to standardize rules to outlaw the above; the market
> will take care of that. What we need to ensure is that it is possible
> to be standards compliant without having to implement design excuses
> like these.

I agree. Now that we have NMDA, things like this shouldn't be necessary.

Lada

>
> Best Regards,
> /jan
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Tue Dec 18 10:15:01 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E552D131192 for ; Tue, 18 Dec 2018 10:14:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 YXb7BK0LsXEr for ; Tue, 18 Dec 2018 10:14:50 -0800 (PST)
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A23CA131197 for ; Tue, 18 Dec 2018 10:14:49 -0800 (PST)
Received: by mail-lj1-x233.google.com with SMTP id k15-v6so15038039ljc.8 for ; Tue, 18 Dec 2018 10:14:49 -0800 (PST)
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=qu5cjoPouQ9Yjc0F2YWLg9buenT433nBKSHe4MCisKM=; b=TxP8AeBfMbSYmrdSgDqK5mcBP/2tyCakdgTmLihWyiZ9mJ//H7CHXa9oCKHzu9U30k /kGOBYXqKZgCfPO3DyFmI7lTKDiFksmX/Cw4z+UrbkeBfs5e1VZ5F5ov5EblZ5C5N+kQ NY7JCvguHG7d0wCjerXYbLeOHsPMN0MtPDLyJiU5VcBPa8TxNja2ASRHTyX/bIhAkvtc vdNgzylNbKWdEDynEzbARkDNWCaE9grk8/KbNaMh16dvSfOBXAORdDaDanwMjWxKkZ+H ic4o4yl9OGtBv3++26YgGurnhlcFFCFV7JX5J30TRV16/YE8klWL/8Pmnt1CD4340Pfz KfQg==
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=qu5cjoPouQ9Yjc0F2YWLg9buenT433nBKSHe4MCisKM=; b=pncgP2YtksfF7QdeMF8FHrkB29mpiuqhqcxhACM5Gotz8A/g2sp+lCs9ONovMpGn5A 4FuPf6btD/lZ3jToz3JHOp/thlA2xBqj0KyRyp8tqy1ENxCExeE8I990Qhsq1pRyJUNJ nKPIoOmVEDzUrNNTM3YghVN7i9jhihFTuueJSUyrGVkwZTsLTwAIYtZICe0s0sSP/1Xl T5Ec/Oz7eV9g41aYVWJFvKSnuzgydcQngCbstso/FKKWVGwD4w8zXW7CuGndHzdClcpV Dt5JRJrIGjW/ED2MYafjzlugpeLXOVRe5KsmSlvRhc3dhAK8P6eOCwQfb6EaXBqWEQdy BAhQ==
X-Gm-Message-State: AA+aEWaBMG/n4CqCkUTEHbtlUqt11FZfP7ENY9BLo499Brdb9/eOIq9o a1RXGkIYHjLTnVyDVZAoDCPKULRAxynmLRPnI4iKUw==
X-Google-Smtp-Source: AFSGD/WasPhXkiOBIFVCPPcOjj+tashzGiJuAs8PP6pk6X7h3JL5Zux+iz7cT8T5TP25Xp+1S8sGLfWWahJjRJUh3c4=
X-Received: by 2002:a2e:e02:: with SMTP id 2-v6mr9266886ljo.10.1545156887654;  Tue, 18 Dec 2018 10:14:47 -0800 (PST)
MIME-Version: 1.0
References:  <20181217.091505.218628572185200621.mbj@tail-f.com> <83b139a1-a0ab-5fbc-f702-7f0d50a46864@ericsson.com> <90DB3C3B-FD52-4903-81B0-93985E6F74FE@tail-f.com>
In-Reply-To: <90DB3C3B-FD52-4903-81B0-93985E6F74FE@tail-f.com>
From: Andy Bierman 
Date: Tue, 18 Dec 2018 10:14:36 -0800
Message-ID: 
To: Jan Lindblad 
Cc: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= ,  "netconf@ietf.org" , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000694c19057d4fdf47"
Archived-At: 
Subject: Re: [netmod] [Netconf] magic leaf 'type' in IETF interfaces
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Dec 2018 18:14:53 -0000

--000000000000694c19057d4fdf47
Content-Type: text/plain; charset="UTF-8"

On Tue, Dec 18, 2018 at 5:37 AM Jan Lindblad  wrote:

> Hi,
>
> While I agree with Martin, in our systems we have a number of places,
> where the system does create configuration in running, due to
>
>    - different levels of automation and autonomous algorithms kick-in
>    - the created config needs to be possible to be further modified by
>    the operator
>    - the created config needs to be referenced from operator created
>    config
>    - the created config is not always ephemeral, it might need to be part
>    of backup/restore
>
> This is only a sampling from "the list of excuses". I have heard many
> more. The road to hell is paved with good intentions, however. If we want
> to build automation based on sound theory, clearly separating the orders
> from managers from a system's own operational view is key, IMO.
> Reliability, security, accountability are growing in importance, and they
> all play in this direction.
>
> We may not need to standardize rules to outlaw the above; the market will
> take care of that. What we need to ensure is that it is possible to be
> standards compliant without having to implement design excuses like these.
>
>
NMDA has a lot of room for proprietary mechanisms for converting 
to .
Many times the features desired by engineers exceed the capabilities of
YANG, such as
a dynamic default leaf.  YANG allows a simple constant, and no business
logic to pick the default.
This is a very valid use of "server auto-magic".

Maybe a future version of YANG can improve the client visibility into this
"auto-magic"


Best Regards,
> /jan
>

Andy


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

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




=

On Tue, Dec 18, 2018 at 5:37 AM Jan Lindblad <janl@tail-f.com> wrote=
:
Hi,
<=
div>
While I agre=
e with Martin, in our systems we have a number of
      places, where the system does create configuration in running, due
      to

    
    
      
  • different levels of automation and autonomous algorithms
        kick-in
    • 
      
  • the created config needs to be possible to be further modified
        by the operator
    • 
      
  • the created config needs to be referenced from operator
        created config
    • 
      
  • the created config is not always ephemeral, it might need to
        be part of backup/restore
Th=
is is only a sampling from "the list of excuses". I have heard ma=
ny more. The road to hell is paved with good intentions, however. If we wan=
t to build automation based on sound theory, clearly separating the orders =
from managers from a system's own operational view is key, IMO. Reliabi=
lity, security, accountability are growing in importance, and they all play=
 in this direction.

We may not need to standardize=
 rules to outlaw the above; the market will take care of that. What we need=
 to ensure is that it is possible to be standards compliant without having =
to implement design excuses like these.


NMDA has a lot of room for proprietary =
mechanisms for converting <running> to <intended>.
Ma=
ny times the features desired by engineers exceed the capabilities of YANG,=
 such as
a dynamic default leaf.=C2=A0 YANG allows a simple const=
ant, and no business logic to pick the default.
This is a very va=
lid use of "server auto-magic".

Maybe a =
future version of YANG can improve the client visibility into this "au=
to-magic"


Best Regards,
=

/jan

Andy
=C2=A0

__________________________________=
_____________

netmod mailing list

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




--000000000000694c19057d4fdf47--


From nobody Tue Dec 18 19:35:48 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435EC130DC8 for ; Tue, 18 Dec 2018 19:35:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0rJUEMqS6R2 for ; Tue, 18 Dec 2018 19:35:44 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B1E12F1A5 for ; Tue, 18 Dec 2018 19:35:44 -0800 (PST)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id BD6B091F09361 for ; Wed, 19 Dec 2018 03:35:39 +0000 (GMT)
Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 19 Dec 2018 03:35:40 +0000
Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.165]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0415.000; Wed, 19 Dec 2018 11:35:28 +0800
From: Rohit R Ranade 
To: Kent Watsen , Andy Bierman , Lou Berger 
CC: Ignas Bagdonas , Warren Kumari , NetMod WG , RFC Errata System 
Thread-Topic: [netmod] [Technical Errata Reported] RFC8342 (5514)
Thread-Index: AQHUXJCS1czPI27EsEa0hT7/Fs4rk6UP6SeAgAAhjoCAACVcAIAAHT4AgAALWACAAntMgIAAqF6AgAAFW4CAARrTgIAAMTiAgAAVWYCAAB6NAIAAFGUAgAAKs4CAcL23cA==
Date: Wed, 19 Dec 2018 03:35:27 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCB29CA@dggeml530-mbs.china.huawei.com>
References: <20181005101427.bw7qo7ertxk2dj5d@anna.jacobs.jacobs-university.de> <1b34ccac-831f-505d-d40b-c21234efc475@labn.net> <20181005142816.avs2es2ymvc7qxwx@anna.jacobs.jacobs-university.de> <2e2f0188-770c-5fad-6a9d-a0be3abd1fce@labn.net>  <20181007064721.i4gfbmhrldvmtgbz@anna.jacobs.jacobs-university.de>  <20181007170907.23ussvtcds7ftnab@anna.jacobs.jacobs-university.de> <973c0b2d-cc42-fdc6-d405-dd7e561a37a3@cisco.com> <0073d57d-217d-3fff-54c3-7f0cf062c0cc@labn.net> <20181008141357.pme6q4aw2v66yi4m@anna.jacobs.jacobs-university.de> <75052af6-665d-f248-7082-c9a0f4f4ab3d@labn.net>  <8385F653-C23A-4101-BE30-11670D4DD4FA@juniper.net>
In-Reply-To: <8385F653-C23A-4101-BE30-11670D4DD4FA@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BCB29CAdggeml530mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC8342 (5514)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Dec 2018 03:35:47 -0000

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

SGkgQWxsLA0KDQpTbyB0aGUgY29uY2x1c2lvbiBoZXJlIGlzIHRvIHJhaXNlIGFuIEVycmF0YSBv
biBSRkMgNzk1MCA/IENhbiBvdGhlcnMgcGxlYXNlIHByb3ZpZGUgeW91ciB0aG91Z2h0cy4NCg0K
V2l0aCBSZWdhcmRzLA0KUm9oaXQNCg0KRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5j
ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLZW50IFdhdHNlbg0KU2VudDogMDggT2N0b2JlciAy
MDE4IDIzOjI1DQpUbzogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+OyBMb3UgQmVy
Z2VyIDxsYmVyZ2VyQGxhYm4ubmV0Pg0KQ2M6IElnbmFzIEJhZ2RvbmFzIDxpYmFnZG9uYUBnbWFp
bC5jb20+OyBXYXJyZW4gS3VtYXJpIDx3YXJyZW5Aa3VtYXJpLm5ldD47IE5ldE1vZCBXRyA8bmV0
bW9kQGlldGYub3JnPjsgUkZDIEVycmF0YSBTeXN0ZW0gPHJmYy1lZGl0b3JAcmZjLWVkaXRvci5v
cmc+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJG
QzgzNDIgKDU1MTQpDQoNCg0KPiBBZnRlciByZWFkaW5nIHRoZSBSRkMgZGV0YWlscywgaXQgc2Vl
bXMgdGhhdCB0aGUgZXhhbXBsZSBpcyBpbnRlbnRpb25hbCBiYXNlZCBvbg0KPiB0aGUgdGV4dCBh
Ym91dCBOUC1jb250YWluZXJzLg0KPg0KPiBJIHRoaW5rIGFuIGVycmF0YSBjb3VsZCBiZSB1c2Vk
IGJlY2F1c2UgdGhlIHNlbnRlbmNlIGFib3V0IGEgdG9wLWxldmVsIG9yaWdpbiBtdXN0IGJlIGRl
ZmluZWQNCj4gY291bGQgYmUgaW50ZXJwcmV0ZWQgdG8gZGVmaW5lICJ0b3AtbGV2ZWwiIGFzIHRo
ZSB0b3Btb3N0IGxldmVsIGZvciB3aGljaCB0aGUgb3JpZ2luIHByb3BlcnR5DQo+IGlzIGFwcGxp
Y2FibGUuICBJdCBhcHBlYXJzIHRoZSBpbnRlbnQgd2FzIHRvIGV4Y2x1ZGUgTlAtY29udGFpbmVy
cyBmcm9tIHRoaXMgcmVxdWlyZW1lbnQuDQoNClllcywgaXQgd2FzIGludGVudGlvbmFsIHRvIGV4
Y2x1ZGUgbnAtY29udGFpbmVycywgSSB2aWV3IHNvbWV0aGluZyBsaWtlOg0KDQpPTEQ6DQogICAg
VGhlIG9yaWdpbiBmb3IgYW55IHRvcC1sZXZlbCBjb25maWd1cmF0aW9uIGRhdGEgbm9kZXMgbXVz
dCBiZSBzcGVjaWZpZWQuDQpORVc6DQogICAgVGhlIG9yaWdpbiBmb3IgYW55IHRvcC1sZXZlbCBj
b25maWd1cmF0aW9uIGRhdGEgbm9kZXMsIGV4Y2VwdA0KICAgIG5vbi1wcmVzZW5jZSBjb250YWlu
ZXJzLCBtdXN0IGJlIHNwZWNpZmllZC4NCg0KdG8gYmUgYWxtb3N0IGVkaXRvcmlhbCBpbiBuYXR1
cmUuICBUaGF0IHNhaWQsIEkgYWxzbyBkbyBub3QgdGhpbmsgdGhhdCBpdOKAmXMgbmVlZGVkLCBp
biB0aGF0IEkgdGhpbmsNCm9uZSBjb3VsZCBhcmd1ZSB0aGF0IGFuIG5wLWNvbnRhaW5lciBpc27i
gJl0IGFjdHVhbGx5IOKAnGNvbmZpZ3VyYXRpb27igJ0gYXQgYWxsLCBpdOKAmXMganVzdCBpbXBs
aWNpdGx5DQp0aGVyZSBwcm92aWRpbmcgYSBza2VsZXRvbiB0byBoYW5nIHN0dWZmIG9mZiBvZi4N
Cg0KUkZDIDgzNDIgc2F5czoNCg0KICAgbyAgY29uZmlndXJhdGlvbjogRGF0YSB0aGF0IGlzIHJl
cXVpcmVkIHRvIGdldCBhIGRldmljZSBmcm9tIGl0cw0KICAgICAgaW5pdGlhbCBkZWZhdWx0IHN0
YXRlIGludG8gYSBkZXNpcmVkIG9wZXJhdGlvbmFsIHN0YXRlLg0KDQpBbiBucC1jb250YWluZXIg
ZG9lc27igJl0IGFjdHVhbGx5IGRvIHRoaXMuICAgUkZDIDc5NTAgc2F5czoNCg0KICAgbyAgbm9u
LXByZXNlbmNlIGNvbnRhaW5lcjogQSBjb250YWluZXIgdGhhdCBoYXMgbm8gbWVhbmluZyBvZiBp
dHMNCiAgICAgIG93biwgZXhpc3Rpbmcgb25seSB0byBjb250YWluIGNoaWxkIG5vZGVzLg0KDQpC
aW5nby4gIFJGQyA3OTUwIGFsc28gc2F5czoNCg0KICAgbyAgZGF0YSBub2RlOiBBIG5vZGUgaW4g
dGhlIHNjaGVtYSB0cmVlIHRoYXQgY2FuIGJlIGluc3RhbnRpYXRlZCBpbiBhDQogICAgICAgZGF0
YSB0cmVlLiAgT25lIG9mIGNvbnRhaW5lciwgbGVhZiwgbGVhZi1saXN0LCBsaXN0LCAgYW55ZGF0
YSwgYW5kIGFueXhtbC4NCg0KTm90ZSB0aGF0IGl0IHNheXMg4oCcY29udGFpbmVy4oCdIHdpdGhv
dXQgY2xhcmlmaWNhdGlvbi4gIENsZWFybHkgYW4gbnAtY29udGFpbmVyIGlzbuKAmXQg4oCcZGF0
YeKAnQ0Kc28sIGlmIHRoZXJlIGlzIHRvIGJlIGFuIGVycmF0YSwgcGVyaGFwcyBpdCBzaG91bGQg
YmUgYWdhaW5zdCAgUkZDIDc5NTAsIGZvciBpbnN0YW5jZToNCg0KTkVXDQogICBvICBkYXRhIG5v
ZGU6IEEgbm9kZSBpbiB0aGUgc2NoZW1hIHRyZWUgdGhhdCBjYW4gYmUgaW5zdGFudGlhdGVkIGlu
IGENCiAgICAgICBkYXRhIHRyZWUuICBPbmUgb2YgcHJlc2VuY2UgY29udGFpbmVyLCBsZWFmLCBs
ZWFmLWxpc3QsIGxpc3QsICBhbnlkYXRhLCBhbmQgYW55eG1sLg0KDQoNCktlbnQgLy8gY29udHJp
YnV0b3INCg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy
bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl
LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l
O30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQ
YXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1h
cmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwg
ZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4t
dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl
LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJZm9u
dC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJdGV4dC10
cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lOw0KCXZlcnRpY2FsLWFs
aWduOmJhc2VsaW5lO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1u
YW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5
bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp
ZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4
cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp
ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh
dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8
Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkhpIEFsbCw8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPlNvIHRoZSBjb25jbHVzaW9uIGhlcmUgaXMg
dG8gcmFpc2UgYW4gRXJyYXRhIG9uIFJGQyA3OTUwID8gQ2FuIG90aGVycyBwbGVhc2UgcHJvdmlk
ZSB5b3VyIHRob3VnaHRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+
V2l0aCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdE
Ij5Sb2hpdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7
Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFu
PjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGll
dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5LZW50IFdhdHNlbjxicj4NCjxiPlNlbnQ6PC9i
PiAwOCBPY3RvYmVyIDIwMTggMjM6MjU8YnI+DQo8Yj5Ubzo8L2I+IEFuZHkgQmllcm1hbiAmbHQ7
YW5keUB5dW1hd29ya3MuY29tJmd0OzsgTG91IEJlcmdlciAmbHQ7bGJlcmdlckBsYWJuLm5ldCZn
dDs8YnI+DQo8Yj5DYzo8L2I+IElnbmFzIEJhZ2RvbmFzICZsdDtpYmFnZG9uYUBnbWFpbC5jb20m
Z3Q7OyBXYXJyZW4gS3VtYXJpICZsdDt3YXJyZW5Aa3VtYXJpLm5ldCZndDs7IE5ldE1vZCBXRyAm
bHQ7bmV0bW9kQGlldGYub3JnJmd0OzsgUkZDIEVycmF0YSBTeXN0ZW0gJmx0O3JmYy1lZGl0b3JA
cmZjLWVkaXRvci5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBbVGVj
aG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDODM0MiAoNTUxNCk8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7IEFmdGVyIHJlYWRpbmcgdGhlIFJGQyBkZXRhaWxz
LCBpdCBzZWVtcyB0aGF0IHRoZSBleGFtcGxlIGlzIGludGVudGlvbmFsIGJhc2VkIG9uPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi
IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7IHRoZSB0ZXh0IGFib3V0IE5QLWNvbnRhaW5l
cnMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZndDs8bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZndDsgSSB0aGluayBhbiBlcnJhdGEgY291bGQgYmUgdXNl
ZCBiZWNhdXNlIHRoZSBzZW50ZW5jZSBhYm91dCBhIHRvcC1sZXZlbCBvcmlnaW4gbXVzdCBiZSBk
ZWZpbmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7IGNvdWxkIGJlIGludGVy
cHJldGVkIHRvIGRlZmluZSAmcXVvdDt0b3AtbGV2ZWwmcXVvdDsgYXMgdGhlIHRvcG1vc3QgbGV2
ZWwgZm9yIHdoaWNoIHRoZSBvcmlnaW4gcHJvcGVydHk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQiPiZndDsgaXMgYXBwbGljYWJsZS4mbmJzcDsgSXQgYXBwZWFycyB0aGUgaW50ZW50IHdh
cyB0byBleGNsdWRlIE5QLWNvbnRhaW5lcnMgZnJvbSB0aGlzIHJlcXVpcmVtZW50LjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz
dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIu
MHB0Ij5ZZXMsIGl0IHdhcyBpbnRlbnRpb25hbCB0byBleGNsdWRlIG5wLWNvbnRhaW5lcnMsIEkg
dmlldyBzb21ldGhpbmcgbGlrZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+T0xEOjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBvcmlnaW4gZm9yIGFueSB0b3AtbGV2
ZWwgY29uZmlndXJhdGlvbiBkYXRhIG5vZGVzIG11c3QgYmUgc3BlY2lmaWVkLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls
ZT0iZm9udC1zaXplOjEyLjBwdCI+TkVXOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBvcmlnaW4gZm9yIGFueSB0b3AtbGV2ZWwgY29uZmlndXJh
dGlvbiBkYXRhIG5vZGVzLCBleGNlcHQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bm9uLXByZXNlbmNlIGNvbnRhaW5lcnMsIG11c3QgYmUg
c3BlY2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0Ij50byBiZSBhbG1vc3QgZWRpdG9yaWFsIGluIG5hdHVyZS4m
bmJzcDsgVGhhdCBzYWlkLCBJIGFsc28gZG8gbm90IHRoaW5rIHRoYXQgaXTigJlzIG5lZWRlZCwg
aW4gdGhhdCBJIHRoaW5rPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5vbmUgY291bGQg
YXJndWUgdGhhdCBhbiBucC1jb250YWluZXIgaXNu4oCZdCBhY3R1YWxseSDigJxjb25maWd1cmF0
aW9u4oCdIGF0IGFsbCwgaXTigJlzIGp1c3QgaW1wbGljaXRseQ0KPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250
LXNpemU6MTIuMHB0Ij50aGVyZSBwcm92aWRpbmcgYSBza2VsZXRvbiB0byBoYW5nIHN0dWZmIG9m
ZiBvZi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdCI+UkZDIDgzNDIgc2F5czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
Mi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7
IG8mbmJzcDsgY29uZmlndXJhdGlvbjogRGF0YSB0aGF0IGlzIHJlcXVpcmVkIHRvIGdldCBhIGRl
dmljZSBmcm9tIGl0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluaXRpYWwgZGVmYXVsdCBzdGF0ZSBpbnRvIGEgZGVzaXJlZCBv
cGVyYXRpb25hbCBzdGF0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW4gbnAtY29udGFpbmVyIGRvZXNu4oCZdCBh
Y3R1YWxseSBkbyB0aGlzLiZuYnNwOyZuYnNwOyBSRkMgNzk1MCBzYXlzOjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4m
bmJzcDsmbmJzcDsgbyZuYnNwOyBub24tcHJlc2VuY2UgY29udGFpbmVyOiBBIGNvbnRhaW5lciB0
aGF0IGhhcyBubyBtZWFuaW5nIG9mIGl0czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG93biwgZXhpc3Rpbmcgb25seSB0byBjb250
YWluIGNoaWxkIG5vZGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5CaW5nby4mbmJzcDsgUkZDIDc5NTAgYWxzbyBz
YXlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyBkYXRhIG5vZGU6IEEgbm9kZSBp
biB0aGUgc2NoZW1hIHRyZWUgdGhhdCBjYW4gYmUgaW5zdGFudGlhdGVkIGluIGE8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBkYXRhIHRyZWUuJm5ic3A7IE9uZSBvZiBjb250YWluZXIsIGxlYWYsIGxlYWYtbGlzdCwgbGlz
dCwmbmJzcDsgYW55ZGF0YSwgYW5kIGFueXhtbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w
cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Tm90ZSB0aGF0IGl0IHNh
eXMg4oCcY29udGFpbmVy4oCdIHdpdGhvdXQgY2xhcmlmaWNhdGlvbi4mbmJzcDsgQ2xlYXJseSBh
biBucC1jb250YWluZXIgaXNu4oCZdCDigJxkYXRh4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6
MTIuMHB0Ij5zbywgaWYgdGhlcmUgaXMgdG8gYmUgYW4gZXJyYXRhLCBwZXJoYXBzIGl0IHNob3Vs
ZCBiZSBhZ2FpbnN0ICZuYnNwO1JGQyA3OTUwLCBmb3IgaW5zdGFuY2U6PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm
b250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk5F
VzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgZGF0
YSBub2RlOiBBIG5vZGUgaW4gdGhlIHNjaGVtYSB0cmVlIHRoYXQgY2FuIGJlIGluc3RhbnRpYXRl
ZCBpbiBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgZGF0YSB0cmVlLiZuYnNwOyBPbmUgb2YgcHJlc2VuY2UgY29udGFp
bmVyLCBsZWFmLCBsZWFmLWxpc3QsIGxpc3QsJm5ic3A7IGFueWRhdGEsIGFuZCBhbnl4bWwuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6
ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+S2VudCAvLyBj
b250cmlidXRvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_991B70D8B4112A4699D5C00DDBBF878A6BCB29CAdggeml530mbschi_--


From nobody Tue Dec 18 19:39:21 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7864412D84D for ; Tue, 18 Dec 2018 19:39:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwXPjTWimR_j for ; Tue, 18 Dec 2018 19:39:16 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B69C412F1A5 for ; Tue, 18 Dec 2018 19:39:16 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A150E70F85CA1; Wed, 19 Dec 2018 03:39:12 +0000 (GMT)
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 19 Dec 2018 03:39:13 +0000
Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.165]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0415.000; Wed, 19 Dec 2018 11:39:04 +0800
From: Rohit R Ranade 
To: Ladislav Lhotka , "netmod@ietf.org" 
Thread-Topic: [netmod] [Technical Errata Reported] RFC7950 (5517)
Thread-Index: AQHUXtZhCjTCNqKdvUCHfibTe3Ea6KUUuBKAgAAG7QCAcRutYA==
Date: Wed, 19 Dec 2018 03:39:03 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCB29E4@dggeml530-mbs.china.huawei.com>
References: <20181008071250.C97CCB8155F@rfc-editor.org> <20181008.135621.2235985294350825585.mbj@tail-f.com> <9f95bb8a9a0a4689dd306fed0442097f719d2d88.camel@nic.cz>
In-Reply-To: <9f95bb8a9a0a4689dd306fed0442097f719d2d88.camel@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5517)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Dec 2018 03:39:19 -0000

Hi All,

Is this errata (with the new text given by Martin) considered accepted by t=
he authors and WG ?

With Regards,
Rohit

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav Lhotka
Sent: 08 October 2018 17:51
To: netmod@ietf.org
Subject: Re: [netmod] [Technical Errata Reported] RFC7950 (5517)

On Mon, 2018-10-08 at 13:56 +0200, Martin Bjorklund wrote:
> Hi,
>=20
> I agree that the text needs clarification.  However, I propose this=20
> text instead:
>=20
>   The derived-from-or-self() function returns "true" if any node in the
>   argument "nodes" is a node of type "identityref" or a type derived
>   from "identityref", and its value is an identity that is equal to or
>   derived from (see Section 7.18.2) the identity "identity";=20
>   otherwise, it returns "false".
>=20

This formulation is better.

It is somewhat confusing that "derived from" has two unrelated meanings in =
the same sentence.

Lada

>=20
> /martin
>=20
>=20
> RFC Errata System  wrote:
> > The following errata report has been submitted for RFC7950, "The=20
> > YANG 1.1 Data Modeling Language".
> >=20
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata/eid5517
> >=20
> > --------------------------------------
> > Type: Technical
> > Reported by: Rohit R Ranade 
> >=20
> > Section: 10.4.2
> >=20
> > Original Text
> > -------------
> > The derived-from-or-self() function returns "true" if any node in the
> >    argument "nodes" is a node of type "identityref" and its value is an
> >    identity that is equal to or derived from (see Section 7.18.2) the
> >    identity "identity"; otherwise, it returns "false".
> >=20
> >=20
> > Corrected Text
> > --------------
> > The derived-from-or-self() function returns "true" if any node in=20
> > the  argument "nodes" is a node of type equal to or derived  from=20
> > "identityref" and its value is an identity that is equal to or =20
> > derived from (see Section 7.18.2) the identity "identity"; =20
> > otherwise, it returns "false".
> >=20
> >=20
> > Notes
> > -----
> > The node-set can have node which are of types that may be derived=20
> > from an identityref. Typical example is in ietf-netconf-nmda, where=20
> > "when 'derived- from-or-self(datastore, "ds:operational")';" is used, b=
ut the "datastore"
> > node is of type "datastore-ref" defined in ietf-datastores module,=20
> > which is in-turn derived from "identityref"
> >=20
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please=20
> > use "Reply All" to discuss whether it should be verified or=20
> > rejected. When a decision is reached, the verifying party can log in=20
> > to change the status and edit the report, if necessary.
> >=20
> > --------------------------------------
> > RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> > --------------------------------------
> > Title               : The YANG 1.1 Data Modeling Language
> > Publication Date    : August 2016
> > Author(s)           : M. Bjorklund, Ed.
> > Category            : PROPOSED STANDARD
> > Source              : Network Modeling
> > Area                : Operations and Management
> > Stream              : IETF
> > Verifying Party     : IESG
> >=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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


From nobody Wed Dec 19 01:30:54 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BDE130DEF; Wed, 19 Dec 2018 01:30:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1b14W7fzPFF; Wed, 19 Dec 2018 01:30:50 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB69130DC8; Wed, 19 Dec 2018 01:30:50 -0800 (PST)
Received: from [10.147.40.143] (unknown [173.38.220.39]) by mail.tail-f.com (Postfix) with ESMTPSA id CE4911AE0446; Wed, 19 Dec 2018 10:30:47 +0100 (CET)
From: Jan Lindblad 
Message-Id: <6912DD4C-4C4E-45E8-9F0E-D8D8139F83AE@tail-f.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0AFC8023-444A-4AA3-AF3F-93CB26C61F8A"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 19 Dec 2018 10:30:46 +0100
In-Reply-To: 
Cc: =?utf-8?Q?Bal=C3=A1zs_Lengyel?= , "netconf@ietf.org" , "netmod@ietf.org" 
To: Andy Bierman 
References:  <20181217.091505.218628572185200621.mbj@tail-f.com> <83b139a1-a0ab-5fbc-f702-7f0d50a46864@ericsson.com> <90DB3C3B-FD52-4903-81B0-93985E6F74FE@tail-f.com> 
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: 
Subject: Re: [netmod] [Netconf] magic leaf 'type' in IETF interfaces
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 19 Dec 2018 09:30:52 -0000

--Apple-Mail=_0AFC8023-444A-4AA3-AF3F-93CB26C61F8A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi,
>> While I agree with Martin, in our systems we have a number of places, =
where the system does create configuration in running, due to
>>=20
>> different levels of automation and autonomous algorithms kick-in
>> the created config needs to be possible to be further modified by the =
operator
>> the created config needs to be referenced from operator created =
config
>> the created config is not always ephemeral, it might need to be part =
of backup/restore
> This is only a sampling from "the list of excuses". I have heard many =
more. The road to hell is paved with good intentions, however. If we =
want to build automation based on sound theory, clearly separating the =
orders from managers from a system's own operational view is key, IMO. =
Reliability, security, accountability are growing in importance, and =
they all play in this direction.
>=20
> We may not need to standardize rules to outlaw the above; the market =
will take care of that. What we need to ensure is that it is possible to =
be standards compliant without having to implement design excuses like =
these.
>=20
>=20
> NMDA has a lot of room for proprietary mechanisms for converting =
 to .
> Many times the features desired by engineers exceed the capabilities =
of YANG, such as
> a dynamic default leaf.  YANG allows a simple constant, and no =
business logic to pick the default.
> This is a very valid use of "server auto-magic".
>=20
> Maybe a future version of YANG can improve the client visibility into =
this "auto-magic"

As you say, this is not uncommon. I usually recommend to leave out any =
default statement, and write in the description what happens if this =
leaf isn't set. The operator can then override the default by giving a =
value.=20

While some more advanced features for default values may be of some =
utility, the simplicity of YANG is also important. We don't want to make =
the YANG models -- the interface contracts -- the new place for all =
business logic.

/jan


--Apple-Mail=_0AFC8023-444A-4AA3-AF3F-93CB26C61F8A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi,
While I agree with Martin, in our systems we have a number of =
places, where the system does create configuration in running, due =
to
  • different levels of automation and =
autonomous algorithms kick-in
  • the created config =
needs to be possible to be further modified by the operator
  • the created config needs to be referenced from operator =
created config
  • the created config is not always =
ephemeral, it might need to be part of =
backup/restore
This is =
only a sampling from "the list of excuses". I have heard many more. The =
road to hell is paved with good intentions, however. If we want to build =
automation based on sound theory, clearly separating the orders from =
managers from a system's own operational view is key, IMO. Reliability, =
security, accountability are growing in importance, and they all play in =
this direction.

We may not need to standardize rules to outlaw the above; the =
market will take care of that. What we need to ensure is that it is =
possible to be standards compliant without having to implement design =
excuses like these.


NMDA has a lot of room for proprietary =
mechanisms for converting <running> to <intended>.
Many times the features desired by engineers exceed the =
capabilities of YANG, such as
a dynamic default =
leaf.  YANG allows a simple constant, and no business logic to pick =
the default.
This is a very valid use of "server =
auto-magic".

Maybe a future version of YANG can improve the client =
visibility into this "auto-magic"

As you say, this is not uncommon. I usually =
recommend to leave out any default statement, and write in the =
description what happens if this leaf isn't set. The operator can then =
override the default by giving a value. 

While some more advanced features for default =
values may be of some utility, the simplicity of YANG is also important. =
We don't want to make the YANG models -- the interface contracts -- the =
new place for all business logic.

/jan

=

--Apple-Mail=_0AFC8023-444A-4AA3-AF3F-93CB26C61F8A--


From nobody Wed Dec 19 03:58:56 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8DC130DFD for ; Wed, 19 Dec 2018 03:58:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-4odM-ewYA1 for ; Wed, 19 Dec 2018 03:58:51 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AFCD128BCC for ; Wed, 19 Dec 2018 03:58:51 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 5F14060527 for ; Wed, 19 Dec 2018 12:58:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1545220729; bh=ahEtZf683MkFbD0kI3qYKk9lShx2zcTReHkoai4Rirk=; h=From:To:Date; b=CKdr7JU78Hasiz3EDiVvjDAZnPHwgqhfxNO/Pnvr0cKif3JfNtwfxHgZlKF7LAhM4 ZR0EbRM+tQD5jd+YKA2GAebACVpn4KUQvGphJgwDbQHJJk60iNM139szA3s8CHKu+a lIKmWzf983gVr56M/E8IvcN6fpxhtOeamGiVXBWk=
Message-ID: <0e6b0f62bbea33615a77d909dfde7098372f889b.camel@nic.cz>
From: Ladislav Lhotka 
To: NETMOD WG 
Date: Wed, 19 Dec 2018 12:58:48 +0100
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.3 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: [netmod] bit positions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 19 Dec 2018 11:58:54 -0000

Hi,

I ran into a problem when trying to translate IANA registry "DNSKEY Flags" [1]
into a YANG "bits" type. Each bit is the registry has an assigned number (0-15), 
so it seems natural to specify this number as the position of each bit in YANG.

However, it turns out that each bit contributes to the numeric value of the
entire bit field with a value of 2^(15-n) where n is the bit number. For
example, if bits ZONE (number 7) and SEP (15) are set, then the value of the
flags field, which also appears in the DNSKEY resource record, is

  257 = 2^8 + 2^0

My question is: Although it is not specified in RFC 7950, was the intention that
bit of position n contributes with 2^n?

Thanks, Lada

[1] https://www.iana.org/assignments/dnskey-flags/dnskey-flags.xhtml

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


From nobody Wed Dec 19 04:16:25 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA96B130DFD for ; Wed, 19 Dec 2018 04:16:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGH2Q7YPp4uk for ; Wed, 19 Dec 2018 04:16:20 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2AB130DFC for ; Wed, 19 Dec 2018 04:16:20 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 834D9FEE; Wed, 19 Dec 2018 13:16:18 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id I5yTFxQeJM_F; Wed, 19 Dec 2018 13:16:18 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 19 Dec 2018 13:16:18 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6DF2820044; Wed, 19 Dec 2018 13:16:18 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id U5wCcDB2c1JA; Wed, 19 Dec 2018 13:16:18 +0100 (CET)
Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 24BC720043; Wed, 19 Dec 2018 13:16:18 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Wed, 19 Dec 2018 13:16:17 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 62DD4300503F4F; Wed, 19 Dec 2018 13:16:17 +0100 (CET)
Date: Wed, 19 Dec 2018 13:16:17 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
CC: NETMOD WG 
Message-ID: <20181219121617.7galbbhjy4bgqyo4@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Ladislav Lhotka , NETMOD WG 
References: <0e6b0f62bbea33615a77d909dfde7098372f889b.camel@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <0e6b0f62bbea33615a77d909dfde7098372f889b.camel@nic.cz>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB01.jacobs.jacobs-university.de (10.70.0.120) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] bit positions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 19 Dec 2018 12:16:24 -0000

Lada,

RFC 7950 says:

   The "position" statement, which is optional, takes as an argument a
   non-negative integer value that specifies the bit's position within a
   hypothetical bit field.  The position value MUST be in the range 0 to
   4294967295, and it MUST be unique within the bits type.

Neither the XML nor the JSON encoding rulse uses the position
property.  I believe the interpretation of the position field is going
to be protocol specific. DNS may do things in its own way, a CBOR
encoding of bits may do a different thing.

/js

On Wed, Dec 19, 2018 at 12:58:48PM +0100, Ladislav Lhotka wrote:
> Hi,
> 
> I ran into a problem when trying to translate IANA registry "DNSKEY Flags" [1]
> into a YANG "bits" type. Each bit is the registry has an assigned number (0-15), 
> so it seems natural to specify this number as the position of each bit in YANG.
> 
> However, it turns out that each bit contributes to the numeric value of the
> entire bit field with a value of 2^(15-n) where n is the bit number. For
> example, if bits ZONE (number 7) and SEP (15) are set, then the value of the
> flags field, which also appears in the DNSKEY resource record, is
> 
>   257 = 2^8 + 2^0
> 
> My question is: Although it is not specified in RFC 7950, was the intention that
> bit of position n contributes with 2^n?
> 
> Thanks, Lada
> 
> [1] https://www.iana.org/assignments/dnskey-flags/dnskey-flags.xhtml
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Dec 19 04:35:10 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C04F130DFA for ; Wed, 19 Dec 2018 04:35:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lo92SZXfouNI for ; Wed, 19 Dec 2018 04:35:05 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0174612D4ED for ; Wed, 19 Dec 2018 04:35:04 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 546B160831; Wed, 19 Dec 2018 13:35:02 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1545222902; bh=sfwo0qXSRvaGCpNLX1ACrOIbU91qnT/yRJ36EHYFRqk=; h=From:To:Date; b=p1M1S0Q09ow9v5kRk870ZCWo0S0EGgCHX+UWG4YtrL/A3ta7ULZB8gO/HJP6H9kzl FQP0iBJ6tuuShy8lnCllUtP2gaqOiv1ZYj0MIuYnjzteemei8Kn5vn+JYwnBxwnZ7s yPNxMgGX2exSRpI1fy2We/ozVgMj2Ru23s/2ZIMg=
Message-ID: 
From: Ladislav Lhotka 
To: Juergen Schoenwaelder 
Cc: NETMOD WG 
Date: Wed, 19 Dec 2018 13:35:02 +0100
In-Reply-To: <20181219121617.7galbbhjy4bgqyo4@anna.jacobs.jacobs-university.de>
References: <0e6b0f62bbea33615a77d909dfde7098372f889b.camel@nic.cz> <20181219121617.7galbbhjy4bgqyo4@anna.jacobs.jacobs-university.de>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.3 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] bit positions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 19 Dec 2018 12:35:08 -0000

On Wed, 2018-12-19 at 13:16 +0100, Juergen Schoenwaelder wrote:
> Lada,
> 
> RFC 7950 says:
> 
>    The "position" statement, which is optional, takes as an argument a
>    non-negative integer value that specifies the bit's position within a
>    hypothetical bit field.  The position value MUST be in the range 0 to
>    4294967295, and it MUST be unique within the bits type.
> 
> Neither the XML nor the JSON encoding rulse uses the position
> property.  I believe the interpretation of the position field is going
> to be protocol specific. DNS may do things in its own way, a CBOR
> encoding of bits may do a different thing.

So do you suggest to keep the position equal to the number in the IANA registry?

Lada

> 
> /js
> 
> On Wed, Dec 19, 2018 at 12:58:48PM +0100, Ladislav Lhotka wrote:
> > Hi,
> > 
> > I ran into a problem when trying to translate IANA registry "DNSKEY Flags"
> > [1]
> > into a YANG "bits" type. Each bit is the registry has an assigned number (0-
> > 15), 
> > so it seems natural to specify this number as the position of each bit in
> > YANG.
> > 
> > However, it turns out that each bit contributes to the numeric value of the
> > entire bit field with a value of 2^(15-n) where n is the bit number. For
> > example, if bits ZONE (number 7) and SEP (15) are set, then the value of the
> > flags field, which also appears in the DNSKEY resource record, is
> > 
> >   257 = 2^8 + 2^0
> > 
> > My question is: Although it is not specified in RFC 7950, was the intention
> > that
> > bit of position n contributes with 2^n?
> > 
> > Thanks, Lada
> > 
> > [1] https://www.iana.org/assignments/dnskey-flags/dnskey-flags.xhtml
> > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Dec 19 04:42:53 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AACE130934 for ; Wed, 19 Dec 2018 04:42:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVVTlqyvMTF5 for ; Wed, 19 Dec 2018 04:42:50 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6929812D4ED for ; Wed, 19 Dec 2018 04:42:50 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id F112BFD9; Wed, 19 Dec 2018 13:42:48 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id ipLSZOVXek0x; Wed, 19 Dec 2018 13:42:48 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 19 Dec 2018 13:42:48 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B2EA520045; Wed, 19 Dec 2018 13:42:48 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kyM3n9HHBQ5k; Wed, 19 Dec 2018 13:42:48 +0100 (CET)
Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 7846C20044; Wed, 19 Dec 2018 13:42:48 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Wed, 19 Dec 2018 13:42:47 +0100
Received: by anna.localdomain (Postfix, from userid 501) id A7B483005040F7; Wed, 19 Dec 2018 13:42:47 +0100 (CET)
Date: Wed, 19 Dec 2018 13:42:46 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
CC: NETMOD WG 
Message-ID: <20181219124246.lvkiwofmq6wk4p5o@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Ladislav Lhotka , NETMOD WG 
References: <0e6b0f62bbea33615a77d909dfde7098372f889b.camel@nic.cz> <20181219121617.7galbbhjy4bgqyo4@anna.jacobs.jacobs-university.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB01.jacobs.jacobs-university.de (10.70.0.120) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] bit positions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 19 Dec 2018 12:42:52 -0000

On Wed, Dec 19, 2018 at 01:35:02PM +0100, Ladislav Lhotka wrote:
> On Wed, 2018-12-19 at 13:16 +0100, Juergen Schoenwaelder wrote:
> > Lada,
> > 
> > RFC 7950 says:
> > 
> >    The "position" statement, which is optional, takes as an argument a
> >    non-negative integer value that specifies the bit's position within a
> >    hypothetical bit field.  The position value MUST be in the range 0 to
> >    4294967295, and it MUST be unique within the bits type.
> > 
> > Neither the XML nor the JSON encoding rulse uses the position
> > property.  I believe the interpretation of the position field is going
> > to be protocol specific. DNS may do things in its own way, a CBOR
> > encoding of bits may do a different thing.
> 
> So do you suggest to keep the position equal to the number in the IANA registry?
>

That seems to be the most obvious thing to do.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Dec 19 04:46:25 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC93130DFA for ; Wed, 19 Dec 2018 04:46:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YL-Fa9aBgYHj for ; Wed, 19 Dec 2018 04:46:21 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC001130DFE for ; Wed, 19 Dec 2018 04:46:21 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 6E38D60604; Wed, 19 Dec 2018 13:46:20 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1545223580; bh=3nnnEkXAyIc0IhJ3FKZhJoWTAsfKqvvZlmavZHJMn7o=; h=From:To:Date; b=yOg593IVAPPbkQzXzJxEjD0KVnu6FFEV7OO5vRlUuEAQ+ovmHndrUqViJENpcadBw 3zpIKYfBnNLVLhqotFgUu5HJ+WPKFaLFHU89x1Q0bBhV3NR1MDEQ3i6X8yD5ONCU2y TJa/CX/F3/H4uSzIeXtK3s1EyjyZdN68H3CZyH/E=
Message-ID: 
From: Ladislav Lhotka 
To: Juergen Schoenwaelder 
Cc: NETMOD WG 
Date: Wed, 19 Dec 2018 13:46:20 +0100
In-Reply-To: <20181219124246.lvkiwofmq6wk4p5o@anna.jacobs.jacobs-university.de>
References: <0e6b0f62bbea33615a77d909dfde7098372f889b.camel@nic.cz> <20181219121617.7galbbhjy4bgqyo4@anna.jacobs.jacobs-university.de>  <20181219124246.lvkiwofmq6wk4p5o@anna.jacobs.jacobs-university.de>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.3 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] bit positions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 19 Dec 2018 12:46:24 -0000

On Wed, 2018-12-19 at 13:42 +0100, Juergen Schoenwaelder wrote:
> On Wed, Dec 19, 2018 at 01:35:02PM +0100, Ladislav Lhotka wrote:
> > On Wed, 2018-12-19 at 13:16 +0100, Juergen Schoenwaelder wrote:
> > > Lada,
> > > 
> > > RFC 7950 says:
> > > 
> > >    The "position" statement, which is optional, takes as an argument a
> > >    non-negative integer value that specifies the bit's position within a
> > >    hypothetical bit field.  The position value MUST be in the range 0 to
> > >    4294967295, and it MUST be unique within the bits type.
> > > 
> > > Neither the XML nor the JSON encoding rulse uses the position
> > > property.  I believe the interpretation of the position field is going
> > > to be protocol specific. DNS may do things in its own way, a CBOR
> > > encoding of bits may do a different thing.
> > 
> > So do you suggest to keep the position equal to the number in the IANA
> > registry?
> > 
> 
> That seems to be the most obvious thing to do.

OK. It will be certainly more palatable to DNS folks.

Thanks, Lada

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


From nobody Wed Dec 19 06:16:18 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1812212867A; Wed, 19 Dec 2018 06:16:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGmtvwF9FbIB; Wed, 19 Dec 2018 06:16:14 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0631200B3; Wed, 19 Dec 2018 06:16:14 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 53BB3182015D; Wed, 19 Dec 2018 15:25:06 +0100 (CET)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 36C8D182015B; Wed, 19 Dec 2018 15:25:04 +0100 (CET)
From: Ladislav Lhotka 
To: Jan Lindblad , Andy Bierman 
Cc: "netconf\@ietf.org" , "netmod\@ietf.org" 
In-Reply-To: <6912DD4C-4C4E-45E8-9F0E-D8D8139F83AE@tail-f.com>
References:  <20181217.091505.218628572185200621.mbj@tail-f.com> <83b139a1-a0ab-5fbc-f702-7f0d50a46864@ericsson.com> <90DB3C3B-FD52-4903-81B0-93985E6F74FE@tail-f.com>  <6912DD4C-4C4E-45E8-9F0E-D8D8139F83AE@tail-f.com>
Mail-Followup-To: Jan Lindblad , Andy Bierman , "netconf\@ietf.org" , "netmod\@ietf.org" 
Date: Wed, 19 Dec 2018 15:16:10 +0100
Message-ID: <875zvpeh5h.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] [Netconf] magic leaf 'type' in IETF interfaces
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 19 Dec 2018 14:16:17 -0000

Jan Lindblad  writes:

> Hi,
>>> While I agree with Martin, in our systems we have a number of places, where the system does create configuration in running, due to
>>> 
>>> different levels of automation and autonomous algorithms kick-in
>>> the created config needs to be possible to be further modified by the operator
>>> the created config needs to be referenced from operator created config
>>> the created config is not always ephemeral, it might need to be part of backup/restore
>> This is only a sampling from "the list of excuses". I have heard many more. The road to hell is paved with good intentions, however. If we want to build automation based on sound theory, clearly separating the orders from managers from a system's own operational view is key, IMO. Reliability, security, accountability are growing in importance, and they all play in this direction.
>> 
>> We may not need to standardize rules to outlaw the above; the market will take care of that. What we need to ensure is that it is possible to be standards compliant without having to implement design excuses like these.
>> 
>> 
>> NMDA has a lot of room for proprietary mechanisms for converting  to .
>> Many times the features desired by engineers exceed the capabilities of YANG, such as
>> a dynamic default leaf.  YANG allows a simple constant, and no business logic to pick the default.
>> This is a very valid use of "server auto-magic".
>> 
>> Maybe a future version of YANG can improve the client visibility into this "auto-magic"
>
> As you say, this is not uncommon. I usually recommend to leave out any
> default statement, and write in the description what happens if this
> leaf isn't set. The operator can then override the default by giving a
> value.

Anyway, this is not a case where the server writes something on its own
to a configuration datastore.

>
> While some more advanced features for default values may be of some
> utility, the simplicity of YANG is also important. We don't want to
> make the YANG models -- the interface contracts -- the new place for
> all business logic.

Absolutely.

Lada

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

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


From nobody Wed Dec 19 10:46:53 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD297130EBA for ; Wed, 19 Dec 2018 10:46:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 Ws4UDzTmBVLr for ; Wed, 19 Dec 2018 10:46:43 -0800 (PST)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29F0130EAE for ; Wed, 19 Dec 2018 10:46:42 -0800 (PST)
Received: by mail-lj1-x230.google.com with SMTP id g11-v6so18322535ljk.3 for ; Wed, 19 Dec 2018 10:46:42 -0800 (PST)
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=XPB8xIbAOgKImY7DsUU9U0/1nQUI0FWFHmZc+36soos=; b=igjxdSf3Y2uWj06m507+OPGlYgjmrWZyDzNzF6X6VWEhJ8LgqcB1pX4vHaCKbFOoP/ cJg0jZRNB7UyNI+B0lJog+iE5iSvNet5ehndmU92ShXg54G5mBDl8SNgPXCfnhXaMP9I OKFE4JDduMcZE6NbFr9vqdgFLCwdPfVHGdqUCQhZxkxygBrM2bob1Kvai5dtL1doJXa6 wwLUr59kBF+cpTSN+RWufsb+DsAvAf5MVuGMFo+QL0DehTSntfatGDyvwYXbE/i28rg9 stq+OrM6cmKGuLTgTvvKIJBctvjTsQcHOXg0SA+XNesNSTKKadVWpkAmYyOOekq3UfFl yoSw==
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=XPB8xIbAOgKImY7DsUU9U0/1nQUI0FWFHmZc+36soos=; b=OnFwlGojfteOrAvcZpogLHiDNjsJnsW219OZTCYviWESr7I0qp3paMrVHCZpfvWnwh 7tvPNAADqJEH3xtIifzAFWaVOKdgTDDqOYC6hQwnxg+j+NEjyRlVoL2dUs1ngIa4QiqN HzMalxtRQEmcV2WG/E31dCWYZfQXj8xXADlHoM3CHO+pin2sV7FvkbaowPQIqOTEigo+ l1RhJ0E3rXKMkzPj8CYjHSLISRVk8oO+DUGhwxcmehGNrggH2DSpqDe9w0puJsqQI5/f umV1KtrBI4uZpCvnpjSkxJdnpL0+d/LnKHVLG0aElPbBA3lq87MuX7mY7rEud1eXej8L gcsw==
X-Gm-Message-State: AA+aEWaavzLJFKYBSQWeTL989nojmDyekfy25BWwn4N8LrB55GAK7QYU pCxlMgGFqSyD9Fw5Ub2m4MOHCq2SG4A3XtM+lyjrUA==
X-Google-Smtp-Source: AFSGD/UY+U4ETEVEL+nmSn0urGiypQVUbmveDjvs5ZC3yXcTeUTmTnNNNdKddnOXFfXsSHJzFOWkjvkpHKY3siqRWDo=
X-Received: by 2002:a2e:9603:: with SMTP id v3-v6mr11361630ljh.15.1545245200812;  Wed, 19 Dec 2018 10:46:40 -0800 (PST)
MIME-Version: 1.0
References:  <20181217.091505.218628572185200621.mbj@tail-f.com> <83b139a1-a0ab-5fbc-f702-7f0d50a46864@ericsson.com> <90DB3C3B-FD52-4903-81B0-93985E6F74FE@tail-f.com>  <6912DD4C-4C4E-45E8-9F0E-D8D8139F83AE@tail-f.com> <875zvpeh5h.fsf@nic.cz>
In-Reply-To: <875zvpeh5h.fsf@nic.cz>
From: Andy Bierman 
Date: Wed, 19 Dec 2018 10:46:29 -0800
Message-ID: 
To: Jan Lindblad , Andy Bierman ,  "netconf@ietf.org" , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000004931b4057d646fa5"
Archived-At: 
Subject: Re: [netmod] [Netconf] magic leaf 'type' in IETF interfaces
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 19 Dec 2018 18:46:47 -0000

--0000000000004931b4057d646fa5
Content-Type: text/plain; charset="UTF-8"

On Wed, Dec 19, 2018 at 6:16 AM Ladislav Lhotka  wrote:

> Jan Lindblad  writes:
>
> > Hi,
> >>> While I agree with Martin, in our systems we have a number of places,
> where the system does create configuration in running, due to
> >>>
> >>> different levels of automation and autonomous algorithms kick-in
> >>> the created config needs to be possible to be further modified by the
> operator
> >>> the created config needs to be referenced from operator created config
> >>> the created config is not always ephemeral, it might need to be part
> of backup/restore
> >> This is only a sampling from "the list of excuses". I have heard many
> more. The road to hell is paved with good intentions, however. If we want
> to build automation based on sound theory, clearly separating the orders
> from managers from a system's own operational view is key, IMO.
> Reliability, security, accountability are growing in importance, and they
> all play in this direction.
> >>
> >> We may not need to standardize rules to outlaw the above; the market
> will take care of that. What we need to ensure is that it is possible to be
> standards compliant without having to implement design excuses like these.
> >>
> >>
> >> NMDA has a lot of room for proprietary mechanisms for converting
>  to .
> >> Many times the features desired by engineers exceed the capabilities of
> YANG, such as
> >> a dynamic default leaf.  YANG allows a simple constant, and no business
> logic to pick the default.
> >> This is a very valid use of "server auto-magic".
> >>
> >> Maybe a future version of YANG can improve the client visibility into
> this "auto-magic"
> >
> > As you say, this is not uncommon. I usually recommend to leave out any
> > default statement, and write in the description what happens if this
> > leaf isn't set. The operator can then override the default by giving a
> > value.
>
> Anyway, this is not a case where the server writes something on its own
> to a configuration datastore.
>


I don't think it is a problem if NMDA or non-NMDA servers write to
.
Just part of the complexity that is baked in -- NMDA does nothing to help
the client know
why  is different than  anyway.


>
> >
> > While some more advanced features for default values may be of some
> > utility, the simplicity of YANG is also important. We don't want to
> > make the YANG models -- the interface contracts -- the new place for
> > all business logic.
>
> Absolutely.
>
>
I am not proposing YANG needs a new default-stmt. There is a
description-stmt
and vendors can add their own extensions to flag auto-magic data nodes.


> Lada
>
> >
> > /jan
>


Andy


> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>

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




=

On Wed, Dec 19, 2018 at 6:16 AM Ladislav Lhotka <lhotka@nic.cz> wrote:
Jan Lindblad <janl@tail-f.com> writes:



> Hi,

>>> While I agree with Martin, in our systems we have a number of =
places, where the system does create configuration in running, due to

>>> 

>>> different levels of automation and autonomous algorithms kick-=
in

>>> the created config needs to be possible to be further modified=
 by the operator

>>> the created config needs to be referenced from operator create=
d config

>>> the created config is not always ephemeral, it might need to b=
e part of backup/restore

>> This is only a sampling from "the list of excuses". I ha=
ve heard many more. The road to hell is paved with good intentions, however=
. If we want to build automation based on sound theory, clearly separating =
the orders from managers from a system's own operational view is key, I=
MO. Reliability, security, accountability are growing in importance, and th=
ey all play in this direction.

>> 

>> We may not need to standardize rules to outlaw the above; the mark=
et will take care of that. What we need to ensure is that it is possible to=
 be standards compliant without having to implement design excuses like the=
se.

>> 

>> 

>> NMDA has a lot of room for proprietary mechanisms for converting &=
lt;running> to <intended>.

>> Many times the features desired by engineers exceed the capabiliti=
es of YANG, such as

>> a dynamic default leaf.=C2=A0 YANG allows a simple constant, and n=
o business logic to pick the default.

>> This is a very valid use of "server auto-magic".

>> 

>> Maybe a future version of YANG can improve the client visibility i=
nto this "auto-magic"

>

> As you say, this is not uncommon. I usually recommend to leave out any=


> default statement, and write in the description what happens if this
> leaf isn't set. The operator can then override the default by givi=
ng a

> value.



Anyway, this is not a case where the server writes something on its own

to a configuration datastore.


I don't think it is a problem if NMDA or non-NMDA servers write t=
o <running>.
Just part of the complexity that is baked in -=
- NMDA does nothing to help the client know
why <running> i=
s different than <intended> anyway.
=C2=A0



>

> While some more advanced features for default values may be of some
> utility, the simplicity of YANG is also important. We don't want t=
o

> make the YANG models -- the interface contracts -- the new place for
> all business logic.



Absolutely.



I am not proposing YANG needs a new de=
fault-stmt. There is a description-stmt
and vendors can add their=
 own extensions to flag auto-magic data nodes.
=C2=A0

Lada



>

> /jan


Andy
=C2=A0

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

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


-- 

Ladislav Lhotka

Head, CZ.NIC Labs

PGP Key ID: 0xB8F92B08A9F76C67




--0000000000004931b4057d646fa5--


From nobody Wed Dec 19 16:49:04 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0EF1294D0; Wed, 19 Dec 2018 16:48:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level: 
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YhcQZi6V7ZK; Wed, 19 Dec 2018 16:48:53 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0BD126C01; Wed, 19 Dec 2018 16:48:52 -0800 (PST)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A8AA64D9FC966; Thu, 20 Dec 2018 00:48:45 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 20 Dec 2018 00:48:47 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.172]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Thu, 20 Dec 2018 08:48:43 +0800
From: Qin Wu 
To: Jan Lindblad , =?gb2312?B?QmFsqKJ6cyBMZW5neWVs?= 
CC: "netconf@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [netmod] [Netconf]   magic leaf 'type' in IETF interfaces
Thread-Index: AQHUltbN9lVO78lVgUuAW3HVKNk4taWGzEeA
Date: Thu, 20 Dec 2018 00:48:42 +0000
Message-ID: 
References:  <20181217.091505.218628572185200621.mbj@tail-f.com> <83b139a1-a0ab-5fbc-f702-7f0d50a46864@ericsson.com> <90DB3C3B-FD52-4903-81B0-93985E6F74FE@tail-f.com>
In-Reply-To: <90DB3C3B-FD52-4903-81B0-93985E6F74FE@tail-f.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B1B55C9nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] [Netconf]   magic leaf 'type' in IETF interfaces
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Dec 2018 00:48:56 -0000

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

SGk6DQq3orz+yMs6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSC0+rHt
IEphbiBMaW5kYmxhZA0Kt6LLzcqxvOQ6IDIwMTjE6jEy1MIxOMjVIDIxOjM3DQrK1bz+yMs6IEJh
bKiienMgTGVuZ3llbA0Ks63LzTogbmV0Y29uZkBpZXRmLm9yZzsgbmV0bW9kQGlldGYub3JnDQrW
98ziOiBSZTogW25ldG1vZF0gW05ldGNvbmZdIG1hZ2ljIGxlYWYgJ3R5cGUnIGluIElFVEYgaW50
ZXJmYWNlcw0KDQpIaSwNCldoaWxlIEkgYWdyZWUgd2l0aCBNYXJ0aW4sIGluIG91ciBzeXN0ZW1z
IHdlIGhhdmUgYSBudW1iZXIgb2YgcGxhY2VzLCB3aGVyZSB0aGUgc3lzdGVtIGRvZXMgY3JlYXRl
IGNvbmZpZ3VyYXRpb24gaW4gcnVubmluZywgZHVlIHRvDQoNCiAgKiAgIGRpZmZlcmVudCBsZXZl
bHMgb2YgYXV0b21hdGlvbiBhbmQgYXV0b25vbW91cyBhbGdvcml0aG1zIGtpY2staW4NCiAgKiAg
IHRoZSBjcmVhdGVkIGNvbmZpZyBuZWVkcyB0byBiZSBwb3NzaWJsZSB0byBiZSBmdXJ0aGVyIG1v
ZGlmaWVkIGJ5IHRoZSBvcGVyYXRvcg0KDQogICogICB0aGUgY3JlYXRlZCBjb25maWcgbmVlZHMg
dG8gYmUgcmVmZXJlbmNlZCBmcm9tIG9wZXJhdG9yIGNyZWF0ZWQgY29uZmlnDQpbUWluXTogV2Ug
aGF2ZSBhIG5ldyBkcmFmdCB0aGF0IGhhcyBqdXN0IGJlZW4gcG9zdGVkIHRvIGRpc2N1c3Mgc29t
ZSBvZiB0aGVzZSBpc3N1ZXMgd2hpY2ggYWxsb3cgc3lzdGVtIGNyZWF0aW9uIGNvbmZpZ3VyYXRp
b24gaW4gcnVubmluZw0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LW5ldGNv
bmYtbm1kYS1jb21wYXRpYmlsaXR5LTAwDQoNCg0KICAqICAgdGhlIGNyZWF0ZWQgY29uZmlnIGlz
IG5vdCBhbHdheXMgZXBoZW1lcmFsLCBpdCBtaWdodCBuZWVkIHRvIGJlIHBhcnQgb2YgYmFja3Vw
L3Jlc3RvcmUNClRoaXMgaXMgb25seSBhIHNhbXBsaW5nIGZyb20gInRoZSBsaXN0IG9mIGV4Y3Vz
ZXMiLiBJIGhhdmUgaGVhcmQgbWFueSBtb3JlLiBUaGUgcm9hZCB0byBoZWxsIGlzIHBhdmVkIHdp
dGggZ29vZCBpbnRlbnRpb25zLCBob3dldmVyLiBJZiB3ZSB3YW50IHRvIGJ1aWxkIGF1dG9tYXRp
b24gYmFzZWQgb24gc291bmQgdGhlb3J5LCBjbGVhcmx5IHNlcGFyYXRpbmcgdGhlIG9yZGVycyBm
cm9tIG1hbmFnZXJzIGZyb20gYSBzeXN0ZW0ncyBvd24gb3BlcmF0aW9uYWwgdmlldyBpcyBrZXks
IElNTy4gUmVsaWFiaWxpdHksIHNlY3VyaXR5LCBhY2NvdW50YWJpbGl0eSBhcmUgZ3Jvd2luZyBp
biBpbXBvcnRhbmNlLCBhbmQgdGhleSBhbGwgcGxheSBpbiB0aGlzIGRpcmVjdGlvbi4NCg0KV2Ug
bWF5IG5vdCBuZWVkIHRvIHN0YW5kYXJkaXplIHJ1bGVzIHRvIG91dGxhdyB0aGUgYWJvdmU7IHRo
ZSBtYXJrZXQgd2lsbCB0YWtlIGNhcmUgb2YgdGhhdC4gV2hhdCB3ZSBuZWVkIHRvIGVuc3VyZSBp
cyB0aGF0IGl0IGlzIHBvc3NpYmxlIHRvIGJlIHN0YW5kYXJkcyBjb21wbGlhbnQgd2l0aG91dCBo
YXZpbmcgdG8gaW1wbGVtZW50IGRlc2lnbiBleGN1c2VzIGxpa2UgdGhlc2UuDQogICAgICBbUWlu
XTogSSB3b3VsZCBzdXBwb3J0IHN0YW5kYXJkaXppbmcgc29tZSBvZiBndWlkYW5jZSBydWxlcyBv
ciBkZXNpZ24gcnVsZXMgb24gaG93IHRvIGRlYWwgd2l0aCB0aGVzZSBjYXNlcy4NCg0KQmVzdCBS
ZWdhcmRzLA0KL2phbg0KDQo=

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











Hi:






=B7=A2=BC=FE=C8=CB: netmod =
[mailto:netmod-bounces@ietf.org]
=B4=FA=
=B1=ED Jan Lindblad

=B7=A2=
=CB=CD=CA=B1=BC=E4: 2018=C4=EA12=D4=C218=C8=D5
 21:37

=CA=D5=BC=FE=C8=CB: Bal=A8=A2zs Lengyel

=B3=AD=CB=CD: netconf@ietf.org; netmod@ietf.org

=D6=F7=CC=E2: Re: [netmod] [Netconf] magic leaf 'type' in IETF interfaces






 


Hi,












While I agree with Martin, in our systems we =
have a number of places, where the system does create configuration in runn=
ing, due to


    

  • 
different levels of automation and autonomous algorith=
ms kick-in
  • 
the created config needs to be possible to be further =
modified by the operator


    

  • 
the created config needs to=
 be referenced from operator created config



[Qin]: We have a new draft that h=
as just been posted to discuss some of these issues which allow system crea=
tion configuration in running



https://tools.ietf.org/html/d=
raft-wu-netconf-nmda-compatibility-00



 


    

  • 
the created config is not always ephemeral, it might n=
eed to be part of backup/restore










This is only a sampling from &q=
uot;the list of excuses". I have heard many more. The road to hell is =
paved with good intentions, however. If we want to build automation based o=
n sound theory, clearly separating the orders
 from managers from a system's own operational view is key, IMO. Reliabilit=
y, security, accountability are growing in importance, and they all play in=
 this direction.






 






We may not need to standardize =
rules to outlaw the above; the market will take care of that. What we need =
to ensure is that it is possible to be standards compliant without having t=
o implement design excuses like these.


 &nbs=
p;    [Qin]: I would support standardizing some of guidance =
rules or design rules on how to deal with these cases.





 






Best Regards,=







/jan






 












--_000_B8F9A780D330094D99AF023C5877DABA9B1B55C9nkgeml513mbxchi_--


From nobody Wed Dec 19 16:57:50 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDC7126F72; Wed, 19 Dec 2018 16:57:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GF3eD7fIFO3R; Wed, 19 Dec 2018 16:57:46 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB3A1294D0; Wed, 19 Dec 2018 16:57:46 -0800 (PST)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 35FFAA068949A; Thu, 20 Dec 2018 00:57:42 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 20 Dec 2018 00:57:43 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.172]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Thu, 20 Dec 2018 08:57:40 +0800
From: Qin Wu 
To: Andy Bierman , Jan Lindblad , "netconf@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [Netconf] [netmod]  magic leaf 'type' in IETF interfaces
Thread-Index: AQHUl8tEIaeGkfvXD0+KnC4oEKYl6aWGzJKQ
Date: Thu, 20 Dec 2018 00:57:40 +0000
Message-ID: 
References:  <20181217.091505.218628572185200621.mbj@tail-f.com> <83b139a1-a0ab-5fbc-f702-7f0d50a46864@ericsson.com> <90DB3C3B-FD52-4903-81B0-93985E6F74FE@tail-f.com>  <6912DD4C-4C4E-45E8-9F0E-D8D8139F83AE@tail-f.com> <875zvpeh5h.fsf@nic.cz> 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B1B55F5nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] [Netconf]   magic leaf 'type' in IETF interfaces
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Dec 2018 00:57:49 -0000

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

5Y+R5Lu25Lq6OiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSDku6Po
oaggQW5keSBCaWVybWFuDQrlj5HpgIHml7bpl7Q6IDIwMTjlubQxMuaciDIw5pelIDI6NDYNCuaU
tuS7tuS6ujogSmFuIExpbmRibGFkOyBBbmR5IEJpZXJtYW47IG5ldGNvbmZAaWV0Zi5vcmc7IG5l
dG1vZEBpZXRmLm9yZw0K5Li76aKYOiBSZTogW05ldGNvbmZdIFtuZXRtb2RdIG1hZ2ljIGxlYWYg
J3R5cGUnIGluIElFVEYgaW50ZXJmYWNlcw0KDQoNCg0KT24gV2VkLCBEZWMgMTksIDIwMTggYXQg
NjoxNiBBTSBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o8bWFpbHRvOmxob3RrYUBuaWMu
Y3o+PiB3cm90ZToNCkphbiBMaW5kYmxhZCA8amFubEB0YWlsLWYuY29tPG1haWx0bzpqYW5sQHRh
aWwtZi5jb20+PiB3cml0ZXM6DQoNCj4gSGksDQo+Pj4gV2hpbGUgSSBhZ3JlZSB3aXRoIE1hcnRp
biwgaW4gb3VyIHN5c3RlbXMgd2UgaGF2ZSBhIG51bWJlciBvZiBwbGFjZXMsIHdoZXJlIHRoZSBz
eXN0ZW0gZG9lcyBjcmVhdGUgY29uZmlndXJhdGlvbiBpbiBydW5uaW5nLCBkdWUgdG8NCj4+Pg0K
Pj4+IGRpZmZlcmVudCBsZXZlbHMgb2YgYXV0b21hdGlvbiBhbmQgYXV0b25vbW91cyBhbGdvcml0
aG1zIGtpY2staW4NCj4+PiB0aGUgY3JlYXRlZCBjb25maWcgbmVlZHMgdG8gYmUgcG9zc2libGUg
dG8gYmUgZnVydGhlciBtb2RpZmllZCBieSB0aGUgb3BlcmF0b3INCj4+PiB0aGUgY3JlYXRlZCBj
b25maWcgbmVlZHMgdG8gYmUgcmVmZXJlbmNlZCBmcm9tIG9wZXJhdG9yIGNyZWF0ZWQgY29uZmln
DQo+Pj4gdGhlIGNyZWF0ZWQgY29uZmlnIGlzIG5vdCBhbHdheXMgZXBoZW1lcmFsLCBpdCBtaWdo
dCBuZWVkIHRvIGJlIHBhcnQgb2YgYmFja3VwL3Jlc3RvcmUNCj4+IFRoaXMgaXMgb25seSBhIHNh
bXBsaW5nIGZyb20gInRoZSBsaXN0IG9mIGV4Y3VzZXMiLiBJIGhhdmUgaGVhcmQgbWFueSBtb3Jl
LiBUaGUgcm9hZCB0byBoZWxsIGlzIHBhdmVkIHdpdGggZ29vZCBpbnRlbnRpb25zLCBob3dldmVy
Li4gSWYgd2Ugd2FudCB0byBidWlsZCBhdXRvbWF0aW9uIGJhc2VkIG9uIHNvdW5kIHRoZW9yeSwg
Y2xlYXJseSBzZXBhcmF0aW5nIHRoZSBvcmRlcnMgZnJvbSBtYW5hZ2VycyBmcm9tIGEgc3lzdGVt
J3Mgb3duIG9wZXJhdGlvbmFsIHZpZXcgaXMga2V5LCBJTU8uIFJlbGlhYmlsaXR5LCBzZWN1cml0
eSwgYWNjb3VudGFiaWxpdHkgYXJlIGdyb3dpbmcgaW4gaW1wb3J0YW5jZSwgYW5kIHRoZXkgYWxs
IHBsYXkgaW4gdGhpcyBkaXJlY3Rpb24uDQo+Pg0KPj4gV2UgbWF5IG5vdCBuZWVkIHRvIHN0YW5k
YXJkaXplIHJ1bGVzIHRvIG91dGxhdyB0aGUgYWJvdmU7IHRoZSBtYXJrZXQgd2lsbCB0YWtlIGNh
cmUgb2YgdGhhdC4gV2hhdCB3ZSBuZWVkIHRvIGVuc3VyZSBpcyB0aGF0IGl0IGlzIHBvc3NpYmxl
IHRvIGJlIHN0YW5kYXJkcyBjb21wbGlhbnQgd2l0aG91dCBoYXZpbmcgdG8gaW1wbGVtZW50IGRl
c2lnbiBleGN1c2VzIGxpa2UgdGhlc2UuDQo+Pg0KPj4NCj4+IE5NREEgaGFzIGEgbG90IG9mIHJv
b20gZm9yIHByb3ByaWV0YXJ5IG1lY2hhbmlzbXMgZm9yIGNvbnZlcnRpbmcgPHJ1bm5pbmc+IHRv
IDxpbnRlbmRlZD4uDQo+PiBNYW55IHRpbWVzIHRoZSBmZWF0dXJlcyBkZXNpcmVkIGJ5IGVuZ2lu
ZWVycyBleGNlZWQgdGhlIGNhcGFiaWxpdGllcyBvZiBZQU5HLCBzdWNoIGFzDQo+PiBhIGR5bmFt
aWMgZGVmYXVsdCBsZWFmLiAgWUFORyBhbGxvd3MgYSBzaW1wbGUgY29uc3RhbnQsIGFuZCBubyBi
dXNpbmVzcyBsb2dpYyB0byBwaWNrIHRoZSBkZWZhdWx0Lg0KPj4gVGhpcyBpcyBhIHZlcnkgdmFs
aWQgdXNlIG9mICJzZXJ2ZXIgYXV0by1tYWdpYyIuDQo+Pg0KPj4gTWF5YmUgYSBmdXR1cmUgdmVy
c2lvbiBvZiBZQU5HIGNhbiBpbXByb3ZlIHRoZSBjbGllbnQgdmlzaWJpbGl0eSBpbnRvIHRoaXMg
ImF1dG8tbWFnaWMiDQo+DQo+IEFzIHlvdSBzYXksIHRoaXMgaXMgbm90IHVuY29tbW9uLiBJIHVz
dWFsbHkgcmVjb21tZW5kIHRvIGxlYXZlIG91dCBhbnkNCj4gZGVmYXVsdCBzdGF0ZW1lbnQsIGFu
ZCB3cml0ZSBpbiB0aGUgZGVzY3JpcHRpb24gd2hhdCBoYXBwZW5zIGlmIHRoaXMNCj4gbGVhZiBp
c24ndCBzZXQuIFRoZSBvcGVyYXRvciBjYW4gdGhlbiBvdmVycmlkZSB0aGUgZGVmYXVsdCBieSBn
aXZpbmcgYQ0KPiB2YWx1ZS4NCg0KQW55d2F5LCB0aGlzIGlzIG5vdCBhIGNhc2Ugd2hlcmUgdGhl
IHNlcnZlciB3cml0ZXMgc29tZXRoaW5nIG9uIGl0cyBvd24NCnRvIGEgY29uZmlndXJhdGlvbiBk
YXRhc3RvcmUuDQoNCg0KSSBkb24ndCB0aGluayBpdCBpcyBhIHByb2JsZW0gaWYgTk1EQSBvciBu
b24tTk1EQSBzZXJ2ZXJzIHdyaXRlIHRvIDxydW5uaW5nPi4NCkp1c3QgcGFydCBvZiB0aGUgY29t
cGxleGl0eSB0aGF0IGlzIGJha2VkIGluIC0tIE5NREEgZG9lcyBub3RoaW5nIHRvIGhlbHAgdGhl
IGNsaWVudCBrbm93DQp3aHkgPHJ1bm5pbmc+IGlzIGRpZmZlcmVudCB0aGFuIDxpbnRlbmRlZD4g
YW55d2F5Lg0KDQoNCg0KDQoNCltRaW5dOiBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBtYWtl
IE5NREEgc2VydmVyIGNhbiB1c2UgZXhpc3Rpbmcgb3BlcmF0aW9uIHRvDQoNCiAgIHJldHVybiB0
aGUgc2FtZSByZXN1bHRzIHRvIE5vbi1OTURBIGNsaWVudCB3aXRoIDxycGMtcmVwbHk+IGFzIG5v
bi1OTURBIHNlcnZlcg0KDQogICBkb2VzLiBXZSBjYWxsIHRoaXMgU2VydmVyIEJhY2t3YXJkcy1D
b21wYXRpYmlsaXR5IGluDQoNCiAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13
dS1uZXRjb25mLW5tZGEtY29tcGF0aWJpbGl0eS0wMCNzZWN0aW9uLTIuMw0KDQoNCg0KPg0KPiBX
aGlsZSBzb21lIG1vcmUgYWR2YW5jZWQgZmVhdHVyZXMgZm9yIGRlZmF1bHQgdmFsdWVzIG1heSBi
ZSBvZiBzb21lDQo+IHV0aWxpdHksIHRoZSBzaW1wbGljaXR5IG9mIFlBTkcgaXMgYWxzbyBpbXBv
cnRhbnQuIFdlIGRvbid0IHdhbnQgdG8NCj4gbWFrZSB0aGUgWUFORyBtb2RlbHMgLS0gdGhlIGlu
dGVyZmFjZSBjb250cmFjdHMgLS0gdGhlIG5ldyBwbGFjZSBmb3INCj4gYWxsIGJ1c2luZXNzIGxv
Z2ljLg0KDQpBYnNvbHV0ZWx5Lg0KDQpJIGFtIG5vdCBwcm9wb3NpbmcgWUFORyBuZWVkcyBhIG5l
dyBkZWZhdWx0LXN0bXQuIFRoZXJlIGlzIGEgZGVzY3JpcHRpb24tc3RtdA0KYW5kIHZlbmRvcnMg
Y2FuIGFkZCB0aGVpciBvd24gZXh0ZW5zaW9ucyB0byBmbGFnIGF1dG8tbWFnaWMgZGF0YSBub2Rl
cy4NCg0KTGFkYQ0KDQo+DQo+IC9qYW4NCg0KDQpBbmR5DQoNCj4NCj4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0K
PiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KLS0NCkxhZGlzbGF2IExob3RrYQ0K
SGVhZCwgQ1ouTklDIExhYnMNClBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ
cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K
cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp
dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBD
aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6
MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t
c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt
c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFt
ZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z
by1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk65a6L5L2TO30N
Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdv
cmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBw
dCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7
fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg
djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw
IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm
XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw
bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxh
bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IE5ldGNvbmYgW21haWx0bzpuZXRj
b25mLWJvdW5jZXNAaWV0Zi5vcmddDQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQiPuS7o+ihqCA8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdCI+QW5keSBCaWVybWFuPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3Nw
YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IDIwMTg8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVT
Ij4xMjwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MjA8L3NwYW4+5pelPHNwYW4gbGFuZz0i
RU4tVVMiPiAyOjQ2PGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46
PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEphbiBMaW5kYmxhZDsgQW5keSBCaWVybWFu
OyBuZXRjb25mQGlldGYub3JnOyBuZXRtb2RAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PGI+5Li76aKY
PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmU6IFtO
ZXRjb25mXSBbbmV0bW9kXSBtYWdpYyBsZWFmICd0eXBlJyBpbiBJRVRGIGludGVyZmFjZXM8bzpw
PjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gV2VkLCBEZWMgMTksIDIwMTgg
YXQgNjoxNiBBTSBMYWRpc2xhdiBMaG90a2EgJmx0OzxhIGhyZWY9Im1haWx0bzpsaG90a2FAbmlj
LmN6Ij5saG90a2FAbmljLmN6PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg
I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0
O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiPkphbiBMaW5kYmxhZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphbmxAdGFpbC1mLmNvbSIgdGFy
Z2V0PSJfYmxhbmsiPmphbmxAdGFpbC1mLmNvbTwvYT4mZ3Q7IHdyaXRlczo8YnI+DQo8YnI+DQom
Z3Q7IEhpLDxicj4NCiZndDsmZ3Q7Jmd0OyBXaGlsZSBJIGFncmVlIHdpdGggTWFydGluLCBpbiBv
dXIgc3lzdGVtcyB3ZSBoYXZlIGEgbnVtYmVyIG9mIHBsYWNlcywgd2hlcmUgdGhlIHN5c3RlbSBk
b2VzIGNyZWF0ZSBjb25maWd1cmF0aW9uIGluIHJ1bm5pbmcsIGR1ZSB0bzxicj4NCiZndDsmZ3Q7
Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgZGlmZmVyZW50IGxldmVscyBvZiBhdXRvbWF0aW9uIGFu
ZCBhdXRvbm9tb3VzIGFsZ29yaXRobXMga2ljay1pbjxicj4NCiZndDsmZ3Q7Jmd0OyB0aGUgY3Jl
YXRlZCBjb25maWcgbmVlZHMgdG8gYmUgcG9zc2libGUgdG8gYmUgZnVydGhlciBtb2RpZmllZCBi
eSB0aGUgb3BlcmF0b3I8YnI+DQomZ3Q7Jmd0OyZndDsgdGhlIGNyZWF0ZWQgY29uZmlnIG5lZWRz
IHRvIGJlIHJlZmVyZW5jZWQgZnJvbSBvcGVyYXRvciBjcmVhdGVkIGNvbmZpZzxicj4NCiZndDsm
Z3Q7Jmd0OyB0aGUgY3JlYXRlZCBjb25maWcgaXMgbm90IGFsd2F5cyBlcGhlbWVyYWwsIGl0IG1p
Z2h0IG5lZWQgdG8gYmUgcGFydCBvZiBiYWNrdXAvcmVzdG9yZTxicj4NCiZndDsmZ3Q7IFRoaXMg
aXMgb25seSBhIHNhbXBsaW5nIGZyb20gJnF1b3Q7dGhlIGxpc3Qgb2YgZXhjdXNlcyZxdW90Oy4g
SSBoYXZlIGhlYXJkIG1hbnkgbW9yZS4gVGhlIHJvYWQgdG8gaGVsbCBpcyBwYXZlZCB3aXRoIGdv
b2QgaW50ZW50aW9ucywgaG93ZXZlci4uIElmIHdlIHdhbnQgdG8gYnVpbGQgYXV0b21hdGlvbiBi
YXNlZCBvbiBzb3VuZCB0aGVvcnksIGNsZWFybHkgc2VwYXJhdGluZyB0aGUgb3JkZXJzIGZyb20g
bWFuYWdlcnMgZnJvbSBhIHN5c3RlbSdzIG93biBvcGVyYXRpb25hbA0KIHZpZXcgaXMga2V5LCBJ
TU8uIFJlbGlhYmlsaXR5LCBzZWN1cml0eSwgYWNjb3VudGFiaWxpdHkgYXJlIGdyb3dpbmcgaW4g
aW1wb3J0YW5jZSwgYW5kIHRoZXkgYWxsIHBsYXkgaW4gdGhpcyBkaXJlY3Rpb24uPGJyPg0KJmd0
OyZndDsgPGJyPg0KJmd0OyZndDsgV2UgbWF5IG5vdCBuZWVkIHRvIHN0YW5kYXJkaXplIHJ1bGVz
IHRvIG91dGxhdyB0aGUgYWJvdmU7IHRoZSBtYXJrZXQgd2lsbCB0YWtlIGNhcmUgb2YgdGhhdC4g
V2hhdCB3ZSBuZWVkIHRvIGVuc3VyZSBpcyB0aGF0IGl0IGlzIHBvc3NpYmxlIHRvIGJlIHN0YW5k
YXJkcyBjb21wbGlhbnQgd2l0aG91dCBoYXZpbmcgdG8gaW1wbGVtZW50IGRlc2lnbiBleGN1c2Vz
IGxpa2UgdGhlc2UuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsg
Tk1EQSBoYXMgYSBsb3Qgb2Ygcm9vbSBmb3IgcHJvcHJpZXRhcnkgbWVjaGFuaXNtcyBmb3IgY29u
dmVydGluZyAmbHQ7cnVubmluZyZndDsgdG8gJmx0O2ludGVuZGVkJmd0Oy48YnI+DQomZ3Q7Jmd0
OyBNYW55IHRpbWVzIHRoZSBmZWF0dXJlcyBkZXNpcmVkIGJ5IGVuZ2luZWVycyBleGNlZWQgdGhl
IGNhcGFiaWxpdGllcyBvZiBZQU5HLCBzdWNoIGFzPGJyPg0KJmd0OyZndDsgYSBkeW5hbWljIGRl
ZmF1bHQgbGVhZi4mbmJzcDsgWUFORyBhbGxvd3MgYSBzaW1wbGUgY29uc3RhbnQsIGFuZCBubyBi
dXNpbmVzcyBsb2dpYyB0byBwaWNrIHRoZSBkZWZhdWx0Ljxicj4NCiZndDsmZ3Q7IFRoaXMgaXMg
YSB2ZXJ5IHZhbGlkIHVzZSBvZiAmcXVvdDtzZXJ2ZXIgYXV0by1tYWdpYyZxdW90Oy48YnI+DQom
Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBNYXliZSBhIGZ1dHVyZSB2ZXJzaW9uIG9mIFlBTkcgY2Fu
IGltcHJvdmUgdGhlIGNsaWVudCB2aXNpYmlsaXR5IGludG8gdGhpcyAmcXVvdDthdXRvLW1hZ2lj
JnF1b3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgQXMgeW91IHNheSwgdGhpcyBpcyBub3QgdW5jb21t
b24uIEkgdXN1YWxseSByZWNvbW1lbmQgdG8gbGVhdmUgb3V0IGFueTxicj4NCiZndDsgZGVmYXVs
dCBzdGF0ZW1lbnQsIGFuZCB3cml0ZSBpbiB0aGUgZGVzY3JpcHRpb24gd2hhdCBoYXBwZW5zIGlm
IHRoaXM8YnI+DQomZ3Q7IGxlYWYgaXNuJ3Qgc2V0LiBUaGUgb3BlcmF0b3IgY2FuIHRoZW4gb3Zl
cnJpZGUgdGhlIGRlZmF1bHQgYnkgZ2l2aW5nIGE8YnI+DQomZ3Q7IHZhbHVlLjxicj4NCjxicj4N
CkFueXdheSwgdGhpcyBpcyBub3QgYSBjYXNlIHdoZXJlIHRoZSBzZXJ2ZXIgd3JpdGVzIHNvbWV0
aGluZyBvbiBpdHMgb3duPGJyPg0KdG8gYSBjb25maWd1cmF0aW9uIGRhdGFzdG9yZS48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBsYW5nPSJFTi1VUyI+SSBkb24ndCB0aGluayBpdCBpcyBhIHByb2JsZW0gaWYgTk1E
QSBvciBub24tTk1EQSBzZXJ2ZXJzIHdyaXRlIHRvICZsdDtydW5uaW5nJmd0Oy48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyI+SnVzdCBwYXJ0IG9mIHRoZSBjb21wbGV4aXR5IHRoYXQgaXMgYmFrZWQgaW4g
LS0gTk1EQSBkb2VzIG5vdGhpbmcgdG8gaGVscCB0aGUgY2xpZW50IGtub3c8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyI+d2h5ICZsdDtydW5uaW5nJmd0OyBpcyBkaWZmZXJlbnQgdGhhbiAmbHQ7aW50ZW5k
ZWQmZ3Q7IGFueXdheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJl
PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86
cD48L286cD48L3NwYW4+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZSBzdHlsZT0idGV4dC1pbmRlbnQ6MTguMHB0Ij48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltRPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5pbl06
IEkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IHRvIG1ha2UgTk1EQSBzZXJ2ZXIgY2FuIHVzZSBleGlz
dGluZyBvcGVyYXRpb24gdG8gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh
bmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDtyZXR1cm4gdGhlIHNhbWUgcmVzdWx0cyB0byBO
b24tTk1EQSBjbGllbnQgd2l0aCAmbHQ7cnBjLXJlcGx5Jmd0OyBhcyBub24tTk1EQSBzZXJ2ZXI8
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZu
YnNwOyBkb2VzLiBXZSBjYWxsIHRoaXMgU2VydmVyIEJhY2t3YXJkcy1Db21wYXRpYmlsaXR5IGlu
PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsm
bmJzcDsgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd1LW5ldGNvbmYtbm1kYS1j
b21wYXRpYmlsaXR5LTAwI3NlY3Rpb24tMi4zPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7
cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6
MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+
PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCiZndDs8YnI+DQomZ3Q7IFdoaWxlIHNvbWUgbW9yZSBh
ZHZhbmNlZCBmZWF0dXJlcyBmb3IgZGVmYXVsdCB2YWx1ZXMgbWF5IGJlIG9mIHNvbWU8YnI+DQom
Z3Q7IHV0aWxpdHksIHRoZSBzaW1wbGljaXR5IG9mIFlBTkcgaXMgYWxzbyBpbXBvcnRhbnQuIFdl
IGRvbid0IHdhbnQgdG88YnI+DQomZ3Q7IG1ha2UgdGhlIFlBTkcgbW9kZWxzIC0tIHRoZSBpbnRl
cmZhY2UgY29udHJhY3RzIC0tIHRoZSBuZXcgcGxhY2UgZm9yPGJyPg0KJmd0OyBhbGwgYnVzaW5l
c3MgbG9naWMuPGJyPg0KPGJyPg0KQWJzb2x1dGVseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGFtIG5vdCBwcm9wb3NpbmcgWUFORyBu
ZWVkcyBhIG5ldyBkZWZhdWx0LXN0bXQuIFRoZXJlIGlzIGEgZGVzY3JpcHRpb24tc3RtdDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIj5hbmQgdmVuZG9ycyBjYW4gYWRkIHRoZWlyIG93biBleHRlbnNpb25z
IHRvIGZsYWcgYXV0by1tYWdpYyBkYXRhIG5vZGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz
cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw
Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TGFkYTxicj4NCjxicj4NCiZndDs8YnI+DQom
Z3Q7IC9qYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QW5keTxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO
LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6
MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0Ozxicj4NCiZndDsgX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IG5l
dG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0PSJf
YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxi
cj4NCjxicj4NCi0tIDxicj4NCkxhZGlzbGF2IExob3RrYTxicj4NCkhlYWQsIENaLk5JQyBMYWJz
PGJyPg0KUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_B8F9A780D330094D99AF023C5877DABA9B1B55F5nkgeml513mbxchi_--


From nobody Thu Dec 20 01:08:42 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B24131110; Thu, 20 Dec 2018 01:08:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.964
X-Spam-Level: 
X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 y4QTJ4xpM4aq; Thu, 20 Dec 2018 01:08:29 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on072c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E937013110D; Thu, 20 Dec 2018 01:08:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8/54RMHUcmOMAgpR+PnDJdI+WXVkDZOQv7RkH6mUcJk=; b=FEPqP8nxXsHoGtLC2Tt1bZEGshdfvGkU68g7hQibpSRb10kD81zvJX25qAAItWNxiay8LlMIwlW6/vhIPEIV/4uqJHcq8BfG148HN7oJJH/QeSp30Bf6+XEhqm0O87ov2BgyxR6+MaUsiTVKWUmTGybjCIuiYWMvQhPEGdxUBeI=
Received: from AM0PR07MB5921.eurprd07.prod.outlook.com (20.178.83.29) by AM0PR07MB4723.eurprd07.prod.outlook.com (52.135.152.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1446.13; Thu, 20 Dec 2018 09:08:23 +0000
Received: from AM0PR07MB5921.eurprd07.prod.outlook.com ([fe80::2472:b9b2:f133:85e8]) by AM0PR07MB5921.eurprd07.prod.outlook.com ([fe80::2472:b9b2:f133:85e8%3]) with mapi id 15.20.1446.020; Thu, 20 Dec 2018 09:08:23 +0000
From: "Belotti, Sergio (Nokia - IT/Vimercate)" 
To: Andy Bierman , Jan Lindblad , "netconf@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [netmod] [Netconf] magic leaf 'type' in IETF interfaces
Thread-Index: AQHUlv2bHKpB64q9oEOoL5It3/ZnuKWFzQ4AgABPvgCAAEuGgIAA7vXg
Date: Thu, 20 Dec 2018 09:08:23 +0000
Message-ID: 
References:  <20181217.091505.218628572185200621.mbj@tail-f.com> <83b139a1-a0ab-5fbc-f702-7f0d50a46864@ericsson.com> <90DB3C3B-FD52-4903-81B0-93985E6F74FE@tail-f.com>  <6912DD4C-4C4E-45E8-9F0E-D8D8139F83AE@tail-f.com> <875zvpeh5h.fsf@nic.cz> 
In-Reply-To: 
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sergio.belotti@nokia.com; 
x-originating-ip: [93.36.178.236]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB4723; 6:02WJceh7Yjoaf7TLGMIEj37umQvSJ7itqgUL/Mvwygqba33yGki4HB+LgUH/0daP4r9T626JnwbKFZ6Yz24dXu0orHT3uLsLop7FXgklcnWQPF9WsWI9yRdEcc75nu31g5ZRgOze9NziBLz87svAanX2yNAOxBpvR+2IKcXbBCxBvpNzutb3Zu1cZ37BLYKva7xrz2wQRObXG2i4Dc7CDHFT29qaavZhKWk11vCOrDKqpt5vZB7YsJoptQH3m0kQArZZ47tH39N/EnF7cOPUCisGWertGjI5JIuToQxF1lb5HsqGR5q05q4tmBrybOQNtZOOo6x16ZRVbUyQ6C13ByFL7W/b8T/NDY7JAK2bfkz4YCsLU0PXwEnXcmxnua0wCY4n3BJJkZmHXAKboAyTTFsXdoEzETMeIokM81JLms5t/vcUvfZdi7k7OpC86qavgvtERVNPhliojn8vx0Iqaw==; 5:dgPHIUvXEhMsKwtWBp8ZK7AzMvzEo8LjVI0tBvJIYUGA4YIzeN2ktn9mEcS3htYW7Rsvno5mvMdcioQFyXOTKxydZqfmwgfJ6bD6hFSCECx0yaM4T73fhXrM00l08j6fU8m07j8vkt6QHrGqK/1OWYx6iRsAGqxhQl4fedzM6Uc=; 7:lnR0LAEzbikRXWrkUmMmf4Jj2ss+9Fr2ChHP/DvlgyflmYXGqZrwqnyt0/aWuIIdgOv9KwaXfB1KZKMgP95WQQlq4+kE5xyhuOU4bKNWDVFu2lr3/K/YWxHQ9F2mxSjONs7fyt0eH5woea2+aGLrOA==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: e6c3417d-3552-48bc-8686-08d6665ab20b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(4534185)(4627221)(201703031133081)(201702281549075)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:AM0PR07MB4723; 
x-ms-traffictypediagnostic: AM0PR07MB4723:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(3230021)(999002)(11241501185)(806100)(5005026)(6040522)(2401047)(8121501046)(3231475)(944501520)(52105112)(93006095)(93001095)(10201501046)(3002001)(6055026)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB4723; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4723; 
x-forefront-prvs: 0892FA9A88
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(376002)(346002)(136003)(396003)(52314003)(43544003)(189003)(199004)(478600001)(53936002)(14454004)(8676002)(105586002)(186003)(2906002)(74316002)(7696005)(33656002)(26005)(97736004)(9686003)(71200400001)(71190400001)(86362001)(236005)(2201001)(14444005)(256004)(68736007)(55016002)(11346002)(54896002)(6306002)(8936002)(476003)(6116002)(114624004)(110136005)(606006)(102836004)(3846002)(2501003)(53546011)(6506007)(966005)(66066001)(486006)(76176011)(9326002)(446003)(6246003)(229853002)(81166006)(81156014)(7520500002)(316002)(790700001)(106356001)(25786009)(5660300001)(99286004)(93886005)(7736002)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4723; H:AM0PR07MB5921.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 8/u5r0IZlOsK0QTEDLYqhuGFFgiCnwtTVoovzPwWoMJUfrselhY+QOAlK+/qcaCns8c53u0VHsruvB83iNMa59vgoaLqJHhX9J5yHgxbjCTYvh6Or+ydeLjl02ykNWfJLAEXJAcFmav7pSaEVaKpeVCLbSzKbyoJfD9sIfJ5kn3jg5NfcxEcrCqzXrAx/wPUH98zBa1TiVw8A9aVohoo64VIMC/I3vnDvDkdBlmxyo6Dqip7zZmhRcMnfzAvSF/drpMw0nYyqAJKvXfbEIRIulaJUFN6LECGFosGPKlreCRVzi/qjGEVRRczIFb9w0F6
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM0PR07MB5921ADC000E6FFF7E418F2EB91BF0AM0PR07MB5921eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e6c3417d-3552-48bc-8686-08d6665ab20b
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Dec 2018 09:08:23.8952 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4723
Archived-At: 
Subject: Re: [netmod] [Netconf] magic leaf 'type' in IETF interfaces
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Dec 2018 09:08:34 -0000

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

SGksDQoNCk9uIFdlZCwgRGVjIDE5LCAyMDE4IGF0IDY6MTYgQU0gTGFkaXNsYXYgTGhvdGthIDxs
aG90a2FAbmljLmN6PG1haWx0bzpsaG90a2FAbmljLmN6Pj4gd3JvdGU6DQpKYW4gTGluZGJsYWQg
PGphbmxAdGFpbC1mLmNvbTxtYWlsdG86amFubEB0YWlsLWYuY29tPj4gd3JpdGVzOg0KDQo+IEhp
LA0KPj4+IFdoaWxlIEkgYWdyZWUgd2l0aCBNYXJ0aW4sIGluIG91ciBzeXN0ZW1zIHdlIGhhdmUg
YSBudW1iZXIgb2YgcGxhY2VzLCB3aGVyZSB0aGUgc3lzdGVtIGRvZXMgY3JlYXRlIGNvbmZpZ3Vy
YXRpb24gaW4gcnVubmluZywgZHVlIHRvDQo+Pj4NCj4+PiBkaWZmZXJlbnQgbGV2ZWxzIG9mIGF1
dG9tYXRpb24gYW5kIGF1dG9ub21vdXMgYWxnb3JpdGhtcyBraWNrLWluDQo+Pj4gdGhlIGNyZWF0
ZWQgY29uZmlnIG5lZWRzIHRvIGJlIHBvc3NpYmxlIHRvIGJlIGZ1cnRoZXIgbW9kaWZpZWQgYnkg
dGhlIG9wZXJhdG9yDQo+Pj4gdGhlIGNyZWF0ZWQgY29uZmlnIG5lZWRzIHRvIGJlIHJlZmVyZW5j
ZWQgZnJvbSBvcGVyYXRvciBjcmVhdGVkIGNvbmZpZw0KPj4+IHRoZSBjcmVhdGVkIGNvbmZpZyBp
cyBub3QgYWx3YXlzIGVwaGVtZXJhbCwgaXQgbWlnaHQgbmVlZCB0byBiZSBwYXJ0IG9mIGJhY2t1
cC9yZXN0b3JlDQo+PiBUaGlzIGlzIG9ubHkgYSBzYW1wbGluZyBmcm9tICJ0aGUgbGlzdCBvZiBl
eGN1c2VzIi4gSSBoYXZlIGhlYXJkIG1hbnkgbW9yZS4gVGhlIHJvYWQgdG8gaGVsbCBpcyBwYXZl
ZCB3aXRoIGdvb2QgaW50ZW50aW9ucywgaG93ZXZlci4uIElmIHdlIHdhbnQgdG8gYnVpbGQgYXV0
b21hdGlvbiBiYXNlZCBvbiBzb3VuZCB0aGVvcnksIGNsZWFybHkgc2VwYXJhdGluZyB0aGUgb3Jk
ZXJzIGZyb20gbWFuYWdlcnMgZnJvbSBhIHN5c3RlbSdzIG93biBvcGVyYXRpb25hbCB2aWV3IGlz
IGtleSwgSU1PLiBSZWxpYWJpbGl0eSwgc2VjdXJpdHksIGFjY291bnRhYmlsaXR5IGFyZSBncm93
aW5nIGluIGltcG9ydGFuY2UsIGFuZCB0aGV5IGFsbCBwbGF5IGluIHRoaXMgZGlyZWN0aW9uLg0K
Pj4NCj4+IFdlIG1heSBub3QgbmVlZCB0byBzdGFuZGFyZGl6ZSBydWxlcyB0byBvdXRsYXcgdGhl
IGFib3ZlOyB0aGUgbWFya2V0IHdpbGwgdGFrZSBjYXJlIG9mIHRoYXQuIFdoYXQgd2UgbmVlZCB0
byBlbnN1cmUgaXMgdGhhdCBpdCBpcyBwb3NzaWJsZSB0byBiZSBzdGFuZGFyZHMgY29tcGxpYW50
IHdpdGhvdXQgaGF2aW5nIHRvIGltcGxlbWVudCBkZXNpZ24gZXhjdXNlcyBsaWtlIHRoZXNlLg0K
Pj4NCj4+DQo+PiBOTURBIGhhcyBhIGxvdCBvZiByb29tIGZvciBwcm9wcmlldGFyeSBtZWNoYW5p
c21zIGZvciBjb252ZXJ0aW5nIDxydW5uaW5nPiB0byA8aW50ZW5kZWQ+Lg0KPj4gTWFueSB0aW1l
cyB0aGUgZmVhdHVyZXMgZGVzaXJlZCBieSBlbmdpbmVlcnMgZXhjZWVkIHRoZSBjYXBhYmlsaXRp
ZXMgb2YgWUFORywgc3VjaCBhcw0KPj4gYSBkeW5hbWljIGRlZmF1bHQgbGVhZi4gIFlBTkcgYWxs
b3dzIGEgc2ltcGxlIGNvbnN0YW50LCBhbmQgbm8gYnVzaW5lc3MgbG9naWMgdG8gcGljayB0aGUg
ZGVmYXVsdC4NCj4+IFRoaXMgaXMgYSB2ZXJ5IHZhbGlkIHVzZSBvZiAic2VydmVyIGF1dG8tbWFn
aWMiLg0KPj4NCj4+IE1heWJlIGEgZnV0dXJlIHZlcnNpb24gb2YgWUFORyBjYW4gaW1wcm92ZSB0
aGUgY2xpZW50IHZpc2liaWxpdHkgaW50byB0aGlzICJhdXRvLW1hZ2ljIg0KPg0KPiBBcyB5b3Ug
c2F5LCB0aGlzIGlzIG5vdCB1bmNvbW1vbi4gSSB1c3VhbGx5IHJlY29tbWVuZCB0byBsZWF2ZSBv
dXQgYW55DQo+IGRlZmF1bHQgc3RhdGVtZW50LCBhbmQgd3JpdGUgaW4gdGhlIGRlc2NyaXB0aW9u
IHdoYXQgaGFwcGVucyBpZiB0aGlzDQo+IGxlYWYgaXNuJ3Qgc2V0LiBUaGUgb3BlcmF0b3IgY2Fu
IHRoZW4gb3ZlcnJpZGUgdGhlIGRlZmF1bHQgYnkgZ2l2aW5nIGENCj4gdmFsdWUuDQoNCkFueXdh
eSwgdGhpcyBpcyBub3QgYSBjYXNlIHdoZXJlIHRoZSBzZXJ2ZXIgd3JpdGVzIHNvbWV0aGluZyBv
biBpdHMgb3duDQp0byBhIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlLg0KDQoNCkkgZG9uJ3QgdGhp
bmsgaXQgaXMgYSBwcm9ibGVtIGlmIE5NREEgb3Igbm9uLU5NREEgc2VydmVycyB3cml0ZSB0byA8
cnVubmluZz4uDQpKdXN0IHBhcnQgb2YgdGhlIGNvbXBsZXhpdHkgdGhhdCBpcyBiYWtlZCBpbiAt
LSBOTURBIGRvZXMgbm90aGluZyB0byBoZWxwIHRoZSBjbGllbnQga25vdw0Kd2h5IDxydW5uaW5n
PiBpcyBkaWZmZXJlbnQgdGhhbiA8aW50ZW5kZWQ+IGFueXdheS4NCg0KU0I+PiBCdXQgUkZDIDgz
NDIgc2F5cyA6DQoNCuKAnEl0IHJlcHJlc2VudHMgdGhlIGNvbmZpZ3VyYXRpb24gYWZ0ZXIgYWxs
IGNvbmZpZ3VyYXRpb24gdHJhbnNmb3JtYXRpb25zIHRvIDxydW5uaW5nPiBhcmUgcGVyZm9ybWVk
IChlLmcuLHRlbXBsYXRlIGV4cGFuc2lvbiwgcmVtb3ZhbCBvZiBpbmFjdGl2ZSBjb25maWd1cmF0
aW9uKeKAnQ0KDQoNClNvIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBieSBkZWZpbml0aW9uIOKA
nGludGVuZGVk4oCdIGNhbiBiZSBkaWZmZXJlbnQgZnJvbSDigJxydW5uaW5n4oCdLg0KQW0gSSBt
aXNzZWQgc29tZXRoaW5nPw0KDQoNCj4NCj4gV2hpbGUgc29tZSBtb3JlIGFkdmFuY2VkIGZlYXR1
cmVzIGZvciBkZWZhdWx0IHZhbHVlcyBtYXkgYmUgb2Ygc29tZQ0KPiB1dGlsaXR5LCB0aGUgc2lt
cGxpY2l0eSBvZiBZQU5HIGlzIGFsc28gaW1wb3J0YW50LiBXZSBkb24ndCB3YW50IHRvDQo+IG1h
a2UgdGhlIFlBTkcgbW9kZWxzIC0tIHRoZSBpbnRlcmZhY2UgY29udHJhY3RzIC0tIHRoZSBuZXcg
cGxhY2UgZm9yDQo+IGFsbCBidXNpbmVzcyBsb2dpYy4NCg0KQWJzb2x1dGVseS4NCg0KSSBhbSBu
b3QgcHJvcG9zaW5nIFlBTkcgbmVlZHMgYSBuZXcgZGVmYXVsdC1zdG10LiBUaGVyZSBpcyBhIGRl
c2NyaXB0aW9uLXN0bXQNCmFuZCB2ZW5kb3JzIGNhbiBhZGQgdGhlaXIgb3duIGV4dGVuc2lvbnMg
dG8gZmxhZyBhdXRvLW1hZ2ljIGRhdGEgbm9kZXMuDQoNCkxhZGENCg0KPg0KPiAvamFuDQoNCg0K
QW5keQ0KDQpUaGFua3MNClNlcmdpbw0KDQpTZXJnaW8gQmVsb3R0aQ0KU2VuaW9yIFN5c3RlbSBF
bmdpbmVlciBhbmQgU3RhbmRhcmRpemF0aW9uIEFyY2hpdGVjdA0KSVAvT3B0aWNhbCBOZXR3b3Jr
cywgT3B0aWNzIEJVDQpOb2tpYQ0KTTogKzM5LTMzNTc2MTc3Ng0KVmlhIEVuZXJneSBQYXJrLCAy
MDg3MSBWaW1lcmNhdGUgKE1CKSAsIEl0YWx5DQpzZXJnaW8uYmVsb3R0aUBub2tpYS5jb208bWFp
bHRvOnNlcmdpby5iZWxvdHRpQG5va2lhLmNvbT4NCg0KDQoNCj4NCj4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0K
PiBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KLS0NCkxhZGlzbGF2IExob3RrYQ0K
SGVhZCwgQ1ouTklDIExhYnMNClBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx
IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp
c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxh
aW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow
Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1m
YW1pbHk6Q29uc29sYXM7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9y
bWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1
dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt
YXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz
b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3
aW5kb3d0ZXh0O30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4g
VGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBs
YWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z
by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl
cmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn
aW46NzAuODVwdCAyLjBjbSAyLjBjbSAyLjBjbTt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6
V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k
aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp
dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48
L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl
IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBEZWMgMTksIDIwMTggYXQgNjoxNiBBTSBMYWRpc2xh
diBMaG90a2EgJmx0OzxhIGhyZWY9Im1haWx0bzpsaG90a2FAbmljLmN6Ij5saG90a2FAbmljLmN6
PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt
IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5KYW4gTGluZGJsYWQgJmx0OzxhIGhyZWY9Im1haWx0bzpqYW5sQHRh
aWwtZi5jb20iIHRhcmdldD0iX2JsYW5rIj5qYW5sQHRhaWwtZi5jb208L2E+Jmd0OyB3cml0ZXM6
PGJyPg0KPGJyPg0KJmd0OyBIaSw8YnI+DQomZ3Q7Jmd0OyZndDsgV2hpbGUgSSBhZ3JlZSB3aXRo
IE1hcnRpbiwgaW4gb3VyIHN5c3RlbXMgd2UgaGF2ZSBhIG51bWJlciBvZiBwbGFjZXMsIHdoZXJl
IHRoZSBzeXN0ZW0gZG9lcyBjcmVhdGUgY29uZmlndXJhdGlvbiBpbiBydW5uaW5nLCBkdWUgdG88
YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IGRpZmZlcmVudCBsZXZlbHMgb2Yg
YXV0b21hdGlvbiBhbmQgYXV0b25vbW91cyBhbGdvcml0aG1zIGtpY2staW48YnI+DQomZ3Q7Jmd0
OyZndDsgdGhlIGNyZWF0ZWQgY29uZmlnIG5lZWRzIHRvIGJlIHBvc3NpYmxlIHRvIGJlIGZ1cnRo
ZXIgbW9kaWZpZWQgYnkgdGhlIG9wZXJhdG9yPGJyPg0KJmd0OyZndDsmZ3Q7IHRoZSBjcmVhdGVk
IGNvbmZpZyBuZWVkcyB0byBiZSByZWZlcmVuY2VkIGZyb20gb3BlcmF0b3IgY3JlYXRlZCBjb25m
aWc8YnI+DQomZ3Q7Jmd0OyZndDsgdGhlIGNyZWF0ZWQgY29uZmlnIGlzIG5vdCBhbHdheXMgZXBo
ZW1lcmFsLCBpdCBtaWdodCBuZWVkIHRvIGJlIHBhcnQgb2YgYmFja3VwL3Jlc3RvcmU8YnI+DQom
Z3Q7Jmd0OyBUaGlzIGlzIG9ubHkgYSBzYW1wbGluZyBmcm9tICZxdW90O3RoZSBsaXN0IG9mIGV4
Y3VzZXMmcXVvdDsuIEkgaGF2ZSBoZWFyZCBtYW55IG1vcmUuIFRoZSByb2FkIHRvIGhlbGwgaXMg
cGF2ZWQgd2l0aCBnb29kIGludGVudGlvbnMsIGhvd2V2ZXIuLiBJZiB3ZSB3YW50IHRvIGJ1aWxk
IGF1dG9tYXRpb24gYmFzZWQgb24gc291bmQgdGhlb3J5LCBjbGVhcmx5IHNlcGFyYXRpbmcgdGhl
IG9yZGVycyBmcm9tIG1hbmFnZXJzIGZyb20gYSBzeXN0ZW0ncyBvd24gb3BlcmF0aW9uYWwNCiB2
aWV3IGlzIGtleSwgSU1PLiBSZWxpYWJpbGl0eSwgc2VjdXJpdHksIGFjY291bnRhYmlsaXR5IGFy
ZSBncm93aW5nIGluIGltcG9ydGFuY2UsIGFuZCB0aGV5IGFsbCBwbGF5IGluIHRoaXMgZGlyZWN0
aW9uLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IFdlIG1heSBub3QgbmVlZCB0byBzdGFu
ZGFyZGl6ZSBydWxlcyB0byBvdXRsYXcgdGhlIGFib3ZlOyB0aGUgbWFya2V0IHdpbGwgdGFrZSBj
YXJlIG9mIHRoYXQuIFdoYXQgd2UgbmVlZCB0byBlbnN1cmUgaXMgdGhhdCBpdCBpcyBwb3NzaWJs
ZSB0byBiZSBzdGFuZGFyZHMgY29tcGxpYW50IHdpdGhvdXQgaGF2aW5nIHRvIGltcGxlbWVudCBk
ZXNpZ24gZXhjdXNlcyBsaWtlIHRoZXNlLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDxi
cj4NCiZndDsmZ3Q7IE5NREEgaGFzIGEgbG90IG9mIHJvb20gZm9yIHByb3ByaWV0YXJ5IG1lY2hh
bmlzbXMgZm9yIGNvbnZlcnRpbmcgJmx0O3J1bm5pbmcmZ3Q7IHRvICZsdDtpbnRlbmRlZCZndDsu
PGJyPg0KJmd0OyZndDsgTWFueSB0aW1lcyB0aGUgZmVhdHVyZXMgZGVzaXJlZCBieSBlbmdpbmVl
cnMgZXhjZWVkIHRoZSBjYXBhYmlsaXRpZXMgb2YgWUFORywgc3VjaCBhczxicj4NCiZndDsmZ3Q7
IGEgZHluYW1pYyBkZWZhdWx0IGxlYWYuJm5ic3A7IFlBTkcgYWxsb3dzIGEgc2ltcGxlIGNvbnN0
YW50LCBhbmQgbm8gYnVzaW5lc3MgbG9naWMgdG8gcGljayB0aGUgZGVmYXVsdC48YnI+DQomZ3Q7
Jmd0OyBUaGlzIGlzIGEgdmVyeSB2YWxpZCB1c2Ugb2YgJnF1b3Q7c2VydmVyIGF1dG8tbWFnaWMm
cXVvdDsuPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgTWF5YmUgYSBmdXR1cmUgdmVyc2lv
biBvZiBZQU5HIGNhbiBpbXByb3ZlIHRoZSBjbGllbnQgdmlzaWJpbGl0eSBpbnRvIHRoaXMgJnF1
b3Q7YXV0by1tYWdpYyZxdW90Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEFzIHlvdSBzYXksIHRoaXMg
aXMgbm90IHVuY29tbW9uLiBJIHVzdWFsbHkgcmVjb21tZW5kIHRvIGxlYXZlIG91dCBhbnk8YnI+
DQomZ3Q7IGRlZmF1bHQgc3RhdGVtZW50LCBhbmQgd3JpdGUgaW4gdGhlIGRlc2NyaXB0aW9uIHdo
YXQgaGFwcGVucyBpZiB0aGlzPGJyPg0KJmd0OyBsZWFmIGlzbid0IHNldC4gVGhlIG9wZXJhdG9y
IGNhbiB0aGVuIG92ZXJyaWRlIHRoZSBkZWZhdWx0IGJ5IGdpdmluZyBhPGJyPg0KJmd0OyB2YWx1
ZS48YnI+DQo8YnI+DQpBbnl3YXksIHRoaXMgaXMgbm90IGEgY2FzZSB3aGVyZSB0aGUgc2VydmVy
IHdyaXRlcyBzb21ldGhpbmcgb24gaXRzIG93bjxicj4NCnRvIGEgY29uZmlndXJhdGlvbiBkYXRh
c3RvcmUuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkkgZG9uJ3QgdGhpbmsgaXQgaXMgYSBwcm9ibGVtIGlmIE5NREEgb3Igbm9u
LU5NREEgc2VydmVycyB3cml0ZSB0byAmbHQ7cnVubmluZyZndDsuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0IHBhcnQgb2YgdGhlIGNvbXBs
ZXhpdHkgdGhhdCBpcyBiYWtlZCBpbiAtLSBOTURBIGRvZXMgbm90aGluZyB0byBoZWxwIHRoZSBj
bGllbnQga25vdzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+d2h5ICZsdDtydW5uaW5nJmd0OyBpcyBkaWZmZXJlbnQgdGhhbiAmbHQ7aW50ZW5kZWQm
Z3Q7IGFueXdheS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U0ImZ3Q7Jmd0OyBCdXQgUkZDIDgz
NDIgc2F5cyA6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7igJw8L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5JdCBy
ZXByZXNlbnRzIHRoZSBjb25maWd1cmF0aW9uIGFmdGVyIGFsbCBjb25maWd1cmF0aW9uIHRyYW5z
Zm9ybWF0aW9ucyB0byAmbHQ7cnVubmluZyZndDsgYXJlIHBlcmZvcm1lZCAoZS5nLix0ZW1wbGF0
ZSBleHBhbnNpb24sIHJlbW92YWwgb2YgaW5hY3RpdmUNCiBjb25maWd1cmF0aW9uKeKAnTxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0
IGJ5IGRlZmluaXRpb24g4oCcaW50ZW5kZWTigJ0gY2FuIGJlIGRpZmZlcmVudCBmcm9tIOKAnHJ1
bm5pbmfigJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbSBJIG1pc3Nl
ZCBzb21ldGhpbmc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9
ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g
MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KJmd0Ozxi
cj4NCiZndDsgV2hpbGUgc29tZSBtb3JlIGFkdmFuY2VkIGZlYXR1cmVzIGZvciBkZWZhdWx0IHZh
bHVlcyBtYXkgYmUgb2Ygc29tZTxicj4NCiZndDsgdXRpbGl0eSwgdGhlIHNpbXBsaWNpdHkgb2Yg
WUFORyBpcyBhbHNvIGltcG9ydGFudC4gV2UgZG9uJ3Qgd2FudCB0bzxicj4NCiZndDsgbWFrZSB0
aGUgWUFORyBtb2RlbHMgLS0gdGhlIGludGVyZmFjZSBjb250cmFjdHMgLS0gdGhlIG5ldyBwbGFj
ZSBmb3I8YnI+DQomZ3Q7IGFsbCBidXNpbmVzcyBsb2dpYy48YnI+DQo8YnI+DQpBYnNvbHV0ZWx5
LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+SSBhbSBub3QgcHJvcG9zaW5nIFlBTkcgbmVlZHMgYSBuZXcgZGVmYXVsdC1zdG10LiBU
aGVyZSBpcyBhIGRlc2NyaXB0aW9uLXN0bXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCB2ZW5kb3JzIGNhbiBhZGQgdGhlaXIgb3duIGV4dGVu
c2lvbnMgdG8gZmxhZyBhdXRvLW1hZ2ljIGRhdGEgbm9kZXMuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND
Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt
YXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxhZGE8YnI+DQo8YnI+DQom
Z3Q7PGJyPg0KJmd0OyAvamFuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+VGhhbmtzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T
ZXJnaW88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IklU
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iY29sb3I6IzdGN0Y3RiI+U2VyZ2lvIEJlbG90dGk8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzdGN0Y3RiI+U2Vu
aW9yIFN5c3RlbSBFbmdpbmVlciBhbmQgU3RhbmRhcmRpemF0aW9uIEFyY2hpdGVjdDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj
N0Y3RjdGIj5JUC9PcHRpY2FsIE5ldHdvcmtzLCBPcHRpY3MgQlU8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzdGN0Y3RiI+Tm9r
aWEgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJJVCIg
c3R5bGU9ImNvbG9yOiM3RjdGN0YiPk06ICYjNDM7MzktMzM1NzYxNzc2PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iSVQiIHN0eWxlPSJjb2xv
cjojN0Y3RjdGIj5WaWEgRW5lcmd5IFBhcmssIDIwODcxIFZpbWVyY2F0ZSAoTUIpICwgSXRhbHk8
L3NwYW4+PHNwYW4gbGFuZz0iSVQiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr
Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJJVCI+PGEgaHJlZj0ibWFpbHRvOnNlcmdpby5iZWxvdHRpQG5va2lhLmNvbSI+PHNwYW4gc3R5
bGU9ImNvbG9yOiMwNTYzQzEiPnNlcmdpby5iZWxvdHRpQG5va2lhLmNvbTwvc3Bhbj48L2E+PG86
cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxi
bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu
MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp
Z2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgbmV0bW9kIG1h
aWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgdGFy
Z2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9ibGFuayI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJyPg0KPGJy
Pg0KLS0gPGJyPg0KTGFkaXNsYXYgTGhvdGthPGJyPg0KSGVhZCwgQ1ouTklDIExhYnM8YnI+DQpQ
R1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjc8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90
ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_AM0PR07MB5921ADC000E6FFF7E418F2EB91BF0AM0PR07MB5921eurp_--


From nobody Thu Dec 20 07:32:02 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BF9130E62 for ; Thu, 20 Dec 2018 07:31:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUnyam6-0ySF for ; Thu, 20 Dec 2018 07:31:57 -0800 (PST)
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 8E5CE130E3F for ; Thu, 20 Dec 2018 07:31:56 -0800 (PST)
Received: by mail-lf1-x131.google.com with SMTP id c16so1670316lfj.8 for ; Thu, 20 Dec 2018 07:31:56 -0800 (PST)
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=QDmQtxL+wAcIUnogEBkWKHcg4gZhiZ2SXcVPm0wz++M=; b=tBjfq2GrEFlOcFzz5EQIOseWMaqm1Jg6RtzitmMHRefq2vDyqnj/Hi55fZF0txHq5d F8yr80tqD1j70Amyeoj3VIIbeGD7Mcuv6Lnvt5Ztv9q6+Hsix+16xCsOYWG+kJCoC9xl lh4iq9q5dKHBqppQvCWNpKGbWgpakgHK/cwcbTQn73YacqWLBVCPxmL5DOoWrXbRgXej p9X82BAzMRxAtD/a/UKg/vsm53mMoi7Qpg04iiwlb56SRF3V0xnfxGP4oxCAeniRQ9Oy U2f0MNzj0iZrUUv1bguCYAEb/8yS03yW+7jVzizf4OGZm4Ed65ouIwVphXCwqXrrx3LI UDWw==
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=QDmQtxL+wAcIUnogEBkWKHcg4gZhiZ2SXcVPm0wz++M=; b=Mx3GSbusw+qd9AMk6UIRB1pW9pkYp7fUAwPcsNzF57ZvMSKrfb0h0Lz6PObNQM4913 LQkK5LKfLcPdYpkYP/sKYTmlqIJbp8yhaMgw9iA24x5MpbUetbsNS3doHuok/mtbN1XY Af4y7JAe1/AbmeAu9rmygASghxYKxh+Vlxz2LXMVFzb5HQmaw5BDCzxpNXfQlHQMgbzQ EOpXPigy1JYZ7bKg/5s05A+efe3NSULU9PR0j8sRBIJ2p6mP7frGDSrhQQ4qR1j7aTCH EL34dw65CUqDiGT+i1xRhP48pj7VbLCeVSxXPDCo+qGp9yw0XHcsc5ai4kBL2aafAtDh CXYw==
X-Gm-Message-State: AA+aEWY1RF8FoL4IzWtcDtomYFilGczbcEtj6D6u0kKDSnNFFT+ke063 ga43QcNuMqncJfY4kWHlOxaYw6jts0rztNtEQURpjA==
X-Google-Smtp-Source: AFSGD/WWUWpj2OGUucdWctEl7S75C0nVpFzpxtDZTnbYoPAGhBlEvqc0IP8xY2IlrwzEmDkBG1Hfw8dn9+zEBInqzHQ=
X-Received: by 2002:a19:ca51:: with SMTP id h17mr14620521lfj.126.1545319914658;  Thu, 20 Dec 2018 07:31:54 -0800 (PST)
MIME-Version: 1.0
References:  <20181217.091505.218628572185200621.mbj@tail-f.com> <83b139a1-a0ab-5fbc-f702-7f0d50a46864@ericsson.com> <90DB3C3B-FD52-4903-81B0-93985E6F74FE@tail-f.com>  <6912DD4C-4C4E-45E8-9F0E-D8D8139F83AE@tail-f.com> <875zvpeh5h.fsf@nic.cz>  
In-Reply-To: 
From: Andy Bierman 
Date: Thu, 20 Dec 2018 07:31:43 -0800
Message-ID: 
To: "Belotti, Sergio (Nokia - IT/Vimercate)" 
Cc: Jan Lindblad , "netconf@ietf.org" ,  "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="00000000000093f452057d75d4b3"
Archived-At: 
Subject: Re: [netmod] [Netconf] magic leaf 'type' in IETF interfaces
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Dec 2018 15:32:00 -0000

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

On Thu, Dec 20, 2018 at 1:08 AM Belotti, Sergio (Nokia - IT/Vimercate) <
sergio.belotti@nokia.com> wrote:

> Hi,
>
>
>
> On Wed, Dec 19, 2018 at 6:16 AM Ladislav Lhotka  wrote:
>
> Jan Lindblad  writes:
>
> > Hi,
> >>> While I agree with Martin, in our systems we have a number of places,
> where the system does create configuration in running, due to
> >>>
> >>> different levels of automation and autonomous algorithms kick-in
> >>> the created config needs to be possible to be further modified by the
> operator
> >>> the created config needs to be referenced from operator created confi=
g
> >>> the created config is not always ephemeral, it might need to be part
> of backup/restore
> >> This is only a sampling from "the list of excuses". I have heard many
> more. The road to hell is paved with good intentions, however.. If we wan=
t
> to build automation based on sound theory, clearly separating the orders
> from managers from a system's own operational view is key, IMO.
> Reliability, security, accountability are growing in importance, and they
> all play in this direction.
> >>
> >> We may not need to standardize rules to outlaw the above; the market
> will take care of that. What we need to ensure is that it is possible to =
be
> standards compliant without having to implement design excuses like these=
.
> >>
> >>
> >> NMDA has a lot of room for proprietary mechanisms for converting
>  to .
> >> Many times the features desired by engineers exceed the capabilities o=
f
> YANG, such as
> >> a dynamic default leaf.  YANG allows a simple constant, and no busines=
s
> logic to pick the default.
> >> This is a very valid use of "server auto-magic".
> >>
> >> Maybe a future version of YANG can improve the client visibility into
> this "auto-magic"
> >
> > As you say, this is not uncommon. I usually recommend to leave out any
> > default statement, and write in the description what happens if this
> > leaf isn't set. The operator can then override the default by giving a
> > value.
>
> Anyway, this is not a case where the server writes something on its own
> to a configuration datastore.
>
>
>
>
>
> I don't think it is a problem if NMDA or non-NMDA servers write to
> .
>
> Just part of the complexity that is baked in -- NMDA does nothing to help
> the client know
>
> why  is different than  anyway.
>
>
>
> SB>> But RFC 8342 says :
>
> =E2=80=9CIt represents the configuration after all configuration transfor=
mations
> to  are performed (e.g.,template expansion, removal of inactive
> configuration)=E2=80=9D
>
>
>
> So my understanding is that by definition =E2=80=9Cintended=E2=80=9D can =
be different from
> =E2=80=9Crunning=E2=80=9D.
>
> Am I missed something?
>
>
>


The client can see WHAT changed because of server-auto-magic but not WHY
a particular server implementation converts  into  if  is
edited.
A client (using plain YANG) cannot predict at all what will happen if 
is edited.

The issue remains: how does a client know that a mandatory leaf is not
actually required in ?  I guess vague auto-magic description-text
is good enough


Andy


> >
> > While some more advanced features for default values may be of some
> > utility, the simplicity of YANG is also important. We don't want to
> > make the YANG models -- the interface contracts -- the new place for
> > all business logic.
>
> Absolutely.
>
>
>
> I am not proposing YANG needs a new default-stmt. There is a
> description-stmt
>
> and vendors can add their own extensions to flag auto-magic data nodes.
>
>
>
> Lada
>
> >
> > /jan
>
>
>
>
>
> Andy
>
>
>
> Thanks
>
> Sergio
>
>
>
> Sergio Belotti
>
> Senior System Engineer and Standardization Architect
>
> IP/Optical Networks, Optics BU
>
> Nokia
>
> M: +39-335761776
>
> Via Energy Park, 20871 Vimercate (MB) , Italy
>
> sergio.belotti@nokia.com
>
>
>
>
>
>
>
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
>

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




=

On Thu, Dec 20, 2018 at 1:08 AM Belotti, Sergio (Nokia - I=
T/Vimercate) <sergio.belotti=
@nokia.com> wrote:















Hi,




=C2=A0






On Wed, Dec 19, 2018 at 6:16 AM Ladislav Lhotka <=
lhotka@nic.cz> wr=
ote:






Jan Lindblad <janl@tail-f.com> writes:



> Hi,

>>> While I agree with Martin, in our systems we have a number of =
places, where the system does create configuration in running, due to

>>> 

>>> different levels of automation and autonomous algorithms kick-=
in

>>> the created config needs to be possible to be further modified=
 by the operator

>>> the created config needs to be referenced from operator create=
d config

>>> the created config is not always ephemeral, it might need to b=
e part of backup/restore

>> This is only a sampling from "the list of excuses". I ha=
ve heard many more. The road to hell is paved with good intentions, however=
.. If we want to build automation based on sound theory, clearly separating=
 the orders from managers from a system's own operational
 view is key, IMO. Reliability, security, accountability are growing in imp=
ortance, and they all play in this direction.

>> 

>> We may not need to standardize rules to outlaw the above; the mark=
et will take care of that. What we need to ensure is that it is possible to=
 be standards compliant without having to implement design excuses like the=
se.

>> 

>> 

>> NMDA has a lot of room for proprietary mechanisms for converting &=
lt;running> to <intended>.

>> Many times the features desired by engineers exceed the capabiliti=
es of YANG, such as

>> a dynamic default leaf.=C2=A0 YANG allows a simple constant, and n=
o business logic to pick the default.

>> This is a very valid use of "server auto-magic".

>> 

>> Maybe a future version of YANG can improve the client visibility i=
nto this "auto-magic"

>

> As you say, this is not uncommon. I usually recommend to leave out any=


> default statement, and write in the description what happens if this
> leaf isn't set. The operator can then override the default by givi=
ng a

> value.



Anyway, this is not a case where the server writes something on its own

to a configuration datastore.






=C2=A0






=C2=A0






I don't think it is a problem if NMDA or non-NMD=
A servers write to <running>.






Just part of the complexity that is baked in -- NMDA=
 does nothing to help the client know






why <running> is different than <intended&g=
t; anyway.


=C2=A0


SB>> But RFC 8342 says :


=E2=80=9CIt represents the configuration after all configuration =
transformations to <running> are performed (e.g.,template expansion, =
removal of inactive
 configuration)=E2=80=9D


=C2=A0


So my understanding is that by definition =E2=80=9Ci=
ntended=E2=80=9D can be different from =E2=80=9Crunning=E2=80=9D.=



Am I missed something?






=C2=A0


The client can see WHAT changed because=
 of server-auto-magic but not WHY
a particular server implementat=
ion converts <foo> into <bar> if <foo> is edited.
A client (using plain YANG) cannot predict at all what will happen if &l=
t;foo> is edited.

The issue remains: how does a=
 client know that a mandatory leaf is not
actually required in &l=
t;running>?=C2=A0 I guess vague auto-magic description-text is good enou=
gh


Andy









>

> While some more advanced features for default values may be of some
> utility, the simplicity of YANG is also important. We don't want t=
o

> make the YANG models -- the interface contracts -- the new place for
> all business logic.



Absolutely.






=C2=A0






I am not proposing YANG needs a new default-stmt. Th=
ere is a description-stmt






and vendors can add their own extensions to flag aut=
o-magic data nodes.






=C2=A0






Lada



>

> /jan






=C2=A0






=C2=A0






Andy






=C2=A0


Thanks


Sergio


=C2=A0


Sergio Belott=
i


Senior System=
 Engineer and Standardization Architect


IP/Optical Ne=
tworks, Optics BU


Nokia =



M=
: +39-335761776


V=
ia Energy Park, 20871 Vimercate (MB) , Italy


sergio.belo=
tti@nokia.com




=C2=A0


=C2=A0


=C2=A0






>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

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



-- 

Ladislav Lhotka

Head, CZ.NIC Labs

PGP Key ID: 0xB8F92B08A9F76C67













--00000000000093f452057d75d4b3--


From nobody Thu Dec 20 09:44:43 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7E6131165 for ; Thu, 20 Dec 2018 09:44:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5P_TuWEXIZM for ; Thu, 20 Dec 2018 09:44:40 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2382F13115E for ; Thu, 20 Dec 2018 09:44:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4724; q=dns/txt; s=iport; t=1545327880; x=1546537480; h=from:subject:to:message-id:date:mime-version; bh=B6HOq9kHRJdtZau4vPqP5p06dqbF6xgpJVvEYLOqFuA=; b=bpyFhGOpezBVscycvQRr0MKkOLNzpxbHbo+lSEIjVtNFS0VNdU/Dtj0K 4HXdkob5ATT9nnf+e6kxj6HFiAaUchLpJpFffIcDh8rWyYswY6Nx3pVXy URPQhwm8KZBKJ48LN+eOO+UaRcOQGOoFcNDKfm52eiBjkuMMcnOvZARI6 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAABo1Btc/xbLJq1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBUwUBAQsBgQ2BXIEChCSIeIx8CJInhVuBew0jh1k2Bw0BAwEBAgEBAm0?= =?us-ascii?q?cAQuFZnU+Al8NCAEBF4MHAYIBD5hZjnSBLx+EIkA/hGEFjFaBQD+BOAyFfQI?= =?us-ascii?q?DAYFHgx6CVwKJd5dGCYcRik4GGIoJh1SJTYR7hEeGfoFNAy4ogS4zGggbFYM?= =?us-ascii?q?oixuFPz8DjxcBAQ?=
X-IronPort-AV: E=Sophos;i="5.56,378,1539648000"; d="scan'208,217";a="8942786"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Dec 2018 17:44:37 +0000
Received: from [10.63.23.68] (dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com [10.63.23.68]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id wBKHibiY003228 for ; Thu, 20 Dec 2018 17:44:37 GMT
From: Robert Wilton 
To: "netmod@ietf.org" 
Message-ID: <38b2c418-d47d-0275-87b0-f5d004863dbe@cisco.com>
Date: Thu, 20 Dec 2018 17:44:37 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------EE2C0E20795031BAAA79A8DC"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.68, dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
Subject: [netmod] YANG Packages
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Dec 2018 17:44:43 -0000

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

Hi,

I've written up an ID for a potential solution for YANG packages using 
instance data:

Abstract

    This document defines YANG packages, an organizational structure
    holding a set of related YANG modules, that can be used to simplify
    the conformance and sharing of YANG schema.  It describes how YANG
    instance data documents are used to define YANG packages, and how the
    YANG library information published by a server can be augmented with
    additional packaging related information.

https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/

Potentially this work may be of use as part of the YANG versioning 
design team work.  In addition, if the WG likes this approach of 
defining YANG packages, then it might also be useful to bind a schema to 
a YANG instance data document.

Some questions for members of the WG:

1) Do members of the WG agree that YANG packages is something that needs 
to be solved?

2) Is the approach in this draft of defining these as instance data 
documents a good starting point?

3) This approach augments YANG library-bis, reusing module-sets, but not 
replacing the way that modules are reported in YANG library-bis.  Is 
this the right approach?  This approach tries to allow module-sets to be 
reused for both schema and packages, but the YANG library-bis rules for 
combining module-sets (i.e. no conflicts) may make this harder to really 
reuse the module-sets for both purposes.

Of course, any other comments or feedback is welcome and appreciated.

Thanks,
Rob


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


  

    
  
  
    
Hi,

    
I've written up an ID for a potential solution for YANG packages
      using instance data:

    
Abstract

   This document defines YANG packages, an organizational structure
   holding a set of related YANG modules, that can be used to simplify
   the conformance and sharing of YANG schema.  It describes how YANG
   instance data documents are used to define YANG packages, and how the
   YANG library information published by a server can be augmented with
   additional packaging related information.

    
https://datatracker.ietf.org/doc/draft-rwilton-netmod-yang-packages/

    
Potentially this work may be of use as part of the YANG
      versioning design team work.  In addition, if the WG likes this
      approach of defining YANG packages, then it might also be useful
      to bind a schema to a YANG instance data document.

    
Some questions for members of the WG:

      

      1) Do members of the WG agree that YANG packages is something that
      needs to be solved?

    
2) Is the approach in this draft of defining these as instance
      data documents a good starting point?

    

    
3) This approach augments YANG library-bis, reusing module-sets,
      but not replacing the way that modules are reported in YANG
      library-bis.  Is this the right approach?  This approach tries to
      allow module-sets to be reused for both schema and packages, but
      the YANG library-bis rules for combining module-sets (i.e. no
      conflicts) may make this harder to really reuse the module-sets
      for both purposes.

    
Of course, any other comments or feedback is welcome and
      appreciated.

    
Thanks,

      Rob

    

  


--------------EE2C0E20795031BAAA79A8DC--


From nobody Thu Dec 20 21:56:29 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34629127B4C for ; Thu, 20 Dec 2018 21:56:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqWRj_HEIuLZ for ; Thu, 20 Dec 2018 21:56:25 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36C6412D4E6 for ; Thu, 20 Dec 2018 21:56:24 -0800 (PST)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D76A78CCAA462 for ; Fri, 21 Dec 2018 05:56:19 +0000 (GMT)
Received: from DGGEML401-HUB.china.huawei.com (10.3.17.32) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 21 Dec 2018 05:56:20 +0000
Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.165]) by DGGEML401-HUB.china.huawei.com ([fe80::89ed:853e:30a9:2a79%31]) with mapi id 14.03.0415.000; Fri, 21 Dec 2018 13:56:08 +0800
From: Rohit R Ranade 
To: "netmod@ietf.org" 
Thread-Topic: Schema Mount with Inline Type
Thread-Index: AdSY8QlqYjMVcg7lQlazR9ZWHav3JQ==
Date: Fri, 21 Dec 2018 05:56:08 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCB50C7@dggeml530-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BCB50C7dggeml530mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod] Schema Mount with Inline Type
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Dec 2018 05:56:28 -0000

--_000_991B70D8B4112A4699D5C00DDBBF878A6BCB50C7dggeml530mbschi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

   module: ietf-yang-schema-mount
     +--ro schema-mounts
        +--ro namespace* [prefix]
        |  +--ro prefix    yang:yang-identifier
        |  +--ro uri?      inet:uri
        +--ro mount-point* [module label]
           +--ro module                 yang:yang-identifier
           +--ro label                  yang:yang-identifier
           +--ro config?                boolean
           +--ro (schema-ref)
              +--:(inline)
              |  +--ro inline!
              +--:(shared-schema)
                 +--ro shared-schema!
                    +--ro parent-reference*   yang:xpath1.0

Any reason for not adding "parent-reference" for "inline" type ? What is th=
e solution for the modules defined under such mount points to refer to pare=
nt schema ?

With Regards,
Rohit

--_000_991B70D8B4112A4699D5C00DDBBF878A6BCB50C7dggeml530mbschi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi All,


 


   module: ietf-yang-schema-mount


     +--ro schema-mou=
nts


        &#=
43;--ro namespace* [prefix]


        |&=
nbsp; +--ro prefix    yang:yang-identifier


        |&=
nbsp; +--ro uri?      inet:uri


        &#=
43;--ro mount-point* [module label]


       &nb=
sp;   +--ro module       &=
nbsp;         yang:yang-identifier<=
o:p>


       &nb=
sp;   +--ro label       &n=
bsp;          yang:yang-identi=
fier


       &nb=
sp;   +--ro config?       =
         boolean<=
/p>

       &nb=
sp;   +--ro (schema-ref)


       &nb=
sp;      +--:(inline)


       &nb=
sp;      |  +--ro inline!


       &nb=
sp;      +--:(shared-schema)=



       &nb=
sp;        
+--ro shared-schema!


     &=
nbsp;           &nbs=
p;  +--ro parent-reference*   yang:xpath1.0


 


Any reason for not adding ̶=
0;parent-reference” for “inline” type ? What is the solut=
ion for the modules defined under such mount points to refer to parent sche=
ma ?


 


With Regards,=



Rohit






--_000_991B70D8B4112A4699D5C00DDBBF878A6BCB50C7dggeml530mbschi_--


From nobody Fri Dec 21 04:01:26 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8780412F1A5 for ; Fri, 21 Dec 2018 04:01:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xt10ubNXtOSY for ; Fri, 21 Dec 2018 04:01:18 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778CA12426A for ; Fri, 21 Dec 2018 04:01:18 -0800 (PST)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 82DA2624146F2 for ; Fri, 21 Dec 2018 12:01:14 +0000 (GMT)
Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 21 Dec 2018 12:01:15 +0000
Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.165]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0415.000; Fri, 21 Dec 2018 20:01:05 +0800
From: Rohit R Ranade 
To: "netmod@ietf.org" 
Thread-Topic: Query about Schema Mount "config" leaf 
Thread-Index: AdSZJNrKetUdei18Txy6eo6+aYB1Qw==
Date: Fri, 21 Dec 2018 12:01:06 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCB5273@dggeml530-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BCB5273dggeml530mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod] Query about Schema Mount "config" 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, 21 Dec 2018 12:01:26 -0000

--_000_991B70D8B4112A4699D5C00DDBBF878A6BCB5273dggeml530mbschi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

        +--ro mount-point* [module label]
           +--ro module                 yang:yang-identifier
           +--ro label                  yang:yang-identifier
           +--ro config?                boolean


1.       When reading the schema mount draft it is not clear for which use-=
case, the "config" being false will be helpful for ?

2.       If there are modules with config true nodes mounted, how can the d=
ata-nodes of those mounted modules be instantiated if the config leaf is fa=
lse ?


With Regards,
Rohit

--_000_991B70D8B4112A4699D5C00DDBBF878A6BCB5273dggeml530mbschi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi All,


 


        &#=
43;--ro mount-point* [module label]


       &nb=
sp;   +--ro module       &=
nbsp;         yang:yang-identifier<=
o:p>


       &nb=
sp;   +--ro label       &n=
bsp;          yang:yang-identi=
fier


       &nb=
sp;   +--ro
config?          &=
nbsp;     boolean


 



1=
.   &=
nbsp;  
When reading the schema=
 mount draft it is not clear for which use-case, the “config” b=
eing false will be helpful for ?




2=
.   &=
nbsp;  
If there are modules wi=
th config true nodes mounted, how can the data-nodes of those mounted modul=
es be instantiated if the config leaf is false ?


 


 


With Regards,=



Rohit






--_000_991B70D8B4112A4699D5C00DDBBF878A6BCB5273dggeml530mbschi_--


From nobody Fri Dec 21 04:11:09 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EC9124408 for ; Fri, 21 Dec 2018 04:11:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.565
X-Spam-Level: 
X-Spam-Status: No, score=-14.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qlXoSjiWHev for ; Fri, 21 Dec 2018 04:11:06 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9D3D12426A for ; Fri, 21 Dec 2018 04:11:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10684; q=dns/txt; s=iport; t=1545394265; x=1546603865; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=6wAzdbbIdj0qVGopG/PoHI4bE2vkcIQXoSetntKAyQE=; b=cqGUlPplVm6d/xX4clQsCyf4hdjj6/E0TTfYEcBVOsidZSXKxmQ3H11c WFednWjOiTXMRQhKr/v7bUbBDgi+vy7HCL7ozmuTSAiVOGFeJ/HvMzLzB 3qYco+FFFzTxNDhviuUsDUyj7GrOCkGL3RmUMBt+2+dRPhb9+C99sJYl5 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAABO1xxc/xbLJq1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUgQBAQEBCwGBDYFccBInjHWMfS2SA4VcgXsNGAEKhANGAoM?= =?us-ascii?q?PNQgNAQMBAQIBAQJtHAyFSgEBAQMBAQErQRALCxguJzAGAQwGAgEBgx4BgXk?= =?us-ascii?q?ID6cuH4QiQD+EbwWMVoFAP4E4gmuDHgEBAwGHPAKhRQmHEopRBhiKC4dUiVO?= =?us-ascii?q?EfoRNhn6BRwE2gVYzGggbFTuCbIschT8/AzCPFgEB?=
X-IronPort-AV: E=Sophos;i="5.56,381,1539648000"; d="scan'208,217";a="8957511"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Dec 2018 12:11:03 +0000
Received: from [10.63.23.68] (dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com [10.63.23.68]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id wBLCB3eQ015861; Fri, 21 Dec 2018 12:11:03 GMT
To: Rohit R Ranade , "netmod@ietf.org" 
References: <991B70D8B4112A4699D5C00DDBBF878A6BCB5273@dggeml530-mbs.china.huawei.com>
From: Robert Wilton 
Message-ID: <192a21f4-19e1-e40c-ec3f-294e0d348168@cisco.com>
Date: Fri, 21 Dec 2018 12:11:03 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3
MIME-Version: 1.0
In-Reply-To: <991B70D8B4112A4699D5C00DDBBF878A6BCB5273@dggeml530-mbs.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------4FFF8F7DFEECB8593248C251"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.68, dhcp-ensft1-uk-vla370-10-63-23-68.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: 
Subject: Re: [netmod] Query about Schema Mount "config" 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, 21 Dec 2018 12:11:08 -0000

This is a multi-part message in MIME format.
--------------4FFF8F7DFEECB8593248C251
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Rohit,

Are you familiar with either of the LNE or NI model drafts?

https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/

https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/

I believe both of these drafts were driving some of the key schema mount 
requirements, and may provide useful examples of the use cases.

On 21/12/2018 12:01, Rohit R Ranade wrote:
>
> Hi All,
>
>  +--ro mount-point* [module label]
>
>  +--ro module yang:yang-identifier
>
>  +--ro label yang:yang-identifier
>
>  +--ro *config*? boolean
>
> 1..When reading the schema mount draft it is not clear for which 
> use-case, the config being false will be helpful for ?
>
Section 3 of the LNE draft writes about the use of this config leaf.


> 2..If there are modules with config true nodes mounted, how can the 
> data-nodes of those mounted modules be instantiated if the config leaf 
> is false ?
>
There will likely be separate direct YANG management protocol access to 
the mounted data (e.g. for a mounted LNE) that would allow the 
configuration to be manipulated.

Thanks,
Rob


> With Regards,
>
> Rohit
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--------------4FFF8F7DFEECB8593248C251
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Rohit,

    
Are you familiar with either of the LNE or NI model drafts?

    
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/

      

    
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/

    
I believe both of these drafts were driving some of the key
      schema mount requirements, and may provide useful examples of the
      use cases.

    

    
On 21/12/2018 12:01, Rohit R Ranade
      wrote:

    

    

      
      
      
      

        
Hi All,

        

        
 +--ro
            mount-point* [module label]

        
 +--ro
            module yang:yang-identifier

        
 +--ro
            label yang:yang-identifier

        
 +--ro
            config? boolean

        

        

          1..
              When
            reading the schema mount draft it is not clear for which
            use-case, the config being false will be helpful for ?
          

      

    

    
Section 3 of the LNE draft writes about the use of this config
      leaf.

    

    


    

    

      

        

        

          2..
              If
            there are modules with config true nodes mounted, how can
            the data-nodes of those mounted modules be instantiated if
            the config leaf is false ?

      

    

    
There will likely be separate direct YANG management protocol
      access to the mounted data (e.g. for a mounted LNE) that would
      allow the configuration to be manipulated. 

    

    
Thanks,

      Rob

    


    

    

      

        

        

        

        
With Regards,

        
Rohit

      

      

      

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


    

  


--------------4FFF8F7DFEECB8593248C251--


From nobody Sun Dec 23 19:30:03 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B39130E48 for ; Sun, 23 Dec 2018 19:30:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level: 
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdi8YOMYo2dk for ; Sun, 23 Dec 2018 19:29:59 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7475130E41 for ; Sun, 23 Dec 2018 19:29:58 -0800 (PST)
Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 8529936E78B90 for ; Mon, 24 Dec 2018 03:29:54 +0000 (GMT)
Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 24 Dec 2018 03:29:55 +0000
Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.165]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0415.000; Mon, 24 Dec 2018 11:29:46 +0800
From: Rohit R Ranade 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] Query about Schema Mount "config" leaf
Thread-Index: AQHUmSZI9xsGOHc4wkyG5lhHWgMji6WNPq1g
Date: Mon, 24 Dec 2018 03:29:45 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCB66F9@dggeml530-mbs.china.huawei.com>
References: <991B70D8B4112A4699D5C00DDBBF878A6BCB5273@dggeml530-mbs.china.huawei.com> <192a21f4-19e1-e40c-ec3f-294e0d348168@cisco.com>
In-Reply-To: <192a21f4-19e1-e40c-ec3f-294e0d348168@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BCB66F9dggeml530mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] Query about Schema Mount "config" 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: Mon, 24 Dec 2018 03:30:02 -0000

--_000_991B70D8B4112A4699D5C00DDBBF878A6BCB66F9dggeml530mbschi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

OK, got the reference.
I felt it would have been better to mention why this "config" leaf has been=
 defined in this draft by citing a reference to other drafts as has been do=
ne for the rest of the leaves.
As a reader, I was left wondering as to why there should be a leaf that ove=
r-rides the actual "config" true definition of the mounted models. If indee=
d the goal is to allow only "read" access why not use the NACM way for it ?

With Regards,
Rohit

From: Robert Wilton [mailto:rwilton@cisco.com]
Sent: 21 December 2018 17:41
To: Rohit R Ranade ; netmod@ietf.org
Subject: Re: [netmod] Query about Schema Mount "config" leaf


Hi Rohit,

Are you familiar with either of the LNE or NI model drafts?

https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne-model/

https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/

I believe both of these drafts were driving some of the key schema mount re=
quirements, and may provide useful examples of the use cases.
On 21/12/2018 12:01, Rohit R Ranade wrote:
Hi All,

        +--ro mount-point* [module label]
           +--ro module                 yang:yang-identifier
           +--ro label                  yang:yang-identifier
           +--ro config?                boolean


1.       When reading the schema mount draft it is not clear for which use-=
case, the "config" being false will be helpful for ?

Section 3 of the LNE draft writes about the use of this config leaf.



2.       If there are modules with config true nodes mounted, how can the d=
ata-nodes of those mounted modules be instantiated if the config leaf is fa=
lse ?

There will likely be separate direct YANG management protocol access to the=
 mounted data (e.g. for a mounted LNE) that would allow the configuration t=
o be manipulated.

Thanks,
Rob




With Regards,
Rohit



_______________________________________________

netmod mailing list

netmod@ietf.org

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

--_000_991B70D8B4112A4699D5C00DDBBF878A6BCB66F9dggeml530mbschi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











OK, got=
 the reference.


I felt =
it would have been better to mention why this “config” leaf has=
 been defined in this draft by citing a reference to other drafts as has be=
en done for the rest of the leaves.


As a re=
ader, I was left wondering as to why there should be a leaf that over-rides=
 the actual “config” true definition of the mounted models. If =
indeed the goal is to allow only “read” access why
 not use the NACM way for it ?


&n=
bsp;


With Re=
gards,


Rohit


&n=
bsp;






From: Robert Wilt=
on [mailto:rwilton@cisco.com]


Sent: 21 December 2018 17:41

To: Rohit R Ranade <rohitrranade@huawei.com>; netmod@ietf.org<=
br>
Subject: Re: [netmod] Query about Schema Mount "config" le=
af






 


Hi Rohit,


Are you familiar with either of the LNE or NI model=
 drafts?


https://datatracker.ietf.org/doc/draft-ietf-rtgwg-lne=
-model/




https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-m=
odel/


I believe both of these drafts were driving some of=
 the key schema mount requirements, and may provide useful examples of the =
use cases.




On 21/12/2018 12:01, Rohit R Ra=
nade wrote:






Hi All,


 


      &n=
bsp; +--ro mount-point* [module label]=



      &n=
bsp;    +--ro module      =
           yang:yang-iden=
tifier


      &n=
bsp;    +--ro label      &=
nbsp;           yang:yang=
-identifier


      &n=
bsp;    +--ro
config?          &=
nbsp;     boolean


 



1=
.   &=
nbsp;  
When reading the schema=
 mount draft it is not clear for which use-case, the “config” b=
eing false will be helpful for ?





Section 3 of the LNE draft writes about the use of =
this config leaf.


 





2=
.   &=
nbsp;  
If there are modules wi=
th config true nodes mounted, how can the data-nodes of those mounted modul=
es be instantiated if the config leaf is false ?




There will likely be separate direct YANG managemen=
t protocol access to the mounted data (e.g. for a mounted LNE) that would a=
llow the configuration to be manipulated.



Thanks,

Rob


 




 


 


With Regards,=



Rohit









_______________________________________________


netmod mailing list


netmod@ietf.or=
g


https://www.ietf.org/mailman/listinfo/netmod<=
/pre>







--_000_991B70D8B4112A4699D5C00DDBBF878A6BCB66F9dggeml530mbschi_--


From nobody Mon Dec 24 08:51:08 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E321E130F8A for ; Mon, 24 Dec 2018 08:51:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.196
X-Spam-Level: ***
X-Spam-Status: No, score=3.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmqoHJUr4ydJ for ; Mon, 24 Dec 2018 08:51:04 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03on0701.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe08::701]) (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 4D9A8130F8E for ; Mon, 24 Dec 2018 08:51:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qUTY9xrSg4TDREWSW4DafFYYyYO0s+t11R4vnhCJHcI=; b=MqwMye8twfJkCaUftJuDyJ9EUO7SMmEVHO1gSkRTewL99Ov/pjvDbZ6zJTIVBpSrOdlW8mCqagt/eGZTwQ72RZO/UFR0NbnYmC/6Ub4uEIxMkgF/XUsCphXArHvX2CcpPw+juaAV36zOg6Knw6ZLdYOnF4TjyQg7eegUHpGR380=
Received: from AM0PR07MB5506.eurprd07.prod.outlook.com (20.178.23.17) by AM0PR07MB5427.eurprd07.prod.outlook.com (20.178.21.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1471.13; Mon, 24 Dec 2018 16:51:01 +0000
Received: from AM0PR07MB5506.eurprd07.prod.outlook.com ([fe80::4435:9a03:4e44:c258]) by AM0PR07MB5506.eurprd07.prod.outlook.com ([fe80::4435:9a03:4e44:c258%4]) with mapi id 15.20.1471.018; Mon, 24 Dec 2018 16:51:01 +0000
From: tom petch 
To: Martin Bjorklund 
CC: "netmod@ietf.org" 
Thread-Topic: draft-ietf-softwire-yang-13
Thread-Index: AQHUm6jaPg3cPcqbdUq6KmxX62XFUQ==
Date: Mon, 24 Dec 2018 16:51:01 +0000
Message-ID: <01e801d49ba8$d6181320$4001a8c0@gateway.2wire.net>
References:  <20181218.171018.1430858087061589506.mbj@tail-f.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-clientproxiedby: LO2P265CA0313.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a4::13) To AM0PR07MB5506.eurprd07.prod.outlook.com (2603:10a6:208:103::17)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [86.139.215.184]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB5427; 6:msgVu1EKA5ZTIBBUX/7O6MuI+VGM5D6rVejWG37X5sTdsOAejFvXIWXdxRcVPcL/yY+xeGBuiAc4HXJQwF30mreJLLUG4tTW4qICbc6YDEfHFp6jxbglLkUw5vSH1VtLxKHO4dhDvQsFDASI1XXS83FCqT+h6G/tn0MDq5YJ7otexP+gLgcMH6bLjmf+UkG03DSKTVSqIVmd9loGNKye9E+nSGe1ap1DbBS+bjlK/ZOXt0t/GEvEqwhCOQ8bGp3QStc4srH8SVnYENyVMZ2WmyZzDE1qN2KYIVZ0malU/J0OZS4Lwq8rfNrQ4jtK0PxsYza9Q9raH/VHo88cWNfQoIT8P22vOj0mYoup1+lpRQThocwE6JY9SWe6syPwQj5s08zCzT3TJST64nbBCBljaBF+mp2FhCrY3PpoQBDvO24zr0IocCXhOSb09WjgPyjp9wQd3lr8v/PjikE+6wliAg==; 5:ihFdvW7iY0NweHwYzzgbzvg4O0pCl9Xa1InV3e7tN+5QM2XuPEyAbR/9hcLES8lfTaLBP7KvlJwu+6WkkRL3OBwGwhLp0YRYa2Yg+xuBW3GjeH75fHAfbHG7c0t0HIYYkUTV6fvHl6HrE6/4lCiOhTkN7DsTlNiU1/JfuurMYkM=; 7:SdlK9n65eB0q2+KUuJlei/uMR8IRfwRj31qVgFteR2QzTuVB/UdUG7ulNsvlNVnQsbbim58VGFT1Sr1jxmfMukWviwVBusxKUzXGe0qK6TxrZSYCfFiFCsCWcMTnnvSMDpGeOwWToYqIQ+mtdWj7hA==
x-ms-office365-filtering-correlation-id: 0c3e0e2c-8180-4e87-9f7a-08d669bffc77
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM0PR07MB5427; 
x-ms-traffictypediagnostic: AM0PR07MB5427:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(3230021)(908002)(999002)(5005026)(6040522)(2401047)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231475)(944501520)(52105112)(6055026)(6041310)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB5427; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB5427; 
x-forefront-prvs: 0896BFCE6C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(346002)(39860400002)(396003)(376002)(136003)(366004)(199004)(189003)(476003)(305945005)(81156014)(8936002)(81166006)(345774005)(7736002)(4326008)(66066001)(86152003)(26005)(256004)(3846002)(6116002)(486006)(9686003)(53936002)(6512007)(14496001)(102836004)(186003)(71200400001)(386003)(8676002)(6506007)(86362001)(2906002)(71190400001)(99286004)(6486002)(25786009)(44736005)(446003)(478600001)(14454004)(1556002)(106356001)(97736004)(105586002)(76176011)(6916009)(5660300001)(52116002)(316002)(68736007)(33896004)(6436002)(84392002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB5427; H:AM0PR07MB5506.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: NZ1H7HT1c4RNB8UYNJvdR2wzT+DQDi2BF6zdUDxMkwg4z3s8KuxVVpkJNoyig8gEB6TLRcoykDTIuwXbk9PcPqlDqbMU8+LNcFRNlp+Xecw5GJvZwZeD1GkS/FMitZ7WCTC8GuR1JknEOq4M7sI+PPSC2lAMgGGyaAG+fx6LQadfVPoCJS1/5JWoRl7ktSG6Wvye5W2RsMdQY5FRg7K8eqnh+mOdkpET8B2Wj4ntccgtj2Adp02QnW3LCOycyC5bFy4490xaC0NjPGMPUjh2aZb3UeOsO0yePFb6LhD3I53C3ra9j0DPT78qyMyBGL6/
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <664DCCD00BCC3A418AECCABAF50F3B79@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0c3e0e2c-8180-4e87-9f7a-08d669bffc77
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2018 16:51:01.8124 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5427
Archived-At: 
Subject: [netmod] draft-ietf-softwire-yang-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 24 Dec 2018 16:51:07 -0000

Martin

The Acknowledgements for
draft-ietf-softwire-yang-13
thank you for your work on this I-D (on the IESG Telechat for 10th
January 2019) so can you tell me where my YANG is going wrong.

The module has
  augment "/if:interfaces/if:interface" {
    when "derived-from(if:type, 'iana-tunnel-type:aplusp')";
and defines aplusp as a tunnel type in section 10.

A suggestion I made last October was to have a base for the three
protocols covered here - MAP-E, MAP-T, Lw406 - and then derive three
separate entities therefrom for the three protocols; I can see no
derivation.  In which case, when is

    when "derived-from(if:type, 'iana-tunnel-type:aplusp')";

going to be true?

Tom Petch


From nobody Thu Dec 27 04:08:42 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FE31292F1 for ; Thu, 27 Dec 2018 04:08:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ljklz-mbftJI for ; Thu, 27 Dec 2018 04:08:39 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 33351127133 for ; Thu, 27 Dec 2018 04:08:39 -0800 (PST)
Received: from localhost (h-4-215.A165.priv.bahnhof.se [158.174.4.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 6FE621AE0291; Thu, 27 Dec 2018 13:08:36 +0100 (CET)
Date: Thu, 27 Dec 2018 13:08:36 +0100 (CET)
Message-Id: <20181227.130836.708030498710454309.mbj@tail-f.com>
To: ietfc@btconnect.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <01e801d49ba8$d6181320$4001a8c0@gateway.2wire.net>
References:  <20181218.171018.1430858087061589506.mbj@tail-f.com> <01e801d49ba8$d6181320$4001a8c0@gateway.2wire.net>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] draft-ietf-softwire-yang-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Dec 2018 12:08:41 -0000

tom petch  wrote:
> Martin
> 
> The Acknowledgements for
> draft-ietf-softwire-yang-13
> thank you for your work on this I-D (on the IESG Telechat for 10th
> January 2019) so can you tell me where my YANG is going wrong.
> 
> The module has
>   augment "/if:interfaces/if:interface" {
>     when "derived-from(if:type, 'iana-tunnel-type:aplusp')";
> and defines aplusp as a tunnel type in section 10.
> 
> A suggestion I made last October was to have a base for the three
> protocols covered here - MAP-E, MAP-T, Lw406 - and then derive three
> separate entities therefrom for the three protocols; I can see no
> derivation.  In which case, when is
> 
>     when "derived-from(if:type, 'iana-tunnel-type:aplusp')";
> 
> going to be true?

Right; either they have to define derived identities as you suggested,
or this need to change to 'derived-from-or-self'.


/martin


From nobody Thu Dec 27 07:06:18 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B212F12426A for ; Thu, 27 Dec 2018 07:06:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.196
X-Spam-Level: ***
X-Spam-Status: No, score=3.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fh5mmCKgIzO7 for ; Thu, 27 Dec 2018 07:06:12 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30125.outbound.protection.outlook.com [40.107.3.125]) (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 845EF12D84D for ; Thu, 27 Dec 2018 07:06:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VEYE8+WqNEzbdbW09u8l0PER1cxJEPob6Hu4JNvoAgk=; b=fwGztloXzkx4Mnii6rC+1ZilMWHl0ncLOgQqrcuf0hAqhVZavWx4buUMgKvSdO9hMC5tvpoqWEth0n/XvMKq647b1dKyJnEkelsBlcQ7bT/bQLfne0IeFbSPQGiwlG4Sjqynmj5FBi3+MIiXnc7RBZY3YrwjqVcPaOBkVVQgCnk=
Received: from AM0PR07MB5506.eurprd07.prod.outlook.com (20.178.23.17) by AM0PR07MB4658.eurprd07.prod.outlook.com (52.135.151.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1471.16; Thu, 27 Dec 2018 15:06:02 +0000
Received: from AM0PR07MB5506.eurprd07.prod.outlook.com ([fe80::4435:9a03:4e44:c258]) by AM0PR07MB5506.eurprd07.prod.outlook.com ([fe80::4435:9a03:4e44:c258%4]) with mapi id 15.20.1471.019; Thu, 27 Dec 2018 15:06:02 +0000
From: tom petch 
To: Martin Bjorklund 
CC: "netmod@ietf.org" 
Thread-Topic: draft-ietf-softwire-yang-13
Thread-Index: AQHUnfWuzVXJFxSfFEa3jgnayWbDRg==
Date: Thu, 27 Dec 2018 15:06:01 +0000
Message-ID: <003601d49df5$a7d094c0$4001a8c0@gateway.2wire.net>
References: <20181218.171018.1430858087061589506.mbj@tail-f.com><01e801d49ba8$d6181320$4001a8c0@gateway.2wire.net> <20181227.130836.708030498710454309.mbj@tail-f.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-clientproxiedby: LO2P265CA0095.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:8::35) To AM0PR07MB5506.eurprd07.prod.outlook.com (2603:10a6:208:103::17)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [86.139.215.184]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB4658; 6:KBxhhlx2vIWQdZXGh7ujv8s+JODcZKSqgOS59JWxCT0M3knLouCMr9FSdFlHwTt9dp5+wciTCDUGSWrgWGI4QZIrhlkq9nQwZhp5qsCzwxRHsko/7Xqrt1dBNs6NOhZwcnJ6m8i0KossRQsMJGAvgw1G4El+FuP1y979fKb1RE4tzGN4ZPbaRA7I4AoqQhTAhYPURakPmzon0kSWyObRdsBsXfO2j8ODEMNnNIcpLEvOk/KrcESTZdyg1LMpmpiiqwLecBbNWKS2jhGiLCOafEgCgL3MmHwt8ZNSZF3By6y/9uveSffFYextZ3hNoomD7cBgelJGG/oEEBf+lbqNDZkPe5DNwJLiytCArEQ0f0lRNCyW56I49siVf+ZMVATZ86IBkhNJuRDTmD8ZchlNOYAVTvEfo6PPmK8AyJ/mupwyFuNnNjnt/OH1s4fAS2iVdsNs8+wD2RgXuT2I2beD7Q==; 5:40SoVSkzzLzz/rLCDkqJFdKQJGiKDDICH9xhWxWlUGaBnHg5rBAYwP88v7JRBBoCV/5q4HpZjTWyGjgBuTK7oCtyrRU1fhYYn4onfJaxmc2GsPdgHH/igHk5Jn4vZV8f8ctZ6JoKtyDKXUFidLNER1pLANXZY6Za8kmcApjjFu8=; 7:aUYdbmzGoNDEAe2xCDVswrI2xpBraq86aXoCqKaOSQziAVXMbLUaKdoklBkOUhtjCU43X0slu+CG9dlk+FMlmZrTw17javv8eDNrrncG02RATfryn2Bhj3d6eVNX5oBbrzV+W4n/TtGyoY6jrzPoCQ==
x-ms-office365-filtering-correlation-id: faa22000-274d-4929-d250-08d66c0cd09d
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7193020); SRVR:AM0PR07MB4658; 
x-ms-traffictypediagnostic: AM0PR07MB4658:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(3230021)(908002)(999002)(5005026)(6040522)(2401047)(8121501046)(3002001)(10201501046)(3231475)(944501520)(52105112)(93006095)(93001095)(6055026)(6041310)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB4658; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4658; 
x-forefront-prvs: 0899B47777
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(136003)(366004)(346002)(396003)(39860400002)(376002)(13464003)(199004)(189003)(106356001)(105586002)(6506007)(386003)(6916009)(6246003)(81166006)(81156014)(53936002)(9686003)(86152003)(6512007)(84392002)(7736002)(26005)(345774005)(186003)(478600001)(14496001)(76176011)(8676002)(1556002)(52116002)(99286004)(256004)(8936002)(102836004)(44736005)(4326008)(229853002)(33896004)(446003)(93886005)(14454004)(6116002)(3846002)(68736007)(486006)(6436002)(2906002)(476003)(25786009)(6486002)(305945005)(71190400001)(5660300001)(71200400001)(97736004)(86362001)(316002)(66066001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4658; H:AM0PR07MB5506.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 8z33zUX0X6f8Wh9cSH5RgiOlzxs28NF8aFFW8JecmhtT4mu2ACkj97nTvqAlkZqPeZSpbYwzkQXg1cRJR4ksR0xC9x1SZLbMtvd/OF11XBvyqHrG9xSqz7wvm2uToNiEDoRcZKmQasU6fwcKSOS1tY4007FJah7KsqhOFnqsxhhRzKrbzysgRdXopqR+fFlkM5clo3kyHedPLO7swdACKT6cSQ7LHSxAdNSiHqbAL7ysmFg/QZefd56MTHcugl8/3IvnoZW34KHIpyPcpOdyiWYt1Cvizn07Kt228sR0St7HX9FLB2Zh4SnfrheMqcUy
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <34E44D20FD7128468FCF362F4A42811B@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: faa22000-274d-4929-d250-08d66c0cd09d
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Dec 2018 15:06:01.9558 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4658
Archived-At: 
Subject: Re: [netmod] draft-ietf-softwire-yang-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Dec 2018 15:06:17 -0000

----- Original Message -----
From: "Martin Bjorklund" 
To: 
Cc: 
Sent: Thursday, December 27, 2018 12:08 PM

> tom petch  wrote:
> > Martin
> >
> > The Acknowledgements for
> > draft-ietf-softwire-yang-13
> > thank you for your work on this I-D (on the IESG Telechat for 10th
> > January 2019) so can you tell me where my YANG is going wrong.
> >
> > The module has
> >   augment "/if:interfaces/if:interface" {
> >     when "derived-from(if:type, 'iana-tunnel-type:aplusp')";
> > and defines aplusp as a tunnel type in section 10.
> >
> > A suggestion I made last October was to have a base for the three
> > protocols covered here - MAP-E, MAP-T, Lw406 - and then derive three
> > separate entities therefrom for the three protocols; I can see no
> > derivation.  In which case, when is
> >
> >     when "derived-from(if:type, 'iana-tunnel-type:aplusp')";
> >
> > going to be true?
>
> Right; either they have to define derived identities as you suggested,
> or this need to change to 'derived-from-or-self'.

.. or drop the 'derived' altogether; if there is only 'aplusp', as at
present, then I see no need for 'derived' and inserting one
unnecessarily leaves scope for a future addition to be true when it is
not wanted.  I can see it either way.

Tom Petch

>
> /martin
>


From nobody Thu Dec 27 20:07:36 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AA2128B14 for ; Thu, 27 Dec 2018 20:07:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KngNlOELcYh6 for ; Thu, 27 Dec 2018 20:07:33 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFEE12870E for ; Thu, 27 Dec 2018 20:07:33 -0800 (PST)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 4B0F5369BBA5C for ; Fri, 28 Dec 2018 04:07:29 +0000 (GMT)
Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 28 Dec 2018 04:07:30 +0000
Received: from DGGEML530-MBS.china.huawei.com ([169.254.8.165]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0415.000; Fri, 28 Dec 2018 12:07:09 +0800
From: Rohit R Ranade 
To: "netmod@ietf.org" 
Thread-Topic: Schema Mount Yang Library Update
Thread-Index: AdSeYUFYxAmOUSMrRlSaqc+d9z9IXA==
Date: Fri, 28 Dec 2018 04:07:09 +0000
Message-ID: <991B70D8B4112A4699D5C00DDBBF878A6BCBB04A@dggeml530-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.18.150.121]
Content-Type: multipart/alternative; boundary="_000_991B70D8B4112A4699D5C00DDBBF878A6BCBB04Adggeml530mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod] Schema Mount Yang Library Update
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 28 Dec 2018 04:07:36 -0000

--_000_991B70D8B4112A4699D5C00DDBBF878A6BCBB04Adggeml530mbschi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

For the shared-schema type, the draft mentions "all instances of the same m=
ount point MUST have the same YANG library content identifier".

I think to achieve above condition, most vendors will plan to have only one=
 YANG library instance for that mount-point.

If use multiple instances for Yang library, it is possible that the algorit=
hm may generate a new content identifier for same data as per below stateme=
nt in Yang library 1.1 draft:

"There is no requirement that the same information always results in the sa=
me "content-id" value."


If use single instance of Yang library, when a YANG library update happens,=
 for which mount-point instance should a YANG library update notification b=
e sent ?
What is the guideline for the implementers of this draft regarding this poi=
nt?

With Regards,
Rohit

--_000_991B70D8B4112A4699D5C00DDBBF878A6BCBB04Adggeml530mbschi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi All,


 


For the shared-schema type, the draft mention=
s “all instances of the same
 mount point MUST have the same YANG library content identifier”. 



 


I think to achieve above condition, most vend=
ors will plan to have only one YANG library instance for that mount-point.



 


If use multiple instances for Yang library, i=
t is possible that the algorithm may generate a new content identifier for =
same data as per below statement in Yang
 library 1.1 draft:


“There is no requirement that the same information =
always results in the same "content-id" value.”


 


If use single instance of Yang library, when =
a YANG library update happens, for which mount-point instance should a YANG=
 library update notification be sent ?


What is the guideline for the implementers of=
 this draft regarding this point?


 


With Regards,


Rohit






--_000_991B70D8B4112A4699D5C00DDBBF878A6BCBB04Adggeml530mbschi_--


From nobody Thu Dec 27 23:47:55 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187EA130FEA for ; Thu, 27 Dec 2018 23:47:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlvVKIuWqE15 for ; Thu, 27 Dec 2018 23:47:50 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 992E4130FE6 for ; Thu, 27 Dec 2018 23:47:49 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 5F60D1820191; Fri, 28 Dec 2018 08:55:53 +0100 (CET)
Received: from localhost (unknown [172.29.2.111]) by trail.lhotka.name (Postfix) with ESMTPSA id 8CB40182015B; Fri, 28 Dec 2018 08:55:47 +0100 (CET)
From: Ladislav Lhotka 
To: tom petch , Martin Bjorklund 
Cc: "netmod\@ietf.org" 
In-Reply-To: <003601d49df5$a7d094c0$4001a8c0@gateway.2wire.net>
References:  <20181218.171018.1430858087061589506.mbj@tail-f.com> <01e801d49ba8$d6181320$4001a8c0@gateway.2wire.net> <20181227.130836.708030498710454309.mbj@tail-f.com> <003601d49df5$a7d094c0$4001a8c0@gateway.2wire.net>
Mail-Followup-To: tom petch , Martin Bjorklund , "netmod\@ietf.org" 
Date: Fri, 28 Dec 2018 08:47:41 +0100
Message-ID: <87d0pm149u.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] draft-ietf-softwire-yang-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 28 Dec 2018 07:47:53 -0000

tom petch  writes:

> ----- Original Message -----
> From: "Martin Bjorklund" 
> To: 
> Cc: 
> Sent: Thursday, December 27, 2018 12:08 PM
>
>> tom petch  wrote:
>> > Martin
>> >
>> > The Acknowledgements for
>> > draft-ietf-softwire-yang-13
>> > thank you for your work on this I-D (on the IESG Telechat for 10th
>> > January 2019) so can you tell me where my YANG is going wrong.
>> >
>> > The module has
>> >   augment "/if:interfaces/if:interface" {
>> >     when "derived-from(if:type, 'iana-tunnel-type:aplusp')";
>> > and defines aplusp as a tunnel type in section 10.
>> >
>> > A suggestion I made last October was to have a base for the three
>> > protocols covered here - MAP-E, MAP-T, Lw406 - and then derive three
>> > separate entities therefrom for the three protocols; I can see no
>> > derivation.  In which case, when is
>> >
>> >     when "derived-from(if:type, 'iana-tunnel-type:aplusp')";
>> >
>> > going to be true?
>>
>> Right; either they have to define derived identities as you suggested,
>> or this need to change to 'derived-from-or-self'.
>
> ... or drop the 'derived' altogether; if there is only 'aplusp', as at
> present, then I see no need for 'derived' and inserting one
> unnecessarily leaves scope for a future addition to be true when it is
> not wanted.  I can see it either way.

Do you mean writing something like

    when "if:type = 'iana-tunnel-type:aplusp'";

?

This is brittle and shouldn't be used because it is a plain string
equality test and the result depends (in XML representation) on the
prefix that is declared for the namespace URI of the iana-tunnel-type
module.

It is true that derived-from/derived-from-or-self leaves scope for
future additions. However, if ever an identity is defined that
is derived from 'iana-tunnel-type:aplusp', then it IMO makes sense only
if the properties of the latter are inherited, so the "when" test
should still be true (and the augment applicable).

Lada

>
> Tom Petch
>
>>
>> /martin
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Fri Dec 28 01:29:45 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34B3128CE4 for ; Fri, 28 Dec 2018 01:29:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0r8cMHrBtFt for ; Fri, 28 Dec 2018 01:29:40 -0800 (PST)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 3D2BA1200D7 for ; Fri, 28 Dec 2018 01:29:40 -0800 (PST)
Received: by mail-pf1-x436.google.com with SMTP id c123so10286909pfb.0 for ; Fri, 28 Dec 2018 01:29:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y6WFtXyu1RdwyHsDqTwA5e+GasHXmRGJhM+we1Fb5lM=; b=pDjsHoV7Q+3kzciCvVKJ5nl9j6PQWiOMa04cVU4CpkBUts1ZuSv417/ZYQS8tkybkA rO/FW+8/Ushuqg3mR0cCsKbNzv3PrKN5uDeQM3kPkhw4fTjYvEADUQbpek5DIjsBrHQ8 MnUBDpr1B2GjOMYf5HM2MYMJcBCNUJcFNfh1+fd6n4LaBMKbsLvz0tK/KgERaf7hffe9 oDq1hD1dM2/0JtJf1kF5GWmpJce1ZMentHlT00FczJmLaRX9Gep7u0G5orBdlr2lZWrK 9EDVg/xMK8e5Fuv8XnXG11n3AizQX3LYRTE6wDz2Tb11f4q3Cvptm+X5xJPEOj0MxSDc E+tA==
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=y6WFtXyu1RdwyHsDqTwA5e+GasHXmRGJhM+we1Fb5lM=; b=SYqPyhnGucsUgeywYETL1TBvW1sKpxmBHylXNOcCwjYp+1Vhlss0SW6HUlqIHb2sJu QdK7+SnrhEw9pwJIRLmRHrf773xEjtLOGTz0UmVrCZYsk93wcJTBvFVhyqtssgBywdJ1 CcpelMxVZf1DGiNyT9PJIEvScXb7/FLB/yIVYQUkk2E3e2iu09OLcDnrLsD6TWXbid+g DtHIOt/BOnN3wodCfOv1sSveI7hgzj4LnVL88nInw+FfSui92NYrcuRPNzj8QAkMSpcQ oHfYpe5+lwnPGaWHmkJSVYKdvliUjgn2EbTmp4RckAjvgFFKdOi2eX8S0UFGe/RjJxvv gSIw==
X-Gm-Message-State: AA+aEWYzonoRXTbHd7t/JNNz8Z12eWZnftnBCYS9aWjx/ZusLK0Gai9M tU/+3A9ijPVBaH7I9e/1uFd1YzMiyttbzUs43fY=
X-Google-Smtp-Source: AFSGD/UPe1Untv6W+F9NgbENSLkfEZu12U8zVpPI52trdItuoK8iA8ci0Z1y8IRrt+5N+Gisg2GWGi6xUZELONFVW+s=
X-Received: by 2002:a62:1289:: with SMTP id 9mr27707859pfs.102.1545989379516;  Fri, 28 Dec 2018 01:29:39 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: nicola sambo 
Date: Fri, 28 Dec 2018 10:29:28 +0100
Message-ID: 
To: Ottawa Guy 
Cc: netmod@ietf.org, Giuseppe Fioccola , piero.castoldi@sssup.it, Haoyu song 
Content-Type: multipart/alternative; boundary="000000000000caee3f057e11b303"
Archived-At: 
Subject: Re: [netmod] Fw: draft-sambo-netmod-yang-fsm-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2018 09:29:43 -0000

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

Hi Hadi,

thanks, please find answers inline:

From: Ottawa Guy 
> To: "nicola.sambo@sssup.it" , "
> piero.castoldi@sssup.it" , "
> giuseppe.fioccola@huawei.com" , "
> haoyu.song@huawei.com" 
> Cc:
> Bcc:
> Date: Mon, 24 Dec 2018 21:09:15 +0000 (UTC)
> Subject: Fw: draft-sambo-netmod-yang-fsm-04
>
>
> Hi,
>
> I am working for Ciena. We are exploring use of generic FSM propose in IETF "draft-sambo-netmod-yang-fsm" for our product. I have few questions about the proposed yang model.
>
>
> 1. Where can I download the latest version of the FSM yang file. Is there
> any github location.
>

The github location is https://github.com/nicola-sambo/FSM

anyway, the last version of the draft should include the whole code:
https://datatracker.ietf.org/doc/draft-sambo-netmod-yang-fsm/?include_text=1


> 2. I didn't find "filter-type" in the yang definition described the
> section 7.2 of the document.
>

I think we removed it, but it is still in the text for a mistake. Please,
let me better check.


> 4.  "transition-type" takes a identity value "ON_CHANGE" . What other
> value can it assume. I am looking for some use cases.
>

This draft defines a general finite state machine. Then, each use case
should have a proper implementation with proper attributes' values.
Currently, the use case that we implemented is the reaction to a change of
BER (
https://datatracker.ietf.org/doc/draft-sambo-ccamp-yang-fsm-transponder-reconf/),
thus we assumed that type of transition. Consider that the work is in
progress and if you have in mind other use cases we can include the values
you think are relevant. We are happy to collaborate with you on the
augmentation of the model. Regarding the transponder reconfiguration,
please check this implementation
https://datatracker.ietf.org/doc/draft-sambo-ccamp-yang-fsm-transponder-reconf/?include_text=1

Please, also consider that, there, the "filter" has been replaced with
"threshold-parameter" and "threshold-operator", but the concept is the
same, thus something which permits to better describe the transition.


> 4. The state-id-type  is defined as uint32.  Is there any reason why
> "identity" was not used. That way derived module could extent the state-id.
>

Currently, the identity is associated to the type of transition not to the
state, the state has an id and a description. If there is a reason to add
"identity" to the state, this is not a problem.


> 5. Is there other yang example where this generic FSM is being used.
>

the other identified use cases up to now (performance measurements,
telemetry) are described in draft-sambo-netmod-yang-fsm-04 . As above, we
implemented the case of transponder reconfiguration. But there are others
we are thinking about, also with respect to the ones already identified.


> 6. How do I join in the mailing list.
>

subscription here: https://datatracker.ietf.org/wg/netmod/about/
I am already replying to the mailing list.

I am now on travel, let's update after January 6. We can set also a
conference call if it's easier.

Thanks and best regards,
Nicola

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


Hi Hadi,

thanks, please find answers=
 inline:

<=
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">From:=C2=A0Ottawa Guy <=
ottawaguy81@yaho=
o.com>
To:=C2=A0"nicola.sambo@sssup.it" <nicola.sambo@sssup.it>, "piero.castoldi@s=
ssup.it" <piero.castoldi@sssup.it>, "giuseppe.fioccola@huawei.com"=
; <giu=
seppe.fioccola@huawei.com>, "haoyu.song@huawei.com" <haoyu.song@huawei.com><=
br>Cc:=C2=A0
Bcc:=C2=A0
Date:=C2=A0Mon, 24 Dec 2018 21:09:15 +0000 (U=
TC)
Subject:=C2=A0Fw: draft-sambo-netmod-yang-fsm-04

        


                

        


                
Hi,
I am working for Ciena. We are e=
xploring use of generic FSM propose in IETF "draft-sambo-netmod-=
yang-fsm" for our product. I have few questions about the proposed yan=
g model. 
=


<=
div class=3D"m_-7514838765400651676gmail-m_-1049943519454038790ydp892017eey=
iv7126124380yqt3576612404" id=3D"m_-7514838765400651676gmail-m_-10499435194=
54038790ydp892017eeyiv7126124380yqtfd80790">
1. Where can I download th=
e latest version of the FSM yang file. Is there any github location.=C2=A0=
=C2=A0

The github location is=C2=A0https://github.com/n=
icola-sambo/FSM

anyway, the last version of th=
e draft should include the whole code:=C2=A0https://datatracker.ietf.org/doc/draft-sambo-netmod-yang-fsm/?include_te=
xt=3D1
=C2=A0
2. I didn't find "filter-type" in the yan=
g definition described the section 7.2 of the document.=C2=A0

I think we removed it, but it is still in the text for a mi=
stake. Please, let me better check.
=C2=A0
4.=C2=A0 "transition-ty=
pe" takes a identity value "ON_CHANGE" . What other value ca=
n it assume. I am looking for some use cases.=C2=A0
=


This draft defines a general finite state machine. Then, each use cas=
e should have a proper implementation with proper attributes' values. C=
urrently, the use case that we implemented is the reaction to a change of B=
ER (https://datatracker.ietf.org/doc/dra=
ft-sambo-ccamp-yang-fsm-transponder-reconf/), thus we assumed that type=
 of transition. Consider that the work is in progress and if you have in mi=
nd other use cases we can include the values you think are relevant. We are=
 happy to collaborate with you on the augmentation of the model. Regarding =
the transponder reconfiguration, please check this implementation=C2=A0https://datatracker.ietf.or=
g/doc/draft-sambo-ccamp-yang-fsm-transponder-reconf/?include_text=3D1=
=C2=A0
Please, also consider that, there, the "filter" =
has been replaced with "threshold-parameter" and "threshold-=
operator", but the concept is the same, thus something which permits t=
o better describe the transition.
=C2=A0
4. The state-id-type=C2=A0 i=
s defined as uint32.=C2=A0 Is there any reason why "identity" was=
 not used. That way derived module could extent the state-id.=C2=A0

Currently, the identity is associated to the type of =
transition not to the state, the state has an id and a description. If ther=
e is a reason to add "identity" to the state, this is not a probl=
em.
=C2=A0
5. Is there other yang example where this generic FSM is being=
 used.=C2=A0

the other identified use cases up=
 to now (performance measurements, telemetry) are described in=C2=A0draft-s=
ambo-netmod-yang-fsm-04 . As above, we implemented the case of transponder =
reconfiguration. But there are others we are thinking about, also with resp=
ect to the ones already identified.=C2=A0
=C2=A0
=

6. How do I join in the =
mailing list.=C2=A0

subscription here:=C2=A0h=
ttps://datatracker.ietf.org/wg/netmod/about/
I am already rep=
lying to the mailing list.
=C2=A0
I am now on travel, l=
et's update after January 6. We can set also a conference call if it=
9;s easier.

Thanks and best regards,
Nic=
ola

<=
div id=3D"m_-7514838765400651676gmail-m_-1049943519454038790ydp892017eeyaho=
o_quoted_5982863178" class=3D"m_-7514838765400651676gmail-m_-10499435194540=
38790ydp892017eeyahoo_quoted">

            

        

            

        
=


--000000000000caee3f057e11b303--


From nobody Fri Dec 28 03:35:40 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3382D12950A for ; Fri, 28 Dec 2018 03:35:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.197
X-Spam-Level: ***
X-Spam-Status: No, score=3.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGcaz5tlG_WY for ; Fri, 28 Dec 2018 03:35:36 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40111.outbound.protection.outlook.com [40.107.4.111]) (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 73DC6130DBE for ; Fri, 28 Dec 2018 03:35:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YHMWwIBX+EFjL/J9F49oIJxvEZXfBW6UiI7yVZhrXek=; b=UNaM27UgjB6tP1c0J6PeVb5BpZY+Kx0jlG0RkW2hRdJx5yz+icEaOvJb6MZBPbcmrwyxik0jDD9aVzakQfD9kG+0fQ9KMPHnp8ZYVkygrOaCEPHrLKXn4Hu+KgKGPzfRNpKzKSybGmc1+rRm224vocIcy+KD3WJ0Ll1TsZ9xjcU=
Received: from AM0PR07MB5506.eurprd07.prod.outlook.com (20.178.23.17) by AM0PR07MB4946.eurprd07.prod.outlook.com (20.178.19.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1471.13; Fri, 28 Dec 2018 11:35:33 +0000
Received: from AM0PR07MB5506.eurprd07.prod.outlook.com ([fe80::4435:9a03:4e44:c258]) by AM0PR07MB5506.eurprd07.prod.outlook.com ([fe80::4435:9a03:4e44:c258%4]) with mapi id 15.20.1471.019; Fri, 28 Dec 2018 11:35:33 +0000
From: tom petch 
To: Ladislav Lhotka , Martin Bjorklund 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] draft-ietf-softwire-yang-13
Thread-Index: AQHUnfWuzVXJFxSfFEa3jgnayWbDRg==
Date: Fri, 28 Dec 2018 11:35:33 +0000
Message-ID: <00be01d49ea1$6a0f5520$4001a8c0@gateway.2wire.net>
References:  <20181218.171018.1430858087061589506.mbj@tail-f.com> <01e801d49ba8$d6181320$4001a8c0@gateway.2wire.net> <20181227.130836.708030498710454309.mbj@tail-f.com> <003601d49df5$a7d094c0$4001a8c0@gateway.2wire.net> <87d0pm149u.fsf@nic.cz>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-clientproxiedby: LNXP265CA0001.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::13) To AM0PR07MB5506.eurprd07.prod.outlook.com (2603:10a6:208:103::17)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [86.139.215.184]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB4946; 6:fDiNmiUFq2z3yJFiHjG+gwybq9IFvSJL8Vg7qUWqxQUPgMsYOFAipH9aS3yJv/TzciSOUXYiIFHUmaQTRRbiXMtCKe4VToNtz/zgxxVBrcctoF6kR/3eVGwkuZaKvBwZx2F5czvFsJbECRUQqYY3SW5uDkQHqz67ZlxqXxLxsT/a/fP3KXBJ9dS6jFPpRh3vDdIy+E3TVlJzmOfpjBH5DIal9rBxIokJwI4xDTywjiWiPO8QyP+0rmBYFYUHQZIUlFyy9rJAXcB/QeXaep2ZQz6eXJRniYFa/nQpVHZsMTReY5Af3o5CBsuNV3J1inTW/d3YGISzFJYapqDlyzVKX+PBB5C2AAK4v0bfoOSVPoqEUfQLgCeLJRdS1nO06/kyi6dn5OdqT189GMhagPqd1ZpOktt5YhYVYSiII0qj1bzwp9Y9FnkjuKuZSWob+YYgkldOy6g/Sa/CCxKUSVngCg==; 5:FXAhzap1FrXmOxovyjI6l1Yda3JVjH1mhSpEDT93gbLJ/I53u0+AfKYVzptBelBR0i4dc3fNguEgCaU+pWPvpp90H3nKBkh1KCQjKsiu7lEFPMyJA3BUw25AlSAWoI463A8Ly+KEtE8mHTZdu9WysQjKH3+aEtx6urBzQWqu2Xs=; 7:/0gqDz3etWh+GAoMTHVCmMHQu39oXbbzW+Ag5AnqVNsAZZPUnLtu4PLW/eg2f3E/sd4j/T7jf0VxJfTNpwrqylj8z8yDgDP/BugDfVliVbDi91GHAzbnIULv4I+bvyyYBgnt0+VPUV7d5HMSmSZ17g==
x-ms-office365-filtering-correlation-id: b315e4a3-18f0-408d-0f87-08d66cb893ee
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM0PR07MB4946; 
x-ms-traffictypediagnostic: AM0PR07MB4946:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(3230021)(908002)(999002)(5005026)(6040522)(2401047)(8121501046)(3231475)(944501520)(52105112)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041310)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB4946; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4946; 
x-forefront-prvs: 09007040D4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(136003)(376002)(39860400002)(346002)(51444003)(13464003)(199004)(189003)(8936002)(81156014)(5660300001)(86152003)(966005)(345774005)(81166006)(84392002)(71190400001)(71200400001)(6436002)(93886005)(229853002)(14454004)(6512007)(106356001)(478600001)(8676002)(44736005)(86362001)(68736007)(446003)(99286004)(105586002)(25786009)(9686003)(6306002)(186003)(114624004)(486006)(316002)(97736004)(256004)(476003)(14496001)(52116002)(7736002)(53936002)(6246003)(1556002)(3846002)(6116002)(4326008)(102836004)(6486002)(26005)(110136005)(66066001)(33896004)(76176011)(2906002)(305945005)(386003)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4946; H:AM0PR07MB5506.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 2+5S/OYE+HkmgL6mcRAMS+GRk3aKYlEHRzINcwEzpDwv/OMg44LaeyNBWS5Cy37U3+vQ42m5nDTcIkbd6i5fvmb2PxzL5tnO7YVXc42VGB+oVEuheErfiWfuiYQK62zG26lErHP3ulUm70WICQMqpzFWh7BnWr4k7V71f7P2MEhqezy6+GTW/08gukZOQAvvK5S60UvO66BAD93QWTpavJEQpQoE7dVZyz49IIX4FDHkzKFB8FJytjRzkcSgr84Vk9SL8vQRW12szNgey9Ju6OfIvR+KILTAQFObrQik2AHSo+z2slREad/pwFSn4vOw
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <1A523E17310A6D4D882EF51A34F0AD5F@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b315e4a3-18f0-408d-0f87-08d66cb893ee
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Dec 2018 11:35:33.3910 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4946
Archived-At: 
Subject: Re: [netmod] draft-ietf-softwire-yang-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 28 Dec 2018 11:35:39 -0000

----- Original Message -----
From: "Ladislav Lhotka" 
Sent: Friday, December 28, 2018 7:47 AM
> tom petch  writes:
>
> > ----- Original Message -----
> > From: "Martin Bjorklund" mbj@tail-f.com
> > Sent: Thursday, December 27, 2018 12:08 PM
> >
> >> tom petch  wrote:
> >> > Martin
> >> >
> >> > The Acknowledgements for
> >> > draft-ietf-softwire-yang-13
> >> > thank you for your work on this I-D (on the IESG Telechat for
10th
> >> > January 2019) so can you tell me where my YANG is going wrong.
> >> >
> >> > The module has
> >> >   augment "/if:interfaces/if:interface" {
> >> >     when "derived-from(if:type, 'iana-tunnel-type:aplusp')";
> >> > and defines aplusp as a tunnel type in section 10.
> >> >
> >> > A suggestion I made last October was to have a base for the three
> >> > protocols covered here - MAP-E, MAP-T, Lw406 - and then derive
three
> >> > separate entities therefrom for the three protocols; I can see no
> >> > derivation.  In which case, when is
> >> >
> >> >     when "derived-from(if:type, 'iana-tunnel-type:aplusp')";
> >> >
> >> > going to be true?
> >>
> >> Right; either they have to define derived identities as you
suggested,
> >> or this need to change to 'derived-from-or-self'.
> >
> > ... or drop the 'derived' altogether; if there is only 'aplusp', as
at
> > present, then I see no need for 'derived' and inserting one
> > unnecessarily leaves scope for a future addition to be true when it
is
> > not wanted.  I can see it either way.
>
> Do you mean writing something like
>
>     when "if:type =3D 'iana-tunnel-type:aplusp'";
>
> ?
>
> This is brittle and shouldn't be used because it is a plain string
> equality test and the result depends (in XML representation) on the
> prefix that is declared for the namespace URI of the iana-tunnel-type
> module.
>
> It is true that derived-from/derived-from-or-self leaves scope for
> future additions. However, if ever an identity is defined that
> is derived from 'iana-tunnel-type:aplusp', then it IMO makes sense
only
> if the properties of the latter are inherited, so the "when" test
> should still be true (and the augment applicable).

Lada

Thanks for that; I did indeed have the string equality test in mind,
even though RFC8407 says otherwise.  I think that all this is too
complicated, for me if not for the authors of I-D coming out of the
Routing Area - I-D such as this one have already have several makeovers,
courtesy of such as Martin and I, and for this in its present form to be
on the next IESG Telechat - well, par for the course.

On a different tack, I was looking at teas-types and seeing
uses path-objective-function_config
Hang on, is underscore valid? Yes, but why use it? RFC8407 suggests do
not.
or
    type union {
        type string {  length 0; // empty string      }
        type string {  pattern ...
and thinking why?  With no length restriction on the pattern, what does
the complexity of a YANG union add?
or
  description  "Then index of the label restriction list entry."; }
    container label-start {
      must "not(../label-end/te-label/direction) or "
        + "not(te-label/direction) "
        + "or ../label-end/te-label/direction =3D te-label/direction" {
        error-message "label-start and label-end must have the same
direction.";
where the error message tells me what is going on (not the description)
but I wondered about the second 'not'  which I asssume is to cater for
 "(te-label/direction) "
not having a value.  All they want is
'start direction must =3D end direction'
but it seems you need to be a contortionist to get there.

I would appreciate any comment on this last - is there a simpler way of
doing it?   After which, I shall return to lurking.

Tom Petch

> Lada
>
> >
> > Tom Petch
> >
> >>
> >> /martin
> >>
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67


From nobody Fri Dec 28 05:03:46 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBF41292F1 for ; Fri, 28 Dec 2018 05:03:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RuMxc1CoiD4 for ; Fri, 28 Dec 2018 05:03:42 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8A2C128CF3 for ; Fri, 28 Dec 2018 05:03:40 -0800 (PST)
Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 4D3E5624A7; Fri, 28 Dec 2018 14:03:37 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1546002217; bh=qcdly+DLCjC+18ulvaVD/KvTprn1xQbTiqqzk10d0Zc=; h=From:To:Date; b=Ac+24wd05j9Hi2U/DRrCeli+ltqmzP98L7vTqScK+Bq897Xn6PxAGWb50Nka+oGfS vkZCKgmboiSRsGkbcFBLbP+wBZxN2zBDhgPorgxNKuXPOWDrfeeINwmavypnGDD7cY lVVMFSBAtD3HNA/QwM+59+hmj48Lh68WDTTBhs00=
Message-ID: <0687c7291fba3b69336cb7e4a12c640b49cb75ea.camel@nic.cz>
From: Ladislav Lhotka 
To: tom petch , Martin Bjorklund 
Cc: "netmod@ietf.org" 
Date: Fri, 28 Dec 2018 14:03:36 +0100
In-Reply-To: <00be01d49ea1$6a0f5520$4001a8c0@gateway.2wire.net>
References:  <20181218.171018.1430858087061589506.mbj@tail-f.com> <01e801d49ba8$d6181320$4001a8c0@gateway.2wire.net> <20181227.130836.708030498710454309.mbj@tail-f.com> <003601d49df5$a7d094c0$4001a8c0@gateway.2wire.net> <87d0pm149u.fsf@nic.cz> <00be01d49ea1$6a0f5520$4001a8c0@gateway.2wire.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.3 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] draft-ietf-softwire-yang-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 28 Dec 2018 13:03:45 -0000

On Fri, 2018-12-28 at 11:35 +0000, tom petch wrote:
> ----- Original Message -----
> From: "Ladislav Lhotka" 
> Sent: Friday, December 28, 2018 7:47 AM
> > tom petch  writes:
> > 
> > > ----- Original Message -----
> > > From: "Martin Bjorklund" mbj@tail-f.com
> > > Sent: Thursday, December 27, 2018 12:08 PM
> > > 
> > > > tom petch  wrote:
> > > > > Martin
> > > > > 
> > > > > The Acknowledgements for
> > > > > draft-ietf-softwire-yang-13
> > > > > thank you for your work on this I-D (on the IESG Telechat for
> 10th
> > > > > January 2019) so can you tell me where my YANG is going wrong.
> > > > > 
> > > > > The module has
> > > > >   augment "/if:interfaces/if:interface" {
> > > > >     when "derived-from(if:type, 'iana-tunnel-type:aplusp')";
> > > > > and defines aplusp as a tunnel type in section 10.
> > > > > 
> > > > > A suggestion I made last October was to have a base for the three
> > > > > protocols covered here - MAP-E, MAP-T, Lw406 - and then derive
> three
> > > > > separate entities therefrom for the three protocols; I can see no
> > > > > derivation.  In which case, when is
> > > > > 
> > > > >     when "derived-from(if:type, 'iana-tunnel-type:aplusp')";
> > > > > 
> > > > > going to be true?
> > > > 
> > > > Right; either they have to define derived identities as you
> suggested,
> > > > or this need to change to 'derived-from-or-self'.
> > > 
> > > ... or drop the 'derived' altogether; if there is only 'aplusp', as
> at
> > > present, then I see no need for 'derived' and inserting one
> > > unnecessarily leaves scope for a future addition to be true when it
> is
> > > not wanted.  I can see it either way.
> > 
> > Do you mean writing something like
> > 
> >     when "if:type = 'iana-tunnel-type:aplusp'";
> > 
> > ?
> > 
> > This is brittle and shouldn't be used because it is a plain string
> > equality test and the result depends (in XML representation) on the
> > prefix that is declared for the namespace URI of the iana-tunnel-type
> > module.
> > 
> > It is true that derived-from/derived-from-or-self leaves scope for
> > future additions. However, if ever an identity is defined that
> > is derived from 'iana-tunnel-type:aplusp', then it IMO makes sense
> only
> > if the properties of the latter are inherited, so the "when" test
> > should still be true (and the augment applicable).
> 
> Lada
> 
> Thanks for that; I did indeed have the string equality test in mind,
> even though RFC8407 says otherwise.  I think that all this is too
> complicated, for me if not for the authors of I-D coming out of the

I agree it is complicated. On the other hand, using the string equality for
identities can lead to mysterious failures.

> Routing Area - I-D such as this one have already have several makeovers,
> courtesy of such as Martin and I, and for this in its present form to be
> on the next IESG Telechat - well, par for the course.
> 
> On a different tack, I was looking at teas-types and seeing
> uses path-objective-function_config
> Hang on, is underscore valid? Yes, but why use it? RFC8407 suggests do
> not.

Maybe the use of the underscore has some meaning? I personally woudn't be so
strict regarding naming conventions, as long as it makes sense to the module
authors and users. And as Randy Presuhn recently explained, there may in fact be
no practical difference between RFC 2119 terms MAY and SHOULD in cases like
this.

> or
>     type union {
>         type string {  length 0; // empty string      }
>         type string {  pattern ...
> and thinking why?  With no length restriction on the pattern, what does
> the complexity of a YANG union add?

It is either an empty string or a string matching the pattern. Of course, it
would be possible to make the pattern match an empty string.

> or
>   description  "Then index of the label restriction list entry."; }
>     container label-start {
>       must "not(../label-end/te-label/direction) or "
>         + "not(te-label/direction) "
>         + "or ../label-end/te-label/direction = te-label/direction" {
>         error-message "label-start and label-end must have the same
> direction.";
> where the error message tells me what is going on (not the description)
> but I wondered about the second 'not'  which I asssume is to cater for
>  "(te-label/direction) "
> not having a value.  All they want is
> 'start direction must = end direction'
> but it seems you need to be a contortionist to get there.

A simpler way to express this could be

    must "not(../label-end/te-label/direction != te-label/direction)"

The inequality test turns false if either of the terms doesn't exist.

Lada

> 
> I would appreciate any comment on this last - is there a simpler way of
> doing it?   After which, I shall return to lurking.
> 
> Tom Petch
> 
> > Lada
> > 
> > > Tom Petch
> > > 
> > > > /martin
> > > > 
> > > 
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Fri Dec 28 07:38:04 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71937130DDA for ; Fri, 28 Dec 2018 07:38:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.197
X-Spam-Level: ***
X-Spam-Status: No, score=3.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sq4HPSYYTLFf for ; Fri, 28 Dec 2018 07:38:01 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30118.outbound.protection.outlook.com [40.107.3.118]) (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 A938812D84C for ; Fri, 28 Dec 2018 07:38:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1Dat+YSNMWRX4NmuSJX8m1XnNjbUUFaNFJDQmgug/IA=; b=DE9MM9q7xz/ZMK2/qnEU9ScZbLeI9UDioej0vq7ChGLPL2T5Swy1EyvHIhPCcGi4eSTDLNKYjZED5PUmHcWwn0O7pdq+xvWmqHxtnCDouTLOOA6PljHpwoH0D7hNVkUgu0ZTQpn/SLaYCsRLAmbBU/2w+qlvQBxJJoZP0PqHiJ8=
Received: from AM0PR07MB5506.eurprd07.prod.outlook.com (20.178.23.17) by AM0PR07MB4513.eurprd07.prod.outlook.com (52.135.151.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1471.14; Fri, 28 Dec 2018 15:37:58 +0000
Received: from AM0PR07MB5506.eurprd07.prod.outlook.com ([fe80::4435:9a03:4e44:c258]) by AM0PR07MB5506.eurprd07.prod.outlook.com ([fe80::4435:9a03:4e44:c258%4]) with mapi id 15.20.1471.019; Fri, 28 Dec 2018 15:37:58 +0000
From: tom petch 
To: Ladislav Lhotka , Martin Bjorklund 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] draft-ietf-softwire-yang-13
Thread-Index: AQHUnfWuzVXJFxSfFEa3jgnayWbDRg==
Date: Fri, 28 Dec 2018 15:37:58 +0000
Message-ID: <003701d49ec3$479bef40$4001a8c0@gateway.2wire.net>
References:  <20181218.171018.1430858087061589506.mbj@tail-f.com> <01e801d49ba8$d6181320$4001a8c0@gateway.2wire.net> <20181227.130836.708030498710454309.mbj@tail-f.com> <003601d49df5$a7d094c0$4001a8c0@gateway.2wire.net> <87d0pm149u.fsf@nic.cz> <00be01d49ea1$6a0f5520$4001a8c0@gateway.2wire.net> <0687c7291fba3b69336cb7e4a12c640b49cb75ea.camel@nic.cz>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-clientproxiedby: LO2P265CA0303.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a5::27) To AM0PR07MB5506.eurprd07.prod.outlook.com (2603:10a6:208:103::17)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [86.139.215.184]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB4513; 6:Ho6w3J1onEKlqwJCFedysvm6KNN0ZDEMMAcOqyZ1I0nzQLkavcfzUs4TgisnMxJig3XClK0IdLUyvPFbuOLxeugkchqEAwglBK7+6R8CYj5+e/mwzOle4Xl13UhCk3p6o7iluSphg4dgKOMT3Rghh97tR7cfEQPTpI60vBQHSW/sGeOrfmECMRqhYqc3EV7NRiD2q41kiXVOfZ4jBwbtZeJJLxP0wPNoRxQfg+04W6BZULS+d3mgUjfxMwKHjId57GaFjsj57IDFzu2L/2MOaeJvz74MqQ9dDrgWLM3eB7hD/Z8bdVgHgCOrgjvGtAVo5T10YEl7Qc4o8citO/i3uqiszSKK2YWORHqUlbhpLX5n6oD9CWkTBe8HlONAm06PP8Mn66HmDlvD/gW5bDGWJySb75NczLmX1Ak06aEDdlIpduRmQoOieyvNRIKswXgN7bk5Jlz03sPNE1SrueX1Bw==; 5:kLbIwigxxiOH5BpggKBSd9K0aLh6FQu36KCcgULc0kND+UZHY7YuCzMv2vLzSutnNsjR7VwuB9xE46jMcDhCnTw4c1DVZXkpzaOhbQCGGJUj0n7skMjXpyQYDXq1TMNfaxafsz41vHCuU0kVqlSCkiZupV1taVCX/1nxm2dcpIE=; 7:p3rg/+T78DNdpXoIezMYnPUf3T1Kr9Tth9VzXosdsLztbKobUaO12md/WFCBr/ALrkeJ5J7rH4Zuh+6Pl/lU9aA9UbwxFvl63Cxc3g9gDeHfA3Ucnqx87tDI6duG4bfydpcZ0JD27FJY3fEeHRP1+Q==
x-ms-office365-filtering-correlation-id: caebfb77-e62a-4396-9142-08d66cda7166
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600109)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM0PR07MB4513; 
x-ms-traffictypediagnostic: AM0PR07MB4513:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(3230021)(908002)(999002)(5005026)(6040522)(2401047)(8121501046)(93006095)(93001095)(3231475)(944501520)(52105112)(10201501046)(3002001)(6055026)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB4513; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4513; 
x-forefront-prvs: 09007040D4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(366004)(396003)(136003)(376002)(13464003)(189003)(199004)(9686003)(6512007)(97736004)(81166006)(256004)(4001150100001)(106356001)(6486002)(6436002)(446003)(53936002)(33896004)(8676002)(4326008)(105586002)(76176011)(93886005)(229853002)(8936002)(25786009)(84392002)(386003)(14496001)(44736005)(6506007)(1556002)(186003)(99286004)(102836004)(71190400001)(52116002)(114624004)(26005)(81156014)(478600001)(486006)(68736007)(476003)(5660300001)(6246003)(7736002)(66066001)(316002)(110136005)(305945005)(3846002)(71200400001)(86152003)(6116002)(2906002)(86362001)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4513; H:AM0PR07MB5506.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; 
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: BSC4NrG8kE7U1PgdqRAFtevu3KkZtjU39jHuyLGg9KvGE+HkE25JYijENuDjDTO489fjrAWdIAdm4mc9gQOG+qQyo1+c2WU9uYIDNtcaaR5tG98L/M5Ppt1rVKG8KjYm6yaDjUZbjxFQT1HD8aQpx7hCBJCCvSZFVTwt/wH8XJz+kgjHcLngcR2wmumvWlbqKLqGH3dnwTmGtP8sI8iwVP5m1gf9Ua6S0jrDP1zdr1ETlT6X/PR/HL8LC4UEOPbFPVr/GsFl1EkgfitSIipYXTfrdwbZfE98Mxpjsw9ltduM55FQfitIAigHEEYe7MXs
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: caebfb77-e62a-4396-9142-08d66cda7166
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Dec 2018 15:37:58.4404 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4513
Archived-At: 
Subject: Re: [netmod] draft-ietf-softwire-yang-13
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 28 Dec 2018 15:38:03 -0000

LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkxhZGlzbGF2IExob3RrYSIgPGxo
b3RrYUBuaWMuY3o+DQpTZW50OiBGcmlkYXksIERlY2VtYmVyIDI4LCAyMDE4IDE6MDMgUE0NCg0K
PiBPbiBGcmksIDIwMTgtMTItMjggYXQgMTE6MzUgKzAwMDAsIHRvbSBwZXRjaCB3cm90ZToNCj4g
PiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID4gRnJvbTogIkxhZGlzbGF2IExob3Rr
YSIgPGxob3RrYUBuaWMuY3o+DQo+ID4gU2VudDogRnJpZGF5LCBEZWNlbWJlciAyOCwgMjAxOCA3
OjQ3IEFNDQoNCjxzbmlwPg0KDQogT24gYSBkaWZmZXJlbnQgdGFjaywgSSB3YXMgbG9va2luZyBh
dCB0ZWFzLXR5cGVzIGFuZCBzZWVpbmcNCj4gPiB1c2VzIHBhdGgtb2JqZWN0aXZlLWZ1bmN0aW9u
X2NvbmZpZw0KPiA+IEhhbmcgb24sIGlzIHVuZGVyc2NvcmUgdmFsaWQ/IFllcywgYnV0IHdoeSB1
c2UgaXQ/IFJGQzg0MDcgc3VnZ2VzdHMNCmRvDQo+ID4gbm90Lg0KPg0KPiBNYXliZSB0aGUgdXNl
IG9mIHRoZSB1bmRlcnNjb3JlIGhhcyBzb21lIG1lYW5pbmc/IEkgcGVyc29uYWxseSB3b3Vkbid0
DQpiZSBzbw0KPiBzdHJpY3QgcmVnYXJkaW5nIG5hbWluZyBjb252ZW50aW9ucywgYXMgbG9uZyBh
cyBpdCBtYWtlcyBzZW5zZSB0byB0aGUNCm1vZHVsZQ0KPiBhdXRob3JzIGFuZCB1c2Vycy4gQW5k
IGFzIFJhbmR5IFByZXN1aG4gcmVjZW50bHkgZXhwbGFpbmVkLCB0aGVyZSBtYXkNCmluIGZhY3Qg
YmUNCj4gbm8gcHJhY3RpY2FsIGRpZmZlcmVuY2UgYmV0d2VlbiBSRkMgMjExOSB0ZXJtcyBNQVkg
YW5kIFNIT1VMRCBpbiBjYXNlcw0KbGlrZQ0KPiB0aGlzLg0KPg0KPiA+IG9yDQo+ID4gICAgIHR5
cGUgdW5pb24gew0KPiA+ICAgICAgICAgdHlwZSBzdHJpbmcgeyAgbGVuZ3RoIDA7IC8vIGVtcHR5
IHN0cmluZyAgICAgIH0NCj4gPiAgICAgICAgIHR5cGUgc3RyaW5nIHsgIHBhdHRlcm4gLi4uDQo+
ID4gYW5kIHRoaW5raW5nIHdoeT8gIFdpdGggbm8gbGVuZ3RoIHJlc3RyaWN0aW9uIG9uIHRoZSBw
YXR0ZXJuLCB3aGF0DQpkb2VzDQo+ID4gdGhlIGNvbXBsZXhpdHkgb2YgYSBZQU5HIHVuaW9uIGFk
ZD8NCj4NCj4gSXQgaXMgZWl0aGVyIGFuIGVtcHR5IHN0cmluZyBvciBhIHN0cmluZyBtYXRjaGlu
ZyB0aGUgcGF0dGVybi4gT2YNCmNvdXJzZSwgaXQNCj4gd291bGQgYmUgcG9zc2libGUgdG8gbWFr
ZSB0aGUgcGF0dGVybiBtYXRjaCBhbiBlbXB0eSBzdHJpbmcuDQo+DQo+ID4gb3INCj4gPiAgIGRl
c2NyaXB0aW9uICAiVGhlbiBpbmRleCBvZiB0aGUgbGFiZWwgcmVzdHJpY3Rpb24gbGlzdCBlbnRy
eS4iOyB9DQo+ID4gICAgIGNvbnRhaW5lciBsYWJlbC1zdGFydCB7DQo+ID4gICAgICAgbXVzdCAi
bm90KC4uL2xhYmVsLWVuZC90ZS1sYWJlbC9kaXJlY3Rpb24pIG9yICINCj4gPiAgICAgICAgICsg
Im5vdCh0ZS1sYWJlbC9kaXJlY3Rpb24pICINCj4gPiAgICAgICAgICsgIm9yIC4uL2xhYmVsLWVu
ZC90ZS1sYWJlbC9kaXJlY3Rpb24gPSB0ZS1sYWJlbC9kaXJlY3Rpb24iDQp7DQo+ID4gICAgICAg
ICBlcnJvci1tZXNzYWdlICJsYWJlbC1zdGFydCBhbmQgbGFiZWwtZW5kIG11c3QgaGF2ZSB0aGUg
c2FtZQ0KPiA+IGRpcmVjdGlvbi4iOw0KPiA+IHdoZXJlIHRoZSBlcnJvciBtZXNzYWdlIHRlbGxz
IG1lIHdoYXQgaXMgZ29pbmcgb24gKG5vdCB0aGUNCmRlc2NyaXB0aW9uKQ0KPiA+IGJ1dCBJIHdv
bmRlcmVkIGFib3V0IHRoZSBzZWNvbmQgJ25vdCcgIHdoaWNoIEkgYXNzc3VtZSBpcyB0byBjYXRl
cg0KZm9yDQo+ID4gICIodGUtbGFiZWwvZGlyZWN0aW9uKSAiDQo+ID4gbm90IGhhdmluZyBhIHZh
bHVlLiAgQWxsIHRoZXkgd2FudCBpcw0KPiA+ICdzdGFydCBkaXJlY3Rpb24gbXVzdCA9IGVuZCBk
aXJlY3Rpb24nDQo+ID4gYnV0IGl0IHNlZW1zIHlvdSBuZWVkIHRvIGJlIGEgY29udG9ydGlvbmlz
dCB0byBnZXQgdGhlcmUuDQo+DQo+IEEgc2ltcGxlciB3YXkgdG8gZXhwcmVzcyB0aGlzIGNvdWxk
IGJlDQo+DQo+ICAgICBtdXN0ICJub3QoLi4vbGFiZWwtZW5kL3RlLWxhYmVsL2RpcmVjdGlvbiAh
PSB0ZS1sYWJlbC9kaXJlY3Rpb24pIg0KPg0KPiBUaGUgaW5lcXVhbGl0eSB0ZXN0IHR1cm5zIGZh
bHNlIGlmIGVpdGhlciBvZiB0aGUgdGVybXMgZG9lc24ndCBleGlzdC4NCg0KQWggeWVzLCB0aGFu
a3MgZm9yIHRoYXQ7IEkgd2FzIG1pc3NpbmcgdGhlIGZhY3QgdGhhdCBub24tZXhpc3RlbnQgdGVy
bXMNCm1ha2UgdGhlIGluZXF1YWxpdHkgZmFsc2UuDQoNClRvbSBQZXRjaA0KDQo+IExhZGENCj4N
Cj4gPg0KPiA+IEkgd291bGQgYXBwcmVjaWF0ZSBhbnkgY29tbWVudCBvbiB0aGlzIGxhc3QgLSBp
cyB0aGVyZSBhIHNpbXBsZXIgd2F5DQpvZg0KPiA+IGRvaW5nIGl0PyAgIEFmdGVyIHdoaWNoLCBJ
IHNoYWxsIHJldHVybiB0byBsdXJraW5nLg0KPiA+DQo+ID4gVG9tIFBldGNoDQo+ID4NCj4gPiA+
IExhZGENCj4gPiA+DQo+ID4gPiA+IFRvbSBQZXRjaA0KPiA+ID4gPg0KPiA+ID4gPiA+IC9tYXJ0
aW4NCj4gPiA+ID4gPg0KPiA+ID4gPg0KPiBMYWRpc2xhdiBMaG90a2ENCj4gSGVhZCwgQ1ouTklD
IExhYnMNCj4gUEdQIEtleSBJRDogMHhCOEY5MkIwOEE5Rjc2QzY3DQo+DQoNCg==


From nobody Mon Dec 31 04:29:40 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B560128AFB for ; Mon, 31 Dec 2018 04:29:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.196
X-Spam-Level: ***
X-Spam-Status: No, score=3.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CiTacyC-6rr for ; Mon, 31 Dec 2018 04:29:37 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30106.outbound.protection.outlook.com [40.107.3.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 BE92712875B for ; Mon, 31 Dec 2018 04:29:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3jVeSUCnIQBK8+thDUlOWF9ZcHPcpZHwdC5OnrTC8oE=; b=h2IwxbY7pOmre8g7b++SPHTtMSVM4af3FEf1EZ/7WYqDxrM+9t2wHhB30YcRYMlZH78N9u2bwd//xRU4XUPN+yh1cK1FUwcQOiZthirs2v7hUEk2PXcAgQ0h7zZ5sb+X6BBcc/KI9vvEm4oD+KQOqbtSODfLwWq1mk3PRVtPDe8=
Received: from AM0PR07MB5506.eurprd07.prod.outlook.com (20.178.23.17) by AM0PR07MB5313.eurprd07.prod.outlook.com (20.178.20.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1495.6; Mon, 31 Dec 2018 12:29:34 +0000
Received: from AM0PR07MB5506.eurprd07.prod.outlook.com ([fe80::30d7:2d62:cf50:fb2a]) by AM0PR07MB5506.eurprd07.prod.outlook.com ([fe80::30d7:2d62:cf50:fb2a%2]) with mapi id 15.20.1495.005; Mon, 31 Dec 2018 12:29:34 +0000
From: tom petch 
To: Juergen Schoenwaelder , Martin Bjorklund 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AQHUoQR8a0aHOCdtV0m5DC1x05zucg==
Date: Mon, 31 Dec 2018 12:29:34 +0000
Message-ID: <02d201d4a104$72b82980$4001a8c0@gateway.2wire.net>
References:   <8aa6b9c7-7d08-9ceb-36be-a54234561667@ericsson.com> <20181130.112544.1021452038429209831.mbj@tail-f.com> <20181130115648.bho3ofouglhibgct@anna.jacobs.jacobs-university.de>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-clientproxiedby: LO2P265CA0268.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a1::16) To AM0PR07MB5506.eurprd07.prod.outlook.com (2603:10a6:208:103::17)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [86.139.215.184]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB5313; 6:zctzP/ALlsRky67A07cDUcDPYGq/nSYO2BxTFIWVU0ILxSqG92joHVHi/3b1uIiXe18J0W3uGX7tilNplHx/gUubVxS6o9RhoIdCe9B6mPPXtnUyTpkxelTlUGIyUdgEBew6cgKCGqAzsthqjVUMDJThLL10FZxi6fygqGPAo+/MfktX5xz1ELwA4etfj23RPycF8vKIdQj9/oe27EzV1Z+3n57kwT5FjcJyaXyfdbxBcdW8jZdOK7uS33Utgy4I1l3gZuWk8TZwy5voY6L1iAIPjf7c5YofwD3ZdVjebpfHRmmGXIOxeJCzNE5FbpiIWt6ebag5n9HT+9S7cnzfAbv8lROmnAQHM4wbqr8WZgMucyWjB/mxR5QqXSEGGo2lz0IMZJzzb/tl0tQMxUrWl0F6MFR0y+b9K8X9qJOfIT/EdYUMyYHkQz6SP3uOm9UOAy36ZXEdGx9RTk4c14oWug==; 5:ljDHC3oNczlVyU1/OUvCz04uEThaziJzdy5o5PpUHbw9RFTgXU05fUFL4Xq2NfkO8FZMk1Tyv/JA9/FjWv0DOH6wk8AS1MIiISgS1BaWeHFH5HG+bEDnuwkD/g0pdJ2bv4ahi68bIhlmO43o58uAxUbxgS44CyNO5Jetuey24J/0B9TS/l8LEGbRUP3cOYCoVDHcDUzvbm4BAHdwsgL8MQ==; 7:oZ+6L4VlUicCHuud7XXVV2lCTYv4FWg6zLHhEhgBHV5lvPf0H4aRfiBDKtz854j1Nutf8Dkmhddi1SRZmR4bjvMbzelpRyaEzQd2YwMoEOzxT1LXjNb9gGMHaWiPq5Wdobudr5oYup6c11YSAxhv/A==
x-ms-office365-filtering-correlation-id: 9245c5c8-fcdc-4e46-3852-08d66f1b9f03
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(2017052603328)(7193020); SRVR:AM0PR07MB5313; 
x-ms-traffictypediagnostic: AM0PR07MB5313:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(3230021)(908002)(999002)(5005026)(6040522)(8220055)(2401047)(8121501046)(3002001)(3231475)(944501520)(52105112)(10201501046)(93006095)(93001095)(6055026)(6041310)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:AM0PR07MB5313; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB5313; 
x-forefront-prvs: 0903DD1D85
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(346002)(376002)(396003)(136003)(189003)(199004)(13464003)(4001150100001)(53546011)(229853002)(6116002)(44736005)(71190400001)(71200400001)(102836004)(6246003)(966005)(52116002)(86152003)(25786009)(99286004)(4326008)(386003)(256004)(14444005)(86362001)(6506007)(106356001)(6486002)(3846002)(105586002)(97736004)(53936002)(68736007)(66066001)(316002)(14496001)(110136005)(7736002)(14454004)(6306002)(33896004)(5660300001)(26005)(2906002)(66574012)(305945005)(1556002)(478600001)(486006)(84392002)(6436002)(76176011)(476003)(6512007)(8936002)(81156014)(81166006)(9686003)(93886005)(8676002)(186003)(446003)(6346003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB5313; H:AM0PR07MB5506.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; 
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: mhzjN8LTUfCwgG8C/iEADPtnOIiIie22CR5VWYlociUctu8hbXjSOKQlrOYgr7lbFJBI5mzm40yjTL+ofcNx5EcehStRo5UrLcmE4PaChHrWoX0kXC0hZ+qzbo/752zIyGWd8lD4rnC7XydUQuh259kV19cRft79v/vzF1RuXvAlwO1OiwvsFhouR0zTY/odtL06I0LIDJk1XJroKGxLuNTCUSzjfeLTWyhtJ2t7zy5gwvo2x5bR8y1/PGYx73HsJqaPXkc+ODMR5sbofIlDuzWLqtZVzY9+odE6HIhuWSLyFafxwrtkoy5L4LpnsAe/
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9245c5c8-fcdc-4e46-3852-08d66f1b9f03
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Dec 2018 12:29:34.3811 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5313
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Dec 2018 12:29:39 -0000

TWFueSAobW9zdD8pIHJvdXRpbmcgcHJvdG9jb2xzIGludHJvZHVjZSBhIHN0YXRlIC0gdXAsIGRv
d24gKy0gY29taW5nDQp1cCwgZ29pbmcgZG93biwgbWFpbnRlbmFuY2UgYW5kIHN1Y2ggbGlrZSwg
dXNlZCBmb3IgaW50ZXJmYWNlcywgdHVubmVscywNCmFkamFjZW5jaWVzIGFuZCB0aGUgbGlrZS4g
IEl0IGlzIGEgc2hhbWUgdGhhdCB0aGVyZSBhcmUgc28gbWFueQ0KdmFyaWF0aW9ucyBvbiB0aGlz
IGFsdGhvdWdoIHRvIHNvbWUgZXh0ZW50IHRoaXMgcmVmbGVjdHMgdGhlIGRpZmZlcmVuY2VzDQpp
biB0aGUgcHJvdG9jb2xzLiAgQW5kIHNvbWUgdXNlIHR5cGVzLCBvdGhlcnMgaWRlbnRpdHkuDQoN
ClRvbSBQZXRjaA0KDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJKdWVy
Z2VuIFNjaG9lbndhZWxkZXIiIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+
DQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDMwLCAyMDE4IDExOjU2IEFNDQoNCj4gVGhpcyBpcyBh
bHJlYWR5IG9uIG15IGxpc3QgKHdhcyBhbHJlYWR5IHByb3Bvc2VkIGJ5IEJhbMOhenMpLg0KPg0K
PiAvanMNCj4NCj4gT24gRnJpLCBOb3YgMzAsIDIwMTggYXQgMTE6MjU6NDRBTSArMDEwMCwgTWFy
dGluIEJqb3JrbHVuZCB3cm90ZToNCj4gPiBCYWzDoXpzIExlbmd5ZWwgPGJhbGF6cy5sZW5neWVs
QGVyaWNzc29uLmNvbT4gd3JvdGU6DQo+ID4gPiBIZWxsbywNCj4gPiA+DQo+ID4gPiBJbiBhIHNp
bWlsYXIgbWFubmVyIHdlIGZvdW5kIG11bHRpcGxlIHVzZXMgZm9yIHRoZQ0KPiA+ID4gaWV0Zi1u
ZXRjb25mLWFjbTpub2RlLWluc3RhbmNlLWlkZW50aWZpZXIuIFdlDQo+ID4gPiBpbXBvcnRlZCBu
YWNtIGp1c3QgdG8gcmV1c2UgdGhpcyB0eXBlLg0KPiA+ID4gQW55b25lIGVsc2UgaW50ZXJlc3Rl
ZD8NCj4gPg0KPiA+IFllcywgdGhpcyBpcyBhIHVzZWZ1bCB0eXBlIHRoYXQgaXMgbm90IGp1c3Qg
TkFDTS1zcGVjaWZpYy4gIFdlIGFsc28NCj4gPiB1c2UgaW4gdmFyaW91cyBwbGFjZXMuDQo+ID4N
Cj4gPg0KPiA+IC9tYXJ0aW4NCj4gPg0KPiA+DQo+ID4gPg0KPiA+ID4gcmVnYXJkcyBCYWxhenMN
Cj4gPiA+DQo+ID4gPiBPbiAyMDE4LiAxMS4gMjkuIDEyOjAzLCBSb2JlcnQgV2lsdG9uIHdyb3Rl
Og0KPiA+ID4NCj4gPiA+ICBIaSBKdWVyZ2VuLA0KPiA+ID4NCj4gPiA+ICBZQU5HIGxpYnJhcnkg
Y3VycmVudGx5IGRlZmluZXMgdGhlIHR5cGUgInJldmlzaW9uLWlkZW50aWZlciIuIElzDQp0aGlz
IGEgdHlwZWRlZiB0aGF0IHNob3VsZA0KPiA+ID4gIGxvZ2ljYWxseSBtaWdyYXRlIHRvIHJmYzY5
OTFiaXM/DQo+ID4gPg0KPiA+ID4gIFRoYW5rcywNCj4gPiA+ICBSb2INCj4gPiA+DQo+ID4gPiAg
T24gMTQvMTEvMjAxOCAwODoxNiwgTGFkaXNsYXYgTGhvdGthIHdyb3RlOg0KPiA+ID4NCj4gPiA+
ICBPbiBXZWQsIDIwMTgtMTEtMTQgYXQgMDk6MTAgKzAxMDAsIE1hcnRpbiBCam9ya2x1bmQgd3Jv
dGU6DQo+ID4gPg0KPiA+ID4gIEhpLA0KPiA+ID4NCj4gPiA+ICBBbGV4IENhbXBiZWxsIDxBbGV4
LkNhbXBiZWxsQEF2aWF0bmV0LmNvbT4gd3JvdGU6DQo+ID4gPg0KPiA+ID4gIERvZXMgYSBwZXJj
ZW50YWdlIHJlYWxseSBuZWVkIGEgc2luZ2xlIHN0YW5kYXJkIHR5cGUgaW4gdGhlIGZpcnN0DQo+
ID4gPiAgcGxhY2U/IEhvdyBhYm91dCAidW5pdHMgcGVyY2VudDsiPw0KPiA+ID4NCj4gPiA+ICBB
dCB0aGlzIHBvaW50LCBhZnRlciBoZWFyaW5nIGFib3V0IGhvdyBkaWZmZXJlbnQgbW9kdWxlcyBo
YXZlDQo+ID4gPiAgZGlmZmVyaW5nIHJlcXVpcmVtZW50IG9uIHRoaXMgdHlwZSwgSSB0ZW5kIHRv
IGFncmVlLg0KPiA+ID4NCj4gPiA+ICArMQ0KPiA+ID4NCj4gPiA+ICBPciBldmVuICJ1bml0cyAl
OyINCj4gPiA+DQo+ID4gPiAgTGFkYQ0KPiA+ID4NCj4gPiA+ICAvbWFydGluDQo+ID4gPg0KPiA+
ID4gIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ICBGcm9t
OiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgQWNlZSBMaW5k
ZW0NCihhY2VlKQ0KPiA+ID4gIDxhY2VlQGNpc2NvLmNvbT4NCj4gPiA+ICBTZW50OiBXZWRuZXNk
YXksIDE0IE5vdmVtYmVyIDIwMTggNTowMyBhLm0uDQo+ID4gPiAgVG86IEp1ZXJnZW4gU2Nob2Vu
d2FlbGRlcjsgQmFsw6F6cyBMZW5neWVsDQo+ID4gPiAgQ2M6IE5FVE1PRCBXRw0KPiA+ID4gIFN1
YmplY3Q6IFJlOiBbbmV0bW9kXSBmb3IgYSBmdXR1cmUgcmZjNjk5MWJpcw0KPiA+ID4NCj4gPiA+
ICDvu79PbiAxMS8xMy8xOCwgOTowNyBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgSnVlcmdlbg0K
U2Nob2Vud2FlbGRlciINCj4gPiA+ICA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxm
IG9mDQo+ID4gPiAgai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToN
Cj4gPiA+DQo+ID4gPiAgT24gVHVlLCBOb3YgMTMsIDIwMTggYXQgMDE6MzM6MDFQTSArMDAwMCwg
QmFsw6F6cyBMZW5neWVsIHdyb3RlOg0KPiA+ID4gID4gSGVsbG8sDQo+ID4gPiAgPg0KPiA+ID4g
ID4gSW4gc29tZSBjYXNlcyBJIHdhbnQgYSBwZXJjZW50YWdlIHdpdGhvdXQgZnJhY3Rpb25zLiBU
aGlzIGNvdWxkDQpiZQ0KPiA+ID4gID4gZGVmaW5lZA0KPiA+ID4gID4gdXNpbmcgcmFuZ2UsIGJ5
IHNwZWNpZnlpbmcgdGhlIG51bWJlcnMgMCB8IDEgfCAyIC4uLiA5OSB8IDEwMA0KaW4gdGhlDQo+
ID4gPiAgPiByYW5nZSdzDQo+ID4gPiAgPiBhcmd1bWVudC4NCj4gPiA+ICA+DQo+ID4gPiAgPiB0
eXBlZGVmIHBlcmNlbnQtc2hvcnQgew0KPiA+ID4gID4gdHlwZSBwZXJjZW50IHsgcmFuZ2UgMCB8
IDEgfCAyIC4uLiA5OSB8IDEwMDsgfSAvLyBkaWRuJ3QgdHlwZQ0KPiA+ID4gIG91dA0KPiA+ID4g
ID4gYWxsIHRoZSAxMDEgaW50ZWdlciB2YWx1ZXMgOi0pDQo+ID4gPiAgPiB9DQo+ID4gPiAgPg0K
PiA+ID4NCj4gPiA+ICBJIGd1ZXNzIHdlIG5lZWQgdG8gc2V0dGxlIG9uIGEgc21hbGwgbnVtYmVy
IG9mIHBlcmNlbnRhZ2UgdHlwZXMNCnRoYXQNCj4gPiA+ICBwZW9wbGUgZmluZCB1c2VmdWwgYW5k
IHRoZW4gbW9kdWxlIGF1dGhvcnMgaG9wZWZ1bGx5IGZpbmQgd2hhdA0KdGhleQ0KPiA+ID4gIG5l
ZWQuIEkgYW0gbm90IHN1cmUgdGhhdCBsaXN0aW5nIDEwMSBudW1iZXJzIGlzIGEgZ29vZCBwYXR0
ZXJuIHRvDQp1c2UNCj4gPiA+ICAoYWx0aG91Z2ggaXQgZG9lcyBhY2hpZXZlIHdoYXQgeW91IHdh
bnQpLiBGb3IgcGVyY2VudGFnZXMgdGhhdA0KaGF2ZSBubw0KPiA+ID4gIGZyYWN0aW9uLCB5b3Ug
bGlrZWx5IHdhbnQgdG8gZGVyaXZlIGZyb20gYSBiYXNlIHR5cGUgdGhhdCBpcw0KZWZmaWNpZW50
DQo+ID4gPiAgdG8gZW5jb2RlIGZvciBiaW5hcnkgZW5jb2RpbmdzIHN1Y2ggYXMgQ0JPUi4NCj4g
PiA+DQo+ID4gPiAgT3Igc2ltcGx5IGRlZmluZSBhIHR5cGUgd2l0aCBhIGJhc2UgdHlwZSBvZiB1
bml0OCB0eXBlIGFuZCBhDQpyYW5nZSBvZg0KPiA+ID4gIDAtMTAwLg0KPiA+ID4NCj4gPiA+ICBB
Y2VlDQo+ID4gPg0KPiA+ID4gIC9qcw0KPiA+ID4NCj4gPiA+ICAtLQ0KPiA+ID4gIEp1ZXJnZW4g
U2Nob2Vud2FlbGRlciBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gPiA+ICBQaG9u
ZTogKzQ5IDQyMSAyMDAgMzU4NyBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFu
eQ0KPiA+ID4gIEZheDogKzQ5IDQyMSAyMDAgMzEwMyA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZl
cnNpdHkuZGUvPg0KPiA+ID4NCj4gPiA+ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPiA+ID4gIG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+ICBuZXRt
b2RAaWV0Zi5vcmcNCj4gPiA+ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L25ldG1vZA0KPiA+ID4NCj4gPiA+ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPiA+ID4gIG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+ICBuZXRtb2RA
aWV0Zi5vcmcNCj4gPiA+ICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l
dG1vZA0KPiA+ID4gIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQo+ID4gPiAgbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4gIG5ldG1vZEBpZXRmLm9yZw0K
PiA+ID4gIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4g
Pg0KPiA+ID4gIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQo+ID4gPiAgbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4gIG5ldG1vZEBpZXRmLm9yZw0KPiA+
ID4gIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4gPg0K
PiA+ID4gIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
ID4gPiAgbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4gIG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4g
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4gPg0KPiA+
ID4gLS0NCj4gPiA+IEJhbGF6cyBMZW5neWVsICAgICAgICAgICAgICAgICAgICAgICBFcmljc3Nv
biBIdW5nYXJ5IEx0ZC4NCj4gPiA+IFNlbmlvciBTcGVjaWFsaXN0DQo+ID4gPiBNb2JpbGU6ICsz
Ni03MC0zMzAtNzkwOSAgICAgICAgICAgICAgZW1haWw6DQpCYWxhenMuTGVuZ3llbEBlcmljc3Nv
bi5jb20NCj4NCj4gLS0NCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMg
VW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAg
ICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPiBGYXg6ICAgKzQ5IDQy
MSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+
DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5l
dG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+DQoNCg==


From nobody Mon Dec 31 04:48:06 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B57126CC7 for ; Mon, 31 Dec 2018 04:48:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VjkCuHo6kMqr for ; Mon, 31 Dec 2018 04:48:01 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE65F1200D7 for ; Mon, 31 Dec 2018 04:47:59 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 5A7DADB8; Mon, 31 Dec 2018 13:47:58 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id YKr3Uq0_mKac; Mon, 31 Dec 2018 13:47:58 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 31 Dec 2018 13:47:58 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 18D4320046; Mon, 31 Dec 2018 13:47:58 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IJ6C3-wOlDwK; Mon, 31 Dec 2018 13:47:57 +0100 (CET)
Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 5952A20045; Mon, 31 Dec 2018 13:47:57 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Mon, 31 Dec 2018 13:47:56 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 6CD1E3005407A6; Mon, 31 Dec 2018 13:47:56 +0100 (CET)
Date: Mon, 31 Dec 2018 13:47:56 +0100
From: Juergen Schoenwaelder 
To: tom petch 
CC: Martin Bjorklund , "netmod@ietf.org" 
Message-ID: <20181231124756.4ira47yirxjkbpon@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: tom petch , Martin Bjorklund , "netmod@ietf.org" 
References:   <8aa6b9c7-7d08-9ceb-36be-a54234561667@ericsson.com> <20181130.112544.1021452038429209831.mbj@tail-f.com> <20181130115648.bho3ofouglhibgct@anna.jacobs.jacobs-university.de> <02d201d4a104$72b82980$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <02d201d4a104$72b82980$4001a8c0@gateway.2wire.net>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Dec 2018 12:48:04 -0000

Tom,

since states are often protocol specific, I believe we are better off
with having states defined with protocol specific semantics. If you go
for generic states, then you end up with mappings of generic states to
protocol specific states, which are often non-trivial to get right and
meaningful.

/js

On Mon, Dec 31, 2018 at 12:29:34PM +0000, tom petch wrote:
> Many (most?) routing protocols introduce a state - up, down +- coming
> up, going down, maintenance and such like, used for interfaces, tunnels,
> adjacencies and the like.  It is a shame that there are so many
> variations on this although to some extent this reflects the differences
> in the protocols.  And some use types, others identity.
> 
> Tom Petch
> 
> 
> ----- Original Message -----
> From: "Juergen Schoenwaelder" 
> Sent: Friday, November 30, 2018 11:56 AM
> 
> > This is already on my list (was already proposed by Balázs).
> >
> > /js
> >
> > On Fri, Nov 30, 2018 at 11:25:44AM +0100, Martin Bjorklund wrote:
> > > Balázs Lengyel  wrote:
> > > > Hello,
> > > >
> > > > In a similar manner we found multiple uses for the
> > > > ietf-netconf-acm:node-instance-identifier. We
> > > > imported nacm just to reuse this type.
> > > > Anyone else interested?
> > >
> > > Yes, this is a useful type that is not just NACM-specific.  We also
> > > use in various places.
> > >
> > >
> > > /martin
> > >
> > >
> > > >
> > > > regards Balazs
> > > >
> > > > On 2018. 11. 29. 12:03, Robert Wilton wrote:
> > > >
> > > >  Hi Juergen,
> > > >
> > > >  YANG library currently defines the type "revision-identifer". Is
> this a typedef that should
> > > >  logically migrate to rfc6991bis?
> > > >
> > > >  Thanks,
> > > >  Rob
> > > >
> > > >  On 14/11/2018 08:16, Ladislav Lhotka wrote:
> > > >
> > > >  On Wed, 2018-11-14 at 09:10 +0100, Martin Bjorklund wrote:
> > > >
> > > >  Hi,
> > > >
> > > >  Alex Campbell  wrote:
> > > >
> > > >  Does a percentage really need a single standard type in the first
> > > >  place? How about "units percent;"?
> > > >
> > > >  At this point, after hearing about how different modules have
> > > >  differing requirement on this type, I tend to agree.
> > > >
> > > >  +1
> > > >
> > > >  Or even "units %;"
> > > >
> > > >  Lada
> > > >
> > > >  /martin
> > > >
> > > >  ________________________________________
> > > >  From: netmod  on behalf of Acee Lindem
> (acee)
> > > >  
> > > >  Sent: Wednesday, 14 November 2018 5:03 a.m.
> > > >  To: Juergen Schoenwaelder; Balázs Lengyel
> > > >  Cc: NETMOD WG
> > > >  Subject: Re: [netmod] for a future rfc6991bis
> > > >
> > > >  On 11/13/18, 9:07 AM, "netmod on behalf of Juergen
> Schoenwaelder"
> > > >   > > >  j.schoenwaelder@jacobs-university.de> wrote:
> > > >
> > > >  On Tue, Nov 13, 2018 at 01:33:01PM +0000, Balázs Lengyel wrote:
> > > >  > Hello,
> > > >  >
> > > >  > In some cases I want a percentage without fractions. This could
> be
> > > >  > defined
> > > >  > using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100
> in the
> > > >  > range's
> > > >  > argument.
> > > >  >
> > > >  > typedef percent-short {
> > > >  > type percent { range 0 | 1 | 2 ... 99 | 100; } // didn't type
> > > >  out
> > > >  > all the 101 integer values :-)
> > > >  > }
> > > >  >
> > > >
> > > >  I guess we need to settle on a small number of percentage types
> that
> > > >  people find useful and then module authors hopefully find what
> they
> > > >  need. I am not sure that listing 101 numbers is a good pattern to
> use
> > > >  (although it does achieve what you want). For percentages that
> have no
> > > >  fraction, you likely want to derive from a base type that is
> efficient
> > > >  to encode for binary encodings such as CBOR.
> > > >
> > > >  Or simply define a type with a base type of unit8 type and a
> range of
> > > >  0-100.
> > > >
> > > >  Acee
> > > >
> > > >  /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
> > > >  _______________________________________________
> > > >  netmod mailing list
> > > >  netmod@ietf.org
> > > >  https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > > >  _______________________________________________
> > > >  netmod mailing list
> > > >  netmod@ietf.org
> > > >  https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > > >  _______________________________________________
> > > >  netmod mailing list
> > > >  netmod@ietf.org
> > > >  https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > > > --
> > > > Balazs Lengyel                       Ericsson Hungary Ltd.
> > > > Senior Specialist
> > > > Mobile: +36-70-330-7909              email:
> Balazs.Lengyel@ericsson.com
> >
> > --
> > 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
> >
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Dec 31 05:21:52 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496DE127B4C for ; Mon, 31 Dec 2018 05:21:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC9L61f0UuD4 for ; Mon, 31 Dec 2018 05:21:48 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B831E126CC7 for ; Mon, 31 Dec 2018 05:21:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10100; q=dns/txt; s=iport; t=1546262508; x=1547472108; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=adieB+U0Svg+HUM9jtazf/WPa36w0yOnL/QC/UhOh7k=; b=JhAcVlD0D1p3HKHN45GC3yFaL8c1zmsnoMDGgJ5SFn1oPog1NjHfwWj9 x1kdFWsegGTTukND6SrnV28b0tMSupEb0ZNnU7gJMa7Nps+g+p+iO9FLd lM5lqgVK/yvDJW/aBcFMpUI0HJmy29y/XIbpWf1GXkClKWpKIuWIpg8GH 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAC4Fipc/4UNJK1aBgMZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBAYFRBAEBAQEBCwGCA2aBAicKg3SIGotwgg2XYxSBZws?= =?us-ascii?q?BARgLhANGAheCLCI0CQ0BAwEBAgEBAm0cDIVKAQEBAQMBASEROgsMAgICAQg?= =?us-ascii?q?OAgEEAQEBAgImAgICGQwLFQgIAQEEAQ0FgyIBggEPpQeBL4VBhFcFBYEGizQ?= =?us-ascii?q?XgX+BEScfgkyDHgEBgS4BCAoBHwcQChkNgkExgiYCoUsJApFnGJFmiVmQKQI?= =?us-ascii?q?RFIEnHzhlcXAVOyoBgkGGO4RhhT9BMYlggR+BHwEB?=
X-IronPort-AV: E=Sophos;i="5.56,422,1539648000"; d="scan'208";a="500475382"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Dec 2018 13:21:47 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id wBVDLkKo021849 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Dec 2018 13:21:47 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 31 Dec 2018 08:21:46 -0500
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Mon, 31 Dec 2018 08:21:46 -0500
From: "Acee Lindem (acee)" 
To: Juergen Schoenwaelder , tom petch 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AdR1b1B75pZToCjlLEK5aT+9YAPiFwrwaWcA//+1oYA=
Date: Mon, 31 Dec 2018 13:21:45 +0000
Message-ID: <6400EF80-F822-4BFE-9A47-FF8D73EE62CB@cisco.com>
References:   <8aa6b9c7-7d08-9ceb-36be-a54234561667@ericsson.com> <20181130.112544.1021452038429209831.mbj@tail-f.com> <20181130115648.bho3ofouglhibgct@anna.jacobs.jacobs-university.de> <02d201d4a104$72b82980$4001a8c0@gateway.2wire.net> <20181231124756.4ira47yirxjkbpon@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181231124756.4ira47yirxjkbpon@anna.jacobs.jacobs-university.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.152, xch-rtp-012.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Dec 2018 13:21:51 -0000

SGkgVG9tLCBKdWVyZ2VuLCANCkkgYWdyZWUgd2l0aCBKdWVyZ2VuIC0gd2Ugd2VudCB0aHJvdWdo
IHRoaXMgZGlzY3Vzc2lvbiB3aXRoIGlldGYtcm91dGluZy10eXBlcyAoUkZDIDgyOTQpIGFuZCBj
YW1lIHRvIHRoZSBzYW1lIGNvbmNsdXNpb24uIFdlIGtlcHQsIHRoZSBnZW5lcmljIGxpbmstYWNj
ZXNzLXR5cGUgZW51bSBidXQgSSBiZWxpZXZlIGl0IGlzLCBoZXJldG9mb3JlLCB1bnVzZWQuIA0K
VGhhbmtzLA0KQWNlZQ0KDQrvu79PbiAxMi8zMS8xOCwgNzo0OCBBTSwgIm5ldG1vZCBvbiBiZWhh
bGYgb2YgSnVlcmdlbiBTY2hvZW53YWVsZGVyIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24g
YmVoYWxmIG9mIGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQoN
CiAgICBUb20sDQogICAgDQogICAgc2luY2Ugc3RhdGVzIGFyZSBvZnRlbiBwcm90b2NvbCBzcGVj
aWZpYywgSSBiZWxpZXZlIHdlIGFyZSBiZXR0ZXIgb2ZmDQogICAgd2l0aCBoYXZpbmcgc3RhdGVz
IGRlZmluZWQgd2l0aCBwcm90b2NvbCBzcGVjaWZpYyBzZW1hbnRpY3MuIElmIHlvdSBnbw0KICAg
IGZvciBnZW5lcmljIHN0YXRlcywgdGhlbiB5b3UgZW5kIHVwIHdpdGggbWFwcGluZ3Mgb2YgZ2Vu
ZXJpYyBzdGF0ZXMgdG8NCiAgICBwcm90b2NvbCBzcGVjaWZpYyBzdGF0ZXMsIHdoaWNoIGFyZSBv
ZnRlbiBub24tdHJpdmlhbCB0byBnZXQgcmlnaHQgYW5kDQogICAgbWVhbmluZ2Z1bC4NCiAgICAN
CiAgICAvanMNCiAgICANCiAgICBPbiBNb24sIERlYyAzMSwgMjAxOCBhdCAxMjoyOTozNFBNICsw
MDAwLCB0b20gcGV0Y2ggd3JvdGU6DQogICAgPiBNYW55IChtb3N0Pykgcm91dGluZyBwcm90b2Nv
bHMgaW50cm9kdWNlIGEgc3RhdGUgLSB1cCwgZG93biArLSBjb21pbmcNCiAgICA+IHVwLCBnb2lu
ZyBkb3duLCBtYWludGVuYW5jZSBhbmQgc3VjaCBsaWtlLCB1c2VkIGZvciBpbnRlcmZhY2VzLCB0
dW5uZWxzLA0KICAgID4gYWRqYWNlbmNpZXMgYW5kIHRoZSBsaWtlLiAgSXQgaXMgYSBzaGFtZSB0
aGF0IHRoZXJlIGFyZSBzbyBtYW55DQogICAgPiB2YXJpYXRpb25zIG9uIHRoaXMgYWx0aG91Z2gg
dG8gc29tZSBleHRlbnQgdGhpcyByZWZsZWN0cyB0aGUgZGlmZmVyZW5jZXMNCiAgICA+IGluIHRo
ZSBwcm90b2NvbHMuICBBbmQgc29tZSB1c2UgdHlwZXMsIG90aGVycyBpZGVudGl0eS4NCiAgICA+
IA0KICAgID4gVG9tIFBldGNoDQogICAgPiANCiAgICA+IA0KICAgID4gLS0tLS0gT3JpZ2luYWwg
TWVzc2FnZSAtLS0tLQ0KICAgID4gRnJvbTogIkp1ZXJnZW4gU2Nob2Vud2FlbGRlciIgPGouc2No
b2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4NCiAgICA+IFNlbnQ6IEZyaWRheSwgTm92
ZW1iZXIgMzAsIDIwMTggMTE6NTYgQU0NCiAgICA+IA0KICAgID4gPiBUaGlzIGlzIGFscmVhZHkg
b24gbXkgbGlzdCAod2FzIGFscmVhZHkgcHJvcG9zZWQgYnkgQmFsw6F6cykuDQogICAgPiA+DQog
ICAgPiA+IC9qcw0KICAgID4gPg0KICAgID4gPiBPbiBGcmksIE5vdiAzMCwgMjAxOCBhdCAxMToy
NTo0NEFNICswMTAwLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KICAgID4gPiA+IEJhbMOhenMg
TGVuZ3llbCA8YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tPiB3cm90ZToNCiAgICA+ID4gPiA+
IEhlbGxvLA0KICAgID4gPiA+ID4NCiAgICA+ID4gPiA+IEluIGEgc2ltaWxhciBtYW5uZXIgd2Ug
Zm91bmQgbXVsdGlwbGUgdXNlcyBmb3IgdGhlDQogICAgPiA+ID4gPiBpZXRmLW5ldGNvbmYtYWNt
Om5vZGUtaW5zdGFuY2UtaWRlbnRpZmllci4gV2UNCiAgICA+ID4gPiA+IGltcG9ydGVkIG5hY20g
anVzdCB0byByZXVzZSB0aGlzIHR5cGUuDQogICAgPiA+ID4gPiBBbnlvbmUgZWxzZSBpbnRlcmVz
dGVkPw0KICAgID4gPiA+DQogICAgPiA+ID4gWWVzLCB0aGlzIGlzIGEgdXNlZnVsIHR5cGUgdGhh
dCBpcyBub3QganVzdCBOQUNNLXNwZWNpZmljLiAgV2UgYWxzbw0KICAgID4gPiA+IHVzZSBpbiB2
YXJpb3VzIHBsYWNlcy4NCiAgICA+ID4gPg0KICAgID4gPiA+DQogICAgPiA+ID4gL21hcnRpbg0K
ICAgID4gPiA+DQogICAgPiA+ID4NCiAgICA+ID4gPiA+DQogICAgPiA+ID4gPiByZWdhcmRzIEJh
bGF6cw0KICAgID4gPiA+ID4NCiAgICA+ID4gPiA+IE9uIDIwMTguIDExLiAyOS4gMTI6MDMsIFJv
YmVydCBXaWx0b24gd3JvdGU6DQogICAgPiA+ID4gPg0KICAgID4gPiA+ID4gIEhpIEp1ZXJnZW4s
DQogICAgPiA+ID4gPg0KICAgID4gPiA+ID4gIFlBTkcgbGlicmFyeSBjdXJyZW50bHkgZGVmaW5l
cyB0aGUgdHlwZSAicmV2aXNpb24taWRlbnRpZmVyIi4gSXMNCiAgICA+IHRoaXMgYSB0eXBlZGVm
IHRoYXQgc2hvdWxkDQogICAgPiA+ID4gPiAgbG9naWNhbGx5IG1pZ3JhdGUgdG8gcmZjNjk5MWJp
cz8NCiAgICA+ID4gPiA+DQogICAgPiA+ID4gPiAgVGhhbmtzLA0KICAgID4gPiA+ID4gIFJvYg0K
ICAgID4gPiA+ID4NCiAgICA+ID4gPiA+ICBPbiAxNC8xMS8yMDE4IDA4OjE2LCBMYWRpc2xhdiBM
aG90a2Egd3JvdGU6DQogICAgPiA+ID4gPg0KICAgID4gPiA+ID4gIE9uIFdlZCwgMjAxOC0xMS0x
NCBhdCAwOToxMCArMDEwMCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToNCiAgICA+ID4gPiA+DQog
ICAgPiA+ID4gPiAgSGksDQogICAgPiA+ID4gPg0KICAgID4gPiA+ID4gIEFsZXggQ2FtcGJlbGwg
PEFsZXguQ2FtcGJlbGxAQXZpYXRuZXQuY29tPiB3cm90ZToNCiAgICA+ID4gPiA+DQogICAgPiA+
ID4gPiAgRG9lcyBhIHBlcmNlbnRhZ2UgcmVhbGx5IG5lZWQgYSBzaW5nbGUgc3RhbmRhcmQgdHlw
ZSBpbiB0aGUgZmlyc3QNCiAgICA+ID4gPiA+ICBwbGFjZT8gSG93IGFib3V0ICJ1bml0cyBwZXJj
ZW50OyI/DQogICAgPiA+ID4gPg0KICAgID4gPiA+ID4gIEF0IHRoaXMgcG9pbnQsIGFmdGVyIGhl
YXJpbmcgYWJvdXQgaG93IGRpZmZlcmVudCBtb2R1bGVzIGhhdmUNCiAgICA+ID4gPiA+ICBkaWZm
ZXJpbmcgcmVxdWlyZW1lbnQgb24gdGhpcyB0eXBlLCBJIHRlbmQgdG8gYWdyZWUuDQogICAgPiA+
ID4gPg0KICAgID4gPiA+ID4gICsxDQogICAgPiA+ID4gPg0KICAgID4gPiA+ID4gIE9yIGV2ZW4g
InVuaXRzICU7Ig0KICAgID4gPiA+ID4NCiAgICA+ID4gPiA+ICBMYWRhDQogICAgPiA+ID4gPg0K
ICAgID4gPiA+ID4gIC9tYXJ0aW4NCiAgICA+ID4gPiA+DQogICAgPiA+ID4gPiAgX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gPiA+ID4gIEZyb206IG5ldG1v
ZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBBY2VlIExpbmRlbQ0KICAg
ID4gKGFjZWUpDQogICAgPiA+ID4gPiAgPGFjZWVAY2lzY28uY29tPg0KICAgID4gPiA+ID4gIFNl
bnQ6IFdlZG5lc2RheSwgMTQgTm92ZW1iZXIgMjAxOCA1OjAzIGEubS4NCiAgICA+ID4gPiA+ICBU
bzogSnVlcmdlbiBTY2hvZW53YWVsZGVyOyBCYWzDoXpzIExlbmd5ZWwNCiAgICA+ID4gPiA+ICBD
YzogTkVUTU9EIFdHDQogICAgPiA+ID4gPiAgU3ViamVjdDogUmU6IFtuZXRtb2RdIGZvciBhIGZ1
dHVyZSByZmM2OTkxYmlzDQogICAgPiA+ID4gPg0KICAgID4gPiA+ID4gIE9uIDExLzEzLzE4LCA5
OjA3IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBKdWVyZ2VuDQogICAgPiBTY2hvZW53YWVsZGVy
Ig0KICAgID4gPiA+ID4gIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YNCiAg
ICA+ID4gPiA+ICBqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0K
ICAgID4gPiA+ID4NCiAgICA+ID4gPiA+ICBPbiBUdWUsIE5vdiAxMywgMjAxOCBhdCAwMTozMzow
MVBNICswMDAwLCBCYWzDoXpzIExlbmd5ZWwgd3JvdGU6DQogICAgPiA+ID4gPiAgPiBIZWxsbywN
CiAgICA+ID4gPiA+ICA+DQogICAgPiA+ID4gPiAgPiBJbiBzb21lIGNhc2VzIEkgd2FudCBhIHBl
cmNlbnRhZ2Ugd2l0aG91dCBmcmFjdGlvbnMuIFRoaXMgY291bGQNCiAgICA+IGJlDQogICAgPiA+
ID4gPiAgPiBkZWZpbmVkDQogICAgPiA+ID4gPiAgPiB1c2luZyByYW5nZSwgYnkgc3BlY2lmeWlu
ZyB0aGUgbnVtYmVycyAwIHwgMSB8IDIgLi4uIDk5IHwgMTAwDQogICAgPiBpbiB0aGUNCiAgICA+
ID4gPiA+ICA+IHJhbmdlJ3MNCiAgICA+ID4gPiA+ICA+IGFyZ3VtZW50Lg0KICAgID4gPiA+ID4g
ID4NCiAgICA+ID4gPiA+ICA+IHR5cGVkZWYgcGVyY2VudC1zaG9ydCB7DQogICAgPiA+ID4gPiAg
PiB0eXBlIHBlcmNlbnQgeyByYW5nZSAwIHwgMSB8IDIgLi4uIDk5IHwgMTAwOyB9IC8vIGRpZG4n
dCB0eXBlDQogICAgPiA+ID4gPiAgb3V0DQogICAgPiA+ID4gPiAgPiBhbGwgdGhlIDEwMSBpbnRl
Z2VyIHZhbHVlcyA6LSkNCiAgICA+ID4gPiA+ICA+IH0NCiAgICA+ID4gPiA+ICA+DQogICAgPiA+
ID4gPg0KICAgID4gPiA+ID4gIEkgZ3Vlc3Mgd2UgbmVlZCB0byBzZXR0bGUgb24gYSBzbWFsbCBu
dW1iZXIgb2YgcGVyY2VudGFnZSB0eXBlcw0KICAgID4gdGhhdA0KICAgID4gPiA+ID4gIHBlb3Bs
ZSBmaW5kIHVzZWZ1bCBhbmQgdGhlbiBtb2R1bGUgYXV0aG9ycyBob3BlZnVsbHkgZmluZCB3aGF0
DQogICAgPiB0aGV5DQogICAgPiA+ID4gPiAgbmVlZC4gSSBhbSBub3Qgc3VyZSB0aGF0IGxpc3Rp
bmcgMTAxIG51bWJlcnMgaXMgYSBnb29kIHBhdHRlcm4gdG8NCiAgICA+IHVzZQ0KICAgID4gPiA+
ID4gIChhbHRob3VnaCBpdCBkb2VzIGFjaGlldmUgd2hhdCB5b3Ugd2FudCkuIEZvciBwZXJjZW50
YWdlcyB0aGF0DQogICAgPiBoYXZlIG5vDQogICAgPiA+ID4gPiAgZnJhY3Rpb24sIHlvdSBsaWtl
bHkgd2FudCB0byBkZXJpdmUgZnJvbSBhIGJhc2UgdHlwZSB0aGF0IGlzDQogICAgPiBlZmZpY2ll
bnQNCiAgICA+ID4gPiA+ICB0byBlbmNvZGUgZm9yIGJpbmFyeSBlbmNvZGluZ3Mgc3VjaCBhcyBD
Qk9SLg0KICAgID4gPiA+ID4NCiAgICA+ID4gPiA+ICBPciBzaW1wbHkgZGVmaW5lIGEgdHlwZSB3
aXRoIGEgYmFzZSB0eXBlIG9mIHVuaXQ4IHR5cGUgYW5kIGENCiAgICA+IHJhbmdlIG9mDQogICAg
PiA+ID4gPiAgMC0xMDAuDQogICAgPiA+ID4gPg0KICAgID4gPiA+ID4gIEFjZWUNCiAgICA+ID4g
PiA+DQogICAgPiA+ID4gPiAgL2pzDQogICAgPiA+ID4gPg0KICAgID4gPiA+ID4gIC0tDQogICAg
PiA+ID4gPiAgSnVlcmdlbiBTY2hvZW53YWVsZGVyIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBn
R21iSA0KICAgID4gPiA+ID4gIFBob25lOiArNDkgNDIxIDIwMCAzNTg3IENhbXB1cyBSaW5nIDEg
fCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQogICAgPiA+ID4gPiAgRmF4OiArNDkgNDIxIDIwMCAz
MTAzIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQogICAgPiA+ID4gPg0KICAg
ID4gPiA+ID4gIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQogICAgPiA+ID4gPiAgbmV0bW9kIG1haWxpbmcgbGlzdA0KICAgID4gPiA+ID4gIG5ldG1vZEBp
ZXRmLm9yZw0KICAgID4gPiA+ID4gIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vbmV0bW9kDQogICAgPiA+ID4gPg0KICAgID4gPiA+ID4gIF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiA+ID4gPiAgbmV0bW9kIG1haWxpbmcg
bGlzdA0KICAgID4gPiA+ID4gIG5ldG1vZEBpZXRmLm9yZw0KICAgID4gPiA+ID4gIGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQogICAgPiA+ID4gPiAgX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ID4gPiA+ICBu
ZXRtb2QgbWFpbGluZyBsaXN0DQogICAgPiA+ID4gPiAgbmV0bW9kQGlldGYub3JnDQogICAgPiA+
ID4gPiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICA+
ID4gPiA+DQogICAgPiA+ID4gPiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCiAgICA+ID4gPiA+ICBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAgPiA+ID4g
PiAgbmV0bW9kQGlldGYub3JnDQogICAgPiA+ID4gPiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICA+ID4gPiA+DQogICAgPiA+ID4gPiAgX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ID4gPiA+ICBuZXRt
b2QgbWFpbGluZyBsaXN0DQogICAgPiA+ID4gPiAgbmV0bW9kQGlldGYub3JnDQogICAgPiA+ID4g
PiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICA+ID4g
PiA+DQogICAgPiA+ID4gPiAtLQ0KICAgID4gPiA+ID4gQmFsYXpzIExlbmd5ZWwgICAgICAgICAg
ICAgICAgICAgICAgIEVyaWNzc29uIEh1bmdhcnkgTHRkLg0KICAgID4gPiA+ID4gU2VuaW9yIFNw
ZWNpYWxpc3QNCiAgICA+ID4gPiA+IE1vYmlsZTogKzM2LTcwLTMzMC03OTA5ICAgICAgICAgICAg
ICBlbWFpbDoNCiAgICA+IEJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbQ0KICAgID4gPg0KICAg
ID4gPiAtLQ0KICAgID4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBV
bml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KICAgID4gPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAg
ICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQogICAgPiA+IEZh
eDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJz
aXR5LmRlLz4NCiAgICA+ID4NCiAgICA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCiAgICA+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KICAgID4gPiBu
ZXRtb2RAaWV0Zi5vcmcNCiAgICA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9uZXRtb2QNCiAgICA+ID4NCiAgICA+IA0KICAgIA0KICAgIC0tIA0KICAgIEp1ZXJnZW4g
U2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQog
ICAgUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkg
QnJlbWVuIHwgR2VybWFueQ0KICAgIEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0
dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCiAgICANCiAgICBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIG5ldG1vZCBtYWlsaW5nIGxp
c3QNCiAgICBuZXRtb2RAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL25ldG1vZA0KICAgIA0KDQo=