From nobody Thu Nov 1 02:39: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 5D7481294D0 for ; Thu, 1 Nov 2018 02:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.047 X-Spam-Level: X-Spam-Status: No, score=-4.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=XlPq1SF6; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Wd51G/IE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aN5s_bW4qZdA for ; Thu, 1 Nov 2018 02:39:18 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D1321286E7 for ; Thu, 1 Nov 2018 02:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1541065155; x=1543657155; 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=Tdr/RQMoJ1qwyfvzX9r5JJ0jPjBW2jeam+dd96eYFmM=; b=XlPq1SF6EiYEsMOldtdcDhxkxeGamZfg3Sci7JzjpWppw/l9NJnIEYzJaINysUQF gAotjc1SXnD+w1Ze52MkpRzJfsJgAT5sKXZcdEqNxxvN10vKZcHbjWmlcLIRH9Vu iCu/AagbSQ1cvuqXIbW/cLMKX/7uM4sVb4OFVpm8U1Y=; X-AuditID: c1b4fb2d-425ff7000000434d-fb-5bdac9c3f467 Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 55.33.17229.3C9CADB5; Thu, 1 Nov 2018 10:39:15 +0100 (CET) Received: from ESESBMB501.ericsson.se (153.88.183.168) 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; Thu, 1 Nov 2018 10:39:15 +0100 Received: from EUR04-VI1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB501.ericsson.se (153.88.183.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 1 Nov 2018 10:39: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=UdoKd4znD9PRSdOfCNQMkP13Kc6frzE/XIAB2J6jo6o=; b=Wd51G/IEDNeECovPC2668f3Fw9Q5G1/C+qD5MbfQ7MPz0Pg90IU7E7tDeoa+axey+fGlQnta0vWUCbT0mcW++w1JPmK9olxoIhcg/xUSvjheBp3ooTX2j3oyksxWXHHZRFL2C5/v9alKBdmHGR0rfU4VHeDYjNhIlqRs5saIYaI= Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2384.eurprd07.prod.outlook.com (10.168.138.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.12; Thu, 1 Nov 2018 09:39:14 +0000 Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd%11]) with mapi id 15.20.1294.018; Thu, 1 Nov 2018 09:39:14 +0000 From: =?Windows-1252?Q?Bal=E1zs_Lengyel?= To: "netmod@ietf.org" Thread-Topic: [netmod] for a future rfc6991bis Thread-Index: AQHUccbAJH8IN3JOb0WNQYaCXq3XQw== Date: Thu, 1 Nov 2018 09:39:14 +0000 Message-ID: <15451817-0d40-5f95-3c81-48cb126063a7@ericsson.com> References: <87y3aejo9y.fsf@nic.cz> <20181031124643.vuaakszwepqqgooy@anna.jacobs.jacobs-university.de> In-Reply-To: <20181031124643.vuaakszwepqqgooy@anna.jacobs.jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.80] user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 x-clientproxiedby: AM6P194CA0060.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:84::37) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2384; 6:ZJ9Vsjnn0XQafAskUBSaNe2do5BzfQj3otP9WM03R/xR1M3KkcZ7x07SvPNGASMFTrgaUvGdVlHLBAWjeO2R0PiUl6Oe1gHpt0z38XQ5m8sNktPS+oBIv3cUKac77tjwMbTWUMDUXHVTj/fKwAUkUzUhfDc3sq0grHAmkUgSacTVybxtiQ0RkyLjFzfsX52Gl9KbFgsEcOUbwudCLGl1Hs+M+4XNZdfBDO98sl250x3BCtlqE5CoSHBSdAEL0GIjHdbTc46euqNumvMZa9z8O5y6jyJc4H43E5WhYDQiQ2WauHaR0d/P2++nkNRYx4iqMm6bV//XkLSgwqYraciW4u+MgNpe/XUJE1MTRGFdbm42otwUb0ZSwLETpkVUiudFprGcUd+uGmgsnbBG1LIAJB3laFZi/iqrwY/7bofxwOtQtqIQXKjl7bfTJi3H/o6szExswo/0o0fZbtsObS4O/A==; 5:883F3WiYLUk/h/8mDXfFv8Tax0BSoa5jP4Ir2PMdyQxdQuUOj67KVqNLDMrpuJg383aTkWxuzxWTrv8aHo2WPVc0mfRXjXQZC2CrWcaJ19+68qok5oKk0PR7NWw5mnThp7QqEMJIkEUvtiqFDZMbHGTNaeM4bOHFPwrqB/pGWhw=; 7:7BGra1sq6olB+UlrwokVqE8jrTEWkfdhJS/l2xWKYjTYLohQ3XZbCyvJPP8t9yA433n7iGVfSkIJwZm9OLM6iZI82kH1qFZYh85RCDHvSuIPyB6z4oT8hGKZ9q8JGAj0EPRPi/RQLycsb/2v/N/p0Q== x-ms-office365-filtering-correlation-id: baf3a919-b9cf-438c-ec49-08d63fdde295 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2384; x-ms-traffictypediagnostic: VI1PR0701MB2384: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(37575265505322)(248295561703944); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231382)(944501410)(4983020)(52105095)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2384; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2384; x-forefront-prvs: 0843C17679 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(39860400002)(396003)(376002)(346002)(252514010)(199004)(189003)(99286004)(5250100002)(229853002)(76176011)(65956001)(966005)(5660300001)(14454004)(58126008)(6916009)(52116002)(386003)(2900100001)(31696002)(66066001)(1730700003)(11346002)(53936002)(2501003)(186003)(6506007)(316002)(102836004)(7736002)(476003)(54896002)(64126003)(105586002)(99936001)(31686004)(2351001)(106356001)(5640700003)(446003)(86362001)(6512007)(6486002)(71200400001)(3846002)(114624004)(14444005)(26005)(486006)(97736004)(81166006)(6436002)(36756003)(606006)(6116002)(6306002)(71190400001)(8676002)(478600001)(256004)(25786009)(81156014)(8936002)(65806001)(3260700006)(6246003)(236005)(2616005)(65826007)(2906002)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2384; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: NrzZkGX/cjbDlcrzRMMysC8uU+sLZjRgEDesKHZjRHzZdTMYpNOKIEzuiBLrtMLm8+v0ttvpzY8sHFMYk8kzlEyFacTg8/zQmrMcg6AXZ3ZxVJn3kzrEcZzvu+Q9GtlA4auKEfwyFb+nmz+/NxHwSlU7PoVoaqss53XAFsfWIUKzq8WtULvBZArEA33p8CA9BhFkbVZTvg59AHMVIzhsstDkpqQXpIc23ewiyFjGvidrhTloFqAxLhJfDsuYocYJRes1pOPzxx3XFQ1WnwiUI7kc/j5X0gyoQdyT6LecGYryNrI3QmWr1I4IXxVvVyKYVmbp/1JQGqqOwCH1y8yktC4P+HRkDOuKNbT8rwhrhmY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050709040903080505080207" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: baf3a919-b9cf-438c-ec49-08d63fdde295 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2018 09:39:14.4805 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2384 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSfyyUcRzH+z7Pc49zc/l2ftxnqq2O1UpI2JImzR/6pWz6o5Fy8QzFsXsk /GEsSq7Jj4xDkZDRYuUcm92400rOREyTWaSm3ZTya7m07rmHrf57fb7vH98f+wpJyZDARZig SGWUCnmijBZR6gvaGx6G/onIg98NXodrhnMEQehEff0vIgxFiI7GMokJaYzSKzBaFF+zUkWn fD6b3ttopLORMaQA2QoB+8KccYnkWIL7EAw+TCpAIgsvI1is01H88JiAm98GEDdQuIgEk3aR 4JVyAsp1ZRvDDIKp0iYbrozGIVA8tUpx7Ij3grqrlS5AQqED9oD21jB+2ROajLPUJi/U5ViZ wm4wt/ATcXYxPgZ6QxZf/wDB/McSq8cWn4OGqi7rVgg7w+qbpwTHJJbCxGwNwd/NEaaHB2ie neDrpz8CnndB/VKxNeuEoyC3v1LAbQC4HEF7oYHkSy9B91T+RvgADI7PIp53wkiNCvGB9zTo tF9seCEU1Plmkud3CIrLozfDudXmjXAymKtXrA8B+CLoDEQR8q7859yVlloS30Gw3GkkOUGM t0G/epbiTR5Q19Fk83+AY3dofGQieQ6AirVemufdcF81veH3A9PLH4hnH2h8tk7XIlEzcmIZ lk2KO+TjySgTYlg2WeGpYFKfI8vX6m03e3SiFtNxPcJCJLMT65smIiUCeRqbkaRHbpaembaW t8iFUiQrGJmjeN3fIotj5RmZjDL5svJ6IsPq0XYhJZOKPZu7IyQ4Tp7KXGOYFEa5qRJCW5ds dN5d0zOaXbGl57S9gzZ7YWu3RuYaECQZ1b66Jb2rtS9pcHE+1WH2G5H3vViChCthJUOvJ3a0 eZfVzmc2xuc1+BrFt8/YTS7vG+nL9C89SYROqbL8jiiWP6T37YnRjHWHjwfGrKmfKPNcowp9 VcEq3dXfI9KxEoNmMlhqDve/1yCj2Hi5935Sycr/Ag5Pq8NiAwAA 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: Thu, 01 Nov 2018 09:39:20 -0000 --------------ms050709040903080505080207 Content-Type: text/html; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: quoted-printable

Hello,

We do see a need for the following types:

  • date (in the earlier debate as I remember Martin wanted to include timezone)
  • time
  • node-instance-identifier from netconf-acm. We found that this is a useful type used not just in acm, so it would be nice to have it defined in 6991.
  • email

regards Balazs

On 2018. 10. 31. 13:46, Juergen Schoenwaelder wrote:
Here is my list of possible =
additions. I might have lost some items on
a computer that meanwhile is not used anymore, I will have to dig a
bit to see what I can recover.

/js

On Wed, Oct 31, 2018 at 01:26:01PM +0100, Ladislav Lhotka wrote:

Hi,

another update that was discussed recently is a clarification of the
XPath context for the xpath1.0 type.

Lada

Kent Watsen <kwatsen@juniper.net> writes:


NETMOD WG,

A conversation in NETCONF WG regarding the yang-push noted that it might =
be=20
time to update RFC 6991, in particular to introduce a type for time-durat=
ion.

  https://mailarchive.ietf.o=
rg/arch/msg/netconf/KaUJloIShkLNIXTuHZNwB-SYBnQ

In addition, it might be good to introduce [inet?] types for RFC 5322=20
(Internet Message Format) including perhaps:

  - email-address        (addr-spec, per Section 3.4.1)
  - named-email-address  (name-addr, per Section 3.4)


Kent // contributor



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

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

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


      

      

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


    

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


  



--------------ms050709040903080505080207
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTEwMTA5MzkxMFow
LwYJKoZIhvcNAQkEMSIEIPHBQYEl/jqA4fwQMUFaSRui3yjiaps4r+DW9jplNv2UMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAFqeW++1Goaf6NMEVXhoev/9x6o16blaZYwphjmstwuW308v
QPD/gf2MBqTcFx/T3qfqYMJ0+vqLk+hLpE17G+uQIsXERkUCaYZpPMjbmpJ3/tJ+pi7eQE1v
Z5E1nxnZcGjzL+HeBuh8xiaoyxiGN2l1YPCPsKJ+hyXcftq78cxJKnX/hK3xn3TPGkc2G0J2
yXLcG88J93O0SZlxVkv3/B8aiH9xOKg1Fp8zTFpW/hX+gcHPDuIHFeWGfiEb0SAZE2YpvobQ
LqZVyYbQxUBKpf1aMRh8LgbCg88p49pGJ2OggT9xKS3NvmqqBE6MdVkrRiGUxRsqQzzukQTQ
bouTXk0AAAAAAAA=

--------------ms050709040903080505080207--


From nobody Thu Nov  1 04:55: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 608321277D2 for ; Thu,  1 Nov 2018 04:55:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPjMnOHdugCK for ; Thu,  1 Nov 2018 04:55:36 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A3A124D68 for ; Thu,  1 Nov 2018 04:55:36 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 9325654CB4C49; Thu,  1 Nov 2018 11:55:29 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 1 Nov 2018 11:55:31 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.136]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Thu, 1 Nov 2018 19:55:25 +0800
From: Qin Wu 
To: Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AQHUb8bb5pZToCjlLEK5aT+9YAPiF6U4xBqAgAAFyYCAAgkIAA==
Date: Thu, 1 Nov 2018 11:55:25 +0000
Message-ID: 
References:  <87y3aejo9y.fsf@nic.cz> <20181031124643.vuaakszwepqqgooy@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181031124643.vuaakszwepqqgooy@anna.jacobs.jacobs-university.de>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] 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: Thu, 01 Nov 2018 11:55:38 -0000

SSBhbSB3b25kZXJpbmcgaWYgd2UgY2FuIGFkZCBsb25naXR1ZGUsIGxhdGl0dWRlIGluIERNUyBv
ciBkZWNpbWFsIGRlZ3JlZSwNCkZ1cnRoZXIgd2UgY2FuIGNvbnNpZGVyIHRvIGFkZA0KUG9zdGFs
LWNvZGUsIENvdW50cnktY29kZSBsaWtlIExvY2F0aW9uIHR5cGUuDQoNCi1RaW4NCi0tLS0t08q8
/tStvP4tLS0tLQ0Kt6K8/sjLOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9y
Z10gtPqx7SBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCreiy83KsbzkOiAyMDE4xOoxMNTCMzHI1SAy
MDo0Nw0KytW8/sjLOiBuZXRtb2RAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbbmV0bW9kXSBmb3IgYSBm
dXR1cmUgcmZjNjk5MWJpcw0KDQpIZXJlIGlzIG15IGxpc3Qgb2YgcG9zc2libGUgYWRkaXRpb25z
LiBJIG1pZ2h0IGhhdmUgbG9zdCBzb21lIGl0ZW1zIG9uIGEgY29tcHV0ZXIgdGhhdCBtZWFud2hp
bGUgaXMgbm90IHVzZWQgYW55bW9yZSwgSSB3aWxsIGhhdmUgdG8gZGlnIGEgYml0IHRvIHNlZSB3
aGF0IEkgY2FuIHJlY292ZXIuDQoNCi9qcw0KDQpPbiBXZWQsIE9jdCAzMSwgMjAxOCBhdCAwMToy
NjowMVBNICswMTAwLCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+IEhpLA0KPiANCj4gYW5vdGhl
ciB1cGRhdGUgdGhhdCB3YXMgZGlzY3Vzc2VkIHJlY2VudGx5IGlzIGEgY2xhcmlmaWNhdGlvbiBv
ZiB0aGUgDQo+IFhQYXRoIGNvbnRleHQgZm9yIHRoZSB4cGF0aDEuMCB0eXBlLg0KPiANCj4gTGFk
YQ0KPiANCj4gS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyaXRlczoNCj4gDQo+
ID4gTkVUTU9EIFdHLA0KPiA+DQo+ID4gQSBjb252ZXJzYXRpb24gaW4gTkVUQ09ORiBXRyByZWdh
cmRpbmcgdGhlIHlhbmctcHVzaCBub3RlZCB0aGF0IGl0IA0KPiA+IG1pZ2h0IGJlIHRpbWUgdG8g
dXBkYXRlIFJGQyA2OTkxLCBpbiBwYXJ0aWN1bGFyIHRvIGludHJvZHVjZSBhIHR5cGUgZm9yIHRp
bWUtZHVyYXRpb24uDQo+ID4NCj4gPiAgIA0KPiA+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v
cmcvYXJjaC9tc2cvbmV0Y29uZi9LYVVKbG9JU2hrTE5JWFR1SFpOd0ItDQo+ID4gU1lCblENCj4g
Pg0KPiA+IEluIGFkZGl0aW9uLCBpdCBtaWdodCBiZSBnb29kIHRvIGludHJvZHVjZSBbaW5ldD9d
IHR5cGVzIGZvciBSRkMgDQo+ID4gNTMyMiAoSW50ZXJuZXQgTWVzc2FnZSBGb3JtYXQpIGluY2x1
ZGluZyBwZXJoYXBzOg0KPiA+DQo+ID4gICAtIGVtYWlsLWFkZHJlc3MgICAgICAgIChhZGRyLXNw
ZWMsIHBlciBTZWN0aW9uIDMuNC4xKQ0KPiA+ICAgLSBuYW1lZC1lbWFpbC1hZGRyZXNzICAobmFt
ZS1hZGRyLCBwZXIgU2VjdGlvbiAzLjQpDQo+ID4NCj4gPg0KPiA+IEtlbnQgLy8gY29udHJpYnV0
b3INCj4gPg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5v
cmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiAN
Cj4gLS0NCj4gTGFkaXNsYXYgTGhvdGthDQo+IEhlYWQsIENaLk5JQyBMYWJzDQo+IFBHUCBLZXkg
SUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0
Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K
LS0gDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJy
ZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAx
IHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAg
ICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K


From nobody Thu Nov  1 05:04: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 0002312777C for ; Thu,  1 Nov 2018 05:04:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yZ2R3PTlCDJh for ; Thu,  1 Nov 2018 05:04:01 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02997124D68 for ; Thu,  1 Nov 2018 05:04:01 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E0219E91; Thu,  1 Nov 2018 13:03: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 Krd3lMHyp1BO; Thu,  1 Nov 2018 13:03: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; Thu,  1 Nov 2018 13:03:58 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0C182003D; Thu,  1 Nov 2018 13:03:58 +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 p_FR5Qbw4aB5; Thu,  1 Nov 2018 13:03: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 504D62003C; Thu,  1 Nov 2018 13:03: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; Thu, 1 Nov 2018 13:03:57 +0100
Received: by anna.localdomain (Postfix, from userid 501) id A737B300368BFF; Thu,  1 Nov 2018 13:03:57 +0100 (CET)
Date: Thu, 1 Nov 2018 13:03:57 +0100
From: Juergen Schoenwaelder 
To: Qin Wu 
CC: "netmod@ietf.org" 
Message-ID: <20181101120357.ny2xbn5ucubbcieo@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Qin Wu , "netmod@ietf.org" 
References:  <87y3aejo9y.fsf@nic.cz> <20181031124643.vuaakszwepqqgooy@anna.jacobs.jacobs-university.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] 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: Thu, 01 Nov 2018 12:04:04 -0000

I think we need to find a way to limit the update to types that are
known (or expected) to be 'widely' needed. In other words, for every
proposed type, an argument should be made why this should be included
in RFC 6991bis.

/js

On Thu, Nov 01, 2018 at 11:55:25AM +0000, Qin Wu wrote:
> I am wondering if we can add longitude, latitude in DMS or decimal degree,
> Further we can consider to add
> Postal-code, Country-code like Location type.
> 
> -Qin
> -----邮件原件-----
> 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Juergen Schoenwaelder
> 发送时间: 2018年10月31日 20:47
> 收件人: netmod@ietf.org
> 主题: Re: [netmod] for a future rfc6991bis
> 
> Here is my list of possible additions. I might have lost some items on a computer that meanwhile is not used anymore, I will have to dig a bit to see what I can recover.
> 
> /js
> 
> On Wed, Oct 31, 2018 at 01:26:01PM +0100, Ladislav Lhotka wrote:
> > Hi,
> > 
> > another update that was discussed recently is a clarification of the 
> > XPath context for the xpath1.0 type.
> > 
> > Lada
> > 
> > Kent Watsen  writes:
> > 
> > > NETMOD WG,
> > >
> > > A conversation in NETCONF WG regarding the yang-push noted that it 
> > > might be time to update RFC 6991, in particular to introduce a type for time-duration.
> > >
> > >   
> > > https://mailarchive.ietf.org/arch/msg/netconf/KaUJloIShkLNIXTuHZNwB-
> > > SYBnQ
> > >
> > > In addition, it might be good to introduce [inet?] types for RFC 
> > > 5322 (Internet Message Format) including perhaps:
> > >
> > >   - email-address        (addr-spec, per Section 3.4.1)
> > >   - named-email-address  (name-addr, per Section 3.4)
> > >
> > >
> > > Kent // contributor
> > >
> > >
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

-- 
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 Nov  1 07:18: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 8C4C91294D0 for ; Thu,  1 Nov 2018 07:18:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.971
X-Spam-Level: 
X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 8sUgYuxXgr6N for ; Thu,  1 Nov 2018 07:18:25 -0700 (PDT)
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 005151277BB for ; Thu,  1 Nov 2018 07:18:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4168; q=dns/txt; s=iport; t=1541081905; x=1542291505; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=K4+jHTppqb7GDWWcJLesfHoyembuqX4pDm9XC2Hbcws=; b=OJVSHFWq8mBSOn3sXbHASuRTpI/Ryko9zS3uzdNa46b07snpYdPdlYzH vklmdbV2Ly7F3Z0ueKBHBUrOXBE303d2999r7OOoUBVx3bIro57pvhJIy Vk8oH4WTFnRggsbkJc/XyHCEkaBr/3bOU0Vok6h/9ZhG1iQ3qZIZnYv7u k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAC2Cttb/4cNJK1hAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVIDAQEBAQELAYIEZn8oCoNslC6CDZcrFIFmCwEBGAu?= =?us-ascii?q?EA0YCF4MiIjUMDQEDAQECAQECbRwMhTsBAQEDAQEhEToZAgIBBgIOAggCAiM?= =?us-ascii?q?DAgICGQwLFAEQAgQBEoMhAYIBD4xgm06BLoE4gnUBhWkFBYEGimEXggCBOB+?= =?us-ascii?q?CTIMbAQECgSwBEgE2CiaCPTGCJgKOcpAwCQKGaooeGIFUjn+JP4NCig8CERS?= =?us-ascii?q?BJh4BNmRxcBU7KgGCQYY4hGGFPm8BiQiBH4EfAQE?=
X-IronPort-AV: E=Sophos;i="5.54,452,1534809600"; d="scan'208";a="474208596"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2018 14:17:55 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id wA1EHtEP007992 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Nov 2018 14:17:55 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 1 Nov 2018 10:17:54 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Thu, 1 Nov 2018 10:17:54 -0400
From: "Acee Lindem (acee)" 
To: Qin Wu , Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AQHUb8bb5pZToCjlLEK5aT+9YAPiF6U5jUSAgAAFyYCAAYQAgP//5MEA
Date: Thu, 1 Nov 2018 14:17:54 +0000
Message-ID: <0DBCF214-C6AB-45F3-8CD7-12C8C6004B70@cisco.com>
References:  <87y3aejo9y.fsf@nic.cz> <20181031124643.vuaakszwepqqgooy@anna.jacobs.jacobs-university.de> 
In-Reply-To: 
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.200]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.154, xch-rtp-014.cisco.com
X-Outbound-Node: alln-core-2.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: Thu, 01 Nov 2018 14:18:28 -0000

SGkgUWluLA0KDQpXZSdkIHRyaWVkIHRvIGNvbnZlcmdlIG9uIGdlby1jb29yZGluYXRlcyBpbiB0
aGUgcHJvdG9jb2xzIGFuZCByZWNlaXZlZCBhbmQgYSByYXRoZXIgd2lkZSByYW5nZSBvZiBvcGlu
aW9ucyBhcyB0byB0aGUgcHJlY2lzaW9uIGFuZCB3aGF0IHdhcyByZXF1aXJlZC4gQW4gSUVURiBj
b25zZW5zdXMgaXMgcmVxdWlyZWQgYW5kIG5vdCBldmVyeW9uZSBpcyBnb2luZyB0byBiZSBoYXBw
eS4gSG93ZXZlciwgSSdtIG5vdCBzdXJlIHdoZXJlIHRoaXMgd29yayBsaWVzIGFuZCBpdCBoYXNu
J3QgYmVlbiBhIHByaW9yaXR5IGZvciBtZS4gSW4gZmFjdCwgSSBsZXQgbXkgZHJhZnQgZXhwaXJl
OiBodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWFjZWUtb3NwZi1nZW8tbG9j
YXRpb24tMDUudHh0LiBJIHRoaW5rIHRyeWluZyB0byBhZGRpbmcgdGhlc2UgYmVmb3JlIHRoaXMg
aGFwcGVucyBjb3VsZCBkZWxheSB0aGUgQklTIHVwZGF0ZS4gDQoNClRoYW5rcywNCkFjZWUNCg0K
77u/T24gMTEvMS8xOCwgNzo1NSBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgUWluIFd1IiA8bmV0
bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGJpbGwud3VAaHVhd2VpLmNvbT4gd3Jv
dGU6DQoNCiAgICBJIGFtIHdvbmRlcmluZyBpZiB3ZSBjYW4gYWRkIGxvbmdpdHVkZSwgbGF0aXR1
ZGUgaW4gRE1TIG9yIGRlY2ltYWwgZGVncmVlLA0KICAgIEZ1cnRoZXIgd2UgY2FuIGNvbnNpZGVy
IHRvIGFkZA0KICAgIFBvc3RhbC1jb2RlLCBDb3VudHJ5LWNvZGUgbGlrZSBMb2NhdGlvbiB0eXBl
Lg0KICAgIA0KICAgIC1RaW4NCiAgICAtLS0tLemCruS7tuWOn+S7ti0tLS0tDQogICAg5Y+R5Lu2
5Lq6OiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEp1ZXJn
ZW4gU2Nob2Vud2FlbGRlcg0KICAgIOWPkemAgeaXtumXtDogMjAxOOW5tDEw5pyIMzHml6UgMjA6
NDcNCiAgICDmlLbku7bkuro6IG5ldG1vZEBpZXRmLm9yZw0KICAgIOS4u+mimDogUmU6IFtuZXRt
b2RdIGZvciBhIGZ1dHVyZSByZmM2OTkxYmlzDQogICAgDQogICAgSGVyZSBpcyBteSBsaXN0IG9m
IHBvc3NpYmxlIGFkZGl0aW9ucy4gSSBtaWdodCBoYXZlIGxvc3Qgc29tZSBpdGVtcyBvbiBhIGNv
bXB1dGVyIHRoYXQgbWVhbndoaWxlIGlzIG5vdCB1c2VkIGFueW1vcmUsIEkgd2lsbCBoYXZlIHRv
IGRpZyBhIGJpdCB0byBzZWUgd2hhdCBJIGNhbiByZWNvdmVyLg0KICAgIA0KICAgIC9qcw0KICAg
IA0KICAgIE9uIFdlZCwgT2N0IDMxLCAyMDE4IGF0IDAxOjI2OjAxUE0gKzAxMDAsIExhZGlzbGF2
IExob3RrYSB3cm90ZToNCiAgICA+IEhpLA0KICAgID4gDQogICAgPiBhbm90aGVyIHVwZGF0ZSB0
aGF0IHdhcyBkaXNjdXNzZWQgcmVjZW50bHkgaXMgYSBjbGFyaWZpY2F0aW9uIG9mIHRoZSANCiAg
ICA+IFhQYXRoIGNvbnRleHQgZm9yIHRoZSB4cGF0aDEuMCB0eXBlLg0KICAgID4gDQogICAgPiBM
YWRhDQogICAgPiANCiAgICA+IEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PiB3cml0
ZXM6DQogICAgPiANCiAgICA+ID4gTkVUTU9EIFdHLA0KICAgID4gPg0KICAgID4gPiBBIGNvbnZl
cnNhdGlvbiBpbiBORVRDT05GIFdHIHJlZ2FyZGluZyB0aGUgeWFuZy1wdXNoIG5vdGVkIHRoYXQg
aXQgDQogICAgPiA+IG1pZ2h0IGJlIHRpbWUgdG8gdXBkYXRlIFJGQyA2OTkxLCBpbiBwYXJ0aWN1
bGFyIHRvIGludHJvZHVjZSBhIHR5cGUgZm9yIHRpbWUtZHVyYXRpb24uDQogICAgPiA+DQogICAg
PiA+ICAgDQogICAgPiA+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbmV0
Y29uZi9LYVVKbG9JU2hrTE5JWFR1SFpOd0ItDQogICAgPiA+IFNZQm5RDQogICAgPiA+DQogICAg
PiA+IEluIGFkZGl0aW9uLCBpdCBtaWdodCBiZSBnb29kIHRvIGludHJvZHVjZSBbaW5ldD9dIHR5
cGVzIGZvciBSRkMgDQogICAgPiA+IDUzMjIgKEludGVybmV0IE1lc3NhZ2UgRm9ybWF0KSBpbmNs
dWRpbmcgcGVyaGFwczoNCiAgICA+ID4NCiAgICA+ID4gICAtIGVtYWlsLWFkZHJlc3MgICAgICAg
IChhZGRyLXNwZWMsIHBlciBTZWN0aW9uIDMuNC4xKQ0KICAgID4gPiAgIC0gbmFtZWQtZW1haWwt
YWRkcmVzcyAgKG5hbWUtYWRkciwgcGVyIFNlY3Rpb24gMy40KQ0KICAgID4gPg0KICAgID4gPg0K
ICAgID4gPiBLZW50IC8vIGNvbnRyaWJ1dG9yDQogICAgPiA+DQogICAgPiA+DQogICAgPiA+DQog
ICAgPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQog
ICAgPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCiAgICA+ID4gbmV0bW9kQGlldGYub3JnDQogICAg
PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQogICAgPiAN
CiAgICA+IC0tDQogICAgPiBMYWRpc2xhdiBMaG90a2ENCiAgICA+IEhlYWQsIENaLk5JQyBMYWJz
DQogICAgPiBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCiAgICA+IA0KICAgID4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IG5ldG1v
ZCBtYWlsaW5nIGxpc3QNCiAgICA+IG5ldG1vZEBpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICANCiAgICAtLSANCiAgICBKdWVy
Z2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21i
SA0KICAgIFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4
NzU5IEJyZW1lbiB8IEdlcm1hbnkNCiAgICBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAg
IDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQogICAgX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBuZXRtb2QgbWFpbGluZyBsaXN0
DQogICAgbmV0bW9kQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9uZXRtb2QNCiAgICANCg0K


From nobody Thu Nov  1 07:44: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 0E57F124D68 for ; Thu,  1 Nov 2018 07:44:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2kmn7IfCfS2 for ; Thu,  1 Nov 2018 07:44:48 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4DF124BAA for ; Thu,  1 Nov 2018 07:44:48 -0700 (PDT)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8FBE9EA6A3956; Thu,  1 Nov 2018 14:44:43 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 1 Nov 2018 14:44:45 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.136]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Thu, 1 Nov 2018 22:44:39 +0800
From: Qin Wu 
To: "Acee Lindem (acee)" , Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AdRx8KlwVnXwWJC6Q8eVYlUeBmdEjA==
Date: Thu, 1 Nov 2018 14:44:39 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.45.109.51]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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: Thu, 01 Nov 2018 14:44:51 -0000

VGhhdCdzIGEgZ29vZCB1c2UgY2FzZSBmb3IgZ2VvLWxvY2F0aW9uIHNlcnZpY2UuIElmIHRoZSBn
ZW8tbG9jYXRpb24gaW5mb3JtYXRpb24gaXMgc3BlY2lmaWVkIGluIHJvdXRpbmcgcHJvdG9jb2ws
IEkgdGhpbmsgaXQgc2hvdWxkIGFsc28gYmUgc3BlY2lmaWVkIGJ5IFlBTkcsIGJ1dCBuZWVkIHRv
IG1ha2Ugc3VyZSB0aGV5IGFyZSBjb25zaXN0ZW50Lg0KRm9yIHByZWNpc2lvbiBvZiBsb25naXR1
ZGUgYW5kIGxhdGl0dWRlLCB3aHkgbm90IHVzZSBETVMgKERlZ3JlZSwgTWludXRlLCBTZWNvbmQp
Pw0KDQotUWluDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IEFjZWUgTGluZGVt
IChhY2VlKSBbbWFpbHRvOmFjZWVAY2lzY28uY29tXSANCuWPkemAgeaXtumXtDogMjAxOOW5tDEx
5pyIMeaXpSAyMjoxOA0K5pS25Lu25Lq6OiBRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT47IEp1
ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRl
PjsgbmV0bW9kQGlldGYub3JnDQrkuLvpopg6IFJlOiBbbmV0bW9kXSBmb3IgYSBmdXR1cmUgcmZj
Njk5MWJpcw0KDQpIaSBRaW4sDQoNCldlJ2QgdHJpZWQgdG8gY29udmVyZ2Ugb24gZ2VvLWNvb3Jk
aW5hdGVzIGluIHRoZSBwcm90b2NvbHMgYW5kIHJlY2VpdmVkIGFuZCBhIHJhdGhlciB3aWRlIHJh
bmdlIG9mIG9waW5pb25zIGFzIHRvIHRoZSBwcmVjaXNpb24gYW5kIHdoYXQgd2FzIHJlcXVpcmVk
LiBBbiBJRVRGIGNvbnNlbnN1cyBpcyByZXF1aXJlZCBhbmQgbm90IGV2ZXJ5b25lIGlzIGdvaW5n
IHRvIGJlIGhhcHB5LiBIb3dldmVyLCBJJ20gbm90IHN1cmUgd2hlcmUgdGhpcyB3b3JrIGxpZXMg
YW5kIGl0IGhhc24ndCBiZWVuIGEgcHJpb3JpdHkgZm9yIG1lLiBJbiBmYWN0LCBJIGxldCBteSBk
cmFmdCBleHBpcmU6IGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYWNlZS1v
c3BmLWdlby1sb2NhdGlvbi0wNS50eHQuIEkgdGhpbmsgdHJ5aW5nIHRvIGFkZGluZyB0aGVzZSBi
ZWZvcmUgdGhpcyBoYXBwZW5zIGNvdWxkIGRlbGF5IHRoZSBCSVMgdXBkYXRlLiANCg0KVGhhbmtz
LA0KQWNlZQ0KDQrvu79PbiAxMS8xLzE4LCA3OjU1IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBR
aW4gV3UiIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgYmlsbC53dUBodWF3
ZWkuY29tPiB3cm90ZToNCg0KICAgIEkgYW0gd29uZGVyaW5nIGlmIHdlIGNhbiBhZGQgbG9uZ2l0
dWRlLCBsYXRpdHVkZSBpbiBETVMgb3IgZGVjaW1hbCBkZWdyZWUsDQogICAgRnVydGhlciB3ZSBj
YW4gY29uc2lkZXIgdG8gYWRkDQogICAgUG9zdGFsLWNvZGUsIENvdW50cnktY29kZSBsaWtlIExv
Y2F0aW9uIHR5cGUuDQogICAgDQogICAgLVFpbg0KICAgIC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0N
CiAgICDlj5Hku7bkuro6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSDk
u6PooaggSnVlcmdlbiBTY2hvZW53YWVsZGVyDQogICAg5Y+R6YCB5pe26Ze0OiAyMDE45bm0MTDm
nIgzMeaXpSAyMDo0Nw0KICAgIOaUtuS7tuS6ujogbmV0bW9kQGlldGYub3JnDQogICAg5Li76aKY
OiBSZTogW25ldG1vZF0gZm9yIGEgZnV0dXJlIHJmYzY5OTFiaXMNCiAgICANCiAgICBIZXJlIGlz
IG15IGxpc3Qgb2YgcG9zc2libGUgYWRkaXRpb25zLiBJIG1pZ2h0IGhhdmUgbG9zdCBzb21lIGl0
ZW1zIG9uIGEgY29tcHV0ZXIgdGhhdCBtZWFud2hpbGUgaXMgbm90IHVzZWQgYW55bW9yZSwgSSB3
aWxsIGhhdmUgdG8gZGlnIGEgYml0IHRvIHNlZSB3aGF0IEkgY2FuIHJlY292ZXIuDQogICAgDQog
ICAgL2pzDQogICAgDQogICAgT24gV2VkLCBPY3QgMzEsIDIwMTggYXQgMDE6MjY6MDFQTSArMDEw
MCwgTGFkaXNsYXYgTGhvdGthIHdyb3RlOg0KICAgID4gSGksDQogICAgPiANCiAgICA+IGFub3Ro
ZXIgdXBkYXRlIHRoYXQgd2FzIGRpc2N1c3NlZCByZWNlbnRseSBpcyBhIGNsYXJpZmljYXRpb24g
b2YgdGhlIA0KICAgID4gWFBhdGggY29udGV4dCBmb3IgdGhlIHhwYXRoMS4wIHR5cGUuDQogICAg
PiANCiAgICA+IExhZGENCiAgICA+IA0KICAgID4gS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBl
ci5uZXQ+IHdyaXRlczoNCiAgICA+IA0KICAgID4gPiBORVRNT0QgV0csDQogICAgPiA+DQogICAg
PiA+IEEgY29udmVyc2F0aW9uIGluIE5FVENPTkYgV0cgcmVnYXJkaW5nIHRoZSB5YW5nLXB1c2gg
bm90ZWQgdGhhdCBpdCANCiAgICA+ID4gbWlnaHQgYmUgdGltZSB0byB1cGRhdGUgUkZDIDY5OTEs
IGluIHBhcnRpY3VsYXIgdG8gaW50cm9kdWNlIGEgdHlwZSBmb3IgdGltZS1kdXJhdGlvbi4NCiAg
ICA+ID4NCiAgICA+ID4gICANCiAgICA+ID4gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9h
cmNoL21zZy9uZXRjb25mL0thVUpsb0lTaGtMTklYVHVIWk53Qi0NCiAgICA+ID4gU1lCblENCiAg
ICA+ID4NCiAgICA+ID4gSW4gYWRkaXRpb24sIGl0IG1pZ2h0IGJlIGdvb2QgdG8gaW50cm9kdWNl
IFtpbmV0P10gdHlwZXMgZm9yIFJGQyANCiAgICA+ID4gNTMyMiAoSW50ZXJuZXQgTWVzc2FnZSBG
b3JtYXQpIGluY2x1ZGluZyBwZXJoYXBzOg0KICAgID4gPg0KICAgID4gPiAgIC0gZW1haWwtYWRk
cmVzcyAgICAgICAgKGFkZHItc3BlYywgcGVyIFNlY3Rpb24gMy40LjEpDQogICAgPiA+ICAgLSBu
YW1lZC1lbWFpbC1hZGRyZXNzICAobmFtZS1hZGRyLCBwZXIgU2VjdGlvbiAzLjQpDQogICAgPiA+
DQogICAgPiA+DQogICAgPiA+IEtlbnQgLy8gY29udHJpYnV0b3INCiAgICA+ID4NCiAgICA+ID4N
CiAgICA+ID4NCiAgICA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCiAgICA+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KICAgID4gPiBuZXRtb2RAaWV0
Zi5vcmcNCiAgICA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt
b2QNCiAgICA+IA0KICAgID4gLS0NCiAgICA+IExhZGlzbGF2IExob3RrYQ0KICAgID4gSGVhZCwg
Q1ouTklDIExhYnMNCiAgICA+IFBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0KICAgID4g
DQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
ICAgID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KICAgID4gbmV0bW9kQGlldGYub3JnDQogICAgPiBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KICAgIA0KICAgIC0t
IA0KICAgIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkg
QnJlbWVuIGdHbWJIDQogICAgUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMg
UmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KICAgIEZheDogICArNDkgNDIxIDIwMCAz
MTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCiAgICBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIG5ldG1vZCBt
YWlsaW5nIGxpc3QNCiAgICBuZXRtb2RAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KICAgIA0KDQo=


From nobody Thu Nov  1 07:47:37 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5584E127598 for ; Thu,  1 Nov 2018 07:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level: 
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvgBiUsQi78g for ; Thu,  1 Nov 2018 07:47:34 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDA9512777C for ; Thu,  1 Nov 2018 07:47:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5716; q=dns/txt; s=iport; t=1541083654; x=1542293254; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=V2500ZHTshRGWb2gMjLajeialfioghzXGeHtsW0M0uo=; b=Y/jgdYL2oHQVfqavr30CAChP7jQi3Lv8ZjSA9Oy7uCB9EkC5+Uf+vQhS OVqjz5T2QNPGf4Wx9AkpIM6/MpFvge5rBu1BQFEpQL0XdLLX2XpfJSrNE bIlLLgEtp8UgfvUYunNX9xfdsEwjka5y1dhF9AJdbLBfdF908CrvuZMg3 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAAdEdtb/5FdJa1gAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVMCAQEBAQELAYIEZn8oCoNslC6CDZcrFIFmCwEBGAu?= =?us-ascii?q?EA0YCF4MiIjYLDQEDAQECAQECbRwMhTsBAQEDAQEhEToZAgIBBgIOAggCAiM?= =?us-ascii?q?DAgICGQwLFAEQAQEEARKDIQGCAQ+MfZtOgS6BOIJ1AYVpBQWBBophF4IAgTg?= =?us-ascii?q?fgkyDGwEBAoEsARIBHxcKJoI9MYImAo5ykDAJAoZqih4YgVSOf4k/g0KKDwI?= =?us-ascii?q?RFIEmJAQtZHFwFTsqAYJBhjiEYYU+bwGJCIEfgR8BAQ?=
X-IronPort-AV: E=Sophos;i="5.54,452,1534809600"; d="scan'208";a="194340162"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Nov 2018 14:47:32 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id wA1ElWjs015829 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Nov 2018 14:47:32 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 1 Nov 2018 10:47:31 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Thu, 1 Nov 2018 10:47:31 -0400
From: "Acee Lindem (acee)" 
To: Qin Wu , Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AdRx8Klw5pZToCjlLEK5aT+9YAPiFwAASQaA
Date: Thu, 1 Nov 2018 14:47:31 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.200]
Content-Type: text/plain; charset="utf-8"
Content-ID: <42DA2BD86A922A4D8EAF38AF53323074@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.151, xch-rtp-011.cisco.com
X-Outbound-Node: rcdn-core-9.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: Thu, 01 Nov 2018 14:47:36 -0000

SGkgUWluLA0KDQrvu79PbiAxMS8xLzE4LCAxMDo0NCBBTSwgIlFpbiBXdSIgPGJpbGwud3VAaHVh
d2VpLmNvbT4gd3JvdGU6DQoNCiAgICBUaGF0J3MgYSBnb29kIHVzZSBjYXNlIGZvciBnZW8tbG9j
YXRpb24gc2VydmljZS4gSWYgdGhlIGdlby1sb2NhdGlvbiBpbmZvcm1hdGlvbiBpcyBzcGVjaWZp
ZWQgaW4gcm91dGluZyBwcm90b2NvbCwgSSB0aGluayBpdCBzaG91bGQgYWxzbyBiZSBzcGVjaWZp
ZWQgYnkgWUFORywgYnV0IG5lZWQgdG8gbWFrZSBzdXJlIHRoZXkgYXJlIGNvbnNpc3RlbnQuDQog
ICAgRm9yIHByZWNpc2lvbiBvZiBsb25naXR1ZGUgYW5kIGxhdGl0dWRlLCB3aHkgbm90IHVzZSBE
TVMgKERlZ3JlZSwgTWludXRlLCBTZWNvbmQpPyANCg0KSSdkIGJlIGhhcHB5IHRvIHJlYWNoIGNv
bnNlbnN1cyBvbiB0aGlzIGJ1dCB3ZSdyZSBnb2luZyB0byBzb2x2ZSBpdCBpbiB0aGlzIEVtYWls
IHRocmVhZC4gDQoNClRoYW5rcywNCkFjZWUNCiAgICANCiAgICAtUWluDQogICAgLS0tLS3pgq7k
u7bljp/ku7YtLS0tLQ0KICAgIOWPkeS7tuS6ujogQWNlZSBMaW5kZW0gKGFjZWUpIFttYWlsdG86
YWNlZUBjaXNjby5jb21dIA0KICAgIOWPkemAgeaXtumXtDogMjAxOOW5tDEx5pyIMeaXpSAyMjox
OA0KICAgIOaUtuS7tuS6ujogUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+OyBKdWVyZ2VuIFNj
aG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT47IG5ldG1v
ZEBpZXRmLm9yZw0KICAgIOS4u+mimDogUmU6IFtuZXRtb2RdIGZvciBhIGZ1dHVyZSByZmM2OTkx
YmlzDQogICAgDQogICAgSGkgUWluLA0KICAgIA0KICAgIFdlJ2QgdHJpZWQgdG8gY29udmVyZ2Ug
b24gZ2VvLWNvb3JkaW5hdGVzIGluIHRoZSBwcm90b2NvbHMgYW5kIHJlY2VpdmVkIGFuZCBhIHJh
dGhlciB3aWRlIHJhbmdlIG9mIG9waW5pb25zIGFzIHRvIHRoZSBwcmVjaXNpb24gYW5kIHdoYXQg
d2FzIHJlcXVpcmVkLiBBbiBJRVRGIGNvbnNlbnN1cyBpcyByZXF1aXJlZCBhbmQgbm90IGV2ZXJ5
b25lIGlzIGdvaW5nIHRvIGJlIGhhcHB5LiBIb3dldmVyLCBJJ20gbm90IHN1cmUgd2hlcmUgdGhp
cyB3b3JrIGxpZXMgYW5kIGl0IGhhc24ndCBiZWVuIGEgcHJpb3JpdHkgZm9yIG1lLiBJbiBmYWN0
LCBJIGxldCBteSBkcmFmdCBleHBpcmU6IGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQv
ZHJhZnQtYWNlZS1vc3BmLWdlby1sb2NhdGlvbi0wNS50eHQuIEkgdGhpbmsgdHJ5aW5nIHRvIGFk
ZGluZyB0aGVzZSBiZWZvcmUgdGhpcyBoYXBwZW5zIGNvdWxkIGRlbGF5IHRoZSBCSVMgdXBkYXRl
LiANCiAgICANCiAgICBUaGFua3MsDQogICAgQWNlZQ0KICAgIA0KICAgIE9uIDExLzEvMTgsIDc6
NTUgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIFFpbiBXdSIgPG5ldG1vZC1ib3VuY2VzQGlldGYu
b3JnIG9uIGJlaGFsZiBvZiBiaWxsLnd1QGh1YXdlaS5jb20+IHdyb3RlOg0KICAgIA0KICAgICAg
ICBJIGFtIHdvbmRlcmluZyBpZiB3ZSBjYW4gYWRkIGxvbmdpdHVkZSwgbGF0aXR1ZGUgaW4gRE1T
IG9yIGRlY2ltYWwgZGVncmVlLA0KICAgICAgICBGdXJ0aGVyIHdlIGNhbiBjb25zaWRlciB0byBh
ZGQNCiAgICAgICAgUG9zdGFsLWNvZGUsIENvdW50cnktY29kZSBsaWtlIExvY2F0aW9uIHR5cGUu
DQogICAgICAgIA0KICAgICAgICAtUWluDQogICAgICAgIC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0N
CiAgICAgICAg5Y+R5Lu25Lq6OiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9y
Z10g5Luj6KGoIEp1ZXJnZW4gU2Nob2Vud2FlbGRlcg0KICAgICAgICDlj5HpgIHml7bpl7Q6IDIw
MTjlubQxMOaciDMx5pelIDIwOjQ3DQogICAgICAgIOaUtuS7tuS6ujogbmV0bW9kQGlldGYub3Jn
DQogICAgICAgIOS4u+mimDogUmU6IFtuZXRtb2RdIGZvciBhIGZ1dHVyZSByZmM2OTkxYmlzDQog
ICAgICAgIA0KICAgICAgICBIZXJlIGlzIG15IGxpc3Qgb2YgcG9zc2libGUgYWRkaXRpb25zLiBJ
IG1pZ2h0IGhhdmUgbG9zdCBzb21lIGl0ZW1zIG9uIGEgY29tcHV0ZXIgdGhhdCBtZWFud2hpbGUg
aXMgbm90IHVzZWQgYW55bW9yZSwgSSB3aWxsIGhhdmUgdG8gZGlnIGEgYml0IHRvIHNlZSB3aGF0
IEkgY2FuIHJlY292ZXIuDQogICAgICAgIA0KICAgICAgICAvanMNCiAgICAgICAgDQogICAgICAg
IE9uIFdlZCwgT2N0IDMxLCAyMDE4IGF0IDAxOjI2OjAxUE0gKzAxMDAsIExhZGlzbGF2IExob3Rr
YSB3cm90ZToNCiAgICAgICAgPiBIaSwNCiAgICAgICAgPiANCiAgICAgICAgPiBhbm90aGVyIHVw
ZGF0ZSB0aGF0IHdhcyBkaXNjdXNzZWQgcmVjZW50bHkgaXMgYSBjbGFyaWZpY2F0aW9uIG9mIHRo
ZSANCiAgICAgICAgPiBYUGF0aCBjb250ZXh0IGZvciB0aGUgeHBhdGgxLjAgdHlwZS4NCiAgICAg
ICAgPiANCiAgICAgICAgPiBMYWRhDQogICAgICAgID4gDQogICAgICAgID4gS2VudCBXYXRzZW4g
PGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyaXRlczoNCiAgICAgICAgPiANCiAgICAgICAgPiA+IE5F
VE1PRCBXRywNCiAgICAgICAgPiA+DQogICAgICAgID4gPiBBIGNvbnZlcnNhdGlvbiBpbiBORVRD
T05GIFdHIHJlZ2FyZGluZyB0aGUgeWFuZy1wdXNoIG5vdGVkIHRoYXQgaXQgDQogICAgICAgID4g
PiBtaWdodCBiZSB0aW1lIHRvIHVwZGF0ZSBSRkMgNjk5MSwgaW4gcGFydGljdWxhciB0byBpbnRy
b2R1Y2UgYSB0eXBlIGZvciB0aW1lLWR1cmF0aW9uLg0KICAgICAgICA+ID4NCiAgICAgICAgPiA+
ICAgDQogICAgICAgID4gPiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL25l
dGNvbmYvS2FVSmxvSVNoa0xOSVhUdUhaTndCLQ0KICAgICAgICA+ID4gU1lCblENCiAgICAgICAg
PiA+DQogICAgICAgID4gPiBJbiBhZGRpdGlvbiwgaXQgbWlnaHQgYmUgZ29vZCB0byBpbnRyb2R1
Y2UgW2luZXQ/XSB0eXBlcyBmb3IgUkZDIA0KICAgICAgICA+ID4gNTMyMiAoSW50ZXJuZXQgTWVz
c2FnZSBGb3JtYXQpIGluY2x1ZGluZyBwZXJoYXBzOg0KICAgICAgICA+ID4NCiAgICAgICAgPiA+
ICAgLSBlbWFpbC1hZGRyZXNzICAgICAgICAoYWRkci1zcGVjLCBwZXIgU2VjdGlvbiAzLjQuMSkN
CiAgICAgICAgPiA+ICAgLSBuYW1lZC1lbWFpbC1hZGRyZXNzICAobmFtZS1hZGRyLCBwZXIgU2Vj
dGlvbiAzLjQpDQogICAgICAgID4gPg0KICAgICAgICA+ID4NCiAgICAgICAgPiA+IEtlbnQgLy8g
Y29udHJpYnV0b3INCiAgICAgICAgPiA+DQogICAgICAgID4gPg0KICAgICAgICA+ID4NCiAgICAg
ICAgPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQog
ICAgICAgID4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAgICAgID4gPiBuZXRtb2RAaWV0Zi5v
cmcNCiAgICAgICAgPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0
bW9kDQogICAgICAgID4gDQogICAgICAgID4gLS0NCiAgICAgICAgPiBMYWRpc2xhdiBMaG90a2EN
CiAgICAgICAgPiBIZWFkLCBDWi5OSUMgTGFicw0KICAgICAgICA+IFBHUCBLZXkgSUQ6IDB4QjhG
OTJCMDhBOUY3NkM2Nw0KICAgICAgICA+IA0KICAgICAgICA+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgID4gbmV0bW9kIG1haWxpbmcgbGlz
dA0KICAgICAgICA+IG5ldG1vZEBpZXRmLm9yZw0KICAgICAgICA+IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQogICAgICAgIA0KICAgICAgICAtLSANCiAgICAg
ICAgSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVt
ZW4gZ0dtYkgNCiAgICAgICAgUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMg
UmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KICAgICAgICBGYXg6ICAgKzQ5IDQyMSAy
MDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQogICAg
ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAg
ICAgIG5ldG1vZCBtYWlsaW5nIGxpc3QNCiAgICAgICAgbmV0bW9kQGlldGYub3JnDQogICAgICAg
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQogICAgICAgIA0K
ICAgIA0KICAgIA0KDQo=


From nobody Thu Nov  1 20:17:44 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5F1128DFD for ; Thu,  1 Nov 2018 20:17:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 w3Wn9ROx17kS for ; Thu,  1 Nov 2018 20:17:39 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F74C128CFD for ; Thu,  1 Nov 2018 20:17:39 -0700 (PDT)
Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id A480C354480B0; Fri,  2 Nov 2018 03:17:35 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 2 Nov 2018 03:17:36 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.136]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Fri, 2 Nov 2018 11:17:22 +0800
From: Qin Wu 
To: Juergen Schoenwaelder 
CC: netmod 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AQHUb8bb5pZToCjlLEK5aT+9YAPiF6U4xBqAgAAFyYCAAgkIAP//fVqAgAGFUBA=
Date: Fri, 2 Nov 2018 03:17:21 +0000
Message-ID: 
References:  <87y3aejo9y.fsf@nic.cz> <20181031124643.vuaakszwepqqgooy@anna.jacobs.jacobs-university.de> , <20181101120357.ny2xbn5ucubbcieo@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181101120357.ny2xbn5ucubbcieo@anna.jacobs.jacobs-university.de>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B0E59EBnkgeml513mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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: Fri, 02 Nov 2018 03:17:42 -0000

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

QWdyZWUgd2l0aCB0aGlzIGNyaXRlcmlhLCByZW1lbWJlciBnZW8gbG9jYXRpb24gcHJvcG9zYWwg
d2FzIGRpc2N1c3NlZCBiZWZvcmUgYnkgQUxUTyBwcm9wb25lbnRzIGluIExNQVAsIGluIGFkZGl0
aW9uLCBsb2NhdGlvbiBzZXJ2aWNlIGlzIHVzZWZ1bCBmb3IgTDNWUE4gc2V2aWNlIHBsYWNlbWVu
dCwgc2VlIGV4YW1wbGUgY2FzZSBpbiBSRkM4Mjk5IHdoaWNoIGNhbiBzZWxlY3QgYXBwcm9wcmlh
dGUgUEUgYmFzZWQgb24gbG9jYXRpb24gaW5mby4gQWNlZSBhbHNvIHByb3ZpZGVkIGEgdmFsaWQg
dXNlIGNhc2UgaW4gdGhpcyBlLW1haWwgdGhyZWFkLg0KDQq3orz+yMujuiBKdWVyZ2VuIFNjaG9l
bndhZWxkZXINCsrVvP7Iy6O6IFFpbiBXdTxiaWxsLnd1QGh1YXdlaS5jb208bWFpbHRvOmJpbGwu
d3VAaHVhd2VpLmNvbT4+DQqzrcvNo7ogbmV0bW9kPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0
bW9kQGlldGYub3JnPj4NCtb3zOKjuiBSZTogW25ldG1vZF0gZm9yIGEgZnV0dXJlIHJmYzY5OTFi
aXMNCsqxvOSjuiAyMDE4LTExLTAxIDIwOjA0OjE1DQoNCkkgdGhpbmsgd2UgbmVlZCB0byBmaW5k
IGEgd2F5IHRvIGxpbWl0IHRoZSB1cGRhdGUgdG8gdHlwZXMgdGhhdCBhcmUNCmtub3duIChvciBl
eHBlY3RlZCkgdG8gYmUgJ3dpZGVseScgbmVlZGVkLiBJbiBvdGhlciB3b3JkcywgZm9yIGV2ZXJ5
DQpwcm9wb3NlZCB0eXBlLCBhbiBhcmd1bWVudCBzaG91bGQgYmUgbWFkZSB3aHkgdGhpcyBzaG91
bGQgYmUgaW5jbHVkZWQNCmluIFJGQyA2OTkxYmlzLg0KDQovanMNCg0KT24gVGh1LCBOb3YgMDEs
IDIwMTggYXQgMTE6NTU6MjVBTSArMDAwMCwgUWluIFd1IHdyb3RlOg0KPiBJIGFtIHdvbmRlcmlu
ZyBpZiB3ZSBjYW4gYWRkIGxvbmdpdHVkZSwgbGF0aXR1ZGUgaW4gRE1TIG9yIGRlY2ltYWwgZGVn
cmVlLA0KPiBGdXJ0aGVyIHdlIGNhbiBjb25zaWRlciB0byBhZGQNCj4gUG9zdGFsLWNvZGUsIENv
dW50cnktY29kZSBsaWtlIExvY2F0aW9uIHR5cGUuDQo+DQo+IC1RaW4NCj4gLS0tLS3Tyrz+1K28
/i0tLS0tDQo+ILeivP7IyzogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmdd
ILT6se0gSnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+ILeiy83KsbzkOiAyMDE4xOoxMNTCMzHI1SAy
MDo0Nw0KPiDK1bz+yMs6IG5ldG1vZEBpZXRmLm9yZw0KPiDW98ziOiBSZTogW25ldG1vZF0gZm9y
IGEgZnV0dXJlIHJmYzY5OTFiaXMNCj4NCj4gSGVyZSBpcyBteSBsaXN0IG9mIHBvc3NpYmxlIGFk
ZGl0aW9ucy4gSSBtaWdodCBoYXZlIGxvc3Qgc29tZSBpdGVtcyBvbiBhIGNvbXB1dGVyIHRoYXQg
bWVhbndoaWxlIGlzIG5vdCB1c2VkIGFueW1vcmUsIEkgd2lsbCBoYXZlIHRvIGRpZyBhIGJpdCB0
byBzZWUgd2hhdCBJIGNhbiByZWNvdmVyLg0KPg0KPiAvanMNCj4NCj4gT24gV2VkLCBPY3QgMzEs
IDIwMTggYXQgMDE6MjY6MDFQTSArMDEwMCwgTGFkaXNsYXYgTGhvdGthIHdyb3RlOg0KPiA+IEhp
LA0KPiA+DQo+ID4gYW5vdGhlciB1cGRhdGUgdGhhdCB3YXMgZGlzY3Vzc2VkIHJlY2VudGx5IGlz
IGEgY2xhcmlmaWNhdGlvbiBvZiB0aGUNCj4gPiBYUGF0aCBjb250ZXh0IGZvciB0aGUgeHBhdGgx
LjAgdHlwZS4NCj4gPg0KPiA+IExhZGENCj4gPg0KPiA+IEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1
bmlwZXIubmV0PiB3cml0ZXM6DQo+ID4NCj4gPiA+IE5FVE1PRCBXRywNCj4gPiA+DQo+ID4gPiBB
IGNvbnZlcnNhdGlvbiBpbiBORVRDT05GIFdHIHJlZ2FyZGluZyB0aGUgeWFuZy1wdXNoIG5vdGVk
IHRoYXQgaXQNCj4gPiA+IG1pZ2h0IGJlIHRpbWUgdG8gdXBkYXRlIFJGQyA2OTkxLCBpbiBwYXJ0
aWN1bGFyIHRvIGludHJvZHVjZSBhIHR5cGUgZm9yIHRpbWUtZHVyYXRpb24uDQo+ID4gPg0KPiA+
ID4NCj4gPiA+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbmV0Y29uZi9L
YVVKbG9JU2hrTE5JWFR1SFpOd0ItDQo+ID4gPiBTWUJuUQ0KPiA+ID4NCj4gPiA+IEluIGFkZGl0
aW9uLCBpdCBtaWdodCBiZSBnb29kIHRvIGludHJvZHVjZSBbaW5ldD9dIHR5cGVzIGZvciBSRkMN
Cj4gPiA+IDUzMjIgKEludGVybmV0IE1lc3NhZ2UgRm9ybWF0KSBpbmNsdWRpbmcgcGVyaGFwczoN
Cj4gPiA+DQo+ID4gPiAgIC0gZW1haWwtYWRkcmVzcyAgICAgICAgKGFkZHItc3BlYywgcGVyIFNl
Y3Rpb24gMy40LjEpDQo+ID4gPiAgIC0gbmFtZWQtZW1haWwtYWRkcmVzcyAgKG5hbWUtYWRkciwg
cGVyIFNlY3Rpb24gMy40KQ0KPiA+ID4NCj4gPiA+DQo+ID4gPiBLZW50IC8vIGNvbnRyaWJ1dG9y
DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPiA+ID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4gbmV0
bW9kQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L25ldG1vZA0KPiA+DQo+ID4gLS0NCj4gPiBMYWRpc2xhdiBMaG90a2ENCj4gPiBIZWFkLCBDWi5O
SUMgTGFicw0KPiA+IFBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0KPiA+DQo+ID4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRtb2Qg
bWFpbGluZyBsaXN0DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4NCj4gLS0NCj4gSnVlcmdlbiBTY2hvZW53YWVs
ZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gUGhvbmU6ICs0
OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2Vy
bWFueQ0KPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNv
YnMtdW5pdmVyc2l0eS5kZS8+DQoNCi0tDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAg
IEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcg
ICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KRmF4OiAgICs0
OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUv
Pg0K

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











Agree with this crit=
eria, remember geo location proposal was discussed before by ALTO proponent=
s in LMAP, in addition, location service is useful for L3VPN sevice placeme=
nt, see example case in RFC8299 which
 can select appropriate PE based on location info. Acee also provided a val=
id use case in this e-mail thread.








=B7=A2=BC=FE=C8=CB=A3=BA Juergen Schoenwaelder


=CA=D5=BC=FE=C8=CB=A3=BA Qin Wu<bill.wu@huawei.com>


=B3=AD=CB=CD=A3=BA netmod<netmod@ietf.org>


=D6=F7=CC=E2=A3=BA Re: [netmod] for a future rfc6991bis


=CA=B1=BC=E4=A3=BA 2018-11-01 20:04:15









I think we need to find a way to limit the update =
to types that are

known (or expected) to be 'widely' needed. In other words, for every

proposed type, an argument should be made why this should be included

in RFC 6991bis.



/js



On Thu, Nov 01, 2018 at 11:55:25AM +0000, Qin Wu wrote:

> I am wondering if we can add longitude, latitude in DMS or decimal deg=
ree,

> Further we can consider to add

> Postal-code, Country-code like Location type.

> 

> -Qin

> -----=D3=CA=BC=FE=D4=AD=BC=FE-----

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

> =B7=A2=CB=CD=CA=B1=BC=E4: 2018=C4=EA10=D4=C231=C8=D5 20:47

> =CA=D5=BC=FE=C8=CB: netmod@ietf.org

> =D6=F7=CC=E2: Re: [netmod] for a future rfc6991bis

> 

> Here is my list of possible additions. I might have lost some items on=
 a computer that meanwhile is not used anymore, I will have to dig a bit to=
 see what I can recover.

> 

> /js

> 

> On Wed, Oct 31, 2018 at 01:26:01PM +0100, Ladislav Lhotka wrote:
> > Hi,

> > 

> > another update that was discussed recently is a clarification of =
the 

> > XPath context for the xpath1.0 type.

> > 

> > Lada

> > 

> > Kent Watsen <kwatsen@juniper.net> writes:

> > 

> > > NETMOD WG,

> > >

> > > A conversation in NETCONF WG regarding the yang-push noted t=
hat it 

> > > might be time to update RFC 6991, in particular to introduce=
 a type for time-duration.

> > >

> > >   

> > > 
https://mailarchive.ietf.org/arch/msg/netconf/KaUJloIShkLNIXTuHZNwB-
> > > SYBnQ

> > >

> > > In addition, it might be good to introduce [inet?] types for=
 RFC 

> > > 5322 (Internet Message Format) including perhaps:

> > >

> > >   - email-address     &nb=
sp;  (addr-spec, per Section 3.4.1)

> > >   - named-email-address  (name-addr, per Sect=
ion 3.4)

> > >

> > >

> > > Kent // contributor

> > >

> > >

> > >

> > > _______________________________________________

> > > netmod mailing list

> > > netmod@ietf.org

> > > htt=
ps://www.ietf.org/mailman/listinfo/netmod

> > 

> > --

> > Ladislav Lhotka

> > Head, CZ.NIC Labs

> > PGP Key ID: 0xB8F92B08A9F76C67

> > 

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.org

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

> 

> -- 

> Juergen Schoenwaelder        &=
nbsp;  Jacobs University Bremen gGmbH

> Phone: +49 421 200 3587       &=
nbsp; Campus Ring 1 | 28759 Bremen | Germany

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



-- 

Juergen Schoenwaelder         =
  Jacobs University Bremen gGmbH

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

Fax:   +49 421 200 3103      &n=
bsp;  <https://www.ja=
cobs-university.de/>







--_000_B8F9A780D330094D99AF023C5877DABA9B0E59EBnkgeml513mbschi_--


From nobody Fri Nov  2 00:07: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 878B6129BBF for ; Fri,  2 Nov 2018 00:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeNPdaRQeNMW for ; Fri,  2 Nov 2018 00:07:23 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140D412426A for ; Fri,  2 Nov 2018 00:07:23 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 132B0E1A; Fri,  2 Nov 2018 08:07:21 +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 FkQSys-YrIfL; Fri,  2 Nov 2018 08:07:19 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri,  2 Nov 2018 08:07:21 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0A452003F; Fri,  2 Nov 2018 08:07:20 +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 7rTCSFhqtuSY; Fri,  2 Nov 2018 08:07:20 +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 4E7912003C; Fri,  2 Nov 2018 08:07:20 +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, 2 Nov 2018 08:07:19 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 5F02430036B210; Fri,  2 Nov 2018 08:07:19 +0100 (CET)
Date: Fri, 2 Nov 2018 08:07:19 +0100
From: Juergen Schoenwaelder 
To: Qin Wu 
CC: netmod 
Message-ID: <20181102070719.ht4walgvrsoc5gqv@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Qin Wu , netmod 
References:  <87y3aejo9y.fsf@nic.cz> <20181031124643.vuaakszwepqqgooy@anna.jacobs.jacobs-university.de>  <20181101120357.ny2xbn5ucubbcieo@anna.jacobs.jacobs-university.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] 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: Fri, 02 Nov 2018 07:07:28 -0000

I searched for longitute or geo in RFC 8299 and this was not a big
hit. Concrete definitions will help. I do know about
https://tools.ietf.org/html/draft-irtf-nmrg-location-ipfix-07 and that
has been dragging on from 2012 to 2016 within the NMRG and I think
this even had a life outside the NMRG before. What I am looking for is
concrete (ideally YANG) definitions that people have already created
and that can be the basis of a common standard. And of course an
argument why location data is so essential that it has to be in
ietf-yang-types and can't be in say a module ietf-geo-types.

/js

On Fri, Nov 02, 2018 at 03:17:21AM +0000, Qin Wu wrote:
> Agree with this criteria, remember geo location proposal was discussed before by ALTO proponents in LMAP, in addition, location service is useful for L3VPN sevice placement, see example case in RFC8299 which can select appropriate PE based on location info. Acee also provided a valid use case in this e-mail thread.
> 
> 发件人： Juergen Schoenwaelder
> 收件人： Qin Wu>
> 抄送： netmod>
> 主题： Re: [netmod] for a future rfc6991bis
> 时间： 2018-11-01 20:04:15
> 
> I think we need to find a way to limit the update to types that are
> known (or expected) to be 'widely' needed. In other words, for every
> proposed type, an argument should be made why this should be included
> in RFC 6991bis.
> 
> /js
> 
> On Thu, Nov 01, 2018 at 11:55:25AM +0000, Qin Wu wrote:
> > I am wondering if we can add longitude, latitude in DMS or decimal degree,
> > Further we can consider to add
> > Postal-code, Country-code like Location type.
> >
> > -Qin
> > -----邮件原件-----
> > 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Juergen Schoenwaelder
> > 发送时间: 2018年10月31日 20:47
> > 收件人: netmod@ietf.org
> > 主题: Re: [netmod] for a future rfc6991bis
> >
> > Here is my list of possible additions. I might have lost some items on a computer that meanwhile is not used anymore, I will have to dig a bit to see what I can recover.
> >
> > /js
> >
> > On Wed, Oct 31, 2018 at 01:26:01PM +0100, Ladislav Lhotka wrote:
> > > Hi,
> > >
> > > another update that was discussed recently is a clarification of the
> > > XPath context for the xpath1.0 type.
> > >
> > > Lada
> > >
> > > Kent Watsen  writes:
> > >
> > > > NETMOD WG,
> > > >
> > > > A conversation in NETCONF WG regarding the yang-push noted that it
> > > > might be time to update RFC 6991, in particular to introduce a type for time-duration.
> > > >
> > > >
> > > > https://mailarchive.ietf.org/arch/msg/netconf/KaUJloIShkLNIXTuHZNwB-
> > > > SYBnQ
> > > >
> > > > In addition, it might be good to introduce [inet?] types for RFC
> > > > 5322 (Internet Message Format) including perhaps:
> > > >
> > > >   - email-address        (addr-spec, per Section 3.4.1)
> > > >   - named-email-address  (name-addr, per Section 3.4)
> > > >
> > > >
> > > > Kent // contributor
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > --
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         
> 
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

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


From nobody Fri Nov  2 00:43: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 45C5E12D4F2 for ; Fri,  2 Nov 2018 00:43:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level: 
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 KTn7_4972RUx for ; Fri,  2 Nov 2018 00:43:05 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722C512D4F1 for ; Fri,  2 Nov 2018 00:43:05 -0700 (PDT)
Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 83AF272EF3DF7; Fri,  2 Nov 2018 07:43:01 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 2 Nov 2018 07:43:02 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.136]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0415.000; Fri, 2 Nov 2018 15:42:58 +0800
From: Qin Wu 
To: Juergen Schoenwaelder 
CC: netmod 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AdRyf5vgyfUzQEJVR2+sO4Bg+/PMrQ==
Date: Fri, 2 Nov 2018 07:42:58 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.45.122.117]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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: Fri, 02 Nov 2018 07:43:08 -0000

TG9uZ2l0dWRlIGlzIG5vdCBkZWZpbmVkIGluIFJGQzgyOTksIFJGQzgyOTkgcHJvdmlkZSBsb2Nh
dGlvbiBwYXJhbWV0ZXIgc3VjaCBhcyBjaXR5LCBjb3VudHJ5LCBjb3VudHJ5LWNvZGUsIHBvc3Rh
bC1jb2RlLCBzdHJlZXQuDQpodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWFj
ZWUtb3NwZi1nZW8tbG9jYXRpb24tMDUudHh0ICBzZWVtcyB0byBwcm92aWRlIGEgZmV3IGRlZmlu
aXRpb25zIG9mIGxvbmdpdHVkZSBhbmQgbGF0aXR1ZGUgaW4gc2VjdGlvbiAyOg0KaHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlZWRvcmYtbG1hcC1hbHRvLTAyI3NlY3Rpb24tNi4y
IHByb3ZpZGUgYW4gZXhhbXBsZSBvZiBsb25naXR1ZGUgdXNhZ2UgaW4gdGFibGUgMSB3aGljaCB1
c2UgZGlmZmVyZW50IHVuaXQoaS5lLixkZWNpbWFsIGRlZ3JlZSkNClNlZSBodHRwczovL3d3dy5y
YXBpZHRhYmxlcy5jb20vY29udmVydC9udW1iZXIvZGVncmVlcy10by1kZWdyZWVzLW1pbnV0ZXMt
c2Vjb25kcy5odG1sDQpSRkM2MjgwIHByb3ZpZGUgYSBnb29kIHRheG9ub215IG9mIGxvY2F0aW9u
IG9iamVjdC4NCiINCiAgIExvY2F0aW9uIE9iamVjdCAoTE8pOiAgIEFuIG9iamVjdCB1c2VkIHRv
IGNvbnZleSBsb2NhdGlvbiBpbmZvcm1hdGlvbg0KICAgICAgdG9nZXRoZXIgd2l0aCBQcml2YWN5
IFJ1bGVzLiAgR2VvcHJpdiBzdXBwb3J0cyBib3RoIGdlb2RldGljDQogICAgICBsb2NhdGlvbiBk
YXRhIChsYXRpdHVkZSwgbG9uZ2l0dWRlLCBhbHRpdHVkZSwgZXRjLikgYW5kIGNpdmljDQogICAg
ICBsb2NhdGlvbiBkYXRhIChzdHJlZXQsIGNpdHksIHN0YXRlLCBldGMuKS4gIEVpdGhlciBvciBi
b3RoIHR5cGVzDQogICAgICBvZiBsb2NhdGlvbiBpbmZvcm1hdGlvbiBtYXkgYmUgcHJlc2VudCBp
biBhIHNpbmdsZSBMTyAoc2VlIHRoZQ0KICAgICAgY29uc2lkZXJhdGlvbnMgaW4gWzVdIGZvciBM
T3MgY29udGFpbmluZyBtdWx0aXBsZSBsb2NhdGlvbnMpLg0KICAgICAgTG9jYXRpb24gT2JqZWN0
cyB0eXBpY2FsbHkgaW5jbHVkZSBzb21lIHNvcnQgb2YgaWRlbnRpZmllciBvZiB0aGUNCiAgICAg
IFRhcmdldC4NCiINCg0KLVFpbg0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBK
dWVyZ2VuIFNjaG9lbndhZWxkZXIgW21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZl
cnNpdHkuZGVdIA0K5Y+R6YCB5pe26Ze0OiAyMDE45bm0MTHmnIgy5pelIDE1OjA3DQrmlLbku7bk
uro6IFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPg0K5oqE6YCBOiBuZXRtb2QgPG5ldG1vZEBp
ZXRmLm9yZz4NCuS4u+mimDogUmU6IFtuZXRtb2RdIGZvciBhIGZ1dHVyZSByZmM2OTkxYmlzDQoN
Ckkgc2VhcmNoZWQgZm9yIGxvbmdpdHV0ZSBvciBnZW8gaW4gUkZDIDgyOTkgYW5kIHRoaXMgd2Fz
IG5vdCBhIGJpZyBoaXQuIENvbmNyZXRlIGRlZmluaXRpb25zIHdpbGwgaGVscC4gSSBkbyBrbm93
IGFib3V0DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaXJ0Zi1ubXJnLWxvY2F0
aW9uLWlwZml4LTA3IGFuZCB0aGF0IGhhcyBiZWVuIGRyYWdnaW5nIG9uIGZyb20gMjAxMiB0byAy
MDE2IHdpdGhpbiB0aGUgTk1SRyBhbmQgSSB0aGluayB0aGlzIGV2ZW4gaGFkIGEgbGlmZSBvdXRz
aWRlIHRoZSBOTVJHIGJlZm9yZS4gV2hhdCBJIGFtIGxvb2tpbmcgZm9yIGlzIGNvbmNyZXRlIChp
ZGVhbGx5IFlBTkcpIGRlZmluaXRpb25zIHRoYXQgcGVvcGxlIGhhdmUgYWxyZWFkeSBjcmVhdGVk
IGFuZCB0aGF0IGNhbiBiZSB0aGUgYmFzaXMgb2YgYSBjb21tb24gc3RhbmRhcmQuIEFuZCBvZiBj
b3Vyc2UgYW4gYXJndW1lbnQgd2h5IGxvY2F0aW9uIGRhdGEgaXMgc28gZXNzZW50aWFsIHRoYXQg
aXQgaGFzIHRvIGJlIGluIGlldGYteWFuZy10eXBlcyBhbmQgY2FuJ3QgYmUgaW4gc2F5IGEgbW9k
dWxlIGlldGYtZ2VvLXR5cGVzLg0KDQovanMNCg0KT24gRnJpLCBOb3YgMDIsIDIwMTggYXQgMDM6
MTc6MjFBTSArMDAwMCwgUWluIFd1IHdyb3RlOg0KPiBBZ3JlZSB3aXRoIHRoaXMgY3JpdGVyaWEs
IHJlbWVtYmVyIGdlbyBsb2NhdGlvbiBwcm9wb3NhbCB3YXMgZGlzY3Vzc2VkIGJlZm9yZSBieSBB
TFRPIHByb3BvbmVudHMgaW4gTE1BUCwgaW4gYWRkaXRpb24sIGxvY2F0aW9uIHNlcnZpY2UgaXMg
dXNlZnVsIGZvciBMM1ZQTiBzZXZpY2UgcGxhY2VtZW50LCBzZWUgZXhhbXBsZSBjYXNlIGluIFJG
QzgyOTkgd2hpY2ggY2FuIHNlbGVjdCBhcHByb3ByaWF0ZSBQRSBiYXNlZCBvbiBsb2NhdGlvbiBp
bmZvLiBBY2VlIGFsc28gcHJvdmlkZWQgYSB2YWxpZCB1c2UgY2FzZSBpbiB0aGlzIGUtbWFpbCB0
aHJlYWQuDQo+IA0KPiDlj5Hku7bkurrvvJogSnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+IOaUtuS7
tuS6uu+8miBRaW4gV3U8YmlsbC53dUBodWF3ZWkuY29tPG1haWx0bzpiaWxsLnd1QGh1YXdlaS5j
b20+Pg0KPiDmioTpgIHvvJogbmV0bW9kPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGll
dGYub3JnPj4NCj4g5Li76aKY77yaIFJlOiBbbmV0bW9kXSBmb3IgYSBmdXR1cmUgcmZjNjk5MWJp
cw0KPiDml7bpl7TvvJogMjAxOC0xMS0wMSAyMDowNDoxNQ0KPiANCj4gSSB0aGluayB3ZSBuZWVk
IHRvIGZpbmQgYSB3YXkgdG8gbGltaXQgdGhlIHVwZGF0ZSB0byB0eXBlcyB0aGF0IGFyZSANCj4g
a25vd24gKG9yIGV4cGVjdGVkKSB0byBiZSAnd2lkZWx5JyBuZWVkZWQuIEluIG90aGVyIHdvcmRz
LCBmb3IgZXZlcnkgDQo+IHByb3Bvc2VkIHR5cGUsIGFuIGFyZ3VtZW50IHNob3VsZCBiZSBtYWRl
IHdoeSB0aGlzIHNob3VsZCBiZSBpbmNsdWRlZCANCj4gaW4gUkZDIDY5OTFiaXMuDQo+IA0KPiAv
anMNCj4gDQo+IE9uIFRodSwgTm92IDAxLCAyMDE4IGF0IDExOjU1OjI1QU0gKzAwMDAsIFFpbiBX
dSB3cm90ZToNCj4gPiBJIGFtIHdvbmRlcmluZyBpZiB3ZSBjYW4gYWRkIGxvbmdpdHVkZSwgbGF0
aXR1ZGUgaW4gRE1TIG9yIGRlY2ltYWwgDQo+ID4gZGVncmVlLCBGdXJ0aGVyIHdlIGNhbiBjb25z
aWRlciB0byBhZGQgUG9zdGFsLWNvZGUsIENvdW50cnktY29kZSANCj4gPiBsaWtlIExvY2F0aW9u
IHR5cGUuDQo+ID4NCj4gPiAtUWluDQo+ID4gLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPiA+IOWP
keS7tuS6ujogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBK
dWVyZ2VuIA0KPiA+IFNjaG9lbndhZWxkZXINCj4gPiDlj5HpgIHml7bpl7Q6IDIwMTjlubQxMOac
iDMx5pelIDIwOjQ3DQo+ID4g5pS25Lu25Lq6OiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiDkuLvpopg6
IFJlOiBbbmV0bW9kXSBmb3IgYSBmdXR1cmUgcmZjNjk5MWJpcw0KPiA+DQo+ID4gSGVyZSBpcyBt
eSBsaXN0IG9mIHBvc3NpYmxlIGFkZGl0aW9ucy4gSSBtaWdodCBoYXZlIGxvc3Qgc29tZSBpdGVt
cyBvbiBhIGNvbXB1dGVyIHRoYXQgbWVhbndoaWxlIGlzIG5vdCB1c2VkIGFueW1vcmUsIEkgd2ls
bCBoYXZlIHRvIGRpZyBhIGJpdCB0byBzZWUgd2hhdCBJIGNhbiByZWNvdmVyLg0KPiA+DQo+ID4g
L2pzDQo+ID4NCj4gPiBPbiBXZWQsIE9jdCAzMSwgMjAxOCBhdCAwMToyNjowMVBNICswMTAwLCBM
YWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+ID4gPiBIaSwNCj4gPiA+DQo+ID4gPiBhbm90aGVyIHVw
ZGF0ZSB0aGF0IHdhcyBkaXNjdXNzZWQgcmVjZW50bHkgaXMgYSBjbGFyaWZpY2F0aW9uIG9mIA0K
PiA+ID4gdGhlIFhQYXRoIGNvbnRleHQgZm9yIHRoZSB4cGF0aDEuMCB0eXBlLg0KPiA+ID4NCj4g
PiA+IExhZGENCj4gPiA+DQo+ID4gPiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4g
d3JpdGVzOg0KPiA+ID4NCj4gPiA+ID4gTkVUTU9EIFdHLA0KPiA+ID4gPg0KPiA+ID4gPiBBIGNv
bnZlcnNhdGlvbiBpbiBORVRDT05GIFdHIHJlZ2FyZGluZyB0aGUgeWFuZy1wdXNoIG5vdGVkIHRo
YXQgDQo+ID4gPiA+IGl0IG1pZ2h0IGJlIHRpbWUgdG8gdXBkYXRlIFJGQyA2OTkxLCBpbiBwYXJ0
aWN1bGFyIHRvIGludHJvZHVjZSBhIHR5cGUgZm9yIHRpbWUtZHVyYXRpb24uDQo+ID4gPiA+DQo+
ID4gPiA+DQo+ID4gPiA+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbmV0
Y29uZi9LYVVKbG9JU2hrTE5JWFR1SFoNCj4gPiA+ID4gTndCLQ0KPiA+ID4gPiBTWUJuUQ0KPiA+
ID4gPg0KPiA+ID4gPiBJbiBhZGRpdGlvbiwgaXQgbWlnaHQgYmUgZ29vZCB0byBpbnRyb2R1Y2Ug
W2luZXQ/XSB0eXBlcyBmb3IgUkZDDQo+ID4gPiA+IDUzMjIgKEludGVybmV0IE1lc3NhZ2UgRm9y
bWF0KSBpbmNsdWRpbmcgcGVyaGFwczoNCj4gPiA+ID4NCj4gPiA+ID4gICAtIGVtYWlsLWFkZHJl
c3MgICAgICAgIChhZGRyLXNwZWMsIHBlciBTZWN0aW9uIDMuNC4xKQ0KPiA+ID4gPiAgIC0gbmFt
ZWQtZW1haWwtYWRkcmVzcyAgKG5hbWUtYWRkciwgcGVyIFNlY3Rpb24gMy40KQ0KPiA+ID4gPg0K
PiA+ID4gPg0KPiA+ID4gPiBLZW50IC8vIGNvbnRyaWJ1dG9yDQo+ID4gPiA+DQo+ID4gPiA+DQo+
ID4gPiA+DQo+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+ID4gPiA+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gbmV0bW9kQGlldGYu
b3JnDQo+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k
DQo+ID4gPg0KPiA+ID4gLS0NCj4gPiA+IExhZGlzbGF2IExob3RrYQ0KPiA+ID4gSGVhZCwgQ1ou
TklDIExhYnMNCj4gPiA+IFBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nw0KPiA+ID4NCj4g
PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g
PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiA+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4NCj4gPiAtLQ0KPiA+
IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVu
IGdHbWJIDQo+ID4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAx
IHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPiA+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAg
ICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4gDQo+IC0tDQo+IEp1
ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdH
bWJIDQo+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4
NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8
aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KDQotLSANCkp1ZXJnZW4gU2Nob2Vu
d2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQpQaG9uZTog
KzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBH
ZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNv
YnMtdW5pdmVyc2l0eS5kZS8+DQo=


From nobody Fri Nov  2 01:19:37 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC5812F1A5 for ; Fri,  2 Nov 2018 01:19:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_FILL_THIS_FORM_SHORT=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 6cVMiKg7okU2 for ; Fri,  2 Nov 2018 01:19:33 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510BD12008A for ; Fri,  2 Nov 2018 01:19:33 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B0A45E3A; Fri,  2 Nov 2018 09:19:31 +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 f_C_SQO9YW5N; Fri,  2 Nov 2018 09:19:30 +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,  2 Nov 2018 09:19:31 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 994972003D; Fri,  2 Nov 2018 09:19:31 +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 XX0I4Sh9Twtm; Fri,  2 Nov 2018 09:19:30 +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 C27A62003C; Fri,  2 Nov 2018 09:19:30 +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, 2 Nov 2018 09:19:30 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 0F88530036B405; Fri,  2 Nov 2018 09:19:29 +0100 (CET)
Date: Fri, 2 Nov 2018 09:19:29 +0100
From: Juergen Schoenwaelder 
To: Qin Wu 
CC: netmod 
Message-ID: <20181102081929.k72onwwawkblz3od@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Qin Wu , netmod 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] 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: Fri, 02 Nov 2018 08:19:36 -0000

It seems someone should draft an ietf-geo yang module proposal.

/js

On Fri, Nov 02, 2018 at 07:42:58AM +0000, Qin Wu wrote:
> Longitude is not defined in RFC8299, RFC8299 provide location parameter such as city, country, country-code, postal-code, street.
> https://www.ietf.org/archive/id/draft-acee-ospf-geo-location-05.txt  seems to provide a few definitions of longitude and latitude in section 2:
> https://tools.ietf.org/html/draft-seedorf-lmap-alto-02#section-6.2 provide an example of longitude usage in table 1 which use different unit(i.e.,decimal degree)
> See https://www.rapidtables.com/convert/number/degrees-to-degrees-minutes-seconds.html
> RFC6280 provide a good taxonomy of location object.
> "
>    Location Object (LO):   An object used to convey location information
>       together with Privacy Rules.  Geopriv supports both geodetic
>       location data (latitude, longitude, altitude, etc.) and civic
>       location data (street, city, state, etc.).  Either or both types
>       of location information may be present in a single LO (see the
>       considerations in [5] for LOs containing multiple locations).
>       Location Objects typically include some sort of identifier of the
>       Target.
> "
> 
> -Qin
> -----邮件原件-----
> 发件人: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] 
> 发送时间: 2018年11月2日 15:07
> 收件人: Qin Wu 
> 抄送: netmod 
> 主题: Re: [netmod] for a future rfc6991bis
> 
> I searched for longitute or geo in RFC 8299 and this was not a big hit. Concrete definitions will help. I do know about
> https://tools.ietf.org/html/draft-irtf-nmrg-location-ipfix-07 and that has been dragging on from 2012 to 2016 within the NMRG and I think this even had a life outside the NMRG before. What I am looking for is concrete (ideally YANG) definitions that people have already created and that can be the basis of a common standard. And of course an argument why location data is so essential that it has to be in ietf-yang-types and can't be in say a module ietf-geo-types.
> 
> /js
> 
> On Fri, Nov 02, 2018 at 03:17:21AM +0000, Qin Wu wrote:
> > Agree with this criteria, remember geo location proposal was discussed before by ALTO proponents in LMAP, in addition, location service is useful for L3VPN sevice placement, see example case in RFC8299 which can select appropriate PE based on location info. Acee also provided a valid use case in this e-mail thread.
> > 
> > 发件人： Juergen Schoenwaelder
> > 收件人： Qin Wu>
> > 抄送： netmod>
> > 主题： Re: [netmod] for a future rfc6991bis
> > 时间： 2018-11-01 20:04:15
> > 
> > I think we need to find a way to limit the update to types that are 
> > known (or expected) to be 'widely' needed. In other words, for every 
> > proposed type, an argument should be made why this should be included 
> > in RFC 6991bis.
> > 
> > /js
> > 
> > On Thu, Nov 01, 2018 at 11:55:25AM +0000, Qin Wu wrote:
> > > I am wondering if we can add longitude, latitude in DMS or decimal 
> > > degree, Further we can consider to add Postal-code, Country-code 
> > > like Location type.
> > >
> > > -Qin
> > > -----邮件原件-----
> > > 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Juergen 
> > > Schoenwaelder
> > > 发送时间: 2018年10月31日 20:47
> > > 收件人: netmod@ietf.org
> > > 主题: Re: [netmod] for a future rfc6991bis
> > >
> > > Here is my list of possible additions. I might have lost some items on a computer that meanwhile is not used anymore, I will have to dig a bit to see what I can recover.
> > >
> > > /js
> > >
> > > On Wed, Oct 31, 2018 at 01:26:01PM +0100, Ladislav Lhotka wrote:
> > > > Hi,
> > > >
> > > > another update that was discussed recently is a clarification of 
> > > > the XPath context for the xpath1.0 type.
> > > >
> > > > Lada
> > > >
> > > > Kent Watsen  writes:
> > > >
> > > > > NETMOD WG,
> > > > >
> > > > > A conversation in NETCONF WG regarding the yang-push noted that 
> > > > > it might be time to update RFC 6991, in particular to introduce a type for time-duration.
> > > > >
> > > > >
> > > > > https://mailarchive.ietf.org/arch/msg/netconf/KaUJloIShkLNIXTuHZ
> > > > > NwB-
> > > > > SYBnQ
> > > > >
> > > > > In addition, it might be good to introduce [inet?] types for RFC
> > > > > 5322 (Internet Message Format) including perhaps:
> > > > >
> > > > >   - email-address        (addr-spec, per Section 3.4.1)
> > > > >   - named-email-address  (name-addr, per Section 3.4)
> > > > >
> > > > >
> > > > > Kent // contributor
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > >
> > > > --
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   +49 421 200 3103         
> > 
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

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


From nobody Fri Nov  2 02:57:35 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913BB12D4F2 for ; Fri,  2 Nov 2018 02:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level: 
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urqaDgFvRw0f for ; Fri,  2 Nov 2018 02:57:31 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043451288BD for ; Fri,  2 Nov 2018 02:57:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2994; q=dns/txt; s=iport; t=1541152651; x=1542362251; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=7wxr9VLxkA01e24j+0p6EAQpwNXbYq+X8GnCbqQimvQ=; b=YPGZMbDXO15Tas/feQxwUt8HhqsQJoX086kgyQFqJoxEvvPCUgJ5uM+U wRbjwfW2zKwcFvREWYpFCM+pgqWIRpKgDgM+inuvFm/h3IOKgyw5Ot2Jm CD99iif70GryIsfSkxneM5Dael5Jz8D5/j5SmhHb4pyPCwGPbgu/2DZYG s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BCAAC/Htxb/xbLJq1gAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgWWBW4EQbRIog3aId40YLZdAgWYNGAuEA0YCg184FgE?= =?us-ascii?q?DAQECAQECbRwBC4U7AQEBAwEBIQ8BBTYZAgkCEAgCAiMDAgIbDB8RBg0GAgE?= =?us-ascii?q?Bgx0BggEPimubToEugTiCdQGBDoRXBQWBBop7gUE/gTiCa4MbAQGBLgEMBgF?= =?us-ascii?q?AJoI9glcCiRWFXpA3CYZsihkGGIFVh3aHD4lAg0WDaIZRgVohZHEzGggbFTu?= =?us-ascii?q?CbIM6AQEIgnSEYYU+PzCLAQ4XgicBAQ?=
X-IronPort-AV: E=Sophos;i="5.54,455,1534809600";  d="scan'208";a="7731273"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2018 09:57:28 +0000
Received: from [10.63.23.96] (dhcp-ensft1-uk-vla370-10-63-23-96.cisco.com [10.63.23.96]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id wA29vSld025033 for ; Fri, 2 Nov 2018 09:57:28 GMT
To: "netmod@ietf.org" 
References:  <87y3aejo9y.fsf@nic.cz> <20181031124643.vuaakszwepqqgooy@anna.jacobs.jacobs-university.de>  <20181101120357.ny2xbn5ucubbcieo@anna.jacobs.jacobs-university.de>
From: Robert Wilton 
Message-ID: <13914a03-e2a3-196d-490a-3cd8a4770654@cisco.com>
Date: Fri, 2 Nov 2018 09:57:28 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20181101120357.ny2xbn5ucubbcieo@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.96, dhcp-ensft1-uk-vla370-10-63-23-96.cisco.com
X-Outbound-Node: aer-core-2.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: Fri, 02 Nov 2018 09:57:34 -0000

On 01/11/2018 12:03, Juergen Schoenwaelder wrote:
> I think we need to find a way to limit the update to types that are
> known (or expected) to be 'widely' needed. In other words, for every
> proposed type, an argument should be made why this should be included
> in RFC 6991bis.
So my view is:
- We should limit the immediate updates to RFC 6991bis to what is easy 
to define and agree on.
- We should try and get the updated module out as quickly as the IETF 
process allows.

In parallel, we could have IDs and discussion to define YANG for email 
addresses and geo locations (could we just revive Acee's draft)?  One we 
are agreed what those definitions should be we can work out the best way 
to get them published, be that in RFC6991bis, RFC6991bisbis or a 
separate RFC.

Thanks,
Rob

>
> /js
>
> On Thu, Nov 01, 2018 at 11:55:25AM +0000, Qin Wu wrote:
>> I am wondering if we can add longitude, latitude in DMS or decimal degree,
>> Further we can consider to add
>> Postal-code, Country-code like Location type.
>>
>> -Qin
>> -----邮件原件-----
>> 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Juergen Schoenwaelder
>> 发送时间: 2018年10月31日 20:47
>> 收件人: netmod@ietf.org
>> 主题: Re: [netmod] for a future rfc6991bis
>>
>> Here is my list of possible additions. I might have lost some items on a computer that meanwhile is not used anymore, I will have to dig a bit to see what I can recover.
>>
>> /js
>>
>> On Wed, Oct 31, 2018 at 01:26:01PM +0100, Ladislav Lhotka wrote:
>>> Hi,
>>>
>>> another update that was discussed recently is a clarification of the
>>> XPath context for the xpath1.0 type.
>>>
>>> Lada
>>>
>>> Kent Watsen  writes:
>>>
>>>> NETMOD WG,
>>>>
>>>> A conversation in NETCONF WG regarding the yang-push noted that it
>>>> might be time to update RFC 6991, in particular to introduce a type for time-duration.
>>>>
>>>>    
>>>> https://mailarchive.ietf.org/arch/msg/netconf/KaUJloIShkLNIXTuHZNwB-
>>>> SYBnQ
>>>>
>>>> In addition, it might be good to introduce [inet?] types for RFC
>>>> 5322 (Internet Message Format) including perhaps:
>>>>
>>>>    - email-address        (addr-spec, per Section 3.4.1)
>>>>    - named-email-address  (name-addr, per Section 3.4)
>>>>
>>>>
>>>> Kent // contributor
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> --
>>> Ladislav Lhotka
>>> Head, CZ.NIC Labs
>>> PGP Key ID: 0xB8F92B08A9F76C67
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> -- 
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         


From nobody Fri Nov  2 05:03: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 BFCFE124408 for ; Fri,  2 Nov 2018 05:03:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z47C9bvBS03r for ; Fri,  2 Nov 2018 05:03:49 -0700 (PDT)
Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77E48130DC1 for ; Fri,  2 Nov 2018 05:03:49 -0700 (PDT)
Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id 4BEAE40AB0 for ; Fri,  2 Nov 2018 06:02:56 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id IYACgKMkRE0jMIYACghvwQ; Fri, 02 Nov 2018 06:02:56 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:References:Cc:To:From:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=GXJWftpzBHAlkVbQElCtn2MT/jnkzdpA6I/i2gNiwmI=; b=sa79CPILEgLz3MCPebNAoXwHOr sLWHvRRmKzNzg+D6vH/1iI9kq+y8LHaR35MPbw8KtD3BRtsIudzcUmTvbsU8XZtQajTXLaT7nwR3i 3A0zBYbse1g9FCZJjsWbL37/E;
Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:46120 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gIYAB-001q4F-UX; Fri, 02 Nov 2018 06:02:56 -0600
From: Lou Berger 
To: NetMod WG 
Cc: NetMod WG Chairs 
References: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
Message-ID: 
Date: Fri, 2 Nov 2018 08:02:55 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <7fe4a6a2-ec5e-1336-d5c0-34fd698e26fb@labn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.106.211
X-Source-L: No
X-Exim-ID: 1gIYAB-001q4F-UX
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:46120
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Org: HG=bhcustomer;ORG=bluehost;
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] WG adoption poll draft-kwatsen-netmod-artwork-folding-08
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 02 Nov 2018 12:03:51 -0000

Hi,

     The adoption poll is closed.

Authors,

     Please submit draft-kwatsen-netmod-artwork-folding-08 as 
draft-ietf-netmod-artwork-folding-00 with only the filename and date 
changed.  Issues raised during adoption should be addressed in -01 
(including, if you are so inclined, adding an open issues section.)

Thank you,

Lou(and co-chairs)

On 10/18/2018 9:03 AM, Lou Berger wrote:
> All,
>
> This is start of a two week poll on making
> draft-kwatsen-netmod-artwork-folding-08 a working group
> document. Please send email to the list indicating "yes/support" or
> "no/do not support".  If indicating no, please state your reservations
> with the document.  If yes, please also feel free to provide comments
> you'd like to see addressed once the document is a WG document.
>
> The poll ends Oct 1.
>
> Thanks,
>
> Lou (and co-chairs)
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Fri Nov  2 05:16:14 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524BF1274D0 for ; Fri,  2 Nov 2018 05:16:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.589
X-Spam-Level: 
X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 MR3-54o5z_9k for ; Fri,  2 Nov 2018 05:16:09 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DEC6124408 for ; Fri,  2 Nov 2018 05:16:09 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 4E87FB65A63E9; Fri,  2 Nov 2018 12:16:05 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 2 Nov 2018 12:16:06 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.136]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0415.000; Fri, 2 Nov 2018 20:16:01 +0800
From: Qin Wu 
To: Juergen Schoenwaelder 
CC: netmod 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AdRyf5vgyfUzQEJVR2+sO4Bg+/PMrf//hDiAgADIMqg=
Date: Fri, 2 Nov 2018 12:16:00 +0000
Message-ID: 
References: ,  <20181102081929.k72onwwawkblz3od@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181102081929.k72onwwawkblz3od@anna.jacobs.jacobs-university.de>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B0EAE38nkgeml513mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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: Fri, 02 Nov 2018 12:16:13 -0000

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

SSBjYW4gdm9sdW50ZWVyIHRvIGRvIHRoYXQgaWYgdGhpcyBoZWxwcy4NCg0Kt6K8/sjLo7ogSnVl
cmdlbiBTY2hvZW53YWVsZGVyDQrK1bz+yMujuiBRaW4gV3U8YmlsbC53dUBodWF3ZWkuY29tPG1h
aWx0bzpiaWxsLnd1QGh1YXdlaS5jb20+Pg0Ks63LzaO6IG5ldG1vZDxuZXRtb2RAaWV0Zi5vcmc8
bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+DQrW98zio7ogUmU6IFtuZXRtb2RdIGZvciBhIGZ1dHVy
ZSByZmM2OTkxYmlzDQrKsbzko7ogMjAxOC0xMS0wMiAxNToyMzoxMA0KDQpJdCBzZWVtcyBzb21l
b25lIHNob3VsZCBkcmFmdCBhbiBpZXRmLWdlbyB5YW5nIG1vZHVsZSBwcm9wb3NhbC4NCg0KL2pz
DQoNCk9uIEZyaSwgTm92IDAyLCAyMDE4IGF0IDA3OjQyOjU4QU0gKzAwMDAsIFFpbiBXdSB3cm90
ZToNCj4gTG9uZ2l0dWRlIGlzIG5vdCBkZWZpbmVkIGluIFJGQzgyOTksIFJGQzgyOTkgcHJvdmlk
ZSBsb2NhdGlvbiBwYXJhbWV0ZXIgc3VjaCBhcyBjaXR5LCBjb3VudHJ5LCBjb3VudHJ5LWNvZGUs
IHBvc3RhbC1jb2RlLCBzdHJlZXQuDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQv
ZHJhZnQtYWNlZS1vc3BmLWdlby1sb2NhdGlvbi0wNS50eHQgIHNlZW1zIHRvIHByb3ZpZGUgYSBm
ZXcgZGVmaW5pdGlvbnMgb2YgbG9uZ2l0dWRlIGFuZCBsYXRpdHVkZSBpbiBzZWN0aW9uIDI6DQo+
IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWVkb3JmLWxtYXAtYWx0by0wMiNz
ZWN0aW9uLTYuMiBwcm92aWRlIGFuIGV4YW1wbGUgb2YgbG9uZ2l0dWRlIHVzYWdlIGluIHRhYmxl
IDEgd2hpY2ggdXNlIGRpZmZlcmVudCB1bml0KGkuZS4sZGVjaW1hbCBkZWdyZWUpDQo+IFNlZSBo
dHRwczovL3d3dy5yYXBpZHRhYmxlcy5jb20vY29udmVydC9udW1iZXIvZGVncmVlcy10by1kZWdy
ZWVzLW1pbnV0ZXMtc2Vjb25kcy5odG1sDQo+IFJGQzYyODAgcHJvdmlkZSBhIGdvb2QgdGF4b25v
bXkgb2YgbG9jYXRpb24gb2JqZWN0Lg0KPiAiDQo+ICAgIExvY2F0aW9uIE9iamVjdCAoTE8pOiAg
IEFuIG9iamVjdCB1c2VkIHRvIGNvbnZleSBsb2NhdGlvbiBpbmZvcm1hdGlvbg0KPiAgICAgICB0
b2dldGhlciB3aXRoIFByaXZhY3kgUnVsZXMuICBHZW9wcml2IHN1cHBvcnRzIGJvdGggZ2VvZGV0
aWMNCj4gICAgICAgbG9jYXRpb24gZGF0YSAobGF0aXR1ZGUsIGxvbmdpdHVkZSwgYWx0aXR1ZGUs
IGV0Yy4pIGFuZCBjaXZpYw0KPiAgICAgICBsb2NhdGlvbiBkYXRhIChzdHJlZXQsIGNpdHksIHN0
YXRlLCBldGMuKS4gIEVpdGhlciBvciBib3RoIHR5cGVzDQo+ICAgICAgIG9mIGxvY2F0aW9uIGlu
Zm9ybWF0aW9uIG1heSBiZSBwcmVzZW50IGluIGEgc2luZ2xlIExPIChzZWUgdGhlDQo+ICAgICAg
IGNvbnNpZGVyYXRpb25zIGluIFs1XSBmb3IgTE9zIGNvbnRhaW5pbmcgbXVsdGlwbGUgbG9jYXRp
b25zKS4NCj4gICAgICAgTG9jYXRpb24gT2JqZWN0cyB0eXBpY2FsbHkgaW5jbHVkZSBzb21lIHNv
cnQgb2YgaWRlbnRpZmllciBvZiB0aGUNCj4gICAgICAgVGFyZ2V0Lg0KPiAiDQo+DQo+IC1RaW4N
Cj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogSnVlcmdlbiBTY2hvZW53YWVsZGVyIFtt
YWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlXQ0KPiC3osvNyrG85Dog
MjAxOMTqMTHUwjLI1SAxNTowNw0KPiDK1bz+yMs6IFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29t
Pg0KPiCzrcvNOiBuZXRtb2QgPG5ldG1vZEBpZXRmLm9yZz4NCj4g1vfM4jogUmU6IFtuZXRtb2Rd
IGZvciBhIGZ1dHVyZSByZmM2OTkxYmlzDQo+DQo+IEkgc2VhcmNoZWQgZm9yIGxvbmdpdHV0ZSBv
ciBnZW8gaW4gUkZDIDgyOTkgYW5kIHRoaXMgd2FzIG5vdCBhIGJpZyBoaXQuIENvbmNyZXRlIGRl
ZmluaXRpb25zIHdpbGwgaGVscC4gSSBkbyBrbm93IGFib3V0DQo+IGh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1pcnRmLW5tcmctbG9jYXRpb24taXBmaXgtMDcgYW5kIHRoYXQgaGFz
IGJlZW4gZHJhZ2dpbmcgb24gZnJvbSAyMDEyIHRvIDIwMTYgd2l0aGluIHRoZSBOTVJHIGFuZCBJ
IHRoaW5rIHRoaXMgZXZlbiBoYWQgYSBsaWZlIG91dHNpZGUgdGhlIE5NUkcgYmVmb3JlLiBXaGF0
IEkgYW0gbG9va2luZyBmb3IgaXMgY29uY3JldGUgKGlkZWFsbHkgWUFORykgZGVmaW5pdGlvbnMg
dGhhdCBwZW9wbGUgaGF2ZSBhbHJlYWR5IGNyZWF0ZWQgYW5kIHRoYXQgY2FuIGJlIHRoZSBiYXNp
cyBvZiBhIGNvbW1vbiBzdGFuZGFyZC4gQW5kIG9mIGNvdXJzZSBhbiBhcmd1bWVudCB3aHkgbG9j
YXRpb24gZGF0YSBpcyBzbyBlc3NlbnRpYWwgdGhhdCBpdCBoYXMgdG8gYmUgaW4gaWV0Zi15YW5n
LXR5cGVzIGFuZCBjYW4ndCBiZSBpbiBzYXkgYSBtb2R1bGUgaWV0Zi1nZW8tdHlwZXMuDQo+DQo+
IC9qcw0KPg0KPiBPbiBGcmksIE5vdiAwMiwgMjAxOCBhdCAwMzoxNzoyMUFNICswMDAwLCBRaW4g
V3Ugd3JvdGU6DQo+ID4gQWdyZWUgd2l0aCB0aGlzIGNyaXRlcmlhLCByZW1lbWJlciBnZW8gbG9j
YXRpb24gcHJvcG9zYWwgd2FzIGRpc2N1c3NlZCBiZWZvcmUgYnkgQUxUTyBwcm9wb25lbnRzIGlu
IExNQVAsIGluIGFkZGl0aW9uLCBsb2NhdGlvbiBzZXJ2aWNlIGlzIHVzZWZ1bCBmb3IgTDNWUE4g
c2V2aWNlIHBsYWNlbWVudCwgc2VlIGV4YW1wbGUgY2FzZSBpbiBSRkM4Mjk5IHdoaWNoIGNhbiBz
ZWxlY3QgYXBwcm9wcmlhdGUgUEUgYmFzZWQgb24gbG9jYXRpb24gaW5mby4gQWNlZSBhbHNvIHBy
b3ZpZGVkIGEgdmFsaWQgdXNlIGNhc2UgaW4gdGhpcyBlLW1haWwgdGhyZWFkLg0KPiA+DQo+ID4g
t6K8/sjLo7ogSnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+ID4gytW8/sjLo7ogUWluIFd1PGJpbGwu
d3VAaHVhd2VpLmNvbTxtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tPj4NCj4gPiCzrcvNo7ogbmV0
bW9kPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NCj4gPiDW98zio7og
UmU6IFtuZXRtb2RdIGZvciBhIGZ1dHVyZSByZmM2OTkxYmlzDQo+ID4gyrG85KO6IDIwMTgtMTEt
MDEgMjA6MDQ6MTUNCj4gPg0KPiA+IEkgdGhpbmsgd2UgbmVlZCB0byBmaW5kIGEgd2F5IHRvIGxp
bWl0IHRoZSB1cGRhdGUgdG8gdHlwZXMgdGhhdCBhcmUNCj4gPiBrbm93biAob3IgZXhwZWN0ZWQp
IHRvIGJlICd3aWRlbHknIG5lZWRlZC4gSW4gb3RoZXIgd29yZHMsIGZvciBldmVyeQ0KPiA+IHBy
b3Bvc2VkIHR5cGUsIGFuIGFyZ3VtZW50IHNob3VsZCBiZSBtYWRlIHdoeSB0aGlzIHNob3VsZCBi
ZSBpbmNsdWRlZA0KPiA+IGluIFJGQyA2OTkxYmlzLg0KPiA+DQo+ID4gL2pzDQo+ID4NCj4gPiBP
biBUaHUsIE5vdiAwMSwgMjAxOCBhdCAxMTo1NToyNUFNICswMDAwLCBRaW4gV3Ugd3JvdGU6DQo+
ID4gPiBJIGFtIHdvbmRlcmluZyBpZiB3ZSBjYW4gYWRkIGxvbmdpdHVkZSwgbGF0aXR1ZGUgaW4g
RE1TIG9yIGRlY2ltYWwNCj4gPiA+IGRlZ3JlZSwgRnVydGhlciB3ZSBjYW4gY29uc2lkZXIgdG8g
YWRkIFBvc3RhbC1jb2RlLCBDb3VudHJ5LWNvZGUNCj4gPiA+IGxpa2UgTG9jYXRpb24gdHlwZS4N
Cj4gPiA+DQo+ID4gPiAtUWluDQo+ID4gPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gPiA+ILeivP7I
yzogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSnVlcmdlbg0K
PiA+ID4gU2Nob2Vud2FlbGRlcg0KPiA+ID4gt6LLzcqxvOQ6IDIwMTjE6jEw1MIzMcjVIDIwOjQ3
DQo+ID4gPiDK1bz+yMs6IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4g1vfM4jogUmU6IFtuZXRtb2Rd
IGZvciBhIGZ1dHVyZSByZmM2OTkxYmlzDQo+ID4gPg0KPiA+ID4gSGVyZSBpcyBteSBsaXN0IG9m
IHBvc3NpYmxlIGFkZGl0aW9ucy4gSSBtaWdodCBoYXZlIGxvc3Qgc29tZSBpdGVtcyBvbiBhIGNv
bXB1dGVyIHRoYXQgbWVhbndoaWxlIGlzIG5vdCB1c2VkIGFueW1vcmUsIEkgd2lsbCBoYXZlIHRv
IGRpZyBhIGJpdCB0byBzZWUgd2hhdCBJIGNhbiByZWNvdmVyLg0KPiA+ID4NCj4gPiA+IC9qcw0K
PiA+ID4NCj4gPiA+IE9uIFdlZCwgT2N0IDMxLCAyMDE4IGF0IDAxOjI2OjAxUE0gKzAxMDAsIExh
ZGlzbGF2IExob3RrYSB3cm90ZToNCj4gPiA+ID4gSGksDQo+ID4gPiA+DQo+ID4gPiA+IGFub3Ro
ZXIgdXBkYXRlIHRoYXQgd2FzIGRpc2N1c3NlZCByZWNlbnRseSBpcyBhIGNsYXJpZmljYXRpb24g
b2YNCj4gPiA+ID4gdGhlIFhQYXRoIGNvbnRleHQgZm9yIHRoZSB4cGF0aDEuMCB0eXBlLg0KPiA+
ID4gPg0KPiA+ID4gPiBMYWRhDQo+ID4gPiA+DQo+ID4gPiA+IEtlbnQgV2F0c2VuIDxrd2F0c2Vu
QGp1bmlwZXIubmV0PiB3cml0ZXM6DQo+ID4gPiA+DQo+ID4gPiA+ID4gTkVUTU9EIFdHLA0KPiA+
ID4gPiA+DQo+ID4gPiA+ID4gQSBjb252ZXJzYXRpb24gaW4gTkVUQ09ORiBXRyByZWdhcmRpbmcg
dGhlIHlhbmctcHVzaCBub3RlZCB0aGF0DQo+ID4gPiA+ID4gaXQgbWlnaHQgYmUgdGltZSB0byB1
cGRhdGUgUkZDIDY5OTEsIGluIHBhcnRpY3VsYXIgdG8gaW50cm9kdWNlIGEgdHlwZSBmb3IgdGlt
ZS1kdXJhdGlvbi4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gaHR0cHM6Ly9tYWls
YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9uZXRjb25mL0thVUpsb0lTaGtMTklYVHVIWg0KPiA+
ID4gPiA+IE53Qi0NCj4gPiA+ID4gPiBTWUJuUQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSW4gYWRk
aXRpb24sIGl0IG1pZ2h0IGJlIGdvb2QgdG8gaW50cm9kdWNlIFtpbmV0P10gdHlwZXMgZm9yIFJG
Qw0KPiA+ID4gPiA+IDUzMjIgKEludGVybmV0IE1lc3NhZ2UgRm9ybWF0KSBpbmNsdWRpbmcgcGVy
aGFwczoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgLSBlbWFpbC1hZGRyZXNzICAgICAgICAoYWRk
ci1zcGVjLCBwZXIgU2VjdGlvbiAzLjQuMSkNCj4gPiA+ID4gPiAgIC0gbmFtZWQtZW1haWwtYWRk
cmVzcyAgKG5hbWUtYWRkciwgcGVyIFNlY3Rpb24gMy40KQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4N
Cj4gPiA+ID4gPiBLZW50IC8vIGNvbnRyaWJ1dG9yDQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+
ID4gPiA+DQo+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4gPiA+ID4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gbmV0bW9k
QGlldGYub3JnDQo+ID4gPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9uZXRtb2QNCj4gPiA+ID4NCj4gPiA+ID4gLS0NCj4gPiA+ID4gTGFkaXNsYXYgTGhvdGthDQo+
ID4gPiA+IEhlYWQsIENaLk5JQyBMYWJzDQo+ID4gPiA+IFBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhB
OUY3NkM2Nw0KPiA+ID4gPg0KPiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPiA+ID4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gPiA+IG5l
dG1vZEBpZXRmLm9yZw0KPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL25ldG1vZA0KPiA+ID4NCj4gPiA+IC0tDQo+ID4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIg
ICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiA+ID4gUGhvbmU6ICs0
OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2Vy
bWFueQ0KPiA+ID4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cu
amFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPiA+DQo+ID4gLS0NCj4gPiBKdWVyZ2VuIFNjaG9lbndh
ZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiA+IFBob25l
OiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8
IEdlcm1hbnkNCj4gPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3
dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+DQo+IC0tDQo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRl
ciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+IFBob25lOiArNDkg
NDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1h
bnkNCj4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2Jz
LXVuaXZlcnNpdHkuZGUvPg0KDQotLQ0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBK
YWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNClBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAg
ICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCkZheDogICArNDkg
NDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4N
Cg==

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











I can volunteer to d=
o that if this helps.








=B7=A2=BC=FE=C8=CB=A3=BA Juergen Schoenwaelder


=CA=D5=BC=FE=C8=CB=A3=BA Qin Wu<bill.wu@huawei.com>


=B3=AD=CB=CD=A3=BA netmod<netmod@ietf.org>


=D6=F7=CC=E2=A3=BA Re: [netmod] for a future rfc6991bis


=CA=B1=BC=E4=A3=BA 2018-11-02 15:23:10









It seems someone should draft an ietf-geo yang mod=
ule proposal.



/js



On Fri, Nov 02, 2018 at 07:42:58AM +0000, Qin Wu wrote:

> Longitude is not defined in RFC8299, RFC8299 provide location paramete=
r such as city, country, country-code, postal-code, street.

> https://www.ietf.org/archive/id/draft-acee-ospf-geo-location-05.t=
xt  seems to provide a few definitions of longitude and latitude i=
n section 2:

> https://tools.ietf.org/html/draft-seedorf-lmap-alto-02#section-6.2=
 provide an example of longitude usage in table 1 which use different u=
nit(i.e.,decimal degree)

> See 
https://www.rapidtables.com/convert/number/degrees-to-degrees-minutes-secon=
ds.html

> RFC6280 provide a good taxonomy of location object.

> "

>    Location Object (LO):   An object used to =
convey location information

>       together with Privacy Rules. =
 Geopriv supports both geodetic

>       location data (latitude, longitude=
, altitude, etc.) and civic

>       location data (street, city, state=
, etc.).  Either or both types

>       of location information may be pre=
sent in a single LO (see the

>       considerations in [5] for LOs cont=
aining multiple locations).

>       Location Objects typically include=
 some sort of identifier of the

>       Target.

> "

> 

> -Qin

> -----=D3=CA=BC=FE=D4=AD=BC=FE-----

> =B7=A2=BC=FE=C8=CB: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]


> =B7=A2=CB=CD=CA=B1=BC=E4: 2018=C4=EA11=D4=C22=C8=D5 15:07

> =CA=D5=BC=FE=C8=CB: Qin Wu <bill.wu@huawei.com>

> =B3=AD=CB=CD: netmod <netmod@ietf.org>

> =D6=F7=CC=E2: Re: [netmod] for a future rfc6991bis

> 

> I searched for longitute or geo in RFC 8299 and this was not a big hit=
. Concrete definitions will help. I do know about

> https://tools.ietf.org/html/draft-irtf-nmrg-location-ipfix-07 and t=
hat has been dragging on from 2012 to 2016 within the NMRG and I think this=
 even had a life outside the NMRG before.
 What I am looking for is concrete (ideally YANG) definitions that people h=
ave already created and that can be the basis of a common standard. And of =
course an argument why location data is so essential that it has to be in i=
etf-yang-types and can't be in say
 a module ietf-geo-types.

> 

> /js

> 

> On Fri, Nov 02, 2018 at 03:17:21AM +0000, Qin Wu wrote:

> > Agree with this criteria, remember geo location proposal was disc=
ussed before by ALTO proponents in LMAP, in addition, location service is u=
seful for L3VPN sevice placement, see example case in RFC8299 which can sel=
ect appropriate PE based on location info.
 Acee also provided a valid use case in this e-mail thread.

> > 

> > =B7=A2=BC=FE=C8=CB=A3=BA Juergen Schoenwaelder

> > =CA=D5=BC=FE=C8=CB=A3=BA Qin Wu<bill.wu@huawei.com<mailto:b=
ill.wu@huawei.com>>

> > =B3=AD=CB=CD=A3=BA netmod<netmod@ietf.org<mailto:netmod@iet=
f.org>>

> > =D6=F7=CC=E2=A3=BA Re: [netmod] for a future rfc6991bis

> > =CA=B1=BC=E4=A3=BA 2018-11-01 20:04:15

> > 

> > I think we need to find a way to limit the update to types that a=
re 

> > known (or expected) to be 'widely' needed. In other words, for ev=
ery 

> > proposed type, an argument should be made why this should be incl=
uded 

> > in RFC 6991bis.

> > 

> > /js

> > 

> > On Thu, Nov 01, 2018 at 11:55:25AM +0000, Qin Wu wrote:

> > > I am wondering if we can add longitude, latitude in DMS or d=
ecimal 

> > > degree, Further we can consider to add Postal-code, Country-=
code 

> > > like Location type.

> > >

> > > -Qin

> > > -----=D3=CA=BC=FE=D4=AD=BC=FE-----

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


> > > Schoenwaelder

> > > =B7=A2=CB=CD=CA=B1=BC=E4: 2018=C4=EA10=D4=C231=C8=D5 20:47
> > > =CA=D5=BC=FE=C8=CB: netmod@ietf.org

> > > =D6=F7=CC=E2: Re: [netmod] for a future rfc6991bis

> > >

> > > Here is my list of possible additions. I might have lost som=
e items on a computer that meanwhile is not used anymore, I will have to di=
g a bit to see what I can recover.

> > >

> > > /js

> > >

> > > On Wed, Oct 31, 2018 at 01:26:01PM +0100, Ladislav Lhotk=
a wrote:

> > > > Hi,

> > > >

> > > > another update that was discussed recently is a clarifi=
cation of 

> > > > the XPath context for the xpath1.0 type.

> > > >

> > > > Lada

> > > >

> > > > Kent Watsen <kwatsen@juniper.net> writes:

> > > >

> > > > > NETMOD WG,

> > > > >

> > > > > A conversation in NETCONF WG regarding the yang-pu=
sh noted that 

> > > > > it might be time to update RFC 6991, in particular=
 to introduce a type for time-duration.

> > > > >

> > > > >

> > > > > 
https://mailarchive.ietf.org/arch/msg/netconf/KaUJloIShkLNIXTuHZ

> > > > > NwB-

> > > > > SYBnQ

> > > > >

> > > > > In addition, it might be good to introduce [inet?]=
 types for RFC

> > > > > 5322 (Internet Message Format) including perhaps:<=
br>
> > > > >

> > > > >   - email-address    =
;    (addr-spec, per Section 3.4.1)

> > > > >   - named-email-address  (name-addr=
, per Section 3.4)

> > > > >

> > > > >

> > > > > Kent // contributor

> > > > >

> > > > >

> > > > >

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

> > > > > netmod@ietf.org

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

> > > >

> > > > --

> > > > Ladislav Lhotka

> > > > Head, CZ.NIC Labs

> > > > PGP Key ID: 0xB8F92B08A9F76C67

> > > >

> > > > _______________________________________________

> > > > netmod mailing list

> > > > netmod@ietf.org

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

> > >

> > > --

> > > Juergen Schoenwaelder      &nb=
sp;    Jacobs University Bremen gGmbH

> > > Phone: +49 421 200 3587     &nb=
sp;   Campus Ring 1 | 28759 Bremen | Germany

> > > Fax:   +49 421 200 3103    =
;     <https://www.jacobs-university.de/>

> > 

> > --

> > Juergen Schoenwaelder       &n=
bsp;   Jacobs University Bremen gGmbH

> > Phone: +49 421 200 3587      &n=
bsp;  Campus Ring 1 | 28759 Bremen | Germany

> > Fax:   +49 421 200 3103    &nbs=
p;    <http=
s://www.jacobs-university.de/>

> 

> -- 

> Juergen Schoenwaelder        &=
nbsp;  Jacobs University Bremen gGmbH

> Phone: +49 421 200 3587       &=
nbsp; Campus Ring 1 | 28759 Bremen | Germany

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



-- 

Juergen Schoenwaelder         =
  Jacobs University Bremen gGmbH

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

Fax:   +49 421 200 3103      &n=
bsp;  <https://www.ja=
cobs-university.de/>







--_000_B8F9A780D330094D99AF023C5877DABA9B0EAE38nkgeml513mbschi_--


From nobody Fri Nov  2 07:55:49 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DDD1292F1 for ; Fri,  2 Nov 2018 07:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.699
X-Spam-Level: 
X-Spam-Status: No, score=-14.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7l_Wh5mbOP9 for ; Fri,  2 Nov 2018 07:55:45 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CC0D123FFD for ; Fri,  2 Nov 2018 07:55:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34470; q=dns/txt; s=iport; t=1541170545; x=1542380145; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=45V1dYxuU015ZqBzqQDPWkZAV/0kppzSSFH2723gSY8=; b=hxbpg2vHg/NbIHIIZCzvKM1DhMdHwQzOhqIOX3TfqXC1jrPQF/tjG6ak pEBpFq8Wh4Qtb6+e6KZwHxCimNgxvcZuEFuDLQ17+1vKU6wtZXz3UrmDB rJgY9l4/84uwR4KfsS1AGj6dp4uvggLlJI4eqK+nGASlvxj92/b2kXw4c k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAAAAZNxb/5tdJa1hAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVMCAQEBAQELAYENSC9mfygKg2yULoINepYyFIFmCwE?= =?us-ascii?q?BGAEMhAFGAheDJyI2Cw0BAwEBAgEBAm0cDIU6AQEBAQMBASFLCw4CAgEGAg4?= =?us-ascii?q?CAQMBAgEgBwMCAgIZDAsUCQgBAQQBDQUZgwgBgR1kD4sdm06BLoE4gnUBAwK?= =?us-ascii?q?BCYRaBQWLbBeCAIEQAScfghc1gxsBAQEBAYEXFAEMBgElEQkBBRARgj0xgiY?= =?us-ascii?q?Cjl0WkDcJAoZqiiAYgVWPBolAg0WHUIJCAhEUgSYkBitkcXAVOyoBgkGGBTO?= =?us-ascii?q?EYYU+bwGKeg4XgQiBHwEB?=
X-IronPort-AV: E=Sophos;i="5.54,456,1534809600";  d="scan'208,217";a="472842176"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Nov 2018 14:55:43 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id wA2EthxY009226 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 2 Nov 2018 14:55:43 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 2 Nov 2018 10:55:43 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1395.000; Fri, 2 Nov 2018 10:55:43 -0400
From: "Acee Lindem (acee)" 
To: Qin Wu , Juergen Schoenwaelder 
CC: netmod 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AdRyf5vg5pZToCjlLEK5aT+9YAPiFwAJrGSAAAhCoAD//+mPgA==
Date: Fri, 2 Nov 2018 14:55:43 +0000
Message-ID: 
References:  <20181102081929.k72onwwawkblz3od@anna.jacobs.jacobs-university.de> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.15.45]
Content-Type: multipart/alternative; boundary="_000_DB8040C65AB74F3198F9477B9694AA6Dciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.154, xch-rtp-014.cisco.com
X-Outbound-Node: rcdn-core-4.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: Fri, 02 Nov 2018 14:55:48 -0000

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

SeKAmWxsIHBhcnRpY2lwYXRlIGFzIHdlbGwuIEkgYWdyZWUgaXQgc2hvdWxkIGJlIGEgc2VwYXJh
dGUgWUFORyBtb2R1bGUgYW5kIGRyYWZ0IGZyb20gdGhlIGdlby1sb2NhdGlvbiBhZHZlcnRpc2Vt
ZW50IHByb3RvY29sIHNwZWNpZmljYXRpb25zIChjdXJyZW50bHkgT1NQRiwgSVMtSVMsIEJHUCwg
YW5kIExJU1ApLg0KVGhhbmtzLA0KQWNlZQ0KDQpGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2Vz
QGlldGYub3JnPiBvbiBiZWhhbGYgb2YgUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+DQpEYXRl
OiBGcmlkYXksIE5vdmVtYmVyIDIsIDIwMTggYXQgODoxNiBBTQ0KVG86IEp1ZXJnZW4gU2Nob2Vu
d2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0KQ2M6IG5ldG1v
ZCA8bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIGZvciBhIGZ1dHVyZSBy
ZmM2OTkxYmlzDQoNCkkgY2FuIHZvbHVudGVlciB0byBkbyB0aGF0IGlmIHRoaXMgaGVscHMuDQrl
j5Hku7bkurrvvJogSnVlcmdlbiBTY2hvZW53YWVsZGVyDQrmlLbku7bkurrvvJogUWluIFd1PGJp
bGwud3VAaHVhd2VpLmNvbTxtYWlsdG86YmlsbC53dUBodWF3ZWkuY29tPj4NCuaKhOmAge+8miBu
ZXRtb2Q8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0K5Li76aKY77ya
IFJlOiBbbmV0bW9kXSBmb3IgYSBmdXR1cmUgcmZjNjk5MWJpcw0K5pe26Ze077yaIDIwMTgtMTEt
MDIgMTU6MjM6MTANCg0KSXQgc2VlbXMgc29tZW9uZSBzaG91bGQgZHJhZnQgYW4gaWV0Zi1nZW8g
eWFuZyBtb2R1bGUgcHJvcG9zYWwuDQoNCi9qcw0KDQpPbiBGcmksIE5vdiAwMiwgMjAxOCBhdCAw
Nzo0Mjo1OEFNICswMDAwLCBRaW4gV3Ugd3JvdGU6DQo+IExvbmdpdHVkZSBpcyBub3QgZGVmaW5l
ZCBpbiBSRkM4Mjk5LCBSRkM4Mjk5IHByb3ZpZGUgbG9jYXRpb24gcGFyYW1ldGVyIHN1Y2ggYXMg
Y2l0eSwgY291bnRyeSwgY291bnRyeS1jb2RlLCBwb3N0YWwtY29kZSwgc3RyZWV0Lg0KPiBodHRw
czovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWFjZWUtb3NwZi1nZW8tbG9jYXRpb24t
MDUudHh0ICBzZWVtcyB0byBwcm92aWRlIGEgZmV3IGRlZmluaXRpb25zIG9mIGxvbmdpdHVkZSBh
bmQgbGF0aXR1ZGUgaW4gc2VjdGlvbiAyOg0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv
ZHJhZnQtc2VlZG9yZi1sbWFwLWFsdG8tMDIjc2VjdGlvbi02LjIgcHJvdmlkZSBhbiBleGFtcGxl
IG9mIGxvbmdpdHVkZSB1c2FnZSBpbiB0YWJsZSAxIHdoaWNoIHVzZSBkaWZmZXJlbnQgdW5pdChp
LmUuLGRlY2ltYWwgZGVncmVlKQ0KPiBTZWUgaHR0cHM6Ly93d3cucmFwaWR0YWJsZXMuY29tL2Nv
bnZlcnQvbnVtYmVyL2RlZ3JlZXMtdG8tZGVncmVlcy1taW51dGVzLXNlY29uZHMuaHRtbA0KPiBS
RkM2MjgwIHByb3ZpZGUgYSBnb29kIHRheG9ub215IG9mIGxvY2F0aW9uIG9iamVjdC4NCj4gIg0K
PiAgICBMb2NhdGlvbiBPYmplY3QgKExPKTogICBBbiBvYmplY3QgdXNlZCB0byBjb252ZXkgbG9j
YXRpb24gaW5mb3JtYXRpb24NCj4gICAgICAgdG9nZXRoZXIgd2l0aCBQcml2YWN5IFJ1bGVzLiAg
R2VvcHJpdiBzdXBwb3J0cyBib3RoIGdlb2RldGljDQo+ICAgICAgIGxvY2F0aW9uIGRhdGEgKGxh
dGl0dWRlLCBsb25naXR1ZGUsIGFsdGl0dWRlLCBldGMuKSBhbmQgY2l2aWMNCj4gICAgICAgbG9j
YXRpb24gZGF0YSAoc3RyZWV0LCBjaXR5LCBzdGF0ZSwgZXRjLikuICBFaXRoZXIgb3IgYm90aCB0
eXBlcw0KPiAgICAgICBvZiBsb2NhdGlvbiBpbmZvcm1hdGlvbiBtYXkgYmUgcHJlc2VudCBpbiBh
IHNpbmdsZSBMTyAoc2VlIHRoZQ0KPiAgICAgICBjb25zaWRlcmF0aW9ucyBpbiBbNV0gZm9yIExP
cyBjb250YWluaW5nIG11bHRpcGxlIGxvY2F0aW9ucykuDQo+ICAgICAgIExvY2F0aW9uIE9iamVj
dHMgdHlwaWNhbGx5IGluY2x1ZGUgc29tZSBzb3J0IG9mIGlkZW50aWZpZXIgb2YgdGhlDQo+ICAg
ICAgIFRhcmdldC4NCj4gIg0KPg0KPiAtUWluDQo+IC0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj4g
5Y+R5Lu25Lq6OiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgW21haWx0bzpqLnNjaG9lbndhZWxkZXJA
amFjb2JzLXVuaXZlcnNpdHkuZGVdDQo+IOWPkemAgeaXtumXtDogMjAxOOW5tDEx5pyIMuaXpSAx
NTowNw0KPiDmlLbku7bkuro6IFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPg0KPiDmioTpgIE6
IG5ldG1vZCA8bmV0bW9kQGlldGYub3JnPg0KPiDkuLvpopg6IFJlOiBbbmV0bW9kXSBmb3IgYSBm
dXR1cmUgcmZjNjk5MWJpcw0KPg0KPiBJIHNlYXJjaGVkIGZvciBsb25naXR1dGUgb3IgZ2VvIGlu
IFJGQyA4Mjk5IGFuZCB0aGlzIHdhcyBub3QgYSBiaWcgaGl0Li4gQ29uY3JldGUgZGVmaW5pdGlv
bnMgd2lsbCBoZWxwLiBJIGRvIGtub3cgYWJvdXQNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LWlydGYtbm1yZy1sb2NhdGlvbi1pcGZpeC0wNyBhbmQgdGhhdCBoYXMgYmVlbiBk
cmFnZ2luZyBvbiBmcm9tIDIwMTIgdG8gMjAxNiB3aXRoaW4gdGhlIE5NUkcgYW5kIEkgdGhpbmsg
dGhpcyBldmVuIGhhZCBhIGxpZmUgb3V0c2lkZSB0aGUgTk1SRyBiZWZvcmUuIFdoYXQgSSBhbSBs
b29raW5nIGZvciBpcyBjb25jcmV0ZSAoaWRlYWxseSBZQU5HKSBkZWZpbml0aW9ucyB0aGF0IHBl
b3BsZSBoYXZlIGFscmVhZHkgY3JlYXRlZCBhbmQgdGhhdCBjYW4gYmUgdGhlIGJhc2lzIG9mIGEg
Y29tbW9uIHN0YW5kYXJkLiBBbmQgb2YgY291cnNlIGFuIGFyZ3VtZW50IHdoeSBsb2NhdGlvbiBk
YXRhIGlzIHNvIGVzc2VudGlhbCB0aGF0IGl0IGhhcyB0byBiZSBpbiBpZXRmLXlhbmctdHlwZXMg
YW5kIGNhbid0IGJlIGluIHNheSBhIG1vZHVsZSBpZXRmLWdlby10eXBlcy4NCj4NCj4gL2pzDQo+
DQo+IE9uIEZyaSwgTm92IDAyLCAyMDE4IGF0IDAzOjE3OjIxQU0gKzAwMDAsIFFpbiBXdSB3cm90
ZToNCj4gPiBBZ3JlZSB3aXRoIHRoaXMgY3JpdGVyaWEsIHJlbWVtYmVyIGdlbyBsb2NhdGlvbiBw
cm9wb3NhbCB3YXMgZGlzY3Vzc2VkIGJlZm9yZSBieSBBTFRPIHByb3BvbmVudHMgaW4gTE1BUCwg
aW4gYWRkaXRpb24sIGxvY2F0aW9uIHNlcnZpY2UgaXMgdXNlZnVsIGZvciBMM1ZQTiBzZXZpY2Ug
cGxhY2VtZW50LCBzZWUgZXhhbXBsZSBjYXNlIGluIFJGQzgyOTkgd2hpY2ggY2FuIHNlbGVjdCBh
cHByb3ByaWF0ZSBQRSBiYXNlZCBvbiBsb2NhdGlvbiBpbmZvLiBBY2VlIGFsc28gcHJvdmlkZWQg
YSB2YWxpZCB1c2UgY2FzZSBpbiB0aGlzIGUtbWFpbCB0aHJlYWQuDQo+ID4NCj4gPiDlj5Hku7bk
urrvvJogSnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+ID4g5pS25Lu25Lq677yaIFFpbiBXdTxiaWxs
Lnd1QGh1YXdlaS5jb208bWFpbHRvOmJpbGwud3VAaHVhd2VpLmNvbT4+DQo+ID4g5oqE6YCB77ya
IG5ldG1vZDxuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+DQo+ID4g5Li7
6aKY77yaIFJlOiBbbmV0bW9kXSBmb3IgYSBmdXR1cmUgcmZjNjk5MWJpcw0KPiA+IOaXtumXtO+8
miAyMDE4LTExLTAxIDIwOjA0OjE1DQo+ID4NCj4gPiBJIHRoaW5rIHdlIG5lZWQgdG8gZmluZCBh
IHdheSB0byBsaW1pdCB0aGUgdXBkYXRlIHRvIHR5cGVzIHRoYXQgYXJlDQo+ID4ga25vd24gKG9y
IGV4cGVjdGVkKSB0byBiZSAnd2lkZWx5JyBuZWVkZWQuIEluIG90aGVyIHdvcmRzLCBmb3IgZXZl
cnkNCj4gPiBwcm9wb3NlZCB0eXBlLCBhbiBhcmd1bWVudCBzaG91bGQgYmUgbWFkZSB3aHkgdGhp
cyBzaG91bGQgYmUgaW5jbHVkZWQNCj4gPiBpbiBSRkMgNjk5MWJpcy4NCj4gPg0KPiA+IC9qcw0K
PiA+DQo+ID4gT24gVGh1LCBOb3YgMDEsIDIwMTggYXQgMTE6NTU6MjVBTSArMDAwMCwgUWluIFd1
IHdyb3RlOg0KPiA+ID4gSSBhbSB3b25kZXJpbmcgaWYgd2UgY2FuIGFkZCBsb25naXR1ZGUsIGxh
dGl0dWRlIGluIERNUyBvciBkZWNpbWFsDQo+ID4gPiBkZWdyZWUsIEZ1cnRoZXIgd2UgY2FuIGNv
bnNpZGVyIHRvIGFkZCBQb3N0YWwtY29kZSwgQ291bnRyeS1jb2RlDQo+ID4gPiBsaWtlIExvY2F0
aW9uIHR5cGUuDQo+ID4gPg0KPiA+ID4gLVFpbg0KPiA+ID4gLS0tLS3pgq7ku7bljp/ku7YtLS0t
LQ0KPiA+ID4g5Y+R5Lu25Lq6OiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9y
Z10g5Luj6KGoIEp1ZXJnZW4NCj4gPiA+IFNjaG9lbndhZWxkZXINCj4gPiA+IOWPkemAgeaXtumX
tDogMjAxOOW5tDEw5pyIMzHml6UgMjA6NDcNCj4gPiA+IOaUtuS7tuS6ujogbmV0bW9kQGlldGYu
b3JnDQo+ID4gPiDkuLvpopg6IFJlOiBbbmV0bW9kXSBmb3IgYSBmdXR1cmUgcmZjNjk5MWJpcw0K
PiA+ID4NCj4gPiA+IEhlcmUgaXMgbXkgbGlzdCBvZiBwb3NzaWJsZSBhZGRpdGlvbnMuIEkgbWln
aHQgaGF2ZSBsb3N0IHNvbWUgaXRlbXMgb24gYSBjb21wdXRlciB0aGF0IG1lYW53aGlsZSBpcyBu
b3QgdXNlZCBhbnltb3JlLCBJIHdpbGwgaGF2ZSB0byBkaWcgYSBiaXQgdG8gc2VlIHdoYXQgSSBj
YW4gcmVjb3Zlci4NCj4gPiA+DQo+ID4gPiAvanMNCj4gPiA+DQo+ID4gPiBPbiBXZWQsIE9jdCAz
MSwgMjAxOCBhdCAwMToyNjowMVBNICswMTAwLCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+ID4g
PiA+IEhpLA0KPiA+ID4gPg0KPiA+ID4gPiBhbm90aGVyIHVwZGF0ZSB0aGF0IHdhcyBkaXNjdXNz
ZWQgcmVjZW50bHkgaXMgYSBjbGFyaWZpY2F0aW9uIG9mDQo+ID4gPiA+IHRoZSBYUGF0aCBjb250
ZXh0IGZvciB0aGUgeHBhdGgxLjAgdHlwZS4NCj4gPiA+ID4NCj4gPiA+ID4gTGFkYQ0KPiA+ID4g
Pg0KPiA+ID4gPiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JpdGVzOg0KPiA+
ID4gPg0KPiA+ID4gPiA+IE5FVE1PRCBXRywNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEEgY29udmVy
c2F0aW9uIGluIE5FVENPTkYgV0cgcmVnYXJkaW5nIHRoZSB5YW5nLXB1c2ggbm90ZWQgdGhhdA0K
PiA+ID4gPiA+IGl0IG1pZ2h0IGJlIHRpbWUgdG8gdXBkYXRlIFJGQyA2OTkxLCBpbiBwYXJ0aWN1
bGFyIHRvIGludHJvZHVjZSBhIHR5cGUgZm9yIHRpbWUtZHVyYXRpb24uDQo+ID4gPiA+ID4NCj4g
PiA+ID4gPg0KPiA+ID4gPiA+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv
bmV0Y29uZi9LYVVKbG9JU2hrTE5JWFR1SFoNCj4gPiA+ID4gPiBOd0ItDQo+ID4gPiA+ID4gU1lC
blENCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEluIGFkZGl0aW9uLCBpdCBtaWdodCBiZSBnb29kIHRv
IGludHJvZHVjZSBbaW5ldD9dIHR5cGVzIGZvciBSRkMNCj4gPiA+ID4gPiA1MzIyIChJbnRlcm5l
dCBNZXNzYWdlIEZvcm1hdCkgaW5jbHVkaW5nIHBlcmhhcHM6DQo+ID4gPiA+ID4NCj4gPiA+ID4g
PiAgIC0gZW1haWwtYWRkcmVzcyAgICAgICAgKGFkZHItc3BlYywgcGVyIFNlY3Rpb24gMy40LjEp
DQo+ID4gPiA+ID4gICAtIG5hbWVkLWVtYWlsLWFkZHJlc3MgIChuYW1lLWFkZHIsIHBlciBTZWN0
aW9uIDMuNCkNCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gS2VudCAvLyBjb250cmli
dXRvcg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4gbmV0bW9k
IG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4gPiA+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+ID4gPiA+DQo+ID4gPiA+
IC0tDQo+ID4gPiA+IExhZGlzbGF2IExob3RrYQ0KPiA+ID4gPiBIZWFkLCBDWi5OSUMgTGFicw0K
PiA+ID4gPiBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCj4gPiA+ID4NCj4gPiA+ID4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4g
bmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+ID4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiA+ID4gaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPiA+DQo+ID4gPiAt
LQ0KPiA+ID4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0
eSBCcmVtZW4gZ0dtYkgNCj4gPiA+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2Ft
cHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4gPiA+IEZheDogICArNDkgNDIx
IDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4g
Pg0KPiA+IC0tDQo+ID4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5p
dmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAg
IENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+ID4gRmF4OiAgICs0OSA0
MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K
Pg0KPiAtLQ0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJz
aXR5IEJyZW1lbiBnR21iSA0KPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1
cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+IEZheDogICArNDkgNDIxIDIwMCAz
MTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCg0KLS0NCkp1
ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdH
bWJIDQpQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1
OSBCcmVtZW4gfCBHZXJtYW55DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRw
czovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo=

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

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1pbmdMaVU7DQoJcGFub3NlLTE6MiAy
IDUgOSAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1h
dGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250
LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFu
b3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi
XEBNaW5nTGlVIjsNCglwYW5vc2UtMToyIDEgNiA5IDAgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4
IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h
bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN
Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N
CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u
TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1
cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNv
bm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1z
by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5lbWFpbHF1b3RlLCBsaS5lbWFp
bHF1b3RlLCBkaXYuZW1haWxxdW90ZQ0KCXttc28tc3R5bGUtbmFtZTplbWFpbHF1b3RlOw0KCW1z
by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MS4wcHQ7DQoJYm9yZGVyOm5vbmU7DQoJcGFk
ZGluZzowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu
cy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y
ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0
ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv
bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu
Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ
e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF
Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv
bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi
PknigJlsbCBwYXJ0aWNpcGF0ZSBhcyB3ZWxsLiBJIGFncmVlIGl0IHNob3VsZCBiZSBhIHNlcGFy
YXRlIFlBTkcgbW9kdWxlIGFuZCBkcmFmdCBmcm9tIHRoZSBnZW8tbG9jYXRpb24gYWR2ZXJ0aXNl
bWVudCBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucyAoY3VycmVudGx5IE9TUEYsIElTLUlTLCBCR1As
IGFuZCBMSVNQKS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5UaGFua3MsPGJyPg0KQWNlZTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g
MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5uZXRtb2Qg
Jmx0O25ldG1vZC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgUWluIFd1ICZsdDti
aWxsLnd1QGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgTm92ZW1iZXIg
MiwgMjAxOCBhdCA4OjE2IEFNPGJyPg0KPGI+VG86IDwvYj5KdWVyZ2VuIFNjaG9lbndhZWxkZXIg
Jmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDs8YnI+DQo8Yj5DYzog
PC9iPm5ldG1vZCAmbHQ7bmV0bW9kQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5S
ZTogW25ldG1vZF0gZm9yIGEgZnV0dXJlIHJmYzY5OTFiaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6
LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0
OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDouNWluIj4NCkkgY2FuIHZvbHVu
dGVlciB0byBkbyB0aGF0IGlmIHRoaXMgaGVscHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk
aW5nOjYuMHB0IDBpbiAwaW4gMGluIiBuYW1lPSJ4X0FueU9mZmljZS1CYWNrZ3JvdW5kLUltYWdl
Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+
PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Ok1pbmdMaVUiPuWPkTwvc3Bhbj48L2I+PGI+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5Lu25Lq677yaPC9z
cGFuPjwvYj48Yj4NCjwvYj5KdWVyZ2VuIFNjaG9lbndhZWxkZXI8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu
Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7mlLbk
u7bkurrvvJo8L3NwYW4+PC9iPjxiPg0KPC9iPlFpbiBXdSZsdDs8YSBocmVmPSJtYWlsdG86Ymls
bC53dUBodWF3ZWkuY29tIj5iaWxsLnd1QGh1YXdlaS5jb208L2E+Jmd0OzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0
Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsi
PuaKhOmAge+8mjwvc3Bhbj48L2I+PGI+DQo8L2I+bmV0bW9kJmx0OzxhIGhyZWY9Im1haWx0bzpu
ZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp
biI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5Li7
PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6TWluZ0xpVSI+6aKYPC9zcGFu
PjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7v
vJo8L3NwYW4+PC9iPjxiPg0KPC9iPlJlOiBbbmV0bW9kXSBmb3IgYSBmdXR1cmUgcmZjNjk5MWJp
czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpNaW5nTGlV
Ij7ml7bpl7Q8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNUyBH
b3RoaWMmcXVvdDsiPu+8mjwvc3Bhbj48L2I+PGI+DQo8L2I+MjAxOC0xMS0wMiAxNToyMzoxMDxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdCI+SXQgc2VlbXMgc29tZW9uZSBzaG91bGQgZHJhZnQgYW4gaWV0
Zi1nZW8geWFuZyBtb2R1bGUgcHJvcG9zYWwuPGJyPg0KPGJyPg0KL2pzPGJyPg0KPGJyPg0KT24g
RnJpLCBOb3YgMDIsIDIwMTggYXQgMDc6NDI6NThBTSAmIzQzOzAwMDAsIFFpbiBXdSB3cm90ZTo8
YnI+DQomZ3Q7IExvbmdpdHVkZSBpcyBub3QgZGVmaW5lZCBpbiBSRkM4Mjk5LCBSRkM4Mjk5IHBy
b3ZpZGUgbG9jYXRpb24gcGFyYW1ldGVyIHN1Y2ggYXMgY2l0eSwgY291bnRyeSwgY291bnRyeS1j
b2RlLCBwb3N0YWwtY29kZSwgc3RyZWV0Ljxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1hY2VlLW9zcGYtZ2VvLWxvY2F0aW9uLTA1LnR4dCI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1hY2VlLW9zcGYtZ2VvLWxvY2F0
aW9uLTA1LnR4dDwvYT4mbmJzcDsgc2VlbXMgdG8gcHJvdmlkZSBhIGZldyBkZWZpbml0aW9ucyBv
ZiBsb25naXR1ZGUgYW5kIGxhdGl0dWRlIGluIHNlY3Rpb24gMjo8YnI+DQomZ3Q7IDxhIGhyZWY9
Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zZWVkb3JmLWxtYXAtYWx0by0wMiNz
ZWN0aW9uLTYuMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlZWRvcmYtbG1h
cC1hbHRvLTAyI3NlY3Rpb24tNi4yPC9hPiBwcm92aWRlIGFuIGV4YW1wbGUgb2YgbG9uZ2l0dWRl
IHVzYWdlIGluIHRhYmxlIDEgd2hpY2ggdXNlIGRpZmZlcmVudCB1bml0KGkuZS4sZGVjaW1hbCBk
ZWdyZWUpPGJyPg0KJmd0OyBTZWUgPGEgaHJlZj0iaHR0cHM6Ly93d3cucmFwaWR0YWJsZXMuY29t
L2NvbnZlcnQvbnVtYmVyL2RlZ3JlZXMtdG8tZGVncmVlcy1taW51dGVzLXNlY29uZHMuaHRtbCI+
DQpodHRwczovL3d3dy5yYXBpZHRhYmxlcy5jb20vY29udmVydC9udW1iZXIvZGVncmVlcy10by1k
ZWdyZWVzLW1pbnV0ZXMtc2Vjb25kcy5odG1sPC9hPjxicj4NCiZndDsgUkZDNjI4MCBwcm92aWRl
IGEgZ29vZCB0YXhvbm9teSBvZiBsb2NhdGlvbiBvYmplY3QuPGJyPg0KJmd0OyAmcXVvdDs8YnI+
DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExvY2F0aW9uIE9iamVjdCAoTE8pOiZuYnNwOyZuYnNw
OyBBbiBvYmplY3QgdXNlZCB0byBjb252ZXkgbG9jYXRpb24gaW5mb3JtYXRpb248YnI+DQomZ3Q7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvZ2V0aGVyIHdpdGggUHJpdmFj
eSBSdWxlcy4mbmJzcDsgR2VvcHJpdiBzdXBwb3J0cyBib3RoIGdlb2RldGljPGJyPg0KJmd0OyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsb2NhdGlvbiBkYXRhIChsYXRpdHVk
ZSwgbG9uZ2l0dWRlLCBhbHRpdHVkZSwgZXRjLikgYW5kIGNpdmljPGJyPg0KJmd0OyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBsb2NhdGlvbiBkYXRhIChzdHJlZXQsIGNpdHks
IHN0YXRlLCBldGMuKS4mbmJzcDsgRWl0aGVyIG9yIGJvdGggdHlwZXM8YnI+DQomZ3Q7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9mIGxvY2F0aW9uIGluZm9ybWF0aW9uIG1h
eSBiZSBwcmVzZW50IGluIGEgc2luZ2xlIExPIChzZWUgdGhlPGJyPg0KJmd0OyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25zaWRlcmF0aW9ucyBpbiBbNV0gZm9yIExPcyBj
b250YWluaW5nIG11bHRpcGxlIGxvY2F0aW9ucykuPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBMb2NhdGlvbiBPYmplY3RzIHR5cGljYWxseSBpbmNsdWRlIHNv
bWUgc29ydCBvZiBpZGVudGlmaWVyIG9mIHRoZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgVGFyZ2V0Ljxicj4NCiZndDsgJnF1b3Q7PGJyPg0KJmd0OyA8YnI+
DQomZ3Q7IC1RaW48YnI+DQomZ3Q7IC0tLS0tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5Ok1pbmdMaVUiPumCrjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuS7tuWOn+S7tjwv
c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+LS0tLS08YnI+DQomZ3Q7IDwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNaW5nTGlVIj7lj5E8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMg
R290aGljJnF1b3Q7Ij7ku7bkuro8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi
PjogSnVlcmdlbiBTY2hvZW53YWVsZGVyIFs8YSBocmVmPSJtYWlsdG86ai5zY2hvZW53YWVsZGVy
QGphY29icy11bml2ZXJzaXR5LmRlIj5tYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2
ZXJzaXR5LmRlPC9hPl0NCjxicj4NCiZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5Ok1pbmdMaVUiPuWPkTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPumAgTwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNaW5nTGlVIj7ml7bpl7Q8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjogMjAxODwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsi
PuW5tDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+MTE8L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7
Ij7mnIg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjI8L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7
Ij7ml6U8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPg0KIDE1OjA3PGJyPg0K
Jmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7TVMgR290aGljJnF1b3Q7Ij7mlLbku7bkuro8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQiPjogUWluIFd1ICZsdDtiaWxsLnd1QGh1YXdlaS5jb20mZ3Q7PGJyPg0KJmd0OyA8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMg
R290aGljJnF1b3Q7Ij7mioTpgIE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi
PjogbmV0bW9kICZsdDtuZXRtb2RAaWV0Zi5vcmcmZ3Q7PGJyPg0KJmd0OyA8L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7
Ij7kuLs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6TWlu
Z0xpVSI+6aKYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij46IFJlOiBbbmV0
bW9kXSBmb3IgYSBmdXR1cmUgcmZjNjk5MWJpczxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHNlYXJj
aGVkIGZvciBsb25naXR1dGUgb3IgZ2VvIGluIFJGQyA4Mjk5IGFuZCB0aGlzIHdhcyBub3QgYSBi
aWcgaGl0Li4gQ29uY3JldGUgZGVmaW5pdGlvbnMgd2lsbCBoZWxwLiBJIGRvIGtub3cgYWJvdXQ8
YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pcnRm
LW5tcmctbG9jYXRpb24taXBmaXgtMDciPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm
dC1pcnRmLW5tcmctbG9jYXRpb24taXBmaXgtMDc8L2E+IGFuZCB0aGF0IGhhcyBiZWVuIGRyYWdn
aW5nIG9uIGZyb20gMjAxMiB0byAyMDE2IHdpdGhpbiB0aGUgTk1SRyBhbmQgSSB0aGluayB0aGlz
IGV2ZW4gaGFkIGEgbGlmZSBvdXRzaWRlIHRoZSBOTVJHIGJlZm9yZS4NCiBXaGF0IEkgYW0gbG9v
a2luZyBmb3IgaXMgY29uY3JldGUgKGlkZWFsbHkgWUFORykgZGVmaW5pdGlvbnMgdGhhdCBwZW9w
bGUgaGF2ZSBhbHJlYWR5IGNyZWF0ZWQgYW5kIHRoYXQgY2FuIGJlIHRoZSBiYXNpcyBvZiBhIGNv
bW1vbiBzdGFuZGFyZC4gQW5kIG9mIGNvdXJzZSBhbiBhcmd1bWVudCB3aHkgbG9jYXRpb24gZGF0
YSBpcyBzbyBlc3NlbnRpYWwgdGhhdCBpdCBoYXMgdG8gYmUgaW4gaWV0Zi15YW5nLXR5cGVzIGFu
ZCBjYW4ndCBiZSBpbiBzYXkNCiBhIG1vZHVsZSBpZXRmLWdlby10eXBlcy48YnI+DQomZ3Q7IDxi
cj4NCiZndDsgL2pzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIEZyaSwgTm92IDAyLCAyMDE4IGF0
IDAzOjE3OjIxQU0gJiM0MzswMDAwLCBRaW4gV3Ugd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IEFncmVl
IHdpdGggdGhpcyBjcml0ZXJpYSwgcmVtZW1iZXIgZ2VvIGxvY2F0aW9uIHByb3Bvc2FsIHdhcyBk
aXNjdXNzZWQgYmVmb3JlIGJ5IEFMVE8gcHJvcG9uZW50cyBpbiBMTUFQLCBpbiBhZGRpdGlvbiwg
bG9jYXRpb24gc2VydmljZSBpcyB1c2VmdWwgZm9yIEwzVlBOIHNldmljZSBwbGFjZW1lbnQsIHNl
ZSBleGFtcGxlIGNhc2UgaW4gUkZDODI5OSB3aGljaCBjYW4gc2VsZWN0IGFwcHJvcHJpYXRlIFBF
IGJhc2VkIG9uIGxvY2F0aW9uIGluZm8uDQogQWNlZSBhbHNvIHByb3ZpZGVkIGEgdmFsaWQgdXNl
IGNhc2UgaW4gdGhpcyBlLW1haWwgdGhyZWFkLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Ok1pbmdM
aVUiPuWPkTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtNUyBHb3RoaWMmcXVvdDsiPuS7tuS6uu+8mjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdCI+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjxicj4NCiZndDsgJmd0OyA8L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGlj
JnF1b3Q7Ij7mlLbku7bkurrvvJo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi
PiBRaW4gV3UmbHQ7YmlsbC53dUBodWF3ZWkuY29tJmx0O21haWx0bzpiaWxsLnd1QGh1YXdlaS5j
b20mZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7mioTpgIHvvJo8L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiBuZXRtb2QmbHQ7bmV0bW9kQGlldGYub3Jn
Jmx0O21haWx0bzpuZXRtb2RAaWV0Zi5vcmcmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyA8L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGlj
JnF1b3Q7Ij7kuLs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6TWluZ0xpVSI+6aKYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+77yaPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0Ij4gUmU6IFtuZXRtb2RdIGZvciBhIGZ1dHVyZSByZmM2OTkxYmlzPGJyPg0K
Jmd0OyAmZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpNaW5nTGlVIj7ml7bpl7Q8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7vvJo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQiPiAyMDE4LTExLTAxIDIwOjA0OjE1PGJyPg0KJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyBJIHRoaW5rIHdlIG5lZWQgdG8gZmluZCBhIHdheSB0byBsaW1pdCB0aGUgdXBk
YXRlIHRvIHR5cGVzIHRoYXQgYXJlIDxicj4NCiZndDsgJmd0OyBrbm93biAob3IgZXhwZWN0ZWQp
IHRvIGJlICd3aWRlbHknIG5lZWRlZC4gSW4gb3RoZXIgd29yZHMsIGZvciBldmVyeSA8YnI+DQom
Z3Q7ICZndDsgcHJvcG9zZWQgdHlwZSwgYW4gYXJndW1lbnQgc2hvdWxkIGJlIG1hZGUgd2h5IHRo
aXMgc2hvdWxkIGJlIGluY2x1ZGVkIDxicj4NCiZndDsgJmd0OyBpbiBSRkMgNjk5MWJpcy48YnI+
DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IC9qczxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7
ICZndDsgT24gVGh1LCBOb3YgMDEsIDIwMTggYXQgMTE6NTU6MjVBTSAmIzQzOzAwMDAsIFFpbiBX
dSB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyBJIGFtIHdvbmRlcmluZyBpZiB3ZSBjYW4gYWRk
IGxvbmdpdHVkZSwgbGF0aXR1ZGUgaW4gRE1TIG9yIGRlY2ltYWwgPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgZGVncmVlLCBGdXJ0aGVyIHdlIGNhbiBjb25zaWRlciB0byBhZGQgUG9zdGFsLWNvZGUsIENv
dW50cnktY29kZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBsaWtlIExvY2F0aW9uIHR5cGUuPGJyPg0K
Jmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAtUWluPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgLS0tLS08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
TWluZ0xpVSI+6YKuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O01TIEdvdGhpYyZxdW90OyI+5Lu25Y6f5Lu2PC9zcGFuPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0Ij4tLS0tLTxicj4NCiZndDsgJmd0OyAmZ3Q7IDwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNaW5nTGlVIj7lj5E8L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1
b3Q7Ij7ku7bkuro8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjogbmV0bW9k
IFs8YSBocmVmPSJtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpuZXRtb2Qt
Ym91bmNlc0BpZXRmLm9yZzwvYT5dDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7ku6Pooag8L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiBKdWVyZ2VuDQo8YnI+DQomZ3Q7ICZndDsgJmd0OyBT
Y2hvZW53YWVsZGVyPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Ok1pbmdMaVUiPuWPkTwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPumAgTwv
c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNaW5nTGlVIj7m
l7bpl7Q8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjogMjAxODwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMm
cXVvdDsiPuW5tDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+MTA8L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGlj
JnF1b3Q7Ij7mnIg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjMxPC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhp
YyZxdW90OyI+5pelPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4NCiAyMDo0
Nzxicj4NCiZndDsgJmd0OyAmZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuaUtuS7tuS6ujwvc3Bhbj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+OiBuZXRtb2RAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZn
dDsgJmd0OyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7kuLs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6TWluZ0xpVSI+6aKYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0Ij46IFJlOiBbbmV0bW9kXSBmb3IgYSBmdXR1cmUgcmZjNjk5MWJpczxicj4NCiZn
dDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSGVyZSBpcyBteSBsaXN0IG9mIHBvc3Np
YmxlIGFkZGl0aW9ucy4gSSBtaWdodCBoYXZlIGxvc3Qgc29tZSBpdGVtcyBvbiBhIGNvbXB1dGVy
IHRoYXQgbWVhbndoaWxlIGlzIG5vdCB1c2VkIGFueW1vcmUsIEkgd2lsbCBoYXZlIHRvIGRpZyBh
IGJpdCB0byBzZWUgd2hhdCBJIGNhbiByZWNvdmVyLjxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgL2pzPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0
OyBPbiBXZWQsIE9jdCAzMSwgMjAxOCBhdCAwMToyNjowMVBNICYjNDM7MDEwMCwgTGFkaXNsYXYg
TGhvdGthIHdyb3RlOjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSGksPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYW5vdGhlciB1cGRhdGUgdGhhdCB3
YXMgZGlzY3Vzc2VkIHJlY2VudGx5IGlzIGEgY2xhcmlmaWNhdGlvbiBvZiA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IHRoZSBYUGF0aCBjb250ZXh0IGZvciB0aGUgeHBhdGgxLjAgdHlwZS48YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBMYWRhPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgS2VudCBXYXRzZW4g
Jmx0O2t3YXRzZW5AanVuaXBlci5uZXQmZ3Q7IHdyaXRlczo8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IE5FVE1PRCBXRyw8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgQSBjb252ZXJz
YXRpb24gaW4gTkVUQ09ORiBXRyByZWdhcmRpbmcgdGhlIHlhbmctcHVzaCBub3RlZCB0aGF0IDxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBpdCBtaWdodCBiZSB0aW1lIHRvIHVwZGF0ZSBS
RkMgNjk5MSwgaW4gcGFydGljdWxhciB0byBpbnRyb2R1Y2UgYSB0eXBlIGZvciB0aW1lLWR1cmF0
aW9uLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL21h
aWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL25ldGNvbmYvS2FVSmxvSVNoa0xOSVhUdUhaIj4N
Cmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvbmV0Y29uZi9LYVVKbG9JU2hr
TE5JWFR1SFo8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IE53Qi08YnI+DQomZ3Q7
ICZndDsgJmd0OyAmZ3Q7ICZndDsgU1lCblE8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSW4gYWRkaXRpb24sIGl0IG1pZ2h0IGJlIGdv
b2QgdG8gaW50cm9kdWNlIFtpbmV0P10gdHlwZXMgZm9yIFJGQzxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgJmd0OyA1MzIyIChJbnRlcm5ldCBNZXNzYWdlIEZvcm1hdCkgaW5jbHVkaW5nIHBlcmhh
cHM6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0
OyAmZ3Q7Jm5ic3A7Jm5ic3A7IC0gZW1haWwtYWRkcmVzcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAoYWRkci1zcGVjLCBwZXIgU2VjdGlvbiAzLjQuMSk8YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsgLSBuYW1lZC1lbWFpbC1hZGRyZXNz
Jm5ic3A7IChuYW1lLWFkZHIsIHBlciBTZWN0aW9uIDMuNCk8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7ICZndDsgS2VudCAvLyBjb250cmlidXRvcjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyBuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IG5ldG1v
ZEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgLS08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IExhZGlz
bGF2IExob3RrYTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSGVhZCwgQ1ouTklDIExhYnM8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhBOUY3NkM2Nzxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBuZXRtb2RA
aWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL25ldG1vZDwvYT48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0
OyAmZ3Q7IC0tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSnVlcmdlbiBTY2hvZW53YWVsZGVyJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEph
Y29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSDxicj4NCiZndDsgJmd0OyAmZ3Q7IFBob25lOiAm
IzQzOzQ5IDQyMSAyMDAgMzU4NyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueTxicj4NCiZn
dDsgJmd0OyAmZ3Q7IEZheDombmJzcDsmbmJzcDsgJiM0Mzs0OSA0MjEgMjAwIDMxMDMmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0
dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLyI+aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZl
cnNpdHkuZGUvPC9hPiZndDs8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0tPGJyPg0K
Jmd0OyAmZ3Q7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKYWNvYnMgVW5pdmVyc2l0eSBCcmVt
ZW4gZ0dtYkg8YnI+DQomZ3Q7ICZndDsgUGhvbmU6ICYjNDM7NDkgNDIxIDIwMCAzNTg3Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENhbXB1cyBSaW5nIDEg
fCAyODc1OSBCcmVtZW4gfCBHZXJtYW55PGJyPg0KJmd0OyAmZ3Q7IEZheDombmJzcDsmbmJzcDsg
JiM0Mzs0OSA0MjEgMjAwIDMxMDMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRl
LyI+aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9hPiZndDs8YnI+DQomZ3Q7IDxi
cj4NCiZndDsgLS0gPGJyPg0KJmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXImbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSmFjb2JzIFVu
aXZlcnNpdHkgQnJlbWVuIGdHbWJIPGJyPg0KJmd0OyBQaG9uZTogJiM0Mzs0OSA0MjEgMjAwIDM1
ODcmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2FtcHVz
IFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnk8YnI+DQomZ3Q7IEZheDombmJzcDsmbmJz
cDsgJiM0Mzs0OSA0MjEgMjAwIDMxMDMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5
LmRlLyI+aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9hPiZndDs8YnI+DQo8YnI+
DQotLSA8YnI+DQpKdWVyZ2VuIFNjaG9lbndhZWxkZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSmFjb2JzIFVuaXZlcnNpdHkgQnJl
bWVuIGdHbWJIPGJyPg0KUGhvbmU6ICYjNDM7NDkgNDIxIDIwMCAzNTg3Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENhbXB1cyBSaW5nIDEgfCAyODc1OSBC
cmVtZW4gfCBHZXJtYW55PGJyPg0KRmF4OiZuYnNwOyZuYnNwOyAmIzQzOzQ5IDQyMSAyMDAgMzEw
MyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEg
aHJlZj0iaHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIj5odHRwczovL3d3dy5qYWNv
YnMtdW5pdmVyc2l0eS5kZS88L2E+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_DB8040C65AB74F3198F9477B9694AA6Dciscocom_--


From nobody Fri Nov  2 08:39: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 460FA126BED for ; Fri,  2 Nov 2018 08:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.197
X-Spam-Level: ***
X-Spam-Status: No, score=3.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RATWARE_OUTLOOK_NONAME=2.95, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sqHNahRdjs8 for ; Fri,  2 Nov 2018 08:38:56 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::708]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48CC01294D7 for ; Fri,  2 Nov 2018 08:38:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mNmlE9xSvIGRTsN+v65sT0Om5Kb9JdAW9EyIGVuwhO8=; b=XdR1foAau0kHHn/mVRBgvW2nwGxSbZy++SfYRnWbYjM9dMPjD/Mtuj7pyFfhnlqWzYqxeYfdiMznhyZLca33DxzOwjw+DhoVvYFzEPBjuS9Z6Lb8qzfHKDNIiQ3yhRpdIz7s3Ftkgk2/enrwF+gXDFyxPWSLjFzCMjlPVIEm+Gs=
Received: from VI1PR07MB5022.eurprd07.prod.outlook.com (20.177.202.206) by VI1PR07MB4512.eurprd07.prod.outlook.com (20.177.56.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.7; Fri, 2 Nov 2018 15:38:53 +0000
Received: from VI1PR07MB5022.eurprd07.prod.outlook.com ([fe80::d929:3695:4655:d265]) by VI1PR07MB5022.eurprd07.prod.outlook.com ([fe80::d929:3695:4655:d265%4]) with mapi id 15.20.1294.024; Fri, 2 Nov 2018 15:38:53 +0000
From: tom petch 
To: Juergen Schoenwaelder , Kent Watsen 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AQHUcsIocc+7Xvl5ikGH9E0soagZkg==
Date: Fri, 2 Nov 2018 15:38:53 +0000
Message-ID: <00fc01d472c1$f526c3c0$4001a8c0@gateway.2wire.net>
References:  <20181029230138.44pmjmza5mg2cb4a@anna.jacobs.jacobs-university.de> <92E98222-E53B-49EE-8BC9-0FC0A406460E@juniper.net> <20181030101448.pwzdyupseabnzpil@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: LO2P265CA0111.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::27) To VI1PR07MB5022.eurprd07.prod.outlook.com (2603:10a6:803:9b::14)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [86.128.101.213]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB4512; 6:hG2vT6ZZ1vfXJ1Qjth0e2WmF6U2MT7KEPjPbCrY0eZMjhaHe/TIUbLGoAC7JeBpbv/WkXixh9pNYKPLUlIMxhHG1itLXEpZ7zNRoB/q3lSCi7m7y+YSmg6a0CYcKeE7UB7y/DgCUNf/PDZT3obAt/DUgDc95xFZnUkpxlMZG/I4ZfGZKCvNZc+uYkgzAETXP+WtLrXSYLDbXuqLtiZYmQW6fOnXzpui9g29cNyRJjbavzihuF1qeHRVxP2raAdIT37sMXnMI6D8//m4jeZv/lXeG7Wz1GvNJJkzyffbLwlp5YfNM2zmwvJyxkpjVuISf8BdKAN/H7tZGH7zZAKZFpZlL0+K3fQa/8q9vSP7nQomLemrgEa42CKauC4YsmkkZ9TAw8l2Esl5vXNffR/dmGZ6DPmEvffOjxUIizpuGfHBcalwEvzUQpiMPZiVIV05cgjdwgsypqy7/ixKdq7pqXg==; 5:N4N5MKYnTFTC3/Us3ROKWZV9d27+bXuz5hfnO+yCpkPWafKQEqyAyhJSzsxuOMARmsYAmdrw+1TrskTCIEm0lmMX5s0D6UMI9vEra1Bhrq6Z2cZChNNvDyFwZaz0s7++BoH9M7pAS8zl355UhfSy3V4XLhR6TfuSStHIA9e47U4=; 7:0SxVeJPvFKvTjVBnWPLB5FQ57sVtZCVOGnJYoCh/uDTxZSy7fjMmGvpogizeZvkGYaS7JeReO0bkICITd5Tq3Rztn2zFtn9Gm1wY58Ivr0F0lqshCqFSycZ+S64/DsUtK8le/i9jQJ9ocDCwiMYmrg==
x-ms-office365-filtering-correlation-id: c0b3025e-c615-48d3-64b7-08d640d94b5c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7193020); SRVR:VI1PR07MB4512; 
x-ms-traffictypediagnostic: VI1PR07MB4512:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231382)(944501410)(52105095)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB4512; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4512; 
x-forefront-prvs: 08444C7C87
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(396003)(39860400002)(136003)(189003)(199004)(13464003)(316002)(97736004)(478600001)(106356001)(105586002)(305945005)(71200400001)(71190400001)(7736002)(14454004)(84392002)(966005)(2906002)(8936002)(81156014)(8676002)(81166006)(5660300001)(68736007)(2900100001)(9686003)(44736005)(6486002)(86152003)(6306002)(6436002)(229853002)(6512007)(66066001)(26005)(4326008)(25786009)(53936002)(6246003)(3846002)(6116002)(1941001)(102836004)(86362001)(14496001)(99286004)(1556002)(476003)(486006)(93886005)(186003)(446003)(6346003)(386003)(6506007)(76176011)(52116002)(33896004)(256004)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4512; H:VI1PR07MB5022.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-microsoft-antispam-message-info: /ZrsNFnfKOIo/a4mXTSN+e65D6Foy2pP+fEh24Q2+a5k9LCbI34uqWwe0dw+KoYKKjB6tRHRy0j55eZwra/051TDmN2ngcmum1Ztp1k6L4J6ecFq4ffvTbGLpXfq4MEzZFgDcxeku0Ix74KM932YbzfUonnm4qnDu2Pg3CVcrtKwQZSJmn5UKBmm9T/yJ5lvvb38iGmppMy9MN4hwQs2J/BFdRTLy2HAKyrcsqeBSfaLX5aL+3pHHUDZONFamL3hn4YgIM+GvWoaYLecOyfsCbkBeDt6qi7WTL7cswsVFY61/mplNBEU21/lIZhC551bNRA+bcmQFzUl0YKKyPp3NLK9bwsKXJ3iqmQ0ossT9ho=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <11E2017A31EE484084BF1FD8F672AD6C@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c0b3025e-c615-48d3-64b7-08d640d94b5c
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2018 15:38:53.7882 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4512
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: Fri, 02 Nov 2018 15:38:59 -0000

---- Original Message -----
From: "Juergen Schoenwaelder" 
To: "Kent Watsen" 
Cc: 
Sent: Tuesday, October 30, 2018 10:14 AM

> On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen wrote:
> >
> > >> In addition, it might be good to introduce [inet?] types for RFC
5322
> > >> (Internet Message Format) including perhaps:
> > >>
> > >>   - email-address        (addr-spec, per Section 3.4.1)
> > >>   - named-email-address  (name-addr, per Section 3.4)
> > >>
> > >
> > > Where are these used? Or have these already been used somewhere?
> >
> > I'm unaware of these ever having been used before.  I am working on
a private module for which I want to configure an email address.  After
some searching, I concluded that no such types have been defined, and
thus thought that they might be good candidates for addition.


We could defined a user-name, of the form localpart@domainpart as is
widely used to identify a user in operations but which does not, in my
experience, owe anything to i18n, just a straightforward character set;
yes it would not boil the ocean, but could be useful.  I am surprised
not to find such a definition somewhere in our 40 or so NETCONF I-Ds.

Tom Petch







> >
>
> It would be good to have strong use cases. I fear that defining this
> type won't be easy given that we also have internationalized email
> addresses (RFC 6530 provides an overview) and we might have to create
> a union of RFC 5322 addresses and "SMTPUTF8 (compliant) addresses".
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Nov  2 13:44: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 9A29112EB11 for ; Fri,  2 Nov 2018 13:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayiUI1oXgLyE for ; Fri,  2 Nov 2018 13:44:37 -0700 (PDT)
Received: from mail-it1-x12f.google.com (mail-it1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22777126BED for ; Fri,  2 Nov 2018 13:44:37 -0700 (PDT)
Received: by mail-it1-x12f.google.com with SMTP id p64-v6so4949394itp.0 for ; Fri, 02 Nov 2018 13:44:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aRpQyE8mzk0FTPwi1yZ3uT7lnfUgGHrwRaPmXO39ufI=; b=tMcUl/8yhQ2vnsfL9a/85/WyDpfd+c39pl4JQ7gGMDTwJogdeUkzkT9+IZ+KUTSOAz SFHu6V3ViPfVsxgMZs3ezGIqjWUgNLtnDhPQdKHqg4TU7ETR794laPp8gSQ+3jXKs80R p/tzIpSAuicX4xlHVvXc9TF+eH0h7wlDUe6wPBQMQ4JRV2tJxwmC19vT2sS6vuea+/fQ cOTyzIWa3l/nbCAUqqdG0r6P/Ei0oy3vkLHVvNiAh0NP+8a4ukyyphBhonCG4C+xIUnW YELesbZ2P+0KkbntL9OPJJjqKJjsfdOOofxk7VnYn85j7dbfO8uIX4HkXp7k5um6jrRl 8yxg==
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=aRpQyE8mzk0FTPwi1yZ3uT7lnfUgGHrwRaPmXO39ufI=; b=OaAKXTt1K2Nk6y+UVae2bxh1J2oKAmB4dh2EhYZWtPx4C5KIW2rP6LS3uH8CJ/xYqj /oBOAG2T/ninNBWTxd5yzt2V776Nt7uVSzQD/rvM+ZwCo3uyF6gATIi6bqAEML8uVG0z RARpzbaBbiQV/cyJGrmDIxqWxUX9SUQrXHGJcfoCYwsSW9GOq5yreTYFbzCECxS3oS4C s+bQlGFl/69aEBc7soMGPeCewrW51xsVWypQZa2X/tn2vgrdPGjdAeWCYURwxRSq6qDg kd6s8UR440R+THzekbba7jSL1niEjJoAwRnKGDiFVkduPLit9lYBeTRtqDRcepUgXeeF zJfA==
X-Gm-Message-State: AGRZ1gL9Y8iwTD7EIuXPR4b2P5gDtiAFr6AgORtK2h7qOGzt/a3U8FRs Nd6zFR3NCE3rNhEnkRR3oYVSqg3VpWjPHIn5L9g=
X-Google-Smtp-Source: AJdET5csT4x4PSKcaoPHp0IgMDbOxlAUTJwlSsTveg0PuyzR3IV+ffUhwExIR1WwnCT5ycqLNuNnXrzxfvn/EkkTIK0=
X-Received: by 2002:a02:b45a:: with SMTP id w26-v6mr11655448jaj.45.1541191476335;  Fri, 02 Nov 2018 13:44:36 -0700 (PDT)
MIME-Version: 1.0
References:  <20181029230138.44pmjmza5mg2cb4a@anna.jacobs.jacobs-university.de> <92E98222-E53B-49EE-8BC9-0FC0A406460E@juniper.net> <20181030101448.pwzdyupseabnzpil@anna.jacobs.jacobs-university.de> <00fc01d472c1$f526c3c0$4001a8c0@gateway.2wire.net>
In-Reply-To: <00fc01d472c1$f526c3c0$4001a8c0@gateway.2wire.net>
From: Xufeng Liu 
Date: Fri, 2 Nov 2018 16:44:24 -0400
Message-ID: 
To: "t.petch" 
Cc: Juergen Schoenwaelder , Kent Watsen , NETMOD WG 
Content-Type: multipart/alternative; boundary="0000000000007a649f0579b49a40"
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: Fri, 02 Nov 2018 20:44:40 -0000

--0000000000007a649f0579b49a40
Content-Type: text/plain; charset="UTF-8"

Remember that some draft asked for a type of percentage value to the
nearest hundredth. Wondering if it can be put in.

Thanks,
- Xufeng

On Fri, Nov 2, 2018 at 11:39 AM tom petch  wrote:

> ---- Original Message -----
> From: "Juergen Schoenwaelder" 
> To: "Kent Watsen" 
> Cc: 
> Sent: Tuesday, October 30, 2018 10:14 AM
>
> > On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen wrote:
> > >
> > > >> In addition, it might be good to introduce [inet?] types for RFC
> 5322
> > > >> (Internet Message Format) including perhaps:
> > > >>
> > > >>   - email-address        (addr-spec, per Section 3.4.1)
> > > >>   - named-email-address  (name-addr, per Section 3.4)
> > > >>
> > > >
> > > > Where are these used? Or have these already been used somewhere?
> > >
> > > I'm unaware of these ever having been used before.  I am working on
> a private module for which I want to configure an email address.  After
> some searching, I concluded that no such types have been defined, and
> thus thought that they might be good candidates for addition.
>
>
> We could defined a user-name, of the form localpart@domainpart as is
> widely used to identify a user in operations but which does not, in my
> experience, owe anything to i18n, just a straightforward character set;
> yes it would not boil the ocean, but could be useful.  I am surprised
> not to find such a definition somewhere in our 40 or so NETCONF I-Ds.
>
> Tom Petch
>
>
>
>
>
>
>
> > >
> >
> > It would be good to have strong use cases. I fear that defining this
> > type won't be easy given that we also have internationalized email
> > addresses (RFC 6530 provides an overview) and we might have to create
> > a union of RFC 5322 addresses and "SMTPUTF8 (compliant) addresses".
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         
> >
> > _______________________________________________
> > 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
>

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


Remember that some draft asked for a type=
 of percentage value to the nearest hundredth. Wondering if it can be put i=
n.

Thanks,
- Xufeng

On Fri, Nov 2, 2018 =
at 11:39 AM tom petch <ietfc@btco=
nnect.com> wrote:
---- Ori=
ginal Message -----

From: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-universit=
y.de>

To: "Kent Watsen" <kwatsen@juniper.net>

Cc: <netmod@ietf.or=
g>

Sent: Tuesday, October 30, 2018 10:14 AM



> On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen wrote:

> >

> > >> In addition, it might be good to introduce [inet?] types=
 for RFC

5322

> > >> (Internet Message Format) including perhaps:

> > >>

> > >>=C2=A0 =C2=A0- email-address=C2=A0 =C2=A0 =C2=A0 =C2=A0 (=
addr-spec, per Section 3.4.1)

> > >>=C2=A0 =C2=A0- named-email-address=C2=A0 (name-addr, per =
Section 3.4)

> > >>

> > >

> > > Where are these used? Or have these already been used somewh=
ere?

> >

> > I'm unaware of these ever having been used before.=C2=A0 I am=
 working on

a private module for which I want to configure an email address.=C2=A0 Afte=
r

some searching, I concluded that no such types have been defined, and

thus thought that they might be good candidates for addition.





We could defined a user-name, of the form localpart@domainpart as is

widely used to identify a user in operations but which does not, in my

experience, owe anything to i18n, just a straightforward character set;

yes it would not boil the ocean, but could be useful.=C2=A0 I am surprised<=
br>
not to find such a definition somewhere in our 40 or so NETCONF I-Ds.



Tom Petch















> >

>

> It would be good to have strong use cases. I fear that defining this
> type won't be easy given that we also have internationalized email=


> addresses (RFC 6530 provides an overview) and we might have to create<=
br>
> a union of RFC 5322 addresses and "SMTPUTF8 (compliant) addresses=
".

>

> /js

>

> --

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

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

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

>

> _______________________________________________

> 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




--0000000000007a649f0579b49a40--


From nobody Fri Nov  2 14:33: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 96321130DC5 for ; Fri,  2 Nov 2018 14:33:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7gKuUHlfCnl for ; Fri,  2 Nov 2018 14:33:14 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D73E12EB11 for ; Fri,  2 Nov 2018 14:33:14 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A4946E1A; Fri,  2 Nov 2018 22:33:12 +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 Ymqo6XQYzX7Q; Fri,  2 Nov 2018 22:33:10 +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,  2 Nov 2018 22:33:12 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 636F42003D; Fri,  2 Nov 2018 22:33:12 +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 L_undewP8szt; Fri,  2 Nov 2018 22:33:11 +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 D21C32003C; Fri,  2 Nov 2018 22:33:11 +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, 2 Nov 2018 22:33:11 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 3905B3003A5525; Fri,  2 Nov 2018 22:33:10 +0100 (CET)
Date: Fri, 2 Nov 2018 22:33:10 +0100
From: Juergen Schoenwaelder 
To: Xufeng Liu 
CC: t.petch , Kent Watsen , NETMOD WG 
Message-ID: <20181102213310.wen75n5nyu5k6uhi@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Xufeng Liu , "t.petch" , Kent Watsen , NETMOD WG 
References:  <20181029230138.44pmjmza5mg2cb4a@anna.jacobs.jacobs-university.de> <92E98222-E53B-49EE-8BC9-0FC0A406460E@juniper.net> <20181030101448.pwzdyupseabnzpil@anna.jacobs.jacobs-university.de> <00fc01d472c1$f526c3c0$4001a8c0@gateway.2wire.net> 
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] 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: Fri, 02 Nov 2018 21:33:18 -0000

What about a concrete pointer or proposal?

/js

On Fri, Nov 02, 2018 at 04:44:24PM -0400, Xufeng Liu wrote:
> Remember that some draft asked for a type of percentage value to the
> nearest hundredth. Wondering if it can be put in.
> 
> Thanks,
> - Xufeng
> 
> On Fri, Nov 2, 2018 at 11:39 AM tom petch  wrote:
> 
> > ---- Original Message -----
> > From: "Juergen Schoenwaelder" 
> > To: "Kent Watsen" 
> > Cc: 
> > Sent: Tuesday, October 30, 2018 10:14 AM
> >
> > > On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen wrote:
> > > >
> > > > >> In addition, it might be good to introduce [inet?] types for RFC
> > 5322
> > > > >> (Internet Message Format) including perhaps:
> > > > >>
> > > > >>   - email-address        (addr-spec, per Section 3.4.1)
> > > > >>   - named-email-address  (name-addr, per Section 3.4)
> > > > >>
> > > > >
> > > > > Where are these used? Or have these already been used somewhere?
> > > >
> > > > I'm unaware of these ever having been used before.  I am working on
> > a private module for which I want to configure an email address.  After
> > some searching, I concluded that no such types have been defined, and
> > thus thought that they might be good candidates for addition.
> >
> >
> > We could defined a user-name, of the form localpart@domainpart as is
> > widely used to identify a user in operations but which does not, in my
> > experience, owe anything to i18n, just a straightforward character set;
> > yes it would not boil the ocean, but could be useful.  I am surprised
> > not to find such a definition somewhere in our 40 or so NETCONF I-Ds.
> >
> > Tom Petch
> >
> >
> >
> >
> >
> >
> >
> > > >
> > >
> > > It would be good to have strong use cases. I fear that defining this
> > > type won't be easy given that we also have internationalized email
> > > addresses (RFC 6530 provides an overview) and we might have to create
> > > a union of RFC 5322 addresses and "SMTPUTF8 (compliant) addresses".
> > >
> > > /js
> > >
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   +49 421 200 3103         
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >

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


From nobody Sun Nov  4 04:07: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 29DFF130E09 for ; Sun,  4 Nov 2018 04:07:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.067
X-Spam-Level: 
X-Spam-Status: No, score=-3.067 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=O7U6MLCl; dkim=pass (1024-bit key) header.d=ericsson.com header.b=YHgWjK4n
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKN42zf3tDDl for ; Sun,  4 Nov 2018 04:07:50 -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 6BFC212426A for ; Sun,  4 Nov 2018 04:07: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=1541333268; x=1543925268; 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=8p9nl4xK4Z5SLKrlfE9cisTnCB4KPlwnV5rOU/9aerM=; b=O7U6MLClyLMUPGHu0gsXzHAfLeoDC4JFSHj3CyrHE0Fbt5Iqc5sdss5Ku1d3AdCm GN9Zd/cqqlskaqPnIYNLQA+B79L63Va8+9sqbJRC1Qi3FFJw00cODxXPR4WTqXMp IrKE6aIUjZY4fCeaKYAG1dZFTs3L993BA3rlXsnv7bg=;
X-AuditID: c1b4fb25-abbff7000000414e-da-5bdee114843f
Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 86.B8.16718.411EEDB5; Sun,  4 Nov 2018 13:07:48 +0100 (CET)
Received: from ESESSMB501.ericsson.se (153.88.183.162) 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; Sun, 4 Nov 2018 13:07:48 +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; Sun, 4 Nov 2018 13:07: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=GB6TptGYWdCMwI38NtdKjyk+t8Xv1LEQBZPyksLLVew=; b=YHgWjK4nz+uLIDtI/1vvygMSHg5mYofhLAD6DdSQlgqo8JgZ7y9e+r36BKmjYkXRRpPZjVbDI/QTw6dyTLpp16jwmKFEyVxNMuTNdfKbB3W9VjJ1opC6Kn/B3uN+PNw1vTzGqt7angslgse9PuD/HugWY7HHre1xZEyMtmTaHBI=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2127.eurprd07.prod.outlook.com (10.169.137.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.8; Sun, 4 Nov 2018 12:07:46 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd%11]) with mapi id 15.20.1294.028; Sun, 4 Nov 2018 12:07:46 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Xufeng Liu , t.petch 
CC: NETMOD WG 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AQHUdDb/JH8IN3JOb0WNQYaCXq3XQw==
Date: Sun, 4 Nov 2018 12:07:46 +0000
Message-ID: <0810ee8c-2c25-c312-9e8f-3ee952048818@ericsson.com>
References:  <20181029230138.44pmjmza5mg2cb4a@anna.jacobs.jacobs-university.de> <92E98222-E53B-49EE-8BC9-0FC0A406460E@juniper.net> <20181030101448.pwzdyupseabnzpil@anna.jacobs.jacobs-university.de> <00fc01d472c1$f526c3c0$4001a8c0@gateway.2wire.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [192.176.1.82]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
x-clientproxiedby: AM5P190CA0008.EURP190.PROD.OUTLOOK.COM (2603:10a6:206:14::21) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2127; 6:odDlWooFQMSNTbin2nc7pkgxj6XGIddz6QSzG2vUP2mQJWNTRFj9KHi8g4KYedM2S01WhhT2bo2ltUB20dPUnL3cgWdZseu+AI0X5Mk8ceLVYpy37joVbJIwiF1XLVSpXuavCNGMPPsciDOmK6Uwbj+qGxA0d6HruOC1VxUpHgq4eUwc17wY5esUelj5z3wKTuC9hxaEk6eTAL4BzYtRfrygSd0hXd5dobZS4+b8PjHLWSVjhQ73WFHiuS957o9HCJwceGUpk3im9PoWQKvHqxtWfOF3huy7/QUmx76OFOuYRX8xK2GBbPnW0NN3ZgmNOPqh7ZxeVLgnlIeZ7xG//8hRsTPlMzchW2zuIVfapiF+mzVyE6ky9PCtkoGMePz8C2/42fsI1ykuyu93z7V9WvqI056LdV7rXrQeQnSboy6YPBjlhOy7SgKRdhjPBQ2T+/9e3x8OJpBaUbj1+rLFmA==; 5:GcPNdI2EZ+/AzVTsngoD89/YxwwINxUWXzmTpNwQDhlLlZF17ajCKAsioo7UT+o34hndJoOhQ6J4sZ8vf1tYVvYzNDb2TeDbC0j2yAn3KqIu+jz2jG57UZZHD0CiXzmnqw7AROA3Xsm5LgqV57dUtPQvfA9JcziLgziwjIv/xlw=; 7:QwpbT7z8MYn7NTqzYk5xROSQZG0k5KXmxALNFqQzf/xrBs3COnKDrXMAWK7/vKdW6yrxleKBN3veWgH+AYFqkLzX0sFIZTrIDC1s/xWE0C1xO9+FN3+GPor9T5Mi5Ibr6hciylJLsLDD7ETVJN5Spg==
x-ms-office365-filtering-correlation-id: ad3fa3a5-4723-45d7-9905-08d6424e2113
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2127; 
x-ms-traffictypediagnostic: VI1PR0701MB2127:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(178726229863574)(219612443155931)(138986009662008)(248295561703944)(37575265505322)(85827821059158);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(4983020)(52105095)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2127; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2127; 
x-forefront-prvs: 084674B2CF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(136003)(39860400002)(396003)(376002)(252514010)(199004)(189003)(13464003)(65806001)(14454004)(8936002)(81166006)(81156014)(8676002)(2900100001)(7736002)(476003)(2616005)(446003)(64126003)(386003)(6506007)(52116002)(99286004)(68736007)(65826007)(102836004)(6486002)(31686004)(486006)(3846002)(6306002)(54896002)(6512007)(256004)(93886005)(478600001)(11346002)(5660300001)(6436002)(6116002)(85182001)(86362001)(25786009)(3260700006)(99936001)(97736004)(105586002)(71190400001)(39060400002)(71200400001)(66066001)(236005)(106356001)(85202003)(316002)(53936002)(2906002)(229853002)(76176011)(6246003)(36756003)(53546011)(65956001)(186003)(966005)(4326008)(31696002)(26005)(110136005)(606006)(58126008); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2127; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 8PV8W0+YnJnYGJ2iGuVV1AHj8RxJ/FrZiAxd9hkPlF1h0oL562SDyYXs++yy9UkrCVwySl1YJGU5VTTDY7iMIKKlkSvh+DLaKniZBRDjt5IzNiSslMYL0q/ChqdXnXa+40fyTfISf2qD64GLXXubCbCydirHVtsZ7tTCHKOnZ73YhOoW6g3ZYngYfNl/a0M/idcNzlMpxEbaJLIeKL4qrxyew08oG6wpORhBP5wLwYcf6p6r4YWZhgwbk37B4iLkDWYOEJa0g2Z9WCZKlDwcgrDSMdhGvJvEouv1VfTp5XZXw0dZ4HfXCyyYbV2a1oLnrUeeo4ctpfP/gkAQd7h2VHurILP9L5f9ypdwC6d8nhA=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020608070806080607050305"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ad3fa3a5-4723-45d7-9905-08d6424e2113
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2018 12:07:46.4000 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2127
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSWUwTURSGc2emw9DY5FpbPYEYtSIxIrUUjcQVEhd8IGD6oIJbxQmiWKAD RnyqKS60bjE10qogsQIiAYNEgagsSrTUtaCiFkixCSpWxcQFXDtcSPTtu+f/zzn/SS5Hy32S MC7TkMcbDfosFStl7Ouv50crfL1pmoGrM+Oe9fcxcaVP9kviuu7+pOLpxKb27yGJjY6ekESn c5hKoVOlS7bzWZl7eOO8ZVulOyyWEiqnJn1vi/kzbUKFOgsK5QDPh5Z75bQFSTk5voPA3uNl yeMLgt/OUyHkcYGC1kILI7Yw+AQNDwcSiGCj4H3fcyQKctyP4E5HksgsXgGHPjRTIivwGihz VY4203gaWO1vgn6Om4Sjob42hVjUUHnfz4yz7cUQRXZFQPfBSlpkGV4O+9ufjqUbpsBzrnO0 IRSvhWvHz4wywpPhW0c1RXZNgZf+UorcqQDfEzdLWAlvX/+WiBkAT4fb72RiWYk3QaHLIRHn Az6NoNo+7p8LD577EeGp4Cm1ImLqZsFdPcySQUnQ+DWX1DsR1J500qQ+F041JJBsm+FG7+Gx mdnwqMrFnkBaxz9RHcF2GhchOOQ3MY7RoyeCy+4PMhcUIqH8gOp/v8hRUF42SBNeDMUjrSzh GWCz+kIIL4DB9iFEOBbKa36x55G0CikFXti2O0Mbq+aNmemCkG1QG/i8OhT8bK31P2Y1oM73 CW0Ic0g1QeZu6U2TS/R7hILdbSgiOKf/yuXHKIwxZBt4lUIWeTQoy7brC/bxxuwtxvwsXmhD 4RyjmiLzLbyaKscZ+jx+F8/n8MZxleJCw0xo1Tr551cbd77pDXiPlJlHigKmQEW8pt69NDL3 0ff05OrQRc152qVWiNFtiMu3PmhaMHsw6o/X1q/UvciZNTm+75NzdcXQpbr573RmWVrjWc0x g6TLldrwWDli9t696H3mZ9yeglsrPcLNYY0mwh3zsQQCdVO7PaXNxQe1yeFqFSPs0MfMoY2C /i+A9AfgdAMAAA==
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: Sun, 04 Nov 2018 12:07:53 -0000

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


  
    
  
  
    
+1 to percentage.

    
Balazs

    

    
On 2018. 11. 03. 3:44, Xufeng Liu
      wrote:

    

    

      
      

        
Remember that some draft asked for a type of
          percentage value to the nearest hundredth. Wondering if it can
          be put in.

        


        

        
Thanks,

        
- Xufeng

        

      

      

      

        
On Fri, Nov 2, 2018 at 11:39 AM tom petch <=
ietfc@btconnect.com>
          wrote:

        

        
----
          Original Message -----

          From: "Juergen Schoenwaelder" <j.schoenwaelder@ja=
cobs-university.de>

          To: "Kent Watsen" <kwatsen@juniper.ne=
t>

          Cc: <netmod@ietf.org>

          Sent: Tuesday, October 30, 2018 10:14 AM

          

          > On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen
          wrote:

          > >

          > > >> In addition, it might be good to introduce
          [inet?] types for RFC

          5322

          > > >> (Internet Message Format) including
          perhaps:

          > > >>

          > > >>=C2=A0 =C2=A0- email-address=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 (addr-spec, per
          Section 3.4.1)

          > > >>=C2=A0 =C2=A0- named-email-address=C2=A0 (nam=
e-addr, per
          Section 3.4)

          > > >>

          > > >

          > > > Where are these used? Or have these already
          been used somewhere?

          > >

          > > I'm unaware of these ever having been used before.=C2=
=A0
          I am working on

          a private module for which I want to configure an email
          address.=C2=A0 After

          some searching, I concluded that no such types have been
          defined, and

          thus thought that they might be good candidates for addition.
          

          

          We could defined a user-name, of the form localpart@domainpart
          as is

          widely used to identify a user in operations but which does
          not, in my

          experience, owe anything to i18n, just a straightforward
          character set;

          yes it would not boil the ocean, but could be useful.=C2=A0 I a=
m
          surprised

          not to find such a definition somewhere in our 40 or so
          NETCONF I-Ds.

          

          Tom Petch

          

          

          

          

          

          

          

          > >

          >

          > It would be good to have strong use cases. I fear that
          defining this

          > type won't be easy given that we also have
          internationalized email

          > addresses (RFC 6530 provides an overview) and we might
          have to create

          > a union of RFC 5322 addresses and "SMTPUTF8 (compliant)
          addresses".

          >

          > /js

          >

          > --

          > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Jacobs University Bremen
          gGmbH

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

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

          >

          > _______________________________________________

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


  



--------------ms020608070806080607050305
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTEwNDEyMDczNFow
LwYJKoZIhvcNAQkEMSIEIJdFnkS/nC194j2NXQm284RZImAEit+xGfwmNxxnfw2VMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBANBwjU0zIenedrlcqhK1ASm+c28JOFTN0IMX4EEbr80E1sVX
gJxggWIxI6TAe1AQr/QvEsEj4E/xfAX93+36fOCAiu180SMZ+vH56I0olEMomAeu1dzgxhG/
81o4TACK+GA0H0TWHjNdpPQ+2tS5CBrVFyaxYvNkDLsadsqFcUzFvL5NOuq743x4Yx6U2GH3
deRFYeyTeKrvwWz/DhJGfpNtlhBYlGOGQwi80vksD0uUK5vaEGPm7/33BTpclUdQQPwUv5aF
2IBUYBqnYEqurf/W4TfLYqtijNd1EYZW+UlLmUjJD7DAXrXP0fiNUALBAbekR+imWYtRdgV4
D+ossocAAAAAAAA=

--------------ms020608070806080607050305--


From nobody Sun Nov  4 04:26: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 6FDE112426A for ; Sun,  4 Nov 2018 04:26:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.791
X-Spam-Level: 
X-Spam-Status: No, score=-3.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=gkfBF6js; dkim=pass (1024-bit key) header.d=ericsson.com header.b=BmOpVEQM
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tD2z4mrRnVDX for ; Sun,  4 Nov 2018 04:26:40 -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 D7D3E1200D7 for ; Sun,  4 Nov 2018 04:26:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1541334397; x=1543926397; 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=NcLfPrQOd5LsAHLSbLAvTfIq+S2dTCkVETPCCUrHwUw=; b=gkfBF6js7B5Kom9DsYLMvke4RVEpeRL2lOlUo4wht0qqWN75GKMroZiWDQ4g9VrL bSGPsxJgK1bmlvYrF0ZQwXG8C0iZbQivtztLN/7JT5lii6eaSqjhKhkk8K1R/MC7 k33mkH1iPZjw6x+AxqqBxGzSBD12zdi5N/RV9fmKlck=;
X-AuditID: c1b4fb2d-887c49e00000434d-14-5bdee57d7132
Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 48.6F.17229.D75EEDB5; Sun,  4 Nov 2018 13:26:37 +0100 (CET)
Received: from ESESSMR505.ericsson.se (153.88.183.127) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sun, 4 Nov 2018 13:26:29 +0100
Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESSMR505.ericsson.se (153.88.183.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sun, 4 Nov 2018 13:26:29 +0100
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sun, 4 Nov 2018 13:26:28 +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=G13D5V2qeIIucfrKaW70BKzecpdEmPz1H0+nsP/OYEg=; b=BmOpVEQMJPL/3hXO4vgbAGQ+b9jxPH42V5Ci+vkGdU56fmDCy2d6qMIWdzUnDivgV3Ruf59yLaIcSTSWeNTmdgB55N6bW8aRlp3atdVbl1ttfqhfXuwr9mdy9Q2W0D33oAKXr7vcZYaaaBVSUYN2OdhKefQbnrR+sVDneCyuV6Y=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2718.eurprd07.prod.outlook.com (10.173.80.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.15; Sun, 4 Nov 2018 12:26:27 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd%11]) with mapi id 15.20.1294.028; Sun, 4 Nov 2018 12:26:27 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
Thread-Index: AQHUdDmbOhP2A3sul0+FiL1KlR/0Ug==
Date: Sun, 4 Nov 2018 12:26:27 +0000
Message-ID: <5746b441-b681-2222-1d77-f0b80db16341@ericsson.com>
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org>   <01d5056d-7645-cb1d-6e88-fbdbeb8ebca4@cisco.com> <20181026093347.3yomg5bhwilassvf@anna.jacobs.jacobs-university.de>  <20181026230148.xnv7kxgqd43abb7g@anna.jacobs.jacobs-university.de>  <20181027083628.tgymddbje3yp2lhy@anna.jacobs.jacobs-university.de> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [192.176.1.82]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
x-clientproxiedby: AM5PR0201CA0019.eurprd02.prod.outlook.com (2603:10a6:203:3d::29) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2718; 6:XIXB/IQPAchYtus0gGfdl9hGbsyYp0HHHUJ6dUUQ3FMmQKCXZ/pqjrl6TkQqtvdLzY4DPXmr0s5PAyn7e26zrmE+7zrVq1WImVcmDJzVB3i8WVrSbc9t+lybwqWeSLY4zg5PdoA19D8xx3DPdth1S+jcSJ4IUrDFltKe2SBPv/7gcMBOnEVK23fjc0c70+oK7Z8hYoofx3vQNWobjFmgi+W8vnufRSGgo+3RBr29wp6jnG8p1GybR+qLZVXeT5p3WlCoA42d0onR8GwvVL26jq1WhapfEPn8Th8C3V3JqcFs3lMQuh203wffdR5zLoZOGUTlGYMQ2xCbt05pjvbBwJqXDodBl24MG6WsD56qrH1ZdmsjHa4gdCSRHyezlogZeGfRb4H8a+yN4of+0RFStuHDHA++fp0mxla0CH4c6lu22ZBZi0xMiBq55NDem0IFQ1DbcRUNadOYYILoF8hkiw==; 5:hNMLRLegG6ifoPzcVXddshwJC99cflgwrmW2mHY5NfpWmthBayr6LQJXC7Rd6WPwu1Uj1dHMNMHpMTcfwIOvySvAMc8IEl2DbV6XBpZDDl9IR/CvIshkeExCE1L6tF03pG0FeYK+bCFxwkpZQ7JK/H3J9dIGWNMbb7lV4JP4MHw=; 7:WGD3uZga8OLdHOO10EF9ug1MKH76qdOx6GMxIOBeh+NeWPpxZvh5MFjXIXucfAZ5u/ZvObvEee+d1LZpfcZAvbbuU4MJYtuCrH5JKEnOoYAO6OoygaijoyNw7d06G9bLUc6Ys8PW40ROoi+CjrCuqw==
x-ms-office365-filtering-correlation-id: 3be161f3-f140-4164-23d3-08d64250bd22
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2718; 
x-ms-traffictypediagnostic: VI1PR0701MB2718:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(248295561703944)(37575265505322); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(4983020)(52105095)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2718; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2718; 
x-forefront-prvs: 084674B2CF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(396003)(39860400002)(346002)(136003)(252514010)(189003)(199004)(68736007)(3260700006)(186003)(2501003)(36756003)(229853002)(386003)(65806001)(2616005)(26005)(6506007)(476003)(11346002)(14454004)(66066001)(65956001)(2900100001)(31696002)(86362001)(85182001)(76176011)(52116002)(7736002)(305945005)(64126003)(478600001)(99286004)(53936002)(93886005)(2906002)(31686004)(6436002)(8936002)(71200400001)(71190400001)(25786009)(3846002)(256004)(6116002)(110136005)(446003)(81156014)(316002)(6512007)(105586002)(5660300001)(486006)(6246003)(81166006)(6486002)(58126008)(8676002)(99936001)(65826007)(85202003)(106356001)(102836004)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2718; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: bRiKRsEJ1SFE0XP4W+TNT7rCq7Jn95auAlfyXe65tZIDU+clVLb67zc49CqdiclzA1PLMLv7mQjcxloVyCeSKoeTGogfLu5mDaXyk+2uCRa+9mh3TSKUY0FGD6cOnpSYk7HAuMldjWFviB+/zsZlM5g532xHQyT0H+QnEaDek+eJVFwbxoY+iixAe3wFFM9KepT7+q+1YRLfZLzhDiQenSbPlC8dQtFZ2mtwdWDlZa8vXRcvSZOOZiW7kopSx3xfMbDFLBdnIc+zy9htmvHcVIiVSsCJxml5m81rjQGQYiOohjkSn9voPkpqCmnn2+KF67/sXR9vDXSnv6RFQNmDk2/TfoG8Uy2PVZ1mCruLzRc=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040403000306070206090506"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3be161f3-f140-4164-23d3-08d64250bd22
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2018 12:26:27.1263 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2718
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0hTYRjHeXfO5nE0e9MtH8wgh/TBvKSWaEUqRZhoJBGZmjn0eEmdsqPS hEDTrDZMg/KyolmJkYq3BJUWy6WJysoLqUjelcpLmBZi3trZ0ahvv+f5P//n8vJShPUXvh2V IE+jFXJZklQgJEtDmzJdbsyMhh9eNB7zHm/TWHh/ql9F3trebL4fEVBevsoLqHt7NiC3oJc8 T4QJT8TQSQkZtMLtZJQwfmuxG6XqvK53jbcTWei9pwpZUoCPwODCAKlCQsoatyHQtg7wueAX Al1JOfobLPflWXDBcx4sbI2YFRIXEmB8OMbjlCIe3FKpCS6YRLBxb03AjhHg03D7u95cJcYq BJqbSzxWsMHRsFqp4rMsxjHQ9KLBlKdM7AoD9d5smsSOUKAZIVgWYV8oy17cXneYD6/LDYgV LHEIfKjtMPdEeC+sdFWbmcC2MDyt5XG3imGit1vAsQS+TW3y2VmAD8C7WRGbluArkNupMb8A YA2CjmodyfWMBN3onW2vMxgHpxHH+6FPq0acYUgA+rpmkhOCQT9QIeCEfgT6rBa04y55mbNd lALtSyOoEHlo/llWY/IQ+C6C4sdVfI357D3QWTpNckVe8OTVBMHxIah4Okf8b2b5OJT8bhVw 7AAP1BMWHB+FufYfiGNPqKjZEJQhYSWSMDTDJMd5eLrSioRohkmRu8rptAZk+nKtjWsuzahq zt+AMIWku0TxraPh1nxZBqNMNiBHU5/JuqoeZEfKU+S0VCw6mG+SRTEyZSatSLmqSE+iGQPa R5FSW5FrpS7MGsfJ0uhEmk6lFTsqj7K0y0IRF1UjcZFU4XpqrFvPrG3qMu+UX8Ru+7lYldWk 2l3dtbDRH2Wfn+ec7bMevBlkSGoM+mprvOQ3LykdK9IJc9NatlZyJFb6fN+eGqfJN5dVMw7F i4882gajEq+5DftP1QbeP7N6Qal0DDpn45NQ3x2oTF/+/HFd+Sx0aP52VWLITynJxMvcnQgF I/sDvnKPb3oDAAA=
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 04 Nov 2018 12:26:42 -0000

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

Hello,

Deprecate and startover today, with the current definition of=20
deprecated, allows: remove and startover. The server is not mandated to=20
support deprecated nodes.

Deprecating/Removing stuff is not just backwards incompatible, it also=20
leads to the client not knowing whether deprecated stuff is supported or =

not. So IMHO anything is better then the current deprecated.

regards Balazs

On 2018. 10. 27. 20:50, Andy Bierman wrote:
> IMO the current "deprecate and start over" is actually the easiest and =

> most robust
> solution path, and it requires no changes to YANG or the protocols.

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



--------------ms040403000306070206090506
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTEwNDEyMjYxOFow
LwYJKoZIhvcNAQkEMSIEIGNd/uWaQwxg4xbmJuue4b9P0I5JEE4Y9CHYFawpNdYbMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBACDzvwdpbuvw4IXX2sRvd2dk+rZF/3P7qLgYCOzVZwkYX2IT
Q0QkDXFLG7iuoY0FrtRGhNVjZdDOBmGb4TM44sV5aB9va5KOWsr8z2bTpsenPMf2y6BGEImk
v+n5gVzc6j3TFx48OCuM/Z9nKoNvKMEuSXaPaJYYAIeuxBNj8vLxYDmcB7g/ocR3+tkJWZIw
HC72pnNQdZuM0FY7w9ODHHZZkbSzm9d96+iMRf7Qo5OEAiIA1caHxWA3hjKPJAwiDO3CQLp3
Yl6Ceu0XXH3AOKaZtJ2PVc2JcutWv1Hr6SLm4ReAdtiuvAf84K6KxqVxgvwvQVBGjGLaulFD
mvsiREsAAAAAAAA=

--------------ms040403000306070206090506--


From nobody Sun Nov  4 04:39:13 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7D5127332 for ; Sun,  4 Nov 2018 04:39:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.067
X-Spam-Level: 
X-Spam-Status: No, score=-3.067 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=hLJCzx5b; dkim=pass (1024-bit key) header.d=ericsson.com header.b=U6gD+P5+
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMuATn38m1NT for ; Sun,  4 Nov 2018 04:39:09 -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 AFA961200D7 for ; Sun,  4 Nov 2018 04:39:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1541335145; x=1543927145; 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=atAtr6unpZ6CT0dypznZVoy+c4ct1zzagQHY6iX+bHQ=; b=hLJCzx5bf1hCbS5crYvcH5NiNdu9D5UFFTdqy5Pqh0Kyu/MaSv5JZMngJ6rn/VUz Dd+aqjpk4QiiLt7W1LNOLiXxvNbTvkPjo6vfmmPDXpQe2bOkQpehSnXqb3AXkGMa wLvTPntJTbXhvC0zZPZmBedpg89kOFkANU6yhIGzHTY=;
X-AuditID: c1b4fb30-203ff70000007d19-93-5bdee869ee41
Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CA.17.32025.968EEDB5; Sun,  4 Nov 2018 13:39:05 +0100 (CET)
Received: from ESESBMB503.ericsson.se (153.88.183.170) 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; Sun, 4 Nov 2018 13:39:05 +0100
Received: from EUR04-VI1-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; Sun, 4 Nov 2018 13:39:05 +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=DZP7vPW+GSGd0cPrrP1HZqYKv92aIEtDwsE6OhszHB8=; b=U6gD+P5+nw/leLrZaxYGPeWJ27BmhFSREk7sMKJbckayZ12S2vuIFd2NNaGGP6xgYxzVr5fpCymSATVNqWsAIqPFrtVEsN0iNKeaDMcGFuR6aVDVXYG8rE8+Xs1THlNaSg0Gr8JoXlQtwVi8uvjhwJX7Y1tfzRLjQ94m00E6wso=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2494.eurprd07.prod.outlook.com (10.168.139.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.15; Sun, 4 Nov 2018 12:39:04 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd%11]) with mapi id 15.20.1294.028; Sun, 4 Nov 2018 12:39:04 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Robert Wilton , Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
Thread-Index: AQHUdDteOhP2A3sul0+FiL1KlR/0Ug==
Date: Sun, 4 Nov 2018 12:39:04 +0000
Message-ID: 
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org>   <01d5056d-7645-cb1d-6e88-fbdbeb8ebca4@cisco.com> <20181026093347.3yomg5bhwilassvf@anna.jacobs.jacobs-university.de>  <69e3974e-69a9-acd4-b0c8-efec63afd8a9@cisco.com>
In-Reply-To: <69e3974e-69a9-acd4-b0c8-efec63afd8a9@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [192.176.1.82]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
x-clientproxiedby: AM5PR0402CA0012.eurprd04.prod.outlook.com (2603:10a6:203:90::22) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2494; 6:5CI4E7FK7dutwgnExY9/b9xamysolJ4ZFf5yM5ysPIBQoa+RjPEP5ShZr3D++Zu3vvlzg8o9dLrNWio1dVfDBq3ZKR9zeA9dsSN2ja0lWpGYoo434/J+RCc+so24CNlLfbjUucrhPX1CfI+X60K98H71WFC6sSGyqTnsg2TNd8DiLM/X8QVG1dN5GTEtZKz3kIdfw4hlR6luJrOlvwIpE2K3TT9C6OJJInG1aGV8vtKSskD10SmKsv7GDJJIaEg8L+JexpqOvim86kOci6xbd11j8jnYMic7T0/guSnZKkG+/ksL0HAcBY0PrdJ4s2+jUNj7KbOzpFcPrxm+AR+IxdG2qZxRW1inWqujAaVdf9vS+ey1ctTFfdNVgcNzJ+CyXUkkh4U4b7O75PvtyW3hZKqV7UrnRqA1q6b2vqVOojQUQc4/LO6npPyWnuj5oRAMB7I7Pz2UZ9nXp32/C8/ELQ==; 5:YYi32CX3g+rFKnA8LyVoDpMh706VkEUZE5grnopn/hKvYuaShcEeRyULb9oFEpk2vcCiTgdo43hz1avgB2JRFvkBMNjgK0lVAvS4oyAfkcJOYV4q6Az0pb+Pi0N5hA7uSOTY2bkgBxkzZwJkMht3tTVP0pk6XvH2n6I4wh34TdM=; 7:BtZAWe1lPGFyoPQR1Euk6gWOPtgYn7FcX8r6Oon9t2oIMXh3DlxE4EU8lRogiKZ2hBJxovihx8+0/HDPSfepeH0hLPsNlzapHtpuq8/OvlnZEDdC2mUDMkkHPgO94JV/lCl0t/QzlycLKMu13lGW1Q==
x-ms-office365-filtering-correlation-id: 7f8d4131-2551-47f6-5bde-08d642528044
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2494; 
x-ms-traffictypediagnostic: VI1PR0701MB2494:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(100405760836317)(158342451672863)(95692535739014)(248295561703944)(37575265505322)(85827821059158);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231382)(944501410)(4983020)(52105095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2494; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2494; 
x-forefront-prvs: 084674B2CF
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(136003)(346002)(396003)(39860400002)(252514010)(199004)(189003)(51444003)(2501003)(6436002)(93886005)(105586002)(58126008)(316002)(186003)(6486002)(478600001)(25786009)(68736007)(8936002)(81156014)(81166006)(3260700006)(26005)(14454004)(8676002)(6246003)(386003)(53546011)(52116002)(102836004)(76176011)(5660300001)(6506007)(97736004)(6306002)(54896002)(6512007)(236005)(66066001)(65806001)(86362001)(966005)(31686004)(99286004)(65956001)(85182001)(31696002)(65826007)(53936002)(110136005)(71190400001)(71200400001)(6116002)(3846002)(5070765005)(36756003)(15650500001)(2906002)(2900100001)(256004)(14444005)(606006)(99936001)(7736002)(4744004)(64126003)(486006)(229853002)(85202003)(2616005)(11346002)(106356001)(446003)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2494; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: DZI/3qwTwjX+ipYftD/w7FjGpR+xnFm5MwH0OKts3UOdTDlKr2QZY6Sj1RzoOByL1WSt+YbnTWgNnveARiVowEEM7B79QrMhWrjbKUmyXmQQtn+bquMlgBEH26MbPADnk8LoUbAi2MYUuj7GKYupebpMpbSkwQMZD4NThMVpBkbcDdQDuaDasA0S+6dkKJrXRmBy6anes7CfAefiso8l+LUR6LVdS0m3CjzKCg6Qfhi4ScmW5FaBV/giaNJHq5J2Prreief3GeNj+5VfoVVgOnGlg8HQKiRDRVgltQCft+mIV0LsRtiJZrL9CZ/Lyvfx5Hpm1jkV1RrrR6GhkOxJDqSvKug9NjJO6f1rkQ0sxQc=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080009050701000206090305"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7f8d4131-2551-47f6-5bde-08d642528044
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2018 12:39:04.2102 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2494
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTURzHOffebdfh4KQzf2jPJUKWpvZgvS0qFmQPKAhX6tKbj3STTSUN wmC9ZpZZhJvCTGWWmpoV9qKcbvgiy3xFD00dmo8MMRM1q93dBfXf5/f7/r7fc86PQ5NuEzwv Ok6ZzKiVigQJX0jpj9ak+sd96ZEHTvVtkH62GATSzvszSGpsO8eTNrZeJUMo2c25+zxZcfEM Iauq3SvTXmujDlJhwi3RTEJcKqNesy1SGNvbcY9MMucRp3vrJ1EGuvoM6ZALDXgddNtGSR0S 0m7YgmC+pZPgiikEQxmNzqKIAOO1DsQWFM4mobPoO+KUWwTcap2kuKIfgfVjk4BN5uNdcHH8 pcMvxpX2sO4xh+COo2CmVMdjWYyjoaakmuA4ALRXyimWKewDeaYGx4wIb4fCkqd8561IKHtR YD+bpl3wVqiZPcDOILwQppvLHTkk9oT3NiPBPU8MfW0tfI49YHjgF4+1Al4G9SMitu2Bj4O2 ycBj4wEbEHy7nEtwmeHwvOeS07saXnXbnCtbDG+NmYgzvONDR1ezgAsNhWrtSa7fjuBJfivv r9laPO9kFVyfbie5oSwEFY2zZDYKMvxzcYNdI/FlBB8K80mDYwMLoElvowz2Q0jsC6bzkv/n WV4FptujJMebIXfWzOd4OdzM7BNwvB5GrROI47VgqpjnFyBhKfLQMJoTiTHBwQGMOi5Ko1Ep A5RMcjWyfz7zw7nAx2h4aEcdwjSSuIr2mnvkbjxFqiYtsQ752HP6q8reIC9KqVIyErHIN8su i6IVaemMWhWhTklgNHXIm6YkniLp/gdhbjhGkcycYpgkRv1XJWgXrwz0aNngnOtX1VSIX7n3 eNJK+WH973q/jrC+n4svmPQrcsb2/Yqljk0t97dO+//Mea0L2jjiKrku8DbKK9Nrc2Shk+aA B5ZeRVrp3fDEOwMNuCC+v+vIYIlkU1bnjcjdbUtyVUsv6s9m++3UTf5YNBO/x6IMT9Hqznyy RfiTCvEhdyShNLGKID9SrVH8AWSeWx2EAwAA
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 04 Nov 2018 12:39:12 -0000

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


  
    
  
  
    
Implementing 3.2 will be very costly. IMHO Ericsson will not
      implement it. We will do our utmost to avoid NBC changes, but if
      they do happen, I don't believe we would support multiple
      versions.

    

    
If the data models are sufficiently NBC e.g. changing a boolean
      to an integer 3.2 may not even be possible. The underlying data
      that drives the device may be an integer or a boolean, but not
      both. (Strange mapping may be possible to imagine, but they will
      not always work.)

    
regards Balazs

    


    

    
On 2018. 10. 27. 1:15, Robert Wilton
      wrote:

    

    

      
      


      

      

      
On 26/10/2018 17:35, Andy Bierman
        wrote:

      

      

        

          


            


              
On Fri, Oct 26, 2018 at 2:33 AM,=

                Juergen Schoenwaelder <j.schoenwa=
elder@jacobs-university.de>
                wrote:

                
Let me add that
                  there was large disagreement what a bug fix is in the
                  design team. Hence, any text that talks about 'bug
                  fixes' is ambiguous

                  and of limited value to achieve consensus. (Or we may
                  find consensus

                  but then not agree on what we have found consensus
                  on.)

                  

                  To be more concrete, I learned that Rob's notion of a
                  bug fix is very

                  different from my notion of a bug fix. I think it is
                  important for

                  having a productive discussion to be aware of this.
=

                  

                  For me, a bug fix is rather limited, i.e., fixing
                  something where the

                  correct intention was clear but the model did not
                  properly capture the

                  intention correctly, i.e., roughly what we can do with
                  errata in the

                  IETF. I think Rob understands bug fixes in a much
                  broader sense,

                  including fixes to what essentially are in my view
                  module design

                  errors.

                  

                  With my narrow definition of bug fixes, bug fixes are
                  essentially

                  backwards compatible (even if they may violate RFC
                  7950 rules - but as

                  long as the original intention was clear, we can be
                  flexible).

                  

                  With Rob's notion of bug fixes, we have to handle them
                  as part of the

                  versioning system since they may be non-backwards
                  compatible.

                  

                

                


                

                


                

                
IMO requirements 3.1 and 3.2 are the most
                  =C2=A0important and have the most impact

                
on the solution space. I do not agree with either
                  of these requirements.

              

            

          

        

      

      OK.

      

      For 3.1, I think that just means that the solution has to be
      backwards compatible with existing clients (e.g. don't change the
      protocols in a non backwards compatible way).

      

      

        

          

            

              

                


                

                
Implementing multiple non-compatible revisions of a
                  module on a server sounds hard,

                
not to mention that it breaks RFC 7950 rules. 
=

              

            

          

        

      

      Completely agree that it will be hard.=C2=A0 I envisage that it wil=
l
      optional for servers to implement this.

      

      

        

          

            

              

                
The current protocols do not support the

                
ability to specify different versions of the same
                  QName. This change makes YANG validation

                
much to difficult to specify and implement (as that
                  has to be rewritten as well).

              

            

          

        

      

      The way that I think of one solution for this problem is using
      datastore schema (as per the NMDA definition):

      

      Say for release X, the server natively supports Module A@ver1.0.0 and ModuleB@ver1.0.0, call this schema X=
=2E

      For release Y, the server natively supports Module A@ver1.1.0 and ModuleB@ver2.0.0, call this schema Y=
=2E

      

      When a client connects it chooses which schema it wants to use, X,
      Y, or latest.=C2=A0 If it doesn't specify then perhaps it uses the
      earliest schema (to handle requirement 3.1).

      

      If the client wants to use X, then the server has to translate the
      request into the equivalent request using schema Y instead.=C2=A0
      Perhaps the server has to validate the config both in the context
      of X and Y.

      

      If the clients wants to use Y then it just talks to the server
      normally, i.e. as it does today.

      

      I think that this is logically the equivalent model mapping that
      clients would have to do to support multiple server revisions.=C2=A0=

      Yes, I think that it is complex.=C2=A0 No, I'm not sure how many
      vendors will decide to implement this, but I think that it is OK
      to require the solution to specify how this is done, so that
      servers that do want to support this, and clients that want to use
      this, can do so.

      

      But all the QNames, validations, etc, I think would be constrained
      to a particular schema.

      

      

        

          

            

              

                


                

                
It is one thing to deploy rapidly changing, buggy
                  YANG modules in order to

                
gain experience quickly..=C2=A0 It is quite another =
to
                  complicate YANG and the protocols

                
to preserve these interim mistakes, and bake into
                  the standards the notion that this

                
is good engineering.

              

            

          

        

      

      Thanks,

      Rob

      

      

        

          

            

              

                


                

                


                

                
 /js

                

                


                

                
Andy

                
=C2=A0

                
 

                  On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert
                  Wilton wrote:

                  > Hi Chris,

                  > 

                  > 

                  > On 25/10/2018 18:42, Christian Hopps wrote:

                  > > 

                  > > Hi Rob,

                  > > 

                  > > We've more privately discussed the bug-fix
                  scenario and I'm sympathetic

                  > > to it; however, the requirement as written
                  does not restrict itself to

                  > > fixing module definition bugs (e.g., a
                  pattern or other value

                  > > constraint) in some small but incompatible
                  way -- instead it's wide open

                  > > and it will be [ab]used that way.

                  > I think that everyone on design team agrees that
                  non-backwards-compatible

                  > changes should be minimized and should really
                  only to used for bug fixes

                  > where it is anticipated that clients should not
                  be affected.

                  > 

                  > We want to allow non-backwards-compatible changes
                  at the head of the

                  > development tree, but again, I think that
                  everyone agrees that keeping it

                  > backwards compatible where possible is a good
                  goal.

                  > 

                  > However, I think that there will be cases where a
                  vendor decides that it is

                  > right for an enhancement or non backwards
                  compatible change to be made to an

                  > already released module.=C2=A0 I agree that this i=
s
                  highly undesirable and an

                  > abuse of the rules, but I don't believe that
                  whatever versioning scheme we

                  > come up with will prevent vendors from doing
                  this.=C2=A0 So then the question

                  > becomes: Is it better to pretend that this
                  scenario will never happen,

                  > design the versioning scheme so that it cannot be
                  expressed, which probably

                  > just means that clients will not be able to
                  detect when vendors do this by

                  > cheating the rules!=C2=A0 Or is it better to accep=
t
                  that this will sometimes

                  > occur, provide strong guidance as to why this is
                  bad practice and should be

                  > avoided, but have a versioning scheme that still
                  allows this to be expressed

                  > (in a bounded way)?=C2=A0 I.e. even if the vendors=
 are
                  doing something that is

                  > less than ideal, at least the clients can spot
                  where they have done this.

                  > 

                  > ---

                  > 

                  > A separate concern that we had about ties this
                  strictly to bug fixes is that

                  > some one will ask for a definition of a bug fix.=C2=
=A0
                  The design team tried this

                  > but we couldn't even agree what a bug fix is, let
                  alone agree with a single

                  > definition of a bug fix as it related to a YANG
                  module.=C2=A0 So our conclusion

                  > was that perhaps it is better not to tie the
                  requirements themselves to bug

                  > fix vs enhancement, because the boundary between
                  the two is too vague, and

                  > module writers will bend the rules.

                  > 

                  > So I see that the rules should be:

                  > =C2=A0- backwards compatible bug fix=C2=A0 - this =
is fine.

                  > =C2=A0- non backwards compatible bug fix - this is=

                  fine if it is pragmatically

                  > expected to not impact any clients, but careful
                  consideration is required if

                  > it might break clients.

                  > =C2=A0- backwards compatible enhancement - not ide=
al,
                  but pragmatically OK.

                  > =C2=A0- non backwards compatible enhancement - thi=
s is
                  bad and should be avoided.

                  > 

                  > But if we don't want to define the difference
                  between a bug fix vs

                  > enhancement then I think that you end up with the
                  most general requirement

                  > being that we do want to allow for
                  non-backwards-compatible changes in

                  > released modules to accommodate the bug fix
                  scenario, but the expectation

                  > (and guidance) will be that they should only be
                  used for bug fixes.

                  > 

                  > 

                  > > 

                  > > For example:

                  > > 

                  > > > Here is what I am afraid the vendors
                  want here: A developer on

                  > > > release train X can easily change some
                  data structure and then push

                  > > > the change into an automated system
                  which generates a new YANG

                  > > > module definition and revs a version
                  number -- all done! They don't

                  > > > have to deal with the inertia of making
                  this change in their release

                  > > > train Y or Z and they don't have to
                  treat modules as a stable API

                  > > > they are exporting, b/c they now have
                  these new wonderful versions

                  > > > from this work. Meanwhile we the users
                  now have to deal with N forks

                  > > > with all the various little
                  incompatible changes random developers

                  > > > at the company wanted to make without
                  having to coordinate with

                  > > > their coworkers/other internal teams.
                  Now multiply this by M

                  > > > vendors. It's a nightmare. It shouldn't
                  be what we are optimizing

                  > > > for, let alone making a requirement.
=

                  > > 

                  > > Regarding enhancements, these are features,
                  and are naturally

                  > > augmentative. I find it hard to believe we
                  have a pressing

                  > > need/requirement to support non-backward
                  compatible changes to existing

                  > > modules in order to support enhancements.
=

                  > I agree.=C2=A0 It was a backwards compatible
                  enhancement that I was considering.

                  > 

                  > Thanks,

                  > Rob

                  > 

                  > 

                  > > 

                  > > Thanks,

                  > > Chris.

                  > > 

                  > > 

                  > > Robert Wilton <rwilton@cisco.com>
                  writes:

                  > > 

                  > > > Hi Chris,

                  > > > 

                  > > > I think that there are two things
                  driving this requirement:

                  > > > 

                  > > > What I regard as the key one, is that
                  we want to be able to support

                  > > > the software

                  > > > that we have shipped. In particular, we
                  may need to fix bugs

                  > > > (perhaps at the

                  > > > operators request) to a YANG model that
                  has already been released.

                  > > > I.e. I think

                  > > > that there are some scenarios, where
                  forking a YANG module, although

                  > > > undesirable

                  > > > is the right thing to do to include a
                  fix. I don't believe that

                  > > > features or

                  > > > deviations help solve this problem.

                  > > > The two alternative solutions to being
                  able to fix bugs, neither of

                  > > > which I

                  > > > think is pragmatic, that I can think of
                  are:

                  > > > (i) Vendors ensure that their YANG
                  modules are perfect before they

                  > > > ship in a

                  > > > release.

                  > > > (ii) If a bug is reported, operators
                  are happy to wait until the bug

                  > > > has been

                  > > > fixed in the current development
                  release, and will migrate to that

                  > > > latest

                  > > > release to pick up the fix.

                  > > > 

                  > > > The second thing driving this
                  requirement is that vendors sometimes

                  > > > get asked

                  > > > for enhancements to existing releases,
                  perhaps because the latest

                  > > > development

                  > > > release is too far out, or ask for an
                  enhancement on the current

                  > > > train to be

                  > > > back ported to an older release.

                  > > > 

                  > > > So, aiming to have stable YANG modules,
                  trying a lot harder to avoid

                  > > > non-backwards-compatible changes, and
                  keeping new functionality to

                  > > > the head of

                  > > > the development I completely agree with
                  you on. But I still believe

                  > > > that there

                  > > > are some valid scenarios, that should
                  be limited as much as

                  > > > possible, where it

                  > > > is necessary to make changes that
                  sometimes break these rules, and

                  > > > having a

                  > > > limited scheme that clearly indicates
                  where such breakages have

                  > > > occurred is

                  > > > probably better that the status quo of
                  where the modules get

                  > > > changed, but the

                  > > > operator doesn't get any useful
                  indication of what type of changes

                  > > > are being

                  > > > made.

                  > > > 

                  > > > Thanks,

                  > > > Rob

                  > > > 

                  > > > 

                  > > > On 25/10/2018 16:26, Christian Hopps
                  wrote:

                  > > > > 

                  > > > > > On Oct 20, 2018, at 1:55 PM,
                  Joe Clarke <jclarke@cisco.com>
                  wrote:

                  > > > > > 

                  > > > > > * New requirement 1.4 for
                  supporting over-arching software releases

                  > > > > [ I read this as supporting
                  various different module versions

                  > > > > based on a vendor's different
                  software release trains. If this

                  > > > > is wrong then the rest of this
                  doesn't apply and I would just

                  > > > > ask for the text to be update to
                  clarify what it means. ]

                  > > > > 

                  > > > > How many operators/users have
                  asked for this or indicated it's a

                  > > > > requirement for them?

                  > > > > 

                  > > > > What problem is intractable
                  without this requirement being met,

                  > > > > and what is the cost of this
                  requirement on the actual users?

                  > > > > 

                  > > > > I have pushed back multiple times
                  on this b/c I believe this

                  > > > > "requirement" is really being
                  pushed to make it easier for

                  > > > > vendors (a small affected group)
                  to develop their software at

                  > > > > the cost of their users (the much
                  larger affected group) who

                  > > > > would then have to deal with
                  multiple trains of the same module.

                  > > > > 

                  > > > > 

                  > > > > We already have features and
                  deviations why are they not enough

                  > > > > to deal with functionality that is
                  present or not in various

                  > > > > software release/devices?

                  > > > > 

                  > > > > FWIW I'm not against making it
                  easier to develop software, but

                  > > > > we have to be mindful if we are
                  just pushing the cost (and

                  > > > > magnifying it greatly) to other
                  people in the community..

                  > > > > 

                  > > > > Thanks,

                  > > > > Chris.

                  > > > > 

                  > > > > ______________________________=
_________________

                  > > > > netmod mailing list

                  > > > > netmod@ietf.org

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

                  > > > > .

                  > > > > 

                  > > 

                  > > .

                  > > 

                  > 

                  > _____________________________________________=
__

                  > netmod mailing list

                  > netmod@ietf.org

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

                  
                      -- 

                      Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0Jacobs University
                      Bremen gGmbH

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

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

                      

                      ______________________________________________=
_

                      netmod mailing list

                      netmod@ietf.org

                      https://www.ietf.org/mai=
lman/listinfo/netmod

                    

              

              

            

          

        

        

        

        

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


      

      

      

      

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


    

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


  



--------------ms080009050701000206090305
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTEwNDEyMzg0Nlow
LwYJKoZIhvcNAQkEMSIEINBUdEic4xx03Mj3hA5k4VGle8E4u/Tk73YJYbXk/GUHMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAKsvRJMS9WSrIQRV5ZzONDAd1xrq21LjdIGwTG7GW1A2OgVX
BCkQaiFamXwyHI/u/DLaeGCUVm6PGhKHsZzxlQwz7Yo23sJA5PWXBnPk+PAXygme80QpAZ2e
JnxDGKOkpTsdTT0dopa/HAK/9NRePCbeN5LeNs7BYrF7gnNIQZdYOh3+l7ZdRgX78PmOF/Sq
jAMKG681AYsZ8p4ivntLR2J4BGY2OwzxXxTPmyhF3Cypuw9fgWSRcqe48/KWTpCrqnwHei+z
sJFtGU4s05jTmStISgT39iR+X6bzHgXgXwjZXcCAO8rZyl2kRwRb+wunahuJZ2vNIVWetBUz
9CaoJrUAAAAAAAA=

--------------ms080009050701000206090305--


From nobody Sun Nov  4 19:02:20 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D814130E53 for ; Sun,  4 Nov 2018 19:02:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEZ-xRCT9ZFm for ; Sun,  4 Nov 2018 19:02:08 -0800 (PST)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD24C126BED for ; Sun,  4 Nov 2018 19:02:08 -0800 (PST)
Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id F1873140823 for ; Sun,  4 Nov 2018 19:35:16 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id JUjUg5zwtj0soJUjUgdZs8; Sun, 04 Nov 2018 19:35:16 -0700
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:Cc:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=0slSBAbewxJGwO7uXku5C8TlF1QLF9FIp8P1DBDHDwk=; b=Cs7fcOt200diTDuiU1JnYSp6rK O/rMXjkiqSs+a4VaIrAjXhR/ydBsPNaBCd/MlnoI6YjFu22pWvYj1YpzkXSHvLDV0RTZkvVW9aRBD GXQSv4r7NOY537r+UgKtGp/6V;
Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:50718 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gJUjU-003Ydx-B9; Sun, 04 Nov 2018 19:35:16 -0700
To: NETMOD Group 
Cc: NetMod WG Chairs 
From: Lou Berger 
Message-ID: <4c03295f-b30b-41a5-2677-acf674e894b5@labn.net>
Date: Mon, 5 Nov 2018 09:35:12 +0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.106.211
X-Source-L: No
X-Exim-ID: 1gJUjU-003Ydx-B9
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:50718
X-Source-Auth: lberger@labn.net
X-Email-Count: 7
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] Please send you slides...
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Nov 2018 03:02:13 -0000

Hi,

     All received slides received to date have been uploaded to 
https://datatracker.ietf.org/meeting/103/session/netmod

If you are on the agenda, please send your slides ASAP.  If you have 
already sent them, please confirm that they are posted at the above link.

Thank you!

Lou


From nobody Mon Nov  5 00:54:54 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 DF5BC130934; Mon,  5 Nov 2018 00:54:47 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.3
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netmod@ietf.org
Message-ID: <154140808785.9316.7124767705894949441@ietfa.amsl.com>
Date: Mon, 05 Nov 2018 00:54:47 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-artwork-folding-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Nov 2018 08:54:48 -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           : Handling Long Lines in Artwork in Internet-Drafts and RFCs
        Authors         : Kent Watsen
                          Qin Wu
                          Adrian Farrel
                          Benoît Claise
	Filename        : draft-ietf-netmod-artwork-folding-00.txt
	Pages           : 17
	Date            : 2018-11-05

Abstract:
   This document introduces a simple and yet time-proven strategy for
   handling long lines in artwork in drafts using a backslash ('\')
   character where line-folding has occurred.  The strategy works on any
   text based artwork, but is primarily intended for sample text and
   formatted examples and code, rather than for graphical artwork.  The
   approach produces consistent results regardless of the content and
   uses a per-artwork header.  The strategy is both self-documenting and
   enables automated reconstitution of the original artwork.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-artwork-folding/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-artwork-folding-00
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-artwork-folding-00


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Nov  5 01:23: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 C773C12F1AC for ; Mon,  5 Nov 2018 01:23:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9UIqoFuC9K8 for ; Mon,  5 Nov 2018 01:23:19 -0800 (PST)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A76C1274D0 for ; Mon,  5 Nov 2018 01:23:19 -0800 (PST)
Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 6A8CC177182 for ; Mon,  5 Nov 2018 02:02:30 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id JamEgAkBij0soJamEgiFw7; Mon, 05 Nov 2018 02:02:30 -0700
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=UD0mbadMivnddJkVowRzHjrVNK60uV0YZRN5P+n0gsU=; b=KoFEqTOEO+2FhxV/xdNNxjslfn e1Jn6LTcxzT9Rnd0JZEB32TVnxyXqX+Hce8C+aeTdD3OaSNVdVEOxrThP8SlDYZ4JF3auXh0yu69+ qS89wVkNM2NyVs8ok7X/lxNXl;
Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:46276 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gJamD-000g9K-Li; Mon, 05 Nov 2018 02:02:30 -0700
To: NetMod WG Chairs , NetMod WG 
From: Lou Berger 
Message-ID: 
Date: Mon, 5 Nov 2018 16:02:26 +0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.106.211
X-Source-L: No
X-Exim-ID: 1gJamD-000g9K-Li
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:46276
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] Revised NetMod agenda
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 05 Nov 2018 09:23:21 -0000

Hi,

     We have shuffled the slots a bit in order to allow for more 
discussion in the second session.  Specifically, the following are now 
in the first session:

    Title:    A YANG Data model for Event Management
     Presenter:    Michael Wang
     Draft: https://tools.ietf.org/html/draft-wwx-netmod-event-yang-00
     Title:    NMDA Base Notification for Applied Intended Configuration
     Presenter:    Qin Wu
     Draft: 
https://tools.ietf.org/html/draft-wu-netmod-base-notification-nmda-00

The updated agenda is available at: 
https://datatracker.ietf.org/meeting/103/materials/agenda-103-netmod-03

Lou (Joel and Kent)



From nobody Mon Nov  5 12:49: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 2A8E01286E7 for ; Mon,  5 Nov 2018 12:49:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3qPXyi8_k_p for ; Mon,  5 Nov 2018 12:48:57 -0800 (PST)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 112DB1286E3 for ; Mon,  5 Nov 2018 12:48:57 -0800 (PST)
Received: by mail-io1-xd33.google.com with SMTP id a5-v6so7581170ioq.8 for ; Mon, 05 Nov 2018 12:48:57 -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=MYeaceaqdd9imsUPApKS7AUZ2aTAYAUDJhsTi6QrOVg=; b=LgLVE4ZhDybTs/e8RpswJtR3g2ClmvZ5KLvq3hgcdJHKN8tXSDKJqE1byyiUwTa1La OZhuptgfygSkIGI+IakQfd8kCLNOMZSRDfgbjRr7bYhO8MdFuG4vcbxQEyDg8N1C8SoC LGLqWLXUbRnMrMGMP+3RbAJSZnlrLSgp7hocTYjlQ155eGgLWRj6e2Zrpltgq3QpNo/c giwMgh+YqgcgjyHtMdDmPaDZgtMz+gSQ/NXLLY9kDePbFVEA3EIz0hNnTlRtzvHtqQGL ru7vpNWkYXNCQJjAwaSZw34D7i0HJBio9hLdXroygKQzhEgdJa1z8yHBDS8G6A8rKhzo Wn3w==
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=MYeaceaqdd9imsUPApKS7AUZ2aTAYAUDJhsTi6QrOVg=; b=KkfEXGaT1cegSw6TiCVFSiXrRhn2g8iIXAiHAboWY6KqK0UEZYhh6UGIe1ciyFl5vY 1yD19qp2lxZKl1reheCCjt9yjwEKthUZjyPm/CXi73PZj3R4TYQxBf0cP3VwhWQ/MNKa lIpK089MerWFFS0mIGsBjEJTmWiG/bvZCnoiFyn2Y1Lk4bt/7lsGPxsYZRTClTtCFqci Spv5As26P406g8UFaUNr4zmAyXizZBfj7xOuxxFIVzD9rFpTHCFUR33C3x+OS7TI/1W5 Uhbo8cUpeq70nJeRBGw15SN5FKpDiwrEqPxp0NWrGQqSPgFWXsxsgtxl+dYkgbUEjuVy igMw==
X-Gm-Message-State: AGRZ1gLcHNsGAQqjtqbBfnhhiZVqBhCzuEW+2UggHo+6m5jYNdD7/fgt JNvpbB1dQWFdNIR39+HlaaAR6T7ToByVWyADAyw=
X-Google-Smtp-Source: AJdET5ctY3v6TnvO8qMLhogGIelh8Wgglmxgs+XDz5G4n2I0HdUnTd80h4xzy4/3GfAL0mVOKj54nM6JtJSpOHLPGuQ=
X-Received: by 2002:a6b:c6cc:: with SMTP id w195-v6mr19233410iof.149.1541450936251;  Mon, 05 Nov 2018 12:48:56 -0800 (PST)
MIME-Version: 1.0
References:  <20181029230138.44pmjmza5mg2cb4a@anna.jacobs.jacobs-university.de> <92E98222-E53B-49EE-8BC9-0FC0A406460E@juniper.net> <20181030101448.pwzdyupseabnzpil@anna.jacobs.jacobs-university.de> <00fc01d472c1$f526c3c0$4001a8c0@gateway.2wire.net>  <0810ee8c-2c25-c312-9e8f-3ee952048818@ericsson.com>
In-Reply-To: <0810ee8c-2c25-c312-9e8f-3ee952048818@ericsson.com>
From: Xufeng Liu 
Date: Mon, 5 Nov 2018 15:48:44 -0500
Message-ID: 
To: balazs.lengyel@ericsson.com
Cc: "t.petch" , NETMOD WG 
Content-Type: multipart/alternative; boundary="0000000000007e79d70579f1034f"
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, 05 Nov 2018 20:49:00 -0000

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

The draft that asked for the percentage type is:
https://tools.ietf.org/html/draft-ye-ccamp-mw-topo-yang-02

They currently define:

              leaf availability {
                type decimal64 {
                  fraction-digits 4;
                  range "0..99.9999";
                }
                description "Availability level of the link";
              }

Thanks,
- Xufeng

On Sun, Nov 4, 2018 at 7:07 AM Bal=C3=A1zs Lengyel 
wrote:

> +1 to percentage.
>
> Balazs
> On 2018. 11. 03. 3:44, Xufeng Liu wrote:
>
> Remember that some draft asked for a type of percentage value to the
> nearest hundredth. Wondering if it can be put in.
>
> Thanks,
> - Xufeng
>
> On Fri, Nov 2, 2018 at 11:39 AM tom petch  wrote:
>
>> ---- Original Message -----
>> From: "Juergen Schoenwaelder" 
>> To: "Kent Watsen" 
>> Cc: 
>> Sent: Tuesday, October 30, 2018 10:14 AM
>>
>> > On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen wrote:
>> > >
>> > > >> In addition, it might be good to introduce [inet?] types for RFC
>> 5322
>> > > >> (Internet Message Format) including perhaps:
>> > > >>
>> > > >>   - email-address        (addr-spec, per Section 3.4.1)
>> > > >>   - named-email-address  (name-addr, per Section 3.4)
>> > > >>
>> > > >
>> > > > Where are these used? Or have these already been used somewhere?
>> > >
>> > > I'm unaware of these ever having been used before.  I am working on
>> a private module for which I want to configure an email address.  After
>> some searching, I concluded that no such types have been defined, and
>> thus thought that they might be good candidates for addition.
>>
>>
>> We could defined a user-name, of the form localpart@domainpart as is
>> widely used to identify a user in operations but which does not, in my
>> experience, owe anything to i18n, just a straightforward character set;
>> yes it would not boil the ocean, but could be useful.  I am surprised
>> not to find such a definition somewhere in our 40 or so NETCONF I-Ds.
>>
>> Tom Petch
>>
>>
>>
>>
>>
>>
>>
>> > >
>> >
>> > It would be good to have strong use cases. I fear that defining this
>> > type won't be easy given that we also have internationalized email
>> > addresses (RFC 6530 provides an overview) and we might have to create
>> > a union of RFC 5322 addresses and "SMTPUTF8 (compliant) addresses".
>> >
>> > /js
>> >
>> > --
>> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> > Fax:   +49 421 200 3103         
>> >
>> > _______________________________________________
>> > 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 listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/n=
etmod
>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>
>

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


The draft that aske=
d for the percentage type is: https://tools.ietf.org/html/draft-ye-ccamp-mw-top=
o-yang-02

They currently define:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 leaf availability {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 type decimal64 {
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 fraction-digits 4;
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 range "0..99.9999";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 description "Availability level of the link";
=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
=


Thanks,
- Xufeng
<=
br>
On Sun, Nov 4, 2018 at 7:07 =
AM Bal=C3=A1zs Lengyel <b=
alazs.lengyel@ericsson.com> wrote:

 =20
   =20
 =20
  

    
+1 to percentage.

    
Balazs

    

    
On 2018. 11. 03. 3:=
44, Xufeng Liu
      wrote:

    

    

     =20
      

        
Remember that some draft asked for a type of
          percentage value to the nearest hundredth. Wondering if it can
          be put in.

        


        

        
Thanks,

        
- Xufeng

        

      

      

      

        
On Fri, Nov 2, 2018 at 11:39 AM tom petch <ietfc@btconnect.com>
          wrote:

        

        
----
          Original Message -----

          From: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs=
-university.de>

          To: "Kent Watsen" <kwatsen@juniper.net>

          Cc: <netm=
od@ietf.org>

          Sent: Tuesday, October 30, 2018 10:14 AM

          

          > On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen
          wrote:

          > >

          > > >> In addition, it might be good to introduce
          [inet?] types for RFC

          5322

          > > >> (Internet Message Format) including
          perhaps:

          > > >>

          > > >>=C2=A0 =C2=A0- email-address=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 (addr-spec, per
          Section 3.4.1)

          > > >>=C2=A0 =C2=A0- named-email-address=C2=A0 (name-=
addr, per
          Section 3.4)

          > > >>

          > > >

          > > > Where are these used? Or have these already
          been used somewhere?

          > >

          > > I'm unaware of these ever having been used before.=
=C2=A0
          I am working on

          a private module for which I want to configure an email
          address.=C2=A0 After

          some searching, I concluded that no such types have been
          defined, and

          thus thought that they might be good candidates for addition.

          

          

          We could defined a user-name, of the form localpart@domainpart
          as is

          widely used to identify a user in operations but which does
          not, in my

          experience, owe anything to i18n, just a straightforward
          character set;

          yes it would not boil the ocean, but could be useful.=C2=A0 I am
          surprised

          not to find such a definition somewhere in our 40 or so
          NETCONF I-Ds.

          

          Tom Petch

          

          

          

          

          

          

          

          > >

          >

          > It would be good to have strong use cases. I fear that
          defining this

          > type won't be easy given that we also have
          internationalized email

          > addresses (RFC 6530 provides an overview) and we might
          have to create

          > a union of RFC 5322 addresses and "SMTPUTF8 (compliant)
          addresses".

          >

          > /js

          >

          > --

          > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Jacobs University Bremen
          gGmbH

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

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

          >

          > _______________________________________________

          > netmod mailing list

          > netmod@=
ietf.org

          > https://www.ietf.org/mailman/listinfo/net=
mod

          

          _______________________________________________

          netmod mailing list

          netmod@ietf.=
org

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

        

      

      

      

      
___________________=
____________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/m=
ailman/listinfo/netmod


    

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


  






--0000000000007e79d70579f1034f--


From nobody Mon Nov  5 14:49:05 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6D1126CB6 for ; Mon,  5 Nov 2018 14:49: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 0r3cmNYmrW9K for ; Mon,  5 Nov 2018 14:49: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 B750F1286D9 for ; Mon,  5 Nov 2018 14:49: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 78643DE6; Mon,  5 Nov 2018 23:48: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 H6Nf73ROy0wL; Mon,  5 Nov 2018 23:48:56 +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,  5 Nov 2018 23:48:59 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 611052003D; Mon,  5 Nov 2018 23:48:59 +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 HsT3OK2-H9mH; Mon,  5 Nov 2018 23:48:58 +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 AA5292003F; Mon,  5 Nov 2018 23:48: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; Mon, 5 Nov 2018 23:48:58 +0100
Received: by anna.localdomain (Postfix, from userid 501) id BEB7E3003ACE48; Mon,  5 Nov 2018 23:48:57 +0100 (CET)
Date: Mon, 5 Nov 2018 23:48:57 +0100
From: Juergen Schoenwaelder 
To: Xufeng Liu 
CC: , NETMOD WG 
Message-ID: <20181105224857.5apilufffjjcllir@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Xufeng Liu , balazs.lengyel@ericsson.com, NETMOD WG 
References:  <20181029230138.44pmjmza5mg2cb4a@anna.jacobs.jacobs-university.de> <92E98222-E53B-49EE-8BC9-0FC0A406460E@juniper.net> <20181030101448.pwzdyupseabnzpil@anna.jacobs.jacobs-university.de> <00fc01d472c1$f526c3c0$4001a8c0@gateway.2wire.net>  <0810ee8c-2c25-c312-9e8f-3ee952048818@ericsson.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/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, 05 Nov 2018 22:49:05 -0000

Apparently people have different needs concerning precision...

/js

On Mon, Nov 05, 2018 at 03:48:44PM -0500, Xufeng Liu wrote:
> The draft that asked for the percentage type is:
> https://tools.ietf.org/html/draft-ye-ccamp-mw-topo-yang-02
> 
> They currently define:
> 
>               leaf availability {
>                 type decimal64 {
>                   fraction-digits 4;
>                   range "0..99.9999";
>                 }
>                 description "Availability level of the link";
>               }
> 
> Thanks,
> - Xufeng
> 
> On Sun, Nov 4, 2018 at 7:07 AM Balzs Lengyel 
> wrote:
> 
> > +1 to percentage.
> >
> > Balazs
> > On 2018. 11. 03. 3:44, Xufeng Liu wrote:
> >
> > Remember that some draft asked for a type of percentage value to the
> > nearest hundredth. Wondering if it can be put in.
> >
> > Thanks,
> > - Xufeng
> >
> > On Fri, Nov 2, 2018 at 11:39 AM tom petch  wrote:
> >
> >> ---- Original Message -----
> >> From: "Juergen Schoenwaelder" 
> >> To: "Kent Watsen" 
> >> Cc: 
> >> Sent: Tuesday, October 30, 2018 10:14 AM
> >>
> >> > On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen wrote:
> >> > >
> >> > > >> In addition, it might be good to introduce [inet?] types for RFC
> >> 5322
> >> > > >> (Internet Message Format) including perhaps:
> >> > > >>
> >> > > >>   - email-address        (addr-spec, per Section 3.4.1)
> >> > > >>   - named-email-address  (name-addr, per Section 3.4)
> >> > > >>
> >> > > >
> >> > > > Where are these used? Or have these already been used somewhere?
> >> > >
> >> > > I'm unaware of these ever having been used before.  I am working on
> >> a private module for which I want to configure an email address.  After
> >> some searching, I concluded that no such types have been defined, and
> >> thus thought that they might be good candidates for addition.
> >>
> >>
> >> We could defined a user-name, of the form localpart@domainpart as is
> >> widely used to identify a user in operations but which does not, in my
> >> experience, owe anything to i18n, just a straightforward character set;
> >> yes it would not boil the ocean, but could be useful.  I am surprised
> >> not to find such a definition somewhere in our 40 or so NETCONF I-Ds.
> >>
> >> Tom Petch
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> > >
> >> >
> >> > It would be good to have strong use cases. I fear that defining this
> >> > type won't be easy given that we also have internationalized email
> >> > addresses (RFC 6530 provides an overview) and we might have to create
> >> > a union of RFC 5322 addresses and "SMTPUTF8 (compliant) addresses".
> >> >
> >> > /js
> >> >
> >> > --
> >> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> >> > Fax:   +49 421 200 3103         
> >> >
> >> > _______________________________________________
> >> > 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 listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
> >
> > --
> > Balazs Lengyel                       Ericsson Hungary Ltd.
> > Senior Specialist
> > Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
> >
> >

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


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


From nobody Mon Nov  5 17:25:57 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE2A128766 for ; Mon,  5 Nov 2018 17:25:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fiUySwbeLFiK for ; Mon,  5 Nov 2018 17:25: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 4815B126DBF for ; Mon,  5 Nov 2018 17:25:53 -0800 (PST)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0E96D8421379; Tue,  6 Nov 2018 01:25:50 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 6 Nov 2018 01:25:50 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.136]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Tue, 6 Nov 2018 09:25:43 +0800
From: Qin Wu 
To: Xufeng Liu , "balazs.lengyel@ericsson.com" 
CC: NETMOD WG 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AdR1b1B7kgfc1cJfSNGjn+lEz8NlxA==
Date: Tue, 6 Nov 2018 01:25:43 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.126.173.236]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B0FC256nkgeml513mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 01:25:56 -0000

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

QW5vdGhlciBjYXNlIHdvdWxkIGJlIDoNCg0KDQrigJwNCg0KdHlwZWRlZiBwZXJjZW50YWdlIHsN
Cg0KICAgICAgdHlwZSBkZWNpbWFsNjQgew0KDQogICAgICAgICBmcmFjdGlvbi1kaWdpdHMgNTsN
Cg0KICAgICAgICAgcmFuZ2UgIjAuLjEwMCI7DQoNCiAgICAgfQ0KDQogICBkZXNjcmlwdGlvbiAi
UGVyY2VudGFnZS4iOw0KICAgfQ0K4oCdDQpXaGljaCBpcyBkZWZpbmVkIGlldGYtY29ubmVjdGlv
bmxlc3Mtb2FtLnlhbmcgbW9kdWxlLg0KDQotUWluDQrlj5Hku7bkuro6IG5ldG1vZCBbbWFpbHRv
Om5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSDku6PooaggWHVmZW5nIExpdQ0K5Y+R6YCB5pe26Ze0
OiAyMDE45bm0MTHmnIg25pelIDM6NDkNCuaUtuS7tuS6ujogYmFsYXpzLmxlbmd5ZWxAZXJpY3Nz
b24uY29tDQrmioTpgIE6IE5FVE1PRCBXRyA8bmV0bW9kQGlldGYub3JnPg0K5Li76aKYOiBSZTog
W25ldG1vZF0gZm9yIGEgZnV0dXJlIHJmYzY5OTFiaXMNCg0KVGhlIGRyYWZ0IHRoYXQgYXNrZWQg
Zm9yIHRoZSBwZXJjZW50YWdlIHR5cGUgaXM6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC15ZS1jY2FtcC1tdy10b3BvLXlhbmctMDINCg0KVGhleSBjdXJyZW50bHkgZGVmaW5lOg0K
DQogICAgICAgICAgICAgIGxlYWYgYXZhaWxhYmlsaXR5IHsNCiAgICAgICAgICAgICAgICB0eXBl
IGRlY2ltYWw2NCB7DQogICAgICAgICAgICAgICAgICBmcmFjdGlvbi1kaWdpdHMgNDsNCiAgICAg
ICAgICAgICAgICAgIHJhbmdlICIwLi45OS45OTk5IjsNCiAgICAgICAgICAgICAgICB9DQogICAg
ICAgICAgICAgICAgZGVzY3JpcHRpb24gIkF2YWlsYWJpbGl0eSBsZXZlbCBvZiB0aGUgbGluayI7
DQogICAgICAgICAgICAgIH0NCg0KVGhhbmtzLA0KLSBYdWZlbmcNCg0KT24gU3VuLCBOb3YgNCwg
MjAxOCBhdCA3OjA3IEFNIEJhbMOhenMgTGVuZ3llbCA8YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24u
Y29tPG1haWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20+PiB3cm90ZToNCg0KKzEgdG8g
cGVyY2VudGFnZS4NCg0KQmFsYXpzDQpPbiAyMDE4LiAxMS4gMDMuIDM6NDQsIFh1ZmVuZyBMaXUg
d3JvdGU6DQpSZW1lbWJlciB0aGF0IHNvbWUgZHJhZnQgYXNrZWQgZm9yIGEgdHlwZSBvZiBwZXJj
ZW50YWdlIHZhbHVlIHRvIHRoZSBuZWFyZXN0IGh1bmRyZWR0aC4gV29uZGVyaW5nIGlmIGl0IGNh
biBiZSBwdXQgaW4uDQoNClRoYW5rcywNCi0gWHVmZW5nDQoNCk9uIEZyaSwgTm92IDIsIDIwMTgg
YXQgMTE6MzkgQU0gdG9tIHBldGNoIDxpZXRmY0BidGNvbm5lY3QuY29tPG1haWx0bzppZXRmY0Bi
dGNvbm5lY3QuY29tPj4gd3JvdGU6DQotLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206
ICJKdWVyZ2VuIFNjaG9lbndhZWxkZXIiIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNp
dHkuZGU8bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4+DQpUbzog
IktlbnQgV2F0c2VuIiA8a3dhdHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBqdW5pcGVy
Li5uZXQ+Pg0KQ2M6IDxuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+DQpT
ZW50OiBUdWVzZGF5LCBPY3RvYmVyIDMwLCAyMDE4IDEwOjE0IEFNDQoNCj4gT24gVHVlLCBPY3Qg
MzAsIDIwMTggYXQgMTI6MDU6MTdBTSArMDAwMCwgS2VudCBXYXRzZW4gd3JvdGU6DQo+ID4NCj4g
PiA+PiBJbiBhZGRpdGlvbiwgaXQgbWlnaHQgYmUgZ29vZCB0byBpbnRyb2R1Y2UgW2luZXQ/XSB0
eXBlcyBmb3IgUkZDDQo1MzIyDQo+ID4gPj4gKEludGVybmV0IE1lc3NhZ2UgRm9ybWF0KSBpbmNs
dWRpbmcgcGVyaGFwczoNCj4gPiA+Pg0KPiA+ID4+ICAgLSBlbWFpbC1hZGRyZXNzICAgICAgICAo
YWRkci1zcGVjLCBwZXIgU2VjdGlvbiAzLjQuMSkNCj4gPiA+PiAgIC0gbmFtZWQtZW1haWwtYWRk
cmVzcyAgKG5hbWUtYWRkciwgcGVyIFNlY3Rpb24gMy40KQ0KPiA+ID4+DQo+ID4gPg0KPiA+ID4g
V2hlcmUgYXJlIHRoZXNlIHVzZWQ/IE9yIGhhdmUgdGhlc2UgYWxyZWFkeSBiZWVuIHVzZWQgc29t
ZXdoZXJlPw0KPiA+DQo+ID4gSSdtIHVuYXdhcmUgb2YgdGhlc2UgZXZlciBoYXZpbmcgYmVlbiB1
c2VkIGJlZm9yZS4gIEkgYW0gd29ya2luZyBvbg0KYSBwcml2YXRlIG1vZHVsZSBmb3Igd2hpY2gg
SSB3YW50IHRvIGNvbmZpZ3VyZSBhbiBlbWFpbCBhZGRyZXNzLiAgQWZ0ZXINCnNvbWUgc2VhcmNo
aW5nLCBJIGNvbmNsdWRlZCB0aGF0IG5vIHN1Y2ggdHlwZXMgaGF2ZSBiZWVuIGRlZmluZWQsIGFu
ZA0KdGh1cyB0aG91Z2h0IHRoYXQgdGhleSBtaWdodCBiZSBnb29kIGNhbmRpZGF0ZXMgZm9yIGFk
ZGl0aW9uLg0KDQoNCldlIGNvdWxkIGRlZmluZWQgYSB1c2VyLW5hbWUsIG9mIHRoZSBmb3JtIGxv
Y2FscGFydEBkb21haW5wYXJ0IGFzIGlzDQp3aWRlbHkgdXNlZCB0byBpZGVudGlmeSBhIHVzZXIg
aW4gb3BlcmF0aW9ucyBidXQgd2hpY2ggZG9lcyBub3QsIGluIG15DQpleHBlcmllbmNlLCBvd2Ug
YW55dGhpbmcgdG8gaTE4biwganVzdCBhIHN0cmFpZ2h0Zm9yd2FyZCBjaGFyYWN0ZXIgc2V0Ow0K
eWVzIGl0IHdvdWxkIG5vdCBib2lsIHRoZSBvY2VhbiwgYnV0IGNvdWxkIGJlIHVzZWZ1bC4gIEkg
YW0gc3VycHJpc2VkDQpub3QgdG8gZmluZCBzdWNoIGEgZGVmaW5pdGlvbiBzb21ld2hlcmUgaW4g
b3VyIDQwIG9yIHNvIE5FVENPTkYgSS1Ecy4NCg0KVG9tIFBldGNoDQoNCg0KDQoNCg0KDQoNCj4g
Pg0KPg0KPiBJdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgc3Ryb25nIHVzZSBjYXNlcy4gSSBmZWFy
IHRoYXQgZGVmaW5pbmcgdGhpcw0KPiB0eXBlIHdvbid0IGJlIGVhc3kgZ2l2ZW4gdGhhdCB3ZSBh
bHNvIGhhdmUgaW50ZXJuYXRpb25hbGl6ZWQgZW1haWwNCj4gYWRkcmVzc2VzIChSRkMgNjUzMCBw
cm92aWRlcyBhbiBvdmVydmlldykgYW5kIHdlIG1pZ2h0IGhhdmUgdG8gY3JlYXRlDQo+IGEgdW5p
b24gb2YgUkZDIDUzMjIgYWRkcmVzc2VzIGFuZCAiU01UUFVURjggKGNvbXBsaWFudCkgYWRkcmVz
c2VzIi4NCj4NCj4gL2pzDQo+DQo+IC0tDQo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAg
ICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+IFBob25lOiArNDkgNDIxIDIwMCAz
NTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4gRmF4
OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNp
dHkuZGUvPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0
bW9kQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l
dG1vZA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
bmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5v
cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCm5ldG1vZCBt
YWlsaW5nIGxpc3QNCg0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQoN
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPGh0dHBzOi8vd3d3
Li5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZD4NCg0KLS0NCg0KQmFsYXpzIExlbmd5
ZWwgICAgICAgICAgICAgICAgICAgICAgIEVyaWNzc29uIEh1bmdhcnkgTHRkLg0KDQpTZW5pb3Ig
U3BlY2lhbGlzdA0KDQpNb2JpbGU6ICszNi03MC0zMzAtNzkwOSAgICAgICAgICAgICAgZW1haWw6
IEJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbTxtYWlsdG86QmFsYXpzLkxlbmd5ZWxAZXJpY3Nz
b24uY29tPg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm
b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg
MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN
CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg
MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N
c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w
MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r
LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1
ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl
cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K
CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFy
Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBw
dDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBjbTsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eTrlrovkvZM7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7m
oLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI
VE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVt
YWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls
eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0
DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN
CgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6
ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl
bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxp
bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw
cmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0
eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Bbm90aGVyIGNhc2Ugd291bGQgYmUgOjxvOnA+PC9vOnA+
PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bh
biBsYW5nPSJFTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPuKAnDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5
cyI+PHNwYW4gbGFuZz0iRU4iPnR5cGVkZWYgcGVyY2VudGFnZSB7PG86cD48L286cD48L3NwYW4+
PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9
IkVOIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBkZWNpbWFsNjQgezxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz
Ij48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IGZyYWN0aW9uLWRpZ2l0cyA1OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJhbmdlICZxdW90OzAu
LjEwMCZxdW90Ozs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJl
YWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyB9PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y
ZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsmbmJzcDsgZGVzY3JpcHRpb24gJnF1b3Q7
UGVyY2VudGFnZS4mcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PHNwYW4gbGFuZz0i
RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox
MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2hpY2ggaXMgZGVmaW5l
ZCBpZXRmLWNvbm5lY3Rpb25sZXNzLW9hbS55YW5nIG1vZHVsZS48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt
c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv
bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LVFpbjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oyxz
YW5zLXNlcmlmIj7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9i
PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IG5ldG1vZCBbbWFpbHRvOm5ldG1v
ZC1ib3VuY2VzQGlldGYub3JnXQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7ku6Po
oaggPC9zcGFuPg0KPC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+WHVmZW5n
IExpdTxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+5Y+R6YCB5pe26Ze0PHNw
YW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7
LHNhbnMtc2VyaWYiPiAyMDE4PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lubQ8c3BhbiBs
YW5nPSJFTi1VUyI+MTE8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjY8L3NwYW4+5pelPHNw
YW4gbGFuZz0iRU4tVVMiPg0KIDM6NDk8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFu
Zz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gYmFsYXpzLmxlbmd5ZWxA
ZXJpY3Nzb24uY29tPGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9z
cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IE5FVE1PRCBXRyAmbHQ7bmV0bW9kQGlldGYub3Jn
Jmd0Ozxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+
PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogW25ldG1vZF0gZm9yIGEgZnV0dXJlIHJmYzY5OTFiaXM8
bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K
PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhl
IGRyYWZ0IHRoYXQgYXNrZWQgZm9yIHRoZSBwZXJjZW50YWdlIHR5cGUgaXM6DQo8YSBocmVmPSJo
dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteWUtY2NhbXAtbXctdG9wby15YW5nLTAy
Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteWUtY2NhbXAtbXctdG9wby15YW5n
LTAyPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+
VGhleSBjdXJyZW50bHkgZGVmaW5lOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgYXZhaWxhYmlsaXR5IHs8
YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHlwZSBkZWNpbWFsNjQgezxi
cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmcmFjdGlv
bi1kaWdpdHMgNDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgcmFuZ2UgJnF1b3Q7MC4uOTkuOTk5OSZxdW90Ozs8YnI+DQombmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgfTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBkZXNjcmlwdGlvbiAmcXVvdDtBdmFpbGFiaWxpdHkgbGV2ZWwgb2YgdGhlIGxpbmsmcXVvdDs7
PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LSBYdWZl
bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh
bmc9IkVOLVVTIj5PbiBTdW4sIE5vdiA0LCAyMDE4IGF0IDc6MDcgQU0gQmFsw6F6cyBMZW5neWVs
ICZsdDs8YSBocmVmPSJtYWlsdG86YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tIj5iYWxhenMu
bGVuZ3llbEBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp
ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44
cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiYjNDM7
MSB0byBwZXJjZW50YWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO
LVVTIj5CYWxhenM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIDIwMTguIDExLiAwMy4gMzo0NCwgWHVmZW5nIExp
dSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVtZW1iZXIgdGhhdCBzb21l
IGRyYWZ0IGFza2VkIGZvciBhIHR5cGUgb2YgcGVyY2VudGFnZSB2YWx1ZSB0byB0aGUgbmVhcmVz
dCBodW5kcmVkdGguIFdvbmRlcmluZyBpZiBpdCBjYW4gYmUgcHV0IGluLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9
IkVOLVVTIj4tIFh1ZmVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n
PSJFTi1VUyI+T24gRnJpLCBOb3YgMiwgMjAxOCBhdCAxMTozOSBBTSB0b20gcGV0Y2ggJmx0Ozxh
IGhyZWY9Im1haWx0bzppZXRmY0BidGNvbm5lY3QuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWV0ZmNA
YnRjb25uZWN0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND
Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn
aW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4t
LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS08YnI+DQpGcm9tOiAmcXVvdDtKdWVyZ2VuIFNjaG9l
bndhZWxkZXImcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2Jz
LXVuaXZlcnNpdHkuZGUiIHRhcmdldD0iX2JsYW5rIj5qLnNjaG9lbndhZWxkZXJAamFjb2JzLXVu
aXZlcnNpdHkuZGU8L2E+Jmd0Ozxicj4NClRvOiAmcXVvdDtLZW50IFdhdHNlbiZxdW90OyAmbHQ7
PGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVuaXBlci4ubmV0IiB0YXJnZXQ9Il9ibGFuayI+a3dh
dHNlbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7PGJyPg0KQ2M6ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0
bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPiZndDs8YnI+
DQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDMwLCAyMDE4IDEwOjE0IEFNPGJyPg0KPGJyPg0KJmd0
OyBPbiBUdWUsIE9jdCAzMCwgMjAxOCBhdCAxMjowNToxN0FNICYjNDM7MDAwMCwgS2VudCBXYXRz
ZW4gd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IEluIGFkZGl0
aW9uLCBpdCBtaWdodCBiZSBnb29kIHRvIGludHJvZHVjZSBbaW5ldD9dIHR5cGVzIGZvciBSRkM8
YnI+DQo1MzIyPGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7IChJbnRlcm5ldCBNZXNzYWdlIEZvcm1h
dCkgaW5jbHVkaW5nIHBlcmhhcHM6PGJyPg0KJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAm
Z3Q7ICZndDsmZ3Q7Jm5ic3A7ICZuYnNwOy0gZW1haWwtYWRkcmVzcyZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAoYWRkci1zcGVjLCBwZXIgU2VjdGlvbiAzLjQuMSk8YnI+DQomZ3Q7ICZndDsg
Jmd0OyZndDsmbmJzcDsgJm5ic3A7LSBuYW1lZC1lbWFpbC1hZGRyZXNzJm5ic3A7IChuYW1lLWFk
ZHIsIHBlciBTZWN0aW9uIDMuNCk8YnI+DQomZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZn
dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFdoZXJlIGFyZSB0aGVzZSB1c2VkPyBPciBoYXZl
IHRoZXNlIGFscmVhZHkgYmVlbiB1c2VkIHNvbWV3aGVyZT88YnI+DQomZ3Q7ICZndDs8YnI+DQom
Z3Q7ICZndDsgSSdtIHVuYXdhcmUgb2YgdGhlc2UgZXZlciBoYXZpbmcgYmVlbiB1c2VkIGJlZm9y
ZS4mbmJzcDsgSSBhbSB3b3JraW5nIG9uPGJyPg0KYSBwcml2YXRlIG1vZHVsZSBmb3Igd2hpY2gg
SSB3YW50IHRvIGNvbmZpZ3VyZSBhbiBlbWFpbCBhZGRyZXNzLiZuYnNwOyBBZnRlcjxicj4NCnNv
bWUgc2VhcmNoaW5nLCBJIGNvbmNsdWRlZCB0aGF0IG5vIHN1Y2ggdHlwZXMgaGF2ZSBiZWVuIGRl
ZmluZWQsIGFuZDxicj4NCnRodXMgdGhvdWdodCB0aGF0IHRoZXkgbWlnaHQgYmUgZ29vZCBjYW5k
aWRhdGVzIGZvciBhZGRpdGlvbi48YnI+DQo8YnI+DQo8YnI+DQpXZSBjb3VsZCBkZWZpbmVkIGEg
dXNlci1uYW1lLCBvZiB0aGUgZm9ybSBsb2NhbHBhcnRAZG9tYWlucGFydCBhcyBpczxicj4NCndp
ZGVseSB1c2VkIHRvIGlkZW50aWZ5IGEgdXNlciBpbiBvcGVyYXRpb25zIGJ1dCB3aGljaCBkb2Vz
IG5vdCwgaW4gbXk8YnI+DQpleHBlcmllbmNlLCBvd2UgYW55dGhpbmcgdG8gaTE4biwganVzdCBh
IHN0cmFpZ2h0Zm9yd2FyZCBjaGFyYWN0ZXIgc2V0Ozxicj4NCnllcyBpdCB3b3VsZCBub3QgYm9p
bCB0aGUgb2NlYW4sIGJ1dCBjb3VsZCBiZSB1c2VmdWwuJm5ic3A7IEkgYW0gc3VycHJpc2VkPGJy
Pg0Kbm90IHRvIGZpbmQgc3VjaCBhIGRlZmluaXRpb24gc29tZXdoZXJlIGluIG91ciA0MCBvciBz
byBORVRDT05GIEktRHMuPGJyPg0KPGJyPg0KVG9tIFBldGNoPGJyPg0KPGJyPg0KPGJyPg0KPGJy
Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsg
SXQgd291bGQgYmUgZ29vZCB0byBoYXZlIHN0cm9uZyB1c2UgY2FzZXMuIEkgZmVhciB0aGF0IGRl
ZmluaW5nIHRoaXM8YnI+DQomZ3Q7IHR5cGUgd29uJ3QgYmUgZWFzeSBnaXZlbiB0aGF0IHdlIGFs
c28gaGF2ZSBpbnRlcm5hdGlvbmFsaXplZCBlbWFpbDxicj4NCiZndDsgYWRkcmVzc2VzIChSRkMg
NjUzMCBwcm92aWRlcyBhbiBvdmVydmlldykgYW5kIHdlIG1pZ2h0IGhhdmUgdG8gY3JlYXRlPGJy
Pg0KJmd0OyBhIHVuaW9uIG9mIFJGQyA1MzIyIGFkZHJlc3NlcyBhbmQgJnF1b3Q7U01UUFVURjgg
KGNvbXBsaWFudCkgYWRkcmVzc2VzJnF1b3Q7Ljxicj4NCiZndDs8YnI+DQomZ3Q7IC9qczxicj4N
CiZndDs8YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXImbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0phY29icyBVbml2ZXJzaXR5IEJyZW1l
biBnR21iSDxicj4NCiZndDsgUGhvbmU6ICYjNDM7NDkgNDIxIDIwMCAzNTg3Jm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJt
YW55PGJyPg0KJmd0OyBGYXg6Jm5ic3A7ICZuYnNwOyYjNDM7NDkgNDIxIDIwMCAzMTAzJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDs8YSBocmVmPSJodHRwczovL3d3dy5qYWNv
YnMtdW5pdmVyc2l0eS5kZS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5qYWNvYnMtdW5p
dmVyc2l0eS5kZS88L2E+Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBuZXRtb2QgbWFpbGluZyBs
aXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9i
bGFuayI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48YnI+DQo8YnI+DQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldG1vZCBt
YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9
Il9ibGFuayI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs
YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5n
PSJFTi1VUyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiPm5ldG1vZCBt
YWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t
VVMiPjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRt
b2RAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkVOLVVTIj48YSBocmVmPSJodHRwczovL3d3dy4uaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u
ZXRtb2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL25ldG1vZDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxw
cmU+PHNwYW4gbGFuZz0iRU4tVVMiPi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJFTi1VUyI+QmFsYXpzIExlbmd5ZWwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRXJpY3Nz
b24gSHVuZ2FyeSBMdGQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9
IkVOLVVTIj5TZW5pb3IgU3BlY2lhbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48
c3BhbiBsYW5nPSJFTi1VUyI+TW9iaWxlOiAmIzQzOzM2LTcwLTMzMC03OTA5Jm5ic3A7Jm5ic3A7
ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwO2VtYWlsOiA8YSBocmVmPSJtYWlsdG86QmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24u
Y29tIiB0YXJnZXQ9Il9ibGFuayI+QmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tPC9hPiA8bzpw
PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_B8F9A780D330094D99AF023C5877DABA9B0FC256nkgeml513mbschi_--


From nobody Mon Nov  5 18:12:11 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 8B4D01294D0; Mon,  5 Nov 2018 18:12:04 -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.87.3
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netmod@ietf.org
Message-ID: <154147032450.4217.6823859263547481037@ietfa.amsl.com>
Date: Mon, 05 Nov 2018 18:12:04 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-yang-instance-file-format-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 02:12:05 -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-00.txt
	Pages           : 14
	Date            : 2018-11-04

Abstract:
   There is a need to document data defined in YANG models without the
   need to fetch it from a live YANG server.  Data is often needed
   already in design time or needed by groups that do not have a live
   running YANG server available.  This document specifies a standard
   file format for YANG Based Instance data, that is data that could be
   stored in a datastore and whose syntax and semantics is defined by
   YANG models.  Most important use cases foreseen include documenting
   server capabilities, factory-default settings, or vendor provided
   default configurations.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-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-00
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format-00


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Nov  5 18:21: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 B08F01294D0 for ; Mon,  5 Nov 2018 18:21:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PjYX3y7nsmNE for ; Mon,  5 Nov 2018 18:21: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 884AD12F295 for ; Mon,  5 Nov 2018 18:21:47 -0800 (PST)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id C8998A0CCC77C; Tue,  6 Nov 2018 02:21:44 +0000 (GMT)
Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 6 Nov 2018 02:21:45 +0000
Received: from DGGEMM528-MBX.china.huawei.com ([169.254.8.232]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0415.000; Tue, 6 Nov 2018 10:21:33 +0800
From: "Yemin (Amy)" 
To: Qin Wu , Xufeng Liu , "balazs.lengyel@ericsson.com" 
CC: NETMOD WG 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AdR1b1B75pZToCjlLEK5aT+9YAPiFwAB1JzU
Date: Tue, 6 Nov 2018 02:21:33 +0000
Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461FCFA7803B@DGGEMM528-MBX.china.huawei.com>
References: 
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.126.171.236]
Content-Type: multipart/alternative; boundary="_000_9C5FD3EFA72E1740A3D41BADDE0B461FCFA7803BDGGEMM528MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 02:21:51 -0000

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

SWYgdGhlIHBlcmNlbnRhZ2UgaXMgZGVmaW5lZCBhcyBmb2xsb3dpbmcsIGFzIGEgYXV0aG9yIG9m
IGRyYWZ0LXllLWNjYW1wLW13LXRvcG8teWFuZy0wMiwgd2Ugd2lsbCBiZSBoYXBweSB0byB1c2Ug
aXQuDQpCdXQgaXQncyBiZXR0ZXIgdG8gaW5jbHVkZSBpbiBSRkM2OTkxYmlzLCBhcyBwZXJjZW50
YWdlIGlzIGEgZ2VuZXJpYyBhbmQgd2lkZWx5IHVzZWQgaXRlbS4NCg0KQlIsDQpBbXkNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IG5ldG1vZCBbbmV0bW9kLWJvdW5j
ZXNAaWV0Zi5vcmddILT6se0gUWluIFd1IFtiaWxsLnd1QGh1YXdlaS5jb21dDQq3osvNyrG85Dog
MjAxOMTqMTHUwjbI1SA5OjI1DQrK1bz+yMs6IFh1ZmVuZyBMaXU7IGJhbGF6cy5sZW5neWVsQGVy
aWNzc29uLmNvbQ0Ks63LzTogTkVUTU9EIFdHDQrW98ziOiBSZTogW25ldG1vZF0gZm9yIGEgZnV0
dXJlIHJmYzY5OTFiaXMNCg0KDQpBbm90aGVyIGNhc2Ugd291bGQgYmUgOg0KDQoNCqGwDQoNCnR5
cGVkZWYgcGVyY2VudGFnZSB7DQoNCiAgICAgIHR5cGUgZGVjaW1hbDY0IHsNCg0KICAgICAgICAg
ZnJhY3Rpb24tZGlnaXRzIDU7DQoNCiAgICAgICAgIHJhbmdlICIwLi4xMDAiOw0KDQogICAgIH0N
Cg0KICAgZGVzY3JpcHRpb24gIlBlcmNlbnRhZ2UuIjsNCiAgIH0NCqGxDQpXaGljaCBpcyBkZWZp
bmVkIGlldGYtY29ubmVjdGlvbmxlc3Mtb2FtLnlhbmcgbW9kdWxlLg0KDQotUWluDQq3orz+yMs6
IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFh1ZmVuZyBMaXUN
Creiy83KsbzkOiAyMDE4xOoxMdTCNsjVIDM6NDkNCsrVvP7IyzogYmFsYXpzLmxlbmd5ZWxAZXJp
Y3Nzb24uY29tDQqzrcvNOiBORVRNT0QgV0cgPG5ldG1vZEBpZXRmLm9yZz4NCtb3zOI6IFJlOiBb
bmV0bW9kXSBmb3IgYSBmdXR1cmUgcmZjNjk5MWJpcw0KDQpUaGUgZHJhZnQgdGhhdCBhc2tlZCBm
b3IgdGhlIHBlcmNlbnRhZ2UgdHlwZSBpczogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LXllLWNjYW1wLW13LXRvcG8teWFuZy0wMg0KDQpUaGV5IGN1cnJlbnRseSBkZWZpbmU6DQoN
CiAgICAgICAgICAgICAgbGVhZiBhdmFpbGFiaWxpdHkgew0KICAgICAgICAgICAgICAgIHR5cGUg
ZGVjaW1hbDY0IHsNCiAgICAgICAgICAgICAgICAgIGZyYWN0aW9uLWRpZ2l0cyA0Ow0KICAgICAg
ICAgICAgICAgICAgcmFuZ2UgIjAuLjk5Ljk5OTkiOw0KICAgICAgICAgICAgICAgIH0NCiAgICAg
ICAgICAgICAgICBkZXNjcmlwdGlvbiAiQXZhaWxhYmlsaXR5IGxldmVsIG9mIHRoZSBsaW5rIjsN
CiAgICAgICAgICAgICAgfQ0KDQpUaGFua3MsDQotIFh1ZmVuZw0KDQpPbiBTdW4sIE5vdiA0LCAy
MDE4IGF0IDc6MDcgQU0gQmFsqKJ6cyBMZW5neWVsIDxiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5j
b208bWFpbHRvOmJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KDQorMSB0byBw
ZXJjZW50YWdlLg0KDQpCYWxhenMNCk9uIDIwMTguIDExLiAwMy4gMzo0NCwgWHVmZW5nIExpdSB3
cm90ZToNClJlbWVtYmVyIHRoYXQgc29tZSBkcmFmdCBhc2tlZCBmb3IgYSB0eXBlIG9mIHBlcmNl
bnRhZ2UgdmFsdWUgdG8gdGhlIG5lYXJlc3QgaHVuZHJlZHRoLiBXb25kZXJpbmcgaWYgaXQgY2Fu
IGJlIHB1dCBpbi4NCg0KVGhhbmtzLA0KLSBYdWZlbmcNCg0KT24gRnJpLCBOb3YgMiwgMjAxOCBh
dCAxMTozOSBBTSB0b20gcGV0Y2ggPGlldGZjQGJ0Y29ubmVjdC5jb208bWFpbHRvOmlldGZjQGJ0
Y29ubmVjdC5jb20+PiB3cm90ZToNCi0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTog
Ikp1ZXJnZW4gU2Nob2Vud2FlbGRlciIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0
eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4NClRvOiAi
S2VudCBXYXRzZW4iIDxrd2F0c2VuQGp1bmlwZXIubmV0PG1haWx0bzprd2F0c2VuQGp1bmlwZXIu
Lm5ldD4+DQpDYzogPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NClNl
bnQ6IFR1ZXNkYXksIE9jdG9iZXIgMzAsIDIwMTggMTA6MTQgQU0NCg0KPiBPbiBUdWUsIE9jdCAz
MCwgMjAxOCBhdCAxMjowNToxN0FNICswMDAwLCBLZW50IFdhdHNlbiB3cm90ZToNCj4gPg0KPiA+
ID4+IEluIGFkZGl0aW9uLCBpdCBtaWdodCBiZSBnb29kIHRvIGludHJvZHVjZSBbaW5ldD9dIHR5
cGVzIGZvciBSRkMNCjUzMjINCj4gPiA+PiAoSW50ZXJuZXQgTWVzc2FnZSBGb3JtYXQpIGluY2x1
ZGluZyBwZXJoYXBzOg0KPiA+ID4+DQo+ID4gPj4gICAtIGVtYWlsLWFkZHJlc3MgICAgICAgIChh
ZGRyLXNwZWMsIHBlciBTZWN0aW9uIDMuNC4xKQ0KPiA+ID4+ICAgLSBuYW1lZC1lbWFpbC1hZGRy
ZXNzICAobmFtZS1hZGRyLCBwZXIgU2VjdGlvbiAzLjQpDQo+ID4gPj4NCj4gPiA+DQo+ID4gPiBX
aGVyZSBhcmUgdGhlc2UgdXNlZD8gT3IgaGF2ZSB0aGVzZSBhbHJlYWR5IGJlZW4gdXNlZCBzb21l
d2hlcmU/DQo+ID4NCj4gPiBJJ20gdW5hd2FyZSBvZiB0aGVzZSBldmVyIGhhdmluZyBiZWVuIHVz
ZWQgYmVmb3JlLiAgSSBhbSB3b3JraW5nIG9uDQphIHByaXZhdGUgbW9kdWxlIGZvciB3aGljaCBJ
IHdhbnQgdG8gY29uZmlndXJlIGFuIGVtYWlsIGFkZHJlc3MuICBBZnRlcg0Kc29tZSBzZWFyY2hp
bmcsIEkgY29uY2x1ZGVkIHRoYXQgbm8gc3VjaCB0eXBlcyBoYXZlIGJlZW4gZGVmaW5lZCwgYW5k
DQp0aHVzIHRob3VnaHQgdGhhdCB0aGV5IG1pZ2h0IGJlIGdvb2QgY2FuZGlkYXRlcyBmb3IgYWRk
aXRpb24uDQoNCg0KV2UgY291bGQgZGVmaW5lZCBhIHVzZXItbmFtZSwgb2YgdGhlIGZvcm0gbG9j
YWxwYXJ0QGRvbWFpbnBhcnQgYXMgaXMNCndpZGVseSB1c2VkIHRvIGlkZW50aWZ5IGEgdXNlciBp
biBvcGVyYXRpb25zIGJ1dCB3aGljaCBkb2VzIG5vdCwgaW4gbXkNCmV4cGVyaWVuY2UsIG93ZSBh
bnl0aGluZyB0byBpMThuLCBqdXN0IGEgc3RyYWlnaHRmb3J3YXJkIGNoYXJhY3RlciBzZXQ7DQp5
ZXMgaXQgd291bGQgbm90IGJvaWwgdGhlIG9jZWFuLCBidXQgY291bGQgYmUgdXNlZnVsLiAgSSBh
bSBzdXJwcmlzZWQNCm5vdCB0byBmaW5kIHN1Y2ggYSBkZWZpbml0aW9uIHNvbWV3aGVyZSBpbiBv
dXIgNDAgb3Igc28gTkVUQ09ORiBJLURzLg0KDQpUb20gUGV0Y2gNCg0KDQoNCg0KDQoNCg0KPiA+
DQo+DQo+IEl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBzdHJvbmcgdXNlIGNhc2VzLiBJIGZlYXIg
dGhhdCBkZWZpbmluZyB0aGlzDQo+IHR5cGUgd29uJ3QgYmUgZWFzeSBnaXZlbiB0aGF0IHdlIGFs
c28gaGF2ZSBpbnRlcm5hdGlvbmFsaXplZCBlbWFpbA0KPiBhZGRyZXNzZXMgKFJGQyA2NTMwIHBy
b3ZpZGVzIGFuIG92ZXJ2aWV3KSBhbmQgd2UgbWlnaHQgaGF2ZSB0byBjcmVhdGUNCj4gYSB1bmlv
biBvZiBSRkMgNTMyMiBhZGRyZXNzZXMgYW5kICJTTVRQVVRGOCAoY29tcGxpYW50KSBhZGRyZXNz
ZXMiLg0KPg0KPiAvanMNCj4NCj4gLS0NCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAg
ICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1
ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPiBGYXg6
ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0
eS5kZS8+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRt
b2RAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0
bW9kDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpu
ZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9y
Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KbmV0bW9kIG1h
aWxpbmcgbGlzdA0KDQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8VXJsQmxvY2tlZEVy
cm9yLmFzcHg+DQoNCi0tDQoNCkJhbGF6cyBMZW5neWVsICAgICAgICAgICAgICAgICAgICAgICBF
cmljc3NvbiBIdW5nYXJ5IEx0ZC4NCg0KU2VuaW9yIFNwZWNpYWxpc3QNCg0KTW9iaWxlOiArMzYt
NzAtMzMwLTc5MDkgICAgICAgICAgICAgIGVtYWlsOiBCYWxhenMuTGVuZ3llbEBlcmljc3Nvbi5j
b208bWFpbHRvOkJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbT4NCg==

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








If the percentage is defin=
ed as following, as a author of draft-ye-ccamp-mw-topo-yang-02,
 we will be happy to use it. 

But it=
's better to include in RFC6991bis, as percentage is a generic and widely u=
sed item. 







BR,


Amy







=B7=A2=BC=FE=C8=CB: netmod [netmod-bounces@ietf.org] =B4=FA=B1=ED Qin Wu [bill.wu@huawei.com=
]

=B7=A2=CB=CD=CA=B1=BC=E4: 2018=C4=EA11=D4=C26=C8=D5 9:25

=CA=D5=BC=FE=C8=CB: Xufeng Liu; balazs.lengyel@ericsson.com

=B3=AD=CB=CD: NETMOD WG

=D6=F7=CC=E2: Re: [netmod] for a future rfc6991bis














Ano=
ther case would be :


 

=A1=B0


typedef percentag=
e {


   =
;   type decimal64 {


   =
;      fraction-digits 5;


   =
;      range "0..100";


   =
;  }


   desc=
ription "Percentage.";


   }


=A1=B1


Which is defined iet=
f-connectionless-oam.yang module.


 


-Qin


=B7=A2=BC=FE=C8=CB: netmod [ma=
ilto:netmod-bounces@ietf.org]
=B4=FA=B1=ED 
Xufeng Liu

=B7=A2=CB=CD=CA=B1=BC=E4: 2018=C4=EA11=D4=C26<=
/span>=C8=D5
 3:49

=CA=D5=BC=FE=C8=CB: balazs.lengyel@ericsson.com

=B3=AD=CB=CD: NETMOD WG <netmod@ietf.org>

=D6=F7=CC=E2: Re: [netmod] for a future rfc6991bis


 










The draft that asked for the pe=
rcentage type is:

https://tools.ietf.org/html/draft-ye-ccamp-mw-topo-yang-02






 






They currently define:





 






     &=
nbsp;        leaf availability {

            &nb=
sp;   type decimal64 {

            &nb=
sp;     fraction-digits 4;

            &nb=
sp;     range "0..99.9999";

            &nb=
sp;   }

            &nb=
sp;   description "Availability level of the link";

            &nb=
sp; }






 






Thanks,






- Xufeng










 






On Sun, Nov 4, 2018 at 7:07 AM =
Bal=A8=A2zs Lengyel <balazs.lengyel@ericsson.com&g=
t; wrote:








+1 to percentage.


Balazs




On 2018. 11. 03. 3:44, Xufeng L=
iu wrote:










Remember that some draft asked =
for a type of percentage value to the nearest hundredth. Wondering if it ca=
n be put in.






 






Thanks,






- Xufeng






 






On Fri, Nov 2, 2018 at 11:39 AM=
 tom petch <ietfc@btconnect.com> wrote:






---- Original Message -----

From: "Juergen Schoenwaelder" <j.sc=
hoenwaelder@jacobs-university.de>

To: "Kent Watsen" <kwatsen@juniper.net>

Cc: <netmod@ietf.org>

Sent: Tuesday, October 30, 2018 10:14 AM



> On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen wrote:

> >

> > >> In addition, it might be good to introduce [inet?] types=
 for RFC

5322

> > >> (Internet Message Format) including perhaps:

> > >>

> > >>   - email-address        (=
addr-spec, per Section 3.4.1)

> > >>   - named-email-address  (name-addr, per =
Section 3.4)

> > >>

> > >

> > > Where are these used? Or have these already been used somewh=
ere?

> >

> > I'm unaware of these ever having been used before.  I am wor=
king on

a private module for which I want to configure an email address.  Afte=
r

some searching, I concluded that no such types have been defined, and

thus thought that they might be good candidates for addition.





We could defined a user-name, of the form localpart@domainpart as is

widely used to identify a user in operations but which does not, in my

experience, owe anything to i18n, just a straightforward character set;

yes it would not boil the ocean, but could be useful.  I am surprised<=
br>
not to find such a definition somewhere in our 40 or so NETCONF I-Ds.



Tom Petch















> >

>

> It would be good to have strong use cases. I fear that defining this
> type won't be easy given that we also have internationalized email

> addresses (RFC 6530 provides an overview) and we might have to create<=
br>
> a union of RFC 5322 addresses and "SMTPUTF8 (compliant) addresses=
".

>

> /js

>

> --

> Juergen Schoenwaelder           Jacobs U=
niversity Bremen gGmbH

> Phone: +49 421 200 3587         Campus Ri=
ng 1 | 28759 Bremen | Germany

> Fax:   +49 421 200 3103         =
;<https://www.jacobs-university.de/>

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

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



_______________________________________________

netmod mailing list

netmod@ietf.org

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






 


_______________________________________________


netmod mailing list


netmod@ietf.org


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




-- 


Balazs Lengyel      =
;            &n=
bsp;    Ericsson Hungary Ltd.


Senior Specialist


Mobile: +36-70-330-7909    &nb=
sp;         email: Balazs.Lengyel@ericsson.com 




















--_000_9C5FD3EFA72E1740A3D41BADDE0B461FCFA7803BDGGEMM528MBXchi_--


From nobody Mon Nov  5 18:55:05 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6E3130FAE for ; Mon,  5 Nov 2018 18:54:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.067
X-Spam-Level: 
X-Spam-Status: No, score=-3.067 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=HZGI3Qu3; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ePMvEPSl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUtqpTnVR3Gk for ; Mon,  5 Nov 2018 18:54:56 -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 E4E9C130F8D for ; Mon,  5 Nov 2018 18:54:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1541472893; x=1544064893; 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=Oec19RdXh/ft+UFtI36ifV4cJ6NXG3YoSo9uxzBfNWM=; b=HZGI3Qu3JRUiCv5lcHZ1Am4YWR4kXXMNC0hF5Az1vmu/KrmFYalHu+DkQvccQ79s jqA5bFPLooV2B9b2wWBJKyLtDcbiYz7uM7kdpqOOVVngzCfYWoDxM72RseU+F09O +6z/y6whqUfFUy2TkI/wFNlcvWBx33U9HL6r9LZnk74=;
X-AuditID: c1b4fb25-ad3ff7000000414e-f6-5be1027dfc22
Received: from ESESBMB501.ericsson.se (Unknown_Domain [153.88.183.114]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 6B.80.16718.D7201EB5; Tue,  6 Nov 2018 03:54:53 +0100 (CET)
Received: from ESESBMR501.ericsson.se (153.88.183.129) by ESESBMB501.ericsson.se (153.88.183.184) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 6 Nov 2018 03:54:53 +0100
Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMR501.ericsson.se (153.88.183.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 6 Nov 2018 03:54:53 +0100
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 6 Nov 2018 03:54:53 +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=jT8G9q9FZGeEOmACIKbkbterrT0TLK+rRTtt1ZR4kBk=; b=ePMvEPSl4HzcIPV+JuSKapD62VqArHPK2eZUlcfh7FjNXv68oaeJLUDM6kvVpT5ITaklqGy7Kz9/HrhozY5XCJ8jkY8bVYj9zxAcyoB+2rGCDjQAYUAFHUwD2y99vZTjq+ds/384IeRXfUSKb2cf+K3gIZ9eJoNKYw9Hux+luwE=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2318.eurprd07.prod.outlook.com (10.168.137.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.15; Tue, 6 Nov 2018 02:54:52 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::4e4:6761:27d5:5bd%11]) with mapi id 15.20.1294.032; Tue, 6 Nov 2018 02:54:52 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: "netmod@ietf.org" 
Thread-Topic: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt
Thread-Index: AQHUdXYipV5hG5p2iUu/shgjxloKo6VCDTMA
Date: Tue, 6 Nov 2018 02:54:52 +0000
Message-ID: <07b9bcea-72e3-9986-7d42-303c4797f13a@ericsson.com>
References: <154147032474.4217.10743411700898817061.idtracker@ietfa.amsl.com>
In-Reply-To: <154147032474.4217.10743411700898817061.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [192.176.1.82]
x-forwarded-message-id: <154147032474.4217.10743411700898817061.idtracker@ietfa.amsl.com>
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
x-clientproxiedby: AM6PR02CA0007.eurprd02.prod.outlook.com (2603:10a6:20b:6e::20) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2318; 6:rv+ZnM2spyclt27sT1yfDOkVyjs3s/WvmZLZwBO6sbjaV2Ac0MPT30Vbe2e44nUqKpZo6V7hT871s/kUAszM1LfWJuFmGXYktXKgJ+TG7gaTaOKwTWpAirhqwgB9nHnT6Fz+OLYbodaKMVlkfSR97z0LHgT+Qp+BI3mzpTx2od6sOkd0e6Ktarwg0zO87YuXBT5OvDl2jMlEk5Qat3lLrVqhQRug3x19JaMhIQkt2GL6Orn2c5x3Q7dSnCtJo190j9axzhpNPk61LmaTvSQg5pa6KYV3NXJg1C6sbCv4CCgytQI8YxMvTLYzTNyJTYsO25uBE3sXgxHQLjBqOdcw0dNvHRAB60WmLw/i4DKwlUBbCsRPy+Q1mr6wxsx+cwtWxu+ONk+pv20vE67K4PsRzMsS2uPvJq3TFPZ+RKD6uBFbzSS/keRyC8jN2uSyKzVVe7D7SUx0H38/8Gl5QnrRbA==; 5:uRQSee+oeyzJVy/QMT8drLMOScesUoriW1866G0pJTsKEOL7PkpLoSnNpliSUpFKW5EdzL6oTTHGMjGOT19yjj3PrexF6NW3fXZbw+Ct12MhIr2hUfKsywUnCR+Mhs75ksL0I7ChyT8iGmn+neWxR+LXg8hFs2QrWn6cLZFZ33A=; 7:sJgfjjSE/KX9f75++mzGRkVX1dxbo9jxJQS21wkGmR3D65G9rHlNN7OoDnt5QZZH/T7I6RbgwRBOAYbHDA+6jwHKAY7/117SriVGay9Uo6EMHphcreUAkBCHAv5VXP7C1nQhr0rKdr6SJ/mIlHNxHQ==
x-ms-office365-filtering-correlation-id: a693f83b-fd56-4383-365a-08d643933847
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2318; 
x-ms-traffictypediagnostic: VI1PR0701MB2318:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014)(248295561703944)(37575265505322)(120809045254105)(158342451672863);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(4983020)(52105095)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2318; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2318; 
x-forefront-prvs: 0848C1A6AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(39860400002)(396003)(136003)(252514010)(199004)(189003)(52116002)(31696002)(85202003)(14444005)(85182001)(186003)(99936001)(31686004)(105586002)(106356001)(76176011)(58126008)(2501003)(65806001)(65956001)(66066001)(316002)(2351001)(7736002)(5660300001)(256004)(6916009)(99286004)(65826007)(14454004)(6486002)(26005)(5640700003)(6436002)(8676002)(81166006)(1730700003)(229853002)(81156014)(86362001)(68736007)(8936002)(2900100001)(966005)(478600001)(2906002)(15650500001)(53936002)(6116002)(2473003)(6512007)(6306002)(236005)(54896002)(3846002)(71200400001)(606006)(446003)(486006)(386003)(11346002)(97736004)(102836004)(476003)(2616005)(36756003)(25786009)(6506007)(3260700006)(71190400001)(64126003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2318; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: C684wqH17Z33yiY+ay+Mj+goVo6Z1Oo+RMhpdPOjo7b+20PqCMKSlCJjEgVfw5TtronjbDu4G3uY7unujnNUkhIVU0mWx5X96SoxGi/RxrMgCTHfCBKSFzxD0BHcvaKK6O9q7v57RnuC0ZUtlwW65QAecwrh7w7OnxaE9LJZgIcde83CdWCTn4VQNdSPKiF1DkKCEQn3TCiQos1NX2P3ePlgyQoI0k3LZrkvcy56lhaBbU1o9HrK6JekFJKUX3q4dg8SgOFs053FsalYwJq9ksrfycOJ2wFS9JDb5lXKZLdBT0Haq9yi9kv0wQ+CP2Ck45yN9BufnxrdGovId6ljYibfQORYCT5hWsz02nFwGAA=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050504020702010909080501"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a693f83b-fd56-4383-365a-08d643933847
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2018 02:54:52.1679 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2318
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSfUhTYRTGe+/urnej0duaeZiIefMD1Kw0KyiysLICTTSilLKlF5V02p2K lomKkh8lGoYfWGYzwRYu1DJxq9QKVCQ/irIkNltCGoqhmJbW3a5S/fd7zvO85z0HDi2SD4iV dLw6heXUqgSGkpJVp9q4LVcIc+Q2k37n7trBHPF+dKS+foEIRRHSvTFsQnway23dd04ap9W1 iZOXw9Lr9PNENtIeLUISGvAOaPoyh4qQlJbjFwhGbl8nBTGHYLK//q+o6SgTCUJLwMysnrAK EpeKoCJPt+JUEFDwuGpFjCHoeTOArN9Q+CBcnXpGWFmBPaCqXU9ZeQOOgpt6CynUoyDPNC0W 2BdGyw22DIldocZksNVlOABKnufYWVmOgyHne5OtpwSHQN0Noy2D8EaY731gq4uwA3yw1BLC qgowD/ZRAtvD18/LfJ7meRN0T8gEPA21P7KsaI/PQGdugHUTwJUIJowLdkL3s2D4VLDSxRv6 31mQwE4wVFuMhAfvKZiuyycFIxhulTWvGMMIPppfo9XXxt5fVCnyq/5n1Go+J8KFCJZmGlG1 bef10FNlIav5qUTYHRrymf/zVvaChrpJkcB7oHKxkxLYBcqLzXYC+8PkyxkksB80NC1Rd5D0 PrLXsJrzibG+fj4sFx+t0SSpfdRsSjPib6uz9afbEzT87UAXwjRi1sqy5kyRcrEqTZOR2IVc +T5jD3UDSEmqk9Qso5AxFG/LYlQZl1guKYpLTWA1XciRJhkHmXlXS4Qcx6pS2Assm8xyqy5B S5TZ6GJ0eGTioWvEgJfi5CNFRkkBng30WHZpdVww0mvE/peNnk78kTmXDMVmLseM9JQa9aZX SjdTmGum7tgJ5umiJPxufurhym5t5u+c+RTvcjokzTk0PX3deO7o23A/r5Yl98bIqaDx44GM vPDeTEZfd9nmKZUqqMN/zjA1mdrWzpCaONV2TxGnUf0BOYEmeGMDAAA=
Archived-At: 
Subject: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 02:55:04 -0000

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


  

    
  
  
    
The first WG version of the document is stored. It is the same
      as=C2=A0 draft-lengyel-netmod-yang-instance-data-05 except for the
      change of title.

    

    
Balazs

      

      -------- Forwarded Message --------
      

        
          

            Sub=
ject:
            
            New Version Notification for
              draft-ietf-netmod-yang-instance-file-format-00.txt
          

          

            Dat=
e: 
            Mon, 5 Nov 2018 18:12:04 -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-00.txt

      has been successfully submitted by Balazs Lengyel and posted to
      the

      IETF repository.

      

      Name: draft-ietf-netmod-yang-instance-file-format

      Revision: 00

      Title: YANG Instance Data File Format

      Document date: 2018-11-04

      Group: netmod

      Pages: 14

      URL:
https://www.ie=
tf.org/internet-drafts/draft-ietf-netmod-yang-instance-file-format-00.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-00

      Htmlized:
https://datatracker.=
ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format

      

      

      Abstract:

      There is a need to document data defined in YANG models without
      the

      need to fetch it from a live YANG server. Data is often needed

      already in design time or needed by groups that do not have a live<=
br>
      running YANG server available. This document specifies a standard
      file format for YANG Based Instance data, that is data that could
      be

      stored in a datastore and whose syntax and semantics is defined by<=
br>
      YANG models. Most important use cases foreseen include documenting<=
br>
      server capabilities, factory-default settings, or vendor provided
      default configurations.

      

      

      

      Please note that it may take a couple of minutes from the time of
      submission

      until the htmlized version and diff are available at
      tools.ietf.org.

      

      The IETF Secretariat

      

    

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


  



--------------ms050504020702010909080501
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTEwNjAyNTQ0MFow
LwYJKoZIhvcNAQkEMSIEIORrM2FrVTV5QOSUHJzjQEXnuHwx7HhTM4NINSeLirpPMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAI8MIRRiYABTJAArhKCoNqaVM9yQWiVAV080uIlEZKj9YQhe
7MX2lROOd8Ok/AAyHBUEFCAL8ao89WTtasJJBtUICT1IivIo5Xqro9qPNhoAPM6M45H4TGma
1UlkLNoQngLS3XX7ErEvPpK/6prIuXMXYqa2nVawuLZlll9g8VPiAqcpDe1nXR+u7JAvHEwa
YaY/KhqrmwekVvdBd/KZ0Pkq9kS4GJX+S9sAAHxnWK+gioVKij61QvTG7IpENg+DJKkl9+sb
MCMnVXaRKQlZVd36+TQbmjBqBj/58QW1pc6cumBrBs2Di85GPCr3WOmMTD77rB4EVUGIKWb8
z1T2xx0AAAAAAAA=

--------------ms050504020702010909080501--


From nobody Mon Nov  5 19:05: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 3C8B41276D0 for ; Mon,  5 Nov 2018 19:05:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level: 
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpLvkncLdCuh for ; Mon,  5 Nov 2018 19:05:48 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90B47127148 for ; Mon,  5 Nov 2018 19:05:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8718; q=dns/txt; s=iport; t=1541473548; x=1542683148; h=from:to:subject:date:message-id:mime-version; bh=JT/H8ZKF6RWFcrQ2Iu+vwiqd3HU9r9CjVX0g4uq0mjg=; b=TUywQftPdxuUTHfnU3npNreG8qi6qIogZbnMY83UXH8F2JzPvoEYC2NB ypu/Xmh4/Xe3ZtiMcpSxFuT0AeFqlTpd2ODU9Vk0skyGeM0SdoLA8S0Lv HzC6uNiSR6lJ2DqXLarRDRYqdUl5duovQndDohZKQePzLlz3x2lH8uasc 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BcAAD1A+Fb/5tdJa1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBUwUBAQsBgQ13Zn8yg2yWGZF+hVSBegsBAYUFgzoiNgsNAQMBAQIBAQJ?= =?us-ascii?q?tHQuFZApeAQZEAgQwJwSDNAGBHWSOI5tPgS6FPIR3i3YXgUE/gTgME4pOMYI?= =?us-ascii?q?mAo5ehiqKKgkCgV6PMRiBVY8LiUKNXQIRFIEmJAonJ4EucBU7KgGCQpBYjWO?= =?us-ascii?q?BHwEB?=
X-IronPort-AV: E=Sophos;i="5.54,469,1534809600";  d="scan'208,217";a="259117303"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2018 03:05:47 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id wA635lj2029513 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 6 Nov 2018 03:05:47 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 5 Nov 2018 21:05:46 -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; Mon, 5 Nov 2018 21:05:47 -0600
From: "Reshad Rahman (rrahman)" 
To: "netmod@ietf.org" 
Thread-Topic: Comments on draft-ietf-netmod-yang-data-ext
Thread-Index: AQHUdX2dH7oARRDfakasnfUk5pbqMw==
Date: Tue, 6 Nov 2018 03:05:46 +0000
Message-ID: <9EA0D913-93E8-4321-BCCD-BE6AAB8583A5@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.255.51]
Content-Type: multipart/alternative; boundary="_000_9EA0D91393E84321BCCDBE6AAB8583A5ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: 
Subject: [netmod] Comments on draft-ietf-netmod-yang-data-ext
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 03:05:50 -0000

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

SGksDQoNCg0KICAqICAgSW4gc2VjdGlvbiAyLjIgMXN0IHBhcmFncmFwaCB0aGUgdGV4dCBzYXlz
IOKAnOKApm1vdmVkIHRvIHRoaXMgZG9jdW1lbnQgYW5kIHVwZGF0ZWTigJ0uIEl0IHdvdWxkIGJl
IGNsZWFyZXIgaWYgdGhlcmUgd2FzIGEgbGlzdC9kZXNjcmlwdGlvbiBvZiB3aGF04oCZcyBiZWVu
IHVwZGF0ZWQgaW4gMi4yIG9yIGEgcmVmZXJlbmNlIHRvIGFub3RoZXIgc2VjdGlvbiB3aGVyZSB0
aGUgdXBkYXRlIHRvIFJDIHlhbmctZGF0YSBpcyBkZXNjcmliZWQuDQogICogICBJbiBleGFtcGxl
IGluIEEuMiwgc2hvdWxkIOKAnHlkOmF1Z21lbnQteWFuZy1kYXRhIC9hZGRyZXNzLWJvb2svYWRk
cmVzc+KAnSBjb250YWluIHRoZSBtb2R1bGUgcHJlZml4PyBQOCBoYXMgeWQ6YXVnbWVudC15YW5n
LWRhdGEgL2Zvbzpmb28tY29uIGFuZCB0aGUgZGVzY3JpcHRpb24gbWVudGlvbnMgYWJzb2x1dGUt
c2NoZW1hLW5vZGVpZA0KDQpSZWdhcmRzLA0KUmVzaGFkLg0K

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1
IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws
IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0
b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h
dHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFy
YWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28t
c3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsN
CgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh
bnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt
Y29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k
b3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhU
TUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5
bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7
fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2Ug
V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu
MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u
MTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo5MDQ4
MDI5OTk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0x
MzYwODcxNTI0IC02NTc1ODI4MTAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg
Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ
e21zby1sZXZlbC1zdGFydC1hdDo1Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGli
cmk7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN
Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl
bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt
Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w
Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x
OC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28t
bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s
ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0
ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl
bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87
DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps
ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9
DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z
by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWls
eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0
OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7
DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7
DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVt
YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0
b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6
LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0K
CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K
CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm
dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0K
CXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0
eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp
dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5
XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk
aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl
YWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0K
PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0iZGlzYyI+
DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNv
LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JbiBz
ZWN0aW9uIDIuMiAxPHN1cD5zdDwvc3VwPiBwYXJhZ3JhcGggdGhlIHRleHQgc2F5cyDigJzigKZt
b3ZlZCB0byB0aGlzIGRvY3VtZW50IGFuZCB1cGRhdGVk4oCdLiBJdCB3b3VsZCBiZSBjbGVhcmVy
IGlmIHRoZXJlIHdhcyBhIGxpc3QvZGVzY3JpcHRpb24gb2Ygd2hhdOKAmXMNCiBiZWVuIHVwZGF0
ZWQgaW4gMi4yIG9yIGEgcmVmZXJlbmNlIHRvIGFub3RoZXIgc2VjdGlvbiB3aGVyZSB0aGUgdXBk
YXRlIHRvIFJDIHlhbmctZGF0YSBpcyBkZXNjcmliZWQuPG86cD48L286cD48L3NwYW4+PC9saT48
bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxp
c3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JbiBleGFt
cGxlIGluIEEuMiwgc2hvdWxkIOKAnDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPnlkOmF1Z21lbnQteWFuZy1kYXRhIC9hZGRyZXNz
LWJvb2svYWRkcmVzczwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+4oCdDQog
Y29udGFpbiB0aGUgbW9kdWxlIHByZWZpeD8gUDggaGFzIDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V
UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPnlkOmF1Z21lbnQteWFuZy1k
YXRhIC9mb286Zm9vLWNvbiBhbmQgdGhlIGRlc2NyaXB0aW9uIG1lbnRpb25zIGFic29sdXRlLXNj
aGVtYS1ub2RlaWQNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD48
L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SZWdhcmRzLDxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0Ij5SZXNoYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jv
ZHk+DQo8L2h0bWw+DQo=

--_000_9EA0D91393E84321BCCDBE6AAB8583A5ciscocom_--


From nobody Mon Nov  5 19:25:20 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142A312F295 for ; Mon,  5 Nov 2018 19:25:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level: 
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB9H4wE0yfkA for ; Mon,  5 Nov 2018 19:25:15 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25ACC12D4EA for ; Mon,  5 Nov 2018 19:25:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5664; q=dns/txt; s=iport; t=1541474715; x=1542684315; h=to:references:from:subject:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=pFUB6SGw5ufxr3d7D2RY3E80GHVrLD2r/RnCMuXBQj8=; b=RsrmtQE7KPCH5/O0hMNSRuZY77xmVWWx7fO5K7NFFu9znokTmoXnVQwN a68/4U6w+cowmKxnAvxxb7j9RnnhcMMBkxlPshk5FjIfBCjCieZPLbZ/b 5+Luj0ab92sdhenl91IsaR1pdQzA8edgRTYLzAA4RFJXspOB0nNWSJFw5 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAADCCOFb/51dJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggRmA3wog3aIGI4mly0UgWYNGA2EAUY?= =?us-ascii?q?Cg1EiNA0NAQMBAQIBAQJtHAyFOgEBAQECAQEBIQ8BOwkSCxEDAQIBAgImAgI?= =?us-ascii?q?nKAgGAQwGAgEBgx0BgXkID6lWgS6EMQIMQIU0gQuKaxeBQT+BOIJrgxsBAQI?= =?us-ascii?q?BAYEqARIBCRaDBII1IgKJFSOFPHaFHooqCYZuih0GGIFVTIQ0gnyHD40Iij6?= =?us-ascii?q?BQzhkcU0jFRohgmwJgh4XEohLhVwhMAGLVII+AQE?=
X-IronPort-AV: E=Sophos;i="5.54,470,1534809600"; d="scan'208";a="196952142"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2018 03:25:14 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro4.cisco.com [10.118.87.85]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTP id wA63PBuO003808; Tue, 6 Nov 2018 03:25:12 GMT
To: =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= , "netmod@ietf.org" 
References: <154147032474.4217.10743411700898817061.idtracker@ietfa.amsl.com> <07b9bcea-72e3-9986-7d42-303c4797f13a@ericsson.com>
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDo1cJ0RBADSZSmbmzdRr1CoRWWKmAyu0eaQimaLV1TsZEML/ksLyg6faXrKIA/MWc7M w4FmKkDjaZdFzobzabnKp2QwVadLqi1gYY2WsApKC0rSoqsPx5E847AmwNWXgjXiXORXmnZL mf5PZ2ECOEJC27sji5Nrh9GSw7OPp6c+EE20gMNVrwCgu3iK5vyGQfy0/wX/jcIvP0nHznUD /RvijiKomyaf6F5pibmouFNeuCDHc8lwx2giA/MCZl/nSkI2/UX27sULGNgvKNkVPu/AukXu zW3fIthsJgjQZUoi/BTe9kUP+RL3+RALXXuLv7b3xGRHJ8A1Rpy9H43fkjHZ945YNPrUvJlG LP5PNGBD1xC21X3EGAyywVynDskcA/4qgbJFkVzmPjFJUjq+RW1zw3UIb3bbkskl/wk5qd+M w2EhiSPTbEhJQAQUvqSGFWEGp2ANic7iYLdPXV/O6I1/guRRaY0eK77YkkCjz1snaKYnGSeI GHGwmHb6D+ZHzTqZqr6IssgEIUHjXfgOUTARQbL15nJTVRzDGUiT/65R3c0eSm9lIENsYXJr ZSA8amNsYXJrZUBjaXNjby5jb20+wl8EExECABcFAjyDqGQFCwcKAwQDFQMCAxYCAQIXgAAS CRDN7TXCWm4C3wdlR1BHAAEB5KkAn0kBda/9+uF6RfnDSFS7RExUU9DqAJ4knRckYiSASteC K03QVtEiXblL287ATQQ6NXCeEAQAhIURlK17jmIMdMIuScFU6xK+jkKgVVFrjlRH5vLV2spp jH/uQ57MMGuOcs7PckXCnPjBV8Tm32Tuw+fCyrbc2gt0ouiT/5WWj0EMeAfWew1zBXX2okGf LqS6gucVDS6tcEFN6PmJEmX+tWDcmiqx/xXiSfMVYiLMdlK+YDkMDDsAAwUD/3BWOyfdnBGH Kv28zx+5wq/2vhYnUYCAdVD2ZWCJizQTMbkcxEIKAwtAj6yqKq9ah82nt4VHl5ZejVe47jvR 2nXwJ5VQ9eITuTjTLDw+3qr9lN077VZ32hyb5ULJcW756j9Z3YB2FTANw6KHgChaSVVx9kYJ FlAggraU7mi39/wvwk4EGBECAAYFAjo1cJ4AEgkQze01wlpuAt8HZUdQRwABAQbdAJ9R8SzU Mluu9r93BMv6fAW9j6qTZgCfYcEAqOMJv+3Z+YxLiDtWcCY4Sfo=
Organization: Cisco
Message-ID: <2a796f78-41b7-376c-8f51-215d14cc4e2c@cisco.com>
Date: Mon, 5 Nov 2018 22:25:10 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <07b9bcea-72e3-9986-7d42-303c4797f13a@ericsson.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.118.87.85, rtp-jclarke-nitro4.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 03:25:18 -0000

On 11/5/18 21:54, Balázs Lengyel wrote:
> The first WG version of the document is stored. It is the same as 
> draft-lengyel-netmod-yang-instance-data-05 except for the change of title.

Thanks, Balazs.  Here is an itemized review of this draft.  Thank you
for acknowledging my requirements around augmenting YANG data/structure.
 You will definitely need that when you start to document server
capabilities.

I agree with Lada and Rob that moving the use case examples to an
appendix would make it easier to get to the meat of the document.

===

In your terminology section, you define an instance data set as
essentially a set of instance data.  I might incorporate the text from
your abstract to call instance data, data that is returned from a YANG
server.  This, too, isn't ideal, but I think it's worth being a bit more
descriptive here.

===

You use "YANG Based Instance Data" as something that feels like a term
throughout the document, but you do not define this exactly.

===

Section 2.1.1

s/Capbilites/Capabilities/

s/capabilites/capabilities/g

You say, "While it is good practice to allow a client to query these
capabilities from the live YANG server, that is often not enough."

"Not enough" doesn't sound right.  I would say, "that is sometimes not
possible."  You may mention examples like the server is not currently
available or the code driving the server is not publicly available, etc.

You say that, "Often when a network node is released an associated NMS
is released with it."

I don't know that this coupling happens "often."  I'd say that when new
network element code is released, operators want to understand the
capabilities that come within that new code.  Other NMS/OSS vendors want
to be able to understand the model provided by the new code so they can
adjust their client code.

You go on to say, "Network operators often build their own home-grown
NMS systems that needs to be integrated with a vendor's network node."

Again, the word "often" doesn't resonate with me.  I do agree that there
are NMS vendors that need to understand how to modify their NMS to
support other vendors' network elements and there are some operators
that are building their own NMS/OSS.

===

Section 2.1.2

s/configurationp/configuration/

===

Section 2.1.3

s/Dcomenting/Documenting/

===

Section 3

s/returmed/returned/

s/configuraton/configuration/

You say, "It SHOULD NOT be used if the file is stored in a version
control system (e.g. git) because the change of file names will break
the connection between the different revisions of the file."

I think you should drop this requirement.  I can use "git mv" or create
tags if I want to retain history.  I wouldn't try and legislate what
people do with their VCS.

You use "meta data" in a number of locations.  Might I suggest
"metadata."  I think that is a more common way to write that term.

===

Section 6

With your datastore leaf, if I pull this off of a running YANG server,
serialize it and share it with my customer, why wouldn't I have the
actual datastore from which I retrieved it?  What I'm saying is that
this element may be missing, but if it is, I don't think you can assume
the source datastore for config=true nodes.

s/dtastore/datastore/

s/thats/that's/

s/Formated/Formatted/

===

Section 8

Do you have to register the ".yid" file extension as well?

Thanks.

Joe

> 
> Balazs
> 
> -------- Forwarded Message --------
> Subject: 	New Version Notification for
> draft-ietf-netmod-yang-instance-file-format-00.txt
> Date: 	Mon, 5 Nov 2018 18:12:04 -0800
> From: 	internet-drafts@ietf.org
> To: 	Benoit Claise , Balazs Lengyel
> 
> 
> 
> 
> 
> A new version of I-D, draft-ietf-netmod-yang-instance-file-format-00.txt
> has been successfully submitted by Balazs Lengyel and posted to the
> IETF repository.
> 
> Name: draft-ietf-netmod-yang-instance-file-format
> Revision: 00
> Title: YANG Instance Data File Format
> Document date: 2018-11-04
> Group: netmod
> Pages: 14
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-instance-file-format-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-instance-file-format/
> Htmlized:
> https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format
> 
> 
> Abstract:
> There is a need to document data defined in YANG models without the
> need to fetch it from a live YANG server. Data is often needed
> already in design time or needed by groups that do not have a live
> running YANG server available. This document specifies a standard
> file format for YANG Based Instance data, that is data that could be
> stored in a datastore and whose syntax and semantics is defined by
> YANG models. Most important use cases foreseen include documenting
> server capabilities, factory-default settings, or vendor provided
> default configurations.
> 
> 
> 
> 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
> 
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Mon Nov  5 19:56:00 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAAF130DCC for ; Mon,  5 Nov 2018 19:55:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level: 
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 tZM1NuWToW2d for ; Mon,  5 Nov 2018 19:55:56 -0800 (PST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::723]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA754127333 for ; Mon,  5 Nov 2018 19:55:55 -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=/J4xTyh7EgNQldV7JCRGOXyqmCTJfiU4w4WuKvSKZRQ=; b=UadseSCpxt3qX23H2BvwPuWZ4leiD5Qt3lG0HRfcmj0E81QfyJP45E873fsF4yUnSTp/qfYP9Svd8UZsYthgPxa9XJzi7gqM7R6xES/NjLSoqueBTrwC2WBUWcvkUx4cciRp0Q9PcAclqSkj4U+/a84UlqpxoqyCZA1qEUx09nc=
Received: from VI1PR07MB3981.eurprd07.prod.outlook.com (52.134.28.141) by VI1PR07MB4863.eurprd07.prod.outlook.com (20.177.63.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.31; Tue, 6 Nov 2018 03:55:53 +0000
Received: from VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::a8a1:3ccb:986d:dad3]) by VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::a8a1:3ccb:986d:dad3%5]) with mapi id 15.20.1294.032; Tue, 6 Nov 2018 03:55:53 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: "netmod@ietf.org" 
Thread-Topic: some comments on netmod-base-notification-nmda (validation after commit response, etc)
Thread-Index: AdR1hJbSr1CKgd7cQqKcqrrZWsXXDA==
Date: Tue, 6 Nov 2018 03:55:53 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:67c:1232:144:613e:dfc0:18ea:ee8f]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB4863; 6:IxC8XwxemcrFJzjSiE2RLXsRsDhaOPt1ND1oLb9octqX8AnkP7I9uJZe0RAuR90/sLseElxGr3MQU65vzeiomJ5SNZDot72IKdjkXJHun85tO7aBXJsIQT3GJ3cC/IYmeQWnCFhjBO2JM/B4Hw/cQGc2Ok875ODo1Y3hiQ5PA0m3B/vWd9++UHJ4KRW1VrDJ0JpDlTjRe96ikKtnhALqWn0DqhTnuyTL+SDbjPBcFNNU7Q/ovMZ9swM22N/CyZiv65/qA/ZjK+taWBUdqJvcLe+I1ZklvMmLfkwqkQ9LUXAlBJcFhAJ3mcGXXaT5utGmeDcHkd7aQudPRyB5oDA+wXczWep5HjpNdK7Xp0wxeNUtnHsAPEO2VkPPrnBiJQ6CDm7+akCk1K5kTGaG9vWd/CMIkGEHJgt/fN0+lbCygetSVDNAdVArRyemeAmHuGKVJVTfWeMaLyy6a8QI0jc+yQ==; 5:Dt0Kf6ce4CCRZZvv35TeGF+2h9uSSeA9ZElY3UO6rUKISol5OFFqI1EivQsXei7anL8U8Ds9+R1uW8OeImZoKIfwFBUqDPCiyAeyB/UeEzMA5vv+bMIXbXRS+wFKTYEkxY0rQnP8hPErdgDFTHwFafdjMwPSCfv3FAmTG8JMklU=; 7:AKbTv6/ZIwd+fkjsKsWYOHH13yXon/yj8NMhScWSBVEFCAjE4xcI36DQklX8a4vJvk4q0JS5ijle9nE0ouhqUBa4mT74SlaFyK8+0/nT+SRAnfDukZAjocqNW56fl8y3pz9Q3+rRozjGIwvjibRqlQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: bcc2d3bb-6d71-4028-6d65-08d6439bbf86
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1PR07MB4863; 
x-ms-traffictypediagnostic: VI1PR07MB4863:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(190501279198761)(227612066756510); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231382)(11241501184)(806099)(944501410)(52105095)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB4863; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4863; 
x-forefront-prvs: 0848C1A6AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39860400002)(136003)(376002)(346002)(199004)(189003)(186003)(97736004)(5660300001)(33656002)(25786009)(7110500001)(2906002)(316002)(478600001)(2501003)(7736002)(74316002)(790700001)(15650500001)(2420400007)(6116002)(46003)(10710500007)(476003)(86362001)(7696005)(6346003)(102836004)(6506007)(68736007)(14454004)(486006)(5640700003)(99286004)(105586002)(6436002)(9326002)(55016002)(9686003)(54896002)(6306002)(81156014)(81166006)(1730700003)(8676002)(53936002)(6916009)(256004)(2900100001)(2351001)(71190400001)(71200400001)(106356001)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4863; 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: jagnb/W8Lc6wI0MDQ+UTqaQWs4nuPhl1lwhW4I8xnrU7Y/3al7poh8sZIvt3qB6Wv8sskS4lDlZiaBig1dpd1Wi11BzwvPmAbptJTpWc6DcGnCMXMbi4aIXbxswCZrZLBtMjJZIEJGbit73LU6dH7JW8yDEmL+3E95+Jh/ECm6hJACvarC6J0580BncG7Yj/e957/4BX71LR+QZNW6RLQs9qqrxuSYGwR7vA29QhaoprzZ7hpU/HRyRBidV1ctePIky6ABncnAGQA9njEedR+JFyLfqhXUQ4W+T2GXV3ltdyYvUPjZzVWdoLusKzVxwtSKFBQPFmnHNJmb4wooHgSfTp5ALrazUh/K/FH7mKs+4=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB3981B3CF71B4216217DF41689BCB0VI1PR07MB3981eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bcc2d3bb-6d71-4028-6d65-08d6439bbf86
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2018 03:55:53.0322 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4863
Archived-At: 
Subject: [netmod] some comments on netmod-base-notification-nmda (validation after commit response, etc)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 03:55:59 -0000

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

Hello,

The draft mentions that "It is possible that some configuration could not b=
e applied to  due to either validation issues, or missing reso=
urce etc."

But wouldn't validation errors cause an error response to the commit RPC? I=
'm not clear why there would be validation later in the commit/apply proces=
s that wasn't part of the decision to reply OK/NOK to the commit.

The draft also implies that the process of moving config from running -> in=
tended -> operational is decoupled from the application of a candidate -> r=
unning.
- Do systems reply OK/NOK to a commit before config is moved from running->=
intended->operational ?
- If so, then maybe it isn't correct to have a username in the notification=
s. A specific user/session did the commit, but then if the commit process e=
nds after candidate->running (i.e. the reply happens at that point), then i=
sn't it really the system moving the config from running->intended->operati=
onal?

Jason

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











Hello,


 


The draft mentions that "It is possible that so=
me configuration could not be applied to <operational> due to either =
validation issues, or missing resource etc."


 


But wouldn't validation errors cause an error respon=
se to the commit RPC? I'm not clear why there would be validation later in =
the commit/apply process that wasn't part of the decision to reply OK/NOK t=
o the commit.


 


The draft also implies that the process of moving co=
nfig from running -> intended -> operational is decoupled from the ap=
plication of a candidate -> running.


- Do systems reply OK/NOK to a commit before config =
is moved from running->intended->operational ?


- If so, then maybe it isn't correct to have a usern=
ame in the notifications. A specific user/session did the commit, but then =
if the commit process ends after candidate->running (i.e. the reply happ=
ens at that point), then isn't it really
 the system moving the config from running->intended->operational?


 


Jason






--_000_VI1PR07MB3981B3CF71B4216217DF41689BCB0VI1PR07MB3981eurp_--


From nobody Mon Nov  5 20:41: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 D286B12D4EA for ; Mon,  5 Nov 2018 20:41:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level: 
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 JrpGh1Ex-kaF for ; Mon,  5 Nov 2018 20:41:19 -0800 (PST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20095.outbound.protection.outlook.com [40.107.2.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC28126BED for ; Mon,  5 Nov 2018 20:41:19 -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=5GqL3KRV40akREaj18ulqXBiStS1gVswtkB5duYnBT8=; b=GBwLCPkJGnrNigs8KjXmJjwYm4enUucvP2+ffrDzFCJ+nuhA3uOXbMSJgGE55BHKIRv4AgPrMwoz/TYe7AnoA3TFfcsj8vbZePdYymoFn9e1eU7+LGXb+sKYXTPTQX+3pnVsjbL2Ln818HCzfkMtGdBsaL+tAHWwtMFvRCY8MKo=
Received: from DB7PR07MB5980.eurprd07.prod.outlook.com (20.178.106.225) by DB7SPR01MB0022.eurprd07.prod.outlook.com (20.177.123.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.31; Tue, 6 Nov 2018 04:41:16 +0000
Received: from DB7PR07MB5980.eurprd07.prod.outlook.com ([fe80::39a2:8a58:7fc4:d2a3]) by DB7PR07MB5980.eurprd07.prod.outlook.com ([fe80::39a2:8a58:7fc4:d2a3%3]) with mapi id 15.20.1294.032; Tue, 6 Nov 2018 04:41:16 +0000
From: "Carey, Timothy (Nokia - US)" 
To: "netmod@ietf.org" 
Thread-Topic: draft-wu-netmod-factory-default-01: Actually resetting the device to factory defaults
Thread-Index: AdR1igfK1ftePAk7Tg6kbS7+EdIuMw==
Date: Tue, 6 Nov 2018 04:41:16 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=timothy.carey@nokia.com; 
x-originating-ip: [43.249.105.152]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB7SPR01MB0022; 6:UQ+7mxc3L3i4WBwCqDSZU+eE/R+epSnefPGrkNiwQQ8wW9GM0ETOxORhfL/wOmjxCYYVNJDWv3ZU50Iv5yF5KdYTW8RBkwNbHSJZ6SblyNsN2n00pNY173ivm1ZtGhy4fY/MA7oEiVMqTbWn94xIi0jQlAuUOLqymilJEObaPZGNYuOVoayE7S+icU9zlzgt5Ut9cWgbDHXVAnByQypSVvnxqk/9eJn4bTX4D8VESewbwLd4sQfHhod9wrgsn26YQGRt/QsKFoV5LR/4lrJLWjJiR5zSHs1C71gwOyGGB82WZGY24yOhWLcF20+XX/B587aRY98vWIEqYYgYejSamjWUZI4HERi4wv8ghgIi9rGDjQ9a8WFyH9+esPzf0BqYWULp3W7TwHEv2nol7tcq2m4NczPwTQhWOKYcvg3p2G7E3O73yZRXE2zLjCPfICeBHqiLUYA6277wtV74UuqQeA==; 5:LQsAiXnYr1w+uLNKKGRZPf9PExPMCBO4F3dZ/Ng8Y1bmo0thriPQ2OhZO7zFN3Mz3imrxL4RlqUILe7nZuxktaJrKHlH7MRruO0ah5vSnp3iirWd4hQwvfMuD8AYqnPEToJwlpuoUIXSxMWb8w0ZT/OV1bk7//9PmcLL/i649sE=; 7:w5/LhdRKy02OOBu8reyP9Y7V+FvC+tzEX7E98szqE/+FXiXlKjYnKZT4+VnR9hj2T928t58bZ0yF7CnM7LL7cVyPHZgr4OhahbVaFGOJZHop/Ny631hpkOrcSEkvQLqTxxQQVBClFcGRNLsHyp8ubQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 95f7cc5f-1aa1-44db-fa41-08d643a21706
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7167020)(7193020); SRVR:DB7SPR01MB0022; 
x-ms-traffictypediagnostic: DB7SPR01MB0022:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(21748063052155)(28532068793085)(190501279198761)(227612066756510); 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231382)(11241501184)(806099)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:DB7SPR01MB0022; BCL:0; PCL:0; RULEID:; SRVR:DB7SPR01MB0022; 
x-forefront-prvs: 0848C1A6AA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(136003)(376002)(366004)(39860400002)(199004)(189003)(99286004)(486006)(2501003)(9326002)(7696005)(1730700003)(2906002)(81166006)(8676002)(81156014)(476003)(55236004)(26005)(316002)(86362001)(186003)(3846002)(6116002)(6506007)(2351001)(102836004)(790700001)(8936002)(106356001)(2900100001)(53936002)(55016002)(9686003)(54896002)(6916009)(478600001)(6306002)(33656002)(25786009)(5640700003)(71200400001)(71190400001)(256004)(6436002)(66066001)(14454004)(74316002)(97736004)(7736002)(105586002)(68736007)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7SPR01MB0022; H:DB7PR07MB5980.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)
x-microsoft-antispam-message-info: 3nXMabuf4soD0WDifjy0gexpPSuva2PZoQzRXd0CM55nB3VXCkmy1WoWYWdDhjNTX3AAqPrXzVaIj+wYOb5HUZ06ptbjMUn4FJOIDUdBLvXA6XHRoMX4zjRyLzDHv2KOu/cI8oCFTGdW/syHEx3BWvegUybiofUmZP6NHe/yKWau66TpP6bTm9MPImANUTtRaMq6wYDd79ioIwmwxt58TJY1Q9sxxmcdAB84zfQdfEnBExOfof6O9C+nnmsCL+7+0ueOUwzStVJ3RE352OHNfuD3Wgbz/GWbKF0sM91WSCOdXQBaSxfVZekwxfTvX6OUcF4PPcKljJzUi59UeuH8E+zVBKoOKIkYOu8jxLuom5k=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB7PR07MB59800FABAE39F42C327EFF1DEFCB0DB7PR07MB5980eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 95f7cc5f-1aa1-44db-fa41-08d643a21706
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2018 04:41:16.8259 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7SPR01MB0022
Archived-At: 
Subject: [netmod] draft-wu-netmod-factory-default-01: Actually resetting the device to factory defaults
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 04:41:22 -0000

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

Hi,

In the IETF 103 meeting a comment was made that using the reset-datastore R=
PC doesn't actually reset the device to factory settings.

I would like to suggest that this RPC when applied to the start-up store ha=
ve the capability to actually reset the device the factory settings.

This might require a device reboot to finalize the action but we do need an=
 option that I can actually place the device in a configuration
That resembles the device when it first arrives from the "factory". I would=
 believe this would be the main use case for this type of reset-datastore o=
peration.

Did I misunderstand the comment?

BR,
Tim



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











Hi,


 


In the IETF 103 meeting a comment was made that usin=
g the reset-datastore RPC doesn’t actually reset the device to factor=
y settings.


 


I would like to suggest that this RPC when applied t=
o the start-up store have the capability to actually reset the device the f=
actory settings.


 


This might require a device reboot to finalize the a=
ction but we do need an option that I can actually place the device in a co=
nfiguration



That resembles the device when it first arrives from=
 the “factory”. I would believe this would be the main use case=
 for this type of reset-datastore operation.


 


Did I misunderstand the comment?


 


BR,


Tim


 


 






--_000_DB7PR07MB59800FABAE39F42C327EFF1DEFCB0DB7PR07MB5980eurp_--


From nobody Mon Nov  5 20:51:41 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAF812D4EA for ; Mon,  5 Nov 2018 20:51:39 -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 KZ3fuQXOORMi for ; Mon,  5 Nov 2018 20:51:36 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 882521294D0 for ; Mon,  5 Nov 2018 20:51:36 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 11CF9182113D; Tue,  6 Nov 2018 05:59:24 +0100 (CET)
Received: from localhost (dhcp-9cfe.meeting.ietf.org [31.133.156.254]) by trail.lhotka.name (Postfix) with ESMTPSA id CB0751821139; Tue,  6 Nov 2018 05:59:21 +0100 (CET)
From: Ladislav Lhotka 
To: Joe Clarke , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod\@ietf.org" 
In-Reply-To: <2a796f78-41b7-376c-8f51-215d14cc4e2c@cisco.com>
References: <154147032474.4217.10743411700898817061.idtracker@ietfa.amsl.com> <07b9bcea-72e3-9986-7d42-303c4797f13a@ericsson.com> <2a796f78-41b7-376c-8f51-215d14cc4e2c@cisco.com>
Mail-Followup-To: Joe Clarke , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod\@ietf.org" 
Date: Tue, 06 Nov 2018 11:51:26 +0700
Message-ID: <87y3a6izap.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 04:51:39 -0000

Joe Clarke  writes:
> ===
>
> Section 6
>
> With your datastore leaf, if I pull this off of a running YANG server,
> serialize it and share it with my customer, why wouldn't I have the
> actual datastore from which I retrieved it?  What I'm saying is that
> this element may be missing, but if it is, I don't think you can assume
> the source datastore for config=true nodes.
>

The description of the "datastore" leaf doesn't make much sense to
me. It says that for configuration data the default is "running" or
"candidate" if "running" isn't writable. Why should it matter whether
"running" is writable? It looks like it is assumed that the config data will
eventually be fed into the indicated datastore, but I don't see any
reason for such an assumption.

I can see that "datastore" can be occasionally useful as auxiliary
metadata but, in my view, this document addresses also instance data
that is not necessarily bound to any datastore.

Lada

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


From nobody Mon Nov  5 22:26: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 8D172130F82 for ; Mon,  5 Nov 2018 22:26:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level: 
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiFFiiGtA-vh for ; Mon,  5 Nov 2018 22:26:14 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9617F130F4A for ; Mon,  5 Nov 2018 22:26:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1193; q=dns/txt; s=iport; t=1541485574; x=1542695174; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=YHkTf9ycrEuOBOnidEjb0LZkbFBquVoCxr8PfOd5gDo=; b=XbiNly3PlRqM+sFV/cFzrT1PzpHLgxW5wSAvN3V0DJ4+U43KOSGXzSl9 vGme+MHPJ6wGfA58rBItegCBhmXTeUkb+X00WkEOWe5170HeczADKs4Zy I0UdHiLBmA+mXtiS0GB7VVEWW2pzd1WbHBc/MI4O0o4mcllKKEdjAo3Tx k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAAYM+Fb/51dJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBggRpfCiDdpY9ly+Beg2EbAKDUiI1DA0?= =?us-ascii?q?BAwEBAgEBAm0ohTsBBSNUEgsYAgImAgJXBgEMBgIBAYMdggKpDoEuijOBC4p?= =?us-ascii?q?rF4FBP4E4gmuEaBaDBII1IgKPODOPSAmRCwYYiVGHD5dJgUQBNoFVTSMVgye?= =?us-ascii?q?CUI4nITCOKwEB?=
X-IronPort-AV: E=Sophos;i="5.54,470,1534809600"; d="scan'208";a="259181546"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2018 06:26:13 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro4.cisco.com [10.118.87.85]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTP id wA66QBMt002480; Tue, 6 Nov 2018 06:26:12 GMT
To: =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= , "netmod@ietf.org" 
References: <154147032474.4217.10743411700898817061.idtracker@ietfa.amsl.com> <07b9bcea-72e3-9986-7d42-303c4797f13a@ericsson.com> <2a796f78-41b7-376c-8f51-215d14cc4e2c@cisco.com> <87y3a6izap.fsf@nic.cz>
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDo1cJ0RBADSZSmbmzdRr1CoRWWKmAyu0eaQimaLV1TsZEML/ksLyg6faXrKIA/MWc7M w4FmKkDjaZdFzobzabnKp2QwVadLqi1gYY2WsApKC0rSoqsPx5E847AmwNWXgjXiXORXmnZL mf5PZ2ECOEJC27sji5Nrh9GSw7OPp6c+EE20gMNVrwCgu3iK5vyGQfy0/wX/jcIvP0nHznUD /RvijiKomyaf6F5pibmouFNeuCDHc8lwx2giA/MCZl/nSkI2/UX27sULGNgvKNkVPu/AukXu zW3fIthsJgjQZUoi/BTe9kUP+RL3+RALXXuLv7b3xGRHJ8A1Rpy9H43fkjHZ945YNPrUvJlG LP5PNGBD1xC21X3EGAyywVynDskcA/4qgbJFkVzmPjFJUjq+RW1zw3UIb3bbkskl/wk5qd+M w2EhiSPTbEhJQAQUvqSGFWEGp2ANic7iYLdPXV/O6I1/guRRaY0eK77YkkCjz1snaKYnGSeI GHGwmHb6D+ZHzTqZqr6IssgEIUHjXfgOUTARQbL15nJTVRzDGUiT/65R3c0eSm9lIENsYXJr ZSA8amNsYXJrZUBjaXNjby5jb20+wl8EExECABcFAjyDqGQFCwcKAwQDFQMCAxYCAQIXgAAS CRDN7TXCWm4C3wdlR1BHAAEB5KkAn0kBda/9+uF6RfnDSFS7RExUU9DqAJ4knRckYiSASteC K03QVtEiXblL287ATQQ6NXCeEAQAhIURlK17jmIMdMIuScFU6xK+jkKgVVFrjlRH5vLV2spp jH/uQ57MMGuOcs7PckXCnPjBV8Tm32Tuw+fCyrbc2gt0ouiT/5WWj0EMeAfWew1zBXX2okGf LqS6gucVDS6tcEFN6PmJEmX+tWDcmiqx/xXiSfMVYiLMdlK+YDkMDDsAAwUD/3BWOyfdnBGH Kv28zx+5wq/2vhYnUYCAdVD2ZWCJizQTMbkcxEIKAwtAj6yqKq9ah82nt4VHl5ZejVe47jvR 2nXwJ5VQ9eITuTjTLDw+3qr9lN077VZ32hyb5ULJcW756j9Z3YB2FTANw6KHgChaSVVx9kYJ FlAggraU7mi39/wvwk4EGBECAAYFAjo1cJ4AEgkQze01wlpuAt8HZUdQRwABAQbdAJ9R8SzU Mluu9r93BMv6fAW9j6qTZgCfYcEAqOMJv+3Z+YxLiDtWcCY4Sfo=
Organization: Cisco
Message-ID: <87bf36ba-5dc0-cdd5-b7f9-8fd4d0c50c4f@cisco.com>
Date: Tue, 6 Nov 2018 01:26:10 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <87y3a6izap.fsf@nic.cz>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.118.87.85, rtp-jclarke-nitro4.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 06:26:21 -0000

On 11/5/18 23:51, Ladislav Lhotka wrote:
> Joe Clarke  writes:
>> ===
>>
>> Section 6
>>
>> With your datastore leaf, if I pull this off of a running YANG server,
>> serialize it and share it with my customer, why wouldn't I have the
>> actual datastore from which I retrieved it?  What I'm saying is that
>> this element may be missing, but if it is, I don't think you can assume
>> the source datastore for config=true nodes.
>>
> 
> The description of the "datastore" leaf doesn't make much sense to
> me. It says that for configuration data the default is "running" or
> "candidate" if "running" isn't writable. Why should it matter whether
> "running" is writable? It looks like it is assumed that the config data will
> eventually be fed into the indicated datastore, but I don't see any
> reason for such an assumption.
> 
> I can see that "datastore" can be occasionally useful as auxiliary
> metadata but, in my view, this document addresses also instance data
> that is not necessarily bound to any datastore.

I agree.  In some cases, I won't have a datastore, and that shouldn't
mean the consumer assumes running (or candidate).

Joe


From nobody Mon Nov  5 22:37: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 413C6130DD2 for ; Mon,  5 Nov 2018 22:37:23 -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 QIjxmox_12RO for ; Mon,  5 Nov 2018 22:37:17 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF062130F62 for ; Mon,  5 Nov 2018 22:36:53 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 2EAEFDC1; Tue,  6 Nov 2018 07:36:51 +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 RbUzskrpoXSu; Tue,  6 Nov 2018 07:36:47 +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,  6 Nov 2018 07:36:50 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D864E2003D; Tue,  6 Nov 2018 07:36:50 +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 mrNa9L0GqUtA; Tue,  6 Nov 2018 07:36:50 +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 36AF72003C; Tue,  6 Nov 2018 07:36:50 +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, 6 Nov 2018 07:36:49 +0100
Received: by anna.localdomain (Postfix, from userid 501) id C938D3003ADA22; Tue,  6 Nov 2018 07:36:48 +0100 (CET)
Date: Tue, 6 Nov 2018 07:36:48 +0100
From: Juergen Schoenwaelder 
To: Joe Clarke , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod@ietf.org" 
Message-ID: <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Joe Clarke , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod@ietf.org" 
References: <154147032474.4217.10743411700898817061.idtracker@ietfa.amsl.com> <07b9bcea-72e3-9986-7d42-303c4797f13a@ericsson.com> <2a796f78-41b7-376c-8f51-215d14cc4e2c@cisco.com> <87y3a6izap.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87y3a6izap.fsf@nic.cz>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 06:37:23 -0000

I agree that

        leaf datastore {
          type ds:datastore-ref;
          description  "The identity of the datastore for which
            the instance data is documented for config=true data nodes.
            The leaf MAY be absent in which case the running dtastore or
            if thats not writable, the candidate datastore is implied.

            For config=false data nodes always the operational
            data store is implied.";
	}

is pretty confusing. It should be something like this:

        leaf datastore {
          type ds:datastore-ref;
          description  "The identity of the datastore holding
            the instance data. If the instance data is not associated
	    with a datastore, then this leaf MUST be absent.";
	}

I am against merging data from different datastores together, which
the last sentence of the original text seems to imply.

/js

On Tue, Nov 06, 2018 at 11:51:26AM +0700, Ladislav Lhotka wrote:
> Joe Clarke  writes:
> > ===
> >
> > Section 6
> >
> > With your datastore leaf, if I pull this off of a running YANG server,
> > serialize it and share it with my customer, why wouldn't I have the
> > actual datastore from which I retrieved it?  What I'm saying is that
> > this element may be missing, but if it is, I don't think you can assume
> > the source datastore for config=true nodes.
> >
> 
> The description of the "datastore" leaf doesn't make much sense to
> me. It says that for configuration data the default is "running" or
> "candidate" if "running" isn't writable. Why should it matter whether
> "running" is writable? It looks like it is assumed that the config data will
> eventually be fed into the indicated datastore, but I don't see any
> reason for such an assumption.
> 
> I can see that "datastore" can be occasionally useful as auxiliary
> metadata but, in my view, this document addresses also instance data
> that is not necessarily bound to any datastore.
> 
> Lada
> 
> -- 
> 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 Mon Nov  5 22:51: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 0988312DD85 for ; Mon,  5 Nov 2018 22:51:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPx9TqEHDe1J for ; Mon,  5 Nov 2018 22:51:42 -0800 (PST)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989EA1277C8 for ; Mon,  5 Nov 2018 22:51:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2728; q=dns/txt; s=iport; t=1541487102; x=1542696702; h=to:references:from:subject:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Lh80nd2hC+2ophkUMPLcZ9C8yMoVGXQEqA1m4GH2m1E=; b=i7iBc1G8q+7FM1XMERlfR/352pEJDcvsweC91roW5f8VbFVxbpdV3RyH krGwiXYXp9pj3d7QsHHRAYpTJcT93C19U4lxMZ2cR22Y3jmfzUFQBLDg0 T5I5v+HeOyf5g70NntgDOfpIw1yPe3YS1RuMbvr/+m0ij9ROTC7ZUmMT2 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADQOOFb/5tdJa1cCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYIEZgN8KIN2iBiOJZcvgXoNGAuEA0Y?= =?us-ascii?q?Cg1ciNA0NAQMBAQIBAQJtHAyFOwEBBAEBIQ8BOwkSCxgCAiYCAicwBgEMBgI?= =?us-ascii?q?BAYMdAYIBD6kFgS6KLgWBC4prF4FBP4ERJ4JrgxsBAYE3FBaDBII1IgKPa4U?= =?us-ascii?q?eiioJkQsGGIlRhw+XSYFDOIFVTSMVO4JsgicXEohLhVwhMI4rAQE?=
X-IronPort-AV: E=Sophos;i="5.54,470,1534809600"; d="scan'208";a="197025642"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Nov 2018 06:51:40 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro4.cisco.com [10.118.87.85]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id wA66pb0h009267; Tue, 6 Nov 2018 06:51:38 GMT
To: =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= , "netmod@ietf.org" 
References: <154147032474.4217.10743411700898817061.idtracker@ietfa.amsl.com> <07b9bcea-72e3-9986-7d42-303c4797f13a@ericsson.com> <2a796f78-41b7-376c-8f51-215d14cc4e2c@cisco.com> <87y3a6izap.fsf@nic.cz> <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de>
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDo1cJ0RBADSZSmbmzdRr1CoRWWKmAyu0eaQimaLV1TsZEML/ksLyg6faXrKIA/MWc7M w4FmKkDjaZdFzobzabnKp2QwVadLqi1gYY2WsApKC0rSoqsPx5E847AmwNWXgjXiXORXmnZL mf5PZ2ECOEJC27sji5Nrh9GSw7OPp6c+EE20gMNVrwCgu3iK5vyGQfy0/wX/jcIvP0nHznUD /RvijiKomyaf6F5pibmouFNeuCDHc8lwx2giA/MCZl/nSkI2/UX27sULGNgvKNkVPu/AukXu zW3fIthsJgjQZUoi/BTe9kUP+RL3+RALXXuLv7b3xGRHJ8A1Rpy9H43fkjHZ945YNPrUvJlG LP5PNGBD1xC21X3EGAyywVynDskcA/4qgbJFkVzmPjFJUjq+RW1zw3UIb3bbkskl/wk5qd+M w2EhiSPTbEhJQAQUvqSGFWEGp2ANic7iYLdPXV/O6I1/guRRaY0eK77YkkCjz1snaKYnGSeI GHGwmHb6D+ZHzTqZqr6IssgEIUHjXfgOUTARQbL15nJTVRzDGUiT/65R3c0eSm9lIENsYXJr ZSA8amNsYXJrZUBjaXNjby5jb20+wl8EExECABcFAjyDqGQFCwcKAwQDFQMCAxYCAQIXgAAS CRDN7TXCWm4C3wdlR1BHAAEB5KkAn0kBda/9+uF6RfnDSFS7RExUU9DqAJ4knRckYiSASteC K03QVtEiXblL287ATQQ6NXCeEAQAhIURlK17jmIMdMIuScFU6xK+jkKgVVFrjlRH5vLV2spp jH/uQ57MMGuOcs7PckXCnPjBV8Tm32Tuw+fCyrbc2gt0ouiT/5WWj0EMeAfWew1zBXX2okGf LqS6gucVDS6tcEFN6PmJEmX+tWDcmiqx/xXiSfMVYiLMdlK+YDkMDDsAAwUD/3BWOyfdnBGH Kv28zx+5wq/2vhYnUYCAdVD2ZWCJizQTMbkcxEIKAwtAj6yqKq9ah82nt4VHl5ZejVe47jvR 2nXwJ5VQ9eITuTjTLDw+3qr9lN077VZ32hyb5ULJcW756j9Z3YB2FTANw6KHgChaSVVx9kYJ FlAggraU7mi39/wvwk4EGBECAAYFAjo1cJ4AEgkQze01wlpuAt8HZUdQRwABAQbdAJ9R8SzU Mluu9r93BMv6fAW9j6qTZgCfYcEAqOMJv+3Z+YxLiDtWcCY4Sfo=
Organization: Cisco
Message-ID: <70011b82-e7a3-5fc4-5f22-d4dc26fb6186@cisco.com>
Date: Tue, 6 Nov 2018 01:51:36 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.118.87.85, rtp-jclarke-nitro4.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 06:51:45 -0000

On 11/6/18 01:36, Juergen Schoenwaelder wrote:
> I agree that
> 
>         leaf datastore {
>           type ds:datastore-ref;
>           description  "The identity of the datastore for which
>             the instance data is documented for config=true data nodes.
>             The leaf MAY be absent in which case the running dtastore or
>             if thats not writable, the candidate datastore is implied.
> 
>             For config=false data nodes always the operational
>             data store is implied.";
> 	}
> 
> is pretty confusing. It should be something like this:
> 
>         leaf datastore {
>           type ds:datastore-ref;
>           description  "The identity of the datastore holding
>             the instance data. If the instance data is not associated
> 	    with a datastore, then this leaf MUST be absent.";
> 	}
> 
> I am against merging data from different datastores together, which
> the last sentence of the original text seems to imply.

This is better.

In the case where the data does come from a datastore would this leaf
need to be there?  Meaning, is there an assumption that when it's not
present then the data did NOT come from a DS?

And it seems like you could provide instance data from  to
merge ct and cf nodes even without merging DSes.

Joe

> 
> /js
> 
> On Tue, Nov 06, 2018 at 11:51:26AM +0700, Ladislav Lhotka wrote:
>> Joe Clarke  writes:
>>> ===
>>>
>>> Section 6
>>>
>>> With your datastore leaf, if I pull this off of a running YANG server,
>>> serialize it and share it with my customer, why wouldn't I have the
>>> actual datastore from which I retrieved it?  What I'm saying is that
>>> this element may be missing, but if it is, I don't think you can assume
>>> the source datastore for config=true nodes.
>>>
>>
>> The description of the "datastore" leaf doesn't make much sense to
>> me. It says that for configuration data the default is "running" or
>> "candidate" if "running" isn't writable. Why should it matter whether
>> "running" is writable? It looks like it is assumed that the config data will
>> eventually be fed into the indicated datastore, but I don't see any
>> reason for such an assumption.
>>
>> I can see that "datastore" can be occasionally useful as auxiliary
>> metadata but, in my view, this document addresses also instance data
>> that is not necessarily bound to any datastore.
>>
>> Lada
>>
>> -- 
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Tue Nov  6 00:45: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 C11F5130DE3 for ; Tue,  6 Nov 2018 00:45:19 -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 a7jPRvVSnEFZ for ; Tue,  6 Nov 2018 00:45:17 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56EA112D4F1 for ; Tue,  6 Nov 2018 00:45: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 D7536E15; Tue,  6 Nov 2018 09:45:15 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id VKzLlNJIVGbI; Tue,  6 Nov 2018 09:45:12 +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,  6 Nov 2018 09:45:15 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B7D9020044; Tue,  6 Nov 2018 09:45:15 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VGBlfp3dB7Cp; Tue,  6 Nov 2018 09:45:15 +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 4AE512003D; Tue,  6 Nov 2018 09:45: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, 6 Nov 2018 09:45:14 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 776A93003ADDDF; Tue,  6 Nov 2018 09:45:13 +0100 (CET)
Date: Tue, 6 Nov 2018 09:45:13 +0100
From: Juergen Schoenwaelder 
To: Joe Clarke 
CC: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod@ietf.org" 
Message-ID: <20181106084513.vwjk5au5kmuod2mw@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Joe Clarke , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod@ietf.org" 
References: <154147032474.4217.10743411700898817061.idtracker@ietfa.amsl.com> <07b9bcea-72e3-9986-7d42-303c4797f13a@ericsson.com> <2a796f78-41b7-376c-8f51-215d14cc4e2c@cisco.com> <87y3a6izap.fsf@nic.cz> <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de> <70011b82-e7a3-5fc4-5f22-d4dc26fb6186@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <70011b82-e7a3-5fc4-5f22-d4dc26fb6186@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] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 08:45:20 -0000

On Tue, Nov 06, 2018 at 01:51:36AM -0500, Joe Clarke wrote:
> On 11/6/18 01:36, Juergen Schoenwaelder wrote:
> > I agree that
> > 
> >         leaf datastore {
> >           type ds:datastore-ref;
> >           description  "The identity of the datastore for which
> >             the instance data is documented for config=true data nodes.
> >             The leaf MAY be absent in which case the running dtastore or
> >             if thats not writable, the candidate datastore is implied.
> > 
> >             For config=false data nodes always the operational
> >             data store is implied.";
> > 	}
> > 
> > is pretty confusing. It should be something like this:
> > 
> >         leaf datastore {
> >           type ds:datastore-ref;
> >           description  "The identity of the datastore holding
> >             the instance data. If the instance data is not associated
> > 	    with a datastore, then this leaf MUST be absent.";
> > 	}
> > 
> > I am against merging data from different datastores together, which
> > the last sentence of the original text seems to imply.
> 
> This is better.
> 
> In the case where the data does come from a datastore would this leaf
> need to be there?  Meaning, is there an assumption that when it's not
> present then the data did NOT come from a DS?

I would prefer to have the datastore leaf mandatory when data is
associated with a specific datastore. If we do not mandate this, we
need a way to distinguish "I do not know what this is" from "this is
not datastore instance data".
 
> And it seems like you could provide instance data from  to
> merge ct and cf nodes even without merging DSes.

The  datastore does contain ct and cf data and the ct
data is the ct data that is operationally used (which can be different
from the ct data in . We went through quite some pain to
sort all of this out as part of the NMDA work and this document should
be consistent with NMDA.

/js

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


From nobody Tue Nov  6 01:36: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 0E7E5128A6E for ; Tue,  6 Nov 2018 01:36:19 -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 Mi0bhtBMwQfI for ; Tue,  6 Nov 2018 01:36:16 -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 A5E56129AB8 for ; Tue,  6 Nov 2018 01:36:15 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:67c:1232:144:1a4f:a84b:2bfd:c611]) by mail.nic.cz (Postfix) with ESMTPSA id E2F2562AC7 for ; Tue,  6 Nov 2018 10:36:12 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1541496973; bh=rcIYCzDGYsNWSumlx7AzduPsbqBeGik+ngX++sblYWk=; h=From:To:Date; b=IMKhq13uim/BRCFk1uFEEGFvQdD8179aK3HugtCGQyVyZdouK6jWkdmZvYbiaO2jy 8K4zr0G4XVSlw8R3Q403h4qKUoVBMj79L45ftHrFK/DkeG/2SUwIXTpW+9p9b1zlZt Y2psfNLmTzCwew0Ev9miWf3raHiutyjDPYk5SzHQ=
Message-ID: <58740c15bf3277e04329546476f60c1d12516594.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Tue, 06 Nov 2018 16:36:09 +0700
In-Reply-To: <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de>
References: <154147032474.4217.10743411700898817061.idtracker@ietfa.amsl.com> <07b9bcea-72e3-9986-7d42-303c4797f13a@ericsson.com> <2a796f78-41b7-376c-8f51-215d14cc4e2c@cisco.com> <87y3a6izap.fsf@nic.cz> <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 09:36:19 -0000

On Tue, 2018-11-06 at 07:36 +0100, Juergen Schoenwaelder wrote:
> I agree that
> 
>         leaf datastore {
>           type ds:datastore-ref;
>           description  "The identity of the datastore for which
>             the instance data is documented for config=true data nodes.
>             The leaf MAY be absent in which case the running dtastore or
>             if thats not writable, the candidate datastore is implied.
> 
>             For config=false data nodes always the operational
>             data store is implied.";
> 	}
> 
> is pretty confusing. It should be something like this:
> 
>         leaf datastore {
>           type ds:datastore-ref;
>           description  "The identity of the datastore holding
>             the instance data. If the instance data is not associated

Or rather the datastore that the instance data was extracted from. After that,
the data exists on its own and the originating datastore may later be holding
something else.

> 	    with a datastore, then this leaf MUST be absent.";

RFC 2119 language would make sense if there is anything that could break if that
MUST isn't observed. But we even didn't know what the data is going to be used
for.

I would treat the "datastore" item as a purely optional information that, if
present, was provided for some reason. If it is false, what can we do?

> 	}
> 
> I am against merging data from different datastores together, which
> the last sentence of the original text seems to imply.

Both config true and config false data may come from , so it
doesn't necessarily mean any mixing of datastores. But then again, I think that
the datastore information isn't in most cases that interesting.

Lada

> 
> /js
> 
> On Tue, Nov 06, 2018 at 11:51:26AM +0700, Ladislav Lhotka wrote:
> > Joe Clarke  writes:
> > > ===
> > > 
> > > Section 6
> > > 
> > > With your datastore leaf, if I pull this off of a running YANG server,
> > > serialize it and share it with my customer, why wouldn't I have the
> > > actual datastore from which I retrieved it?  What I'm saying is that
> > > this element may be missing, but if it is, I don't think you can assume
> > > the source datastore for config=true nodes.
> > > 
> > 
> > The description of the "datastore" leaf doesn't make much sense to
> > me. It says that for configuration data the default is "running" or
> > "candidate" if "running" isn't writable. Why should it matter whether
> > "running" is writable? It looks like it is assumed that the config data will
> > eventually be fed into the indicated datastore, but I don't see any
> > reason for such an assumption.
> > 
> > I can see that "datastore" can be occasionally useful as auxiliary
> > metadata but, in my view, this document addresses also instance data
> > that is not necessarily bound to any datastore.
> > 
> > Lada
> > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Nov  6 01:42: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 70FE1130E69 for ; Tue,  6 Nov 2018 01:42: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 O55ymGu6IOjO for ; Tue,  6 Nov 2018 01:41: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 982FE130E5C for ; Tue,  6 Nov 2018 01:41:59 -0800 (PST)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 779CD1AE018C; Tue,  6 Nov 2018 10:41:58 +0100 (CET)
Date: Tue, 06 Nov 2018 10:41:57 +0100 (CET)
Message-Id: <20181106.104157.239419955739949818.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <58740c15bf3277e04329546476f60c1d12516594.camel@nic.cz>
References: <87y3a6izap.fsf@nic.cz> <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de> <58740c15bf3277e04329546476f60c1d12516594.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 09:42:03 -0000

Ladislav Lhotka  wrote:
> On Tue, 2018-11-06 at 07:36 +0100, Juergen Schoenwaelder wrote:
> > I agree that
> > 
> >         leaf datastore {
> >           type ds:datastore-ref;
> >           description  "The identity of the datastore for which
> >             the instance data is documented for config=true data nodes.
> >             The leaf MAY be absent in which case the running dtastore or
> >             if thats not writable, the candidate datastore is implied.
> > 
> >             For config=false data nodes always the operational
> >             data store is implied.";
> > 	}
> > 
> > is pretty confusing. It should be something like this:
> > 
> >         leaf datastore {
> >           type ds:datastore-ref;
> >           description  "The identity of the datastore holding
> >             the instance data. If the instance data is not associated
> 
> Or rather the datastore that the instance data was extracted from.

I prefer "associated with".  There are other uses cases than just
holding data "extracted from", e.g., data that is supposed to "be
inserted into" a datastore.  "associated with" is less resrictive.

> After that,
> the data exists on its own and the originating datastore may later be holding
> something else.
> 
> > 	    with a datastore, then this leaf MUST be absent.";
> 
> RFC 2119 language would make sense if there is anything that could break if that
> MUST isn't observed. But we even didn't know what the data is going to be used
> for.
> 
> I would treat the "datastore" item as a purely optional information

I agree.


/martin



> that, if
> present, was provided for some reason. If it is false, what can we do?
> 
> > 	}
> > 
> > I am against merging data from different datastores together, which
> > the last sentence of the original text seems to imply.
> 
> Both config true and config false data may come from , so it
> doesn't necessarily mean any mixing of datastores. But then again, I think that
> the datastore information isn't in most cases that interesting.
> 
> Lada
> 
> > 
> > /js
> > 
> > On Tue, Nov 06, 2018 at 11:51:26AM +0700, Ladislav Lhotka wrote:
> > > Joe Clarke  writes:
> > > > ===
> > > > 
> > > > Section 6
> > > > 
> > > > With your datastore leaf, if I pull this off of a running YANG server,
> > > > serialize it and share it with my customer, why wouldn't I have the
> > > > actual datastore from which I retrieved it?  What I'm saying is that
> > > > this element may be missing, but if it is, I don't think you can assume
> > > > the source datastore for config=true nodes.
> > > > 
> > > 
> > > The description of the "datastore" leaf doesn't make much sense to
> > > me. It says that for configuration data the default is "running" or
> > > "candidate" if "running" isn't writable. Why should it matter whether
> > > "running" is writable? It looks like it is assumed that the config data will
> > > eventually be fed into the indicated datastore, but I don't see any
> > > reason for such an assumption.
> > > 
> > > I can see that "datastore" can be occasionally useful as auxiliary
> > > metadata but, in my view, this document addresses also instance data
> > > that is not necessarily bound to any datastore.
> > > 
> > > Lada
> > > 
> > > -- 
> > > Ladislav Lhotka
> > > Head, CZ.NIC Labs
> > > PGP Key ID: 0xB8F92B08A9F76C67
> > > 
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Tue Nov  6 01:58:09 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 020971277C8; Tue,  6 Nov 2018 01:58:00 -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.87.3
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: netmod@ietf.org
Message-ID: <154149827998.30784.6654227805978324308@ietfa.amsl.com>
Date: Tue, 06 Nov 2018 01:58:00 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-21.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 09:58:00 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

        Title           : Network Access Control List (ACL) YANG Data Model
        Authors         : Mahesh Jethanandani
                          Sonal Agarwal
                          Lisa Huang
                          Dana Blair
	Filename        : draft-ietf-netmod-acl-model-21.txt
	Pages           : 60
	Date            : 2018-11-06

Abstract:
   This document defines a data model for Access Control List (ACL).  An
   ACL is a user-ordered set of rules, used to configure the forwarding
   behavior in device.  Each rule is used to find a match on a packet,
   and define actions that will be performed on the packet.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-acl-model-21
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-21


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 Tue Nov  6 01:59:39 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED7B128A5C for ; Tue,  6 Nov 2018 01:59:38 -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 ndajGX0O8ash for ; Tue,  6 Nov 2018 01:59:36 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 25DF61277C8 for ; Tue,  6 Nov 2018 01:59:36 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 9779C182113C; Tue,  6 Nov 2018 11:07:24 +0100 (CET)
Received: from localhost (dhcp-9cfe.meeting.ietf.org [31.133.156.254]) by trail.lhotka.name (Postfix) with ESMTPSA id 7157C1821139 for ; Tue,  6 Nov 2018 11:07:22 +0100 (CET)
From: Ladislav Lhotka 
To: netmod@ietf.org
Mail-Followup-To: netmod@ietf.org
Date: Tue, 06 Nov 2018 16:59:28 +0700
Message-ID: <87sh0eil1b.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: [netmod] validity of instance-data
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 09:59:38 -0000

Hi,

the second bullet of Appendix A in
draft-ietf-netmod-yang-instance-file-format-00 talks about
validity. This would make sense if we have a complete schema - YANG
modules, even with revisions, is not enough. The schema can be provided
off-line but it can also be specified as a part of the metadata.

I would suggest to extend the metadata with the following two optional
methods of specifying the schema:

1. the schema can be specified in-line, for example in the format of the
   new YANG library, i.e. as a list of module-sets

2. A URL specifying the location of the schema.

Lada

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


From nobody Tue Nov  6 02:03:34 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9958B128A5C for ; Tue,  6 Nov 2018 02:03:32 -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 Xa3H2gSeJ3QQ for ; Tue,  6 Nov 2018 02:03:30 -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 E43F11277C8 for ; Tue,  6 Nov 2018 02:03:29 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:67c:1232:144:1a4f:a84b:2bfd:c611]) by mail.nic.cz (Postfix) with ESMTPSA id 1564F6272C; Tue,  6 Nov 2018 11:03:25 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1541498607; bh=hxT6XMl0N3XP4s2bYwS40wnrNwNVsVfe3m835DfrOh8=; h=From:To:Date; b=cRgkl1vgHCT5li8pKe3S9YjmRH7PpMc9NRSLdi3IiMLdoeCtvYifTggzkOaoI10/i P+esPNtvimH0V7iwwF0/W/EHrw95pHlbzlLVgFl2waF1VpSgPLvzCX5DHHlWT624Y9 yZxk2u0MNiBZvGaClrv6jPC4VsxammVtz3xnrzDE=
Message-ID: <866ff105cf8fda7eadbdce5b344f4cd734fd99b8.camel@nic.cz>
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: netmod@ietf.org
Date: Tue, 06 Nov 2018 17:03:22 +0700
In-Reply-To: <20181106.104157.239419955739949818.mbj@tail-f.com>
References: <87y3a6izap.fsf@nic.cz> <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de> <58740c15bf3277e04329546476f60c1d12516594.camel@nic.cz> <20181106.104157.239419955739949818.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 10:03:32 -0000

On Tue, 2018-11-06 at 10:41 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > On Tue, 2018-11-06 at 07:36 +0100, Juergen Schoenwaelder wrote:
> > > I agree that
> > > 
> > >         leaf datastore {
> > >           type ds:datastore-ref;
> > >           description  "The identity of the datastore for which
> > >             the instance data is documented for config=true data nodes.
> > >             The leaf MAY be absent in which case the running dtastore or
> > >             if thats not writable, the candidate datastore is implied.
> > > 
> > >             For config=false data nodes always the operational
> > >             data store is implied.";
> > >     }
> > > 
> > > is pretty confusing. It should be something like this:
> > > 
> > >         leaf datastore {
> > >           type ds:datastore-ref;
> > >           description  "The identity of the datastore holding
> > >             the instance data. If the instance data is not associated
> > 
> > Or rather the datastore that the instance data was extracted from.
> 
> I prefer "associated with".  There are other uses cases than just
> holding data "extracted from", e.g., data that is supposed to "be
> inserted into" a datastore.  "associated with" is less resrictive.

It unclear what "associated with" means in this context.

Lada

> 
> > After that,
> > the data exists on its own and the originating datastore may later be
> holding
> > something else.
> > 
> > >         with a datastore, then this leaf MUST be absent.";
> > 
> > RFC 2119 language would make sense if there is anything that could break if
> that
> > MUST isn't observed. But we even didn't know what the data is going to be
> used
> > for.
> > 
> > I would treat the "datastore" item as a purely optional information
> 
> I agree.
> 
> 
> /martin
> 
> 
> 
> > that, if
> > present, was provided for some reason. If it is false, what can we do?
> > 
> > >     }
> > > 
> > > I am against merging data from different datastores together, which
> > > the last sentence of the original text seems to imply.
> > 
> > Both config true and config false data may come from , so it
> > doesn't necessarily mean any mixing of datastores. But then again, I think
> that
> > the datastore information isn't in most cases that interesting.
> > 
> > Lada
> > 
> > > 
> > > /js
> > > 
> > > On Tue, Nov 06, 2018 at 11:51:26AM +0700, Ladislav Lhotka wrote:
> > > > Joe Clarke  writes:
> > > > > ===
> > > > > 
> > > > > Section 6
> > > > > 
> > > > > With your datastore leaf, if I pull this off of a running YANG server,
> > > > > serialize it and share it with my customer, why wouldn't I have the
> > > > > actual datastore from which I retrieved it?  What I'm saying is that
> > > > > this element may be missing, but if it is, I don't think you can
> assume
> > > > > the source datastore for config=true nodes.
> > > > > 
> > > > 
> > > > The description of the "datastore" leaf doesn't make much sense to
> > > > me. It says that for configuration data the default is "running" or
> > > > "candidate" if "running" isn't writable. Why should it matter whether
> > > > "running" is writable? It looks like it is assumed that the config data
> will
> > > > eventually be fed into the indicated datastore, but I don't see any
> > > > reason for such an assumption.
> > > > 
> > > > I can see that "datastore" can be occasionally useful as auxiliary
> > > > metadata but, in my view, this document addresses also instance data
> > > > that is not necessarily bound to any datastore.
> > > > 
> > > > Lada
> > > > 
> > > > -- 
> > > > Ladislav Lhotka
> > > > Head, CZ.NIC Labs
> > > > PGP Key ID: 0xB8F92B08A9F76C67
> > > > 
> > > > _______________________________________________
> > > > netmod mailing list
> > > > netmod@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Nov  6 02:22:38 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 7575F1277C8; Tue,  6 Nov 2018 02:22:29 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?Mirja_K=C3=BChlewind?= 
To: "The IESG" 
Cc: draft-ietf-netmod-acl-model@ietf.org, Kent Watsen , netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154149974947.30792.4051804738275979786.idtracker@ietfa.amsl.com>
Date: Tue, 06 Nov 2018 02:22:29 -0800
Archived-At: 
Subject: [netmod] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draf?= =?utf-8?q?t-ietf-netmod-acl-model-21=3A_=28with_COMMENT=29?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 10:22:30 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-netmod-acl-model-21: No Objection

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


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


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



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

Thanks for addressing my discuss!



From nobody Tue Nov  6 02:45:28 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF456130DC4 for ; Tue,  6 Nov 2018 02:45:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.172
X-Spam-Level: 
X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmTOuT9vWe8d for ; Tue,  6 Nov 2018 02:45:25 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A19B4130DDB for ; Tue,  6 Nov 2018 02:45:22 -0800 (PST)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wA69oGnl016824; Tue, 6 Nov 2018 01:55:33 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=PPS1017; bh=dMhmZGMEHWwqfU5jVunlQQnTUXn4Q2+M6/tGMSOdYXI=; b=dw7iwPlDpaJAuPPJ3GynS54SA5aZs6bF3d0x0P1AeCFAjv2uLCJ3NoXIMqJ8Gomt1KxP COea1W8bkzDTtTa+paCLQhidgFO4LPN7E0LqfO8PpOOAJVJvzZcpFvS7vXwOH4wcqjd0 75YzYrnHi65bwO95cVNKJ8/7gcBglzgme5B8quUplpCMts2WgI4tVqWUAIRWgaGJjAyb ujsWM+O559G/AbGChj8lZqvxjqRWmlf7fjQDt+mxyxMS6slY+FlK3DojH9FZL0Z7pbQy K0dLstx84mHdrpIWo+XftyeeP5y+aAKu9rzAKb4bgxAp6rKDCMxZpODwBqO4P8716Acv MQ== 
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0084.outbound.protection.outlook.com [207.46.163.84]) by mx0b-00273201.pphosted.com with ESMTP id 2nk5g9g8t7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 06 Nov 2018 01:55:33 -0800
Received: from SN4PR0501CA0122.namprd05.prod.outlook.com (2603:10b6:803:42::39) by SN6PR05MB4894.namprd05.prod.outlook.com (2603:10b6:805:9c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14; Tue, 6 Nov 2018 09:55:31 +0000
Received: from BY2NAM05FT059.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::209) by SN4PR0501CA0122.outlook.office365.com (2603:10b6:803:42::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14 via Frontend Transport; Tue, 6 Nov 2018 09:55:31 +0000
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.13 as permitted sender)
Received: from P-EXFEND-EQX-02.jnpr.net (66.129.239.13) by BY2NAM05FT059.mail.protection.outlook.com (10.152.100.196) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.20.1339.3 via Frontend Transport; Tue, 6 Nov 2018 09:55:31 +0000
Received: from P-EXBEND-EQX-03.jnpr.net (10.104.8.56) by P-EXFEND-EQX-02.jnpr.net (10.104.8.55) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 6 Nov 2018 01:55:26 -0800
Received: from P-EXBEND-EQX-02.jnpr.net (10.104.8.53) by P-EXBEND-EQX-03.jnpr.net (10.104.8.56) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 6 Nov 2018 01:55:26 -0800
Received: from smtp.juniper.net (10.104.20.6) by P-EXBEND-EQX-02.jnpr.net (10.104.8.53) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Tue, 6 Nov 2018 01:55:25 -0800
Date: Tue, 6 Nov 2018 16:55:23 +0700
From: Ebben Aries 
To: "Carey, Timothy (Nokia - US)" 
CC: "netmod@ietf.org" 
Message-ID: <20181106095523.ghfyoq5abvfmzd6i@smtp.juniper.net>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.13; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(136003)(39860400002)(2980300002)(199004)(189003)(69596002)(68736007)(77096007)(6246003)(186003)(53936002)(23726003)(4326008)(478600001)(316002)(296002)(81156014)(486006)(81166006)(8676002)(106466001)(97756001)(105596002)(126002)(446003)(14444005)(476003)(336012)(11346002)(305945005)(55016002)(8936002)(50466002)(76176011)(229853002)(26005)(6346003)(5660300001)(53416004)(356004)(2906002)(6916009)(47776003)(7696005)(1076002)(16586007)(46406003)(97736004)(86362001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR05MB4894; H:P-EXFEND-EQX-02.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; 
X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT059; 1:ZmJQoBQpUpUr7wqwe3AzbZQWv2QE5ZHBLgVBvv0Jq7AlbmQvUrrkIzGBawkuJg67/BRjqfOJig/6rz9ozxh8mydzqLlGGcy9rgKY597tgX75B0/246bmwScGG1NhdRuT
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: cd7898a8-7f5d-4c64-23f7-08d643cdfd20
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060); SRVR:SN6PR05MB4894; 
X-Microsoft-Exchange-Diagnostics: 1; SN6PR05MB4894; 3:OBhajylaFOyIpl9e1ndJOWH5YKbalxgw6AyM4eVeGYAWyAtkeGWNVeKWmvG0ADamqiUqLE0mYcIMpgAl6ezl/8f3sB8NRaZMEpTIaR7MMBNHx5iIDeuB9AQksM0eKV5u4/7GVcGVl5Fd7Soqtoz3CUzHbjYbmVfNLunfFSs2SA0fA6yxW/OFk3uPfE1L7bqfmhm/aXKcdW2G/wM9apkrThz5/iE4BlyTgAb7jmz4T9QdRksKC4BWhdxhrzevBXvWEMMXvgvAwJ72NybjN/3CtnuXq4fGWgO1GHlbuRy2pnCmYLgyW1fTXw2DfaOLEMTG1uHy7+5udf0j7a/lSKjerqClYrbW/5RDktp0uPdw/zQ=; 25:4osEfbVF5BPrNaUNDhMDgD+nXHQ4xxA/wApiVmuMSsDgT/q8SlRwtn7gv6VjCzhA/p0El0M9dbjH+/+c1FJwEAhVylbySc4IMfS31RLhS1QZJ5AUDoOjJJREglWOzf16l+MBCbAZ0NKXxPfBKAtWQA/klqZHMQ2L82FWypTilFL6VyzgtpMCGBLZhDgsRVDViF/QEMo55Zv11JbEuWKcgRSO+iBirEXKCHM9nrTS04dPX9q+5sVQ5TTea7L6Q7IPO1Eq1Zjh16JNZ48Cxp/1Nh92jJuJSN7ZcrHI9EQ+BgdHo+lOzV7ILc1c00Jjf2b1ct0nkSyu63xXveqT4QLY2Q==
X-MS-TrafficTypeDiagnostic: SN6PR05MB4894:
X-Microsoft-Exchange-Diagnostics: 1; SN6PR05MB4894; 31:KReyCdfsG895pQlBHXgrTVKLUssy6BO5eaGNcyx88K5DdD53pACDPFbD/xW3sFuJY8z7mPQAIxWAiFLMCKK8cAsh6JbkyNiBK0xWtpQxaQ3vyd32iCLUpS+iFmyPlisn7hBYqYiVm0nT/DZcxH6vK6gDGodngNu3Gc8xmL1cDAkKAswO4PliNpMZC63eYytIUvqnQp594hPtTllWG2hBpbd1+XCD+mDIkOzTaduVjmQ=; 20:uMioiXJCSKvFtr6K3TFVj5js7muDB+tk9dVPHmLabi8Q/Z2Z1OdoZwlnHr2+vB0Ug8MOEWg/1Qhi5aMSntkm7yv5rrMB3vR3HPMxV85vBAamRYAxQngkEcLhjI4+Q1vU/EhNsefWyOywcnfT2KM2dX1GtfpdFLtQ+y7fKIOEvSipk6twCpN8TQ0cPwfO+LKlM4vxH927oETgMXAlGTnHPkhSz87ERgeQHct2V4Bmu3i1m71zm6ouQUR2XB0NCoe2iGwBI51clJ4xPB5RFecv/xVxgWFjo3W5oNDwLxX6BtlDCvOotqYmFLvjplhYUgvFVlov08oJlxAW07SdlrJEt0FkkYSNXPUwWHz5I+fn0yp7y01015LTVrBun+kXu33eV497X7yKWuj+eNhXLJYHUTWYcP73R/lKVjCCHcW30E0lnWtVNuK/X2V0ktJTxCFV6+IQz6zuUIgGCmn0qHJSq5SLNXtIj9ejG/zozyxVawh8//jqk56+6/lj0vgtWuF5
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231382)(944501410)(52105095)(93006095)(93003095)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:SN6PR05MB4894; BCL:0; PCL:0; RULEID:; SRVR:SN6PR05MB4894; 
X-Microsoft-Exchange-Diagnostics: 1; SN6PR05MB4894; 4:8z+Gy4pUvUnUvY6vRfj0USwpqro7yxAcT25s+UtZK6lE3yNjOldJ+B2hb1799GZsYVnvRcKVh0OyjQjH1Q3AMhYlI2f+Bom3gQgwtBIj/JBrL18QjKORovvHrb0ujGhWYaHts0E9tGkKNQS/ixdeQ2ioer1EsyW4z1dJQuCJ7AFZo7AVnmVORtxkdNuj7X6FGmOsoXry2OW+tEhipP3FU65Zod6hxGlepktnHV/OE5mqi4IADr9Bn6J6KVhZMwgKHc9ouQRzJBEIJxiUQb8CvQ==
X-Forefront-PRVS: 0848C1A6AA
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN6PR05MB4894; 23:bE29Z19P9Smv1TfhGe+B11wz3j74rU0xh1FdwqPXk?= =?us-ascii?Q?e/2o5/sNfV+uulKT92A83zgttBveniqrE6IWNJ2L6FbiIHKZ/FBea9DwyVhs?= =?us-ascii?Q?g2Q7l/Cvp/lUbtpb8aIr3ZBiQJjwFY+5POP3uOa0/vq8OKRgo4/Z9XiWwhHe?= =?us-ascii?Q?F9SqUbdBJganeMi6/SZ7cfQBt//mOpvrZhtIl8z1DvAbjTVEm6w5K5vyOFb2?= =?us-ascii?Q?xO4A5Yh7Gk49qDRmOHNjU0WAI0qT2TTLlSZHugcWo6TCkUVOhWcRjwWTYVui?= =?us-ascii?Q?R2J6iiEZrxvESTIj8D/WY4J5OnYZXvyScSIdfAItt2FA5jmeTHkdK9quRoOS?= =?us-ascii?Q?jipXJjXCmJoAhVMyAziFXjbjr6JokEPcan7LiNxxB1huqy3oph1uRLLipEhy?= =?us-ascii?Q?mtsoXPBStkjkdzGTkMvliM9p1hmW4jLXfcGC7LQWhYZ9AQi4NBMNdJG8Ledd?= =?us-ascii?Q?hjDMKdm/xN2s698mmDz+8uO2OirfziYN3NYsyoaLoUTO68Fv2MNiHnQK0zUF?= =?us-ascii?Q?O7aAfbhP9w8sa4HPF+0zoFODVf3CcHGk0PP952sm8ulX/ZmsWATWl/YfNfYQ?= =?us-ascii?Q?IIplSMb8lWLuBaxcsp68kQqowkfB6/5TDK83lJV6Grs8j7lQATJ88Sa+LkIY?= =?us-ascii?Q?aOyg6cYKl8uloJR7Lr1B13p6WECI1vSOJEtMf46cqVZn5evWJg6UWvqAsjnr?= =?us-ascii?Q?Am+stfeB0r5VTjqxAVTlYfq7HFaTqsfv75aayzLVJypdMi+3KWwyUMceOU8p?= =?us-ascii?Q?KCGAyxpDe5HHcGs5tXyZINRtroy7mrKZOkP3AboTLKIL20O6YQrCPQoQo0se?= =?us-ascii?Q?X7FPEZCvOxm0llA/eP+hysRs2meBZhBhJ2kxgNpQycr7kEcZHIx/TUlA6CzC?= =?us-ascii?Q?7TJNuN+4dPUdoDnQrvHooy6Nh38lY3ahLtL8Uho9AaGqONjTseR5F1jfUpt4?= =?us-ascii?Q?gWURMfMvdeLpv7u8Z5g9sTMXfijH7Kkug8B3xFWboLq8c/xQxIyjZf1bmNnK?= =?us-ascii?Q?heqd+cVDp5NxtLo4lkfRcasvbY8+0szOG+RkjWR4I/uUpSb96znodf1H70kW?= =?us-ascii?Q?Ra+R/4w1onaeorz9eHAIVBPtPTZZnwKhHXWvIhviI6D3TzmxxvCd5x/rRogl?= =?us-ascii?Q?/PEWq+zdRX3qGC0TAihCA6Kze2flOsrGJ8zhU3piGXd5BsfNgr289VfmiUKY?= =?us-ascii?Q?TgWCFYU58o7XuE=3D?=
X-Microsoft-Antispam-Message-Info: apFYt2BvABSh8ZN+L35ImGxsvowhAv2oiL9X2Cn0VQDZB2iTTxOhX1gyeEaky9WrSMJt7Jrbm4yRaWtMkvm3Hge0ouocjIjXzGwGQtKXnQn23Cf8BfF8PRiw/UHTGd8HcGw21MVinvXyCQ3ZtGzJljiocqWNWfUS4gmlvTBMwCWiN0DiAEGmjPMonMb59avXCvB5mXA+THgf0/ZGcWq8U8X3onbYiDBVuhJ05EC9W8CYOqgLkv/r4eBzdMS0SLlgCUwkSFNtuHxWtXra1iOy6TKTI6sn7qVSFDZZRVOAeeehV+PRVF84DNJJphBjvlwJ5g0Hs9aq/qDPwagEQG00AtHldc7MpnYT6DeTh7PV6qQ=
X-Microsoft-Exchange-Diagnostics: 1; SN6PR05MB4894; 6:Mz1q+HGXa4FD8yzHfU4aHGw4qMxzRm/Zzj+JDxc7+swtsBD5qZLLdMFVoUrcQlEl6puDiXLY1bycY6gkJ1ALquZ0xYr+8vpxGHHtW2pn8Gqf7ViDapzThZBLR8sBhgGPwdz3NcOaFJmYraNuJwKj+RwFVIqdFIQeoPmslyde3z4Ei1iPX8kjo1/fnXg8VkhigpbRup//OxHp1iUu3QwDe5mJP59ifBcPEaFen2xXTdteH3ppCGVW5ioYkkJKHlQIu1O1Uqmrou6sSkpCw10GK8epvuCuJ/fYTsRb/20oSiycSNE7vc2MUzQxIy3lyHAO6h7t7rV1QJHnsXnyvVBvFQPJDy7MJkabmKwsXr+KV0GAjcDTQB51k+3x86pV+SwPtrqmLzBUMzolePqG5+OqVpim5oj+v8Lgf5Xo+VwSIPtsU2ntyc27WKO2gr+Tcwq4yFPdVgUqD04dWYQZFthXPg==; 5:mNYy8WcabpcuXmSpLo8JJJZsvj4ELf63C5JH3DXJzR7Pcia31XGxCSdskM0lmRrhVu7++gbcguym3En8zyW3YSD7c5U+8+WRS2QKfR/ADJUtQVKqfUG56UPCp/DZ9VQwe6IE4pzrIOy+ojiJx/MnIUP2GT1nVn1WbBYoDdrmWqE=; 7:WABXWELKq5Uor/MgvY/RdRIhGK7UFE63BJuGuEzIhaaAiywkusLHN/GSL4lGW0qQ86GAo544myS/fqlyBtnARxnaKnfaAv6Lx7Dofiuduz4UfQEeQZDCQQQSopdl52WHbJfukBKbXGePYzagvFJQ1Q==
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Nov 2018 09:55:31.3446 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: cd7898a8-7f5d-4c64-23f7-08d643cdfd20
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.13];  Helo=[P-EXFEND-EQX-02.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR05MB4894
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-06_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811060087
Archived-At: 
Subject: Re: [netmod] draft-wu-netmod-factory-default-01: Actually resetting the device to factory defaults
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 10:45:27 -0000

On Nov 06 04:41 AM, Carey, Timothy (Nokia - US) wrote:
> Hi,
> 
> In the IETF 103 meeting a comment was made that using the reset-datastore RPC doesn't actually reset the device to factory settings.
> 
> I would like to suggest that this RPC when applied to the start-up store have the capability to actually reset the device the factory settings.
> 
> This might require a device reboot to finalize the action but we do need an option that I can actually place the device in a configuration
> That resembles the device when it first arrives from the "factory". I would believe this would be the main use case for this type of reset-datastore operation.
> 
> Did I misunderstand the comment?
> 
> BR,
> Tim
> 

Correct - I haven't read this draft yet but it sounds like the focus so
far is specific to default datastore configuration only which imo is
very close to an edit/load of an implementation specific default
configuration + commit action

Resetting an entire device to factory defaults involves many more things
such as wiping the filesystem (or portions of) e.g. logs, scripts,
user-added files, etc.. in addition

So to your point, I agree - the scope should be expanded to entire
device factory defaults

/ebben


From nobody Tue Nov  6 06:16: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 82F26130E1E for ; Tue,  6 Nov 2018 06:16:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ocEMcTe-UFP1 for ; Tue,  6 Nov 2018 06:16: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 10DCB130E12 for ; Tue,  6 Nov 2018 06:16:18 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 8A666E0B; Tue,  6 Nov 2018 15:16: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 0KyeUfbPM611; Tue,  6 Nov 2018 15:16:13 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue,  6 Nov 2018 15:16:16 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 717132003F; Tue,  6 Nov 2018 15:16:16 +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 MaQYmU5CAnro; Tue,  6 Nov 2018 15:16:15 +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 7E0542003C; Tue,  6 Nov 2018 15:16: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, 6 Nov 2018 15:16:15 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 8617D3003AEAED; Tue,  6 Nov 2018 15:16:14 +0100 (CET)
Date: Tue, 6 Nov 2018 15:16:13 +0100
From: Juergen Schoenwaelder 
To: "Yemin (Amy)" 
CC: Qin Wu , Xufeng Liu , "balazs.lengyel@ericsson.com" , NETMOD WG 
Message-ID: <20181106141613.zqy5xmq7qvahzzpz@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "Yemin (Amy)" , Qin Wu , Xufeng Liu , "balazs.lengyel@ericsson.com" , NETMOD WG 
References:  <9C5FD3EFA72E1740A3D41BADDE0B461FCFA7803B@DGGEMM528-MBX.china.huawei.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: <9C5FD3EFA72E1740A3D41BADDE0B461FCFA7803B@DGGEMM528-MBX.china.huawei.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB02.jacobs.jacobs-university.de (10.70.0.121) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 14:16:22 -0000

Well, the draft-ye-ccamp-mw-topo-yang-02 definition excludes 100%,
which is likely not generally useful. In fact, even 150% can be in
some contexts a perfectly sensible percentage. So we may need to
provide some flexibility here, i.e., having a base time where the
range can be refined and refined types with an upper limit set to 100%
for use in situations where this limit is sensible.

The more difficult aspect seems to be precision, I am not sure YANG
allows subtyping the fractional part. RFC 7950 seems to be silent
about this and in the general case this would not be meaningful. But
in this particular case, when the number range is limited, it would
actually be OK to allow this (but then we have to have a limit and
we can't set the upper limit to max).

/js

On Tue, Nov 06, 2018 at 02:21:33AM +0000, Yemin (Amy) wrote:
> If the percentage is defined as following, as a author of draft-ye-ccamp-mw-topo-yang-02, we will be happy to use it.
> But it's better to include in RFC6991bis, as percentage is a generic and widely used item.
> 
> BR,
> Amy
> ________________________________
> 发件人: netmod [netmod-bounces@ietf.org] 代表 Qin Wu [bill.wu@huawei.com]
> 发送时间: 2018年11月6日 9:25
> 收件人: Xufeng Liu; balazs.lengyel@ericsson.com
> 抄送: NETMOD WG
> 主题: Re: [netmod] for a future rfc6991bis
> 
> 
> Another case would be :
> 
> 
> “
> 
> typedef percentage {
> 
>       type decimal64 {
> 
>          fraction-digits 5;
> 
>          range "0..100";
> 
>      }
> 
>    description "Percentage.";
>    }
> ”
> Which is defined ietf-connectionless-oam.yang module.
> 
> -Qin
> 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Xufeng Liu
> 发送时间: 2018年11月6日 3:49
> 收件人: balazs.lengyel@ericsson.com
> 抄送: NETMOD WG 
> 主题: Re: [netmod] for a future rfc6991bis
> 
> The draft that asked for the percentage type is: https://tools.ietf.org/html/draft-ye-ccamp-mw-topo-yang-02
> 
> They currently define:
> 
>               leaf availability {
>                 type decimal64 {
>                   fraction-digits 4;
>                   range "0..99.9999";
>                 }
>                 description "Availability level of the link";
>               }
> 
> Thanks,
> - Xufeng
> 
> On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel > wrote:
> 
> +1 to percentage.
> 
> Balazs
> On 2018. 11. 03. 3:44, Xufeng Liu wrote:
> Remember that some draft asked for a type of percentage value to the nearest hundredth. Wondering if it can be put in.
> 
> Thanks,
> - Xufeng
> 
> On Fri, Nov 2, 2018 at 11:39 AM tom petch > wrote:
> ---- Original Message -----
> From: "Juergen Schoenwaelder" >
> To: "Kent Watsen" >
> Cc: >
> Sent: Tuesday, October 30, 2018 10:14 AM
> 
> > On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen wrote:
> > >
> > > >> In addition, it might be good to introduce [inet?] types for RFC
> 5322
> > > >> (Internet Message Format) including perhaps:
> > > >>
> > > >>   - email-address        (addr-spec, per Section 3.4.1)
> > > >>   - named-email-address  (name-addr, per Section 3.4)
> > > >>
> > > >
> > > > Where are these used? Or have these already been used somewhere?
> > >
> > > I'm unaware of these ever having been used before.  I am working on
> a private module for which I want to configure an email address.  After
> some searching, I concluded that no such types have been defined, and
> thus thought that they might be good candidates for addition.
> 
> 
> We could defined a user-name, of the form localpart@domainpart as is
> widely used to identify a user in operations but which does not, in my
> experience, owe anything to i18n, just a straightforward character set;
> yes it would not boil the ocean, but could be useful.  I am surprised
> not to find such a definition somewhere in our 40 or so NETCONF I-Ds.
> 
> Tom Petch
> 
> 
> 
> 
> 
> 
> 
> > >
> >
> > It would be good to have strong use cases. I fear that defining this
> > type won't be easy given that we also have internationalized email
> > addresses (RFC 6530 provides an overview) and we might have to create
> > a union of RFC 5322 addresses and "SMTPUTF8 (compliant) addresses".
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         
> >
> > _______________________________________________
> > 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

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


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


From nobody Tue Nov  6 09:31: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 26FEE12F1AB for ; Tue,  6 Nov 2018 09:31:27 -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=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 5DOLg8SMa-tW for ; Tue,  6 Nov 2018 09:31:23 -0800 (PST)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0949E130934 for ; Tue,  6 Nov 2018 09:31:23 -0800 (PST)
Received: by mail-lj1-x234.google.com with SMTP id z80-v6so12189200ljb.8 for ; Tue, 06 Nov 2018 09:31:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=lVcYmI2b7ylyA2XesBidy9gTKYhgN8I7ga9A5rbL1EY=; b=WDNSePvgK9BqWVNcP6giWTyeBwxHimdNN02mSDKn+AVG9rC46PeuV0aA21lodNkWPd sosq3W2uwjBNb1InQWohkQWIr4I3kGBDJIHpNBXLmLBF4jzDnTFItEsohcUJNTI83jW6 IHhGwL2lO7F30lPaf2ETGuRxkJCuv4m1CviWXd0YoebzeHRs2fNJQqrrkbvkwQq2wDlk HOya2sqmtuzuuJc8H5Rp89kEcRI+c1QY56uGqZxymYMsuXjboAQ1ySiBJYGGUxWbmbl0 gn1AiaDB+OeYnyprogYJtTMWT1WMtuSX8JLa96eHdNAxj4ShLfAkxF3AoCr+MHpQGtvi eflA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lVcYmI2b7ylyA2XesBidy9gTKYhgN8I7ga9A5rbL1EY=; b=BnY8c0FIWeo3bEcwEiPjYb8l7OzCe2rz+6vylveZ/4V3EvZF28NHP+ISrK6bQcGo3S eyOiDz/M+57qWLmQ6qrOOzMgWqPuaYOzdTnnXxZgRAGRCABJSPQFstxMo+Ujq1OzUHLU h3Rdb2ujOjtHXCSi5Cxx+t4VKvIrf5YRiG9Zb8ikEJu4CXI79tvVnLUeLzI/K3/yQ+fe gkAHccgCDmzCiIot8SHH/Kqi91JNjF1bRFjeSsZqNLis9dM4z3deBCgcqqpmt95deLnS /ogS4iIBL55cNQPanWeAkrgvfvg4Z1MgjJn3I/7p3+iKiByf3w39iAkNa9TwVcWK21oy VjSg==
X-Gm-Message-State: AGRZ1gKNkvGmQCzbCRpqyVd3uXgUtY3hTKH/9M46hofEPA0bic4B94yO z2hCiOJIwE+dKo1xJ76T7WyFweBGTPMK4KBxHcnxUhD5
X-Google-Smtp-Source: AJdET5eJJzjnZ6t0iwh6vqPZvUfPdlzzn+a2ZRqRLZ/rchQj2zvyi9BtvYhgl49r3agP8BJWWIbX9v45i3qJfEqPt58=
X-Received: by 2002:a2e:2019:: with SMTP id g25-v6mr16708398ljg.20.1541525480483;  Tue, 06 Nov 2018 09:31:20 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Tue, 6 Nov 2018 09:31:19 -0800 (PST)
From: Andy Bierman 
Date: Tue, 6 Nov 2018 09:31:19 -0800
Message-ID: 
To: NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000ad4e3f057a025ea0"
Archived-At: 
Subject: [netmod] Issues with draft-ietf-netmod-nmda-diff-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 17:31:27 -0000

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

Hi,

I understand the WG is going to delay this work 1 or 2 meetings to
see if any proposals for a diff format are proposed.

Any diff command assumes some algorithm that requires:
  (1) copy of the source document
  (2) set of diffs against the source document
  (3) procedure for applying diffs

With this information the tool can produce the target document.

The WG has to decide if this  operation is for
textual representation of a datastore or is it a conceptual compare
of a datastore.  They are not the same.

The first problem that comes up with a textual compare is document order.
There is no defined order for top-level data nodes within a datastore.
There is no defined order for augmenting nodes which are siblings.

The next problem is that some data types have no canonical representation.

A textual compare will be affected by both types of false positives.

So while we are waiting up to 8 months for proposals...
What problem is this new diff format trying to solve?


Andy

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


Hi,

I understand the WG is going to del=
ay this work 1 or 2 meetings to
see if any proposals for a diff f=
ormat are proposed.

Any diff command assumes some =
algorithm that requires:
=C2=A0 (1) copy of the source document
=C2=A0 (2) set of diffs against the source document
=C2=
=A0 (3) procedure for applying diffs

With this inf=
ormation the tool can produce the target document.

The WG has to decide if this <compare> operation is for
te=
xtual representation of a datastore or is it a conceptual compare
of a datastore.=C2=A0 They are not the same.

The =
first problem that comes up with a textual compare is document order.
=

There is no defined order for top-level data nodes within a datastore.=

There is no defined order for augmenting nodes which are sibling=
s.

The next problem is that some data types have n=
o canonical representation.

A textual compare will=
 be affected by both types of false positives.

So =
while we are waiting up to 8 months for proposals...
What problem=
 is this new diff format trying to solve?


Andy



--000000000000ad4e3f057a025ea0--


From nobody Tue Nov  6 09:41: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 08BC8130DC1 for ; Tue,  6 Nov 2018 09:41:48 -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 d8SvII_kQjMe for ; Tue,  6 Nov 2018 09:41:45 -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 608E012F1AB for ; Tue,  6 Nov 2018 09:41:45 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id F072BE33; Tue,  6 Nov 2018 18:41:43 +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 8LX3HXepnqhg; Tue,  6 Nov 2018 18:41:40 +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,  6 Nov 2018 18:41:43 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA91D2003D; Tue,  6 Nov 2018 18:41:43 +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 dssacwjBy0ME; Tue,  6 Nov 2018 18:41:43 +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 954362003C; Tue,  6 Nov 2018 18:41:43 +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, 6 Nov 2018 18:41:43 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 01C1C3003AF20D; Tue,  6 Nov 2018 18:41:42 +0100 (CET)
Date: Tue, 6 Nov 2018 18:41:42 +0100
From: Juergen Schoenwaelder 
To: Andy Bierman 
CC: NetMod WG 
Message-ID: <20181106174142.g5gqcisok4gote5k@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , NetMod WG 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Issues with draft-ietf-netmod-nmda-diff-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 06 Nov 2018 17:41:48 -0000

On Tue, Nov 06, 2018 at 09:31:19AM -0800, Andy Bierman wrote:
> 
> The next problem is that some data types have no canonical representation.
> 

YANG requires a canonical format, xpath expressions for example are
evaluated against the canonical representation. Data types that have
no canonical representation need to be fixed if we want interoperable
behaviour (independent of any diff solutions).

That said, I tend to agree with your other points that diff should be
calculated on the data tree and not its serialization and that a diff
and patch algorithm has to be smart to take different orders, that are
entirely possible, into account (unless we want to go down the path of
defining a canonical order for the tree itself, which I expect to hit
quite some resistance).

/js

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


From nobody Tue Nov  6 18:39:06 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 0B89C130EB4; Tue,  6 Nov 2018 18:38:59 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.3
Auto-Submitted: auto-generated
Precedence: bulk
Cc: ibagdona@gmail.com, netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org, The IESG , Kent Watsen ,  draft-ietf-netmod-acl-model@ietf.org, rfc-editor@rfc-editor.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <154155833903.30893.8408096708188000290.idtracker@ietfa.amsl.com>
Date: Tue, 06 Nov 2018 18:38:59 -0800
Archived-At: 
Subject: [netmod] Protocol Action: 'Network Access Control List (ACL) YANG Data Model' to Proposed Standard (draft-ietf-netmod-acl-model-21.txt)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Nov 2018 02:39:04 -0000

The IESG has approved the following document:
- 'Network Access Control List (ACL) YANG Data Model'
  (draft-ietf-netmod-acl-model-21.txt) as Proposed Standard

This document is the product of the Network Modeling Working Group.

The IESG contact persons are Warren Kumari and Ignas Bagdonas.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/




Technical Summary

This document defines YANG data model for Access Control Lists. An ACL is a user-defined ordered set of packet field matching criteria used to control the packet processing behavior of the network element. ACLs define matching rules and actions that will be performed on the packets.


Working Group Summary

The document defines YANG ACL data model that is considered to be uniform enough across the majority of implementations. There is no goal to align to the platform implementation specifics and particular vendor extensions. WG has reached a consensus that the functionality covered is sufficient and generic enough to be practically implementable and usable.  


Document Quality

There are existing implementations in both closed and open source products, and a general agreement that this model will see more implementations. The document has been in active development and refinement for 4 years and there are no major concerns left. 


Personnel

Responsible Area Director is Ignas Bagdonas. Document shepherd is Kent Watsen. The document adds new YANG module namespace URIs to the existing IETF registries. 





From nobody Tue Nov  6 23:50:14 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACD0129619 for ; Tue,  6 Nov 2018 23:50:12 -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 SXeRXCqV51w3 for ; Tue,  6 Nov 2018 23:50:06 -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 F033F127333 for ; Tue,  6 Nov 2018 23:50:05 -0800 (PST)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A0C5B5D8B79FD; Wed,  7 Nov 2018 07:50:02 +0000 (GMT)
Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 7 Nov 2018 07:50:02 +0000
Received: from DGGEMM528-MBX.china.huawei.com ([169.254.8.232]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0415.000; Wed, 7 Nov 2018 15:49:54 +0800
From: "Yemin (Amy)" 
To: Juergen Schoenwaelder 
CC: Qin Wu , Xufeng Liu , "balazs.lengyel@ericsson.com" , NETMOD WG 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AdR1b1B75pZToCjlLEK5aT+9YAPiFwAB1JzUAAhlL4AANTEPSw==
Date: Wed, 7 Nov 2018 07:49:54 +0000
Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461FCFA78BFA@DGGEMM528-MBX.china.huawei.com>
References:  <9C5FD3EFA72E1740A3D41BADDE0B461FCFA7803B@DGGEMM528-MBX.china.huawei.com>, <20181106141613.zqy5xmq7qvahzzpz@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181106141613.zqy5xmq7qvahzzpz@anna.jacobs.jacobs-university.de>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.126.173.20]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Nov 2018 07:50:13 -0000

SGkgSnVlcmdlbiwKCldoYXQgd2UgZG9uJ3QgbGlrZSBpbiBjdXJyZW50IFJGQzY5OTEgaXMgdGhl
IHR5cGUgaXMgdWludDggd2hpY2ggZG9lc24ndCBhbGxvdyBmcmFjdGlvbi4gCkZvciB0aGUgcmFu
Z2UsIGlmIHRoZSBkZWZpbnRpb24gY2FuIGNvdmVyIHRoZSBvdXIgcmFuZ2UoMC4uOTkuOTk5OSks
IGl0IHdpbGwgYmUgYWNjZXB0YWJsZS4gCkluIHlvdXIgc3VnZ2VzdGlvbiBiZWxvdywgZG9lcyB0
aGF0IG1lYW4gdGhlIGJhc2UgZGVmaW50aW9uIGlzIHdpdGhvdXQgcmFuZ2UsIHdoaWxlIHJlZmlu
ZWQgdHlwZXMgY2FuIGNob3NzZSB0aGUgcmFuZ2UgdGhleSBsaWtlPwoKQlIsCkFteQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCreivP7IyzogSnVlcmdlbiBTY2hvZW53
YWVsZGVyIFtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGVdCreiy83KsbzkOiAy
MDE4xOoxMdTCNsjVIDIyOjE2CsrVvP7IyzogWWVtaW4gKEFteSkKs63LzTogUWluIFd1OyBYdWZl
bmcgTGl1OyBiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb207IE5FVE1PRCBXRwrW98ziOiBSZTog
W25ldG1vZF0gZm9yIGEgZnV0dXJlIHJmYzY5OTFiaXMKCldlbGwsIHRoZSBkcmFmdC15ZS1jY2Ft
cC1tdy10b3BvLXlhbmctMDIgZGVmaW5pdGlvbiBleGNsdWRlcyAxMDAlLAp3aGljaCBpcyBsaWtl
bHkgbm90IGdlbmVyYWxseSB1c2VmdWwuIEluIGZhY3QsIGV2ZW4gMTUwJSBjYW4gYmUgaW4Kc29t
ZSBjb250ZXh0cyBhIHBlcmZlY3RseSBzZW5zaWJsZSBwZXJjZW50YWdlLiBTbyB3ZSBtYXkgbmVl
ZCB0bwpwcm92aWRlIHNvbWUgZmxleGliaWxpdHkgaGVyZSwgaS5lLiwgaGF2aW5nIGEgYmFzZSB0
aW1lIHdoZXJlIHRoZQpyYW5nZSBjYW4gYmUgcmVmaW5lZCBhbmQgcmVmaW5lZCB0eXBlcyB3aXRo
IGFuIHVwcGVyIGxpbWl0IHNldCB0byAxMDAlCmZvciB1c2UgaW4gc2l0dWF0aW9ucyB3aGVyZSB0
aGlzIGxpbWl0IGlzIHNlbnNpYmxlLgoKVGhlIG1vcmUgZGlmZmljdWx0IGFzcGVjdCBzZWVtcyB0
byBiZSBwcmVjaXNpb24sIEkgYW0gbm90IHN1cmUgWUFORwphbGxvd3Mgc3VidHlwaW5nIHRoZSBm
cmFjdGlvbmFsIHBhcnQuIFJGQyA3OTUwIHNlZW1zIHRvIGJlIHNpbGVudAphYm91dCB0aGlzIGFu
ZCBpbiB0aGUgZ2VuZXJhbCBjYXNlIHRoaXMgd291bGQgbm90IGJlIG1lYW5pbmdmdWwuIEJ1dApp
biB0aGlzIHBhcnRpY3VsYXIgY2FzZSwgd2hlbiB0aGUgbnVtYmVyIHJhbmdlIGlzIGxpbWl0ZWQs
IGl0IHdvdWxkCmFjdHVhbGx5IGJlIE9LIHRvIGFsbG93IHRoaXMgKGJ1dCB0aGVuIHdlIGhhdmUg
dG8gaGF2ZSBhIGxpbWl0IGFuZAp3ZSBjYW4ndCBzZXQgdGhlIHVwcGVyIGxpbWl0IHRvIG1heCku
CgovanMKCk9uIFR1ZSwgTm92IDA2LCAyMDE4IGF0IDAyOjIxOjMzQU0gKzAwMDAsIFllbWluIChB
bXkpIHdyb3RlOgo+IElmIHRoZSBwZXJjZW50YWdlIGlzIGRlZmluZWQgYXMgZm9sbG93aW5nLCBh
cyBhIGF1dGhvciBvZiBkcmFmdC15ZS1jY2FtcC1tdy10b3BvLXlhbmctMDIsIHdlIHdpbGwgYmUg
aGFwcHkgdG8gdXNlIGl0Lgo+IEJ1dCBpdCdzIGJldHRlciB0byBpbmNsdWRlIGluIFJGQzY5OTFi
aXMsIGFzIHBlcmNlbnRhZ2UgaXMgYSBnZW5lcmljIGFuZCB3aWRlbHkgdXNlZCBpdGVtLgo+Cj4g
QlIsCj4gQW15Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiC3orz+yMs6IG5l
dG1vZCBbbmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gUWluIFd1IFtiaWxsLnd1QGh1YXdl
aS5jb21dCj4gt6LLzcqxvOQ6IDIwMTjE6jEx1MI2yNUgOToyNQo+IMrVvP7IyzogWHVmZW5nIExp
dTsgYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tCj4gs63LzTogTkVUTU9EIFdHCj4g1vfM4jog
UmU6IFtuZXRtb2RdIGZvciBhIGZ1dHVyZSByZmM2OTkxYmlzCj4KPgo+IEFub3RoZXIgY2FzZSB3
b3VsZCBiZSA6Cj4KPgo+IKGwCj4KPiB0eXBlZGVmIHBlcmNlbnRhZ2Ugewo+Cj4gICAgICAgdHlw
ZSBkZWNpbWFsNjQgewo+Cj4gICAgICAgICAgZnJhY3Rpb24tZGlnaXRzIDU7Cj4KPiAgICAgICAg
ICByYW5nZSAiMC4uMTAwIjsKPgo+ICAgICAgfQo+Cj4gICAgZGVzY3JpcHRpb24gIlBlcmNlbnRh
Z2UuIjsKPiAgICB9Cj4gobEKPiBXaGljaCBpcyBkZWZpbmVkIGlldGYtY29ubmVjdGlvbmxlc3Mt
b2FtLnlhbmcgbW9kdWxlLgo+Cj4gLVFpbgo+ILeivP7IyzogbmV0bW9kIFttYWlsdG86bmV0bW9k
LWJvdW5jZXNAaWV0Zi5vcmddILT6se0gWHVmZW5nIExpdQo+ILeiy83KsbzkOiAyMDE4xOoxMdTC
NsjVIDM6NDkKPiDK1bz+yMs6IGJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbQo+ILOty806IE5F
VE1PRCBXRyA8bmV0bW9kQGlldGYub3JnPgo+INb3zOI6IFJlOiBbbmV0bW9kXSBmb3IgYSBmdXR1
cmUgcmZjNjk5MWJpcwo+Cj4gVGhlIGRyYWZ0IHRoYXQgYXNrZWQgZm9yIHRoZSBwZXJjZW50YWdl
IHR5cGUgaXM6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15ZS1jY2FtcC1tdy10
b3BvLXlhbmctMDIKPgo+IFRoZXkgY3VycmVudGx5IGRlZmluZToKPgo+ICAgICAgICAgICAgICAg
bGVhZiBhdmFpbGFiaWxpdHkgewo+ICAgICAgICAgICAgICAgICB0eXBlIGRlY2ltYWw2NCB7Cj4g
ICAgICAgICAgICAgICAgICAgZnJhY3Rpb24tZGlnaXRzIDQ7Cj4gICAgICAgICAgICAgICAgICAg
cmFuZ2UgIjAuLjk5Ljk5OTkiOwo+ICAgICAgICAgICAgICAgICB9Cj4gICAgICAgICAgICAgICAg
IGRlc2NyaXB0aW9uICJBdmFpbGFiaWxpdHkgbGV2ZWwgb2YgdGhlIGxpbmsiOwo+ICAgICAgICAg
ICAgICAgfQo+Cj4gVGhhbmtzLAo+IC0gWHVmZW5nCj4KPiBPbiBTdW4sIE5vdiA0LCAyMDE4IGF0
IDc6MDcgQU0gQmFsqKJ6cyBMZW5neWVsIDxiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb208bWFp
bHRvOmJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbT4+IHdyb3RlOgo+Cj4gKzEgdG8gcGVyY2Vu
dGFnZS4KPgo+IEJhbGF6cwo+IE9uIDIwMTguIDExLiAwMy4gMzo0NCwgWHVmZW5nIExpdSB3cm90
ZToKPiBSZW1lbWJlciB0aGF0IHNvbWUgZHJhZnQgYXNrZWQgZm9yIGEgdHlwZSBvZiBwZXJjZW50
YWdlIHZhbHVlIHRvIHRoZSBuZWFyZXN0IGh1bmRyZWR0aC4gV29uZGVyaW5nIGlmIGl0IGNhbiBi
ZSBwdXQgaW4uCj4KPiBUaGFua3MsCj4gLSBYdWZlbmcKPgo+IE9uIEZyaSwgTm92IDIsIDIwMTgg
YXQgMTE6MzkgQU0gdG9tIHBldGNoIDxpZXRmY0BidGNvbm5lY3QuY29tPG1haWx0bzppZXRmY0Bi
dGNvbm5lY3QuY29tPj4gd3JvdGU6Cj4gLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJv
bTogIkp1ZXJnZW4gU2Nob2Vud2FlbGRlciIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVy
c2l0eS5kZTxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4KPiBU
bzogIktlbnQgV2F0c2VuIiA8a3dhdHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBqdW5p
cGVyLi5uZXQ+Pgo+IENjOiA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+
Pgo+IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMzAsIDIwMTggMTA6MTQgQU0KPgo+ID4gT24gVHVl
LCBPY3QgMzAsIDIwMTggYXQgMTI6MDU6MTdBTSArMDAwMCwgS2VudCBXYXRzZW4gd3JvdGU6Cj4g
PiA+Cj4gPiA+ID4+IEluIGFkZGl0aW9uLCBpdCBtaWdodCBiZSBnb29kIHRvIGludHJvZHVjZSBb
aW5ldD9dIHR5cGVzIGZvciBSRkMKPiA1MzIyCj4gPiA+ID4+IChJbnRlcm5ldCBNZXNzYWdlIEZv
cm1hdCkgaW5jbHVkaW5nIHBlcmhhcHM6Cj4gPiA+ID4+Cj4gPiA+ID4+ICAgLSBlbWFpbC1hZGRy
ZXNzICAgICAgICAoYWRkci1zcGVjLCBwZXIgU2VjdGlvbiAzLjQuMSkKPiA+ID4gPj4gICAtIG5h
bWVkLWVtYWlsLWFkZHJlc3MgIChuYW1lLWFkZHIsIHBlciBTZWN0aW9uIDMuNCkKPiA+ID4gPj4K
PiA+ID4gPgo+ID4gPiA+IFdoZXJlIGFyZSB0aGVzZSB1c2VkPyBPciBoYXZlIHRoZXNlIGFscmVh
ZHkgYmVlbiB1c2VkIHNvbWV3aGVyZT8KPiA+ID4KPiA+ID4gSSdtIHVuYXdhcmUgb2YgdGhlc2Ug
ZXZlciBoYXZpbmcgYmVlbiB1c2VkIGJlZm9yZS4gIEkgYW0gd29ya2luZyBvbgo+IGEgcHJpdmF0
ZSBtb2R1bGUgZm9yIHdoaWNoIEkgd2FudCB0byBjb25maWd1cmUgYW4gZW1haWwgYWRkcmVzcy4g
IEFmdGVyCj4gc29tZSBzZWFyY2hpbmcsIEkgY29uY2x1ZGVkIHRoYXQgbm8gc3VjaCB0eXBlcyBo
YXZlIGJlZW4gZGVmaW5lZCwgYW5kCj4gdGh1cyB0aG91Z2h0IHRoYXQgdGhleSBtaWdodCBiZSBn
b29kIGNhbmRpZGF0ZXMgZm9yIGFkZGl0aW9uLgo+Cj4KPiBXZSBjb3VsZCBkZWZpbmVkIGEgdXNl
ci1uYW1lLCBvZiB0aGUgZm9ybSBsb2NhbHBhcnRAZG9tYWlucGFydCBhcyBpcwo+IHdpZGVseSB1
c2VkIHRvIGlkZW50aWZ5IGEgdXNlciBpbiBvcGVyYXRpb25zIGJ1dCB3aGljaCBkb2VzIG5vdCwg
aW4gbXkKPiBleHBlcmllbmNlLCBvd2UgYW55dGhpbmcgdG8gaTE4biwganVzdCBhIHN0cmFpZ2h0
Zm9yd2FyZCBjaGFyYWN0ZXIgc2V0Owo+IHllcyBpdCB3b3VsZCBub3QgYm9pbCB0aGUgb2NlYW4s
IGJ1dCBjb3VsZCBiZSB1c2VmdWwuICBJIGFtIHN1cnByaXNlZAo+IG5vdCB0byBmaW5kIHN1Y2gg
YSBkZWZpbml0aW9uIHNvbWV3aGVyZSBpbiBvdXIgNDAgb3Igc28gTkVUQ09ORiBJLURzLgo+Cj4g
VG9tIFBldGNoCj4KPgo+Cj4KPgo+Cj4KPiA+ID4KPiA+Cj4gPiBJdCB3b3VsZCBiZSBnb29kIHRv
IGhhdmUgc3Ryb25nIHVzZSBjYXNlcy4gSSBmZWFyIHRoYXQgZGVmaW5pbmcgdGhpcwo+ID4gdHlw
ZSB3b24ndCBiZSBlYXN5IGdpdmVuIHRoYXQgd2UgYWxzbyBoYXZlIGludGVybmF0aW9uYWxpemVk
IGVtYWlsCj4gPiBhZGRyZXNzZXMgKFJGQyA2NTMwIHByb3ZpZGVzIGFuIG92ZXJ2aWV3KSBhbmQg
d2UgbWlnaHQgaGF2ZSB0byBjcmVhdGUKPiA+IGEgdW5pb24gb2YgUkZDIDUzMjIgYWRkcmVzc2Vz
IGFuZCAiU01UUFVURjggKGNvbXBsaWFudCkgYWRkcmVzc2VzIi4KPiA+Cj4gPiAvanMKPiA+Cj4g
PiAtLQo+ID4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0
eSBCcmVtZW4gZ0dtYkgKPiA+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVz
IFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkKPiA+IEZheDogICArNDkgNDIxIDIwMCAz
MTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4KPiA+Cj4gPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID4gbmV0bW9k
IG1haWxpbmcgbGlzdAo+ID4gbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+
Cj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo+Cj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBuZXRtb2QgbWFp
bGluZyBsaXN0Cj4gbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Cj4gaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKPgo+Cj4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPgo+IG5ldG1vZCBtYWlsaW5n
IGxpc3QKPgo+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPgo+Cj4gaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8VXJsQmxvY2tlZEVycm9y
LmFzcHg+Cj4KPiAtLQo+Cj4gQmFsYXpzIExlbmd5ZWwgICAgICAgICAgICAgICAgICAgICAgIEVy
aWNzc29uIEh1bmdhcnkgTHRkLgo+Cj4gU2VuaW9yIFNwZWNpYWxpc3QKPgo+IE1vYmlsZTogKzM2
LTcwLTMzMC03OTA5ICAgICAgICAgICAgICBlbWFpbDogQmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24u
Y29tPG1haWx0bzpCYWxhenMuTGVuZ3llbEBlcmljc3Nvbi5jb20+Cgo+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gbmV0bW9kIG1haWxpbmcgbGlzdAo+
IG5ldG1vZEBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
bmV0bW9kCgoKLS0KSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVy
c2l0eSBCcmVtZW4gZ0dtYkgKUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMg
UmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAg
ICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+Cg==


From nobody Wed Nov  7 00:34: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 BA436128BCC for ; Wed,  7 Nov 2018 00:34:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cf3tOsnXuu_x for ; Wed,  7 Nov 2018 00:34:06 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32CAD128B14 for ; Wed,  7 Nov 2018 00:34:06 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 4A835E94; Wed,  7 Nov 2018 09:34:04 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id phgYzwEN-zYO; Wed,  7 Nov 2018 09:34:03 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed,  7 Nov 2018 09:34:04 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 321582003D; Wed,  7 Nov 2018 09:34:04 +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 tJ-Twjo3-V5r; Wed,  7 Nov 2018 09:34:03 +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 CFACB2003C; Wed,  7 Nov 2018 09:34:02 +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, 7 Nov 2018 09:34:02 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 22F643003B0901; Wed,  7 Nov 2018 09:34:01 +0100 (CET)
Date: Wed, 7 Nov 2018 09:34:01 +0100
From: Juergen Schoenwaelder 
To: "Yemin (Amy)" 
CC: Qin Wu , Xufeng Liu , "balazs.lengyel@ericsson.com" , NETMOD WG 
Message-ID: <20181107083401.7bqbjnewg3syd6dj@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "Yemin (Amy)" , Qin Wu , Xufeng Liu , "balazs.lengyel@ericsson.com" , NETMOD WG 
References:  <9C5FD3EFA72E1740A3D41BADDE0B461FCFA7803B@DGGEMM528-MBX.china.huawei.com> <20181106141613.zqy5xmq7qvahzzpz@anna.jacobs.jacobs-university.de> <9C5FD3EFA72E1740A3D41BADDE0B461FCFA78BFA@DGGEMM528-MBX.china.huawei.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: <9C5FD3EFA72E1740A3D41BADDE0B461FCFA78BFA@DGGEMM528-MBX.china.huawei.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Nov 2018 08:34:10 -0000

On Wed, Nov 07, 2018 at 07:49:54AM +0000, Yemin (Amy) wrote:

> For the range, if the defintion can cover the our range(0..99.9999),
> it will be acceptable.  In your suggestion below, does that mean the
> base defintion is without range, while refined types can chosse the
> range they like?

I was thinking loud. Let me detail somewhat more what was going on in
my head:

  We could define a percent type without the upper bound being
  whatever the decimal covers but fixing the precision of the
  fractional part. We could then narrow the upper bound via
  subtyping:

     typedef percent {
       type decimal {
         fraction-digits 4;
         range "0..max";
       }
     }

     typedef percent' {
       type percent { range 0..100; }
     }

  If wanted flexibility on the fractional part, we could define
  percent with a fixed range and the largest number of fraction digits
  possible and then we could subtype this to obtain a precision that
  makes sense in the usage contexts (although it is not clear whether
  YANG 1.1 really allows this, if not this may be just due to nobody
  ever thinking about this before):

    typedef percent {
      type decimal {
        fraction-digits 16;
        range 0..100;
      }
    }

    typedef percent' {
      type percent { fraction-digits 4; }
    }

  An ideal solution would provide flexibility both on the range and
  the number of fraction digits but it seems this is impossible since
  these two properties (range and precision) interact.

So it seems we have to do something that is pragmatic and this likely
means fixing the fraction since subtyping the fractional part may not
be allowed by YANG or not be supported by implementations. The
question is then how we pick suitable fractions. I understand you want
4 digits.

/js

> BR,
> Amy
> ________________________________________
> 发件人: Juergen Schoenwaelder [j.schoenwaelder@jacobs-university.de]
> 发送时间: 2018年11月6日 22:16
> 收件人: Yemin (Amy)
> 抄送: Qin Wu; Xufeng Liu; balazs.lengyel@ericsson.com; NETMOD WG
> 主题: Re: [netmod] for a future rfc6991bis
> 
> Well, the draft-ye-ccamp-mw-topo-yang-02 definition excludes 100%,
> which is likely not generally useful. In fact, even 150% can be in
> some contexts a perfectly sensible percentage. So we may need to
> provide some flexibility here, i.e., having a base time where the
> range can be refined and refined types with an upper limit set to 100%
> for use in situations where this limit is sensible.
> 
> The more difficult aspect seems to be precision, I am not sure YANG
> allows subtyping the fractional part. RFC 7950 seems to be silent
> about this and in the general case this would not be meaningful. But
> in this particular case, when the number range is limited, it would
> actually be OK to allow this (but then we have to have a limit and
> we can't set the upper limit to max).
> 
> /js
> 
> On Tue, Nov 06, 2018 at 02:21:33AM +0000, Yemin (Amy) wrote:
> > If the percentage is defined as following, as a author of draft-ye-ccamp-mw-topo-yang-02, we will be happy to use it.
> > But it's better to include in RFC6991bis, as percentage is a generic and widely used item.
> >
> > BR,
> > Amy
> > ________________________________
> > 发件人: netmod [netmod-bounces@ietf.org] 代表 Qin Wu [bill.wu@huawei.com]
> > 发送时间: 2018年11月6日 9:25
> > 收件人: Xufeng Liu; balazs.lengyel@ericsson.com
> > 抄送: NETMOD WG
> > 主题: Re: [netmod] for a future rfc6991bis
> >
> >
> > Another case would be :
> >
> >
> > “
> >
> > typedef percentage {
> >
> >       type decimal64 {
> >
> >          fraction-digits 5;
> >
> >          range "0..100";
> >
> >      }
> >
> >    description "Percentage.";
> >    }
> > ”
> > Which is defined ietf-connectionless-oam.yang module.
> >
> > -Qin
> > 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Xufeng Liu
> > 发送时间: 2018年11月6日 3:49
> > 收件人: balazs.lengyel@ericsson.com
> > 抄送: NETMOD WG 
> > 主题: Re: [netmod] for a future rfc6991bis
> >
> > The draft that asked for the percentage type is: https://tools.ietf.org/html/draft-ye-ccamp-mw-topo-yang-02
> >
> > They currently define:
> >
> >               leaf availability {
> >                 type decimal64 {
> >                   fraction-digits 4;
> >                   range "0..99.9999";
> >                 }
> >                 description "Availability level of the link";
> >               }
> >
> > Thanks,
> > - Xufeng
> >
> > On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel > wrote:
> >
> > +1 to percentage.
> >
> > Balazs
> > On 2018. 11. 03. 3:44, Xufeng Liu wrote:
> > Remember that some draft asked for a type of percentage value to the nearest hundredth. Wondering if it can be put in.
> >
> > Thanks,
> > - Xufeng
> >
> > On Fri, Nov 2, 2018 at 11:39 AM tom petch > wrote:
> > ---- Original Message -----
> > From: "Juergen Schoenwaelder" >
> > To: "Kent Watsen" >
> > Cc: >
> > Sent: Tuesday, October 30, 2018 10:14 AM
> >
> > > On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen wrote:
> > > >
> > > > >> In addition, it might be good to introduce [inet?] types for RFC
> > 5322
> > > > >> (Internet Message Format) including perhaps:
> > > > >>
> > > > >>   - email-address        (addr-spec, per Section 3.4.1)
> > > > >>   - named-email-address  (name-addr, per Section 3.4)
> > > > >>
> > > > >
> > > > > Where are these used? Or have these already been used somewhere?
> > > >
> > > > I'm unaware of these ever having been used before.  I am working on
> > a private module for which I want to configure an email address.  After
> > some searching, I concluded that no such types have been defined, and
> > thus thought that they might be good candidates for addition.
> >
> >
> > We could defined a user-name, of the form localpart@domainpart as is
> > widely used to identify a user in operations but which does not, in my
> > experience, owe anything to i18n, just a straightforward character set;
> > yes it would not boil the ocean, but could be useful.  I am surprised
> > not to find such a definition somewhere in our 40 or so NETCONF I-Ds.
> >
> > Tom Petch
> >
> >
> >
> >
> >
> >
> >
> > > >
> > >
> > > It would be good to have strong use cases. I fear that defining this
> > > type won't be easy given that we also have internationalized email
> > > addresses (RFC 6530 provides an overview) and we might have to create
> > > a union of RFC 5322 addresses and "SMTPUTF8 (compliant) addresses".
> > >
> > > /js
> > >
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   +49 421 200 3103         
> > >
> > > _______________________________________________
> > > 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
> 
> > _______________________________________________
> > 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         

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


From nobody Wed Nov  7 00:57: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 64C291286D9 for ; Wed,  7 Nov 2018 00:57:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outbound.mailhop.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mdFpUhvbQiJ for ; Wed,  7 Nov 2018 00:57:04 -0800 (PST)
Received: from outbound1f.eu.mailhop.org (outbound1f.eu.mailhop.org [52.28.59.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DDE4128B14 for ; Wed,  7 Nov 2018 00:57:03 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1541581021; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=qqYnpKGP7BMJGcf1ji0bzqtE+2QlGX66FMNlsx3Ib1S+zBPKwZp2s0/c+bWSpb04WA8+GFguYoom6 Ihhjg6D/2jBYcoJy9BLG3i6qRrP4CIvXO0MGFFZUFhWd0nxuAw6uYLAayl2Gx7XzDg5UMTMhUCsAjw Y6FSA8jL3galZ5PZWb3Wie0Rb63MdrenTn98avVBlkx2Dyx0v9P1iFmVefsh8MTFWWJwwkzQcD581v 412cEMFfWsj8+ffjf3SLuO1PKVHRTFCFDFCWGjwHIoHaGplyKrjBJ4+uvIHYtLl3w3VvoCP0ZwMBtD zGgRKcisfa4fYt7qqpDllxZftOCKnKQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:cc:references:to:subject:dkim-signature:from; bh=PIwPYErhhO0P4iiKMR34xO40J9lqD+ReyCCny7jnp78=; b=f6hMGZHfXd7gWyV/mkEs5jzId0FIHWnx6Ov93ncOSH6+oZQi7T0lcTLgNne37wzGN+rzX7G97Y4JG WKqPD2HAjQbj5Ia1OFTNbUaKuK34W3YL5wY5kCcG/2vY2IlVPenoNO70m1nKbU7+uc7nOlDfQY74sx gO7r/HqWKr+yAM9npdR7PK7onyESwp2LLuD8LtBMoyeI8IoSYB1vShKrqupijsyQyfxjHKlk4CCMwz e9+Eqat8FI0+NDOQCIF3GZ6wOVjncO0NiYOftMwUfFGf4hhzWgcmofniVX8D4gES+eJWfOPht3jwuQ SRt5NUUslH5Bp8M0gDqEXA0Tpim1o2A==
ARC-Authentication-Results: i=1; outbound1.eu.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.152.101; dmarc=none header.from=hedeland.org; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:cc:references:to:subject:from; bh=PIwPYErhhO0P4iiKMR34xO40J9lqD+ReyCCny7jnp78=; b=WMqN24mbENnmwBMHlZKfoyzO76zbXt37nEOYP7rxNc4Rvy7+op1QBasEEaL/h01y0z1Vd0GH2MSf7 aGMYQ6ONRsnEP/1pLT8mIpo1syTf0lt7OhG9ubTV2bknlPP+E+a6cdNu8sa5dOOLozzMRt8QEnuNHz UvHEsPhF0ZjQpvsGxTA5uh+aOGlpSIR4I2pxGXBtz96uj2oY6+AAz4p3l6z4I2U0PFaHZj9br5TmFP yEBL3F3wNRLRMU+VqjDzLODVO5aT8baTIcEQlD5ClCaWrEq9CD6GWpLJM52iTmdrKlAP1OKRzirnP3 BYfx5aRhczMPwkPOWtOJXgbLlkXWHcQ==
X-MHO-RoutePath: cGVyaGVkZWxhbmQ=
X-MHO-User: 12d61dfc-e26b-11e8-9048-075f73944867
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 81.228.152.101
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from hedeland.org (unknown [81.228.152.101]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 12d61dfc-e26b-11e8-9048-075f73944867; Wed, 07 Nov 2018 08:56:57 +0000 (UTC)
Received: from pluto.hedeland.org (pluto.hedeland.org [10.1.1.5]) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPS id wA78urnV070206 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 7 Nov 2018 09:56:53 +0100 (CET) (envelope-from per@hedeland.org)
To: Juergen Schoenwaelder 
References:  <9C5FD3EFA72E1740A3D41BADDE0B461FCFA7803B@DGGEMM528-MBX.china.huawei.com> <20181106141613.zqy5xmq7qvahzzpz@anna.jacobs.jacobs-university.de> <9C5FD3EFA72E1740A3D41BADDE0B461FCFA78BFA@DGGEMM528-MBX.china.huawei.com> <20181107083401.7bqbjnewg3syd6dj@anna.jacobs.jacobs-university.de>
Cc: NETMOD WG 
From: Per Hedeland 
Message-ID: <839c8311-6560-a792-3d1e-30fb2444a739@hedeland.org>
Date: Wed, 7 Nov 2018 09:56:53 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20181107083401.7bqbjnewg3syd6dj@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Nov 2018 08:57:07 -0000

On 2018-11-07 09:34, Juergen Schoenwaelder wrote:
> On Wed, Nov 07, 2018 at 07:49:54AM +0000, Yemin (Amy) wrote:
> 
>> For the range, if the defintion can cover the our range(0..99.9999),
>> it will be acceptable.  In your suggestion below, does that mean the
>> base defintion is without range, while refined types can chosse the
>> range they like?
> 
> I was thinking loud. Let me detail somewhat more what was going on in
> my head:
> 
>    We could define a percent type without the upper bound being
>    whatever the decimal covers but fixing the precision of the
>    fractional part. We could then narrow the upper bound via
>    subtyping:
> 
>       typedef percent {
>         type decimal {
>           fraction-digits 4;
>           range "0..max";
>         }
>       }
> 
>       typedef percent' {
>         type percent { range 0..100; }
>       }
> 
>    If wanted flexibility on the fractional part, we could define
>    percent with a fixed range and the largest number of fraction digits
>    possible and then we could subtype this to obtain a precision that
>    makes sense in the usage contexts (although it is not clear whether
>    YANG 1.1 really allows this, if not this may be just due to nobody
>    ever thinking about this before):

I believe it is quite clear that this is *not* allowed:

   9.3.3.  Restrictions

      A decimal64 type can be restricted with the "range" statement
      (Section 9.2.4).

--Per

>      typedef percent {
>        type decimal {
>          fraction-digits 16;
>          range 0..100;
>        }
>      }
> 
>      typedef percent' {
>        type percent { fraction-digits 4; }
>      }
> 
>    An ideal solution would provide flexibility both on the range and
>    the number of fraction digits but it seems this is impossible since
>    these two properties (range and precision) interact.
> 
> So it seems we have to do something that is pragmatic and this likely
> means fixing the fraction since subtyping the fractional part may not
> be allowed by YANG or not be supported by implementations. The
> question is then how we pick suitable fractions. I understand you want
> 4 digits.
> 
> /js
> 
>> BR,
>> Amy
>> ________________________________________
>> Ñöº: Juergen Schoenwaelder [j.schoenwaelder@jacobs-university.de]
>> Ñöô: 2018t116å 22:16
>> 6öº: Yemin (Amy)
>> „: Qin Wu; Xufeng Liu; balazs.lengyel@ericsson.com; NETMOD WG
>> ;˜: Re: [netmod] for a future rfc6991bis
>>
>> Well, the draft-ye-ccamp-mw-topo-yang-02 definition excludes 100%,
>> which is likely not generally useful. In fact, even 150% can be in
>> some contexts a perfectly sensible percentage. So we may need to
>> provide some flexibility here, i.e., having a base time where the
>> range can be refined and refined types with an upper limit set to 100%
>> for use in situations where this limit is sensible.
>>
>> The more difficult aspect seems to be precision, I am not sure YANG
>> allows subtyping the fractional part. RFC 7950 seems to be silent
>> about this and in the general case this would not be meaningful. But
>> in this particular case, when the number range is limited, it would
>> actually be OK to allow this (but then we have to have a limit and
>> we can't set the upper limit to max).
>>
>> /js
>>
>> On Tue, Nov 06, 2018 at 02:21:33AM +0000, Yemin (Amy) wrote:
>>> If the percentage is defined as following, as a author of draft-ye-ccamp-mw-topo-yang-02, we will be happy to use it.
>>> But it's better to include in RFC6991bis, as percentage is a generic and widely used item.
>>>
>>> BR,
>>> Amy
>>> ________________________________
>>> Ñöº: netmod [netmod-bounces@ietf.org] ãh Qin Wu [bill.wu@huawei.com]
>>> Ñöô: 2018t116å 9:25
>>> 6öº: Xufeng Liu; balazs.lengyel@ericsson.com
>>> „: NETMOD WG
>>> ;˜: Re: [netmod] for a future rfc6991bis
>>>
>>>
>>> Another case would be :
>>>
>>>
>>> 
>>>
>>> typedef percentage {
>>>
>>>        type decimal64 {
>>>
>>>           fraction-digits 5;
>>>
>>>           range "0..100";
>>>
>>>       }
>>>
>>>     description "Percentage.";
>>>     }
>>> 
>>> Which is defined ietf-connectionless-oam.yang module.
>>>
>>> -Qin
>>> Ñöº: netmod [mailto:netmod-bounces@ietf.org] ãh Xufeng Liu
>>> Ñöô: 2018t116å 3:49
>>> 6öº: balazs.lengyel@ericsson.com
>>> „: NETMOD WG 
>>> ;˜: Re: [netmod] for a future rfc6991bis
>>>
>>> The draft that asked for the percentage type is: https://tools.ietf.org/html/draft-ye-ccamp-mw-topo-yang-02
>>>
>>> They currently define:
>>>
>>>                leaf availability {
>>>                  type decimal64 {
>>>                    fraction-digits 4;
>>>                    range "0..99.9999";
>>>                  }
>>>                  description "Availability level of the link";
>>>                }
>>>
>>> Thanks,
>>> - Xufeng
>>>
>>> On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel > wrote:
>>>
>>> +1 to percentage.
>>>
>>> Balazs
>>> On 2018. 11. 03. 3:44, Xufeng Liu wrote:
>>> Remember that some draft asked for a type of percentage value to the nearest hundredth. Wondering if it can be put in.
>>>
>>> Thanks,
>>> - Xufeng
>>>
>>> On Fri, Nov 2, 2018 at 11:39 AM tom petch > wrote:
>>> ---- Original Message -----
>>> From: "Juergen Schoenwaelder" >
>>> To: "Kent Watsen" >
>>> Cc: >
>>> Sent: Tuesday, October 30, 2018 10:14 AM
>>>
>>>> On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen wrote:
>>>>>
>>>>>>> In addition, it might be good to introduce [inet?] types for RFC
>>> 5322
>>>>>>> (Internet Message Format) including perhaps:
>>>>>>>
>>>>>>>    - email-address        (addr-spec, per Section 3.4.1)
>>>>>>>    - named-email-address  (name-addr, per Section 3.4)
>>>>>>>
>>>>>>
>>>>>> Where are these used? Or have these already been used somewhere?
>>>>>
>>>>> I'm unaware of these ever having been used before.  I am working on
>>> a private module for which I want to configure an email address.  After
>>> some searching, I concluded that no such types have been defined, and
>>> thus thought that they might be good candidates for addition.
>>>
>>>
>>> We could defined a user-name, of the form localpart@domainpart as is
>>> widely used to identify a user in operations but which does not, in my
>>> experience, owe anything to i18n, just a straightforward character set;
>>> yes it would not boil the ocean, but could be useful.  I am surprised
>>> not to find such a definition somewhere in our 40 or so NETCONF I-Ds.
>>>
>>> Tom Petch
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>>
>>>>
>>>> It would be good to have strong use cases. I fear that defining this
>>>> type won't be easy given that we also have internationalized email
>>>> addresses (RFC 6530 provides an overview) and we might have to create
>>>> a union of RFC 5322 addresses and "SMTPUTF8 (compliant) addresses".
>>>>
>>>> /js
>>>>
>>>> --
>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>>> Fax:   +49 421 200 3103         
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>> _______________________________________________
>>> 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 Nov  7 07:38: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 DD5FD130DC3 for ; Wed,  7 Nov 2018 07:38:05 -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 2Ls26Yxb1qXX for ; Wed,  7 Nov 2018 07:38:04 -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 A87B0127B92 for ; Wed,  7 Nov 2018 07:38:03 -0800 (PST)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 6E40FFDC73C4E for ; Wed,  7 Nov 2018 15:38:00 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 7 Nov 2018 15:38:01 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.136]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0415.000; Wed, 7 Nov 2018 23:37:58 +0800
From: Qin Wu 
To: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" 
Thread-Topic: some comments on netmod-base-notification-nmda (validation after commit response, etc)
Thread-Index: AdR2rcGTDhLJgsLtSyCKImzYQfQbTQ==
Date: Wed, 7 Nov 2018 15:37:57 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.126.171.31]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B10099Ankgeml513mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] some comments on netmod-base-notification-nmda (validation after commit response, etc)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Nov 2018 15:38:06 -0000

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

t6K8/sjLOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBTdGVy
bmUsIEphc29uIChOb2tpYSAtIENBL090dGF3YSkNCreiy83KsbzkOiAyMDE4xOoxMdTCNsjVIDEw
OjU2DQrK1bz+yMs6IG5ldG1vZEBpZXRmLm9yZw0K1vfM4jogW25ldG1vZF0gc29tZSBjb21tZW50
cyBvbiBuZXRtb2QtYmFzZS1ub3RpZmljYXRpb24tbm1kYSAodmFsaWRhdGlvbiBhZnRlciBjb21t
aXQgcmVzcG9uc2UsIGV0YykNCg0KSGVsbG8sDQoNClRoZSBkcmFmdCBtZW50aW9ucyB0aGF0ICJJ
dCBpcyBwb3NzaWJsZSB0aGF0IHNvbWUgY29uZmlndXJhdGlvbiBjb3VsZCBub3QgYmUgYXBwbGll
ZCB0byA8b3BlcmF0aW9uYWw+IGR1ZSB0byBlaXRoZXIgdmFsaWRhdGlvbiBpc3N1ZXMsIG9yIG1p
c3NpbmcgcmVzb3VyY2UgZXRjLiINCg0KQnV0IHdvdWxkbid0IHZhbGlkYXRpb24gZXJyb3JzIGNh
dXNlIGFuIGVycm9yIHJlc3BvbnNlIHRvIHRoZSBjb21taXQgUlBDPyBJJ20gbm90IGNsZWFyIHdo
eSB0aGVyZSB3b3VsZCBiZSB2YWxpZGF0aW9uIGxhdGVyIGluIHRoZSBjb21taXQvYXBwbHkgcHJv
Y2VzcyB0aGF0IHdhc24ndCBwYXJ0IG9mIHRoZSBkZWNpc2lvbiB0byByZXBseSBPSy9OT0sgdG8g
dGhlIGNvbW1pdC4NCg0KDQpbUWluXTpUaGUgY29uZmlndXJhdGlvbiBpcyB3cml0dGVuIGludG8g
cnVubmluZyB2aWEgY29tbWl0IG9wZXJhdGlvbiwgYnV0IGNvbW1pdCBvcGVyYXRpb24gZG9lc26h
r3QgZXF1YWwgdG8gdmFsaWRhdGUgb3BlcmF0aW9uLiBWYWxpZGF0ZSBvcGVyYXRpb24gaXMgZGVm
aW5lZCBpbiBSRkM2MjQxIHRvIHZhbGlkYXRlLCBlLmcuLCBjYW5kaWRhdGUgZGF0YXN0b3JlIG9y
IHRoZSA8Y29uZmlnPiBlbGVtZW50IGNvbnRhaW5pbmcgdGhlIGNvbXBsZXRlIGNvbmZpZ3VyYXRp
b24gaW4gdGhlIGVkaXQgY29uZmlnLiBCdXQgUkZDNjI0MSBkb2VzbqGvdCBkaXNjdXNzIGhvdyB2
YWxpZGF0ZSBvcGVyYXRpb24gY2FuIGJlIGFwcGxpZWQgdG8gaW50ZW5kZWQgb3Igb3RoZXIgTk1E
QSBkYXRhc3RvcmUgc2luY2UgTk1EQSBpcyBpbnRyb2R1Y2VkIGFmdGVyIFJGQzYyNDEgZ2V0cyBw
dWJsaXNoZWQuDQoNCg0KDQpBcyBkZXNjcmliZWQgaW4gUkZDODM0MiBhbmQgZmlndXJlIDIgb2Yg
UkZDODM0Mg0KDQqhsFdoZW5ldmVyIGRhdGEgaXMgd3JpdHRlbg0KDQogICB0byA8cnVubmluZz4s
IHRoZSBzZXJ2ZXIgTVVTVCBhbHNvIGltbWVkaWF0ZWx5IHVwZGF0ZSBhbmQgdmFsaWRhdGUNCg0K
ICAgPGludGVuZGVkPi4NCg0KobANCg0KU28gdmFsaWRhdGUgPGludGVuZGVkPiB0YWtlcyBwbGFj
ZSBhZnRlciBjb21taXQgb3BlcmF0aW9uLiBJdCBpbnZvbHZlcyBpbiBjb25maWd1cmF0aW9uIHRy
YW5zZm9ybWF0aW9ucyB0byA8cnVubmluZz4gYmVmb3JlIGludGVuZGVkIHZhbGlkYXRpb24gb3Bl
cmF0aW9uLg0KDQpUaGUgZHJhZnQgYWxzbyBpbXBsaWVzIHRoYXQgdGhlIHByb2Nlc3Mgb2YgbW92
aW5nIGNvbmZpZyBmcm9tIHJ1bm5pbmcgLT4gaW50ZW5kZWQgLT4gb3BlcmF0aW9uYWwgaXMgZGVj
b3VwbGVkIGZyb20gdGhlIGFwcGxpY2F0aW9uIG9mIGEgY2FuZGlkYXRlIC0+IHJ1bm5pbmcuDQot
IERvIHN5c3RlbXMgcmVwbHkgT0svTk9LIHRvIGEgY29tbWl0IGJlZm9yZSBjb25maWcgaXMgbW92
ZWQgZnJvbSBydW5uaW5nLT5pbnRlbmRlZC0+b3BlcmF0aW9uYWwgPw0KW1Fpbl06IHJlcGx5IE9L
L05PSyBpbmRpY2F0ZXMgd2hldGhlciBjb25maWd1cmF0aW9uIGlzIHdyaXR0ZW4gaW50byBydW5u
aW5nIGJ1dCBkb2VzbqGvdCB0ZWxsIHVzIHdoZXRoZXIgdmFsaWRhdGlvbiBwZXJmb3JtZWQgb24g
aW50ZW5kZWQgaXMgc3VjY2VzcyBvciBmYWlsdXJlLCB2YWxpZGF0ZSBvcGVyYXRpb24gZGVmaW5l
ZCBpbiBSRkM2MjQxIG9uIGNhbmRpZGF0ZSBkYXRhc3RvcmUgbWF5IGJlIGRpZmZlcmVudCBmcm9t
IFZhbGlkYXRpb24gb3BlcmF0aW9uIG9uIGludGVuZGVkIHNpbmNlIGl0IGNsZWFybHkgaGFwcGVu
cyBhdCBkaWZmZXJlbnQgc3RhZ2UsIHN1cmUgdmFsaWRhdGUgb3BlcmF0aW9uIGNhbiBiZSBhcHBs
aWVkIHRvIGludGVuZGVkLCBidXQgbm8gc3RhbmRhcmRzIGV4cGxpY2l0bHkgc3BlY2lmeSB3aGV0
aGVyIHZhbGlkYXRlIG9wZXJhdGlvbiBjYW4gYmUgYXBwbGllZCB0byBpbnRlbmRlZC4NClRoaXMg
aXMgc29tZXRoaW5nIHdlIGNhbiB1cGRhdGUgaW4gdGhpcyBkb2N1bWVudC4NCg0KLSBJZiBzbywg
dGhlbiBtYXliZSBpdCBpc24ndCBjb3JyZWN0IHRvIGhhdmUgYSB1c2VybmFtZSBpbiB0aGUgbm90
aWZpY2F0aW9ucy4gQSBzcGVjaWZpYyB1c2VyL3Nlc3Npb24gZGlkIHRoZSBjb21taXQsIGJ1dCB0
aGVuIGlmIHRoZSBjb21taXQgcHJvY2VzcyBlbmRzIGFmdGVyIGNhbmRpZGF0ZS0+cnVubmluZyAo
aS5lLiB0aGUgcmVwbHkgaGFwcGVucyBhdCB0aGF0IHBvaW50KSwgdGhlbiBpc24ndCBpdCByZWFs
bHkgdGhlIHN5c3RlbSBtb3ZpbmcgdGhlIGNvbmZpZyBmcm9tIHJ1bm5pbmctPmludGVuZGVkLT5v
cGVyYXRpb25hbD8NCltRaW5dOiBTZWUgYWJvdmUuDQpKYXNvbg0K

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











=B7=A2=BC=FE=C8=CB: netmod [mailto:netmod-bounces@ietf.org]
=B4=FA=B1=ED
Sterne, Jason (Nokia=
 - CA/Ottawa)

=B7=A2=CB=CD=CA=B1=BC=E4: 2018=
=C4=EA11=D4=
=C26=C8=D5
 10:56

=CA=D5=BC=FE=C8=CB: netmod@ietf.org

=D6=F7=CC=E2: [netmod] some comments on netmod-base-notification-nmda (validation after=
 commit response, etc)


 


Hello,


 


The draft mentions that "I=
t is possible that some configuration could not be applied to <operation=
al> due to either validation issues, or missing resource etc."=



 


But wouldn't validation errors =
cause an error response to the commit RPC? I'm not clear why there would be=
 validation later in the commit/apply process that wasn't part of the decis=
ion to reply OK/NOK to the commit.


 


[Qin]=
:The configuration is written into running via commit operation, but commit=
 operation doesn=A1=AFt equal to validate operation. Validate operation is =
defined in RFC6241 to validate, e.g., candidate datastore or the <config=
> element containing the complete configuration in the edit config. But =
RFC6241 doesn=A1=AFt discuss how validate operation can be applied to inten=
ded or other NMDA datastore since NMDA is introduced after RFC6241 gets pub=
lished.


=
 


As de=
scribed in RFC8342 and figure 2 of RFC8342


=A1=
=B0Whenever data is written


 =
;  to <running>, the server MUST also immediately update and val=
idate


 =
;  <intended>.


=A1=
=B0


So va=
lidate <intended> takes place after commit operation. It involves in =
configuration transformations to <running> before intended validation=
 operation.


 


The draft also implies that the=
 process of moving config from running -> intended -> operational is =
decoupled from the application of a candidate -> running.


- Do systems reply OK/NOK to a =
commit before config is moved from running->intended->operational ?


[Qin]: reply OK/NOK indicates whether =
configuration is written into running but doesn=A1=AFt tell us whether vali=
dation performed on intended is success or
 failure, validate operation defined in RFC6241 on candidate datastore may =
be different from Validation operation on intended since it clearly happens=
 at different stage, sure validate operation can be applied to intended, bu=
t no standards explicitly specify
 whether validate operation can be applied to intended.

This is something we can update in thi=
s document.


 


- If so, then maybe it isn't co=
rrect to have a username in the notifications. A specific user/session did =
the commit, but then if the commit process ends after candidate->running=
 (i.e. the reply happens at that point),
 then isn't it really the system moving the config from running->intende=
d->operational?


[Qin]: See above.


Jason






--_000_B8F9A780D330094D99AF023C5877DABA9B10099Ankgeml513mbschi_--


From nobody Wed Nov  7 07:56:35 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8820130DC8 for ; Wed,  7 Nov 2018 07:56:33 -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 MH2iQygI9RRf for ; Wed,  7 Nov 2018 07:56:30 -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 5877C1274D0 for ; Wed,  7 Nov 2018 07:56:30 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id F0A641F1F23AF; Wed,  7 Nov 2018 15:56:25 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 7 Nov 2018 15:56:22 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.136]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0415.000; Wed, 7 Nov 2018 23:56:18 +0800
From: Qin Wu 
To: Per Hedeland , Juergen Schoenwaelder 
CC: NETMOD WG 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AdR2sfES6Fy28Jv4RnCNpaIuonKKLg==
Date: Wed, 7 Nov 2018 15:56:17 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.126.171.31]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Nov 2018 15:56:34 -0000

LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBuZXRtb2QgW21haWx0bzpuZXRtb2Qt
Ym91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIFBlciBIZWRlbGFuZA0K5Y+R6YCB5pe26Ze0OiAyMDE4
5bm0MTHmnIg35pelIDE1OjU3DQrmlLbku7bkuro6IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5z
Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0K5oqE6YCBOiBORVRNT0QgV0cgPG5l
dG1vZEBpZXRmLm9yZz4NCuS4u+mimDogUmU6IFtuZXRtb2RdIGZvciBhIGZ1dHVyZSByZmM2OTkx
YmlzDQoNCk9uIDIwMTgtMTEtMDcgMDk6MzQsIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciB3cm90ZToN
Cj4gT24gV2VkLCBOb3YgMDcsIDIwMTggYXQgMDc6NDk6NTRBTSArMDAwMCwgWWVtaW4gKEFteSkg
d3JvdGU6DQo+IA0KPj4gRm9yIHRoZSByYW5nZSwgaWYgdGhlIGRlZmludGlvbiBjYW4gY292ZXIg
dGhlIG91ciByYW5nZSgwLi45OS45OTk5KSwgDQo+PiBpdCB3aWxsIGJlIGFjY2VwdGFibGUuICBJ
biB5b3VyIHN1Z2dlc3Rpb24gYmVsb3csIGRvZXMgdGhhdCBtZWFuIHRoZSANCj4+IGJhc2UgZGVm
aW50aW9uIGlzIHdpdGhvdXQgcmFuZ2UsIHdoaWxlIHJlZmluZWQgdHlwZXMgY2FuIGNob3NzZSB0
aGUgDQo+PiByYW5nZSB0aGV5IGxpa2U/DQo+IA0KPiBJIHdhcyB0aGlua2luZyBsb3VkLiBMZXQg
bWUgZGV0YWlsIHNvbWV3aGF0IG1vcmUgd2hhdCB3YXMgZ29pbmcgb24gaW4gDQo+IG15IGhlYWQ6
DQo+IA0KPiAgICBXZSBjb3VsZCBkZWZpbmUgYSBwZXJjZW50IHR5cGUgd2l0aG91dCB0aGUgdXBw
ZXIgYm91bmQgYmVpbmcNCj4gICAgd2hhdGV2ZXIgdGhlIGRlY2ltYWwgY292ZXJzIGJ1dCBmaXhp
bmcgdGhlIHByZWNpc2lvbiBvZiB0aGUNCj4gICAgZnJhY3Rpb25hbCBwYXJ0LiBXZSBjb3VsZCB0
aGVuIG5hcnJvdyB0aGUgdXBwZXIgYm91bmQgdmlhDQo+ICAgIHN1YnR5cGluZzoNCj4gDQo+ICAg
ICAgIHR5cGVkZWYgcGVyY2VudCB7DQo+ICAgICAgICAgdHlwZSBkZWNpbWFsIHsNCj4gICAgICAg
ICAgIGZyYWN0aW9uLWRpZ2l0cyA0Ow0KPiAgICAgICAgICAgcmFuZ2UgIjAuLm1heCI7DQo+ICAg
ICAgICAgfQ0KPiAgICAgICB9DQo+IA0KPiAgICAgICB0eXBlZGVmIHBlcmNlbnQnIHsNCj4gICAg
ICAgICB0eXBlIHBlcmNlbnQgeyByYW5nZSAwLi4xMDA7IH0NCj4gICAgICAgfQ0KPiANCj4gICAg
SWYgd2FudGVkIGZsZXhpYmlsaXR5IG9uIHRoZSBmcmFjdGlvbmFsIHBhcnQsIHdlIGNvdWxkIGRl
ZmluZQ0KPiAgICBwZXJjZW50IHdpdGggYSBmaXhlZCByYW5nZSBhbmQgdGhlIGxhcmdlc3QgbnVt
YmVyIG9mIGZyYWN0aW9uIGRpZ2l0cw0KPiAgICBwb3NzaWJsZSBhbmQgdGhlbiB3ZSBjb3VsZCBz
dWJ0eXBlIHRoaXMgdG8gb2J0YWluIGEgcHJlY2lzaW9uIHRoYXQNCj4gICAgbWFrZXMgc2Vuc2Ug
aW4gdGhlIHVzYWdlIGNvbnRleHRzIChhbHRob3VnaCBpdCBpcyBub3QgY2xlYXIgd2hldGhlcg0K
PiAgICBZQU5HIDEuMSByZWFsbHkgYWxsb3dzIHRoaXMsIGlmIG5vdCB0aGlzIG1heSBiZSBqdXN0
IGR1ZSB0byBub2JvZHkNCj4gICAgZXZlciB0aGlua2luZyBhYm91dCB0aGlzIGJlZm9yZSk6DQoN
CkkgYmVsaWV2ZSBpdCBpcyBxdWl0ZSBjbGVhciB0aGF0IHRoaXMgaXMgKm5vdCogYWxsb3dlZDoN
Cg0KICAgOS4zLjMuICBSZXN0cmljdGlvbnMNCg0KICAgICAgQSBkZWNpbWFsNjQgdHlwZSBjYW4g
YmUgcmVzdHJpY3RlZCB3aXRoIHRoZSAicmFuZ2UiIHN0YXRlbWVudA0KICAgICAgKFNlY3Rpb24g
OS4yLjQpLg0KDQotLVBlcg0KDQpbUWluXTogU2VjdGlvbiA5LjIuNCBzYWlkOg0KIg0KSWYgYSBy
YW5nZSByZXN0cmljdGlvbiBpcyBhcHBsaWVkIHRvIGEgdHlwZSB0aGF0IGlzDQogICBhbHJlYWR5
IHJhbmdlLXJlc3RyaWN0ZWQsIHRoZSBuZXcgcmVzdHJpY3Rpb24gTVVTVCBiZSBlcXVhbGx5DQog
ICBsaW1pdGluZyBvciBtb3JlIGxpbWl0aW5nLCBpLmUuLCByYWlzaW5nIHRoZSBsb3dlciBib3Vu
ZHMsIHJlZHVjaW5nDQogICB0aGUgdXBwZXIgYm91bmRzLCByZW1vdmluZyBleHBsaWNpdCB2YWx1
ZXMgb3IgcmFuZ2VzLCBvciBzcGxpdHRpbmcNCiAgIHJhbmdlcyBpbnRvIG11bHRpcGxlIHJhbmdl
cyB3aXRoIGludGVybWVkaWF0ZSBnYXBzLg0KIg0KSSBhbSBub3Qgc3VyZSB0aGUgYWJvdmUgZXhh
bXBsZSByZWFsbHkgdmlvbGF0ZXMgdGhlIHJ1bGUgZGVzY3JpYmVkIGFib3ZlLg0KDQo+ICAgICAg
dHlwZWRlZiBwZXJjZW50IHsNCj4gICAgICAgIHR5cGUgZGVjaW1hbCB7DQo+ICAgICAgICAgIGZy
YWN0aW9uLWRpZ2l0cyAxNjsNCj4gICAgICAgICAgcmFuZ2UgMC4uMTAwOw0KPiAgICAgICAgfQ0K
PiAgICAgIH0NCj4gDQo+ICAgICAgdHlwZWRlZiBwZXJjZW50JyB7DQo+ICAgICAgICB0eXBlIHBl
cmNlbnQgeyBmcmFjdGlvbi1kaWdpdHMgNDsgfQ0KPiAgICAgIH0NCj4gDQo+ICAgIEFuIGlkZWFs
IHNvbHV0aW9uIHdvdWxkIHByb3ZpZGUgZmxleGliaWxpdHkgYm90aCBvbiB0aGUgcmFuZ2UgYW5k
DQo+ICAgIHRoZSBudW1iZXIgb2YgZnJhY3Rpb24gZGlnaXRzIGJ1dCBpdCBzZWVtcyB0aGlzIGlz
IGltcG9zc2libGUgc2luY2UNCj4gICAgdGhlc2UgdHdvIHByb3BlcnRpZXMgKHJhbmdlIGFuZCBw
cmVjaXNpb24pIGludGVyYWN0Lg0KPiANCj4gU28gaXQgc2VlbXMgd2UgaGF2ZSB0byBkbyBzb21l
dGhpbmcgdGhhdCBpcyBwcmFnbWF0aWMgYW5kIHRoaXMgbGlrZWx5IA0KPiBtZWFucyBmaXhpbmcg
dGhlIGZyYWN0aW9uIHNpbmNlIHN1YnR5cGluZyB0aGUgZnJhY3Rpb25hbCBwYXJ0IG1heSBub3Qg
DQo+IGJlIGFsbG93ZWQgYnkgWUFORyBvciBub3QgYmUgc3VwcG9ydGVkIGJ5IGltcGxlbWVudGF0
aW9ucy4gVGhlIA0KPiBxdWVzdGlvbiBpcyB0aGVuIGhvdyB3ZSBwaWNrIHN1aXRhYmxlIGZyYWN0
aW9ucy4gSSB1bmRlcnN0YW5kIHlvdSB3YW50DQo+IDQgZGlnaXRzLg0KPiANCj4gL2pzDQo+IA0K
Pj4gQlIsDQo+PiBBbXkNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCj4+IMORw7bCujogSnVlcmdlbiBTY2hvZW53YWVsZGVyIFtqLnNjaG9lbndhZWxkZXJAamFj
b2JzLXVuaXZlcnNpdHkuZGVdDQo+PiDDkQHDtsO0OiAyMDE4dDExCDbDpSAyMjoxNg0KPj4gNsO2
wro6IFllbWluIChBbXkpDQo+PiDChAE6IFFpbiBXdTsgWHVmZW5nIExpdTsgYmFsYXpzLmxlbmd5
ZWxAZXJpY3Nzb24uY29tOyBORVRNT0QgV0cNCj4+IDvCmDogUmU6IFtuZXRtb2RdIGZvciBhIGZ1
dHVyZSByZmM2OTkxYmlzDQo+Pg0KPj4gV2VsbCwgdGhlIGRyYWZ0LXllLWNjYW1wLW13LXRvcG8t
eWFuZy0wMiBkZWZpbml0aW9uIGV4Y2x1ZGVzIDEwMCUsIA0KPj4gd2hpY2ggaXMgbGlrZWx5IG5v
dCBnZW5lcmFsbHkgdXNlZnVsLiBJbiBmYWN0LCBldmVuIDE1MCUgY2FuIGJlIGluIA0KPj4gc29t
ZSBjb250ZXh0cyBhIHBlcmZlY3RseSBzZW5zaWJsZSBwZXJjZW50YWdlLiBTbyB3ZSBtYXkgbmVl
ZCB0byANCj4+IHByb3ZpZGUgc29tZSBmbGV4aWJpbGl0eSBoZXJlLCBpLmUuLCBoYXZpbmcgYSBi
YXNlIHRpbWUgd2hlcmUgdGhlIA0KPj4gcmFuZ2UgY2FuIGJlIHJlZmluZWQgYW5kIHJlZmluZWQg
dHlwZXMgd2l0aCBhbiB1cHBlciBsaW1pdCBzZXQgdG8gDQo+PiAxMDAlIGZvciB1c2UgaW4gc2l0
dWF0aW9ucyB3aGVyZSB0aGlzIGxpbWl0IGlzIHNlbnNpYmxlLg0KPj4NCj4+IFRoZSBtb3JlIGRp
ZmZpY3VsdCBhc3BlY3Qgc2VlbXMgdG8gYmUgcHJlY2lzaW9uLCBJIGFtIG5vdCBzdXJlIFlBTkcg
DQo+PiBhbGxvd3Mgc3VidHlwaW5nIHRoZSBmcmFjdGlvbmFsIHBhcnQuIFJGQyA3OTUwIHNlZW1z
IHRvIGJlIHNpbGVudCANCj4+IGFib3V0IHRoaXMgYW5kIGluIHRoZSBnZW5lcmFsIGNhc2UgdGhp
cyB3b3VsZCBub3QgYmUgbWVhbmluZ2Z1bC4gQnV0IA0KPj4gaW4gdGhpcyBwYXJ0aWN1bGFyIGNh
c2UsIHdoZW4gdGhlIG51bWJlciByYW5nZSBpcyBsaW1pdGVkLCBpdCB3b3VsZCANCj4+IGFjdHVh
bGx5IGJlIE9LIHRvIGFsbG93IHRoaXMgKGJ1dCB0aGVuIHdlIGhhdmUgdG8gaGF2ZSBhIGxpbWl0
IGFuZCB3ZSANCj4+IGNhbid0IHNldCB0aGUgdXBwZXIgbGltaXQgdG8gbWF4KS4NCj4+DQo+PiAv
anMNCj4+DQo+PiBPbiBUdWUsIE5vdiAwNiwgMjAxOCBhdCAwMjoyMTozM0FNICswMDAwLCBZZW1p
biAoQW15KSB3cm90ZToNCj4+PiBJZiB0aGUgcGVyY2VudGFnZSBpcyBkZWZpbmVkIGFzIGZvbGxv
d2luZywgYXMgYSBhdXRob3Igb2YgZHJhZnQteWUtY2NhbXAtbXctdG9wby15YW5nLTAyLCB3ZSB3
aWxsIGJlIGhhcHB5IHRvIHVzZSBpdC4NCj4+PiBCdXQgaXQncyBiZXR0ZXIgdG8gaW5jbHVkZSBp
biBSRkM2OTkxYmlzLCBhcyBwZXJjZW50YWdlIGlzIGEgZ2VuZXJpYyBhbmQgd2lkZWx5IHVzZWQg
aXRlbS4NCj4+Pg0KPj4+IEJSLA0KPj4+IEFteQ0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+Pj4gw5HDtsK6OiBuZXRtb2QgW25ldG1vZC1ib3VuY2VzQGlldGYub3JnXSDD
o2ggUWluIFd1IFtiaWxsLnd1QGh1YXdlaS5jb21dDQo+Pj4gw5EBw7bDtDogMjAxOHQxMQg2w6Ug
OToyNQ0KPj4+IDbDtsK6OiBYdWZlbmcgTGl1OyBiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20N
Cj4+PiDChAE6IE5FVE1PRCBXRw0KPj4+IDvCmDogUmU6IFtuZXRtb2RdIGZvciBhIGZ1dHVyZSBy
ZmM2OTkxYmlzDQo+Pj4NCj4+Pg0KPj4+IEFub3RoZXIgY2FzZSB3b3VsZCBiZSA6DQo+Pj4NCj4+
Pg0KPj4+IBwNCj4+Pg0KPj4+IHR5cGVkZWYgcGVyY2VudGFnZSB7DQo+Pj4NCj4+PiAgICAgICAg
dHlwZSBkZWNpbWFsNjQgew0KPj4+DQo+Pj4gICAgICAgICAgIGZyYWN0aW9uLWRpZ2l0cyA1Ow0K
Pj4+DQo+Pj4gICAgICAgICAgIHJhbmdlICIwLi4xMDAiOw0KPj4+DQo+Pj4gICAgICAgfQ0KPj4+
DQo+Pj4gICAgIGRlc2NyaXB0aW9uICJQZXJjZW50YWdlLiI7DQo+Pj4gICAgIH0NCj4+PiAdDQo+
Pj4gV2hpY2ggaXMgZGVmaW5lZCBpZXRmLWNvbm5lY3Rpb25sZXNzLW9hbS55YW5nIG1vZHVsZS4N
Cj4+Pg0KPj4+IC1RaW4NCj4+PiDDkcO2wro6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2Vz
QGlldGYub3JnXSDDo2ggWHVmZW5nIExpdQ0KPj4+IMORAcO2w7Q6IDIwMTh0MTEINsOlIDM6NDkN
Cj4+PiA2w7bCujogYmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tDQo+Pj4gwoQBOiBORVRNT0Qg
V0cgPG5ldG1vZEBpZXRmLm9yZz4NCj4+PiA7wpg6IFJlOiBbbmV0bW9kXSBmb3IgYSBmdXR1cmUg
cmZjNjk5MWJpcw0KPj4+DQo+Pj4gVGhlIGRyYWZ0IHRoYXQgYXNrZWQgZm9yIHRoZSBwZXJjZW50
YWdlIHR5cGUgaXM6IA0KPj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC15ZS1j
Y2FtcC1tdy10b3BvLXlhbmctMDINCj4+Pg0KPj4+IFRoZXkgY3VycmVudGx5IGRlZmluZToNCj4+
Pg0KPj4+ICAgICAgICAgICAgICAgIGxlYWYgYXZhaWxhYmlsaXR5IHsNCj4+PiAgICAgICAgICAg
ICAgICAgIHR5cGUgZGVjaW1hbDY0IHsNCj4+PiAgICAgICAgICAgICAgICAgICAgZnJhY3Rpb24t
ZGlnaXRzIDQ7DQo+Pj4gICAgICAgICAgICAgICAgICAgIHJhbmdlICIwLi45OS45OTk5IjsNCj4+
PiAgICAgICAgICAgICAgICAgIH0NCj4+PiAgICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uICJB
dmFpbGFiaWxpdHkgbGV2ZWwgb2YgdGhlIGxpbmsiOw0KPj4+ICAgICAgICAgICAgICAgIH0NCj4+
Pg0KPj4+IFRoYW5rcywNCj4+PiAtIFh1ZmVuZw0KPj4+DQo+Pj4gT24gU3VuLCBOb3YgNCwgMjAx
OCBhdCA3OjA3IEFNIEJhbMOhenMgTGVuZ3llbCA8YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t
PG1haWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20+PiB3cm90ZToNCj4+Pg0KPj4+ICsx
IHRvIHBlcmNlbnRhZ2UuDQo+Pj4NCj4+PiBCYWxhenMNCj4+PiBPbiAyMDE4LiAxMS4gMDMuIDM6
NDQsIFh1ZmVuZyBMaXUgd3JvdGU6DQo+Pj4gUmVtZW1iZXIgdGhhdCBzb21lIGRyYWZ0IGFza2Vk
IGZvciBhIHR5cGUgb2YgcGVyY2VudGFnZSB2YWx1ZSB0byB0aGUgbmVhcmVzdCBodW5kcmVkdGgu
IFdvbmRlcmluZyBpZiBpdCBjYW4gYmUgcHV0IGluLg0KPj4+DQo+Pj4gVGhhbmtzLA0KPj4+IC0g
WHVmZW5nDQo+Pj4NCj4+PiBPbiBGcmksIE5vdiAyLCAyMDE4IGF0IDExOjM5IEFNIHRvbSBwZXRj
aCA8aWV0ZmNAYnRjb25uZWN0LmNvbTxtYWlsdG86aWV0ZmNAYnRjb25uZWN0LmNvbT4+IHdyb3Rl
Og0KPj4+IC0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KPj4+IEZyb206ICJKdWVyZ2VuIFNj
aG9lbndhZWxkZXIiIA0KPj4+IDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8
bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtDQo+Pj4gdW5pdmVyc2l0eS5kZT4+DQo+Pj4g
VG86ICJLZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3YXRzZW5AanVu
aXBlci4ubmV0Pj4NCj4+PiBDYzogPG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYu
b3JnPj4NCj4+PiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDMwLCAyMDE4IDEwOjE0IEFNDQo+Pj4N
Cj4+Pj4gT24gVHVlLCBPY3QgMzAsIDIwMTggYXQgMTI6MDU6MTdBTSArMDAwMCwgS2VudCBXYXRz
ZW4gd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4+PiBJbiBhZGRpdGlvbiwgaXQgbWlnaHQgYmUgZ29vZCB0
byBpbnRyb2R1Y2UgW2luZXQ/XSB0eXBlcyBmb3IgUkZDDQo+Pj4gNTMyMg0KPj4+Pj4+PiAoSW50
ZXJuZXQgTWVzc2FnZSBGb3JtYXQpIGluY2x1ZGluZyBwZXJoYXBzOg0KPj4+Pj4+Pg0KPj4+Pj4+
PiAgICAtIGVtYWlsLWFkZHJlc3MgICAgICAgIChhZGRyLXNwZWMsIHBlciBTZWN0aW9uIDMuNC4x
KQ0KPj4+Pj4+PiAgICAtIG5hbWVkLWVtYWlsLWFkZHJlc3MgIChuYW1lLWFkZHIsIHBlciBTZWN0
aW9uIDMuNCkNCj4+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IFdoZXJlIGFyZSB0aGVzZSB1c2VkPyBP
ciBoYXZlIHRoZXNlIGFscmVhZHkgYmVlbiB1c2VkIHNvbWV3aGVyZT8NCj4+Pj4+DQo+Pj4+PiBJ
J20gdW5hd2FyZSBvZiB0aGVzZSBldmVyIGhhdmluZyBiZWVuIHVzZWQgYmVmb3JlLiAgSSBhbSB3
b3JraW5nIA0KPj4+Pj4gb24NCj4+PiBhIHByaXZhdGUgbW9kdWxlIGZvciB3aGljaCBJIHdhbnQg
dG8gY29uZmlndXJlIGFuIGVtYWlsIGFkZHJlc3MuICANCj4+PiBBZnRlciBzb21lIHNlYXJjaGlu
ZywgSSBjb25jbHVkZWQgdGhhdCBubyBzdWNoIHR5cGVzIGhhdmUgYmVlbiANCj4+PiBkZWZpbmVk
LCBhbmQgdGh1cyB0aG91Z2h0IHRoYXQgdGhleSBtaWdodCBiZSBnb29kIGNhbmRpZGF0ZXMgZm9y
IGFkZGl0aW9uLg0KPj4+DQo+Pj4NCj4+PiBXZSBjb3VsZCBkZWZpbmVkIGEgdXNlci1uYW1lLCBv
ZiB0aGUgZm9ybSBsb2NhbHBhcnRAZG9tYWlucGFydCBhcyBpcyANCj4+PiB3aWRlbHkgdXNlZCB0
byBpZGVudGlmeSBhIHVzZXIgaW4gb3BlcmF0aW9ucyBidXQgd2hpY2ggZG9lcyBub3QsIGluIA0K
Pj4+IG15IGV4cGVyaWVuY2UsIG93ZSBhbnl0aGluZyB0byBpMThuLCBqdXN0IGEgc3RyYWlnaHRm
b3J3YXJkIA0KPj4+IGNoYXJhY3RlciBzZXQ7IHllcyBpdCB3b3VsZCBub3QgYm9pbCB0aGUgb2Nl
YW4sIGJ1dCBjb3VsZCBiZSB1c2VmdWwuICANCj4+PiBJIGFtIHN1cnByaXNlZCBub3QgdG8gZmlu
ZCBzdWNoIGEgZGVmaW5pdGlvbiBzb21ld2hlcmUgaW4gb3VyIDQwIG9yIHNvIE5FVENPTkYgSS1E
cy4NCj4+Pg0KPj4+IFRvbSBQZXRjaA0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+
DQo+Pj4+Pg0KPj4+Pg0KPj4+PiBJdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgc3Ryb25nIHVzZSBj
YXNlcy4gSSBmZWFyIHRoYXQgZGVmaW5pbmcgDQo+Pj4+IHRoaXMgdHlwZSB3b24ndCBiZSBlYXN5
IGdpdmVuIHRoYXQgd2UgYWxzbyBoYXZlIGludGVybmF0aW9uYWxpemVkIA0KPj4+PiBlbWFpbCBh
ZGRyZXNzZXMgKFJGQyA2NTMwIHByb3ZpZGVzIGFuIG92ZXJ2aWV3KSBhbmQgd2UgbWlnaHQgaGF2
ZSANCj4+Pj4gdG8gY3JlYXRlIGEgdW5pb24gb2YgUkZDIDUzMjIgYWRkcmVzc2VzIGFuZCAiU01U
UFVURjggKGNvbXBsaWFudCkgYWRkcmVzc2VzIi4NCj4+Pj4NCj4+Pj4gL2pzDQo+Pj4+DQo+Pj4+
IC0tDQo+Pj4+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNp
dHkgQnJlbWVuIGdHbWJIDQo+Pj4+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2Ft
cHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8IEdlcm1hbnkNCj4+Pj4gRmF4OiAgICs0OSA0MjEg
MjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPj4+
Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
Pj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0
bW9kQGlldGYub3JnPg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L25ldG1vZA0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4gbmV0bW9kQGlldGYub3JnPG1h
aWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9uZXRtb2QNCj4+Pg0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj4+Pg0KPj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+Pg0K
Pj4+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KPj4+DQo+Pj4gaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8VXJsQmxvY2tlZEVycm9y
LmFzcHg+DQo+Pj4NCj4+PiAtLQ0KPj4+DQo+Pj4gQmFsYXpzIExlbmd5ZWwgICAgICAgICAgICAg
ICAgICAgICAgIEVyaWNzc29uIEh1bmdhcnkgTHRkLg0KPj4+DQo+Pj4gU2VuaW9yIFNwZWNpYWxp
c3QNCj4+Pg0KPj4+IE1vYmlsZTogKzM2LTcwLTMzMC03OTA5ICAgICAgICAgICAgICBlbWFpbDog
QmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tPG1haWx0bzpCYWxhenMuTGVuZ3llbEBlcmljc3Nv
bi5jb20+DQo+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4+
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+Pg0KPj4NCj4+
IC0tDQo+PiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5
IEJyZW1lbiBnR21iSA0KPj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMg
UmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPj4gRmF4OiAgICs0OSA0MjEgMjAwIDMx
MDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPiANCg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWls
aW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9uZXRtb2QNCg==


From nobody Wed Nov  7 08:08: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 8DAD11274D0 for ; Wed,  7 Nov 2018 08:08:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outbound.mailhop.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WahLD5iBeoB for ; Wed,  7 Nov 2018 08:08:53 -0800 (PST)
Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C42130DC8 for ; Wed,  7 Nov 2018 08:08:53 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1541606933; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=c7hKNB+aF2cS06aTKb8JSzjTp/oKPd1MHOiSaaP2W+SKCT1iJggeUX9Qo8sTlmJFJ3Yswjc7pL5sK +TBYUnXbTvazG9R4covKiVim0p3MTGf553GUspKaHciBnz12BHmTZo8i/2EjDY64tROe7fObDfNH7S FqMUXfb2EAfODEoEyXjiNBI2reMympkC8U1R4Nv5jGSVCiJce6nWL+zVjs1OUePs7UL7n9/HJe6Ybc n1vx6rxUUegmaVvXRXq8tCF+fz50IO8h9MqgAtLl5G9W91x2BPJsQPmQqhg26ySiAw4+UCXFgyGeQ8 nECpa5X+dYtf5qRw7/qKnpdFKCYxrWg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:dkim-signature:from; bh=YtmeCK/l3hmSWTFVhTuHTHYmnvZMF27SHt+7PzLxnm8=; b=nBKHjHm7FTtLuYBvLD9/cgroYmOAmTcT1bD3Xo9W4D415D71FD33EbTqijWJ4x6YmIWlFdAJh8Yj1 wrlwYBERcRTOgZV+ZY5KtsCx0kNcalnJff1mjOHfexhtuy/Ian5BVwSmw8+2pLuwIZgDuk6eIk0jw+ tAG9S8DvMeBTqcO6MhOOQucs+dwc446IyjXMRMMW2hyf8VqJkpaxEQcQUYLyJIuicM1r11ccPb1mlF gZNCOoWRvoPUbqFogGoX1tDx1LScLh30fX1WSG6GgvKQzyXBCuqcQYIlkRPQF/8dsOPpPre3iW0IOI sfTnTy2UTS7jOrlelKNrwB/y64Mgkqg==
ARC-Authentication-Results: i=1; outbound2.ore.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.152.101; dmarc=none header.from=hedeland.org; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:from; bh=YtmeCK/l3hmSWTFVhTuHTHYmnvZMF27SHt+7PzLxnm8=; b=GCiJx2jB9Xi8l4uHPx46pWea0yU9bNYhVzULbXUIrQVDtrDg2w074rALoihLW28paRHnpRZuakaQ8 9bPQUrFHK0v0f33AizAhxjHilFvHRjn8tGE965WQmwnefLxwL58FVU6gZHXKBm2hnQXjrYTRzHEy81 Fwch+9PH6wuKByacBrGEeOugpXvDn5rTZmH9Oq/rCN7r9PKPXXvPdIwb+rpbsV/RIHBanRQstTbz7J 0leqW4ysMAIKZYUXqTwtZm0MWp6SKtITyDcY+LahzCjrxCdqfWtZHE/0CYcqr2xQ4bCtWMyRPWMGAG uFnihTu1RjpTI+fUFZgj7gGzu1uQE6w==
X-MHO-RoutePath: cGVyaGVkZWxhbmQ=
X-MHO-User: 68f5eb88-e2a7-11e8-a630-335f030b21f2
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 81.228.152.101
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from hedeland.org (unknown [81.228.152.101]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 68f5eb88-e2a7-11e8-a630-335f030b21f2; Wed, 07 Nov 2018 16:08:51 +0000 (UTC)
Received: from mars.tail-f.com ([173.38.220.34]) (authenticated bits=0) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPSA id wA7G8kaO071446 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 7 Nov 2018 17:08:47 +0100 (CET) (envelope-from per@hedeland.org)
X-Authentication-Warning: tellus.hedeland.org: Host [173.38.220.34] claimed to be mars.tail-f.com
To: Qin Wu 
Cc: Juergen Schoenwaelder , NETMOD WG 
References: 
From: Per Hedeland 
Message-ID: <99242f6c-5886-dd48-e42f-3f478665058e@hedeland.org>
Date: Wed, 7 Nov 2018 17:08:41 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Nov 2018 16:08:57 -0000

On 2018-11-07 16:56, Qin Wu wrote:
> -----®öŸö-----
> Ñöº: netmod [mailto:netmod-bounces@ietf.org] ãh Per Hedeland
> Ñöô: 2018t117å 15:57
> 6öº: Juergen Schoenwaelder 
> „: NETMOD WG 
> ;˜: Re: [netmod] for a future rfc6991bis
> 
> On 2018-11-07 09:34, Juergen Schoenwaelder wrote:
>> On Wed, Nov 07, 2018 at 07:49:54AM +0000, Yemin (Amy) wrote:
>>
>>> For the range, if the defintion can cover the our range(0..99.9999), 
>>> it will be acceptable.  In your suggestion below, does that mean the 
>>> base defintion is without range, while refined types can chosse the 
>>> range they like?
>>
>> I was thinking loud. Let me detail somewhat more what was going on in 
>> my head:
>>
>>    We could define a percent type without the upper bound being
>>    whatever the decimal covers but fixing the precision of the
>>    fractional part. We could then narrow the upper bound via
>>    subtyping:
>>
>>       typedef percent {
>>         type decimal {
>>           fraction-digits 4;
>>           range "0..max";
>>         }
>>       }
>>
>>       typedef percent' {
>>         type percent { range 0..100; }
>>       }
>>
>>    If wanted flexibility on the fractional part, we could define
>>    percent with a fixed range and the largest number of fraction digits
>>    possible and then we could subtype this to obtain a precision that
>>    makes sense in the usage contexts (although it is not clear whether
>>    YANG 1.1 really allows this, if not this may be just due to nobody
>>    ever thinking about this before):
> 
> I believe it is quite clear that this is *not* allowed:
> 
>    9.3.3.  Restrictions
> 
>       A decimal64 type can be restricted with the "range" statement
>       (Section 9.2.4).
> 
> --Per
> 
> [Qin]: Section 9.2.4 said:
> "
> If a range restriction is applied to a type that is
>    already range-restricted, the new restriction MUST be equally
>    limiting or more limiting, i.e., raising the lower bounds, reducing
>    the upper bounds, removing explicit values or ranges, or splitting
>    ranges into multiple ranges with intermediate gaps.
> "
> I am not sure the above example really violates the rule described above.

No, it's the example *below* - that Juergen was referring to above with
the "it is not clear whether YANG 1.1 really allows this" that I replied
to - that does. I.e. restricting a decimal64 type with a fraction-digits
statement is not allowed.

--Per

>>      typedef percent {
>>        type decimal {
>>          fraction-digits 16;
>>          range 0..100;
>>        }
>>      }
>>
>>      typedef percent' {
>>        type percent { fraction-digits 4; }      <<<<<<<<<<<<<<
>>      }
>>
>>    An ideal solution would provide flexibility both on the range and
>>    the number of fraction digits but it seems this is impossible since
>>    these two properties (range and precision) interact.
>>
>> So it seems we have to do something that is pragmatic and this likely 
>> means fixing the fraction since subtyping the fractional part may not 
>> be allowed by YANG or not be supported by implementations. The 
>> question is then how we pick suitable fractions. I understand you want
>> 4 digits.
>>
>> /js
>>
>>> BR,
>>> Amy
>>> ________________________________________
>>> Ñöº: Juergen Schoenwaelder [j.schoenwaelder@jacobs-university.de]
>>> Ñöô: 2018t116å 22:16
>>> 6öº: Yemin (Amy)
>>> „: Qin Wu; Xufeng Liu; balazs.lengyel@ericsson.com; NETMOD WG
>>> ;˜: Re: [netmod] for a future rfc6991bis
>>>
>>> Well, the draft-ye-ccamp-mw-topo-yang-02 definition excludes 100%, 
>>> which is likely not generally useful. In fact, even 150% can be in 
>>> some contexts a perfectly sensible percentage. So we may need to 
>>> provide some flexibility here, i.e., having a base time where the 
>>> range can be refined and refined types with an upper limit set to 
>>> 100% for use in situations where this limit is sensible.
>>>
>>> The more difficult aspect seems to be precision, I am not sure YANG 
>>> allows subtyping the fractional part. RFC 7950 seems to be silent 
>>> about this and in the general case this would not be meaningful. But 
>>> in this particular case, when the number range is limited, it would 
>>> actually be OK to allow this (but then we have to have a limit and we 
>>> can't set the upper limit to max).
>>>
>>> /js
>>>
>>> On Tue, Nov 06, 2018 at 02:21:33AM +0000, Yemin (Amy) wrote:
>>>> If the percentage is defined as following, as a author of draft-ye-ccamp-mw-topo-yang-02, we will be happy to use it.
>>>> But it's better to include in RFC6991bis, as percentage is a generic and widely used item.
>>>>
>>>> BR,
>>>> Amy
>>>> ________________________________
>>>> Ñöº: netmod [netmod-bounces@ietf.org] ãh Qin Wu [bill.wu@huawei.com]
>>>> Ñöô: 2018t116å 9:25
>>>> 6öº: Xufeng Liu; balazs.lengyel@ericsson.com
>>>> „: NETMOD WG
>>>> ;˜: Re: [netmod] for a future rfc6991bis
>>>>
>>>>
>>>> Another case would be :
>>>>
>>>>
>>>> 
>>>>
>>>> typedef percentage {
>>>>
>>>>        type decimal64 {
>>>>
>>>>           fraction-digits 5;
>>>>
>>>>           range "0..100";
>>>>
>>>>       }
>>>>
>>>>     description "Percentage.";
>>>>     }
>>>> 
>>>> Which is defined ietf-connectionless-oam.yang module.
>>>>
>>>> -Qin
>>>> Ñöº: netmod [mailto:netmod-bounces@ietf.org] ãh Xufeng Liu
>>>> Ñöô: 2018t116å 3:49
>>>> 6öº: balazs.lengyel@ericsson.com
>>>> „: NETMOD WG 
>>>> ;˜: Re: [netmod] for a future rfc6991bis
>>>>
>>>> The draft that asked for the percentage type is: 
>>>> https://tools.ietf.org/html/draft-ye-ccamp-mw-topo-yang-02
>>>>
>>>> They currently define:
>>>>
>>>>                leaf availability {
>>>>                  type decimal64 {
>>>>                    fraction-digits 4;
>>>>                    range "0..99.9999";
>>>>                  }
>>>>                  description "Availability level of the link";
>>>>                }
>>>>
>>>> Thanks,
>>>> - Xufeng
>>>>
>>>> On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel > wrote:
>>>>
>>>> +1 to percentage.
>>>>
>>>> Balazs
>>>> On 2018. 11. 03. 3:44, Xufeng Liu wrote:
>>>> Remember that some draft asked for a type of percentage value to the nearest hundredth. Wondering if it can be put in.
>>>>
>>>> Thanks,
>>>> - Xufeng
>>>>
>>>> On Fri, Nov 2, 2018 at 11:39 AM tom petch > wrote:
>>>> ---- Original Message -----
>>>> From: "Juergen Schoenwaelder" 
>>>> >>> university.de>>
>>>> To: "Kent Watsen" >
>>>> Cc: >
>>>> Sent: Tuesday, October 30, 2018 10:14 AM
>>>>
>>>>> On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen wrote:
>>>>>>
>>>>>>>> In addition, it might be good to introduce [inet?] types for RFC
>>>> 5322
>>>>>>>> (Internet Message Format) including perhaps:
>>>>>>>>
>>>>>>>>    - email-address        (addr-spec, per Section 3.4.1)
>>>>>>>>    - named-email-address  (name-addr, per Section 3.4)
>>>>>>>>
>>>>>>>
>>>>>>> Where are these used? Or have these already been used somewhere?
>>>>>>
>>>>>> I'm unaware of these ever having been used before.  I am working 
>>>>>> on
>>>> a private module for which I want to configure an email address.  
>>>> After some searching, I concluded that no such types have been 
>>>> defined, and thus thought that they might be good candidates for addition.
>>>>
>>>>
>>>> We could defined a user-name, of the form localpart@domainpart as is 
>>>> widely used to identify a user in operations but which does not, in 
>>>> my experience, owe anything to i18n, just a straightforward 
>>>> character set; yes it would not boil the ocean, but could be useful.  
>>>> I am surprised not to find such a definition somewhere in our 40 or so NETCONF I-Ds.
>>>>
>>>> Tom Petch
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>
>>>>>
>>>>> It would be good to have strong use cases. I fear that defining 
>>>>> this type won't be easy given that we also have internationalized 
>>>>> email addresses (RFC 6530 provides an overview) and we might have 
>>>>> to create a union of RFC 5322 addresses and "SMTPUTF8 (compliant) addresses".
>>>>>
>>>>> /js
>>>>>
>>>>> --
>>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>>>> Fax:   +49 421 200 3103         
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>>
>>> --
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   +49 421 200 3103         
>>
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Wed Nov  7 08:32: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 B7327130E58 for ; Wed,  7 Nov 2018 08:32:10 -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 dmg0S-C3-CNG for ; Wed,  7 Nov 2018 08:32:07 -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 51827130E5C for ; Wed,  7 Nov 2018 08:32:06 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 65072EC0; Wed,  7 Nov 2018 17:32:05 +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 eWxpZlklHuqB; Wed,  7 Nov 2018 17:32:04 +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,  7 Nov 2018 17:32:05 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4D7332003C; Wed,  7 Nov 2018 17:32:05 +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 J21QGUVI6kYB; Wed,  7 Nov 2018 17:32:04 +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 E16A82003F; Wed,  7 Nov 2018 17:32:03 +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, 7 Nov 2018 17:32:03 +0100
Received: by anna.localdomain (Postfix, from userid 501) id CE7AD3003B2A3E; Wed,  7 Nov 2018 17:32:02 +0100 (CET)
Date: Wed, 7 Nov 2018 17:32:02 +0100
From: Juergen Schoenwaelder 
To: Qin Wu 
CC: "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" 
Message-ID: <20181107163202.3espsfrdfaq7rowp@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Qin Wu , "Sterne, Jason (Nokia - CA/Ottawa)" , "netmod@ietf.org" 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] some comments on netmod-base-notification-nmda (validation after commit response, etc)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Nov 2018 16:32:17 -0000

RFC 8342 says:

   However,
    MUST always be a valid configuration data tree, as defined
   in Section 8.1 of [RFC7950].

    is tightly coupled to .  Whenever data is written
   to , the server MUST also immediately update and validate
   .

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

   For simple implementations,  and  are identical.

/js

On Wed, Nov 07, 2018 at 03:37:57PM +0000, Qin Wu wrote:
> 发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Sterne, Jason (Nokia - CA/Ottawa)
> 发送时间: 2018年11月6日 10:56
> 收件人: netmod@ietf.org
> 主题: [netmod] some comments on netmod-base-notification-nmda (validation after commit response, etc)
> 
> Hello,
> 
> The draft mentions that "It is possible that some configuration could not be applied to  due to either validation issues, or missing resource etc."
> 
> But wouldn't validation errors cause an error response to the commit RPC? I'm not clear why there would be validation later in the commit/apply process that wasn't part of the decision to reply OK/NOK to the commit.
> 
> 
> [Qin]:The configuration is written into running via commit operation, but commit operation doesn’t equal to validate operation. Validate operation is defined in RFC6241 to validate, e.g., candidate datastore or the  element containing the complete configuration in the edit config. But RFC6241 doesn’t discuss how validate operation can be applied to intended or other NMDA datastore since NMDA is introduced after RFC6241 gets published.
> 
> 
> 
> As described in RFC8342 and figure 2 of RFC8342
> 
> “Whenever data is written
> 
>    to , the server MUST also immediately update and validate
> 
>    .
> 
> “
> 
> So validate  takes place after commit operation. It involves in configuration transformations to  before intended validation operation.
> 
> The draft also implies that the process of moving config from running -> intended -> operational is decoupled from the application of a candidate -> running.
> - Do systems reply OK/NOK to a commit before config is moved from running->intended->operational ?
> [Qin]: reply OK/NOK indicates whether configuration is written into running but doesn’t tell us whether validation performed on intended is success or failure, validate operation defined in RFC6241 on candidate datastore may be different from Validation operation on intended since it clearly happens at different stage, sure validate operation can be applied to intended, but no standards explicitly specify whether validate operation can be applied to intended.
> This is something we can update in this document.
> 
> - If so, then maybe it isn't correct to have a username in the notifications. A specific user/session did the commit, but then if the commit process ends after candidate->running (i.e. the reply happens at that point), then isn't it really the system moving the config from running->intended->operational?
> [Qin]: See above.
> Jason

> _______________________________________________
> 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 Nov  7 15:21: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 5A989129C6A for ; Wed,  7 Nov 2018 15:21: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=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 vaymqCe916CR for ; Wed,  7 Nov 2018 15:21:38 -0800 (PST)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEE5A1298C5 for ; Wed,  7 Nov 2018 15:21:37 -0800 (PST)
Received: by mail-lj1-x22f.google.com with SMTP id j4-v6so16307152ljc.12 for ; Wed, 07 Nov 2018 15:21:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ATiUS+7hzTq1rsKtLXyP32LL108PPvEuqA5Ymras2gc=; b=nUU/nc3ZIC8xuLO2j6YJP4HmNpaKfyssRa+w2OImlJ788mZSE6oReDiWnJ3Og5GR1f A6tINlqRAKfeWvexghhA1H4XF7WtWabznqjl9SxQglDkEbihs1cDS+/c+ic1dsOI9ymK PczanvINdkQEDWsIw9khlT+77gDJfn36T5LM/lc7M4uNkG8LbGSd0FMLPx9pkeuHrVSU dR3X/WIJY6QvJlvW9cMXXuXJe23XyZQDiqGQCfgUdNpmtaZSmDigFxIA3kEaZSRdr18j Wdf6CG7wAmLT+XjY//eIiIvnAajI/wt9QtnpKcR3ze7Rtf0WqGRY4JCveNkrcgV29uYJ Ph3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ATiUS+7hzTq1rsKtLXyP32LL108PPvEuqA5Ymras2gc=; b=FWA/8bOPdDfnXnXTWLSXMI++HZyLKPRXlWJyM9RP8egl3McLjzRKAsFfqn7sI71ow3 L8FfIobptjzsNsO5UkainPUULYutVX/2FTxyeTQvEUNWw9q32aZ67xszVDtukRIhaGks 4So0ExpbirCIoy8KDIz3eJb5aN6G34HzywGleXT1Z8lmRJQKoJsSsMqmtepAdvgjbivs P/E6T1KQ+TNQtu+Kaen5U9AffJ3cjV9RLMWfqsjxQTFY/TuOLFX6FPMcLF79lZvyDAGl i1oL53K1KUbwwgSGHUnrf4HX44NJD6QO5b2PO7xWtexV3kx1Q85aWYEoQGZuI8HCDX6g LC3g==
X-Gm-Message-State: AGRZ1gIkpJ2WOgvacsoMfmKK8mvWYak+NZ9UJCszgoMiso1AOOCM+HVW 34U/CZPMRZ6O5yLcsqNWEec4zU8BjmAI1btL03+NkA==
X-Google-Smtp-Source: AJdET5f8mGH3S22zL5rJCMEhiuVoy7gymLut6whsl2bsGmoyJuyQW7syYlXE5n0qvsWZNdQDMCUTFGNNBXDgUXd+OT0=
X-Received: by 2002:a2e:744:: with SMTP id i4-v6mr1453412ljd.36.1541632895621;  Wed, 07 Nov 2018 15:21:35 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Wed, 7 Nov 2018 15:21:34 -0800 (PST)
In-Reply-To: 
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <1485DDD0-EB56-422D-A216-4A20F9B63A17@chopps.org>   <01d5056d-7645-cb1d-6e88-fbdbeb8ebca4@cisco.com> <20181026093347.3yomg5bhwilassvf@anna.jacobs.jacobs-university.de>  <69e3974e-69a9-acd4-b0c8-efec63afd8a9@cisco.com> 
From: Andy Bierman 
Date: Wed, 7 Nov 2018 15:21:34 -0800
Message-ID: 
To: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= 
Cc: Robert Wilton ,  Juergen Schoenwaelder , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="0000000000001e2e7b057a1b612d"
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 07 Nov 2018 23:21:47 -0000

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

On Sun, Nov 4, 2018 at 4:39 AM, Bal=C3=A1zs Lengyel 
wrote:

> Implementing 3.2 will be very costly. IMHO Ericsson will not implement it=
.
> We will do our utmost to avoid NBC changes, but if they do happen, I don'=
t
> believe we would support multiple versions.
>
> If the data models are sufficiently NBC e.g. changing a boolean to an
> integer 3.2 may not even be possible. The underlying data that drives the
> device may be an integer or a boolean, but not both. (Strange mapping may
> be possible to imagine, but they will not always work.)
>


IMO the requirements and solutions drafts are both too abstract.
It would help if the authors could point to existing RFCs or I-Ds where a
published module needs specific NBC changes.

The intended usage of the status-stmt in YANG 1.1 seems to be for NBC
changes
to be made by introducing a replacement (maybe sibling) node and changing
the replaced
node status to deprecated.

The requirements draft is not clear at all when this practice should be
followed
and when it is OK to simply change the data node and not deprecate it at
all.
IMO the latter is only OK if the change is truly a bugfix and implementatio=
n
of the previous version SHOULD NOT be done.

Even though this means a server MAY implement the old bugfixed version,
that does not
mean an operator gets to choose both versions active at once in a given
server.
It is reasonable to let the operator configure which version to use.

The solution proposal does not indicate how a protocol would support REQ.
3.2.
E.g., how to say "I mean foo the integer not foo the boolean"

regards Balazs
>
>
>
Andy


> On 2018. 10. 27. 1:15, Robert Wilton wrote:
>
>
>
> On 26/10/2018 17:35, Andy Bierman wrote:
>
>
>
> On Fri, Oct 26, 2018 at 2:33 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
>> Let me add that there was large disagreement what a bug fix is in the
>> design team. Hence, any text that talks about 'bug fixes' is ambiguous
>> and of limited value to achieve consensus. (Or we may find consensus
>> but then not agree on what we have found consensus on.)
>>
>> To be more concrete, I learned that Rob's notion of a bug fix is very
>> different from my notion of a bug fix. I think it is important for
>> having a productive discussion to be aware of this.
>>
>> For me, a bug fix is rather limited, i.e., fixing something where the
>> correct intention was clear but the model did not properly capture the
>> intention correctly, i.e., roughly what we can do with errata in the
>> IETF. I think Rob understands bug fixes in a much broader sense,
>> including fixes to what essentially are in my view module design
>> errors.
>>
>> With my narrow definition of bug fixes, bug fixes are essentially
>> backwards compatible (even if they may violate RFC 7950 rules - but as
>> long as the original intention was clear, we can be flexible).
>>
>> With Rob's notion of bug fixes, we have to handle them as part of the
>> versioning system since they may be non-backwards compatible.
>>
>>
>
> IMO requirements 3.1 and 3.2 are the most  important and have the most
> impact
> on the solution space. I do not agree with either of these requirements.
>
> OK.
>
> For 3.1, I think that just means that the solution has to be backwards
> compatible with existing clients (e.g. don't change the protocols in a no=
n
> backwards compatible way).
>
>
> Implementing multiple non-compatible revisions of a module on a server
> sounds hard,
> not to mention that it breaks RFC 7950 rules.
>
> Completely agree that it will be hard.  I envisage that it will optional
> for servers to implement this.
>
> The current protocols do not support the
> ability to specify different versions of the same QName. This change make=
s
> YANG validation
> much to difficult to specify and implement (as that has to be rewritten a=
s
> well).
>
> The way that I think of one solution for this problem is using datastore
> schema (as per the NMDA definition):
>
> Say for release X, the server natively supports Module A@ver1.0.0 and
> ModuleB@ver1.0.0, call this schema X.
> For release Y, the server natively supports Module A@ver1.1.0 and
> ModuleB@ver2.0.0, call this schema Y.
>
> When a client connects it chooses which schema it wants to use, X, Y, or
> latest.  If it doesn't specify then perhaps it uses the earliest schema (=
to
> handle requirement 3.1).
>
> If the client wants to use X, then the server has to translate the reques=
t
> into the equivalent request using schema Y instead.  Perhaps the server h=
as
> to validate the config both in the context of X and Y.
>
> If the clients wants to use Y then it just talks to the server normally,
> i.e. as it does today.
>
> I think that this is logically the equivalent model mapping that clients
> would have to do to support multiple server revisions.  Yes, I think that
> it is complex.  No, I'm not sure how many vendors will decide to implemen=
t
> this, but I think that it is OK to require the solution to specify how th=
is
> is done, so that servers that do want to support this, and clients that
> want to use this, can do so.
>
> But all the QNames, validations, etc, I think would be constrained to a
> particular schema.
>
>
> It is one thing to deploy rapidly changing, buggy YANG modules in order t=
o
> gain experience quickly..  It is quite another to complicate YANG and the
> protocols
> to preserve these interim mistakes, and bake into the standards the notio=
n
> that this
> is good engineering.
>
> Thanks,
> Rob
>
>
>
> /js
>>
>
> Andy
>
>
>>
>> On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert Wilton wrote:
>> > Hi Chris,
>> >
>> >
>> > On 25/10/2018 18:42, Christian Hopps wrote:
>> > >
>> > > Hi Rob,
>> > >
>> > > We've more privately discussed the bug-fix scenario and I'm
>> sympathetic
>> > > to it; however, the requirement as written does not restrict itself =
to
>> > > fixing module definition bugs (e.g., a pattern or other value
>> > > constraint) in some small but incompatible way -- instead it's wide
>> open
>> > > and it will be [ab]used that way.
>> > I think that everyone on design team agrees that
>> non-backwards-compatible
>> > changes should be minimized and should really only to used for bug fix=
es
>> > where it is anticipated that clients should not be affected.
>> >
>> > We want to allow non-backwards-compatible changes at the head of the
>> > development tree, but again, I think that everyone agrees that keeping
>> it
>> > backwards compatible where possible is a good goal.
>> >
>> > However, I think that there will be cases where a vendor decides that
>> it is
>> > right for an enhancement or non backwards compatible change to be made
>> to an
>> > already released module.  I agree that this is highly undesirable and =
an
>> > abuse of the rules, but I don't believe that whatever versioning schem=
e
>> we
>> > come up with will prevent vendors from doing this.  So then the questi=
on
>> > becomes: Is it better to pretend that this scenario will never happen,
>> > design the versioning scheme so that it cannot be expressed, which
>> probably
>> > just means that clients will not be able to detect when vendors do thi=
s
>> by
>> > cheating the rules!  Or is it better to accept that this will sometime=
s
>> > occur, provide strong guidance as to why this is bad practice and
>> should be
>> > avoided, but have a versioning scheme that still allows this to be
>> expressed
>> > (in a bounded way)?  I.e. even if the vendors are doing something that
>> is
>> > less than ideal, at least the clients can spot where they have done
>> this.
>> >
>> > ---
>> >
>> > A separate concern that we had about ties this strictly to bug fixes i=
s
>> that
>> > some one will ask for a definition of a bug fix.  The design team trie=
d
>> this
>> > but we couldn't even agree what a bug fix is, let alone agree with a
>> single
>> > definition of a bug fix as it related to a YANG module.  So our
>> conclusion
>> > was that perhaps it is better not to tie the requirements themselves t=
o
>> bug
>> > fix vs enhancement, because the boundary between the two is too vague,
>> and
>> > module writers will bend the rules.
>> >
>> > So I see that the rules should be:
>> >  - backwards compatible bug fix  - this is fine.
>> >  - non backwards compatible bug fix - this is fine if it is
>> pragmatically
>> > expected to not impact any clients, but careful consideration is
>> required if
>> > it might break clients.
>> >  - backwards compatible enhancement - not ideal, but pragmatically OK.
>> >  - non backwards compatible enhancement - this is bad and should be
>> avoided.
>> >
>> > But if we don't want to define the difference between a bug fix vs
>> > enhancement then I think that you end up with the most general
>> requirement
>> > being that we do want to allow for non-backwards-compatible changes in
>> > released modules to accommodate the bug fix scenario, but the
>> expectation
>> > (and guidance) will be that they should only be used for bug fixes.
>> >
>> >
>> > >
>> > > For example:
>> > >
>> > > > Here is what I am afraid the vendors want here: A developer on
>> > > > release train X can easily change some data structure and then pus=
h
>> > > > the change into an automated system which generates a new YANG
>> > > > module definition and revs a version number -- all done! They don'=
t
>> > > > have to deal with the inertia of making this change in their relea=
se
>> > > > train Y or Z and they don't have to treat modules as a stable API
>> > > > they are exporting, b/c they now have these new wonderful versions
>> > > > from this work. Meanwhile we the users now have to deal with N for=
ks
>> > > > with all the various little incompatible changes random developers
>> > > > at the company wanted to make without having to coordinate with
>> > > > their coworkers/other internal teams. Now multiply this by M
>> > > > vendors. It's a nightmare. It shouldn't be what we are optimizing
>> > > > for, let alone making a requirement.
>> > >
>> > > Regarding enhancements, these are features, and are naturally
>> > > augmentative. I find it hard to believe we have a pressing
>> > > need/requirement to support non-backward compatible changes to
>> existing
>> > > modules in order to support enhancements.
>> > I agree.  It was a backwards compatible enhancement that I was
>> considering.
>> >
>> > Thanks,
>> > Rob
>> >
>> >
>> > >
>> > > Thanks,
>> > > Chris.
>> > >
>> > >
>> > > Robert Wilton  writes:
>> > >
>> > > > Hi Chris,
>> > > >
>> > > > I think that there are two things driving this requirement:
>> > > >
>> > > > What I regard as the key one, is that we want to be able to suppor=
t
>> > > > the software
>> > > > that we have shipped. In particular, we may need to fix bugs
>> > > > (perhaps at the
>> > > > operators request) to a YANG model that has already been released.
>> > > > I.e. I think
>> > > > that there are some scenarios, where forking a YANG module, althou=
gh
>> > > > undesirable
>> > > > is the right thing to do to include a fix. I don't believe that
>> > > > features or
>> > > > deviations help solve this problem.
>> > > > The two alternative solutions to being able to fix bugs, neither o=
f
>> > > > which I
>> > > > think is pragmatic, that I can think of are:
>> > > > (i) Vendors ensure that their YANG modules are perfect before they
>> > > > ship in a
>> > > > release.
>> > > > (ii) If a bug is reported, operators are happy to wait until the b=
ug
>> > > > has been
>> > > > fixed in the current development release, and will migrate to that
>> > > > latest
>> > > > release to pick up the fix.
>> > > >
>> > > > The second thing driving this requirement is that vendors sometime=
s
>> > > > get asked
>> > > > for enhancements to existing releases, perhaps because the latest
>> > > > development
>> > > > release is too far out, or ask for an enhancement on the current
>> > > > train to be
>> > > > back ported to an older release.
>> > > >
>> > > > So, aiming to have stable YANG modules, trying a lot harder to avo=
id
>> > > > non-backwards-compatible changes, and keeping new functionality to
>> > > > the head of
>> > > > the development I completely agree with you on. But I still believ=
e
>> > > > that there
>> > > > are some valid scenarios, that should be limited as much as
>> > > > possible, where it
>> > > > is necessary to make changes that sometimes break these rules, and
>> > > > having a
>> > > > limited scheme that clearly indicates where such breakages have
>> > > > occurred is
>> > > > probably better that the status quo of where the modules get
>> > > > changed, but the
>> > > > operator doesn't get any useful indication of what type of changes
>> > > > are being
>> > > > made.
>> > > >
>> > > > Thanks,
>> > > > Rob
>> > > >
>> > > >
>> > > > On 25/10/2018 16:26, Christian Hopps wrote:
>> > > > >
>> > > > > > On Oct 20, 2018, at 1:55 PM, Joe Clarke 
>> wrote:
>> > > > > >
>> > > > > > * New requirement 1.4 for supporting over-arching software
>> releases
>> > > > > [ I read this as supporting various different module versions
>> > > > > based on a vendor's different software release trains. If this
>> > > > > is wrong then the rest of this doesn't apply and I would just
>> > > > > ask for the text to be update to clarify what it means. ]
>> > > > >
>> > > > > How many operators/users have asked for this or indicated it's a
>> > > > > requirement for them?
>> > > > >
>> > > > > What problem is intractable without this requirement being met,
>> > > > > and what is the cost of this requirement on the actual users?
>> > > > >
>> > > > > I have pushed back multiple times on this b/c I believe this
>> > > > > "requirement" is really being pushed to make it easier for
>> > > > > vendors (a small affected group) to develop their software at
>> > > > > the cost of their users (the much larger affected group) who
>> > > > > would then have to deal with multiple trains of the same module.
>> > > > >
>> > > > >
>> > > > > We already have features and deviations why are they not enough
>> > > > > to deal with functionality that is present or not in various
>> > > > > software release/devices?
>> > > > >
>> > > > > FWIW I'm not against making it easier to develop software, but
>> > > > > we have to be mindful if we are just pushing the cost (and
>> > > > > magnifying it greatly) to other people in the community..
>> > > > >
>> > > > > Thanks,
>> > > > > Chris.
>> > > > >
>> > > > > _______________________________________________
>> > > > > netmod mailing list
>> > > > > netmod@ietf.org
>> > > > > https://www.ietf.org/mailman/listinfo/netmod
>> > > > > .
>> > > > >
>> > >
>> > > .
>> > >
>> >
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/n=
etmod
>
>
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/n=
etmod
>
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>
>

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




On Sun, Nov 4, 2018 at 4:39 AM, Bal=C3=A1zs Lengyel &=
lt;balazs.=
lengyel@ericsson.com> wrote:

    
Implementing 3.2 will be very costly. IMHO Ericsson will not
      implement it. We will do our utmost to avoid NBC changes, but if
      they do happen, I don't believe we would support multiple
      versions.

    

    
If the data models are sufficiently NBC e.g. changing a boolean
      to an integer 3.2 may not even be possible. The underlying data
      that drives the device may be an integer or a boolean, but not
      both. (Strange mapping may be possible to imagine, but they will
      not always work.)


IMO the requirements and solutions drafts are both too abstract.
It would help if the authors could point to existing RFCs or I-Ds whe=
re a
published module needs specific NBC changes.

<=
/div>
The intended usage of the status-stmt in YANG 1.1 seems to be for=
 NBC changes
to be made by introducing a replacement (maybe sibli=
ng) node and changing the replaced
node status to deprecated.

The requirements draft is not clear at all when this =
practice should be followed
and when it is OK to simply change th=
e data node and not deprecate it at all.
IMO the latter is only O=
K if the change is truly a bugfix and implementation
of the previ=
ous version SHOULD NOT be done.

Even though this m=
eans a server MAY implement the old bugfixed version, that does not
mean an operator gets to choose both versions active at once in a given =
server.
It is reasonable to let the operator configure which vers=
ion to use.

The solution proposal does not indicat=
e how a protocol would support REQ. 3.2.
E.g., how to say "I=
 mean foo the integer not foo the boolean"


    
regards Balazs

    


Andy
=C2=A0=


    

    
On 2018. 10. 27. 1:15=
, Robert Wilton
      wrote:

    

    

     =20
      


      

      

      
On 26/10/2018 17:35=
, Andy Bierman
        wrote:

      

      

        

          


            


              
On Fri, Oct 26, 2018 at 2:33 AM,
                Juergen Schoenwaelder <j.schoenwaelder@=
jacobs-university.de>
                wrote:

                
Let me ad=
d that
                  there was large disagreement what a bug fix is in the

                  design team. Hence, any text that talks about 'bug
                  fixes' is ambiguous

                  and of limited value to achieve consensus. (Or we may
                  find consensus

                  but then not agree on what we have found consensus
                  on.)

                  

                  To be more concrete, I learned that Rob's notion of a
                  bug fix is very

                  different from my notion of a bug fix. I think it is
                  important for

                  having a productive discussion to be aware of this.

                  

                  For me, a bug fix is rather limited, i.e., fixing
                  something where the

                  correct intention was clear but the model did not
                  properly capture the

                  intention correctly, i.e., roughly what we can do with
                  errata in the

                  IETF. I think Rob understands bug fixes in a much
                  broader sense,

                  including fixes to what essentially are in my view
                  module design

                  errors.

                  

                  With my narrow definition of bug fixes, bug fixes are
                  essentially

                  backwards compatible (even if they may violate RFC
                  7950 rules - but as

                  long as the original intention was clear, we can be
                  flexible).

                  

                  With Rob's notion of bug fixes, we have to handle the=
m
                  as part of the

                  versioning system since they may be non-backwards
                  compatible.

                  

                

                


                

                


                

                
IMO requirements 3.1 and 3.2 are the most
                  =C2=A0important and have the most impact

                
on the solution space. I do not agree with either
                  of these requirements.

              

            

          

        

      

      OK.

      

      For 3.1, I think that just means that the solution has to be
      backwards compatible with existing clients (e.g. don't change the
      protocols in a non backwards compatible way).

      

      

        

          

            

              

                


                

                
Implementing multiple non-compatible revisions of a
                  module on a server sounds hard,

                
not to mention that it breaks RFC 7950 rules. 

              

            

          

        

      

      Completely agree that it will be hard.=C2=A0 I envisage that it will
      optional for servers to implement this.

      

      

        

          

            

              

                
The current protocols do not support the

                
ability to specify different versions of the same
                  QName. This change makes YANG validation

                
much to difficult to specify and implement (as that
                  has to be rewritten as well).

              

            

          

        

      

      The way that I think of one solution for this problem is using
      datastore schema (as per the NMDA definition):

      

      Say for release X, the server natively supports Module A@ver1.0.0 and ModuleB@ve=
r1.0.0, call this schema X.

      For release Y, the server natively supports Module A@ver1.1.0 and ModuleB@ver2.0=
.0, call this schema Y.

      

      When a client connects it chooses which schema it wants to use, X,
      Y, or latest.=C2=A0 If it doesn't specify then perhaps it uses th=
e
      earliest schema (to handle requirement 3.1).

      

      If the client wants to use X, then the server has to translate the
      request into the equivalent request using schema Y instead.=C2=A0
      Perhaps the server has to validate the config both in the context
      of X and Y.

      

      If the clients wants to use Y then it just talks to the server
      normally, i.e. as it does today.

      

      I think that this is logically the equivalent model mapping that
      clients would have to do to support multiple server revisions.=C2=A0
      Yes, I think that it is complex.=C2=A0 No, I'm not sure how many
      vendors will decide to implement this, but I think that it is OK
      to require the solution to specify how this is done, so that
      servers that do want to support this, and clients that want to use
      this, can do so.

      

      But all the QNames, validations, etc, I think would be constrained
      to a particular schema.

      

      

        

          

            

              

                


                

                
It is one thing to deploy rapidly changing, buggy
                  YANG modules in order to

                
gain experience quickly..=C2=A0 It is quite another to
                  complicate YANG and the protocols

                
to preserve these interim mistakes, and bake into
                  the standards the notion that this

                
is good engineering.

              

            

          

        

      

      Thanks,

      Rob

      

      

        

          

            

              

                


                

                


                

                
 /js

                

                


                

                
Andy

                
=C2=A0

                
 

                  On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert
                  Wilton wrote:

                  > Hi Chris,

                  > 

                  > 

                  > On 25/10/2018 18:42, Christian Hopps wrote:

                  > > 

                  > > Hi Rob,

                  > > 

                  > > We've more privately discussed the bug-fix
                  scenario and I'm sympathetic

                  > > to it; however, the requirement as written
                  does not restrict itself to

                  > > fixing module definition bugs (e.g., a
                  pattern or other value

                  > > constraint) in some small but incompatible
                  way -- instead it's wide open

                  > > and it will be [ab]used that way.

                  > I think that everyone on design team agrees that
                  non-backwards-compatible

                  > changes should be minimized and should really
                  only to used for bug fixes

                  > where it is anticipated that clients should not
                  be affected.

                  > 

                  > We want to allow non-backwards-compatible changes
                  at the head of the

                  > development tree, but again, I think that
                  everyone agrees that keeping it

                  > backwards compatible where possible is a good
                  goal.

                  > 

                  > However, I think that there will be cases where a
                  vendor decides that it is

                  > right for an enhancement or non backwards
                  compatible change to be made to an

                  > already released module.=C2=A0 I agree that this is
                  highly undesirable and an

                  > abuse of the rules, but I don't believe that
                  whatever versioning scheme we

                  > come up with will prevent vendors from doing
                  this.=C2=A0 So then the question

                  > becomes: Is it better to pretend that this
                  scenario will never happen,

                  > design the versioning scheme so that it cannot be
                  expressed, which probably

                  > just means that clients will not be able to
                  detect when vendors do this by

                  > cheating the rules!=C2=A0 Or is it better to accept
                  that this will sometimes

                  > occur, provide strong guidance as to why this is
                  bad practice and should be

                  > avoided, but have a versioning scheme that still
                  allows this to be expressed

                  > (in a bounded way)?=C2=A0 I.e. even if the vendors a=
re
                  doing something that is

                  > less than ideal, at least the clients can spot
                  where they have done this.

                  > 

                  > ---

                  > 

                  > A separate concern that we had about ties this
                  strictly to bug fixes is that

                  > some one will ask for a definition of a bug fix.=C2=
=A0
                  The design team tried this

                  > but we couldn't even agree what a bug fix is, le=
t
                  alone agree with a single

                  > definition of a bug fix as it related to a YANG
                  module.=C2=A0 So our conclusion

                  > was that perhaps it is better not to tie the
                  requirements themselves to bug

                  > fix vs enhancement, because the boundary between
                  the two is too vague, and

                  > module writers will bend the rules.

                  > 

                  > So I see that the rules should be:

                  > =C2=A0- backwards compatible bug fix=C2=A0 - this is=
 fine.

                  > =C2=A0- non backwards compatible bug fix - this is
                  fine if it is pragmatically

                  > expected to not impact any clients, but careful
                  consideration is required if

                  > it might break clients.

                  > =C2=A0- backwards compatible enhancement - not ideal=
,
                  but pragmatically OK.

                  > =C2=A0- non backwards compatible enhancement - this =
is
                  bad and should be avoided.

                  > 

                  > But if we don't want to define the difference
                  between a bug fix vs

                  > enhancement then I think that you end up with the
                  most general requirement

                  > being that we do want to allow for
                  non-backwards-compatible changes in

                  > released modules to accommodate the bug fix
                  scenario, but the expectation

                  > (and guidance) will be that they should only be
                  used for bug fixes.

                  > 

                  > 

                  > > 

                  > > For example:

                  > > 

                  > > > Here is what I am afraid the vendors
                  want here: A developer on

                  > > > release train X can easily change some
                  data structure and then push

                  > > > the change into an automated system
                  which generates a new YANG

                  > > > module definition and revs a version
                  number -- all done! They don't

                  > > > have to deal with the inertia of making
                  this change in their release

                  > > > train Y or Z and they don't have to
                  treat modules as a stable API

                  > > > they are exporting, b/c they now have
                  these new wonderful versions

                  > > > from this work. Meanwhile we the users
                  now have to deal with N forks

                  > > > with all the various little
                  incompatible changes random developers

                  > > > at the company wanted to make without
                  having to coordinate with

                  > > > their coworkers/other internal teams.
                  Now multiply this by M

                  > > > vendors. It's a nightmare. It shouldn&=
#39;t
                  be what we are optimizing

                  > > > for, let alone making a requirement.

                  > > 

                  > > Regarding enhancements, these are features,
                  and are naturally

                  > > augmentative. I find it hard to believe we
                  have a pressing

                  > > need/requirement to support non-backward
                  compatible changes to existing

                  > > modules in order to support enhancements.

                  > I agree.=C2=A0 It was a backwards compatible
                  enhancement that I was considering.

                  > 

                  > Thanks,

                  > Rob

                  > 

                  > 

                  > > 

                  > > Thanks,

                  > > Chris.

                  > > 

                  > > 

                  > > Robert Wilton <rwilton@cisco.com>
                  writes:

                  > > 

                  > > > Hi Chris,

                  > > > 

                  > > > I think that there are two things
                  driving this requirement:

                  > > > 

                  > > > What I regard as the key one, is that
                  we want to be able to support

                  > > > the software

                  > > > that we have shipped. In particular, we
                  may need to fix bugs

                  > > > (perhaps at the

                  > > > operators request) to a YANG model that
                  has already been released.

                  > > > I.e. I think

                  > > > that there are some scenarios, where
                  forking a YANG module, although

                  > > > undesirable

                  > > > is the right thing to do to include a
                  fix. I don't believe that

                  > > > features or

                  > > > deviations help solve this problem.

                  > > > The two alternative solutions to being
                  able to fix bugs, neither of

                  > > > which I

                  > > > think is pragmatic, that I can think of
                  are:

                  > > > (i) Vendors ensure that their YANG
                  modules are perfect before they

                  > > > ship in a

                  > > > release.

                  > > > (ii) If a bug is reported, operators
                  are happy to wait until the bug

                  > > > has been

                  > > > fixed in the current development
                  release, and will migrate to that

                  > > > latest

                  > > > release to pick up the fix.

                  > > > 

                  > > > The second thing driving this
                  requirement is that vendors sometimes

                  > > > get asked

                  > > > for enhancements to existing releases,
                  perhaps because the latest

                  > > > development

                  > > > release is too far out, or ask for an
                  enhancement on the current

                  > > > train to be

                  > > > back ported to an older release.

                  > > > 

                  > > > So, aiming to have stable YANG modules,
                  trying a lot harder to avoid

                  > > > non-backwards-compatible changes, and
                  keeping new functionality to

                  > > > the head of

                  > > > the development I completely agree with
                  you on. But I still believe

                  > > > that there

                  > > > are some valid scenarios, that should
                  be limited as much as

                  > > > possible, where it

                  > > > is necessary to make changes that
                  sometimes break these rules, and

                  > > > having a

                  > > > limited scheme that clearly indicates
                  where such breakages have

                  > > > occurred is

                  > > > probably better that the status quo of
                  where the modules get

                  > > > changed, but the

                  > > > operator doesn't get any useful
                  indication of what type of changes

                  > > > are being

                  > > > made.

                  > > > 

                  > > > Thanks,

                  > > > Rob

                  > > > 

                  > > > 

                  > > > On 25/10/2018 16:26, Christian Hopps
                  wrote:

                  > > > > 

                  > > > > > On Oct 20, 2018, at 1:55 PM,
                  Joe Clarke <jclarke@cisco.com>
                  wrote:

                  > > > > > 

                  > > > > > * New requirement 1.4 for
                  supporting over-arching software releases

                  > > > > [ I read this as supporting
                  various different module versions

                  > > > > based on a vendor's different
                  software release trains. If this

                  > > > > is wrong then the rest of this
                  doesn't apply and I would just

                  > > > > ask for the text to be update to
                  clarify what it means. ]

                  > > > > 

                  > > > > How many operators/users have
                  asked for this or indicated it's a

                  > > > > requirement for them?

                  > > > > 

                  > > > > What problem is intractable
                  without this requirement being met,

                  > > > > and what is the cost of this
                  requirement on the actual users?

                  > > > > 

                  > > > > I have pushed back multiple times
                  on this b/c I believe this

                  > > > > "requirement" is really bei=
ng
                  pushed to make it easier for

                  > > > > vendors (a small affected group)
                  to develop their software at

                  > > > > the cost of their users (the much
                  larger affected group) who

                  > > > > would then have to deal with
                  multiple trains of the same module.

                  > > > > 

                  > > > > 

                  > > > > We already have features and
                  deviations why are they not enough

                  > > > > to deal with functionality that is
                  present or not in various

                  > > > > software release/devices?

                  > > > > 

                  > > > > FWIW I'm not against making it
                  easier to develop software, but

                  > > > > we have to be mindful if we are
                  just pushing the cost (and

                  > > > > magnifying it greatly) to other
                  people in the community..

                  > > > > 

                  > > > > Thanks,

                  > > > > Chris.

                  > > > > 

                  > > > > ________________________________=
_______________

                  > > > > netmod mailing list

                  > > > > netmod@ietf.org

                  > > > > https://www.ietf.o=
rg/mailman/listinfo/netmod

                  > > > > .

                  > > > > 

                  > > 

                  > > .

                  > > 

                  > 

                  > _______________________________________________=


                  > netmod mailing list

                  > netmod@ietf.org

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

                  

                      -- 

                      Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0Jacobs University
                      Bremen gGmbH

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

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

                      _______________________________________________<=
br>
                      netmod mailing list

                      =
netmod@ietf.org

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

                    

              

              

            

          

        

        

        

        

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


      

      

      

      

      
_____________________=
__________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mai=
lman/listinfo/netmod


    

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


  







--0000000000001e2e7b057a1b612d--


From nobody Wed Nov  7 20:27:36 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 9CB481276D0; Wed,  7 Nov 2018 20:27:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla 
To: "The IESG" 
Cc: draft-ietf-netmod-schema-mount@ietf.org, Joel Jaeggli ,  Lou Berger , Kent Watsen , netmod-chairs@ietf.org, joelja@gmail.com, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154165125463.26467.7203154311829783289.idtracker@ietfa.amsl.com>
Date: Wed, 07 Nov 2018 20:27:34 -0800
Archived-At: 
Subject: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-schema-mount-12: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Nov 2018 04:27:35 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-netmod-schema-mount-12: No Objection

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


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


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



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

Thank you for addressing my DISCUSS



From nobody Wed Nov  7 20:59: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 1F79A130F15; Wed,  7 Nov 2018 20:59:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Dw4Cy_z6wmrD; Wed,  7 Nov 2018 20:59:16 -0800 (PST)
Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (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 6161C130E82; Wed,  7 Nov 2018 20:59:16 -0800 (PST)
Received: by mail-pg1-x543.google.com with SMTP id q5-v6so8338461pgv.0; Wed, 07 Nov 2018 20:59:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pMQo/8yP4olsjPwbEKBLyDPAvrrCEsW92xhmwI3g2mQ=; b=Fi4fPG1ENNSJRWLsj2pbMqgROlPzPUgdY+H/47q6H44jzmvVBZBWEV2tG+8LiaSiyT WSoKg2ZnvTvOPsOaneak7hMC5w3Vlxf2RJ8Ba/YXg3PoM7bEZ0Hhxuqp7v3uRktAFvSE tCzwJlKgjELni8NkfIntkxb+9L+GBmYkX1839uS8i7iU10U04Rz0OW63rSumMEIBlDeX JnatAq7ixuO/G+VH6h4mm/ySmJucZhvkTSdrTa0xbyb23+Hr6D5iC8oTBnBh++9Z+oCb IZwxgKACwlJmCyjbALNdyB3wLJ5p52JiuL0wjd4wnHNFt3vqSJ0BrJSy4zgXNV9WuoTF LHLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pMQo/8yP4olsjPwbEKBLyDPAvrrCEsW92xhmwI3g2mQ=; b=l2/QVC3rQT5mTh8jOdy3jJ8p0mhnBhlngtiupm8toDV/dFUGl+8CrhaE9NC4RoMUF/ LDM1J1a702cbv+6U4gcarbn8MF0GGPA2e/TMR7jTipJz26xTy6JMzsw3qg2PLQpyhQz2 zqxfDJ7pErs1Bqg8KaKjJ3aeuE9R0vOo3s1+VtMXH6IfG0smhERUrdMlh8C2W0ASI1SQ +Ey6nXouhlLSWyUDH+IMTkjxkIocC+8O4I7hmbDO21gsqsXY9UKz9Uyxww06LqVDZ4za 0FgXYhvFZGX+e+A3MHtNYDrfBEdSlFh42KmfplLAj+jKm5ZWshkFB3Wdcr/EkJ7Or/qN PtoQ==
X-Gm-Message-State: AGRZ1gKsMTLEXzbePD/LtX0ZKShvEgxDWWwgdi6ATq0Xmuomoso8+Pwf PjXlnjMR5syFLY/gbMgMGj8=
X-Google-Smtp-Source: AJdET5fapCQxrGZbnbaEF4xyU8leeNlUzdPFp+DtQSWfg2wezhrZqGhwQw9fHkTmKpnkA1TapQDibg==
X-Received: by 2002:a62:9989:: with SMTP id t9-v6mr3119793pfk.179.1541653155709;  Wed, 07 Nov 2018 20:59:15 -0800 (PST)
Received: from ?IPv6:2001:67c:370:128:85ca:8c79:da2a:16d2? ([2001:67c:370:128:85ca:8c79:da2a:16d2]) by smtp.gmail.com with ESMTPSA id n2-v6sm2279705pgg.86.2018.11.07.20.59.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 20:59:14 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: joel jaeggli 
In-Reply-To: <154165125463.26467.7203154311829783289.idtracker@ietfa.amsl.com>
Date: Thu, 8 Nov 2018 11:59:09 +0700
Cc: The IESG , draft-ietf-netmod-schema-mount@ietf.org, Lou Berger , Kent Watsen , netmod-chairs@ietf.org, netmod@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <1DA6E8D2-A8C1-4C60-95EA-9A4C97552504@gmail.com>
References: <154165125463.26467.7203154311829783289.idtracker@ietfa.amsl.com>
To: Eric Rescorla 
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: 
Subject: Re: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-schema-mount-12: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Nov 2018 04:59:23 -0000

Thanks all

Glad that was acceptable.

Joel 


> On Nov 8, 2018, at 11:27, Eric Rescorla  wrote:
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-netmod-schema-mount-12: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for addressing my DISCUSS
> 
> 


From nobody Wed Nov  7 21:38:16 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E222127148; Wed,  7 Nov 2018 21:38:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCnjLQWZZ_Q5; Wed,  7 Nov 2018 21:38:02 -0800 (PST)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA28124408; Wed,  7 Nov 2018 21:38:02 -0800 (PST)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id wA85bxKY031907; Thu, 8 Nov 2018 05:37:59 GMT
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1A3CC22044; Thu,  8 Nov 2018 05:37:59 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs2.iomartmail.com (Postfix) with ESMTPS id 04A2822042; Thu,  8 Nov 2018 05:37:59 +0000 (GMT)
Received: from 950129200 (dhcp-984f.meeting.ietf.org [31.133.152.79]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id wA85bswF011560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2018 05:37:56 GMT
Reply-To: 
From: "Adrian Farrel" 
To: "'Eric Rescorla'" , "'The IESG'" 
Cc: , , , 
References: <154165125463.26467.7203154311829783289.idtracker@ietfa.amsl.com>
In-Reply-To: <154165125463.26467.7203154311829783289.idtracker@ietfa.amsl.com>
Date: Thu, 8 Nov 2018 05:37:52 -0000
Message-ID: <026701d47725$33e3cf10$9bab6d30$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHFJVVUuzz2dn8SaCZZXclmc4L4OqVj/2vg
Content-Language: en-gb
X-Originating-IP: 31.133.152.79
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24210.005
X-TM-AS-Result: No--15.504-10.0-31-10
X-imss-scan-details: No--15.504-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24210.005
X-TMASE-Result: 10--15.504000-10.000000
X-TMASE-MatchedRID: oTBA/+sdKabxIbpQ8BhdbOYAh37ZsBDClvTuxOaR0gLadW4iYSMjUXAW uORm0TIa7rYjKjSGs+0Bryn+euSfXYT3OBUyTeleMGAKZueP0mY6En2bnefhoOvyo+XEW/dx4c8 iVvPqSut57OZgMiSXUJvam7E/mkYpYWo9dIuk10DCtSG/SQAC8QBzfxM7vRJxVz8J52OVy+Rh92 j5NFYaFu5f+SbQ7VhgHmGY/o4z88lNfs8n85Te8v7E6GNqs6ce/W9MYGK5mu1TZDOrzlZ+cHQdJ 7XfU86eOwBXM346/+yhocJb61oHvG4waMnEWQ8So8rizrkqBDQCcs0kdJWDfleqTkiaDxvx
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: 
Subject: Re: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-schema-mount-12: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Nov 2018 05:38:05 -0000

Thanks!

Was a useful Discuss, and good to be moving the cluster forward.

Adrian

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Eric Rescorla
> Sent: 08 November 2018 04:28
> To: The IESG
> Cc: netmod-chairs@ietf.org; netmod@ietf.org; joelja@gmail.com; draft-ietf-
> netmod-schema-mount@ietf.org
> Subject: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-schema-
> mount-12: (with COMMENT)
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-netmod-schema-mount-12: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for addressing my DISCUSS
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Nov  8 13:40: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 D76A7129385 for ; Thu,  8 Nov 2018 13:40:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TjiyDBv3xDdk for ; Thu,  8 Nov 2018 13:40:01 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A6F8E12D4E8 for ; Thu,  8 Nov 2018 13:40:00 -0800 (PST)
Received: from localhost (h-255-177.A165.priv.bahnhof.se [176.10.255.177]) by mail.tail-f.com (Postfix) with ESMTPSA id 0B1001AE0936; Thu,  8 Nov 2018 22:39:58 +0100 (CET)
Date: Thu, 08 Nov 2018 22:39:57 +0100 (CET)
Message-Id: <20181108.223957.1204257041429418398.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20181026093347.3yomg5bhwilassvf@anna.jacobs.jacobs-university.de>
References:  <01d5056d-7645-cb1d-6e88-fbdbeb8ebca4@cisco.com> <20181026093347.3yomg5bhwilassvf@anna.jacobs.jacobs-university.de>
X-Mailer: Mew version 6.7 on Emacs 25.2 / 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] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Nov 2018 21:40:04 -0000

Hi,

Juergen Schoenwaelder  wrote:
> Let me add that there was large disagreement what a bug fix is in the=

> design team. Hence, any text that talks about 'bug fixes' is ambiguou=
s
> and of limited value to achieve consensus. (Or we may find consensus
> but then not agree on what we have found consensus on.)
> =

> To be more concrete, I learned that Rob's notion of a bug fix is very=

> different from my notion of a bug fix. I think it is important for
> having a productive discussion to be aware of this.
> =

> For me, a bug fix is rather limited, i.e., fixing something where the=

> correct intention was clear but the model did not properly capture th=
e
> intention correctly, i.e., roughly what we can do with errata in the
> IETF. I think Rob understands bug fixes in a much broader sense,
> including fixes to what essentially are in my view module design
> errors.
> =

> With my narrow definition of bug fixes, bug fixes are essentially
> backwards compatible (even if they may violate RFC 7950 rules - but a=
s
> long as the original intention was clear, we can be flexible).

I agree with this interpretation of a bug fix.  For example
fixing incorrect patterns (e.g. errata 3957 that Andy mentioned).



/martin



> With Rob's notion of bug fixes, we have to handle them as part of the=

> versioning system since they may be non-backwards compatible.
> =

> /js
> =

> On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert Wilton wrote:
> > Hi Chris,
> > =

> > =

> > On 25/10/2018 18:42, Christian Hopps wrote:
> > > =

> > > Hi Rob,
> > > =

> > > We've more privately discussed the bug-fix scenario and I'm sympa=
thetic
> > > to it; however, the requirement as written does not restrict itse=
lf to
> > > fixing module definition bugs (e.g., a pattern or other value
> > > constraint) in some small but incompatible way -- instead it's wi=
de open
> > > and it will be [ab]used that way.
> > I think that everyone on design team agrees that non-backwards-comp=
atible
> > changes should be minimized and should really only to used for bug =
fixes
> > where it is anticipated that clients should not be affected.
> > =

> > We want to allow non-backwards-compatible changes at the head of th=
e
> > development tree, but again, I think that everyone agrees that keep=
ing it
> > backwards compatible where possible is a good goal.
> > =

> > However, I think that there will be cases where a vendor decides th=
at it is
> > right for an enhancement or non backwards compatible change to be m=
ade to an
> > already released module.=A0 I agree that this is highly undesirable=
 and an
> > abuse of the rules, but I don't believe that whatever versioning sc=
heme we
> > come up with will prevent vendors from doing this.=A0 So then the q=
uestion
> > becomes: Is it better to pretend that this scenario will never happ=
en,
> > design the versioning scheme so that it cannot be expressed, which =
probably
> > just means that clients will not be able to detect when vendors do =
this by
> > cheating the rules!=A0 Or is it better to accept that this will som=
etimes
> > occur, provide strong guidance as to why this is bad practice and s=
hould be
> > avoided, but have a versioning scheme that still allows this to be =
expressed
> > (in a bounded way)?=A0 I.e. even if the vendors are doing something=
 that is
> > less than ideal, at least the clients can spot where they have done=
 this.
> > =

> > ---
> > =

> > A separate concern that we had about ties this strictly to bug fixe=
s is that
> > some one will ask for a definition of a bug fix.=A0 The design team=
 tried this
> > but we couldn't even agree what a bug fix is, let alone agree with =
a single
> > definition of a bug fix as it related to a YANG module.=A0 So our c=
onclusion
> > was that perhaps it is better not to tie the requirements themselve=
s to bug
> > fix vs enhancement, because the boundary between the two is too vag=
ue, and
> > module writers will bend the rules.
> > =

> > So I see that the rules should be:
> > =A0- backwards compatible bug fix=A0 - this is fine.
> > =A0- non backwards compatible bug fix - this is fine if it is pragm=
atically
> > expected to not impact any clients, but careful consideration is re=
quired if
> > it might break clients.
> > =A0- backwards compatible enhancement - not ideal, but pragmaticall=
y OK.
> > =A0- non backwards compatible enhancement - this is bad and should =
be avoided.
> > =

> > But if we don't want to define the difference between a bug fix vs
> > enhancement then I think that you end up with the most general requ=
irement
> > being that we do want to allow for non-backwards-compatible changes=
 in
> > released modules to accommodate the bug fix scenario, but the expec=
tation
> > (and guidance) will be that they should only be used for bug fixes.=

> > =

> > =

> > > =

> > > For example:
> > > =

> > > > Here is what I am afraid the vendors want here: A developer on
> > > > release train X can easily change some data structure and then =
push
> > > > the change into an automated system which generates a new YANG
> > > > module definition and revs a version number -- all done! They d=
on't
> > > > have to deal with the inertia of making this change in their re=
lease
> > > > train Y or Z and they don't have to treat modules as a stable A=
PI
> > > > they are exporting, b/c they now have these new wonderful versi=
ons
> > > > from this work. Meanwhile we the users now have to deal with N =
forks
> > > > with all the various little incompatible changes random develop=
ers
> > > > at the company wanted to make without having to coordinate with=

> > > > their coworkers/other internal teams. Now multiply this by M
> > > > vendors. It's a nightmare. It shouldn't be what we are optimizi=
ng
> > > > for, let alone making a requirement.
> > > =

> > > Regarding enhancements, these are features, and are naturally
> > > augmentative. I find it hard to believe we have a pressing
> > > need/requirement to support non-backward compatible changes to ex=
isting
> > > modules in order to support enhancements.
> > I agree.=A0 It was a backwards compatible enhancement that I was co=
nsidering.
> > =

> > Thanks,
> > Rob
> > =

> > =

> > > =

> > > Thanks,
> > > Chris.
> > > =

> > > =

> > > Robert Wilton  writes:
> > > =

> > > > Hi Chris,
> > > > =

> > > > I think that there are two things driving this requirement:
> > > > =

> > > > What I regard as the key one, is that we want to be able to sup=
port
> > > > the software
> > > > that we have shipped. In particular, we may need to fix bugs
> > > > (perhaps at the
> > > > operators request) to a YANG model that has already been releas=
ed.
> > > > I.e. I think
> > > > that there are some scenarios, where forking a YANG module, alt=
hough
> > > > undesirable
> > > > is the right thing to do to include a fix. I don't believe that=

> > > > features or
> > > > deviations help solve this problem.
> > > > The two alternative solutions to being able to fix bugs, neithe=
r of
> > > > which I
> > > > think is pragmatic, that I can think of are:
> > > > (i) Vendors ensure that their YANG modules are perfect before t=
hey
> > > > ship in a
> > > > release.
> > > > (ii) If a bug is reported, operators are happy to wait until th=
e bug
> > > > has been
> > > > fixed in the current development release, and will migrate to t=
hat
> > > > latest
> > > > release to pick up the fix.
> > > > =

> > > > The second thing driving this requirement is that vendors somet=
imes
> > > > get asked
> > > > for enhancements to existing releases, perhaps because the late=
st
> > > > development
> > > > release is too far out, or ask for an enhancement on the curren=
t
> > > > train to be
> > > > back ported to an older release.
> > > > =

> > > > So, aiming to have stable YANG modules, trying a lot harder to =
avoid
> > > > non-backwards-compatible changes, and keeping new functionality=
 to
> > > > the head of
> > > > the development I completely agree with you on. But I still bel=
ieve
> > > > that there
> > > > are some valid scenarios, that should be limited as much as
> > > > possible, where it
> > > > is necessary to make changes that sometimes break these rules, =
and
> > > > having a
> > > > limited scheme that clearly indicates where such breakages have=

> > > > occurred is
> > > > probably better that the status quo of where the modules get
> > > > changed, but the
> > > > operator doesn't get any useful indication of what type of chan=
ges
> > > > are being
> > > > made.
> > > > =

> > > > Thanks,
> > > > Rob
> > > > =

> > > > =

> > > > On 25/10/2018 16:26, Christian Hopps wrote:
> > > > > =

> > > > > > On Oct 20, 2018, at 1:55 PM, Joe Clarke =
 wrote:
> > > > > > =

> > > > > > * New requirement 1.4 for supporting over-arching software =
releases
> > > > > [ I read this as supporting various different module versions=

> > > > > based on a vendor's different software release trains. If thi=
s
> > > > > is wrong then the rest of this doesn't apply and I would just=

> > > > > ask for the text to be update to clarify what it means. ]
> > > > > =

> > > > > How many operators/users have asked for this or indicated it'=
s a
> > > > > requirement for them?
> > > > > =

> > > > > What problem is intractable without this requirement being me=
t,
> > > > > and what is the cost of this requirement on the actual users?=

> > > > > =

> > > > > I have pushed back multiple times on this b/c I believe this
> > > > > "requirement" is really being pushed to make it easier for
> > > > > vendors (a small affected group) to develop their software at=

> > > > > the cost of their users (the much larger affected group) who
> > > > > would then have to deal with multiple trains of the same modu=
le.
> > > > > =

> > > > > =

> > > > > We already have features and deviations why are they not enou=
gh
> > > > > to deal with functionality that is present or not in various
> > > > > software release/devices?
> > > > > =

> > > > > FWIW I'm not against making it easier to develop software, bu=
t
> > > > > we have to be mindful if we are just pushing the cost (and
> > > > > magnifying it greatly) to other people in the community.
> > > > > =

> > > > > Thanks,
> > > > > Chris.
> > > > > =

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

> > > =

> > > .
> > > =

> > =

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

> -- =

> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | German=
y
> Fax:   +49 421 200 3103         
> =

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


From nobody Thu Nov  8 13:42: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 AB5E212DD85 for ; Thu,  8 Nov 2018 13:42:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cy54GmHkT5Gr for ; Thu,  8 Nov 2018 13:42:21 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 49F5112D4E8 for ; Thu,  8 Nov 2018 13:42:21 -0800 (PST)
Received: from localhost (h-255-177.A165.priv.bahnhof.se [176.10.255.177]) by mail.tail-f.com (Postfix) with ESMTPSA id 88E991AE0936; Thu,  8 Nov 2018 22:42:20 +0100 (CET)
Date: Thu, 08 Nov 2018 22:42:20 +0100 (CET)
Message-Id: <20181108.224220.1513800936571555652.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20181027211355.ppu7wavjcq2butc4@anna.jacobs.jacobs-university.de>
References: <20181027083628.tgymddbje3yp2lhy@anna.jacobs.jacobs-university.de>  <20181027211355.ppu7wavjcq2butc4@anna.jacobs.jacobs-university.de>
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] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Nov 2018 21:42:24 -0000

Juergen Schoenwaelder  wrote:
> On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > 
> > This is what we have today only if modules are updated in legal ways.
> > The 3.1 requirement says this backward compatibility is maintained even
> > if the module is updated in violation of the module update rules.
> >
> 
> It is stating a requirement. How solutions meet the requirement is for
> the solutions to figure out.
> 
> > How would 3.1 be met if the WG decided to just add a new 'datastore'
> > key leaf to the /modules-state/module list?
> 
> Depends on the solution I guess.
>  
> > IMO the current "deprecate and start over" is actually the easiest
> > and most robust solution path, and it requires no changes to YANG or
> > the protocols.
> 
> Yep. But there are people who think that other solutions can do
> better. The challenge is to find out whether they actually do better
> or for whom they do better (and if someone has to pay a price for it).
> For having this discussions, it is good to write down requirements.
> 
> > >        3.2  The solution MUST provide a mechanism to allow servers to
> > >             simultaneously support clients using different revisions of
> > >             modules.  A client's choice of particular revision of one or
> > >             more modules may restrict the particular revision of other
> > >             modules that may be used in the same request or session.
> > >
> > > Today, the version number is effectively an (implicit) part of the
> > > module name (plus the revision date for backwards compatible changes).
> > > Hence, my understanding is that today's model does satisfy 3.2 as
> > > well.
> > 
> > This is not what we have at all. RFC 7950 says a server can only implement
> > one revision of a module.
> >
> 
> A new version today essentially means a new module name and I do not
> see a conflict with what I wrote.

Then I think this requirement needs clarification.  It says "different
revision of modules", which can be interpreted as different revisions
of *the same* module.

Also the second part of the paragraph seems to indicate multiple
revisions of the same module in the server.

I do not agree with this requirement.



/martin


> 
> > > If we want to increase 'agility' in an attempt to make it easier to
> > > deliver early designs and to fix them on the go, the costs will go up
> > > somewhere. The extreme cases are:
> > >
> > > 1) The server can make changes to YANG modules in arbitrary ways and
> > >    the clients have to adapt, i.e., clients have to pay the bill.
> > >
> > > 2) The server has to provide strict backwards compatibility in order
> > >    to not break clients, i.e., servers have to pay the bill.
> > >
> > >
> > This is not correct. Implementing multiple incompatible revisions of a
> > module
> > (e.g, "module" list keyed 2 different ways) is a huge bill to pay for the
> > server developer.
> 
> Depends on the details and the developer will decide based on the
> impact on the clients and whether a transition period is possible. You
> seem to read that the requirement says one has to implement backwards
> compatibility. This is not what the text says. The text says it must
> be possible.
> 
> > > Unless we go for option 1) above, I believe 3.1 and 3.2 are valid and
> > > important requirements.
> > 
> > I do not agree with the premise that non-compatible data model updates are
> > required.
> > 3.1 can be achieved without such changes. 3.2 violates RFC 7950, requiring
> > a new(much more complicated) version of YANG
> 
> I think you misread the requirements text.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Thu Nov  8 13:46:37 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B270130DBE; Thu,  8 Nov 2018 13:46:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JGJT0wrz9it; Thu,  8 Nov 2018 13:46:34 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F242D130934; Thu,  8 Nov 2018 13:46:33 -0800 (PST)
Received: from localhost (h-255-177.A165.priv.bahnhof.se [176.10.255.177]) by mail.tail-f.com (Postfix) with ESMTPSA id 3A7761AE0936; Thu,  8 Nov 2018 22:46:33 +0100 (CET)
Date: Thu, 08 Nov 2018 22:46:33 +0100 (CET)
Message-Id: <20181108.224633.1499859196570533612.mbj@tail-f.com>
To: jclarke@cisco.com
Cc: netmod@ietf.org, netmod-ver-dt@ietf.org
From: Martin Bjorklund 
In-Reply-To: <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com>
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com>
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] Fwd: New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Nov 2018 21:46:35 -0000

Hi,

After the session today, it seems to me that one fundamental
requirement (or non-requirement) is missing.  How much branching does
the solution have to support?  The current solution (6020/7950) and (if
I understood Rob Shakir correctly) also openconfig have linear
versioning *per module*.  If we can get agreement on this requirement,
I think it will be easier to find a solution.


/martin


From nobody Thu Nov  8 14:52: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 7B79A123FFD for ; Thu,  8 Nov 2018 14:52:56 -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=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 opu6d3Sosaw2 for ; Thu,  8 Nov 2018 14:52:54 -0800 (PST)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05058128C65 for ; Thu,  8 Nov 2018 14:52:53 -0800 (PST)
Received: by mail-lf1-x12e.google.com with SMTP id f23so10880677lfc.13 for ; Thu, 08 Nov 2018 14:52:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ux0IM/CcxwiVVEajMZWM4Eh941BPcSXnL+maQ+3axwc=; b=EMjnwFtrVNTz7/yBbLxJzOGp20kwAKGqZ4EuN8wG3941qs8Ys2Jm5vWdftdoaGQsP4 9KAzbjrCGsMJyGp2fuEDOFZd5MBtstt6bD3MzfNn0FjgS9Rk5MlJ9dL/8+sy+6dKIgnJ IPhSVFcTrVkXuGd8WfcYH4rincGKVEF369/x5J1ArsfomlgS6cRGNC9dyo+peTyIz3fy TtzoiU8BKqs7im+rJn/sLxXv+dwFc+oX9mna6tCIewGvPI0lFSXD2QTubwPb9aAO/A2J 3XQ4yq3Bj9P+YO2ZEJcCGmy/SAfmA171wcM15OQhHG3sx5czgMStXKKdGdSoRFjxjSL8 WkVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ux0IM/CcxwiVVEajMZWM4Eh941BPcSXnL+maQ+3axwc=; b=D1JR5R4Y9D3begnO+1PCZYIi3q0NQmMtyn4k2xT33bPZkSVlssfBxJ48k0PbfDoEr1 CQjzIO2FE7C/LIviphM/FQrZG7USDBcu5ZxTp+/Pb+EAXBM8+M0O3c8MX0WhHBQqf5iE sQ6H5SxlCAgn+pFBdunn26Mfhv9SjQdYCjmr+BaMvbwWRpY/guNQ42eJpDJWQ0oL0UcB rlHiPIhgHfBXIXcCGQCSP1Qqt6RMwbgnjX9fYkTUsct3iEbT0eGiWTuqpQUjkZH87WRm KervbFi1RsXIQUaaSljeoXtdNN7v/6LSttPtsObrqvK/r/+9I40KRbSIvfav09pJQACF nwVA==
X-Gm-Message-State: AGRZ1gKn+uD/777SgCiZ0mUTonGkApHb+k3ipqz2M0BGK4xkmx6AfL6F prMZuJdzkdk+oJhHQ89WqevaqjM56R+3BESgkBMSL9xG
X-Google-Smtp-Source: AJdET5e1bLRKKqF3Gf32mvkEZ5K4Q2KVjmtsrmp3VIpoYRYFiqJWp+p633t7L3V38G0qq5FLBSA+vpT/qLgYpOB32DU=
X-Received: by 2002:a19:ca51:: with SMTP id h17mr3661523lfj.126.1541717571352;  Thu, 08 Nov 2018 14:52:51 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Thu, 8 Nov 2018 14:52:50 -0800 (PST)
From: Andy Bierman 
Date: Thu, 8 Nov 2018 14:52:50 -0800
Message-ID: 
To: NetMod WG 
Content-Type: multipart/alternative; boundary="0000000000002f5747057a2f18f6"
Archived-At: 
Subject: [netmod] comments on YANG versioning
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 08 Nov 2018 22:52:56 -0000

--0000000000002f5747057a2f18f6
Content-Type: text/plain; charset="UTF-8"

Hi,

A few comments on the netmod meeting yesterday

1) what is a bugfix?
It is not encouraging that the DT cannot agree on the scope of a bugfix.
But not sure it matters if NBC updates can occur for any reason.
IMO it is easy to define a bugfix in the IETF -- it is called an Errata.
If an Errata is approved for a YANG module in an RFC then it is a bugfix.


2) SEMVER to the rescue?
If every module release can be its own feature release train then the value
of
ascending numeric identifiers is greatly diminished. The (m) and (M) tags
do not really help.  I strongly agree with the comment that cherry-picking
new
features can (and should) be done with deviations.  Updates of old
revisions needs to be for bugfixes only.

I prefer the OpenConfig "SEMVER Classic" rather than introducing a new
incompatible complex numbering scheme to support something that
should not be done anyway.

3) Bundles and compatibility modules
I strongly agree this solution approach is far better than treating every
revision
as a separate feature release train.  I don't see how I am going to
track the major.minor.patch for 100 different modules.  SEMVER is not
very useful for telling if module A works with B, C, and D. Import by SEMVER
will probably be OK at first, but become too error-prone after awhile.

4) Automation tools
Ad-hoc WEB pages from IANA do not cut it anymore.
We need a way to get patch versions of modules published and usable
by automation tools (without an RFC) with just the Errata report as a patch.
SEMVER requires that a module be released with the change but this is not
that practical.
Think how yocto works, using a base source version of a package + patches.
(IMO we need YANG Packages, which would serve as recipes
for a set of modules, features, annotations, patches and deviations, that
have been
tested to work together.)

5) YANG 1.2 vs Extensions
IMO a new YANG version would be better than extensions, especially to
fix status-stmt, import-by-revision, deviations, and add annotation,
patch, and many other new mechanisms to help backward compatibility.


Andy

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


Hi,

A few comments on the netmod meetin=
g yesterday

1) what is a bugfix?
It is n=
ot encouraging that the DT cannot agree on the scope of a bugfix.
But not sure it matters if NBC updates can occur for any reason.
IMO it is easy to define a bugfix in the IETF -- it is called an Errata.
If an Errata is approved for a YANG module in an RFC then it is a =
bugfix.


2) SEMVER to the rescue?
If every module release can be its own feature release train then t=
he value of
ascending numeric identifiers is greatly diminished. =
The (m) and (M) tags
do not really help.=C2=A0 I strongly agree w=
ith the comment that cherry-picking new
features can (and should)=
 be done with deviations.=C2=A0 Updates of old
revisions needs to=
 be for bugfixes only.

I prefer the OpenConfig &qu=
ot;SEMVER Classic" rather than introducing a new
incompatibl=
e complex numbering scheme to support something that
should not b=
e done anyway.

3) Bundles and compatibility module=
s
I strongly agree this solution approach is far better than trea=
ting every revision
as a separate feature release train.=C2=A0 I =
don't see how I am going to
track the major.minor.patch for 1=
00 different modules.=C2=A0 SEMVER is not
very useful for telling=
 if module A works with B, C, and D. Import by SEMVER
will probab=
ly be OK at first, but become too error-prone after awhile.

<=
/div>
4) Automation tools
Ad-hoc WEB pages from IANA do not c=
ut it anymore.
We need a way to get patch versions of modules pub=
lished and usable
by automation tools (without an RFC) with just =
the Errata report as a patch.
SEMVER requires that a module be re=
leased with the change but this is not that practical.
Think how =
yocto works, using a base source version of a package + patches.
=
(IMO we need YANG Packages, which would serve as recipes
for a se=
t of modules, features, annotations, patches and deviations, that have been=

tested to work together.)

5) YANG 1.2 v=
s Extensions
IMO a new YANG version would be better than extensio=
ns, especially to
fix status-stmt, import-by-revision, deviations=
, and add annotation,
patch, and many other new mechanisms to hel=
p backward compatibility.


Andy



--0000000000002f5747057a2f18f6--


From nobody Thu Nov  8 18:08:05 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97D4128D0C; Thu,  8 Nov 2018 18:07:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.971
X-Spam-Level: 
X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 2CZ7V-OuHehm; Thu,  8 Nov 2018 18:07:56 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32DCE1288BD; Thu,  8 Nov 2018 18:07:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=881; q=dns/txt; s=iport; t=1541729276; x=1542938876; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=P/IzHt9J7c8W1UGyqj2cE5Uu9fUKqHXm2N2YxmMSFmc=; b=PJqHxz3pbv/lQSjqjB0dfjGDqiEzJ783aJMAqJ34NLvs+CAEYdRH27QO vkIXNShQZRbufGIj8ECCbyxxnwQe3DaoWUgWTVnJrYGI75mflF96GeVms 7M8a1sKVgrOuei35/QXKssIgEgTTIJZarkc7Dx+IKJhxTwNjri/JAmsPm I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAAAk6+Rb/5tdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBggNpTDOEH5QTgWAtmSwNhGwCgxgiNwo?= =?us-ascii?q?NAQMBAQIBAQJtKIU7AQIDI1QCEAsOCgICJgICVwYNCAEBF4MGggKoJIEuiii?= =?us-ascii?q?BC4puF4FBP4E4gmuIAoJXAok9hggzj1AJkRAGGIlUhxiXcIFZIoFVTSMVgyi?= =?us-ascii?q?CT44oIQOOAAEB?=
X-IronPort-AV: E=Sophos;i="5.54,481,1534809600"; d="scan'208";a="260863984"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2018 02:07:55 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro4.cisco.com [10.118.87.85]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id wA927qNY024790; Fri, 9 Nov 2018 02:07:53 GMT
To: Martin Bjorklund 
Cc: netmod@ietf.org, netmod-ver-dt@ietf.org
References: <154005782323.13611.776830839788125372.idtracker@ietfa.amsl.com> <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <20181108.224633.1499859196570533612.mbj@tail-f.com>
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDo1cJ0RBADSZSmbmzdRr1CoRWWKmAyu0eaQimaLV1TsZEML/ksLyg6faXrKIA/MWc7M w4FmKkDjaZdFzobzabnKp2QwVadLqi1gYY2WsApKC0rSoqsPx5E847AmwNWXgjXiXORXmnZL mf5PZ2ECOEJC27sji5Nrh9GSw7OPp6c+EE20gMNVrwCgu3iK5vyGQfy0/wX/jcIvP0nHznUD /RvijiKomyaf6F5pibmouFNeuCDHc8lwx2giA/MCZl/nSkI2/UX27sULGNgvKNkVPu/AukXu zW3fIthsJgjQZUoi/BTe9kUP+RL3+RALXXuLv7b3xGRHJ8A1Rpy9H43fkjHZ945YNPrUvJlG LP5PNGBD1xC21X3EGAyywVynDskcA/4qgbJFkVzmPjFJUjq+RW1zw3UIb3bbkskl/wk5qd+M w2EhiSPTbEhJQAQUvqSGFWEGp2ANic7iYLdPXV/O6I1/guRRaY0eK77YkkCjz1snaKYnGSeI GHGwmHb6D+ZHzTqZqr6IssgEIUHjXfgOUTARQbL15nJTVRzDGUiT/65R3c0eSm9lIENsYXJr ZSA8amNsYXJrZUBjaXNjby5jb20+wl8EExECABcFAjyDqGQFCwcKAwQDFQMCAxYCAQIXgAAS CRDN7TXCWm4C3wdlR1BHAAEB5KkAn0kBda/9+uF6RfnDSFS7RExUU9DqAJ4knRckYiSASteC K03QVtEiXblL287ATQQ6NXCeEAQAhIURlK17jmIMdMIuScFU6xK+jkKgVVFrjlRH5vLV2spp jH/uQ57MMGuOcs7PckXCnPjBV8Tm32Tuw+fCyrbc2gt0ouiT/5WWj0EMeAfWew1zBXX2okGf LqS6gucVDS6tcEFN6PmJEmX+tWDcmiqx/xXiSfMVYiLMdlK+YDkMDDsAAwUD/3BWOyfdnBGH Kv28zx+5wq/2vhYnUYCAdVD2ZWCJizQTMbkcxEIKAwtAj6yqKq9ah82nt4VHl5ZejVe47jvR 2nXwJ5VQ9eITuTjTLDw+3qr9lN077VZ32hyb5ULJcW756j9Z3YB2FTANw6KHgChaSVVx9kYJ FlAggraU7mi39/wvwk4EGBECAAYFAjo1cJ4AEgkQze01wlpuAt8HZUdQRwABAQbdAJ9R8SzU Mluu9r93BMv6fAW9j6qTZgCfYcEAqOMJv+3Z+YxLiDtWcCY4Sfo=
Organization: Cisco
Message-ID: 
Date: Thu, 8 Nov 2018 21:07:52 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <20181108.224633.1499859196570533612.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.118.87.85, rtp-jclarke-nitro4.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] Fwd: New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2018 02:07:58 -0000

On 11/8/18 16:46, Martin Bjorklund wrote:
> Hi,
> 
> After the session today, it seems to me that one fundamental
> requirement (or non-requirement) is missing.  How much branching does
> the solution have to support?  The current solution (6020/7950) and (if
> I understood Rob Shakir correctly) also openconfig have linear
> versioning *per module*.  If we can get agreement on this requirement,
> I think it will be easier to find a solution.

We discussed this in the DT.  We didn't want to discuss levels of
branching in the requirements as that pointed to certain solutions.  The
point of requirement 1.4 was to say that the DT felt previous versions
of modules needed to support fixes without bringing in elements from head.

We discussed branching to satisfy this requirement as well as protecting
new features with if-feature and using deviations.

Joe


From nobody Thu Nov  8 18:37: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 227B7128D0C for ; Thu,  8 Nov 2018 18:37:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5q-Cn41Z0IZ for ; Thu,  8 Nov 2018 18:37:43 -0800 (PST)
Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 A61341288BD for ; Thu,  8 Nov 2018 18:37:43 -0800 (PST)
Received: by mail-it1-x143.google.com with SMTP id j79-v6so1212002itb.2 for ; Thu, 08 Nov 2018 18:37:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=references:mime-version:in-reply-to:content-transfer-encoding :message-id:cc:from:subject:date:to; bh=Yf34feX2ZIDM9qq/Khpx808F7OKr8WUr7mXlqV31Ak8=; b=CdTOI0NkCJ3Cy+6kIxv9TI1cWm385WecZDmM/DHRFTjbm04xdnu447PprsUMUM4Q56 fVaNXj37km2RziyO26tVgNqn5tnCMr+wQlfu9o/WBQqXZAnVCgEqOj6w/73zSV0J4FVx IVYOTdRZc6SmurVZVye1zii18FZ/6j+cIlQ8SIhD2MeM9K84F3ZtKx+yEtR7W/ZpKH0U +rfUP70BFiUlgL5b7PU94gVNRK0Iv+F1hwKvi2iVTWxzNpvu4bCqikvgOfmQtGpuv7ba PPZBzmz+blfrRqfBG16sxg/S5I3n9np156GxoHiOu8B8oUuZpylVfUHFb6L0ZTko8f23 taeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:mime-version:in-reply-to :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=Yf34feX2ZIDM9qq/Khpx808F7OKr8WUr7mXlqV31Ak8=; b=lQ1lHVEfH1UFvyLPs/ZJPT6S1b2fRRLsXdBptpIxttvGxhnXA/UXx52TcHVM/Erzkl bdZs870C0ERqkLnABRMRK0L3qE3dj+1gIIrL3+HpWmo6qSPekWI64DASzbhBu+xkN8TD zLtKg+JHkKzynsKqwTfCqgc7SDBPtDZZWiH4lTBP2PwxwQWCvnTi7w/aai9a3QOR+DdC 9L3hh505aUthdek2dZOPHPuueWgtZRgPOVu4MlqeihQRrBb1huXw5/UM4VWYdEkDJfk5 BqVWssZDLU5XO8u9cpnVJUYdWuURA1YL+cmqYamdAfhmxwECyIpq9exI2G+cH5CTca72 fodA==
X-Gm-Message-State: AGRZ1gLBdDnRG8JGzF3Beu7yBaPN0/GNTQS0vyl7lV4/Vo/rxR/HlUI1 mcD0ndQuSJttoEp06p5AONVSqjC60KE=
X-Google-Smtp-Source: AJdET5eTBpsqBMJUS0x1ANUipOIpmhUUtYArendjvEmxFobpdmTvywzsYgQTmAwVsBDzbstBz5z70g==
X-Received: by 2002:a02:39b:: with SMTP id e27-v6mr6492546jae.3.1541731062596;  Thu, 08 Nov 2018 18:37:42 -0800 (PST)
Received: from [172.20.10.2] ([172.56.12.126]) by smtp.gmail.com with ESMTPSA id u132-v6sm107166itb.21.2018.11.08.18.37.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 08 Nov 2018 18:37:42 -0800 (PST)
References: 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Cc: NetMod WG 
X-Mailer: iPad Mail (13G36)
From: Mahesh Jethanandani 
Date: Fri, 9 Nov 2018 09:37:35 +0700
To: Andy Bierman 
Archived-At: 
Subject: Re: [netmod] comments on YANG versioning
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2018 02:37:46 -0000

I am wondering if we are looking at two sets of rules for the versioning sys=
tem we come up with. One that vendors do with their "native" models to satis=
fy their customers, and the other what standard bodies follow for the models=
 published by them.

For example, vendors can make feature and NBC fixes to models in releases th=
at are not the latest, while standard bodies like IETF make changes in model=
s that are always the latest, even as they use the same versioning system. A=
gain, vendors use all the three numbers, but standard bodies use the first (=
major) and the last (patch) number.

Mahesh Jethanandani
mjethanandani@gmail.com

> On Nov 9, 2018, at 5:52 AM, Andy Bierman  wrote:
>=20
> Hi,
>=20
> A few comments on the netmod meeting yesterday
>=20
> 1) what is a bugfix?
> It is not encouraging that the DT cannot agree on the scope of a bugfix.
> But not sure it matters if NBC updates can occur for any reason.
> IMO it is easy to define a bugfix in the IETF -- it is called an Errata.
> If an Errata is approved for a YANG module in an RFC then it is a bugfix.
>=20
>=20
> 2) SEMVER to the rescue?
> If every module release can be its own feature release train then the valu=
e of
> ascending numeric identifiers is greatly diminished. The (m) and (M) tags
> do not really help.  I strongly agree with the comment that cherry-picking=
 new
> features can (and should) be done with deviations.  Updates of old
> revisions needs to be for bugfixes only.
>=20
> I prefer the OpenConfig "SEMVER Classic" rather than introducing a new
> incompatible complex numbering scheme to support something that
> should not be done anyway.
>=20
> 3) Bundles and compatibility modules
> I strongly agree this solution approach is far better than treating every r=
evision
> as a separate feature release train.  I don't see how I am going to
> track the major.minor.patch for 100 different modules.  SEMVER is not
> very useful for telling if module A works with B, C, and D. Import by SEMV=
ER
> will probably be OK at first, but become too error-prone after awhile.
>=20
> 4) Automation tools
> Ad-hoc WEB pages from IANA do not cut it anymore.
> We need a way to get patch versions of modules published and usable
> by automation tools (without an RFC) with just the Errata report as a patc=
h.
> SEMVER requires that a module be released with the change but this is not t=
hat practical.
> Think how yocto works, using a base source version of a package + patches.=

> (IMO we need YANG Packages, which would serve as recipes
> for a set of modules, features, annotations, patches and deviations, that h=
ave been
> tested to work together.)
>=20
> 5) YANG 1.2 vs Extensions
> IMO a new YANG version would be better than extensions, especially to
> fix status-stmt, import-by-revision, deviations, and add annotation,
> patch, and many other new mechanisms to help backward compatibility.
>=20
>=20
> Andy
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Nov  8 19:46: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 26654130EB7 for ; Thu,  8 Nov 2018 19:46:56 -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 FeD3UKY5el_0 for ; Thu,  8 Nov 2018 19:46:54 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02B6B130EF1 for ; Thu,  8 Nov 2018 19:46:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3550; q=dns/txt; s=iport; t=1541735214; x=1542944814; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ExUnrbeaMU+/ZYdfx7r1jUNl6025flvXShCzMfdWS6w=; b=QlKflV+Ngt5Fwdkh9ZljxQISvl8TL2A3ur4+5/CANnNG1mw6++ly5GhU LvoOQc8mIcm9bICD4LxQS43g/Ygo4VsHpEPHtHJc+MBOFoSbRfaSIZ795 21ETBv7sa828dGtXCO8I8NgfNNyk86f8xgXzTyDTgtCZ3hVH7SBCPKi5h Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CzAAC0AuVb/5RdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYIEZgNMMyeDeJQTgWAIJYkEkCgNGAuEA0YCgxgiOBY?= =?us-ascii?q?BAwEBAgEBAm0cDIU6AQEBAQIBAQEhSwsQCw4KAgImAgIhBjAGAQwGAgEBF4M?= =?us-ascii?q?GAYFpAw0ID6gWgS6IAg2CFAWBC4puF4FBP4ERJwyCX4JWRQEBhGWCVwKPRTO?= =?us-ascii?q?OeycuCY1rgyUGGIlUhxiOJIlMgVohgVVNIxU7gmyLHIVcIQMwjVABAQ?=
X-IronPort-AV: E=Sophos;i="5.54,481,1534809600"; d="scan'208";a="198132814"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2018 03:46:52 +0000
Received: from [192.168.10.113] (rtp-jclarke-nitro4.cisco.com [10.118.87.85]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTP id wA93kmmj031773; Fri, 9 Nov 2018 03:46:50 GMT
To: Mahesh Jethanandani , Andy Bierman 
Cc: NetMod WG 
References:  
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDo1cJ0RBADSZSmbmzdRr1CoRWWKmAyu0eaQimaLV1TsZEML/ksLyg6faXrKIA/MWc7M w4FmKkDjaZdFzobzabnKp2QwVadLqi1gYY2WsApKC0rSoqsPx5E847AmwNWXgjXiXORXmnZL mf5PZ2ECOEJC27sji5Nrh9GSw7OPp6c+EE20gMNVrwCgu3iK5vyGQfy0/wX/jcIvP0nHznUD /RvijiKomyaf6F5pibmouFNeuCDHc8lwx2giA/MCZl/nSkI2/UX27sULGNgvKNkVPu/AukXu zW3fIthsJgjQZUoi/BTe9kUP+RL3+RALXXuLv7b3xGRHJ8A1Rpy9H43fkjHZ945YNPrUvJlG LP5PNGBD1xC21X3EGAyywVynDskcA/4qgbJFkVzmPjFJUjq+RW1zw3UIb3bbkskl/wk5qd+M w2EhiSPTbEhJQAQUvqSGFWEGp2ANic7iYLdPXV/O6I1/guRRaY0eK77YkkCjz1snaKYnGSeI GHGwmHb6D+ZHzTqZqr6IssgEIUHjXfgOUTARQbL15nJTVRzDGUiT/65R3c0eSm9lIENsYXJr ZSA8amNsYXJrZUBjaXNjby5jb20+wl8EExECABcFAjyDqGQFCwcKAwQDFQMCAxYCAQIXgAAS CRDN7TXCWm4C3wdlR1BHAAEB5KkAn0kBda/9+uF6RfnDSFS7RExUU9DqAJ4knRckYiSASteC K03QVtEiXblL287ATQQ6NXCeEAQAhIURlK17jmIMdMIuScFU6xK+jkKgVVFrjlRH5vLV2spp jH/uQ57MMGuOcs7PckXCnPjBV8Tm32Tuw+fCyrbc2gt0ouiT/5WWj0EMeAfWew1zBXX2okGf LqS6gucVDS6tcEFN6PmJEmX+tWDcmiqx/xXiSfMVYiLMdlK+YDkMDDsAAwUD/3BWOyfdnBGH Kv28zx+5wq/2vhYnUYCAdVD2ZWCJizQTMbkcxEIKAwtAj6yqKq9ah82nt4VHl5ZejVe47jvR 2nXwJ5VQ9eITuTjTLDw+3qr9lN077VZ32hyb5ULJcW756j9Z3YB2FTANw6KHgChaSVVx9kYJ FlAggraU7mi39/wvwk4EGBECAAYFAjo1cJ4AEgkQze01wlpuAt8HZUdQRwABAQbdAJ9R8SzU Mluu9r93BMv6fAW9j6qTZgCfYcEAqOMJv+3Z+YxLiDtWcCY4Sfo=
Organization: Cisco
Message-ID: <18c119c0-b90b-ed49-0671-df5b6b2a7066@cisco.com>
Date: Thu, 8 Nov 2018 22:46:47 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.118.87.85, rtp-jclarke-nitro4.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: 
Subject: Re: [netmod] comments on YANG versioning
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2018 03:46:57 -0000

On 11/8/18 21:37, Mahesh Jethanandani wrote:
> I am wondering if we are looking at two sets of rules for the versioning system we come up with. One that vendors do with their "native" models to satisfy their customers, and the other what standard bodies follow for the models published by them.
> 
> For example, vendors can make feature and NBC fixes to models in releases that are not the latest, while standard bodies like IETF make changes in models that are always the latest, even as they use the same versioning system. Again, vendors use all the three numbers, but standard bodies use the first (major) and the last (patch) number.

That's what we initially discussed on the DT call.  It was then raised
that there may be standards bodies (even groups in the IETF) that would
want to fork a model and make changes to both branches.

Joe

> 
> Mahesh Jethanandani
> mjethanandani@gmail.com
> 
>> On Nov 9, 2018, at 5:52 AM, Andy Bierman  wrote:
>>
>> Hi,
>>
>> A few comments on the netmod meeting yesterday
>>
>> 1) what is a bugfix?
>> It is not encouraging that the DT cannot agree on the scope of a bugfix.
>> But not sure it matters if NBC updates can occur for any reason.
>> IMO it is easy to define a bugfix in the IETF -- it is called an Errata.
>> If an Errata is approved for a YANG module in an RFC then it is a bugfix.
>>
>>
>> 2) SEMVER to the rescue?
>> If every module release can be its own feature release train then the value of
>> ascending numeric identifiers is greatly diminished. The (m) and (M) tags
>> do not really help.  I strongly agree with the comment that cherry-picking new
>> features can (and should) be done with deviations.  Updates of old
>> revisions needs to be for bugfixes only.
>>
>> I prefer the OpenConfig "SEMVER Classic" rather than introducing a new
>> incompatible complex numbering scheme to support something that
>> should not be done anyway.
>>
>> 3) Bundles and compatibility modules
>> I strongly agree this solution approach is far better than treating every revision
>> as a separate feature release train.  I don't see how I am going to
>> track the major.minor.patch for 100 different modules.  SEMVER is not
>> very useful for telling if module A works with B, C, and D. Import by SEMVER
>> will probably be OK at first, but become too error-prone after awhile.
>>
>> 4) Automation tools
>> Ad-hoc WEB pages from IANA do not cut it anymore.
>> We need a way to get patch versions of modules published and usable
>> by automation tools (without an RFC) with just the Errata report as a patch.
>> SEMVER requires that a module be released with the change but this is not that practical.
>> Think how yocto works, using a base source version of a package + patches.
>> (IMO we need YANG Packages, which would serve as recipes
>> for a set of modules, features, annotations, patches and deviations, that have been
>> tested to work together.)
>>
>> 5) YANG 1.2 vs Extensions
>> IMO a new YANG version would be better than extensions, especially to
>> fix status-stmt, import-by-revision, deviations, and add annotation,
>> patch, and many other new mechanisms to help backward compatibility.
>>
>>
>> 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 Fri Nov  9 00:16: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 A1C32130DBE for ; Fri,  9 Nov 2018 00:16:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Kti4sq7l6wau for ; Fri,  9 Nov 2018 00:16:02 -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 8D450124D68 for ; Fri,  9 Nov 2018 00:16:01 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A300AEDB; Fri,  9 Nov 2018 09:15: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 dJJiHYjlTScA; Fri,  9 Nov 2018 09:15: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; Fri,  9 Nov 2018 09:15:59 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C83C2003C; Fri,  9 Nov 2018 09:15:59 +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 0zHfSUGnqV7m; Fri,  9 Nov 2018 09:15:58 +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 C13112003D; Fri,  9 Nov 2018 09:15: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; Fri, 9 Nov 2018 09:15:58 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 04FBC3003CA1E5; Fri,  9 Nov 2018 09:15:57 +0100 (CET)
Date: Fri, 9 Nov 2018 09:15:57 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
CC: , 
Message-ID: <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org
References: <20181027083628.tgymddbje3yp2lhy@anna.jacobs.jacobs-university.de>  <20181027211355.ppu7wavjcq2butc4@anna.jacobs.jacobs-university.de> <20181108.224220.1513800936571555652.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20181108.224220.1513800936571555652.mbj@tail-f.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2018 08:16:06 -0000

On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > > 
> > > This is what we have today only if modules are updated in legal ways.
> > > The 3.1 requirement says this backward compatibility is maintained even
> > > if the module is updated in violation of the module update rules.
> > >
> > 
> > It is stating a requirement. How solutions meet the requirement is for
> > the solutions to figure out.
> > 
> > > How would 3.1 be met if the WG decided to just add a new 'datastore'
> > > key leaf to the /modules-state/module list?
> > 
> > Depends on the solution I guess.
> >  
> > > IMO the current "deprecate and start over" is actually the easiest
> > > and most robust solution path, and it requires no changes to YANG or
> > > the protocols.
> > 
> > Yep. But there are people who think that other solutions can do
> > better. The challenge is to find out whether they actually do better
> > or for whom they do better (and if someone has to pay a price for it).
> > For having this discussions, it is good to write down requirements.
> > 
> > > >        3.2  The solution MUST provide a mechanism to allow servers to
> > > >             simultaneously support clients using different revisions of
> > > >             modules.  A client's choice of particular revision of one or
> > > >             more modules may restrict the particular revision of other
> > > >             modules that may be used in the same request or session.
> > > >
> > > > Today, the version number is effectively an (implicit) part of the
> > > > module name (plus the revision date for backwards compatible changes).
> > > > Hence, my understanding is that today's model does satisfy 3.2 as
> > > > well.
> > > 
> > > This is not what we have at all. RFC 7950 says a server can only implement
> > > one revision of a module.
> > >
> > 
> > A new version today essentially means a new module name and I do not
> > see a conflict with what I wrote.
> 
> Then I think this requirement needs clarification.  It says "different
> revision of modules", which can be interpreted as different revisions
> of *the same* module.
> 
> Also the second part of the paragraph seems to indicate multiple
> revisions of the same module in the server.
> 
> I do not agree with this requirement.

Today, you need to create a new module if you make NBC changes to
existing changes (e.g., you change Bool to Int {0..1} and you are not
creating a new leaf). Since there are now two modules, you _can_
implement both modules if that makes sense.

If we allow to make such changes as part of a module revision, i.e.,
without creating a new module, I think we should not loose the ability
to implement both the old version and the new version.

I think we need to distinguish between the agreement on the
requirement, namely that a server should be able to provide support
for an old and a new definition, and agreement on the solution.

Do you disagree with the requirement? Or do you disagree with the
consequences of implementing multiple versions of the same module
for some of the proposed new versioning schemes? Or both?

/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 Nov  9 03:38:14 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3E7130DEB for ; Fri,  9 Nov 2018 03:38:11 -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=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 IWNOEep_yr2p for ; Fri,  9 Nov 2018 03:38:07 -0800 (PST)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BEDB130DDA for ; Fri,  9 Nov 2018 03:38:07 -0800 (PST)
Received: by mail-lj1-x235.google.com with SMTP id f3-v6so1296395ljk.9 for ; Fri, 09 Nov 2018 03:38:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=KAto7xOLUsrxqC2WWuwMw0xRqmMXYn4ss1E9RiAYyQc=; b=X1Qs1MwWmAPfJnRjwkiFH/X+W2ZriB3BTu8F4yIG5xLo446GtGYKGO1LgtuW3CjHM5 CVhN25OD2QAFiZ6vvgjZRTOrX0Izv+Io54PER1d/qCifox0ND1qIwwhiFsJ50HrBlL3T rBu9bRsaG8qwUlUoF/nR9wVnB7JJcQXlLjZ9Qgzgkf5c9ZIsOmwx/4FyYlZewcP8+A/1 N8ZjvNpgeR3SC8xPaLvLWnSdEEhdY0eCw1vowY0p0b6FbV2t2ViH/N5uzt+LO+nsQnc6 KlEHJGXEXscPKVXeI9oRFK1qpfqmhpvuWw1ppI9Y4h0VNcjD5bJ113OKzTfkrzKWezLY a+cQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=KAto7xOLUsrxqC2WWuwMw0xRqmMXYn4ss1E9RiAYyQc=; b=VzuNggdwq9LOYneRODydS5cYvtLwS2qWIag5lWiMcacgJ4E2rCSZ/GJmon43x7lSGC WmpNTAdUpf57CYy+h/evm4nohSq/JUmvNI1s4/laceJBUu/W7rSnPq6uo5ZphSTauh1F jIb868yGVEnPmOtRRyoASRLXds8Rz33z5mjVZV/BZfxaSLmkKhtb9xCcTYs6Bpkr829W 2D+14c8bcM3eUiw50Q5ddWadGymMgnrptD73WVdhFnW2Uxvwxg2BX4qheLDGPo2midVN nnsrVzHfYffdfiEnjqY6ennBM4pngGC8W98XLcBCSOp2P16mv3RuscET61EIxCv6pujt qnPw==
X-Gm-Message-State: AGRZ1gLQmMu4nRPkCWMiKceK7qrV8HWK4xJ0EJa2ORCNi1QqfqJrkCHI mTYT6bqpMfVEF9KdoiwNOhOWoR40FSroFQEEFDEcBI7n
X-Google-Smtp-Source: AJdET5cOmx06iL92BtPOzultGNeCdgxltI18zA3gEQmYpALPlcSYjg0Y2/c6vkJx3JhPZmETurHR373s2RjsZNFBozM=
X-Received: by 2002:a2e:e02:: with SMTP id 2-v6mr4671565ljo.10.1541763485316;  Fri, 09 Nov 2018 03:38:05 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Fri, 9 Nov 2018 03:38:03 -0800 (PST)
In-Reply-To: <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de>
References: <20181027083628.tgymddbje3yp2lhy@anna.jacobs.jacobs-university.de>  <20181027211355.ppu7wavjcq2butc4@anna.jacobs.jacobs-university.de> <20181108.224220.1513800936571555652.mbj@tail-f.com> <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de>
From: Andy Bierman 
Date: Fri, 9 Nov 2018 03:38:03 -0800
Message-ID: 
To: Juergen Schoenwaelder , Martin Bjorklund ,  Andy Bierman , NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000dee7fb057a39c8b4"
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2018 11:38:12 -0000

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

On Fri, Nov 9, 2018 at 12:15 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > > >
> > > > This is what we have today only if modules are updated in legal ways.
> > > > The 3.1 requirement says this backward compatibility is maintained
> even
> > > > if the module is updated in violation of the module update rules.
> > > >
> > >
> > > It is stating a requirement. How solutions meet the requirement is for
> > > the solutions to figure out.
> > >
> > > > How would 3.1 be met if the WG decided to just add a new 'datastore'
> > > > key leaf to the /modules-state/module list?
> > >
> > > Depends on the solution I guess.
> > >
> > > > IMO the current "deprecate and start over" is actually the easiest
> > > > and most robust solution path, and it requires no changes to YANG or
> > > > the protocols.
> > >
> > > Yep. But there are people who think that other solutions can do
> > > better. The challenge is to find out whether they actually do better
> > > or for whom they do better (and if someone has to pay a price for it).
> > > For having this discussions, it is good to write down requirements.
> > >
> > > > >        3.2  The solution MUST provide a mechanism to allow servers
> to
> > > > >             simultaneously support clients using different
> revisions of
> > > > >             modules.  A client's choice of particular revision of
> one or
> > > > >             more modules may restrict the particular revision of
> other
> > > > >             modules that may be used in the same request or
> session.
> > > > >
> > > > > Today, the version number is effectively an (implicit) part of the
> > > > > module name (plus the revision date for backwards compatible
> changes).
> > > > > Hence, my understanding is that today's model does satisfy 3.2 as
> > > > > well.
> > > >
> > > > This is not what we have at all. RFC 7950 says a server can only
> implement
> > > > one revision of a module.
> > > >
> > >
> > > A new version today essentially means a new module name and I do not
> > > see a conflict with what I wrote.
> >
> > Then I think this requirement needs clarification.  It says "different
> > revision of modules", which can be interpreted as different revisions
> > of *the same* module.
> >
> > Also the second part of the paragraph seems to indicate multiple
> > revisions of the same module in the server.
> >
> > I do not agree with this requirement.
>
> Today, you need to create a new module if you make NBC changes to
> existing changes (e.g., you change Bool to Int {0..1} and you are not
> creating a new leaf). Since there are now two modules, you _can_
> implement both modules if that makes sense.
>
>

This does not make sense because a node in YANG is identified by a QName,
not just a local-name.   The node oldmod:foo is not the same as newmod:foo.
It never has been and never will be the same node.



> If we allow to make such changes as part of a module revision, i.e.,
> without creating a new module, I think we should not loose the ability
> to implement both the old version and the new version.
>
>
As Balazs asked, how can the data node be a boolean and an integer at the
same time?
There seem to be plenty of scenarios that cannot be implemented
simultaneously by a server.



> I think we need to distinguish between the agreement on the
> requirement, namely that a server should be able to provide support
> for an old and a new definition, and agreement on the solution.
>
> Do you disagree with the requirement? Or do you disagree with the
> consequences of implementing multiple versions of the same module
> for some of the proposed new versioning schemes? Or both?
>


I understand the transformation approach (am have implemented something
like it).
This only works if the mapping is complete.  If there are any holes in the
mapping
then the affected nodes are lost.  Vendors have already proven they
can implement this approach without any new standards.

Vendors are already releasing updates to old module revisions by managing
the revision date.
I agree SEMVER is incrementally better than that.

I do not agree that more than 1 revision of a module can be implemented.
A server can have multiple "outside" schema that gets transformed to the
real "inside" schema.
This is fine and breaks no YANG rules.  It also requires no additional
standards unless the
transformation mechanism is going to be standardized.



> /js
>


Andy


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

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




On Fri, Nov 9, 2018 at 12:15 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjo=
rklund wrote:

> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

> > On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:

> > > 

> > > This is what we have today only if modules are updated in le=
gal ways.

> > > The 3.1 requirement says this backward compatibility is main=
tained even

> > > if the module is updated in violation of the module update r=
ules.

> > >

> > 

> > It is stating a requirement. How solutions meet the requirement i=
s for

> > the solutions to figure out.

> > 

> > > How would 3.1 be met if the WG decided to just add a new =
9;datastore'

> > > key leaf to the /modules-state/module list?

> > 

> > Depends on the solution I guess.

> >=C2=A0 

> > > IMO the current "deprecate and start over" is actu=
ally the easiest

> > > and most robust solution path, and it requires no changes to=
 YANG or

> > > the protocols.

> > 

> > Yep. But there are people who think that other solutions can do
> > better. The challenge is to find out whether they actually do bet=
ter

> > or for whom they do better (and if someone has to pay a price for=
 it).

> > For having this discussions, it is good to write down requirement=
s.

> > 

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.2=C2=A0 The solution MUST =
provide a mechanism to allow servers to

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0simultan=
eously support clients using different revisions of

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0modules.=
=C2=A0 A client's choice of particular revision of one or

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more mod=
ules may restrict the particular revision of other

> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0modules =
that may be used in the same request or session.

> > > >

> > > > Today, the version number is effectively an (implicit) =
part of the

> > > > module name (plus the revision date for backwards compa=
tible changes).

> > > > Hence, my understanding is that today's model does =
satisfy 3.2 as

> > > > well.

> > > 

> > > This is not what we have at all. RFC 7950 says a server can =
only implement

> > > one revision of a module.

> > >

> > 

> > A new version today essentially means a new module name and I do =
not

> > see a conflict with what I wrote.

> 

> Then I think this requirement needs clarification.=C2=A0 It says "=
;different

> revision of modules", which can be interpreted as different revis=
ions

> of *the same* module.

> 

> Also the second part of the paragraph seems to indicate multiple

> revisions of the same module in the server.

> 

> I do not agree with this requirement.



Today, you need to create a new module if you make NBC changes to

existing changes (e.g., you change Bool to Int {0..1} and you are not

creating a new leaf). Since there are now two modules, you _can_

implement both modules if that makes sense.




This does not make sens=
e because a node in YANG is identified by a QName,
not just a loc=
al-name. =C2=A0 The node oldmod:foo is not the same as newmod:foo.
It never has been and never will be the same node.

=C2=A0

If we allow to make such changes as part of a module revision, i.e.,

without creating a new module, I think we should not loose the ability

to implement both the old version and the new version.



As Balazs asked, how can the data node=
 be a boolean and an integer at the same time?
There seem to be p=
lenty of scenarios that cannot be implemented simultaneously by a server.

=C2=A0

I think we need to distinguish between the agreement on the

requirement, namely that a server should be able to provide support

for an old and a new definition, and agreement on the solution.



Do you disagree with the requirement? Or do you disagree with the

consequences of implementing multiple versions of the same module

for some of the proposed new versioning schemes? Or both?
<=
div>

I understand the transformation approach =
(am have implemented something like it).
This only works if the m=
apping is complete.=C2=A0 If there are any holes in the mapping
t=
hen the affected nodes are lost.=C2=A0 Vendors have already proven they
can implement this approach without any new standards.
Vendors are already releasing updates to old module revisions b=
y managing the revision date.
I agree SEMVER is incrementally bet=
ter than that.

I do not agree that more than 1 rev=
ision of a module can be implemented.
A server can have multiple =
"outside" schema that gets transformed to the real "inside&q=
uot; schema.
This is fine and breaks no YANG rules.=C2=A0 It also=
 requires no additional standards unless the
transformation mecha=
nism is going to be standardized.





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





--000000000000dee7fb057a39c8b4--


From nobody Fri Nov  9 05:37:37 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B513129AB8 for ; Fri,  9 Nov 2018 05:37:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwfFjtLAUxXV for ; Fri,  9 Nov 2018 05:37:34 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 15A4912777C for ; Fri,  9 Nov 2018 05:37:33 -0800 (PST)
Received: from localhost (h-40-120.A165.priv.bahnhof.se [94.254.40.120]) by mail.tail-f.com (Postfix) with ESMTPSA id 0A06A1AE0493; Fri,  9 Nov 2018 14:37:30 +0100 (CET)
Date: Fri, 09 Nov 2018 14:37:29 +0100 (CET)
Message-Id: <20181109.143729.1869485019013831956.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de>
References: <20181027211355.ppu7wavjcq2butc4@anna.jacobs.jacobs-university.de> <20181108.224220.1513800936571555652.mbj@tail-f.com> <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de>
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] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2018 13:37:36 -0000

Juergen Schoenwaelder  wrote:
> On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > > > 
> > > > This is what we have today only if modules are updated in legal ways.
> > > > The 3.1 requirement says this backward compatibility is maintained even
> > > > if the module is updated in violation of the module update rules.
> > > >
> > > 
> > > It is stating a requirement. How solutions meet the requirement is for
> > > the solutions to figure out.
> > > 
> > > > How would 3.1 be met if the WG decided to just add a new 'datastore'
> > > > key leaf to the /modules-state/module list?
> > > 
> > > Depends on the solution I guess.
> > >  
> > > > IMO the current "deprecate and start over" is actually the easiest
> > > > and most robust solution path, and it requires no changes to YANG or
> > > > the protocols.
> > > 
> > > Yep. But there are people who think that other solutions can do
> > > better. The challenge is to find out whether they actually do better
> > > or for whom they do better (and if someone has to pay a price for it).
> > > For having this discussions, it is good to write down requirements.
> > > 
> > > > >        3.2  The solution MUST provide a mechanism to allow servers to
> > > > >             simultaneously support clients using different revisions of
> > > > >             modules.  A client's choice of particular revision of one or
> > > > >             more modules may restrict the particular revision of other
> > > > >             modules that may be used in the same request or session.
> > > > >
> > > > > Today, the version number is effectively an (implicit) part of the
> > > > > module name (plus the revision date for backwards compatible changes).
> > > > > Hence, my understanding is that today's model does satisfy 3.2 as
> > > > > well.
> > > > 
> > > > This is not what we have at all. RFC 7950 says a server can only implement
> > > > one revision of a module.
> > > >
> > > 
> > > A new version today essentially means a new module name and I do not
> > > see a conflict with what I wrote.
> > 
> > Then I think this requirement needs clarification.  It says "different
> > revision of modules", which can be interpreted as different revisions
> > of *the same* module.
> > 
> > Also the second part of the paragraph seems to indicate multiple
> > revisions of the same module in the server.
> > 
> > I do not agree with this requirement.
> 
> Today, you need to create a new module if you make NBC changes to
> existing changes (e.g., you change Bool to Int {0..1} and you are not
> creating a new leaf). Since there are now two modules, you _can_
> implement both modules if that makes sense.

Yes.

> If we allow to make such changes as part of a module revision, i.e.,
> without creating a new module, I think we should not loose the ability
> to implement both the old version and the new version.

I don't think we should allow such changes, and if we did, I don't
think that both revisions should be implemented at the same time.  I
think the overall solution would just be too complex.

> I think we need to distinguish between the agreement on the
> requirement, namely that a server should be able to provide support
> for an old and a new definition, and agreement on the solution.
> 
> Do you disagree with the requirement? Or do you disagree with the
> consequences of implementing multiple versions of the same module
> for some of the proposed new versioning schemes? Or both?

I do not agree with the requirement that a server MUST be able to
support multiple revisions of the same module, which is how I
interpret 3.2.  If this is not the intention of 3.2, maybe it can be
clarified.


/martin





> 
> /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 Nov  9 05:42: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 34186130E04; Fri,  9 Nov 2018 05:42:06 -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 7yMTMNN7P8gi; Fri,  9 Nov 2018 05:42:04 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5B405130DFB; Fri,  9 Nov 2018 05:42:04 -0800 (PST)
Received: from localhost (h-40-120.A165.priv.bahnhof.se [94.254.40.120]) by mail.tail-f.com (Postfix) with ESMTPSA id 9AA7C1AE0493; Fri,  9 Nov 2018 14:42:03 +0100 (CET)
Date: Fri, 09 Nov 2018 14:42:03 +0100 (CET)
Message-Id: <20181109.144203.1456851344567787622.mbj@tail-f.com>
To: jclarke@cisco.com
Cc: netmod@ietf.org, netmod-ver-dt@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <20181108.224633.1499859196570533612.mbj@tail-f.com> 
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] Fwd: New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2018 13:42:06 -0000

Joe Clarke  wrote:
> On 11/8/18 16:46, Martin Bjorklund wrote:
> > Hi,
> > 
> > After the session today, it seems to me that one fundamental
> > requirement (or non-requirement) is missing.  How much branching does
> > the solution have to support?  The current solution (6020/7950) and (if
> > I understood Rob Shakir correctly) also openconfig have linear
> > versioning *per module*.  If we can get agreement on this requirement,
> > I think it will be easier to find a solution.
> 
> We discussed this in the DT.  We didn't want to discuss levels of
> branching in the requirements as that pointed to certain solutions.

All requirements point to certain solutions, in a sense.

But if you say that branching is not a requirement on a solution, I'm
happy with that.

> The
> point of requirement 1.4 was to say that the DT felt previous versions
> of modules needed to support fixes without bringing in elements from head.

I think this means that you require branching.

But is this still the point of the "new 1.4" that was mentioned in the
session?

However, as Rob Shakir mentioned in the session, there are other ways
to do fixes / enhacements than branching a single module.  You can add
new functionality with augment and make changes with deviations.


/martin


> We discussed branching to satisfy this requirement as well as protecting
> new features with if-feature and using deviations.
> 
> Joe
> 


From nobody Fri Nov  9 05:46: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 EB5D7130DFF for ; Fri,  9 Nov 2018 05:46:13 -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 SBOjcBb5OvNg for ; Fri,  9 Nov 2018 05:46:11 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025D5130DFB for ; Fri,  9 Nov 2018 05:46:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7066; q=dns/txt; s=iport; t=1541771170; x=1542980770; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7wU4SHf8IyHmwLNV5/w81YP+CWs2s4uZtyvb/zXbQiQ=; b=jLGx9bWHq5ZVaXe+kkibEBdgvaCcxUv+QhfhbNTRjB6GY3Axwd//SX/g N5qaxuPFABJ2pKSv7vV+XaBRvjQmrEUOepdTQS2NBT277elxZxXlKmO75 ifdIUgLJegJ3N2nQO9LS7EwmjNyq9/9rLIkkC3IQa1QL7nT2raJPdH9GD 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADIjuVb/5JdJa1hAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYIDZoECJwqDbogYjWMllzKBegsBARg?= =?us-ascii?q?LhANGAheDCyI0DQ0BAwEBAgEBAm0cDIU6AQEBAwEBASEROgkCDgICAQgOAgg?= =?us-ascii?q?CAiYCAgIZDAsVEAIEAQ0FG4MGAYF5CA+nTIEuihsFBYEGinEXgUE/gREnDBO?= =?us-ascii?q?BTn6DGwEBgUsWFwoZDYI9MYImAok9hUWGGIoyCQKRFxiBV48XiVaNdAIRFIE?= =?us-ascii?q?mHTiBVXAVOyoBgkGCJxcSg2uEYYU+QTGMJYEfAQE?=
X-IronPort-AV: E=Sophos;i="5.54,483,1534809600"; d="scan'208";a="468836958"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2018 13:46:09 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id wA9Dk9r9008037 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Nov 2018 13:46:09 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 9 Nov 2018 07:46:09 -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; Fri, 9 Nov 2018 07:46:08 -0600
From: "Reshad Rahman (rrahman)" 
To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
Thread-Index: AQHUbQzN26pBXqFS9Uuo4XPBFQXcdaUxl7WAgAB13oCAAGvkAIAACa0AgACW4gCAAFffAIAAe8KAgBL0rgCAALEIgIAAWdaA//+ulYA=
Date: Fri, 9 Nov 2018 13:46:08 +0000
Message-ID: <44622200-AB28-4826-9CEC-8A17264E033A@cisco.com>
References: <20181027211355.ppu7wavjcq2butc4@anna.jacobs.jacobs-university.de> <20181108.224220.1513800936571555652.mbj@tail-f.com> <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de> <20181109.143729.1869485019013831956.mbj@tail-f.com>
In-Reply-To: <20181109.143729.1869485019013831956.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.241.214]
Content-Type: text/plain; charset="utf-8"
Content-ID: <7CE7D0564D4B4D44BFEE8E030E5B57F6@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2018 13:46:14 -0000

DQoNCu+7v09uIDIwMTgtMTEtMDksIDg6MzcgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIE1hcnRp
biBCam9ya2x1bmQiIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbWJqQHRh
aWwtZi5jb20+IHdyb3RlOg0KDQogICAgSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndh
ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KICAgID4gT24gVGh1LCBOb3YgMDgs
IDIwMTggYXQgMTA6NDI6MjBQTSArMDEwMCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToNCiAgICA+
ID4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNp
dHkuZGU+IHdyb3RlOg0KICAgID4gPiA+IE9uIFNhdCwgT2N0IDI3LCAyMDE4IGF0IDA2OjUwOjU4
QU0gLTA3MDAsIEFuZHkgQmllcm1hbiB3cm90ZToNCiAgICA+ID4gPiA+IA0KICAgID4gPiA+ID4g
VGhpcyBpcyB3aGF0IHdlIGhhdmUgdG9kYXkgb25seSBpZiBtb2R1bGVzIGFyZSB1cGRhdGVkIGlu
IGxlZ2FsIHdheXMuDQogICAgPiA+ID4gPiBUaGUgMy4xIHJlcXVpcmVtZW50IHNheXMgdGhpcyBi
YWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzIG1haW50YWluZWQgZXZlbg0KICAgID4gPiA+ID4gaWYg
dGhlIG1vZHVsZSBpcyB1cGRhdGVkIGluIHZpb2xhdGlvbiBvZiB0aGUgbW9kdWxlIHVwZGF0ZSBy
dWxlcy4NCiAgICA+ID4gPiA+DQogICAgPiA+ID4gDQogICAgPiA+ID4gSXQgaXMgc3RhdGluZyBh
IHJlcXVpcmVtZW50LiBIb3cgc29sdXRpb25zIG1lZXQgdGhlIHJlcXVpcmVtZW50IGlzIGZvcg0K
ICAgID4gPiA+IHRoZSBzb2x1dGlvbnMgdG8gZmlndXJlIG91dC4NCiAgICA+ID4gPiANCiAgICA+
ID4gPiA+IEhvdyB3b3VsZCAzLjEgYmUgbWV0IGlmIHRoZSBXRyBkZWNpZGVkIHRvIGp1c3QgYWRk
IGEgbmV3ICdkYXRhc3RvcmUnDQogICAgPiA+ID4gPiBrZXkgbGVhZiB0byB0aGUgL21vZHVsZXMt
c3RhdGUvbW9kdWxlIGxpc3Q/DQogICAgPiA+ID4gDQogICAgPiA+ID4gRGVwZW5kcyBvbiB0aGUg
c29sdXRpb24gSSBndWVzcy4NCiAgICA+ID4gPiAgDQogICAgPiA+ID4gPiBJTU8gdGhlIGN1cnJl
bnQgImRlcHJlY2F0ZSBhbmQgc3RhcnQgb3ZlciIgaXMgYWN0dWFsbHkgdGhlIGVhc2llc3QNCiAg
ICA+ID4gPiA+IGFuZCBtb3N0IHJvYnVzdCBzb2x1dGlvbiBwYXRoLCBhbmQgaXQgcmVxdWlyZXMg
bm8gY2hhbmdlcyB0byBZQU5HIG9yDQogICAgPiA+ID4gPiB0aGUgcHJvdG9jb2xzLg0KICAgID4g
PiA+IA0KICAgID4gPiA+IFllcC4gQnV0IHRoZXJlIGFyZSBwZW9wbGUgd2hvIHRoaW5rIHRoYXQg
b3RoZXIgc29sdXRpb25zIGNhbiBkbw0KICAgID4gPiA+IGJldHRlci4gVGhlIGNoYWxsZW5nZSBp
cyB0byBmaW5kIG91dCB3aGV0aGVyIHRoZXkgYWN0dWFsbHkgZG8gYmV0dGVyDQogICAgPiA+ID4g
b3IgZm9yIHdob20gdGhleSBkbyBiZXR0ZXIgKGFuZCBpZiBzb21lb25lIGhhcyB0byBwYXkgYSBw
cmljZSBmb3IgaXQpLg0KICAgID4gPiA+IEZvciBoYXZpbmcgdGhpcyBkaXNjdXNzaW9ucywgaXQg
aXMgZ29vZCB0byB3cml0ZSBkb3duIHJlcXVpcmVtZW50cy4NCiAgICA+ID4gPiANCiAgICA+ID4g
PiA+ID4gICAgICAgIDMuMiAgVGhlIHNvbHV0aW9uIE1VU1QgcHJvdmlkZSBhIG1lY2hhbmlzbSB0
byBhbGxvdyBzZXJ2ZXJzIHRvDQogICAgPiA+ID4gPiA+ICAgICAgICAgICAgIHNpbXVsdGFuZW91
c2x5IHN1cHBvcnQgY2xpZW50cyB1c2luZyBkaWZmZXJlbnQgcmV2aXNpb25zIG9mDQogICAgPiA+
ID4gPiA+ICAgICAgICAgICAgIG1vZHVsZXMuICBBIGNsaWVudCdzIGNob2ljZSBvZiBwYXJ0aWN1
bGFyIHJldmlzaW9uIG9mIG9uZSBvcg0KICAgID4gPiA+ID4gPiAgICAgICAgICAgICBtb3JlIG1v
ZHVsZXMgbWF5IHJlc3RyaWN0IHRoZSBwYXJ0aWN1bGFyIHJldmlzaW9uIG9mIG90aGVyDQogICAg
PiA+ID4gPiA+ICAgICAgICAgICAgIG1vZHVsZXMgdGhhdCBtYXkgYmUgdXNlZCBpbiB0aGUgc2Ft
ZSByZXF1ZXN0IG9yIHNlc3Npb24uDQogICAgPiA+ID4gPiA+DQogICAgPiA+ID4gPiA+IFRvZGF5
LCB0aGUgdmVyc2lvbiBudW1iZXIgaXMgZWZmZWN0aXZlbHkgYW4gKGltcGxpY2l0KSBwYXJ0IG9m
IHRoZQ0KICAgID4gPiA+ID4gPiBtb2R1bGUgbmFtZSAocGx1cyB0aGUgcmV2aXNpb24gZGF0ZSBm
b3IgYmFja3dhcmRzIGNvbXBhdGlibGUgY2hhbmdlcykuDQogICAgPiA+ID4gPiA+IEhlbmNlLCBt
eSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdG9kYXkncyBtb2RlbCBkb2VzIHNhdGlzZnkgMy4yIGFz
DQogICAgPiA+ID4gPiA+IHdlbGwuDQogICAgPiA+ID4gPiANCiAgICA+ID4gPiA+IFRoaXMgaXMg
bm90IHdoYXQgd2UgaGF2ZSBhdCBhbGwuIFJGQyA3OTUwIHNheXMgYSBzZXJ2ZXIgY2FuIG9ubHkg
aW1wbGVtZW50DQogICAgPiA+ID4gPiBvbmUgcmV2aXNpb24gb2YgYSBtb2R1bGUuDQogICAgPiA+
ID4gPg0KICAgID4gPiA+IA0KICAgID4gPiA+IEEgbmV3IHZlcnNpb24gdG9kYXkgZXNzZW50aWFs
bHkgbWVhbnMgYSBuZXcgbW9kdWxlIG5hbWUgYW5kIEkgZG8gbm90DQogICAgPiA+ID4gc2VlIGEg
Y29uZmxpY3Qgd2l0aCB3aGF0IEkgd3JvdGUuDQogICAgPiA+IA0KICAgID4gPiBUaGVuIEkgdGhp
bmsgdGhpcyByZXF1aXJlbWVudCBuZWVkcyBjbGFyaWZpY2F0aW9uLiAgSXQgc2F5cyAiZGlmZmVy
ZW50DQogICAgPiA+IHJldmlzaW9uIG9mIG1vZHVsZXMiLCB3aGljaCBjYW4gYmUgaW50ZXJwcmV0
ZWQgYXMgZGlmZmVyZW50IHJldmlzaW9ucw0KICAgID4gPiBvZiAqdGhlIHNhbWUqIG1vZHVsZS4N
CiAgICA+ID4gDQogICAgPiA+IEFsc28gdGhlIHNlY29uZCBwYXJ0IG9mIHRoZSBwYXJhZ3JhcGgg
c2VlbXMgdG8gaW5kaWNhdGUgbXVsdGlwbGUNCiAgICA+ID4gcmV2aXNpb25zIG9mIHRoZSBzYW1l
IG1vZHVsZSBpbiB0aGUgc2VydmVyLg0KICAgID4gPiANCiAgICA+ID4gSSBkbyBub3QgYWdyZWUg
d2l0aCB0aGlzIHJlcXVpcmVtZW50Lg0KICAgID4gDQogICAgPiBUb2RheSwgeW91IG5lZWQgdG8g
Y3JlYXRlIGEgbmV3IG1vZHVsZSBpZiB5b3UgbWFrZSBOQkMgY2hhbmdlcyB0bw0KICAgID4gZXhp
c3RpbmcgY2hhbmdlcyAoZS5nLiwgeW91IGNoYW5nZSBCb29sIHRvIEludCB7MC4uMX0gYW5kIHlv
dSBhcmUgbm90DQogICAgPiBjcmVhdGluZyBhIG5ldyBsZWFmKS4gU2luY2UgdGhlcmUgYXJlIG5v
dyB0d28gbW9kdWxlcywgeW91IF9jYW5fDQogICAgPiBpbXBsZW1lbnQgYm90aCBtb2R1bGVzIGlm
IHRoYXQgbWFrZXMgc2Vuc2UuDQogICAgDQogICAgWWVzLg0KICAgIA0KICAgID4gSWYgd2UgYWxs
b3cgdG8gbWFrZSBzdWNoIGNoYW5nZXMgYXMgcGFydCBvZiBhIG1vZHVsZSByZXZpc2lvbiwgaS5l
LiwNCiAgICA+IHdpdGhvdXQgY3JlYXRpbmcgYSBuZXcgbW9kdWxlLCBJIHRoaW5rIHdlIHNob3Vs
ZCBub3QgbG9vc2UgdGhlIGFiaWxpdHkNCiAgICA+IHRvIGltcGxlbWVudCBib3RoIHRoZSBvbGQg
dmVyc2lvbiBhbmQgdGhlIG5ldyB2ZXJzaW9uLg0KICAgIA0KICAgIEkgZG9uJ3QgdGhpbmsgd2Ug
c2hvdWxkIGFsbG93IHN1Y2ggY2hhbmdlcywgYW5kIGlmIHdlIGRpZCwgSSBkb24ndA0KICAgIHRo
aW5rIHRoYXQgYm90aCByZXZpc2lvbnMgc2hvdWxkIGJlIGltcGxlbWVudGVkIGF0IHRoZSBzYW1l
IHRpbWUuICBJDQogICAgdGhpbmsgdGhlIG92ZXJhbGwgc29sdXRpb24gd291bGQganVzdCBiZSB0
b28gY29tcGxleC4NCiAgICANCiAgICA+IEkgdGhpbmsgd2UgbmVlZCB0byBkaXN0aW5ndWlzaCBi
ZXR3ZWVuIHRoZSBhZ3JlZW1lbnQgb24gdGhlDQogICAgPiByZXF1aXJlbWVudCwgbmFtZWx5IHRo
YXQgYSBzZXJ2ZXIgc2hvdWxkIGJlIGFibGUgdG8gcHJvdmlkZSBzdXBwb3J0DQogICAgPiBmb3Ig
YW4gb2xkIGFuZCBhIG5ldyBkZWZpbml0aW9uLCBhbmQgYWdyZWVtZW50IG9uIHRoZSBzb2x1dGlv
bi4NCiAgICA+IA0KICAgID4gRG8geW91IGRpc2FncmVlIHdpdGggdGhlIHJlcXVpcmVtZW50PyBP
ciBkbyB5b3UgZGlzYWdyZWUgd2l0aCB0aGUNCiAgICA+IGNvbnNlcXVlbmNlcyBvZiBpbXBsZW1l
bnRpbmcgbXVsdGlwbGUgdmVyc2lvbnMgb2YgdGhlIHNhbWUgbW9kdWxlDQogICAgPiBmb3Igc29t
ZSBvZiB0aGUgcHJvcG9zZWQgbmV3IHZlcnNpb25pbmcgc2NoZW1lcz8gT3IgYm90aD8NCiAgICAN
CiAgICBJIGRvIG5vdCBhZ3JlZSB3aXRoIHRoZSByZXF1aXJlbWVudCB0aGF0IGEgc2VydmVyIE1V
U1QgYmUgYWJsZSB0bw0KICAgIHN1cHBvcnQgbXVsdGlwbGUgcmV2aXNpb25zIG9mIHRoZSBzYW1l
IG1vZHVsZSwgd2hpY2ggaXMgaG93IEkNCiAgICBpbnRlcnByZXQgMy4yLiAgSWYgdGhpcyBpcyBu
b3QgdGhlIGludGVudGlvbiBvZiAzLjIsIG1heWJlIGl0IGNhbiBiZQ0KICAgIGNsYXJpZmllZC4N
CiAgICANCjxSUj4gSXQgc2F5cyAiVGhlIHNvbHV0aW9uIE1VU1QgcHJvdmlkZS4uLiIsIHNvIHRo
ZSBzb2x1dGlvbiBkcmFmdCBNVVNUIHByb3ZpZGUgYSBzb2x1dGlvbiBvbiBob3cgdG8gZG8gdGhp
cy4gV2hldGhlciBhIHNlcnZlciBpbXBsZW1lbnRzIHRoZSBzb2x1dGlvbiBvciBub3QgaXMgYSBk
aWZmZXJlbnQgbWF0dGVyLiBXZSByZWFsaXplIHRoaXMgaXMgYSBwYWluIGZvciBtb3N0IHNlcnZl
cnMgYnV0IHNvbWUgc2VydmVycyBtYXkgYmUgYWJsZSB0byBkbyBpdC4NCg0KUmVnYXJkcywNClJl
c2hhZC4NCiAgICANCiAgICAvbWFydGluDQogICAgDQogICAgDQogICAgDQogICAgDQogICAgDQog
ICAgPiANCiAgICA+IC9qcw0KICAgID4gDQogICAgPiAtLSANCiAgICA+IEp1ZXJnZW4gU2Nob2Vu
d2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQogICAgPiBQ
aG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVt
ZW4gfCBHZXJtYW55DQogICAgPiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRw
czovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQogICAgPiANCiAgICANCiAgICBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIG5ldG1vZCBtYWls
aW5nIGxpc3QNCiAgICBuZXRtb2RAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KICAgIA0KDQo=


From nobody Fri Nov  9 05:51: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 91B12130DFF for ; Fri,  9 Nov 2018 05:51:13 -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 oxK__kN5AizN for ; Fri,  9 Nov 2018 05:51:07 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 00218130DFB for ; Fri,  9 Nov 2018 05:51:06 -0800 (PST)
Received: from localhost (h-40-120.A165.priv.bahnhof.se [94.254.40.120]) by mail.tail-f.com (Postfix) with ESMTPSA id 348A21AE0493; Fri,  9 Nov 2018 14:51:06 +0100 (CET)
Date: Fri, 09 Nov 2018 14:51:06 +0100 (CET)
Message-Id: <20181109.145106.380003384922236577.mbj@tail-f.com>
To: rrahman@cisco.com
Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <44622200-AB28-4826-9CEC-8A17264E033A@cisco.com>
References: <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de> <20181109.143729.1869485019013831956.mbj@tail-f.com> <44622200-AB28-4826-9CEC-8A17264E033A@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2018 13:51:14 -0000

IlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNjby5jb20+IHdyb3RlOg0KPiAN
Cj4gDQo+IO+7v09uIDIwMTgtMTEtMDksIDg6MzcgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIE1h
cnRpbiBCam9ya2x1bmQiDQo+IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yg
bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0KPiANCj4gICAgIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8
ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4gICAgID4gT24g
VGh1LCBOb3YgMDgsIDIwMTggYXQgMTA6NDI6MjBQTSArMDEwMCwgTWFydGluIEJqb3JrbHVuZCB3
cm90ZToNCj4gICAgID4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBq
YWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+ICAgICA+ID4gPiBPbiBTYXQsIE9jdCAyNywg
MjAxOCBhdCAwNjo1MDo1OEFNIC0wNzAwLCBBbmR5IEJpZXJtYW4gd3JvdGU6DQo+ICAgICA+ID4g
PiA+IA0KPiAgICAgPiA+ID4gPiBUaGlzIGlzIHdoYXQgd2UgaGF2ZSB0b2RheSBvbmx5IGlmIG1v
ZHVsZXMgYXJlIHVwZGF0ZWQgaW4gbGVnYWwNCj4gICAgID4gPiA+ID4gd2F5cy4NCj4gICAgID4g
PiA+ID4gVGhlIDMuMSByZXF1aXJlbWVudCBzYXlzIHRoaXMgYmFja3dhcmQgY29tcGF0aWJpbGl0
eSBpcyBtYWludGFpbmVkDQo+ICAgICA+ID4gPiA+IGV2ZW4NCj4gICAgID4gPiA+ID4gaWYgdGhl
IG1vZHVsZSBpcyB1cGRhdGVkIGluIHZpb2xhdGlvbiBvZiB0aGUgbW9kdWxlIHVwZGF0ZSBydWxl
cy4NCj4gICAgID4gPiA+ID4NCj4gICAgID4gPiA+IA0KPiAgICAgPiA+ID4gSXQgaXMgc3RhdGlu
ZyBhIHJlcXVpcmVtZW50LiBIb3cgc29sdXRpb25zIG1lZXQgdGhlIHJlcXVpcmVtZW50IGlzDQo+
ICAgICA+ID4gPiBmb3INCj4gICAgID4gPiA+IHRoZSBzb2x1dGlvbnMgdG8gZmlndXJlIG91dC4N
Cj4gICAgID4gPiA+IA0KPiAgICAgPiA+ID4gPiBIb3cgd291bGQgMy4xIGJlIG1ldCBpZiB0aGUg
V0cgZGVjaWRlZCB0byBqdXN0IGFkZCBhIG5ldw0KPiAgICAgPiA+ID4gPiAnZGF0YXN0b3JlJw0K
PiAgICAgPiA+ID4gPiBrZXkgbGVhZiB0byB0aGUgL21vZHVsZXMtc3RhdGUvbW9kdWxlIGxpc3Q/
DQo+ICAgICA+ID4gPiANCj4gICAgID4gPiA+IERlcGVuZHMgb24gdGhlIHNvbHV0aW9uIEkgZ3Vl
c3MuDQo+ICAgICA+ID4gPiAgDQo+ICAgICA+ID4gPiA+IElNTyB0aGUgY3VycmVudCAiZGVwcmVj
YXRlIGFuZCBzdGFydCBvdmVyIiBpcyBhY3R1YWxseSB0aGUgZWFzaWVzdA0KPiAgICAgPiA+ID4g
PiBhbmQgbW9zdCByb2J1c3Qgc29sdXRpb24gcGF0aCwgYW5kIGl0IHJlcXVpcmVzIG5vIGNoYW5n
ZXMgdG8gWUFORw0KPiAgICAgPiA+ID4gPiBvcg0KPiAgICAgPiA+ID4gPiB0aGUgcHJvdG9jb2xz
Lg0KPiAgICAgPiA+ID4gDQo+ICAgICA+ID4gPiBZZXAuIEJ1dCB0aGVyZSBhcmUgcGVvcGxlIHdo
byB0aGluayB0aGF0IG90aGVyIHNvbHV0aW9ucyBjYW4gZG8NCj4gICAgID4gPiA+IGJldHRlci4g
VGhlIGNoYWxsZW5nZSBpcyB0byBmaW5kIG91dCB3aGV0aGVyIHRoZXkgYWN0dWFsbHkgZG8gYmV0
dGVyDQo+ICAgICA+ID4gPiBvciBmb3Igd2hvbSB0aGV5IGRvIGJldHRlciAoYW5kIGlmIHNvbWVv
bmUgaGFzIHRvIHBheSBhIHByaWNlIGZvcg0KPiAgICAgPiA+ID4gaXQpLg0KPiAgICAgPiA+ID4g
Rm9yIGhhdmluZyB0aGlzIGRpc2N1c3Npb25zLCBpdCBpcyBnb29kIHRvIHdyaXRlIGRvd24gcmVx
dWlyZW1lbnRzLg0KPiAgICAgPiA+ID4gDQo+ICAgICA+ID4gPiA+ID4gICAgICAgIDMuMiBUaGUg
c29sdXRpb24gTVVTVCBwcm92aWRlIGEgbWVjaGFuaXNtIHRvIGFsbG93IHNlcnZlcnMNCj4gICAg
ID4gPiA+ID4gPiAgICAgICAgdG8NCj4gICAgID4gPiA+ID4gPiAgICAgICAgICAgICBzaW11bHRh
bmVvdXNseSBzdXBwb3J0IGNsaWVudHMgdXNpbmcgZGlmZmVyZW50DQo+ICAgICA+ID4gPiA+ID4g
ICAgICAgICAgICAgcmV2aXNpb25zIG9mDQo+ICAgICA+ID4gPiA+ID4gICAgICAgICAgICAgbW9k
dWxlcy4gIEEgY2xpZW50J3MgY2hvaWNlIG9mIHBhcnRpY3VsYXIgcmV2aXNpb24gb2YNCj4gICAg
ID4gPiA+ID4gPiAgICAgICAgICAgICBvbmUgb3INCj4gICAgID4gPiA+ID4gPiAgICAgICAgICAg
ICBtb3JlIG1vZHVsZXMgbWF5IHJlc3RyaWN0IHRoZSBwYXJ0aWN1bGFyIHJldmlzaW9uIG9mDQo+
ICAgICA+ID4gPiA+ID4gICAgICAgICAgICAgb3RoZXINCj4gICAgID4gPiA+ID4gPiAgICAgICAg
ICAgICBtb2R1bGVzIHRoYXQgbWF5IGJlIHVzZWQgaW4gdGhlIHNhbWUgcmVxdWVzdCBvcg0KPiAg
ICAgPiA+ID4gPiA+ICAgICAgICAgICAgIHNlc3Npb24uDQo+ICAgICA+ID4gPiA+ID4NCj4gICAg
ID4gPiA+ID4gPiBUb2RheSwgdGhlIHZlcnNpb24gbnVtYmVyIGlzIGVmZmVjdGl2ZWx5IGFuIChp
bXBsaWNpdCkgcGFydCBvZg0KPiAgICAgPiA+ID4gPiA+IHRoZQ0KPiAgICAgPiA+ID4gPiA+IG1v
ZHVsZSBuYW1lIChwbHVzIHRoZSByZXZpc2lvbiBkYXRlIGZvciBiYWNrd2FyZHMgY29tcGF0aWJs
ZQ0KPiAgICAgPiA+ID4gPiA+IGNoYW5nZXMpLg0KPiAgICAgPiA+ID4gPiA+IEhlbmNlLCBteSB1
bmRlcnN0YW5kaW5nIGlzIHRoYXQgdG9kYXkncyBtb2RlbCBkb2VzIHNhdGlzZnkgMy4yIGFzDQo+
ICAgICA+ID4gPiA+ID4gd2VsbC4NCj4gICAgID4gPiA+ID4gDQo+ICAgICA+ID4gPiA+IFRoaXMg
aXMgbm90IHdoYXQgd2UgaGF2ZSBhdCBhbGwuIFJGQyA3OTUwIHNheXMgYSBzZXJ2ZXIgY2FuIG9u
bHkNCj4gICAgID4gPiA+ID4gaW1wbGVtZW50DQo+ICAgICA+ID4gPiA+IG9uZSByZXZpc2lvbiBv
ZiBhIG1vZHVsZS4NCj4gICAgID4gPiA+ID4NCj4gICAgID4gPiA+IA0KPiAgICAgPiA+ID4gQSBu
ZXcgdmVyc2lvbiB0b2RheSBlc3NlbnRpYWxseSBtZWFucyBhIG5ldyBtb2R1bGUgbmFtZSBhbmQg
SSBkbyBub3QNCj4gICAgID4gPiA+IHNlZSBhIGNvbmZsaWN0IHdpdGggd2hhdCBJIHdyb3RlLg0K
PiAgICAgPiA+IA0KPiAgICAgPiA+IFRoZW4gSSB0aGluayB0aGlzIHJlcXVpcmVtZW50IG5lZWRz
IGNsYXJpZmljYXRpb24uICBJdCBzYXlzICJkaWZmZXJlbnQNCj4gICAgID4gPiByZXZpc2lvbiBv
ZiBtb2R1bGVzIiwgd2hpY2ggY2FuIGJlIGludGVycHJldGVkIGFzIGRpZmZlcmVudCByZXZpc2lv
bnMNCj4gICAgID4gPiBvZiAqdGhlIHNhbWUqIG1vZHVsZS4NCj4gICAgID4gPiANCj4gICAgID4g
PiBBbHNvIHRoZSBzZWNvbmQgcGFydCBvZiB0aGUgcGFyYWdyYXBoIHNlZW1zIHRvIGluZGljYXRl
IG11bHRpcGxlDQo+ICAgICA+ID4gcmV2aXNpb25zIG9mIHRoZSBzYW1lIG1vZHVsZSBpbiB0aGUg
c2VydmVyLg0KPiAgICAgPiA+IA0KPiAgICAgPiA+IEkgZG8gbm90IGFncmVlIHdpdGggdGhpcyBy
ZXF1aXJlbWVudC4NCj4gICAgID4gDQo+ICAgICA+IFRvZGF5LCB5b3UgbmVlZCB0byBjcmVhdGUg
YSBuZXcgbW9kdWxlIGlmIHlvdSBtYWtlIE5CQyBjaGFuZ2VzIHRvDQo+ICAgICA+IGV4aXN0aW5n
IGNoYW5nZXMgKGUuZy4sIHlvdSBjaGFuZ2UgQm9vbCB0byBJbnQgezAuLjF9IGFuZCB5b3UgYXJl
IG5vdA0KPiAgICAgPiBjcmVhdGluZyBhIG5ldyBsZWFmKS4gU2luY2UgdGhlcmUgYXJlIG5vdyB0
d28gbW9kdWxlcywgeW91IF9jYW5fDQo+ICAgICA+IGltcGxlbWVudCBib3RoIG1vZHVsZXMgaWYg
dGhhdCBtYWtlcyBzZW5zZS4NCj4gICAgIA0KPiAgICAgWWVzLg0KPiAgICAgDQo+ICAgICA+IElm
IHdlIGFsbG93IHRvIG1ha2Ugc3VjaCBjaGFuZ2VzIGFzIHBhcnQgb2YgYSBtb2R1bGUgcmV2aXNp
b24sIGkuZS4sDQo+ICAgICA+IHdpdGhvdXQgY3JlYXRpbmcgYSBuZXcgbW9kdWxlLCBJIHRoaW5r
IHdlIHNob3VsZCBub3QgbG9vc2UgdGhlIGFiaWxpdHkNCj4gICAgID4gdG8gaW1wbGVtZW50IGJv
dGggdGhlIG9sZCB2ZXJzaW9uIGFuZCB0aGUgbmV3IHZlcnNpb24uDQo+ICAgICANCj4gICAgIEkg
ZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIGFsbG93IHN1Y2ggY2hhbmdlcywgYW5kIGlmIHdlIGRpZCwg
SSBkb24ndA0KPiAgICAgdGhpbmsgdGhhdCBib3RoIHJldmlzaW9ucyBzaG91bGQgYmUgaW1wbGVt
ZW50ZWQgYXQgdGhlIHNhbWUgdGltZS4gIEkNCj4gICAgIHRoaW5rIHRoZSBvdmVyYWxsIHNvbHV0
aW9uIHdvdWxkIGp1c3QgYmUgdG9vIGNvbXBsZXguDQo+ICAgICANCj4gICAgID4gSSB0aGluayB3
ZSBuZWVkIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gdGhlIGFncmVlbWVudCBvbiB0aGUNCj4gICAg
ID4gcmVxdWlyZW1lbnQsIG5hbWVseSB0aGF0IGEgc2VydmVyIHNob3VsZCBiZSBhYmxlIHRvIHBy
b3ZpZGUgc3VwcG9ydA0KPiAgICAgPiBmb3IgYW4gb2xkIGFuZCBhIG5ldyBkZWZpbml0aW9uLCBh
bmQgYWdyZWVtZW50IG9uIHRoZSBzb2x1dGlvbi4NCj4gICAgID4gDQo+ICAgICA+IERvIHlvdSBk
aXNhZ3JlZSB3aXRoIHRoZSByZXF1aXJlbWVudD8gT3IgZG8geW91IGRpc2FncmVlIHdpdGggdGhl
DQo+ICAgICA+IGNvbnNlcXVlbmNlcyBvZiBpbXBsZW1lbnRpbmcgbXVsdGlwbGUgdmVyc2lvbnMg
b2YgdGhlIHNhbWUgbW9kdWxlDQo+ICAgICA+IGZvciBzb21lIG9mIHRoZSBwcm9wb3NlZCBuZXcg
dmVyc2lvbmluZyBzY2hlbWVzPyBPciBib3RoPw0KPiAgICAgDQo+ICAgICBJIGRvIG5vdCBhZ3Jl
ZSB3aXRoIHRoZSByZXF1aXJlbWVudCB0aGF0IGEgc2VydmVyIE1VU1QgYmUgYWJsZSB0bw0KPiAg
ICAgc3VwcG9ydCBtdWx0aXBsZSByZXZpc2lvbnMgb2YgdGhlIHNhbWUgbW9kdWxlLCB3aGljaCBp
cyBob3cgSQ0KPiAgICAgaW50ZXJwcmV0IDMuMi4gIElmIHRoaXMgaXMgbm90IHRoZSBpbnRlbnRp
b24gb2YgMy4yLCBtYXliZSBpdCBjYW4gYmUNCj4gICAgIGNsYXJpZmllZC4NCj4gICAgIA0KPiA8
UlI+IEl0IHNheXMgIlRoZSBzb2x1dGlvbiBNVVNUIHByb3ZpZGUuLi4iLCBzbyB0aGUgc29sdXRp
b24gZHJhZnQNCj4gTVVTVCBwcm92aWRlIGEgc29sdXRpb24gb24gaG93IHRvIGRvIHRoaXMuIFdo
ZXRoZXIgYSBzZXJ2ZXIgaW1wbGVtZW50cw0KPiB0aGUgc29sdXRpb24gb3Igbm90IGlzIGEgZGlm
ZmVyZW50IG1hdHRlci4gV2UgcmVhbGl6ZSB0aGlzIGlzIGEgcGFpbg0KPiBmb3IgbW9zdCBzZXJ2
ZXJzIGJ1dCBzb21lIHNlcnZlcnMgbWF5IGJlIGFibGUgdG8gZG8gaXQuDQoNCkkgdW5kZXJzdGFu
ZC4gIEJ1dCBJIGRvbid0IGFncmVlIHdpdGggdGhpcyByZXF1aXJlbWVudCwgZXZlbiBpZiBzb21l
DQpzZXJ2ZXIgd291bGQgYmUgYWJsZSB0byBpbXBsZW1lbnQgaXQuICBJIHRoaW5rIGl0IG1ha2Vz
IHRoZSB3aG9sZQ0Kc29sdXRpb24gbXVjaCBtb3JlIGNvbXBsZXgsIHcvbyBtdWNoIGdhaW4uICBJ
dCBpcyBjb21wbGV4IGVub3VnaCBhcyBpdA0KaXMuDQoNCg0KL21hcnRpbg0K


From nobody Fri Nov  9 05:54: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 65AB8130E03 for ; Fri,  9 Nov 2018 05:54:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-qJZW5HCt9H for ; Fri,  9 Nov 2018 05:54:43 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9114E130DFF for ; Fri,  9 Nov 2018 05:54:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22104; q=dns/txt; s=iport; t=1541771683; x=1542981283; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=pHjw6aMSYa6mUm8j700ob4Xu1BtAjMzdKCwqeq3Pt6E=; b=Ps3MkrVNdHTWVTbQP1isa7TRuudKOSqwGff3yZU/WcawW7hlNCLMKH5i TmK1EVkG9EGDpQzgJuEUXF3bkg5QqGp5aMvVdSZcTSc/eI90xCGfgZ/X2 nBR//PtJLYDR5B0i55gyZrc2XsBVM1UABM8lILoMM8wz03Lzoyoj2CBDK c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACvkOVb/4gNJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ12ZoECJwqDbogYi3uCDZFehVSBegs?= =?us-ascii?q?BASOESQIXgwsiNA0NAQMBAQIBAQJtHAyFOgEBAQEDIwpKEgIBCBABAwECASc?= =?us-ascii?q?DAgICMBQJCAIEARIbgwYBgR1kD6dCgS6KHQWLfBeBQT+BEScfgU5+gxsBAQI?= =?us-ascii?q?BgUgkEhaCTjGCJgKJHSBMhGIXhhiKMgkChnGKJhiBV48XiVaDS4opAhEUgSY?= =?us-ascii?q?dOIFVcBU7KgGCQQmCR4hMhT5BMQEBi3CBHwEB?=
X-IronPort-AV: E=Sophos;i="5.54,483,1534809600";  d="scan'208,217";a="199021327"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2018 13:54:42 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id wA9DsgRd002579 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Nov 2018 13:54:42 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 9 Nov 2018 07:54:41 -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; Fri, 9 Nov 2018 07:54:41 -0600
From: "Reshad Rahman (rrahman)" 
To: Andy Bierman , Juergen Schoenwaelder , Martin Bjorklund , NetMod WG 
Thread-Topic: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
Thread-Index: AQHUbQzN26pBXqFS9Uuo4XPBFQXcdaUxl7WAgAB13oCAAGvkAIAACa0AgACW4gCAAFffAIAAe8KAgBL0rgCAALEIgIAAOHeA///SWAA=
Date: Fri, 9 Nov 2018 13:54:41 +0000
Message-ID: <6A766C10-92D0-465E-A3D9-FB54086E2510@cisco.com>
References: <20181027083628.tgymddbje3yp2lhy@anna.jacobs.jacobs-university.de>  <20181027211355.ppu7wavjcq2butc4@anna.jacobs.jacobs-university.de> <20181108.224220.1513800936571555652.mbj@tail-f.com> <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.241.214]
Content-Type: multipart/alternative; boundary="_000_6A766C1092D0465EA3D9FB54086E2510ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2018 13:54:48 -0000

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

DQpGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgJ0Fu
ZHkgQmllcm1hbicgPGFuZHlAeXVtYXdvcmtzLmNvbT4NCkRhdGU6IEZyaWRheSwgTm92ZW1iZXIg
OSwgMjAxOCBhdCA2OjM4IFBNDQpUbzogSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndh
ZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+LCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1m
LmNvbT4sICdBbmR5IEJpZXJtYW4nIDxhbmR5QHl1bWF3b3Jrcy5jb20+LCBOZXRNb2QgV0cgPG5l
dG1vZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBOZXcgVmVyc2lvbiBOb3RpZmlj
YXRpb24gZm9yIGRyYWZ0LXZlcmR0LW5ldG1vZC15YW5nLXZlcnNpb25pbmctcmVxcy0wMS50eHQN
Cg0KDQoNCk9uIEZyaSwgTm92IDksIDIwMTggYXQgMTI6MTUgQU0sIEp1ZXJnZW4gU2Nob2Vud2Fl
bGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9l
bndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+PiB3cm90ZToNCk9uIFRodSwgTm92IDA4LCAy
MDE4IGF0IDEwOjQyOjIwUE0gKzAxMDAsIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQo+IEp1ZXJn
ZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPG1h
aWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+PiB3cm90ZToNCj4gPiBP
biBTYXQsIE9jdCAyNywgMjAxOCBhdCAwNjo1MDo1OEFNIC0wNzAwLCBBbmR5IEJpZXJtYW4gd3Jv
dGU6DQo+ID4gPg0KPiA+ID4gVGhpcyBpcyB3aGF0IHdlIGhhdmUgdG9kYXkgb25seSBpZiBtb2R1
bGVzIGFyZSB1cGRhdGVkIGluIGxlZ2FsIHdheXMuDQo+ID4gPiBUaGUgMy4xIHJlcXVpcmVtZW50
IHNheXMgdGhpcyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzIG1haW50YWluZWQgZXZlbg0KPiA+
ID4gaWYgdGhlIG1vZHVsZSBpcyB1cGRhdGVkIGluIHZpb2xhdGlvbiBvZiB0aGUgbW9kdWxlIHVw
ZGF0ZSBydWxlcy4NCj4gPiA+DQo+ID4NCj4gPiBJdCBpcyBzdGF0aW5nIGEgcmVxdWlyZW1lbnQu
IEhvdyBzb2x1dGlvbnMgbWVldCB0aGUgcmVxdWlyZW1lbnQgaXMgZm9yDQo+ID4gdGhlIHNvbHV0
aW9ucyB0byBmaWd1cmUgb3V0Lg0KPiA+DQo+ID4gPiBIb3cgd291bGQgMy4xIGJlIG1ldCBpZiB0
aGUgV0cgZGVjaWRlZCB0byBqdXN0IGFkZCBhIG5ldyAnZGF0YXN0b3JlJw0KPiA+ID4ga2V5IGxl
YWYgdG8gdGhlIC9tb2R1bGVzLXN0YXRlL21vZHVsZSBsaXN0Pw0KPiA+DQo+ID4gRGVwZW5kcyBv
biB0aGUgc29sdXRpb24gSSBndWVzcy4NCj4gPg0KPiA+ID4gSU1PIHRoZSBjdXJyZW50ICJkZXBy
ZWNhdGUgYW5kIHN0YXJ0IG92ZXIiIGlzIGFjdHVhbGx5IHRoZSBlYXNpZXN0DQo+ID4gPiBhbmQg
bW9zdCByb2J1c3Qgc29sdXRpb24gcGF0aCwgYW5kIGl0IHJlcXVpcmVzIG5vIGNoYW5nZXMgdG8g
WUFORyBvcg0KPiA+ID4gdGhlIHByb3RvY29scy4NCj4gPg0KPiA+IFllcC4gQnV0IHRoZXJlIGFy
ZSBwZW9wbGUgd2hvIHRoaW5rIHRoYXQgb3RoZXIgc29sdXRpb25zIGNhbiBkbw0KPiA+IGJldHRl
ci4gVGhlIGNoYWxsZW5nZSBpcyB0byBmaW5kIG91dCB3aGV0aGVyIHRoZXkgYWN0dWFsbHkgZG8g
YmV0dGVyDQo+ID4gb3IgZm9yIHdob20gdGhleSBkbyBiZXR0ZXIgKGFuZCBpZiBzb21lb25lIGhh
cyB0byBwYXkgYSBwcmljZSBmb3IgaXQpLg0KPiA+IEZvciBoYXZpbmcgdGhpcyBkaXNjdXNzaW9u
cywgaXQgaXMgZ29vZCB0byB3cml0ZSBkb3duIHJlcXVpcmVtZW50cy4NCj4gPg0KPiA+ID4gPiAg
ICAgICAgMy4yICBUaGUgc29sdXRpb24gTVVTVCBwcm92aWRlIGEgbWVjaGFuaXNtIHRvIGFsbG93
IHNlcnZlcnMgdG8NCj4gPiA+ID4gICAgICAgICAgICAgc2ltdWx0YW5lb3VzbHkgc3VwcG9ydCBj
bGllbnRzIHVzaW5nIGRpZmZlcmVudCByZXZpc2lvbnMgb2YNCj4gPiA+ID4gICAgICAgICAgICAg
bW9kdWxlcy4gIEEgY2xpZW50J3MgY2hvaWNlIG9mIHBhcnRpY3VsYXIgcmV2aXNpb24gb2Ygb25l
IG9yDQo+ID4gPiA+ICAgICAgICAgICAgIG1vcmUgbW9kdWxlcyBtYXkgcmVzdHJpY3QgdGhlIHBh
cnRpY3VsYXIgcmV2aXNpb24gb2Ygb3RoZXINCj4gPiA+ID4gICAgICAgICAgICAgbW9kdWxlcyB0
aGF0IG1heSBiZSB1c2VkIGluIHRoZSBzYW1lIHJlcXVlc3Qgb3Igc2Vzc2lvbi4NCj4gPiA+ID4N
Cj4gPiA+ID4gVG9kYXksIHRoZSB2ZXJzaW9uIG51bWJlciBpcyBlZmZlY3RpdmVseSBhbiAoaW1w
bGljaXQpIHBhcnQgb2YgdGhlDQo+ID4gPiA+IG1vZHVsZSBuYW1lIChwbHVzIHRoZSByZXZpc2lv
biBkYXRlIGZvciBiYWNrd2FyZHMgY29tcGF0aWJsZSBjaGFuZ2VzKS4NCj4gPiA+ID4gSGVuY2Us
IG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0b2RheSdzIG1vZGVsIGRvZXMgc2F0aXNmeSAzLjIg
YXMNCj4gPiA+ID4gd2VsbC4NCj4gPiA+DQo+ID4gPiBUaGlzIGlzIG5vdCB3aGF0IHdlIGhhdmUg
YXQgYWxsLiBSRkMgNzk1MCBzYXlzIGEgc2VydmVyIGNhbiBvbmx5IGltcGxlbWVudA0KPiA+ID4g
b25lIHJldmlzaW9uIG9mIGEgbW9kdWxlLg0KPiA+ID4NCj4gPg0KPiA+IEEgbmV3IHZlcnNpb24g
dG9kYXkgZXNzZW50aWFsbHkgbWVhbnMgYSBuZXcgbW9kdWxlIG5hbWUgYW5kIEkgZG8gbm90DQo+
ID4gc2VlIGEgY29uZmxpY3Qgd2l0aCB3aGF0IEkgd3JvdGUuDQo+DQo+IFRoZW4gSSB0aGluayB0
aGlzIHJlcXVpcmVtZW50IG5lZWRzIGNsYXJpZmljYXRpb24uICBJdCBzYXlzICJkaWZmZXJlbnQN
Cj4gcmV2aXNpb24gb2YgbW9kdWxlcyIsIHdoaWNoIGNhbiBiZSBpbnRlcnByZXRlZCBhcyBkaWZm
ZXJlbnQgcmV2aXNpb25zDQo+IG9mICp0aGUgc2FtZSogbW9kdWxlLg0KPg0KPiBBbHNvIHRoZSBz
ZWNvbmQgcGFydCBvZiB0aGUgcGFyYWdyYXBoIHNlZW1zIHRvIGluZGljYXRlIG11bHRpcGxlDQo+
IHJldmlzaW9ucyBvZiB0aGUgc2FtZSBtb2R1bGUgaW4gdGhlIHNlcnZlci4NCj4NCj4gSSBkbyBu
b3QgYWdyZWUgd2l0aCB0aGlzIHJlcXVpcmVtZW50Lg0KDQpUb2RheSwgeW91IG5lZWQgdG8gY3Jl
YXRlIGEgbmV3IG1vZHVsZSBpZiB5b3UgbWFrZSBOQkMgY2hhbmdlcyB0bw0KZXhpc3RpbmcgY2hh
bmdlcyAoZS5nLiwgeW91IGNoYW5nZSBCb29sIHRvIEludCB7MC4uMX0gYW5kIHlvdSBhcmUgbm90
DQpjcmVhdGluZyBhIG5ldyBsZWFmKS4gU2luY2UgdGhlcmUgYXJlIG5vdyB0d28gbW9kdWxlcywg
eW91IF9jYW5fDQppbXBsZW1lbnQgYm90aCBtb2R1bGVzIGlmIHRoYXQgbWFrZXMgc2Vuc2UuDQoN
Cg0KVGhpcyBkb2VzIG5vdCBtYWtlIHNlbnNlIGJlY2F1c2UgYSBub2RlIGluIFlBTkcgaXMgaWRl
bnRpZmllZCBieSBhIFFOYW1lLA0Kbm90IGp1c3QgYSBsb2NhbC1uYW1lLiAgIFRoZSBub2RlIG9s
ZG1vZDpmb28gaXMgbm90IHRoZSBzYW1lIGFzIG5ld21vZDpmb28uDQpJdCBuZXZlciBoYXMgYmVl
biBhbmQgbmV2ZXIgd2lsbCBiZSB0aGUgc2FtZSBub2RlLg0KPFJSPiBJIGRpc2FncmVlLCBwZXIg
aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc5NTAjc2VjdGlvbi00LjIuMQ0KICAgQSBz
ZXJ2ZXIgbWF5IGltcGxlbWVudCBhIG51bWJlciBvZiBtb2R1bGVzLCBhbGxvd2luZyBtdWx0aXBs
ZSB2aWV3cw0KICAgb2YgdGhlIHNhbWUgZGF0YSBvciBtdWx0aXBsZSB2aWV3cyBvZiBkaXNqb2lu
dCBzdWJzZWN0aW9ucyBvZiB0aGUNCiAgIHNlcnZlcidzIGRhdGEuICBBbHRlcm5hdGl2ZWx5LCB0
aGUgc2VydmVyIG1heSBpbXBsZW1lbnQgb25seSBvbmUNCiAgIG1vZHVsZSB0aGF0IGRlZmluZXMg
YWxsIGF2YWlsYWJsZSBkYXRhLg0KDQoNCklmIHdlIGFsbG93IHRvIG1ha2Ugc3VjaCBjaGFuZ2Vz
IGFzIHBhcnQgb2YgYSBtb2R1bGUgcmV2aXNpb24sIGkuZS4sDQp3aXRob3V0IGNyZWF0aW5nIGEg
bmV3IG1vZHVsZSwgSSB0aGluayB3ZSBzaG91bGQgbm90IGxvb3NlIHRoZSBhYmlsaXR5DQp0byBp
bXBsZW1lbnQgYm90aCB0aGUgb2xkIHZlcnNpb24gYW5kIHRoZSBuZXcgdmVyc2lvbi4NCg0KQXMg
QmFsYXpzIGFza2VkLCBob3cgY2FuIHRoZSBkYXRhIG5vZGUgYmUgYSBib29sZWFuIGFuZCBhbiBp
bnRlZ2VyIGF0IHRoZSBzYW1lIHRpbWU/DQpUaGVyZSBzZWVtIHRvIGJlIHBsZW50eSBvZiBzY2Vu
YXJpb3MgdGhhdCBjYW5ub3QgYmUgaW1wbGVtZW50ZWQgc2ltdWx0YW5lb3VzbHkgYnkgYSBzZXJ2
ZXIuDQo8UlI+IENvcnJlY3QsIGJ1dCBzb21lIHNjZW5hcmlvcyBjYW4gYmUgaW1wbGVtZW50ZWQu
IElNTyB3ZSBzaG91bGQgZG9jdW1lbnQgdGhlIHR5cGUgb2YgY2hhbmdlcyB3aGVyZSB0aGlzIHdv
dWxkIG9yIHdvdWxkIG5vdCB3b3JrLg0KDQpSZWdhcmRzLA0KUmVzaGFkLg0KPHNuaXA+DQoNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHls
ZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz
b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3
aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5
Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw
dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv
cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl
IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy
NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh
cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+
DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n
PSJFTi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj
dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6
c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr
Ij5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs
YWNrIj5uZXRtb2QgJmx0O25ldG1vZC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2Yg
J0FuZHkgQmllcm1hbicgJmx0O2FuZHlAeXVtYXdvcmtzLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8
L2I+RnJpZGF5LCBOb3ZlbWJlciA5LCAyMDE4IGF0IDY6MzggUE08YnI+DQo8Yj5UbzogPC9iPkp1
ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5
LmRlJmd0OywgTWFydGluIEJqb3JrbHVuZCAmbHQ7bWJqQHRhaWwtZi5jb20mZ3Q7LCAnQW5keSBC
aWVybWFuJyAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0OywgTmV0TW9kIFdHICZsdDtuZXRtb2RA
aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbbmV0bW9kXSBOZXcgVmVyc2lv
biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXZlcmR0LW5ldG1vZC15YW5nLXZlcnNpb25pbmctcmVx
cy0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpw
PjwvYT48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1i
b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h
aWxPcmlnaW5hbEJvZHkiPk9uIEZyaSwgTm92IDksIDIwMTggYXQgMTI6MTUgQU0sIEp1ZXJnZW4g
U2Nob2Vud2FlbGRlciAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpqLnNjaG9lbndhZWxkZXJA
amFjb2JzLXVuaXZlcnNpdHkuZGUiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0ibXNvLWJv
b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5qLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNp
dHkuZGU8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+
PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4m
Z3Q7DQogd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt
IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9Im1z
by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+T24gVGh1LCBOb3YgMDgsIDIwMTggYXQgMTA6
NDI6MjBQTSAmIzQzOzAxMDAsIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6PGJyPg0KJmd0OyBKdWVy
Z2VuIFNjaG9lbndhZWxkZXIgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86ai5zY2hvZW53YWVs
ZGVyQGphY29icy11bml2ZXJzaXR5LmRlIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls
T3JpZ2luYWxCb2R5Ij5qLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU8L3NwYW4+
PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48
c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij4mZ3Q7DQogd3JvdGU6
PGJyPg0KJmd0OyAmZ3Q7IE9uIFNhdCwgT2N0IDI3LCAyMDE4IGF0IDA2OjUwOjU4QU0gLTA3MDAs
IEFuZHkgQmllcm1hbiB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyBUaGlzIGlzIHdoYXQgd2UgaGF2ZSB0b2RheSBvbmx5IGlmIG1vZHVsZXMgYXJlIHVwZGF0
ZWQgaW4gbGVnYWwgd2F5cy48YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGUgMy4xIHJlcXVpcmVtZW50
IHNheXMgdGhpcyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzIG1haW50YWluZWQgZXZlbjxicj4N
CiZndDsgJmd0OyAmZ3Q7IGlmIHRoZSBtb2R1bGUgaXMgdXBkYXRlZCBpbiB2aW9sYXRpb24gb2Yg
dGhlIG1vZHVsZSB1cGRhdGUgcnVsZXMuPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn
dDsgPGJyPg0KJmd0OyAmZ3Q7IEl0IGlzIHN0YXRpbmcgYSByZXF1aXJlbWVudC4gSG93IHNvbHV0
aW9ucyBtZWV0IHRoZSByZXF1aXJlbWVudCBpcyBmb3I8YnI+DQomZ3Q7ICZndDsgdGhlIHNvbHV0
aW9ucyB0byBmaWd1cmUgb3V0Ljxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBI
b3cgd291bGQgMy4xIGJlIG1ldCBpZiB0aGUgV0cgZGVjaWRlZCB0byBqdXN0IGFkZCBhIG5ldyAn
ZGF0YXN0b3JlJzxicj4NCiZndDsgJmd0OyAmZ3Q7IGtleSBsZWFmIHRvIHRoZSAvbW9kdWxlcy1z
dGF0ZS9tb2R1bGUgbGlzdD88YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IERlcGVuZHMg
b24gdGhlIHNvbHV0aW9uIEkgZ3Vlc3MuPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7IDxicj4NCiZndDsg
Jmd0OyAmZ3Q7IElNTyB0aGUgY3VycmVudCAmcXVvdDtkZXByZWNhdGUgYW5kIHN0YXJ0IG92ZXIm
cXVvdDsgaXMgYWN0dWFsbHkgdGhlIGVhc2llc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyBhbmQgbW9z
dCByb2J1c3Qgc29sdXRpb24gcGF0aCwgYW5kIGl0IHJlcXVpcmVzIG5vIGNoYW5nZXMgdG8gWUFO
RyBvcjxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoZSBwcm90b2NvbHMuPGJyPg0KJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyBZZXAuIEJ1dCB0aGVyZSBhcmUgcGVvcGxlIHdobyB0aGluayB0aGF0IG90
aGVyIHNvbHV0aW9ucyBjYW4gZG88YnI+DQomZ3Q7ICZndDsgYmV0dGVyLiBUaGUgY2hhbGxlbmdl
IGlzIHRvIGZpbmQgb3V0IHdoZXRoZXIgdGhleSBhY3R1YWxseSBkbyBiZXR0ZXI8YnI+DQomZ3Q7
ICZndDsgb3IgZm9yIHdob20gdGhleSBkbyBiZXR0ZXIgKGFuZCBpZiBzb21lb25lIGhhcyB0byBw
YXkgYSBwcmljZSBmb3IgaXQpLjxicj4NCiZndDsgJmd0OyBGb3IgaGF2aW5nIHRoaXMgZGlzY3Vz
c2lvbnMsIGl0IGlzIGdvb2QgdG8gd3JpdGUgZG93biByZXF1aXJlbWVudHMuPGJyPg0KJmd0OyAm
Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
My4yJm5ic3A7IFRoZSBzb2x1dGlvbiBNVVNUIHByb3ZpZGUgYSBtZWNoYW5pc20gdG8gYWxsb3cg
c2VydmVycyB0bzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzaW11bHRhbmVvdXNseSBzdXBwb3J0IGNsaWVudHMg
dXNpbmcgZGlmZmVyZW50IHJldmlzaW9ucyBvZjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDttb2R1bGVzLiZuYnNw
OyBBIGNsaWVudCdzIGNob2ljZSBvZiBwYXJ0aWN1bGFyIHJldmlzaW9uIG9mIG9uZSBvcjxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDttb3JlIG1vZHVsZXMgbWF5IHJlc3RyaWN0IHRoZSBwYXJ0aWN1bGFyIHJldmlz
aW9uIG9mIG90aGVyPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO21vZHVsZXMgdGhhdCBtYXkgYmUgdXNlZCBpbiB0
aGUgc2FtZSByZXF1ZXN0IG9yIHNlc3Npb24uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgVG9kYXksIHRoZSB2ZXJzaW9uIG51bWJlciBpcyBlZmZlY3Rp
dmVseSBhbiAoaW1wbGljaXQpIHBhcnQgb2YgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBt
b2R1bGUgbmFtZSAocGx1cyB0aGUgcmV2aXNpb24gZGF0ZSBmb3IgYmFja3dhcmRzIGNvbXBhdGli
bGUgY2hhbmdlcykuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBIZW5jZSwgbXkgdW5kZXJzdGFu
ZGluZyBpcyB0aGF0IHRvZGF5J3MgbW9kZWwgZG9lcyBzYXRpc2Z5IDMuMiBhczxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsgd2VsbC48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyBUaGlzIGlzIG5vdCB3aGF0IHdlIGhhdmUgYXQgYWxsLiBSRkMgNzk1MCBzYXlzIGEgc2Vy
dmVyIGNhbiBvbmx5IGltcGxlbWVudDxicj4NCiZndDsgJmd0OyAmZ3Q7IG9uZSByZXZpc2lvbiBv
ZiBhIG1vZHVsZS48YnI+DQomZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7
ICZndDsgQSBuZXcgdmVyc2lvbiB0b2RheSBlc3NlbnRpYWxseSBtZWFucyBhIG5ldyBtb2R1bGUg
bmFtZSBhbmQgSSBkbyBub3Q8YnI+DQomZ3Q7ICZndDsgc2VlIGEgY29uZmxpY3Qgd2l0aCB3aGF0
IEkgd3JvdGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZW4gSSB0aGluayB0aGlzIHJlcXVpcmVt
ZW50IG5lZWRzIGNsYXJpZmljYXRpb24uJm5ic3A7IEl0IHNheXMgJnF1b3Q7ZGlmZmVyZW50PGJy
Pg0KJmd0OyByZXZpc2lvbiBvZiBtb2R1bGVzJnF1b3Q7LCB3aGljaCBjYW4gYmUgaW50ZXJwcmV0
ZWQgYXMgZGlmZmVyZW50IHJldmlzaW9uczxicj4NCiZndDsgb2YgKnRoZSBzYW1lKiBtb2R1bGUu
PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFsc28gdGhlIHNlY29uZCBwYXJ0IG9mIHRoZSBwYXJhZ3Jh
cGggc2VlbXMgdG8gaW5kaWNhdGUgbXVsdGlwbGU8YnI+DQomZ3Q7IHJldmlzaW9ucyBvZiB0aGUg
c2FtZSBtb2R1bGUgaW4gdGhlIHNlcnZlci48YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBkbyBub3Qg
YWdyZWUgd2l0aCB0aGlzIHJlcXVpcmVtZW50Ljxicj4NCjxicj4NClRvZGF5LCB5b3UgbmVlZCB0
byBjcmVhdGUgYSBuZXcgbW9kdWxlIGlmIHlvdSBtYWtlIE5CQyBjaGFuZ2VzIHRvPGJyPg0KZXhp
c3RpbmcgY2hhbmdlcyAoZS5nLiwgeW91IGNoYW5nZSBCb29sIHRvIEludCB7MC4uMX0gYW5kIHlv
dSBhcmUgbm90PGJyPg0KY3JlYXRpbmcgYSBuZXcgbGVhZikuIFNpbmNlIHRoZXJlIGFyZSBub3cg
dHdvIG1vZHVsZXMsIHlvdSBfY2FuXzxicj4NCmltcGxlbWVudCBib3RoIG1vZHVsZXMgaWYgdGhh
dCBtYWtlcyBzZW5zZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y
aWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp
bmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs
Qm9keSI+VGhpcyBkb2VzIG5vdCBtYWtlIHNlbnNlIGJlY2F1c2UgYSBub2RlIGluIFlBTkcgaXMg
aWRlbnRpZmllZCBieSBhIFFOYW1lLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP
cmlnaW5hbEJvZHkiPm5vdCBqdXN0IGEgbG9jYWwtbmFtZS4gJm5ic3A7IFRoZSBub2RlIG9sZG1v
ZDpmb28gaXMgbm90IHRoZSBzYW1lIGFzIG5ld21vZDpmb28uPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1i
b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+SXQgbmV2ZXIgaGFzIGJlZW4gYW5kIG5ldmVyIHdp
bGwgYmUgdGhlIHNhbWUgbm9kZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3Jp
Z2luYWxCb2R5Ij4mbHQ7UlImZ3Q7IEkgZGlzYWdyZWUsIHBlcg0KPC9zcGFuPjxhIGhyZWY9Imh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3OTUwI3NlY3Rpb24tNC4yLjEiPjxzcGFuIHN0
eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9yZmM3OTUwI3NlY3Rpb24tNC4yLjE8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29r
bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2tt
YXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEEgc2VydmVyIG1heSBpbXBsZW1lbnQg
YSBudW1iZXIgb2YgbW9kdWxlcywgYWxsb3dpbmcgbXVsdGlwbGUgdmlld3M8bzpwPjwvbzpwPjwv
c3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1i
b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZu
YnNwOyBvZiB0aGUgc2FtZSBkYXRhIG9yIG11bHRpcGxlIHZpZXdzIG9mIGRpc2pvaW50IHN1YnNl
Y3Rpb25zIG9mIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx
dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHNlcnZlcidzIGRhdGEuJm5ic3A7IEFsdGVy
bmF0aXZlbHksIHRoZSBzZXJ2ZXIgbWF5IGltcGxlbWVudCBvbmx5IG9uZTxvOnA+PC9vOnA+PC9z
cGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJv
b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i
c3A7IG1vZHVsZSB0aGF0IGRlZmluZXMgYWxsIGF2YWlsYWJsZSBkYXRhLjwvc3Bhbj48L3NwYW4+
PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy
azpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf
TWFpbE9yaWdpbmFsQm9keSI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx
LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y
aWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu
MHB0Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5JZiB3ZSBh
bGxvdyB0byBtYWtlIHN1Y2ggY2hhbmdlcyBhcyBwYXJ0IG9mIGEgbW9kdWxlIHJldmlzaW9uLCBp
LmUuLDxicj4NCndpdGhvdXQgY3JlYXRpbmcgYSBuZXcgbW9kdWxlLCBJIHRoaW5rIHdlIHNob3Vs
ZCBub3QgbG9vc2UgdGhlIGFiaWxpdHk8YnI+DQp0byBpbXBsZW1lbnQgYm90aCB0aGUgb2xkIHZl
cnNpb24gYW5kIHRoZSBuZXcgdmVyc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr
cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r
bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy
azpfTWFpbE9yaWdpbmFsQm9keSI+QXMgQmFsYXpzIGFza2VkLCBob3cgY2FuIHRoZSBkYXRhIG5v
ZGUgYmUgYSBib29sZWFuIGFuZCBhbiBpbnRlZ2VyIGF0IHRoZSBzYW1lIHRpbWU/PG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+VGhlcmUgc2VlbSB0byBiZSBw
bGVudHkgb2Ygc2NlbmFyaW9zIHRoYXQgY2Fubm90IGJlIGltcGxlbWVudGVkIHNpbXVsdGFuZW91
c2x5IGJ5IGEgc2VydmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h
bEJvZHkiPiZsdDtSUiZndDsgQ29ycmVjdCwgYnV0IHNvbWUgc2NlbmFyaW9zIGNhbiBiZSBpbXBs
ZW1lbnRlZC4gSU1PIHdlIHNob3VsZCBkb2N1bWVudCB0aGUgdHlwZSBvZiBjaGFuZ2VzIHdoZXJl
IHRoaXMgd291bGQgb3Igd291bGQgbm90IHdvcmsuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu
YWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5SZWdhcmRzLDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt
c28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPlJlc2hhZC48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls
T3JpZ2luYWxCb2R5Ij4mbHQ7c25pcCZndDs8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy
azpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxP
cmlnaW5hbEJvZHkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_6A766C1092D0465EA3D9FB54086E2510ciscocom_--


From nobody Fri Nov  9 06:07: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 BD704130DFF for ; Fri,  9 Nov 2018 06:07:32 -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 vUm-frq8YHxf for ; Fri,  9 Nov 2018 06:07:30 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B9CC1277C8 for ; Fri,  9 Nov 2018 06:07:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8442; q=dns/txt; s=iport; t=1541772450; x=1542982050; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pKX2Hotu590m2hcbRqsWEwRBzFAnTzigsErDN/eC0OE=; b=VfUClNrqCyOkZH21SfJiuH0lwOoGZCGysKgVgNjn+wGSI0Uiq9KiKrm7 42OdiLKSuR92iXGEwDZ5NflMirDL5eCAnrTEm3rPkUBX9yLKQAKzqK4sq JQo4bEDktf8fP6j9Th83XwxoPIDraIj7BXWMlbZ+nrLNwvY9WEzxeo7ur U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAA+k+Vb/5BdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggOBaCcKg26IGIt6gg2XMhSBZgsBAYR?= =?us-ascii?q?sAheDCyI0DQ0BAwEBAgEBAm0ohToBAQEBAgEjETgKAQIFCwIBCA4CCAICJgI?= =?us-ascii?q?CAjAVEAIEDgUbgwaBeginUoEuiiGBC4pxF4FBP4ERJx+BTn6EZgIWFyOCSjG?= =?us-ascii?q?CJgKJPYVFkEoJApEXGIFXjxeJVo10AhEUgSYdOIFVcBU7KgGCQYInFxKOCkE?= =?us-ascii?q?xi3KBHwEB?=
X-IronPort-AV: E=Sophos;i="5.54,483,1534809600"; d="scan'208";a="198976870"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2018 14:07:29 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id wA9E7Tx3028677 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Nov 2018 14:07:29 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; Fri, 9 Nov 2018 08:07:28 -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; Fri, 9 Nov 2018 08:07:28 -0600
From: "Reshad Rahman (rrahman)" 
To: Martin Bjorklund 
CC: "j.schoenwaelder@jacobs-university.de" , "netmod@ietf.org" 
Thread-Topic: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
Thread-Index: AQHUbQzN26pBXqFS9Uuo4XPBFQXcdaUxl7WAgAB13oCAAGvkAIAACa0AgACW4gCAAFffAIAAe8KAgBL0rgCAALEIgIAAWdaA//+ulYCAAFU5AP//sL2A
Date: Fri, 9 Nov 2018 14:07:28 +0000
Message-ID: 
References: <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de> <20181109.143729.1869485019013831956.mbj@tail-f.com> <44622200-AB28-4826-9CEC-8A17264E033A@cisco.com> <20181109.145106.380003384922236577.mbj@tail-f.com>
In-Reply-To: <20181109.145106.380003384922236577.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.86.241.214]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2018 14:07:33 -0000

DQrvu79PbiAyMDE4LTExLTA5LCA4OjUxIFBNLCAiTWFydGluIEJqb3JrbHVuZCIgPG1iakB0YWls
LWYuY29tPiB3cm90ZToNCg0KICAgICJSZXNoYWQgUmFobWFuIChycmFobWFuKSIgPHJyYWhtYW5A
Y2lzY28uY29tPiB3cm90ZToNCiAgICA+IA0KICAgID4gDQogICAgPiBPbiAyMDE4LTExLTA5LCA4
OjM3IFBNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBNYXJ0aW4gQmpvcmtsdW5kIg0KICAgID4gPG5l
dG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtYmpAdGFpbC1mLmNvbT4gd3JvdGU6
DQogICAgPiANCiAgICA+ICAgICBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRl
ckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQogICAgPiAgICAgPiBPbiBUaHUsIE5vdiAw
OCwgMjAxOCBhdCAxMDo0MjoyMFBNICswMTAwLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KICAg
ID4gICAgID4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMt
dW5pdmVyc2l0eS5kZT4gd3JvdGU6DQogICAgPiAgICAgPiA+ID4gT24gU2F0LCBPY3QgMjcsIDIw
MTggYXQgMDY6NTA6NThBTSAtMDcwMCwgQW5keSBCaWVybWFuIHdyb3RlOg0KICAgID4gICAgID4g
PiA+ID4gDQogICAgPiAgICAgPiA+ID4gPiBUaGlzIGlzIHdoYXQgd2UgaGF2ZSB0b2RheSBvbmx5
IGlmIG1vZHVsZXMgYXJlIHVwZGF0ZWQgaW4gbGVnYWwNCiAgICA+ICAgICA+ID4gPiA+IHdheXMu
DQogICAgPiAgICAgPiA+ID4gPiBUaGUgMy4xIHJlcXVpcmVtZW50IHNheXMgdGhpcyBiYWNrd2Fy
ZCBjb21wYXRpYmlsaXR5IGlzIG1haW50YWluZWQNCiAgICA+ICAgICA+ID4gPiA+IGV2ZW4NCiAg
ICA+ICAgICA+ID4gPiA+IGlmIHRoZSBtb2R1bGUgaXMgdXBkYXRlZCBpbiB2aW9sYXRpb24gb2Yg
dGhlIG1vZHVsZSB1cGRhdGUgcnVsZXMuDQogICAgPiAgICAgPiA+ID4gPg0KICAgID4gICAgID4g
PiA+IA0KICAgID4gICAgID4gPiA+IEl0IGlzIHN0YXRpbmcgYSByZXF1aXJlbWVudC4gSG93IHNv
bHV0aW9ucyBtZWV0IHRoZSByZXF1aXJlbWVudCBpcw0KICAgID4gICAgID4gPiA+IGZvcg0KICAg
ID4gICAgID4gPiA+IHRoZSBzb2x1dGlvbnMgdG8gZmlndXJlIG91dC4NCiAgICA+ICAgICA+ID4g
PiANCiAgICA+ICAgICA+ID4gPiA+IEhvdyB3b3VsZCAzLjEgYmUgbWV0IGlmIHRoZSBXRyBkZWNp
ZGVkIHRvIGp1c3QgYWRkIGEgbmV3DQogICAgPiAgICAgPiA+ID4gPiAnZGF0YXN0b3JlJw0KICAg
ID4gICAgID4gPiA+ID4ga2V5IGxlYWYgdG8gdGhlIC9tb2R1bGVzLXN0YXRlL21vZHVsZSBsaXN0
Pw0KICAgID4gICAgID4gPiA+IA0KICAgID4gICAgID4gPiA+IERlcGVuZHMgb24gdGhlIHNvbHV0
aW9uIEkgZ3Vlc3MuDQogICAgPiAgICAgPiA+ID4gIA0KICAgID4gICAgID4gPiA+ID4gSU1PIHRo
ZSBjdXJyZW50ICJkZXByZWNhdGUgYW5kIHN0YXJ0IG92ZXIiIGlzIGFjdHVhbGx5IHRoZSBlYXNp
ZXN0DQogICAgPiAgICAgPiA+ID4gPiBhbmQgbW9zdCByb2J1c3Qgc29sdXRpb24gcGF0aCwgYW5k
IGl0IHJlcXVpcmVzIG5vIGNoYW5nZXMgdG8gWUFORw0KICAgID4gICAgID4gPiA+ID4gb3INCiAg
ICA+ICAgICA+ID4gPiA+IHRoZSBwcm90b2NvbHMuDQogICAgPiAgICAgPiA+ID4gDQogICAgPiAg
ICAgPiA+ID4gWWVwLiBCdXQgdGhlcmUgYXJlIHBlb3BsZSB3aG8gdGhpbmsgdGhhdCBvdGhlciBz
b2x1dGlvbnMgY2FuIGRvDQogICAgPiAgICAgPiA+ID4gYmV0dGVyLiBUaGUgY2hhbGxlbmdlIGlz
IHRvIGZpbmQgb3V0IHdoZXRoZXIgdGhleSBhY3R1YWxseSBkbyBiZXR0ZXINCiAgICA+ICAgICA+
ID4gPiBvciBmb3Igd2hvbSB0aGV5IGRvIGJldHRlciAoYW5kIGlmIHNvbWVvbmUgaGFzIHRvIHBh
eSBhIHByaWNlIGZvcg0KICAgID4gICAgID4gPiA+IGl0KS4NCiAgICA+ICAgICA+ID4gPiBGb3Ig
aGF2aW5nIHRoaXMgZGlzY3Vzc2lvbnMsIGl0IGlzIGdvb2QgdG8gd3JpdGUgZG93biByZXF1aXJl
bWVudHMuDQogICAgPiAgICAgPiA+ID4gDQogICAgPiAgICAgPiA+ID4gPiA+ICAgICAgICAzLjIg
VGhlIHNvbHV0aW9uIE1VU1QgcHJvdmlkZSBhIG1lY2hhbmlzbSB0byBhbGxvdyBzZXJ2ZXJzDQog
ICAgPiAgICAgPiA+ID4gPiA+ICAgICAgICB0bw0KICAgID4gICAgID4gPiA+ID4gPiAgICAgICAg
ICAgICBzaW11bHRhbmVvdXNseSBzdXBwb3J0IGNsaWVudHMgdXNpbmcgZGlmZmVyZW50DQogICAg
PiAgICAgPiA+ID4gPiA+ICAgICAgICAgICAgIHJldmlzaW9ucyBvZg0KICAgID4gICAgID4gPiA+
ID4gPiAgICAgICAgICAgICBtb2R1bGVzLiAgQSBjbGllbnQncyBjaG9pY2Ugb2YgcGFydGljdWxh
ciByZXZpc2lvbiBvZg0KICAgID4gICAgID4gPiA+ID4gPiAgICAgICAgICAgICBvbmUgb3INCiAg
ICA+ICAgICA+ID4gPiA+ID4gICAgICAgICAgICAgbW9yZSBtb2R1bGVzIG1heSByZXN0cmljdCB0
aGUgcGFydGljdWxhciByZXZpc2lvbiBvZg0KICAgID4gICAgID4gPiA+ID4gPiAgICAgICAgICAg
ICBvdGhlcg0KICAgID4gICAgID4gPiA+ID4gPiAgICAgICAgICAgICBtb2R1bGVzIHRoYXQgbWF5
IGJlIHVzZWQgaW4gdGhlIHNhbWUgcmVxdWVzdCBvcg0KICAgID4gICAgID4gPiA+ID4gPiAgICAg
ICAgICAgICBzZXNzaW9uLg0KICAgID4gICAgID4gPiA+ID4gPg0KICAgID4gICAgID4gPiA+ID4g
PiBUb2RheSwgdGhlIHZlcnNpb24gbnVtYmVyIGlzIGVmZmVjdGl2ZWx5IGFuIChpbXBsaWNpdCkg
cGFydCBvZg0KICAgID4gICAgID4gPiA+ID4gPiB0aGUNCiAgICA+ICAgICA+ID4gPiA+ID4gbW9k
dWxlIG5hbWUgKHBsdXMgdGhlIHJldmlzaW9uIGRhdGUgZm9yIGJhY2t3YXJkcyBjb21wYXRpYmxl
DQogICAgPiAgICAgPiA+ID4gPiA+IGNoYW5nZXMpLg0KICAgID4gICAgID4gPiA+ID4gPiBIZW5j
ZSwgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRvZGF5J3MgbW9kZWwgZG9lcyBzYXRpc2Z5IDMu
MiBhcw0KICAgID4gICAgID4gPiA+ID4gPiB3ZWxsLg0KICAgID4gICAgID4gPiA+ID4gDQogICAg
PiAgICAgPiA+ID4gPiBUaGlzIGlzIG5vdCB3aGF0IHdlIGhhdmUgYXQgYWxsLiBSRkMgNzk1MCBz
YXlzIGEgc2VydmVyIGNhbiBvbmx5DQogICAgPiAgICAgPiA+ID4gPiBpbXBsZW1lbnQNCiAgICA+
ICAgICA+ID4gPiA+IG9uZSByZXZpc2lvbiBvZiBhIG1vZHVsZS4NCiAgICA+ICAgICA+ID4gPiA+
DQogICAgPiAgICAgPiA+ID4gDQogICAgPiAgICAgPiA+ID4gQSBuZXcgdmVyc2lvbiB0b2RheSBl
c3NlbnRpYWxseSBtZWFucyBhIG5ldyBtb2R1bGUgbmFtZSBhbmQgSSBkbyBub3QNCiAgICA+ICAg
ICA+ID4gPiBzZWUgYSBjb25mbGljdCB3aXRoIHdoYXQgSSB3cm90ZS4NCiAgICA+ICAgICA+ID4g
DQogICAgPiAgICAgPiA+IFRoZW4gSSB0aGluayB0aGlzIHJlcXVpcmVtZW50IG5lZWRzIGNsYXJp
ZmljYXRpb24uICBJdCBzYXlzICJkaWZmZXJlbnQNCiAgICA+ICAgICA+ID4gcmV2aXNpb24gb2Yg
bW9kdWxlcyIsIHdoaWNoIGNhbiBiZSBpbnRlcnByZXRlZCBhcyBkaWZmZXJlbnQgcmV2aXNpb25z
DQogICAgPiAgICAgPiA+IG9mICp0aGUgc2FtZSogbW9kdWxlLg0KICAgID4gICAgID4gPiANCiAg
ICA+ICAgICA+ID4gQWxzbyB0aGUgc2Vjb25kIHBhcnQgb2YgdGhlIHBhcmFncmFwaCBzZWVtcyB0
byBpbmRpY2F0ZSBtdWx0aXBsZQ0KICAgID4gICAgID4gPiByZXZpc2lvbnMgb2YgdGhlIHNhbWUg
bW9kdWxlIGluIHRoZSBzZXJ2ZXIuDQogICAgPiAgICAgPiA+IA0KICAgID4gICAgID4gPiBJIGRv
IG5vdCBhZ3JlZSB3aXRoIHRoaXMgcmVxdWlyZW1lbnQuDQogICAgPiAgICAgPiANCiAgICA+ICAg
ICA+IFRvZGF5LCB5b3UgbmVlZCB0byBjcmVhdGUgYSBuZXcgbW9kdWxlIGlmIHlvdSBtYWtlIE5C
QyBjaGFuZ2VzIHRvDQogICAgPiAgICAgPiBleGlzdGluZyBjaGFuZ2VzIChlLmcuLCB5b3UgY2hh
bmdlIEJvb2wgdG8gSW50IHswLi4xfSBhbmQgeW91IGFyZSBub3QNCiAgICA+ICAgICA+IGNyZWF0
aW5nIGEgbmV3IGxlYWYpLiBTaW5jZSB0aGVyZSBhcmUgbm93IHR3byBtb2R1bGVzLCB5b3UgX2Nh
bl8NCiAgICA+ICAgICA+IGltcGxlbWVudCBib3RoIG1vZHVsZXMgaWYgdGhhdCBtYWtlcyBzZW5z
ZS4NCiAgICA+ICAgICANCiAgICA+ICAgICBZZXMuDQogICAgPiAgICAgDQogICAgPiAgICAgPiBJ
ZiB3ZSBhbGxvdyB0byBtYWtlIHN1Y2ggY2hhbmdlcyBhcyBwYXJ0IG9mIGEgbW9kdWxlIHJldmlz
aW9uLCBpLmUuLA0KICAgID4gICAgID4gd2l0aG91dCBjcmVhdGluZyBhIG5ldyBtb2R1bGUsIEkg
dGhpbmsgd2Ugc2hvdWxkIG5vdCBsb29zZSB0aGUgYWJpbGl0eQ0KICAgID4gICAgID4gdG8gaW1w
bGVtZW50IGJvdGggdGhlIG9sZCB2ZXJzaW9uIGFuZCB0aGUgbmV3IHZlcnNpb24uDQogICAgPiAg
ICAgDQogICAgPiAgICAgSSBkb24ndCB0aGluayB3ZSBzaG91bGQgYWxsb3cgc3VjaCBjaGFuZ2Vz
LCBhbmQgaWYgd2UgZGlkLCBJIGRvbid0DQogICAgPiAgICAgdGhpbmsgdGhhdCBib3RoIHJldmlz
aW9ucyBzaG91bGQgYmUgaW1wbGVtZW50ZWQgYXQgdGhlIHNhbWUgdGltZS4gIEkNCiAgICA+ICAg
ICB0aGluayB0aGUgb3ZlcmFsbCBzb2x1dGlvbiB3b3VsZCBqdXN0IGJlIHRvbyBjb21wbGV4Lg0K
ICAgID4gICAgIA0KICAgID4gICAgID4gSSB0aGluayB3ZSBuZWVkIHRvIGRpc3Rpbmd1aXNoIGJl
dHdlZW4gdGhlIGFncmVlbWVudCBvbiB0aGUNCiAgICA+ICAgICA+IHJlcXVpcmVtZW50LCBuYW1l
bHkgdGhhdCBhIHNlcnZlciBzaG91bGQgYmUgYWJsZSB0byBwcm92aWRlIHN1cHBvcnQNCiAgICA+
ICAgICA+IGZvciBhbiBvbGQgYW5kIGEgbmV3IGRlZmluaXRpb24sIGFuZCBhZ3JlZW1lbnQgb24g
dGhlIHNvbHV0aW9uLg0KICAgID4gICAgID4gDQogICAgPiAgICAgPiBEbyB5b3UgZGlzYWdyZWUg
d2l0aCB0aGUgcmVxdWlyZW1lbnQ/IE9yIGRvIHlvdSBkaXNhZ3JlZSB3aXRoIHRoZQ0KICAgID4g
ICAgID4gY29uc2VxdWVuY2VzIG9mIGltcGxlbWVudGluZyBtdWx0aXBsZSB2ZXJzaW9ucyBvZiB0
aGUgc2FtZSBtb2R1bGUNCiAgICA+ICAgICA+IGZvciBzb21lIG9mIHRoZSBwcm9wb3NlZCBuZXcg
dmVyc2lvbmluZyBzY2hlbWVzPyBPciBib3RoPw0KICAgID4gICAgIA0KICAgID4gICAgIEkgZG8g
bm90IGFncmVlIHdpdGggdGhlIHJlcXVpcmVtZW50IHRoYXQgYSBzZXJ2ZXIgTVVTVCBiZSBhYmxl
IHRvDQogICAgPiAgICAgc3VwcG9ydCBtdWx0aXBsZSByZXZpc2lvbnMgb2YgdGhlIHNhbWUgbW9k
dWxlLCB3aGljaCBpcyBob3cgSQ0KICAgID4gICAgIGludGVycHJldCAzLjIuICBJZiB0aGlzIGlz
IG5vdCB0aGUgaW50ZW50aW9uIG9mIDMuMiwgbWF5YmUgaXQgY2FuIGJlDQogICAgPiAgICAgY2xh
cmlmaWVkLg0KICAgID4gICAgIA0KICAgID4gPFJSPiBJdCBzYXlzICJUaGUgc29sdXRpb24gTVVT
VCBwcm92aWRlLi4uIiwgc28gdGhlIHNvbHV0aW9uIGRyYWZ0DQogICAgPiBNVVNUIHByb3ZpZGUg
YSBzb2x1dGlvbiBvbiBob3cgdG8gZG8gdGhpcy4gV2hldGhlciBhIHNlcnZlciBpbXBsZW1lbnRz
DQogICAgPiB0aGUgc29sdXRpb24gb3Igbm90IGlzIGEgZGlmZmVyZW50IG1hdHRlci4gV2UgcmVh
bGl6ZSB0aGlzIGlzIGEgcGFpbg0KICAgID4gZm9yIG1vc3Qgc2VydmVycyBidXQgc29tZSBzZXJ2
ZXJzIG1heSBiZSBhYmxlIHRvIGRvIGl0Lg0KICAgIA0KICAgIEkgdW5kZXJzdGFuZC4gIEJ1dCBJ
IGRvbid0IGFncmVlIHdpdGggdGhpcyByZXF1aXJlbWVudCwgZXZlbiBpZiBzb21lDQogICAgc2Vy
dmVyIHdvdWxkIGJlIGFibGUgdG8gaW1wbGVtZW50IGl0LiAgSSB0aGluayBpdCBtYWtlcyB0aGUg
d2hvbGUNCiAgICBzb2x1dGlvbiBtdWNoIG1vcmUgY29tcGxleCwgdy9vIG11Y2ggZ2Fpbi4gIEl0
IGlzIGNvbXBsZXggZW5vdWdoIGFzIGl0DQogICAgaXMuDQpJIGFncmVlIHRoYXQgaWRlYWxseSB3
ZSBkb24ndCBuZWVkIHRvIGhhdmUgdGhpcyB0byBzb2x2ZSB0aGUgcHJvYmxlbSwgYnV0IGl0IGlz
IGEgcG90ZW50aWFsIHNvbHV0aW9uLiBJZiBpdCBpcyByZW1vdmVkIGluIHRoZSByZXF1aXJlbWVu
dHMgZHJhZnQgYnV0IGNvbnNpZGVyZWQgaW4gdGhlIHNvbHV0aW9ucyBkcmFmdCwgd291bGQgeW91
IGJlIG9rIHdpdGggdGhhdD8NCg0KUmVnYXJkcywNClJlc2hhZC4NCiAgICANCiAgICAvbWFydGlu
DQogICAgDQoNCg==


From nobody Fri Nov  9 06:24: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 E15B71277C8 for ; Fri,  9 Nov 2018 06:24:52 -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 I4MrQ7HiSCLC for ; Fri,  9 Nov 2018 06:24:51 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBCC130E08 for ; Fri,  9 Nov 2018 06:24:50 -0800 (PST)
Received: from localhost (h-40-120.A165.priv.bahnhof.se [94.254.40.120]) by mail.tail-f.com (Postfix) with ESMTPSA id 100FC1AE0493; Fri,  9 Nov 2018 15:24:49 +0100 (CET)
Date: Fri, 09 Nov 2018 15:24:48 +0100 (CET)
Message-Id: <20181109.152448.2106746182360412729.mbj@tail-f.com>
To: rrahman@cisco.com
Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <44622200-AB28-4826-9CEC-8A17264E033A@cisco.com> <20181109.145106.380003384922236577.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2018 14:24:53 -0000

IlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJhaG1hbkBjaXNjby5jb20+IHdyb3RlOg0KPiAN
Cj4g77u/T24gMjAxOC0xMS0wOSwgODo1MSBQTSwgIk1hcnRpbiBCam9ya2x1bmQiIDxtYmpAdGFp
bC1mLmNvbT4gd3JvdGU6DQo+IA0KPiAgICAgIlJlc2hhZCBSYWhtYW4gKHJyYWhtYW4pIiA8cnJh
aG1hbkBjaXNjby5jb20+IHdyb3RlOg0KPiAgICAgPiANCj4gICAgID4gDQo+ICAgICA+IE9uIDIw
MTgtMTEtMDksIDg6MzcgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIE1hcnRpbiBCam9ya2x1bmQi
DQo+ICAgICA+IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbWJqQHRhaWwt
Zi5jb20+IHdyb3RlOg0KPiAgICAgPiANCj4gICAgID4gICAgIEp1ZXJnZW4gU2Nob2Vud2FlbGRl
ciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4gICAgID4g
ICAgID4gT24gVGh1LCBOb3YgMDgsIDIwMTggYXQgMTA6NDI6MjBQTSArMDEwMCwgTWFydGluIEJq
b3JrbHVuZCB3cm90ZToNCj4gICAgID4gICAgID4gPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGou
c2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4NCj4gICAgID4gICAgID4gPiB3cm90
ZToNCj4gICAgID4gICAgID4gPiA+IE9uIFNhdCwgT2N0IDI3LCAyMDE4IGF0IDA2OjUwOjU4QU0g
LTA3MDAsIEFuZHkgQmllcm1hbiB3cm90ZToNCj4gICAgID4gICAgID4gPiA+ID4gDQo+ICAgICA+
ICAgICA+ID4gPiA+IFRoaXMgaXMgd2hhdCB3ZSBoYXZlIHRvZGF5IG9ubHkgaWYgbW9kdWxlcyBh
cmUgdXBkYXRlZCBpbg0KPiAgICAgPiAgICAgPiA+ID4gPiBsZWdhbA0KPiAgICAgPiAgICAgPiA+
ID4gPiB3YXlzLg0KPiAgICAgPiAgICAgPiA+ID4gPiBUaGUgMy4xIHJlcXVpcmVtZW50IHNheXMg
dGhpcyBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGlzDQo+ICAgICA+ICAgICA+ID4gPiA+IG1haW50
YWluZWQNCj4gICAgID4gICAgID4gPiA+ID4gZXZlbg0KPiAgICAgPiAgICAgPiA+ID4gPiBpZiB0
aGUgbW9kdWxlIGlzIHVwZGF0ZWQgaW4gdmlvbGF0aW9uIG9mIHRoZSBtb2R1bGUgdXBkYXRlDQo+
ICAgICA+ICAgICA+ID4gPiA+IHJ1bGVzLg0KPiAgICAgPiAgICAgPiA+ID4gPg0KPiAgICAgPiAg
ICAgPiA+ID4gDQo+ICAgICA+ICAgICA+ID4gPiBJdCBpcyBzdGF0aW5nIGEgcmVxdWlyZW1lbnQu
IEhvdyBzb2x1dGlvbnMgbWVldCB0aGUgcmVxdWlyZW1lbnQNCj4gICAgID4gICAgID4gPiA+IGlz
DQo+ICAgICA+ICAgICA+ID4gPiBmb3INCj4gICAgID4gICAgID4gPiA+IHRoZSBzb2x1dGlvbnMg
dG8gZmlndXJlIG91dC4NCj4gICAgID4gICAgID4gPiA+IA0KPiAgICAgPiAgICAgPiA+ID4gPiBI
b3cgd291bGQgMy4xIGJlIG1ldCBpZiB0aGUgV0cgZGVjaWRlZCB0byBqdXN0IGFkZCBhIG5ldw0K
PiAgICAgPiAgICAgPiA+ID4gPiAnZGF0YXN0b3JlJw0KPiAgICAgPiAgICAgPiA+ID4gPiBrZXkg
bGVhZiB0byB0aGUgL21vZHVsZXMtc3RhdGUvbW9kdWxlIGxpc3Q/DQo+ICAgICA+ICAgICA+ID4g
PiANCj4gICAgID4gICAgID4gPiA+IERlcGVuZHMgb24gdGhlIHNvbHV0aW9uIEkgZ3Vlc3MuDQo+
ICAgICA+ICAgICA+ID4gPiAgDQo+ICAgICA+ICAgICA+ID4gPiA+IElNTyB0aGUgY3VycmVudCAi
ZGVwcmVjYXRlIGFuZCBzdGFydCBvdmVyIiBpcyBhY3R1YWxseSB0aGUNCj4gICAgID4gICAgID4g
PiA+ID4gZWFzaWVzdA0KPiAgICAgPiAgICAgPiA+ID4gPiBhbmQgbW9zdCByb2J1c3Qgc29sdXRp
b24gcGF0aCwgYW5kIGl0IHJlcXVpcmVzIG5vIGNoYW5nZXMgdG8NCj4gICAgID4gICAgID4gPiA+
ID4gWUFORw0KPiAgICAgPiAgICAgPiA+ID4gPiBvcg0KPiAgICAgPiAgICAgPiA+ID4gPiB0aGUg
cHJvdG9jb2xzLg0KPiAgICAgPiAgICAgPiA+ID4gDQo+ICAgICA+ICAgICA+ID4gPiBZZXAuIEJ1
dCB0aGVyZSBhcmUgcGVvcGxlIHdobyB0aGluayB0aGF0IG90aGVyIHNvbHV0aW9ucyBjYW4gZG8N
Cj4gICAgID4gICAgID4gPiA+IGJldHRlci4gVGhlIGNoYWxsZW5nZSBpcyB0byBmaW5kIG91dCB3
aGV0aGVyIHRoZXkgYWN0dWFsbHkgZG8NCj4gICAgID4gICAgID4gPiA+IGJldHRlcg0KPiAgICAg
PiAgICAgPiA+ID4gb3IgZm9yIHdob20gdGhleSBkbyBiZXR0ZXIgKGFuZCBpZiBzb21lb25lIGhh
cyB0byBwYXkgYSBwcmljZQ0KPiAgICAgPiAgICAgPiA+ID4gZm9yDQo+ICAgICA+ICAgICA+ID4g
PiBpdCkuDQo+ICAgICA+ICAgICA+ID4gPiBGb3IgaGF2aW5nIHRoaXMgZGlzY3Vzc2lvbnMsIGl0
IGlzIGdvb2QgdG8gd3JpdGUgZG93bg0KPiAgICAgPiAgICAgPiA+ID4gcmVxdWlyZW1lbnRzLg0K
PiAgICAgPiAgICAgPiA+ID4gDQo+ICAgICA+ICAgICA+ID4gPiA+ID4gICAgICAgIDMuMiBUaGUg
c29sdXRpb24gTVVTVCBwcm92aWRlIGEgbWVjaGFuaXNtIHRvIGFsbG93DQo+ICAgICA+ICAgICA+
ID4gPiA+ID4gICAgICAgIHNlcnZlcnMNCj4gICAgID4gICAgID4gPiA+ID4gPiAgICAgICAgdG8N
Cj4gICAgID4gICAgID4gPiA+ID4gPiAgICAgICAgICAgICBzaW11bHRhbmVvdXNseSBzdXBwb3J0
IGNsaWVudHMgdXNpbmcgZGlmZmVyZW50DQo+ICAgICA+ICAgICA+ID4gPiA+ID4gICAgICAgICAg
ICAgcmV2aXNpb25zIG9mDQo+ICAgICA+ICAgICA+ID4gPiA+ID4gICAgICAgICAgICAgbW9kdWxl
cy4gIEEgY2xpZW50J3MgY2hvaWNlIG9mIHBhcnRpY3VsYXINCj4gICAgID4gICAgID4gPiA+ID4g
PiAgICAgICAgICAgICByZXZpc2lvbiBvZg0KPiAgICAgPiAgICAgPiA+ID4gPiA+ICAgICAgICAg
ICAgIG9uZSBvcg0KPiAgICAgPiAgICAgPiA+ID4gPiA+ICAgICAgICAgICAgIG1vcmUgbW9kdWxl
cyBtYXkgcmVzdHJpY3QgdGhlIHBhcnRpY3VsYXINCj4gICAgID4gICAgID4gPiA+ID4gPiAgICAg
ICAgICAgICByZXZpc2lvbiBvZg0KPiAgICAgPiAgICAgPiA+ID4gPiA+ICAgICAgICAgICAgIG90
aGVyDQo+ICAgICA+ICAgICA+ID4gPiA+ID4gICAgICAgICAgICAgbW9kdWxlcyB0aGF0IG1heSBi
ZSB1c2VkIGluIHRoZSBzYW1lIHJlcXVlc3Qgb3INCj4gICAgID4gICAgID4gPiA+ID4gPiAgICAg
ICAgICAgICBzZXNzaW9uLg0KPiAgICAgPiAgICAgPiA+ID4gPiA+DQo+ICAgICA+ICAgICA+ID4g
PiA+ID4gVG9kYXksIHRoZSB2ZXJzaW9uIG51bWJlciBpcyBlZmZlY3RpdmVseSBhbiAoaW1wbGlj
aXQpIHBhcnQNCj4gICAgID4gICAgID4gPiA+ID4gPiBvZg0KPiAgICAgPiAgICAgPiA+ID4gPiA+
IHRoZQ0KPiAgICAgPiAgICAgPiA+ID4gPiA+IG1vZHVsZSBuYW1lIChwbHVzIHRoZSByZXZpc2lv
biBkYXRlIGZvciBiYWNrd2FyZHMNCj4gICAgID4gICAgID4gPiA+ID4gPiBjb21wYXRpYmxlDQo+
ICAgICA+ICAgICA+ID4gPiA+ID4gY2hhbmdlcykuDQo+ICAgICA+ICAgICA+ID4gPiA+ID4gSGVu
Y2UsIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0b2RheSdzIG1vZGVsIGRvZXMgc2F0aXNmeQ0K
PiAgICAgPiAgICAgPiA+ID4gPiA+IDMuMiBhcw0KPiAgICAgPiAgICAgPiA+ID4gPiA+IHdlbGwu
DQo+ICAgICA+ICAgICA+ID4gPiA+IA0KPiAgICAgPiAgICAgPiA+ID4gPiBUaGlzIGlzIG5vdCB3
aGF0IHdlIGhhdmUgYXQgYWxsLiBSRkMgNzk1MCBzYXlzIGEgc2VydmVyIGNhbg0KPiAgICAgPiAg
ICAgPiA+ID4gPiBvbmx5DQo+ICAgICA+ICAgICA+ID4gPiA+IGltcGxlbWVudA0KPiAgICAgPiAg
ICAgPiA+ID4gPiBvbmUgcmV2aXNpb24gb2YgYSBtb2R1bGUuDQo+ICAgICA+ICAgICA+ID4gPiA+
DQo+ICAgICA+ICAgICA+ID4gPiANCj4gICAgID4gICAgID4gPiA+IEEgbmV3IHZlcnNpb24gdG9k
YXkgZXNzZW50aWFsbHkgbWVhbnMgYSBuZXcgbW9kdWxlIG5hbWUgYW5kIEkNCj4gICAgID4gICAg
ID4gPiA+IGRvIG5vdA0KPiAgICAgPiAgICAgPiA+ID4gc2VlIGEgY29uZmxpY3Qgd2l0aCB3aGF0
IEkgd3JvdGUuDQo+ICAgICA+ICAgICA+ID4gDQo+ICAgICA+ICAgICA+ID4gVGhlbiBJIHRoaW5r
IHRoaXMgcmVxdWlyZW1lbnQgbmVlZHMgY2xhcmlmaWNhdGlvbi4gIEl0IHNheXMNCj4gICAgID4g
ICAgID4gPiAiZGlmZmVyZW50DQo+ICAgICA+ICAgICA+ID4gcmV2aXNpb24gb2YgbW9kdWxlcyIs
IHdoaWNoIGNhbiBiZSBpbnRlcnByZXRlZCBhcyBkaWZmZXJlbnQNCj4gICAgID4gICAgID4gPiBy
ZXZpc2lvbnMNCj4gICAgID4gICAgID4gPiBvZiAqdGhlIHNhbWUqIG1vZHVsZS4NCj4gICAgID4g
ICAgID4gPiANCj4gICAgID4gICAgID4gPiBBbHNvIHRoZSBzZWNvbmQgcGFydCBvZiB0aGUgcGFy
YWdyYXBoIHNlZW1zIHRvIGluZGljYXRlIG11bHRpcGxlDQo+ICAgICA+ICAgICA+ID4gcmV2aXNp
b25zIG9mIHRoZSBzYW1lIG1vZHVsZSBpbiB0aGUgc2VydmVyLg0KPiAgICAgPiAgICAgPiA+IA0K
PiAgICAgPiAgICAgPiA+IEkgZG8gbm90IGFncmVlIHdpdGggdGhpcyByZXF1aXJlbWVudC4NCj4g
ICAgID4gICAgID4gDQo+ICAgICA+ICAgICA+IFRvZGF5LCB5b3UgbmVlZCB0byBjcmVhdGUgYSBu
ZXcgbW9kdWxlIGlmIHlvdSBtYWtlIE5CQyBjaGFuZ2VzIHRvDQo+ICAgICA+ICAgICA+IGV4aXN0
aW5nIGNoYW5nZXMgKGUuZy4sIHlvdSBjaGFuZ2UgQm9vbCB0byBJbnQgezAuLjF9IGFuZCB5b3Ug
YXJlDQo+ICAgICA+ICAgICA+IG5vdA0KPiAgICAgPiAgICAgPiBjcmVhdGluZyBhIG5ldyBsZWFm
KS4gU2luY2UgdGhlcmUgYXJlIG5vdyB0d28gbW9kdWxlcywgeW91IF9jYW5fDQo+ICAgICA+ICAg
ICA+IGltcGxlbWVudCBib3RoIG1vZHVsZXMgaWYgdGhhdCBtYWtlcyBzZW5zZS4NCj4gICAgID4g
ICAgIA0KPiAgICAgPiAgICAgWWVzLg0KPiAgICAgPiAgICAgDQo+ICAgICA+ICAgICA+IElmIHdl
IGFsbG93IHRvIG1ha2Ugc3VjaCBjaGFuZ2VzIGFzIHBhcnQgb2YgYSBtb2R1bGUgcmV2aXNpb24s
DQo+ICAgICA+ICAgICA+IGkuZS4sDQo+ICAgICA+ICAgICA+IHdpdGhvdXQgY3JlYXRpbmcgYSBu
ZXcgbW9kdWxlLCBJIHRoaW5rIHdlIHNob3VsZCBub3QgbG9vc2UgdGhlDQo+ICAgICA+ICAgICA+
IGFiaWxpdHkNCj4gICAgID4gICAgID4gdG8gaW1wbGVtZW50IGJvdGggdGhlIG9sZCB2ZXJzaW9u
IGFuZCB0aGUgbmV3IHZlcnNpb24uDQo+ICAgICA+ICAgICANCj4gICAgID4gICAgIEkgZG9uJ3Qg
dGhpbmsgd2Ugc2hvdWxkIGFsbG93IHN1Y2ggY2hhbmdlcywgYW5kIGlmIHdlIGRpZCwgSSBkb24n
dA0KPiAgICAgPiAgICAgdGhpbmsgdGhhdCBib3RoIHJldmlzaW9ucyBzaG91bGQgYmUgaW1wbGVt
ZW50ZWQgYXQgdGhlIHNhbWUgdGltZS4gIEkNCj4gICAgID4gICAgIHRoaW5rIHRoZSBvdmVyYWxs
IHNvbHV0aW9uIHdvdWxkIGp1c3QgYmUgdG9vIGNvbXBsZXguDQo+ICAgICA+ICAgICANCj4gICAg
ID4gICAgID4gSSB0aGluayB3ZSBuZWVkIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gdGhlIGFncmVl
bWVudCBvbiB0aGUNCj4gICAgID4gICAgID4gcmVxdWlyZW1lbnQsIG5hbWVseSB0aGF0IGEgc2Vy
dmVyIHNob3VsZCBiZSBhYmxlIHRvIHByb3ZpZGUgc3VwcG9ydA0KPiAgICAgPiAgICAgPiBmb3Ig
YW4gb2xkIGFuZCBhIG5ldyBkZWZpbml0aW9uLCBhbmQgYWdyZWVtZW50IG9uIHRoZSBzb2x1dGlv
bi4NCj4gICAgID4gICAgID4gDQo+ICAgICA+ICAgICA+IERvIHlvdSBkaXNhZ3JlZSB3aXRoIHRo
ZSByZXF1aXJlbWVudD8gT3IgZG8geW91IGRpc2FncmVlIHdpdGggdGhlDQo+ICAgICA+ICAgICA+
IGNvbnNlcXVlbmNlcyBvZiBpbXBsZW1lbnRpbmcgbXVsdGlwbGUgdmVyc2lvbnMgb2YgdGhlIHNh
bWUgbW9kdWxlDQo+ICAgICA+ICAgICA+IGZvciBzb21lIG9mIHRoZSBwcm9wb3NlZCBuZXcgdmVy
c2lvbmluZyBzY2hlbWVzPyBPciBib3RoPw0KPiAgICAgPiAgICAgDQo+ICAgICA+ICAgICBJIGRv
IG5vdCBhZ3JlZSB3aXRoIHRoZSByZXF1aXJlbWVudCB0aGF0IGEgc2VydmVyIE1VU1QgYmUgYWJs
ZSB0bw0KPiAgICAgPiAgICAgc3VwcG9ydCBtdWx0aXBsZSByZXZpc2lvbnMgb2YgdGhlIHNhbWUg
bW9kdWxlLCB3aGljaCBpcyBob3cgSQ0KPiAgICAgPiAgICAgaW50ZXJwcmV0IDMuMi4gIElmIHRo
aXMgaXMgbm90IHRoZSBpbnRlbnRpb24gb2YgMy4yLCBtYXliZSBpdCBjYW4gYmUNCj4gICAgID4g
ICAgIGNsYXJpZmllZC4NCj4gICAgID4gICAgIA0KPiAgICAgPiA8UlI+IEl0IHNheXMgIlRoZSBz
b2x1dGlvbiBNVVNUIHByb3ZpZGUuLi4iLCBzbyB0aGUgc29sdXRpb24gZHJhZnQNCj4gICAgID4g
TVVTVCBwcm92aWRlIGEgc29sdXRpb24gb24gaG93IHRvIGRvIHRoaXMuIFdoZXRoZXIgYSBzZXJ2
ZXIgaW1wbGVtZW50cw0KPiAgICAgPiB0aGUgc29sdXRpb24gb3Igbm90IGlzIGEgZGlmZmVyZW50
IG1hdHRlci4gV2UgcmVhbGl6ZSB0aGlzIGlzIGEgcGFpbg0KPiAgICAgPiBmb3IgbW9zdCBzZXJ2
ZXJzIGJ1dCBzb21lIHNlcnZlcnMgbWF5IGJlIGFibGUgdG8gZG8gaXQuDQo+ICAgICANCj4gICAg
IEkgdW5kZXJzdGFuZC4gIEJ1dCBJIGRvbid0IGFncmVlIHdpdGggdGhpcyByZXF1aXJlbWVudCwg
ZXZlbiBpZiBzb21lDQo+ICAgICBzZXJ2ZXIgd291bGQgYmUgYWJsZSB0byBpbXBsZW1lbnQgaXQu
ICBJIHRoaW5rIGl0IG1ha2VzIHRoZSB3aG9sZQ0KPiAgICAgc29sdXRpb24gbXVjaCBtb3JlIGNv
bXBsZXgsIHcvbyBtdWNoIGdhaW4uICBJdCBpcyBjb21wbGV4IGVub3VnaCBhcyBpdA0KPiAgICAg
aXMuDQo+IEkgYWdyZWUgdGhhdCBpZGVhbGx5IHdlIGRvbid0IG5lZWQgdG8gaGF2ZSB0aGlzIHRv
IHNvbHZlIHRoZSBwcm9ibGVtLA0KPiBidXQgaXQgaXMgYSBwb3RlbnRpYWwgc29sdXRpb24uIElm
IGl0IGlzIHJlbW92ZWQgaW4gdGhlIHJlcXVpcmVtZW50cw0KPiBkcmFmdCBidXQgY29uc2lkZXJl
ZCBpbiB0aGUgc29sdXRpb25zIGRyYWZ0LCB3b3VsZCB5b3UgYmUgb2sgd2l0aA0KPiB0aGF0Pw0K
DQpZZXM7IGl0IHNob3VsZCBiZSBvayBmb3IgYSBzb2x1dGlvbiB0byBzb2x2ZSBtb3JlIHByb2Js
ZW1zIHRoYW4gd2hhdA0KdGhlIHJlcXVpcmVtZW50cyBkb2Mgc3BlY2lmeS4NCg0KDQovbWFydGlu
DQo=


From nobody Fri Nov  9 07:14: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 4E60A130E2D for ; Fri,  9 Nov 2018 07:13:54 -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 boeymN5QUK6T for ; Fri,  9 Nov 2018 07:13:51 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25433130EB8 for ; Fri,  9 Nov 2018 07:13:51 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id BD98DE1F; Fri,  9 Nov 2018 16:13: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 pJOCkE8emoih; Fri,  9 Nov 2018 16:13:48 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri,  9 Nov 2018 16:13:49 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id A736F2003D; Fri,  9 Nov 2018 16:13: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 raEwQMPEvVz1; Fri,  9 Nov 2018 16:13:49 +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 29B4F2003C; Fri,  9 Nov 2018 16:13:49 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Fri, 9 Nov 2018 16:13:48 +0100
Received: by anna.localdomain (Postfix, from userid 501) id E30AD3003CB416; Fri,  9 Nov 2018 16:13:47 +0100 (CET)
Date: Fri, 9 Nov 2018 16:13:47 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
CC: , 
Message-ID: <20181109151347.3xms2cty6hxyl232@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org
References: <20181027211355.ppu7wavjcq2butc4@anna.jacobs.jacobs-university.de> <20181108.224220.1513800936571555652.mbj@tail-f.com> <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de> <20181109.143729.1869485019013831956.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20181109.143729.1869485019013831956.mbj@tail-f.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB02.jacobs.jacobs-university.de (10.70.0.121) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2018 15:14:00 -0000

On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
> 
> > I think we need to distinguish between the agreement on the
> > requirement, namely that a server should be able to provide support
> > for an old and a new definition, and agreement on the solution.
> > 
> > Do you disagree with the requirement? Or do you disagree with the
> > consequences of implementing multiple versions of the same module
> > for some of the proposed new versioning schemes? Or both?
> 
> I do not agree with the requirement that a server MUST be able to
> support multiple revisions of the same module, which is how I
> interpret 3.2.  If this is not the intention of 3.2, maybe it can be
> clarified.
>

Here is what 3.2 says:

       3.2  The solution MUST provide a mechanism to allow servers to
            simultaneously support clients using different revisions of
            modules.  A client's choice of particular revision of one or
            more modules may restrict the particular revision of other
            modules that may be used in the same request or session.

This does _not_ say servers MUST implement this.

Item 3.2 establishes a requirement and for some solutions it may be
easy to satisfy this requirement, for others it may be more costly to
satisfy this requirement.

The whole requirements exercise becomes a rather pointless exercise if
we remove requirements so that certain solutions look more attractive.
I have not seen a proposal that addresses all requirements and hence
at the end the WG needs to decide which tradeoffs make sense.

/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 Nov  9 08:32: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 BCBDD128CF2 for ; Fri,  9 Nov 2018 08:32:04 -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 bbZIzA-NFuMU for ; Fri,  9 Nov 2018 08:32:03 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 206E1128CE4 for ; Fri,  9 Nov 2018 08:32:03 -0800 (PST)
Received: from localhost (h-40-120.A165.priv.bahnhof.se [94.254.40.120]) by mail.tail-f.com (Postfix) with ESMTPSA id 2FF621AE0493; Fri,  9 Nov 2018 17:32:00 +0100 (CET)
Date: Fri, 09 Nov 2018 17:31:59 +0100 (CET)
Message-Id: <20181109.173159.1522007243611164311.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20181109151347.3xms2cty6hxyl232@anna.jacobs.jacobs-university.de>
References: <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de> <20181109.143729.1869485019013831956.mbj@tail-f.com> <20181109151347.3xms2cty6hxyl232@anna.jacobs.jacobs-university.de>
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] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2018 16:32:05 -0000

Juergen Schoenwaelder  wrote:
> On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
> > 
> > > I think we need to distinguish between the agreement on the
> > > requirement, namely that a server should be able to provide support
> > > for an old and a new definition, and agreement on the solution.
> > > 
> > > Do you disagree with the requirement? Or do you disagree with the
> > > consequences of implementing multiple versions of the same module
> > > for some of the proposed new versioning schemes? Or both?
> > 
> > I do not agree with the requirement that a server MUST be able to
> > support multiple revisions of the same module, which is how I
> > interpret 3.2.  If this is not the intention of 3.2, maybe it can be
> > clarified.
> >
> 
> Here is what 3.2 says:
> 
>        3.2  The solution MUST provide a mechanism to allow servers to
>             simultaneously support clients using different revisions of
>             modules.  A client's choice of particular revision of one or
>             more modules may restrict the particular revision of other
>             modules that may be used in the same request or session.
> 
> This does _not_ say servers MUST implement this.
> 
> Item 3.2 establishes a requirement and for some solutions it may be
> easy to satisfy this requirement, for others it may be more costly to
> satisfy this requirement.
> 
> The whole requirements exercise becomes a rather pointless exercise if
> we remove requirements so that certain solutions look more
> attractive.

Ok, but that's not what I wrote.  I don't agree with this requirement
which says that it MUST be possible for a server to support
different revisions of a given module (again, if this is not the
intention of the text, please clarify).  I simply don't think that
this is a good requirement.


/martin


> I have not seen a proposal that addresses all requirements and hence
> at the end the WG needs to decide which tradeoffs make sense.
> 
> /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 Nov  9 08:55: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 E90A7130DFD for ; Fri,  9 Nov 2018 08:55: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, 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 paPoNgaulnGH for ; Fri,  9 Nov 2018 08:55:15 -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 49F01128766 for ; Fri,  9 Nov 2018 08:55:15 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E2C45E15; Fri,  9 Nov 2018 17:55:13 +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 YknLlQ6c_up1; Fri,  9 Nov 2018 17:55:12 +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,  9 Nov 2018 17:55:13 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC12F2003D; Fri,  9 Nov 2018 17:55:13 +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 quHAJlchYyzo; Fri,  9 Nov 2018 17:55:13 +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 4002D2003C; Fri,  9 Nov 2018 17:55:13 +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, 9 Nov 2018 17:55:12 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 9767A3003CBA8E; Fri,  9 Nov 2018 17:55:12 +0100 (CET)
Date: Fri, 9 Nov 2018 17:55:12 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
CC: , 
Message-ID: <20181109165512.6f3hi55mv2kc3qlp@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org
References: <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de> <20181109.143729.1869485019013831956.mbj@tail-f.com> <20181109151347.3xms2cty6hxyl232@anna.jacobs.jacobs-university.de> <20181109.173159.1522007243611164311.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20181109.173159.1522007243611164311.mbj@tail-f.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] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2018 16:55:18 -0000

On Fri, Nov 09, 2018 at 05:31:59PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
> > > 
> > > > I think we need to distinguish between the agreement on the
> > > > requirement, namely that a server should be able to provide support
> > > > for an old and a new definition, and agreement on the solution.
> > > > 
> > > > Do you disagree with the requirement? Or do you disagree with the
> > > > consequences of implementing multiple versions of the same module
> > > > for some of the proposed new versioning schemes? Or both?
> > > 
> > > I do not agree with the requirement that a server MUST be able to
> > > support multiple revisions of the same module, which is how I
> > > interpret 3.2.  If this is not the intention of 3.2, maybe it can be
> > > clarified.
> > >
> > 
> > Here is what 3.2 says:
> > 
> >        3.2  The solution MUST provide a mechanism to allow servers to
> >             simultaneously support clients using different revisions of
> >             modules.  A client's choice of particular revision of one or
> >             more modules may restrict the particular revision of other
> >             modules that may be used in the same request or session.
> > 
> > This does _not_ say servers MUST implement this.
> > 
> > Item 3.2 establishes a requirement and for some solutions it may be
> > easy to satisfy this requirement, for others it may be more costly to
> > satisfy this requirement.
> > 
> > The whole requirements exercise becomes a rather pointless exercise if
> > we remove requirements so that certain solutions look more
> > attractive.
> 
> Ok, but that's not what I wrote.  I don't agree with this requirement
> which says that it MUST be possible for a server to support
> different revisions of a given module (again, if this is not the
> intention of the text, please clarify).  I simply don't think that
> this is a good requirement.
>

I can't follow you or I do not understand what you are after.

  In some versioning schemes, providing support for different
  'versions' is relatively easy. If I have modules foo-1 and foo-2,
  then I can implement foo-1 and foo-2 (or proper workable subsets of
  them) easily. And older clients expecting foo-1 may continue to work
  while newer clients move to foo-2. In other versioning schemes,
  providing the same possibility to migrate from foo version 1 to foo
  version 2, would lead to the support of foo in two different
  versions.

The requirement tries to express that it must be possible to have a
transition path where old clients can continue to function with the
old version while new clients start using the new version. The idea is
to state this as a requirement without making any assumptions about
the solutions.

Are you saying that a requirement saying that there should be a
possibility of a transition path is in general a bad requirement?

/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 Nov  9 10:35: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 53E24130DC0 for ; Fri,  9 Nov 2018 10:35:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lx5vk0s2nxHY for ; Fri,  9 Nov 2018 10:35:23 -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 8CC2B128CF3 for ; Fri,  9 Nov 2018 10:35:23 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id p86so2039182lfg.5 for ; Fri, 09 Nov 2018 10:35:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=RRQvYHiX3py4AGzBZN8bDVxNUFytn/wplAJ14LbjfKI=; b=WCUL+aN+9fbH0Mx7pkuI4gs/qlEj4rloiAfDBkQMQvGBS11ZpzeXDqSppbrtKfv/Rn 2MpZMqNKvaQnrvrDF2Y/OZaX/bwCa+hebo4H/NQwyPACTtA1UmMFE5iqSOgpQIgN64C0 odWF5D9+jOGoivtmDQuYnhFV9eg8H2CE/y4jFHCMYUMCcGV91nzgugy3p7ktbNjDrHd4 azgpBtbubVtV2+d8+dEmhm+4ZcFERTLMzuOkHUMi/rDPMKg/xMbZQl7OwVVjJRTWhAzu WYq5NzF9jHz9LJwo/godFmMHhI6rGnGpJoPT0JmGW5RBXr0O+GbFLHB9o54cfcn1OMNv Zx4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RRQvYHiX3py4AGzBZN8bDVxNUFytn/wplAJ14LbjfKI=; b=s8SF7GqL7TjuukTGR+WFzoRJjAUaZsWlasM+z2ymwdv4ecPBt3bEmeK5h00Uigqmdz 6BSJs6qtzZPfzgNJFJOMfczeZfWuJoUDraZUSAzgGk3PLhL3PgfetO52lhz1oZYxDLEo gjgMADWsAopEYwR1BIFl5jWsNsYa00gXoHn+XrKrkOOwUUfi0gxE0TtqrRN6fOOXf3xk rMJ/FM6JlcigVgXW46F4D7qj4S/0whsBJWs4501dXQQoOfnNtxv+54E3N5id1FH6RzG0 EFFP8pyclUQvg3h1WXpB0/Ph9OJlJFeKFPPf87oUEU1iSObMYfnExW1vOCOZqh037Avc wx2Q==
X-Gm-Message-State: AGRZ1gIXJvxQ1gGmr4Jd7GPL+VOh6t8TnjRWZWfuC3ygXHwAuFrp1DRN AIYvD5LbyrFNa58E0EU+R+c2X42lSvMDOrLq+ERRcSdi
X-Google-Smtp-Source: AJdET5dQGZh7MGex48qmQ0BmKt9VTSVM0cvtAX9u7rpGD7SL4tKCmuNc6ZASp7ddegUqIofNtjogbKqU1ia9dcywyOs=
X-Received: by 2002:a19:6f0a:: with SMTP id k10mr5782303lfc.119.1541788520951;  Fri, 09 Nov 2018 10:35:20 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Fri, 9 Nov 2018 10:35:19 -0800 (PST)
From: Andy Bierman 
Date: Fri, 9 Nov 2018 10:35:19 -0800
Message-ID: 
To: NetMod WG 
Content-Type: multipart/alternative; boundary="0000000000001c4a82057a3f9d5e"
Archived-At: 
Subject: [netmod] missing YANG versioning requirements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2018 18:35:25 -0000

--0000000000001c4a82057a3f9d5e
Content-Type: text/plain; charset="UTF-8"

Hi,

I think the requirements doc should state that

1) there are many more readers, operators, and client developers than
server developers so the solution MUST take into account the numbers
of people affected when finding a balance between client and server
complexity.

2) if existing protocol and YANG solutions exist then they MUST be used
in favor of developing new solutions.


Andy

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


Hi,

I think the requirements doc should=
 state that

1) there are many more readers, operat=
ors, and client developers than
server developers so the solution=
 MUST take into account the numbers
of people affected when findi=
ng a balance between client and server complexity.

2) if existing protocol and YANG solutions exist then they MUST be used
in favor of developing new solutions.


=

Andy



--0000000000001c4a82057a3f9d5e--


From nobody Fri Nov  9 14:46: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 474F412D4E7 for ; Fri,  9 Nov 2018 14:46:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVxHcf8rqH91 for ; Fri,  9 Nov 2018 14:46:09 -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 E5A41129619 for ; Fri,  9 Nov 2018 14:46:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21975; q=dns/txt; s=iport; t=1541803569; x=1543013169; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=t8l+/+32htbkBMM++wjzFnqgz/zHJKSIJLuGHY4OPYQ=; b=Nk3kM4Vyb+gMS1iwS6ox9LbzpFYLJqePXpcH07C+JkmpDbrpTaPStOr4 6Nujy75LsSlugw3i9UJto/DF6a42tobxG2FkL2rd9C3UTDxz5jdort+MB XQeECZxAA5/qeSP0K4DJHsEuy2yAzA9I5UsVTlis9S6NQ0+ent6Ya0bxl 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAD5DOZb/xbLJq1gAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVIDAQEBAQELAYJpgQIng3iId40EJZcygXoNGAEKgxJ?= =?us-ascii?q?xRgKDRjUMDQEDAQECAQECbRwMhToBAQEDAQEBIUsJBwkCCQIQCCcDAgIbDB8?= =?us-ascii?q?RBgEMBgIBAReDBgGBeQgPjC2bUIEuH4UfhGQFBYwOgUE/gREnDIFhfoMbAQG?= =?us-ascii?q?BSzcmgj2CVwKJPYVFkEoJkRMGGIFXh32HGolWh0SGV4FEATaBVTMaCBsVO4J?= =?us-ascii?q?sgXdZg2uEYYU+PwMwjQ8BAQ?=
X-IronPort-AV: E=Sophos;i="5.54,485,1534809600"; d="scan'208,217";a="7879924"
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; 09 Nov 2018 22:46:06 +0000
Received: from [10.61.194.82] ([10.61.194.82]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id wA9Mk5Ii021692; Fri, 9 Nov 2018 22:46:06 GMT
To: Andy Bierman , Juergen Schoenwaelder , Martin Bjorklund , NetMod WG 
References: <20181027083628.tgymddbje3yp2lhy@anna.jacobs.jacobs-university.de>  <20181027211355.ppu7wavjcq2butc4@anna.jacobs.jacobs-university.de> <20181108.224220.1513800936571555652.mbj@tail-f.com> <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de> 
From: Robert Wilton 
Message-ID: <7feb0020-9484-2903-6f38-e45b13ff06a4@cisco.com>
Date: Fri, 9 Nov 2018 22:46:05 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------0C5F85BA11D9321E90CFE45A"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.61.194.82, [10.61.194.82]
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2018 22:46:13 -0000

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



On 09/11/2018 11:38, Andy Bierman wrote:
>
>
> On Fri, Nov 9, 2018 at 12:15 AM, Juergen Schoenwaelder 
>  > wrote:
>
>     On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
>     > Juergen Schoenwaelder      > wrote:
>     > > On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
>     > > >
>     > > > This is what we have today only if modules are updated in
>     legal ways.
>     > > > The 3.1 requirement says this backward compatibility is
>     maintained even
>     > > > if the module is updated in violation of the module update
>     rules.
>     > > >
>     > >
>     > > It is stating a requirement. How solutions meet the
>     requirement is for
>     > > the solutions to figure out.
>     > >
>     > > > How would 3.1 be met if the WG decided to just add a new
>     'datastore'
>     > > > key leaf to the /modules-state/module list?
>     > >
>     > > Depends on the solution I guess.
>     > >
>     > > > IMO the current "deprecate and start over" is actually the
>     easiest
>     > > > and most robust solution path, and it requires no changes to
>     YANG or
>     > > > the protocols.
>     > >
>     > > Yep. But there are people who think that other solutions can do
>     > > better. The challenge is to find out whether they actually do
>     better
>     > > or for whom they do better (and if someone has to pay a price
>     for it).
>     > > For having this discussions, it is good to write down
>     requirements.
>     > >
>     > > > >        3.2  The solution MUST provide a mechanism to allow
>     servers to
>     > > > >             simultaneously support clients using different
>     revisions of
>     > > > >             modules.  A client's choice of particular
>     revision of one or
>     > > > >             more modules may restrict the particular
>     revision of other
>     > > > >             modules that may be used in the same request
>     or session.
>     > > > >
>     > > > > Today, the version number is effectively an (implicit)
>     part of the
>     > > > > module name (plus the revision date for backwards
>     compatible changes).
>     > > > > Hence, my understanding is that today's model does satisfy
>     3.2 as
>     > > > > well.
>     > > >
>     > > > This is not what we have at all. RFC 7950 says a server can
>     only implement
>     > > > one revision of a module.
>     > > >
>     > >
>     > > A new version today essentially means a new module name and I
>     do not
>     > > see a conflict with what I wrote.
>     >
>     > Then I think this requirement needs clarification. It says
>     "different
>     > revision of modules", which can be interpreted as different
>     revisions
>     > of *the same* module.
>     >
>     > Also the second part of the paragraph seems to indicate multiple
>     > revisions of the same module in the server.
>     >
>     > I do not agree with this requirement.
>
>     Today, you need to create a new module if you make NBC changes to
>     existing changes (e.g., you change Bool to Int {0..1} and you are not
>     creating a new leaf). Since there are now two modules, you _can_
>     implement both modules if that makes sense.
>
>
>
> This does not make sense because a node in YANG is identified by a QName,
> not just a local-name.   The node oldmod:foo is not the same as 
> newmod:foo.
> It never has been and never will be the same node.

Yes, not the same node, but both representing the same property.

For "config false", or stuff coming out of operational then I have no 
issues with two nodes reporting different representations of the same 
property (unless default values are not being returned).  This is quite 
a common thing to do anyway, and clients can ignore the data that is not 
being returned.

But I struggle to understand how have two nodes in the same schema that 
both directly manipulate the same underlying config property works.  I 
think that various folks have suggesting that this is a viable way of 
fixing bugs in config nodes, but I would be interested to see an 
explanation of exactly how this works, and what limitations are deemed 
to be acceptable.


>
>     If we allow to make such changes as part of a module revision, i.e.,
>     without creating a new module, I think we should not loose the ability
>     to implement both the old version and the new version.
>
>
> As Balazs asked, how can the data node be a boolean and an integer at 
> the same time?
> There seem to be plenty of scenarios that cannot be implemented 
> simultaneously by a server.
I think that there are lots of questions if you have two properties 
representing the same underlying configurable node:
  - can they both be configured at the same time with different values?
  - can they both be configured at the same time with the same value?
  - what if the configured value for one data node is not representable 
in the other data node?
  - what if the defaults values differ?

>
>     I think we need to distinguish between the agreement on the
>     requirement, namely that a server should be able to provide support
>     for an old and a new definition, and agreement on the solution.
>
>     Do you disagree with the requirement? Or do you disagree with the
>     consequences of implementing multiple versions of the same module
>     for some of the proposed new versioning schemes? Or both?
>
>
>
> I understand the transformation approach (am have implemented 
> something like it).
> This only works if the mapping is complete.  If there are any holes in 
> the mapping
> then the affected nodes are lost.  Vendors have already proven they
> can implement this approach without any new standards.
>
> Vendors are already releasing updates to old module revisions by 
> managing the revision date.
> I agree SEMVER is incrementally better than that.
>
> I do not agree that more than 1 revision of a module can be implemented.
> A server can have multiple "outside" schema that gets transformed to 
> the real "inside" schema.

This is the solution that I'm potentially thinking of ... but it may 
require some protocol mechanism for a client to be able to select which 
"outside" schema it is using, if the server supports multiple.

If different revisions of modules exist in different "outside" schema 
then some may argue that the server is implementing two different 
revisions of a module.

For me, one thing is certain, is that there should only be a single 
revision of each module as being implemented in YANG library.

> This is fine and breaks no YANG rules.  It also requires no additional 
> standards unless the
> transformation mechanism is going to be standardized.
>
No current plans to try and standardize the transformation mechanism.

Thanks,
Rob

>
>
>     /js
>
>
>
> Andy
>
>
>     -- 
>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>     Fax:   +49 421 200 3103              >
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


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


  
    
  
  
    


    

    

    
On 09/11/2018 11:38, Andy Bierman
      wrote:

    

    

      
      


        


          
On Fri, Nov 9, 2018 at 12:15 AM,
            Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
            wrote:

            
On Thu,
              Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:

              > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
              wrote:

              > > On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy
              Bierman wrote:

              > > > 

              > > > This is what we have today only if modules
              are updated in legal ways.

              > > > The 3.1 requirement says this backward
              compatibility is maintained even

              > > > if the module is updated in violation of
              the module update rules.

              > > >

              > > 

              > > It is stating a requirement. How solutions meet
              the requirement is for

              > > the solutions to figure out.

              > > 

              > > > How would 3.1 be met if the WG decided to
              just add a new 'datastore'

              > > > key leaf to the /modules-state/module list?

              > > 

              > > Depends on the solution I guess.

              > >  

              > > > IMO the current "deprecate and start over"
              is actually the easiest

              > > > and most robust solution path, and it
              requires no changes to YANG or

              > > > the protocols.

              > > 

              > > Yep. But there are people who think that other
              solutions can do

              > > better. The challenge is to find out whether
              they actually do better

              > > or for whom they do better (and if someone has
              to pay a price for it).

              > > For having this discussions, it is good to write
              down requirements.

              > > 

              > > > >        3.2  The solution MUST provide
              a mechanism to allow servers to

              > > > >             simultaneously support
              clients using different revisions of

              > > > >             modules.  A client's
              choice of particular revision of one or

              > > > >             more modules may restrict
              the particular revision of other

              > > > >             modules that may be used
              in the same request or session.

              > > > >

              > > > > Today, the version number is
              effectively an (implicit) part of the

              > > > > module name (plus the revision date
              for backwards compatible changes).

              > > > > Hence, my understanding is that
              today's model does satisfy 3.2 as

              > > > > well.

              > > > 

              > > > This is not what we have at all. RFC 7950
              says a server can only implement

              > > > one revision of a module.

              > > >

              > > 

              > > A new version today essentially means a new
              module name and I do not

              > > see a conflict with what I wrote.

              > 

              > Then I think this requirement needs clarification. 
              It says "different

              > revision of modules", which can be interpreted as
              different revisions

              > of *the same* module.

              > 

              > Also the second part of the paragraph seems to
              indicate multiple

              > revisions of the same module in the server.

              > 

              > I do not agree with this requirement.

              

              Today, you need to create a new module if you make NBC
              changes to

              existing changes (e.g., you change Bool to Int {0..1} and
              you are not

              creating a new leaf). Since there are now two modules, you
              _can_

              implement both modules if that makes sense.

              

            

            


            

            


            

            
This does not make sense because a node in YANG is
              identified by a QName,

            
not just a local-name.   The node oldmod:foo is not the
              same as newmod:foo.

            
It never has been and never will be the same node.

          

        

      

    

    

    Yes, not the same node, but both representing the same property.

    

    For "config false", or stuff coming out of operational then I have
    no issues with two nodes reporting different representations of the
    same property (unless default values are not being returned).  This
    is quite a common thing to do anyway, and clients can ignore the
    data that is not being returned.

    

    But I struggle to understand how have two nodes in the same schema
    that both directly manipulate the same underlying config property
    works.  I think that various folks have suggesting that this is a
    viable way of fixing bugs in config nodes, but I would be interested
    to see an explanation of exactly how this works, and what
    limitations are deemed to be acceptable. 

    

    

    

      

        

          

            


            

            
 

            

              If we allow to make such changes as part of a module
              revision, i.e.,

              without creating a new module, I think we should not loose
              the ability

              to implement both the old version and the new version.

              

            

            


            

            
As Balazs asked, how can the data node be a boolean and
              an integer at the same time?

            
There seem to be plenty of scenarios that cannot be
              implemented simultaneously by a server.

          

        

      

    

    I think that there are lots of questions if you have two properties
    representing the same underlying configurable node:

     - can they both be configured at the same time with different
    values?

     - can they both be configured at the same time with the same value?

     - what if the configured value for one data node is not
    representable in the other data node?

     - what if the defaults values differ?

    

    

      

        

          

            


            

            
 

            

              I think we need to distinguish between the agreement on
              the

              requirement, namely that a server should be able to
              provide support

              for an old and a new definition, and agreement on the
              solution.

              

              Do you disagree with the requirement? Or do you disagree
              with the

              consequences of implementing multiple versions of the same
              module

              for some of the proposed new versioning schemes? Or both?

            

            


            

            


            

            
I understand the transformation approach (am have
              implemented something like it).

            
This only works if the mapping is complete.  If there
              are any holes in the mapping

            
then the affected nodes are lost.  Vendors have already
              proven they

            
can implement this approach without any new standards.

            


            

            
Vendors are already releasing updates to old module
              revisions by managing the revision date.

            
I agree SEMVER is incrementally better than that.

            


            

            
I do not agree that more than 1 revision of a module
              can be implemented.

            
A server can have multiple "outside" schema that gets
              transformed to the real "inside" schema.

          

        

      

    

    

    This is the solution that I'm potentially thinking of ... but it may
    require some protocol mechanism for a client to be able to select
    which "outside" schema it is using, if the server supports multiple.

    

    If different revisions of modules exist in different "outside"
    schema then some may argue that the server is implementing two
    different revisions of a module.

    

    For me, one thing is certain, is that there should only be a single
    revision of each module as being implemented in YANG library.

    

    

      

        

          

            
This is fine and breaks no YANG rules.  It also
              requires no additional standards unless the

            
transformation mechanism is going to be standardized.

            


            

          

        

      

    

    No current plans to try and standardize the transformation
    mechanism.

    

    Thanks,

    Rob

    

    

      

        

          

            


            

            

              

                  /js

                

            


            

            


            

            
Andy

            
 

            

                  

                  -- 

                  Juergen Schoenwaelder           Jacobs University
                  Bremen gGmbH

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

                  Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

                

          

          

        

      

      

      

      

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


    

    

  


--------------0C5F85BA11D9321E90CFE45A--


From nobody Fri Nov  9 14:53:24 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3DE129619 for ; Fri,  9 Nov 2018 14:53:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.971
X-Spam-Level: 
X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 ZmQ-jjIbN3aJ for ; Fri,  9 Nov 2018 14:53:20 -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 89ED9129385 for ; Fri,  9 Nov 2018 14:53:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3235; q=dns/txt; s=iport; t=1541803999; x=1543013599; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=rKduOwvVIyLPXO39kHbg34QMB9KTxpzcRBHEVEib8Qg=; b=cks2L+xsKZ8U/ScMQ9mpbKGKnSkeHIu4TvoX/w1cb2WL/u9U5wsye4oU fksylJiDAPJMqgYx1KJzPv76+ODo1SRoyKWW9hjVNhYygQqs+BiWRGP7C //4Z/y7O96OSpprDKci+g0rZ9nXa/jzTlwcajLujYD3wimExTZfrJffAE Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9AADZDuZb/xbLJq1gAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgWWCaoECJ4N4iHeNKZksDRgLhANGAoNGOBYBAwEBAgE?= =?us-ascii?q?BAm0cDIU7AQEEAQEhDwEFNgkCDgILDgIIAgImAgIbDDAGAQwGAgEBF4MGAYI?= =?us-ascii?q?BD6d8gS6FPoRkBQWBBosIgUE/gREngmuDGwEBgUs3JoI9glcCiUCWDAmREwY?= =?us-ascii?q?YgVeFAYJ8hxqRGoZXgVohgVUzGggbFTuCbIJQg2uEYYU+PwMwjQ8BAQ?=
X-IronPort-AV: E=Sophos;i="5.54,485,1534809600";  d="scan'208";a="7881340"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Nov 2018 22:53:17 +0000
Received: from [10.61.194.82] ([10.61.194.82]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id wA9MrH5l022684; Fri, 9 Nov 2018 22:53:17 GMT
To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de
Cc: netmod@ietf.org
References: <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de> <20181109.143729.1869485019013831956.mbj@tail-f.com> <20181109151347.3xms2cty6hxyl232@anna.jacobs.jacobs-university.de> <20181109.173159.1522007243611164311.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <96995ddc-f69e-1a91-21b6-36304c8510f3@cisco.com>
Date: Fri, 9 Nov 2018 22:53:16 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20181109.173159.1522007243611164311.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.61.194.82, [10.61.194.82]
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 09 Nov 2018 22:53:22 -0000

Hi Martin,


On 09/11/2018 16:31, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
>> On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
>>>> I think we need to distinguish between the agreement on the
>>>> requirement, namely that a server should be able to provide support
>>>> for an old and a new definition, and agreement on the solution.
>>>>
>>>> Do you disagree with the requirement? Or do you disagree with the
>>>> consequences of implementing multiple versions of the same module
>>>> for some of the proposed new versioning schemes? Or both?
>>> I do not agree with the requirement that a server MUST be able to
>>> support multiple revisions of the same module, which is how I
>>> interpret 3.2.  If this is not the intention of 3.2, maybe it can be
>>> clarified.
>>>
>> Here is what 3.2 says:
>>
>>         3.2  The solution MUST provide a mechanism to allow servers to
>>              simultaneously support clients using different revisions of
>>              modules.  A client's choice of particular revision of one or
>>              more modules may restrict the particular revision of other
>>              modules that may be used in the same request or session.
>>
>> This does _not_ say servers MUST implement this.
>>
>> Item 3.2 establishes a requirement and for some solutions it may be
>> easy to satisfy this requirement, for others it may be more costly to
>> satisfy this requirement.
>>
>> The whole requirements exercise becomes a rather pointless exercise if
>> we remove requirements so that certain solutions look more
>> attractive.
> Ok, but that's not what I wrote.  I don't agree with this requirement
> which says that it MUST be possible for a server to support
> different revisions of a given module (again, if this is not the
> intention of the text, please clarify).  I simply don't think that
> this is a good requirement.
One way to think of this is as YANG data models defining an API between 
client and server.

There seem to be lots of REST APIs that implement versioning of their 
API by having a version number in the URL.  In fact, I think that 
RESTCONF adopts this approach to allow versioning of the protocol.

One solution is as Andy describes.  The underlying server only 
implements one version of the a given YANG module, but they may provide 
other views on to this data using different versions of YANG modules.  
E.g. the same as how Vendor YANG models, IETF YANG models, and 
OpenConfig YANG models might be treated as their own views, mapped to 
the same internal YANG modules.

Thanks,
Rob


>
>
> /martin
>
>
>> I have not seen a proposal that addresses all requirements and hence
>> at the end the WG needs to decide which tradeoffs make sense.
>>
>> /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 Fri Nov  9 19:45:47 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152BF130DD7; Fri,  9 Nov 2018 19:45:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.172
X-Spam-Level: 
X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7cSpvH8nxNR; Fri,  9 Nov 2018 19:45:37 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6F6130DD5; Fri,  9 Nov 2018 19:45:37 -0800 (PST)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wAA2npl3022844; Fri, 9 Nov 2018 18:49:51 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=PPS1017; bh=k1JeWx89UlCatTiU9IVavIi3r5wRV9Bx3+xVjfXcsmM=; b=eHTauSoiyimC3cNQ4tuThJDKotdGP+cfsPwE4juOmCyUofnkweQ3Q54qGdEdV5g5B9De qQdZ2WiFFnatjveq9UhIB9qDnBbZ8khroD8MaJNJzwcAPm7ycF+ExV4GoUTfULhXZj54 YKKucnh8RXQXbhMLhjWd8AMc+PdCLzd5Ym0qIpr+eP+3N2wvXrO8JvMTT4KDiz9jKdu/ 2pjAwQIg6HgMIB/scLNLRRfMF/gF0XhUKvXmj9FXdVsF5CZvkIERY3ioxX7ylAGMvLD9 dsOTYGD53IuU5Qz2G8RX25/Q96RwNqtEpt3f9bDfzG7d68eN4A1kSfetxqp1rA7R85g2 pA== 
Received: from nam04-bn3-obe.outbound.protection.outlook.com (mail-bn3nam04lp0119.outbound.protection.outlook.com [216.32.180.119]) by mx0a-00273201.pphosted.com with ESMTP id 2nnnamg3qc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 09 Nov 2018 18:49:51 -0800
Received: from CO2PR05CA0005.namprd05.prod.outlook.com (2603:10b6:102:2::15) by BYASPR01MB0023.namprd05.prod.outlook.com (2603:10b6:a03:72::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.11; Sat, 10 Nov 2018 02:49:48 +0000
Received: from BY2NAM05FT054.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::207) by CO2PR05CA0005.outlook.office365.com (2603:10b6:102:2::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.12 via Frontend Transport; Sat, 10 Nov 2018 02:49:47 +0000
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.13 as permitted sender)
Received: from P-EXFEND-EQX-02.jnpr.net (66.129.239.13) by BY2NAM05FT054.mail.protection.outlook.com (10.152.100.191) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.20.1339.3 via Frontend Transport; Sat, 10 Nov 2018 02:49:47 +0000
Received: from P-EXBEND-EQX-01.jnpr.net (10.104.8.52) by P-EXFEND-EQX-02.jnpr.net (10.104.8.55) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 9 Nov 2018 18:49:47 -0800
Received: from smtp.juniper.net (10.104.20.6) by P-EXBEND-EQX-01.jnpr.net (10.104.8.52) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Fri, 9 Nov 2018 18:49:45 -0800
Date: Sat, 10 Nov 2018 09:49:44 +0700
From: Ebben Aries 
To: Martin Bjorklund 
CC: , , 
Message-ID: <20181110024944.fxc47watzlvhtih5@smtp.juniper.net>
References: <37f05b48-5fe7-82b4-ae32-9b856596e6a2@cisco.com> <20181108.224633.1499859196570533612.mbj@tail-f.com>  <20181109.144203.1456851344567787622.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20181109.144203.1456851344567787622.mbj@tail-f.com>
X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.13; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(136003)(376002)(39860400002)(346002)(396003)(2980300002)(189003)(199004)(8936002)(69596002)(336012)(2906002)(8676002)(97736004)(446003)(11346002)(305945005)(86362001)(55016002)(26005)(23726003)(68736007)(4326008)(1076002)(486006)(126002)(53936002)(81156014)(6246003)(186003)(97756001)(77096007)(81166006)(476003)(356004)(6346003)(7696005)(54906003)(93886005)(229853002)(46406003)(76176011)(6916009)(53416004)(47776003)(106466001)(478600001)(16586007)(316002)(5660300001)(50466002)(105596002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYASPR01MB0023; H:P-EXFEND-EQX-02.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1; 
X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT054; 1:qE2hDW8JtMFWWFMfzjZrjHdOCGMLo5nKBlwnapSTLhpHospDQ3IG9/lIIYpV2ea6sQFKNFNCN7MI0qeiPr6lN3YTsAASnUwV5fXZhDpa3vwvvUwJvNDvWUmR1LF1OdGR
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 723f400a-cada-4a8e-bba6-08d646b72d84
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390017)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060); SRVR:BYASPR01MB0023; 
X-Microsoft-Exchange-Diagnostics: 1; BYASPR01MB0023; 3:zlMcAmqCqxeC6TZguUbyEXEUTeYKal9F33ZGYGgq6v+jDqH2qkvDJ0G8ldiNygCyhC4eEjkVQPBL8MP4Chy3SE1RAr/0LuvRe378Y+MVeIiwgvK5tvW+yLlNzrkqSGGVyXrencJfOMmJH/7mxPiZbpBObykz7DK4+k4/HTGQHvuFaxta5Pjztk5sD9Xm4ZHIV39oVL3fiN4H4Y0+rZCqTsWzuUtZ5QruhCLyh3Dgx6G4OY6/EJqqfbKeR3KvjlowykfeFAo6w5GKpilfKBsHswuRS9T6oFx14GpuYzlP1mytr2C9FjPUGlMWlIexNuSDNVbqDDgNHg+qQ4T/qpxqX73K+Kjqhjxv+NxfkvPHKBI=; 25:AhsBcRSaEVenpaiZz5ie9AtFb3/3O/GAR/0D9rv4frtAnFsJ3SUtwHps7dcUal3xnB1wmrdhIGCF0Yryx2S7zqGXgzUf9yc2QP2YmWQnOakLuU5hU/Q9eKZPAUxZTPDuWcqpERrb5imRoIvw2/Jv+35YC2WxQ4eAsv9sMHnBXOzNH2c7h4TGL866bHnehes9nYh5IiAe1L0xWnbEZhvd22UMYPBQVtiftFSRm5y/zehqzNXjF1C04ibdJywdz6i4cnZRYCh0VgNT1ZG0Iqf74dppDmdfT9CBxozJGCLJGRqGZ9s2gGVkUSjmVFe5Dq6R1C9EQYyjHGENKmZ6XmxvGQ==
X-MS-TrafficTypeDiagnostic: BYASPR01MB0023:
X-Microsoft-Exchange-Diagnostics: 1; BYASPR01MB0023; 31:tEte2jwCJuHx3SAK9hqx/1HRhvnFVf+CicMBq9rXIV5lLxenZ4FUZxZBu7+UUBWTUWTc85j7iHIeGyvulnEkQPW1WRqxx3yGPLQR4mE0qQMTSj2elvi30VD5kbOSO5E4XLoS6lh245vVrjabz/b2VZo2sMvL31aXQyjsPHUM7RaIlUlDNvy6AtSsEGtqySIe8v8Q+3Oe9CGhNzJO6C1TKjann1KXe1+4VECX+wvEwmk=; 20:xH/0gc0ma7tB68cCSwmmvXIlW2SgUUOcSASIrWiWzWg6EcJR2I3YM+V9NFVEw8fI7uH1xOVLsv2Z30hMqUPAGCPYVIR5AAk2uEVls91fP+Uo9BkKlpBrdg2v1ITTrh1aEAARUBXIyAlivmN0dZ1kpoTSne8ig2+rcaHPy5BWheDhXFXmBWUdAsfXgwye+Bc3W1o86FqRN7vxcvgNoU/pgRXnO+4bpfhYeU1AQiGvLFBMjHEQkjlqLZzOAaWZhTbqzLdHNAN0b+oMLQldkqnWdQNX6gHFzTSgfwpB8ntS1ykE9AKVeZWFJkcF4qn6FqF7/m/zkOfLpwJFP4+J8LeKQg+vNsz0nd3zejUsYf65oHAYer2gQwaBgLu24gNSiyOslSk10jIvP/V9pv0bw2OC2dXCe1CO9EoTbKr6WbTu5D9ylCXj/66cdcDDagBaVgOUmEzMGiTzR7zdiO849Fwz1OXLaHl0mqz1b92Scc9wHTY+57garfeTQcH+9fabK7zH
X-Microsoft-Antispam-PRVS: 
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93003095)(3002001)(3231402)(944501410)(52105111)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:BYASPR01MB0023; BCL:0; PCL:0; RULEID:; SRVR:BYASPR01MB0023; 
X-Microsoft-Exchange-Diagnostics: 1; BYASPR01MB0023; 4:8DkdFwwNaoSfftCsi7Lt3qqSvPuJe3G+L2wxjd0NR18dU8/eyjMCidg0Jv5W8ni5R94pgiINQKebrFDwVmpjIHWvb7yqAGIeRC6gEkif+yUf8NPS1j/nfv1W4tjrElZV5Arvi4gH38fAkYFQ1nNPvwRkLa61xu5hs8ZhPCiTKw2jL+wzefoAfJn/oe0CMy/so99wGQuqXopSkxbtluBiptnVwyLXUApdvJtFKfzaTy3YxzE2TKyRPGs5fRiDrvLEoC3tLEQyCPFR6DDXfoQb3g==
X-Forefront-PRVS: 0852EB6797
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BYASPR01MB0023; 23:MXkyxNQt6pL4JaKiMlLGc/MpHdI+W92zW4jAjS3j?= =?us-ascii?Q?v8MDA0R9/U9lf+UD/nhZMSdpfEG6KBmybYKu/t7QVTaYuugNZm/ghur0Ksnf?= =?us-ascii?Q?hJWuumyE/+nDncpgIDkcIx8IucFe8WnL/cCZcQosXA0h9IVHZU73snFMq0Fh?= =?us-ascii?Q?yOcBiFzOjrMhn1S6JbEv632Ars3u+5qAN+i9ayyjfWq+dK5uO3ixbUwNx0dh?= =?us-ascii?Q?VYDFKBLu+nWQwLsgQHK7/6No3zn/MpzS3sGLOWho4DYMpzHWwa4fwbirWNvx?= =?us-ascii?Q?K/q7PkEjv/mD+J+PDOz44pXvLD/Rz6DCbgg8keaOUZ+d9ltoTL6SEuKhyEqa?= =?us-ascii?Q?BBjtZSXMLhxDNtrBf6UZRGLzTcqqcANuzanMlyHY/6yuFI+TkH8G3f+NpCva?= =?us-ascii?Q?hZzlFVZsBqldhaxgaFXn2U9AokiMBAixr8yvDsvrdpzYglDZpAwMm+XQklU7?= =?us-ascii?Q?J78koTzEWLvFA5xzA/f9eayGU6gip5xyGBENxepqFFHz5GyXrEE4Sns2N1Dw?= =?us-ascii?Q?XOnrst89xBZecYUHLBFY6wcrfDxTsL8fjg8iVjiUaOnLAFGHBoHoZ4cjrVvp?= =?us-ascii?Q?pfKCF6sPgVbBe3nqtmluct5F2watM2qJh8VL/b2fwkQyEqz2VemWoLDRkwFf?= =?us-ascii?Q?CRTAak/lDV1/zkLgvBxUXP7kjOBZcYW7m6mb61YN/kT6+17Cg3V9qg49xia7?= =?us-ascii?Q?ziUgX8GQofrNnmYK1XB0NxbgY21YMzD5SJ/mgwObFN3qvx2MuoYAvquam5IC?= =?us-ascii?Q?FZB1JuWxFU4YeMoflD/TRPKQMb2iUhbFmRtgh0FEx3ZNpHrRXTthm12lNU9h?= =?us-ascii?Q?3SX38nC46W933EfgI2a1Y04KmAfz2gy8pIYwq2zHIDuhSOXool/HTKYTqgcZ?= =?us-ascii?Q?zS/JW9hxZNecMscnvbt/UdHCC37nDHEWG9fXrzxefevWf0rt1kSTIsedNWL9?= =?us-ascii?Q?lhEYSVaDEqQriGWJAKhqcUY4njkIikngrutqNfX6aJEGSSCqbK0uPl/KH0iL?= =?us-ascii?Q?cgOltfqR4PBU+hrVsU7r3ViYYrUGGHAohBXXi9wmiw9RZeDrTufXAbvzq/Bu?= =?us-ascii?Q?fBSyENG6uFuL6HhAy6uh1q10OzqD/g62PbIpPEZZ4JwyMadSll/SpToakwhJ?= =?us-ascii?Q?5zlcBxYlm5qRDCkFGjbYXWs4syxoRD/ifKsAiKka1vz0AnwVXCo/yBLGyOPU?= =?us-ascii?Q?zVHQXz2OD5BqQbw=3D?=
X-Microsoft-Antispam-Message-Info: LtKdlgnBiWuvQ8MemrEcUsQYnDdaHADUFbsYaeWUIOdhsmfyvz5O03ytCVHEcei+5c7wF1xfqpojaIQmFeRN4tB8FO7qnSN+O3MhU9eK3TWMPLKadLMGQMg9uN2TL5LZEdeUbKT4uOcN/4/ka7M7tblYyDNjSRpZcApAxj0mKl78b4923o1ZPlC/NWNcKZRlXTHAUbYONqiwVJxgFqgrDtX96I+G6Lo8xW6+BdaMYSzG+97w+/xSJNfFTcHHiDISOnvHdrupyDTGBm8+p6bLo6F+/CC1yZCkGDinPW0UpKADyRWLcaXJaIhZDFamXbhMJFCErAnSJBUZfcSYi2zEWuY/QpV1kHiM43jAZ3PBuxI=
X-Microsoft-Exchange-Diagnostics: 1; BYASPR01MB0023; 6:uxzN11y6FAEs+2NQFSdGKvOUuV9DxTyOSILlyPu7yN1jR3YinAbJ4i8/8Eux7DQHzzS3dX7r23KO79NZiVSVA/4QeHY98BSG0kgh6wmCtokfAQmKpmoJyCc6AIIGEZc1DkexySP3nRFtMzzLlFfuSHwpzVrWJ3VhkwmDZ/t8FGTZfabmGfOe4+HJZpAKqlKv2vHo+y5LQUgCMPEXGR7e88p/FNI5KCJJ27fKKavZjRi6tg84+FP67CswLkjX3auZ8or5MgnvSqZyzmZT+pB64wj2yBJ3q1lb6OosTsaHpm9yiGDFdkJ7fpmhsSTDX1TDBmxv3Q8km94MWNVMfAWOdrOVJvPy1JBlZVNUCo9E894mS+8iohieVo+/shCTtSqvnkaUblLSthY9c0TmB1h2cO4dAEHnZ4xkNGqeQ9B7CRn7zz2U2a+Peqd2fHCj03MFCXwqI4m8pyqHDq8dgEhukA==; 5:j2btEIfijC/3ddmc3TOw1I2BPHtNn+yR8+kHR1MZNqJdW44IKVg8rHucCIcCJekRc6T3/fi/4unC7UdVKsCgTCzGjI1+nO5rnpuUuKTSdkIjd7EfVhhhFvRyhlvoevaCUvm83kqJzd0wCzHHWOI97WM4igoVgFnup49rt3IZsaw=; 7:u1Gzo/knL0jBUnFZ53YgAD+FxmIUEkl9giiBk9gpGmA8R5rx/VsAhFj4JfUbKmpM5ud0WofbF10mvS2RAQiBqmW2tEWC6C7twf/GjcX+oD+QWt0tX+lUP4sXUny5UDwZZkX2mpUAfyWths9Yj7rnWw==
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Nov 2018 02:49:47.5980 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 723f400a-cada-4a8e-bba6-08d646b72d84
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.13];  Helo=[P-EXFEND-EQX-02.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYASPR01MB0023
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-09_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811100022
Archived-At: 
Subject: Re: [netmod] Fwd: New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Nov 2018 03:45:39 -0000

On Nov 09 14:42 PM, Martin Bjorklund wrote:
> > The
> > point of requirement 1.4 was to say that the DT felt previous versions
> > of modules needed to support fixes without bringing in elements from head.
> 
> I think this means that you require branching.
> 
> But is this still the point of the "new 1.4" that was mentioned in the
> session?
> 
> However, as Rob Shakir mentioned in the session, there are other ways
> to do fixes / enhacements than branching a single module.  You can add
> new functionality with augment and make changes with deviations.
> 

So we could potentially result in a cleaner set of base model versioning
but augments and deviations that will need somewhat of it's own
branch versioning now.  I often find that consumers/clients make quite a
few assumptions and expectations when one supports model version X (w/o
the realization that it is X+/- for various reasons)

We'll have a namespace problem which will result in namespaces being
inserted (and removed at later dates) which ultimately has an impact on
clients

Possibly a better middle ground but think there are still considerations
here as well as to the overall impact of this approach

/ebben


From nobody Sat Nov 10 08:18:35 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0761277C8 for ; Sat, 10 Nov 2018 08:18:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2upGkXf8f6uc for ; Sat, 10 Nov 2018 08:18: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 ED720124408 for ; Sat, 10 Nov 2018 08:18:31 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 25E894D6C85A4 for ; Sat, 10 Nov 2018 16:18:25 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 10 Nov 2018 16:18:26 +0000
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.171]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0415.000; Sun, 11 Nov 2018 00:18:15 +0800
From: Qin Wu 
To: NETMOD WG 
Thread-Topic: Ambiguity on list entry deletion using edit-config
Thread-Index: AdR5EOMNHMIJ2wK/S0id97IrYa2vTQ==
Date: Sat, 10 Nov 2018 16:18:14 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.45.111.30]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9B10535Cnkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: [netmod] Ambiguity on list entry deletion using edit-config
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 10 Nov 2018 16:18:34 -0000

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

Hi,
I have confusion on list entry deletion operation defined in RFC7950.
RFC7950 said:
"
List entries can be deleted through  by using the "operation" =
attribute in the list's XML
element. When a NETCONF server processes an  request, if the o=
peration is "delete", the entry
is deleted from the list if it exists.  If the list entry does not exist, a=
 "data-missing"
error is returned.
"
I am wondering how do we define the list entry exist in the above Quoted te=
xt?
A list entry may include one or multiple key leafs and/or one of multiple n=
on-key leafs.
Do we just check if requested list entry with specified key leafs exist in =
the list of target datastore
or do we need to check if the requested list entry with all specified leafs=
 including key leafs and non-key leafs
exist in the list of target datastore?

In other words, do we need to validate non-key leafs within the list? What =
about requested list entry with specified
key leaf matching corresponding key leaf in the list of target datastore wh=
ile specified non-key leaf not matching?

Do we judge this as the list entry not exist and report "data-missing" erro=
r?
or we should report new error "non-key-data-mismatching"?

If we follows RFC7950 rule and judge this case as the list entry doesn't ex=
ist, I feel this rule is too strict and RFC7950
doesn't clarify whether validation on leaf of list is required.

If my understanding is correct, if the key leaf matches, the corresponding =
leaf list will be delete even though
non-key leafs mismatches? But this seems not complaint with RFC7950?

Comments or clarification?

-Qin


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











Hi,


I have confusion on list entry =
deletion operation defined in RFC7950.


RFC7950 said:=



"


List entries can be deleted thr=
ough <edit-config> by using the "operation" attribute in th=
e list's XML


element. When a NETCONF server =
processes an <edit-config> request, if the operation is "delete&=
quot;, the entry


is deleted from the list if it =
exists.  
If the list entry does not exist, a "data-missing"=



error is returned.


"


I am wondering how do we def=
ine the list entry exist in the above Quoted text? 



A list entry may include one or=
 multiple key leafs and/or one of multiple non-key leafs.=



Do we just check if requested l=
ist entry with specified key leafs exist in the list of target datastore



or do we need to check if the r=
equested list entry with all specified leafs including key leafs and non-ke=
y leafs



exist in the list of target dat=
astore? 



 


In other words, do we need to v=
alidate non-key leafs within the list? What about requested list entry with=
 specified



key leaf matching corresponding=
 key leaf in the list of target datastore while specified non-key leaf not =
matching?



 


Do we judge this as the list en=
try not exist and report "data-missing" error?



or we should report new error &=
quot;non-key-data-mismatching"?


 


If we follows RFC7950 rule and =
judge this case as the list entry doesn’t exist, I feel this rule is =
too strict and RFC7950



doesn’t clarify whether v=
alidation on leaf of list is required.


 


If my understanding is correct,=
 if the key leaf matches, the corresponding leaf list will be delete even t=
hough



non-key leafs mismatches? But t=
his seems not complaint with RFC7950?



 


Comments or clarification?=



 


-Qin


 






--_000_B8F9A780D330094D99AF023C5877DABA9B10535Cnkgeml513mbxchi_--


From nobody Sat Nov 10 23:07:56 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F0312D4F1 for ; Sat, 10 Nov 2018 23:07:54 -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=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 DA6HbZy_QXuV for ; Sat, 10 Nov 2018 23:07:51 -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 42EBD1292F1 for ; Sat, 10 Nov 2018 23:07:51 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id n18so4055273lfh.6 for ; Sat, 10 Nov 2018 23:07:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K7LwRtGcBeFCjwyEosW3zsHTx37I8mxmkqOklFU29uQ=; b=rEYt1DW0VCHCRR7G3yVRfgvh3fnGUYEQ+wSfV5tAQ2ZRfG10NKp7pA/j9VqPneZplP CXtVen7kh6hPt+Rmclo0M+9IEqeA1cm+mezVRj0qQwnxhj3iIVlFAuvj+G0vGWNV1cgl eGYy1ESYisv+f2w6Vvd/x16485P2j3rL4ZYveRCfVKZdAGvL2f77IXrsuMTXAE8zbgUc 5ycPHYoQ5q4pp6ZU3XULAWJXMK3r4PQk5d8fc+E1sOt0TI5xdKWSmBzfIB22Q9uASLXI g+aBGZxUmZWUu/qOsz1VeKxbwgzc7VwxzNieB+i6zFRe+YLn03Z2c5FlKEJ387VhNbkI 6hhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K7LwRtGcBeFCjwyEosW3zsHTx37I8mxmkqOklFU29uQ=; b=nQ8g3CJI+wXtqIw+fSQnOY1v/tFquZBkLkVj0ZsgAxzAD4s4d5X/97BYPjoHczjWt/ M1GfkaI0PnW/KiNFVfCbb/YMG4uEjh33O0S7+o/cNZkRU3mcZtYA89ztvgMBWn6UTp7T kafMBvCN57rsm8QjtwYgHQ9XRQPpSmJ0lOnfcE6NR3ymKkOEZfjpUQGus01hL9n4JDxk XoJ6IwmdqsQQSvX1ajvXwL/em8fzKHGN1flD3R+k2s36qBLgWT6zMdO4a5clIu2TNSp0 R8zy5NUTnPg3TaVBCJJAJANNfQafQbyL2MaynMhf5l9zmQxAvWoL+LcKePj0q9edviMA MbIw==
X-Gm-Message-State: AGRZ1gJYsAj1REQVmHu6vVygwXXkf+J4RU+ME90GVhe6kcSnhLs4caKm chV5X9G6SLE6yCLtSsDYJcRjGtGPcyevI9FeBqPEdg==
X-Google-Smtp-Source: AJdET5dmJroLtouDZzFS25rwE3WJl0LNq+iEIH/Ry8rJu1MFAeS93DXWaKiLPMFoZJDRqdHk1YinTjgO0bsLFYItalc=
X-Received: by 2002:a19:ca51:: with SMTP id h17mr8265401lfj.126.1541920069124;  Sat, 10 Nov 2018 23:07:49 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Sat, 10 Nov 2018 23:07:47 -0800 (PST)
In-Reply-To: <96995ddc-f69e-1a91-21b6-36304c8510f3@cisco.com>
References: <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de> <20181109.143729.1869485019013831956.mbj@tail-f.com> <20181109151347.3xms2cty6hxyl232@anna.jacobs.jacobs-university.de> <20181109.173159.1522007243611164311.mbj@tail-f.com> <96995ddc-f69e-1a91-21b6-36304c8510f3@cisco.com>
From: Andy Bierman 
Date: Sat, 10 Nov 2018 23:07:47 -0800
Message-ID: 
To: Robert Wilton 
Cc: Martin Bjorklund ,  Juergen Schoenwaelder , NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000fe21fc057a5e3d0a"
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Nov 2018 07:07:54 -0000

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

On Fri, Nov 9, 2018 at 2:53 PM, Robert Wilton  wrote:

> Hi Martin,
>
>
> On 09/11/2018 16:31, Martin Bjorklund wrote:
>
>> Juergen Schoenwaelder  wrote:
>>
>>> On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
>>>
>>>> I think we need to distinguish between the agreement on the
>>>>> requirement, namely that a server should be able to provide support
>>>>> for an old and a new definition, and agreement on the solution.
>>>>>
>>>>> Do you disagree with the requirement? Or do you disagree with the
>>>>> consequences of implementing multiple versions of the same module
>>>>> for some of the proposed new versioning schemes? Or both?
>>>>>
>>>> I do not agree with the requirement that a server MUST be able to
>>>> support multiple revisions of the same module, which is how I
>>>> interpret 3.2.  If this is not the intention of 3.2, maybe it can be
>>>> clarified.
>>>>
>>>> Here is what 3.2 says:
>>>
>>>         3.2  The solution MUST provide a mechanism to allow servers to
>>>              simultaneously support clients using different revisions of
>>>              modules.  A client's choice of particular revision of one or
>>>              more modules may restrict the particular revision of other
>>>              modules that may be used in the same request or session.
>>>
>>> This does _not_ say servers MUST implement this.
>>>
>>> Item 3.2 establishes a requirement and for some solutions it may be
>>> easy to satisfy this requirement, for others it may be more costly to
>>> satisfy this requirement.
>>>
>>> The whole requirements exercise becomes a rather pointless exercise if
>>> we remove requirements so that certain solutions look more
>>> attractive.
>>>
>> Ok, but that's not what I wrote.  I don't agree with this requirement
>> which says that it MUST be possible for a server to support
>> different revisions of a given module (again, if this is not the
>> intention of the text, please clarify).  I simply don't think that
>> this is a good requirement.
>>
> One way to think of this is as YANG data models defining an API between
> client and server.
>
> There seem to be lots of REST APIs that implement versioning of their API
> by having a version number in the URL.  In fact, I think that RESTCONF
> adopts this approach to allow versioning of the protocol.
>
> One solution is as Andy describes.  The underlying server only implements
> one version of the a given YANG module, but they may provide other views on
> to this data using different versions of YANG modules.  E.g. the same as
> how Vendor YANG models, IETF YANG models, and OpenConfig YANG models might
> be treated as their own views, mapped to the same internal YANG modules.
>
>

I agree with Martin that this requirement is a bad idea.
It will make YANG too complicated and error-prone.
This is not the same as versioning the entire API (e.g., /restconf2,
/restconf3).
This is conceptually a version number at every node in the tree.

The "outer" models are ignored by the server in this approach.
Only the "inner" model is actually implemented and validated.
A different set of outer models for each client, based on the set of modules
the client wants to see, sounds very complicated to design, implement,
test, and operate.


Thanks,
> Rob
>
>
Andy


>
>
>>
>> /martin
>>
>>
>> I have not seen a proposal that addresses all requirements and hence
>>> at the end the WG needs to decide which t
>>> radeoffs
>>> make sense.
>>>
>>> /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
>

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




On Fri, Nov 9, 2018 at 2:53 PM, Robert Wilton <rwilton@cisco.com&g=
t; wrote:
Hi Martin,





On 09/11/2018 16:31, Martin Bjorklund wrote:



Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> =
wrote:



On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:



I think we need to distinguish between the agreement on the

requirement, namely that a server should be able to provide support

for an old and a new definition, and agreement on the solution.



Do you disagree with the requirement? Or do you disagree with the

consequences of implementing multiple versions of the same module

for some of the proposed new versioning schemes? Or both?



I do not agree with the requirement that a server MUST be able to

support multiple revisions of the same module, which is how I

interpret 3.2.=C2=A0 If this is not the intention of 3.2, maybe it can be
clarified.





Here is what 3.2 says:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 3.2=C2=A0 The solution MUST provide a mechanism=
 to allow servers to

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0simultaneously support clie=
nts using different revisions of

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0modules.=C2=A0 A client'=
;s choice of particular revision of one or

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0more modules may restrict t=
he particular revision of other

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0modules that may be used in=
 the same request or session.



This does _not_ say servers MUST implement this.



Item 3.2 establishes a requirement and for some solutions it may be

easy to satisfy this requirement, for others it may be more costly to

satisfy this requirement.



The whole requirements exercise becomes a rather pointless exercise if

we remove requirements so that certain solutions look more

attractive.



Ok, but that's not what I wrote.=C2=A0 I don't agree with this requ=
irement

which says that it MUST be possible for a server to support

different revisions of a given module (again, if this is not the

intention of the text, please clarify).=C2=A0 I simply don't think that=


this is a good requirement.



One way to think of this is as YANG data models defining an API between cli=
ent and server.



There seem to be lots of REST APIs that implement versioning of their API b=
y having a version number in the URL.=C2=A0 In fact, I think that RESTCONF =
adopts this approach to allow versioning of the protocol.



One solution is as Andy describes.=C2=A0 The underlying server only impleme=
nts one version of the a given YANG module, but they may provide other view=
s on to this data using different versions of YANG modules.=C2=A0 E.g. the =
same as how Vendor YANG models, IETF YANG models, and OpenConfig YANG model=
s might be treated as their own views, mapped to the same internal YANG mod=
ules.




I agree with Martin tha=
t this requirement is a bad idea.
It will make YANG too complicat=
ed and error-prone.
This is not the same as versioning the entire=
 API (e.g., /restconf2, /restconf3).
This is conceptually a versi=
on number at every node in the tree.

The "out=
er" models are ignored by the server in this approach.
Only =
the "inner" model is actually implemented and validated.
A different set of outer models for each client, based on the set of modu=
les
the client wants to see, sounds very complicated to design, i=
mplement, test, and operate.



Thanks,

Rob



Andy
=C2=A0









/martin







I have not seen a proposal that addresses all requirements and hence

at the end the WG needs to decide whi=
ch tradeoffs make sense.



/js



-- 

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

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

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





_______________________________________________

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




--000000000000fe21fc057a5e3d0a--


From nobody Sun Nov 11 12:43:44 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6909130DC1 for ; Sun, 11 Nov 2018 12:43:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level: 
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzJ3moK_Ke-a for ; Sun, 11 Nov 2018 12:43:38 -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 4BA0B124BAA for ; Sun, 11 Nov 2018 12:43:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18067; q=dns/txt; s=iport; t=1541969018; x=1543178618; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=Qou8L93pqTu0ccm+1+Tv0HTCMOaGq9ZZU9t+N6axtr8=; b=LDICrtdhSG50bRlpvVoCLTzhvQx8QdMi3TI2QoG92powj67k0fsUF+H8 rMYepFUP22mi3LDLTmDt03nSPpJFlibZ0dfIVZ95eTnyJuqsTDkNOmw8K pfbdj+cYSUzOoTuZW/Z7KjP7LGVKG6gmrRWg/sLiJO5bBRsRWXuesFkNm g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AAD5k+hb/xbLJq1gAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgWWCak8hEieDeIh3jQIlkWGGeANTDRgBDIMQcUYCg0Y?= =?us-ascii?q?4FgEDAQECAQECbRwMhToBAQEDAQEBIUsJAg4CCQIQCCcDAgIbDB8RBg0GAgE?= =?us-ascii?q?BF4MGAYF5CA+MIZtQgS8fhR+EUwUFjBKBQD+BEScMgl+DGwEBAhiBMTcmgj2?= =?us-ascii?q?CVwKJPwKVOVUJhnaKIQYYgViFAoJ8hxqNJoN6hliBWiE0gSEzGggbFTuCbIF?= =?us-ascii?q?3MBcSgzgzhGGFPj8DMIpLK4IgAQE?=
X-IronPort-AV: E=Sophos;i="5.54,492,1534809600"; d="scan'208,217";a="7916377"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Nov 2018 20:43:34 +0000
Received: from [10.61.210.56] ([10.61.210.56]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id wABKhW80026189; Sun, 11 Nov 2018 20:43:32 GMT
To: Andy Bierman 
Cc: Martin Bjorklund , Juergen Schoenwaelder , NetMod WG 
References: <20181109081557.kzalxvnsk2k2fycm@anna.jacobs.jacobs-university.de> <20181109.143729.1869485019013831956.mbj@tail-f.com> <20181109151347.3xms2cty6hxyl232@anna.jacobs.jacobs-university.de> <20181109.173159.1522007243611164311.mbj@tail-f.com> <96995ddc-f69e-1a91-21b6-36304c8510f3@cisco.com> 
From: Robert Wilton 
Message-ID: 
Date: Sun, 11 Nov 2018 20:43:32 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------968F41AF5C155E26DEBFD070"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.61.210.56, [10.61.210.56]
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 11 Nov 2018 20:43:42 -0000

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



On 11/11/2018 07:07, Andy Bierman wrote:
>
>
> On Fri, Nov 9, 2018 at 2:53 PM, Robert Wilton  > wrote:
>
>     Hi Martin,
>
>
>     On 09/11/2018 16:31, Martin Bjorklund wrote:
>
>         Juergen Schoenwaelder          > wrote:
>
>             On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund
>             wrote:
>
>                     I think we need to distinguish between the
>                     agreement on the
>                     requirement, namely that a server should be able
>                     to provide support
>                     for an old and a new definition, and agreement on
>                     the solution.
>
>                     Do you disagree with the requirement? Or do you
>                     disagree with the
>                     consequences of implementing multiple versions of
>                     the same module
>                     for some of the proposed new versioning schemes?
>                     Or both?
>
>                 I do not agree with the requirement that a server MUST
>                 be able to
>                 support multiple revisions of the same module, which
>                 is how I
>                 interpret 3.2.  If this is not the intention of 3.2,
>                 maybe it can be
>                 clarified.
>
>             Here is what 3.2 says:
>
>                     3.2  The solution MUST provide a mechanism to
>             allow servers to
>                          simultaneously support clients using
>             different revisions of
>                          modules.  A client's choice of particular
>             revision of one or
>                          more modules may restrict the particular
>             revision of other
>                          modules that may be used in the same request
>             or session.
>
>             This does _not_ say servers MUST implement this.
>
>             Item 3.2 establishes a requirement and for some solutions
>             it may be
>             easy to satisfy this requirement, for others it may be
>             more costly to
>             satisfy this requirement.
>
>             The whole requirements exercise becomes a rather pointless
>             exercise if
>             we remove requirements so that certain solutions look more
>             attractive.
>
>         Ok, but that's not what I wrote.  I don't agree with this
>         requirement
>         which says that it MUST be possible for a server to support
>         different revisions of a given module (again, if this is not the
>         intention of the text, please clarify).  I simply don't think that
>         this is a good requirement.
>
>     One way to think of this is as YANG data models defining an API
>     between client and server.
>
>     There seem to be lots of REST APIs that implement versioning of
>     their API by having a version number in the URL.  In fact, I think
>     that RESTCONF adopts this approach to allow versioning of the
>     protocol.
>
>     One solution is as Andy describes.  The underlying server only
>     implements one version of the a given YANG module, but they may
>     provide other views on to this data using different versions of
>     YANG modules.  E.g. the same as how Vendor YANG models, IETF YANG
>     models, and OpenConfig YANG models might be treated as their own
>     views, mapped to the same internal YANG modules.
>
>
>
> I agree with Martin that this requirement is a bad idea.
> It will make YANG too complicated and error-prone.
> This is not the same as versioning the entire API (e.g., /restconf2, 
> /restconf3).
> This is conceptually a version number at every node in the tree.
>
> The "outer" models are ignored by the server in this approach.
> Only the "inner" model is actually implemented and validated.
> A different set of outer models for each client, based on the set of 
> modules
> the client wants to see, sounds very complicated to design, implement, 
> test, and operate.

That is not what I'm proposing.

The server exposes one or more different schema of it's choosing. When 
the client opens the connection with the server it chooses which schema 
to use.

For example, if the server release history was:

Release 1 , supports schema A
Release 1.1, supports schema B
Release 2, supports schema C

Then in release 2, the server may also support the schema associated 
with release 1 and 1.1 (i.e. it supports schema A, B and C)

If this seems too complex, then the server chooses to just implement  
schema C, associated with release 2, and clients are forced to upgrade 
and use the latest schema.

It is not our intention to force servers to implement this version 
selection, only to specify it for vendors who did wish to implement it.

Thanks,
Rob

>
>     Thanks,
>     Rob
>
>
> Andy
>
>
>
>
>         /martin
>
>
>             I have not seen a proposal that addresses all requirements
>             and hence
>             at the end the WG needs to decide which t
>             radeoffs
>             make sense.
>
>             /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
>     
>
>


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


  
    
  
  
    


    

    

    
On 11/11/2018 07:07, Andy Bierman
      wrote:

    

    

      
      


        


          
On Fri, Nov 9, 2018 at 2:53 PM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            
Hi
              Martin,

              

              

              On 09/11/2018 16:31, Martin Bjorklund wrote:

              

                Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
                wrote:

                

                  On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin
                  Bjorklund wrote:

                  

                    

                      I think we need to distinguish between the
                      agreement on the

                      requirement, namely that a server should be able
                      to provide support

                      for an old and a new definition, and agreement on
                      the solution.

                      

                      Do you disagree with the requirement? Or do you
                      disagree with the

                      consequences of implementing multiple versions of
                      the same module

                      for some of the proposed new versioning schemes?
                      Or both?

                    

                    I do not agree with the requirement that a server
                    MUST be able to

                    support multiple revisions of the same module, which
                    is how I

                    interpret 3.2.  If this is not the intention of 3.2,
                    maybe it can be

                    clarified.

                    

                  

                  Here is what 3.2 says:

                  

                          3.2  The solution MUST provide a mechanism to
                  allow servers to

                               simultaneously support clients using
                  different revisions of

                               modules.  A client's choice of particular
                  revision of one or

                               more modules may restrict the particular
                  revision of other

                               modules that may be used in the same
                  request or session.

                  

                  This does _not_ say servers MUST implement this.

                  

                  Item 3.2 establishes a requirement and for some
                  solutions it may be

                  easy to satisfy this requirement, for others it may be
                  more costly to

                  satisfy this requirement.

                  

                  The whole requirements exercise becomes a rather
                  pointless exercise if

                  we remove requirements so that certain solutions look
                  more

                  attractive.

                

                Ok, but that's not what I wrote.  I don't agree with
                this requirement

                which says that it MUST be possible for a server to
                support

                different revisions of a given module (again, if this is
                not the

                intention of the text, please clarify).  I simply don't
                think that

                this is a good requirement.

              

              One way to think of this is as YANG data models defining
              an API between client and server.

              

              There seem to be lots of REST APIs that implement
              versioning of their API by having a version number in the
              URL.  In fact, I think that RESTCONF adopts this approach
              to allow versioning of the protocol.

              

              One solution is as Andy describes.  The underlying server
              only implements one version of the a given YANG module,
              but they may provide other views on to this data using
              different versions of YANG modules.  E.g. the same as how
              Vendor YANG models, IETF YANG models, and OpenConfig YANG
              models might be treated as their own views, mapped to the
              same internal YANG modules.

              

            

            


            

            


            

            
I agree with Martin that this requirement is a bad
              idea.

            
It will make YANG too complicated and error-prone.

            
This is not the same as versioning the entire API
              (e.g., /restconf2, /restconf3).

            
This is conceptually a version number at every node in
              the tree.

            


            

            
The "outer" models are ignored by the server in this
              approach.

            
Only the "inner" model is actually implemented and
              validated.

            
A different set of outer models for each client, based
              on the set of modules

            
the client wants to see, sounds very complicated to
              design, implement, test, and operate.

          

        

      

    

    

    That is not what I'm proposing.

    

    The server exposes one or more different schema of it's choosing. 
    When the client opens the connection with the server it chooses
    which schema to use.

    

    For example, if the server release history was:

    

    Release 1 , supports schema A

    Release 1.1, supports schema B 

    Release 2, supports schema C

    

    Then in release 2, the server may also support the schema associated
    with release 1 and 1.1 (i.e. it supports schema A, B and C)

    

    If this seems too complex, then the server chooses to just
    implement  schema C, associated with release 2, and clients are
    forced to upgrade and use the latest schema.

    

    It is not our intention to force servers to implement this version
    selection, only to specify it for vendors who did wish to implement
    it. 

    

    Thanks,

    Rob

    

    

      

        

          

            


            

            

              Thanks,

              Rob

              

            

            


            

            
Andy

            
 

            

              

              

                

                

                /martin

                

                

                

                  I have not seen a proposal that addresses all
                  requirements and hence

                  at the end the WG needs to
                    decide which tradeoffs make sense.

                  

                  /js

                  

                  -- 

                  Juergen Schoenwaelder           Jacobs University
                  Bremen gGmbH

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

                  Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

                  

                

                _______________________________________________

                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

            

          

          

        

      

    

    

  


--------------968F41AF5C155E26DEBFD070--


From nobody Mon Nov 12 07:01: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 8890E130E16 for ; Mon, 12 Nov 2018 07:01:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KRysQW_ZkrxP for ; Mon, 12 Nov 2018 07:01:06 -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 E9143130E14 for ; Mon, 12 Nov 2018 07:01:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4976; q=dns/txt; s=iport; t=1542034866; x=1543244466; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=3X0SX6bu+nZTDoZ8gazRc/+jS8MABhLCjJ0w8USZpOM=; b=CtBuaLHP3nWWEFoc99WCmuS6xSg+ltE/wVzRHQW7rG59ShVZX+XTb0N6 dxfdRMqDjhTOpJ5+LAnKfnCfK3/DHuef4KrMiyIWzi9Tvwl8+75t1xOVl 3Kh6DtCMenAx945c2uaA5pT5nH5+x0IOUdjU009cPXS0+Qi9ab6B2zDfg Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAABSlOlb/xbLJq1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAIBAQEBCwGCaXASJ4N4YogVjHstkWGFaIFmDRgBCoQDRgK?= =?us-ascii?q?DTjcKDQEDAQECAQECbRwMhToBAQEBAgEBAQwVQgkbCwQUFRUCAicwBgEMBgI?= =?us-ascii?q?BAReDBgGBeQgPqVSBLx+FH4RYBYwXgUA/gREngmuDGwEBgRwvVYJFglcCn08?= =?us-ascii?q?JkRcGGIFYh36HGolah0aGWIFZIieBLjMaCBsVO4JsixyFPj8DMI4WAQE?=
X-IronPort-AV: E=Sophos;i="5.54,495,1534809600"; d="scan'208,217";a="7935960"
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; 12 Nov 2018 15:01:03 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id wACF13Gh019550; Mon, 12 Nov 2018 15:01:03 GMT
To: Andy Bierman , NetMod WG 
References: 
From: Robert Wilton 
Message-ID: <5d8a14f4-94a9-c6eb-4a7c-6d6a155e0c84@cisco.com>
Date: Mon, 12 Nov 2018 15:01:03 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------126A62893C7B24B0EB027412"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
Subject: Re: [netmod] missing YANG versioning requirements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2018 15:01:09 -0000

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



On 09/11/2018 18:35, Andy Bierman wrote:
> Hi,
>
> I think the requirements doc should state that
>
> 1) there are many more readers, operators, and client developers than
> server developers so the solution MUST take into account the numbers
> of people affected when finding a balance between client and server 
> complexity.
OK.  So you would like the solution to be weighted towards clients, but 
yet you do not want servers to have to implement any sort of version 
selection, instead pushing the problem on to the client? :-)

More seriously, I'm looking for a solution where we it up to the market 
to decide whether the complexity should be pushed to client, server, or 
a 3rd party controller.  I think that some sort of version selection 
should be able to achieve this.


>
> 2) if existing protocol and YANG solutions exist then they MUST be used
> in favor of developing new solutions.
If you replace the "MUST" with a "SHOULD" then I sort of think that this 
one is obvious.  I think that we are only trying to develop next 
solutions where the existing ones do not appear to be working well.  
There are examples in the earlier text in the requirements draft, and 
also draft-clacla-netmod-yang-model-update to provide the background and 
justify why we need to do something different than the status quo.

Thanks,
Rob


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


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


  
    
  
  
    


    

    

    
On 09/11/2018 18:35, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
I think the requirements doc should state that

        


        

        
1) there are many more readers, operators, and client
          developers than

        
server developers so the solution MUST take into account
          the numbers

        
of people affected when finding a balance between client
          and server complexity.

      

    

    OK.  So you would like the solution to be weighted towards clients,
    but yet you do not want servers to have to implement any sort of
    version selection, instead pushing the problem on to the client? :-)

    

    More seriously, I'm looking for a solution where we it up to the
    market to decide whether the complexity should be pushed to client,
    server, or a 3rd party controller.  I think that some sort of
    version selection should be able to achieve this.

    

    

    

      

        


        

        
2) if existing protocol and YANG solutions exist then they
          MUST be used

        
in favor of developing new solutions.

      

    

    If you replace the "MUST" with a "SHOULD" then I sort of think that
    this one is obvious.  I think that we are only trying to develop
    next solutions where the existing ones do not appear to be working
    well.  There are examples in the earlier text in the requirements
    draft, and also draft-clacla-netmod-yang-model-update to provide the
    background and justify why we need to do something different than
    the status quo.

    

    Thanks,

    Rob

    

    

    

      

        


        

        


        

        
Andy

        


        

      

      

      

      

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


    

    

  


--------------126A62893C7B24B0EB027412--


From nobody Mon Nov 12 08:15: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 41CD4130E68 for ; Mon, 12 Nov 2018 08:15:55 -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 2-f1Z-ZWcRuT for ; Mon, 12 Nov 2018 08:15:52 -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 227DE130E79 for ; Mon, 12 Nov 2018 08:15:52 -0800 (PST)
Received: by mail-lj1-x233.google.com with SMTP id q186-v6so8123820ljb.5 for ; Mon, 12 Nov 2018 08:15:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MQSgqDm+w1QrI7SDrhIm5tBK0nf9gZSWz2Lwd67aUu8=; b=XYkgHWHZKEG/0RB9JB7CNcZ15xvSoaYwV0XIvTJK3ouaLDCGANjTzxqIpMXxCqtD4d Sn/jH88LXwt4JOiZXlE8XqqhBHYN8kHZvSapLHYBlyEzqCAFaotjamnbFubwXXwhbNQl somv99XSBT51N5Mbb1YPGf020vOd/7IjKeAsuzqwSYC2PLDA3xuFOi0ejPFLd+aZ32AI t1hahI9Ly1iir67EEiti7siB4BETqrxUQkbVoT7RWQaXINGp5SysPmMGa48f0d/Ee7ca hymwG7BexNq+/jlR//zzVetAMoyujraHeM4X2jdr10X9Ru9oegeMQp08XJyz8OvQw7mN T0kw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MQSgqDm+w1QrI7SDrhIm5tBK0nf9gZSWz2Lwd67aUu8=; b=TO43dXHMijxMdBwPHah3lNMFxAuYWzk+CriSiQrjIZjlEl1jjdmJZTot2CrH6mOcgG TQxNF0FHkQlE4vt08s8zAQ0Ix+v1Tvgyz8MZCu6/j/ikT0WXBZgtCFocqUAU8vuAJsi8 SEeiaOjj3HDwoGNOow3L9xxpDA8R8+NiC8VD+nhw0ZL0HjoGIIpAYho6EkGUG3/rTM1t QFG0V7ea8APemqjU8pH3e2FzPoXhveOPrKerOieLvLCR/vRWArbrcmfQk2B5dRpHuYRa GvHeEwlTRxWLgAArm0c1/nW9P/ypu4xIHBflZFN+/rnpLJa7dk46JVqMoAaCObHD5ZYj ywVw==
X-Gm-Message-State: AGRZ1gKimdzYr0oLLa21qy8kA82EnlXIW8xs7O+WFVdyeiaiuOvwSeEK CE+2cZi9QMXI/LDq6pcgGmFOTCUcKAxBDAAPHEeIsgfs
X-Google-Smtp-Source: AJdET5chzueKiyqyxaSB1KseIb5lrGI96yerw9MzqHf0r1GUqQMP+CgBLvPXdk1vt30ksj8ie8XnQFXhwf67irI7K3M=
X-Received: by 2002:a2e:145a:: with SMTP id 26-v6mr1102341lju.116.1542039350066;  Mon, 12 Nov 2018 08:15:50 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Mon, 12 Nov 2018 08:15:49 -0800 (PST)
In-Reply-To: <5d8a14f4-94a9-c6eb-4a7c-6d6a155e0c84@cisco.com>
References:  <5d8a14f4-94a9-c6eb-4a7c-6d6a155e0c84@cisco.com>
From: Andy Bierman 
Date: Mon, 12 Nov 2018 08:15:49 -0800
Message-ID: 
To: Robert Wilton 
Cc: NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000b0d9b7057a7a03ce"
Archived-At: 
Subject: Re: [netmod] missing YANG versioning requirements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2018 16:15:55 -0000

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

On Mon, Nov 12, 2018 at 7:01 AM, Robert Wilton  wrote:

>
>
> On 09/11/2018 18:35, Andy Bierman wrote:
>
> Hi,
>
> I think the requirements doc should state that
>
> 1) there are many more readers, operators, and client developers than
> server developers so the solution MUST take into account the numbers
> of people affected when finding a balance between client and server
> complexity.
>
> OK.  So you would like the solution to be weighted towards clients, but
> yet you do not want servers to have to implement any sort of version
> selection, instead pushing the problem on to the client? :-)
>
>

I support some aspects of this work:
  - SEMVER
  - import-stmt
  - status-stmt

I strongly oppose the simultaneous implemented revisions requirement
because it is actually
a solution, not a requirement at all, and a bad solution.

For any given buggy data node, a replacement sibling can be created so the
new node and the deprecated
buggy node can both be implemented.

YANG represents a customer-facing API, like the CLI.  Vendors understand
that customers
don't like it when CLI keywords change meaning from release to release.
Vendors are careful
to introduce new keywords so the old ones keep working.



> More seriously, I'm looking for a solution where we it up to the market to
> decide whether the complexity should be pushed to client, server, or a 3rd
> party controller.  I think that some sort of version selection should be
> able to achieve this.
>
>
>
I do not agree the standards should be changed to support this solution
approach.


>
> 2) if existing protocol and YANG solutions exist then they MUST be used
> in favor of developing new solutions.
>
> If you replace the "MUST" with a "SHOULD" then I sort of think that this
> one is obvious.  I think that we are only trying to develop next solutions
> where the existing ones do not appear to be working well.  There are
> examples in the earlier text in the requirements draft, and also
> draft-clacla-netmod-yang-model-update to provide the background and
> justify why we need to do something different than the status quo.
>
>

It would help to have real examples where deprecate-and-replace was an
unworkable solution.
IMO it is OK to update a data node because sub-statements are incorrect
(e.g. pattern, type).
In this case, the old definition is not worth preserving.

Note that changes between I-Ds are not interesting.  Only changes from RFC
to RFC are interesting.
Vendors need to review their own modules and do a better job identifying
stable vs. unstable releases.


Thanks,
> Rob
>
>

Andy


>
>
>
> Andy
>
>
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>

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




On Mon, Nov 12, 2018 at 7:01 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    


    

    

    
On 09/11/2018 18:3=
5, Andy Bierman
      wrote:

    

    

     =20
      
Hi,
        


        

        
I think the requirements doc should state that

        


        

        
1) there are many more readers, operators, and client
          developers than

        
server developers so the solution MUST take into account
          the numbers

        
of people affected when finding a balance between client
          and server complexity.

      

    

    OK.=C2=A0 So you would like the solution to be weighted towards clients=
,
    but yet you do not want servers to have to implement any sort of
    version selection, instead pushing the problem on to the client? :-)
    


I support som=
e aspects of this work:
=C2=A0 - SEMVER
=C2=A0 - import=
-stmt
=C2=A0 - status-stmt

I strongly op=
pose the simultaneous implemented revisions requirement because it is actua=
lly
a solution, not a requirement at all, and a bad solution.

For any given buggy data node, a replacement sibling =
can be created so the new node and the deprecated
buggy node can =
both be implemented.

YANG represents a customer-fa=
cing API, like the CLI.=C2=A0 Vendors understand that customers
d=
on't like it when CLI keywords change meaning from release to release.=
=C2=A0 Vendors are careful
to introduce new keywords so the old o=
nes keep working.

=C2=A0

    More seriously, I'm looking for a solution where we it up to the
    market to decide whether the complexity should be pushed to client,
    server, or a 3rd party controller.=C2=A0 I think that some sort of
    version selection should be able to achieve this.

    

    

I do not agree the standards=
 should be changed to support this solution approach.
=C2=A0

    

      

        


        

        
2) if existing protocol and YANG solutions exist then they
          MUST be used

        
in favor of developing new solutions.

      

    

    If you replace the "MUST" with a "SHOULD" then I so=
rt of think that
    this one is obvious.=C2=A0 I think that we are only trying to develop
    next solutions where the existing ones do not appear to be working
    well.=C2=A0 There are examples in the earlier text in the requirements
    draft, and also draft-clacla-netmod-yang-model-update to provide t=
he
    background and justify why we need to do something different than
    the status quo.

    


It would help=
 to have real examples where deprecate-and-replace was an unworkable soluti=
on.
IMO it is OK to update a data node because sub-statements are=
 incorrect (e.g. pattern, type).
In this case, the old definition=
 is not worth preserving.

Note that changes betwee=
n I-Ds are not interesting.=C2=A0 Only changes from RFC to RFC are interest=
ing.
Vendors need to review their own modules and do a better job=
 identifying stable vs. unstable releases.



    Thanks,

    Rob

    


Andy
=C2=A0

    

    

      

        


        

        


        

        
Andy

        


        

      

      

      

      

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


    

    

  






--000000000000b0d9b7057a7a03ce--


From nobody Mon Nov 12 08:22: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 DCC3C130E1D for ; Mon, 12 Nov 2018 08:21: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O__MF7_fv_eq for ; Mon, 12 Nov 2018 08:21:57 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9665912F1AC for ; Mon, 12 Nov 2018 08:21:57 -0800 (PST)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 0DE1E1AE0290; Mon, 12 Nov 2018 17:21:56 +0100 (CET)
Date: Mon, 12 Nov 2018 17:21:55 +0100 (CET)
Message-Id: <20181112.172155.1599685820248587823.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20181109165512.6f3hi55mv2kc3qlp@anna.jacobs.jacobs-university.de>
References: <20181109151347.3xms2cty6hxyl232@anna.jacobs.jacobs-university.de> <20181109.173159.1522007243611164311.mbj@tail-f.com> <20181109165512.6f3hi55mv2kc3qlp@anna.jacobs.jacobs-university.de>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2018 16:22:00 -0000

Juergen Schoenwaelder  wrote:
> On Fri, Nov 09, 2018 at 05:31:59PM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
> > > > 
> > > > > I think we need to distinguish between the agreement on the
> > > > > requirement, namely that a server should be able to provide support
> > > > > for an old and a new definition, and agreement on the solution.
> > > > > 
> > > > > Do you disagree with the requirement? Or do you disagree with the
> > > > > consequences of implementing multiple versions of the same module
> > > > > for some of the proposed new versioning schemes? Or both?
> > > > 
> > > > I do not agree with the requirement that a server MUST be able to
> > > > support multiple revisions of the same module, which is how I
> > > > interpret 3.2.  If this is not the intention of 3.2, maybe it can be
> > > > clarified.
> > > >
> > > 
> > > Here is what 3.2 says:
> > > 
> > >        3.2  The solution MUST provide a mechanism to allow servers to
> > >             simultaneously support clients using different revisions of
> > >             modules.  A client's choice of particular revision of one or
> > >             more modules may restrict the particular revision of other
> > >             modules that may be used in the same request or session.
> > > 
> > > This does _not_ say servers MUST implement this.
> > > 
> > > Item 3.2 establishes a requirement and for some solutions it may be
> > > easy to satisfy this requirement, for others it may be more costly to
> > > satisfy this requirement.
> > > 
> > > The whole requirements exercise becomes a rather pointless exercise if
> > > we remove requirements so that certain solutions look more
> > > attractive.
> > 
> > Ok, but that's not what I wrote.  I don't agree with this requirement
> > which says that it MUST be possible for a server to support
> > different revisions of a given module (again, if this is not the
> > intention of the text, please clarify).  I simply don't think that
> > this is a good requirement.
> >
> 
> I can't follow you or I do not understand what you are after.
> 
>   In some versioning schemes, providing support for different
>   'versions' is relatively easy. If I have modules foo-1 and foo-2,
>   then I can implement foo-1 and foo-2 (or proper workable subsets of
>   them) easily. And older clients expecting foo-1 may continue to work
>   while newer clients move to foo-2. In other versioning schemes,
>   providing the same possibility to migrate from foo version 1 to foo
>   version 2, would lead to the support of foo in two different
>   versions.

But module 'foo-2' is not a new revision of module 'foo-1'.  It might
be that 'foo-2' represents a new version of the underlying "function"
that 'foo-1' represents; but that is a different issue.


> The requirement tries to express that it must be possible to have a
> transition path where old clients can continue to function with the
> old version while new clients start using the new version. The idea is
> to state this as a requirement without making any assumptions about
> the solutions.
> 
> Are you saying that a requirement saying that there should be a
> possibility of a transition path is in general a bad requirement?

No (but I agree w/ Rob Wilton that it is unclear how this should be
done in non-trivial examples), but again, that is not what I think 3.2
says.  IMO 3.2 doesn't allow a solution that requires a new module for
new NBC stuff, since it says that a client should be able to pick a
particular revision of a module.


/martin




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


From nobody Mon Nov 12 08:26:16 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58034130E1D for ; Mon, 12 Nov 2018 08:26:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 E3jEZ_YChY_m for ; Mon, 12 Nov 2018 08:26:07 -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 E178012F1AC for ; Mon, 12 Nov 2018 08:26:06 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 33FCAE1F; Mon, 12 Nov 2018 17:26:05 +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 RQb6bWgQdHTq; Mon, 12 Nov 2018 17:26:02 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 12 Nov 2018 17:26:05 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 340A82003D; Mon, 12 Nov 2018 17:26:05 +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 CMUM2koApG66; Mon, 12 Nov 2018 17:26:04 +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 7855A2003C; Mon, 12 Nov 2018 17:26:04 +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, 12 Nov 2018 17:26:03 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 3947B30040D286; Mon, 12 Nov 2018 17:26:02 +0100 (CET)
Date: Mon, 12 Nov 2018 17:26:02 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
CC: , 
Message-ID: <20181112162602.crxyh7ubjwbphmcl@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org
References: <20181109151347.3xms2cty6hxyl232@anna.jacobs.jacobs-university.de> <20181109.173159.1522007243611164311.mbj@tail-f.com> <20181109165512.6f3hi55mv2kc3qlp@anna.jacobs.jacobs-university.de> <20181112.172155.1599685820248587823.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20181112.172155.1599685820248587823.mbj@tail-f.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2018 16:26:14 -0000

On Mon, Nov 12, 2018 at 05:21:55PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Fri, Nov 09, 2018 at 05:31:59PM +0100, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  wrote:
> > > > On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
> > > > > 
> > > > > > I think we need to distinguish between the agreement on the
> > > > > > requirement, namely that a server should be able to provide support
> > > > > > for an old and a new definition, and agreement on the solution.
> > > > > > 
> > > > > > Do you disagree with the requirement? Or do you disagree with the
> > > > > > consequences of implementing multiple versions of the same module
> > > > > > for some of the proposed new versioning schemes? Or both?
> > > > > 
> > > > > I do not agree with the requirement that a server MUST be able to
> > > > > support multiple revisions of the same module, which is how I
> > > > > interpret 3.2.  If this is not the intention of 3.2, maybe it can be
> > > > > clarified.
> > > > >
> > > > 
> > > > Here is what 3.2 says:
> > > > 
> > > >        3.2  The solution MUST provide a mechanism to allow servers to
> > > >             simultaneously support clients using different revisions of
> > > >             modules.  A client's choice of particular revision of one or
> > > >             more modules may restrict the particular revision of other
> > > >             modules that may be used in the same request or session.
> > > > 
> > > > This does _not_ say servers MUST implement this.
> > > > 
> > > > Item 3.2 establishes a requirement and for some solutions it may be
> > > > easy to satisfy this requirement, for others it may be more costly to
> > > > satisfy this requirement.
> > > > 
> > > > The whole requirements exercise becomes a rather pointless exercise if
> > > > we remove requirements so that certain solutions look more
> > > > attractive.
> > > 
> > > Ok, but that's not what I wrote.  I don't agree with this requirement
> > > which says that it MUST be possible for a server to support
> > > different revisions of a given module (again, if this is not the
> > > intention of the text, please clarify).  I simply don't think that
> > > this is a good requirement.
> > >
> > 
> > I can't follow you or I do not understand what you are after.
> > 
> >   In some versioning schemes, providing support for different
> >   'versions' is relatively easy. If I have modules foo-1 and foo-2,
> >   then I can implement foo-1 and foo-2 (or proper workable subsets of
> >   them) easily. And older clients expecting foo-1 may continue to work
> >   while newer clients move to foo-2. In other versioning schemes,
> >   providing the same possibility to migrate from foo version 1 to foo
> >   version 2, would lead to the support of foo in two different
> >   versions.
> 
> But module 'foo-2' is not a new revision of module 'foo-1'.  It might
> be that 'foo-2' represents a new version of the underlying "function"
> that 'foo-1' represents; but that is a different issue.

This depends on the versioning solution or what we consider a versioning
solution.

> > The requirement tries to express that it must be possible to have a
> > transition path where old clients can continue to function with the
> > old version while new clients start using the new version. The idea is
> > to state this as a requirement without making any assumptions about
> > the solutions.
> > 
> > Are you saying that a requirement saying that there should be a
> > possibility of a transition path is in general a bad requirement?
> 
> No (but I agree w/ Rob Wilton that it is unclear how this should be
> done in non-trivial examples), but again, that is not what I think 3.2
> says.  IMO 3.2 doesn't allow a solution that requires a new module for
> new NBC stuff, since it says that a client should be able to pick a
> particular revision of a module.
>

We apparently lack words for modules that may be versioned by new
module names.

/js

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


From nobody Mon Nov 12 08:29: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 410AD130E1D for ; Mon, 12 Nov 2018 08:29:28 -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 tc_XqgyyntK6 for ; Mon, 12 Nov 2018 08:29:27 -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 707AE130E53 for ; Mon, 12 Nov 2018 08:29:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2738; q=dns/txt; s=iport; t=1542040164; x=1543249764; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=8fhWIFSkXGkjzz5+islBrOFCa+iaPPcRtW6TR9WycHw=; b=M/T0eaSthDtmFIVG2VgkOPeOpap0tqQCPGpMLjGRPAdgY8P/+dKfAYLw VwemYTtd9zdT/sTPsjMWIcMgGh+vgKl8C3JcKWKhJCKs6yjqD8UVZoTy/ 8EHEDO5eeb35sianQPyGsX9tLHJlOCl9HippbXrVRoU0V5FrwU9zyZpzA I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DcAgDpqOlb/xbLJq1jHAEBAQQBAQc?= =?us-ascii?q?EAQGBZYFWgWMhEoQfiHeNA5lUDYg9OBYBAwEBAgEBAm0dC4VkDwEFdgImAl8?= =?us-ascii?q?NCAEBgx2CAqlWgS+FPoRmgQuLDIFAP4E4DIIyAYUUgxqCVwKJPpYRCYFijzU?= =?us-ascii?q?GGIlWhxqRIIZYgVohgVUzGggbFYMokFk/A45EAQE?=
X-IronPort-AV: E=Sophos;i="5.54,495,1534809600";  d="scan'208";a="7998906"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2018 16:29:22 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id wACGTLY1003300 for ; Mon, 12 Nov 2018 16:29:21 GMT
To: "netmod@ietf.org" 
From: Robert Wilton 
Message-ID: 
Date: Mon, 12 Nov 2018 16:29:20 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
Subject: [netmod] Deviations and augmentations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2018 16:29:28 -0000

In the Thursday Netmod meeting, it was interesting to hear Rob Shakir 
describe how deviations and augmentations are used in OpenConfig to add 
functionality into an older YANG model where the semver rules prevent 
the version number from being incremented.

Further, I think that someone (Martin?) stated on the audio bridge that 
this was an intended/allowed behavior for deviations.

This surprised me, because I thought that RFC 7950 was quite explicit 
that this is not what deviations are intended for.  My reading of RFC 
7950 is that the deviation statement represents the case where the 
server *implementation* does not match the *specification*.  However, 
the versioning issue that we are discussing are bug fixes/changes in the 
specification rather than the bug fixes in the implementation.

Personally, I'm really not keen on using deviations to represent bug 
fixes to older YANG models for three reasons:

(i) It is changing the meaning of deviation.  It is much cleaner to keep 
the meaning of deviation statements as they are defined today, and not 
conflate their semantics.
(ii) A different mechanism is used to put a bug fix into an older branch 
rather than in the head of the development.
(iii) For clients to track the lifecycle of modules they would not only 
need to know the module version number but would also need to find and 
track all associated deviation modules.  This seems significantly more 
complex for clients than the modified semver that was proposed.

---

I think that has also been some suggestion that augmentations (or 
duplicate YANG modules with their major version number changed) can be 
used to make bug fixes in a completely backwards compatible way.  
However, I still don't understand a robust scheme of how this works.

---

Finally, there were some comments about using augmentation modules for 
enhancements.  This is fine, where appropriate (e.g. a non trivial 
number of data nodes are being added as an enhancement) then a separate 
module may be the right way to go. But here, I presume that the new 
functionality will always be tracked by that separate module.  If that 
functionality folds back into the original module at some point in the 
future, then obviously a non backwards compatible version change is 
being forced on to the client, along with additional work on the server 
as well.

I think that there are also many cases where the number of data nodes 
being added via an enhancement is small compared to the size of the 
module being updated.  In this case I believe that it better to add 
these data nodes into the module itself, perhaps predicated under 
if-feature if appropriate.

Thanks,
Rob



From nobody Mon Nov 12 08:29: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 E863F12F1AC for ; Mon, 12 Nov 2018 08:29:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8jzYCAHJEUL for ; Mon, 12 Nov 2018 08:29:48 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB50130E41 for ; Mon, 12 Nov 2018 08:29:47 -0800 (PST)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 256B61AE0442; Mon, 12 Nov 2018 17:29:46 +0100 (CET)
Date: Mon, 12 Nov 2018 17:29:45 +0100 (CET)
Message-Id: <20181112.172945.713446019460767559.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <96995ddc-f69e-1a91-21b6-36304c8510f3@cisco.com>
References: <20181109151347.3xms2cty6hxyl232@anna.jacobs.jacobs-university.de> <20181109.173159.1522007243611164311.mbj@tail-f.com> <96995ddc-f69e-1a91-21b6-36304c8510f3@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2018 16:29:51 -0000

Robert Wilton  wrote:
> Hi Martin,
> =

> =

> On 09/11/2018 16:31, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:=

> >> On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
> >>>> I think we need to distinguish between the agreement on the
> >>>> requirement, namely that a server should be able to provide supp=
ort
> >>>> for an old and a new definition, and agreement on the solution.
> >>>>
> >>>> Do you disagree with the requirement? Or do you disagree with th=
e
> >>>> consequences of implementing multiple versions of the same modul=
e
> >>>> for some of the proposed new versioning schemes? Or both?
> >>> I do not agree with the requirement that a server MUST be able to=

> >>> support multiple revisions of the same module, which is how I
> >>> interpret 3.2.  If this is not the intention of 3.2, maybe it can=
 be
> >>> clarified.
> >>>
> >> Here is what 3.2 says:
> >>
> >>         3.2  The solution MUST provide a mechanism to allow server=
s to
> >>              simultaneously support clients using different revisi=
ons of
> >>              modules.  A client's choice of particular revision of=
 one or
> >>              more modules may restrict the particular revision of =
other
> >>              modules that may be used in the same request or sessi=
on.
> >>
> >> This does _not_ say servers MUST implement this.
> >>
> >> Item 3.2 establishes a requirement and for some solutions it may b=
e
> >> easy to satisfy this requirement, for others it may be more costly=
 to
> >> satisfy this requirement.
> >>
> >> The whole requirements exercise becomes a rather pointless exercis=
e if
> >> we remove requirements so that certain solutions look more
> >> attractive.
> > Ok, but that's not what I wrote.  I don't agree with this requireme=
nt
> > which says that it MUST be possible for a server to support
> > different revisions of a given module (again, if this is not the
> > intention of the text, please clarify).  I simply don't think that
> > this is a good requirement.
> One way to think of this is as YANG data models defining an API
> between client and server.
> =

> There seem to be lots of REST APIs that implement versioning of their=

> API by having a version number in the URL.

Yes, but that doesn't mean that a given server supports more than one
version seamlessly.  As you wrote, it works fine for operational
state, but it is less obvious how it should work in the general case
for config data.

> In fact, I think that
> RESTCONF adopts this approach to allow versioning of the protocol.
> =

> One solution is as Andy describes.=A0 The underlying server only
> implements one version of the a given YANG module, but they may
> provide other views on to this data using different versions of YANG
> modules.=A0 E.g. the same as how Vendor YANG models, IETF YANG models=
,
> and OpenConfig YANG models might be treated as their own views, mappe=
d
> to the same internal YANG modules.

Yes, but this solution is also problematic; it is not always the case
that clients can pick and choose from these different "views" and get
consistent results, simply b/c the mappings are not 100% one-to-one.


/martin

> =

> Thanks,
> Rob
> =

> =

> >
> >
> > /martin
> >
> >
> >> I have not seen a proposal that addresses all requirements and hen=
ce
> >> at the end the WG needs to decide which tradeoffs make sense.
> >>
> >> /js
> >>
> >> -- =

> >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Ger=
many
> >> Fax:   +49 421 200 3103         
> >>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > .
> >
> =


From nobody Mon Nov 12 08:33: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 A9290130DF2 for ; Mon, 12 Nov 2018 08:33:54 -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 hvWSUbaX6puL for ; Mon, 12 Nov 2018 08:33:53 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 213E112F1AC for ; Mon, 12 Nov 2018 08:33:53 -0800 (PST)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 454511AE0290; Mon, 12 Nov 2018 17:33:52 +0100 (CET)
Date: Mon, 12 Nov 2018 17:33:51 +0100 (CET)
Message-Id: <20181112.173351.1984161388756642220.mbj@tail-f.com>
To: rwilton@cisco.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] Deviations and augmentations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2018 16:33:55 -0000

Robert Wilton  wrote:
> In the Thursday Netmod meeting, it was interesting to hear Rob Shakir=

> describe how deviations and augmentations are used in OpenConfig to
> add functionality into an older YANG model where the semver rules
> prevent the version number from being incremented.
> =

> Further, I think that someone (Martin?) stated on the audio bridge
> that this was an intended/allowed behavior for deviations.

I said that using augmentations (not deviations) was one idea we
originally had for solving the "branching problem".

I think that this works for OC b/c they don't branch their modules.
Hence I think it is important that we decide if branching is a
requirement or not.


/martin


> This surprised me, because I thought that RFC 7950 was quite explicit=

> that this is not what deviations are intended for.=A0 My reading of R=
FC
> 7950 is that the deviation statement represents the case where the
> server *implementation* does not match the *specification*.=A0 Howeve=
r,
> the versioning issue that we are discussing are bug fixes/changes in
> the specification rather than the bug fixes in the implementation.
> =

> Personally, I'm really not keen on using deviations to represent bug
> fixes to older YANG models for three reasons:
> =

> (i) It is changing the meaning of deviation.=A0 It is much cleaner to=

> keep the meaning of deviation statements as they are defined today,
> and not conflate their semantics.
> (ii) A different mechanism is used to put a bug fix into an older
> branch rather than in the head of the development.
> (iii) For clients to track the lifecycle of modules they would not
> only need to know the module version number but would also need to
> find and track all associated deviation modules.=A0 This seems
> significantly more complex for clients than the modified semver that
> was proposed.
> =

> ---
> =

> I think that has also been some suggestion that augmentations (or
> duplicate YANG modules with their major version number changed) can b=
e
> used to make bug fixes in a completely backwards compatible way.=A0
> However, I still don't understand a robust scheme of how this works.
> =

> ---
> =

> Finally, there were some comments about using augmentation modules fo=
r
> enhancements.=A0 This is fine, where appropriate (e.g. a non trivial
> number of data nodes are being added as an enhancement) then a
> separate module may be the right way to go. But here, I presume that
> the new functionality will always be tracked by that separate module.=
=A0
> If that functionality folds back into the original module at some
> point in the future, then obviously a non backwards compatible versio=
n
> change is being forced on to the client, along with additional work o=
n
> the server as well.
> =

> I think that there are also many cases where the number of data nodes=

> being added via an enhancement is small compared to the size of the
> module being updated.=A0 In this case I believe that it better to add=

> these data nodes into the module itself, perhaps predicated under
> if-feature if appropriate.
> =

> Thanks,
> Rob
> =

> =

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


From nobody Mon Nov 12 08:46:35 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB5D130E6D for ; Mon, 12 Nov 2018 08:46:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvRzikOKt5iE for ; Mon, 12 Nov 2018 08:46:23 -0800 (PST)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 9592D130E0E for ; Mon, 12 Nov 2018 08:46:23 -0800 (PST)
Received: by mail-pg1-x529.google.com with SMTP id n10-v6so4303196pgv.10 for ; Mon, 12 Nov 2018 08:46:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=fX5gcIMI2kVrL4FRb3znTjqBFyLHCZavUvRUSZIxNzg=; b=EHgsA2uFBkCbdkDzhpiftKOkayesrnstxAVgmBDQC93rsxVV11tWxSF25qDgN+aZWn F0piXv5XR1iv0FRSfIo2a3RIxc3/CpgTP1WtUUhaRsoiZCct6Eat+qEJdFJEbGcRz/r1 p51YiCbUoELTKguHIH8/6sseRDVxln7ykong7U8DzKyKElmGwcBbeksVHwETnqm62PXD MnVuDX5L3Bi1g6LXGxKk1t+XSyBJGxNVhA/Z2vdZ+R6JGndLfTMcowm/ZGiXUo46vPLi 54CwZO+gWG/DMGLYPZYEvZJG2G7GwlNNeGtir0HR5i6jZ2nvOf3EuLXh1or59CHdmAoo 15Bw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=fX5gcIMI2kVrL4FRb3znTjqBFyLHCZavUvRUSZIxNzg=; b=NLQ6SXER+A8RxziS3DcYWV6wdw3laopsCrwi8OzsVUWsFw4mq/ej/Uw96jA1DoA2mp wanhmqFzl6UB9GNhEKajAki1QXTqg3P0za9zZlAVA5/VVxQXIvAYRLjs5X1HECMiEDnc tlsv20dHq2D3YoHgeGfQnSBV1vhs51Q/nFNsbKAsOvBULANcr6fQN7jmbb2on1vN5Ut5 iZariRvXHVukYJjxqK3QguUklYdCXb18HnDoOrDx7kX/d8trrmoeCxzIJUa/MpmRSNYI tex3jgsIr92xJvM2MvkS6+Y+7wPL6TuBeydVvMZ4P2XNRoLg1w9a0cMBEI4UY0FFE9J9 cgaA==
X-Gm-Message-State: AGRZ1gLDN4kYdmYm5AzZGt3WGPPXWfEOkWQ318CgmhFeG5wiq+7bFWtr tRem/AoP1Kjd6PwL4gbAB23EE9JC
X-Google-Smtp-Source: AJdET5dzNy0WCXfOVuJXxysTzeBxUUmjwzj3HTThD+az6ohpSxSOWJRRYT3/Zn2o14j01RTthVW17Q==
X-Received: by 2002:a63:ee4c:: with SMTP id n12mr1409021pgk.21.1542041182549;  Mon, 12 Nov 2018 08:46:22 -0800 (PST)
Received: from [192.168.0.109] (c-73-202-177-209.hsd1.ca.comcast.net. [73.202.177.209]) by smtp.gmail.com with ESMTPSA id q128-v6sm18369611pfb.160.2018.11.12.08.46.21 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Nov 2018 08:46:21 -0800 (PST)
From: joel jaeggli 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Message-Id: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>
Date: Mon, 12 Nov 2018 08:46:17 -0800
To: NETMOD Working Group 
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: 
Subject: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2018 16:46:33 -0000

During the Thursday nov 8 session of netmod, we asked if there were any =
objections to the publication of the Draft-03 version of =
draft-ietf-netmod-module-tags which addresses comments and concerns =
raised during the WGLC. In the meeting there were none. This commences a =
comment period to confirm that call. As this follows closely on the =
heels of the IETF 103 meeting we=E2=80=99ll let the call run through =
Monday the 26th of November.=20

https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-module-tags-03.txt=



Thanks
Joel=


From nobody Mon Nov 12 09:04: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 ECA61128CB7 for ; Mon, 12 Nov 2018 09:04:39 -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 DVuZBjIwYsv4 for ; Mon, 12 Nov 2018 09:04:37 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43AA012896A for ; Mon, 12 Nov 2018 09:04:37 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id n18so6708320lfh.6 for ; Mon, 12 Nov 2018 09:04:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9vOg4LBKW3Xm8KgZv8t+h3XEbFeQZyMgDO+tHKHSKpM=; b=sAjZOfsFeAMSXO1Gf61rPAYHYr9mkgAiA6BSqcjVxtlYB9lrtOPHFNeDW64YDYCbsg SvPghTBPbJkt1C7V/gVpr69KUG6h/thKrAz/1XSsxex0QVqmmwuwdPEL5bEJNJdpBNcw LdknXngYnPA2OrGjcGUwwp5p0Whiav3Md09oN8XUOd5AH7BC/xSqh70Pvbw5AuvgEBKI gVUC+tgWAqnPG/nMf//6s1b85Ueucb5fAzsxhWgw5JX0TDbyDYuojgMyJ5/3rXRL1CR+ HhjRaUpUWpX4xDWDRJQqYAtR/uxcssiOAkEm0R4aXhiTPyNis/HmuWymgoG1U+rSmptY m2nA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9vOg4LBKW3Xm8KgZv8t+h3XEbFeQZyMgDO+tHKHSKpM=; b=A1t5jdexKKdOsnk+OAgfI6UR3fQODYutbNidjtGgkf3YnIVDkW0ZeQSbULQK4e1SLH hmYR8TEkL4X9n5aPVrqotfr5lmjgKdrWoePb5YComQgWyU4Q0ozEf2QykC7DZTp7QscW 8Hek5DO21g+p9eNYfHlJ9wJg4ZPlMHXQWfv5DH6JEZXBLpqEamIrQgTJ/sUER29drtKq +kdDOJ99Uzi3Yqhi8Z6iR3rK2AisuVb9rnd7Wrl19SQCP664ZcsiKBeSM3C7OYRGqNTr auU3yk9XXi7SyXxXzviQYWTj2GjK+BqDLM7yI/vkVCW3Zs3/lBEcYCWdZsH9iGIXbAle l0hQ==
X-Gm-Message-State: AGRZ1gKNsQc/LuK0spGRznMrCT34LrGs8YRuicK59vdI46+sE91ycwtN yb7z1pQYD9PP856uhqkWLG2XfJH39FLcZ3sK5qO6QQ==
X-Google-Smtp-Source: AJdET5dLGTcFU7mJHs3Divj/enm8KZPErCxVA4adpYJsKevFx4KZxO8qlgNA6zkCm2Ss41lIyjGqXwMDcvMJaBMEe4k=
X-Received: by 2002:a19:690d:: with SMTP id e13mr1104887lfc.84.1542042275270;  Mon, 12 Nov 2018 09:04:35 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Mon, 12 Nov 2018 09:04:34 -0800 (PST)
In-Reply-To: <20181112.173351.1984161388756642220.mbj@tail-f.com>
References:  <20181112.173351.1984161388756642220.mbj@tail-f.com>
From: Andy Bierman 
Date: Mon, 12 Nov 2018 09:04:34 -0800
Message-ID: 
To: Martin Bjorklund 
Cc: Robert Wilton , NetMod WG 
Content-Type: multipart/alternative; boundary="0000000000000beab7057a7ab2bf"
Archived-At: 
Subject: Re: [netmod] Deviations and augmentations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2018 17:04:40 -0000

--0000000000000beab7057a7ab2bf
Content-Type: text/plain; charset="UTF-8"

On Mon, Nov 12, 2018 at 8:33 AM, Martin Bjorklund  wrote:

> Robert Wilton  wrote:
> > In the Thursday Netmod meeting, it was interesting to hear Rob Shakir
> > describe how deviations and augmentations are used in OpenConfig to
> > add functionality into an older YANG model where the semver rules
> > prevent the version number from being incremented.
> >
> > Further, I think that someone (Martin?) stated on the audio bridge
> > that this was an intended/allowed behavior for deviations.
>
> I said that using augmentations (not deviations) was one idea we
> originally had for solving the "branching problem".
>
> I think that this works for OC b/c they don't branch their modules.
> Hence I think it is important that we decide if branching is a
> requirement or not.
>
>
Branching is a solution, not a requirement.
IMO deviate(not-supported) is intended to let the server describe what it
supports
without requiring branching. Clients already support deviations.



>
> /martin
>

Andy


>
>
> > This surprised me, because I thought that RFC 7950 was quite explicit
> > that this is not what deviations are intended for.  My reading of RFC
> > 7950 is that the deviation statement represents the case where the
> > server *implementation* does not match the *specification*.  However,
> > the versioning issue that we are discussing are bug fixes/changes in
> > the specification rather than the bug fixes in the implementation.
> >
> > Personally, I'm really not keen on using deviations to represent bug
> > fixes to older YANG models for three reasons:
> >
> > (i) It is changing the meaning of deviation.  It is much cleaner to
> > keep the meaning of deviation statements as they are defined today,
> > and not conflate their semantics.
> > (ii) A different mechanism is used to put a bug fix into an older
> > branch rather than in the head of the development.
> > (iii) For clients to track the lifecycle of modules they would not
> > only need to know the module version number but would also need to
> > find and track all associated deviation modules.  This seems
> > significantly more complex for clients than the modified semver that
> > was proposed.
> >
> > ---
> >
> > I think that has also been some suggestion that augmentations (or
> > duplicate YANG modules with their major version number changed) can be
> > used to make bug fixes in a completely backwards compatible way.
> > However, I still don't understand a robust scheme of how this works.
> >
> > ---
> >
> > Finally, there were some comments about using augmentation modules for
> > enhancements.  This is fine, where appropriate (e.g. a non trivial
> > number of data nodes are being added as an enhancement) then a
> > separate module may be the right way to go. But here, I presume that
> > the new functionality will always be tracked by that separate module.
> > If that functionality folds back into the original module at some
> > point in the future, then obviously a non backwards compatible version
> > change is being forced on to the client, along with additional work on
> > the server as well.
> >
> > I think that there are also many cases where the number of data nodes
> > being added via an enhancement is small compared to the size of the
> > module being updated.  In this case I believe that it better to add
> > these data nodes into the module itself, perhaps predicated under
> > if-feature if appropriate.
> >
> > Thanks,
> > Rob
> >
> >
> > _______________________________________________
> > 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
>

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




On Mon, Nov 12, 2018 at 8:33 AM, Martin Bjorklund <=
;mbj@tail-f.com>=
 wrote:
Robert Wilton <rwilton@cisco.com> wrote:

> In the Thursday Netmod meeting, it was interesting to hear Rob Shakir<=
br>
> describe how deviations and augmentations are used in OpenConfig to
> add functionality into an older YANG model where the semver rules

> prevent the version number from being incremented.

> 

> Further, I think that someone (Martin?) stated on the audio bridge

> that this was an intended/allowed behavior for deviations.



I said that using augmentations (not deviations) was one idea we

originally had for solving the "branching problem".



I think that this works for OC b/c they don't branch their modules.

Hence I think it is important that we decide if branching is a

requirement or not.



Branching is a solution, not a require=
ment.
IMO deviate(not-supported) is intended to let the server de=
scribe what it supports
without requiring branching. Clients alre=
ady support deviations.

=C2=A0



/martin

Andy
=C2=A0





> This surprised me, because I thought that RFC 7950 was quite explicit<=
br>
> that this is not what deviations are intended for.=C2=A0 My reading of=
 RFC

> 7950 is that the deviation statement represents the case where the

> server *implementation* does not match the *specification*.=C2=A0 Howe=
ver,

> the versioning issue that we are discussing are bug fixes/changes in
> the specification rather than the bug fixes in the implementation.

> 

> Personally, I'm really not keen on using deviations to represent b=
ug

> fixes to older YANG models for three reasons:

> 

> (i) It is changing the meaning of deviation.=C2=A0 It is much cleaner =
to

> keep the meaning of deviation statements as they are defined today,
> and not conflate their semantics.

> (ii) A different mechanism is used to put a bug fix into an older

> branch rather than in the head of the development.

> (iii) For clients to track the lifecycle of modules they would not

> only need to know the module version number but would also need to

> find and track all associated deviation modules.=C2=A0 This seems

> significantly more complex for clients than the modified semver that
> was proposed.

> 

> ---

> 

> I think that has also been some suggestion that augmentations (or

> duplicate YANG modules with their major version number changed) can be=


> used to make bug fixes in a completely backwards compatible way.=C2=A0=


> However, I still don't understand a robust scheme of how this work=
s.

> 

> ---

> 

> Finally, there were some comments about using augmentation modules for=


> enhancements.=C2=A0 This is fine, where appropriate (e.g. a non trivia=
l

> number of data nodes are being added as an enhancement) then a

> separate module may be the right way to go. But here, I presume that
> the new functionality will always be tracked by that separate module.=
=C2=A0

> If that functionality folds back into the original module at some

> point in the future, then obviously a non backwards compatible version=


> change is being forced on to the client, along with additional work on=


> the server as well.

> 

> I think that there are also many cases where the number of data nodes<=
br>
> being added via an enhancement is small compared to the size of the
> module being updated.=C2=A0 In this case I believe that it better to a=
dd

> these data nodes into the module itself, perhaps predicated under

> if-feature if appropriate.

> 

> Thanks,

> Rob

> 

> 

> _______________________________________________

> 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




--0000000000000beab7057a7ab2bf--


From nobody Mon Nov 12 09:08: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 88E33130DF2 for ; Mon, 12 Nov 2018 09:08:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level: 
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIn6MLMp_daQ for ; Mon, 12 Nov 2018 09:08:45 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB6D128CB7 for ; Mon, 12 Nov 2018 09:08:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4082; q=dns/txt; s=iport; t=1542042525; x=1543252125; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=wB3aWoSEdWfgUynWO+X0eD+D7ZMv+M0nmrWB+gNN6bc=; b=dor3TTfCA9eA3PpdS2AbFRRxJnHb//3ONbGSgjcSl6ejN7C9TMvo7Wlq +zYTgZJcqbSlpM1luDbf0LodPZpxDb22JPfOmf5EeuJS5jDwt0SrxmuND CSOWi/Oz6LHgNphAkqrh2uMKZ5qQ4hEt0R6/AMlvcyY9jik1RxbRAOOqN o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AaAACPsulb/xbLJq1jGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUwQBAQELAYJpTyESJ4N4iHeNAyWXNYF6DRgLhANGAoNPNgsNAQM?= =?us-ascii?q?BAQIBAQJtHAyFOgEBAQMBAQEhDwEFNgsQCw4KAgImAgInMAYNBgIBAReDBgG?= =?us-ascii?q?BeQgPqTGBL4U+hGMFgQuLDIFAP4E4DIFhfoMbAQGBS4MaglcCiT6WEQmJYYc?= =?us-ascii?q?2BhiJVocakSCGWIFKByqBVTMaCBsVO4JsgicXiF6FPj8DMI4UAQE?=
X-IronPort-AV: E=Sophos;i="5.54,495,1534809600";  d="scan'208";a="7996274"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2018 17:08:42 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id wACH8gPP021240; Mon, 12 Nov 2018 17:08:42 GMT
To: Martin Bjorklund 
Cc: netmod@ietf.org
References:  <20181112.173351.1984161388756642220.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: 
Date: Mon, 12 Nov 2018 17:08:42 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20181112.173351.1984161388756642220.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] Deviations and augmentations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2018 17:08:47 -0000

On 12/11/2018 16:33, Martin Bjorklund wrote:
> Robert Wilton  wrote:
>> In the Thursday Netmod meeting, it was interesting to hear Rob Shakir
>> describe how deviations and augmentations are used in OpenConfig to
>> add functionality into an older YANG model where the semver rules
>> prevent the version number from being incremented.
>>
>> Further, I think that someone (Martin?) stated on the audio bridge
>> that this was an intended/allowed behavior for deviations.
> I said that using augmentations (not deviations) was one idea we
> originally had for solving the "branching problem".
Ah, OK. I agree that makes sense.

>
> I think that this works for OC b/c they don't branch their modules.
> Hence I think it is important that we decide if branching is a
> requirement or not.
So, I think that this probably works for adding enhancements, but not 
for the (arguably more important) bug fix case, unless there is a 
reasonable solution to having two config data nodes both modifying the 
same underlying property.  Perhaps under some reasonable constraints 
this could be made to work - but I don't know.

Of course, even for enhancements it is not necessarily a perfect 
solution.  E.g. backporting some subset of a module already 
coded/implemented in latest to an older release.  And yes, we really do 
get asked to do this sometimes, although it is relatively rare.

Thanks,
Rob

>
>
> /martin
>
>
>> This surprised me, because I thought that RFC 7950 was quite explicit
>> that this is not what deviations are intended for.  My reading of RFC
>> 7950 is that the deviation statement represents the case where the
>> server *implementation* does not match the *specification*.  However,
>> the versioning issue that we are discussing are bug fixes/changes in
>> the specification rather than the bug fixes in the implementation.
>>
>> Personally, I'm really not keen on using deviations to represent bug
>> fixes to older YANG models for three reasons:
>>
>> (i) It is changing the meaning of deviation.  It is much cleaner to
>> keep the meaning of deviation statements as they are defined today,
>> and not conflate their semantics.
>> (ii) A different mechanism is used to put a bug fix into an older
>> branch rather than in the head of the development.
>> (iii) For clients to track the lifecycle of modules they would not
>> only need to know the module version number but would also need to
>> find and track all associated deviation modules.  This seems
>> significantly more complex for clients than the modified semver that
>> was proposed.
>>
>> ---
>>
>> I think that has also been some suggestion that augmentations (or
>> duplicate YANG modules with their major version number changed) can be
>> used to make bug fixes in a completely backwards compatible way.
>> However, I still don't understand a robust scheme of how this works.
>>
>> ---
>>
>> Finally, there were some comments about using augmentation modules for
>> enhancements.  This is fine, where appropriate (e.g. a non trivial
>> number of data nodes are being added as an enhancement) then a
>> separate module may be the right way to go. But here, I presume that
>> the new functionality will always be tracked by that separate module.
>> If that functionality folds back into the original module at some
>> point in the future, then obviously a non backwards compatible version
>> change is being forced on to the client, along with additional work on
>> the server as well.
>>
>> I think that there are also many cases where the number of data nodes
>> being added via an enhancement is small compared to the size of the
>> module being updated.  In this case I believe that it better to add
>> these data nodes into the module itself, perhaps predicated under
>> if-feature if appropriate.
>>
>> Thanks,
>> Rob
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Mon Nov 12 09:14: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 51D6E12896A for ; Mon, 12 Nov 2018 09:14:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9e39eJ9vWxJ for ; Mon, 12 Nov 2018 09:14:23 -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 298E2130DF2 for ; Mon, 12 Nov 2018 09:14:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4691; q=dns/txt; s=iport; t=1542042863; x=1543252463; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=sQNMs9IXGj9Z4IBSeFzwkqQs916MEkiBrr049je/Fnw=; b=bNXX/KHXsw7givu0QNO+YzhGPH/70/sxSwar7GyaWfBO+1ydRs+zvhr0 SFw4kfXN5GVTOYPzz06ZSmNnxr3OXt+0okTKwgIXkAKNQT9EaU/EnyLze kA0+WHROsJsXAhAObkVU6HFNa8kBgYA53XIPURKY/E+GZ4SQ67fjeFR2S Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAAAztOlb/xbLJq1ZBwMZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBAYFUAQEBAQEBCwGCaU8hEieDeIh3jQMlmS8NGAuEA0Y?= =?us-ascii?q?Cg083Cg0BAwEBAgEBAm0cDIU6AQEBAwEBASEPAQU2CQIFCQILDgIIAgImAgI?= =?us-ascii?q?bDDAGDQYCAQEXgwYBgXkID6ksgS+FPoRjBQWBBosMgUA/gREnDIJfgxsBAYE?= =?us-ascii?q?2FTcmgj2CVwKJQZYOCZEXBhiBWIUCgnyHGpEghliBWSKBVTMaCBsVO4JsglC?= =?us-ascii?q?Da4RhhT4/AzCOFAEB?=
X-IronPort-AV: E=Sophos;i="5.54,496,1534809600";  d="scan'208";a="7938731"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2018 17:14:21 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id wACHEKl8020688; Mon, 12 Nov 2018 17:14:21 GMT
To: Martin Bjorklund 
Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org
References: <20181109151347.3xms2cty6hxyl232@anna.jacobs.jacobs-university.de> <20181109.173159.1522007243611164311.mbj@tail-f.com> <96995ddc-f69e-1a91-21b6-36304c8510f3@cisco.com> <20181112.172945.713446019460767559.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <09429e6f-3af9-ee8c-4031-adea712d5e58@cisco.com>
Date: Mon, 12 Nov 2018 17:14:20 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <20181112.172945.713446019460767559.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2018 17:14:25 -0000

On 12/11/2018 16:29, Martin Bjorklund wrote:
> Robert Wilton  wrote:
>> Hi Martin,
>>
>>
>> On 09/11/2018 16:31, Martin Bjorklund wrote:
>>> Juergen Schoenwaelder  wrote:
>>>> On Fri, Nov 09, 2018 at 02:37:29PM +0100, Martin Bjorklund wrote:
>>>>>> I think we need to distinguish between the agreement on the
>>>>>> requirement, namely that a server should be able to provide support
>>>>>> for an old and a new definition, and agreement on the solution.
>>>>>>
>>>>>> Do you disagree with the requirement? Or do you disagree with the
>>>>>> consequences of implementing multiple versions of the same module
>>>>>> for some of the proposed new versioning schemes? Or both?
>>>>> I do not agree with the requirement that a server MUST be able to
>>>>> support multiple revisions of the same module, which is how I
>>>>> interpret 3.2.  If this is not the intention of 3.2, maybe it can be
>>>>> clarified.
>>>>>
>>>> Here is what 3.2 says:
>>>>
>>>>          3.2  The solution MUST provide a mechanism to allow servers to
>>>>               simultaneously support clients using different revisions of
>>>>               modules.  A client's choice of particular revision of one or
>>>>               more modules may restrict the particular revision of other
>>>>               modules that may be used in the same request or session.
>>>>
>>>> This does _not_ say servers MUST implement this.
>>>>
>>>> Item 3.2 establishes a requirement and for some solutions it may be
>>>> easy to satisfy this requirement, for others it may be more costly to
>>>> satisfy this requirement.
>>>>
>>>> The whole requirements exercise becomes a rather pointless exercise if
>>>> we remove requirements so that certain solutions look more
>>>> attractive.
>>> Ok, but that's not what I wrote.  I don't agree with this requirement
>>> which says that it MUST be possible for a server to support
>>> different revisions of a given module (again, if this is not the
>>> intention of the text, please clarify).  I simply don't think that
>>> this is a good requirement.
>> One way to think of this is as YANG data models defining an API
>> between client and server.
>>
>> There seem to be lots of REST APIs that implement versioning of their
>> API by having a version number in the URL.
> Yes, but that doesn't mean that a given server supports more than one
> version seamlessly.
I agree.  But if a set of translations are being defined between old and 
new it should be possible to identify those cases where the mapping does 
not work.

At the end of the day, if the schema has been expanded in any way, then 
an old client isn't going to understand new functionality used by a new 
client.

>   As you wrote, it works fine for operational
> state, but it is less obvious how it should work in the general case
> for config data.
Even for operational data (if we are discussing mapping different 
versions of a schema) then it is not guaranteed that it is possible to 
map between different representations.  If they are two far apart then a 
good mapping may not be possible.


>
>> In fact, I think that
>> RESTCONF adopts this approach to allow versioning of the protocol.
>>
>> One solution is as Andy describes.  The underlying server only
>> implements one version of the a given YANG module, but they may
>> provide other views on to this data using different versions of YANG
>> modules.  E.g. the same as how Vendor YANG models, IETF YANG models,
>> and OpenConfig YANG models might be treated as their own views, mapped
>> to the same internal YANG modules.
> Yes, but this solution is also problematic; it is not always the case
> that clients can pick and choose from these different "views" and get
> consistent results, simply b/c the mappings are not 100% one-to-one.
But a device performing that mapping should be able to report the 
paths/values that it has not been able to map.

Thanks,
Rob

>
>
> /martin
>
>> Thanks,
>> Rob
>>
>>
>>>
>>> /martin
>>>
>>>
>>>> I have not seen a proposal that addresses all requirements and hence
>>>> at the end the WG needs to decide which tradeoffs make sense.
>>>>
>>>> /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 Mon Nov 12 09:20: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 BA1D2129AB8 for ; Mon, 12 Nov 2018 09:20:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.969
X-Spam-Level: 
X-Spam-Status: No, score=-14.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 jYEIFD5iVGg7 for ; Mon, 12 Nov 2018 09:20:07 -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 7484B12896A for ; Mon, 12 Nov 2018 09:20:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18926; q=dns/txt; s=iport; t=1542043206; x=1543252806; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=TYPP/6xnpMkUkvXXM4DalZnqD4E/5Mf5u0+E+xF/f1Q=; b=ll81/JhGDiH0jSkupC24zmNiEoBInc2q/ulML9OVxDXVo6lf5BNcsp0r cU+jagNxZzcBEkjQ1/hIaU64g6TNAjzgwK/GVHYWCz7fawK1lZquc9fKC 8//G61+EIU7aZQPSidIFc/8fg1Vl8JZ+izoqmOexshC4X4Xu0gv+6CMVk E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAABatelb/xbLJq1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVAIBAQEBCwGBWoEPTyESJ4N4iHeNKJdJgWYNGAEKhANGAoN?= =?us-ascii?q?PNwoNAQMBAQIBAQJtHAyFOgEBAQMBAQEMFUIJCwULCxgVEgMCAicfEQYNBgI?= =?us-ascii?q?BAReDBgGBeQgPqS+BLx+FH4RkBYwXgUA/gREngW1+gxsBAYEcL1WCRYJXApU?= =?us-ascii?q?bijQJkRcGGIFYhQKCfIcaiVqHRoZYgVkiJ4EuMxoIGxU7gmyBd4FGAQmHVYU?= =?us-ascii?q?+PwMwjhQBAQ?=
X-IronPort-AV: E=Sophos;i="5.54,496,1534809600"; d="scan'208,217";a="7938812"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2018 17:20:04 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id wACHK3YO021569; Mon, 12 Nov 2018 17:20:04 GMT
To: Andy Bierman 
Cc: NetMod WG 
References:  <5d8a14f4-94a9-c6eb-4a7c-6d6a155e0c84@cisco.com> 
From: Robert Wilton 
Message-ID: <0ffe7036-58ff-abbc-c0fd-efd6e251f815@cisco.com>
Date: Mon, 12 Nov 2018 17:20:03 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------6365FB9A78B0B54ADDECFB72"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: 
Subject: Re: [netmod] missing YANG versioning requirements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2018 17:20:10 -0000

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



On 12/11/2018 16:15, Andy Bierman wrote:
>
>
> On Mon, Nov 12, 2018 at 7:01 AM, Robert Wilton  > wrote:
>
>
>
>     On 09/11/2018 18:35, Andy Bierman wrote:
>>     Hi,
>>
>>     I think the requirements doc should state that
>>
>>     1) there are many more readers, operators, and client developers than
>>     server developers so the solution MUST take into account the numbers
>>     of people affected when finding a balance between client and
>>     server complexity.
>     OK.  So you would like the solution to be weighted towards
>     clients, but yet you do not want servers to have to implement any
>     sort of version selection, instead pushing the problem on to the
>     client? :-)
>
>
>
> I support some aspects of this work:
>   - SEMVER
>   - import-stmt
>   - status-stmt
OK

>
> I strongly oppose the simultaneous implemented revisions requirement 
> because it is actually
> a solution, not a requirement at all, and a bad solution.
>

>
> For any given buggy data node, a replacement sibling can be created so 
> the new node and the deprecated
> buggy node can both be implemented.
So, I regard this as a potential solution to requirement 3.2.

However, I still do not understand a scheme for how this works for 
config items, either covering all of the various corner cases of clients 
at different versions, or at least states under what assumptions that 
solution works.

Please can someone who thinks that this is a solution explain how this 
solution works.  I think that there are quite a lot of potential 
questions/issues:

Are there two version entirely independent of are they connected (i.e. 
updating one, updates the other)?
If they are dependent then does writing one value also update the other one?
If they are independent they can two different values be written 
(perhaps for a pair of leaves this could be enforced with a must 
statement), but with more complex models this is not possible?
Does this solution support 2 clients interacting with the server using 
different versions of the leaf, or is it assumed that all clients will 
interact using the same version?
What happens if both leaves have different default values (perhaps this 
can just be avoided)?
What happens when the new value cannot be represented in the old leaf 
used by client A?  It now has a configuration that it cannot change 
because it doesn't know about the new leaf.
What leaf values are updated in operational?  Is it both of them, or 
just one of them?


>
> YANG represents a customer-facing API, like the CLI. Vendors 
> understand that customers
> don't like it when CLI keywords change meaning from release to 
> release.  Vendors are careful
> to introduce new keywords so the old ones keep working.

For our CLI, we generally accept the old, but always return the config 
using the new CLI.  However, I would expect that approach would probably 
break clients using YANG.  They would be confused that the configuration 
returned via get-config does not match what they programmed via edit-config.

>
>     More seriously, I'm looking for a solution where we it up to the
>     market to decide whether the complexity should be pushed to
>     client, server, or a 3rd party controller.  I think that some sort
>     of version selection should be able to achieve this.
>
>
>
> I do not agree the standards should be changed to support this 
> solution approach.

>>
>>     2) if existing protocol and YANG solutions exist then they MUST
>>     be used
>>     in favor of developing new solutions.
>     If you replace the "MUST" with a "SHOULD" then I sort of think
>     that this one is obvious.  I think that we are only trying to
>     develop next solutions where the existing ones do not appear to be
>     working well.  There are examples in the earlier text in the
>     requirements draft, and also draft-clacla-netmod-yang-model-update
>     to provide the background and justify why we need to do something
>     different than the status quo.
>
>
>
> It would help to have real examples where deprecate-and-replace was an 
> unworkable solution.
I would happy to start with an example where you think it does work, 
taking into consideration the questions that I provided previously.

> IMO it is OK to update a data node because sub-statements are 
> incorrect (e.g. pattern, type).
> In this case, the old definition is not worth preserving.
This can still break some clients.

>
> Note that changes between I-Ds are not interesting. Only changes from 
> RFC to RFC are interesting.
> Vendors need to review their own modules and do a better job 
> identifying stable vs. unstable releases.
I agree to both of these.

But lets not pretend that all code that we ever produce will be perfect 
the first time, contain no bugs, and never need to be changed.  We have 
seen the industry push for us to be more reactive and get changes out 
more quickly.  I would argue that a natural side effect of that is that 
there are likely to be more bugs that will need fixing.

Thanks,
Rob


>
>
>     Thanks,
>     Rob
>
>
>
> Andy
>
>
>>
>>
>>     Andy
>>
>>
>>
>>     _______________________________________________
>>     netmod mailing list
>>     netmod@ietf.org 
>>     https://www.ietf.org/mailman/listinfo/netmod
>>     
>
>


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


  
    
  
  
    


    

    

    
On 12/11/2018 16:15, Andy Bierman
      wrote:

    

    

      
      


        


          
On Mon, Nov 12, 2018 at 7:01 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            

              

                


                

                

                
On
                  09/11/2018 18:35, Andy Bierman wrote:

                

                

                  
Hi,
                    


                    

                    
I think the requirements doc should state that

                    


                    

                    
1) there are many more readers, operators, and
                      client developers than

                    
server developers so the solution MUST take
                      into account the numbers

                    
of people affected when finding a balance
                      between client and server complexity.

                  

                

                OK.  So you would like the solution to be weighted
                towards clients, but yet you do not want servers to have
                to implement any sort of version selection, instead
                pushing the problem on to the client? :-)

                

              

            

            


            

            


            

            
I support some aspects of this work:

            
  - SEMVER

            
  - import-stmt

            
  - status-stmt

          

        

      

    

    OK

    

    

      

        

          

            


            

            
I strongly oppose the simultaneous implemented
              revisions requirement because it is actually

            
a solution, not a requirement at all, and a bad
              solution.

              

            

          

        

      

    

    

    

      

        

          

            


            

            
For any given buggy data node, a replacement sibling
              can be created so the new node and the deprecated

            
buggy node can both be implemented.

          

        

      

    

    So, I regard this as a potential solution to requirement 3.2.

    

    However, I still do not understand a scheme for how this works for
    config items, either covering all of the various corner cases of
    clients at different versions, or at least states under what
    assumptions that solution works.

    

    Please can someone who thinks that this is a solution explain how
    this solution works.  I think that there are quite a lot of
    potential questions/issues:

    

    Are there two version entirely independent of are they connected
    (i.e. updating one, updates the other)?

    If they are dependent then does writing one value also update the
    other one?

    If they are independent they can two different values be written
    (perhaps for a pair of leaves this could be enforced with a must
    statement), but with more complex models this is not possible?

    Does this solution support 2 clients interacting with the server
    using different versions of the leaf, or is it assumed that all
    clients will interact using the same version?

    What happens if both leaves have different default values (perhaps
    this can just be avoided)?

    What happens when the new value cannot be represented in the old
    leaf used by client A?  It now has a configuration that it cannot
    change because it doesn't know about the new leaf.

    What leaf values are updated in operational?  Is it both of them, or
    just one of them?

    

    

    

      

        

          

            


            

            
YANG represents a customer-facing API, like the CLI. 
              Vendors understand that customers

            
don't like it when CLI keywords change meaning from
              release to release.  Vendors are careful

            
to introduce new keywords so the old ones keep working.

          

        

      

    

    

    For our CLI, we generally accept the old, but always return the
    config using the new CLI.  However, I would expect that approach
    would probably break clients using YANG.  They would be confused
    that the configuration returned via get-config does not match what
    they programmed via edit-config.

    

    

      

        

          

            


            

            
 

            

              
 More seriously, I'm
                looking for a solution where we it up to the market to
                decide whether the complexity should be pushed to
                client, server, or a 3rd party controller.  I think that
                some sort of version selection should be able to achieve
                this.

                

                

              

            

            


            

            
I do not agree the standards should be changed to
              support this solution approach.

          

        

      

    

    

    

      

        

          

            
 

            

              

                

                  

                    


                    

                    
2) if existing protocol and YANG solutions
                      exist then they MUST be used

                    
in favor of developing new solutions.

                  

                

                If you replace the "MUST" with a "SHOULD" then I sort of
                think that this one is obvious.  I think that we are
                only trying to develop next solutions where the existing
                ones do not appear to be working well.  There are
                examples in the earlier text in the requirements draft,
                and also draft-clacla-netmod-yang-model-update to
                provide the background and justify why we need to do
                something different than the status quo.

                

              

            

            


            

            


            

            
It would help to have real examples where
              deprecate-and-replace was an unworkable solution.

          

        

      

    

    I would happy to start with an example where you think it does work,
    taking into consideration the questions that I provided previously.

    

    

      

        

          

            
IMO it is OK to update a data node because
              sub-statements are incorrect (e.g. pattern, type).

            
In this case, the old definition is not worth
              preserving.

          

        

      

    

    This can still break some clients.

    

    

      

        

          

            


            

            
Note that changes between I-Ds are not interesting. 
              Only changes from RFC to RFC are interesting.

            
Vendors need to review their own modules and do a
              better job identifying stable vs. unstable releases.

          

        

      

    

    I agree to both of these.

    

    But lets not pretend that all code that we ever produce will be
    perfect the first time, contain no bugs, and never need to be
    changed.  We have seen the industry push for us to be more reactive
    and get changes out more quickly.  I would argue that a natural side
    effect of that is that there are likely to be more bugs that will
    need fixing.

    

    Thanks,

    Rob

    

    

    

      

        

          

            


            

            


            

            

              
 Thanks,

                Rob

                

              

            

            


            

            


            

            
Andy

            
 

            

              
 

                

                  

                    


                    

                    


                    

                    
Andy

                    


                    

                  

                  

                  

                  

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


                

                

              

            

          

          

        

      

    

    

  


--------------6365FB9A78B0B54ADDECFB72--


From nobody Mon Nov 12 09:54: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 E4F73130E8E for ; Mon, 12 Nov 2018 09:54:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.971
X-Spam-Level: 
X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 D742I_EVFX1J for ; Mon, 12 Nov 2018 09:54:48 -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 50A24130EBE for ; Mon, 12 Nov 2018 09:54:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3663; q=dns/txt; s=iport; t=1542045288; x=1543254888; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=WmT1baTXGomOONsPkMOQWnI05uSN7FDPkBlQOqbAJGI=; b=g+o+LxBHKZw4BtJ4MCsmtXZrJoQP7HLEutVr9t4RuQrHlMq+fTFPWwzJ GwzjDigr2WcEjQ8G8I83hxjTK9PoqLwUJ5Kk51PbUOiuIwTIyj/EuLyVb 8/udZmOnBumeS/8yyMtih096/zpots16IUBNO+d8P++ks5K6fAcgBdTMI U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfAgALvelb/xbLJq1jHAEBAQQBAQc?= =?us-ascii?q?EAQGBZYFWgRRPIRKEH4h3jQOZVA0jgVSGRjgWAQMBAQIBAQJtHAELhWQPAQV?= =?us-ascii?q?2AiYCXw0IAQGDHQGCAQ+pGIEvhT6EZgWBC4sMgUA/gTgMgjIBg0cCgUuDGoJ?= =?us-ascii?q?XAokwDgOWDgmBYoUUiiEGGIFYh36HGolag0yDeoZYgVohgVUzGggbFYMogiY?= =?us-ascii?q?Xg0qKUj8DjkQBAQ?=
X-IronPort-AV: E=Sophos;i="5.54,496,1534809600";  d="scan'208";a="7940469"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2018 17:54:46 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id wACHski2028063 for ; Mon, 12 Nov 2018 17:54:46 GMT
To: "netmod@ietf.org" 
From: Robert Wilton 
Message-ID: <3bea2401-6888-7643-7a20-52ecaf908fa9@cisco.com>
Date: Mon, 12 Nov 2018 17:54:45 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: [netmod] Limitations of semver
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2018 17:54:57 -0000

Although, we may like to think otherwise, I do not believe that semver 
is a silver bullet that will solve all YANG versioning problems.

Yes, it is popular and used, perhaps quite successfully, in lots of 
projects.  But there are many other large scale projects that have not 
adopted semver, e.g. 
https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e states that none 
of the following properly use semver: Node doesn't follow SemVer, Rails 
doesn't do it, Python doesn't do it, Ruby doesn't do it, jQuery doesn't 
(really) do it, even npm doesn't follow SemVer.

The reason why I don't think that vanilla semver works for YANG is for 
two reasons:
(1) Semver is often used where API and implementation are versioned 
together (e.g. code libraries).  I.e. the "patch" field is semver is 
really about fixes to the implementation that do not change the API in 
anyway.  But a YANG module definition is really defining an API contract 
between client and server.
(2) Semver makes the assumption that all changes can be made to the head 
of the development branch, and that clients are able to relatively 
easily update to the latest version if required.  In fact, for an open 
source project it is a beneficial feature if you can force your clients 
to migrate to the latest API and code because there are less different 
versions to support.

But when applied to YANG modules there are two significant differences:
(1) The server implementations are not being versioned with the YANG 
API.  They may be multiple vendor products implementing the same YANG 
module, or there may be multiple products across multiple vendors 
implementing the same YANG module.  Asking a customer to move to the 
latest release to pick up a bug fix is not a realistic option, since the 
vendor/device may not even implement the latest version of the YANG 
module.  Also moving to the latest version of one particular YANG module 
could have cascading dependencies on other YANG modules.

(2) I would expect YANG modules, and the requirements to support them, 
to be much more long lived than open source projects that are using 
semver.  Where vendors are being paid to support software releases that 
have shipped with particular modules, customer have an expectation that 
they can get point fixes to those releases without being forced to 
update to major versions.

Hence, the proposal for modified semver.  Its aim is to be semver plus 
the minimal added changes to allow it to primarily support bug fixes 
(including nbc ones) to older releases.

The alternative, of using vanilla semver, looks similar to what we have 
today:
- vendors will increment the major version number for every release so 
that they they can increment the minor version number for bug fixes.
- or vendors will use deviations as a mechanism to get round where the 
API is wrong,
- or most likely, vendors will just fix the bug and increment the 
"patch" version number anyway breaking the semver rules, just as they 
ignore the YANG module updated rules today.

Perhaps this will all lead to the schema diff tool that I also like, if 
clients reach the point where they cannot trust the semver version 
numbers because it cannot actually encode the changes that are happening 
to the module.

As a vendor, I know that we have bug fixes going into older modules, Rob 
S indicated that OpenConfig does as well.  So, I think that the key 
question is whether we want the versioning scheme to be able to sensibly 
label bug fixes.  If we do, then I don't think that vanilla semver will 
meet the requirement.

Thanks,
Rob


From nobody Mon Nov 12 11:13: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 BD764130E4B for ; Mon, 12 Nov 2018 11:13:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.171
X-Spam-Level: 
X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nRv1MfmafIS for ; Mon, 12 Nov 2018 11:13:42 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE29E1274D0 for ; Mon, 12 Nov 2018 11:13:41 -0800 (PST)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wACJ8o26021300; Mon, 12 Nov 2018 11:13:40 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=PPS1017; bh=747mBPNfA9RRjt57oTdhpFglJJzWgawssTJ4D9OpdQ8=; b=WDUHWNqzJwzKBxhS4ygil+VaeuquZP2bJ+YVRdhhXMRMn0HJNmcg3YxbO4d75/DFF3Kw p0pbv3eZ9cfo5TPbsTnwJZoakEN5bSY4zlMuSl3hYaFPVNrIj9EKmUXtLsITKa8r7aaw hNQPvDBAClXq7R6SdmijORZ0AOX2C9SCIKt3ge2irrKDZWJl9PMERKAzqqpHVvsndrlO H2czKCzq/U4UOmQutiMYMchenbp/MM1bM0ynFCNYAxwojWbvHdntUVTtN95ZaBFN92bv T0Y0Q8yef0H3A7KJrYE3MlGZxlx61RbRQ8ePI8jjzGtqXH8zcZjA4npdh0b9czwyfMMX Ng== 
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0056.outbound.protection.outlook.com [207.46.163.56]) by mx0b-00273201.pphosted.com with ESMTP id 2nq7geh3cq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 12 Nov 2018 11:13:40 -0800
Received: from BN6PR05CA0013.namprd05.prod.outlook.com (2603:10b6:405:39::26) by CO2PR0501MB854.namprd05.prod.outlook.com (2a01:111:e400:142e::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.19; Mon, 12 Nov 2018 19:13:36 +0000
Received: from BY2NAM05FT042.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::204) by BN6PR05CA0013.outlook.office365.com (2603:10b6:405:39::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.12 via Frontend Transport; Mon, 12 Nov 2018 19:13:35 +0000
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender)
Received: from P-EXFEND-EQX-01.jnpr.net (66.129.239.12) by BY2NAM05FT042.mail.protection.outlook.com (10.152.100.179) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1339.3 via Frontend Transport; Mon, 12 Nov 2018 19:13:34 +0000
Received: from P-EXBEND-EQX-02.jnpr.net (10.104.8.53) by P-EXFEND-EQX-01.jnpr.net (10.104.8.54) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 12 Nov 2018 11:13:33 -0800
Received: from P-EXBEND-EQX-01.jnpr.net (10.104.8.52) by P-EXBEND-EQX-02.jnpr.net (10.104.8.53) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 12 Nov 2018 11:13:33 -0800
Received: from smtp.juniper.net (10.104.20.6) by P-EXBEND-EQX-01.jnpr.net (10.104.8.52) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Mon, 12 Nov 2018 11:13:32 -0800
Date: Mon, 12 Nov 2018 12:13:32 -0700
From: Ebben Aries 
To: Martin Bjorklund 
CC: , 
Message-ID: <20181112191332.g5ha5pvm5s32jgcd@smtp.juniper.net>
References:  <20181112.173351.1984161388756642220.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20181112.173351.1984161388756642220.mbj@tail-f.com>
X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(396003)(136003)(39860400002)(346002)(376002)(2980300002)(199004)(51444003)(189003)(336012)(4326008)(5660300001)(356004)(97736004)(1076002)(6306002)(966005)(478600001)(76176011)(47776003)(26005)(186003)(14444005)(23756003)(55016002)(77096007)(486006)(81156014)(53416004)(106466001)(316002)(476003)(6916009)(126002)(305945005)(54906003)(229853002)(446003)(7696005)(11346002)(105596002)(6246003)(2906002)(69596002)(53936002)(68736007)(2870700001)(8676002)(8936002)(86362001)(81166006)(50466002)(575784001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR0501MB854; H:P-EXFEND-EQX-01.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; 
X-Microsoft-Exchange-Diagnostics: 1; BY2NAM05FT042; 1:lTk01CnsBOqJR0Vg6kpiaNHDL5/0/iDt6Bq7Kmd+Xl4Us65KP/AZPddzpfll/o2qO6WK5ObT1RwdHZRYcHKmZoZapMaw5HpjIyFvXnSP42fOl/dLRQ/+cbApMgWRgaag
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 66ce3bfb-15d3-429b-a95e-08d648d2f139
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390040)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060); SRVR:CO2PR0501MB854; 
X-Microsoft-Exchange-Diagnostics: 1; CO2PR0501MB854; 3:FtOyFu/unWvLSWNVShohMERK/ISvYQs4VoOjR185cAQAW8kZClKx1NI6/t4WkIRBiVxs3T+9Np0oqWcnarsmsWNoJ0fuo0kUf0GDMXCJcYaTC6Wr9DO18R7sRStOHhGJCZBb7VbqmiTIsaO8gkG2Z7atrtyy/91rPHVE2g5DWw5B+bgrnMlFLrGeB5Gcf8+DrXHkBzUPw4hktiUDh8w6yzj6qH/vLgzN9X4hWXaBzP+BN6jq6H9blypPfjiqQPaZ+IBchW/zyPvEdz6FyaxVCFh57ZK0r5/L833Z+J77bLzM/9sobUqmue63fFHjypugKbhpqnEebunHJCuX2t83JbsQ8PzZAZ0TgeUPKW/AzkA=; 25:gLdHSQjDsKNSj03hPRV9lStUJ5rMQ93/+stziofB+/oK6HDTUAZ6+3HdxNwT8FVpAcT2LBnH4JbM16lx6JInEN+1mYaf4CnukOa+Qwhg0bPIgVF9nzEYllGHRpk3XwGs+y+nHLVjz51DQX6A9abHIB5KsmfJW3EQzFAZ6wBB9iPKm2h6YT01LPmkad0MYjBxE3vo4qWIRboWhFOTUg8bRo5B0vBSIgYTg2Pp9Zzd+Hxj5e1RrMyM0bJhuesf4K1xG5GuxHl0VZV6fFvKn2vFqwf7R4pOl2w6fMDU2T7EfH0aeajkAkkQlUY6EGBpxhA6INQfcKLcUxNJBXNQl5CF5M6WAgYaeyt6vSrfH3NFWe0=
X-MS-TrafficTypeDiagnostic: CO2PR0501MB854:
X-Microsoft-Exchange-Diagnostics: 1; CO2PR0501MB854; 31:94/19ZNHT1f5TmF3Iw4RCiHGidQlL8nm4aYmJCYFeBbxXmZaT9T7OU5TDDJRKaca9aKMxJVhMeLp+bdkzWonUD6y0z3KDWNm6OCeqn6jDK6oo2VJEyp9S8hAcvOzXivR4EZalXLbfWIs3Jy0ohtvtSKxfVfJ73fa5yZe53fHU1dJ9CVp2gTOUIdZcKeXJWcke5fyV/gOEHoYHRvA+tOd33lnMqYDBPDub3TdNIQRTQ4=; 20:ymjzk8yjS+iJ+Dt1bYV6TiuaEPpAx3ZzR5KcQ5dg/bqC+hXbIIuz+B/pHE5MZqlkQynVna4ZY8rokkkKJoywHydclFxy1G4i3E0qGjcaGnod+8UkbXGJG2w995yv4HNSCb+/XboZe0qZSNYMaLRiIYgjOYl2QI1mpproEZTSLU0q2nXqFNl3bJPH5FQA0yvtbxFCrQRgucKeCRcpDgvr5KH2yI6jvKcBCd5sMGm4mDYYQ/rBt9aP37vc8DFHG/TCGfho+vuEPd42eTL+b2swuhnA5bBRFAZoAfZetj3qUNpNxX3DcXVNxUk3ivVu7njPnFgiJuqp9WVsqI5RGbNnZDggFmj7iAQXImBU6c9hano9O48MU9sckVv7DqbNMyrv5WItiloUrr+jyJGlO8QjiOg7ZSaSW7EuxqmjOcobHpJGFuHXJrcSYK+wzudCD+ewFtplOAdlXkLcEw4mVnd56tjG7jnyLznZoSnENGzsroskioOgNPDPECdlUI2bVRtH
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)(3231382)(944501410)(52105112)(3002001)(10201501046)(93006095)(93003095)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:CO2PR0501MB854; BCL:0; PCL:0; RULEID:; SRVR:CO2PR0501MB854; 
X-Microsoft-Exchange-Diagnostics: 1; CO2PR0501MB854; 4:rMzop0Dg+jdHH5SxA5BJcjXO16qTwvWzmCsHgu05O7BaF47uTHNDMSFskQPxrfkw2OfwK2JV1nUtc/yH7F3Hl/ovr+5jDA45OyL/9LDSTvqrggsK51md2Derc+qCgUhpBHysB377smvjD5Em1HsL5+cthM9tlXbHxxLhRa31ZwZQEbOx+aFHLSpOVgfEG5gLSvTARQxotphNmVpPksCZ4xGZ8J3z3Wno+G8LgMiLZANz/sw1o31tSHiGtmpBJFL3FoBKs5YVaM+EodxIDJ+KeQ==
X-Forefront-PRVS: 0854128AF0
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; CO2PR0501MB854; 23:Necy5sZ9w+6GvddzORLR0ixAfee1tMwkd6DCFC?= =?iso-8859-1?Q?cUW/ZXk/E0fh+rJEYAzDTSqtzqFGFMREK2+Itu6whhJhrN0HMopcaXAkLo?= =?iso-8859-1?Q?QvKk40iD3kJdxf9X+FCpT0ivD7UG7Ff23RD858gmkFnT7AwuPwpVwaS0Sh?= =?iso-8859-1?Q?2kIT7uHqHXpfhmKvjTXFdi/GsjcasZvKpVE7CsOHiUhstM/rHagCpj1Xf+?= =?iso-8859-1?Q?pmByXfs9TocFCf0qWzQlQEwnI5k061KcGHWaQOIrW04T5OgMBfUoKAMl3P?= =?iso-8859-1?Q?CQRHaIQRUX8Q9I00T5prtykq5f9F+kwWIatRVs+wmUd+0+HxO78F5TjGp1?= =?iso-8859-1?Q?zRAWQlBe+QgpPLmdsXuOe9GnPDnVuX7Qe64a4ai2hAcPoCnEnkB7eACBNw?= =?iso-8859-1?Q?Jom994xJD+IowcUeY9p91w8J9v6sLGuXUezsFvjhk++6shoz0gzlmJym2f?= =?iso-8859-1?Q?dWieDD0+3zlbo+W/KQ5DEE8swg41wws8wPG6zlXJ6yAWMSMeTw69psoRH7?= =?iso-8859-1?Q?fx1PV8WjHi6lXbkSez0MmeFwhLercJ09dZbL9wUzPxT1evlGS3s10bZmqu?= =?iso-8859-1?Q?qpgYhxpvqVh1CBeOTHiFEXfjvx5WCWzchluYWcgaAqK3Iw6637+//N6QHb?= =?iso-8859-1?Q?//4R4H6CHqMIN5d7NGjGB5ygSA+N9XAg9fxBK8C2/SjLKcQsY2km0LKALs?= =?iso-8859-1?Q?tb/zdjjFFVM+6ZULOiqJM8JrxxOowcrNu5IzYWYwx9unoCnQojCc7rtwZG?= =?iso-8859-1?Q?kss/ZwjiKWI+gusBlDLlSTUNC7c8qOZO/j3vYFrBVX02AZ/dWva5lXRar6?= =?iso-8859-1?Q?9jTwXfBLYx2DXuhnNaq1Guc4awDMsekZ1LOxsQHZE6fWgsYIoc3IPrCLAE?= =?iso-8859-1?Q?t0XIoCbdlNH9KeDp7ltluhI/pC4janBiwrMiWd00nBOpj82ZeLPRso09VE?= =?iso-8859-1?Q?EFvLu/A3ki044A0qEZdm6aI3AH6hpqjwoU6sPGObBx+OwkeKnWonlNklpf?= =?iso-8859-1?Q?/YjLEZNnhQYcTAxmG/o8N1qdm+H7U4oIm17NdHZDZuZaysFcURnpGg/y8f?= =?iso-8859-1?Q?Kww8lpcwEMDwII3MuyQfkbDh52HO3zNEZyAXXiZCxlOrYrOrsIksTE9oBo?= =?iso-8859-1?Q?s/0k4kiiOVikYvwpf+UuZZG7nRQqWq5jN1TYd4x364cO2/u6hsdbrnU3wW?= =?iso-8859-1?Q?ZC5NIq0a08rDZD+xL8ORWERaJGEvC/rWeuxsFDV6pfKCHXPqq0WJiZI28Q?= =?iso-8859-1?Q?eaPUuAfkbZazgpl4sd?=
X-Microsoft-Antispam-Message-Info: QL92i544AiTp5qWGDhdDU7GMnD7aGaBWiYEJNXGa2RN+/R16X79gtxysKdck17eEEicn7pyfib6RSr+Xpw4cxiAo7Gr2nZfU6Jd2Ff87uNzEH+BLayLFuIaekcCLU7rbHwuO2LMXCGK/4jT8DeKOgve4xviaMW+H8oWUaBbS2LBcOHZK6Bq8bkzBSLILKyhXyFMY0SJ/lucrHQ8jTAeeFqDHy3/DSF3oxr0HFvhK83BtbDdbDt2m6Um4SusYa3ULQg4NeZK5aqaMcExYzD9N9p0n9iH2zSUju6tVz0SoTfDScnLvbQQ6OIAD2d1pGkNa2PMQKAGLvsb21NQpe+uPXiwtot/wV1znROUTLVxz6yE=
X-Microsoft-Exchange-Diagnostics: 1; CO2PR0501MB854; 6:ZCYcpNsYzZkzwgLN1r9outi+DPGiDHZcDWlS9Zs2f3noW37PWQxA17fb9ujyaK554ebgadPUDB99nyN9+zdyPI7CoTgkcSmRb7MX/TvhBeRgvNraFP0IBy9rAF+bys/T10ksX+dnMLgA1UvxaDe8PhtFU+lROIIU7ldS2W53Xryw8yjIAjeJz0rYEbsZNWajh/xBaroEedzqi1BYYngiwQp3NdAVeCSsZE8qCYkvounE7tjQEd4DAA2ex/jd1oOmHcz8nm84VGhPUDtpc2VvC8LFzRJZ3qhN4fPOCiLEBp+qXfzSh2jRHsKF6aWa79+YphrD5oguUZy1MGYL4xXjp35SKcURGr33g0BcYuoasWOB5coAoVz70mLqADSECOIeeRujPGGP1oKiJYDIRb0HNcWLn4FnxiBkudfP7msyBbkSlNxTPJqh2AFNLbW82O0P7yfmfItmAV3KUfl1A0n5fQ==; 5:b6g1LCLzmrFWIFWiibfcRiUVyYBoncaaXU8m93N11XB5+xU/U4uf1q2OGiWW8Pn75Xjxfbesi6hsgoN/NbeqlczOxDQBM5TaNDr5ZS7uf+WFXeBKWYtZD3L5LvSXFncED3F3fSVYlkHaEx56ThkUQ9XOYhy8S+a1rGUgnhcKCGY=; 7:dux1Sh2fNoTWCwvg+Mw+ROLODU9QU8E+PDZV4neRnxD1wdFzr+Ccc8llxlVd73tFqVl9GH6G+xdVToJzqLAf4rBCZJuf2AE2D4WALsmHMaWh83O2iA7OUuSiL2c5IxnT5Va8z3TprDNsIUyiP3JYTw==
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Nov 2018 19:13:34.6611 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 66ce3bfb-15d3-429b-a95e-08d648d2f139
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12];  Helo=[P-EXFEND-EQX-01.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR0501MB854
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-12_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811120167
Archived-At: 
Subject: Re: [netmod] Deviations and augmentations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2018 19:13:44 -0000

On Nov 12 17:33 PM, Martin Bjorklund wrote:
> Robert Wilton  wrote:
> > In the Thursday Netmod meeting, it was interesting to hear Rob Shakir
> > describe how deviations and augmentations are used in OpenConfig to
> > add functionality into an older YANG model where the semver rules
> > prevent the version number from being incremented.
> > 
> > Further, I think that someone (Martin?) stated on the audio bridge
> > that this was an intended/allowed behavior for deviations.
> 
> I said that using augmentations (not deviations) was one idea we
> originally had for solving the "branching problem".
> 
> I think that this works for OC b/c they don't branch their modules.
> Hence I think it is important that we decide if branching is a
> requirement or not.
> 
> 

Does this not already somewhat exist today by way of each vendors
augments and deviations to OC models?  While branching doesn't exist
within OC directly, each implementation today supports *a* version at a
given point in time and deviations and augments exist within these
"branches". Occasionally the need arises to introduce changes in the
vendor provided modules as a stopgap that are ultimately mapped to a sw
release.

This could be fixes or additional functionality not previously there to
satisfy not having a customer have to upgrade their network element
and/or move to more recent modules

> 
> 
> > This surprised me, because I thought that RFC 7950 was quite explicit
> > that this is not what deviations are intended for. My reading of RFC
> > 7950 is that the deviation statement represents the case where the
> > server *implementation* does not match the *specification*. However,
> > the versioning issue that we are discussing are bug fixes/changes in
> > the specification rather than the bug fixes in the implementation.
> > 
> > Personally, I'm really not keen on using deviations to represent bug
> > fixes to older YANG models for three reasons:
> > 
> > (i) It is changing the meaning of deviation. It is much cleaner to
> > keep the meaning of deviation statements as they are defined today,
> > and not conflate their semantics.
> > (ii) A different mechanism is used to put a bug fix into an older
> > branch rather than in the head of the development.
> > (iii) For clients to track the lifecycle of modules they would not
> > only need to know the module version number but would also need to
> > find and track all associated deviation modules. This seems
> > significantly more complex for clients than the modified semver that
> > was proposed.
> > 
> > ---
> > 
> > I think that has also been some suggestion that augmentations (or
> > duplicate YANG modules with their major version number changed) can be
> > used to make bug fixes in a completely backwards compatible way.
> > However, I still don't understand a robust scheme of how this works.
> > 
> > ---
> > 
> > Finally, there were some comments about using augmentation modules for
> > enhancements. This is fine, where appropriate (e.g. a non trivial
> > number of data nodes are being added as an enhancement) then a
> > separate module may be the right way to go. But here, I presume that
> > the new functionality will always be tracked by that separate module.
> > If that functionality folds back into the original module at some
> > point in the future, then obviously a non backwards compatible version
> > change is being forced on to the client, along with additional work on
> > the server as well.
> > 
> > I think that there are also many cases where the number of data nodes
> > being added via an enhancement is small compared to the size of the
> > module being updated. In this case I believe that it better to add
> > these data nodes into the module itself, perhaps predicated under
> > if-feature if appropriate.
> > 
> > Thanks,
> > Rob
> > 
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=8si7cLdi3y5avgA6Nvi0V0TixjVoKFudWwp3mJNat5I&s=4OHPx7mvkQdY9-M_M5HEOcYS566LOUuNecztVjp_NFw&e=
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIFAw&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=8si7cLdi3y5avgA6Nvi0V0TixjVoKFudWwp3mJNat5I&s=4OHPx7mvkQdY9-M_M5HEOcYS566LOUuNecztVjp_NFw&e=


From nobody Mon Nov 12 15:37: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 3C8D6130E9C for ; Mon, 12 Nov 2018 15:37:02 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Alcb0PeBFfUQ for ; Mon, 12 Nov 2018 15:36:59 -0800 (PST)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820059.outbound.protection.outlook.com [40.107.82.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBF33130E46 for ; Mon, 12 Nov 2018 15:36:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IkIdU5bEPaDIhV0PbyvLYmO9j9EIdBBabc+MyqBvCMU=; b=e34VdEMThYEaybojyLbfEOtMI++7ugokh+1Cpxl4wD62IVe9VoR+VfqgYVTKBJ0ALhMi1GGBP5HjVnghZW5ypemr1o0yQ+U0MitmEbHWY/lj7THEeHuCiZz8IvMoAiouEpMU0pYRZ6rRq/hUHhfTufaKBebED9QUugP2Z9XW1E0=
Received: from MWHPR2201CA0049.namprd22.prod.outlook.com (2603:10b6:301:16::23) by CY4PR22MB0599.namprd22.prod.outlook.com (2603:10b6:903:eb::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.29; Mon, 12 Nov 2018 23:36:58 +0000
Received: from CO1NAM03FT007.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e48::204) by MWHPR2201CA0049.outlook.office365.com (2603:10b6:301:16::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1294.23 via Frontend Transport; Mon, 12 Nov 2018 23:36:58 +0000
Authentication-Results: spf=pass (sender IP is 192.147.115.52) smtp.mailfrom=Aviatnet.com; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=bestguesspass action=none header.from=Aviatnet.com;
Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.52 as permitted sender) receiver=protection.outlook.com;  client-ip=192.147.115.52; helo=mail-send.aviatnet.com;
Received: from mail-send.aviatnet.com (192.147.115.52) by CO1NAM03FT007.mail.protection.outlook.com (10.152.80.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1339.10 via Frontend Transport; Mon, 12 Nov 2018 23:36:57 +0000
From: Alex Campbell 
To: joel jaeggli , NETMOD Working Group 
Thread-Topic: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
Thread-Index: AQHUeuCYPynVjMzsZUumk/tVht2Miw==
Date: Mon, 12 Nov 2018 23:36:55 +0000
Message-ID: <1542065815557.72600@Aviatnet.com>
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>
In-Reply-To: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.10]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:192.147.115.52; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(136003)(346002)(39850400004)(396003)(376002)(2980300002)(438002)(189003)(199004)(3846002)(956004)(6116002)(11346002)(2616005)(14444005)(118246002)(246002)(476003)(23746002)(47776003)(39060400002)(305945005)(7736002)(7636002)(8676002)(36736006)(446003)(316002)(7596002)(5660300001)(53546011)(86362001)(110136005)(8746002)(8936002)(486006)(126002)(53416004)(336012)(7696005)(76176011)(36756003)(186003)(26005)(478600001)(117636001)(25786009)(356004)(6306002)(6486002)(2906002)(72206003)(50466002)(6246003)(106466001)(966005)(102836004)(97876018)(229853002)(106002)(554374003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR22MB0599; H:mail-send.aviatnet.com; FPR:;  SPF:Pass; LANG:en; PTR:mail-send.aviatnet.com; MX:1; A:1; 
X-Microsoft-Exchange-Diagnostics: 1; CO1NAM03FT007; 1:fRt7OaonN59F4q/cbFBa9wG+7Z5JXA0qMVERFwF9ZTTYFVJHTiMhv85i2NvmKHDmro/UoariEM19OkwikQGtMx7t+moAsjZnb0v9yNFUU4M2AJ9FgyPtrnTcWw7xU+xO
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 44f22ede-5bc8-402e-91ec-08d648f7bc7f
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390040)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4608076)(2017052603328)(7153060)(7193020); SRVR:CY4PR22MB0599; 
X-Microsoft-Exchange-Diagnostics: 1; CY4PR22MB0599; 3:ad45P3Q+gseguwNduRSVKvQlHh4VuOvHlMN/OF4kx3Vh1N8KKqlwxzZplOInT+ZikuS4WLlDXnTQR6j7mbDl02ns650cbp5mC0rTkAJlqZCgpEMDRQJslkWDOK0Y5ocJHtJopzinon5k8R8LyOpvfWV5bPi9tO4AICQ9r4/54M+e0M+FOnOrTa0E7h46IJwUR5LBU7KA/QzVCq4oKtwSeZF1q8fJTjvGiu+rchLeOzrG2Hb/iB9P7X313xkXpyTAMUqjwuhQ4M7o7XeqngkWeNB2YbW61qnnnfS/hiXFUjQPjojBAm9vwNbTSMZWQ9r7f/x5IvZGKNlWQfIIBsddSyEEhWOyF/s1X6rdYP6/3gc=; 25:nL7zBQ52Za/NQPD3sO4Azb01Z8Ccb80fRWX+EP6XL8gvuzomho6Qjhc3mgISs2uPh2wqrL70TTKy9SNVDKXOInLFtwwKpKv8lpObRvSKVrilAXnQn5OJOs9SIsnDVYGHivaFkMKzGnDKLi/JUj29Fczqq+0kt6DtyrqTtphl491rWQRy1oeWM5Xs/bhMjD9fgigmgRBKrjIXY0RNcUlw2lwZ2hxZ/v9v7bEZsm1CdyTKbH44MWwZ9CwbVdLnVSjdeLbAfZA9qylyE+CBfQZoVhkvS7AzgLgnofz9zhYW6YHsMW0QyfIIsII40C/zay1I/te1czZdXUx7ggETAgZjYg==
X-MS-TrafficTypeDiagnostic: CY4PR22MB0599:
X-Microsoft-Exchange-Diagnostics: 1; CY4PR22MB0599; 31:4MRwM39KM13zX7gosF5MuoI3mEHIisoX6zq4yYR2mxbTYiV9m86KmD9Dq82VW8CcyPMiJ3jJJ4VmXHlVLkAZLMrYt2Z3l0QtzO/1jb6s/EulHBO+Tma2XLlarwo/Nc6v0JOhCTBsg/rr9I3FL1vTPbmGf2LKkgxIRdHYx6gYd0/TfUNHFt4Y95TsglpeRC8+7Yi/iW5JtrVRMP3g00I6LUh1H3fsiWzHyq1IYrvuUr4=; 20:LrWgjDEWtD2q+50vigdZ0p/EfEcj9TftnJZs2XmlNv7K1h4B94yMQNyghAI2JFfK6sNUe3mR4MuS43gB6Yk2iaklZIPZTi60BmLkjax6LkqtSMlU5pZ6PftNKnkVMnUAdtaY4oh+zEcKj3xfqPewbT5J2x5jJRiVaU7xAM/hJBwfEcaOepxXXSze0sFuBxbq1UH6ihZAJd8jSRCfJF4X9XpBGgQ0z/b9XA1PBB/4rkvuBaLFP3xbKnW09+v+SjHGlFCNZso3uj2AIvOERx4df7lRpAUlRe0gP1NB36wiwRf3TbRlMTuEpdnaA/exMXKBFgpi66VuX9CpQIJOcERiAJHbUH7sZ/RxWXr95BlrF2TZ0UlAmQnPZa4EFnAg4iOSGezkiWtmeF4CV9VRddkhevTnLnQeBKv0iR3mqkBrYQEV8QYgHDvYcf0h/f7Q53IRGaLS4qOwxVGMZhruqJLOYcoV573y3Osf0TFsRAecnMsVm4briVnzkvmdEKfQZPV8
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(100405760836317)(158342451672863)(85827821059158); 
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93004095)(3231402)(944501410)(52105112)(3002001)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:CY4PR22MB0599; BCL:0; PCL:0; RULEID:; SRVR:CY4PR22MB0599; 
X-Microsoft-Exchange-Diagnostics: 1; CY4PR22MB0599; 4:gFwC1BxjGsrUGDIGdwhNAUv4kBuMNTbt775zE+uG0btZIvb4ibgGIgoEZn+lfuoa8ChUzLRwKv4mmBKn6/ja0xnWkEn/9cXlxeRRMRuwYOi0/uJO1wdk5c+iU6TO8GykU4aV0sHDA7fV+Z4tBvoedzM9heceuff9MSqiyfEDivLXFCMMyLY6Cyk1n7RBQbFslS7say0DDNDQaF2/PSxK5jfG4lOjwIUsVu21mmiHpWDYO4SgH4m+/kOaw++p9UjVmIwiKcLjG1N2TbcT7VjHs+WixlDP9Q475+t4OxK3ALD74ssznCfzHsg5T2C+d+EHsD9FxY7pKQrQpULfuMvoV6SF+O9+MvakMiIAGYD42uwAhjoq6PmjBsrxLFbJZwcx
X-Forefront-PRVS: 0854128AF0
X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; CY4PR22MB0599; 23:avhpt5/5mEOHZX/t1JlYWEfUo8zLTnr+K9dmb?= =?Windows-1252?Q?QD8hoO6eNbXNfZfT3Wq1P4EfW1xvoG7WkQ/rf9MO8+zvYjrDCBoSOh32?= =?Windows-1252?Q?c1ezCvV065mNHRWEiF3sFPmO+4Sz8JztDKG6pOusJ5A3xz+PzsoKNYM+?= =?Windows-1252?Q?iC9Q735T85znyGybER+j3ilIID9hUaqer9pBH10hc9lGjaVwXxOCSYv0?= =?Windows-1252?Q?gHVS+kZKUqx3ECwJ9wEZtnvOqmHmq58yLmQTnWZdrn8wIQ4y5AdLeO0r?= =?Windows-1252?Q?nX8SJingOjNrHutMpsGIaaafVsR1A0g8S80JNl5MKN4baAfmKKeAn09M?= =?Windows-1252?Q?lhIJ+FvhHyv+vGOEoVT401lRqP+Fe8969QjVZnAhfgOJYXbo+/9+TGVe?= =?Windows-1252?Q?kNVgsbdJl/luh8Py2z4JOQJmAuwL0S2BNnXlPNSkMa++wH4HL03dTRcL?= =?Windows-1252?Q?d2F4muFQq2Ii3oWirGNN+pdOkIAilDFV1WDZTXgot6QwNIEXLcqhrn6a?= =?Windows-1252?Q?Wf6R8L/ONqtpy/D4BmfxjEbC1Zmh5oqeapgEka79sQV1h/Ij07FJPl8w?= =?Windows-1252?Q?n+JIo3vWe1YncB71Ok+6ddagAvAdsBMzTGC6RqjWN9VWjloPaW1PWjf6?= =?Windows-1252?Q?gyLz1u9lXt1BqVPsHoLNbhgbY567ykR2+emruPv/qHTQ0M6rHKI39MZe?= =?Windows-1252?Q?n1RWpsZawnjpI74jYe4CdSxwAO4pYa/2fzh72koUGg+uEz/+5aLP+Zm9?= =?Windows-1252?Q?KEtP61MEMxFs2PafbXz6mpT/ICNQEd9+D3rWbSYMvo290+NMdYJ6Pozt?= =?Windows-1252?Q?4Pz4m9stGVnHP9Zc1clvCH6UeKJODqJsr9fDyHLzU1Jqg6SkkBBJTz7O?= =?Windows-1252?Q?HmLPuzCczkqzC30mkdTGQFH9Hg9hcQwaV0lrYf+YDxdVD+vqupVFR4u+?= =?Windows-1252?Q?FoFqLY3UZBqf3Nkj7fE33dpNQI4jGenxYG81IG7SvIzgcV4M3LQeWem7?= =?Windows-1252?Q?sdQs2+X8JNbq1XlI640k7ClFnVaxUVhL3Vgek/Z/7AtKSVBRajvvi5Wv?= =?Windows-1252?Q?jfG52Hw/oitrQI5DEHomNxDRHsJpoK0y2JK7oqm/PzTohyw/D9T0Pasb?= =?Windows-1252?Q?imtiOX7SImFiBIhF+jNAzQjJIdQ+VvYNKEbAq5AXoq5niMsOc+j2S1uA?= =?Windows-1252?Q?pwg3KX3i+txY/nIMxmy/Qp7T96Jkm6jy7JaTj0CYjCpMWy13eaL0z/RC?= =?Windows-1252?Q?TWYMUNGNK1GL2rIZFiWxoJZfIlXfNnvee8bU9fV94UHQry9ZYZmyi/Sb?= =?Windows-1252?Q?0zaanjNXzQY0TdRkIFH7O+4wWwrZ2fc3SFySMwF/SKgwgcnUwQ/AsTao?= =?Windows-1252?Q?P+coXo9ucm/4OYvrW+3ktoUt7REVkwzHOv/AbYihMpMqaOivYsgWJI?= =?Windows-1252?Q?=3D?=
X-Microsoft-Antispam-Message-Info: jxGAA9J7KAmcsypvex/aeMBw+o1Emh/1ULsXpvmwYsD6OJ7SMzUNOdkASbmhrkbi7CDUZQk9fVTF6WslJIlwcp8BfuRe+vu8hS0NSURm9BNbhKdmLTtBshuWAwbE0S08sHBObMsJM3VPeXCG/6MVBUb9nog37fl3QVPMURKxLWUqd1r5Ht7zf9neICD0wfsLHZvP4eO4gPONrvYBojlNhLupTynrxvgNa+XddvrlzgZrgNPCzjU98wODPJYNfSKIJdtEk5uAIJfAwKrq7R8AOMC/crbnY8/Mn/Cec5mUGGf7xn2cXTpUEnExhngs3yRIRj84SqiTM3PUDqjZqG/NP1aRDGos/E2JoqqK9kP6UIw=
X-Microsoft-Exchange-Diagnostics: 1; CY4PR22MB0599; 6:3iD/vm/yd/+W2FN1M4o5j2p1P5MDXdJ5P5tzl5KZ2KgYEWtSGYR6CudLS0oEM4Gs/9njayHjO76D5uj4TksAgLm1NG+HcMzueR909vdK00g6D+EBHCI2K0nA1iUBpB/K55pQDP+MbB4sXjqU4rRdek4VyjxjWjQlDXAqcwnWoneTLiKVo3stDmTD9oeOMzmhIyZVDbGsZ2sFucTvjAWlqcTWrizJ6EfW+aCbRpcZZQkRM2c8xP0mVThx6oVx3lhFstapCxC/YaIssDt974f9uUHYyO9ymj1ADFznmuiA6j7ReFiIeKYHmpafTvFPOBZjhJmE0QOqPJk2t/RaS6lFk4L+i2GVQzfLcZmqBlL4ooSuXrfC/6xIH30YpyCc6ttC7q66CyI+o0Gb4LxFXqB8+zvKrianZOAeoy9VFpdNF/VHk5l7rUovD+ljb8z+5HUq5Jgrva1xfc9raQGN+y86mg==; 5:KRyWEOXCgD+fkWNnsoy8CBjK4vqvj7QUWUO7N5DzuIqZfmQMjpGVgNucvLMRJ4zE9xmnfFXnjYazOV18FPq48oCBsfcKDcFr4HAaBLVA671T3UUW/sG+Jhse5iyv0NSenH8xS6PfAKXCGs7GskdvqM7wiOefE1n4xBFPRyeBiG8=; 7:t80MqP/ZTaF02jr0tGejKHkcDpcFfZAa5XQ1Y/O4eeKXMq5VC15YyicrhNqvRebJwLzfxhx8WcIfjjgFBmpxZFPkNn4AX1QNquP4jA1ZTb5t1qlb46KkvZ5Uh7UGfziV9Vs8T0OjRsmxVoWFEE6ixg==
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: aviatnet.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Nov 2018 23:36:57.4852 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 44f22ede-5bc8-402e-91ec-08d648f7bc7f
X-MS-Exchange-CrossTenant-Id: 8d7d22b9-3890-4eef-95a6-a226e64151be
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8d7d22b9-3890-4eef-95a6-a226e64151be; Ip=[192.147.115.52];  Helo=[mail-send.aviatnet.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR22MB0599
Archived-At: 
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Nov 2018 23:37:02 -0000

Hi,=0A=
=0A=
I was not at the IETF meeting unfortunately.=0A=
=0A=
I see that the technical issues raised in the WGLC have been fixed, which i=
s good.=0A=
=0A=
However I still have reservations about the utility of the proposed standar=
d. It seems to me like a solution in search of a problem, and I can't under=
stand why it should be pushed forward to an RFC. Maybe there is some contex=
t I am missing. The use-cases that have been described to me so far seem li=
ke they would be better served by a client-side mechanism. Perhaps the clie=
nt-side data store can still be modelled in YANG, but in that case, I think=
 the document should say so.=0A=
=0A=
I asked why the server should hold the data. The reason I am given is "so t=
hat clients can read it." Why is the data not on the client in the first pl=
ace?=0A=
The client can make modifications to the data, so that the client can read =
it back later. Why does the client need to store these modifications outsid=
e of itself?=0A=
=0A=
I am told this is a general-purpose tool. In that case, I would like to see=
 at least two or three separate use-cases so that I can be sure this is act=
ually a *useful general-purpose abstraction*, and not something specific to=
 the one (or zero!) use-cases the authors seem to envision. I am aware that=
 the cost of creating bad standards can be quite high, if the next person w=
ho wants some YANG module metadata feels obligated to use the existing tag =
mechanism instead of something new, but finds it doesn't quite fit their ne=
eds. See also https://blog.codinghorror.com/rule-of-three/ and https://www.=
sandimetz.com/blog/2016/1/20/the-wrong-abstraction=0A=
=0A=
I think the draft could also do with describing how this module is supposed=
 to be used. A YANG module in isolation means nothing. Most of the YANG mod=
ules I am familiar with are to define configuration and/or state data to be=
 stored on a network element or a provisioning/orchestration system, and ac=
cessed over NETCONF. I believe it is implicit that unless otherwise specifi=
ed, YANG modules are intended for NETCONF use, but I am unclear on which ki=
nds of NETCONF servers should implement this module.=0A=
=0A=
Perhaps my opinion also carries less weight, as someone who's only on the m=
ailing list and didn't actually attend the IETF meeting.=0A=
=0A=
=0A=
=0A=
________________________________________=0A=
From: netmod  on behalf of joel jaeggli =0A=
Sent: Tuesday, 13 November 2018 5:46 a.m.=0A=
To: NETMOD Working Group=0A=
Subject: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus cal=
l=0A=
=0A=
During the Thursday nov 8 session of netmod, we asked if there were any obj=
ections to the publication of the Draft-03 version of draft-ietf-netmod-mod=
ule-tags which addresses comments and concerns raised during the WGLC. In t=
he meeting there were none. This commences a comment period to confirm that=
 call. As this follows closely on the heels of the IETF 103 meeting we=92ll=
 let the call run through Monday the 26th of November.=0A=
=0A=
https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-module-tags-03.txt=
=0A=
=0A=
=0A=
Thanks=0A=
Joel=0A=
_______________________________________________=0A=
netmod mailing list=0A=
netmod@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netmod=0A=


From nobody Mon Nov 12 16:02: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 F2350130DC2 for ; Mon, 12 Nov 2018 16:02: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, 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 cWPjj9M6K7S0 for ; Mon, 12 Nov 2018 16:02:21 -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 7F16F128CE4 for ; Mon, 12 Nov 2018 16:02:20 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id p17so7500599lfh.4 for ; Mon, 12 Nov 2018 16:02:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1UoRvRIJay71QjXdWZdGm7iA/SX8qnop72zn64Po6DM=; b=rT/E4X2BqYeS+Ar/Pf5cQaoxnzKw5tfdRVDiUci5kVfycgCyWTz9ABAABcwYHpCLtk Us6Zb/D/irlYSExboUBxKcH7yNFEitxIbMjSvWca+zof+soegdc6m/RfAYEE66g78+R7 3DRLsnD6TKPDuCLdtsZQzJ1Gq+8bNEzSUBSP9wVlwmdiU1ngtbCgAkX/kQVMk/M5+sNr hd5olXN9wWT0kBrslNk3gLyGmR8LG1eawpdNXHHIDPXTQg9c5gq3FA2hCuL5JtVYDIzX 3+A8d3Yv9bUff00VhUA77f80+KJvgy/DWJxRxzUWdw+GlgJ0YELSmaVDwEIIFviBgtaA 7zzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1UoRvRIJay71QjXdWZdGm7iA/SX8qnop72zn64Po6DM=; b=R8wlUCoFH80CJr4YaSodGNPPiuOVL8+tu+0CZCGtxxIODmbSfO3uirtKd3f6lLybxB ls/RvXRbjNs1a90UjQ0aemP9UBxo6sirOf+BG1X+RQNgljeWfrsBv31ekEm6NBskjKsf 3hXwJ6dF0lPHBWb1BOsAnC5YrX3hvkyfdbx1I/O+VQOQaToeAxkpAE7i1G0WzPYEnr73 GHnu6CLGyx14A4ir7tzGy4x3iCzmJNdyKNeWOx1yIYFOz3fiPv2swTq8v0u1z6EqhLA1 HKXlHWknk1HghZj3NYTl7wv5WgWXRED4CUdItAsg50plgLDKxcxzxyOH+ZgZQZPSwdap Lfbw==
X-Gm-Message-State: AGRZ1gJPJqHQNqBN4MnQuT7mjZru8RD79DNaybenf7WWa3qoI9m4QstA NrUpVQdj7Vu96jgmJLYSDdXsRym4raP6u8hv615G2Q==
X-Google-Smtp-Source: AJdET5dSoC5CQlecUD3GYfSmckc5MvBD6dD2B4PexSyHYNNoombSS7nsRX/LwOZoPTW20DiiQuz3K/64x/aA8APJFtc=
X-Received: by 2002:a19:690d:: with SMTP id e13mr1725079lfc.84.1542067338358;  Mon, 12 Nov 2018 16:02:18 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Mon, 12 Nov 2018 16:02:17 -0800 (PST)
In-Reply-To: <0ffe7036-58ff-abbc-c0fd-efd6e251f815@cisco.com>
References:  <5d8a14f4-94a9-c6eb-4a7c-6d6a155e0c84@cisco.com>  <0ffe7036-58ff-abbc-c0fd-efd6e251f815@cisco.com>
From: Andy Bierman 
Date: Mon, 12 Nov 2018 16:02:17 -0800
Message-ID: 
To: Robert Wilton 
Cc: NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000ec4d27057a808749"
Archived-At: 
Subject: Re: [netmod] missing YANG versioning requirements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 00:02:24 -0000

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

On Mon, Nov 12, 2018 at 9:20 AM, Robert Wilton  wrote:

>
>
> On 12/11/2018 16:15, Andy Bierman wrote:
>
>
>
> On Mon, Nov 12, 2018 at 7:01 AM, Robert Wilton  wrote:
>
>>
>>
>> On 09/11/2018 18:35, Andy Bierman wrote:
>>
>> Hi,
>>
>> I think the requirements doc should state that
>>
>> 1) there are many more readers, operators, and client developers than
>> server developers so the solution MUST take into account the numbers
>> of people affected when finding a balance between client and server
>> complexity.
>>
>> OK.  So you would like the solution to be weighted towards clients, but
>> yet you do not want servers to have to implement any sort of version
>> selection, instead pushing the problem on to the client? :-)
>>
>>
>
> I support some aspects of this work:
>   - SEMVER
>   - import-stmt
>   - status-stmt
>
> OK
>
>
> I strongly oppose the simultaneous implemented revisions requirement
> because it is actually
> a solution, not a requirement at all, and a bad solution.
>
>
>
> For any given buggy data node, a replacement sibling can be created so the
> new node and the deprecated
> buggy node can both be implemented.
>
> So, I regard this as a potential solution to requirement 3.2.
>
> However, I still do not understand a scheme for how this works for config
> items, either covering all of the various corner cases of clients at
> different versions, or at least states under what assumptions that solution
> works.
>
> Please can someone who thinks that this is a solution explain how this
> solution works.  I think that there are quite a lot of potential
> questions/issues:
>
>
I think model transformation is a flawed solution and not worth doing,
especially since the goal is to map NBC changes that do not work well with
this solution.
It is designed to map 1 disjoint subtree to another one, not really 2
revisions of the same nodes.
To be clear: I am not proposing that this solution be standardized at all.



> Are there two version entirely independent of are they connected (i.e.
> updating one, updates the other)?
>

no


> If they are dependent then does writing one value also update the other
> one?
>

no


> If they are independent they can two different values be written (perhaps
> for a pair of leaves this could be enforced with a must statement), but
> with more complex models this is not possible?
>


The  and  datastores would have the configured values,
and 
would have the value in use.

   start: foo = bar = 5
   config: foo=5, bar=5
   operational: foo=5, bar=5

  set bar to 10
  config: foo=5, bar=10
  operational: foo=10, bar=10

the 'origin' value is 'intended' for bar.
Not sure what it should be for foo.






> Does this solution support 2 clients interacting with the server using
> different versions of the leaf, or is it assumed that all clients will
> interact using the same version?
> What happens if both leaves have different default values (perhaps this
> can just be avoided)?
> What happens when the new value cannot be represented in the old leaf used
> by client A?  It now has a configuration that it cannot change because it
> doesn't know about the new leaf.
> What leaf values are updated in operational?  Is it both of them, or just
> one of them?
>
>
>
> YANG represents a customer-facing API, like the CLI.  Vendors understand
> that customers
> don't like it when CLI keywords change meaning from release to release.
> Vendors are careful
> to introduce new keywords so the old ones keep working.
>
>
> For our CLI, we generally accept the old, but always return the config
> using the new CLI.  However, I would expect that approach would probably
> break clients using YANG.  They would be confused that the configuration
> returned via get-config does not match what they programmed via edit-config.
>


If the transformation is 2-way then get-config can return the outer model.
You have to do that if the client implements only the
outer model and the server does not even advertise the inner model.



>
>
>
>
>> More seriously, I'm looking for a solution where we it up to the market
>> to decide whether the complexity should be pushed to client, server, or a
>> 3rd party controller.  I think that some sort of version selection should
>> be able to achieve this.
>>
>>
>>
> I do not agree the standards should be changed to support this solution
> approach.
>
>
>
>
>>
>> 2) if existing protocol and YANG solutions exist then they MUST be used
>> in favor of developing new solutions.
>>
>> If you replace the "MUST" with a "SHOULD" then I sort of think that this
>> one is obvious.  I think that we are only trying to develop next solutions
>> where the existing ones do not appear to be working well.  There are
>> examples in the earlier text in the requirements draft, and also
>> draft-clacla-netmod-yang-model-update to provide the background and
>> justify why we need to do something different than the status quo.
>>
>>
>
> It would help to have real examples where deprecate-and-replace was an
> unworkable solution.
>
> I would happy to start with an example where you think it does work,
> taking into consideration the questions that I provided previously.
>
> IMO it is OK to update a data node because sub-statements are incorrect
> (e.g. pattern, type).
> In this case, the old definition is not worth preserving.
>
> This can still break some clients.
>


Agreed.
It depends on the bugfix.
With the ip-address pattern example, a correct client would only be
sending valid addresses that match the new pattern.  I understand that
sometimes a vendor wants to let the client send invalid values.
IMO this is a case where deprecate-and-replace is needed.



>
> Note that changes between I-Ds are not interesting.  Only changes from RFC
> to RFC are interesting.
> Vendors need to review their own modules and do a better job identifying
> stable vs. unstable releases.
>
> I agree to both of these.
>
> But lets not pretend that all code that we ever produce will be perfect
> the first time, contain no bugs, and never need to be changed.  We have
> seen the industry push for us to be more reactive and get changes out more
> quickly.  I would argue that a natural side effect of that is that there
> are likely to be more bugs that will need fixing.
>
>

Nobody is pretending code or YANG will be perfect in the first release.
The issue is how you fix the module and support existing clients at the
same time.
Since the new client has to know about the new revision anyway (even if
/restconf is
changed to /restconf2) is is usually OK to deprecate and replace the buggy
node.


Thanks,
> Rob
>
>
>
Andy


>
>
> Thanks,
>> Rob
>>
>>
>
> Andy
>
>
>>
>>
>>
>> Andy
>>
>>
>>
>> _______________________________________________
>> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>>
>>
>>
>
>

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




On Mon, Nov 12, 2018 at 9:20 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    


    

    

    
On 12/11/2018 16:15=
, Andy Bierman
      wrote:

    

    

     =20
      


        


          
On Mon, Nov 12, 2018 at 7:01 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            

              

                


                

                

                
On
                  09/11/2018 18:35, Andy Bierman wrote:

                

                

                  
Hi,
                    


                    

                    
I think the requirements doc should state that
                    


                    

                    
1) there are many more readers, operators, and
                      client developers than

                    
server developers so the solution MUST take
                      into account the numbers

                    
of people affected when finding a balance
                      between client and server complexity.

                  

                

                OK.=C2=A0 So you would like the solution to be weighted
                towards clients, but yet you do not want servers to have
                to implement any sort of version selection, instead
                pushing the problem on to the client? :-)

                

              

            

            


            

            


            

            
I support some aspects of this work:

            
=C2=A0 - SEMVER

            
=C2=A0 - import-stmt

            
=C2=A0 - status-stmt

          

        

      

    

    OK

    

    

      

        

          

            


            

            
I strongly oppose the simultaneous implemented
              revisions requirement because it is actually

            
a solution, not a requirement at all, and a bad
              solution.

              

            

          

        

      

    

    

    

      

        

          

            


            

            
For any given buggy data node, a replacement sibling
              can be created so the new node and the deprecated

            
buggy node can both be implemented.

          

        

      

    

    So, I regard this as a potential solution to requirement 3.2.

    

    However, I still do not understand a scheme for how this works for
    config items, either covering all of the various corner cases of
    clients at different versions, or at least states under what
    assumptions that solution works.

    

    Please can someone who thinks that this is a solution explain how
    this solution works.=C2=A0 I think that there are quite a lot of
    potential questions/issues:

    

I think model transformation=
 is a flawed solution and not worth doing,
especially since the g=
oal is to map NBC changes that do not work well with this solution.
It is designed to map 1 disjoint subtree to another one, not really 2 re=
visions of the same nodes.
To be clear: I am not proposing that t=
his solution be standardized at all.

=C2=A0

    Are there two version entirely independent of are they connected
    (i.e. updating one, updates the other)?

=

no
=C2=A0

    If they are dependent then does writing one value also update the
    other one?

no
=C2=
=A0

    If they are independent they can two different values be written
    (perhaps for a pair of leaves this could be enforced with a must
    statement), but with more complex models this is not possible?


The <running> and &l=
t;intended> datastores would have the configured values, and <operati=
onal>
would have the value in use.

=
=C2=A0 =C2=A0start: foo =3D bar =3D 5
=C2=A0 =C2=A0config: foo=3D=
5, bar=3D5
=C2=A0 =C2=A0operational: foo=3D5, bar=3D5
<=
br>
=C2=A0 set bar to 10
=C2=A0=C2=A0config: foo=3D5, bar=3D10
=C2=A0 operational: foo=
=3D10, bar=3D10

=

the 'origin'=
; value is 'intended' for bar.
Not sure what it should be for foo.




=C2=A0

    Does this solution support 2 clients interacting with the server
    using different versions of the leaf, or is it assumed that all
    clients will interact using the same version?

    What happens if both leaves have different default values (perhaps
    this can just be avoided)?

    What happens when the new value cannot be represented in the old
    leaf used by client A?=C2=A0 It now has a configuration that it cannot
    change because it doesn't know about the new leaf.

    What leaf values are updated in operational?=C2=A0 Is it both of them, =
or
    just one of them?

    

    

    

      

        

          

            


            

            
YANG represents a customer-facing API, like the CLI.=C2=A0
              Vendors understand that customers

            
don't like it when CLI keywords change meaning from
              release to release.=C2=A0 Vendors are careful

            
to introduce new keywords so the old ones keep working.
          

        

      

    

    

    For our CLI, we generally accept the old, but always return the
    config using the new CLI.=C2=A0 However, I would expect that approach
    would probably break clients using YANG.=C2=A0 They would be confused
    that the configuration returned via get-config does not match what
    they programmed via edit-config.

<=
div>
If the transformation is 2-way then get-config can retur=
n the outer model.
You have to do that if the client implements o=
nly the
outer model and the server does not even advertise the in=
ner model.

=C2=A0

    

    

      

        

          

            


            

            
=C2=A0

            

              
 More seriously, I&=
#39;m
                looking for a solution where we it up to the market to
                decide whether the complexity should be pushed to
                client, server, or a 3rd party controller.=C2=A0 I think th=
at
                some sort of version selection should be able to achieve
                this.

                

                

              

            

            


            

            
I do not agree the standards should be changed to
              support this solution approach.

          

        

      

    

    

    

      

        

          

            
=C2=A0

            

              

                

                  

                    


                    

                    
2) if existing protocol and YANG solutions
                      exist then they MUST be used

                    
in favor of developing new solutions.

                  

                

                If you replace the "MUST" with a "SHOULD&quo=
t; then I sort of
                think that this one is obvious.=C2=A0 I think that we are
                only trying to develop next solutions where the existing
                ones do not appear to be working well.=C2=A0 There are
                examples in the earlier text in the requirements draft,
                and also draft-clacla-netmod-yang-model-update to
                provide the background and justify why we need to do
                something different than the status quo.

                

              

            

            


            

            


            

            
It would help to have real examples where
              deprecate-and-replace was an unworkable solution.

          

        

      

    

    I would happy to start with an example where you think it does work,
    taking into consideration the questions that I provided previously.

    

    

      

        

          

            
IMO it is OK to update a data node because
              sub-statements are incorrect (e.g. pattern, type).

            
In this case, the old definition is not worth
              preserving.

          

        

      

    

    This can still break some clients.


Agreed.
It depends on the bugfix.
=
With the ip-address pattern example, a correct client would only be
sending valid addresses that match the new pattern.=C2=A0 I understand t=
hat
sometimes a vendor wants to let the client send invalid value=
s.
IMO this is a case where deprecate-and-replace is needed.



    

    

      

        

          

            


            

            
Note that changes between I-Ds are not interesting.=C2=A0
              Only changes from RFC to RFC are interesting.

            
Vendors need to review their own modules and do a
              better job identifying stable vs. unstable releases.

          

        

      

    

    I agree to both of these.

    

    But lets not pretend that all code that we ever produce will be
    perfect the first time, contain no bugs, and never need to be
    changed.=C2=A0 We have seen the industry push for us to be more reactiv=
e
    and get changes out more quickly.=C2=A0 I would argue that a natural si=
de
    effect of that is that there are likely to be more bugs that will
    need fixing.

    


Nobody is pre=
tending code or YANG will be perfect in the first release.
The is=
sue is how you fix the module and support existing clients at the same time=
.
Since the new client has to know about the new revision anyway =
(even if /restconf is
changed to /restconf2) is is usually OK to =
deprecate and replace the buggy node.



    Thanks,

    Rob

    

    

Andy
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

    

      

        

          

            


            

            


            

            

              
 Thanks,

                Rob

                

              

            

            


            

            


            

            
Andy

            
=C2=A0

            

              
 

                

                  

                    


                    

                    


                    

                    
Andy

                    


                    

                  

                  

                  

                  

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


                

                

              

            

          

          

        

      

    

    

  






--000000000000ec4d27057a808749--


From nobody Mon Nov 12 16:03: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 A7332130DC2 for ; Mon, 12 Nov 2018 16:03:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOzS3-PFNTgn for ; Mon, 12 Nov 2018 16:03:05 -0800 (PST)
Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 10430128CE4 for ; Mon, 12 Nov 2018 16:03:05 -0800 (PST)
Received: by mail-pg1-x52a.google.com with SMTP id z10so4784125pgp.7 for ; Mon, 12 Nov 2018 16:03:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xDlu9U8PlUUq7t7J3nBAsFpniFsIbJnqxYOfAHKBN9g=; b=TQLAGIBOTfQhg5Qzs1tShAZh8DDR/kfpX40ej1pknKjJ5WOrngDlqwB6Un1q2jY1MQ SV/ZYNvoIaJmgTkcNN2d72Zigu9QB678WR8DQ6R4VuQd3azw5oa7PpZcsBM6BOq9GoaX QlLlmxEd5SAdc1qcbtAIZQ+zO14ebhsu8uAM3In06MjLKstE0wSQtH7myMUWmaJvmCiD Utv5Fjsl4ri6ADmvRsma8veWEwhJbFYH+ZzTl0X+t2ZaZPrD7cWgDYw2A/VRScEKdvnu OyHrrH/hlwgDQA5tCdFtEUMOnCkfGaNetjhWK3dSmDyELkyVHGfARzzCEQkkXl5UqNzI BNvA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xDlu9U8PlUUq7t7J3nBAsFpniFsIbJnqxYOfAHKBN9g=; b=ZxAJJ2L8iiFJdOxpgQhuJQo5SQSOvOxgGVpuPlg+DJPAjeLxGcSSU/Mx5MZBbgcovX +/8RA6Q2wod/H4FOhc28i8jDdUxoyhYwIEuvojHElHuEvfY1wrJDfRxtFydR/udIrA1S lY59JEBA/9PSA22InVwo6AMS0tOo12Sc7Eqc+fTZ6vuaytoOuFR9nAI2g6yCRy3jKV+p yzZvHBi8BXKCz8PeqEvPDTPDnODHY5Mf6vPx4qvZbwThJzRcTBhcNw21Dv8Gn6YXlqjD mMxGdTOYp4WsDWfPdA/ozaifq5iJhFLF3js2bYWXdT/g72uvHCMlny6RSZiMU+W1E2rW G6eA==
X-Gm-Message-State: AGRZ1gIb+hpejgGIKtqhc7+JlEzOP6lCZIExM6pMTuMKFpgc9pplMgHE 338r/RKR4XqaFhyvk2/KRoCeEMev
X-Google-Smtp-Source: AJdET5fkBtod2pTz8XN/3DQoTVoFoVezfgVSXBjMcHkmvMisVUHtoLlDr33hqEaDWvCdiZd2/dQGIw==
X-Received: by 2002:a62:1d14:: with SMTP id d20mr2826710pfd.221.1542067384331;  Mon, 12 Nov 2018 16:03:04 -0800 (PST)
Received: from [192.168.0.109] (c-73-202-177-209.hsd1.ca.comcast.net. [73.202.177.209]) by smtp.gmail.com with ESMTPSA id d3sm16268447pgl.64.2018.11.12.16.03.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Nov 2018 16:03:03 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: joel jaeggli 
In-Reply-To: <1542065815557.72600@Aviatnet.com>
Date: Mon, 12 Nov 2018 16:02:56 -0800
Cc: NETMOD Working Group 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com> <1542065815557.72600@Aviatnet.com>
To: Alex Campbell 
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: 
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 00:03:07 -0000

> On Nov 12, 2018, at 15:36, Alex Campbell  =
wrote:
>=20
> Perhaps my opinion also carries less weight, as someone who's only on =
the mailing list and didn't actually attend the IETF meeting.
>=20


So, the reason we take the discussion back to the list is precisely to =
insure that we capture the opinions of those not present in the working =
group meeting. I think that is a point to be addressed separately from =
the question of whether the document is ready to go or not.

Thanks
Joel


From nobody Mon Nov 12 20:55: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 23B84126F72 for ; Mon, 12 Nov 2018 20:55:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kn_i27QTblUS for ; Mon, 12 Nov 2018 20:55:35 -0800 (PST)
Received: from mail2.advaoptical.com (mail2.advaoptical.com [91.217.199.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16FDA124408 for ; Mon, 12 Nov 2018 20:55:34 -0800 (PST)
Received: from MUC-S-EX16D.advaoptical.com ([172.20.1.28]) by muc-vs-fsmail2.advaoptical.com (8.16.0.22/8.16.0.22) with ESMTPS id wAD4tQv1023851 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=FAIL); Tue, 13 Nov 2018 05:55:26 +0100
Received: from MGN-S-EX16B.advaoptical.com (172.25.1.192) by MUC-S-EX16D.advaoptical.com (172.20.1.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1591.10; Tue, 13 Nov 2018 05:55:25 +0100
Received: from MGN-S-EX16B.advaoptical.com ([fe80::c022:bed0:3eb:b5c5]) by MGN-S-EX16B.advaoptical.com ([fe80::c022:bed0:3eb:b5c5%7]) with mapi id 15.01.1591.008; Tue, 13 Nov 2018 05:55:25 +0100
From: John Messenger 
To: Robert Wilton , Lou Berger , "Holness, Marc" , "STDS-802-1-L@LISTSERV.IEEE.ORG" , "netmod@ietf.org" 
Thread-Topic: [802.1 - 12909] IETF Sub-interface VLAN YANG Data Models - draft-ietf-netmod-sub-intf-vlan-model-04
Thread-Index: AQHUdOi9tjNIF+LjDU2pKDc3UZOkWaVNIrng
Date: Tue, 13 Nov 2018 04:55:25 +0000
Message-ID: <9485c56783074f19b4fbf357e5e82946@advaoptical.com>
References: <14a5c6fd-b24a-9669-7701-75dd822f95e2@cisco.com>
In-Reply-To: <14a5c6fd-b24a-9669-7701-75dd822f95e2@cisco.com>
Accept-Language: en-GB, de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.20.1.231]
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-11-13_03:, , signatures=0
Archived-At: 
Subject: Re: [netmod] [802.1 - 12909] IETF Sub-interface VLAN YANG Data Models - draft-ietf-netmod-sub-intf-vlan-model-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 04:55:38 -0000

SGksDQoNCkF0IHRoZSA4MDIuMSBUU04gbWVldGluZyB0aGlzIG1vcm5pbmcsIExvdSBCZXJnZXIg
bWFkZSBhIHByZXNlbnRhdGlvbiBvbiBiZWhhbGYgb2YgUm9iIFdpbHRvbiBzdW1tYXJpc2luZyB0
aGUgcmVjZW50IGNoYW5nZXMgaW4gdGhpcyBkcmFmdC4gIEkgbGlrZSB0aGUgY2hhbmdlcyB0byB0
aGUgc3RydWN0dXJlIHdoaWNoIGFyZSBpbnRlbmRlZCB0byBhbGlnbiB0aGUgVkxBTiB0YWcgc3Ry
dWN0dXJlIHRvIHRoYXQgc3BlY2lmaWVkIGluIDgwMi4xUS4gIEkgbm90aWNlIHRoYXQgdGhlIGRy
YWZ0IHJldGFpbnMgY2xhdXNlIDIuMiAoRXh0ZW5zaWJpbGl0eSkgYnV0IEkgdGhpbmsgdGhhdCdz
IGEgYnVnLCBiZWNhdXNlIGl0J3Mgbm90IHJlZmxlY3RlZCBpbiB0aGUgbW9kZWwgKHdoaWNoIGlz
IGEgZml4ZWQgc3RydWN0dXJlIG9mIG9uZSBvciB0d28gdGFncykuDQoNClJpZ2h0IG5vdywgaXQg
c2F5cyB0aGF0IHRoZSBFdGhlcnR5cGVzIGFyZSB0YWtlbiBmcm9tIGRvdDFxLXRhZy10eXBlLiAg
V291bGQgdGhpcyBhbGxvdyB0YWdzIG90aGVyIHRoYW4gODAyLjFRVGFnVHlwZSAoODEtMDApIGFu
ZCA4MDIuMVFTVGFnVHlwZSAoODgtQTgpPyAgVGhhdCBzaG91bGRuJ3QgYmUgYWxsb3dlZC4NCg0K
TXkgcHJlZmVyZW5jZSB3b3VsZCBiZSB0byByZW1vdmUgdGhlIGZvcndhcmQtbG9va2luZyBzdGF0
ZW1lbnQgcXVvdGVkIGhlcmUgYmVjYXVzZSBpdCBpbXBsaWVzIGEgd2lsbGluZ25lc3MgdG8gZXh0
ZW5kIHRvIDMgdGFnczoNCglUaGUgc3RydWN0dXJlIG9mIHRoZSBtb2RlbCBpcyBjdXJyZW50bHkg
bGltaXRlZCB0byBtYXRjaGluZyBvcg0KICAgcmV3cml0aW5nIGEgbWF4aW11bSBvZiB0d28gODAy
LjFRIHRhZ3MgaW4gdGhlIGZyYW1lIGhlYWRlciBidXQgaGFzDQogICBiZWVuIGRlc2lnbmVkIHRv
IGJlIGVhc2lseSBleHRlbnNpYmxlIHRvIG1hdGNoaW5nL3Jld3JpdGluZyB0aHJlZSBvcg0KICAg
bW9yZSBWTEFOIHRhZ3MgaW4gZnV0dXJlLCBpZiByZXF1aXJlZC4NCg0KSXQgbG9va3MgbGlrZSB5
b3UgY291bGQgcGFyc2UgYW4gdW50YWdnZWQgZnJhbWUgYXMgZWl0aGVyIDoodW50YWdnZWQpIG9y
IDooZG90MXEtdmxhbi10YWdnZWQpICh3aXRob3V0IGVpdGhlciBvZiB0aGUgb3B0aW9uYWwgdGFn
cykuICBJcyB0aGF0IGEgYnVnPw0KDQpUaGFua3MsDQoJLS0gSm9obiANCg0KLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCkZyb206IExpc3QgSEVMUCBvbmx5IDxoZGsuMS1vZXlvOHZzNEBoamtl
ZW4ubmV0PiBPbiBCZWhhbGYgT2YgUm9iZXJ0IFdpbHRvbg0KU2VudDogMDUgTm92ZW1iZXIgMjAx
OCAxNjoxNg0KVG86IFNURFMtODAyLTEtTEBMSVNUU0VSVi5JRUVFLk9SRw0KU3ViamVjdDogWzgw
Mi4xIC0gMTI5MDldIElFVEYgU3ViLWludGVyZmFjZSBWTEFOIFlBTkcgRGF0YSBNb2RlbHMgLSBk
cmFmdC1pZXRmLW5ldG1vZC1zdWItaW50Zi12bGFuLW1vZGVsLTA0DQoNCkJhbGxvdCBkdWUgTm92
LiA2OiBQODAyLjFRY3gvRDAuNA0KRm9yIHBhcnRpY3VsYXJzIHNlZQ0KICBodHRwczovLzEuaWVl
ZTgwMi5vcmcvYWN0aXZlLWJhbGxvdHMvDQo4MDIuMSBsaXN0IGhlbHA6IGh0dHBzOi8vMS5pZWVl
ODAyLm9yZy9lbWFpbC1saXN0cy8NCkxpc3QgYXJjaGl2ZXMgKGFjY2Vzcy1jb250cm9sbGVkKSBi
eSBkYXRlOg0KICAgICAgICAgICAgICAgd3d3LmllZWU4MDIub3JnLzEvcHJpdmF0ZS9lbWFpbDIv
bWFpbDEuaHRtbA0KLS0tLS0NCg0KRGVhciBlc3RlZW1lZCA4MDIuMSBXRyBtZW1iZXJzLA0KDQpB
IGZldyB5ZWFycyBiYWNrLCBhdCB0aGUgc3RhcnQgb2YgbXkgSUVURiBhbmQgSUVFRSBzdGFuZGFy
ZHMgam91cm5leSBJIHdyb3RlIGEgZHJhZnQgZGVmaW5pbmcgYSBzdWItaW50ZXJmYWNlIGJhc2Vk
IFZMQU4gdGVybWluYXRpb24gWUFORyBtb2RlbC7CoCBBZnRlciBkaXNjdXNzaW9uIGFuZCBwcmVz
ZW50YXRpb25zIGluIGJvdGggSUVURiBORVRNT0QgV0cgYW5kIElFRUUgODAyLjEgV0csIHRoZXJl
IHdhcyBhIGdlbmVyYWwgYWdyZWVtZW50IHRoYXQgaXQgd291bGQgYmUgYWNjZXB0YWJsZSBmb3Ig
SUVURiB0byBwdWJsaXNoIHRoaXMgWUFORyBtb2RlbCBhcyBhbiBpbmZvcm1hdGlvbmFsIFJGQywg
d2l0aCB0aGUgYWNrbm93bGVkZ2VtZW50IHRoYXQgODAyLjFRIFZMQU4gdGVjaG5vbG9neSBpcyBv
d25lZCBieSBJRUVFLCBhbmQgaW4gZnV0dXJlIHRoZSBJRUVFIDgwMi4xIFdHIG1heSBjaG9vc2Ug
dG8gcHVibGlzaCBhIFZMQU4gdGVybWluYXRpb24gbW9kZWwuDQoNCkFzIHBhcnQgb2YgdGhhdCBJ
RVRGIE5FVE1PRCBXRyBwcm9jZXNzLCBhbmQgYWZ0ZXIgSUVFRSA4MDIuMSBXRyBoYWQgcmV2aWV3
ZWQgdGhlIG1vZGVsLCBJIG1hZGUgYSBzbWFsbCBjaGFuZ2UgaW4gc3RydWN0dXJlIG9mIHRoZSBZ
QU5HIG1vZGVsIHdpdGggdGhlIHNvbGUgYWltIG9mIG1ha2luZyB0aGUgbW9kZWwgc2ltcGxlciB0
byB1c2UuIEluIHBhcnRpY3VsYXIsIHRoZSBvbGRlciBtb2RlbCByZXF1aXJlZCBhIHNsaWdodGx5
IGNsdW5reSBpbmRleGVkIGxpc3Qgb2YgVkxBTiB0YWdzLCBhbmQgdGhhdCBpcyByZXBsYWNlZCB3
aXRoIGEgc2ltcGxlciBzdHJ1Y3R1cmUgc3VwcG9ydGluZyB0d28gZXhwbGljaXQgbmFtZWQgVkxB
TiB0YWdzICgnb3V0ZXItdGFnJyBhbmQgJ3NlY29uZC10YWcnKS7CoCBBIHdoaWxlIGJhY2ssIEds
ZW5uIHJlcXVlc3RlZCB0aGF0IEkgcGFzcyB0aGVzZSBjaGFuZ2VzIGJ5IHRoZSBJRUVFIDgwMi4x
IFdHIHRvIGVuc3VyZSB0aGF0IHRoZSBjaGFuZ2VzIGFyZSBhY2NlcHRhYmxlIHRvIHRoZSBJRUVF
IDgwMi4xIFdHLCBoZW5jZSB0aGlzIGVtYWlsLg0KDQpUaGUgY2hhbmdlIGlzIHBlcmhhcHMgYmVz
dCBpbGx1c3RyYXRlZCB2aWEgdGhlIGZvbGxvd2luZyBjaGFuZ2UgaW4gdGhlIFlBTkcgdHJlZSBv
dXRwdXQuDQoNClRoZSpvbGRlciBmb3JtYXQqIG9mIHRoZSBZQU5HIG1vZGVsICh0aGF0IG1lbWJl
cnMgb2YgdGhlIDgwMi4xUSBXRyBwcmV2aW91c2x5IHNhdykgd2FzIGxpa2UgdGhpczoNCg0KKmlm
LWNtbjplbmNhcHMtdHlwZTogKy0tOih2bGFuKSArLS1ydyB2bGFuICstLXJ3IHRhZ3MgKy0tcncg
dGFnKiBbaW5kZXhdIA0KKy0tcncgaW5kZXggdWludDggKy0tcncgZG90MXEtdGFnICstLXJ3IHRh
Zy10eXBlIGRvdDFxLXRhZy10eXBlICstLXJ3DQp2bGFuLWlkIGRvdDFxLXZsYW4taWQqDQoNClRo
ZSAqdXBkYXRlZCBmb3JtYXQgKm9mIFlBTkcgbW9kZWwgaW4gdGhlIGN1cnJlbnQgZHJhZnQgaXMg
bGlrZSB0aGlzOg0KDQogICAgICAgICstLTooZG90MXEtdmxhbikNCiAgICAgICAgICAgKy0tcncg
ZG90MXEtdmxhbg0KICAgICAgICAgICAgICArLS1ydyBvdXRlci10YWchDQogICAgICAgICAgICAg
IHwgICstLXJ3IHRhZy10eXBlICAgIGRvdDFxLXRhZy10eXBlDQogICAgICAgICAgICAgIHwgICst
LXJ3IHZsYW4taWQgICAgIGllZWU6dmxhbmlkDQogICAgICAgICAgICAgICstLXJ3IHNlY29uZC10
YWchDQogICAgICAgICAgICAgICAgICstLXJ3IHRhZy10eXBlICAgIGRvdDFxLXRhZy10eXBlDQog
ICAgICAgICAgICAgICAgICstLXJ3IHZsYW4taWQgICAgIGllZWU6dmxhbmlkDQoNClRoZSBzYW1l
IGVxdWl2YWxlbnQgY2hhbmdlIGhhcyBiZWVuIG1hZGUgZm9yIEwyIHN1Yi1pbnRlcmZhY2VzIGFz
IHdlbGwuDQoNClRoZSBsYXRlc3QgaW50ZXJuZXQgZHJhZnQgaXMgDQpodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qtc3ViLWludGYtdmxhbi1tb2RlbC0wNA0KDQpJ
biBwYXJ0aWN1bGFyLCBpdCBtYXkgYWxzbyBiZSB1c2VmdWwgdG8gbG9vayBhdCB0aGUgaW5zdGFu
Y2UgZGF0YSANCmV4YW1wbGVzIGluIGNoYXB0ZXIgNywgdGhhdCBnaXZlIGEgY291cGxlIG9mIGV4
YW1wbGVzIG9mIGhvdyB0aGUgWUFORyANCm1vZGVsIGlzIGV4cGVjdGVkIHRvIGJlIHVzZWQgYm90
aCBmb3IgTDMgdGVybWluYXRpb24sIGFuZCBhbHNvIHdoZW4gdXNlZCANCmluIGNvbmp1bmN0aW9u
IHdpdGggdGhlIElFVEYgTDJWUE4gWUFORyBtb2RlbCB0byBwcm92aXNpb24gYSANCnBvaW50LXRv
LXBvaW50IEwyIHNlcnZpY2UuDQoNCkkgaG9wZSB0byBzdWJtaXQgdGhpcyBkcmFmdCB0byB0aGUg
TkVUTU9EIFdHIGNoYWlycyBmb3IgV0cgbGFzdCBjYWxsIA0KYWZ0ZXIgdGhlIGN1cnJlbnQgSUVU
RiAxMDMgbWVldGluZy7CoCBTbyBpZiBhbnlvbmUgaGFzIGFueSBjb25jZXJucyB0aGVuIA0KcGxl
YXNlIG1heSBJIGFzayB0aGF0IHlvdSByYWlzZSB0aGVtLsKgIGlkZWFsbHkgSSB3b3VsZCBsaWtl
IHRvIGdldCB0aGVtIA0KaW5mb3JtYWxseSBhZGRyZXNzZWQgYmVmb3JlIHRoaXMgZG9jdW1lbnQg
cHJvZ3Jlc3Nlcy7CoCBBbHRlcm5hdGl2ZWx5IGlmIA0KeW91IG5lZWQgbW9yZSB0aW1lIHRvIHJl
dmlldyB0aGlzIGNoYW5nZSwgb3IgbmVlZCB0aGlzIGFzIGEgZm9ybWFsIA0KbGlhaXNvbiB0aGVu
IHBsZWFzZSBsZXQgbWUga25vdywgYW5kIEknbGwgZG8gbXkgYmVzdC4NCg0KVGhhbmsgeW91IGZv
ciB5b3VyIHRpbWUsDQpSb2IgV2lsdG9uDQoNCg0KPT09DQpVbnN1YnNjcmliZSBsaW5rOiBtYWls
dG86U1REUy04MDItMS1MLVNJR05PRkYtUkVRVUVTVEBMSVNUU0VSVi5JRUVFLk9SRw0KSUVFRS4g
Rm9zdGVyaW5nIHRlY2hub2xvZ2ljYWwgaW5ub3ZhdGlvbiBhbmQgZXhjZWxsZW5jZSBmb3IgdGhl
IGJlbmVmaXQgb2YgaHVtYW5pdHkuDQo=


From nobody Mon Nov 12 23:03: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 4D65712D4E7 for ; Mon, 12 Nov 2018 23:03:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sN91ZLcYRrO3 for ; Mon, 12 Nov 2018 23:03:40 -0800 (PST)
Received: from outbound-ss-579.bluehost.com (outbound-ss-579.bluehost.com [74.220.218.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2B43128CF3 for ; Mon, 12 Nov 2018 23:03:40 -0800 (PST)
Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id C168C1E1022 for ; Tue, 13 Nov 2018 00:03:38 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id MSjagTR0EE0jMMSjagp3KA; Tue, 13 Nov 2018 00:03:38 -0700
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=73g4AhpGys4lFpzBjuD5gs1aFjf5wPD4OZmNr+luUHQ=; b=XS0WDser4JehT54nDQBAfu4AX2 2bgXuM/B/B4Jom7TwbxD+pzK/Xyrcz+rx2T9W6cXEdTv4T8LgMzvGlcTB0viy207mU4pe+slq+IJl sqseQHPtBk/ht+gIoFj+ES/rC;
Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:51488 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gMSjZ-0010xq-SU; Tue, 13 Nov 2018 00:03:38 -0700
To: John Messenger , Robert Wilton , "Holness, Marc" , "STDS-802-1-L@LISTSERV.IEEE.ORG" , "netmod@ietf.org" 
References: <14a5c6fd-b24a-9669-7701-75dd822f95e2@cisco.com> <9485c56783074f19b4fbf357e5e82946@advaoptical.com>
From: Lou Berger 
Message-ID: 
Date: Tue, 13 Nov 2018 14:03:32 +0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <9485c56783074f19b4fbf357e5e82946@advaoptical.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.106.211
X-Source-L: No
X-Exim-ID: 1gMSjZ-0010xq-SU
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:51488
X-Source-Auth: lberger@labn.net
X-Email-Count: 5
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] [802.1 - 12909] IETF Sub-interface VLAN YANG Data Models - draft-ietf-netmod-sub-intf-vlan-model-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 07:03:44 -0000

Hi John,

     Thank you (and Janos, the group) for the agenda time and the 
message.  There was also a request for a single c-type vlan example.  I 
see that there is already one on page 22 as part of the match container.

See below for inline responses.

Rob/WG,
     The plan is to address the comments raised in this mail, update the 
draft and then go to LC.  Please note that the document status should be 
changed Informational to Standards Track.

On 11/13/2018 11:55 AM, John Messenger wrote:
> Hi,
>
> At the 802.1 TSN meeting this morning, Lou Berger made a presentation on behalf of Rob Wilton summarising the recent changes in this draft.  I like the changes to the structure which are intended to align the VLAN tag structure to that specified in 802.1Q.  I notice that the draft retains clause 2.2 (Extensibility) but I think that's a bug, because it's not reflected in the model (which is a fixed structure of one or two tags).
I agree.
> Right now, it says that the Ethertypes are taken from dot1q-tag-type.  Would this allow tags other than 802.1QTagType (81-00) and 802.1QSTagType (88-A8)?  That shouldn't be allowed.
I read this as just trying to use the IEEE defined types.  We certainly 
can restrict this to just c-vlan and s-vlan values, but perhaps you want 
to consider defining an enumeration for this case (valid-qtag-types).

Rob (wg)

     Do you see any issue with restricting tag-types to 
dot1q-types:c-vlan and dot1q-types:s-vlan?

> My preference would be to remove the forward-looking statement quoted here because it implies a willingness to extend to 3 tags:
> 	The structure of the model is currently limited to matching or
>     rewriting a maximum of two 802.1Q tags in the frame header but has
>     been designed to be easily extensible to matching/rewriting three or
>     more VLAN tags in future, if required.

sure. (at least from my perspective.)

> It looks like you could parse an untagged frame as either :(untagged) or :(dot1q-vlan-tagged) (without either of the optional tags).  Is that a bug?

I may be missing something, but I think you're right - i,e., why would 
dot1q-vlan-tagged be present without an outer-tag, but I may be missing 
something...

Thanks again.

Lou

> Thanks,
> 	-- John
>
> -----Original Message-----
> From: List HELP only  On Behalf Of Robert Wilton
> Sent: 05 November 2018 16:16
> To: STDS-802-1-L@LISTSERV.IEEE.ORG
> Subject: [802.1 - 12909] IETF Sub-interface VLAN YANG Data Models - draft-ietf-netmod-sub-intf-vlan-model-04
>
> Ballot due Nov. 6: P802.1Qcx/D0.4
> For particulars see
>    https://1.ieee802.org/active-ballots/
> 802.1 list help: https://1.ieee802.org/email-lists/
> List archives (access-controlled) by date:
>                 www.ieee802.org/1/private/email2/mail1.html
> -----
>
> Dear esteemed 802.1 WG members,
>
> A few years back, at the start of my IETF and IEEE standards journey I wrote a draft defining a sub-interface based VLAN termination YANG model.  After discussion and presentations in both IETF NETMOD WG and IEEE 802.1 WG, there was a general agreement that it would be acceptable for IETF to publish this YANG model as an informational RFC, with the acknowledgement that 802.1Q VLAN technology is owned by IEEE, and in future the IEEE 802.1 WG may choose to publish a VLAN termination model.
>
> As part of that IETF NETMOD WG process, and after IEEE 802.1 WG had reviewed the model, I made a small change in structure of the YANG model with the sole aim of making the model simpler to use. In particular, the older model required a slightly clunky indexed list of VLAN tags, and that is replaced with a simpler structure supporting two explicit named VLAN tags ('outer-tag' and 'second-tag').  A while back, Glenn requested that I pass these changes by the IEEE 802.1 WG to ensure that the changes are acceptable to the IEEE 802.1 WG, hence this email.
>
> The change is perhaps best illustrated via the following change in the YANG tree output.
>
> The*older format* of the YANG model (that members of the 802.1Q WG previously saw) was like this:
>
> *if-cmn:encaps-type: +--:(vlan) +--rw vlan +--rw tags +--rw tag* [index]
> +--rw index uint8 +--rw dot1q-tag +--rw tag-type dot1q-tag-type +--rw
> vlan-id dot1q-vlan-id*
>
> The *updated format *of YANG model in the current draft is like this:
>
>          +--:(dot1q-vlan)
>             +--rw dot1q-vlan
>                +--rw outer-tag!
>                |  +--rw tag-type    dot1q-tag-type
>                |  +--rw vlan-id     ieee:vlanid
>                +--rw second-tag!
>                   +--rw tag-type    dot1q-tag-type
>                   +--rw vlan-id     ieee:vlanid
>
> The same equivalent change has been made for L2 sub-interfaces as well.
>
> The latest internet draft is
> https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-04
>
> In particular, it may also be useful to look at the instance data
> examples in chapter 7, that give a couple of examples of how the YANG
> model is expected to be used both for L3 termination, and also when used
> in conjunction with the IETF L2VPN YANG model to provision a
> point-to-point L2 service.
>
> I hope to submit this draft to the NETMOD WG chairs for WG last call
> after the current IETF 103 meeting.  So if anyone has any concerns then
> please may I ask that you raise them.  ideally I would like to get them
> informally addressed before this document progresses.  Alternatively if
> you need more time to review this change, or need this as a formal
> liaison then please let me know, and I'll do my best.
>
> Thank you for your time,
> Rob Wilton
>
>
> ===
> Unsubscribe link: mailto:STDS-802-1-L-SIGNOFF-REQUEST@LISTSERV.IEEE.ORG
> IEEE. Fostering technological innovation and excellence for the benefit of humanity.


From nobody Tue Nov 13 02:58:33 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB191286E7; Tue, 13 Nov 2018 02:58:32 -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 xO_k3RSxTdxk; Tue, 13 Nov 2018 02:58:30 -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 4A9BF126DBF; Tue, 13 Nov 2018 02:58:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3485; q=dns/txt; s=iport; t=1542106709; x=1543316309; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=W5+e4bvPtRhqCif7zOhSN0hMtmHkz0v5JtR0fdRHcbA=; b=IxYAMt1li0ubPSqfI8s8Q2u/S4ZVlQ2L2AbkQK9EGBZINIL4AVKXwAQJ LAsBgj9xgUtaanwj4kLio0kloNbeigAgt3kcHQhQZkPkC4VmoU6ERuCxS COlm3kXzFfvrZuJLiA9eY+lSWQWObs9vrT++skk+F6g3vuQFhC1mCmCvg I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAAD1rOpb/xbLJq1iGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUgQBAQEBCwGCaXASJ4N4iHeNBCWXNYF6DRgNhAFGAoNVNQw?= =?us-ascii?q?NAQMBAQIBAQJtHAyFOwEBBAEBIQ8BBTYbCxgCAiYCAicwBgEMBgIBAYMdAYI?= =?us-ascii?q?BD6dOgS+FQIRoBYELiw2BQD+BEScMgWF+gxsBAQIBF4EhgyqCVwKKfYQIkFE?= =?us-ascii?q?JhneKJQYYgViIACaGdYFOi1qDfIZZgUUCNIFVMxoIGxU7gmyCLBKIXoU+PwM?= =?us-ascii?q?wAYtigkwBAQ?=
X-IronPort-AV: E=Sophos;i="5.54,498,1534809600";  d="scan'208";a="8014511"
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; 13 Nov 2018 10:58:27 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id wADAwQcD003141; Tue, 13 Nov 2018 10:58:26 GMT
To: joel jaeggli , NETMOD Working Group , draft-ietf-netmod-module-tags.authors@ietf.org
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>
From: Robert Wilton 
Message-ID: 
Date: Tue, 13 Nov 2018 10:58:25 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: 
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 10:58:32 -0000

Hi Joel, authors,

I have to confess that I didn't have time to review this during the last 
call (but have reviewed/provided comments on previous versions).

These comments may be too late, but I will provide them anyway, so make 
of them what you will :-)

In summary, I like the idea of tags and I think that they are a good fit 
for classifying YANG models.  In particular, I think that a flexible 
classification of YANG modules is better than a rigid structure that can 
never be changed.

For me the one of the great utilities of module tags could be in 
applications like YANG catalog search 
(https://yangcatalog.org/yang-search/).  Being able to search for 
modules by tag seems like it would be a particularly useful thing to be 
able to do.

However, I do have some sympathy with Alex's comment, in that it is a 
bit unclear as to benefits of configuring the tag information on the 
devices.  At the moment, the configuration doesn't have any material 
affect on the device, and the only thing that a client can do is read 
back the tag configuration.  Is the intention that the protocols may be 
extended in future to allow filter queries to be based on module tags?

So, I am supportive of Alex's comment that it would give the document 
more clarity if some of the specific use cases could be described.


Some other random comments/nits:

1) 6087bis references can be updated to RFC 8407.  Is a reference even 
allowed in the abstract?

2) Abstract: "writing a modules tags" => "writing a module's tags" or 
"writing module tags"

3) The module is YANG 1.1, so RFC 6020 reference can be changed to RFC 7950.

4) Section 3.4: Should there be a tag prefix for "experimental"? Or 
perhaps this would be "ietf:experimental:" anyway.

5) Section 5.1: It might be useful if the tags were also reported under 
YANG library, e.g. as an augmentation to rfc7895bis.  E.g. this would 
report the same information as "modules-tags/module[name]/tag" leaf-list.

6) YANG module: Should you limit the maximum size of a tag? Perhaps to 
255, or 1000 characters.

7) Line length for "The operational view of this list is constructed 
..." looks like it may be too long.

8) Section 7, Guidelines to authors.  I was wondering if this section 
should state that YANG modules SHOULD define standard tags that are 
associated with it.  At the moment, it just states what can be done, 
without providing guidance of what should be done.

9) Section 9.2.  A few more possible categories: discovery protocol, 
vpn, tunnel.  I'm not sure that I particularly like "rfc8199-" as a 
module name, and possibly "classification-" would be better.

Apologies for the tardy review comments,
Rob


On 12/11/2018 16:46, joel jaeggli wrote:
> During the Thursday nov 8 session of netmod, we asked if there were any objections to the publication of the Draft-03 version of draft-ietf-netmod-module-tags which addresses comments and concerns raised during the WGLC. In the meeting there were none. This commences a comment period to confirm that call. As this follows closely on the heels of the IETF 103 meeting we’ll let the call run through Monday the 26th of November.
>
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-03.txt
>
>
> Thanks
> Joel
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Nov 13 05:33:12 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08FF130934 for ; Tue, 13 Nov 2018 05:33:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.792
X-Spam-Level: 
X-Spam-Status: No, score=-3.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Sh1BpL7A; dkim=pass (1024-bit key) header.d=ericsson.com header.b=UdlVbM01
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHlzv_bMsvEF for ; Tue, 13 Nov 2018 05:33:06 -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 570C21276D0 for ; Tue, 13 Nov 2018 05:33:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1542115983; x=1544707983; 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=9fIAgKRifpAVdmyzH582wOGKUhnyrAmqF+PwcJftOxo=; b=Sh1BpL7AidlLgVZDzBUAzPloBgN6xA8BeCmINHLpx6kvQjoci+5Jgi1pQyey9r00 LYSJW6pthGOVIyMCYRWobikBLk8cOt0UanDL8NlzcSWRoL/nN6fkevI61Fy6BA4m EgGds37mopIv7UsmT5dekGul00j6/LHLaXsxR5+EjV8=;
X-AuditID: c1b4fb30-f2dff700000043c4-ee-5bead28f796f
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 73.B6.17348.F82DAEB5; Tue, 13 Nov 2018 14:33:03 +0100 (CET)
Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 13 Nov 2018 14:33:03 +0100
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 13 Nov 2018 14:33:03 +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=hFV8uMectyJYe3tsfReVg419l4Vt4EA92J4auOOhU58=; b=UdlVbM01x07n25kUaVCUgV9z5Kx/jAZWpw6AsKvtznBYC0mR0LM06BwQKN35nA6vgcgmh3KL2TE5WIWzEG+xnAE8Jp+TW4QnK53AsVaIE2WZg//uouMkykxzrkrd38KPHZnT+AeATItJLloJvI++B+4vc0YXpzFlMpukVytRDTM=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2751.eurprd07.prod.outlook.com (10.173.81.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.10; Tue, 13 Nov 2018 13:33:02 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::70d1:cf80:392b:814b]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::70d1:cf80:392b:814b%4]) with mapi id 15.20.1339.019; Tue, 13 Nov 2018 13:33:02 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: "Yemin (Amy)" , Qin Wu , "Xufeng Liu" , NETMOD WG 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AQHUe1VmbTarS7Bo30CiE6gJ+Dl/9w==
Date: Tue, 13 Nov 2018 13:33:01 +0000
Message-ID: <0bb4d572-3378-c46a-0802-c2c2fce7cc4e@ericsson.com>
References:  <9C5FD3EFA72E1740A3D41BADDE0B461FCFA7803B@DGGEMM528-MBX.china.huawei.com> <20181106141613.zqy5xmq7qvahzzpz@anna.jacobs.jacobs-university.de> <9C5FD3EFA72E1740A3D41BADDE0B461FCFA78BFA@DGGEMM528-MBX.china.huawei.com> <20181107083401.7bqbjnewg3syd6dj@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181107083401.7bqbjnewg3syd6dj@anna.jacobs.jacobs-university.de>
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.0
x-clientproxiedby: AM6PR07CA0016.eurprd07.prod.outlook.com (2603:10a6:209:2a::29) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2751; 6:bWxcJE5iAHeC3h4+7hOhqhuWhSoSOwzDh2Are04XbSj1X2x9hwami4hYYnDZw1N4x/WbINgcuNTY5F5DwG7vmXx6CHfc7oEFuIuciAPlDx15xMTPEFqfIuwWP7zz3UgbIsRCHqT/ePOeRNxv1WDJokEACr504M+evA9n2YQpRTLp0IZb31qUeuVXNqFOAONE0/bfdBTlMcr+Y9fBZfFPIgXk6A72vuBM57fJC1G1g1sW+8pYlDNuB+DHnAbf8Jbtt2ehGVUPYY3SGhBq85g/SsnueH22cuJm7r8oKel1vzN3LQnnfyaGVznfrDZ+Wj4m36KzZAR/pLjVLgYaZnJ4pYiS6Vhwk8FMayguUYPjRidJprRjeMOA8+QGxcWF6LMFDB6tWcpkK+Cf5LfajFxAJ1x5lkp/mHVsYmo3rTRIZFeeyDF5RjKEdm5LeLyRhL8z/jb2oQvkcflsUBQ2zLix8g==; 5:E4RzM95UsDJgX9+dA50DZ7lDyfPYlO8o4I2KlRq77aM8U8iy8+iRwt6juR7qiQvQd9FKpZLRjV+9fYfNULQ775a+hPwBdRm77wEVnWz1wbA+K4jT1p+cIln+k9AHZ9FTHAlF2zDI5Gnak50UxCRe4Ktu8Bc6/Z9pG267zbideUo=; 7:tggA00nR9/A2phdUkz2PK+tKTuDNxKINhPTU4PD92u67iR5uv0AaOTHyddb3d6GvIXH45ep+5dAfO1g6ve3hsapm7h0izs0ik5RiqpqdFYPiUIAXUX81zOjfFwwN+ayO98c9oPN39QQplquviVMaNQ==
x-ms-office365-filtering-correlation-id: 90e70861-8f6b-416e-fcbd-08d6496c8875
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390060)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2751; 
x-ms-traffictypediagnostic: VI1PR0701MB2751:
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)(3002001)(10201501046)(3231382)(944501410)(4983020)(52105112)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2751; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2751; 
x-forefront-prvs: 085551F5A8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39860400002)(366004)(396003)(376002)(136003)(346002)(189003)(252514010)(199004)(13464003)(966005)(305945005)(105586002)(93886005)(97736004)(446003)(106356001)(86362001)(26005)(6486002)(11346002)(99286004)(65806001)(14454004)(186003)(66066001)(6436002)(99936001)(486006)(2616005)(39060400002)(85202003)(71190400001)(316002)(6246003)(65956001)(52116002)(58126008)(71200400001)(6306002)(6512007)(476003)(3846002)(6116002)(110136005)(53936002)(31696002)(2906002)(7736002)(66574009)(85182001)(53546011)(6506007)(386003)(76176011)(102836004)(31686004)(229853002)(81156014)(5660300001)(8936002)(14444005)(65826007)(256004)(68736007)(8676002)(3260700006)(64126003)(478600001)(25786009)(81166006)(2900100001)(36756003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2751; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: gb6zaSB2zec0BQkFSc/JF+Ih5fGaalaNZ71xJX2d12RI9Zex5OAkheItX/eSpdD4jNdf2WAzvbdVBnYGBrTtAOVxt7dkzZ/pVP+OikU0xODBuJh2K41yt4Vc4dVnRTOXF3OcjjBynGuLZ3nEC743dnTMP/K+UObLKFGExOl2ur+BT0MLy7x1f1werhD9ySYDEb8Tuwy7DH09KSjnR4WCtl8/kHFRvBtAs93rGvrAfsr4rUtCQQ8L3eVyv5Shsh3djkkZxyNdAB6g+1qPecLFfaRzMm/JYl8UFCellNnUzDyTQfp9NOxvHit9vLr/A7LJmmt/zkCffuFZrocp/0gn0o3fKuGqaCqb70x2aDx2wuQ=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060708060603040900010207"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 90e70861-8f6b-416e-fcbd-08d6496c8875
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2018 13:33:01.9702 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2751
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA2WSSUxTURSGvX2vA40ljwpyrFNodKECMonFgcG4wESRJSlBKPBCy9CSVyQF TKxiFBmUhYQpWgiDBBwIEJEEI4USpUwFRyZNhRQpKmEhBREi7QVj4u4758//nz83l0cIZ9ki nkKZQTNKWaqYwyfLo9o1XndHrdE+QzqRpDWvmSOZvl/FluhGrrElb1/9ZoWS4R0VU9zwG4bv 7PDa2hVWJCHln0qkUxWZNHM0OI4vX7N8RunD2Rrjoo6rRcPyfMTjARUAdbMu+YjPE1IGBCu2 SU4+ctoYlhBUjmVioZYF/f02wi6QVDEBq+1iLJSywDYyxMWDBUHVswqHnUOdhVs/XrLs7Erd QWDsirWf20F5QdvTSLz2hoaBGXKLS6xFbHzgICys9yE7C6gQMNdNEDjfxoKuUYujhRN1Ecr1 nY58RO0Em/GRgwnKHcZndA4GyhXMI/0czG4wN73OxiyGMus4297HjYoB/fUQez5QZQh+fisl ceYl6PyUt+n1hMEPMwjzXhjVFSBs+MiBodrBTeECvOnL42JhEkH7UtNft6mnarORCnKnbm62 2AeNRWayGPlU/FMc820EZUZFheMFXKCvfIbE+0B40GomMB+B+up54n/vSSj7pedg9oB7BWYu 5mMw37uIMPtD/ZM1ThXiNyI3Na2OT0vy8/OmGUWCWq1SeivpjBa08eX0bas+z9HcbFg3onhI vF0w32SNFrJlmeqstG50YCPnS3OTCYlIpUpJi10FHQEbsiBRlpVNM6pY5nIqre5Gu3mk2F0g iWiVCqkkWQadQtPpNLOlsnhOIi06b5pYzvKN8nrcID13Oudqjo/KcKhF7/xOG+rr/Lo3aLVy IGxwwv+hV+7y3PRAg9zpvqG6Js2ijSuskZZqF/ZnLCe/D9Ioqo2B/K/znmNNYb7CFyWrFuue ZNOZbRGaBFF0MNObqBlLOX5F6bJm8hgRL/VMe7gUSnediM9l3FQxYlItl/keJhi17A+umTcM egMAAA==
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 13:33:10 -0000

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

Hello,

In some cases I want a percentage without fractions. This could be=20
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 :-)
     }

regards Balazs

On 2018. 11. 07. 9:34, Juergen Schoenwaelder wrote:
> On Wed, Nov 07, 2018 at 07:49:54AM +0000, Yemin (Amy) wrote:
>
>> For the range, if the defintion can cover the our range(0..99.9999),
>> it will be acceptable.  In your suggestion below, does that mean the
>> base defintion is without range, while refined types can chosse the
>> range they like?
> I was thinking loud. Let me detail somewhat more what was going on in
> my head:
>
>    We could define a percent type without the upper bound being
>    whatever the decimal covers but fixing the precision of the
>    fractional part. We could then narrow the upper bound via
>    subtyping:
>
>       typedef percent {
>         type decimal {
>           fraction-digits 4;
>           range "0..max";
>         }
>       }
>
>       typedef percent' {
>         type percent { range 0..100; }
>       }
>
>    If wanted flexibility on the fractional part, we could define
>    percent with a fixed range and the largest number of fraction digits=

>    possible and then we could subtype this to obtain a precision that
>    makes sense in the usage contexts (although it is not clear whether
>    YANG 1.1 really allows this, if not this may be just due to nobody
>    ever thinking about this before):
>
>      typedef percent {
>        type decimal {
>          fraction-digits 16;
>          range 0..100;
>        }
>      }
>
>      typedef percent' {
>        type percent { fraction-digits 4; }
>      }
>
>    An ideal solution would provide flexibility both on the range and
>    the number of fraction digits but it seems this is impossible since
>    these two properties (range and precision) interact.
>
> So it seems we have to do something that is pragmatic and this likely
> means fixing the fraction since subtyping the fractional part may not
> be allowed by YANG or not be supported by implementations. The
> question is then how we pick suitable fractions. I understand you want
> 4 digits.
>
> /js
>
>> BR,
>> Amy
>> ________________________________________
>> =E5=8F=91=E4=BB=B6=E4=BA=BA: Juergen Schoenwaelder [j.schoenwaelder@ja=
cobs-university.de]
>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2018=E5=B9=B411=E6=9C=886=E6=97=A5=
 22:16
>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Yemin (Amy)
>> =E6=8A=84=E9=80=81: Qin Wu; Xufeng Liu; balazs.lengyel@ericsson.com; N=
ETMOD WG
>> =E4=B8=BB=E9=A2=98: Re: [netmod] for a future rfc6991bis
>>
>> Well, the draft-ye-ccamp-mw-topo-yang-02 definition excludes 100%,
>> which is likely not generally useful. In fact, even 150% can be in
>> some contexts a perfectly sensible percentage. So we may need to
>> provide some flexibility here, i.e., having a base time where the
>> range can be refined and refined types with an upper limit set to 100%=

>> for use in situations where this limit is sensible.
>>
>> The more difficult aspect seems to be precision, I am not sure YANG
>> allows subtyping the fractional part. RFC 7950 seems to be silent
>> about this and in the general case this would not be meaningful. But
>> in this particular case, when the number range is limited, it would
>> actually be OK to allow this (but then we have to have a limit and
>> we can't set the upper limit to max).
>>
>> /js
>>
>> On Tue, Nov 06, 2018 at 02:21:33AM +0000, Yemin (Amy) wrote:
>>> If the percentage is defined as following, as a author of draft-ye-cc=
amp-mw-topo-yang-02, we will be happy to use it.
>>> But it's better to include in RFC6991bis, as percentage is a generic =
and widely used item.
>>>
>>> BR,
>>> Amy
>>> ________________________________
>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: netmod [netmod-bounces@ietf.org] =E4=BB=A3=
=E8=A1=A8 Qin Wu [bill.wu@huawei.com]
>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2018=E5=B9=B411=E6=9C=886=E6=97=
=A5 9:25
>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Xufeng Liu; balazs.lengyel@ericsson.com
>>> =E6=8A=84=E9=80=81: NETMOD WG
>>> =E4=B8=BB=E9=A2=98: Re: [netmod] for a future rfc6991bis
>>>
>>>
>>> Another case would be :
>>>
>>>
>>> =E2=80=9C
>>>
>>> typedef percentage {
>>>
>>>        type decimal64 {
>>>
>>>           fraction-digits 5;
>>>
>>>           range "0..100";
>>>
>>>       }
>>>
>>>     description "Percentage.";
>>>     }
>>> =E2=80=9D
>>> Which is defined ietf-connectionless-oam.yang module.
>>>
>>> -Qin
>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: netmod [mailto:netmod-bounces@ietf.org] =
=E4=BB=A3=E8=A1=A8 Xufeng Liu
>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2018=E5=B9=B411=E6=9C=886=E6=97=
=A5 3:49
>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: balazs.lengyel@ericsson.com
>>> =E6=8A=84=E9=80=81: NETMOD WG 
>>> =E4=B8=BB=E9=A2=98: Re: [netmod] for a future rfc6991bis
>>>
>>> The draft that asked for the percentage type is: https://tools.ietf.o=
rg/html/draft-ye-ccamp-mw-topo-yang-02
>>>
>>> They currently define:
>>>
>>>                leaf availability {
>>>                  type decimal64 {
>>>                    fraction-digits 4;
>>>                    range "0..99.9999";
>>>                  }
>>>                  description "Availability level of the link";
>>>                }
>>>
>>> Thanks,
>>> - Xufeng
>>>
>>> On Sun, Nov 4, 2018 at 7:07 AM Bal=C3=A1zs Lengyel > wrote:
>>>
>>> +1 to percentage.
>>>
>>> Balazs
>>> On 2018. 11. 03. 3:44, Xufeng Liu wrote:
>>> Remember that some draft asked for a type of percentage value to the =
nearest hundredth. Wondering if it can be put in.
>>>
>>> Thanks,
>>> - Xufeng
>>>
>>> On Fri, Nov 2, 2018 at 11:39 AM tom petch > wrote:
>>> ---- Original Message -----
>>> From: "Juergen Schoenwaelder" >
>>> To: "Kent Watsen" >
>>> Cc: >
>>> Sent: Tuesday, October 30, 2018 10:14 AM
>>>
>>>> On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen wrote:
>>>>>>> In addition, it might be good to introduce [inet?] types for RFC
>>> 5322
>>>>>>> (Internet Message Format) including perhaps:
>>>>>>>
>>>>>>>    - email-address        (addr-spec, per Section 3.4.1)
>>>>>>>    - named-email-address  (name-addr, per Section 3.4)
>>>>>>>
>>>>>> Where are these used? Or have these already been used somewhere?
>>>>> I'm unaware of these ever having been used before.  I am working on=

>>> a private module for which I want to configure an email address.  Aft=
er
>>> some searching, I concluded that no such types have been defined, and=

>>> thus thought that they might be good candidates for addition.
>>>
>>>
>>> We could defined a user-name, of the form localpart@domainpart as is
>>> widely used to identify a user in operations but which does not, in m=
y
>>> experience, owe anything to i18n, just a straightforward character se=
t;
>>> yes it would not boil the ocean, but could be useful.  I am surprised=

>>> not to find such a definition somewhere in our 40 or so NETCONF I-Ds.=

>>>
>>> Tom Petch
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> It would be good to have strong use cases. I fear that defining this=

>>>> type won't be easy given that we also have internationalized email
>>>> addresses (RFC 6530 provides an overview) and we might have to creat=
e
>>>> a union of RFC 5322 addresses and "SMTPUTF8 (compliant) addresses".
>>>>
>>>> /js
>>>>
>>>> --
>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germa=
ny
>>>> 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
>>>
>>> --
>>>
>>> Balazs Lengyel                       Ericsson Hungary Ltd.
>>>
>>> Senior Specialist
>>>
>>> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.c=
om
>>> _______________________________________________
>>> 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         

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



--------------ms060708060603040900010207
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTExMzEzMzI1Nlow
LwYJKoZIhvcNAQkEMSIEIICb0NPM3MnC8VfKhlwLDivkCzHBxOcCXmSmB6chbAuaMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBACp+ceBtSgQa5QIqqhFw3Y6Nmj0kHenOnETv2/xfmntyh4Nf
lCeYyO3LeLcp5Ls5S6VJr6RZC9nxBfZeTGQNAT2AzZgfPEzaFfmcvVEm2JaKJjoPASjT9VRu
xDSy5acyUN3gcLR1eHO22et5Kc74h78Qb7Tljp5igagFrNaI8deq3r2mrMgVkzq4oulnPWMq
OwurqYQ3La+ykLtxGMuPjX0UvJFydUOH08DQwsZxzF4KRxv6M5AmAoNcHorQUjWkQzeR5OEX
qA4q1RDLtGOa5o+Pn5cQsc3fbHP1q48cC1TpR5DVxnlXxzHdjtXIeLuVpu2xqQqzPPANAig6
zq5mHnAAAAAAAAA=

--------------ms060708060603040900010207--


From nobody Tue Nov 13 05:47: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 030BD12F1A6 for ; Tue, 13 Nov 2018 05:47:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.068
X-Spam-Level: 
X-Spam-Status: No, score=-3.068 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=PRmnsp1b; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ZSRcLsSr
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4LqJPxspJab for ; Tue, 13 Nov 2018 05:47:15 -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 BC71712D4EE for ; Tue, 13 Nov 2018 05:47:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1542116832; x=1544708832; 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=zcvYfCoNUhsTlyEmYU+JyMdcQkIGTHJzHdqGWzuoxos=; b=PRmnsp1bb1gsZB6cGRDcOK0UtQZhEN1u0gA0RTls1mZSYvhp1LmpTWCRtOjroxgd gd8xoN4Zoi+USSLckVO6Atbf7aneKGkSYt9t+LWnWQucmCnYwvYD41qARNw0vuoH iVSMOfwO5saXympSXpD8QKpQfLR/oif6Jxc+lUpzLYk=;
X-AuditID: c1b4fb30-f2dff700000043c4-ac-5bead5e0f878
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id BA.1A.17348.0E5DAEB5; Tue, 13 Nov 2018 14:47:12 +0100 (CET)
Received: from ESESBMR501.ericsson.se (153.88.183.129) by ESESSMB502.ericsson.se (153.88.183.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 13 Nov 2018 14:47:12 +0100
Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMR501.ericsson.se (153.88.183.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 13 Nov 2018 14:47:02 +0100
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 13 Nov 2018 14:47:01 +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=8Jj0HQsudaXIuKiltCx2Uq+5d/THJYCBtXeFPtv6S6g=; b=ZSRcLsSrI0ZVwKWVc7VyrjN6tvYZprxem/KnOzWVmcy402y9hPXyaGByf2N+abkj8KEyF5EhlA+eAn4KpUDFUFeEtewMHLsc4pafz+R+rYpTtf6LwIO/swpETRuolEPLLusJ0loeL74RpBl4cGivFL550BSf6dqUWrId23FX1qw=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2350.eurprd07.prod.outlook.com (10.168.137.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.12; Tue, 13 Nov 2018 13:46:59 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::70d1:cf80:392b:814b]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::70d1:cf80:392b:814b%4]) with mapi id 15.20.1339.019; Tue, 13 Nov 2018 13:46:59 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Robert Wilton , Martin Bjorklund 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] Deviations and augmentations
Thread-Index: AQHUeqpc7mk2gryvX0i0YxVu+tJ6OaVNuVoA
Date: Tue, 13 Nov 2018 13:46:59 +0000
Message-ID: <77b69d64-2ce2-29d9-77a9-04a7159003a9@ericsson.com>
References:  <20181112.173351.1984161388756642220.mbj@tail-f.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [89.135.192.225]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
x-clientproxiedby: HE1PR0701CA0047.eurprd07.prod.outlook.com (2603:10a6:3:9e::15) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2350; 6:kI7pKvYitdakmkeCHniuaerTV1FKsNI2j/8AGudWV/MH3Su9zewwehn6R2Iy/iKOZl89cMF68NUCblc2QJsz0+SAk1t9wBpfay/XZ/agg0AXWtOnMX7+vDGfvG4xNHawg7zCNrUqa71iTQPwFev0L5DdiF/7JIZN4BA/cEMRx4Z9PWYbxlAK8wSHSgnREYPE+dNB7qgOn1IjWXU5k7fjzLM9iQlFVYI4v4Fad+DXUri6jJPPSXeN8jIOsL5BungGLwfQ8D5mOR6S/uUOmbxsBSufFuaJ3Ui/DI5D95oKDncxQj5HTKMG0O1nfuVJc5IBugJL7ig8vZ5fgeaw9wwicUDSK3sFruZV1WmTaMrHXVYSmwVLAFUOEL/mPG92ec62N2JdnyDPU5vwdj5/jC2PKJy3aIvCafqvJH7XXKnRfPd7Mh9oyocL2kVxJPt9GIMKfn6DSSVGmvWhqFSH/XKlrA==; 5:wbVoDYh4wZfdgRBujiBIPKg85R3GIjkWvlb9wJX0FEdo3aRNFn4nDS/sWqwMZDTtJ4LH8lJkuCiwBU2KpfwQ7pmBS5VS13+G7SxOokxS0dvtwOw769TZKaI33WbCn9Fqh0bUNIccPyNaymTHwXrhb+Pn3s1pU4v3Cur/iciuv10=; 7:Oz8AzCYz219TmUu0qrjjdmP5C6v3xMlWocokAVJPvn4Q6AxiwKcDMe1S51l7e4Ll8J2e/8N8HYul562O2y8FE3M99XEJcE/+SjlmwYl3h51W3iCCS/OF+TPDoiWr91A0AfuCd6q/DMeZjg+xVjKwZg==
x-ms-office365-filtering-correlation-id: aeca9a39-9278-4371-9e4d-08d6496e7ba6
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390060)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2350; 
x-ms-traffictypediagnostic: VI1PR0701MB2350:
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)(3231382)(944501410)(4983020)(52105112)(3002001)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2350; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2350; 
x-forefront-prvs: 085551F5A8
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(346002)(376002)(136003)(189003)(199004)(51444003)(252514010)(6512007)(236005)(99286004)(53936002)(99936001)(31686004)(106356001)(31696002)(26005)(14454004)(6436002)(5660300001)(54896002)(6306002)(76176011)(52116002)(966005)(2900100001)(65826007)(85202003)(53546011)(64126003)(105586002)(81156014)(81166006)(97736004)(8936002)(386003)(8676002)(36756003)(25786009)(4326008)(102836004)(3260700006)(6506007)(478600001)(256004)(71190400001)(6116002)(229853002)(6246003)(7736002)(68736007)(110136005)(14444005)(58126008)(85182001)(486006)(476003)(71200400001)(3846002)(446003)(11346002)(186003)(66066001)(65956001)(606006)(2906002)(6486002)(2616005)(316002)(65806001)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2350; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:3; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: SVaxvhiqqlZgeoEKeT/IQhQC840tDkuMPJxeHTd+t0g8R5QLj+xzSZAYFfjT/dDFzgneHK3x9cRxZP5V2A/aQC3bjInCaD37jeJE6aVPoEgirI/0YGxz/LNJ2EhqCC5iYtNMn/jQ8Ng3ZxJT+4nyOlak+TAMEKKPL2sOQmTWUhC+x/5lOQkL7k0TeIp5AMuuTRcbl/pBdTtR/MUvm+wJAVearr8cf1U++EDphM6tyrgM+//fQE8dwli8qJ6X42Bxp6ahuDCm/k/AOvoKN4++OCv8wMd9Z+EQ+R/NI8aOXA4Jkf2pYxSX7984iefcYEXoq2a+w6UM9HJLdkqC38RpBi+lsdCPhE7wvRrndfJMjRQ=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000807020502020505030802"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: aeca9a39-9278-4371-9e4d-08d6496e7ba6
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2018 13:46:59.4094 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2350
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSeUjTYRjHfX/Hrhq+Lc0HS6jRRXkuo0WHmlJCGEVQYlTO/KGSzdys1P5I i/KYhYih+c8SxSxHnqFiIV6QWh6J2DxW0zXZRmJUmtq1n69C/fd5+B7P88IromUW1lOUoE7h NGpVolwgYR5FNqb6fBy2n/P/bghU6nRWoVI/mMkqX/c9oIPp8MKlWja8vHyBCq9dLGNO0lGS g7FcYsJ1TuN3OFoS/8RUJ7g6m5ya1fmUzUCms7lILAIcCD+mOhmeZbgTgWEiOhdJnDyHQP/M QBPBORgnERHKKfidZxTyA4PzafhkH2KJUkzBz885FBmsCF69aRTyeQEOg6yZVopnNxwOs5U5 LM803gHjPVMCntdjBTw3PWSJZw8UGO+vsAKqR5qXswzeBro/RU6/SCTFQWBuCiC7KhBYFzOX d4nxIWgxO5YZ4Q0w32OgyC4PGLXoKfJoNzAP9goIu4Nt6jdLWA7F9lGW73fH56HtdhDfD7gY wdi9aYZ0XoCXpuyVrDe8HbEgwl7wTq9DJPBeAE3N/QwRIiDjjk1IhHEEIx0W4Wra3FaP8pGi 5J8DS5w+Gucg6O+pEvKCFK+D7kcWpsR5FY23Q8Vd+f9+nndDRamDJnwAihfbBIS3QKHOLCS8 FxxdXxDhPVDx/JfgMZI8Q+5aThtzJU6h8OU0CZe02iS1r5pLqUPO/9bWsOTfhGzTIe0Ii5B8 rdRRZT8nY1XXtWlX2tFWZ89kTdUA8mTUSWpO7iZtDnTK0lhVWjqnSbqouZbIadvRRhEj95Aq T9RHyXCcKoW7zHFXOc2qSonEnhmoJGbB4uUy1PWhbE1NhzVX/Kegz9R9eu6bLOKWrfKr8ViE 62T/Nc0843WjZcRDtS/95YubyagoUu6dHTbRPnEqKtktYbjDMKMe+nYrovWo62yp30xo85i4 N+9M8KaGwNA5QzDEjO6sb/KPG3OU+lC2A9b6MpfqzV3Hj+wfCAmazpQz2nhVwC5ao1X9BYos kXR3AwAA
Archived-At: 
Subject: Re: [netmod] Deviations and augmentations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 13:47:23 -0000

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


  
    
  
  
    
Hello,

    
We also need a method for removing stuff. It does happen that
      some functionality is deemed not important enough, outdated, too
      expensive to maintain, so we want to remove it. 

    

    
    
      
  • Augment is clearly not the tool for that.
    • 
      
  • Deviations are not intended for that=C2=A0 (from rfc 7950: "ser=
ver
        deviation: A failure of the server ...")
    • 
    

    
So we still need Semver(or something akin) and the possibility to
      do NBC changes.

    
Balazs

    

    
On 2018. 11. 12. 18:08, Robert Wilton
      wrote:

    

    

      

      

      On 12/11/2018 16:33, Martin Bjorklund wrote:
      

      
Robert Wilton <rwilton@cisco.com>
        wrote:
        

        
In the Thursday Netmod meeting, it was
          interesting to hear Rob Shakir
          

          describe how deviations and augmentations are used in
          OpenConfig to
          

          add functionality into an older YANG model where the semver
          rules
          

          prevent the version number from being incremented.
          

          

          Further, I think that someone (Martin?) stated on the audio
          bridge
          

          that this was an intended/allowed behavior for deviations.
          

        

        I said that using augmentations (not deviations) was one idea we
        

        originally had for solving the "branching problem".
        

      

      Ah, OK. I agree that makes sense.
      

      

      

        

        I think that this works for OC b/c they don't branch their
        modules.
        

        Hence I think it is important that we decide if branching is a
        

        requirement or not.
        

      

      So, I think that this probably works for adding enhancements, but
      not for the (arguably more important) bug fix case, unless there
      is a reasonable solution to having two config data nodes both
      modifying the same underlying property.=C2=A0 Perhaps under some
      reasonable constraints this could be made to work - but I don't
      know.
      

      

      Of course, even for enhancements it is not necessarily a perfect
      solution.=C2=A0 E.g. backporting some subset of a module already
      coded/implemented in latest to an older release.=C2=A0 And yes, we
      really do get asked to do this sometimes, although it is
      relatively rare.
      

      

      Thanks,
      

      Rob
      

      

      

        

        

        /martin
        

        

        

        
This surprised me, because I thought
          that RFC 7950 was quite explicit
          

          that this is not what deviations are intended for.=C2=A0 My rea=
ding
          of RFC
          

          7950 is that the deviation statement represents the case where
          the
          

          server *implementation* does not match the *specification*.=C2=A0=

          However,
          

          the versioning issue that we are discussing are bug
          fixes/changes in
          

          the specification rather than the bug fixes in the
          implementation.
          

          

          Personally, I'm really not keen on using deviations to
          represent bug
          

          fixes to older YANG models for three reasons:
          

          

          (i) It is changing the meaning of deviation.=C2=A0 It is much
          cleaner to
          

          keep the meaning of deviation statements as they are defined
          today,
          

          and not conflate their semantics.
          

          (ii) A different mechanism is used to put a bug fix into an
          older
          

          branch rather than in the head of the development.
          

          (iii) For clients to track the lifecycle of modules they would
          not
          

          only need to know the module version number but would also
          need to
          

          find and track all associated deviation modules.=C2=A0 This see=
ms
          

          significantly more complex for clients than the modified
          semver that
          

          was proposed.
          

          

          ---
          

          

          I think that has also been some suggestion that augmentations
          (or
          

          duplicate YANG modules with their major version number
          changed) can be
          

          used to make bug fixes in a completely backwards compatible
          way.
          

          However, I still don't understand a robust scheme of how this
          works.
          

          

          ---
          

          

          Finally, there were some comments about using augmentation
          modules for
          

          enhancements.=C2=A0 This is fine, where appropriate (e.g. a non=

          trivial
          

          number of data nodes are being added as an enhancement) then a
          

          separate module may be the right way to go. But here, I
          presume that
          

          the new functionality will always be tracked by that separate
          module.
          

          If that functionality folds back into the original module at
          some
          

          point in the future, then obviously a non backwards compatible
          version
          

          change is being forced on to the client, along with additional
          work on
          

          the server as well.
          

          

          I think that there are also many cases where the number of
          data nodes
          

          being added via an enhancement is small compared to the size
          of the
          

          module being updated.=C2=A0 In this case I believe that it bett=
er
          to add
          

          these data nodes into the module itself, perhaps predicated
          under
          

          if-feature if appropriate.
          

          

          Thanks,
          

          Rob
          

          

          

          _______________________________________________
          

          netmod mailing list
          

          netmod@ietf.org
          

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

        

        .
        

        

      

      

      _______________________________________________
      

      netmod mailing list
      

      netmod@ietf.org
      

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

    

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


  



--------------ms000807020502020505030802
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTExMzEzNDY1Nlow
LwYJKoZIhvcNAQkEMSIEIDWs6sWYdfuVE+WQbcuC+CpRO562ZNr4JnL9evBhd2ZOMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAKYluFBZGu8Uzq2m4tAK8FiDRivQr2xeS/4w6lKn3OWh2vFc
LUNKPjKwi79eRbTb8oyjJGd6mL2/GWT0RulUaIJoYNBJntIxva3qw3ReD6XG1c6e+jyW6hl7
9qc4HibaI1W0kHL8UdvNSmcbudfQiNYy7SFqtNaL9qVgyGo2ywz5pv4hYwgB8876SBlhttCT
bA7DNVpDkstqDGsK1bgn/e1SOjKEuCPCJ8F5LK/s1/c/a6FQFZu03LnY7APbuAXHNQVvWjgv
zTmYfP7Lfcq6/qHRl32/QJuJT38Yixkd/+E9eaQyAZCwjLoy+RFq8fBTvoB6FRbr+B0wiL34
pifUmNoAAAAAAAA=

--------------ms000807020502020505030802--


From nobody Tue Nov 13 06:01: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 7483D130DDC for ; Tue, 13 Nov 2018 06:01:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level: 
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGi07LodJ4kN for ; Tue, 13 Nov 2018 06:01:19 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3FC130DE5 for ; Tue, 13 Nov 2018 06:01:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14776; q=dns/txt; s=iport; t=1542117674; x=1543327274; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=guHnUxyE5panu2TUv6E/oZ9Lby4/X9Ih2kUQMu4SfOU=; b=DVaTJrDQYMKo5KIgEPnoS/H4aG+e9xEKziQ68zLTxAkEBaOSEKjqFCNX BZI7ouXndJAfIb6UwJ27GgwLrS1OKQMUsogLyP5fr4iWOSWQBzxQgY4Z+ +JGPHAumIGtphxivv87sHGnz9N9BF7prQZ12pEJ3s3VYwa6vFx4e50mjR 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAABd2Opb/xbLJq1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwMBAQEBCwGBVYEUcBIng3iId40GJZFhhVQUgWYNGAEKhAN?= =?us-ascii?q?GAoNbNgsNAQMBAQIBAQJtHAyFOgEBAQMBAQEhSwsFCwsYKgICJzAGAQwGAgE?= =?us-ascii?q?BF4MGAYF5CA+nT4EvH4UhhGUFjBiBQD+BOAyBYX6DGwEBgS4BEgEHAoMaglc?= =?us-ascii?q?CiRsllhYJhjeDL4c2BhiJWIcbkSSGWYFKAi9kcTMaCBsVO4JsgicXiF6FPj8?= =?us-ascii?q?DMItxgj4BAQ?=
X-IronPort-AV: E=Sophos;i="5.54,499,1534809600"; d="scan'208,217";a="8015118"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Nov 2018 14:01:12 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id wADE1B6O007871; Tue, 13 Nov 2018 14:01:12 GMT
To: =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= , Martin Bjorklund 
Cc: "netmod@ietf.org" 
References:  <20181112.173351.1984161388756642220.mbj@tail-f.com>  <77b69d64-2ce2-29d9-77a9-04a7159003a9@ericsson.com>
From: Robert Wilton 
Message-ID: 
Date: Tue, 13 Nov 2018 14:01:11 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <77b69d64-2ce2-29d9-77a9-04a7159003a9@ericsson.com>
Content-Type: multipart/alternative; boundary="------------B20B28A5A3BD3E35015EDC44"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] Deviations and augmentations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 14:01:29 -0000

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

Hi Balazs,

On 13/11/2018 13:46, Balázs Lengyel wrote:
>
> Hello,
>
> We also need a method for removing stuff. It does happen that some 
> functionality is deemed not important enough, outdated, too expensive 
> to maintain, so we want to remove it.
>
>   * Augment is clearly not the tool for that.
>   * Deviations are not intended for that  (from rfc 7950: "server
>     deviation: A failure of the server ...")
>
> So we still need Semver(or something akin) and the possibility to do 
> NBC changes.
>
But one could perhaps argue that nodes should only be removed (i.e. 
obsoleted) at the development head, where semver is allowed.

Do you think that we also need to support obsoleting YANG nodes in 
branches that have already been released?

Thanks,
Rob


> Balazs
>
> On 2018. 11. 12. 18:08, Robert Wilton wrote:
>>
>>
>> On 12/11/2018 16:33, Martin Bjorklund wrote:
>>> Robert Wilton  wrote:
>>>> In the Thursday Netmod meeting, it was interesting to hear Rob Shakir
>>>> describe how deviations and augmentations are used in OpenConfig to
>>>> add functionality into an older YANG model where the semver rules
>>>> prevent the version number from being incremented.
>>>>
>>>> Further, I think that someone (Martin?) stated on the audio bridge
>>>> that this was an intended/allowed behavior for deviations.
>>> I said that using augmentations (not deviations) was one idea we
>>> originally had for solving the "branching problem".
>> Ah, OK. I agree that makes sense.
>>
>>>
>>> I think that this works for OC b/c they don't branch their modules.
>>> Hence I think it is important that we decide if branching is a
>>> requirement or not.
>> So, I think that this probably works for adding enhancements, but not 
>> for the (arguably more important) bug fix case, unless there is a 
>> reasonable solution to having two config data nodes both modifying 
>> the same underlying property.  Perhaps under some reasonable 
>> constraints this could be made to work - but I don't know.
>>
>> Of course, even for enhancements it is not necessarily a perfect 
>> solution.  E.g. backporting some subset of a module already 
>> coded/implemented in latest to an older release.  And yes, we really 
>> do get asked to do this sometimes, although it is relatively rare.
>>
>> Thanks,
>> Rob
>>
>>>
>>>
>>> /martin
>>>
>>>
>>>> This surprised me, because I thought that RFC 7950 was quite explicit
>>>> that this is not what deviations are intended for.  My reading of RFC
>>>> 7950 is that the deviation statement represents the case where the
>>>> server *implementation* does not match the *specification*. However,
>>>> the versioning issue that we are discussing are bug fixes/changes in
>>>> the specification rather than the bug fixes in the implementation.
>>>>
>>>> Personally, I'm really not keen on using deviations to represent bug
>>>> fixes to older YANG models for three reasons:
>>>>
>>>> (i) It is changing the meaning of deviation.  It is much cleaner to
>>>> keep the meaning of deviation statements as they are defined today,
>>>> and not conflate their semantics.
>>>> (ii) A different mechanism is used to put a bug fix into an older
>>>> branch rather than in the head of the development.
>>>> (iii) For clients to track the lifecycle of modules they would not
>>>> only need to know the module version number but would also need to
>>>> find and track all associated deviation modules.  This seems
>>>> significantly more complex for clients than the modified semver that
>>>> was proposed.
>>>>
>>>> ---
>>>>
>>>> I think that has also been some suggestion that augmentations (or
>>>> duplicate YANG modules with their major version number changed) can be
>>>> used to make bug fixes in a completely backwards compatible way.
>>>> However, I still don't understand a robust scheme of how this works.
>>>>
>>>> ---
>>>>
>>>> Finally, there were some comments about using augmentation modules for
>>>> enhancements.  This is fine, where appropriate (e.g. a non trivial
>>>> number of data nodes are being added as an enhancement) then a
>>>> separate module may be the right way to go. But here, I presume that
>>>> the new functionality will always be tracked by that separate module.
>>>> If that functionality folds back into the original module at some
>>>> point in the future, then obviously a non backwards compatible version
>>>> change is being forced on to the client, along with additional work on
>>>> the server as well.
>>>>
>>>> I think that there are also many cases where the number of data nodes
>>>> being added via an enhancement is small compared to the size of the
>>>> module being updated.  In this case I believe that it better to add
>>>> these data nodes into the module itself, perhaps predicated under
>>>> if-feature if appropriate.
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>> _______________________________________________
>>>> 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  

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


  
    
  
  
    
Hi Balazs,

    

    
On 13/11/2018 13:46, Balázs Lengyel
      wrote:

    

    

      
      
Hello,

      
We also need a method for removing stuff. It does happen that
        some functionality is deemed not important enough, outdated, too
        expensive to maintain, so we want to remove it. 

      

      
    
        
  • Augment is clearly not the tool for that.
    • 
        
  • Deviations are not intended for that  (from rfc 7950:
          "server deviation: A failure of the server ...")
    • 
      

      
So we still need Semver(or something akin) and the possibility
        to do NBC changes.

    

    
But one could perhaps argue that nodes should only be removed
      (i.e. obsoleted) at the development head, where semver is allowed.

    
Do you think that we also need to support obsoleting YANG nodes
      in branches that have already been released?

    
Thanks,

      Rob

    

    


    

    

      
Balazs

      

      
On 2018. 11. 12. 18:08, Robert Wilton
        wrote:

      

      
 

        

        On 12/11/2018 16:33, Martin Bjorklund wrote: 

        
Robert Wilton <rwilton@cisco.com>
          wrote: 

          
In the Thursday Netmod meeting, it was
            interesting to hear Rob Shakir 

            describe how deviations and augmentations are used in
            OpenConfig to 

            add functionality into an older YANG model where the semver
            rules 

            prevent the version number from being incremented. 

            

            Further, I think that someone (Martin?) stated on the audio
            bridge 

            that this was an intended/allowed behavior for deviations. 

          

          I said that using augmentations (not deviations) was one idea
          we 

          originally had for solving the "branching problem". 

        

        Ah, OK. I agree that makes sense. 

        

        
 

          I think that this works for OC b/c they don't branch their
          modules. 

          Hence I think it is important that we decide if branching is a
          

          requirement or not. 

        

        So, I think that this probably works for adding enhancements,
        but not for the (arguably more important) bug fix case, unless
        there is a reasonable solution to having two config data nodes
        both modifying the same underlying property.  Perhaps under some
        reasonable constraints this could be made to work - but I don't
        know. 

        

        Of course, even for enhancements it is not necessarily a perfect
        solution.  E.g. backporting some subset of a module already
        coded/implemented in latest to an older release.  And yes, we
        really do get asked to do this sometimes, although it is
        relatively rare. 

        

        Thanks, 

        Rob 

        

        
 

          

          /martin 

          

          

          
This surprised me, because I thought
            that RFC 7950 was quite explicit 

            that this is not what deviations are intended for.  My
            reading of RFC 

            7950 is that the deviation statement represents the case
            where the 

            server *implementation* does not match the *specification*. 
            However, 

            the versioning issue that we are discussing are bug
            fixes/changes in 

            the specification rather than the bug fixes in the
            implementation. 

            

            Personally, I'm really not keen on using deviations to
            represent bug 

            fixes to older YANG models for three reasons: 

            

            (i) It is changing the meaning of deviation.  It is much
            cleaner to 

            keep the meaning of deviation statements as they are defined
            today, 

            and not conflate their semantics. 

            (ii) A different mechanism is used to put a bug fix into an
            older 

            branch rather than in the head of the development. 

            (iii) For clients to track the lifecycle of modules they
            would not 

            only need to know the module version number but would also
            need to 

            find and track all associated deviation modules.  This seems
            

            significantly more complex for clients than the modified
            semver that 

            was proposed. 

            

            --- 

            

            I think that has also been some suggestion that
            augmentations (or 

            duplicate YANG modules with their major version number
            changed) can be 

            used to make bug fixes in a completely backwards compatible
            way. 

            However, I still don't understand a robust scheme of how
            this works. 

            

            --- 

            

            Finally, there were some comments about using augmentation
            modules for 

            enhancements.  This is fine, where appropriate (e.g. a non
            trivial 

            number of data nodes are being added as an enhancement) then
            a 

            separate module may be the right way to go. But here, I
            presume that 

            the new functionality will always be tracked by that
            separate module. 

            If that functionality folds back into the original module at
            some 

            point in the future, then obviously a non backwards
            compatible version 

            change is being forced on to the client, along with
            additional work on 

            the server as well. 

            

            I think that there are also many cases where the number of
            data nodes 

            being added via an enhancement is small compared to the size
            of the 

            module being updated.  In this case I believe that it better
            to add 

            these data nodes into the module itself, perhaps predicated
            under 

            if-feature if appropriate. 

            

            Thanks, 

            Rob 

            

            

            _______________________________________________ 

            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 


    

  


--------------B20B28A5A3BD3E35015EDC44--


From nobody Tue Nov 13 06:07:16 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DF412F1A6 for ; Tue, 13 Nov 2018 06:07:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fl7WsuKqolRF for ; Tue, 13 Nov 2018 06:07:13 -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 F1B2812D4EE for ; Tue, 13 Nov 2018 06:07:12 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 84439DC0; Tue, 13 Nov 2018 15:07:11 +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 3UaYS2dzFYIm; Tue, 13 Nov 2018 15:07:11 +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, 13 Nov 2018 15:07:11 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6CF1C2003F; Tue, 13 Nov 2018 15:07:11 +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 Uy1mD6jLFvUC; Tue, 13 Nov 2018 15:07:11 +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 E05192003C; Tue, 13 Nov 2018 15:07:10 +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, 13 Nov 2018 15:07:10 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 3998530040FFA2; Tue, 13 Nov 2018 15:07:09 +0100 (CET)
Date: Tue, 13 Nov 2018 15:07:09 +0100
From: Juergen Schoenwaelder 
To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel 
CC: "Yemin (Amy)" , Qin Wu , Xufeng Liu , NETMOD WG 
Message-ID: <20181113140709.vwc4f3mqmmgjaluu@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel ,  "Yemin (Amy)" , Qin Wu , Xufeng Liu , NETMOD WG 
References:  <9C5FD3EFA72E1740A3D41BADDE0B461FCFA7803B@DGGEMM528-MBX.china.huawei.com> <20181106141613.zqy5xmq7qvahzzpz@anna.jacobs.jacobs-university.de> <9C5FD3EFA72E1740A3D41BADDE0B461FCFA78BFA@DGGEMM528-MBX.china.huawei.com> <20181107083401.7bqbjnewg3syd6dj@anna.jacobs.jacobs-university.de> <0bb4d572-3378-c46a-0802-c2c2fce7cc4e@ericsson.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: <0bb4d572-3378-c46a-0802-c2c2fce7cc4e@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] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 14:07:16 -0000

On Tue, Nov 13, 2018 at 01:33:01PM +0000, Balzs 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.

/js

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


From nobody Tue Nov 13 07:17: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 9EC18130DDD for ; Tue, 13 Nov 2018 07:17:44 -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=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 A4zq_4YSYixk for ; Tue, 13 Nov 2018 07:17:41 -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 4A75B128A6E for ; Tue, 13 Nov 2018 07:17:41 -0800 (PST)
Received: by mail-lf1-x131.google.com with SMTP id v5so9079080lfe.7 for ; Tue, 13 Nov 2018 07:17:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8/2IZpnqOExUjQlHhpnzXN8wYUWOB8+ASQWFwE3mA7M=; b=Rn4Mh2GFJn2Qi0Z4EWNqRP9NVuU9rqZhRUcCWFAhzlyu+FciHamPz6ndOj2YrXAveH ZSF2E412VLm1GDqajDeBRKUHRdUbxcRZh+R3TEEb83CMzO/08sFtimcWcVrhdKrtCrv6 OepZuurF/gUJBHDkEFIZ0NZX18UtkSx+zYq1lf9whzojv7XhY2jQbyiY6RARe2Pw/B/5 mgoqWzU35Ym0mm7p8fVy1xP4ltNW2tqITuan+AqcmdaMbQuLBdeasiUBbmo+AdwM5x1t PaPtXL9D9u5aa7pZm6ZdeR3p73X2jsig3n2J2hEjZD2F5R15/bZAtNR3TNKfwwVtUyk+ DYPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8/2IZpnqOExUjQlHhpnzXN8wYUWOB8+ASQWFwE3mA7M=; b=hnIuVnR71WWbsjlOYIMKUuj2tO3/RhlHsZySTB03UAwme+sZqPj+KxhPIaGu5K/u7R /g/d2JDOffmr27W4BS1Tx/pArKSIXx2+BDBZZhtgTCGR3WkiJtF+9jSnwUtFQ1laWSrn 1RiYcDaUh6VB11ot/GTpsN8xBYNqcPwku2+gDr6OLPVJ4cOFlw188UH2xpn1lwaP//p+ vKqDMGvNGEdopcr6YnCy7Bu7U2Vn6d7u6vRDYgj7Uoh93A+QEY1XZxjhn4y+hiiuFpox XYvEq8xVsxVlR7macZWUTrxTWxA422UVzEUoWa5XUccjhdh669myMw9/c26IP//9leax kk0w==
X-Gm-Message-State: AGRZ1gKSUf1J1yfmmUEAt3v+sBRBAecCqQOQcbBVWcoudBOo/PRwEU5y oY3ONZCE2RuM6VRCGJMN7JKpSNdoPDBLkfoY22P7AA==
X-Google-Smtp-Source: AJdET5dVWMQlDPaxL2DZxjJLJDV0KHcxbBh/Sws19yJPM/C/jOpB2GBTHZPLRmOn+g0QAPlq03BXNxOdwM59gUPj3EY=
X-Received: by 2002:a19:750a:: with SMTP id y10mr3106308lfe.43.1542122259049;  Tue, 13 Nov 2018 07:17:39 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Tue, 13 Nov 2018 07:17:37 -0800 (PST)
In-Reply-To: <77b69d64-2ce2-29d9-77a9-04a7159003a9@ericsson.com>
References:  <20181112.173351.1984161388756642220.mbj@tail-f.com>  <77b69d64-2ce2-29d9-77a9-04a7159003a9@ericsson.com>
From: Andy Bierman 
Date: Tue, 13 Nov 2018 07:17:37 -0800
Message-ID: 
To: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= 
Cc: Robert Wilton , Martin Bjorklund ,  "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000738b5b057a8d5158"
Archived-At: 
Subject: Re: [netmod] Deviations and augmentations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 15:17:44 -0000

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

On Tue, Nov 13, 2018 at 5:46 AM, Bal=C3=A1zs Lengyel  wrote:

> Hello,
>
> We also need a method for removing stuff. It does happen that some
> functionality is deemed not important enough, outdated, too expensive to
> maintain, so we want to remove it.
>
>    - Augment is clearly not the tool for that.
>    - Deviations are not intended for that  (from rfc 7950: "server
>    deviation: A failure of the server ...")
>
>
Removing nodes is easy with the status-stmt. Update the module and set the
status to deprecated or obsolete.


Andy




>
>
> So we still need Semver(or something akin) and the possibility to do NBC
> changes.
>
> Balazs
> On 2018. 11. 12. 18:08, Robert Wilton wrote:
>
>
>
> On 12/11/2018 16:33, Martin Bjorklund wrote:
>
> Robert Wilton   wrote:
>
> In the Thursday Netmod meeting, it was interesting to hear Rob Shakir
> describe how deviations and augmentations are used in OpenConfig to
> add functionality into an older YANG model where the semver rules
> prevent the version number from being incremented.
>
> Further, I think that someone (Martin?) stated on the audio bridge
> that this was an intended/allowed behavior for deviations.
>
> I said that using augmentations (not deviations) was one idea we
> originally had for solving the "branching problem".
>
> Ah, OK. I agree that makes sense.
>
>
> I think that this works for OC b/c they don't branch their modules.
> Hence I think it is important that we decide if branching is a
> requirement or not.
>
> So, I think that this probably works for adding enhancements, but not for
> the (arguably more important) bug fix case, unless there is a reasonable
> solution to having two config data nodes both modifying the same underlyi=
ng
> property.  Perhaps under some reasonable constraints this could be made t=
o
> work - but I don't know.
>
> Of course, even for enhancements it is not necessarily a perfect
> solution.  E.g. backporting some subset of a module already
> coded/implemented in latest to an older release.  And yes, we really do g=
et
> asked to do this sometimes, although it is relatively rare.
>
> Thanks,
> Rob
>
>
>
> /martin
>
>
> This surprised me, because I thought that RFC 7950 was quite explicit
> that this is not what deviations are intended for.  My reading of RFC
> 7950 is that the deviation statement represents the case where the
> server *implementation* does not match the *specification*.  However,
> the versioning issue that we are discussing are bug fixes/changes in
> the specification rather than the bug fixes in the implementation.
>
> Personally, I'm really not keen on using deviations to represent bug
> fixes to older YANG models for three reasons:
>
> (i) It is changing the meaning of deviation.  It is much cleaner to
> keep the meaning of deviation statements as they are defined today,
> and not conflate their semantics.
> (ii) A different mechanism is used to put a bug fix into an older
> branch rather than in the head of the development.
> (iii) For clients to track the lifecycle of modules they would not
> only need to know the module version number but would also need to
> find and track all associated deviation modules.  This seems
> significantly more complex for clients than the modified semver that
> was proposed.
>
> ---
>
> I think that has also been some suggestion that augmentations (or
> duplicate YANG modules with their major version number changed) can be
> used to make bug fixes in a completely backwards compatible way.
> However, I still don't understand a robust scheme of how this works.
>
> ---
>
> Finally, there were some comments about using augmentation modules for
> enhancements.  This is fine, where appropriate (e.g. a non trivial
> number of data nodes are being added as an enhancement) then a
> separate module may be the right way to go. But here, I presume that
> the new functionality will always be tracked by that separate module.
> If that functionality folds back into the original module at some
> point in the future, then obviously a non backwards compatible version
> change is being forced on to the client, along with additional work on
> the server as well.
>
> I think that there are also many cases where the number of data nodes
> being added via an enhancement is small compared to the size of the
> module being updated.  In this case I believe that it better to add
> these data nodes into the module itself, perhaps predicated under
> if-feature if appropriate.
>
> Thanks,
> Rob
>
>
> _______________________________________________
> 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
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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




On Tue, Nov 13, 2018 at 5:46 AM, Bal=C3=A1zs Lengyel =
<balazs=
.lengyel@ericsson.com> wrote:

 =20
   =20
 =20
  

    
Hello,

    
We also need a method for removing stuff. It does happen that
      some functionality is deemed not important enough, outdated, too
      expensive to maintain, so we want to remove it. 

    

    
    
      
  • Augment is clearly not the tool for that.
    • 
      
  • Deviations are not intended for that=C2=A0 (from rfc 7950: "=
server
        deviation: A failure of the server ...")

Removing nodes is easy with the status-stmt. Upd=
ate the module and set the status to deprecated or obsolete.

=


Andy


=C2=
=A0
    
    

    
So we still need Semver(or something akin) and the possibility to
      do NBC changes.

    
Balazs

    

    
On 2018. 11. 12. 1=
8:08, Robert Wilton
      wrote:

    

    

      

      

      On 12/11/2018 16:33, Martin Bjorklund wrote:
      

      
Robert Wilton <rwilton@cisco.com>
        wrote:
        

        
In the Thursday Netmod meeting, it was
          interesting to hear Rob Shakir
          

          describe how deviations and augmentations are used in
          OpenConfig to
          

          add functionality into an older YANG model where the semver
          rules
          

          prevent the version number from being incremented.
          

          

          Further, I think that someone (Martin?) stated on the audio
          bridge
          

          that this was an intended/allowed behavior for deviations.
          

        

        I said that using augmentations (not deviations) was one idea we
        

        originally had for solving the "branching problem".
        

      

      Ah, OK. I agree that makes sense.
      

      

      

        

        I think that this works for OC b/c they don't branch their
        modules.
        

        Hence I think it is important that we decide if branching is a
        

        requirement or not.
        

      

      So, I think that this probably works for adding enhancements, but
      not for the (arguably more important) bug fix case, unless there
      is a reasonable solution to having two config data nodes both
      modifying the same underlying property.=C2=A0 Perhaps under some
      reasonable constraints this could be made to work - but I don't
      know.
      

      

      Of course, even for enhancements it is not necessarily a perfect
      solution.=C2=A0 E.g. backporting some subset of a module already
      coded/implemented in latest to an older release.=C2=A0 And yes, we
      really do get asked to do this sometimes, although it is
      relatively rare.
      

      

      Thanks,
      

      Rob
      

      

      

        

        

        /martin
        

        

        

        
This surprised me, because I thought
          that RFC 7950 was quite explicit
          

          that this is not what deviations are intended for.=C2=A0 My readi=
ng
          of RFC
          

          7950 is that the deviation statement represents the case where
          the
          

          server *implementation* does not match the *specification*.=C2=A0
          However,
          

          the versioning issue that we are discussing are bug
          fixes/changes in
          

          the specification rather than the bug fixes in the
          implementation.
          

          

          Personally, I'm really not keen on using deviations to
          represent bug
          

          fixes to older YANG models for three reasons:
          

          

          (i) It is changing the meaning of deviation.=C2=A0 It is much
          cleaner to
          

          keep the meaning of deviation statements as they are defined
          today,
          

          and not conflate their semantics.
          

          (ii) A different mechanism is used to put a bug fix into an
          older
          

          branch rather than in the head of the development.
          

          (iii) For clients to track the lifecycle of modules they would
          not
          

          only need to know the module version number but would also
          need to
          

          find and track all associated deviation modules.=C2=A0 This seems
          

          significantly more complex for clients than the modified
          semver that
          

          was proposed.
          

          

          ---
          

          

          I think that has also been some suggestion that augmentations
          (or
          

          duplicate YANG modules with their major version number
          changed) can be
          

          used to make bug fixes in a completely backwards compatible
          way.
          

          However, I still don't understand a robust scheme of how this
          works.
          

          

          ---
          

          

          Finally, there were some comments about using augmentation
          modules for
          

          enhancements.=C2=A0 This is fine, where appropriate (e.g. a non
          trivial
          

          number of data nodes are being added as an enhancement) then a
          

          separate module may be the right way to go. But here, I
          presume that
          

          the new functionality will always be tracked by that separate
          module.
          

          If that functionality folds back into the original module at
          some
          

          point in the future, then obviously a non backwards compatible
          version
          

          change is being forced on to the client, along with additional
          work on
          

          the server as well.
          

          

          I think that there are also many cases where the number of
          data nodes
          

          being added via an enhancement is small compared to the size
          of the
          

          module being updated.=C2=A0 In this case I believe that it better
          to add
          

          these data nodes into the module itself, perhaps predicated
          under
          

          if-feature if appropriate.
          

          

          Thanks,
          

          Rob
          

          

          

          _______________________________________________
          

          netmod mailing list
          

          netmod@ietf.org
          

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

        

        .
        

        

      

      

      _______________________________________________
      

      netmod mailing list
      

      netmod@ietf.org
      

      https://www.iet=
f.org/mailman/listinfo/netmod
      

    

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


  




_______________________________________________

netmod mailing list

netmod@ietf.org

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




--000000000000738b5b057a8d5158--


From nobody Tue Nov 13 07:28: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 E710E130E35 for ; Tue, 13 Nov 2018 07:28:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level: 
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKypO-UpqXgI for ; Tue, 13 Nov 2018 07:28:40 -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 5F7FF130E1E for ; Tue, 13 Nov 2018 07:28:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20209; q=dns/txt; s=iport; t=1542122919; x=1543332519; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=U6RADB54Axvx98ZEwav9RTloecd1a8u4ryfmQ2lRu4E=; b=JbHcudRFBzBlhwm0S6bvZhp35R/4eE6rH8bBBGtcRk8rVdeAFk+ajtbj FjoS4CrYFgFnZIC2NaAkKf0vRLrNtemhRhBJlubM/4ocP0j0taMCrnpMD q5a5LaHa0TgryFMDBi/LxwPycUwDv7iKucpHd+BOBxufaxtrk6q27erAB U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAABy7Opb/xbLJq1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBVYEUTyESJ4N4iBhfjSuXNRSBZg0YAQqEA0Y?= =?us-ascii?q?Cg100DQ0BAwEBAgEBAm0cDIU6AQEBAwEBASFLCxALGCcDAgInHxEGAQwGAgE?= =?us-ascii?q?BF4MGAYF5CA+neIEvH4UhhGEFjBmBQD+BOIFtfoMbAQGBLgESAQmDGoJXAok?= =?us-ascii?q?bJZYWCYY3gy+HNgYYgViIAIcbiVqHSoZZgUM4ZHEzGggbFTuCbIF3MBeIXoU?= =?us-ascii?q?+PwMwi2OCPgEB?=
X-IronPort-AV: E=Sophos;i="5.54,499,1534809600"; d="scan'208,217";a="8016877"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Nov 2018 15:28:37 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id wADFSa8m022560; Tue, 13 Nov 2018 15:28:36 GMT
To: Andy Bierman , =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= 
Cc: Martin Bjorklund , "netmod@ietf.org" 
References:  <20181112.173351.1984161388756642220.mbj@tail-f.com>  <77b69d64-2ce2-29d9-77a9-04a7159003a9@ericsson.com> 
From: Robert Wilton 
Message-ID: <98d6293c-d762-4d21-a9e2-c9cb20f74135@cisco.com>
Date: Tue, 13 Nov 2018 15:28:36 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------95BF2F9A884985BE39472A2E"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] Deviations and augmentations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 15:28:49 -0000

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


On 13/11/2018 15:17, Andy Bierman wrote:
>
>
> On Tue, Nov 13, 2018 at 5:46 AM, Balázs Lengyel 
> > wrote:
>
>     Hello,
>
>     We also need a method for removing stuff. It does happen that some
>     functionality is deemed not important enough, outdated, too
>     expensive to maintain, so we want to remove it.
>
>       * Augment is clearly not the tool for that.
>       * Deviations are not intended for that  (from rfc 7950: "server
>         deviation: A failure of the server ...")
>
>
> Removing nodes is easy with the status-stmt. Update the module and set 
> the status to deprecated or obsolete.

Yes, but obsoleting nodes should be regarded as a 
non-backwards-compatible change because it can break clients that were 
relying on those nodes.

Thanks,
Rob


>
>
> Andy
>
>
>     So we still need Semver(or something akin) and the possibility to
>     do NBC changes.
>
>     Balazs
>
>     On 2018. 11. 12. 18:08, Robert Wilton wrote:
>>
>>
>>     On 12/11/2018 16:33, Martin Bjorklund wrote:
>>>     Robert Wilton   wrote:
>>>>     In the Thursday Netmod meeting, it was interesting to hear Rob
>>>>     Shakir
>>>>     describe how deviations and augmentations are used in
>>>>     OpenConfig to
>>>>     add functionality into an older YANG model where the semver rules
>>>>     prevent the version number from being incremented.
>>>>
>>>>     Further, I think that someone (Martin?) stated on the audio bridge
>>>>     that this was an intended/allowed behavior for deviations.
>>>     I said that using augmentations (not deviations) was one idea we
>>>     originally had for solving the "branching problem".
>>     Ah, OK. I agree that makes sense.
>>
>>>
>>>     I think that this works for OC b/c they don't branch their modules.
>>>     Hence I think it is important that we decide if branching is a
>>>     requirement or not.
>>     So, I think that this probably works for adding enhancements, but
>>     not for the (arguably more important) bug fix case, unless there
>>     is a reasonable solution to having two config data nodes both
>>     modifying the same underlying property.  Perhaps under some
>>     reasonable constraints this could be made to work - but I don't
>>     know.
>>
>>     Of course, even for enhancements it is not necessarily a perfect
>>     solution.  E.g. backporting some subset of a module already
>>     coded/implemented in latest to an older release.  And yes, we
>>     really do get asked to do this sometimes, although it is
>>     relatively rare.
>>
>>     Thanks,
>>     Rob
>>
>>>
>>>
>>>     /martin
>>>
>>>
>>>>     This surprised me, because I thought that RFC 7950 was quite
>>>>     explicit
>>>>     that this is not what deviations are intended for.  My reading
>>>>     of RFC
>>>>     7950 is that the deviation statement represents the case where the
>>>>     server *implementation* does not match the *specification*. 
>>>>     However,
>>>>     the versioning issue that we are discussing are bug
>>>>     fixes/changes in
>>>>     the specification rather than the bug fixes in the implementation.
>>>>
>>>>     Personally, I'm really not keen on using deviations to
>>>>     represent bug
>>>>     fixes to older YANG models for three reasons:
>>>>
>>>>     (i) It is changing the meaning of deviation.  It is much
>>>>     cleaner to
>>>>     keep the meaning of deviation statements as they are defined
>>>>     today,
>>>>     and not conflate their semantics.
>>>>     (ii) A different mechanism is used to put a bug fix into an older
>>>>     branch rather than in the head of the development.
>>>>     (iii) For clients to track the lifecycle of modules they would not
>>>>     only need to know the module version number but would also need to
>>>>     find and track all associated deviation modules. This seems
>>>>     significantly more complex for clients than the modified semver
>>>>     that
>>>>     was proposed.
>>>>
>>>>     ---
>>>>
>>>>     I think that has also been some suggestion that augmentations (or
>>>>     duplicate YANG modules with their major version number changed)
>>>>     can be
>>>>     used to make bug fixes in a completely backwards compatible way.
>>>>     However, I still don't understand a robust scheme of how this
>>>>     works.
>>>>
>>>>     ---
>>>>
>>>>     Finally, there were some comments about using augmentation
>>>>     modules for
>>>>     enhancements.  This is fine, where appropriate (e.g. a non trivial
>>>>     number of data nodes are being added as an enhancement) then a
>>>>     separate module may be the right way to go. But here, I presume
>>>>     that
>>>>     the new functionality will always be tracked by that separate
>>>>     module.
>>>>     If that functionality folds back into the original module at some
>>>>     point in the future, then obviously a non backwards compatible
>>>>     version
>>>>     change is being forced on to the client, along with additional
>>>>     work on
>>>>     the server as well.
>>>>
>>>>     I think that there are also many cases where the number of data
>>>>     nodes
>>>>     being added via an enhancement is small compared to the size of
>>>>     the
>>>>     module being updated.  In this case I believe that it better to
>>>>     add
>>>>     these data nodes into the module itself, perhaps predicated under
>>>>     if-feature if appropriate.
>>>>
>>>>     Thanks,
>>>>     Rob
>>>>
>>>>
>>>>     _______________________________________________
>>>>     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    
>
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netmod
>     
>
>

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


  
    
  
  
    


    

    
On 13/11/2018 15:17, Andy Bierman
      wrote:

    

    

      
      


        


          
On Tue, Nov 13, 2018 at 5:46 AM,
            Balázs Lengyel <balazs.lengyel@ericsson.com>
            wrote:

            

              

                
Hello,

                
We also need a method for removing stuff. It does
                  happen that some functionality is deemed not important
                  enough, outdated, too expensive to maintain, so we
                  want to remove it. 

                

                
    
                  
  • Augment is clearly not the tool for that.
    • 
                  
  • Deviations are not intended for that  (from rfc
                    7950: "server deviation: A failure of the server
                    ...")
    • 
                

              

            

            


            

            
Removing nodes is easy with the status-stmt. Update the
              module and set the status to deprecated or obsolete.

          

        

      

    

    
Yes, but obsoleting nodes should be regarded as a
      non-backwards-compatible change because it can break clients that
      were relying on those nodes.

    
Thanks,

      Rob

    

    


    

    

      

        

          

            


            

            


            

            
Andy

            


            

            


            

            
 

            

              

                
    
                

                
So we still need Semver(or something akin) and the
                  possibility to do NBC changes.

                
Balazs

                

                
On
                  2018. 11. 12. 18:08, Robert Wilton wrote:

                

                
 

                  

                  On 12/11/2018 16:33, Martin Bjorklund wrote: 

                  
Robert Wilton <rwilton@cisco.com>
                    wrote: 

                    
In the Thursday Netmod
                      meeting, it was interesting to hear Rob Shakir 

                      describe how deviations and augmentations are used
                      in OpenConfig to 

                      add functionality into an older YANG model where
                      the semver rules 

                      prevent the version number from being incremented.
                      

                      

                      Further, I think that someone (Martin?) stated on
                      the audio bridge 

                      that this was an intended/allowed behavior for
                      deviations. 

                    

                    I said that using augmentations (not deviations) was
                    one idea we 

                    originally had for solving the "branching problem".
                    

                  

                  Ah, OK. I agree that makes sense. 

                  

                  
 

                    I think that this works for OC b/c they don't branch
                    their modules. 

                    Hence I think it is important that we decide if
                    branching is a 

                    requirement or not. 

                  

                  So, I think that this probably works for adding
                  enhancements, but not for the (arguably more
                  important) bug fix case, unless there is a reasonable
                  solution to having two config data nodes both
                  modifying the same underlying property.  Perhaps under
                  some reasonable constraints this could be made to work
                  - but I don't know. 

                  

                  Of course, even for enhancements it is not necessarily
                  a perfect solution.  E.g. backporting some subset of a
                  module already coded/implemented in latest to an older
                  release.  And yes, we really do get asked to do this
                  sometimes, although it is relatively rare. 

                  

                  Thanks, 

                  Rob 

                  

                  
 

                    

                    /martin 

                    

                    

                    
This surprised me, because I
                      thought that RFC 7950 was quite explicit 

                      that this is not what deviations are intended
                      for.  My reading of RFC 

                      7950 is that the deviation statement represents
                      the case where the 

                      server *implementation* does not match the
                      *specification*.  However, 

                      the versioning issue that we are discussing are
                      bug fixes/changes in 

                      the specification rather than the bug fixes in the
                      implementation. 

                      

                      Personally, I'm really not keen on using
                      deviations to represent bug 

                      fixes to older YANG models for three reasons: 

                      

                      (i) It is changing the meaning of deviation.  It
                      is much cleaner to 

                      keep the meaning of deviation statements as they
                      are defined today, 

                      and not conflate their semantics. 

                      (ii) A different mechanism is used to put a bug
                      fix into an older 

                      branch rather than in the head of the development.
                      

                      (iii) For clients to track the lifecycle of
                      modules they would not 

                      only need to know the module version number but
                      would also need to 

                      find and track all associated deviation modules. 
                      This seems 

                      significantly more complex for clients than the
                      modified semver that 

                      was proposed. 

                      

                      --- 

                      

                      I think that has also been some suggestion that
                      augmentations (or 

                      duplicate YANG modules with their major version
                      number changed) can be 

                      used to make bug fixes in a completely backwards
                      compatible way. 

                      However, I still don't understand a robust scheme
                      of how this works. 

                      

                      --- 

                      

                      Finally, there were some comments about using
                      augmentation modules for 

                      enhancements.  This is fine, where appropriate
                      (e.g. a non trivial 

                      number of data nodes are being added as an
                      enhancement) then a 

                      separate module may be the right way to go. But
                      here, I presume that 

                      the new functionality will always be tracked by
                      that separate module. 

                      If that functionality folds back into the original
                      module at some 

                      point in the future, then obviously a non
                      backwards compatible version 

                      change is being forced on to the client, along
                      with additional work on 

                      the server as well. 

                      

                      I think that there are also many cases where the
                      number of data nodes 

                      being added via an enhancement is small compared
                      to the size of the 

                      module being updated.  In this case I believe that
                      it better to add 

                      these data nodes into the module itself, perhaps
                      predicated under 

                      if-feature if appropriate. 

                      

                      Thanks, 

                      Rob 

                      

                      

                      _______________________________________________
                      

                      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 


                  

              

              _______________________________________________

              netmod mailing list

              netmod@ietf.org

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

              

            

          

          

        

      

    

  


--------------95BF2F9A884985BE39472A2E--


From nobody Tue Nov 13 07:32: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 CF380128D09 for ; Tue, 13 Nov 2018 07:32:21 -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=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 EEPp4qVwzy2g for ; Tue, 13 Nov 2018 07:32:18 -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 5656E128A6E for ; Tue, 13 Nov 2018 07:32:18 -0800 (PST)
Received: by mail-lf1-x136.google.com with SMTP id l10so5512136lfh.9 for ; Tue, 13 Nov 2018 07:32:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1rqEiFFmk30d/pOIOZ4DlRjpaannSe6w8kxWtfkZlOc=; b=snPCdoe2cB7v5dcOeIif0SUBzGgmqST+lXDjuHCHvLxo0zuk2uR7SHcSdfTrbKvA8/ qp2jn6rYxX7GBkLiBa3Ajtk3FpnDJDW2occKAcm7lcri9YsB+AwxHmb0VEEEg2G8Jdex Zys82viaoH5CJ2wZhzRidy9qjQn8lMme+231LKwGwrh6XewHAuaFE8CTygWxWPOjmMVY o7GRmpFPwhd7n2hs3ORsSTTs1aTf74lZ7G81xn9m7izYmyWG2a8vgI8PSlgrOkjTsUjO I9e9v5NBoofLhMWMoiYkBnuQJVynbQVswgGYLv6jndvxDI7g7M69aRUpjds23jzN7lqM zRyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1rqEiFFmk30d/pOIOZ4DlRjpaannSe6w8kxWtfkZlOc=; b=oxO8hnkTbe02XneX3TFS9pN7nU34ybWsB/8ehb20WoOtN0D4LerTWT6wRj4b3OvkCC DQU+pQUE5fU9s8kYrL4QWPJJCnrESFnf+RIbBGg0rilLyqIXHQC5yQXqZUx58dzqvEVS DqzaoFkjrtUj5IhVoJghf/wNx+yoCpWv4sl1NUQYZvJvAwJS0bErQ9oisk5V5E58oaJf NZRVWZ7raIk1+CTZQJYHo+p4fLSyNAhyNjI+KHwZ4OnpKSzIREOrPxuXsEg43wbSmdLA T/V6BSrAt4UYfcyHhnfUItUf5ZdSL+Vxx0BQj0TxvR0t7m0y9rhELjNdMfwS5PRcc4gu qDNA==
X-Gm-Message-State: AGRZ1gL5Pqat0jBDv9w1CX4wkf12NPwm7ogAUdfPo6aJ0xtnQwUkGKs6 3nn4c5PTdEWa8g6jH+yCsbdslD+Q5f/KZYvDKptDug==
X-Google-Smtp-Source: AJdET5c+kwbur30YKOKML1nV+Op8LF6quVMvY/5nDWsAjh9XRY0b/daXj/kndiQSTPELunxtrhz+7mCYL4Y2HMn4FUA=
X-Received: by 2002:a19:d58e:: with SMTP id m136mr3513554lfg.70.1542123136314;  Tue, 13 Nov 2018 07:32:16 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Tue, 13 Nov 2018 07:32:14 -0800 (PST)
In-Reply-To: <98d6293c-d762-4d21-a9e2-c9cb20f74135@cisco.com>
References:  <20181112.173351.1984161388756642220.mbj@tail-f.com>  <77b69d64-2ce2-29d9-77a9-04a7159003a9@ericsson.com>  <98d6293c-d762-4d21-a9e2-c9cb20f74135@cisco.com>
From: Andy Bierman 
Date: Tue, 13 Nov 2018 07:32:14 -0800
Message-ID: 
To: Robert Wilton 
Cc: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= ,  Martin Bjorklund , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000bd900d057a8d85c6"
Archived-At: 
Subject: Re: [netmod] Deviations and augmentations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 15:32:22 -0000

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

On Tue, Nov 13, 2018 at 7:28 AM, Robert Wilton  wrote:

>
> On 13/11/2018 15:17, Andy Bierman wrote:
>
>
>
> On Tue, Nov 13, 2018 at 5:46 AM, Bal=C3=A1zs Lengyel <
> balazs.lengyel@ericsson.com> wrote:
>
>> Hello,
>>
>> We also need a method for removing stuff. It does happen that some
>> functionality is deemed not important enough, outdated, too expensive to
>> maintain, so we want to remove it.
>>
>>    - Augment is clearly not the tool for that.
>>    - Deviations are not intended for that  (from rfc 7950: "server
>>    deviation: A failure of the server ...")
>>
>>
> Removing nodes is easy with the status-stmt. Update the module and set th=
e
> status to deprecated or obsolete.
>
> Yes, but obsoleting nodes should be regarded as a non-backwards-compatibl=
e
> change because it can break clients that were relying on those nodes.
>

I don't think RFC 7950 says that.
Removing outdated functionality is exactly what the status-stmt is for.
IMO we should learn to use the YANG that is already there.


> Thanks,
> Rob
>
>
>
Andy


>
>
> Andy
>
>
>
>
>>
>>
>> So we still need Semver(or something akin) and the possibility to do NBC
>> changes.
>>
>> Balazs
>> On 2018. 11. 12. 18:08, Robert Wilton wrote:
>>
>>
>>
>> On 12/11/2018 16:33, Martin Bjorklund wrote:
>>
>> Robert Wilton   wrote:
>>
>> In the Thursday Netmod meeting, it was interesting to hear Rob Shakir
>> describe how deviations and augmentations are used in OpenConfig to
>> add functionality into an older YANG model where the semver rules
>> prevent the version number from being incremented.
>>
>> Further, I think that someone (Martin?) stated on the audio bridge
>> that this was an intended/allowed behavior for deviations.
>>
>> I said that using augmentations (not deviations) was one idea we
>> originally had for solving the "branching problem".
>>
>> Ah, OK. I agree that makes sense.
>>
>>
>> I think that this works for OC b/c they don't branch their modules.
>> Hence I think it is important that we decide if branching is a
>> requirement or not.
>>
>> So, I think that this probably works for adding enhancements, but not fo=
r
>> the (arguably more important) bug fix case, unless there is a reasonable
>> solution to having two config data nodes both modifying the same underly=
ing
>> property.  Perhaps under some reasonable constraints this could be made =
to
>> work - but I don't know.
>>
>> Of course, even for enhancements it is not necessarily a perfect
>> solution.  E.g. backporting some subset of a module already
>> coded/implemented in latest to an older release.  And yes, we really do =
get
>> asked to do this sometimes, although it is relatively rare.
>>
>> Thanks,
>> Rob
>>
>>
>>
>> /martin
>>
>>
>> This surprised me, because I thought that RFC 7950 was quite explicit
>> that this is not what deviations are intended for.  My reading of RFC
>> 7950 is that the deviation statement represents the case where the
>> server *implementation* does not match the *specification*.  However,
>> the versioning issue that we are discussing are bug fixes/changes in
>> the specification rather than the bug fixes in the implementation.
>>
>> Personally, I'm really not keen on using deviations to represent bug
>> fixes to older YANG models for three reasons:
>>
>> (i) It is changing the meaning of deviation.  It is much cleaner to
>> keep the meaning of deviation statements as they are defined today,
>> and not conflate their semantics.
>> (ii) A different mechanism is used to put a bug fix into an older
>> branch rather than in the head of the development.
>> (iii) For clients to track the lifecycle of modules they would not
>> only need to know the module version number but would also need to
>> find and track all associated deviation modules.  This seems
>> significantly more complex for clients than the modified semver that
>> was proposed.
>>
>> ---
>>
>> I think that has also been some suggestion that augmentations (or
>> duplicate YANG modules with their major version number changed) can be
>> used to make bug fixes in a completely backwards compatible way.
>> However, I still don't understand a robust scheme of how this works.
>>
>> ---
>>
>> Finally, there were some comments about using augmentation modules for
>> enhancements.  This is fine, where appropriate (e.g. a non trivial
>> number of data nodes are being added as an enhancement) then a
>> separate module may be the right way to go. But here, I presume that
>> the new functionality will always be tracked by that separate module.
>> If that functionality folds back into the original module at some
>> point in the future, then obviously a non backwards compatible version
>> change is being forced on to the client, along with additional work on
>> the server as well.
>>
>> I think that there are also many cases where the number of data nodes
>> being added via an enhancement is small compared to the size of the
>> module being updated.  In this case I believe that it better to add
>> these data nodes into the module itself, perhaps predicated under
>> if-feature if appropriate.
>>
>> Thanks,
>> Rob
>>
>>
>> _______________________________________________
>> 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
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>

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




On Tue, Nov 13, 2018 at 7:28 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:

 =20
   =20
 =20
  

    


    

    
On 13/11/2018 15:17=
, Andy Bierman
      wrote:

    

    

     =20
      


        


          
On Tue, Nov 13, 2018 at 5:46 AM,
            Bal=C3=A1zs Lengyel <balazs.lengyel@ericsson.com=
>
            wrote:

            

              

                
Hello,

                
We also need a method for removing stuff. It does
                  happen that some functionality is deemed not important
                  enough, outdated, too expensive to maintain, so we
                  want to remove it. 

                

                
    
                  
  • Augment is clearly not the tool for that.
    • 
                  
  • Deviations are not intended for that=C2=A0 (from rfc
                    7950: "server deviation: A failure of the server
                    ...")
    • 
                

              

            

            


            

            
Removing nodes is easy with the status-stmt. Update the
              module and set the status to deprecated or obsolete.

          

        

      

    

    
Yes, but obsoleting nodes should be regarded as a
      non-backwards-compatible change because it can break clients that
      were relying on those nodes.

I don't think RFC 7950 says that.
Removing outdated functio=
nality is exactly what the status-stmt is for.
IMO we should lear=
n to use the YANG that is already there.
=C2=A0

    
Thanks,

      Rob

    

    


Andy
=C2=A0=


    

    

      

        

          

            


            

            


            

            
Andy

            


            

            


            

            
=C2=A0

            

              

                
    
                

                
So we still need Semver(or something akin) and the
                  possibility to do NBC changes.

                
Balazs

                

                
On
                  2018. 11. 12. 18:08, Robert Wilton wrote:

                

                
 

                  

                  On 12/11/2018 16:33, Martin Bjorklund wrote: 

                  
Robert Wilton <rwilton@cisco.com>
                    wrote: 

                    
In the Thursday Netmod
                      meeting, it was interesting to hear Rob Shakir 

                      describe how deviations and augmentations are used
                      in OpenConfig to 

                      add functionality into an older YANG model where
                      the semver rules 

                      prevent the version number from being incremented.
                      

                      

                      Further, I think that someone (Martin?) stated on
                      the audio bridge 

                      that this was an intended/allowed behavior for
                      deviations. 

                    

                    I said that using augmentations (not deviations) was
                    one idea we 

                    originally had for solving the "branching problem&=
quot;.
                    

                  

                  Ah, OK. I agree that makes sense. 

                  

                  
 

                    I think that this works for OC b/c they don't branc=
h
                    their modules. 

                    Hence I think it is important that we decide if
                    branching is a 

                    requirement or not. 

                  

                  So, I think that this probably works for adding
                  enhancements, but not for the (arguably more
                  important) bug fix case, unless there is a reasonable
                  solution to having two config data nodes both
                  modifying the same underlying property.=C2=A0 Perhaps und=
er
                  some reasonable constraints this could be made to work
                  - but I don't know. 

                  

                  Of course, even for enhancements it is not necessarily
                  a perfect solution.=C2=A0 E.g. backporting some subset of=
 a
                  module already coded/implemented in latest to an older
                  release.=C2=A0 And yes, we really do get asked to do this
                  sometimes, although it is relatively rare. 

                  

                  Thanks, 

                  Rob 

                  

                  
 

                    

                    /martin 

                    

                    

                    
This surprised me, because I
                      thought that RFC 7950 was quite explicit 

                      that this is not what deviations are intended
                      for.=C2=A0 My reading of RFC 

                      7950 is that the deviation statement represents
                      the case where the 

                      server *implementation* does not match the
                      *specification*.=C2=A0 However, 

                      the versioning issue that we are discussing are
                      bug fixes/changes in 

                      the specification rather than the bug fixes in the
                      implementation. 

                      

                      Personally, I'm really not keen on using
                      deviations to represent bug 

                      fixes to older YANG models for three reasons: 

                      

                      (i) It is changing the meaning of deviation.=C2=A0 It
                      is much cleaner to 

                      keep the meaning of deviation statements as they
                      are defined today, 

                      and not conflate their semantics. 

                      (ii) A different mechanism is used to put a bug
                      fix into an older 

                      branch rather than in the head of the development.
                      

                      (iii) For clients to track the lifecycle of
                      modules they would not 

                      only need to know the module version number but
                      would also need to 

                      find and track all associated deviation modules.=C2=
=A0
                      This seems 

                      significantly more complex for clients than the
                      modified semver that 

                      was proposed. 

                      

                      --- 

                      

                      I think that has also been some suggestion that
                      augmentations (or 

                      duplicate YANG modules with their major version
                      number changed) can be 

                      used to make bug fixes in a completely backwards
                      compatible way. 

                      However, I still don't understand a robust scheme
                      of how this works. 

                      

                      --- 

                      

                      Finally, there were some comments about using
                      augmentation modules for 

                      enhancements.=C2=A0 This is fine, where appropriate
                      (e.g. a non trivial 

                      number of data nodes are being added as an
                      enhancement) then a 

                      separate module may be the right way to go. But
                      here, I presume that 

                      the new functionality will always be tracked by
                      that separate module. 

                      If that functionality folds back into the original
                      module at some 

                      point in the future, then obviously a non
                      backwards compatible version 

                      change is being forced on to the client, along
                      with additional work on 

                      the server as well. 

                      

                      I think that there are also many cases where the
                      number of data nodes 

                      being added via an enhancement is small compared
                      to the size of the 

                      module being updated.=C2=A0 In this case I believe th=
at
                      it better to add 

                      these data nodes into the module itself, perhaps
                      predicated under 

                      if-feature if appropriate. 

                      

                      Thanks, 

                      Rob 

                      

                      

                      _______________________________________________
                      

                      netmod mailing list 

                      netmod@ietf.org 

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

                    

                    . 

                    

                  

                  

                  _______________________________________________ 

                  netmod mailing list 

                  n=
etmod@ietf.org 

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

                   

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


                  
=

              

              _______________________________________________

              netmod mailing list

              netmod@i=
etf.org

              https://www.ietf.org/mailman/listinf=
o/netmod

              

            

          

          

        

      

    

  






--000000000000bd900d057a8d85c6--


From nobody Tue Nov 13 07:54:20 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8B6128CF2 for ; Tue, 13 Nov 2018 07:54:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level: 
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjIohTz1C_dc for ; Tue, 13 Nov 2018 07:54:15 -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 C7155128A6E for ; Tue, 13 Nov 2018 07:54:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30746; q=dns/txt; s=iport; t=1542124455; x=1543334055; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=8qDOgHj8qWfkEMKkan3EvIjs1kZZYW/PFfflv2QqUio=; b=BwQp/qe+kKnk/+1c9qouQ1zh65Iz1oSsNTJ9qfZ+zHLX8DOgnrHpAAOD q/UM7/iA7Dqm67r2cYKJxEBg3l1x+LWTOmiHp44VOjRida+hxbeOtKO2U ypYuYLKpfdAqg5bFr5FfC+/McsXLlNq8oqSNxhlc03IAzmTrcLz4BGSPa k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAACu8upb/xbLJq1kGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYENSIEUD0AhEieDeIgYX40rlzUUgWMDDRgBCoQDRgK?= =?us-ascii?q?DXjQNDQEDAQECAQECbRwMhToBAQEDAQEBIUsLBQsLGCABBgMCAicfEQYNBgI?= =?us-ascii?q?BAReDBgGBeQgPqAeBLx+FIYRgBYwZgUA/gTiBbX6DGwEBgS4BEgEHAoMaglc?= =?us-ascii?q?CiRsli0wSijgJhjeDL4c2BhiBWIgAgUGFWolah0qGWYFDOGRxMxoIGxU7gmy?= =?us-ascii?q?BdzAXiF6FPj8DMItjgj4BAQ?=
X-IronPort-AV: E=Sophos;i="5.54,499,1534809600"; d="scan'208,217";a="7960227"
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; 13 Nov 2018 15:54:12 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id wADFsBeX011538; Tue, 13 Nov 2018 15:54:12 GMT
To: Andy Bierman 
Cc: =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= , Martin Bjorklund , "netmod@ietf.org" 
References:  <20181112.173351.1984161388756642220.mbj@tail-f.com>  <77b69d64-2ce2-29d9-77a9-04a7159003a9@ericsson.com>  <98d6293c-d762-4d21-a9e2-c9cb20f74135@cisco.com> 
From: Robert Wilton 
Message-ID: <453368b2-aa52-f09a-ea0b-960255bce46b@cisco.com>
Date: Tue, 13 Nov 2018 15:54:11 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------41375586AB8DE4B0DF9189D0"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
Subject: Re: [netmod] Deviations and augmentations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 15:54:18 -0000

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


On 13/11/2018 15:32, Andy Bierman wrote:
>
>
> On Tue, Nov 13, 2018 at 7:28 AM, Robert Wilton  > wrote:
>
>
>     On 13/11/2018 15:17, Andy Bierman wrote:
>>
>>
>>     On Tue, Nov 13, 2018 at 5:46 AM, Balázs Lengyel
>>     >     > wrote:
>>
>>         Hello,
>>
>>         We also need a method for removing stuff. It does happen that
>>         some functionality is deemed not important enough, outdated,
>>         too expensive to maintain, so we want to remove it.
>>
>>           * Augment is clearly not the tool for that.
>>           * Deviations are not intended for that (from rfc 7950:
>>             "server deviation: A failure of the server ...")
>>
>>
>>     Removing nodes is easy with the status-stmt. Update the module
>>     and set the status to deprecated or obsolete.
>
>     Yes, but obsoleting nodes should be regarded as a
>     non-backwards-compatible change because it can break clients that
>     were relying on those nodes.
>
>
> I don't think RFC 7950 says that.

RFC 7950 states '"obsolete" means that the definition is obsolete and 
SHOULD NOT be implemented and/or can be removed from implementations.'

So if there was a client using those definitions it would break, hence 
it is a non-backwards-compatible change.


> Removing outdated functionality is exactly what the status-stmt is for.

Agreed.


> IMO we should learn to use the YANG that is already there.

We are trying to make what we have today better.

Specifically, so that a client can look at a semver numbers between two 
modules revisions and determine whether or not they might be broken by 
that change.

Today, just using the status element alone to mark removed nodes means 
that a client would have to check for all changes in the module between 
two revisions to determine whether or not the new module revision is 
backwards compatible with the old one.

Thanks,
Rob


>     Thanks,
>     Rob
>
>
>
> Andy
>
>>
>>
>>     Andy
>>
>>
>>         So we still need Semver(or something akin) and the
>>         possibility to do NBC changes.
>>
>>         Balazs
>>
>>         On 2018. 11. 12. 18:08, Robert Wilton wrote:
>>>
>>>
>>>         On 12/11/2018 16:33, Martin Bjorklund wrote:
>>>>         Robert Wilton 
>>>>          wrote:
>>>>>         In the Thursday Netmod meeting, it was interesting to hear
>>>>>         Rob Shakir
>>>>>         describe how deviations and augmentations are used in
>>>>>         OpenConfig to
>>>>>         add functionality into an older YANG model where the
>>>>>         semver rules
>>>>>         prevent the version number from being incremented.
>>>>>
>>>>>         Further, I think that someone (Martin?) stated on the
>>>>>         audio bridge
>>>>>         that this was an intended/allowed behavior for deviations.
>>>>         I said that using augmentations (not deviations) was one
>>>>         idea we
>>>>         originally had for solving the "branching problem".
>>>         Ah, OK. I agree that makes sense.
>>>
>>>>
>>>>         I think that this works for OC b/c they don't branch their
>>>>         modules.
>>>>         Hence I think it is important that we decide if branching is a
>>>>         requirement or not.
>>>         So, I think that this probably works for adding
>>>         enhancements, but not for the (arguably more important) bug
>>>         fix case, unless there is a reasonable solution to having
>>>         two config data nodes both modifying the same underlying
>>>         property. Perhaps under some reasonable constraints this
>>>         could be made to work - but I don't know.
>>>
>>>         Of course, even for enhancements it is not necessarily a
>>>         perfect solution.  E.g. backporting some subset of a module
>>>         already coded/implemented in latest to an older release. 
>>>         And yes, we really do get asked to do this sometimes,
>>>         although it is relatively rare.
>>>
>>>         Thanks,
>>>         Rob
>>>
>>>>
>>>>
>>>>         /martin
>>>>
>>>>
>>>>>         This surprised me, because I thought that RFC 7950 was
>>>>>         quite explicit
>>>>>         that this is not what deviations are intended for.  My
>>>>>         reading of RFC
>>>>>         7950 is that the deviation statement represents the case
>>>>>         where the
>>>>>         server *implementation* does not match the
>>>>>         *specification*.  However,
>>>>>         the versioning issue that we are discussing are bug
>>>>>         fixes/changes in
>>>>>         the specification rather than the bug fixes in the
>>>>>         implementation.
>>>>>
>>>>>         Personally, I'm really not keen on using deviations to
>>>>>         represent bug
>>>>>         fixes to older YANG models for three reasons:
>>>>>
>>>>>         (i) It is changing the meaning of deviation.  It is much
>>>>>         cleaner to
>>>>>         keep the meaning of deviation statements as they are
>>>>>         defined today,
>>>>>         and not conflate their semantics.
>>>>>         (ii) A different mechanism is used to put a bug fix into
>>>>>         an older
>>>>>         branch rather than in the head of the development.
>>>>>         (iii) For clients to track the lifecycle of modules they
>>>>>         would not
>>>>>         only need to know the module version number but would also
>>>>>         need to
>>>>>         find and track all associated deviation modules.  This seems
>>>>>         significantly more complex for clients than the modified
>>>>>         semver that
>>>>>         was proposed.
>>>>>
>>>>>         ---
>>>>>
>>>>>         I think that has also been some suggestion that
>>>>>         augmentations (or
>>>>>         duplicate YANG modules with their major version number
>>>>>         changed) can be
>>>>>         used to make bug fixes in a completely backwards
>>>>>         compatible way.
>>>>>         However, I still don't understand a robust scheme of how
>>>>>         this works.
>>>>>
>>>>>         ---
>>>>>
>>>>>         Finally, there were some comments about using augmentation
>>>>>         modules for
>>>>>         enhancements.  This is fine, where appropriate (e.g. a non
>>>>>         trivial
>>>>>         number of data nodes are being added as an enhancement)
>>>>>         then a
>>>>>         separate module may be the right way to go. But here, I
>>>>>         presume that
>>>>>         the new functionality will always be tracked by that
>>>>>         separate module.
>>>>>         If that functionality folds back into the original module
>>>>>         at some
>>>>>         point in the future, then obviously a non backwards
>>>>>         compatible version
>>>>>         change is being forced on to the client, along with
>>>>>         additional work on
>>>>>         the server as well.
>>>>>
>>>>>         I think that there are also many cases where the number of
>>>>>         data nodes
>>>>>         being added via an enhancement is small compared to the
>>>>>         size of the
>>>>>         module being updated.  In this case I believe that it
>>>>>         better to add
>>>>>         these data nodes into the module itself, perhaps
>>>>>         predicated under
>>>>>         if-feature if appropriate.
>>>>>
>>>>>         Thanks,
>>>>>         Rob
>>>>>
>>>>>
>>>>>         _______________________________________________
>>>>>         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    
>>
>>
>>         _______________________________________________
>>         netmod mailing list
>>         netmod@ietf.org 
>>         https://www.ietf.org/mailman/listinfo/netmod
>>         
>>
>>
>

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


  
    
  
  
    


    

    
On 13/11/2018 15:32, Andy Bierman
      wrote:

    

    

      
      


        


          
On Tue, Nov 13, 2018 at 7:28 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            

              

                


                

                
On
                  13/11/2018 15:17, Andy Bierman wrote:

                

                

                  


                    


                      
On Tue, Nov 13, 2018 at
                        5:46 AM, Balázs Lengyel <balazs.lengyel@ericsson.com>
                        wrote:

                        

                          

                            
Hello,

                            
We also need a method for removing stuff.
                              It does happen that some functionality is
                              deemed not important enough, outdated, too
                              expensive to maintain, so we want to
                              remove it. 

                            

                            
    
                              
  • Augment is clearly not the tool for
                                that.
    • 
                              
  • Deviations are not intended for that 
                                (from rfc 7950: "server deviation: A
                                failure of the server ...")
    • 
                            

                          

                        

                        


                        

                        
Removing nodes is easy with the
                          status-stmt. Update the module and set the
                          status to deprecated or obsolete.

                      

                    

                  

                

                
Yes, but obsoleting nodes should be regarded as a
                  non-backwards-compatible change because it can break
                  clients that were relying on those nodes.

              

            

            


            

            
I don't think RFC 7950 says that.

          

        

      

    

    
RFC 7950 states '"obsolete" means that the definition is obsolete and SHOULD NOT be
      implemented and/or can be removed from implementations.'

    

    
So if there was a client using those definitions it would break,
      hence it is a non-backwards-compatible change.

    


    

    

      

        

          

            
Removing outdated functionality is exactly what the
              status-stmt is for.

          

        

      

    

    
Agreed.

    

    


    

    

      

        

          

            
IMO we should learn to use the YANG that is already
              there.

          

        

      

    

    
We are trying to make what we have today better.

    
Specifically, so that a client can look at a semver numbers
      between two modules revisions and determine whether or not they
      might be broken by that change.

    
Today, just using the status element alone to mark removed nodes
      means that a client would have to check for all changes in the
      module between two revisions to determine whether or not the new
      module revision is backwards compatible with the old one.

    

    
Thanks,

      Rob

    


    

    

      

        

          

            
 

            

              

                
Thanks,

                  Rob

                

                


                

              

            

            


            

            
Andy

            
 

            

              

                
 

                

                  

                    

                      

                        


                        

                        


                        

                        
Andy

                        


                        

                        


                        

                        
 

                        

                          

                            
    
                            

                            
So we still need Semver(or something
                              akin) and the possibility to do NBC
                              changes.

                            
Balazs

                            

                            
On
                              2018. 11. 12. 18:08, Robert Wilton wrote:

                            

                            
 

                              

                              On 12/11/2018 16:33, Martin Bjorklund
                              wrote: 

                              
Robert Wilton <rwilton@cisco.com>
                                wrote: 

                                
In the Thursday
                                  Netmod meeting, it was interesting to
                                  hear Rob Shakir 

                                  describe how deviations and
                                  augmentations are used in OpenConfig
                                  to 

                                  add functionality into an older YANG
                                  model where the semver rules 

                                  prevent the version number from being
                                  incremented. 

                                  

                                  Further, I think that someone
                                  (Martin?) stated on the audio bridge 

                                  that this was an intended/allowed
                                  behavior for deviations. 

                                

                                I said that using augmentations (not
                                deviations) was one idea we 

                                originally had for solving the
                                "branching problem". 

                              

                              Ah, OK. I agree that makes sense. 

                              

                              
 

                                I think that this works for OC b/c they
                                don't branch their modules. 

                                Hence I think it is important that we
                                decide if branching is a 

                                requirement or not. 

                              

                              So, I think that this probably works for
                              adding enhancements, but not for the
                              (arguably more important) bug fix case,
                              unless there is a reasonable solution to
                              having two config data nodes both
                              modifying the same underlying property. 
                              Perhaps under some reasonable constraints
                              this could be made to work - but I don't
                              know. 

                              

                              Of course, even for enhancements it is not
                              necessarily a perfect solution.  E.g.
                              backporting some subset of a module
                              already coded/implemented in latest to an
                              older release.  And yes, we really do get
                              asked to do this sometimes, although it is
                              relatively rare. 

                              

                              Thanks, 

                              Rob 

                              

                              
 

                                

                                /martin 

                                

                                

                                
This surprised
                                  me, because I thought that RFC 7950
                                  was quite explicit 

                                  that this is not what deviations are
                                  intended for.  My reading of RFC 

                                  7950 is that the deviation statement
                                  represents the case where the 

                                  server *implementation* does not match
                                  the *specification*.  However, 

                                  the versioning issue that we are
                                  discussing are bug fixes/changes in 

                                  the specification rather than the bug
                                  fixes in the implementation. 

                                  

                                  Personally, I'm really not keen on
                                  using deviations to represent bug 

                                  fixes to older YANG models for three
                                  reasons: 

                                  

                                  (i) It is changing the meaning of
                                  deviation.  It is much cleaner to 

                                  keep the meaning of deviation
                                  statements as they are defined today,
                                  

                                  and not conflate their semantics. 

                                  (ii) A different mechanism is used to
                                  put a bug fix into an older 

                                  branch rather than in the head of the
                                  development. 

                                  (iii) For clients to track the
                                  lifecycle of modules they would not 

                                  only need to know the module version
                                  number but would also need to 

                                  find and track all associated
                                  deviation modules.  This seems 

                                  significantly more complex for clients
                                  than the modified semver that 

                                  was proposed. 

                                  

                                  --- 

                                  

                                  I think that has also been some
                                  suggestion that augmentations (or 

                                  duplicate YANG modules with their
                                  major version number changed) can be 

                                  used to make bug fixes in a completely
                                  backwards compatible way. 

                                  However, I still don't understand a
                                  robust scheme of how this works. 

                                  

                                  --- 

                                  

                                  Finally, there were some comments
                                  about using augmentation modules for 

                                  enhancements.  This is fine, where
                                  appropriate (e.g. a non trivial 

                                  number of data nodes are being added
                                  as an enhancement) then a 

                                  separate module may be the right way
                                  to go. But here, I presume that 

                                  the new functionality will always be
                                  tracked by that separate module. 

                                  If that functionality folds back into
                                  the original module at some 

                                  point in the future, then obviously a
                                  non backwards compatible version 

                                  change is being forced on to the
                                  client, along with additional work on
                                  

                                  the server as well. 

                                  

                                  I think that there are also many cases
                                  where the number of data nodes 

                                  being added via an enhancement is
                                  small compared to the size of the 

                                  module being updated.  In this case I
                                  believe that it better to add 

                                  these data nodes into the module
                                  itself, perhaps predicated under 

                                  if-feature if appropriate. 

                                  

                                  Thanks, 

                                  Rob 

                                  

                                  

                                  _______________________________________________
                                  

                                  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 


                                  

                           

                              _______________________________________________

                              netmod mailing list

                              netmod@ietf.org

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

                              

                            

                         

                       

                        

                  

                

              

            

          

          

        

      

    

  


--------------41375586AB8DE4B0DF9189D0--


From nobody Tue Nov 13 08:03: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 D07AF1294D7 for ; Tue, 13 Nov 2018 08:03:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.971
X-Spam-Level: 
X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 E6vD-AJxSZFc for ; Tue, 13 Nov 2018 08:03:26 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF4E128CF2 for ; Tue, 13 Nov 2018 08:03:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2120; q=dns/txt; s=iport; t=1542125005; x=1543334605; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=n+v3pmdDmjF+wcLQuwpOcXsAvsPpRQvf19OAGvfB4X8=; b=BKybca7GbpELfasBSJGYl2ZxtH588bsRwz7pP08bl1PmxvcTWtZONQU+ 8QRuNXH3Ra1Vo8qKRriIVH86pK2Fy97hLXYUdH1FTPQ6+DdYZoEKoOols 56GLEx2jsFi1xFVEQnwDhCfXhc9NNVnB62eBKp7d7HecjHPEHRaHR3xE2 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABB9Opb/49dJa1hAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYIDZoECJwqDbogYi32CDZc1gXoLAQE?= =?us-ascii?q?YC4QDRgIXgyUiNA0NAQMBAQIBAQJtHAyFOwEBBAEBIRE6Cw4CAgEIDgIIAgI?= =?us-ascii?q?mAgICGQwLFRACBAENBYMhAYIBD6gFgS+KIAUFgQaKdxeBf4ERJx+CTIMbAQG?= =?us-ascii?q?BYRcKJoI9MYImAp9WCQKRIBiQc5dWAhEUgSYdOIFVcBU7KgGCQYY7hGGFPkE?= =?us-ascii?q?xjQKBHwEB?=
X-IronPort-AV: E=Sophos;i="5.54,499,1534809600"; d="scan'208";a="201221959"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Nov 2018 16:03:24 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id wADG3OUf022685 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Nov 2018 16:03:24 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 13 Nov 2018 11:03:23 -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; Tue, 13 Nov 2018 11:03:23 -0500
From: "Acee Lindem (acee)" 
To: Juergen Schoenwaelder , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
CC: NETMOD WG 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AdR1b1B75pZToCjlLEK5aT+9YAPiFwAB1JzUACOi7oAAJMyqAAABim+AATgw44AAATEtgP//zKeA
Date: Tue, 13 Nov 2018 16:03:23 +0000
Message-ID: <091DC7F4-0C17-4E64-85B8-8963EFBC208B@cisco.com>
References:  <9C5FD3EFA72E1740A3D41BADDE0B461FCFA7803B@DGGEMM528-MBX.china.huawei.com> <20181106141613.zqy5xmq7qvahzzpz@anna.jacobs.jacobs-university.de> <9C5FD3EFA72E1740A3D41BADDE0B461FCFA78BFA@DGGEMM528-MBX.china.huawei.com> <20181107083401.7bqbjnewg3syd6dj@anna.jacobs.jacobs-university.de> <0bb4d572-3378-c46a-0802-c2c2fce7cc4e@ericsson.com> <20181113140709.vwc4f3mqmmgjaluu@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181113140709.vwc4f3mqmmgjaluu@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: <8BCF686AD1FE44428A457C32E80B512B@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.155, xch-rtp-015.cisco.com
X-Outbound-Node: rcdn-core-7.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: Tue, 13 Nov 2018 16:03:28 -0000

DQoNCu+7v09uIDExLzEzLzE4LCA5OjA3IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBKdWVyZ2Vu
IFNjaG9lbndhZWxkZXIiIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygai5z
Y2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCg0KICAgIE9uIFR1ZSwg
Tm92IDEzLCAyMDE4IGF0IDAxOjMzOjAxUE0gKzAwMDAsIEJhbMOhenMgTGVuZ3llbCB3cm90ZToN
CiAgICA+IEhlbGxvLA0KICAgID4gDQogICAgPiBJbiBzb21lIGNhc2VzIEkgd2FudCBhIHBlcmNl
bnRhZ2Ugd2l0aG91dCBmcmFjdGlvbnMuIFRoaXMgY291bGQgYmUgZGVmaW5lZA0KICAgID4gdXNp
bmcgcmFuZ2UsIGJ5IHNwZWNpZnlpbmcgdGhlIG51bWJlcnMgMCB8IDEgfCAyIC4uLiA5OSB8IDEw
MCBpbiB0aGUgcmFuZ2Uncw0KICAgID4gYXJndW1lbnQuDQogICAgPiANCiAgICA+ICAgICB0eXBl
ZGVmIHBlcmNlbnQtc2hvcnQgew0KICAgID4gICAgICAgdHlwZSBwZXJjZW50IHsgcmFuZ2UgMCB8
IDEgfCAyIC4uLiA5OSB8IDEwMDsgfSAgLy8gZGlkbid0IHR5cGUgb3V0IGFsbCB0aGUgMTAxIGlu
dGVnZXIgdmFsdWVzIDotKQ0KICAgID4gICAgIH0NCiAgICA+DQogICAgDQogICAgSSBndWVzcyB3
ZSBuZWVkIHRvIHNldHRsZSBvbiBhIHNtYWxsIG51bWJlciBvZiBwZXJjZW50YWdlIHR5cGVzIHRo
YXQNCiAgICBwZW9wbGUgZmluZCB1c2VmdWwgYW5kIHRoZW4gbW9kdWxlIGF1dGhvcnMgaG9wZWZ1
bGx5IGZpbmQgd2hhdCB0aGV5DQogICAgbmVlZC4gSSBhbSBub3Qgc3VyZSB0aGF0IGxpc3Rpbmcg
MTAxIG51bWJlcnMgaXMgYSBnb29kIHBhdHRlcm4gdG8gdXNlDQogICAgKGFsdGhvdWdoIGl0IGRv
ZXMgYWNoaWV2ZSB3aGF0IHlvdSB3YW50KS4gRm9yIHBlcmNlbnRhZ2VzIHRoYXQgaGF2ZSBubw0K
ICAgIGZyYWN0aW9uLCB5b3UgbGlrZWx5IHdhbnQgdG8gZGVyaXZlIGZyb20gYSBiYXNlIHR5cGUg
dGhhdCBpcyBlZmZpY2llbnQNCiAgICB0byBlbmNvZGUgZm9yIGJpbmFyeSBlbmNvZGluZ3Mgc3Vj
aCBhcyBDQk9SLg0KDQpPciBzaW1wbHkgZGVmaW5lIGEgdHlwZSB3aXRoIGEgYmFzZSB0eXBlIG9m
IHVuaXQ4IHR5cGUgYW5kIGEgcmFuZ2Ugb2YgMC0xMDAuIA0KDQpBY2VlIA0KDQoNCg0KDQogICAg
DQogICAgL2pzDQogICAgDQogICAgLS0gDQogICAgSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAg
ICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCiAgICBQaG9uZTogKzQ5IDQyMSAy
MDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQog
ICAgRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVu
aXZlcnNpdHkuZGUvPg0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQogICAgbmV0bW9kIG1haWxpbmcgbGlzdA0KICAgIG5ldG1vZEBpZXRm
Lm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQog
ICAgDQoNCg==


From nobody Tue Nov 13 08:19:52 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D06B128B14 for ; Tue, 13 Nov 2018 08:19:51 -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=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 uf3gBsrd7A1l for ; Tue, 13 Nov 2018 08:19:48 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF9D6128A6E for ; Tue, 13 Nov 2018 08:19:47 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id p17so9262735lfh.4 for ; Tue, 13 Nov 2018 08:19:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5KbKeviwKyWH3/thResjdMhU1YxK1V3j0DIhLRYuzFk=; b=av13KnFQxPa6ykTdOutuae0lbF9WsAyi+DNso+U1TX7jAnEPbvD6DGjD+JwzRc3Zek HVM3WXoY158uPz2O9Q63doHYzcn/QaTX/Q7qSdQBQ4EbxwINOET3g8hcKi8Llq35t9NR lx6yU6BB8/+6Yg17oJ8UAvifUp/UUDuFLpm6WtWJTJ3tbEr7ySY4rcts/Z9F02sVpkTP 0I4/6aequXEwHzsVyBJZRsQjdkd6A1iuwOhr3nb48TBBeD6Lvo81m5/taQPv7I0fypE5 boSTuG7bhFI96mQBsHLEEJHY1cryXXMfddRoNm+CfUO5yx0PV5BpCemw6pUBSXGRPAGG 1C7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5KbKeviwKyWH3/thResjdMhU1YxK1V3j0DIhLRYuzFk=; b=oaNjRf6JTHH/iUsKQiLk7HcxAu1szOr/amXjV3wHzkay/3hkeyAgR9bvJjYb0rhGoG Yo0IG6wyY6n7JJRa/Z+xBFSPpnhQYwpRRCp757izOVUDlL0CXcp6XRRLmZVZxn0ucZEG v+u64osR5Oo7qtpS6X7WFcPFLAUZLtFewpVkZJah/aH/E8R0wYar+TFBzZlyxnXpZiKh rQV8sCxAJLLjWtn2Yr9MNRubrcImVlXsOA0apEvDpPpbrLFFQnekGAuxYQo07DMXOsPv MzRUVTYWFlKk0x9BlsqZY4Eg1ONTD4fgI/RmnsK3ourgMJgW3NKUn1UTdXXoWyGYnYDx fvjg==
X-Gm-Message-State: AGRZ1gLVW5Vjw5BmRVcuTZBCrDsZzz7Qt7vrGjdobm1xV3UiZqi0gyzr cc3xxcQn1hUbleSAlOYXEHBbLNVc6o3dr7ONC702CPdcOy0=
X-Google-Smtp-Source: AJdET5dzEbGF4DLzpluAH6DKP5K0RR9WagaOkJ8L/sZQpzBH5FpxktU7Ui413OeuyVBt9wcx8/2Ap2dLpN89o+bEMHo=
X-Received: by 2002:a19:d58e:: with SMTP id m136mr3621173lfg.70.1542125985753;  Tue, 13 Nov 2018 08:19:45 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Tue, 13 Nov 2018 08:19:44 -0800 (PST)
In-Reply-To: <453368b2-aa52-f09a-ea0b-960255bce46b@cisco.com>
References:  <20181112.173351.1984161388756642220.mbj@tail-f.com>  <77b69d64-2ce2-29d9-77a9-04a7159003a9@ericsson.com>  <98d6293c-d762-4d21-a9e2-c9cb20f74135@cisco.com>  <453368b2-aa52-f09a-ea0b-960255bce46b@cisco.com>
From: Andy Bierman 
Date: Tue, 13 Nov 2018 08:19:44 -0800
Message-ID: 
To: Robert Wilton 
Cc: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= ,  Martin Bjorklund , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000948cbe057a8e2f57"
Archived-At: 
Subject: Re: [netmod] Deviations and augmentations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 16:19:51 -0000

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

On Tue, Nov 13, 2018 at 7:54 AM, Robert Wilton  wrote:

>
> On 13/11/2018 15:32, Andy Bierman wrote:
>
>
>
> On Tue, Nov 13, 2018 at 7:28 AM, Robert Wilton  wrote:
>
>>
>> On 13/11/2018 15:17, Andy Bierman wrote:
>>
>>
>>
>> On Tue, Nov 13, 2018 at 5:46 AM, Bal=C3=A1zs Lengyel <
>> balazs.lengyel@ericsson.com> wrote:
>>
>>> Hello,
>>>
>>> We also need a method for removing stuff. It does happen that some
>>> functionality is deemed not important enough, outdated, too expensive t=
o
>>> maintain, so we want to remove it.
>>>
>>>    - Augment is clearly not the tool for that.
>>>    - Deviations are not intended for that  (from rfc 7950: "server
>>>    deviation: A failure of the server ...")
>>>
>>>
>> Removing nodes is easy with the status-stmt. Update the module and set
>> the status to deprecated or obsolete.
>>
>> Yes, but obsoleting nodes should be regarded as a
>> non-backwards-compatible change because it can break clients that were
>> relying on those nodes.
>>
>
> I don't think RFC 7950 says that.
>
> RFC 7950 states '"obsolete" means that the definition is obsolete and
> SHOULD NOT be implemented and/or can be removed from implementations.'
>
> So if there was a client using those definitions it would break, hence it
> is a non-backwards-compatible change.
>
>
>
>From RFC 7950, sec 11:

   o  A "status" statement may be added, or changed from "current" to
      "deprecated" or "obsolete", or changed from "deprecated" to
      "obsolete".



> Removing outdated functionality is exactly what the status-stmt is for.
>
> Agreed.
>
>
> IMO we should learn to use the YANG that is already there.
>
> We are trying to make what we have today better.
>
> Specifically, so that a client can look at a semver numbers between two
> modules revisions and determine whether or not they might be broken by th=
at
> change.
>
> Today, just using the status element alone to mark removed nodes means
> that a client would have to check for all changes in the module between t=
wo
> revisions to determine whether or not the new module revision is backward=
s
> compatible with the old one.
>


It is quite easy to check if the status-stmt is set to deprecated or
obsolete.
SEMVER is not very useful, especially if the major version is incremented
even though there were no NBC changes.




> Thanks,
> Rob
>
>
>

Andy


>
>
>> Thanks,
>> Rob
>>
>>
>>
> Andy
>
>
>>
>>
>> Andy
>>
>>
>>
>>
>>>
>>>
>>> So we still need Semver(or something akin) and the possibility to do NB=
C
>>> changes.
>>>
>>> Balazs
>>> On 2018. 11. 12. 18:08, Robert Wilton wrote:
>>>
>>>
>>>
>>> On 12/11/2018 16:33, Martin Bjorklund wrote:
>>>
>>> Robert Wilton   wrote:
>>>
>>> In the Thursday Netmod meeting, it was interesting to hear Rob Shakir
>>> describe how deviations and augmentations are used in OpenConfig to
>>> add functionality into an older YANG model where the semver rules
>>> prevent the version number from being incremented.
>>>
>>> Further, I think that someone (Martin?) stated on the audio bridge
>>> that this was an intended/allowed behavior for deviations.
>>>
>>> I said that using augmentations (not deviations) was one idea we
>>> originally had for solving the "branching problem".
>>>
>>> Ah, OK. I agree that makes sense.
>>>
>>>
>>> I think that this works for OC b/c they don't branch their modules.
>>> Hence I think it is important that we decide if branching is a
>>> requirement or not.
>>>
>>> So, I think that this probably works for adding enhancements, but not
>>> for the (arguably more important) bug fix case, unless there is a
>>> reasonable solution to having two config data nodes both modifying the =
same
>>> underlying property.  Perhaps under some reasonable constraints this co=
uld
>>> be made to work - but I don't know.
>>>
>>> Of course, even for enhancements it is not necessarily a perfect
>>> solution.  E.g. backporting some subset of a module already
>>> coded/implemented in latest to an older release.  And yes, we really do=
 get
>>> asked to do this sometimes, although it is relatively rare.
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>>
>>> /martin
>>>
>>>
>>> This surprised me, because I thought that RFC 7950 was quite explicit
>>> that this is not what deviations are intended for.  My reading of RFC
>>> 7950 is that the deviation statement represents the case where the
>>> server *implementation* does not match the *specification*.  However,
>>> the versioning issue that we are discussing are bug fixes/changes in
>>> the specification rather than the bug fixes in the implementation.
>>>
>>> Personally, I'm really not keen on using deviations to represent bug
>>> fixes to older YANG models for three reasons:
>>>
>>> (i) It is changing the meaning of deviation.  It is much cleaner to
>>> keep the meaning of deviation statements as they are defined today,
>>> and not conflate their semantics.
>>> (ii) A different mechanism is used to put a bug fix into an older
>>> branch rather than in the head of the development.
>>> (iii) For clients to track the lifecycle of modules they would not
>>> only need to know the module version number but would also need to
>>> find and track all associated deviation modules.  This seems
>>> significantly more complex for clients than the modified semver that
>>> was proposed.
>>>
>>> ---
>>>
>>> I think that has also been some suggestion that augmentations (or
>>> duplicate YANG modules with their major version number changed) can be
>>> used to make bug fixes in a completely backwards compatible way.
>>> However, I still don't understand a robust scheme of how this works.
>>>
>>> ---
>>>
>>> Finally, there were some comments about using augmentation modules for
>>> enhancements.  This is fine, where appropriate (e.g. a non trivial
>>> number of data nodes are being added as an enhancement) then a
>>> separate module may be the right way to go. But here, I presume that
>>> the new functionality will always be tracked by that separate module.
>>> If that functionality folds back into the original module at some
>>> point in the future, then obviously a non backwards compatible version
>>> change is being forced on to the client, along with additional work on
>>> the server as well.
>>>
>>> I think that there are also many cases where the number of data nodes
>>> being added via an enhancement is small compared to the size of the
>>> module being updated.  In this case I believe that it better to add
>>> these data nodes into the module itself, perhaps predicated under
>>> if-feature if appropriate.
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>>
>>
>

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




On Tue, Nov 13, 2018 at 7:54 AM, Robert Wilton <rwilt=
on@cisco.com> wrote:

 =20
   =20
 =20
  

    


    

    
On 13/11/2018=
 15:32, Andy Bierman
      wrote:

    

    

     =20
      


        


          
On Tue, Nov 13, 2018 at 7:28 AM,
            Robert Wilton <rwilton@cisco.com>
            wrote:

            

              

                


                

                
On
                  13/11/2018 15:17, Andy Bierman wrote:

                

                

                  


                    


                      
On Tue, Nov 13, 2018 at
                        5:46 AM, Bal=C3=A1zs Lengyel <=
balazs.len=
gyel@ericsson.com>
                        wrote:

                        

                          

                            
Hello,

                            
We also need a method for removing stuff.
                              It does happen that some functionality is
                              deemed not important enough, outdated, too
                              expensive to maintain, so we want to
                              remove it. 

                            

                            
    
                              
  • Augment is clearly not the tool for
                                that.
    • 
                              
  • Deviations are not intended for that=C2=
=A0
                                (from rfc 7950: "server deviation: A
                                failure of the server ...")
    • 
                            

                          

                        

                        


                        

                        
Removing nodes is easy with the
                          status-stmt. Update the module and set the
                          status to deprecated or obsolete.

                      

                    

                  

                

                
Yes, but obsoleting nodes should be regarded as a
                  non-backwards-compatible change because it can break
                  clients that were relying on those nodes.

              

            

            


            

            
I don't think RFC 7950 says that.

          

        

      

    

    
RFC 7950 states '"obsolete" means that the definiti=
on is obsolete and SHOULD NOT be
      implemented and/or can be removed from implementations.'
    

    
So if there was a client using those definitions it would break,
      hence it is a non-backwards-compatible change.

    


From RFC 7950, sec 11=
:

   o  A "status" statement may be added, or =
changed from "current" to
      "deprecated" or "obsolete", or changed from "=
;deprecated" to
      "obsolete".

=C2=A0

    

    

      

        

          

            
Removing outdated functionality is exactly what the
              status-stmt is for.

          

        

      

    

    
Agreed.

    

    


    

    

      

        

          

            
IMO we should learn to use the YANG that is already
              there.

          

        

      

    

    
We are trying to make what we have today better.

    
Specifically, so that a client can look at a semver numbers
      between two modules revisions and determine whether or not they
      might be broken by that change.

    
Today, just using the status element alone to mark removed nodes
      means that a client would have to check for all changes in the
      module between two revisions to determine whether or not the new
      module revision is backwards compatible with the old one.


It is quite easy to check=
 if the status-stmt is set to deprecated or obsolete.
SEMVER is n=
ot very useful, especially if the major version is incremented
ev=
en though there were no NBC changes.


=C2=A0

    

    
Thanks,

      Rob

    



Andy
=C2=A0

    

    

      

        

          

            
=C2=A0

            

              

                
Thanks,

                  Rob

                

                


                

              

            

            


            

            
Andy

            
=C2=A0

            

              

                
 

                

                  

                    

                      

                        


                        

                        


                        

                        
Andy

                        


                        

                        


                        

                        
=C2=A0

                        

                          

                            
    
                            

                            
So we still need Semver(or something
                              akin) and the possibility to do NBC
                              changes.

                            
Balazs

                            

                            
On
                              2018. 11. 12. 18:08, Robert Wilton wrote:

                            

                            
 

                              

                              On 12/11/2018 16:33, Martin Bjorklund
                              wrote: 

                              
Robert Wilton <rwilton@cisco.com>
                                wrote: 

                                
In the Thursday
                                  Netmod meeting, it was interesting to
                                  hear Rob Shakir 

                                  describe how deviations and
                                  augmentations are used in OpenConfig
                                  to 

                                  add functionality into an older YANG
                                  model where the semver rules 

                                  prevent the version number from being
                                  incremented. 

                                  

                                  Further, I think that someone
                                  (Martin?) stated on the audio bridge 

                                  that this was an intended/allowed
                                  behavior for deviations. 

                                

                                I said that using augmentations (not
                                deviations) was one idea we 

                                originally had for solving the
                                "branching problem". 

                              

                              Ah, OK. I agree that makes sense. 

                              

                              
 

                                I think that this works for OC b/c they
                                don't branch their modules. 

                                Hence I think it is important that we
                                decide if branching is a 

                                requirement or not. 

                              

                              So, I think that this probably works for
                              adding enhancements, but not for the
                              (arguably more important) bug fix case,
                              unless there is a reasonable solution to
                              having two config data nodes both
                              modifying the same underlying property.=C2=A0
                              Perhaps under some reasonable constraints
                              this could be made to work - but I don't
                              know. 

                              

                              Of course, even for enhancements it is not
                              necessarily a perfect solution.=C2=A0 E.g.
                              backporting some subset of a module
                              already coded/implemented in latest to an
                              older release.=C2=A0 And yes, we really do ge=
t
                              asked to do this sometimes, although it is
                              relatively rare. 

                              

                              Thanks, 

                              Rob 

                              

                              
 

                                

                                /martin 

                                

                                

                                
This surprised
                                  me, because I thought that RFC 7950
                                  was quite explicit 

                                  that this is not what deviations are
                                  intended for.=C2=A0 My reading of RFC 
                                  7950 is that the deviation statement
                                  represents the case where the 

                                  server *implementation* does not match
                                  the *specification*.=C2=A0 However, 

                                  the versioning issue that we are
                                  discussing are bug fixes/changes in 

                                  the specification rather than the bug
                                  fixes in the implementation. 

                                  

                                  Personally, I'm really not keen on
                                  using deviations to represent bug 

                                  fixes to older YANG models for three
                                  reasons: 

                                  

                                  (i) It is changing the meaning of
                                  deviation.=C2=A0 It is much cleaner to 
                                  keep the meaning of deviation
                                  statements as they are defined today,
                                  

                                  and not conflate their semantics. 

                                  (ii) A different mechanism is used to
                                  put a bug fix into an older 

                                  branch rather than in the head of the
                                  development. 

                                  (iii) For clients to track the
                                  lifecycle of modules they would not 

                                  only need to know the module version
                                  number but would also need to 

                                  find and track all associated
                                  deviation modules.=C2=A0 This seems 

                                  significantly more complex for clients
                                  than the modified semver that 

                                  was proposed. 

                                  

                                  --- 

                                  

                                  I think that has also been some
                                  suggestion that augmentations (or 

                                  duplicate YANG modules with their
                                  major version number changed) can be 

                                  used to make bug fixes in a completely
                                  backwards compatible way. 

                                  However, I still don't understand a
                                  robust scheme of how this works. 

                                  

                                  --- 

                                  

                                  Finally, there were some comments
                                  about using augmentation modules for 

                                  enhancements.=C2=A0 This is fine, where
                                  appropriate (e.g. a non trivial 

                                  number of data nodes are being added
                                  as an enhancement) then a 

                                  separate module may be the right way
                                  to go. But here, I presume that 

                                  the new functionality will always be
                                  tracked by that separate module. 

                                  If that functionality folds back into
                                  the original module at some 

                                  point in the future, then obviously a
                                  non backwards compatible version 

                                  change is being forced on to the
                                  client, along with additional work on
                                  

                                  the server as well. 

                                  

                                  I think that there are also many cases
                                  where the number of data nodes 

                                  being added via an enhancement is
                                  small compared to the size of the 

                                  module being updated.=C2=A0 In this case =
I
                                  believe that it better to add 

                                  these data nodes into the module
                                  itself, perhaps predicated under 

                                  if-feature if appropriate. 

                                  

                                  Thanks, 

                                  Rob 

                                  

                                  

                                  ____________________________________=
___________
                                  

                                  netmod mailing list 

                                  netmod@ietf.org
                                  

                                  https://www.ie=
tf.org/mailman/listinfo/netmod
                                  

                                

                                . 

                                

                              

                              

                              ________________________________________=
_______
                              

                              netmod mailing list 

                              netmod@ietf.org
                              

                              https://www.ietf.o=
rg/mailman/listinfo/netmod
                              

                              
                                   

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


                                  

                           

                              ________________________________________=
_______

                              netmod mailing list

                              netmod@ietf.org

                              https://www.ietf.org/mailm=
an/listinfo/netmod

                              

                            

                        <=
font color=3D"#888888"> 

                       

                        

                  

                

              

            

          

          

        

      

    

  






--000000000000948cbe057a8e2f57--


From nobody Tue Nov 13 08:54:34 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D85F128B14 for ; Tue, 13 Nov 2018 08:54:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.971
X-Spam-Level: 
X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 JrA3hS9pgnVb for ; Tue, 13 Nov 2018 08:54:29 -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 2C2E9127333 for ; Tue, 13 Nov 2018 08:54:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7590; q=dns/txt; s=iport; t=1542128069; x=1543337669; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=sSourWOTM5qw/lKJwXiaFKTnm67rUjQXCO+OcVgbqHE=; b=h3xNJgBsVb22TGearbxDpiWcDH/IkgORICUSkPQ3YZuCQjrKyXeOmX9t x3twrdz1SBr52nuBIhTwVrGoLodAgIngC9ze+mDrZrXf8M7C+f/bLzNDR as+qt9259pkLPwWHQnrnh+I9l2IaPJ56TAm/qrIqIxf39yg/hHlpJyc1S w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAABUAOtb/xbLJq1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGCaU8hEieDeIgYX40GJZc1FIFmDRgLhEkCg14?= =?us-ascii?q?0DQ0BAwEBAgEBAm0cDIU6AQEBAwEBASEPAQURBSsMBAkCDgMEAQEBAgIfBAM?= =?us-ascii?q?CAigJFQkIBQEBDAYCAQEZBIMAAYF5CA+MT5tQgS+EAgEuAgKBC4RlgQuHKYI?= =?us-ascii?q?xgTSBQD+BEScMgg8iLoFBgSAvCwEBAQKBJgUBCwYCAQYYgwSCVwKJIIt+ijg?= =?us-ascii?q?JhneGFDODXgYYgVgihGKCfCaEC4JqgnSGZoNOg3yECIJRgUM4ZHEzGggbFTu?= =?us-ascii?q?CbAmCKh2ITIUIATU/AzABi1OCTQEB?=
X-IronPort-AV: E=Sophos;i="5.56,228,1539648000";  d="scan'208";a="7962396"
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; 13 Nov 2018 16:54:26 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id wADGsPsK004963; Tue, 13 Nov 2018 16:54:25 GMT
To: Lou Berger , John Messenger , "Holness, Marc" , "STDS-802-1-L@LISTSERV.IEEE.ORG" , "netmod@ietf.org" 
References: <14a5c6fd-b24a-9669-7701-75dd822f95e2@cisco.com> <9485c56783074f19b4fbf357e5e82946@advaoptical.com> 
From: Robert Wilton 
Message-ID: <6475190b-3e7b-bf8c-5536-3a9cc10c8436@cisco.com>
Date: Tue, 13 Nov 2018 16:54:24 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: 
Subject: Re: [netmod] [802.1 - 12909] IETF Sub-interface VLAN YANG Data Models - draft-ietf-netmod-sub-intf-vlan-model-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 16:54:33 -0000

Hi John, Lou,

Thank you both for your comments and helping to get the necessary 
visibility and review from 802.1 WG.

On 13/11/2018 07:03, Lou Berger wrote:
> Hi John,
>
>     Thank you (and Janos, the group) for the agenda time and the 
> message.  There was also a request for a single c-type vlan example.  
> I see that there is already one on page 22 as part of the match 
> container.

I will add an explicit example for a single tag L3 sub-interface c-vlan 
match as well.

>
> See below for inline responses.
>
> Rob/WG,
>     The plan is to address the comments raised in this mail, update 
> the draft and then go to LC.  Please note that the document status 
> should be changed Informational to Standards Track.

OK.


>
> On 11/13/2018 11:55 AM, John Messenger wrote:
>> Hi,
>>
>> At the 802.1 TSN meeting this morning, Lou Berger made a presentation 
>> on behalf of Rob Wilton summarising the recent changes in this 
>> draft.  I like the changes to the structure which are intended to 
>> align the VLAN tag structure to that specified in 802.1Q.  I notice 
>> that the draft retains clause 2.2 (Extensibility) but I think that's 
>> a bug, because it's not reflected in the model (which is a fixed 
>> structure of one or two tags).
> I agree.

I agree, I think that this section can be deleted.


>> Right now, it says that the Ethertypes are taken from 
>> dot1q-tag-type.  Would this allow tags other than 802.1QTagType 
>> (81-00) and 802.1QSTagType (88-A8)?  That shouldn't be allowed.
> I read this as just trying to use the IEEE defined types.  We 
> certainly can restrict this to just c-vlan and s-vlan values, but 
> perhaps you want to consider defining an enumeration for this case 
> (valid-qtag-types).
>
> Rob (wg)
>
>     Do you see any issue with restricting tag-types to 
> dot1q-types:c-vlan and dot1q-types:s-vlan?
I quite like the model being tied to the IEEE defined type and 
associated identities, that only currently defines "c-vlan" and 
"s-vlan".  However, since they are identities it is possible for anyone 
to augment new identities in new YANG modules.

We could block other types by using must statements.  In fact, in the 
case that they are double tagged then the model already enforces that 
outer-tag is s-vlan and inner-tag is c-vlan.  So covering the single tag 
case also makes sense.


>
>> My preference would be to remove the forward-looking statement quoted 
>> here because it implies a willingness to extend to 3 tags:
>>     The structure of the model is currently limited to matching or
>>     rewriting a maximum of two 802.1Q tags in the frame header but has
>>     been designed to be easily extensible to matching/rewriting three or
>>     more VLAN tags in future, if required.
>
> sure. (at least from my perspective.)

Agreed.  This statement is now wrong and should be removed.


>
>> It looks like you could parse an untagged frame as either :(untagged) 
>> or :(dot1q-vlan-tagged) (without either of the optional tags).  Is 
>> that a bug?

Yes, that is a bug.  I will fix this.  dot1q-vlan-tagged should only be 
allowed to match on outer-tag or outer-tag & second-tag.  So, I probably 
need to mark outer-tag as mandatory.

Thanks again for your help.

I'll post an updated draft shortly.

Thanks,
Rob


>
> I may be missing something, but I think you're right - i,e., why would 
> dot1q-vlan-tagged be present without an outer-tag, but I may be 
> missing something...
>
> Thanks again.
>
> Lou
>
>> Thanks,
>>     -- John
>>
>> -----Original Message-----
>> From: List HELP only  On Behalf Of Robert 
>> Wilton
>> Sent: 05 November 2018 16:16
>> To: STDS-802-1-L@LISTSERV.IEEE.ORG
>> Subject: [802.1 - 12909] IETF Sub-interface VLAN YANG Data Models - 
>> draft-ietf-netmod-sub-intf-vlan-model-04
>>
>> Ballot due Nov. 6: P802.1Qcx/D0.4
>> For particulars see
>>    https://1.ieee802.org/active-ballots/
>> 802.1 list help: https://1.ieee802.org/email-lists/
>> List archives (access-controlled) by date:
>>                 www.ieee802.org/1/private/email2/mail1.html
>> -----
>>
>> Dear esteemed 802.1 WG members,
>>
>> A few years back, at the start of my IETF and IEEE standards journey 
>> I wrote a draft defining a sub-interface based VLAN termination YANG 
>> model.  After discussion and presentations in both IETF NETMOD WG and 
>> IEEE 802.1 WG, there was a general agreement that it would be 
>> acceptable for IETF to publish this YANG model as an informational 
>> RFC, with the acknowledgement that 802.1Q VLAN technology is owned by 
>> IEEE, and in future the IEEE 802.1 WG may choose to publish a VLAN 
>> termination model.
>>
>> As part of that IETF NETMOD WG process, and after IEEE 802.1 WG had 
>> reviewed the model, I made a small change in structure of the YANG 
>> model with the sole aim of making the model simpler to use. In 
>> particular, the older model required a slightly clunky indexed list 
>> of VLAN tags, and that is replaced with a simpler structure 
>> supporting two explicit named VLAN tags ('outer-tag' and 
>> 'second-tag').  A while back, Glenn requested that I pass these 
>> changes by the IEEE 802.1 WG to ensure that the changes are 
>> acceptable to the IEEE 802.1 WG, hence this email.
>>
>> The change is perhaps best illustrated via the following change in 
>> the YANG tree output.
>>
>> The*older format* of the YANG model (that members of the 802.1Q WG 
>> previously saw) was like this:
>>
>> *if-cmn:encaps-type: +--:(vlan) +--rw vlan +--rw tags +--rw tag* [index]
>> +--rw index uint8 +--rw dot1q-tag +--rw tag-type dot1q-tag-type +--rw
>> vlan-id dot1q-vlan-id*
>>
>> The *updated format *of YANG model in the current draft is like this:
>>
>>          +--:(dot1q-vlan)
>>             +--rw dot1q-vlan
>>                +--rw outer-tag!
>>                |  +--rw tag-type    dot1q-tag-type
>>                |  +--rw vlan-id     ieee:vlanid
>>                +--rw second-tag!
>>                   +--rw tag-type    dot1q-tag-type
>>                   +--rw vlan-id     ieee:vlanid
>>
>> The same equivalent change has been made for L2 sub-interfaces as well.
>>
>> The latest internet draft is
>> https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model-04
>>
>> In particular, it may also be useful to look at the instance data
>> examples in chapter 7, that give a couple of examples of how the YANG
>> model is expected to be used both for L3 termination, and also when used
>> in conjunction with the IETF L2VPN YANG model to provision a
>> point-to-point L2 service.
>>
>> I hope to submit this draft to the NETMOD WG chairs for WG last call
>> after the current IETF 103 meeting.  So if anyone has any concerns then
>> please may I ask that you raise them.  ideally I would like to get them
>> informally addressed before this document progresses. Alternatively if
>> you need more time to review this change, or need this as a formal
>> liaison then please let me know, and I'll do my best.
>>
>> Thank you for your time,
>> Rob Wilton
>>
>>
>> ===
>> Unsubscribe link: mailto:STDS-802-1-L-SIGNOFF-REQUEST@LISTSERV.IEEE.ORG
>> IEEE. Fostering technological innovation and excellence for the 
>> benefit of humanity.
> .
>


From nobody Tue Nov 13 09:07: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 33070128CF2 for ; Tue, 13 Nov 2018 09:06: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, 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 ycf6kTYcqFoO for ; Tue, 13 Nov 2018 09:06:57 -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 C5746127332 for ; Tue, 13 Nov 2018 09:06:56 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 91031E50; Tue, 13 Nov 2018 18:06:54 +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 OowfQZwgEzcP; Tue, 13 Nov 2018 18:06:54 +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, 13 Nov 2018 18:06:54 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 78B2820046; Tue, 13 Nov 2018 18:06:54 +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 keqyG1Bu5fjg; Tue, 13 Nov 2018 18:06:54 +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 0A0CC2003D; Tue, 13 Nov 2018 18:06:53 +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, 13 Nov 2018 18:06:53 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 37F713004107E0; Tue, 13 Nov 2018 18:06:52 +0100 (CET)
Date: Tue, 13 Nov 2018 18:06:52 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
CC: Andy Bierman , "netmod@ietf.org" 
Message-ID: <20181113170652.intfq37w6rxyw4rq@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Andy Bierman , "netmod@ietf.org" 
References:  <20181112.173351.1984161388756642220.mbj@tail-f.com>  <77b69d64-2ce2-29d9-77a9-04a7159003a9@ericsson.com>  <98d6293c-d762-4d21-a9e2-c9cb20f74135@cisco.com>  <453368b2-aa52-f09a-ea0b-960255bce46b@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <453368b2-aa52-f09a-ea0b-960255bce46b@cisco.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Deviations and augmentations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 17:06:59 -0000

On Tue, Nov 13, 2018 at 03:54:11PM +0000, Robert Wilton wrote:

> Today, just using the status element alone to mark removed nodes means that
> a client would have to check for all changes in the module between two
> revisions to determine whether or not the new module revision is backwards
> compatible with the old one.

A client needs to know whether it is _affected_ by changes. This
requires to match what is used by a client against what has been
changed (including any changed deviations). A three digit number
simply does not tell you that.


Corner cases:

- An implementation claims to support the latest semver but then
  deviates things back to an earlier version.

- An implementation claims to support an earlier semver but then
  deviates things forward to a more recent version.

Of course, nobody would do that...


My point is that semver is _at best_ a hint whether there is a version
mismatch potentially affecting a client. It is not sufficient to
determine whether there is indeed a problem.

In other words, robust automation requires to match what is used by a
client against what has been updated (taking deviations into account
during the comparison).

/js

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


From nobody Tue Nov 13 09:54:35 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE39F1294D0 for ; Tue, 13 Nov 2018 09:54:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.971
X-Spam-Level: 
X-Spam-Status: No, score=-14.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 eMoWm7uOotce for ; Tue, 13 Nov 2018 09:54:31 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A956128B14 for ; Tue, 13 Nov 2018 09:54:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2690; q=dns/txt; s=iport; t=1542131671; x=1543341271; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Gl0ylIVLDleS+RVo0owjGfmGbBtBs7PAfjIhenD1phc=; b=SgTAAEdoExE4jZ1vIHHZh8msWZHH+VblPXh8G84+Q0akYnushthimYzd gZQachB/Ujom+hAaStvsoG975mQZcRXHfTTUmltkjJxETx5N1k8kjiOmU SZC+fwaCWjib93+wTFFOjz8RkXevdDqgRWcm5lU4jaG7C7Otq1820fF28 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAABjDutb/xbLJq1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgzghEoQfiHeNBiWXSYFmDYRsAoNeNwo?= =?us-ascii?q?NAQMBAQIBAQJtKIU7AQUjDwEFUQsYAgIRFQICVwYBDAgBAReDBoICqEWBL4V?= =?us-ascii?q?AhGOBC4sOgUA/gTgMgl+EOS1XgkWCVwKJQJYWCZEcBhiJWIcbkSSGWYFZIoF?= =?us-ascii?q?VMxoIGxWDKJBZPwOOUQEB?=
X-IronPort-AV: E=Sophos;i="5.56,228,1539648000";  d="scan'208";a="8020042"
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; 13 Nov 2018 17:54:29 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id wADHsRL0029817; Tue, 13 Nov 2018 17:54:27 GMT
To: Andy Bierman , "netmod@ietf.org" 
References:  <20181112.173351.1984161388756642220.mbj@tail-f.com>  <77b69d64-2ce2-29d9-77a9-04a7159003a9@ericsson.com>  <98d6293c-d762-4d21-a9e2-c9cb20f74135@cisco.com>  <453368b2-aa52-f09a-ea0b-960255bce46b@cisco.com> <20181113170652.intfq37w6rxyw4rq@anna.jacobs.jacobs-university.de>
From: Robert Wilton 
Message-ID: 
Date: Tue, 13 Nov 2018 17:54:27 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <20181113170652.intfq37w6rxyw4rq@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.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
Subject: Re: [netmod] Deviations and augmentations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 17:54:34 -0000

On 13/11/2018 17:06, Juergen Schoenwaelder wrote:
> On Tue, Nov 13, 2018 at 03:54:11PM +0000, Robert Wilton wrote:
>
>> Today, just using the status element alone to mark removed nodes means that
>> a client would have to check for all changes in the module between two
>> revisions to determine whether or not the new module revision is backwards
>> compatible with the old one.
> A client needs to know whether it is _affected_ by changes. This
> requires to match what is used by a client against what has been
> changed (including any changed deviations). A three digit number
> simply does not tell you that.
>
> 
> Corner cases:
>
> - An implementation claims to support the latest semver but then
>    deviates things back to an earlier version.
>
> - An implementation claims to support an earlier semver but then
>    deviates things forward to a more recent version.
>
> Of course, nobody would do that...
> 
>
> My point is that semver is _at best_ a hint whether there is a version
> mismatch potentially affecting a client. It is not sufficient to
> determine whether there is indeed a problem.
>
> In other words, robust automation requires to match what is used by a
> client against what has been updated (taking deviations into account
> during the comparison).

I don't disagree with any of this, I'm also a proponent of a schema 
comparison tool.

I think that my main point regarding version numbers is:

  - If we are going to use semver then we should define and follow the 
rules strictly.  I.e. assuming that the semver has been populated 
correctly then it should be possible to determine whether the change is 
a nbc, bc, or editorial change.  I think that a solution where semver is 
done in a half-hearted way is entirely useless (e.g. if clients cannot 
trust the version number).  I think that there is a pretty clear 
requirement to support NBC changes to older revisions (i.e. I really 
mean bug fixes but a looser interpretation than your definition), and 
hence I don't think that vanilla semver is sufficient.

- An alternative is to not use a semver version number at all, instead 
we define a non semantic 3 digit version number that is something like:

  major = significant changes to the module have been made
  minor = smaller changes/feature enhancements to the module have been made
  patch = a bug fix to the module has been made.

Clients, module readers, etc, and then required to use a schema 
comparison tool to determine what the actual changes between two 
revisions are and whether or not they will be broken by those changes.

Thanks,
Rob


>
> /js
>


From nobody Tue Nov 13 10:26:35 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD73130E78 for ; Tue, 13 Nov 2018 10:26:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Yfvm3q2NNCCV for ; Tue, 13 Nov 2018 10:26:25 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7150130E3F for ; Tue, 13 Nov 2018 10:26:24 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 5BE0EEF9; Tue, 13 Nov 2018 19:26:23 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 1rkyJ4DVwC_r; Tue, 13 Nov 2018 19:26:23 +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, 13 Nov 2018 19:26:23 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 43E172003D; Tue, 13 Nov 2018 19:26:23 +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 tLks4tC3w91W; Tue, 13 Nov 2018 19:26:22 +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 AE1742003C; Tue, 13 Nov 2018 19:26:22 +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, 13 Nov 2018 19:26:22 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 8CEA6300410A0F; Tue, 13 Nov 2018 19:26:21 +0100 (CET)
Date: Tue, 13 Nov 2018 19:26:21 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
CC: Andy Bierman , "netmod@ietf.org" 
Message-ID: <20181113182621.vixdnijldgs7pmtj@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Andy Bierman , "netmod@ietf.org" 
References:  <20181112.173351.1984161388756642220.mbj@tail-f.com>  <77b69d64-2ce2-29d9-77a9-04a7159003a9@ericsson.com>  <98d6293c-d762-4d21-a9e2-c9cb20f74135@cisco.com>  <453368b2-aa52-f09a-ea0b-960255bce46b@cisco.com> <20181113170652.intfq37w6rxyw4rq@anna.jacobs.jacobs-university.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Deviations and augmentations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 18:26:33 -0000

On Tue, Nov 13, 2018 at 05:54:27PM +0000, Robert Wilton wrote:
> 
> 
> I think that my main point regarding version numbers is:
> 
> - If we are going to use semver then we should define and follow the rules
> strictly. I.e. assuming that the semver has been populated correctly then
> it should be possible to determine whether the change is a nbc, bc, or
> editorial change. I think that a solution where semver is done in a
> half-hearted way is entirely useless (e.g. if clients cannot trust the
> version number). I think that there is a pretty clear requirement to
> support NBC changes to older revisions (i.e. I really mean bug fixes but a
> looser interpretation than your definition), and hence I don't think that
> vanilla semver is sufficient.

But even if you make the 'YANG world' use semvers correctly (not sure
how you want to achieve that but lets pretend you manage), then the
three digit number does not tell a client whether it will work or not.
What should a client do if semver indicate nbc? What should it do if
semver indicates bc? What should it do if semver indicates editorial
change? Where is the "protocol specification" for this?
 
> - An alternative is to not use a semver version number at all, instead we
> define a non semantic 3 digit version number that is something like:
> 
> major = significant changes to the module have been made
> minor = smaller changes/feature enhancements to the module have been made
> patch = a bug fix to the module has been made.
> 
> Clients, module readers, etc, and then required to use a schema comparison
> tool to determine what the actual changes between two revisions are and
> whether or not they will be broken by those changes.

The only robust solution is schema comparison and we may think about
what kind of annotations make such schema comparisons easier or faster
or how we can help clients to adapt (e.g., providing pointers where
definitions have moved, providing machine readable information
allowing tools to track which modules replace others etc.).

/js

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


From nobody Tue Nov 13 13:05: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 7B740130DE0; Tue, 13 Nov 2018 13:05:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yse4tg6gTYde; Tue, 13 Nov 2018 13:05:17 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFE0130DE7; Tue, 13 Nov 2018 13:05:14 -0800 (PST)
Received: from [192.168.2.5] (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 37B6B600C1; Tue, 13 Nov 2018 21:05:13 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Christian Hopps 
In-Reply-To: 
Date: Tue, 13 Nov 2018 16:05:11 -0500
Cc: Christian Hopps , joel jaeggli , NETMOD Working Group , draft-ietf-netmod-module-tags.authors@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com> 
To: Robert Wilton 
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: 
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 21:05:20 -0000

The servers implement the modules which can have predefined tags from =
the module designer as well as the implementer (vendor) which literally =
cannot come from anywhere *but* the server that implements the module.

This is not what I thought would hold this work up.

Thanks,
Chris.

> On Nov 13, 2018, at 5:58 AM, Robert Wilton  wrote:
>=20
> Hi Joel, authors,
>=20
> I have to confess that I didn't have time to review this during the =
last call (but have reviewed/provided comments on previous versions).
>=20
> These comments may be too late, but I will provide them anyway, so =
make of them what you will :-)
>=20
> In summary, I like the idea of tags and I think that they are a good =
fit for classifying YANG models.  In particular, I think that a flexible =
classification of YANG modules is better than a rigid structure that can =
never be changed.
>=20
> For me the one of the great utilities of module tags could be in =
applications like YANG catalog search =
(https://yangcatalog.org/yang-search/).  Being able to search for =
modules by tag seems like it would be a particularly useful thing to be =
able to do.
>=20
> However, I do have some sympathy with Alex's comment, in that it is a =
bit unclear as to benefits of configuring the tag information on the =
devices.  At the moment, the configuration doesn't have any material =
affect on the device, and the only thing that a client can do is read =
back the tag configuration.  Is the intention that the protocols may be =
extended in future to allow filter queries to be based on module tags?
>=20
> So, I am supportive of Alex's comment that it would give the document =
more clarity if some of the specific use cases could be described.
>=20
>=20
> Some other random comments/nits:
>=20
> 1) 6087bis references can be updated to RFC 8407.  Is a reference even =
allowed in the abstract?
>=20
> 2) Abstract: "writing a modules tags" =3D> "writing a module's tags" =
or "writing module tags"
>=20
> 3) The module is YANG 1.1, so RFC 6020 reference can be changed to RFC =
7950.
>=20
> 4) Section 3.4: Should there be a tag prefix for "experimental"? Or =
perhaps this would be "ietf:experimental:" anyway.
>=20
> 5) Section 5.1: It might be useful if the tags were also reported =
under YANG library, e.g. as an augmentation to rfc7895bis.  E.g. this =
would report the same information as "modules-tags/module[name]/tag" =
leaf-list.
>=20
> 6) YANG module: Should you limit the maximum size of a tag? Perhaps to =
255, or 1000 characters.
>=20
> 7) Line length for "The operational view of this list is constructed =
..." looks like it may be too long.
>=20
> 8) Section 7, Guidelines to authors.  I was wondering if this section =
should state that YANG modules SHOULD define standard tags that are =
associated with it.  At the moment, it just states what can be done, =
without providing guidance of what should be done.
>=20
> 9) Section 9.2.  A few more possible categories: discovery protocol, =
vpn, tunnel.  I'm not sure that I particularly like "rfc8199-" as a =
module name, and possibly "classification-" would be better.
>=20
> Apologies for the tardy review comments,
> Rob
>=20
>=20
> On 12/11/2018 16:46, joel jaeggli wrote:
>> During the Thursday nov 8 session of netmod, we asked if there were =
any objections to the publication of the Draft-03 version of =
draft-ietf-netmod-module-tags which addresses comments and concerns =
raised during the WGLC. In the meeting there were none. This commences a =
comment period to confirm that call. As this follows closely on the =
heels of the IETF 103 meeting we=E2=80=99ll let the call run through =
Monday the 26th of November.
>>=20
>> =
https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-module-tags-03.txt=

>>=20
>>=20
>> Thanks
>> Joel
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Nov 13 13:27: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 B0520130E08 for ; Tue, 13 Nov 2018 13:27:44 -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=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 NDYDwVH82RzU for ; Tue, 13 Nov 2018 13:27:41 -0800 (PST)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5FFF130E0A for ; Tue, 13 Nov 2018 13:27:40 -0800 (PST)
Received: by mail-lj1-x235.google.com with SMTP id t9-v6so12210448ljh.6 for ; Tue, 13 Nov 2018 13:27:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1XwFW6NrfwRcyL4Tnhq34FGrpbUsz0FAEEeJgv69wxc=; b=NfNr5GKwCuPQhfuZMjbTc0r+qZ4lqLdkXV3oVcrPyd8IdZgslmbOSKq11gGdFgU9Pe +8DU6d+O6hOvufJRt9fRkgc2OYbq3CwEECuPYmPJGQ5wLYTdQ5N02Dy5mn8u/WB0Dhjp wqkx+SWiOJE4ZucW5uwBDqJvyHl+R+A8d0e2XIq+0LA7t5odrC5anp7jI6VDo+7rs03h Lxl6t6DzpcdYhwKbvo2oqryadiBZ6qIVHhV7RKgyS9i+db6HpdOnxhp6frmq63SeTVdm se+sWUh3x8QGNdogzPibbogNPkessQBWtQI8ANQ63pt/u04q40FJ9T8hlzyZMBhS0X90 8ubQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1XwFW6NrfwRcyL4Tnhq34FGrpbUsz0FAEEeJgv69wxc=; b=cMgr2g8+XC6UJKxBHkBUAy1+lzKj/8YafFNn0l0Z2bTpsJz+tV6MRIVmbMKXjlOjLg O8afCZHjZhBY4n0gvl3Haops9+GPVG1oL1IzrjyC+qxO5EHSigBwNDEyQpJr6ubbJ57m qIJjBo3c0SSrJApYt5V/4ApeHnbLGk4tMXtRL0xq37au7hYkSu+NYH4i5FDzkTbnsLEH YdrczR6ca9P0sZqg3O3I4wsIsz9OmHB/mWISvo8Md+11rp0Q9ng9IVJ1EjOBFiFOcaYL aO/xorr18MTGRumofu8qYkY2d5uWkF5uleOa2DR/uPhX3BOe09UXqqpnKjxEry76H6F5 syTA==
X-Gm-Message-State: AGRZ1gITYedHKsCnq88JNHz9Zpgmlz2TJhbmDRLyo3w+qJzcMdYRaZsv 9D4jXr01SVlChQhsv5L9Dk8ans+13WewpkfGIwDiCA==
X-Google-Smtp-Source: AJdET5e7+OR0+cnHuzRIfQi7j17KSgJhDS3mq+cL8G2FgB50hr4lzycdGaIIRaJ+LOs+a085PVyl34PRUYbwACcAGks=
X-Received: by 2002:a2e:2019:: with SMTP id g25-v6mr3921907ljg.20.1542144458674;  Tue, 13 Nov 2018 13:27:38 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a19:1f87:0:0:0:0:0 with HTTP; Tue, 13 Nov 2018 13:27:37 -0800 (PST)
In-Reply-To: <77b69d64-2ce2-29d9-77a9-04a7159003a9@ericsson.com>
References:  <20181112.173351.1984161388756642220.mbj@tail-f.com>  <77b69d64-2ce2-29d9-77a9-04a7159003a9@ericsson.com>
From: Andy Bierman 
Date: Tue, 13 Nov 2018 13:27:37 -0800
Message-ID: 
To: =?UTF-8?Q?Bal=C3=A1zs_Lengyel?= 
Cc: Robert Wilton , Martin Bjorklund ,  "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="000000000000a6e9ab057a927cc9"
Archived-At: 
Subject: Re: [netmod] Deviations and augmentations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 21:27:45 -0000

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

On Tue, Nov 13, 2018 at 5:46 AM, Bal=C3=A1zs Lengyel  wrote:

> Hello,
>
> We also need a method for removing stuff. It does happen that some
> functionality is deemed not important enough, outdated, too expensive to
> maintain, so we want to remove it.
>
>    - Augment is clearly not the tool for that.
>    - Deviations are not intended for that  (from rfc 7950: "server
>    deviation: A failure of the server ...")
>
> So we still need Semver(or something akin) and the possibility to do NBC
> changes.
>


This aspect of deviations is unfortunate because it really is a good idea t=
o
limit the number of ways to do the same thing in YANG.

It was a mistake to limit so many legitimate schema alterations and also a
mistake
to characterize all schema modifications as a server failure. Maybe if it
was called "patch"
instead of "deviation".

We should encourage servers to provide the most accurate schema possible.
Many vendors already maintain detailed deviations modules.

Balazs
>

Andy


> On 2018. 11. 12. 18:08, Robert Wilton wrote:
>
>
>
> On 12/11/2018 16:33, Martin Bjorklund wrote:
>
> Robert Wilton   wrote:
>
> In the Thursday Netmod meeting, it was interesting to hear Rob Shakir
> describe how deviations and augmentations are used in OpenConfig to
> add functionality into an older YANG model where the semver rules
> prevent the version number from being incremented.
>
> Further, I think that someone (Martin?) stated on the audio bridge
> that this was an intended/allowed behavior for deviations.
>
> I said that using augmentations (not deviations) was one idea we
> originally had for solving the "branching problem".
>
> Ah, OK. I agree that makes sense.
>
>
> I think that this works for OC b/c they don't branch their modules.
> Hence I think it is important that we decide if branching is a
> requirement or not.
>
> So, I think that this probably works for adding enhancements, but not for
> the (arguably more important) bug fix case, unless there is a reasonable
> solution to having two config data nodes both modifying the same underlyi=
ng
> property.  Perhaps under some reasonable constraints this could be made t=
o
> work - but I don't know.
>
> Of course, even for enhancements it is not necessarily a perfect
> solution.  E.g. backporting some subset of a module already
> coded/implemented in latest to an older release.  And yes, we really do g=
et
> asked to do this sometimes, although it is relatively rare.
>
> Thanks,
> Rob
>
>
>
> /martin
>
>
> This surprised me, because I thought that RFC 7950 was quite explicit
> that this is not what deviations are intended for.  My reading of RFC
> 7950 is that the deviation statement represents the case where the
> server *implementation* does not match the *specification*.  However,
> the versioning issue that we are discussing are bug fixes/changes in
> the specification rather than the bug fixes in the implementation.
>
> Personally, I'm really not keen on using deviations to represent bug
> fixes to older YANG models for three reasons:
>
> (i) It is changing the meaning of deviation.  It is much cleaner to
> keep the meaning of deviation statements as they are defined today,
> and not conflate their semantics.
> (ii) A different mechanism is used to put a bug fix into an older
> branch rather than in the head of the development.
> (iii) For clients to track the lifecycle of modules they would not
> only need to know the module version number but would also need to
> find and track all associated deviation modules.  This seems
> significantly more complex for clients than the modified semver that
> was proposed.
>
> ---
>
> I think that has also been some suggestion that augmentations (or
> duplicate YANG modules with their major version number changed) can be
> used to make bug fixes in a completely backwards compatible way.
> However, I still don't understand a robust scheme of how this works.
>
> ---
>
> Finally, there were some comments about using augmentation modules for
> enhancements.  This is fine, where appropriate (e.g. a non trivial
> number of data nodes are being added as an enhancement) then a
> separate module may be the right way to go. But here, I presume that
> the new functionality will always be tracked by that separate module.
> If that functionality folds back into the original module at some
> point in the future, then obviously a non backwards compatible version
> change is being forced on to the client, along with additional work on
> the server as well.
>
> I think that there are also many cases where the number of data nodes
> being added via an enhancement is small compared to the size of the
> module being updated.  In this case I believe that it better to add
> these data nodes into the module itself, perhaps predicated under
> if-feature if appropriate.
>
> Thanks,
> Rob
>
>
> _______________________________________________
> 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
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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




On Tue, Nov 13, 2018 at 5:46 AM, Bal=C3=A1zs Lengyel =
<balazs=
.lengyel@ericsson.com> wrote:

 =20
   =20
 =20
  

    
Hello,

    
We also need a method for removing stuff. It does happen that
      some functionality is deemed not important enough, outdated, too
      expensive to maintain, so we want to remove it. 

    

    
    
      
  • Augment is clearly not the tool for that.
    • 
      
  • Deviations are not intended for that=C2=A0 (from rfc 7950: "=
server
        deviation: A failure of the server ...")
    • 
    

    
So we still need Semver(or something akin) and the possibility to
      do NBC changes.


<=
div>This aspect of deviations is unfortunate because it really is a good id=
ea to
limit the number of ways to do the same thing in YANG.

It was a mistake to limit so many legitimate schema al=
terations and also a mistake
to characterize all schema modificat=
ions as a server failure. Maybe if it was called "patch"
instead of "deviation".

We should enco=
urage servers to provide the most accurate schema possible.
Many =
vendors already maintain detailed deviations modules.

<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

    
Balazs

Andy
=
=C2=A0

    

    
On 2018. 11. 12. 18:08, Robert Wilton
      wrote:

    

    

      

      

      On 12/11/2018 16:33, Martin Bjorklund wrote:
      

      
Robert Wilton <rwilton@cisco.com>
        wrote:
        

        
In the Thursday Netmod meeting, it was
          interesting to hear Rob Shakir
          

          describe how deviations and augmentations are used in
          OpenConfig to
          

          add functionality into an older YANG model where the semver
          rules
          

          prevent the version number from being incremented.
          

          

          Further, I think that someone (Martin?) stated on the audio
          bridge
          

          that this was an intended/allowed behavior for deviations.
          

        

        I said that using augmentations (not deviations) was one idea we
        

        originally had for solving the "branching problem".
        

      

      Ah, OK. I agree that makes sense.
      

      

      

        

        I think that this works for OC b/c they don't branch their
        modules.
        

        Hence I think it is important that we decide if branching is a
        

        requirement or not.
        

      

      So, I think that this probably works for adding enhancements, but
      not for the (arguably more important) bug fix case, unless there
      is a reasonable solution to having two config data nodes both
      modifying the same underlying property.=C2=A0 Perhaps under some
      reasonable constraints this could be made to work - but I don't
      know.
      

      

      Of course, even for enhancements it is not necessarily a perfect
      solution.=C2=A0 E.g. backporting some subset of a module already
      coded/implemented in latest to an older release.=C2=A0 And yes, we
      really do get asked to do this sometimes, although it is
      relatively rare.
      

      

      Thanks,
      

      Rob
      

      

      

        

        

        /martin
        

        

        

        
This surprised me, because I thought
          that RFC 7950 was quite explicit
          

          that this is not what deviations are intended for.=C2=A0 My readi=
ng
          of RFC
          

          7950 is that the deviation statement represents the case where
          the
          

          server *implementation* does not match the *specification*.=C2=A0
          However,
          

          the versioning issue that we are discussing are bug
          fixes/changes in
          

          the specification rather than the bug fixes in the
          implementation.
          

          

          Personally, I'm really not keen on using deviations to
          represent bug
          

          fixes to older YANG models for three reasons:
          

          

          (i) It is changing the meaning of deviation.=C2=A0 It is much
          cleaner to
          

          keep the meaning of deviation statements as they are defined
          today,
          

          and not conflate their semantics.
          

          (ii) A different mechanism is used to put a bug fix into an
          older
          

          branch rather than in the head of the development.
          

          (iii) For clients to track the lifecycle of modules they would
          not
          

          only need to know the module version number but would also
          need to
          

          find and track all associated deviation modules.=C2=A0 This seems
          

          significantly more complex for clients than the modified
          semver that
          

          was proposed.
          

          

          ---
          

          

          I think that has also been some suggestion that augmentations
          (or
          

          duplicate YANG modules with their major version number
          changed) can be
          

          used to make bug fixes in a completely backwards compatible
          way.
          

          However, I still don't understand a robust scheme of how this
          works.
          

          

          ---
          

          

          Finally, there were some comments about using augmentation
          modules for
          

          enhancements.=C2=A0 This is fine, where appropriate (e.g. a non
          trivial
          

          number of data nodes are being added as an enhancement) then a
          

          separate module may be the right way to go. But here, I
          presume that
          

          the new functionality will always be tracked by that separate
          module.
          

          If that functionality folds back into the original module at
          some
          

          point in the future, then obviously a non backwards compatible
          version
          

          change is being forced on to the client, along with additional
          work on
          

          the server as well.
          

          

          I think that there are also many cases where the number of
          data nodes
          

          being added via an enhancement is small compared to the size
          of the
          

          module being updated.=C2=A0 In this case I believe that it better
          to add
          

          these data nodes into the module itself, perhaps predicated
          under
          

          if-feature if appropriate.
          

          

          Thanks,
          

          Rob
          

          

          

          _______________________________________________
          

          netmod mailing list
          

          netmod@ietf.=
org
          

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

        

        .
        

        

      

      

      _______________________________________________
      

      netmod mailing list
      

      netmod@ietf.org<=
/a>
      

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

    

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


  




_______________________________________________

netmod mailing list

netmod@ietf.org

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




--000000000000a6e9ab057a927cc9--


From nobody Tue Nov 13 15:45:49 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD46130DC7 for ; Tue, 13 Nov 2018 15:45:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aviatus.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOlillbtrgjt for ; Tue, 13 Nov 2018 15:45:44 -0800 (PST)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810042.outbound.protection.outlook.com [40.107.81.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E4CC130DF1 for ; Tue, 13 Nov 2018 15:45:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aviatus.onmicrosoft.com; s=selector1-aviatnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/P/pYwVBAqlfAA3GeFFvOGGSW9YKNRgKl2pHLdF8Y3c=; b=Z+QjvKs8UBBQP6MIwdBdtyM9A2454TGA9jN+LtRKUyo96v0gPGfgBlYqseEXXGpzogIIAFUIdtxcGUpwH7RO/jTPOW+Y6IX9rn+lwMZ8EVjuQdsr6U7oNsyBkrr00hfReQSN0R+ZVXslW5mg7IIR/7O1Mofm3hO77405H7vt0Rg=
Received: from MWHPR2201CA0068.namprd22.prod.outlook.com (2603:10b6:301:5e::21) by MWHPR2201MB1117.namprd22.prod.outlook.com (2603:10b6:301:33::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.26; Tue, 13 Nov 2018 23:45:41 +0000
Received: from BY2NAM03FT045.eop-NAM03.prod.protection.outlook.com (2a01:111:f400:7e4a::209) by MWHPR2201CA0068.outlook.office365.com (2603:10b6:301:5e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1339.20 via Frontend Transport; Tue, 13 Nov 2018 23:45:41 +0000
Authentication-Results: spf=pass (sender IP is 192.147.115.53) smtp.mailfrom=Aviatnet.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=Aviatnet.com;
Received-SPF: Pass (protection.outlook.com: domain of Aviatnet.com designates 192.147.115.53 as permitted sender) receiver=protection.outlook.com;  client-ip=192.147.115.53; helo=mail-send.aviatnet.com;
Received: from mail-send.aviatnet.com (192.147.115.53) by BY2NAM03FT045.mail.protection.outlook.com (10.152.85.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1339.10 via Frontend Transport; Tue, 13 Nov 2018 23:45:40 +0000
From: Alex Campbell 
To: NETMOD WG 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AQHUe6r76C+EZfZj2kKTXlR8pzGfIQ==
Date: Tue, 13 Nov 2018 23:45:39 +0000
Message-ID: <1542152721437.91451@Aviatnet.com>
References:  <9C5FD3EFA72E1740A3D41BADDE0B461FCFA7803B@DGGEMM528-MBX.china.huawei.com> <20181106141613.zqy5xmq7qvahzzpz@anna.jacobs.jacobs-university.de> <9C5FD3EFA72E1740A3D41BADDE0B461FCFA78BFA@DGGEMM528-MBX.china.huawei.com> <20181107083401.7bqbjnewg3syd6dj@anna.jacobs.jacobs-university.de> <0bb4d572-3378-c46a-0802-c2c2fce7cc4e@ericsson.com> <20181113140709.vwc4f3mqmmgjaluu@anna.jacobs.jacobs-university.de>, <091DC7F4-0C17-4E64-85B8-8963EFBC208B@cisco.com>
In-Reply-To: <091DC7F4-0C17-4E64-85B8-8963EFBC208B@cisco.com>
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.10]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:192.147.115.53; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(376002)(39850400004)(136003)(396003)(346002)(2980300002)(438002)(189003)(199004)(76176011)(47776003)(7696005)(2486003)(23676004)(93886005)(25786009)(186003)(336012)(26005)(106002)(316002)(436003)(86362001)(126002)(53546011)(11346002)(956004)(118246002)(36736006)(102836004)(486006)(2616005)(446003)(476003)(7596002)(2906002)(246002)(305945005)(53416004)(6916009)(6486002)(966005)(7636002)(7736002)(72206003)(478600001)(117636001)(229853002)(36756003)(97876018)(106466001)(6306002)(6116002)(5660300001)(8676002)(8936002)(356004)(6246003)(3846002)(50466002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR2201MB1117; H:mail-send.aviatnet.com; FPR:; SPF:Pass; LANG:en; PTR:mail-send.aviatnet.com; MX:1; A:1; 
X-Microsoft-Exchange-Diagnostics: 1; BY2NAM03FT045; 1:WXl+ERlNTtS9xPaKcubjiT3QjrhlQlcDz1vRuFndDmnD3tbTHj5tO5CuA96adIKlx8kwDccvGVsLQ3sCYlfuvn7jg7FXONVLxCeB+xsEaGT2ektYDotbm3+tEMXPnlKr
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 25df27f6-e390-48f0-3d6f-08d649c21ea5
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390060)(7020095)(4652040)(8989299)(5600074)(711020)(4608076)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MWHPR2201MB1117; 
X-Microsoft-Exchange-Diagnostics: 1; MWHPR2201MB1117; 3:MjEQhDY3fBOOS2rGxerjsArU0RNlL/62MbAMr1bQ76ltG5nqf7qekbsowdxnre1RGH1K3VYX6xMUxuwbuJqgFbJ1pBBh0caAYnfkvdX0DuMKb6FLJVpHt1o5GPRAHBi7rCZQD+Th64zpULg5fxTveHcUB4HmE68QBUpdmCOQXQkuQYhbF7Yl4Um3Uh3AC8AGPEipqP32+yIKiiShZEuX6noB8bg0Y6myjCIcV2wZZjU7LuK9gzAagnOK8iwFpqs8tdqEuphIHPcLnmn54LdwyJItWQjkmL70F6JPxUlmTz8X1Mho970aTjS2nhItuTcE/ljPNO7gbga5Jmm9qZ5q8ca6r8zGAPGZ35U1m/zB8A4=; 25:+p8jCR61k998jRRXenFsNWF/cUwmG7sCPrQxEXi0b0FruHJ1bDG4YT8Iv7sMLKn4bLM/R//lRpUM6pfM7FKcxj2kF5ewO0GySrVhaHfLA0/vmo/fQ4cYu4YR11p/5h9Ls4ZT09FbcCtNvu86kd9vzdlPHpopKQRGxD00/xBzzBxkIFpsCa8p+p+FjgFexIGo85OklAa80drr4cXsxBlxmOP2Rub1YwvZeXNofJCEFfmBWe2gqFcgECk31cJmV/L4w05EDxOnKLWn2YLCm6bvb5Yfa5D0X1Fk6XLZjsrphkiOpntIOK3n/HFDIBg7OhLHuK03jF/mY7fXPgi+S23eUA==
X-MS-TrafficTypeDiagnostic: MWHPR2201MB1117:
X-Microsoft-Exchange-Diagnostics: 1; MWHPR2201MB1117; 31:kycWVbn1tcLKwN3XFwSfuI7bCug6mrGAT58cMV0wbKaL3o1nVbF+7mSIdNT2YXYqQSzy34NBwYcoxzFLXskORvdwrPTj9fQxh5IbOeR/5Ajkx+KPU3w/a6ZzVCOpwWZEt+/ekYEY/bGNGoM40U64M1SZfFnO6r70ztItGToMPBHReMyrWxMqp1V24PTmVouaF+ySKYJF/JDcrZvofvyS4SDFcw33SJjFgWRydBV5AfE=; 20:7irvRiTy/vAAO7iyNMbKvKEPGWiMlmwUcUYi7QEnAVonPQg9wols1w/2MU2WwWjyCxyb0kn2G6ns1itf1afP+QtcdxOcA+JUgnzCReElOg3S5gnkr3QHnXmEazO9q8XqS+EApJOTQ8XH6g4XcGlv9OnZghWR9Ns7QkLNM0Ni24cDxyyXIHZFt2w3Dze6b6jCJg4uaP80su0qgLeHsbSYbxwya5KFejthtRYYz/44r8i8rmU0ym1D1TitoO1ypubwpO6MRaRpo/0dHxLnmYinrm3OwoGknJwLWkPdIyTILS9YF0vlgp2TMUEu1VjXaJhoUISIJCQOeBg5OTSQZvxaMGOdDsj7HyEcqExCKlgBkFeRp3WNyCz7UknEC9FIDS44qZfiOE+rp9xMeNK/tBli+AWKiiKy5TUPG1qmE+vQowc/Eo8z47XjBnfkSU6gafp3BLWKsFw7K0zoM2jqcabec/ZeAvYyChc5jHTj+FflJyyg1w+KvHji0vpNrT2klXPW
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(95692535739014);
X-MS-Exchange-SenderADCheck: 1
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93004095)(3002001)(10201501046)(3231410)(944501410)(52105112)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:MWHPR2201MB1117; BCL:0; PCL:0; RULEID:; SRVR:MWHPR2201MB1117; 
X-Microsoft-Exchange-Diagnostics: 1; MWHPR2201MB1117; 4:wv+rLAJzpzfnYGIfFPKVs1iXEiM4mk+6p67CCke54bgrTw+VOa0RaQa5f7C0E3lGqDbCldfkYr9pntS7TeFYZCwyEqcUV2hBeumk1MuA1wItKtrZ8BeuKOPFsdK5S1dnSSU0ZGZ/GHMAyN7m52JLu2s8jOCg0svuvI+F9BAear9WDQ4PemfmK0IBbCtJNS1SJZZUKsGqOn5wItAbnSry6MLcsiUMKdd8FZbtEfA4GR5hNhDrHrn0oagDqyPaYH0aDVCz7/sbtdbjoHO4XM90d8OsBSjxt8KQ99kJ07OQNFR2+4mj0nhRyi9wHhpQhG1t
X-Forefront-PRVS: 085551F5A8
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtNV0hQUjIyMDFNQjExMTc7MjM6MU1aS1NGSUVETVdLV3dOV1JGd1Rsc0VM?= =?utf-8?B?NnZIbjA1bWhFbmxVQWloTkRMSGJRLzZDQk9Sbzg4N3ZFVmRWVXc2OUMxVTlY?= =?utf-8?B?dWIwMUhCbHBKNHRzMXlZcEg5Z1VWcmk2NGdxRkVMSmJHenpNU3h4Visyblly?= =?utf-8?B?NStpaGUxMHRSTDR4eHdsZjRXSUhtOFQ0QkJQVVlQdkRhcHlrdDZpcU42ZjlR?= =?utf-8?B?d1JlSWd4aUNseWFzQU1hY3NBWDNDcC9TQjZOKys2OEhzQUVQTVJZbFdLTXVY?= =?utf-8?B?TDdBUXVlbmRqU3ZhbDZ0MkdrS3NrSWo3dnI2ekY5RzRkeDVpZy80OWhuWjdC?= =?utf-8?B?Ukh2cGVjUFAvNTdpdi9XKzNtbHBIeEZsdExSUkRlUHlVNG9qL2dnNlZybWxG?= =?utf-8?B?bm55bXFIYlRYUCtwOXZNZE0xWWtpSnluVG1TRFlrL3lybUpXbHN5cDFJbFBR?= =?utf-8?B?U2JOemx5cGg2bkQrYnd4Z1I5bTc5R0U1eXFpTmFxSnQvZjl3VGxmL3M2TG55?= =?utf-8?B?VnBkOVZhM1dVVWtzamZKRlc4RDB5Uk9BUGtTcVlneW1QS1Y0UG42YVBNYVNP?= =?utf-8?B?aWM2L05TcFY4OUpMdWxibndNUG9hTHdNblROWEtnQ1ZqSXJQRGdGbEFXYjJt?= =?utf-8?B?RGhyNVc3RWJzRzMxTjJLcXUyL3FkaWNnMENSa0thYU9mcHh1dHBBZEowbUZR?= =?utf-8?B?WmZsdUM3TXYzV0xudHcwRm9SWDhMU3h2M3M3SXBFeGwydi84Y1U5K21CNkZB?= =?utf-8?B?akVBSlN5RzZyWlM3Y3pzN1diYllYTWhYM1VmMUprNXJLSUl6YTY4U2FiQjBV?= =?utf-8?B?NWNYY2xqWjJ2QlJ4MHgzN2ZqR1dYRHhGYTdrcmUrT3h6ZG8yNmNOOGE5MzBL?= =?utf-8?B?WUlmY3JMR0xPU2pZUW5JVHN6a1JMdzBwZ0piUEJGSy9WSjR5eThHc1BLbmxV?= =?utf-8?B?Vmk2dUg0dUZQaHFWSVh0OFhtWGZHbW1EWENxQkxZNlVQdWtWNGVJQVkrOHdB?= =?utf-8?B?aW9XbjVNSWlJQW1HODZhYStVMWRBUi92a3FzOUVSd1JzZ2NJcGFMZjgrdGF0?= =?utf-8?B?M3crTHMrMmR3ZmFVdCsrdlRsWi9jSzFsVGlHbEpVU0Y2N3NuSkhXWU9iazRk?= =?utf-8?B?ODhTZDV0VVgrQ1V3Nnl2ZVlzRUZpYVFuTlRqa3ExWVJwUWE5SUN5K2VPRE9H?= =?utf-8?B?dUkyeTBUeTVaU0xDTHhUeWJPbkczejhPUlIvb0IxTkl3eGhiaXZMU1E4TCtH?= =?utf-8?B?R3laMEhFT2tUMFRlZDc2R1VWNHE0RVJKVU81K0paMjFUSkVMOWdiUWhkR2M5?= =?utf-8?B?UWgrQkxsZXhRditjeFFMakJuM1pKN1l4bHNkV09xTDJ4c0pGMm9XUWFNU1Uv?= =?utf-8?B?WWpRWUNSYjluNjdzZHltSytPR0FYeitpKzEzNFJiRXlWSVNmQXZFUVRiZzZs?= =?utf-8?B?U2c1cGo5aGRoZGdycWtKYlA5MGR5SkVKOXl4N3N3OHJ5ZUVWeGtPbHU4YS9r?= =?utf-8?B?VkNvSnJwZmZRTUhlYXVJeVlGNEs1QktKTGhWYXFTZVNlZ2NFdHdMOUVKWWk5?= =?utf-8?B?VHgxQzRCSHZuV01jN0ZMcnhUa0dCNnlIN2FQZHkzR2h6WGRRYzYxVVNOQ3Vq?= =?utf-8?B?NlZpUngzKzdLY1ErT0RPSXB1RUI5TjNSemNzY2hFTFgrOE5nZDdvWDNmeHVM?= =?utf-8?B?eHl0T1RDdm4yQ3hpSTdhejd0UytCM2g4Vm5KbVdpSHAzVk5PWDE1dGNJR0F1?= =?utf-8?B?SjhhUUZKbWhaeU5WVkVnUlBBPT0=?=
X-Microsoft-Antispam-Message-Info: TZjzK3q2ox+nUzGUpUGse/UoqRWCOV/fnjZfAYVq9IYwVAKFEKmizo0OAkqRmiy6CXj7xlXIRkYkvjBDIv3vsKPOydYyShtoE40QYQBWOjt0RZNGd0Ju1ae7J9XLjq2cOTGY1FZM2zFQolnOrHRzks95cy8Bio/BZWMrvveJcnrc/bioQAsRzJwo94k2E32KXrY6P7T3At4nLO4WyfIt6d6YC22x++S3FOmxjMI2ZQOv4xLx0P+IghCQ0KL/31QSOUA4f2ZEkZvYhV+yqJB4fLq9I5CVHKlOBt8AH476H1W/RrNGTzhElcynW+OCe2MCV42lDu1z9eM4+wu0kZiZ99odsS25mqzdPJQYLxipTAY=
X-Microsoft-Exchange-Diagnostics: 1; MWHPR2201MB1117; 6:B3v2okADiGrTaM1iOiYAIEk26xlHrwTr7Y3ihr2K8SjIA8wHi6Uofu3P3mA/uA4ZLgYxS7pqcC8QNa0FUM09a2RmCnd+/PzyrXvJvAM7iaoiVSHObNylP50l3sJlWU52styQF5rQp45esS97a1qOokYNGa1OVAx3Ch7cJODsf7dBLZPDLXsetEOhsESEd88EOooM71KnyPFAFb+d9NkwO96BNpX851ofYbyg14Zxp0dUji/CUpD/h1V1jnoAsGUsH+YKKZGqaFg68t8WjmoHCFMl+EKZZCRp3tsAgECAy03M8HPNX26ibf8wCz+iQdL21rUHLQsX3+3+mKQ47QmyJu2yW0ISt2gOD7DU1rml51jXJisDfojQVLCoLU2kgoigk/UzGPAg8ikAWqJj0exG2BrzAKhb7Sg58FxWIRvE6JochLyaXEIy1Pfjx9Zm/GCeHQVtEwwpvCvn0NTw1xDbdw==; 5:8ZjV7zRWB5LKBWVGXgrhtI8tYomi3kzQns/KwJd/xLZTHRddYPVw+ZjH3agnW5h9yVFEl6R+OcW06jSTFqX2/5DbPpO+OI/j+jPP/w4CISqBB5ezZZnikqVKVMIDqxWi8VEF9E04Nxm6geTXL14T7KhuxP6pINKgnpu1LgqrqfA=; 7:Ut1BjeIYVoKHA5H/mMvP0UIFN6E8oJEqYFxvG2sdl8PD8HsnICGO/3E0lZMuVmd/pFc1FlL5eBJDKsPMOCkpWR2Sl9RCiuy13jgg0VfC6IHKUmztyU9bxynjBXJPt/hn5d9wzagX49QueDWRj8smsQ==
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: aviatnet.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Nov 2018 23:45:40.5663 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 25df27f6-e390-48f0-3d6f-08d649c21ea5
X-MS-Exchange-CrossTenant-Id: 8d7d22b9-3890-4eef-95a6-a226e64151be
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=8d7d22b9-3890-4eef-95a6-a226e64151be; Ip=[192.147.115.53];  Helo=[mail-send.aviatnet.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR2201MB1117
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Nov 2018 23:45:48 -0000

RG9lcyBhIHBlcmNlbnRhZ2UgcmVhbGx5IG5lZWQgYSBzaW5nbGUgc3RhbmRhcmQgdHlwZSBpbiB0
aGUgZmlyc3QgcGxhY2U/IEhvdyBhYm91dCAidW5pdHMgcGVyY2VudDsiPwoKX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2Vz
QGlldGYub3JnPiBvbiBiZWhhbGYgb2YgQWNlZSBMaW5kZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNv
bT4KU2VudDogV2VkbmVzZGF5LCAxNCBOb3ZlbWJlciAyMDE4IDU6MDMgYS5tLgpUbzogSnVlcmdl
biBTY2hvZW53YWVsZGVyOyBCYWzDoXpzIExlbmd5ZWwKQ2M6IE5FVE1PRCBXRwpTdWJqZWN0OiBS
ZTogW25ldG1vZF0gZm9yIGEgZnV0dXJlIHJmYzY5OTFiaXMKCu+7v09uIDExLzEzLzE4LCA5OjA3
IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIiIDxuZXRtb2Qt
Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygai5zY2hvZW53YWVsZGVyQGphY29icy11bml2
ZXJzaXR5LmRlPiB3cm90ZToKCiAgICBPbiBUdWUsIE5vdiAxMywgMjAxOCBhdCAwMTozMzowMVBN
ICswMDAwLCBCYWzDoXpzIExlbmd5ZWwgd3JvdGU6CiAgICA+IEhlbGxvLAogICAgPgogICAgPiBJ
biBzb21lIGNhc2VzIEkgd2FudCBhIHBlcmNlbnRhZ2Ugd2l0aG91dCBmcmFjdGlvbnMuIFRoaXMg
Y291bGQgYmUgZGVmaW5lZAogICAgPiB1c2luZyByYW5nZSwgYnkgc3BlY2lmeWluZyB0aGUgbnVt
YmVycyAwIHwgMSB8IDIgLi4uIDk5IHwgMTAwIGluIHRoZSByYW5nZSdzCiAgICA+IGFyZ3VtZW50
LgogICAgPgogICAgPiAgICAgdHlwZWRlZiBwZXJjZW50LXNob3J0IHsKICAgID4gICAgICAgdHlw
ZSBwZXJjZW50IHsgcmFuZ2UgMCB8IDEgfCAyIC4uLiA5OSB8IDEwMDsgfSAgLy8gZGlkbid0IHR5
cGUgb3V0IGFsbCB0aGUgMTAxIGludGVnZXIgdmFsdWVzIDotKQogICAgPiAgICAgfQogICAgPgoK
ICAgIEkgZ3Vlc3Mgd2UgbmVlZCB0byBzZXR0bGUgb24gYSBzbWFsbCBudW1iZXIgb2YgcGVyY2Vu
dGFnZSB0eXBlcyB0aGF0CiAgICBwZW9wbGUgZmluZCB1c2VmdWwgYW5kIHRoZW4gbW9kdWxlIGF1
dGhvcnMgaG9wZWZ1bGx5IGZpbmQgd2hhdCB0aGV5CiAgICBuZWVkLiBJIGFtIG5vdCBzdXJlIHRo
YXQgbGlzdGluZyAxMDEgbnVtYmVycyBpcyBhIGdvb2QgcGF0dGVybiB0byB1c2UKICAgIChhbHRo
b3VnaCBpdCBkb2VzIGFjaGlldmUgd2hhdCB5b3Ugd2FudCkuIEZvciBwZXJjZW50YWdlcyB0aGF0
IGhhdmUgbm8KICAgIGZyYWN0aW9uLCB5b3UgbGlrZWx5IHdhbnQgdG8gZGVyaXZlIGZyb20gYSBi
YXNlIHR5cGUgdGhhdCBpcyBlZmZpY2llbnQKICAgIHRvIGVuY29kZSBmb3IgYmluYXJ5IGVuY29k
aW5ncyBzdWNoIGFzIENCT1IuCgpPciBzaW1wbHkgZGVmaW5lIGEgdHlwZSB3aXRoIGEgYmFzZSB0
eXBlIG9mIHVuaXQ4IHR5cGUgYW5kIGEgcmFuZ2Ugb2YgMC0xMDAuCgpBY2VlCgoKCgoKICAgIC9q
cwoKICAgIC0tCiAgICBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2
ZXJzaXR5IEJyZW1lbiBnR21iSAogICAgUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBD
YW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQogICAgRmF4OiAgICs0OSA0MjEg
MjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPgoKICAg
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiAgICBuZXRt
b2QgbWFpbGluZyBsaXN0CiAgICBuZXRtb2RAaWV0Zi5vcmcKICAgIGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KbmV0bW9kIG1haWxpbmcgbGlzdApuZXRtb2RAaWV0Zi5vcmcK
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QK


From nobody Wed Nov 14 00:10:30 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E2B12D4F0 for ; Wed, 14 Nov 2018 00:10:28 -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 gsV_mW1r1Ras for ; Wed, 14 Nov 2018 00:10:26 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 623C0128CF3 for ; Wed, 14 Nov 2018 00:10:26 -0800 (PST)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 1C2C51AE0351; Wed, 14 Nov 2018 09:10:25 +0100 (CET)
Date: Wed, 14 Nov 2018 09:10:24 +0100 (CET)
Message-Id: <20181114.091024.1454093230497622054.mbj@tail-f.com>
To: Alex.Campbell@Aviatnet.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1542152721437.91451@Aviatnet.com>
References: <20181113140709.vwc4f3mqmmgjaluu@anna.jacobs.jacobs-university.de> <091DC7F4-0C17-4E64-85B8-8963EFBC208B@cisco.com> <1542152721437.91451@Aviatnet.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2018 08:10:29 -0000

SGksDQoNCkFsZXggQ2FtcGJlbGwgPEFsZXguQ2FtcGJlbGxAQXZpYXRuZXQuY29tPiB3cm90ZToN
Cj4gRG9lcyBhIHBlcmNlbnRhZ2UgcmVhbGx5IG5lZWQgYSBzaW5nbGUgc3RhbmRhcmQgdHlwZSBp
biB0aGUgZmlyc3QNCj4gcGxhY2U/IEhvdyBhYm91dCAidW5pdHMgcGVyY2VudDsiPw0KDQpBdCB0
aGlzIHBvaW50LCBhZnRlciBoZWFyaW5nIGFib3V0IGhvdyBkaWZmZXJlbnQgbW9kdWxlcyBoYXZl
DQpkaWZmZXJpbmcgcmVxdWlyZW1lbnQgb24gdGhpcyB0eXBlLCBJIHRlbmQgdG8gYWdyZWUuDQoN
Cg0KL21hcnRpbg0KDQoNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4gRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxm
IG9mIEFjZWUgTGluZGVtIChhY2VlKQ0KPiA8YWNlZUBjaXNjby5jb20+DQo+IFNlbnQ6IFdlZG5l
c2RheSwgMTQgTm92ZW1iZXIgMjAxOCA1OjAzIGEubS4NCj4gVG86IEp1ZXJnZW4gU2Nob2Vud2Fl
bGRlcjsgQmFsw6F6cyBMZW5neWVsDQo+IENjOiBORVRNT0QgV0cNCj4gU3ViamVjdDogUmU6IFtu
ZXRtb2RdIGZvciBhIGZ1dHVyZSByZmM2OTkxYmlzDQo+IA0KPiDvu79PbiAxMS8xMy8xOCwgOTow
NyBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgSnVlcmdlbiBTY2hvZW53YWVsZGVyIg0KPiA8bmV0
bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mDQo+IGouc2Nob2Vud2FlbGRlckBqYWNv
YnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+IA0KPiAgICAgT24gVHVlLCBOb3YgMTMsIDIwMTgg
YXQgMDE6MzM6MDFQTSArMDAwMCwgQmFsw6F6cyBMZW5neWVsIHdyb3RlOg0KPiAgICAgPiBIZWxs
bywNCj4gICAgID4NCj4gICAgID4gSW4gc29tZSBjYXNlcyBJIHdhbnQgYSBwZXJjZW50YWdlIHdp
dGhvdXQgZnJhY3Rpb25zLiBUaGlzIGNvdWxkIGJlDQo+ICAgICA+IGRlZmluZWQNCj4gICAgID4g
dXNpbmcgcmFuZ2UsIGJ5IHNwZWNpZnlpbmcgdGhlIG51bWJlcnMgMCB8IDEgfCAyIC4uLiA5OSB8
IDEwMCBpbiB0aGUNCj4gICAgID4gcmFuZ2Uncw0KPiAgICAgPiBhcmd1bWVudC4NCj4gICAgID4N
Cj4gICAgID4gICAgIHR5cGVkZWYgcGVyY2VudC1zaG9ydCB7DQo+ICAgICA+ICAgICAgIHR5cGUg
cGVyY2VudCB7IHJhbmdlIDAgfCAxIHwgMiAuLi4gOTkgfCAxMDA7IH0gLy8gZGlkbid0IHR5cGUg
b3V0DQo+ICAgICA+ICAgICAgIGFsbCB0aGUgMTAxIGludGVnZXIgdmFsdWVzIDotKQ0KPiAgICAg
PiAgICAgfQ0KPiAgICAgPg0KPiANCj4gICAgIEkgZ3Vlc3Mgd2UgbmVlZCB0byBzZXR0bGUgb24g
YSBzbWFsbCBudW1iZXIgb2YgcGVyY2VudGFnZSB0eXBlcyB0aGF0DQo+ICAgICBwZW9wbGUgZmlu
ZCB1c2VmdWwgYW5kIHRoZW4gbW9kdWxlIGF1dGhvcnMgaG9wZWZ1bGx5IGZpbmQgd2hhdCB0aGV5
DQo+ICAgICBuZWVkLiBJIGFtIG5vdCBzdXJlIHRoYXQgbGlzdGluZyAxMDEgbnVtYmVycyBpcyBh
IGdvb2QgcGF0dGVybiB0byB1c2UNCj4gICAgIChhbHRob3VnaCBpdCBkb2VzIGFjaGlldmUgd2hh
dCB5b3Ugd2FudCkuIEZvciBwZXJjZW50YWdlcyB0aGF0IGhhdmUgbm8NCj4gICAgIGZyYWN0aW9u
LCB5b3UgbGlrZWx5IHdhbnQgdG8gZGVyaXZlIGZyb20gYSBiYXNlIHR5cGUgdGhhdCBpcyBlZmZp
Y2llbnQNCj4gICAgIHRvIGVuY29kZSBmb3IgYmluYXJ5IGVuY29kaW5ncyBzdWNoIGFzIENCT1Iu
DQo+IA0KPiBPciBzaW1wbHkgZGVmaW5lIGEgdHlwZSB3aXRoIGEgYmFzZSB0eXBlIG9mIHVuaXQ4
IHR5cGUgYW5kIGEgcmFuZ2Ugb2YNCj4gMC0xMDAuDQo+IA0KPiBBY2VlDQo+IA0KPiANCj4gDQo+
IA0KPiANCj4gICAgIC9qcw0KPiANCj4gICAgIC0tDQo+ICAgICBKdWVyZ2VuIFNjaG9lbndhZWxk
ZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiAgICAgUGhvbmU6
ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwg
R2VybWFueQ0KPiAgICAgRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cHM6Ly93
d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPiANCj4gICAgIF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgICBuZXRtb2QgbWFpbGluZyBsaXN0DQo+
ICAgICBuZXRtb2RAaWV0Zi5vcmcNCj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vbmV0bW9kDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5v
cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1h
aWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9uZXRtb2QNCg==


From nobody Wed Nov 14 00:16: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 1A24312D4F0 for ; Wed, 14 Nov 2018 00:16:14 -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 5lawwEC_XnkU for ; Wed, 14 Nov 2018 00:16:10 -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 7A5B8128CF3 for ; Wed, 14 Nov 2018 00:16:10 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id D5D6562E1A for ; Wed, 14 Nov 2018 09:16:08 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1542183368; bh=cJ4C6au317etSfG7UQ2BiYkx8UYGohXTLTHqxQ4AAJk=; h=From:To:Date; b=dQ2jNuk35zHxRn4ztDPD9jqrbsmM5R/CIDKCPi6l2BqNN8mL0chsO7E9BPWW/4W2J pgYgB7MzVK/DGuHpXZz5NaRzcQpnDpbx21QBzHPHy++yFJ+IsdhPbImaQ0kzzNUePE +wVvxj1MB0I3HsHdDllrk/LT+Nt+xycK1xqpjJdc=
Message-ID: 
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Wed, 14 Nov 2018 09:16:08 +0100
In-Reply-To: <20181114.091024.1454093230497622054.mbj@tail-f.com>
References: <20181113140709.vwc4f3mqmmgjaluu@anna.jacobs.jacobs-university.de> <091DC7F4-0C17-4E64-85B8-8963EFBC208B@cisco.com> <1542152721437.91451@Aviatnet.com> <20181114.091024.1454093230497622054.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2018 08:16:14 -0000

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
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Nov 14 02:04: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 73C40128BCC; Wed, 14 Nov 2018 02:04:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTPhY-PdFk-L; Wed, 14 Nov 2018 02:04:38 -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 723E8124BE5; Wed, 14 Nov 2018 02:04:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5888; q=dns/txt; s=iport; t=1542189877; x=1543399477; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=4tL4P0QllDlGrMDOv8UJWfQv6bYKjM1opUT3dS7Uc2k=; b=JkzOlDulNFu+CoJPEbddFFeOGZ1UGLCQ8bBlfL10u8/tMeWuERMXY8mC lT6S+2kFE2DikwegkQGU4Ctp01ZDVSQX/fPQbNSel8ytZVNFoZOjrngx9 szVR3bXgjl8hzP8DVw6Cv5piZDlCejewWME3Wqmc1cfJIB1eyaSX/ydU/ U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABH8utb/xbLJq1iGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgmmBAieDeIgYX40FJZc2gXoNGA2EAUY?= =?us-ascii?q?Cg2U0DQ0BAwEBAgEBAm0cDIU6AQEBAwEBASEPAQU2CwULCw4KAgImAgInMAY?= =?us-ascii?q?NBgIBAYMdAYF5CA+oKIEvhUCEagWBC4sRgUA/gREnDIFhfoMbAQECAReBIRC?= =?us-ascii?q?DGoJXAolDA4E6hAmQVQmGd4olBhiBWIgBJoZ2gU6LXoN8hlmBRTiBVTMaCBs?= =?us-ascii?q?VO4JsgiwSiF6FPj8DMAGLKIJMAQE?=
X-IronPort-AV: E=Sophos;i="5.56,232,1539648000";  d="scan'208";a="7978008"
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; 14 Nov 2018 10:04:35 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id wAEA4YJh019487; Wed, 14 Nov 2018 10:04:34 GMT
To: Christian Hopps 
Cc: joel jaeggli , NETMOD Working Group , draft-ietf-netmod-module-tags.authors@ietf.org
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>  
From: Robert Wilton 
Message-ID: <96b1510e-2d12-32ba-4609-009b4e86d790@cisco.com>
Date: Wed, 14 Nov 2018 10:04:34 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2018 10:04:41 -0000

Hi Chris,

On 13/11/2018 21:05, Christian Hopps wrote:
> The servers implement the modules which can have predefined tags from the module designer as well as the implementer (vendor) which literally cannot come from anywhere *but* the server that implements the module.

Clients should also be able to know find out the predefined tags from 
the module definition.  I agree that the any tags added by the 
implementation can only be known by querying the server, although its 
not obvious to me what those tags would be.  E.g. if Cisco had a YANG 
module for EIGRP and wanted to give it the ietf:protocol and 
ietf:routing tag then it would ideally use the extension and put it in 
the YANG file.

> This is not what I thought would hold this work up.

Sorry, I'm not trying to hold anything up.

It not obvious to me how the ietf-module-tags modules will actually be 
used on a device:
  1) being able to ask a device: "What are all the YANG modules that are 
implemented on this device that are routing protocols" seems a useful 
thing to do.  Although personally I would ideally want the answer in the 
context of YANG library.  I.e. to see the modules with the given tags, 
along with module evision/version, features and any deviations.  This 
can probably be achieved today with an appropriate xpath query, if 
supported, or could perhaps be achieved more easily if the operational 
list of tags also augmented the module entries in the YANG library 
structure.  But perhaps for your envisaged use case just getting back 
the list of modules with that tag is sufficient and is what you are after.

Is this how you are envisaging YANG module tags would be used, and if 
so, would it do any harm to add a short section near the intro 
explaining this (and perhaps the YANG catalogue example as well)?  Or do 
you think that this would just be needless noise.

2) Being able to filter queried data based on tags may also be useful, 
but this would require protocol extensions, perhaps something to be done 
in future?

Thanks,
Rob


>
> Thanks,
> Chris.
>
>> On Nov 13, 2018, at 5:58 AM, Robert Wilton  wrote:
>>
>> Hi Joel, authors,
>>
>> I have to confess that I didn't have time to review this during the last call (but have reviewed/provided comments on previous versions).
>>
>> These comments may be too late, but I will provide them anyway, so make of them what you will :-)
>>
>> In summary, I like the idea of tags and I think that they are a good fit for classifying YANG models.  In particular, I think that a flexible classification of YANG modules is better than a rigid structure that can never be changed.
>>
>> For me the one of the great utilities of module tags could be in applications like YANG catalog search (https://yangcatalog.org/yang-search/).  Being able to search for modules by tag seems like it would be a particularly useful thing to be able to do.
>>
>> However, I do have some sympathy with Alex's comment, in that it is a bit unclear as to benefits of configuring the tag information on the devices.  At the moment, the configuration doesn't have any material affect on the device, and the only thing that a client can do is read back the tag configuration.  Is the intention that the protocols may be extended in future to allow filter queries to be based on module tags?
>>
>> So, I am supportive of Alex's comment that it would give the document more clarity if some of the specific use cases could be described.
>>
>>
>> Some other random comments/nits:
>>
>> 1) 6087bis references can be updated to RFC 8407.  Is a reference even allowed in the abstract?
>>
>> 2) Abstract: "writing a modules tags" => "writing a module's tags" or "writing module tags"
>>
>> 3) The module is YANG 1.1, so RFC 6020 reference can be changed to RFC 7950.
>>
>> 4) Section 3.4: Should there be a tag prefix for "experimental"? Or perhaps this would be "ietf:experimental:" anyway.
>>
>> 5) Section 5.1: It might be useful if the tags were also reported under YANG library, e.g. as an augmentation to rfc7895bis.  E.g. this would report the same information as "modules-tags/module[name]/tag" leaf-list.
>>
>> 6) YANG module: Should you limit the maximum size of a tag? Perhaps to 255, or 1000 characters.
>>
>> 7) Line length for "The operational view of this list is constructed ..." looks like it may be too long.
>>
>> 8) Section 7, Guidelines to authors.  I was wondering if this section should state that YANG modules SHOULD define standard tags that are associated with it.  At the moment, it just states what can be done, without providing guidance of what should be done.
>>
>> 9) Section 9.2.  A few more possible categories: discovery protocol, vpn, tunnel.  I'm not sure that I particularly like "rfc8199-" as a module name, and possibly "classification-" would be better.
>>
>> Apologies for the tardy review comments,
>> Rob
>>
>>
>> On 12/11/2018 16:46, joel jaeggli wrote:
>>> During the Thursday nov 8 session of netmod, we asked if there were any objections to the publication of the Draft-03 version of draft-ietf-netmod-module-tags which addresses comments and concerns raised during the WGLC. In the meeting there were none. This commences a comment period to confirm that call. As this follows closely on the heels of the IETF 103 meeting we’ll let the call run through Monday the 26th of November.
>>>
>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-03.txt
>>>
>>>
>>> Thanks
>>> Joel
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Wed Nov 14 02:48: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 ADE0112D4EB for ; Wed, 14 Nov 2018 02:48:20 -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 rZshoI8ighnt for ; Wed, 14 Nov 2018 02:48:18 -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 523C8124408 for ; Wed, 14 Nov 2018 02:48:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3926; q=dns/txt; s=iport; t=1542192498; x=1543402098; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=wPMCC+jguMH2lRXej1H1fwnLEOA6Ic9iRpB6pvik+vo=; b=kcAmA2QM/wsOXjIGKXw57k003PnLAX2PAxxCAdtEQct/RyetI3BVmq6T CncyTpxLduTPga05h70xuHiYFRXJ7Qx4Xq+PbIZlBKiXFCf6gYbFnN7NB WQbi0di427AKgU7vylJit9XUOVwS2tvqMUp9SyFYA8WwTqk03ZZpx2T0K I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAAAy/Otb/xbLJq1iGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwMBAQEBCwGDa4QfiHeNBSWXNoF6DYRsAoNlNgsNAQMBAQI?= =?us-ascii?q?BAQJtKIU7AQUjDwEFPBULGAICJgICVwYBDAgBAReDBoICqBiBL4VAhG6BC4s?= =?us-ascii?q?RgUA/gTgMgl+EaIMaglcCiRMwlhsJkRwGGIlZhxyRKIZZgUwKJ4FVMxoIGxW?= =?us-ascii?q?DKJBZPwOOJQEB?=
X-IronPort-AV: E=Sophos;i="5.56,232,1539648000";  d="scan'208";a="8039940"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2018 10:48:16 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id wAEAmFdH026915; Wed, 14 Nov 2018 10:48:16 GMT
To: Andy Bierman , "netmod@ietf.org" 
References:  <20181112.173351.1984161388756642220.mbj@tail-f.com>  <77b69d64-2ce2-29d9-77a9-04a7159003a9@ericsson.com>  <98d6293c-d762-4d21-a9e2-c9cb20f74135@cisco.com>  <453368b2-aa52-f09a-ea0b-960255bce46b@cisco.com> <20181113170652.intfq37w6rxyw4rq@anna.jacobs.jacobs-university.de>  <20181113182621.vixdnijldgs7pmtj@anna.jacobs.jacobs-university.de>
From: Robert Wilton 
Message-ID: 
Date: Wed, 14 Nov 2018 10:48:14 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <20181113182621.vixdnijldgs7pmtj@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.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [netmod] Deviations and augmentations
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2018 10:48:21 -0000

On 13/11/2018 18:26, Juergen Schoenwaelder wrote:
> On Tue, Nov 13, 2018 at 05:54:27PM +0000, Robert Wilton wrote:
>>
>> I think that my main point regarding version numbers is:
>>
>>   - If we are going to use semver then we should define and follow the rules
>> strictly.  I.e. assuming that the semver has been populated correctly then
>> it should be possible to determine whether the change is a nbc, bc, or
>> editorial change.  I think that a solution where semver is done in a
>> half-hearted way is entirely useless (e.g. if clients cannot trust the
>> version number).  I think that there is a pretty clear requirement to
>> support NBC changes to older revisions (i.e. I really mean bug fixes but a
>> looser interpretation than your definition), and hence I don't think that
>> vanilla semver is sufficient.
> But even if you make the 'YANG world' use semvers correctly (not sure
> how you want to achieve that but lets pretend you manage), then the
> three digit number does not tell a client whether it will work or not.
> What should a client do if semver indicate nbc? What should it do if
> semver indicates bc? What should it do if semver indicates editorial
> change? Where is the "protocol specification" for this?

In theory, for editorial or bc changes an existing client, coded 
correctly SHOULD work unchanged (assuming that it doesn't barf on 
operational state that it doesn't understand or config that it isn't 
aware of)  I.e. I see that it is effectively making the same promise 
that 7950 module updates rules are trying to enforce today (putting 
status obsolete aside).

For an nbc change they would need to check, manually or using a schema 
compare tool, to see what has changed.

But I agree that a scheme level version number is really giving a 
suggestion rather than a robust promise that the client won't break.

Even the schema compare tool doesn't guarantee that a client won't 
break, since it does not guarantee that the server implementation 
doesn't have any bugs.

The next step is a solid set of tests that can be run against the 
updated schema and servers, and check that they behave as expected.  Rob 
Shakir indicated that OpenConfig is busy building such as test framework.

Then I think that the operator still rolls out the changes gradually, 
monitors for unexpected conditions, and is able to roll back if 
something goes wrong.

But none of these stages prove that the network will still be fine 
afterwards, they just help catch issues earlier, where they should be 
easier to handle, and give a bit more confidence that the previous step.


>   
>> - An alternative is to not use a semver version number at all, instead we
>> define a non semantic 3 digit version number that is something like:
>>
>>   major = significant changes to the module have been made
>>   minor = smaller changes/feature enhancements to the module have been made
>>   patch = a bug fix to the module has been made.
>>
>> Clients, module readers, etc, and then required to use a schema comparison
>> tool to determine what the actual changes between two revisions are and
>> whether or not they will be broken by those changes.
> The only robust solution is schema comparison and we may think about
> what kind of annotations make such schema comparisons easier or faster
> or how we can help clients to adapt (e.g., providing pointers where
> definitions have moved, providing machine readable information
> allowing tools to track which modules replace others etc.).

Yes, I think that all of this is a good idea.  But I still think that 
having a human readable version number per module is also helpful, even 
if it is only to help humans label the module revision in an easy way.  
E.g. I think that a version number is easier to parse/remember than a 
revision date.

Thanks,
Rob


>
> /js
>


From nobody Wed Nov 14 03:30: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 262A612F1A5 for ; Wed, 14 Nov 2018 03:30:49 -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 9jQDOyDDV6ET for ; Wed, 14 Nov 2018 03:30:46 -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 BD00712958B for ; Wed, 14 Nov 2018 03:30:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13131; q=dns/txt; s=iport; t=1542195046; x=1543404646; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=bBg2TICJXauP+sGhcQ/Tk7/5hV2VpuIrO7GKh2AX3XQ=; b=hT8n4PGhHA1mlLtTwkbxEr+9x2CkyFjB1mNwBP6r4rnKk79z1VNoOEQE Qp+czD9x7tcsuWLiKN5yXus61+dr2iuM4YZ5Q1jemYILUHvvMyieSQaD2 Txe8mr2N9cOLrIU28k+dnzeQUmQe65bMJ9HRuFXjrMevZoXsAI70yTnLe A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAAAoBuxb/xbLJq1iGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwMBAQEBCwGBVYEUgQIng3iId40qkWKFVIF6DRgBCoFUgi9?= =?us-ascii?q?GAoNoNgsNAQMBAQIBAQJtHAyFOgEBAQMBAQEhSxALCxgqAgInMAYBDAYCAQE?= =?us-ascii?q?XgwYBgXkID6gDgS8fhSGEaQWMHIFAP4ERJ4JrgxsBAYFLgxqCVwKVI4o7CZE?= =?us-ascii?q?cBhiJWYcckSiGWYFMAy4ngS4zGggbFTuCbIschT4/AzCNdQEB?=
X-IronPort-AV: E=Sophos;i="5.56,232,1539648000"; d="scan'208,217";a="7979991"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2018 11:30:43 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id wAEBUhmG005104; Wed, 14 Nov 2018 11:30:43 GMT
To: Andy Bierman , NetMod WG 
References: 
From: Robert Wilton 
Message-ID: 
Date: Wed, 14 Nov 2018 11:30:42 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------ADC87AFC156945E17C80FC29"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] comments on YANG versioning
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2018 11:30:49 -0000

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


On 08/11/2018 22:52, Andy Bierman wrote:
> Hi,
>
> A few comments on the netmod meeting yesterday
>
> 1) what is a bugfix?
> It is not encouraging that the DT cannot agree on the scope of a bugfix.
> But not sure it matters if NBC updates can occur for any reason.
> IMO it is easy to define a bugfix in the IETF -- it is called an Errata.
> If an Errata is approved for a YANG module in an RFC then it is a bugfix.

Ultimately we have customers that will say "this part of your YANG is 
broken" and we want you to fix it in that release train, either in the 
next release, or as a software patch.

Sometimes vendors will disagree with their customers as to whether it is 
really a bug fix or an enhancement.  Sometimes we will fix what we think 
is an obvious bug but that will unfortunately break another customer 
whom was relying on the existing behavior and then ask us to revert the fix.

I think that it should be down to the module author/owner to decide 
whether or not it is a bug fix or an enhancement, and I would just like 
a versioning scheme that allows these changes to be expressed.  None of 
this changes the fact that I think that we should be avoiding making 
these changes in the first place.  I.e. I think that there is a clear 
separation between what the versioning scheme should be able to express, 
and what is recommended practice.


>
>
> 2) SEMVER to the rescue?
> If every module release can be its own feature release train then the 
> value of
> ascending numeric identifiers is greatly diminished. The (m) and (M) tags
> do not really help.  I strongly agree with the comment that 
> cherry-picking new
> features can (and should) be done with deviations.  Updates of old
> revisions needs to be for bugfixes only.
>
> I prefer the OpenConfig "SEMVER Classic" rather than introducing a new
> incompatible complex numbering scheme to support something that
> should not be done anyway.

SEMVER classic does not support making bug fixes (even bc ones) on older 
releases.

In an older release, SEMVER classic allows:
  - editorial changes, e.g. spelling corrections or clarifications in 
description statements that do not change the API semantics in anyway.
  - bug fixes to the *implementation*, but then we are not using SEMVER 
to version the implementation anyway, only the API.

If you want to allow bug fixes (even just bc ones) in an older release 
then you either need something like modified semver, or a different 
versioning scheme that allows them.  Or you do what Rob Shakir suggests 
and use deviations for this instead, which I think is a misuse of 
deviations.

>
> 3) Bundles and compatibility modules
> I strongly agree this solution approach is far better than treating 
> every revision
> as a separate feature release train.  I don't see how I am going to
> track the major.minor.patch for 100 different modules. SEMVER is not
> very useful for telling if module A works with B, C, and D. Import by 
> SEMVER
> will probably be OK at first, but become too error-prone after awhile.

+1.  I think that the versioning solution needs to consider something 
like bundles or packages.


>
> 4) Automation tools
> Ad-hoc WEB pages from IANA do not cut it anymore.
> We need a way to get patch versions of modules published and usable
> by automation tools (without an RFC) with just the Errata report as a 
> patch.
> SEMVER requires that a module be released with the change but this is 
> not that practical.

I think that we need to have a place where all revisions of modules are 
published and easily accessible.


> Think how yocto works, using a base source version of a package + patches.
> (IMO we need YANG Packages, which would serve as recipes
> for a set of modules, features, annotations, patches and deviations, 
> that have been
> tested to work together.)
>
> 5) YANG 1.2 vs Extensions
> IMO a new YANG version would be better than extensions, especially to
> fix status-stmt, import-by-revision, deviations, and add annotation,
> patch, and many other new mechanisms to help backward compatibility.

Perhaps.  There is currently a long list of stuff on the YANG.next issue 
tracker.  My concern is that this effort will get bogged down.

Also, some of these changes we want to apply across YANG language 
versions.  E.g. I want the updated status behaviour to apply to all YANG 
modules on the server, regardless of whether of which version of YANG 
they were defined in.

Thanks,
Rob


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

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


  
    
  
  
    


    

    
On 08/11/2018 22:52, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
A few comments on the netmod meeting yesterday

        


        

        
1) what is a bugfix?

        
It is not encouraging that the DT cannot agree on the scope
          of a bugfix.

        
But not sure it matters if NBC updates can occur for any
          reason.

        
IMO it is easy to define a bugfix in the IETF -- it is
          called an Errata.

        
If an Errata is approved for a YANG module in an RFC then
          it is a bugfix.

      

    

    
Ultimately we have customers that will say "this part of your
      YANG is broken" and we want you to fix it in that release train,
      either in the next release, or as a software patch.

    

    
Sometimes vendors will disagree with their customers as to
      whether it is really a bug fix or an enhancement.  Sometimes we
      will fix what we think is an obvious bug but that will
      unfortunately break another customer whom was relying on the
      existing behavior and then ask us to revert the fix.

    
I think that it should be down to the module author/owner to
      decide whether or not it is a bug fix or an enhancement, and I
      would just like a versioning scheme that allows these changes to
      be expressed.  None of this changes the fact that I think that we
      should be avoiding making these changes in the first place.  I.e.
      I think that there is a clear separation between what the
      versioning scheme should be able to express, and what is
      recommended practice. 

    

    


    

    

      

        


        

        


        

        
2) SEMVER to the rescue?

        
If every module release can be its own feature release
          train then the value of

        
ascending numeric identifiers is greatly diminished. The
          (m) and (M) tags

        
do not really help.  I strongly agree with the comment that
          cherry-picking new

        
features can (and should) be done with deviations.  Updates
          of old

        
revisions needs to be for bugfixes only.

      

    

    

      

        


        

        
I prefer the OpenConfig "SEMVER Classic" rather than
          introducing a new

        
incompatible complex numbering scheme to support something
          that

        
should not be done anyway.

      

    

    
SEMVER classic does not support making bug fixes (even bc ones)
      on older releases.

    
In an older release, SEMVER classic allows:

       - editorial changes, e.g. spelling corrections or clarifications
      in description statements that do not change the API semantics in
      anyway.

       - bug fixes to the *implementation*, but then we are not using
      SEMVER to version the implementation anyway, only the API.

    

    
If you want to allow bug fixes (even just bc ones) in an older
      release then you either need something like modified semver, or a
      different versioning scheme that allows them.  Or you do what Rob
      Shakir suggests and use deviations for this instead, which I think
      is a misuse of deviations.

    

    

      

        


        

        
3) Bundles and compatibility modules

        
I strongly agree this solution approach is far better than
          treating every revision

        
as a separate feature release train.  I don't see how I am
          going to

        
track the major.minor.patch for 100 different modules. 
          SEMVER is not

        
very useful for telling if module A works with B, C, and D.
          Import by SEMVER

        
will probably be OK at first, but become too error-prone
          after awhile.

      

    

    
+1.  I think that the versioning solution needs to consider
      something like bundles or packages.

    

    


    

    

      

        


        

        
4) Automation tools

        
Ad-hoc WEB pages from IANA do not cut it anymore.

        
We need a way to get patch versions of modules published
          and usable

        
by automation tools (without an RFC) with just the Errata
          report as a patch.

        
SEMVER requires that a module be released with the change
          but this is not that practical.

      

    

    
I think that we need to have a place where all revisions of
      modules are published and easily accessible.

    

    


    

    

      

        
Think how yocto works, using a base source version of a
          package + patches.

        
(IMO we need YANG Packages, which would serve as recipes

        
for a set of modules, features, annotations, patches and
          deviations, that have been

        
tested to work together.)

        


        

        
5) YANG 1.2 vs Extensions

        
IMO a new YANG version would be better than extensions,
          especially to

        
fix status-stmt, import-by-revision, deviations, and add
          annotation,

        
patch, and many other new mechanisms to help backward
          compatibility.

      

    

    
Perhaps.  There is currently a long list of stuff on the
      YANG.next issue tracker.  My concern is that this effort will get
      bogged down.

    
Also, some of these changes we want to apply across YANG language
      versions.  E.g. I want the updated status behaviour to apply to
      all YANG modules on the server, regardless of whether of which
      version of YANG they were defined in.

    
Thanks,

      Rob

    


    

    

      

        


        

        


        

        
Andy

        


        

      

      

      

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


    

  


--------------ADC87AFC156945E17C80FC29--


From nobody Wed Nov 14 03:48:47 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAFB130DDE for ; Wed, 14 Nov 2018 03:48:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 F272yyZ7qRt0 for ; Wed, 14 Nov 2018 03:48:43 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 83043130DD6 for ; Wed, 14 Nov 2018 03:48:43 -0800 (PST)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 67AB81AE0351; Wed, 14 Nov 2018 12:48:42 +0100 (CET)
Date: Wed, 14 Nov 2018 12:48:41 +0100 (CET)
Message-Id: <20181114.124841.232214537179191240.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] comments on YANG versioning
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2018 11:48:45 -0000

Hi,

Robert Wilton  wrote:
> =

> On 08/11/2018 22:52, Andy Bierman wrote:
> > Hi,
> >
> > A few comments on the netmod meeting yesterday
> >
> > 1) what is a bugfix?
> > It is not encouraging that the DT cannot agree on the scope of a
> > bugfix.
> > But not sure it matters if NBC updates can occur for any reason.
> > IMO it is easy to define a bugfix in the IETF -- it is called an
> > Errata.
> > If an Errata is approved for a YANG module in an RFC then it is a
> > bugfix.
> =

> Ultimately we have customers that will say "this part of your YANG is=

> broken" and we want you to fix it in that release train, either in th=
e
> next release, or as a software patch.
> =

> Sometimes vendors will disagree with their customers as to whether it=

> is really a bug fix or an enhancement.=A0 Sometimes we will fix what =
we
> think is an obvious bug but that will unfortunately break another
> customer whom was relying on the existing behavior and then ask us to=

> revert the fix.
> =

> I think that it should be down to the module author/owner to decide
> whether or not it is a bug fix or an enhancement, and I would just
> like a versioning scheme that allows these changes to be expressed.=A0=


So the requirement is that the versioning scheme must support
branching, and must support expressing NBC changes on any version?

This requirement isn't present in the current draft, AFAICT.

(not that I support it as a requirement)


> None of this changes the fact that I think that we should be avoiding=

> making these changes in the first place.=A0 I.e. I think that there i=
s a
> clear separation between what the versioning scheme should be able to=

> express, and what is recommended practice.
> =

> =

> >
> >
> > 2) SEMVER to the rescue?
> > If every module release can be its own feature release train then t=
he
> > value of
> > ascending numeric identifiers is greatly diminished. The (m) and (M=
)
> > tags
> > do not really help.=A0 I strongly agree with the comment that
> > cherry-picking new
> > features can (and should) be done with deviations.=A0 Updates of ol=
d
> > revisions needs to be for bugfixes only.
> >
> > I prefer the OpenConfig "SEMVER Classic" rather than introducing a =
new
> > incompatible complex numbering scheme to support something that
> > should not be done anyway.
> =

> SEMVER classic does not support making bug fixes (even bc ones) on
> older releases.
> =

> In an older release, SEMVER classic allows:
> =A0- editorial changes, e.g. spelling corrections or clarifications i=
n
> description statements that do not change the API semantics in anyway=
.=

> =A0- bug fixes to the *implementation*, but then we are not using SEM=
VER
> to version the implementation anyway, only the API.
> =

> If you want to allow bug fixes (even just bc ones) in an older releas=
e
> then you either need something like modified semver, or a different
> versioning scheme that allows them.=A0 Or you do what Rob Shakir
> suggests and use deviations for this instead, which I think is a
> misuse of deviations.

But, as you state in the solution draft, not even modified semver can
determine if a specific change is NBC or not.  It seems you would need
the entire history to determine this - which goes against the original
idea that a client should be able to easily determine if a new version
is NBC or not, compared to the version the client knows.


/martin


From nobody Wed Nov 14 05:46: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 01BBC130E66; Wed, 14 Nov 2018 05:46:06 -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 IBPJz3EMLPQW; Wed, 14 Nov 2018 05:46:03 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id A5299130E58; Wed, 14 Nov 2018 05:46:03 -0800 (PST)
Received: from [192.168.2.5] (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id CAE70600C1; Wed, 14 Nov 2018 13:46:02 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Christian Hopps 
In-Reply-To: <96b1510e-2d12-32ba-4609-009b4e86d790@cisco.com>
Date: Wed, 14 Nov 2018 08:46:01 -0500
Cc: Christian Hopps , joel jaeggli , NETMOD Working Group , draft-ietf-netmod-module-tags.authors@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>   <96b1510e-2d12-32ba-4609-009b4e86d790@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: 
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2018 13:46:06 -0000

Do you have similar objections over comments in CLI config files? =
Routers (the server) certainly don't use those and clients write them =
and read them -- yet they are stored on the server. Perhaps if you =
thought of there being more than just one client possible this might all =
make more sense?

Regarding the yang library you keep bringing up. This was in the work =
originally and the WG decided that we should remove it. I do not think =
the tail end of a WGLC is an appropriate time or place to start =
wondering out loud about whether it would be a good to have. I admit to =
being confused by this since I believe you were actively participating =
WRT this work when it had the yang library augmentation as well as after =
we removed it.

I'm OK with taking the editorial suggestions. I'm not so OK with going =
back and redoing this document or it's fundamental design at the tail =
end of a WGLC. Unless the WG agrees that it's truly broken. This would =
be pretty odd given it seemed like we were done, including during the =
103 meeting in which you were in attendance.

You say your not trying to hold the work up; however, that is exactly =
what your last minute public pondering is doing.

Thanks,
Chris.

> On Nov 14, 2018, at 5:04 AM, Robert Wilton  wrote:
>=20
> Hi Chris,
>=20
> On 13/11/2018 21:05, Christian Hopps wrote:
>> The servers implement the modules which can have predefined tags from =
the module designer as well as the implementer (vendor) which literally =
cannot come from anywhere *but* the server that implements the module.
>=20
> Clients should also be able to know find out the predefined tags from =
the module definition.  I agree that the any tags added by the =
implementation can only be known by querying the server, although its =
not obvious to me what those tags would be.  E.g. if Cisco had a YANG =
module for EIGRP and wanted to give it the ietf:protocol and =
ietf:routing tag then it would ideally use the extension and put it in =
the YANG file.
>=20
>> This is not what I thought would hold this work up.
>=20
> Sorry, I'm not trying to hold anything up.
>=20
> It not obvious to me how the ietf-module-tags modules will actually be =
used on a device:
>  1) being able to ask a device: "What are all the YANG modules that =
are implemented on this device that are routing protocols" seems a =
useful thing to do.  Although personally I would ideally want the answer =
in the context of YANG library.  I.e. to see the modules with the given =
tags, along with module evision/version, features and any deviations.  =
This can probably be achieved today with an appropriate xpath query, if =
supported, or could perhaps be achieved more easily if the operational =
list of tags also augmented the module entries in the YANG library =
structure.  But perhaps for your envisaged use case just getting back =
the list of modules with that tag is sufficient and is what you are =
after.
>=20
> Is this how you are envisaging YANG module tags would be used, and if =
so, would it do any harm to add a short section near the intro =
explaining this (and perhaps the YANG catalogue example as well)?  Or do =
you think that this would just be needless noise.
>=20
> 2) Being able to filter queried data based on tags may also be useful, =
but this would require protocol extensions, perhaps something to be done =
in future?
>=20
> Thanks,
> Rob
>=20
>=20
>>=20
>> Thanks,
>> Chris.
>>=20
>>> On Nov 13, 2018, at 5:58 AM, Robert Wilton  =
wrote:
>>>=20
>>> Hi Joel, authors,
>>>=20
>>> I have to confess that I didn't have time to review this during the =
last call (but have reviewed/provided comments on previous versions).
>>>=20
>>> These comments may be too late, but I will provide them anyway, so =
make of them what you will :-)
>>>=20
>>> In summary, I like the idea of tags and I think that they are a good =
fit for classifying YANG models.  In particular, I think that a flexible =
classification of YANG modules is better than a rigid structure that can =
never be changed.
>>>=20
>>> For me the one of the great utilities of module tags could be in =
applications like YANG catalog search =
(https://yangcatalog.org/yang-search/).  Being able to search for =
modules by tag seems like it would be a particularly useful thing to be =
able to do.
>>>=20
>>> However, I do have some sympathy with Alex's comment, in that it is =
a bit unclear as to benefits of configuring the tag information on the =
devices.  At the moment, the configuration doesn't have any material =
affect on the device, and the only thing that a client can do is read =
back the tag configuration.  Is the intention that the protocols may be =
extended in future to allow filter queries to be based on module tags?
>>>=20
>>> So, I am supportive of Alex's comment that it would give the =
document more clarity if some of the specific use cases could be =
described.
>>>=20
>>>=20
>>> Some other random comments/nits:
>>>=20
>>> 1) 6087bis references can be updated to RFC 8407.  Is a reference =
even allowed in the abstract?
>>>=20
>>> 2) Abstract: "writing a modules tags" =3D> "writing a module's tags" =
or "writing module tags"
>>>=20
>>> 3) The module is YANG 1.1, so RFC 6020 reference can be changed to =
RFC 7950.
>>>=20
>>> 4) Section 3.4: Should there be a tag prefix for "experimental"? Or =
perhaps this would be "ietf:experimental:" anyway.
>>>=20
>>> 5) Section 5.1: It might be useful if the tags were also reported =
under YANG library, e.g. as an augmentation to rfc7895bis.  E.g. this =
would report the same information as "modules-tags/module[name]/tag" =
leaf-list.
>>>=20
>>> 6) YANG module: Should you limit the maximum size of a tag? Perhaps =
to 255, or 1000 characters.
>>>=20
>>> 7) Line length for "The operational view of this list is constructed =
..." looks like it may be too long.
>>>=20
>>> 8) Section 7, Guidelines to authors.  I was wondering if this =
section should state that YANG modules SHOULD define standard tags that =
are associated with it.  At the moment, it just states what can be done, =
without providing guidance of what should be done.
>>>=20
>>> 9) Section 9.2.  A few more possible categories: discovery protocol, =
vpn, tunnel.  I'm not sure that I particularly like "rfc8199-" as a =
module name, and possibly "classification-" would be better.
>>>=20
>>> Apologies for the tardy review comments,
>>> Rob
>>>=20
>>>=20
>>> On 12/11/2018 16:46, joel jaeggli wrote:
>>>> During the Thursday nov 8 session of netmod, we asked if there were =
any objections to the publication of the Draft-03 version of =
draft-ietf-netmod-module-tags which addresses comments and concerns =
raised during the WGLC. In the meeting there were none. This commences a =
comment period to confirm that call. As this follows closely on the =
heels of the IETF 103 meeting we=E2=80=99ll let the call run through =
Monday the 26th of November.
>>>>=20
>>>> =
https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-module-tags-03.txt=

>>>>=20
>>>>=20
>>>> Thanks
>>>> Joel
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> .


From nobody Wed Nov 14 07:14:28 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4525C130EA5; Wed, 14 Nov 2018 07:14:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level: 
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJ0f8y3_GQLS; Wed, 14 Nov 2018 07:14: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 EE0461292AD; Wed, 14 Nov 2018 07:14:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9278; q=dns/txt; s=iport; t=1542208463; x=1543418063; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ivZyYAimj09TW4ThNdgR5+xPK3XJgywC4mwt06gS/Xk=; b=l9EitSpyNSIzY04QZqKVNrS0uJJvEEyM4PN23Pf9XLFm3O8gIGksHy7X jrY1UThISIoOe/GuOMDDg3CuTSL6qt+U//8vKfgTcRmudPzsOma3981GD IRpSbJSvkWhqQOmheaGr/+w/QucSkWaub17Wrbm471pmwermBk1XuYjLN c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACQOuxb/xbLJq1iGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVWBFE8hEieDeIgYX4x6LZc2FIFmDRg?= =?us-ascii?q?NhAFGAoNrNA0NAQMBAQIBAQJtHAyFOgEBAQMBAQEhDwEFNgsFCwsOCgICJgI?= =?us-ascii?q?CJzAGDQYCAQEXgwYBgXkID6gAgS+FQIRnBYELixGBQD+BESeBbX6DGwEBAgE?= =?us-ascii?q?XgSEOAoMaglcCiUMDgTqECZBVCYZ3iiUGGIFYiAEmhnaBToteg3yGWYFFOIF?= =?us-ascii?q?VMxoIGxU7gmyCJwUSiF6FPj8DMAGLGoJMAQE?=
X-IronPort-AV: E=Sophos;i="5.56,232,1539648000";  d="scan'208";a="7986029"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2018 15:14:20 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id wAEFEKmX014747; Wed, 14 Nov 2018 15:14:20 GMT
To: Christian Hopps 
Cc: joel jaeggli , NETMOD Working Group , draft-ietf-netmod-module-tags.authors@ietf.org
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>   <96b1510e-2d12-32ba-4609-009b4e86d790@cisco.com> 
From: Robert Wilton 
Message-ID: <794f077a-898a-b351-411b-6c1879c69ffd@cisco.com>
Date: Wed, 14 Nov 2018 15:14:19 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2018 15:14:26 -0000

Hi Chris,

On 14/11/2018 13:46, Christian Hopps wrote:
> Do you have similar objections over comments in CLI config files?

No, not at all.

But one difference here is that the tags are bound to modules, not to 
the config, or config paths.

>   Routers (the server) certainly don't use those and clients write them and read them -- yet they are stored on the server. Perhaps if you thought of there being more than just one client possible this might all make more sense?

Yes, perhaps.


>
> Regarding the yang library you keep bringing up. This was in the work originally and the WG decided that we should remove it.

Sorry, I had missed the WG discussion where this was removed. But OK.


>   I do not think the tail end of a WGLC is an appropriate time or place to start wondering out loud about whether it would be a good to have. I admit to being confused by this since I believe you were actively participating WRT this work when it had the yang library augmentation as well as after we removed it.

My apologies, but I had intended to review this more thoroughly during 
the WG LC but ran out of time.  If was when I read Alex's comments that 
I thought that he was raising some valid points. The key one that struck 
a chord is that this document describes a solution but doesn't seem to 
clearly describe what problem it is solving (other than tags are good), 
or how it is intending to be used.  When I reviewed this document after 
reading Alex's comments, I was asking myself how this was going to be 
used, and the answer I came up with was that I didn't really know.  Or 
the case that I had in mind (YANG catalog filtering on module tag) 
doesn't seem to match the authors envisaged use cases.  Looking back at 
some of the previous comments on this work (not just Alex), others have 
also questioned what problem it is solving and how it will be used.


> I'm OK with taking the editorial suggestions. I'm not so OK with going back and redoing this document or it's fundamental design at the tail end of a WGLC. Unless the WG agrees that it's truly broken. This would be pretty odd given it seemed like we were done, including during the 103 meeting in which you were in attendance.
>
> You say your not trying to hold the work up; however, that is exactly what your last minute public pondering is doing.

Yes, I admit that I should have reviewed it earlier.  My aim is not to 
slow it down but to ensure that the document is as clear as possible.  
As I've said lots of times, I like the idea of tags for classifying YANG 
modules :-)

Given all that, it is still my opinion that this document would benefit 
from the introduction being slightly clearer on the specific problem 
being solved - e.g. I think that the abstract is more clear than the 
introduction, and also think that the document would benefit having some 
examples of how module tags could be used.

But I appreciate that my comments are after the WGLC and have no issues 
if the authors/chairs decide that they are too late.  After all, no one 
else, other than Alex, has expressed any concern.

Thanks,
Rob


>
> Thanks,
> Chris.
>
>> On Nov 14, 2018, at 5:04 AM, Robert Wilton  wrote:
>>
>> Hi Chris,
>>
>> On 13/11/2018 21:05, Christian Hopps wrote:
>>> The servers implement the modules which can have predefined tags from the module designer as well as the implementer (vendor) which literally cannot come from anywhere *but* the server that implements the module.
>> Clients should also be able to know find out the predefined tags from the module definition.  I agree that the any tags added by the implementation can only be known by querying the server, although its not obvious to me what those tags would be.  E.g. if Cisco had a YANG module for EIGRP and wanted to give it the ietf:protocol and ietf:routing tag then it would ideally use the extension and put it in the YANG file.
>>
>>> This is not what I thought would hold this work up.
>> Sorry, I'm not trying to hold anything up.
>>
>> It not obvious to me how the ietf-module-tags modules will actually be used on a device:
>>   1) being able to ask a device: "What are all the YANG modules that are implemented on this device that are routing protocols" seems a useful thing to do.  Although personally I would ideally want the answer in the context of YANG library.  I.e. to see the modules with the given tags, along with module evision/version, features and any deviations.  This can probably be achieved today with an appropriate xpath query, if supported, or could perhaps be achieved more easily if the operational list of tags also augmented the module entries in the YANG library structure.  But perhaps for your envisaged use case just getting back the list of modules with that tag is sufficient and is what you are after.
>>
>> Is this how you are envisaging YANG module tags would be used, and if so, would it do any harm to add a short section near the intro explaining this (and perhaps the YANG catalogue example as well)?  Or do you think that this would just be needless noise.
>>
>> 2) Being able to filter queried data based on tags may also be useful, but this would require protocol extensions, perhaps something to be done in future?
>>
>> Thanks,
>> Rob
>>
>>
>>> Thanks,
>>> Chris.
>>>
>>>> On Nov 13, 2018, at 5:58 AM, Robert Wilton  wrote:
>>>>
>>>> Hi Joel, authors,
>>>>
>>>> I have to confess that I didn't have time to review this during the last call (but have reviewed/provided comments on previous versions).
>>>>
>>>> These comments may be too late, but I will provide them anyway, so make of them what you will :-)
>>>>
>>>> In summary, I like the idea of tags and I think that they are a good fit for classifying YANG models.  In particular, I think that a flexible classification of YANG modules is better than a rigid structure that can never be changed.
>>>>
>>>> For me the one of the great utilities of module tags could be in applications like YANG catalog search (https://yangcatalog.org/yang-search/).  Being able to search for modules by tag seems like it would be a particularly useful thing to be able to do.
>>>>
>>>> However, I do have some sympathy with Alex's comment, in that it is a bit unclear as to benefits of configuring the tag information on the devices.  At the moment, the configuration doesn't have any material affect on the device, and the only thing that a client can do is read back the tag configuration.  Is the intention that the protocols may be extended in future to allow filter queries to be based on module tags?
>>>>
>>>> So, I am supportive of Alex's comment that it would give the document more clarity if some of the specific use cases could be described.
>>>>
>>>>
>>>> Some other random comments/nits:
>>>>
>>>> 1) 6087bis references can be updated to RFC 8407.  Is a reference even allowed in the abstract?
>>>>
>>>> 2) Abstract: "writing a modules tags" => "writing a module's tags" or "writing module tags"
>>>>
>>>> 3) The module is YANG 1.1, so RFC 6020 reference can be changed to RFC 7950.
>>>>
>>>> 4) Section 3.4: Should there be a tag prefix for "experimental"? Or perhaps this would be "ietf:experimental:" anyway.
>>>>
>>>> 5) Section 5.1: It might be useful if the tags were also reported under YANG library, e.g. as an augmentation to rfc7895bis.  E.g. this would report the same information as "modules-tags/module[name]/tag" leaf-list.
>>>>
>>>> 6) YANG module: Should you limit the maximum size of a tag? Perhaps to 255, or 1000 characters.
>>>>
>>>> 7) Line length for "The operational view of this list is constructed ..." looks like it may be too long.
>>>>
>>>> 8) Section 7, Guidelines to authors.  I was wondering if this section should state that YANG modules SHOULD define standard tags that are associated with it.  At the moment, it just states what can be done, without providing guidance of what should be done.
>>>>
>>>> 9) Section 9.2.  A few more possible categories: discovery protocol, vpn, tunnel.  I'm not sure that I particularly like "rfc8199-" as a module name, and possibly "classification-" would be better.
>>>>
>>>> Apologies for the tardy review comments,
>>>> Rob
>>>>
>>>>
>>>> On 12/11/2018 16:46, joel jaeggli wrote:
>>>>> During the Thursday nov 8 session of netmod, we asked if there were any objections to the publication of the Draft-03 version of draft-ietf-netmod-module-tags which addresses comments and concerns raised during the WGLC. In the meeting there were none. This commences a comment period to confirm that call. As this follows closely on the heels of the IETF 103 meeting we’ll let the call run through Monday the 26th of November.
>>>>>
>>>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-03.txt
>>>>>
>>>>>
>>>>> Thanks
>>>>> Joel
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> .
> .
>


From nobody Wed Nov 14 07:48: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 367F3130E5D for ; Wed, 14 Nov 2018 07:48:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.969
X-Spam-Level: 
X-Spam-Status: No, score=-14.969 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 6w48GMmQFqSA for ; Wed, 14 Nov 2018 07:48:05 -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 5B3F4124BAA for ; Wed, 14 Nov 2018 07:48:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13991; q=dns/txt; s=iport; t=1542210484; x=1543420084; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=ZAGIXmx0MZ5WbPSck7nQ0QMl10L9yZvLSCBDT3dU3VA=; b=Jz2gxE5a48Wqef2VMsBVZhp/SVUuWDUO0CgnTnKQb093PSTmCi2Asx6l 8/e6VGBN3yP3g9YZS+n+j2sNiQ8p+7YSW0p196jBPpmzRW26UG++D+BF8 4SrSbB9WYoYxutJXOVUmt1egZbyeRj+DjfMXNqWZbe08HYdv5WpCKrkt4 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAAAZQ+xb/xbLJq1iGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwMBAQEBCwGBDUiBYyESJ4N4iHeMei2RYoVUgXoNgXeCdQK?= =?us-ascii?q?DazYLDQEDAQECAQECbSiFOgEBAQMBI1YQCw4KKgICVwYNBgIBAReDBoF6CKg?= =?us-ascii?q?UgS8fhSGEa4wcgUA/gREngmuEaIMaglcCiUOWGwmRHAYYiVmHHJEohlmBTAs?= =?us-ascii?q?mgVUzGggbFYMnkFo/AzCNZwEB?=
X-IronPort-AV: E=Sophos;i="5.56,232,1539648000"; d="scan'208,217";a="7986185"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Nov 2018 15:47:59 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id wAEFlw0B026003; Wed, 14 Nov 2018 15:47:59 GMT
To: Martin Bjorklund 
Cc: andy@yumaworks.com, netmod@ietf.org
References:   <20181114.124841.232214537179191240.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: 
Date: Wed, 14 Nov 2018 15:47:58 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <20181114.124841.232214537179191240.mbj@tail-f.com>
Content-Type: multipart/alternative; boundary="------------C5850CD6CCAB2952939D28DC"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: 
Subject: Re: [netmod] comments on YANG versioning
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2018 15:48:07 -0000

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

Hi Martin,

On 14/11/2018 11:48, Martin Bjorklund wrote:
> Hi,
>
> Robert Wilton  wrote:
>> On 08/11/2018 22:52, Andy Bierman wrote:
>>> Hi,
>>>
>>> A few comments on the netmod meeting yesterday
>>>
>>> 1) what is a bugfix?
>>> It is not encouraging that the DT cannot agree on the scope of a
>>> bugfix.
>>> But not sure it matters if NBC updates can occur for any reason.
>>> IMO it is easy to define a bugfix in the IETF -- it is called an
>>> Errata.
>>> If an Errata is approved for a YANG module in an RFC then it is a
>>> bugfix.
>> Ultimately we have customers that will say "this part of your YANG is
>> broken" and we want you to fix it in that release train, either in the
>> next release, or as a software patch.
>>
>> Sometimes vendors will disagree with their customers as to whether it
>> is really a bug fix or an enhancement.  Sometimes we will fix what we
>> think is an obvious bug but that will unfortunately break another
>> customer whom was relying on the existing behavior and then ask us to
>> revert the fix.
>>
>> I think that it should be down to the module author/owner to decide
>> whether or not it is a bug fix or an enhancement, and I would just
>> like a versioning scheme that allows these changes to be expressed.
> So the requirement is that the versioning scheme must support
> branching, and must support expressing NBC changes on any version?

I deem that 1.4 (without the sentence about versioning by software 
release) defines this:

        1.4  The solution MUST allow for backwards-compatible
             enhancements and bug fixes to be allowed in any non-latest
             release.

Although this text is ambiguous, perhaps stating it more clearly, I see 
the requirement as:

        1.4  The solution MUST allow for backwards-compatible
             enhancements, and backward-compatible or non-backwards compatible
             bug fixes to be allowed in non-latest releases.


>
> This requirement isn't present in the current draft, AFAICT.
>
> (not that I support it as a requirement)

But vendors *have* to do this today.  I don't think telling our 
customers that no, we can't fix that bug, because the versioning scheme 
doesn't allow it is really pragmatic.

Rob Shakir also indicated in the Netmod meeting that he does not support 
this requirement.  However, this conflicts with the fact that there are 
examples in OpenConfig when it has been necessary to apply fixes to 
older versions, which has been achieved using deviations.


>
>
>> None of this changes the fact that I think that we should be avoiding
>> making these changes in the first place.  I.e. I think that there is a
>> clear separation between what the versioning scheme should be able to
>> express, and what is recommended practice.
>>
>>
>>>
>>> 2) SEMVER to the rescue?
>>> If every module release can be its own feature release train then the
>>> value of
>>> ascending numeric identifiers is greatly diminished. The (m) and (M)
>>> tags
>>> do not really help.  I strongly agree with the comment that
>>> cherry-picking new
>>> features can (and should) be done with deviations.  Updates of old
>>> revisions needs to be for bugfixes only.
>>>
>>> I prefer the OpenConfig "SEMVER Classic" rather than introducing a new
>>> incompatible complex numbering scheme to support something that
>>> should not be done anyway.
>> SEMVER classic does not support making bug fixes (even bc ones) on
>> older releases.
>>
>> In an older release, SEMVER classic allows:
>>   - editorial changes, e.g. spelling corrections or clarifications in
>> description statements that do not change the API semantics in anyway.
>>   - bug fixes to the *implementation*, but then we are not using SEMVER
>> to version the implementation anyway, only the API.
>>
>> If you want to allow bug fixes (even just bc ones) in an older release
>> then you either need something like modified semver, or a different
>> versioning scheme that allows them.  Or you do what Rob Shakir
>> suggests and use deviations for this instead, which I think is a
>> misuse of deviations.
> But, as you state in the solution draft, not even modified semver can
> determine if a specific change is NBC or not.  It seems you would need
> the entire history to determine this - which goes against the original
> idea that a client should be able to easily determine if a new version
> is NBC or not, compared to the version the client knows.

The (m|M) is intended to be a tool of last resort.  So provide a 
mechanism to make bug fixes to older versions, but don't encourage it.  
It provides a mechanism to provide bug fixes on an existing release, but 
at the cost that you lose some of the benefits of semver (which is 
unavoidable).

If the server is on a version of the form "A.B.X(m)" then the client 
knows that all changes between "A.B.0" and "A.B.X(m)" are backwards 
compatible.  If the version is "A.B.X(M)" then the client knows that 
there is at least one nbc change between "A.B.0" and "A.B.X(M)".  The 
client does not know whether going from "A.B.X(m|M)" to "A.B+1.0" is a 
backwards incompatible change or not.

Thanks,
Rob


>
>
> /martin
> .
>

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


  
    
  
  
    
Hi Martin,

    

    
On 14/11/2018 11:48, Martin Bjorklund
      wrote:

    

    

      
Hi,

Robert Wilton <rwilton@cisco.com> wrote:


      

        
On 08/11/2018 22:52, Andy Bierman wrote:


        

          
Hi,

A few comments on the netmod meeting yesterday

1) what is a bugfix?
It is not encouraging that the DT cannot agree on the scope of a
bugfix.
But not sure it matters if NBC updates can occur for any reason.
IMO it is easy to define a bugfix in the IETF -- it is called an
Errata.
If an Errata is approved for a YANG module in an RFC then it is a
bugfix.


        

        
Ultimately we have customers that will say "this part of your YANG is
broken" and we want you to fix it in that release train, either in the
next release, or as a software patch.

Sometimes vendors will disagree with their customers as to whether it
is really a bug fix or an enhancement.  Sometimes we will fix what we
think is an obvious bug but that will unfortunately break another
customer whom was relying on the existing behavior and then ask us to
revert the fix.

I think that it should be down to the module author/owner to decide
whether or not it is a bug fix or an enhancement, and I would just
like a versioning scheme that allows these changes to be expressed. 


      

      
So the requirement is that the versioning scheme must support
branching, and must support expressing NBC changes on any version?

    

    
I deem that 1.4 (without the sentence about versioning by
      software release) defines this:

    
       1.4  The solution MUST allow for backwards-compatible
            enhancements and bug fixes to be allowed in any non-latest
            release.

    
Although this text is ambiguous, perhaps stating it more clearly,
      I see the requirement as:

    

    
       1.4  The solution MUST allow for backwards-compatible
            enhancements, and backward-compatible or non-backwards compatible 
            bug fixes to be allowed in non-latest releases.

    


    

    

      

This requirement isn't present in the current draft, AFAICT.

(not that I support it as a requirement)

    

    
But vendors *have* to do this today.  I don't think telling our
      customers that no, we can't fix that bug, because the versioning
      scheme doesn't allow it is really pragmatic.

    
Rob Shakir also indicated in the Netmod meeting that he does not
      support this requirement.  However, this conflicts with the fact
      that there are examples in OpenConfig when it has been necessary
      to apply fixes to older versions, which has been achieved using
      deviations.

    

    


    

    

      




      

        
None of this changes the fact that I think that we should be avoiding
making these changes in the first place.  I.e. I think that there is a
clear separation between what the versioning scheme should be able to
express, and what is recommended practice.




        

          

2) SEMVER to the rescue?
If every module release can be its own feature release train then the
value of
ascending numeric identifiers is greatly diminished. The (m) and (M)
tags
do not really help.  I strongly agree with the comment that
cherry-picking new
features can (and should) be done with deviations.  Updates of old
revisions needs to be for bugfixes only.

I prefer the OpenConfig "SEMVER Classic" rather than introducing a new
incompatible complex numbering scheme to support something that
should not be done anyway.


        

        
SEMVER classic does not support making bug fixes (even bc ones) on
older releases.

In an older release, SEMVER classic allows:
 - editorial changes, e.g. spelling corrections or clarifications in
description statements that do not change the API semantics in anyway.
 - bug fixes to the *implementation*, but then we are not using SEMVER
to version the implementation anyway, only the API.

If you want to allow bug fixes (even just bc ones) in an older release
then you either need something like modified semver, or a different
versioning scheme that allows them.  Or you do what Rob Shakir
suggests and use deviations for this instead, which I think is a
misuse of deviations.


      

      
But, as you state in the solution draft, not even modified semver can
determine if a specific change is NBC or not.  It seems you would need
the entire history to determine this - which goes against the original
idea that a client should be able to easily determine if a new version
is NBC or not, compared to the version the client knows.

    

    
The (m|M) is intended to be a tool of last resort.  So provide a
      mechanism to make bug fixes to older versions, but don't encourage
      it.  It provides a mechanism to provide bug fixes on an existing
      release, but at the cost that you lose some of the benefits of
      semver (which is unavoidable).

    
If the server is on a version of the form "A.B.X(m)" then the
      client knows that all changes between "A.B.0" and "A.B.X(m)" are
      backwards compatible.  If the version is "A.B.X(M)" then the
      client knows that there is at least one nbc change between "A.B.0"
      and "A.B.X(M)".  The client does not know whether going from
      "A.B.X(m|M)" to "A.B+1.0" is a backwards incompatible change or
      not. 

    

    
Thanks,

      Rob

    

    


    

    

      


/martin
.



    

  


--------------C5850CD6CCAB2952939D28DC--


From nobody Wed Nov 14 08:04:37 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7AF124BAA for ; Wed, 14 Nov 2018 08:04:35 -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 BtVRtY1L6wxn for ; Wed, 14 Nov 2018 08:04:30 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7A3130EC6 for ; Wed, 14 Nov 2018 08:04:29 -0800 (PST)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 615C01AE0351; Wed, 14 Nov 2018 17:04:27 +0100 (CET)
Date: Wed, 14 Nov 2018 17:04:26 +0100 (CET)
Message-Id: <20181114.170426.2226367966445007155.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <20181114.124841.232214537179191240.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] comments on YANG versioning
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2018 16:04:35 -0000

Robert Wilton  wrote:
> Hi Martin,
> =

> On 14/11/2018 11:48, Martin Bjorklund wrote:
> > Hi,
> >
> > Robert Wilton  wrote:
> >> On 08/11/2018 22:52, Andy Bierman wrote:
> >>> Hi,
> >>>
> >>> A few comments on the netmod meeting yesterday
> >>>
> >>> 1) what is a bugfix?
> >>> It is not encouraging that the DT cannot agree on the scope of a
> >>> bugfix.
> >>> But not sure it matters if NBC updates can occur for any reason.
> >>> IMO it is easy to define a bugfix in the IETF -- it is called an
> >>> Errata.
> >>> If an Errata is approved for a YANG module in an RFC then it is a=

> >>> bugfix.
> >> Ultimately we have customers that will say "this part of your YANG=
 is
> >> broken" and we want you to fix it in that release train, either in=
 the
> >> next release, or as a software patch.
> >>
> >> Sometimes vendors will disagree with their customers as to whether=
 it
> >> is really a bug fix or an enhancement.=A0 Sometimes we will fix wh=
at we
> >> think is an obvious bug but that will unfortunately break another
> >> customer whom was relying on the existing behavior and then ask us=
 to
> >> revert the fix.
> >>
> >> I think that it should be down to the module author/owner to decid=
e
> >> whether or not it is a bug fix or an enhancement, and I would just=

> >> like a versioning scheme that allows these changes to be expressed=
.=

> > So the requirement is that the versioning scheme must support
> > branching, and must support expressing NBC changes on any version?
> =

> I deem that 1.4 (without the sentence about versioning by software
> release) defines this:
> =

>        1.4  The solution MUST allow for backwards-compatible
>             enhancements and bug fixes to be allowed in any non-lates=
t
>             release.
> =

> Although this text is ambiguous, perhaps stating it more clearly, I
> see the requirement as:
> =

>        1.4  The solution MUST allow for backwards-compatible
>             enhancements, and backward-compatible or non-backwards co=
mpatible
>             bug fixes to be allowed in non-latest releases.
> =

> =

> >
> > This requirement isn't present in the current draft, AFAICT.
> >
> > (not that I support it as a requirement)
> =

> But vendors *have* to do this today.=A0 I don't think telling our
> customers that no, we can't fix that bug, because the versioning
> scheme doesn't allow it is really pragmatic.

The pragmatic thing to do is to violate the rule when you think your
customers can accept it, and introduce a NBC even though it doesn't
follow 7950 section 11 rules.

> Rob Shakir also indicated in the Netmod meeting that he does not
> support this requirement.=A0 However, this conflicts with the fact th=
at
> there are examples in OpenConfig when it has been necessary to apply
> fixes to older versions, which has been achieved using deviations.
> =

> =

> >
> >
> >> None of this changes the fact that I think that we should be avoid=
ing
> >> making these changes in the first place.=A0 I.e. I think that ther=
e is a
> >> clear separation between what the versioning scheme should be able=
 to
> >> express, and what is recommended practice.
> >>
> >>
> >>>
> >>> 2) SEMVER to the rescue?
> >>> If every module release can be its own feature release train then=
 the
> >>> value of
> >>> ascending numeric identifiers is greatly diminished. The (m) and =
(M)
> >>> tags
> >>> do not really help.=A0 I strongly agree with the comment that
> >>> cherry-picking new
> >>> features can (and should) be done with deviations.=A0 Updates of =
old
> >>> revisions needs to be for bugfixes only.
> >>>
> >>> I prefer the OpenConfig "SEMVER Classic" rather than introducing =
a new
> >>> incompatible complex numbering scheme to support something that
> >>> should not be done anyway.
> >> SEMVER classic does not support making bug fixes (even bc ones) on=

> >> older releases.
> >>
> >> In an older release, SEMVER classic allows:
> >>  =A0- editorial changes, e.g. spelling corrections or clarificatio=
ns in
> >> description statements that do not change the API semantics in any=
way.
> >>  =A0- bug fixes to the *implementation*, but then we are not using=
 SEMVER
> >> to version the implementation anyway, only the API.
> >>
> >> If you want to allow bug fixes (even just bc ones) in an older rel=
ease
> >> then you either need something like modified semver, or a differen=
t
> >> versioning scheme that allows them.=A0 Or you do what Rob Shakir
> >> suggests and use deviations for this instead, which I think is a
> >> misuse of deviations.
> > But, as you state in the solution draft, not even modified semver c=
an
> > determine if a specific change is NBC or not.  It seems you would n=
eed
> > the entire history to determine this - which goes against the origi=
nal
> > idea that a client should be able to easily determine if a new vers=
ion
> > is NBC or not, compared to the version the client knows.
> =

> The (m|M) is intended to be a tool of last resort.=A0 So provide a
> mechanism to make bug fixes to older versions, but don't encourage
> it.=A0 It provides a mechanism to provide bug fixes on an existing
> release, but at the cost that you lose some of the benefits of semver=

> (which is unavoidable).

Suppose I have version 1.2.3M.  Now I make an editorial fix to this
module, what is the next version?  1.2.4 or 1.2.4M?


/martin




> =

> If the server is on a version of the form "A.B.X(m)" then the client
> knows that all changes between "A.B.0" and "A.B.X(m)" are backwards
> compatible.=A0 If the version is "A.B.X(M)" then the client knows tha=
t
> there is at least one nbc change between "A.B.0" and "A.B.X(M)".=A0 T=
he
> client does not know whether going from "A.B.X(m|M)" to "A.B+1.0" is =
a
> backwards incompatible change or not.
> =

> Thanks,
> Rob
> =

> =

> >
> >
> > /martin
> > .
> >


From nobody Wed Nov 14 08:38: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 E50BF130E95 for ; Wed, 14 Nov 2018 08:38:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.97
X-Spam-Level: 
X-Spam-Status: No, score=-14.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VghUU6jSSfEE for ; Wed, 14 Nov 2018 08:38:03 -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 9CC6D130E61 for ; Wed, 14 Nov 2018 08:38:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9270; q=dns/txt; s=iport; t=1542213482; x=1543423082; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=oiXkWkB2uR44GjzHNWrQN8B+aho/0OCVH+vh+hIEIJQ=; b=BB811YI7RqBODcupcWKRAml6zeVVqyxXFQAmq5UOqURAgXJRo+psZLQr ekClxJsvKahUiW+RvCTv4dPh23sj2WsW/Yn0sa++CrWNsxxrBjYRnjaAf zbvXTeLVEWOsiMrmpDL3pps+HHMQJkUbXZC2UjfK61hvMn62tNv96YVSY U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAACGTuxb/xbLJq1jGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUwQBAQELAYM4IRIng3iId4x6CCWXNoF6DYF3gnUCg2s2Cw0BAwE?= =?us-ascii?q?BAgEBAm0ohToBAQEDASMPAQVBEAsOCgICJgICVwYNBgIBAReDBoF6CKgSgS+?= =?us-ascii?q?FQIRrgQuLEYFAP4ERJwyCX4RXARAJgxGCVwKJQ5YbCZEcBhiBWIgBhxyJXYd?= =?us-ascii?q?LhlmBTAQtgVUzGggbFYMnkFo/AzCLGgEBJIInAQE?=
X-IronPort-AV: E=Sophos;i="5.56,233,1539648000";  d="scan'208";a="8048024"
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; 14 Nov 2018 16:38:00 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id wAEGbxhg030250; Wed, 14 Nov 2018 16:37:59 GMT
To: Martin Bjorklund 
Cc: andy@yumaworks.com, netmod@ietf.org
References:  <20181114.124841.232214537179191240.mbj@tail-f.com>  <20181114.170426.2226367966445007155.mbj@tail-f.com>
From: Robert Wilton 
Message-ID: <56acc545-392c-b423-1232-0b3f6170fb9c@cisco.com>
Date: Wed, 14 Nov 2018 16:37:59 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <20181114.170426.2226367966445007155.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-4.cisco.com
Archived-At: 
Subject: Re: [netmod] comments on YANG versioning
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2018 16:38:06 -0000

On 14/11/2018 16:04, Martin Bjorklund wrote:
> Robert Wilton  wrote:
>> Hi Martin,
>>
>> On 14/11/2018 11:48, Martin Bjorklund wrote:
>>> Hi,
>>>
>>> Robert Wilton  wrote:
>>>> On 08/11/2018 22:52, Andy Bierman wrote:
>>>>> Hi,
>>>>>
>>>>> A few comments on the netmod meeting yesterday
>>>>>
>>>>> 1) what is a bugfix?
>>>>> It is not encouraging that the DT cannot agree on the scope of a
>>>>> bugfix.
>>>>> But not sure it matters if NBC updates can occur for any reason.
>>>>> IMO it is easy to define a bugfix in the IETF -- it is called an
>>>>> Errata.
>>>>> If an Errata is approved for a YANG module in an RFC then it is a
>>>>> bugfix.
>>>> Ultimately we have customers that will say "this part of your YANG is
>>>> broken" and we want you to fix it in that release train, either in the
>>>> next release, or as a software patch.
>>>>
>>>> Sometimes vendors will disagree with their customers as to whether it
>>>> is really a bug fix or an enhancement.  Sometimes we will fix what we
>>>> think is an obvious bug but that will unfortunately break another
>>>> customer whom was relying on the existing behavior and then ask us to
>>>> revert the fix.
>>>>
>>>> I think that it should be down to the module author/owner to decide
>>>> whether or not it is a bug fix or an enhancement, and I would just
>>>> like a versioning scheme that allows these changes to be expressed.
>>> So the requirement is that the versioning scheme must support
>>> branching, and must support expressing NBC changes on any version?
>> I deem that 1.4 (without the sentence about versioning by software
>> release) defines this:
>>
>>         1.4  The solution MUST allow for backwards-compatible
>>              enhancements and bug fixes to be allowed in any non-latest
>>              release.
>>
>> Although this text is ambiguous, perhaps stating it more clearly, I
>> see the requirement as:
>>
>>         1.4  The solution MUST allow for backwards-compatible
>>              enhancements, and backward-compatible or non-backwards compatible
>>              bug fixes to be allowed in non-latest releases.
>>
>>
>>> This requirement isn't present in the current draft, AFAICT.
>>>
>>> (not that I support it as a requirement)
>> But vendors *have* to do this today.  I don't think telling our
>> customers that no, we can't fix that bug, because the versioning
>> scheme doesn't allow it is really pragmatic.
> The pragmatic thing to do is to violate the rule when you think your
> customers can accept it, and introduce a NBC even though it doesn't
> follow 7950 section 11 rules.

Yes, but say we adopt vanilla semver, it cannot express this as an NBC 
change, or even as a BC change!

Say the released software on the server is using module version 1.2.0.  
Module versions 1.3.0 and 2.0.0 already exist with new added 
functionality (that we can't/won't backport)

Is it really right to label the fixed version as a patch update (e.g. 
going from 1.2.0 to 1.2.1, which semver states is an editorial change) 
even through it is actually an NBC change and could break some clients?

This is the reason that I introduced the modified semver scheme, so that 
it could be labelled as "1.2.1(M)".  I.e. the client can easily 
determine that it is an NBC update.

Of course, if there isn't a "2.0.0" version at the time that an NBC fix 
is made to 1.2.0 then it should follow the normal semver rules and use 
"2.0.0" instead.  The "(m|M)" notation is only used whether there isn't 
a semver number available to use because it has already been used for 
new development.  Similarly, if the code change that was present in 
"1.3.0" was only an BC bugfix, and if the fix being made was BC, then it 
would be recommended to use "1.4.0" for the bug fix version.  I.e. 
although I don't think that it pragmatic to require that new 
functionality be backported to an old release to pick up a bug fix, it 
does seem more pragmatic to think that a bug fix could be back ported to 
an older software release, if required. But ultimately I think that it 
is at the discretion of the module author to decide where to put the 
fix, with the suggestion that if it is created as  "1.2.1(M)" then the 
fix should probably also be made to head of the tree ("3.0.0") as well.

The real aim of the modified semver solution is to be able to describe 
these changes, rather than say that they are good or bad.  Hence 
guidance would be provided to recommend how they are used.

---

If the modified semver solution is really disliked, then an alternative 
is to just not use semver, and use a 3 digit version number, e.g. as I 
proposed to Juergen yesterday, when the "patch" field always means bug 
fix.  This has the downside that it is incompatible with what OpenConfig 
is doing though, and clients would have to use a schema compare tool to 
understand the changes between two modules.

>
>> Rob Shakir also indicated in the Netmod meeting that he does not
>> support this requirement.  However, this conflicts with the fact that
>> there are examples in OpenConfig when it has been necessary to apply
>> fixes to older versions, which has been achieved using deviations.
>>
>>
>>>
>>>> None of this changes the fact that I think that we should be avoiding
>>>> making these changes in the first place.  I.e. I think that there is a
>>>> clear separation between what the versioning scheme should be able to
>>>> express, and what is recommended practice.
>>>>
>>>>
>>>>> 2) SEMVER to the rescue?
>>>>> If every module release can be its own feature release train then the
>>>>> value of
>>>>> ascending numeric identifiers is greatly diminished. The (m) and (M)
>>>>> tags
>>>>> do not really help.  I strongly agree with the comment that
>>>>> cherry-picking new
>>>>> features can (and should) be done with deviations.  Updates of old
>>>>> revisions needs to be for bugfixes only.
>>>>>
>>>>> I prefer the OpenConfig "SEMVER Classic" rather than introducing a new
>>>>> incompatible complex numbering scheme to support something that
>>>>> should not be done anyway.
>>>> SEMVER classic does not support making bug fixes (even bc ones) on
>>>> older releases.
>>>>
>>>> In an older release, SEMVER classic allows:
>>>>    - editorial changes, e.g. spelling corrections or clarifications in
>>>> description statements that do not change the API semantics in anyway.
>>>>    - bug fixes to the *implementation*, but then we are not using SEMVER
>>>> to version the implementation anyway, only the API.
>>>>
>>>> If you want to allow bug fixes (even just bc ones) in an older release
>>>> then you either need something like modified semver, or a different
>>>> versioning scheme that allows them.  Or you do what Rob Shakir
>>>> suggests and use deviations for this instead, which I think is a
>>>> misuse of deviations.
>>> But, as you state in the solution draft, not even modified semver can
>>> determine if a specific change is NBC or not.  It seems you would need
>>> the entire history to determine this - which goes against the original
>>> idea that a client should be able to easily determine if a new version
>>> is NBC or not, compared to the version the client knows.
>> The (m|M) is intended to be a tool of last resort.  So provide a
>> mechanism to make bug fixes to older versions, but don't encourage
>> it.  It provides a mechanism to provide bug fixes on an existing
>> release, but at the cost that you lose some of the benefits of semver
>> (which is unavoidable).
> Suppose I have version 1.2.3M.  Now I make an editorial fix to this
> module, what is the next version?  1.2.4 or 1.2.4M?

1.2.4M.

Once you have put a "m" or "M" on an x.y._ branch, it is effectively 
poisoned to always keep the letter on that branch (although 'm' would be 
upgraded to 'M' in a NBC change is made). E.g. 3.4.5m could go to 3.4.6M.

My assumption here is that 'm' and 'M' should only be used 
infrequently.  If they end up being used heavily then the scheme does 
not work so well.  But in this case, this really points to the fact that 
the YANG modules need more review and to be more stable before they are 
released.  Again, the aim here is to make the m|M syntax to be somewhat 
limited to discourage and somewhat limit its use.

E.g. a more general solution here would be to allow a separate semver 
for each place where a bugfix is required.  E.g. if you but an nbc 
bugfix on branch "1.2.3" then that could be "1.2.3/2.0.0" ... but I see 
that this is adding way too much branch flexibility and complexity.

Thanks,
Rob


>
>
> /martin
>
>
>
>
>> If the server is on a version of the form "A.B.X(m)" then the client
>> knows that all changes between "A.B.0" and "A.B.X(m)" are backwards
>> compatible.  If the version is "A.B.X(M)" then the client knows that
>> there is at least one nbc change between "A.B.0" and "A.B.X(M)".  The
>> client does not know whether going from "A.B.X(m|M)" to "A.B+1.0" is a
>> backwards incompatible change or not.
>>
>> Thanks,
>> Rob
>>
>>
>>>
>>> /martin
>>> .
>>>
> .
>


From nobody Wed Nov 14 08:44:05 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1CC5130E61; Wed, 14 Nov 2018 08:44:03 -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 poVwT2qiCpuA; Wed, 14 Nov 2018 08:44:01 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id D8326130DD7; Wed, 14 Nov 2018 08:44:00 -0800 (PST)
Received: from [192.168.2.5] (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 1C2E060024; Wed, 14 Nov 2018 16:44:00 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Christian Hopps 
In-Reply-To: <794f077a-898a-b351-411b-6c1879c69ffd@cisco.com>
Date: Wed, 14 Nov 2018 11:43:59 -0500
Cc: Christian Hopps , joel jaeggli , NETMOD Working Group , draft-ietf-netmod-module-tags.authors@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4EFB8243-F05B-404B-A638-CAD439D491FD@chopps.org>
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>   <96b1510e-2d12-32ba-4609-009b4e86d790@cisco.com>  <794f077a-898a-b351-411b-6c1879c69ffd@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: 
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2018 16:44:04 -0000

> On Nov 14, 2018, at 10:14 AM, Robert Wilton  wrote:
>=20
> Hi Chris,
>=20
> On 14/11/2018 13:46, Christian Hopps wrote:
>> Do you have similar objections over comments in CLI config files?
>=20
> No, not at all.
>=20
> But one difference here is that the tags are bound to modules, not to =
the config, or config paths.

This has nothing to do with the point I am addressing that you and Alex =
raised regarding "Servers not using the tags so why should they store =
them".

The answer is:

1) B/c there's literally no where else they could be stored (no way for =
a vendor to add tags)
2) There are other examples of servers storing things they don't use =
like comments, so "server not using what it stores" isn't a reason to =
not store them on the server in the first place.

Regarding the rest. Maybe we should write a requirements draft and a use =
cases draft for the use of meta-data/tags for organizing things.

And maybe let's put this work on hold until we can find someone that is =
willing to do all that busy work.

I understand more and more why openconfig exists.

Thanks,
Chris.

>=20
>>  Routers (the server) certainly don't use those and clients write =
them and read them -- yet they are stored on the server. Perhaps if you =
thought of there being more than just one client possible this might all =
make more sense?
>=20
> Yes, perhaps.
>=20
>=20
>>=20
>> Regarding the yang library you keep bringing up. This was in the work =
originally and the WG decided that we should remove it.
>=20
> Sorry, I had missed the WG discussion where this was removed. But OK.
>=20
>=20
>>  I do not think the tail end of a WGLC is an appropriate time or =
place to start wondering out loud about whether it would be a good to =
have. I admit to being confused by this since I believe you were =
actively participating WRT this work when it had the yang library =
augmentation as well as after we removed it.
>=20
> My apologies, but I had intended to review this more thoroughly during =
the WG LC but ran out of time.  If was when I read Alex's comments that =
I thought that he was raising some valid points. The key one that struck =
a chord is that this document describes a solution but doesn't seem to =
clearly describe what problem it is solving (other than tags are good), =
or how it is intending to be used.  When I reviewed this document after =
reading Alex's comments, I was asking myself how this was going to be =
used, and the answer I came up with was that I didn't really know.  Or =
the case that I had in mind (YANG catalog filtering on module tag) =
doesn't seem to match the authors envisaged use cases.  Looking back at =
some of the previous comments on this work (not just Alex), others have =
also questioned what problem it is solving and how it will be used.
>=20
>=20
>> I'm OK with taking the editorial suggestions. I'm not so OK with =
going back and redoing this document or it's fundamental design at the =
tail end of a WGLC. Unless the WG agrees that it's truly broken. This =
would be pretty odd given it seemed like we were done, including during =
the 103 meeting in which you were in attendance.
>>=20
>> You say your not trying to hold the work up; however, that is exactly =
what your last minute public pondering is doing.
>=20
> Yes, I admit that I should have reviewed it earlier.  My aim is not to =
slow it down but to ensure that the document is as clear as possible.  =
As I've said lots of times, I like the idea of tags for classifying YANG =
modules :-)
>=20
> Given all that, it is still my opinion that this document would =
benefit from the introduction being slightly clearer on the specific =
problem being solved - e.g. I think that the abstract is more clear than =
the introduction, and also think that the document would benefit having =
some examples of how module tags could be used.
>=20
> But I appreciate that my comments are after the WGLC and have no =
issues if the authors/chairs decide that they are too late.  After all, =
no one else, other than Alex, has expressed any concern.
>=20
> Thanks,
> Rob
>=20
>=20
>>=20
>> Thanks,
>> Chris.
>>=20
>>> On Nov 14, 2018, at 5:04 AM, Robert Wilton  =
wrote:
>>>=20
>>> Hi Chris,
>>>=20
>>> On 13/11/2018 21:05, Christian Hopps wrote:
>>>> The servers implement the modules which can have predefined tags =
from the module designer as well as the implementer (vendor) which =
literally cannot come from anywhere *but* the server that implements the =
module.
>>> Clients should also be able to know find out the predefined tags =
from the module definition.  I agree that the any tags added by the =
implementation can only be known by querying the server, although its =
not obvious to me what those tags would be.  E.g. if Cisco had a YANG =
module for EIGRP and wanted to give it the ietf:protocol and =
ietf:routing tag then it would ideally use the extension and put it in =
the YANG file.
>>>=20
>>>> This is not what I thought would hold this work up.
>>> Sorry, I'm not trying to hold anything up.
>>>=20
>>> It not obvious to me how the ietf-module-tags modules will actually =
be used on a device:
>>>  1) being able to ask a device: "What are all the YANG modules that =
are implemented on this device that are routing protocols" seems a =
useful thing to do.  Although personally I would ideally want the answer =
in the context of YANG library.  I.e. to see the modules with the given =
tags, along with module evision/version, features and any deviations.  =
This can probably be achieved today with an appropriate xpath query, if =
supported, or could perhaps be achieved more easily if the operational =
list of tags also augmented the module entries in the YANG library =
structure.  But perhaps for your envisaged use case just getting back =
the list of modules with that tag is sufficient and is what you are =
after.
>>>=20
>>> Is this how you are envisaging YANG module tags would be used, and =
if so, would it do any harm to add a short section near the intro =
explaining this (and perhaps the YANG catalogue example as well)?  Or do =
you think that this would just be needless noise.
>>>=20
>>> 2) Being able to filter queried data based on tags may also be =
useful, but this would require protocol extensions, perhaps something to =
be done in future?
>>>=20
>>> Thanks,
>>> Rob
>>>=20
>>>=20
>>>> Thanks,
>>>> Chris.
>>>>=20
>>>>> On Nov 13, 2018, at 5:58 AM, Robert Wilton  =
wrote:
>>>>>=20
>>>>> Hi Joel, authors,
>>>>>=20
>>>>> I have to confess that I didn't have time to review this during =
the last call (but have reviewed/provided comments on previous =
versions).
>>>>>=20
>>>>> These comments may be too late, but I will provide them anyway, so =
make of them what you will :-)
>>>>>=20
>>>>> In summary, I like the idea of tags and I think that they are a =
good fit for classifying YANG models.  In particular, I think that a =
flexible classification of YANG modules is better than a rigid structure =
that can never be changed.
>>>>>=20
>>>>> For me the one of the great utilities of module tags could be in =
applications like YANG catalog search =
(https://yangcatalog.org/yang-search/).  Being able to search for =
modules by tag seems like it would be a particularly useful thing to be =
able to do.
>>>>>=20
>>>>> However, I do have some sympathy with Alex's comment, in that it =
is a bit unclear as to benefits of configuring the tag information on =
the devices.  At the moment, the configuration doesn't have any material =
affect on the device, and the only thing that a client can do is read =
back the tag configuration.  Is the intention that the protocols may be =
extended in future to allow filter queries to be based on module tags?
>>>>>=20
>>>>> So, I am supportive of Alex's comment that it would give the =
document more clarity if some of the specific use cases could be =
described.
>>>>>=20
>>>>>=20
>>>>> Some other random comments/nits:
>>>>>=20
>>>>> 1) 6087bis references can be updated to RFC 8407.  Is a reference =
even allowed in the abstract?
>>>>>=20
>>>>> 2) Abstract: "writing a modules tags" =3D> "writing a module's =
tags" or "writing module tags"
>>>>>=20
>>>>> 3) The module is YANG 1.1, so RFC 6020 reference can be changed to =
RFC 7950.
>>>>>=20
>>>>> 4) Section 3.4: Should there be a tag prefix for "experimental"? =
Or perhaps this would be "ietf:experimental:" anyway.
>>>>>=20
>>>>> 5) Section 5.1: It might be useful if the tags were also reported =
under YANG library, e.g. as an augmentation to rfc7895bis.  E.g. this =
would report the same information as "modules-tags/module[name]/tag" =
leaf-list.
>>>>>=20
>>>>> 6) YANG module: Should you limit the maximum size of a tag? =
Perhaps to 255, or 1000 characters.
>>>>>=20
>>>>> 7) Line length for "The operational view of this list is =
constructed ..." looks like it may be too long.
>>>>>=20
>>>>> 8) Section 7, Guidelines to authors.  I was wondering if this =
section should state that YANG modules SHOULD define standard tags that =
are associated with it.  At the moment, it just states what can be done, =
without providing guidance of what should be done.
>>>>>=20
>>>>> 9) Section 9.2.  A few more possible categories: discovery =
protocol, vpn, tunnel.  I'm not sure that I particularly like "rfc8199-" =
as a module name, and possibly "classification-" would be better.
>>>>>=20
>>>>> Apologies for the tardy review comments,
>>>>> Rob
>>>>>=20
>>>>>=20
>>>>> On 12/11/2018 16:46, joel jaeggli wrote:
>>>>>> During the Thursday nov 8 session of netmod, we asked if there =
were any objections to the publication of the Draft-03 version of =
draft-ietf-netmod-module-tags which addresses comments and concerns =
raised during the WGLC. In the meeting there were none. This commences a =
comment period to confirm that call. As this follows closely on the =
heels of the IETF 103 meeting we=E2=80=99ll let the call run through =
Monday the 26th of November.
>>>>>>=20
>>>>>> =
https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-module-tags-03.txt=

>>>>>>=20
>>>>>>=20
>>>>>> Thanks
>>>>>> Joel
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> .
>> .


From nobody Wed Nov 14 09:00: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 B7811130E61 for ; Wed, 14 Nov 2018 09:00: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, 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 YvOckSa2Vf87 for ; Wed, 14 Nov 2018 09:00:52 -0800 (PST)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC0A130DE6 for ; Wed, 14 Nov 2018 09:00:51 -0800 (PST)
Received: by mail-lf1-x12e.google.com with SMTP id v5so12036910lfe.7 for ; Wed, 14 Nov 2018 09:00:51 -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=hypJIkMXoPo8Q5CRHoZIe4+2+2G2+3MqH0waKtJUcWo=; b=p0Lwi58nE3xeUjLubSGjCd6Xjk4A0TNBuMG0/EIZLXuEVaQC3I99IdYI/6jFRiTTSa D69aoB/JCOZhvqK8clA/FzFMOJaeebzRvjI9QxK2ho+HEvoNEV0TVIPBjELK3bWWpyXX 4moznaI7+4bY/P0DBQX4WFyMaoKLIB5XVZfMiWPpU0q4WXYuTO55A/ZBryVHIsqzRgEs n46U6Yioa8UvviwTr6bmw8MjWaDShDDOAI9YAZtYI/jnhwy/pzOcICd05G8QvlyU3dLk FmpaAkoYXF9B052tRh/U9t3SLPnMMwfBWYaFPwg2QGRqeL7wHW4zG8PGGkZ9DZY9odob QujA==
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=hypJIkMXoPo8Q5CRHoZIe4+2+2G2+3MqH0waKtJUcWo=; b=m4j9QGAbWIOs1CcqpAKsKM1w83fd+CNsi77XYsj3NANaLH+VJGsXstw7XC3UkJufNU 1u/FnaOUQICgd6Dg9Q2y0ApW6Jdm2ww+0QfCBWajTYjgbAZZmvgpN6b5+619DO6MqCdq Cr/EXGBVJftsT66gA/kbt1FnytbSJPDfs2eVlLYOMhoj0q+yIL4OBzf1TrWGwlhYhRym T/go19WGzBxhm+RmL3gqrtrHSEV9iNs8pbIidG9CVF0AybQIHzRGwjaFh/xiuzmta5Xp jNkmWzT7FK53zOeM2Rfxg+Mqc7rq9EiWo8gF3v25w1nzCW1xgIm7BIYjMubk5MdpBYER 9RUg==
X-Gm-Message-State: AGRZ1gL43B3j7s2+CRoKNAfs3GeSOH1RE5VrAC9SBDDN5ixCNfyjqIFF wlPUaCQLa0YixOwnXu4qS7UZSoQiDPn2qyZmUXh5KLhw
X-Google-Smtp-Source: AJdET5c+68u93ohcAiKLKKXUhtF2Wmhyd1QCZmfL6TJP9ALXLSYo6Sz3za6b13Vuk2g9tW5K3FdJpmu8nMPqoTDUeJE=
X-Received: by 2002:a19:ca51:: with SMTP id h17mr1409204lfj.126.1542214849768;  Wed, 14 Nov 2018 09:00:49 -0800 (PST)
MIME-Version: 1.0
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>   <96b1510e-2d12-32ba-4609-009b4e86d790@cisco.com>  <794f077a-898a-b351-411b-6c1879c69ffd@cisco.com> <4EFB8243-F05B-404B-A638-CAD439D491FD@chopps.org>
In-Reply-To: <4EFB8243-F05B-404B-A638-CAD439D491FD@chopps.org>
From: Andy Bierman 
Date: Wed, 14 Nov 2018 09:00:38 -0800
Message-ID: 
To: Christian Hopps 
Cc: Robert Wilton , joel jaeggli ,  draft-ietf-netmod-module-tags.authors@ietf.org, NetMod WG 
Content-Type: multipart/alternative; boundary="00000000000049cbd2057aa2e0fc"
Archived-At: 
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2018 17:00:58 -0000

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

Hi,

I think there are some legitimate issues that should be addressed for this
work to go forward
wrt/ how it will be used.

1) IANA registry: is this really needed at all? Doesn't the module-tag
extension
make the registry unnecessary?

2) Standard solution: will there be one or is the intent to have
proprietary solutions
to actually utilize module-tags?

3) If there is going to be a standard protocol solution to use module-tags,
then is it
really wise to nail down the tag format before starting work on mechanisms
that use
module tags?

4) How do I distinguish openconfig from mef from bbf from my router vendor?
All their tags seem to share the same prefix "vendor:"  What if I want to
match all routing modules? Then the prefix actually gets in the way because
I have to specify 3 tags ("ietf:routing", "vendor:routing" and
"user:routing")

5) Who decides what module tags apply to a new IETF YANG module?
Is it each independent WG? A design team? The IESG? What guidelines exist
for reviewers to determine if the correct module tags have been assigned?

I do not agree this work is being held up because there is no way to use
a module-tag with any standard protocols.

Andy



On Wed, Nov 14, 2018 at 8:44 AM Christian Hopps  wrote:

>
>
> > On Nov 14, 2018, at 10:14 AM, Robert Wilton  wrote:
> >
> > Hi Chris,
> >
> > On 14/11/2018 13:46, Christian Hopps wrote:
> >> Do you have similar objections over comments in CLI config files?
> >
> > No, not at all.
> >
> > But one difference here is that the tags are bound to modules, not to
> the config, or config paths.
>
> This has nothing to do with the point I am addressing that you and Alex
> raised regarding "Servers not using the tags so why should they store the=
m".
>
> The answer is:
>
> 1) B/c there's literally no where else they could be stored (no way for a
> vendor to add tags)
> 2) There are other examples of servers storing things they don't use like
> comments, so "server not using what it stores" isn't a reason to not stor=
e
> them on the server in the first place.
>
> Regarding the rest. Maybe we should write a requirements draft and a use
> cases draft for the use of meta-data/tags for organizing things.
>
> And maybe let's put this work on hold until we can find someone that is
> willing to do all that busy work.
>
> I understand more and more why openconfig exists.
>
> Thanks,
> Chris.
>
> >
> >>  Routers (the server) certainly don't use those and clients write them
> and read them -- yet they are stored on the server. Perhaps if you though=
t
> of there being more than just one client possible this might all make mor=
e
> sense?
> >
> > Yes, perhaps.
> >
> >
> >>
> >> Regarding the yang library you keep bringing up. This was in the work
> originally and the WG decided that we should remove it.
> >
> > Sorry, I had missed the WG discussion where this was removed. But OK.
> >
> >
> >>  I do not think the tail end of a WGLC is an appropriate time or place
> to start wondering out loud about whether it would be a good to have. I
> admit to being confused by this since I believe you were actively
> participating WRT this work when it had the yang library augmentation as
> well as after we removed it.
> >
> > My apologies, but I had intended to review this more thoroughly during
> the WG LC but ran out of time.  If was when I read Alex's comments that I
> thought that he was raising some valid points. The key one that struck a
> chord is that this document describes a solution but doesn't seem to
> clearly describe what problem it is solving (other than tags are good), o=
r
> how it is intending to be used.  When I reviewed this document after
> reading Alex's comments, I was asking myself how this was going to be use=
d,
> and the answer I came up with was that I didn't really know.  Or the case
> that I had in mind (YANG catalog filtering on module tag) doesn't seem to
> match the authors envisaged use cases.  Looking back at some of the
> previous comments on this work (not just Alex), others have also question=
ed
> what problem it is solving and how it will be used.
> >
> >
> >> I'm OK with taking the editorial suggestions. I'm not so OK with going
> back and redoing this document or it's fundamental design at the tail end
> of a WGLC. Unless the WG agrees that it's truly broken. This would be
> pretty odd given it seemed like we were done, including during the 103
> meeting in which you were in attendance.
> >>
> >> You say your not trying to hold the work up; however, that is exactly
> what your last minute public pondering is doing.
> >
> > Yes, I admit that I should have reviewed it earlier.  My aim is not to
> slow it down but to ensure that the document is as clear as possible.  As
> I've said lots of times, I like the idea of tags for classifying YANG
> modules :-)
> >
> > Given all that, it is still my opinion that this document would benefit
> from the introduction being slightly clearer on the specific problem bein=
g
> solved - e.g. I think that the abstract is more clear than the
> introduction, and also think that the document would benefit having some
> examples of how module tags could be used.
> >
> > But I appreciate that my comments are after the WGLC and have no issues
> if the authors/chairs decide that they are too late.  After all, no one
> else, other than Alex, has expressed any concern.
> >
> > Thanks,
> > Rob
> >
> >
> >>
> >> Thanks,
> >> Chris.
> >>
> >>> On Nov 14, 2018, at 5:04 AM, Robert Wilton  wrote:
> >>>
> >>> Hi Chris,
> >>>
> >>> On 13/11/2018 21:05, Christian Hopps wrote:
> >>>> The servers implement the modules which can have predefined tags fro=
m
> the module designer as well as the implementer (vendor) which literally
> cannot come from anywhere *but* the server that implements the module.
> >>> Clients should also be able to know find out the predefined tags from
> the module definition.  I agree that the any tags added by the
> implementation can only be known by querying the server, although its not
> obvious to me what those tags would be.  E.g. if Cisco had a YANG module
> for EIGRP and wanted to give it the ietf:protocol and ietf:routing tag th=
en
> it would ideally use the extension and put it in the YANG file.
> >>>
> >>>> This is not what I thought would hold this work up.
> >>> Sorry, I'm not trying to hold anything up.
> >>>
> >>> It not obvious to me how the ietf-module-tags modules will actually b=
e
> used on a device:
> >>>  1) being able to ask a device: "What are all the YANG modules that
> are implemented on this device that are routing protocols" seems a useful
> thing to do.  Although personally I would ideally want the answer in the
> context of YANG library.  I.e. to see the modules with the given tags,
> along with module evision/version, features and any deviations.  This can
> probably be achieved today with an appropriate xpath query, if supported,
> or could perhaps be achieved more easily if the operational list of tags
> also augmented the module entries in the YANG library structure.  But
> perhaps for your envisaged use case just getting back the list of modules
> with that tag is sufficient and is what you are after.
> >>>
> >>> Is this how you are envisaging YANG module tags would be used, and if
> so, would it do any harm to add a short section near the intro explaining
> this (and perhaps the YANG catalogue example as well)?  Or do you think
> that this would just be needless noise.
> >>>
> >>> 2) Being able to filter queried data based on tags may also be useful=
,
> but this would require protocol extensions, perhaps something to be done =
in
> future?
> >>>
> >>> Thanks,
> >>> Rob
> >>>
> >>>
> >>>> Thanks,
> >>>> Chris.
> >>>>
> >>>>> On Nov 13, 2018, at 5:58 AM, Robert Wilton 
> wrote:
> >>>>>
> >>>>> Hi Joel, authors,
> >>>>>
> >>>>> I have to confess that I didn't have time to review this during the
> last call (but have reviewed/provided comments on previous versions).
> >>>>>
> >>>>> These comments may be too late, but I will provide them anyway, so
> make of them what you will :-)
> >>>>>
> >>>>> In summary, I like the idea of tags and I think that they are a goo=
d
> fit for classifying YANG models.  In particular, I think that a flexible
> classification of YANG modules is better than a rigid structure that can
> never be changed.
> >>>>>
> >>>>> For me the one of the great utilities of module tags could be in
> applications like YANG catalog search (
> https://yangcatalog.org/yang-search/).  Being able to search for modules
> by tag seems like it would be a particularly useful thing to be able to d=
o.
> >>>>>
> >>>>> However, I do have some sympathy with Alex's comment, in that it is
> a bit unclear as to benefits of configuring the tag information on the
> devices.  At the moment, the configuration doesn't have any material affe=
ct
> on the device, and the only thing that a client can do is read back the t=
ag
> configuration.  Is the intention that the protocols may be extended in
> future to allow filter queries to be based on module tags?
> >>>>>
> >>>>> So, I am supportive of Alex's comment that it would give the
> document more clarity if some of the specific use cases could be describe=
d.
> >>>>>
> >>>>>
> >>>>> Some other random comments/nits:
> >>>>>
> >>>>> 1) 6087bis references can be updated to RFC 8407.  Is a reference
> even allowed in the abstract?
> >>>>>
> >>>>> 2) Abstract: "writing a modules tags" =3D> "writing a module's tags=
"
> or "writing module tags"
> >>>>>
> >>>>> 3) The module is YANG 1.1, so RFC 6020 reference can be changed to
> RFC 7950.
> >>>>>
> >>>>> 4) Section 3.4: Should there be a tag prefix for "experimental"? Or
> perhaps this would be "ietf:experimental:" anyway.
> >>>>>
> >>>>> 5) Section 5.1: It might be useful if the tags were also reported
> under YANG library, e.g. as an augmentation to rfc7895bis.  E.g. this wou=
ld
> report the same information as "modules-tags/module[name]/tag" leaf-list.
> >>>>>
> >>>>> 6) YANG module: Should you limit the maximum size of a tag? Perhaps
> to 255, or 1000 characters.
> >>>>>
> >>>>> 7) Line length for "The operational view of this list is constructe=
d
> ..." looks like it may be too long.
> >>>>>
> >>>>> 8) Section 7, Guidelines to authors.  I was wondering if this
> section should state that YANG modules SHOULD define standard tags that a=
re
> associated with it.  At the moment, it just states what can be done,
> without providing guidance of what should be done.
> >>>>>
> >>>>> 9) Section 9.2.  A few more possible categories: discovery protocol=
,
> vpn, tunnel.  I'm not sure that I particularly like "rfc8199-" as a modul=
e
> name, and possibly "classification-" would be better.
> >>>>>
> >>>>> Apologies for the tardy review comments,
> >>>>> Rob
> >>>>>
> >>>>>
> >>>>> On 12/11/2018 16:46, joel jaeggli wrote:
> >>>>>> During the Thursday nov 8 session of netmod, we asked if there wer=
e
> any objections to the publication of the Draft-03 version of
> draft-ietf-netmod-module-tags which addresses comments and concerns raise=
d
> during the WGLC. In the meeting there were none. This commences a comment
> period to confirm that call. As this follows closely on the heels of the
> IETF 103 meeting we=E2=80=99ll let the call run through Monday the 26th o=
f November.
> >>>>>>
> >>>>>>
> https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-module-tags-03.tx=
t
> >>>>>>
> >>>>>>
> >>>>>> Thanks
> >>>>>> Joel
> >>>>>> _______________________________________________
> >>>>>> 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
>

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


Hi,

I think there are some legitimate i=
ssues that should be addressed for this work to go forward
wrt/ h=
ow it will be used.

1) IANA registry: is this real=
ly needed at all? Doesn't the module-tag extension
make the r=
egistry unnecessary?

2) Standard solution: will th=
ere be one or is the intent to have proprietary solutions
to actu=
ally utilize module-tags?

3) If there is going to =
be a standard protocol solution to use module-tags, then is it
re=
ally wise to nail down the tag format before starting work on mechanisms th=
at use
module tags?

4) How do I distingu=
ish openconfig from mef from bbf from my router vendor?
All their=
 tags seem to share the same prefix "vendor:"=C2=A0 What if I wan=
t to
match all routing modules? Then the prefix actually gets in =
the way because
I have to specify 3 tags ("ietf:routing"=
;, "vendor:routing" and "user:routing")

<=
/div>
5) Who decides what module tags apply to a new IETF YANG module?<=
/div>
Is it each independent WG? A design team? The IESG? What guidelin=
es exist
for reviewers to determine if the correct module tags ha=
ve been assigned?

I do not agree this work is bein=
g held up because there is no way to use
a module-tag with any st=
andard protocols.

Andy


On Wed, Nov 1=
4, 2018 at 8:44 AM Christian Hopps <chopps@chopps.org> wrote:
<=
br>


> On Nov 14, 2018, at 10:14 AM, Robert Wilton <rwilton@cisco.com> wrote:

> 

> Hi Chris,

> 

> On 14/11/2018 13:46, Christian Hopps wrote:

>> Do you have similar objections over comments in CLI config files?<=
br>
> 

> No, not at all.

> 

> But one difference here is that the tags are bound to modules, not to =
the config, or config paths.



This has nothing to do with the point I am addressing that you and Alex rai=
sed regarding "Servers not using the tags so why should they store the=
m".



The answer is:



1) B/c there's literally no where else they could be stored (no way for=
 a vendor to add tags)

2) There are other examples of servers storing things they don't use li=
ke comments, so "server not using what it stores" isn't a rea=
son to not store them on the server in the first place.



Regarding the rest. Maybe we should write a requirements draft and a use ca=
ses draft for the use of meta-data/tags for organizing things.



And maybe let's put this work on hold until we can find someone that is=
 willing to do all that busy work.



I understand more and more why openconfig exists.



Thanks,

Chris.



> 

>>=C2=A0 Routers (the server) certainly don't use those and clien=
ts write them and read them -- yet they are stored on the server. Perhaps i=
f you thought of there being more than just one client possible this might =
all make more sense?

> 

> Yes, perhaps.

> 

> 

>> 

>> Regarding the yang library you keep bringing up. This was in the w=
ork originally and the WG decided that we should remove it.

> 

> Sorry, I had missed the WG discussion where this was removed. But OK.<=
br>
> 

> 

>>=C2=A0 I do not think the tail end of a WGLC is an appropriate time=
 or place to start wondering out loud about whether it would be a good to h=
ave. I admit to being confused by this since I believe you were actively pa=
rticipating WRT this work when it had the yang library augmentation as well=
 as after we removed it.

> 

> My apologies, but I had intended to review this more thoroughly during=
 the WG LC but ran out of time.=C2=A0 If was when I read Alex's comment=
s that I thought that he was raising some valid points. The key one that st=
ruck a chord is that this document describes a solution but doesn't see=
m to clearly describe what problem it is solving (other than tags are good)=
, or how it is intending to be used.=C2=A0 When I reviewed this document af=
ter reading Alex's comments, I was asking myself how this was going to =
be used, and the answer I came up with was that I didn't really know.=
=C2=A0 Or the case that I had in mind (YANG catalog filtering on module tag=
) doesn't seem to match the authors envisaged use cases.=C2=A0 Looking =
back at some of the previous comments on this work (not just Alex), others =
have also questioned what problem it is solving and how it will be used.
> 

> 

>> I'm OK with taking the editorial suggestions. I'm not so O=
K with going back and redoing this document or it's fundamental design =
at the tail end of a WGLC. Unless the WG agrees that it's truly broken.=
 This would be pretty odd given it seemed like we were done, including duri=
ng the 103 meeting in which you were in attendance.

>> 

>> You say your not trying to hold the work up; however, that is exac=
tly what your last minute public pondering is doing.

> 

> Yes, I admit that I should have reviewed it earlier.=C2=A0 My aim is n=
ot to slow it down but to ensure that the document is as clear as possible.=
=C2=A0 As I've said lots of times, I like the idea of tags for classify=
ing YANG modules :-)

> 

> Given all that, it is still my opinion that this document would benefi=
t from the introduction being slightly clearer on the specific problem bein=
g solved - e.g. I think that the abstract is more clear than the introducti=
on, and also think that the document would benefit having some examples of =
how module tags could be used.

> 

> But I appreciate that my comments are after the WGLC and have no issue=
s if the authors/chairs decide that they are too late.=C2=A0 After all, no =
one else, other than Alex, has expressed any concern.

> 

> Thanks,

> Rob

> 

> 

>> 

>> Thanks,

>> Chris.

>> 

>>> On Nov 14, 2018, at 5:04 AM, Robert Wilton <rwilton@cisco.com> wrote:
>>> 

>>> Hi Chris,

>>> 

>>> On 13/11/2018 21:05, Christian Hopps wrote:

>>>> The servers implement the modules which can have predefine=
d tags from the module designer as well as the implementer (vendor) which l=
iterally cannot come from anywhere *but* the server that implements the mod=
ule.

>>> Clients should also be able to know find out the predefined ta=
gs from the module definition.=C2=A0 I agree that the any tags added by the=
 implementation can only be known by querying the server, although its not =
obvious to me what those tags would be.=C2=A0 E.g. if Cisco had a YANG modu=
le for EIGRP and wanted to give it the ietf:protocol and ietf:routing tag t=
hen it would ideally use the extension and put it in the YANG file.

>>> 

>>>> This is not what I thought would hold this work up.

>>> Sorry, I'm not trying to hold anything up.

>>> 

>>> It not obvious to me how the ietf-module-tags modules will act=
ually be used on a device:

>>>=C2=A0 1) being able to ask a device: "What are all the YA=
NG modules that are implemented on this device that are routing protocols&q=
uot; seems a useful thing to do.=C2=A0 Although personally I would ideally =
want the answer in the context of YANG library.=C2=A0 I.e. to see the modul=
es with the given tags, along with module evision/version, features and any=
 deviations.=C2=A0 This can probably be achieved today with an appropriate =
xpath query, if supported, or could perhaps be achieved more easily if the =
operational list of tags also augmented the module entries in the YANG libr=
ary structure.=C2=A0 But perhaps for your envisaged use case just getting b=
ack the list of modules with that tag is sufficient and is what you are aft=
er.

>>> 

>>> Is this how you are envisaging YANG module tags would be used,=
 and if so, would it do any harm to add a short section near the intro expl=
aining this (and perhaps the YANG catalogue example as well)?=C2=A0 Or do y=
ou think that this would just be needless noise.

>>> 

>>> 2) Being able to filter queried data based on tags may also be=
 useful, but this would require protocol extensions, perhaps something to b=
e done in future?

>>> 

>>> Thanks,

>>> Rob

>>> 

>>> 

>>>> Thanks,

>>>> Chris.

>>>> 

>>>>> On Nov 13, 2018, at 5:58 AM, Robert Wilton <rwilton@cisco.com> w=
rote:

>>>>> 

>>>>> Hi Joel, authors,

>>>>> 

>>>>> I have to confess that I didn't have time to revie=
w this during the last call (but have reviewed/provided comments on previou=
s versions).

>>>>> 

>>>>> These comments may be too late, but I will provide the=
m anyway, so make of them what you will :-)

>>>>> 

>>>>> In summary, I like the idea of tags and I think that t=
hey are a good fit for classifying YANG models.=C2=A0 In particular, I thin=
k that a flexible classification of YANG modules is better than a rigid str=
ucture that can never be changed.

>>>>> 

>>>>> For me the one of the great utilities of module tags c=
ould be in applications like YANG catalog search (https://yangca=
talog.org/yang-search/).=C2=A0 Being able to search for modules by tag =
seems like it would be a particularly useful thing to be able to do.

>>>>> 

>>>>> However, I do have some sympathy with Alex's comme=
nt, in that it is a bit unclear as to benefits of configuring the tag infor=
mation on the devices.=C2=A0 At the moment, the configuration doesn't h=
ave any material affect on the device, and the only thing that a client can=
 do is read back the tag configuration.=C2=A0 Is the intention that the pro=
tocols may be extended in future to allow filter queries to be based on mod=
ule tags?

>>>>> 

>>>>> So, I am supportive of Alex's comment that it woul=
d give the document more clarity if some of the specific use cases could be=
 described.

>>>>> 

>>>>> 

>>>>> Some other random comments/nits:

>>>>> 

>>>>> 1) 6087bis references can be updated to RFC 8407.=C2=
=A0 Is a reference even allowed in the abstract?

>>>>> 

>>>>> 2) Abstract: "writing a modules tags" =3D>=
; "writing a module's tags" or "writing module tags"=
;

>>>>> 

>>>>> 3) The module is YANG 1.1, so RFC 6020 reference can b=
e changed to RFC 7950.

>>>>> 

>>>>> 4) Section 3.4: Should there be a tag prefix for "=
;experimental"? Or perhaps this would be "ietf:experimental:<t=
ag-name>" anyway.

>>>>> 

>>>>> 5) Section 5.1: It might be useful if the tags were al=
so reported under YANG library, e.g. as an augmentation to rfc7895bis.=C2=
=A0 E.g. this would report the same information as "modules-tags/modul=
e[name]/tag" leaf-list.

>>>>> 

>>>>> 6) YANG module: Should you limit the maximum size of a=
 tag? Perhaps to 255, or 1000 characters.

>>>>> 

>>>>> 7) Line length for "The operational view of this =
list is constructed ..." looks like it may be too long.

>>>>> 

>>>>> 8) Section 7, Guidelines to authors.=C2=A0 I was wonde=
ring if this section should state that YANG modules SHOULD define standard =
tags that are associated with it.=C2=A0 At the moment, it just states what =
can be done, without providing guidance of what should be done.

>>>>> 

>>>>> 9) Section 9.2.=C2=A0 A few more possible categories: =
discovery protocol, vpn, tunnel.=C2=A0 I'm not sure that I particularly=
 like "rfc8199-" as a module name, and possibly "classificat=
ion-" would be better.

>>>>> 

>>>>> Apologies for the tardy review comments,

>>>>> Rob

>>>>> 

>>>>> 

>>>>> On 12/11/2018 16:46, joel jaeggli wrote:

>>>>>> During the Thursday nov 8 session of netmod, we as=
ked if there were any objections to the publication of the Draft-03 version=
 of draft-ietf-netmod-module-tags which addresses comments and concerns rai=
sed during the WGLC. In the meeting there were none. This commences a comme=
nt period to confirm that call. As this follows closely on the heels of the=
 IETF 103 meeting we=E2=80=99ll let the call run through Monday the 26th of=
 November.

>>>>>> 

>>>>>> h=
ttps://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-module-tags-03.txt

>>>>>> 

>>>>>> 

>>>>>> Thanks

>>>>>> Joel

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

>>>>>> netmod@ietf.org

>>>>>> https://www.ietf.org/mailman/li=
stinfo/netmod

>>>>> _______________________________________________

>>>>> netmod mailing list

>>>>> n=
etmod@ietf.org

>>>>> https://www.ietf.org/mailman/listin=
fo/netmod

>>>> .

>> .



_______________________________________________

netmod mailing list

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




--00000000000049cbd2057aa2e0fc--


From nobody Wed Nov 14 09:26: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 35BC712958B; Wed, 14 Nov 2018 09:26:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tMpHz80t_k8G; Wed, 14 Nov 2018 09:26:29 -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 126C6128D09; Wed, 14 Nov 2018 09:26:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34171; q=dns/txt; s=iport; t=1542216388; x=1543425988; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=9N7IgNjRGbXPRc4E3X1+dGjZsE9Zpx8WgPuTfAdsrAE=; b=fvdLrN26otgJD+gxPhRBFO4wBI80KFHde2LJTbHlSZb2dcZbEwYckntd bK9OtY79aa/K9oBBbt6KMiBRWQ5CEO0yDmXHs9d3sUYIqzwjMW2ltPpNw iekl3ZtEgLTTWJLo1PZGzdn5QjDLTyrfnsLihUQbTRnbCBeWQnTmLLUTL A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABcWuxb/xbLJq1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ1IgRSBAieDeIgYX4x6LZc2FIFjAw0?= =?us-ascii?q?YAQyEAUYCg2s0DQ0BAwEBAgEBAm0cDIU6AQEBAQIBAQEYCUsLBQsLDgogCgI?= =?us-ascii?q?CJzAGDQYCAQEXgwYBgXkID6gAgS8fhSGEZQWMHIFAP4ERJ4FtfoMbAQECARe?= =?us-ascii?q?BIQ4CgxqCVwKIc1ADgTqECZBVCYZ3iiUGGIFYhQUFgncmhnaBToteg3yGWYF?= =?us-ascii?q?FOIFVMxoIGxU7gmyCJwUSiF6FPj8DMAGLOYJMAQE?=
X-IronPort-AV: E=Sophos;i="5.56,233,1539648000"; d="scan'208,217";a="7988807"
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; 14 Nov 2018 17:26:23 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id wAEHQNc3016319; Wed, 14 Nov 2018 17:26:23 GMT
To: Christian Hopps 
Cc: joel jaeggli , NETMOD Working Group , draft-ietf-netmod-module-tags.authors@ietf.org
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>   <96b1510e-2d12-32ba-4609-009b4e86d790@cisco.com>  <794f077a-898a-b351-411b-6c1879c69ffd@cisco.com> <4EFB8243-F05B-404B-A638-CAD439D491FD@chopps.org>
From: Robert Wilton 
Message-ID: 
Date: Wed, 14 Nov 2018 17:26:22 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <4EFB8243-F05B-404B-A638-CAD439D491FD@chopps.org>
Content-Type: multipart/alternative; boundary="------------C6D2721EE423D2D585CF3014"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: 
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Nov 2018 17:26:32 -0000

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


On 14/11/2018 16:43, Christian Hopps wrote:
>
>> On Nov 14, 2018, at 10:14 AM, Robert Wilton  wrote:
>>
>> Hi Chris,
>>
>> On 14/11/2018 13:46, Christian Hopps wrote:
>>> Do you have similar objections over comments in CLI config files?
>> No, not at all.
>>
>> But one difference here is that the tags are bound to modules, not to the config, or config paths.
> This has nothing to do with the point I am addressing that you and Alex raised regarding "Servers not using the tags so why should they store them".

My point was not that "servers shouldn't have to do this", but more "it 
is isn't obvious why operators want servers to do this".


>
> The answer is:
>
> 1) B/c there's literally no where else they could be stored (no way for a vendor to add tags)
> 2) There are other examples of servers storing things they don't use like comments, so "server not using what it stores" isn't a reason to not store them on the server in the first place.
>
> Regarding the rest. Maybe we should write a requirements draft and a use cases draft for the use of meta-data/tags for organizing things.

That is not what I was suggesting.

I was suggesting text something like this:

Introduction:

OLD:

The use of tags for classification and organization is fairly ubiquitous 
not only within IETF protocols, but in the internet itself (e.g., 
#hashtags). Tags can be usefully standardized, but they can also serve 
as a non-standardized mechanism available for users to define 
themselves. Our solution provides for both cases allowing for the most 
flexibility. In particular, tags may be standardized as well as assigned 
during module definition; assigned by implementations; or dynamically 
defined and set by users.

NEW:

The use of tags for classification and organization is fairly ubiquitous 
not only within IETF protocols, but in the internet itself (e.g., 
#hashtags). One benefit of using tags for organization over a rigid 
structure is that it is more flexible and can more easily adapt over 
time as technologies evolve. Tags can be usefully standardized, but they 
can also serve as a non-standardized mechanism available for users to 
define themselves. This document provides a mechanism to define tags and 
associate them with YANG modules in a flexible manner. In particular, 
tags may be standardized as well as assigned during module definition; 
assigned by implementations; or dynamically defined and set by users.

NEW: 1.1 Some example use cases of YANG module tags

Tags can be used to help filter different discrete categories of YANG 
modules supported by a device. E.g., if modules are suitably tagged, 
then an XPath query can be used to list all of the vendor modules 
supported by a device.

Tags can also be used to help coordination when multiple 
semi-independent clients are interacting with the same devices. E.g., 
one management client could mark that some modules should not be used 
because they have not been verified to behave correctly, so that other 
management clients avoid querying the data associated with those modules.

Tag classification is useful for users searching module repositories 
(e.g. YANG catalog). A query restricted to the 'ietf:routing' module tag 
could be used to return only the IETF YANG modules associated with 
routing. Without tags, a user would need to know the name of all the 
IETF routing protocol YANG modules.

Future management protocol extensions could allow for filtering queries 
of configuration or operational state on a server based on tags. E.g., 
return all operational state related to system-management.


If you think that this text is helpful, and it allowed, then please add 
it, refining as required.  If you think that it detracts from the 
clarify of document, and is superfluous then leave it out, that is also 
fine with me ...

Thanks,
Rob


> And maybe let's put this work on hold until we can find someone that is willing to do all that busy work.
>
> I understand more and more why openconfig exists.
>
> Thanks,
> Chris.
>
>>>   Routers (the server) certainly don't use those and clients write them and read them -- yet they are stored on the server. Perhaps if you thought of there being more than just one client possible this might all make more sense?
>> Yes, perhaps.
>>
>>
>>> Regarding the yang library you keep bringing up. This was in the work originally and the WG decided that we should remove it.
>> Sorry, I had missed the WG discussion where this was removed. But OK.
>>
>>
>>>   I do not think the tail end of a WGLC is an appropriate time or place to start wondering out loud about whether it would be a good to have. I admit to being confused by this since I believe you were actively participating WRT this work when it had the yang library augmentation as well as after we removed it.
>> My apologies, but I had intended to review this more thoroughly during the WG LC but ran out of time.  If was when I read Alex's comments that I thought that he was raising some valid points. The key one that struck a chord is that this document describes a solution but doesn't seem to clearly describe what problem it is solving (other than tags are good), or how it is intending to be used.  When I reviewed this document after reading Alex's comments, I was asking myself how this was going to be used, and the answer I came up with was that I didn't really know.  Or the case that I had in mind (YANG catalog filtering on module tag) doesn't seem to match the authors envisaged use cases.  Looking back at some of the previous comments on this work (not just Alex), others have also questioned what problem it is solving and how it will be used.
>>
>>
>>> I'm OK with taking the editorial suggestions. I'm not so OK with going back and redoing this document or it's fundamental design at the tail end of a WGLC. Unless the WG agrees that it's truly broken. This would be pretty odd given it seemed like we were done, including during the 103 meeting in which you were in attendance.
>>>
>>> You say your not trying to hold the work up; however, that is exactly what your last minute public pondering is doing.
>> Yes, I admit that I should have reviewed it earlier.  My aim is not to slow it down but to ensure that the document is as clear as possible.  As I've said lots of times, I like the idea of tags for classifying YANG modules :-)
>>
>> Given all that, it is still my opinion that this document would benefit from the introduction being slightly clearer on the specific problem being solved - e.g. I think that the abstract is more clear than the introduction, and also think that the document would benefit having some examples of how module tags could be used.
>>
>> But I appreciate that my comments are after the WGLC and have no issues if the authors/chairs decide that they are too late.  After all, no one else, other than Alex, has expressed any concern.
>>
>> Thanks,
>> Rob
>>
>>
>>> Thanks,
>>> Chris.
>>>
>>>> On Nov 14, 2018, at 5:04 AM, Robert Wilton  wrote:
>>>>
>>>> Hi Chris,
>>>>
>>>> On 13/11/2018 21:05, Christian Hopps wrote:
>>>>> The servers implement the modules which can have predefined tags from the module designer as well as the implementer (vendor) which literally cannot come from anywhere *but* the server that implements the module.
>>>> Clients should also be able to know find out the predefined tags from the module definition.  I agree that the any tags added by the implementation can only be known by querying the server, although its not obvious to me what those tags would be.  E.g. if Cisco had a YANG module for EIGRP and wanted to give it the ietf:protocol and ietf:routing tag then it would ideally use the extension and put it in the YANG file.
>>>>
>>>>> This is not what I thought would hold this work up.
>>>> Sorry, I'm not trying to hold anything up.
>>>>
>>>> It not obvious to me how the ietf-module-tags modules will actually be used on a device:
>>>>   1) being able to ask a device: "What are all the YANG modules that are implemented on this device that are routing protocols" seems a useful thing to do.  Although personally I would ideally want the answer in the context of YANG library.  I.e. to see the modules with the given tags, along with module evision/version, features and any deviations.  This can probably be achieved today with an appropriate xpath query, if supported, or could perhaps be achieved more easily if the operational list of tags also augmented the module entries in the YANG library structure.  But perhaps for your envisaged use case just getting back the list of modules with that tag is sufficient and is what you are after.
>>>>
>>>> Is this how you are envisaging YANG module tags would be used, and if so, would it do any harm to add a short section near the intro explaining this (and perhaps the YANG catalogue example as well)?  Or do you think that this would just be needless noise.
>>>>
>>>> 2) Being able to filter queried data based on tags may also be useful, but this would require protocol extensions, perhaps something to be done in future?
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>>> Thanks,
>>>>> Chris.
>>>>>
>>>>>> On Nov 13, 2018, at 5:58 AM, Robert Wilton  wrote:
>>>>>>
>>>>>> Hi Joel, authors,
>>>>>>
>>>>>> I have to confess that I didn't have time to review this during the last call (but have reviewed/provided comments on previous versions).
>>>>>>
>>>>>> These comments may be too late, but I will provide them anyway, so make of them what you will :-)
>>>>>>
>>>>>> In summary, I like the idea of tags and I think that they are a good fit for classifying YANG models.  In particular, I think that a flexible classification of YANG modules is better than a rigid structure that can never be changed.
>>>>>>
>>>>>> For me the one of the great utilities of module tags could be in applications like YANG catalog search (https://yangcatalog.org/yang-search/).  Being able to search for modules by tag seems like it would be a particularly useful thing to be able to do.
>>>>>>
>>>>>> However, I do have some sympathy with Alex's comment, in that it is a bit unclear as to benefits of configuring the tag information on the devices.  At the moment, the configuration doesn't have any material affect on the device, and the only thing that a client can do is read back the tag configuration.  Is the intention that the protocols may be extended in future to allow filter queries to be based on module tags?
>>>>>>
>>>>>> So, I am supportive of Alex's comment that it would give the document more clarity if some of the specific use cases could be described.
>>>>>>
>>>>>>
>>>>>> Some other random comments/nits:
>>>>>>
>>>>>> 1) 6087bis references can be updated to RFC 8407.  Is a reference even allowed in the abstract?
>>>>>>
>>>>>> 2) Abstract: "writing a modules tags" => "writing a module's tags" or "writing module tags"
>>>>>>
>>>>>> 3) The module is YANG 1.1, so RFC 6020 reference can be changed to RFC 7950.
>>>>>>
>>>>>> 4) Section 3.4: Should there be a tag prefix for "experimental"? Or perhaps this would be "ietf:experimental:" anyway.
>>>>>>
>>>>>> 5) Section 5.1: It might be useful if the tags were also reported under YANG library, e.g. as an augmentation to rfc7895bis.  E.g. this would report the same information as "modules-tags/module[name]/tag" leaf-list.
>>>>>>
>>>>>> 6) YANG module: Should you limit the maximum size of a tag? Perhaps to 255, or 1000 characters.
>>>>>>
>>>>>> 7) Line length for "The operational view of this list is constructed ..." looks like it may be too long.
>>>>>>
>>>>>> 8) Section 7, Guidelines to authors.  I was wondering if this section should state that YANG modules SHOULD define standard tags that are associated with it.  At the moment, it just states what can be done, without providing guidance of what should be done.
>>>>>>
>>>>>> 9) Section 9.2.  A few more possible categories: discovery protocol, vpn, tunnel.  I'm not sure that I particularly like "rfc8199-" as a module name, and possibly "classification-" would be better.
>>>>>>
>>>>>> Apologies for the tardy review comments,
>>>>>> Rob
>>>>>>
>>>>>>
>>>>>> On 12/11/2018 16:46, joel jaeggli wrote:
>>>>>>> During the Thursday nov 8 session of netmod, we asked if there were any objections to the publication of the Draft-03 version of draft-ietf-netmod-module-tags which addresses comments and concerns raised during the WGLC. In the meeting there were none. This commences a comment period to confirm that call. As this follows closely on the heels of the IETF 103 meeting we’ll let the call run through Monday the 26th of November.
>>>>>>>
>>>>>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-03.txt
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>> Joel
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>> .
>>> .
> .
>

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


  
    
  
  
    


    

    
On 14/11/2018 16:43, Christian Hopps
      wrote:

    

    

      



      

        
On Nov 14, 2018, at 10:14 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi Chris,

On 14/11/2018 13:46, Christian Hopps wrote:


        

          
Do you have similar objections over comments in CLI config files?


        

        
No, not at all.

But one difference here is that the tags are bound to modules, not to the config, or config paths.


      

      
This has nothing to do with the point I am addressing that you and Alex raised regarding "Servers not using the tags so why should they store them".

    

    
My point was not that "servers shouldn't have to do this", but
      more "it is isn't obvious why operators want servers to do this".

    

    


    

    

      

The answer is:

1) B/c there's literally no where else they could be stored (no way for a vendor to add tags)
2) There are other examples of servers storing things they don't use like comments, so "server not using what it stores" isn't a reason to not store them on the server in the first place.

Regarding the rest. Maybe we should write a requirements draft and a use cases draft for the use of meta-data/tags for organizing things.

    

    
That is not what I was suggesting.

    
I was suggesting text something like this:

    
Introduction:

    
OLD:

    
  The use of tags for classification and organization is fairly
   ubiquitous not only within IETF protocols, but in the internet itself
   (e.g., #hashtags).  Tags can be usefully standardized, but they can
   also serve as a non-standardized mechanism available for users to
   define themselves.  Our solution provides for both cases allowing for
   the most flexibility.  In particular, tags may be standardized as
   well as assigned during module definition; assigned by
   implementations; or dynamically defined and set by users.

    
NEW:

    

    
  The use of tags for classification and organization is fairly
   ubiquitous not only within IETF protocols, but in the internet itself
   (e.g., #hashtags).  One benefit of using tags for organization
   over a rigid structure is that it is more flexible and can more easily
   adapt over time as technologies evolve.  Tags can be usefully
   standardized, but they can also serve as a non-standardized mechanism
   available for users to define themselves. This document provides a
   mechanism to define tags and associate them with YANG modules in a
   flexible manner.  In particular, tags may be standardized as
   well as assigned during module definition; assigned by
   implementations; or dynamically defined and set by users.

    

NEW:
   
1.1 Some example use cases of YANG module tags

    
  Tags can be used to help filter different discrete categories of YANG
  modules supported by a device.  E.g., if modules are suitably tagged,
  then an XPath query can be used to list all of the vendor modules
  supported by a device.


    
  Tags can also be used to help coordination when multiple
  semi-independent clients are interacting with the same devices.  E.g.,
  one management client could mark that some modules should not be used
  because they have not been verified to behave correctly, so that other
  management clients avoid querying the data associated with those
  modules.


    
  Tag classification is useful for users searching module repositories
  (e.g. YANG catalog).  A query restricted to the 'ietf:routing' module
  tag could be used to return only the IETF YANG modules associated with
  routing.  Without tags, a user would need to know the name of all
  the IETF routing protocol YANG modules.


    
  Future management protocol extensions could allow for filtering
  queries of configuration or operational state on a server based on
  tags.  E.g., return all operational state related to system-management.

    


      If you think that this text is helpful, and it allowed, then
      please add it, refining as required.  If you think that it
      detracts from the clarify of document, and is superfluous then
      leave it out, that is also fine with me ... 

    

    
Thanks,

      Rob

    


    

    

      
And maybe let's put this work on hold until we can find someone that is willing to do all that busy work.

I understand more and more why openconfig exists.

Thanks,
Chris.



      

        

        

          
 Routers (the server) certainly don't use those and clients write them and read them -- yet they are stored on the server. Perhaps if you thought of there being more than just one client possible this might all make more sense?


        

        
Yes, perhaps.




        

          
Regarding the yang library you keep bringing up. This was in the work originally and the WG decided that we should remove it.


        

        
Sorry, I had missed the WG discussion where this was removed. But OK.




        

          
 I do not think the tail end of a WGLC is an appropriate time or place to start wondering out loud about whether it would be a good to have. I admit to being confused by this since I believe you were actively participating WRT this work when it had the yang library augmentation as well as after we removed it.


        

        
My apologies, but I had intended to review this more thoroughly during the WG LC but ran out of time.  If was when I read Alex's comments that I thought that he was raising some valid points. The key one that struck a chord is that this document describes a solution but doesn't seem to clearly describe what problem it is solving (other than tags are good), or how it is intending to be used.  When I reviewed this document after reading Alex's comments, I was asking myself how this was going to be used, and the answer I came up with was that I didn't really know.  Or the case that I had in mind (YANG catalog filtering on module tag) doesn't seem to match the authors envisaged use cases.  Looking back at some of the previous comments on this work (not just Alex), others have also questioned what problem it is solving and how it will be used.




        

          
I'm OK with taking the editorial suggestions. I'm not so OK with going back and redoing this document or it's fundamental design at the tail end of a WGLC. Unless the WG agrees that it's truly broken. This would be pretty odd given it seemed like we were done, including during the 103 meeting in which you were in attendance.

You say your not trying to hold the work up; however, that is exactly what your last minute public pondering is doing.


        

        
Yes, I admit that I should have reviewed it earlier.  My aim is not to slow it down but to ensure that the document is as clear as possible.  As I've said lots of times, I like the idea of tags for classifying YANG modules :-)

Given all that, it is still my opinion that this document would benefit from the introduction being slightly clearer on the specific problem being solved - e.g. I think that the abstract is more clear than the introduction, and also think that the document would benefit having some examples of how module tags could be used.

But I appreciate that my comments are after the WGLC and have no issues if the authors/chairs decide that they are too late.  After all, no one else, other than Alex, has expressed any concern.

Thanks,
Rob




        

          
Thanks,
Chris.



          

            
On Nov 14, 2018, at 5:04 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi Chris,

On 13/11/2018 21:05, Christian Hopps wrote:


            

              
The servers implement the modules which can have predefined tags from the module designer as well as the implementer (vendor) which literally cannot come from anywhere *but* the server that implements the module.


            

            
Clients should also be able to know find out the predefined tags from the module definition.  I agree that the any tags added by the implementation can only be known by querying the server, although its not obvious to me what those tags would be.  E.g. if Cisco had a YANG module for EIGRP and wanted to give it the ietf:protocol and ietf:routing tag then it would ideally use the extension and put it in the YANG file.



            

              
This is not what I thought would hold this work up.


            

            
Sorry, I'm not trying to hold anything up.

It not obvious to me how the ietf-module-tags modules will actually be used on a device:
 1) being able to ask a device: "What are all the YANG modules that are implemented on this device that are routing protocols" seems a useful thing to do.  Although personally I would ideally want the answer in the context of YANG library.  I.e. to see the modules with the given tags, along with module evision/version, features and any deviations.  This can probably be achieved today with an appropriate xpath query, if supported, or could perhaps be achieved more easily if the operational list of tags also augmented the module entries in the YANG library structure.  But perhaps for your envisaged use case just getting back the list of modules with that tag is sufficient and is what you are after.

Is this how you are envisaging YANG module tags would be used, and if so, would it do any harm to add a short section near the intro explaining this (and perhaps the YANG catalogue example as well)?  Or do you think that this would just be needless noise.

2) Being able to filter queried data based on tags may also be useful, but this would require protocol extensions, perhaps something to be done in future?

Thanks,
Rob




            

              
Thanks,
Chris.



              

                
On Nov 13, 2018, at 5:58 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi Joel, authors,

I have to confess that I didn't have time to review this during the last call (but have reviewed/provided comments on previous versions).

These comments may be too late, but I will provide them anyway, so make of them what you will :-)

In summary, I like the idea of tags and I think that they are a good fit for classifying YANG models.  In particular, I think that a flexible classification of YANG modules is better than a rigid structure that can never be changed.

For me the one of the great utilities of module tags could be in applications like YANG catalog search (https://yangcatalog.org/yang-search/).  Being able to search for modules by tag seems like it would be a particularly useful thing to be able to do.

However, I do have some sympathy with Alex's comment, in that it is a bit unclear as to benefits of configuring the tag information on the devices.  At the moment, the configuration doesn't have any material affect on the device, and the only thing that a client can do is read back the tag configuration.  Is the intention that the protocols may be extended in future to allow filter queries to be based on module tags?

So, I am supportive of Alex's comment that it would give the document more clarity if some of the specific use cases could be described.


Some other random comments/nits:

1) 6087bis references can be updated to RFC 8407.  Is a reference even allowed in the abstract?

2) Abstract: "writing a modules tags" => "writing a module's tags" or "writing module tags"

3) The module is YANG 1.1, so RFC 6020 reference can be changed to RFC 7950.

4) Section 3.4: Should there be a tag prefix for "experimental"? Or perhaps this would be "ietf:experimental:<tag-name>" anyway.

5) Section 5.1: It might be useful if the tags were also reported under YANG library, e.g. as an augmentation to rfc7895bis.  E.g. this would report the same information as "modules-tags/module[name]/tag" leaf-list.

6) YANG module: Should you limit the maximum size of a tag? Perhaps to 255, or 1000 characters.

7) Line length for "The operational view of this list is constructed ..." looks like it may be too long.

8) Section 7, Guidelines to authors.  I was wondering if this section should state that YANG modules SHOULD define standard tags that are associated with it.  At the moment, it just states what can be done, without providing guidance of what should be done.

9) Section 9.2.  A few more possible categories: discovery protocol, vpn, tunnel.  I'm not sure that I particularly like "rfc8199-" as a module name, and possibly "classification-" would be better.

Apologies for the tardy review comments,
Rob


On 12/11/2018 16:46, joel jaeggli wrote:


                

                  
During the Thursday nov 8 session of netmod, we asked if there were any objections to the publication of the Draft-03 version of draft-ietf-netmod-module-tags which addresses comments and concerns raised during the WGLC. In the meeting there were none. This commences a comment period to confirm that call. As this follows closely on the heels of the IETF 103 meeting we’ll let the call run through Monday the 26th of November.

https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-03.txt


Thanks
Joel
_______________________________________________
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


              

              
.


            

          

          
.


        

      

      
.



    

  


--------------C6D2721EE423D2D585CF3014--


From nobody Wed Nov 14 20:43: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 D2B0A130E05 for ; Wed, 14 Nov 2018 20:43:13 -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=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 DS8hLNVGCC8r for ; Wed, 14 Nov 2018 20:43:11 -0800 (PST)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE52E1271FF for ; Wed, 14 Nov 2018 20:43:10 -0800 (PST)
Received: by mail-lf1-x135.google.com with SMTP id c16so13193877lfj.8 for ; Wed, 14 Nov 2018 20:43:10 -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=yrzR2C9Yw/0938qr6W5HiyxVgBGYiFGAVgfYKx4kr4A=; b=A4C/pWF0GLGEEpNlu0ikBoKM61doVLaJwOGfX3asZ1sc1UUyj0kt8yGgagwRO2gqRD Dbdzawc0dgw60xNGBU7C7lPnQII4ozF4/s4JgXggTTi4WBLPfRIWB7k3l8E6rkZGSWW/ Ahaya2ycWw3NOW6js+wZMOLR+x8uxZXPn+o/pKoXUJQqN7ZF+VX4X2puSJQ1Bnx5+kwE u2wV9VZLZHnYHiOkTla6/ybV30pOARZCbTg6ROACB6IUEzWPzE7iYT8oytcOtCK342Kr pp2+qrwaFjfeXJDVnczmum7kuiYigNphkYJV5CkrvvBS6zfnK7u2AGhfkUztktnRV96J As8A==
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=yrzR2C9Yw/0938qr6W5HiyxVgBGYiFGAVgfYKx4kr4A=; b=N9RU1YfHTdqGePLLZreD4UJYf6K7YaCx+c7R3Aq3K/vqpkUlhuCkSV9XbYeaqR9mWT cP5zyrL2wWMrrP6qhg6zHyQAtyVAAdAVlX1HyGOmYlf9FE+akpvuHI3qmSBjzLL84nye 1QY69s0kJgVVZhQmgWeH9GfYlob9Sda/Cc8Hi+LTgvqLObrgj4RjWl6g+ULLynmn5gAa c8EDuacZWOSJhx5IbIvETe4ad8UtKTn48dNpGnLqOMBIbECy5REDpegdodVc4+V0Xr5a kttina+mB12C0MhR1FG/kFNS6fFG3xClvkqa0nq+4xCK3mDJ1GNRw8ZRxNbWw14GTj0q KK+Q==
X-Gm-Message-State: AGRZ1gIO3VSqH/xl58QiokE+raZksP3HIDPw0euKmRJvGv9rcjOWzpOX k76e4Rb+Zvl2iDxe89ug1+PKMXkuMZTPinZuDH7KLw==
X-Google-Smtp-Source: AJdET5dBcSMCOFi/bOt8JzUwIq8oR3tPXvkn0EbJweBziLZCH0cDJECF5OaiC2ZabBx11c2zKmxbS4tGQ4+b1NYZqeY=
X-Received: by 2002:a19:ca51:: with SMTP id h17mr2362340lfj.126.1542256988679;  Wed, 14 Nov 2018 20:43:08 -0800 (PST)
MIME-Version: 1.0
References:   <20181114.124841.232214537179191240.mbj@tail-f.com> 
In-Reply-To: 
From: Andy Bierman 
Date: Wed, 14 Nov 2018 20:42:56 -0800
Message-ID: 
To: Robert Wilton 
Cc: Martin Bjorklund , NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000f68c11057aacaf10"
Archived-At: 
Subject: Re: [netmod] comments on YANG versioning
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Nov 2018 04:43:14 -0000

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

On Wed, Nov 14, 2018 at 7:48 AM Robert Wilton  wrote:

> Hi Martin,
> On 14/11/2018 11:48, Martin Bjorklund wrote:
>
> Hi,
>
> Robert Wilton   wrote:
>
> On 08/11/2018 22:52, Andy Bierman wrote:
>
> Hi,
>
> A few comments on the netmod meeting yesterday
>
> 1) what is a bugfix?
> It is not encouraging that the DT cannot agree on the scope of a
> bugfix.
> But not sure it matters if NBC updates can occur for any reason.
> IMO it is easy to define a bugfix in the IETF -- it is called an
> Errata.
> If an Errata is approved for a YANG module in an RFC then it is a
> bugfix.
>
> Ultimately we have customers that will say "this part of your YANG is
> broken" and we want you to fix it in that release train, either in the
> next release, or as a software patch.
>
> Sometimes vendors will disagree with their customers as to whether it
> is really a bug fix or an enhancement.  Sometimes we will fix what we
> think is an obvious bug but that will unfortunately break another
> customer whom was relying on the existing behavior and then ask us to
> revert the fix.
>
> I think that it should be down to the module author/owner to decide
> whether or not it is a bug fix or an enhancement, and I would just
> like a versioning scheme that allows these changes to be expressed.
>
> So the requirement is that the versioning scheme must support
> branching, and must support expressing NBC changes on any version?
>
> I deem that 1.4 (without the sentence about versioning by software
> release) defines this:
>
>        1.4  The solution MUST allow for backwards-compatible
>             enhancements and bug fixes to be allowed in any non-latest
>             release.
>
> Although this text is ambiguous, perhaps stating it more clearly, I see
> the requirement as:
>
>        1.4  The solution MUST allow for backwards-compatible
>             enhancements, and backward-compatible or non-backwards compatible
>             bug fixes to be allowed in non-latest releases.
>
>
>
This new 1.4 (2nd one) is much better. Thanks for rewriting it.


Andy





> This requirement isn't present in the current draft, AFAICT.
>
> (not that I support it as a requirement)
>
> But vendors *have* to do this today.  I don't think telling our customers
> that no, we can't fix that bug, because the versioning scheme doesn't allow
> it is really pragmatic.
>
> Rob Shakir also indicated in the Netmod meeting that he does not support
> this requirement.  However, this conflicts with the fact that there are
> examples in OpenConfig when it has been necessary to apply fixes to older
> versions, which has been achieved using deviations.
>
>
> None of this changes the fact that I think that we should be avoiding
> making these changes in the first place.  I.e. I think that there is a
> clear separation between what the versioning scheme should be able to
> express, and what is recommended practice.
>
>
>
> 2) SEMVER to the rescue?
> If every module release can be its own feature release train then the
> value of
> ascending numeric identifiers is greatly diminished. The (m) and (M)
> tags
> do not really help.  I strongly agree with the comment that
> cherry-picking new
> features can (and should) be done with deviations.  Updates of old
> revisions needs to be for bugfixes only.
>
> I prefer the OpenConfig "SEMVER Classic" rather than introducing a new
> incompatible complex numbering scheme to support something that
> should not be done anyway.
>
> SEMVER classic does not support making bug fixes (even bc ones) on
> older releases.
>
> In an older release, SEMVER classic allows:
>  - editorial changes, e.g. spelling corrections or clarifications in
> description statements that do not change the API semantics in anyway.
>  - bug fixes to the *implementation*, but then we are not using SEMVER
> to version the implementation anyway, only the API.
>
> If you want to allow bug fixes (even just bc ones) in an older release
> then you either need something like modified semver, or a different
> versioning scheme that allows them.  Or you do what Rob Shakir
> suggests and use deviations for this instead, which I think is a
> misuse of deviations.
>
> But, as you state in the solution draft, not even modified semver can
> determine if a specific change is NBC or not.  It seems you would need
> the entire history to determine this - which goes against the original
> idea that a client should be able to easily determine if a new version
> is NBC or not, compared to the version the client knows.
>
> The (m|M) is intended to be a tool of last resort.  So provide a mechanism
> to make bug fixes to older versions, but don't encourage it.  It provides a
> mechanism to provide bug fixes on an existing release, but at the cost that
> you lose some of the benefits of semver (which is unavoidable).
>
> If the server is on a version of the form "A.B.X(m)" then the client knows
> that all changes between "A.B.0" and "A.B.X(m)" are backwards compatible.
> If the version is "A.B.X(M)" then the client knows that there is at least
> one nbc change between "A.B.0" and "A.B.X(M)".  The client does not know
> whether going from "A.B.X(m|M)" to "A.B+1.0" is a backwards incompatible
> change or not.
>
> Thanks,
> Rob
>
>
> /martin
> .
>
>
>

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




On Wed=
, Nov 14, 2018 at 7:48 AM Robert Wilton <rwilton@cisco.com> wrote:

 =20
   =20
 =20
  

    
Hi Martin,

    

    
On 14/11/2018 11:48=
, Martin Bjorklund
      wrote:

    

    

      
Hi,

Robert Wilton <rwilton@cisco.com> wrote:


      

        
On 08/11/2018 22:=
52, Andy Bierman wrote:


        

          
Hi,

A few comments on the netmod meeting yesterday

1) what is a bugfix?
It is not encouraging that the DT cannot agree on the scope of a
bugfix.
But not sure it matters if NBC updates can occur for any reason.
IMO it is easy to define a bugfix in the IETF -- it is called an
Errata.
If an Errata is approved for a YANG module in an RFC then it is a
bugfix.


        

        
Ultimately we hav=
e customers that will say "this part of your YANG is
broken" and we want you to fix it in that release train, either in the
next release, or as a software patch.

Sometimes vendors will disagree with their customers as to whether it
is really a bug fix or an enhancement.=C2=A0 Sometimes we will fix what we
think is an obvious bug but that will unfortunately break another
customer whom was relying on the existing behavior and then ask us to
revert the fix.

I think that it should be down to the module author/owner to decide
whether or not it is a bug fix or an enhancement, and I would just
like a versioning scheme that allows these changes to be expressed.=C2=A0


      

      
So the requirement =
is that the versioning scheme must support
branching, and must support expressing NBC changes on any version?

    

    
I deem that 1.4 (without the sentence about versioning by
      software release) defines this:

    
       1.4  The solution MUST allow for backwards=
-compatible
            enhancements and bug fixes to be allowed in any non-latest
            release.

    
Although this text is ambiguous, perhaps stating it more clearly,
      I see the requirement as:

    

    
       1.4  The solution MUST allow for backwards=
-compatible
            enhancements, and backward-compatible or non-backwards compatib=
le=20
            bug fixes to be allowed in non-latest releases.

    




Andy



=C2=A0<=
/div>

    

    

      
This requirement is=
n't present in the current draft, AFAICT.

(not that I support it as a requirement)

    

    
But vendors *have* to do this today.=C2=A0 I don't think telling=
 our
      customers that no, we can't fix that bug, because the versioning
      scheme doesn't allow it is really pragmatic.

    
Rob Shakir also indicated in the Netmod meeting that he does not
      support this requirement.=C2=A0 However, this conflicts with the fact
      that there are examples in OpenConfig when it has been necessary
      to apply fixes to older versions, which has been achieved using
      deviations.

    

    


    

    

      

      

        
None of this chan=
ges the fact that I think that we should be avoiding
making these changes in the first place.=C2=A0 I.e. I think that there is a
clear separation between what the versioning scheme should be able to
express, and what is recommended practice.




        

          
2) SEMVER to th=
e rescue?
If every module release can be its own feature release train then the
value of
ascending numeric identifiers is greatly diminished. The (m) and (M)
tags
do not really help.=C2=A0 I strongly agree with the comment that
cherry-picking new
features can (and should) be done with deviations.=C2=A0 Updates of old
revisions needs to be for bugfixes only.

I prefer the OpenConfig "SEMVER Classic" rather than introducing =
a new
incompatible complex numbering scheme to support something that
should not be done anyway.


        

        
SEMVER classic do=
es not support making bug fixes (even bc ones) on
older releases.

In an older release, SEMVER classic allows:
=C2=A0- editorial changes, e.g. spelling corrections or clarifications in
description statements that do not change the API semantics in anyway.
=C2=A0- bug fixes to the *implementation*, but then we are not using SEMVER
to version the implementation anyway, only the API.

If you want to allow bug fixes (even just bc ones) in an older release
then you either need something like modified semver, or a different
versioning scheme that allows them.=C2=A0 Or you do what Rob Shakir
suggests and use deviations for this instead, which I think is a
misuse of deviations.


      

      
But, as you state i=
n the solution draft, not even modified semver can
determine if a specific change is NBC or not.  It seems you would need
the entire history to determine this - which goes against the original
idea that a client should be able to easily determine if a new version
is NBC or not, compared to the version the client knows.

    

    
The (m|M) is intended to be a tool of last resort.=C2=A0 So provide =
a
      mechanism to make bug fixes to older versions, but don't encourag=
e
      it.=C2=A0 It provides a mechanism to provide bug fixes on an existing
      release, but at the cost that you lose some of the benefits of
      semver (which is unavoidable).

    
If the server is on a version of the form "A.B.X(m)" then =
the
      client knows that all changes between "A.B.0" and "A.B=
.X(m)" are
      backwards compatible.=C2=A0 If the version is "A.B.X(M)" th=
en the
      client knows that there is at least one nbc change between "A.B.=
0"
      and "A.B.X(M)".=C2=A0 The client does not know whether goin=
g from
      "A.B.X(m|M)" to "A.B+1.0" is a backwards incompat=
ible change or
      not. 

    

    
Thanks,

      Rob

    

    


    

    

      
/martin
.



    

  





--000000000000f68c11057aacaf10--


From nobody Thu Nov 15 16:54: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 BF81D130E08; Thu, 15 Nov 2018 16:54:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.172
X-Spam-Level: 
X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvGt117wlIx1; Thu, 15 Nov 2018 16:54:28 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1364D128B14; Thu, 15 Nov 2018 16:54:27 -0800 (PST)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wAG0i5dB032344; Thu, 15 Nov 2018 16:54:24 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=E/kH0qRnnAZdy5WHBo7X9eMKWqEmcxQZKOxEReukKmU=; b=EOkAHFPm1/3H7AA2UICmHzlBiBiMZRJiFW8k8Hl/LpbVgIY5LENKC/uuf60JDDDmIVaF KlhRk4zZqbxh8iph4BsGq66rwfcTMg782qizQDdAORmRAvjQziHwellH+NQqnqqkUi8r DnuN/vnhknlbsR+Y70PhKkP3SD3eAeeHH4zuuTuw0743V1UPkGH/OhpI+IqpVk8d072V OmgVqWLYelnDdHee05QWQ+tDdBiDXgdaGssGtixKkpaEvRsKRVnhZjGEFwBpgtnNqiG5 e6uJkZPCxibrHU5A2Km4OEO99SnJfL31V0IavsXI/0cnrP7oalfKLAwfG9m7XDJMc+QZ FA== 
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0119.outbound.protection.outlook.com [207.46.163.119]) by mx0a-00273201.pphosted.com with ESMTP id 2nse6krht6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Nov 2018 16:54:24 -0800
Received: from DM6PR05MB4665.namprd05.prod.outlook.com (20.176.109.202) by DM6PR05MB4460.namprd05.prod.outlook.com (20.176.79.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1339.15; Fri, 16 Nov 2018 00:54:22 +0000
Received: from DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a]) by DM6PR05MB4665.namprd05.prod.outlook.com ([fe80::7540:75f2:3803:298a%5]) with mapi id 15.20.1339.021; Fri, 16 Nov 2018 00:54:22 +0000
From: Kent Watsen 
To: Christian Hopps , Robert Wilton 
CC: joel jaeggli , "draft-ietf-netmod-module-tags.authors@ietf.org" , NETMOD Working Group 
Thread-Topic: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
Thread-Index: AQHUeqdUNvHcXv700EGZT1tuC2mJ5qVNikqAgACpiICAAxDrgA==
Date: Fri, 16 Nov 2018 00:54:22 +0000
Message-ID: <3FDB2C4D-659C-4653-A482-64E07D93F1EA@juniper.net>
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/10.10.4.181110
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM6PR05MB4460; 6:iX1Oku0/UhTvJzioeMrkUxY+c3B901Ok6yRJS6awr/r3SvKW3mnPvdYvKvhp167MjKVigFVTmSIIMppPuPe8mFw8tH0L753gFNcJadFNO4vqK0CNIwIQBSWS0+gMvy8K6M78Xg5x1LPNEEokv+Y4Ap+VGOgGZhHFkG7gOE196jzEMqiibYLwiuSThkW1N2I7px3pSgEs8O/ni4GKu9He4+yULC/IOTZebKM0fUG1JCAUCJ7jA7FYBnuaPrgpLc5yPkGt7+jvFGCabLatLYJF5rhcbWYwJrkCiiatRxbe+IrRpbedFD2ritC5taAnCEV+qSzl16+Casp0nEdERLZI/2Q3nJlfXgL5I8sPeyRO+Ghf8OsB0+Zx1CW+FBHikaH/N4nmEJPoU6YuijY3r2Xs8P8gubGvJCws69PvqwpH4gqi9xRDOC9xVYz0Y7B0aPAXLzIsh2igrC8lGoYZ1Av+4A==; 5:j1TPQ7VzqVnDrNvLVx90fR+mA93ZSScAHrH5OppJI1pI5jFvzygS1gknfHGXaibKSbKVYKuk8mGNsK2j8lyN+ELmiXi0RDfLRSuMqrYzA6reHBtIKymVgZ+uQPbofxzoH7/iC4ff32ELpG+ID7Lm1wit4p/DCZ0EkCmoHxBz93E=; 7:os3nXTBIiugluVoeotl7aCFJl5vis057CcJsQS+6hSKqs/SiPKFtO9V6vLHiTCvzIOqNviVQsZ2BPkLQhMEY1a0TPkvHkSR2XYmPXbeXpIupz7+fPl+tU8+p4VAFi+1NR8wIiBR9VN2PCCSzpNmtFA==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 923b4b65-a9a8-4d1e-5013-08d64b5e0c39
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:DM6PR05MB4460; 
x-ms-traffictypediagnostic: DM6PR05MB4460:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231415)(944501410)(52105112)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:DM6PR05MB4460; BCL:0; PCL:0; RULEID:; SRVR:DM6PR05MB4460; 
x-forefront-prvs: 0858FF8026
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(136003)(396003)(366004)(199004)(189003)(106356001)(76176011)(6512007)(99286004)(82746002)(14444005)(97736004)(71190400001)(71200400001)(83716004)(58126008)(256004)(2616005)(316002)(25786009)(476003)(102836004)(110136005)(54906003)(2900100001)(68736007)(26005)(86362001)(6506007)(186003)(53936002)(305945005)(33656002)(6246003)(478600001)(6486002)(36756003)(229853002)(7736002)(39060400002)(81156014)(81166006)(8936002)(8676002)(2906002)(105586002)(486006)(446003)(5660300001)(6116002)(3846002)(66066001)(11346002)(6436002)(14454004)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR05MB4460; 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: vMrtvaHZQX884IwIIb2LXkeguSzjikN8T+qjQH0oo9vygtwLJi25M91KjNMCTXIlDKIt2vOqQgsaOqc3Ew/29X4M362qZV2r+BzYVV4/qE2u1zI4C30584GuOmXya4dCifT0YBLcELmdpsiaf+vKC8HIu6h1/c/0fsFDxse1uXF+9IOYKyWUijHnU0y8DmxmPz7uAiEA0+A9xgBA9+b6zpoPO8LYF4PgkKER/kUNsLIhJSyJISD/A7SP9og9Ie90PGI7Rg6cBe4PydFMVT6qyEGWc3pD2Zyq6pcGZed9rcjjjkqRDFQdL3I1OYglUVXdO6Mo/qSGnknyozjUgvJUjWsWvdnQGhCFU8QZ+cZw0/E=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 923b4b65-a9a8-4d1e-5013-08d64b5e0c39
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2018 00:54:22.1914 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB4460
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-15_17:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811160004
Archived-At: 
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Nov 2018 00:54:30 -0000

DQo+IFRoZSBzZXJ2ZXJzIGltcGxlbWVudCB0aGUgbW9kdWxlcyB3aGljaCBjYW4gaGF2ZSBwcmVk
ZWZpbmVkIHRhZ3MgZnJvbQ0KPiB0aGUgbW9kdWxlIGRlc2lnbmVyIGFzIHdlbGwgYXMgdGhlIGlt
cGxlbWVudGVyICh2ZW5kb3IpIHdoaWNoIGxpdGVyYWxseQ0KPiBjYW5ub3QgY29tZSBmcm9tIGFu
eXdoZXJlICpidXQqIHRoZSBzZXJ2ZXIgdGhhdCBpbXBsZW1lbnRzIHRoZSBtb2R1bGUuDQoNClBy
ZWRlZmluZWQgdGFncyBmcm9tIHRoZSBpbXBsZW1lbnRlciBvbmx5IG5lZWRzIHRvIGNvbWUgZnJv
bSB0aGUgDQppbXBsZW1lbnRvci4gIFdoZXRoZXIgaXQgaXMgcHJvdmlkZWQgYnkgdGhlIHNlcnZl
ciBpdHNlbGYgb3IgdmlhDQpzb21lIG91dC1vZi1iYW5kIG1lY2hhbmlzbSAoZS5nLiwgbW9kdWxl
IGNhdGFsb2cpIHNlZW1zIHRvIGJlIHRoZQ0KcXVlc3Rpb24uDQoNCk9mIGNvdXJzZSwgb25lIG1p
Z2h0IHNheSB0aGF0IHVzZXItdGFncyBtdXN0IGJlIHByb3ZpZGVkIGJ5IHRoZSANCnNlcnZlciBp
dHNlbGYsIGluIG9yZGVyIHRvIHByb3ZpZGUgYW4gaW50ZXItY2xpZW50IGNvbW11bmljYXRpb24g
DQptZWNoYW5pc20gb2Ygc29tZSBzb3J0LCBhcyBvdGhlcndpc2UgYSBzaW5nbGUgY2xpZW50LCBl
dmVuIGlmIA0KZGlzdHJpYnV0ZWQsIGNvdWxkIGtlZXAgdGhlIHVzZXItdGFncyBpbiBpdHMgbG9j
YWwgZGF0YWJhc2UuDQoNClRob3VnaCB0aGlzIGJlZ3MgdGhlIHF1ZXN0aW9uLCB3b3VsZCBpdCBi
ZSBiZXR0ZXIgZm9yIHRoZSBjbGllbnRzDQp0byB1c2UgYSBjZW50cmFsaXplZCBzZXJ2aWNlIG9m
IHNvbWUgc29ydCAocGVyaGFwcyB3aXRoaW4gdGhlDQpkZXBsb3ltZW50J3MgaW5mcmFzdHJ1Y3R1
cmUsIGFzc3VtaW5nIHRoZSB1c2VyLXRhZ3MgYXJlIHByaXZhdGUpDQp0byBoYXZlIHVzZXItdGFn
cyBvbmNlIHBlciBtb2R1bGUsIHJhdGhlciB0aGFuIChyZWR1bmRhbnRseT8pIG9uDQplYWNoIHNl
cnZlciwgdGh1cyBlbnN1cmluZyBjb25zaXN0ZW5jeSBhcyB3ZWxsIGFzIGF2b2lkaW5nIA0KcG90
ZW50aWFsIHJhY2UgY29uZGl0aW9ucz8gIE9yIGFyZSB0aGVzZSB1c2VyLXRhZ3MgdHJ1bHkgDQpz
ZXJ2ZXItc3BlY2lmaWMgKG5vdCBqdXN0IG1vZHVsZS1zcGVjaWZpYyk/DQoNCklzIGl0IGFjY3Vy
YXRlIHRvIGFzc3VtZSB0aGF0IHR3byBzZXJ2ZXJzIHJ1bm5pbmcgaWRlbnRpY2FsIA0Kc29mdHdh
cmUgd291bGQgaGF2ZSBpZGVudGljYWwgdXNlci10YWdzPyAgT2YgY291cnNlLCB0aGUgc2VydmVy
cw0KbWlnaHQgYmUgcnVubmluZyBkaWZmZXJlbnQgc29mdHdhcmUgKGVpdGhlciBkaWZmZXJlbnQg
cmVsZWFzZXMNCmZvciB0aGUgc2FtZSBoYXJkd2FyZSwgb3IgZGlmZmVyZW50IGhhcmR3YXJlLCBw
b3RlbnRpYWxseSBmcm9tDQpkaWZmZXJlbnQgdmVuZG9ycykuICBBY2NvbW1vZGF0aW5nIHN1Y2gg
d291bGQgY29tcGxpY2F0ZSB0aGUNCmNvbnN0cnVjdGlvbiBvZiBhIGNlbnRyYWxpemVkIG1vZHVs
ZS10YWdnaW5nIHNlcnZpY2UsIHRob3VnaA0KaXQgY291bGQgc3RpbGwgYmUgZG9uZS4NCg0KSSBz
dXBwb3NlIHRoYXQgdGhlIHZhbHVlIG9mIHRoaXMgZG9jdW1lbnQgaXMgbm90IGluIGFueSBvbmUg
b2YNCnRoZSB1c2UtY2FzZXMsIGFzIHRoZXkgZWFjaCBzZWVtIG1pbm9yIGFuZCBoYXZpbmcgYWx0
ZXJuYXRlIA0KKHBvdGVudGlhbGx5IGJldHRlcikgd29ya2Fyb3VuZHMsIGJ1dCBpbiB0aGUgbXVs
dGl0dWRlIG9mIHRoZW0NCmFsbCwgYW5kIGhvdyBhIHNpbmdsZSBtZWNoYW5pc20gY2FuIGhlbHAu
DQoNCg0KPiBUaGlzIGlzIG5vdCB3aGF0IEkgdGhvdWdodCB3b3VsZCBob2xkIHRoaXMgd29yayB1
cC4NCg0KTXkgZXhwZXJpZW5jZSBpcyB0aGF0IExhc3QgQ2FsbHMgdGVuZCB0byBkcml2ZSBwZW9w
bGUgdG8gcXVlc3Rpb24NCmJhc2ljcyBhZ2Fpbi4gIEJ5IGV4YW1wbGUsIGl0J3MgcmF0aGVyIGNv
bW1vbiBmb3IgYSBkcmFmdCdzIHRpdGxlDQp0byBjaGFuZ2UgZHVyaW5nIGEgTGFzdCBDYWxsLiAg
VGhhdCBzYWlkLCB0aGlzIHN1aXRhYmlsaXR5IHF1ZXN0aW9uDQpoYXMgYmVlbiBsaW5nZXJpbmcg
c2luY2UgdGhlIGRheSBKb2VsIGtpY2tlZCBvZmYgdGhlIEFkb3B0aW9uIENhbGwsDQp0aGF0IGl0
IGlzIHN0aWxsIHdpdGggdXMgc2VlbXMgdG8gYmUgdGhlIHByb2JsZW0uDQoNCg0KS2VudCAvLyBj
b250cmlidXRvcg0KDQoNCg0K


From nobody Thu Nov 15 18:57: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 ABAFC130E3D; Thu, 15 Nov 2018 18:57:19 -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 BWWCWYV4sDnY; Thu, 15 Nov 2018 18:57:18 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2332D1274D0; Thu, 15 Nov 2018 18:57:18 -0800 (PST)
Received: from dex.chopps.org (97-83-3-72.dhcp.aldl.mi.charter.com [97.83.3.72]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 5CE1360024; Fri, 16 Nov 2018 02:57:17 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Christian Hopps 
In-Reply-To: <3FDB2C4D-659C-4653-A482-64E07D93F1EA@juniper.net>
Date: Thu, 15 Nov 2018 21:57:16 -0500
Cc: Christian Hopps , Robert Wilton , joel jaeggli , "draft-ietf-netmod-module-tags.authors@ietf.org" ,  NETMOD Working Group 
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>   <3FDB2C4D-659C-4653-A482-64E07D93F1EA@juniper.net>
To: Kent Watsen 
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: 
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Nov 2018 02:57:20 -0000

So I would now have a new tags server to store tags associated with the =
modules for each of my actual servers in my network?

This seems a bit convoluted to me, and I haven=E2=80=99t heard anyone =
say what the problem is with the servers storing the tags associated =
with their modules, there are obvious problems (that you highlight) with =
the servers *not* storing the tags.

I think this is a rather simple thing we=E2=80=99ve proposed, and the =
server is the seemingly natural/simple place to do it.

I think it would be good to get some justification for *not* having the =
server store tags for it=E2=80=99s own modules.

Thanks,
Chris.



> On Nov 15, 2018, at 19:54, Kent Watsen  wrote:
>=20
>=20
>> The servers implement the modules which can have predefined tags from
>> the module designer as well as the implementer (vendor) which =
literally
>> cannot come from anywhere *but* the server that implements the =
module.
>=20
> Predefined tags from the implementer only needs to come from the=20
> implementor.  Whether it is provided by the server itself or via
> some out-of-band mechanism (e.g., module catalog) seems to be the
> question.
>=20
> Of course, one might say that user-tags must be provided by the=20
> server itself, in order to provide an inter-client communication=20
> mechanism of some sort, as otherwise a single client, even if=20
> distributed, could keep the user-tags in its local database.
>=20
> Though this begs the question, would it be better for the clients
> to use a centralized service of some sort (perhaps within the
> deployment's infrastructure, assuming the user-tags are private)
> to have user-tags once per module, rather than (redundantly?) on
> each server, thus ensuring consistency as well as avoiding=20
> potential race conditions?  Or are these user-tags truly=20
> server-specific (not just module-specific)?
>=20
> Is it accurate to assume that two servers running identical=20
> software would have identical user-tags?  Of course, the servers
> might be running different software (either different releases
> for the same hardware, or different hardware, potentially from
> different vendors).  Accommodating such would complicate the
> construction of a centralized module-tagging service, though
> it could still be done.
>=20
> I suppose that the value of this document is not in any one of
> the use-cases, as they each seem minor and having alternate=20
> (potentially better) workarounds, but in the multitude of them
> all, and how a single mechanism can help.
>=20
>=20
>> This is not what I thought would hold this work up.
>=20
> My experience is that Last Calls tend to drive people to question
> basics again.  By example, it's rather common for a draft's title
> to change during a Last Call.  That said, this suitability question
> has been lingering since the day Joel kicked off the Adoption Call,
> that it is still with us seems to be the problem.
>=20
>=20
> Kent // contributor
>=20
>=20
>=20


From nobody Thu Nov 15 19:23: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 1BC4C130E5C for ; Thu, 15 Nov 2018 19:23:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OP9beuioklAJ for ; Thu, 15 Nov 2018 19:23:15 -0800 (PST)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5953D130E3D for ; Thu, 15 Nov 2018 19:23:15 -0800 (PST)
Received: by mail-lj1-x235.google.com with SMTP id v15-v6so19059024ljh.13 for ; Thu, 15 Nov 2018 19:23:15 -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=P+5BH3l7tS7SM5K/DCIlEcLOYsYQkSmdK9o4xjCezgA=; b=jaCQZuSkn3K8ldIvEA+BzK63VP7mrePnQYTKojQlaopr1f46oJK/AMPjp9CkUVVNFO PVADni5c8EgjTymS32qMhcrrW9NvcoDDNT2XA7SqX+trt1XrEbbAGEciRfX2Mw1Qlcq4 5tXlk4g4IoSKv7cyQSyVpgZkWy2cQJAc2tNUgL/WqX7ie2LeHVon3G2Lq423ANOl/ooD WcWVq0IH8b0aj0I/FhWaKCys5kerC/3K4XL6WPEhTujYIvTqAsrX/BzHS2wPk06Oq6Fc fUe+dPdnqX/uS95q79ioPP1sMIkSlQgm5hQQiLbHc/JXjfZy2PWF3XB+faT16S+yaNIH jxmw==
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=P+5BH3l7tS7SM5K/DCIlEcLOYsYQkSmdK9o4xjCezgA=; b=RIAuiWB0RDOkkEXdLks4qrlQJ/mXrKl2Xr/OFdH+8+ijkQGtAOBYlt1OVBS5C4Rn7B auIFU52LuYH9+LFT3YEACBb1GtOzoSFmig7ROycDyyqeaRvlrQSVjxmgYRZFR00HSb6g yWal+O+aDB+CAOSvQaMYtR5a+Ys1/wF9TuDbPyTvEGx2OIHYC25yyFdDvVQJc2e9XTAI MQjCp63uCjoiD5Kzw7KKi74D6PQjijCCejuYxiNUqsuXQzv9zpyMaCjSjzFq1xdx4eDe FKmM9/DFHnX2OriCSU0qlrg3x0KINaupqWiKFE1udjrV348iYFtRHucPAPmMUN063MBu +lWw==
X-Gm-Message-State: AGRZ1gKNWSFfyxAN1PBJwclnM93dL5XTNZ0YlKIwe9FADMlbaFMbnHr+ 2jql1llBVOeFhYUUDTVTa4AjfdpF8b+lFTX4VRKlMg==
X-Google-Smtp-Source: AJdET5chcek5IZodwyev1T1wFOXewurp0Gk36L4JgYCs8rpoccC6UCbeXwHlAgbTWApfO7etKSdh7IP6X8z/1/k25sc=
X-Received: by 2002:a2e:458b:: with SMTP id s133-v6mr4935465lja.170.1542338593308;  Thu, 15 Nov 2018 19:23:13 -0800 (PST)
MIME-Version: 1.0
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>   <3FDB2C4D-659C-4653-A482-64E07D93F1EA@juniper.net> 
In-Reply-To: 
From: Andy Bierman 
Date: Thu, 15 Nov 2018 19:23:01 -0800
Message-ID: 
To: Christian Hopps 
Cc: Kent Watsen , joel jaeggli ,  draft-ietf-netmod-module-tags.authors@ietf.org, NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000fa5984057abfaf28"
Archived-At: 
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Nov 2018 03:23:18 -0000

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

On Thu, Nov 15, 2018 at 6:57 PM Christian Hopps  wrote:

> So I would now have a new tags server to store tags associated with the
> modules for each of my actual servers in my network?
>
> This seems a bit convoluted to me, and I haven=E2=80=99t heard anyone say=
 what the
> problem is with the servers storing the tags associated with their module=
s,
> there are obvious problems (that you highlight) with the servers *not*
> storing the tags.
>
> I think this is a rather simple thing we=E2=80=99ve proposed, and the ser=
ver is
> the seemingly natural/simple place to do it.
>
> I think it would be good to get some justification for *not* having the
> server store tags for it=E2=80=99s own modules.
>
>
+1 to all.
Hopefully, the standard and vendor tags automatically installed by the
server are good enough,
but if not, then the user can configure tags as well.

It would be good to get away from complex data silos in the client, or a
mega-tags-server
that does the same thing. The tag mappings could get complex and keeping
them in the config
on each server seems the easiest to manage,


Thanks,
> Chris.
>
>

Andy


>
> > On Nov 15, 2018, at 19:54, Kent Watsen  wrote:
> >
> >
> >> The servers implement the modules which can have predefined tags from
> >> the module designer as well as the implementer (vendor) which literall=
y
> >> cannot come from anywhere *but* the server that implements the module.
> >
> > Predefined tags from the implementer only needs to come from the
> > implementor.  Whether it is provided by the server itself or via
> > some out-of-band mechanism (e.g., module catalog) seems to be the
> > question.
> >
> > Of course, one might say that user-tags must be provided by the
> > server itself, in order to provide an inter-client communication
> > mechanism of some sort, as otherwise a single client, even if
> > distributed, could keep the user-tags in its local database.
> >
> > Though this begs the question, would it be better for the clients
> > to use a centralized service of some sort (perhaps within the
> > deployment's infrastructure, assuming the user-tags are private)
> > to have user-tags once per module, rather than (redundantly?) on
> > each server, thus ensuring consistency as well as avoiding
> > potential race conditions?  Or are these user-tags truly
> > server-specific (not just module-specific)?
> >
> > Is it accurate to assume that two servers running identical
> > software would have identical user-tags?  Of course, the servers
> > might be running different software (either different releases
> > for the same hardware, or different hardware, potentially from
> > different vendors).  Accommodating such would complicate the
> > construction of a centralized module-tagging service, though
> > it could still be done.
> >
> > I suppose that the value of this document is not in any one of
> > the use-cases, as they each seem minor and having alternate
> > (potentially better) workarounds, but in the multitude of them
> > all, and how a single mechanism can help.
> >
> >
> >> This is not what I thought would hold this work up.
> >
> > My experience is that Last Calls tend to drive people to question
> > basics again.  By example, it's rather common for a draft's title
> > to change during a Last Call.  That said, this suitability question
> > has been lingering since the day Joel kicked off the Adoption Call,
> > that it is still with us seems to be the problem.
> >
> >
> > Kent // contributor
> >
> >
> >
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




So I would now have a new tags server to store tags associated with t=
he modules for each of my actual servers in my network?



This seems a bit convoluted to me, and I haven=E2=80=99t heard anyone say w=
hat the problem is with the servers storing the tags associated with their =
modules, there are obvious problems (that you highlight) with the servers *=
not* storing the tags.



I think this is a rather simple thing we=E2=80=99ve proposed, and the serve=
r is the seemingly natural/simple place to do it.



I think it would be good to get some justification for *not* having the ser=
ver store tags for it=E2=80=99s own modules.



+1 to all.
Hopefully, the st=
andard and vendor tags automatically installed by the server are good enoug=
h,
but if not, then the user can configure tags as well.

It would be good to get away from complex data silos in th=
e client, or a mega-tags-server
that does the same thing. The tag=
 mappings could get complex and keeping them in the config
on eac=
h server seems the easiest to manage,



Thanks,

Chris.




Andy=C2=A0





> On Nov 15, 2018, at 19:54, Kent Watsen <kwatsen@juniper.net> wrote:

> 

> 

>> The servers implement the modules which can have predefined tags f=
rom

>> the module designer as well as the implementer (vendor) which lite=
rally

>> cannot come from anywhere *but* the server that implements the mod=
ule.

> 

> Predefined tags from the implementer only needs to come from the 

> implementor.=C2=A0 Whether it is provided by the server itself or via<=
br>
> some out-of-band mechanism (e.g., module catalog) seems to be the

> question.

> 

> Of course, one might say that user-tags must be provided by the 

> server itself, in order to provide an inter-client communication 

> mechanism of some sort, as otherwise a single client, even if 

> distributed, could keep the user-tags in its local database.

> 

> Though this begs the question, would it be better for the clients

> to use a centralized service of some sort (perhaps within the

> deployment's infrastructure, assuming the user-tags are private)
> to have user-tags once per module, rather than (redundantly?) on

> each server, thus ensuring consistency as well as avoiding 

> potential race conditions?=C2=A0 Or are these user-tags truly 

> server-specific (not just module-specific)?

> 

> Is it accurate to assume that two servers running identical 

> software would have identical user-tags?=C2=A0 Of course, the servers<=
br>
> might be running different software (either different releases

> for the same hardware, or different hardware, potentially from

> different vendors).=C2=A0 Accommodating such would complicate the

> construction of a centralized module-tagging service, though

> it could still be done.

> 

> I suppose that the value of this document is not in any one of

> the use-cases, as they each seem minor and having alternate 

> (potentially better) workarounds, but in the multitude of them

> all, and how a single mechanism can help.

> 

> 

>> This is not what I thought would hold this work up.

> 

> My experience is that Last Calls tend to drive people to question

> basics again.=C2=A0 By example, it's rather common for a draft'=
;s title

> to change during a Last Call.=C2=A0 That said, this suitability questi=
on

> has been lingering since the day Joel kicked off the Adoption Call,
> that it is still with us seems to be the problem.

> 

> 

> Kent // contributor

> 

> 

> 



_______________________________________________

netmod mailing list

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




--000000000000fa5984057abfaf28--


From nobody Thu Nov 15 20:51: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 93147129619; Thu, 15 Nov 2018 20:51:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level: 
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 Hgc66PLJtxix; Thu, 15 Nov 2018 20:51:33 -0800 (PST)
Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885E81286E3; Thu, 15 Nov 2018 20:51:33 -0800 (PST)
Received: by mail-pl1-x642.google.com with SMTP id b5-v6so10554556pla.6; Thu, 15 Nov 2018 20:51:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Sa5++/h+n/vT9NXOCcGvEyxwdo7DSDQsg3hhbm7yVQc=; b=juvZgIKFr9x4uhOiWObGUGEDdylb7LWwzTd1kon9m3IXKyu8BrVgqpThPeMATKB7Wj hJystXoFJEWjU3jJdawZh11yvqOjOwtUz41+qZRuTIM8+GtGst0wb3lRndfHI8ebHRrX Ky7qZyuN9p3OSKJlqVepT2cPNh+Mat9KG1yHb2/ERGIcMv6ZWYfAMsjsjEPjtleJ7Jtj LPc1pqxedbL6XtD/LnXuUVkPi5rL/E07xBSiz4K85IOnn8sSKGXao9srkJIa9Mx0ibWj 1QY7J/dm4gd3l8KnyhUsZPYKovHfuD3puxEa4UUggy+22e0pZ2hn0F+zStzN3jjIKsKy fVrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Sa5++/h+n/vT9NXOCcGvEyxwdo7DSDQsg3hhbm7yVQc=; b=PmtXm5FAqapop3ZzNIoHnb6Gi5dtL+amSi/az6b6kgYI9Wh/o25X5o3/XhgRppGQeL 5rUKItlQ6KbwwGLy94yYtKsvZZGvJazyCOEzqPiCuQ8jZ6Mdr4e78LGuQw8f6L0yQO36 p+lKOIG018NSX1Xtl5M/MWdgx/HRGyQdfNlRsb0olPqjXiMjick7iqjRBqjpTg6wtFsY VtwcXUBl26e8AX7xzCYypDl+M6Nhd2D8lntbHOL7BjpwrR/emP2xdN4j0uaHsUIt1rl2 KQ8mByHjjC7gtH325GgfeU6JAQbL8d0KeyZ/5/1aCTmzwRk9fE9TPq/6Xwfb2wPjsdUi x/pw==
X-Gm-Message-State: AGRZ1gJNdAA1EWI91dTkxdbISx5ZaSuhVq8C2e3rJQTcKb2Mxl2d7wlL qusph/iZHWA2vRUa8CjCcV4=
X-Google-Smtp-Source: AJdET5cAyP0tyJCudWFKMrzqIBNQXnspKB3ISQsFVklAnpSNTv7rxNYxDws2BnuYtDg7dtLULsc/qg==
X-Received: by 2002:a17:902:1105:: with SMTP id d5-v6mr9590772pla.28.1542343892995;  Thu, 15 Nov 2018 20:51:32 -0800 (PST)
Received: from [192.168.88.33] (mx-ll-183.89.24-193.dynamic.3bb.co.th. [183.89.24.193]) by smtp.gmail.com with ESMTPSA id z83-v6sm34577284pfi.4.2018.11.15.20.51.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Nov 2018 20:51:32 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-806141F5-A524-4D20-8D3C-CE692FAD3895
Mime-Version: 1.0 (1.0)
From: Jeff Tantsura 
X-Mailer: iPhone Mail (16B92)
In-Reply-To: 
Date: Fri, 16 Nov 2018 11:51:27 +0700
Cc: Christian Hopps , joel jaeggli , draft-ietf-netmod-module-tags.authors@ietf.org, NetMod WG 
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>   <3FDB2C4D-659C-4653-A482-64E07D93F1EA@juniper.net>  
To: Andy Bierman 
Archived-At: 
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Nov 2018 04:51:37 -0000

--Apple-Mail-806141F5-A524-4D20-8D3C-CE692FAD3895
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

+1 Christian=20

Regards,
Jeff

> On Nov 16, 2018, at 10:23, Andy Bierman  wrote:
>=20
>=20
>=20
>> On Thu, Nov 15, 2018 at 6:57 PM Christian Hopps  wrote=
:
>> So I would now have a new tags server to store tags associated with the m=
odules for each of my actual servers in my network?
>>=20
>> This seems a bit convoluted to me, and I haven=E2=80=99t heard anyone say=
 what the problem is with the servers storing the tags associated with their=
 modules, there are obvious problems (that you highlight) with the servers *=
not* storing the tags.
>>=20
>> I think this is a rather simple thing we=E2=80=99ve proposed, and the ser=
ver is the seemingly natural/simple place to do it.
>>=20
>> I think it would be good to get some justification for *not* having the s=
erver store tags for it=E2=80=99s own modules.
>>=20
>=20
> +1 to all.
> Hopefully, the standard and vendor tags automatically installed by the ser=
ver are good enough,
> but if not, then the user can configure tags as well.
>=20
> It would be good to get away from complex data silos in the client, or a m=
ega-tags-server
> that does the same thing. The tag mappings could get complex and keeping t=
hem in the config
> on each server seems the easiest to manage,
>=20
>=20
>> Thanks,
>> Chris.
>>=20
>=20
>=20
> Andy=20
>=20
>>=20
>>=20
>> > On Nov 15, 2018, at 19:54, Kent Watsen  wrote:
>> >=20
>> >=20
>> >> The servers implement the modules which can have predefined tags from
>> >> the module designer as well as the implementer (vendor) which literall=
y
>> >> cannot come from anywhere *but* the server that implements the module.=

>> >=20
>> > Predefined tags from the implementer only needs to come from the=20
>> > implementor.  Whether it is provided by the server itself or via
>> > some out-of-band mechanism (e.g., module catalog) seems to be the
>> > question.
>> >=20
>> > Of course, one might say that user-tags must be provided by the=20
>> > server itself, in order to provide an inter-client communication=20
>> > mechanism of some sort, as otherwise a single client, even if=20
>> > distributed, could keep the user-tags in its local database.
>> >=20
>> > Though this begs the question, would it be better for the clients
>> > to use a centralized service of some sort (perhaps within the
>> > deployment's infrastructure, assuming the user-tags are private)
>> > to have user-tags once per module, rather than (redundantly?) on
>> > each server, thus ensuring consistency as well as avoiding=20
>> > potential race conditions?  Or are these user-tags truly=20
>> > server-specific (not just module-specific)?
>> >=20
>> > Is it accurate to assume that two servers running identical=20
>> > software would have identical user-tags?  Of course, the servers
>> > might be running different software (either different releases
>> > for the same hardware, or different hardware, potentially from
>> > different vendors).  Accommodating such would complicate the
>> > construction of a centralized module-tagging service, though
>> > it could still be done.
>> >=20
>> > I suppose that the value of this document is not in any one of
>> > the use-cases, as they each seem minor and having alternate=20
>> > (potentially better) workarounds, but in the multitude of them
>> > all, and how a single mechanism can help.
>> >=20
>> >=20
>> >> This is not what I thought would hold this work up.
>> >=20
>> > My experience is that Last Calls tend to drive people to question
>> > basics again.  By example, it's rather common for a draft's title
>> > to change during a Last Call.  That said, this suitability question
>> > has been lingering since the day Joel kicked off the Adoption Call,
>> > that it is still with us seems to be the problem.
>> >=20
>> >=20
>> > Kent // contributor
>> >=20
>> >=20
>> >=20
>>=20
>> _______________________________________________
>> 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

--Apple-Mail-806141F5-A524-4D20-8D3C-CE692FAD3895
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

+1 Christian 

Regards,
Jeff

=
On Nov 16, 2018, at 10:23, Andy Bierman <andy@yumaworks.com> wrote:



On Thu, Nov 15, 2018 at 6:57 PM Christian Hopps <chopps@chopps.org> wrote:
So I would now have a new tags server to store tags as=
sociated with the modules for each of my actual servers in my network?



This seems a bit convoluted to me, and I haven=E2=80=99t heard anyone say wh=
at the problem is with the servers storing the tags associated with their mo=
dules, there are obvious problems (that you highlight) with the servers *not=
* storing the tags.



I think this is a rather simple thing we=E2=80=99ve proposed, and the server=
 is the seemingly natural/simple place to do it.



I think it would be good to get some justification for *not* having the serv=
er store tags for it=E2=80=99s own modules.



+1 to all.
Hopefully, the sta=
ndard and vendor tags automatically installed by the server are good enough,=

but if not, then the user can configure tags as well.
<=
br>
It would be good to get away from complex data silos in the cl=
ient, or a mega-tags-server
that does the same thing. The tag mapp=
ings could get complex and keeping them in the config
on each serv=
er seems the easiest to manage,



Thanks,

Chris.




Andy 





> On Nov 15, 2018, at 19:54, Kent Watsen <kwatsen@juniper.net> wrote:

> 

> 

>> The servers implement the modules which can have predefined tags fr=
om

>> the module designer as well as the implementer (vendor) which liter=
ally

>> cannot come from anywhere *but* the server that implements the modu=
le.

> 

> Predefined tags from the implementer only needs to come from the 

> implementor.  Whether it is provided by the server itself or via
> some out-of-band mechanism (e.g., module catalog) seems to be the

> question.

> 

> Of course, one might say that user-tags must be provided by the 

> server itself, in order to provide an inter-client communication 

> mechanism of some sort, as otherwise a single client, even if 

> distributed, could keep the user-tags in its local database.

> 

> Though this begs the question, would it be better for the clients

> to use a centralized service of some sort (perhaps within the

> deployment's infrastructure, assuming the user-tags are private)

> to have user-tags once per module, rather than (redundantly?) on

> each server, thus ensuring consistency as well as avoiding 

> potential race conditions?  Or are these user-tags truly 

> server-specific (not just module-specific)?

> 

> Is it accurate to assume that two servers running identical 

> software would have identical user-tags?  Of course, the servers
> might be running different software (either different releases

> for the same hardware, or different hardware, potentially from

> different vendors).  Accommodating such would complicate the

> construction of a centralized module-tagging service, though

> it could still be done.

> 

> I suppose that the value of this document is not in any one of

> the use-cases, as they each seem minor and having alternate 

> (potentially better) workarounds, but in the multitude of them

> all, and how a single mechanism can help.

> 

> 

>> This is not what I thought would hold this work up.

> 

> My experience is that Last Calls tend to drive people to question

> basics again.  By example, it's rather common for a draft's title<=
br>
> to change during a Last Call.  That said, this suitability questio=
n

> has been lingering since the day Joel kicked off the Adoption Call,
=

> that it is still with us seems to be the problem.

> 

> 

> Kent // contributor

> 

> 

> 



_______________________________________________

netmod mailing list

netmod@ietf.org
=

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




________=
_______________________________________
netmod mailing list<=
/span>
netmod@ietf.org
https://=
www.ietf.org/mailman/listinfo/netmod
=

--Apple-Mail-806141F5-A524-4D20-8D3C-CE692FAD3895--


From nobody Fri Nov 16 02:00: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 194DB130DC7; Fri, 16 Nov 2018 02:00:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9iRSEFVQ6TS; Fri, 16 Nov 2018 02:00:54 -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 D5F92130DC6; Fri, 16 Nov 2018 02:00:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3592; q=dns/txt; s=iport; t=1542362454; x=1543572054; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=J5dbbdcRh5H5s/cbJAz3144F5y0llq4PnBQ/9/F2GjM=; b=WoVoNt4atwaUPTm80hzp0r22s+rFuUjabYh6ar7kJJd+refRpE40AZ3U QXU1AlxJXMIpPrTmcg9Ppxidf4B0HyC5gO2qEtY/5elQlhlzNQSpA/t5z KGODBJLrR51F7Pu78v3U4HcvabxdBUPWoPW+as0fp1Ch7ZjfujTSv9jqZ M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAChlO5b/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgmlwEieDeIgYX4x9CCWXNhSBZg0jgVS?= =?us-ascii?q?CdQKDdTQJDQEDAQECAQECbRwMhTwBAQEDASMPAQVBEAsOCgICJgICVwYBDAg?= =?us-ascii?q?BAYMdAYF5CA+nSYEvhUCEXQWBC4sRgUA/gTgMgl+DGwOBJCaDGoJXAolKgTq?= =?us-ascii?q?UZgmGeoMrhnwGGIlchx6BT4tmhACGW4FGOEGBFDMaCBsVGoMNgicXiCOFeT8?= =?us-ascii?q?DMI1lAQE?=
X-IronPort-AV: E=Sophos;i="5.56,239,1539648000";  d="scan'208";a="8092115"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Nov 2018 10:00:51 +0000
Received: from [10.63.23.62] (dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com [10.63.23.62]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id wAGA0o0J005205; Fri, 16 Nov 2018 10:00:51 GMT
To: Kent Watsen , Christian Hopps 
Cc: joel jaeggli , "draft-ietf-netmod-module-tags.authors@ietf.org" , NETMOD Working Group 
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>   <3FDB2C4D-659C-4653-A482-64E07D93F1EA@juniper.net>
From: Robert Wilton 
Message-ID: <9adac84c-c44f-0d05-3617-865118ab6617@cisco.com>
Date: Fri, 16 Nov 2018 10:00:49 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <3FDB2C4D-659C-4653-A482-64E07D93F1EA@juniper.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.62, dhcp-ensft1-uk-vla370-10-63-23-62.cisco.com
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: 
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Nov 2018 10:00:56 -0000

On 16/11/2018 00:54, Kent Watsen wrote:
>> The servers implement the modules which can have predefined tags from
>> the module designer as well as the implementer (vendor) which literally
>> cannot come from anywhere *but* the server that implements the module.
> Predefined tags from the implementer only needs to come from the
> implementor.  Whether it is provided by the server itself or via
> some out-of-band mechanism (e.g., module catalog) seems to be the
> question.

I wasn't trying to argue that tags shouldn't be on the server.  I was 
just trying to say that the reason for doing so wasn't immediately 
intuitive to me from reading the draft.  In particular, I hadn't 
considered the use case of multiple clients coordinating via the tag 
information in the server config/state that Chris suggested.  I can see 
that having one client store the tag information on the server may make 
it a lot easier to code a different client (that might be monitoring 
devices for consistency).  E.g. client B only fetch the data for modules 
marked with a tag set by client A.

For the catalog use case, I wasn't particularly suggesting that tooling 
needs to pull tags from a catalog, although I have no issues with that.  
It was more my observation that once we start classifying modules using 
tags then an obvious use case (at least to me ;-) for that meta-data 
information is for humans to be able to search library repositories 
using tags.  E.g. in a similar way to how RPM repositories might be 
searched (https://rpmfind.net/linux/RPM/Groups.html).

I think that Chris is going to add some brief use case text to the 
draft.  With that addition, I have no further objections and I'm happy 
for document to progress.

Thanks,
Rob


>
> Of course, one might say that user-tags must be provided by the
> server itself, in order to provide an inter-client communication
> mechanism of some sort, as otherwise a single client, even if
> distributed, could keep the user-tags in its local database.
>
> Though this begs the question, would it be better for the clients
> to use a centralized service of some sort (perhaps within the
> deployment's infrastructure, assuming the user-tags are private)
> to have user-tags once per module, rather than (redundantly?) on
> each server, thus ensuring consistency as well as avoiding
> potential race conditions?  Or are these user-tags truly
> server-specific (not just module-specific)?
>
> Is it accurate to assume that two servers running identical
> software would have identical user-tags?  Of course, the servers
> might be running different software (either different releases
> for the same hardware, or different hardware, potentially from
> different vendors).  Accommodating such would complicate the
> construction of a centralized module-tagging service, though
> it could still be done.
>
> I suppose that the value of this document is not in any one of
> the use-cases, as they each seem minor and having alternate
> (potentially better) workarounds, but in the multitude of them
> all, and how a single mechanism can help.
>
>
>> This is not what I thought would hold this work up.
> My experience is that Last Calls tend to drive people to question
> basics again.  By example, it's rather common for a draft's title
> to change during a Last Call.  That said, this suitability question
> has been lingering since the day Joel kicked off the Adoption Call,
> that it is still with us seems to be the problem.
>
>
> Kent // contributor
>
>
>


From nobody Mon Nov 19 12:32:05 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878BD130934 for ; Mon, 19 Nov 2018 12:32:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.37
X-Spam-Level: 
X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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 SINI6ZDRyiuf for ; Mon, 19 Nov 2018 12:32:01 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150123.outbound.protection.outlook.com [40.107.15.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E28130DE3 for ; Mon, 19 Nov 2018 12:31:57 -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=YlT5FR65PiPE+gPtcTPlSvXImIWLThMLu75rlef4tNg=; b=lYwJR2p4jHxPuP7PPUVZYvdgajy9WR/KypGX5x8DsHCEwsPmV5G/Qvs6r0CFhL/rgzf4eCtaTnyrh+QjG+n2H1utmUu9B40Yav/7/COCZ2hGCiN55eEI08wF36uC71wGZCQLbHX/v55LXp6Lu0zIkNXltl8Q7kspkR8jBdRffZ8=
Received: from VI1PR07MB3981.eurprd07.prod.outlook.com (52.134.28.141) by VI1PR07MB6016.eurprd07.prod.outlook.com (20.178.123.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.9; Mon, 19 Nov 2018 20:31:55 +0000
Received: from VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::2858:36b3:3cd7:5f09]) by VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::2858:36b3:3cd7:5f09%2]) with mapi id 15.20.1361.013; Mon, 19 Nov 2018 20:31:55 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: "netmod@ietf.org" 
Thread-Topic: Adding a pre-existing leaf into a new 'choice' - NBC change?
Thread-Index: AdSARc1DsD04ldMzQTGmSlWVLz4VPQ==
Date: Mon, 19 Nov 2018 20:31:55 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com; 
x-originating-ip: [135.245.20.4]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB6016; 6:7bfKJY33GrAukXIJdBqeRq1Lm/My23/gUq0RLEmyM/7f5ea3akLEPQxUIv6k45AbZ9UrOmVrMQknsJFExRCHDxvJH/MYzOpocUt9JqzYs+Csr4q6033DrMJ4GihTFzLO4/T8Ad0AoJzpKupVnCTvzYvXA8ABCVQ64wMWu28QVNWts5H7GPH6nZYzKR+MYR11RCXX3vP4mTLMC4HQCxcUw/q7QY39iXghXg98JZdqcy8LqMpYwJpEP7P83EWcfILEZYwpXMGlgcjI0Fhg2hgmLeWUpoenbeGV9cdbcS9VDOn+ViGO3SEzErAK7WvcI3D2P4+p0tjuaUHO1dHq9gWD0WKdLDfnphnj1ZcmOY6YMI9JpJIX3BCHvc1QmiiU3qAgmKREv73USD0sZeYBu8CeWDzCAfgtZLEVkBc3j8YW0ulTZ9NkD0xD/TbG+uOPSzc0w3jb9uwmkHHeheZTyH2p3g==; 5:0Zfn1u8DqirHS/A8jTlhOjnLddhrYnWuNoqtIAihBuUgu+aLpLIARthXkl8Erg4JdGgxfuUnybUqODyC/T2yEt8wI+x1lure8ZxoBfTVdN2Qcfow619tmDjhHZiEHDTgnozGKuwbGuOx5aZNDhNsWYDFkLZ4+MxIoGkUQCfxOO8=; 7:00/yLRtqkAmev61KIqUq/lb4ZLojMHXktcz/tJj1B7UeTZi2bYllqwFGxCQQX2RG8Xvulj8HHlT7hv+AbPWg6U1k8gFzT53GgRIB85U5LJgPo0ea7adpdOXd8wAxnRZqxuqKzhoqXs+Ew4S9VBWFgQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: c9d1b80f-c9c8-49b6-8e9a-08d64e5e0c20
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)(7193020); SRVR:VI1PR07MB6016; 
x-ms-traffictypediagnostic: VI1PR07MB6016:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231415)(11241501184)(806099)(944501410)(52105112)(3002001)(10201501046)(93006095)(93001095)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB6016; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB6016; 
x-forefront-prvs: 08617F610C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(136003)(39860400002)(366004)(376002)(396003)(189003)(199004)(53754006)(71200400001)(71190400001)(478600001)(316002)(102836004)(14454004)(2906002)(5640700003)(2501003)(97736004)(26005)(256004)(25786009)(33656002)(53936002)(9686003)(105586002)(54896002)(6306002)(55016002)(68736007)(106356001)(8676002)(3846002)(6116002)(790700001)(186003)(2900100001)(74316002)(2351001)(6916009)(6436002)(486006)(7736002)(7696005)(66066001)(6506007)(99286004)(476003)(86362001)(1730700003)(81156014)(5660300001)(81166006)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB6016; H:VI1PR07MB3981.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: omdKHzGgpFBBkcinRa5hRgvJfnemHx0LWdGNm4SpGT16QI8+POnfiFbInGDyeexHOwdN8mtWZ1HezrqxOToCaKFiUbkB4EIGa7nVjYXU6THhc3jDCt0WgdO/uxLms+4wlM5dxMX7T/494m2MR8WP0HXmE1WH0IapfVzzbmUADQ26QSEnlbm6RPSqBwk1J+o/yqjDImppQ9junMD8UoGMpZF9qi2rIm339lU9P071xPmkYJW10v60B524R5qsorTJQK3OtCVdWrs1TOrh6Ac4BpTs8XbjalSxxwLMwohSu29HGycesKg82XJAVfbEUqGKUF9mwTjEnZW2/YaXfauJDGPgpe9n9oUgwWJ5hk0YrIU=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_VI1PR07MB3981A171F18213B030D289A79BD80VI1PR07MB3981eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c9d1b80f-c9c8-49b6-8e9a-08d64e5e0c20
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2018 20:31:55.6065 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6016
Archived-At: 
Subject: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Nov 2018 20:32:04 -0000

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

Hi all,

If we have a YANG model with a leaf:

MODEL VERSION 1:
container my-model {
    leaf a { type string; }
}

And then later we produce another version of the model where that leaf is p=
laced into a choice construct:

MODEL VERSION 2:
container my-model {
    choice some-choice {
        case x {
            leaf a { type string; }
        }
    }
}

Is that considered a non-backwards-compatible change?

Does the answer depend on whether the choice contains other cases (or other=
 cases that are the default case)?

MODEL VERSION 3:
container my-model {
    choice some-choice {
        case x {
            leaf a { type string; }
        }
        case y {
            leaf b { type string; }
        }
    }
}

A client 'foo' using VERSION 1 would still be able to set & read back leaf =
a in the same way as it always did.

But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf 'a' =
would disappear. That could be surprising to client 'foo' although perhaps =
no more surprising than if another client simply deletes leaf 'a' (using VE=
RSION 1).

Jason




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











Hi all,


 


If we have a YANG model with a =
leaf:


 


MODEL VERSION 1:


container my-model {=



    leaf a { typ=
e string; }


}


 


And then later we produce anoth=
er version of the model where that leaf is placed into a choice construct:<=
o:p>


 


MODEL VERSION 2:


container my-model {=



    choice some-=
choice {


     &=
nbsp;  case x {


      =
      leaf a { type string; }


     &=
nbsp;  }


    }=



}


 


Is that considered a non-backwa=
rds-compatible change?


 


Does the answer depend on wheth=
er the choice contains other cases (or other cases that are the default cas=
e)?


 


MODEL VERSION 3:


container my-model {=



    choice some-=
choice {


     &=
nbsp;  case x {


      =
      leaf a { type string; }


     &=
nbsp;  }


     &=
nbsp;  case y {


     &=
nbsp;      leaf b { type string; }


     &=
nbsp;  }


    }=



}


 


A client 'foo' using VERSION 1 =
would still be able to set & read back leaf a in the same way as it alw=
ays did.


 


But if another client 'bar' (us=
ing VERSION 3) sets leaf 'b', then leaf 'a' would disappear. That could be =
surprising to client 'foo' although perhaps no more surprising than if anot=
her client simply deletes leaf 'a' (using
 VERSION 1).


 


Jason


 


 


 






--_000_VI1PR07MB3981A171F18213B030D289A79BD80VI1PR07MB3981eurp_--


From nobody Mon Nov 19 12:46:27 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0BB130934 for ; Mon, 19 Nov 2018 12:46:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5vQRjkA6WgB for ; Mon, 19 Nov 2018 12:46:24 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DEE0B128D0C for ; Mon, 19 Nov 2018 12:46:23 -0800 (PST)
Received: from localhost (h-39-108.A165.priv.bahnhof.se [213.136.39.108]) by mail.tail-f.com (Postfix) with ESMTPSA id 52DBD1AE018C; Mon, 19 Nov 2018 21:46:22 +0100 (CET)
Date: Mon, 19 Nov 2018 21:46:22 +0100 (CET)
Message-Id: <20181119.214622.418972213170057209.mbj@tail-f.com>
To: jason.sterne@nokia.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: 
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] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Nov 2018 20:46:26 -0000

Hi,

"Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> Hi all,
> 
> If we have a YANG model with a leaf:
> 
> MODEL VERSION 1:
> container my-model {
>     leaf a { type string; }
> }
> 
> And then later we produce another version of the model where that leaf
> is placed into a choice construct:
> 
> MODEL VERSION 2:
> container my-model {
>     choice some-choice {
>         case x {
>             leaf a { type string; }
>         }
>     }
> }
> 
> Is that considered a non-backwards-compatible change?

Not accordning to current RFC 7950 rules, since it changes the schema
node path (suppose the leaf was a container, and someone had augment
/my-model/a).

> Does the answer depend on whether the choice contains other cases (or
> other cases that are the default case)?

No.

> MODEL VERSION 3:
> container my-model {
>     choice some-choice {
>         case x {
>             leaf a { type string; }
>         }
>         case y {
>             leaf b { type string; }
>         }
>     }
> }
> 
> A client 'foo' using VERSION 1 would still be able to set & read back
> leaf a in the same way as it always did.
> 
> But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf
> 'a' would disappear. That could be surprising to client 'foo' although
> perhaps no more surprising than if another client simply deletes leaf
> 'a' (using VERSION 1).



/martin


From nobody Mon Nov 19 12:47: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 A3120130934 for ; Mon, 19 Nov 2018 12:47:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.371
X-Spam-Level: 
X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 wSuX6ElbMV8o for ; Mon, 19 Nov 2018 12:47:43 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40096.outbound.protection.outlook.com [40.107.4.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D680128D0C for ; Mon, 19 Nov 2018 12:47:43 -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=uAjBLVfmO6xIqyIxA6l/0NNyEjpvpXkgmMIRrQiJWF8=; b=T4dGLbeNg8Fwu3GUB26d9WXHxXGFNUd0pO92lG87EwEuD/c7Cj02JFxEwlw4wfFH6F4ncSnx3v/xVrWTMeePm80cgmy866dEthjRUNgMd4MvY66BrksmGnMZ6gJ50imWWMcjNIZR1nShPV+lrBZbqS8819M3VV4AbUF//G+neoY=
Received: from VI1PR07MB3981.eurprd07.prod.outlook.com (52.134.28.141) by VI1PR07MB3853.eurprd07.prod.outlook.com (52.134.26.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.9; Mon, 19 Nov 2018 20:47:40 +0000
Received: from VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::2858:36b3:3cd7:5f09]) by VI1PR07MB3981.eurprd07.prod.outlook.com ([fe80::2858:36b3:3cd7:5f09%2]) with mapi id 15.20.1361.013; Mon, 19 Nov 2018 20:47:40 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: Martin Bjorklund 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
Thread-Index: AdSARc1DsD04ldMzQTGmSlWVLz4VPQAAyDAAAAAFtPA=
Date: Mon, 19 Nov 2018 20:47:40 +0000
Message-ID: 
References:  <20181119.214622.418972213170057209.mbj@tail-f.com>
In-Reply-To: <20181119.214622.418972213170057209.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com; 
x-originating-ip: [135.245.20.4]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB3853; 6:UAmZCp4WU9ISvkCBmixhFmr0OqkpOSVn+BxxmVvumljtHljf+e02P52RWoUQfOXjyZyHeSs+559zsloZvC9kG+ulIwQFUcX9NzUnQB8cSyByowWgljWc60uBPb8Y8lgeZgRYB7qsC0U+KdQagaMDNCRaLUpaviMdUrL80sX9HKSDsJA+9/cg7lficyEGPUHgylA3P6cGCEiw9evsbt8+W9iNxf48oiiN/y/GloHVNR9E41VQcoCojST/HoumZNDGB2xpGGYHuM2yjfH4h60YeK2t/hCJ6LI2Mu1boPegvzsZFtAFl5Bp49rHBS8rUUfwNyCwwvpc8dFND11FBnkoC7OPjMZSGgW3ED/mCrSfKxMaZSf7lNxq2cPqjra63EeqDUmd6DiKaTnpTMul8c3FdQEeb1rKqdVImdGSGO1AhKjHnqJws//W3F1gHKyherBy/jjm9g7Gg/n2ZKv1Agyv/Q==; 5:yhLMoUj43oJXPef6h31GuzMl+bdZPU1YaulIdRiOVBjgQiCDaeR9EQ2oMV5/yrJ9TnnOsYIY8G4hmZO9xPHOP9ulkAtZejHCY7ba9HCSKPFQ5+qLbovInQuSfUOYiTxWKeUAYcH6AkLCmG7m/j7APt6cnEoWZTP8wpFWJZk98nU=; 7:/Wqh6OXXsuWdLI4N8y4mqO27f4SkMEKnFdIjfazuarRvQkjfdTYsmZkl2OQRfRoIjE/YRZvsZ+p/+hvAGuP6ib8QBXXvBBmMRPXj/kEXSM2AvpdKb0S6c7FVm86WjVn2w8QOiFSKtFZ0eFE9CuK79w==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 1f163ffd-6631-4f04-0f63-08d64e603f86
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)(7193020); SRVR:VI1PR07MB3853; 
x-ms-traffictypediagnostic: VI1PR07MB3853:
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)(3231415)(11241501184)(806099)(944501410)(52105112)(93006095)(93001095)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB3853; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB3853; 
x-forefront-prvs: 08617F610C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(346002)(39860400002)(366004)(376002)(13464003)(189003)(199004)(53754006)(25786009)(14454004)(97736004)(8936002)(68736007)(33656002)(105586002)(476003)(316002)(2906002)(53936002)(256004)(4326008)(478600001)(6246003)(6116002)(3846002)(5660300001)(74316002)(86362001)(2900100001)(55016002)(9686003)(6916009)(81156014)(7696005)(81166006)(6436002)(99286004)(229853002)(66066001)(8676002)(106356001)(71190400001)(71200400001)(11346002)(446003)(6506007)(102836004)(53546011)(26005)(186003)(486006)(7736002)(76176011)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB3853; H:VI1PR07MB3981.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: gWQWYfKYJywMy2BdtchN/BHkyr6N6vHngUHwsAqEfpNLQY46ARCaWxcBXW8uSK12/Ih/kT8cUqcByAwLWvNfBcHCg6o0vP2MgBnd/mceZMJrRbTaVf58YYr5vH4UVxKy+U4o361h3TMSN1UDEGelsgXAfhgdDr4iMztUO/CWhLHvL8KUb23wTkRsGCiRV4B6/eFsKKB832UjkFRyoDZIWolSv0H2Li7kA9UuukkseJRnwylntZjBTlO9v9btxV2K5vng6luX/2gjun0ThMMQAw4lO+yVzIg6ZuO2o7xV5zHWNigyoyUhTOaFmvPUOWcRdtnJUY7lSCm7JkDWYA5ov7JWtHuMLrD9loZ0cglgxSc=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1f163ffd-6631-4f04-0f63-08d64e603f86
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2018 20:47:40.7820 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3853
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Nov 2018 20:47:46 -0000

Thanks. I forgot that the choice is in the *schema* path (was thinking abou=
t the instance data path which doesn't include the choice or case statement=
s).

> -----Original Message-----
> From: Martin Bjorklund 
> Sent: Monday, November 19, 2018 3:46 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NB=
C
> change?
>=20
> Hi,
>=20
> "Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> > Hi all,
> >
> > If we have a YANG model with a leaf:
> >
> > MODEL VERSION 1:
> > container my-model {
> >     leaf a { type string; }
> > }
> >
> > And then later we produce another version of the model where that leaf
> > is placed into a choice construct:
> >
> > MODEL VERSION 2:
> > container my-model {
> >     choice some-choice {
> >         case x {
> >             leaf a { type string; }
> >         }
> >     }
> > }
> >
> > Is that considered a non-backwards-compatible change?
>=20
> Not accordning to current RFC 7950 rules, since it changes the schema
> node path (suppose the leaf was a container, and someone had augment
> /my-model/a).
>=20
> > Does the answer depend on whether the choice contains other cases (or
> > other cases that are the default case)?
>=20
> No.
>=20
> > MODEL VERSION 3:
> > container my-model {
> >     choice some-choice {
> >         case x {
> >             leaf a { type string; }
> >         }
> >         case y {
> >             leaf b { type string; }
> >         }
> >     }
> > }
> >
> > A client 'foo' using VERSION 1 would still be able to set & read back
> > leaf a in the same way as it always did.
> >
> > But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf
> > 'a' would disappear. That could be surprising to client 'foo' although
> > perhaps no more surprising than if another client simply deletes leaf
> > 'a' (using VERSION 1).
>=20
>=20
>=20
> /martin


From nobody Mon Nov 19 12:54:12 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F048130E0A for ; Mon, 19 Nov 2018 12:54:05 -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=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 QEdhneyUADhq for ; Mon, 19 Nov 2018 12:54:01 -0800 (PST)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44121130E5A for ; Mon, 19 Nov 2018 12:54:01 -0800 (PST)
Received: by mail-lf1-x135.google.com with SMTP id u18so22330216lff.10 for ; Mon, 19 Nov 2018 12:54:01 -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=csKo1cGXew/IOgikcMenGRSL1zEORFavcJK6duaelYk=; b=cE7NXhscmZJ2dUMSBmRVplAZV1vTPqCvGz+QyvDM30rXcHeniQEoP6Yw9xyzfNjjbN agFueLb1uvF7nVEae2tf8NM7Qiz08i5oaIUxwvWrPOFmuIL8/rZ4ZbXPcVlFjqmaPEHU 4HU7PjUxXBD2v8vg7JE1N6gZ/Zz020xTMgy3Zex65HQdV87Ta7d5uH5/eJsIdWMhNUpL RBqcXw18HG8SLFLn4OzPGekbRy6W/4GL/U2suDsuI6PQTunXtCLG/oHKB0n2G5biOzb+ OUB0o0KWEag+FzuMKjqYn6/QXTzc6wbqDcoWYd9z/CQLEY7jnSk/TLIoIeGddll2If/C raeA==
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=csKo1cGXew/IOgikcMenGRSL1zEORFavcJK6duaelYk=; b=kGFYRPK8qal2DeYJHc0U+q9uIe5Ez5vQ1UXvFvm36g/USfLyU/arQffQjCrFeu7hhR ucfEHXjRoIXHlskt56yzojuCo2dz/HKizfnu22KlkTmbPYUpQneefJ6vtezXrj4jMD/2 +1j1gftHavgBvxqzNBoI5pKMSKElrlMaG4HegrfgjRSWq36Xwklmz86OwpsNr9k61F9d mYVMYfPqI8lFU8b8kjSKdirAIVYirpTAmn96XWDGDAd+YPJLzN+SdJLvEgHCyN+32zC1 McZyf6fuUPo9AM5rEkCH45lRIDL1vCIy+tUJ8HkkGH3ZuoQHZlF3WqjoBQfhAKOKynXm VPlw==
X-Gm-Message-State: AGRZ1gLQnEchTVqtOcXuT6TKOdGmwpYrNpjJuIrpvDm67JZKZ/0g59T3 F0VGhoUd4Y1VIanRjye/jEv4hyatm0d0/NQ/Zyod0lmf
X-Google-Smtp-Source: AJdET5cmqblm/4C61OVocSRysoj1jhooLERsa3LutXQsDrw5bxtWo9j3pURXIkcMuePPIbEqEOpQppgRHQSwxFbocg4=
X-Received: by 2002:a19:690d:: with SMTP id e13mr11590717lfc.84.1542660839242;  Mon, 19 Nov 2018 12:53:59 -0800 (PST)
MIME-Version: 1.0
References: 
In-Reply-To: 
From: Andy Bierman 
Date: Mon, 19 Nov 2018 12:53:47 -0800
Message-ID: 
To: "Sterne, Jason (Nokia - CA)" 
Cc: NetMod WG 
Content-Type: multipart/alternative; boundary="0000000000005513c9057b0ab7f0"
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Nov 2018 20:54:11 -0000

--0000000000005513c9057b0ab7f0
Content-Type: text/plain; charset="UTF-8"

On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
jason.sterne@nokia.com> wrote:

> Hi all,
>
>
>
> If we have a YANG model with a leaf:
>
>
>
> MODEL VERSION 1:
>
> container my-model {
>
>     leaf a { type string; }
>
> }
>
>
>
> And then later we produce another version of the model where that leaf is
> placed into a choice construct:
>
>
>
> MODEL VERSION 2:
>
> container my-model {
>
>     choice some-choice {
>
>         case x {
>
>             leaf a { type string; }
>
>         }
>
>     }
>
> }
>
>
>
> Is that considered a non-backwards-compatible change?
>


yes -- even though the data node /my-model/x did not change,
the schema node /my-model/a changed to /my-model/some-choice/x/a.
Any leafref path pointing at this leaf will break.


Andy


>
> Does the answer depend on whether the choice contains other cases (or
> other cases that are the default case)?
>
>
>

no


> MODEL VERSION 3:
>
> container my-model {
>
>     choice some-choice {
>
>         case x {
>
>             leaf a { type string; }
>
>         }
>
>         case y {
>
>             leaf b { type string; }
>
>         }
>
>     }
>
> }
>
>
>
> A client 'foo' using VERSION 1 would still be able to set & read back leaf
> a in the same way as it always did.
>
>
>
> But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf 'a'
> would disappear. That could be surprising to client 'foo' although perhaps
> no more surprising than if another client simply deletes leaf 'a' (using
> VERSION 1).
>
>
>
> Jason
>
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Mon=
, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com> wrote:











Hi all,

=C2=A0


If we have a YANG model with a =
leaf:


=C2=A0


MODEL VERSION 1:<=
/span>


container my-model {<=
/u>


=C2=A0=C2=A0=C2=A0 leaf a { typ=
e string; }


}


=C2=A0


And then later we produce anoth=
er version of the model where that leaf is placed into a choice construct:<=
u>


=C2=A0


MODEL VERSION 2:<=
/span>


container my-model {<=
/u>


=C2=A0=C2=A0=C2=A0 choice some-=
choice {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 case x {


=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0leaf a { type string; }


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


=C2=A0=C2=A0=C2=A0 }<=
/u>


}


=C2=A0


Is that considered a non-backwa=
rds-compatible change?






<=
div class=3D"m_-71832675242669823m_6141564456552465457WordSection1">


MODEL VERSION 3:<=
/span>


container my-model {<=
/u>


=C2=A0=C2=A0=C2=A0 choice some-=
choice {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 case x {


=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0leaf a { type string; }


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


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 case y {


=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf b { type string; }<=
/span>


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


=C2=A0=C2=A0=C2=A0 }<=
/u>


}


=C2=A0


A client 'foo' using VE=
RSION 1 would still be able to set & read back leaf a in the same way a=
s it always did.


=C2=A0


But if another client 'bar&=
#39; (using VERSION 3) sets leaf 'b', then leaf 'a' would d=
isappear. That could be surprising to client 'foo' although perhaps=
 no more surprising than if another client simply deletes leaf 'a' =
(using
 VERSION 1).


=C2=A0


Jason


=C2=A0


=C2=A0


=C2=A0






_______________________________________________

netmod mailing list

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




--0000000000005513c9057b0ab7f0--


From nobody Mon Nov 19 23:34: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 49A8712870E for ; Mon, 19 Nov 2018 23:34: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, 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 kQs6FteWa0-B for ; Mon, 19 Nov 2018 23:34:02 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE57124408 for ; Mon, 19 Nov 2018 23:34:02 -0800 (PST)
Received: from localhost (h-39-108.A165.priv.bahnhof.se [213.136.39.108]) by mail.tail-f.com (Postfix) with ESMTPSA id 736F61AE0187; Tue, 20 Nov 2018 08:33:59 +0100 (CET)
Date: Tue, 20 Nov 2018 08:33:59 +0100 (CET)
Message-Id: <20181120.083359.615984508747950128.mbj@tail-f.com>
To: jason.sterne@nokia.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20181119.214622.418972213170057209.mbj@tail-f.com>
References:  <20181119.214622.418972213170057209.mbj@tail-f.com>
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] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Nov 2018 07:34:04 -0000

Martin Bjorklund  wrote:
> Hi,
> 
> "Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> > Hi all,
> > 
> > If we have a YANG model with a leaf:
> > 
> > MODEL VERSION 1:
> > container my-model {
> >     leaf a { type string; }
> > }
> > 
> > And then later we produce another version of the model where that leaf
> > is placed into a choice construct:
> > 
> > MODEL VERSION 2:
> > container my-model {
> >     choice some-choice {
> >         case x {
> >             leaf a { type string; }
> >         }
> >     }
> > }
> > 
> > Is that considered a non-backwards-compatible change?
> 
> Not accordning to current RFC 7950 rules, since it changes the schema
  ^^^^^^^^^^^^^^^^^

I meant, "Yes, accordning to current RFC 7950 rules this is not
allowed".   But I think you got that.


/martin

> node path (suppose the leaf was a container, and someone had augment
> /my-model/a).
> 
> > Does the answer depend on whether the choice contains other cases (or
> > other cases that are the default case)?
> 
> No.
> 
> > MODEL VERSION 3:
> > container my-model {
> >     choice some-choice {
> >         case x {
> >             leaf a { type string; }
> >         }
> >         case y {
> >             leaf b { type string; }
> >         }
> >     }
> > }
> > 
> > A client 'foo' using VERSION 1 would still be able to set & read back
> > leaf a in the same way as it always did.
> > 
> > But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf
> > 'a' would disappear. That could be surprising to client 'foo' although
> > perhaps no more surprising than if another client simply deletes leaf
> > 'a' (using VERSION 1).
> 
> 
> 
> /martin
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
> 


From nobody Wed Nov 21 03:35: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 90CB3130F59 for ; Wed, 21 Nov 2018 03:35:33 -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 oPhIqAnM0th2 for ; Wed, 21 Nov 2018 03:35:31 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80100.outbound.protection.outlook.com [40.107.8.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DCDE130EE7 for ; Wed, 21 Nov 2018 03:35:30 -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=c39H82+n9mHkrjSiPdQ7eY6Jrv581jliodyYUfXpJQU=; b=T0F0nmF3R7ZvH2rI4JzBtcb6vmXGuVf1vLOrMHC8C6ncuCKw9b//IYD0cN2xrQMfqmQJGuVQAA6Fn2Ihov2Eiqifd7txts+Jg5P5pcvxae4HivoYzojbdN6e8vYH4digEWefR8xpXVOoCsUcH+K/XbU6rHc3nZRJFzn3oscFZgc=
Received: from VI1PR07MB5022.eurprd07.prod.outlook.com (20.177.202.206) by VI1PR07MB5374.eurprd07.prod.outlook.com (20.178.13.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.11; Wed, 21 Nov 2018 11:35:28 +0000
Received: from VI1PR07MB5022.eurprd07.prod.outlook.com ([fe80::929:bd11:beb6:b887]) by VI1PR07MB5022.eurprd07.prod.outlook.com ([fe80::929:bd11:beb6:b887%4]) with mapi id 15.20.1361.015; Wed, 21 Nov 2018 11:35:28 +0000
From: tom petch 
To: "netmod@ietf.org" 
Thread-Topic: Address Family versus Address Family
Thread-Index: AQHUgY5NMaELHgY0r0Cg02b5JWd9UQ==
Date: Wed, 21 Nov 2018 11:35:28 +0000
Message-ID: <033101d4818e$08689dc0$4001a8c0@gateway.2wire.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-clientproxiedby: CWXP265CA0030.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:2d::18) To VI1PR07MB5022.eurprd07.prod.outlook.com (2603:10a6:803:9b::14)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [86.128.101.213]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB5374; 6:Rf7ljuv5ShNM073ktWvf8hFElZNVnaOyoF0C6Bp/cWTNoDnUJ4oUcGA6g9Dd7n7H5BantIJMWD/JDRJvMItdfxdiC/ALxN1YufKrqOaB/p+PZSdxcIL/FMeWcFoKeI8DAZCxdyj8yS/l/o8p70X82UbaSglMB1GkVOCPZET9egLoooyvKDDG4ezr3OvtxrZenZN+9l5Z6itnAWFsxhksaPoS/zqlKtRgjDIt8a1uaegBv3j67tL9AQbJQYm22yhHeAKGH56TLdFf7b4ip+62PYMIagplm1qEywqNLSp/mB7oa/J9r+HGfXzjoi3Wpsc3zD//R0/LiyBJLDEbqaKpQsptC+iNwQHwrTy4ntbGx4g6AZz5oeMSZ5/gmmX9CzDUcm5WKBLN9oQSW0JxfHpp+B9AV6vK06EYUSYR/VSLzqVyjYPFZArPzVp0LnFatKiiW1P4SxlrfjmtUmBx3vvcyA==; 5:dQZyzGVxjt7VDdEHdsyG6AKoN5nOJxQPKhjeqvykNiZoBds+OQp88O5cXm0bcyZzaSPHv6FbQdu0JJEmAKhTkpKNv/3oH5JGc4LDTxDrtjlqYAaqwoSBaJvqp8SKmowh6zmQXCEsyzLyzWXcIL0SDN87Eao7MG9rajEpH5wxdbY=; 7:dVPi/ZHZ3dZqkmron5OQMXb/voGTiP1KKd5BD2liX2skXqG9DbKvyQrSVZBGZhU/p66p36dH3YVi2gbK6BWxKgff/ND/aQWscHn8cL0wZQB24ZippZ6q11bG8kFiPHfaPZhxbIkEVf4jqBb3O/JWCg==
x-ms-office365-filtering-correlation-id: b344bdec-b18a-4426-7ef6-08d64fa56fbf
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:VI1PR07MB5374; 
x-ms-traffictypediagnostic: VI1PR07MB5374:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231442)(944501410)(52105112)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB5374; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB5374; 
x-forefront-prvs: 08635C03D4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(39860400002)(136003)(366004)(199004)(189003)(486006)(106356001)(316002)(6116002)(44736005)(53936002)(1730700003)(2351001)(6486002)(14454004)(105586002)(5660300001)(3846002)(66066001)(81166006)(81156014)(5640700003)(86362001)(9686003)(6512007)(305945005)(71190400001)(71200400001)(8676002)(6436002)(86152003)(68736007)(25786009)(186003)(2900100001)(2501003)(6916009)(84392002)(478600001)(7736002)(14496001)(2906002)(1556002)(256004)(14444005)(33896004)(8936002)(99286004)(476003)(26005)(97736004)(386003)(102836004)(6506007)(52116002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5374; H:VI1PR07MB5022.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 5gNKv5tF3ImWlFsOpyfBRVzLmq0zYCyIZn/rOgwjUbLQNj+gNDgOnbCJhxXSiOkgr/bbijtputJItPZhvrtjxFeichRQYHZBpPK73j3KOizD4lNAop2hmQGLeNreQ2p8C5jiZaJDUlQxOlCyDcJoS4EnR5gYLgse7Emkpq/KXg4VxYChHaWRtWTR6leGVNUu64mjd50H5Ta2YQtUaMTBebmemwutJW4nhS2CrpAJBjgsizeYAZtr3byEShNyDHktd5WB5uR4HbUUffbfxYaThdm/s7ODiewab6s0rut8n3psOhx9RXWZbbroXpTkA43IOzPNhcQt+bTMw80/sQ+u2yO7oa/wDNr1KXb9TW02lrk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <5C4AF1FDD1643C42A0059C1A6872B280@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: b344bdec-b18a-4426-7ef6-08d64fa56fbf
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2018 11:35:28.5384 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5374
Archived-At: 
Subject: [netmod] Address Family versus Address Family
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Nov 2018 11:35:39 -0000

I have always thought of Address Family as something that BGP created
and that others have used.  In fact, I find that there is an IANA
registry of Address Families which RFC8294 has turned into a YANG
module, but one using enumeration and not identity, which would seem to
limit its utility.

Indeed, while the lsr WG uses that module, I2RS does not with
 draft-ietf-i2rs-rib-data-model
defining
   identity address-family {description  "Base identity from which all
RIB      address families are derived.";  }

identity - good; RYO definition - um.

BGP also goes its own way with
  identity AFI_SAFI_TYPE { description
         "Base identity type for AFI,SAFI tuples for BGP-4";
       reference "RFC4760 - multi-protocol extensions for BGP-4";  }

And then there is RFC8349 with
  identity address-family {
    description  "Base identity from which identities describing address
          families are derived.";      }
and which defines ipv4 and ipv6, and which ties the concept firmly to a
RIB in a 1:1 correspondence.

When I raised this on the rtgwg list, the response was that the concept
of an address family is particular to a protocol, so there is no reason
for ospf and BGP to share anything, which is how it seems.

So, is there any reason for anyone to use the definition in RFC8349? or
the IANA module?

Tom Petch



From nobody Wed Nov 21 04:13:39 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B2212F18C for ; Wed, 21 Nov 2018 04:13:37 -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 5-Qm8niEIXFf for ; Wed, 21 Nov 2018 04:13:33 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A0E8A1298C5 for ; Wed, 21 Nov 2018 04:13:28 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 64E9A182113D; Wed, 21 Nov 2018 13:20:56 +0100 (CET)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 60156182113A; Wed, 21 Nov 2018 13:20:42 +0100 (CET)
From: Ladislav Lhotka 
To: tom petch , "netmod\@ietf.org" 
In-Reply-To: <033101d4818e$08689dc0$4001a8c0@gateway.2wire.net>
References: <033101d4818e$08689dc0$4001a8c0@gateway.2wire.net>
Mail-Followup-To: tom petch , "netmod\@ietf.org" 
Date: Wed, 21 Nov 2018 13:13:07 +0100
Message-ID: <87wop6sk6k.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Address Family versus Address Family
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 21 Nov 2018 12:13:38 -0000

tom petch  writes:

> I have always thought of Address Family as something that BGP created
> and that others have used.  In fact, I find that there is an IANA
> registry of Address Families which RFC8294 has turned into a YANG
> module, but one using enumeration and not identity, which would seem to
> limit its utility.

In draft-lhotka-dnsop-iana-class-type-yang-00 we also use enumerations
representing DNS classes and resource records types. However, in
addition to the enumeration type that reflects the corresponding IANA
registries, we also added a union type that allows for using either the
mnemonic name or assigned number:

typedef rr-type {
  type union {
    type uint16;
    type rr-type-name;
  }
}

(and similarly for DNS classes). The numeric value corresponding to each
mnemonic name is given by the "value" statement inside each enum.

Actually, this approach was suggested by RFC 3597 that introduced the
general possibility of representing DNS classes and RR types
numerically. For example, RR type "AAAA" can be equivalently represented
as "TYPE28".

Perhaps this approach could be used for address families as well. In
fact, the use of identities also has its share of problems.

Lada

>
> Indeed, while the lsr WG uses that module, I2RS does not with
>  draft-ietf-i2rs-rib-data-model
> defining
>    identity address-family {description  "Base identity from which all
> RIB      address families are derived.";  }
>
> identity - good; RYO definition - um.
>
> BGP also goes its own way with
>   identity AFI_SAFI_TYPE { description
>          "Base identity type for AFI,SAFI tuples for BGP-4";
>        reference "RFC4760 - multi-protocol extensions for BGP-4";  }
>
> And then there is RFC8349 with
>   identity address-family {
>     description  "Base identity from which identities describing address
>           families are derived.";      }
> and which defines ipv4 and ipv6, and which ties the concept firmly to a
> RIB in a 1:1 correspondence.
>
> When I raised this on the rtgwg list, the response was that the concept
> of an address family is particular to a protocol, so there is no reason
> for ospf and BGP to share anything, which is how it seems.
>
> So, is there any reason for anyone to use the definition in RFC8349? or
> the IANA module?
>
> Tom Petch
>
>
> _______________________________________________
> 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 Nov 22 04:54: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 621E212F1A2 for ; Thu, 22 Nov 2018 04:54:34 -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_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, 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 7QhMawbReD8v for ; Thu, 22 Nov 2018 04:54:30 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0723.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::723]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6EF12DDA3 for ; Thu, 22 Nov 2018 04:54:29 -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=2Sg8KGjCNMj0gkO4jGJJlUwNquvg9mWRfFFkOFNrdIc=; b=ZJKQXUc00w+IR2vVhKQlRLMZu7yTuZWaX/7ojVHx39flpL/vvyZwsm9g0wH/ItbKxDmotU73ZfJc7AIzVHIPmHhTYhmkuXtUxKQoUdxWoamB9Nnei4ZECNCGMntOTDNS0XNo1zJxyJxbXOiTkhifXyKsLXSdXfxFwLMQYhuHvqY=
Received: from DB7PR07MB3978.eurprd07.prod.outlook.com (52.134.100.23) by DB7PR07MB5802.eurprd07.prod.outlook.com (20.178.105.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.8; Thu, 22 Nov 2018 12:54:27 +0000
Received: from DB7PR07MB3978.eurprd07.prod.outlook.com ([fe80::d501:332:48c7:4d6c]) by DB7PR07MB3978.eurprd07.prod.outlook.com ([fe80::d501:332:48c7:4d6c%3]) with mapi id 15.20.1382.007; Thu, 22 Nov 2018 12:54:27 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: Andy Bierman 
CC: NetMod WG 
Thread-Topic: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
Thread-Index: AdSARc1DsD04ldMzQTGmSlWVLz4VPQABCoCAAIXePiA=
Date: Thu, 22 Nov 2018 12:54:27 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [45.72.219.254]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB7PR07MB5802; 6:GeJDrKQ2Dk4HXZwwFUYQC/DU8rPy1usWF5vb6sTxb1bjpf0Kh6yaTOPA6WLJ2JFnbIW/428MISTs+mvsjW1fjEc1ui8ktBEVCWCWJJZUzt00RBuj0bQ0eCFY8beYffBIxBN5UlFd8CprJvWJNGkQF0pBbQ9bGHfvN+cl8wDu/z5+iNm8yoTaHQDGHcQCPT+6RaHvo4JGwBSwwDzGNrnuJbCTY6ar8iTdP6Rr7L8hPGvYI3/zM+KfVfeYQhwnfZXzzAxB27qAXe1mLtVKbOoPNFNF8cQozzd8EzKfK5P+T7tKamVhfgP9kAlRZjtGFqp+9maZHVQ+3L3qKDwh2cN6fllfDuH8g6X56NMswKBEFq3WuVrCx8mLSMdp+fRMoEGPaYvGYYMQIpYPY38B/UWqFmg36XwSoxJa695wP+7ZdR1UHbMBLoCzMBPrQloeWOZcAjjtBY7gM4hp9JvtlfSWvA==; 5:+d/lCSq3nk3X5ZDBy1z1KxT1IKzhq2GDoDZ0wvj1JhaB22e2P/hD42F6BIPNhUKb/nXTmxN6GpzDBVCbbMw7PzH1DXIJwB9bJikEdrbccSGVVpQH5g/Ne5EFnACO4qIRpv6POOwL2Eao5mLp5r6YBxv5Bn3zqIJc1ZbQx1Pt1vo=; 7:QqoZkxPpkDRdHZVysUBSX3qhFHDKt70k5PP6otVsL+ozogTmdWjouPZAdKxhw7ZfIyK5ABJno5uSSkJ0XpzytHFlo0+xECcFfK9JAElNLM11WBEnksJNAThMgSZfXxh2l11jvvLW8hbpXrw5gPiCig==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: e8fabacd-f0c8-4a46-bd6f-08d65079a2f5
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)(7193020); SRVR:DB7PR07MB5802; 
x-ms-traffictypediagnostic: DB7PR07MB5802:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com; 
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231442)(11241501184)(806099)(944501410)(52105112)(10201501046)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB5802; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB5802; 
x-forefront-prvs: 0864A36BBF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(366004)(346002)(396003)(376002)(199004)(53754006)(189003)(478600001)(2906002)(6506007)(53546011)(5660300001)(6246003)(966005)(9686003)(8936002)(3846002)(106356001)(99286004)(53936002)(25786009)(790700001)(6116002)(54896002)(102836004)(7696005)(4326008)(6306002)(76176011)(86362001)(71200400001)(105586002)(55016002)(71190400001)(229853002)(81166006)(81156014)(68736007)(33656002)(26005)(7736002)(14454004)(6436002)(476003)(186003)(8676002)(486006)(97736004)(2900100001)(74316002)(606006)(6916009)(11346002)(446003)(316002)(236005)(66066001)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB5802; H:DB7PR07MB3978.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)
x-microsoft-antispam-message-info: ceHwPOFJWM4dQtXu7gUxAjD06jgZChsWZJ9ktuNWwZ5czQVb8rUMyqARPWXczvqDrTFx+j/3RMuoLZA8pQysvBTWKemgGw9jo58/winkhgwc9D57GwY3ch3SG7Lmf7FiLjg96oT2u1WwdHA8Z/4G7CVeFZfMhgcaA71CnJjqbRoyhSQDb3IEvuD2rmJ2wzZhayJfNVlwY1xtEvX7rFyPXk3BC7xM5AmMdCLZ/q86t92CpnqLf1fRTJlbC19Bcve16EUbNOjCdSyB13/L5IljFwo77E0J9L3OCDhSpeCketnd0+nKIH+N3g1BfQoO7mpppi3QIUrHAqm3/TVK3zZl5wU0Cc20j/F14DF1Wm28t9s=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_DB7PR07MB3978A22EA0FFF32725E37B639BDB0DB7PR07MB3978eurp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e8fabacd-f0c8-4a46-bd6f-08d65079a2f5
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2018 12:54:27.4402 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5802
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2018 12:54:34 -0000

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

VGhhbmtzIEFuZHkuDQoNCkkgZGlkbid0IHJlYWxpemUgdGhhdCBsZWFmcmVmIHBhdGhzIHdvdWxk
IGNvbnRhaW4gdGhlIGNob2ljZSAmIGNhc2UgbmFtZXMgYXMgc2VnbWVudHMgb2YgdGhlIHBhdGgu
IEJ1dCBub3cgdGhhdCB5b3UgcG9pbnRlZCB0aGF0IG91dCBpdCBjbGFyaWZpZWQgd2hhdCB0aGlz
IG1lYW50IGluIHNlY3Rpb24gNy45IG9mIFJGQzc5NTA6DQogICBUaGUgaWRlbnRpZmllciBpcyB1
c2VkIHRvIGlkZW50aWZ5IHRoZSBjaG9pY2UNCiAgIG5vZGUgaW4gdGhlIHNjaGVtYSB0cmVlLiAg
QSBjaG9pY2Ugbm9kZSBkb2VzIG5vdCBleGlzdCBpbiB0aGUgZGF0YQ0KICAgdHJlZS4NCg0KSXMg
dGhlIHNhbWUgdGhpbmcgdHJ1ZSBmb3IgWFBhdGhzIGluICdtdXN0JyBhbmQgJ3doZW4nIGV4cHJl
c3Npb25zPyBXb3VsZCB0aG9zZSBjb250YWluIGNob2ljZSAmIGNhc2UgbmFtZXMgd2hlbiByZWZl
cnJpbmcgdG8gYSBub2RlPyBPciBkbyB0aG9zZSByZWZlciB0byB0aGUgKmRhdGEqIHRyZWUgcmF0
aGVyIHRoYW4gdGhlICpzY2hlbWEqIHRyZWU/ICBJJ20gc3VyZSBpdCBpcyBpbiB0aGVyZSBzb21l
d2hlcmUgYnV0IEkgY291bGRuJ3QgcXVpdGUgZmlndXJlIHRoYXQgb3V0IGZyb20gbG9va2luZyBh
cm91bmQgNzk1MC4NCg0KSmFzb24NCg0KRnJvbTogQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jr
cy5jb20+DQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDE5LCAyMDE4IDM6NTQgUE0NClRvOiBTdGVy
bmUsIEphc29uIChOb2tpYSAtIENBL090dGF3YSkgPGphc29uLnN0ZXJuZUBub2tpYS5jb20+DQpD
YzogTmV0TW9kIFdHIDxuZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gQWRk
aW5nIGEgcHJlLWV4aXN0aW5nIGxlYWYgaW50byBhIG5ldyAnY2hvaWNlJyAtIE5CQyBjaGFuZ2U/
DQoNCg0KT24gTW9uLCBOb3YgMTksIDIwMTggYXQgMTI6MzIgUE0gU3Rlcm5lLCBKYXNvbiAoTm9r
aWEgLSBDQS9PdHRhd2EpIDxqYXNvbi5zdGVybmVAbm9raWEuY29tPG1haWx0bzpqYXNvbi5zdGVy
bmVAbm9raWEuY29tPj4gd3JvdGU6DQpIaSBhbGwsDQoNCklmIHdlIGhhdmUgYSBZQU5HIG1vZGVs
IHdpdGggYSBsZWFmOg0KDQpNT0RFTCBWRVJTSU9OIDE6DQpjb250YWluZXIgbXktbW9kZWwgew0K
ICAgIGxlYWYgYSB7IHR5cGUgc3RyaW5nOyB9DQp9DQoNCkFuZCB0aGVuIGxhdGVyIHdlIHByb2R1
Y2UgYW5vdGhlciB2ZXJzaW9uIG9mIHRoZSBtb2RlbCB3aGVyZSB0aGF0IGxlYWYgaXMgcGxhY2Vk
IGludG8gYSBjaG9pY2UgY29uc3RydWN0Og0KDQpNT0RFTCBWRVJTSU9OIDI6DQpjb250YWluZXIg
bXktbW9kZWwgew0KICAgIGNob2ljZSBzb21lLWNob2ljZSB7DQogICAgICAgIGNhc2UgeCB7DQog
ICAgICAgICAgICBsZWFmIGEgeyB0eXBlIHN0cmluZzsgfQ0KICAgICAgICB9DQogICAgfQ0KfQ0K
DQpJcyB0aGF0IGNvbnNpZGVyZWQgYSBub24tYmFja3dhcmRzLWNvbXBhdGlibGUgY2hhbmdlPw0K
DQoNCnllcyAtLSBldmVuIHRob3VnaCB0aGUgZGF0YSBub2RlIC9teS1tb2RlbC94IGRpZCBub3Qg
Y2hhbmdlLA0KdGhlIHNjaGVtYSBub2RlIC9teS1tb2RlbC9hIGNoYW5nZWQgdG8gL215LW1vZGVs
L3NvbWUtY2hvaWNlL3gvYS4NCkFueSBsZWFmcmVmIHBhdGggcG9pbnRpbmcgYXQgdGhpcyBsZWFm
IHdpbGwgYnJlYWsuDQoNCg0KQW5keQ0KDQoNCkRvZXMgdGhlIGFuc3dlciBkZXBlbmQgb24gd2hl
dGhlciB0aGUgY2hvaWNlIGNvbnRhaW5zIG90aGVyIGNhc2VzIChvciBvdGhlciBjYXNlcyB0aGF0
IGFyZSB0aGUgZGVmYXVsdCBjYXNlKT8NCg0KDQpubw0KDQpNT0RFTCBWRVJTSU9OIDM6DQpjb250
YWluZXIgbXktbW9kZWwgew0KICAgIGNob2ljZSBzb21lLWNob2ljZSB7DQogICAgICAgIGNhc2Ug
eCB7DQogICAgICAgICAgICBsZWFmIGEgeyB0eXBlIHN0cmluZzsgfQ0KICAgICAgICB9DQogICAg
ICAgIGNhc2UgeSB7DQogICAgICAgICAgICBsZWFmIGIgeyB0eXBlIHN0cmluZzsgfQ0KICAgICAg
ICB9DQogICAgfQ0KfQ0KDQpBIGNsaWVudCAnZm9vJyB1c2luZyBWRVJTSU9OIDEgd291bGQgc3Rp
bGwgYmUgYWJsZSB0byBzZXQgJiByZWFkIGJhY2sgbGVhZiBhIGluIHRoZSBzYW1lIHdheSBhcyBp
dCBhbHdheXMgZGlkLg0KDQpCdXQgaWYgYW5vdGhlciBjbGllbnQgJ2JhcicgKHVzaW5nIFZFUlNJ
T04gMykgc2V0cyBsZWFmICdiJywgdGhlbiBsZWFmICdhJyB3b3VsZCBkaXNhcHBlYXIuIFRoYXQg
Y291bGQgYmUgc3VycHJpc2luZyB0byBjbGllbnQgJ2ZvbycgYWx0aG91Z2ggcGVyaGFwcyBubyBt
b3JlIHN1cnByaXNpbmcgdGhhbiBpZiBhbm90aGVyIGNsaWVudCBzaW1wbHkgZGVsZXRlcyBsZWFm
ICdhJyAodXNpbmcgVkVSU0lPTiAxKS4NCg0KSmFzb24NCg0KDQoNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRt
b2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph
OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv
cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z
b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw
bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v
cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z
LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ
bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K
ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h
eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9
IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k
eSBsYW5nPSJFTi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX
b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJl
YXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFua3MgQW5keS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBkaWRuJ3QgcmVhbGl6ZSB0
aGF0IGxlYWZyZWYgcGF0aHMgd291bGQgY29udGFpbiB0aGUgY2hvaWNlICZhbXA7IGNhc2UgbmFt
ZXMgYXMgc2VnbWVudHMgb2YgdGhlIHBhdGguIEJ1dCBub3cgdGhhdCB5b3UgcG9pbnRlZCB0aGF0
IG91dCBpdCBjbGFyaWZpZWQgd2hhdCB0aGlzIG1lYW50IGluIHNlY3Rpb24gNy45IG9mIFJGQzc5
NTA6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsmbmJzcDsgVGhlIGlkZW50aWZp
ZXIgaXMgdXNlZCB0byBpZGVudGlmeSB0aGUgY2hvaWNlPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO
LVVTIj4mbmJzcDsmbmJzcDsgbm9kZSBpbiB0aGUgc2NoZW1hIHRyZWUuJm5ic3A7IEEgY2hvaWNl
IG5vZGUgZG9lcyBub3QgZXhpc3QgaW4gdGhlIGRhdGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t
VVMiPiZuYnNwOyZuYnNwOyB0cmVlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JcyB0aGUgc2FtZSB0aGluZyB0cnVlIGZvciBY
UGF0aHMgaW4gJ211c3QnIGFuZCAnd2hlbicgZXhwcmVzc2lvbnM/IFdvdWxkIHRob3NlIGNvbnRh
aW4gY2hvaWNlICZhbXA7IGNhc2UgbmFtZXMgd2hlbiByZWZlcnJpbmcgdG8gYSBub2RlPyBPciBk
byB0aG9zZSByZWZlciB0byB0aGUgKjxiPmRhdGE8L2I+KiB0cmVlIHJhdGhlciB0aGFuIHRoZSAq
PGI+c2NoZW1hKg0KPC9iPnRyZWU/Jm5ic3A7IEknbSBzdXJlIGl0IGlzIGluIHRoZXJlIHNvbWV3
aGVyZSBidXQgSSBjb3VsZG4ndCBxdWl0ZSBmaWd1cmUgdGhhdCBvdXQgZnJvbSBsb29raW5nIGFy
b3VuZCA3OTUwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0
LWxhbmd1YWdlOkVOLVVTIj5KYXNvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl
ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8
ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk
ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs
YW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gQW5keSBCaWVy
bWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5
LCBOb3ZlbWJlciAxOSwgMjAxOCAzOjU0IFBNPGJyPg0KPGI+VG86PC9iPiBTdGVybmUsIEphc29u
IChOb2tpYSAtIENBL090dGF3YSkgJmx0O2phc29uLnN0ZXJuZUBub2tpYS5jb20mZ3Q7PGJyPg0K
PGI+Q2M6PC9iPiBOZXRNb2QgV0cgJmx0O25ldG1vZEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq
ZWN0OjwvYj4gUmU6IFtuZXRtb2RdIEFkZGluZyBhIHByZS1leGlzdGluZyBsZWFmIGludG8gYSBu
ZXcgJ2Nob2ljZScgLSBOQkMgY2hhbmdlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBN
b24sIE5vdiAxOSwgMjAxOCBhdCAxMjozMiBQTSBTdGVybmUsIEphc29uIChOb2tpYSAtIENBL090
dGF3YSkgJmx0OzxhIGhyZWY9Im1haWx0bzpqYXNvbi5zdGVybmVAbm9raWEuY29tIiB0YXJnZXQ9
Il9ibGFuayI+amFzb24uc3Rlcm5lQG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6
c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0
OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBhbGwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+
SWYgd2UgaGF2ZSBhIFlBTkcgbW9kZWwgd2l0aCBhIGxlYWY6PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V
UyI+TU9ERUwgVkVSU0lPTiAxOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h
bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPmNvbnRhaW5lciBteS1tb2RlbCB7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7IGxlYWYgYSB7IHR5cGUgc3RyaW5nOyB9PC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph
dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+fTwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t
VVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gbGFuZz0iRU4tVVMiPkFuZCB0aGVuIGxhdGVyIHdlIHByb2R1Y2UgYW5vdGhlciB2ZXJz
aW9uIG9mIHRoZSBtb2RlbCB3aGVyZSB0aGF0IGxlYWYgaXMgcGxhY2VkIGludG8gYSBjaG9pY2Ug
Y29uc3RydWN0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+
PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk1PREVMIFZFUlNJT04gMjo8L3NwYW4+
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10
b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT
Ij5jb250YWluZXIgbXktbW9kZWwgezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv
bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyBjaG9pY2Ug
c29tZS1jaG9pY2Ugezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0
byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBjYXNlIHggezwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtsZWFmIGEgeyB0eXBlIHN0cmluZzsg
fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu
Zz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9PC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF
Ti1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i
b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj59PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V
UyI+SXMgdGhhdCBjb25zaWRlcmVkIGEgbm9uLWJhY2t3YXJkcy1jb21wYXRpYmxlIGNoYW5nZT88
L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj55ZXMgLS0gZXZlbiB0aG91Z2ggdGhlIGRhdGEg
bm9kZSAvbXktbW9kZWwveCBkaWQgbm90IGNoYW5nZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBzY2hlbWEgbm9kZSAvbXktbW9kZWwvYSBj
aGFuZ2VkIHRvIC9teS1tb2RlbC9zb21lLWNob2ljZS94L2EuPG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbnkgbGVhZnJlZiBwYXRoIHBvaW50aW5n
IGF0IHRoaXMgbGVhZiB3aWxsIGJyZWFrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx
LjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y
aWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh
bmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0
OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5Eb2VzIHRoZSBhbnN3ZXIgZGVwZW5kIG9uIHdoZXRo
ZXIgdGhlIGNob2ljZSBjb250YWlucyBvdGhlciBjYXNlcyAob3Igb3RoZXIgY2FzZXMgdGhhdCBh
cmUgdGhlIGRlZmF1bHQgY2FzZSk/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPm5vPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt
IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+TU9ERUwgVkVS
U0lPTiAzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw
YW4gbGFuZz0iRU4tVVMiPmNvbnRhaW5lciBteS1tb2RlbCB7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z
by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7IGNob2ljZSBzb21lLWNob2ljZSB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t
Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNhc2UgeCB7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn
aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7ICZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2xlYWYgYSB7
IHR5cGUgc3RyaW5nOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph
dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IH08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i
PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgY2FzZSB5IHs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1
dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbGVhZiBiIHsgdHlwZSBzdHJpbmc7IH08
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9
IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu
LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t
VVMiPiZuYnNwOyZuYnNwOyZuYnNwOyB9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90
dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t
bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv
cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi
PkEgY2xpZW50ICdmb28nIHVzaW5nIFZFUlNJT04gMSB3b3VsZCBzdGlsbCBiZSBhYmxlIHRvIHNl
dCAmYW1wOyByZWFkIGJhY2sgbGVhZiBhIGluIHRoZSBzYW1lIHdheSBhcyBpdCBhbHdheXMgZGlk
Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t
bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu
Zz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkJ1dCBpZiBhbm90aGVyIGNsaWVudCAnYmFyJyAodXNp
bmcgVkVSU0lPTiAzKSBzZXRzIGxlYWYgJ2InLCB0aGVuIGxlYWYgJ2EnIHdvdWxkIGRpc2FwcGVh
ci4gVGhhdCBjb3VsZCBiZSBzdXJwcmlzaW5nIHRvIGNsaWVudCAnZm9vJyBhbHRob3VnaCBwZXJo
YXBzIG5vIG1vcmUNCiBzdXJwcmlzaW5nIHRoYW4gaWYgYW5vdGhlciBjbGllbnQgc2ltcGx5IGRl
bGV0ZXMgbGVhZiAnYScgKHVzaW5nIFZFUlNJT04gMSkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t
YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w
LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+
SmFzb248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu
IGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv
LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRtb2Qg
bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyIgdGFyZ2V0
PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxvOnA+PC9vOnA+PC9wPg0K
PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8
L2h0bWw+DQo=

--_000_DB7PR07MB3978A22EA0FFF32725E37B639BDB0DB7PR07MB3978eurp_--


From nobody Thu Nov 22 05:35: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 621F6130EE0 for ; Thu, 22 Nov 2018 05:35:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 921rMcWWrqiq for ; Thu, 22 Nov 2018 05:35:06 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id DE13C130EDC for ; Thu, 22 Nov 2018 05:35:05 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 29A93182113B; Thu, 22 Nov 2018 14:42:32 +0100 (CET)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id AD2E7182113A; Thu, 22 Nov 2018 14:42:28 +0100 (CET)
From: Ladislav Lhotka 
To: Andy Bierman , "Sterne\, Jason \(Nokia - CA\)" 
Cc: NetMod WG 
In-Reply-To: 
References:  
Mail-Followup-To: Andy Bierman , "Sterne\, Jason \(Nokia - CA\)" , NetMod WG 
Date: Thu, 22 Nov 2018 14:35:00 +0100
Message-ID: <87wop5kzgb.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2018 13:35:09 -0000

Andy Bierman  writes:

> On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
> jason.sterne@nokia.com> wrote:
>
>> Hi all,
>>
>>
>>
>> If we have a YANG model with a leaf:
>>
>>
>>
>> MODEL VERSION 1:
>>
>> container my-model {
>>
>>     leaf a { type string; }
>>
>> }
>>
>>
>>
>> And then later we produce another version of the model where that leaf is
>> placed into a choice construct:
>>
>>
>>
>> MODEL VERSION 2:
>>
>> container my-model {
>>
>>     choice some-choice {
>>
>>         case x {
>>
>>             leaf a { type string; }
>>
>>         }
>>
>>     }
>>
>> }
>>
>>
>>
>> Is that considered a non-backwards-compatible change?
>>
>
>
> yes -- even though the data node /my-model/x did not change,
> the schema node /my-model/a changed to /my-model/some-choice/x/a.
> Any leafref path pointing at this leaf will break.

This is not correct. A leafref path is a special XPath, and as such
includes only data nodes, i.e. NOT choice and case nodes.

What does change are schema node identifier. This could be significant
in an augment statement, but not ini this example because a leaf cannot
be augmented anyway.

I don't see anything else that could break, so Jason's change seems
backward compatible to me.

Lada

>
>
> Andy
>
>
>>
>> Does the answer depend on whether the choice contains other cases (or
>> other cases that are the default case)?
>>
>>
>>
>
> no
>
>
>> MODEL VERSION 3:
>>
>> container my-model {
>>
>>     choice some-choice {
>>
>>         case x {
>>
>>             leaf a { type string; }
>>
>>         }
>>
>>         case y {
>>
>>             leaf b { type string; }
>>
>>         }
>>
>>     }
>>
>> }
>>
>>
>>
>> A client 'foo' using VERSION 1 would still be able to set & read back leaf
>> a in the same way as it always did.
>>
>>
>>
>> But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf 'a'
>> would disappear. That could be surprising to client 'foo' although perhaps
>> no more surprising than if another client simply deletes leaf 'a' (using
>> VERSION 1).
>>
>>
>>
>> Jason
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Thu Nov 22 05:37: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 1F481130EE0 for ; Thu, 22 Nov 2018 05:37: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, 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 v8l15tbYsEuU for ; Thu, 22 Nov 2018 05:37:47 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D815C130EDC for ; Thu, 22 Nov 2018 05:37:46 -0800 (PST)
Received: from localhost (h-39-108.A165.priv.bahnhof.se [213.136.39.108]) by mail.tail-f.com (Postfix) with ESMTPSA id D25371AE018C; Thu, 22 Nov 2018 14:37:45 +0100 (CET)
Date: Thu, 22 Nov 2018 14:37:45 +0100 (CET)
Message-Id: <20181122.143745.956867478908279019.mbj@tail-f.com>
To: jason.sterne@nokia.com
Cc: andy@yumaworks.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:   
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] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2018 13:37:49 -0000

Hi,

"Sterne, Jason (Nokia - CA/Ottawa)"  wrote:
> Thanks Andy.
> 
> I didn't realize that leafref paths would contain the choice & case
> names as segments of the path.

The choice and case nodes are not present in the leafref's path, since
it's an XPath expression that works on the data tree.

Section 9.9.2 says about the context:

   o  If the "path" statement is defined within a typedef, the context
      node is the leaf or leaf-list node in the data tree that
      references the typedef.

   o  Otherwise, the context node is the node in the data tree for which
      the "path" statement is defined.

Note that it says "data tree", not "schema tree".

Also, note how leafref can match on keys:

  path "/interface/interface[name=current()/../mgmt-if-name]/name";

This won't work in the schema tree.

> But now that you pointed that out it
> clarified what this meant in section 7.9 of RFC7950:
>    The identifier is used to identify the choice
>    node in the schema tree.  A choice node does not exist in the data
>    tree.
> 
> Is the same thing true for XPaths in 'must' and 'when' expressions?
> Would those contain choice & case names when referring to a node? Or
> do those refer to the *data* tree rather than the *schema* tree?

All XPath evaluations are done towards a data tree.  So no choice or
state nodes are present there.


/martin

> I'm
> sure it is in there somewhere but I couldn't quite figure that out
> from looking around 7950.
> 
> Jason
> 
> From: Andy Bierman 
> Sent: Monday, November 19, 2018 3:54 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) 
> Cc: NetMod WG 
> Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' -
> NBC change?
> 
> 
> On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa)
> > wrote:
> Hi all,
> 
> If we have a YANG model with a leaf:
> 
> MODEL VERSION 1:
> container my-model {
>     leaf a { type string; }
> }
> 
> And then later we produce another version of the model where that leaf
> is placed into a choice construct:
> 
> MODEL VERSION 2:
> container my-model {
>     choice some-choice {
>         case x {
>             leaf a { type string; }
>         }
>     }
> }
> 
> Is that considered a non-backwards-compatible change?
> 
> 
> yes -- even though the data node /my-model/x did not change,
> the schema node /my-model/a changed to /my-model/some-choice/x/a.
> Any leafref path pointing at this leaf will break.
> 
> 
> Andy
> 
> 
> Does the answer depend on whether the choice contains other cases (or
> other cases that are the default case)?
> 
> 
> no
> 
> MODEL VERSION 3:
> container my-model {
>     choice some-choice {
>         case x {
>             leaf a { type string; }
>         }
>         case y {
>             leaf b { type string; }
>         }
>     }
> }
> 
> A client 'foo' using VERSION 1 would still be able to set & read back
> leaf a in the same way as it always did.
> 
> But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf
> 'a' would disappear. That could be surprising to client 'foo' although
> perhaps no more surprising than if another client simply deletes leaf
> 'a' (using VERSION 1).
> 
> Jason
> 
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Nov 22 05:39: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 46DC8130EE0 for ; Thu, 22 Nov 2018 05:39: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, 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 noVQi1x1GohE for ; Thu, 22 Nov 2018 05:39: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 33EE0130EDC for ; Thu, 22 Nov 2018 05:39:49 -0800 (PST)
Received: from localhost (h-39-108.A165.priv.bahnhof.se [213.136.39.108]) by mail.tail-f.com (Postfix) with ESMTPSA id 7624D1AE018C; Thu, 22 Nov 2018 14:39:48 +0100 (CET)
Date: Thu, 22 Nov 2018 14:39:48 +0100 (CET)
Message-Id: <20181122.143948.1543843065251732639.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: andy@yumaworks.com, jason.sterne@nokia.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <87wop5kzgb.fsf@nic.cz>
References:   <87wop5kzgb.fsf@nic.cz>
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] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2018 13:39:52 -0000

Hi,

Ladislav Lhotka  wrote:
> Andy Bierman  writes:
> 
> > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
> > jason.sterne@nokia.com> wrote:
> >
> >> Hi all,
> >>
> >>
> >>
> >> If we have a YANG model with a leaf:
> >>
> >>
> >>
> >> MODEL VERSION 1:
> >>
> >> container my-model {
> >>
> >>     leaf a { type string; }
> >>
> >> }
> >>
> >>
> >>
> >> And then later we produce another version of the model where that leaf is
> >> placed into a choice construct:
> >>
> >>
> >>
> >> MODEL VERSION 2:
> >>
> >> container my-model {
> >>
> >>     choice some-choice {
> >>
> >>         case x {
> >>
> >>             leaf a { type string; }
> >>
> >>         }
> >>
> >>     }
> >>
> >> }
> >>
> >>
> >>
> >> Is that considered a non-backwards-compatible change?
> >>
> >
> >
> > yes -- even though the data node /my-model/x did not change,
> > the schema node /my-model/a changed to /my-model/some-choice/x/a.
> > Any leafref path pointing at this leaf will break.
> 
> This is not correct. A leafref path is a special XPath, and as such
> includes only data nodes, i.e. NOT choice and case nodes.
> 
> What does change are schema node identifier. This could be significant
> in an augment statement, but not ini this example because a leaf cannot
> be augmented anyway.
> 
> I don't see anything else that could break, so Jason's change seems
> backward compatible to me.

Since it does change the schema tree, this is not legal according to
7950.  So in that sense it is not backwards compatible.  The rules in
7950 protect both clients and other modules that import the module.


/martin



> 
> Lada
> 
> >
> >
> > Andy
> >
> >
> >>
> >> Does the answer depend on whether the choice contains other cases (or
> >> other cases that are the default case)?
> >>
> >>
> >>
> >
> > no
> >
> >
> >> MODEL VERSION 3:
> >>
> >> container my-model {
> >>
> >>     choice some-choice {
> >>
> >>         case x {
> >>
> >>             leaf a { type string; }
> >>
> >>         }
> >>
> >>         case y {
> >>
> >>             leaf b { type string; }
> >>
> >>         }
> >>
> >>     }
> >>
> >> }
> >>
> >>
> >>
> >> A client 'foo' using VERSION 1 would still be able to set & read back leaf
> >> a in the same way as it always did.
> >>
> >>
> >>
> >> But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf 'a'
> >> would disappear. That could be surprising to client 'foo' although perhaps
> >> no more surprising than if another client simply deletes leaf 'a' (using
> >> VERSION 1).
> >>
> >>
> >>
> >> Jason
> >>
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> 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 Nov 22 05:53:12 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01D2130EE0 for ; Thu, 22 Nov 2018 05:53:11 -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 KgkxkInS3ZC8 for ; Thu, 22 Nov 2018 05:53:07 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74F3130DCE for ; Thu, 22 Nov 2018 05:53:06 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id v1-v6so8071969ljd.0 for ; Thu, 22 Nov 2018 05:53:06 -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=9lqEiF5Z9NaeiikHe5QubOXQJdTEjn30la+eW9OmUeg=; b=k8KTfeYBa9NvKc0qGTzYIzDe9l7kZBLhZCfZ/nB7l0DbaB6NhLzUVs21c4qQafHQB1 q8LeKC+4rwwxU9wxMN6/1VOG+DBlh5nrazwyS5qn6V8IkDgvcJb/dy+vFiXdRU7aGcWM C/hW4m8yLNmU3LgIPusvhKuucdW7DodeRS8FCF1gDXXaJxfxKqLZeoalIClxHuWN7MrF 3F3e53YyXDlKmH2TGzVAe1d3y6HS2J5+cxctuSpTvAmDZ00VnbLn8b/KXl5hAkc3ce6Y RgLkoUC/2VrxOONkAg/E41wzxFAvbfwYSrWEDgiPHoIl8GfzYIHlBcUl2pGZTZkB8x0f XGdQ==
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=9lqEiF5Z9NaeiikHe5QubOXQJdTEjn30la+eW9OmUeg=; b=j6+67jMbhDk+AOeZ1e+J4mAv4108c8YFf2JSKAQF44MJL/5gSlbtymz2qn75vUyxzi xpxj0GVMjY18KvhkXMB61EISMuMwFfoMdn5rCVG5OjSXAqmSuvlz6R0wZxiGLGKBTXjZ 3B3sgOJNoOoPpsPpWjS3N2v7em34a837gCCTrg/ZivawAQHpSo4jmgORrajSOdwUcvsL mmFVc1boHvMc6h3iN05N7NK2oCTnySD0sF3E0dRB5519ZCV1FWtFdJ3qkiJ5IewEqTZo Qqe4mRf5tEzkGYAbkHeAxCz/pnyhEwhymfyjmvzDDTn752fBgTVyGMTUC2tMYBoL3q4a NPLg==
X-Gm-Message-State: AA+aEWbEjeOHAiKZQeCrdM6E7FuKZvv+Z8/j7qFNyBDX967ySD0GkvRX NRJR/eupWTdRxRtZqRLfM/CNyvIity6QfO6/IjhHjPZzm1ux8Q==
X-Google-Smtp-Source: AFSGD/WEGiqP3DeHFGuSZxY9qawXjIQGFNFNXUdiKduIrqL5Km0QKSrx/SOc7Rdog+r6p9mq59oJtmHzTZwLrRX9GE4=
X-Received: by 2002:a2e:9556:: with SMTP id t22-v6mr530659ljh.36.1542894784681;  Thu, 22 Nov 2018 05:53:04 -0800 (PST)
MIME-Version: 1.0
References:   <87wop5kzgb.fsf@nic.cz> <20181122.143948.1543843065251732639.mbj@tail-f.com>
In-Reply-To: <20181122.143948.1543843065251732639.mbj@tail-f.com>
From: Andy Bierman 
Date: Thu, 22 Nov 2018 05:52:53 -0800
Message-ID: 
To: Martin Bjorklund 
Cc: Ladislav Lhotka , "Sterne, Jason (Nokia - CA)" , NetMod WG 
Content-Type: multipart/alternative; boundary="00000000000091317a057b412f9e"
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2018 13:53:11 -0000

--00000000000091317a057b412f9e
Content-Type: text/plain; charset="UTF-8"

On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund  wrote:

> Hi,
>
> Ladislav Lhotka  wrote:
> > Andy Bierman  writes:
> >
> > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
> > > jason.sterne@nokia.com> wrote:
> > >
> > >> Hi all,
> > >>
> > >>
> > >>
> > >> If we have a YANG model with a leaf:
> > >>
> > >>
> > >>
> > >> MODEL VERSION 1:
> > >>
> > >> container my-model {
> > >>
> > >>     leaf a { type string; }
> > >>
> > >> }
> > >>
> > >>
> > >>
> > >> And then later we produce another version of the model where that
> leaf is
> > >> placed into a choice construct:
> > >>
> > >>
> > >>
> > >> MODEL VERSION 2:
> > >>
> > >> container my-model {
> > >>
> > >>     choice some-choice {
> > >>
> > >>         case x {
> > >>
> > >>             leaf a { type string; }
> > >>
> > >>         }
> > >>
> > >>     }
> > >>
> > >> }
> > >>
> > >>
> > >>
> > >> Is that considered a non-backwards-compatible change?
> > >>
> > >
> > >
> > > yes -- even though the data node /my-model/x did not change,
> > > the schema node /my-model/a changed to /my-model/some-choice/x/a.
> > > Any leafref path pointing at this leaf will break.
> >
> > This is not correct. A leafref path is a special XPath, and as such
> > includes only data nodes, i.e. NOT choice and case nodes.
> >
> > What does change are schema node identifier. This could be significant
> > in an augment statement, but not ini this example because a leaf cannot
> > be augmented anyway.
> >
> > I don't see anything else that could break, so Jason's change seems
> > backward compatible to me.
>
> Since it does change the schema tree, this is not legal according to
> 7950.  So in that sense it is not backwards compatible.  The rules in
> 7950 protect both clients and other modules that import the module.
>
>
This text is confusing wrt/ schema tree vs data tree:


9.9 .  The leafref
Built-In Type

   The leafref built-in type is restricted to the value space of some
   leaf or leaf-list node in the schema tree and optionally further
   restricted by corresponding instance nodes in the data tree.  The
   "path" substatement (Section 9.9.2
) is used to
identify the referred
   leaf or leaf-list node in the schema tree.  The value space of the
   referring node is the value space of the referred node.





>
> /martin
>
>

Andy


>
>
> >
> > Lada
> >
> > >
> > >
> > > Andy
> > >
> > >
> > >>
> > >> Does the answer depend on whether the choice contains other cases (or
> > >> other cases that are the default case)?
> > >>
> > >>
> > >>
> > >
> > > no
> > >
> > >
> > >> MODEL VERSION 3:
> > >>
> > >> container my-model {
> > >>
> > >>     choice some-choice {
> > >>
> > >>         case x {
> > >>
> > >>             leaf a { type string; }
> > >>
> > >>         }
> > >>
> > >>         case y {
> > >>
> > >>             leaf b { type string; }
> > >>
> > >>         }
> > >>
> > >>     }
> > >>
> > >> }
> > >>
> > >>
> > >>
> > >> A client 'foo' using VERSION 1 would still be able to set & read back
> leaf
> > >> a in the same way as it always did.
> > >>
> > >>
> > >>
> > >> But if another client 'bar' (using VERSION 3) sets leaf 'b', then
> leaf 'a'
> > >> would disappear. That could be surprising to client 'foo' although
> perhaps
> > >> no more surprising than if another client simply deletes leaf 'a'
> (using
> > >> VERSION 1).
> > >>
> > >>
> > >>
> > >> Jason
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> 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
> >
>

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




On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,



Ladislav Lhotka <lhot=
ka@nic.cz> wrote:

> Andy Bierman <andy@yumaworks.com> writes:

> 

> > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa=
) <

> > jason=
.sterne@nokia.com> wrote:

> >

> >> Hi all,

> >>

> >>

> >>

> >> If we have a YANG model with a leaf:

> >>

> >>

> >>

> >> MODEL VERSION 1:

> >>

> >> container my-model {

> >>

> >>=C2=A0 =C2=A0 =C2=A0leaf a { type string; }

> >>

> >> }

> >>

> >>

> >>

> >> And then later we produce another version of the model where =
that leaf is

> >> placed into a choice construct:

> >>

> >>

> >>

> >> MODEL VERSION 2:

> >>

> >> container my-model {

> >>

> >>=C2=A0 =C2=A0 =C2=A0choice some-choice {

> >>

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case x {

> >>

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf a { type =
string; }

> >>

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

> >>

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

> >>

> >> }

> >>

> >>

> >>

> >> Is that considered a non-backwards-compatible change?

> >>

> >

> >

> > yes -- even though the data node /my-model/x did not change,

> > the schema node /my-model/a changed to /my-model/some-choice/x/a.=


> > Any leafref path pointing at this leaf will break.

> 

> This is not correct. A leafref path is a special XPath, and as such
> includes only data nodes, i.e. NOT choice and case nodes.

> 

> What does change are schema node identifier. This could be significant=


> in an augment statement, but not ini this example because a leaf canno=
t

> be augmented anyway.

> 

> I don't see anything else that could break, so Jason's change =
seems

> backward compatible to me.



Since it does change the schema tree, this is not legal according to

7950.=C2=A0 So in that sense it is not backwards compatible.=C2=A0 The rule=
s in

7950 protect both clients and other modules that import the module.



This text is confusing wrt/ schema tre=
e vs data tree:


9.9.  The leafref Built-In Type


   The leafref built-in type is restricted to the value space of some
   leaf or leaf-list node in the schema tree and optionally further
   restricted by corresponding instance nodes in the data tree.  The
   "path" substatement (Section 9.9.2) is used to identify the referred
   leaf or leaf-list node in the schema tree.  The value space of the
   referring node is the value space of the referred node.



=C2=A0



/martin




Andy
=C2=A0





> 

> Lada

> 

> >

> >

> > Andy

> >

> >

> >>

> >> Does the answer depend on whether the choice contains other c=
ases (or

> >> other cases that are the default case)?

> >>

> >>

> >>

> >

> > no

> >

> >

> >> MODEL VERSION 3:

> >>

> >> container my-model {

> >>

> >>=C2=A0 =C2=A0 =C2=A0choice some-choice {

> >>

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case x {

> >>

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf a { type =
string; }

> >>

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

> >>

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case y {

> >>

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf b { type =
string; }

> >>

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

> >>

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

> >>

> >> }

> >>

> >>

> >>

> >> A client 'foo' using VERSION 1 would still be able to=
 set & read back leaf

> >> a in the same way as it always did.

> >>

> >>

> >>

> >> But if another client 'bar' (using VERSION 3) sets le=
af 'b', then leaf 'a'

> >> would disappear. That could be surprising to client 'foo&=
#39; although perhaps

> >> no more surprising than if another client simply deletes leaf=
 'a' (using

> >> VERSION 1).

> >>

> >>

> >>

> >> Jason

> >>

> >>

> >>

> >>

> >>

> >>

> >> _______________________________________________

> >> netmod mailing list

> >> netmod@i=
etf.org

> >> https://www.ietf.org/mailman/listinfo/net=
mod

> >>

> > _______________________________________________

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




--00000000000091317a057b412f9e--


From nobody Thu Nov 22 05:59: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 47F32130ED9 for ; Thu, 22 Nov 2018 05:59:14 -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 udo7xuDOdySK for ; Thu, 22 Nov 2018 05:59:11 -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 3D80112EB11 for ; Thu, 22 Nov 2018 05:59:11 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 7F17A64235 for ; Thu, 22 Nov 2018 14:59:08 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1542895148; bh=jBdeLLC7vFhBQR9blNfXu1+q3xNZ0hlQo3KThlgJfOg=; h=From:To:Date; b=pJGqK7mnO56hnB81S48TaDE+0O1Xt6sAu8k7/ei8EqdU9mGczJ/ulP1HmBnCLipDs gBooxK/aZbr4X2Bju9z9xy7bdRHz7mNJ+USanUCCIWijrG+jJotm7u8QJFTmbOTk2t GNS1S6HTjoN4Qu+2duHEt6cE3f+0ROsLpj32mFHY=
Message-ID: <378d35ce154cb00c390a55e6b88ceb21ca74ebf2.camel@nic.cz>
From: Ladislav Lhotka 
To: NETMOD WG 
Date: Thu, 22 Nov 2018 14:59:08 +0100
In-Reply-To: <20181122.143948.1543843065251732639.mbj@tail-f.com>
References:   <87wop5kzgb.fsf@nic.cz> <20181122.143948.1543843065251732639.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2018 13:59:14 -0000

On Thu, 2018-11-22 at 14:39 +0100, Martin Bjorklund wrote:
> Hi,
> 
> Ladislav Lhotka  wrote:
> > Andy Bierman  writes:
> > 
> > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
> > > jason.sterne@nokia.com> wrote:
> > > 
> > > > Hi all,
> > > > 
> > > > 
> > > > 
> > > > If we have a YANG model with a leaf:
> > > > 
> > > > 
> > > > 
> > > > MODEL VERSION 1:
> > > > 
> > > > container my-model {
> > > > 
> > > >     leaf a { type string; }
> > > > 
> > > > }
> > > > 
> > > > 
> > > > 
> > > > And then later we produce another version of the model where that leaf
> > > > is
> > > > placed into a choice construct:
> > > > 
> > > > 
> > > > 
> > > > MODEL VERSION 2:
> > > > 
> > > > container my-model {
> > > > 
> > > >     choice some-choice {
> > > > 
> > > >         case x {
> > > > 
> > > >             leaf a { type string; }
> > > > 
> > > >         }
> > > > 
> > > >     }
> > > > 
> > > > }
> > > > 
> > > > 
> > > > 
> > > > Is that considered a non-backwards-compatible change?
> > > > 
> > > 
> > > yes -- even though the data node /my-model/x did not change,
> > > the schema node /my-model/a changed to /my-model/some-choice/x/a.
> > > Any leafref path pointing at this leaf will break.
> > 
> > This is not correct. A leafref path is a special XPath, and as such
> > includes only data nodes, i.e. NOT choice and case nodes.
> > 
> > What does change are schema node identifier. This could be significant
> > in an augment statement, but not ini this example because a leaf cannot
> > be augmented anyway.
> > 
> > I don't see anything else that could break, so Jason's change seems
> > backward compatible to me.
> 
> Since it does change the schema tree, this is not legal according to
> 7950.  So in that sense it is not backwards compatible.  The rules in
> 7950 protect both clients and other modules that import the module.

Section 11 does not explicitly forbid changes that change schema node
identifiers. On the other hand, it contains this item:

   o  Any set of data definition nodes may be replaced with another set
      of syntactically and semantically equivalent nodes.  For example,
      a set of leafs may be replaced by a "uses" statement of a grouping
      with the same leafs.

I think this applies nicely to the current case: the modified schema is arguably
semantically equivalent to the old one.

Lada


> 
> /martin
> 
> 
> 
> > Lada
> > 
> > > 
> > > Andy
> > > 
> > > 
> > > > Does the answer depend on whether the choice contains other cases (or
> > > > other cases that are the default case)?
> > > > 
> > > > 
> > > > 
> > > 
> > > no
> > > 
> > > 
> > > > MODEL VERSION 3:
> > > > 
> > > > container my-model {
> > > > 
> > > >     choice some-choice {
> > > > 
> > > >         case x {
> > > > 
> > > >             leaf a { type string; }
> > > > 
> > > >         }
> > > > 
> > > >         case y {
> > > > 
> > > >             leaf b { type string; }
> > > > 
> > > >         }
> > > > 
> > > >     }
> > > > 
> > > > }
> > > > 
> > > > 
> > > > 
> > > > A client 'foo' using VERSION 1 would still be able to set & read back
> leaf
> > > > a in the same way as it always did.
> > > > 
> > > > 
> > > > 
> > > > But if another client 'bar' (using VERSION 3) sets leaf 'b', then leaf
> 'a'
> > > > would disappear. That could be surprising to client 'foo' although
> perhaps
> > > > no more surprising than if another client simply deletes leaf 'a' (using
> > > > VERSION 1).
> > > > 
> > > > 
> > > > 
> > > > Jason
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > 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 Nov 22 06:00:32 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEAC130ED9 for ; Thu, 22 Nov 2018 06:00:30 -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 H0XQYTbH5-y5 for ; Thu, 22 Nov 2018 06:00:28 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4863A12EB11 for ; Thu, 22 Nov 2018 06:00:28 -0800 (PST)
Received: from localhost (h-39-108.A165.priv.bahnhof.se [213.136.39.108]) by mail.tail-f.com (Postfix) with ESMTPSA id 7780F1AE018C; Thu, 22 Nov 2018 15:00:27 +0100 (CET)
Date: Thu, 22 Nov 2018 15:00:27 +0100 (CET)
Message-Id: <20181122.150027.823800945772964674.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: lhotka@nic.cz, jason.sterne@nokia.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <87wop5kzgb.fsf@nic.cz> <20181122.143948.1543843065251732639.mbj@tail-f.com> 
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] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2018 14:00:30 -0000

Andy Bierman  wrote:
> On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund  wrote:
> 
> > Hi,
> >
> > Ladislav Lhotka  wrote:
> > > Andy Bierman  writes:
> > >
> > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
> > > > jason.sterne@nokia.com> wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >>
> > > >>
> > > >> If we have a YANG model with a leaf:
> > > >>
> > > >>
> > > >>
> > > >> MODEL VERSION 1:
> > > >>
> > > >> container my-model {
> > > >>
> > > >>     leaf a { type string; }
> > > >>
> > > >> }
> > > >>
> > > >>
> > > >>
> > > >> And then later we produce another version of the model where that
> > leaf is
> > > >> placed into a choice construct:
> > > >>
> > > >>
> > > >>
> > > >> MODEL VERSION 2:
> > > >>
> > > >> container my-model {
> > > >>
> > > >>     choice some-choice {
> > > >>
> > > >>         case x {
> > > >>
> > > >>             leaf a { type string; }
> > > >>
> > > >>         }
> > > >>
> > > >>     }
> > > >>
> > > >> }
> > > >>
> > > >>
> > > >>
> > > >> Is that considered a non-backwards-compatible change?
> > > >>
> > > >
> > > >
> > > > yes -- even though the data node /my-model/x did not change,
> > > > the schema node /my-model/a changed to /my-model/some-choice/x/a.
> > > > Any leafref path pointing at this leaf will break.
> > >
> > > This is not correct. A leafref path is a special XPath, and as such
> > > includes only data nodes, i.e. NOT choice and case nodes.
> > >
> > > What does change are schema node identifier. This could be significant
> > > in an augment statement, but not ini this example because a leaf cannot
> > > be augmented anyway.
> > >
> > > I don't see anything else that could break, so Jason's change seems
> > > backward compatible to me.
> >
> > Since it does change the schema tree, this is not legal according to
> > 7950.  So in that sense it is not backwards compatible.  The rules in
> > 7950 protect both clients and other modules that import the module.
> >
> >
> This text is confusing wrt/ schema tree vs data tree:
> 
> 
> 9.9 .  The leafref
> Built-In Type
> 
>    The leafref built-in type is restricted to the value space of some
>    leaf or leaf-list node in the schema tree and optionally further
>    restricted by corresponding instance nodes in the data tree.  The
>    "path" substatement (Section 9.9.2
> ) is used to
> identify the referred
>    leaf or leaf-list node in the schema tree.  The value space of the
>    referring node is the value space of the referred node.

Yes, it should be "data tree" in both occurrences.



/martin


> 
> 
> 
> 
> 
> >
> > /martin
> >
> >
> 
> Andy
> 
> 
> >
> >
> > >
> > > Lada
> > >
> > > >
> > > >
> > > > Andy
> > > >
> > > >
> > > >>
> > > >> Does the answer depend on whether the choice contains other cases (or
> > > >> other cases that are the default case)?
> > > >>
> > > >>
> > > >>
> > > >
> > > > no
> > > >
> > > >
> > > >> MODEL VERSION 3:
> > > >>
> > > >> container my-model {
> > > >>
> > > >>     choice some-choice {
> > > >>
> > > >>         case x {
> > > >>
> > > >>             leaf a { type string; }
> > > >>
> > > >>         }
> > > >>
> > > >>         case y {
> > > >>
> > > >>             leaf b { type string; }
> > > >>
> > > >>         }
> > > >>
> > > >>     }
> > > >>
> > > >> }
> > > >>
> > > >>
> > > >>
> > > >> A client 'foo' using VERSION 1 would still be able to set & read back
> > leaf
> > > >> a in the same way as it always did.
> > > >>
> > > >>
> > > >>
> > > >> But if another client 'bar' (using VERSION 3) sets leaf 'b', then
> > leaf 'a'
> > > >> would disappear. That could be surprising to client 'foo' although
> > perhaps
> > > >> no more surprising than if another client simply deletes leaf 'a'
> > (using
> > > >> VERSION 1).
> > > >>
> > > >>
> > > >>
> > > >> Jason
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> _______________________________________________
> > > >> 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 Nov 22 06:26:39 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F244C130F15 for ; Thu, 22 Nov 2018 06:26:23 -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 jDhsrdm3EO0J for ; Thu, 22 Nov 2018 06:26:16 -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 93A35130EFF for ; Thu, 22 Nov 2018 06:26:15 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 9DA5F64256; Thu, 22 Nov 2018 15:26:12 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1542896772; bh=+/Juk7erqVUiU1Q5GPi4ExdibB6NZ0EBP37CYzjEXYw=; h=From:To:Date; b=oeuNQxEPOwaixKCGQAmk5RW5751q1bk2L7nZPT/CwxpvimsOL2xeXsd0AWr1k/Cx+ If0hVvp2uQ9n1pMb1UJGtuSn6nqyOzqF5r6mHHbDZtYO0Td/JdhGPD0rWtXJj9+2u6 dZZ4m0z3pT3M4zq709wOjahjoP2CGWbSGo1ze6rs=
Message-ID: 
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: NETMOD WG 
Date: Thu, 22 Nov 2018 15:26:12 +0100
In-Reply-To: <20181122.150156.1985409098195442690.mbj@tail-f.com>
References: <87wop5kzgb.fsf@nic.cz> <20181122.143948.1543843065251732639.mbj@tail-f.com> <1930836700bcb03d6a1cbd829b46281c746ef629.camel@nic.cz> <20181122.150156.1985409098195442690.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2018 14:26:24 -0000

On Thu, 2018-11-22 at 15:01 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > On Thu, 2018-11-22 at 14:39 +0100, Martin Bjorklund wrote:
> > > Hi,
> > > 
> > > Ladislav Lhotka  wrote:
> > > > Andy Bierman  writes:
> > > > 
> > > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
> > > > > jason.sterne@nokia.com> wrote:
> > > > >
> > > > >> Hi all,
> > > > >>
> > > > >>
> > > > >>
> > > > >> If we have a YANG model with a leaf:
> > > > >>
> > > > >>
> > > > >>
> > > > >> MODEL VERSION 1:
> > > > >>
> > > > >> container my-model {
> > > > >>
> > > > >>     leaf a { type string; }
> > > > >>
> > > > >> }
> > > > >>
> > > > >>
> > > > >>
> > > > >> And then later we produce another version of the model where that
> leaf is
> > > > >> placed into a choice construct:
> > > > >>
> > > > >>
> > > > >>
> > > > >> MODEL VERSION 2:
> > > > >>
> > > > >> container my-model {
> > > > >>
> > > > >>     choice some-choice {
> > > > >>
> > > > >>         case x {
> > > > >>
> > > > >>             leaf a { type string; }
> > > > >>
> > > > >>         }
> > > > >>
> > > > >>     }
> > > > >>
> > > > >> }
> > > > >>
> > > > >>
> > > > >>
> > > > >> Is that considered a non-backwards-compatible change?
> > > > >>
> > > > >
> > > > >
> > > > > yes -- even though the data node /my-model/x did not change,
> > > > > the schema node /my-model/a changed to /my-model/some-choice/x/a.
> > > > > Any leafref path pointing at this leaf will break.
> > > > 
> > > > This is not correct. A leafref path is a special XPath, and as such
> > > > includes only data nodes, i.e. NOT choice and case nodes.
> > > > 
> > > > What does change are schema node identifier. This could be significant
> > > > in an augment statement, but not ini this example because a leaf cannot
> > > > be augmented anyway.
> > > > 
> > > > I don't see anything else that could break, so Jason's change seems
> > > > backward compatible to me.
> > > 
> > > Since it does change the schema tree, this is not legal according to
> > > 7950.  So in that sense it is not backwards compatible.  The rules in
> > > 7950 protect both clients and other modules that import the module.
> > 
> > Section 11 does not explicitly forbid changes that change schema node
> > identifiers. On the other hand, it contains this item:
> > 
> >    o  Any set of data definition nodes may be replaced with another set
> >       of syntactically and semantically equivalent nodes.  For example,
> >       a set of leafs may be replaced by a "uses" statement of a grouping
> >       with the same leafs.
> 
> But moving nodes into a grouping that is used doesn't change the
> schema tree.

The grouping is mentioned there as an example.

> 
> 
> > I think this applies nicely to the current case: the modified schema
> > is arguably
> > semantically equivalent to the old one.
> 
> But not syntactically (in the schema tree).

Well, "syntactically equivalent" is not defined in RFC 7950, and intuitively it
is not clear at all that it means "the same schema tree". In fact, the example
with a grouping leads to a different abstract syntax tree for the YANG module,
so one could also argue that it is not syntactically equivalent.

"Semantically equivalent" makes more sense: schemas A and B are semantically
equivalent if all data trees valid against A are also valid against B, and vice
versa.

Lada 

> 
> 
> /martin
> 
> 
> > 
> > Lada
> > 
> > 
> > > 
> > > 
> > > /martin
> > > 
> > > 
> > > 
> > > > 
> > > > Lada
> > > > 
> > > > >
> > > > >
> > > > > Andy
> > > > >
> > > > >
> > > > >>
> > > > >> Does the answer depend on whether the choice contains other cases (or
> > > > >> other cases that are the default case)?
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > > no
> > > > >
> > > > >
> > > > >> MODEL VERSION 3:
> > > > >>
> > > > >> container my-model {
> > > > >>
> > > > >>     choice some-choice {
> > > > >>
> > > > >>         case x {
> > > > >>
> > > > >>             leaf a { type string; }
> > > > >>
> > > > >>         }
> > > > >>
> > > > >>         case y {
> > > > >>
> > > > >>             leaf b { type string; }
> > > > >>
> > > > >>         }
> > > > >>
> > > > >>     }
> > > > >>
> > > > >> }
> > > > >>
> > > > >>
> > > > >>
> > > > >> A client 'foo' using VERSION 1 would still be able to set & read back
> > > leaf
> > > > >> a in the same way as it always did.
> > > > >>
> > > > >>
> > > > >>
> > > > >> But if another client 'bar' (using VERSION 3) sets leaf 'b', then
> leaf
> > > 'a'
> > > > >> would disappear. That could be surprising to client 'foo' although
> > > perhaps
> > > > >> no more surprising than if another client simply deletes leaf 'a'
> (using
> > > > >> VERSION 1).
> > > > >>
> > > > >>
> > > > >>
> > > > >> Jason
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> _______________________________________________
> > > > >> 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
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Thu Nov 22 07:07: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 89C15130EFF for ; Thu, 22 Nov 2018 07:07:52 -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 nNcTGdJRZNT4 for ; Thu, 22 Nov 2018 07:07:49 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BD9712DD85 for ; Thu, 22 Nov 2018 07:07:49 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 19FD2642F2; Thu, 22 Nov 2018 16:07:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1542899267; bh=DkQraSeMitUnO+VmbjqD27k1w1d/qejNF9ZKtjKFzTc=; h=From:To:Date; b=SfBeVG8Wa9gwKprDwLHrKbkcH2UAb9GXp6uWEBBJmTrSYBROCOhBXQ8mR1mHpnkc9 d0Ft9vd3iMbbrRTc33FUsB8luy7jUd4CDgZo9T9ufhw9OzC0z6bu7Y+aU71WszrUQu 8Af7pxtxUKOsDeDLGt2NfW5g8i6d8CtOhs81smC0=
Message-ID: 
From: Ladislav Lhotka 
To: Martin Bjorklund , andy@yumaworks.com
Cc: jason.sterne@nokia.com, netmod@ietf.org
Date: Thu, 22 Nov 2018 16:07:46 +0100
In-Reply-To: <20181122.150027.823800945772964674.mbj@tail-f.com>
References: <87wop5kzgb.fsf@nic.cz> <20181122.143948.1543843065251732639.mbj@tail-f.com>  <20181122.150027.823800945772964674.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2018 15:07:52 -0000

On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote:
> Andy Bierman  wrote:
> > On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund  wrote:
> > 
> > > Hi,
> > >
> > > Ladislav Lhotka  wrote:
> > > > Andy Bierman  writes:
> > > >
> > > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
> > > > > jason.sterne@nokia.com> wrote:
> > > > >
> > > > >> Hi all,
> > > > >>
> > > > >>
> > > > >>
> > > > >> If we have a YANG model with a leaf:
> > > > >>
> > > > >>
> > > > >>
> > > > >> MODEL VERSION 1:
> > > > >>
> > > > >> container my-model {
> > > > >>
> > > > >>     leaf a { type string; }
> > > > >>
> > > > >> }
> > > > >>
> > > > >>
> > > > >>
> > > > >> And then later we produce another version of the model where that
> > > leaf is
> > > > >> placed into a choice construct:
> > > > >>
> > > > >>
> > > > >>
> > > > >> MODEL VERSION 2:
> > > > >>
> > > > >> container my-model {
> > > > >>
> > > > >>     choice some-choice {
> > > > >>
> > > > >>         case x {
> > > > >>
> > > > >>             leaf a { type string; }
> > > > >>
> > > > >>         }
> > > > >>
> > > > >>     }
> > > > >>
> > > > >> }
> > > > >>
> > > > >>
> > > > >>
> > > > >> Is that considered a non-backwards-compatible change?
> > > > >>
> > > > >
> > > > >
> > > > > yes -- even though the data node /my-model/x did not change,
> > > > > the schema node /my-model/a changed to /my-model/some-choice/x/a.
> > > > > Any leafref path pointing at this leaf will break.
> > > >
> > > > This is not correct. A leafref path is a special XPath, and as such
> > > > includes only data nodes, i.e. NOT choice and case nodes.
> > > >
> > > > What does change are schema node identifier. This could be significant
> > > > in an augment statement, but not ini this example because a leaf cannot
> > > > be augmented anyway.
> > > >
> > > > I don't see anything else that could break, so Jason's change seems
> > > > backward compatible to me.
> > >
> > > Since it does change the schema tree, this is not legal according to
> > > 7950.  So in that sense it is not backwards compatible.  The rules in
> > > 7950 protect both clients and other modules that import the module.
> > >
> > >
> > This text is confusing wrt/ schema tree vs data tree:
> > 
> > 
> > 9.9 ;.  The leafref
> > Built-In Type
> > 
> >    The leafref built-in type is restricted to the value space of some
> >    leaf or leaf-list node in the schema tree and optionally further
> >    restricted by corresponding instance nodes in the data tree.  The
> >    "path" substatement (Section 9.9.2
> > ;) is used to
> > identify the referred
> >    leaf or leaf-list node in the schema tree.  The value space of the
> >    referring node is the value space of the referred node.
> 
> Yes, it should be "data tree" in both occurrences.

I tend to disagree. The values of a leafref are first restricted according to
the *schema*, i.e. even before any leaf instance exists in the data tree that
the leafref can point to. Consider this example:

list map {
  key name;
  leaf name {
    type string;
  }
  leaf value {
    type uint8;
  }
}
leaf link {
  type leafref {
    path "../map[name='quux']/value";
    default "foo";
  }
}

We had a long discussion about this, maybe I could find it, and the conclusion
was that a YANG parser should flag the default "foo" value as incorrect even
before any instance data are in sight.

I wasn't exactly happy with this conclusion because it assumes that we can use
the XPath from the argument of "path" to locate the *schema node* and check its
type. Although it looks appealing (everybody sees what the type of "value" is,
right?), I think this is just another unfortunate example of mixing up the
schema and data instances.

Let me ask: can we expect a newcomer to understand what's going on if even
seasoned YANG doctors get confused?

Lada 

> 
> 
> 
> /martin
> 
> 
> > 
> > 
> > 
> > 
> > 
> > >
> > > /martin
> > >
> > >
> > 
> > Andy
> > 
> > 
> > >
> > >
> > > >
> > > > Lada
> > > >
> > > > >
> > > > >
> > > > > Andy
> > > > >
> > > > >
> > > > >>
> > > > >> Does the answer depend on whether the choice contains other cases (or
> > > > >> other cases that are the default case)?
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > > no
> > > > >
> > > > >
> > > > >> MODEL VERSION 3:
> > > > >>
> > > > >> container my-model {
> > > > >>
> > > > >>     choice some-choice {
> > > > >>
> > > > >>         case x {
> > > > >>
> > > > >>             leaf a { type string; }
> > > > >>
> > > > >>         }
> > > > >>
> > > > >>         case y {
> > > > >>
> > > > >>             leaf b { type string; }
> > > > >>
> > > > >>         }
> > > > >>
> > > > >>     }
> > > > >>
> > > > >> }
> > > > >>
> > > > >>
> > > > >>
> > > > >> A client 'foo' using VERSION 1 would still be able to set & read back
> > > leaf
> > > > >> a in the same way as it always did.
> > > > >>
> > > > >>
> > > > >>
> > > > >> But if another client 'bar' (using VERSION 3) sets leaf 'b', then
> > > leaf 'a'
> > > > >> would disappear. That could be surprising to client 'foo' although
> > > perhaps
> > > > >> no more surprising than if another client simply deletes leaf 'a'
> > > (using
> > > > >> VERSION 1).
> > > > >>
> > > > >>
> > > > >>
> > > > >> Jason
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> _______________________________________________
> > > > >> 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 Nov 22 07:14: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 EB52112DD85 for ; Thu, 22 Nov 2018 07:14:41 -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 H1-ACvd06mD1 for ; Thu, 22 Nov 2018 07:14:40 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 52B4C126CB6 for ; Thu, 22 Nov 2018 07:14:39 -0800 (PST)
Received: from localhost (h-39-108.A165.priv.bahnhof.se [213.136.39.108]) by mail.tail-f.com (Postfix) with ESMTPSA id 86E7F1AE018C; Thu, 22 Nov 2018 16:14:38 +0100 (CET)
Date: Thu, 22 Nov 2018 16:14:38 +0100 (CET)
Message-Id: <20181122.161438.975515366125603770.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: andy@yumaworks.com, jason.sterne@nokia.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <20181122.150027.823800945772964674.mbj@tail-f.com> 
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] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2018 15:14:42 -0000

Ladislav Lhotka  wrote:
> On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote:
> > Andy Bierman  wrote:
> > > On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund  wrote:
> > > 
> > > > Hi,
> > > >
> > > > Ladislav Lhotka  wrote:
> > > > > Andy Bierman  writes:
> > > > >
> > > > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa) <
> > > > > > jason.sterne@nokia.com> wrote:
> > > > > >
> > > > > >> Hi all,
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> If we have a YANG model with a leaf:
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> MODEL VERSION 1:
> > > > > >>
> > > > > >> container my-model {
> > > > > >>
> > > > > >>     leaf a { type string; }
> > > > > >>
> > > > > >> }
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> And then later we produce another version of the model where that
> > > > leaf is
> > > > > >> placed into a choice construct:
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> MODEL VERSION 2:
> > > > > >>
> > > > > >> container my-model {
> > > > > >>
> > > > > >>     choice some-choice {
> > > > > >>
> > > > > >>         case x {
> > > > > >>
> > > > > >>             leaf a { type string; }
> > > > > >>
> > > > > >>         }
> > > > > >>
> > > > > >>     }
> > > > > >>
> > > > > >> }
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> Is that considered a non-backwards-compatible change?
> > > > > >>
> > > > > >
> > > > > >
> > > > > > yes -- even though the data node /my-model/x did not change,
> > > > > > the schema node /my-model/a changed to /my-model/some-choice/x/a.
> > > > > > Any leafref path pointing at this leaf will break.
> > > > >
> > > > > This is not correct. A leafref path is a special XPath, and as such
> > > > > includes only data nodes, i.e. NOT choice and case nodes.
> > > > >
> > > > > What does change are schema node identifier. This could be significant
> > > > > in an augment statement, but not ini this example because a leaf cannot
> > > > > be augmented anyway.
> > > > >
> > > > > I don't see anything else that could break, so Jason's change seems
> > > > > backward compatible to me.
> > > >
> > > > Since it does change the schema tree, this is not legal according to
> > > > 7950.  So in that sense it is not backwards compatible.  The rules in
> > > > 7950 protect both clients and other modules that import the module.
> > > >
> > > >
> > > This text is confusing wrt/ schema tree vs data tree:
> > > 
> > > 
> > > 9.9 ;.  The leafref
> > > Built-In Type
> > > 
> > >    The leafref built-in type is restricted to the value space of some
> > >    leaf or leaf-list node in the schema tree and optionally further
> > >    restricted by corresponding instance nodes in the data tree.  The
> > >    "path" substatement (Section 9.9.2
> > > ;) is used to
> > > identify the referred
> > >    leaf or leaf-list node in the schema tree.  The value space of the
> > >    referring node is the value space of the referred node.
> > 
> > Yes, it should be "data tree" in both occurrences.
> 
> I tend to disagree. The values of a leafref are first restricted according to
> the *schema*, i.e. even before any leaf instance exists in the data tree that
> the leafref can point to. Consider this example:
> 
> list map {
>   key name;
>   leaf name {
>     type string;
>   }
>   leaf value {
>     type uint8;
>   }
> }
> leaf link {
>   type leafref {
>     path "../map[name='quux']/value";
>     default "foo";
>   }
> }
> 
> We had a long discussion about this, maybe I could find it, and the conclusion
> was that a YANG parser should flag the default "foo" value as incorrect even
> before any instance data are in sight.

Yes, this is correct.  The quoted text needs to be rewritten to make
this more clear.  Altough the path refers to a (potential) node in the
data tree, that node obviously has a node in the schema tree, and its
value space restricts the value space of the leafref node.

> I wasn't exactly happy with this conclusion because it assumes that we can use
> the XPath from the argument of "path" to locate the *schema node* and check its
> type. Although it looks appealing (everybody sees what the type of "value" is,
> right?), I think this is just another unfortunate example of mixing up the
> schema and data instances.
> 
> Let me ask: can we expect a newcomer to understand what's going on if even
> seasoned YANG doctors get confused?

Yes.

I've been told that people don't read documentation or specifications
and just look at examples.



/martin


From nobody Thu Nov 22 07:15:47 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C2D126CB6; Thu, 22 Nov 2018 07:15:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vD1YPN3AwWse; Thu, 22 Nov 2018 07:15:43 -0800 (PST)
Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 95211130ED9; Thu, 22 Nov 2018 07:15:43 -0800 (PST)
Received: by mail-pl1-x636.google.com with SMTP id x21-v6so9394154pln.9; Thu, 22 Nov 2018 07:15:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fTN1oTl4BnZ4lY/ByqHj7eWnDMOArfz5roXGzVzbC9E=; b=Q3j542dqsQ/RD/gIgKETIDYIzZOxq7yE+zE2AWR0fnSldSHip0erTiQPl9bXe2KHFO QOdZT+IHsMNQYH80EnYUe/doyaliXiZJIARvxKH+HV+7idOz26OeVBskChgOq6ngi3OD s40LfSaodnJ8wwyZbMN8/GmJuofOY3IUqxTigZrbeYCCIFoej6FNpn2o7n42+IH15DNb objXsBLVshWbeedTnMs5+WrjbZaP8YRWe5u4KrkysVS+6WyF0OPBdY9kGLfupruhwQxj Le7ajzZkI2SUZIQ805uw48NGhrjSLET+e+lSKPWYRMAM6q5eHJ+z85Ojnpo+KxiAyOQP lhSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fTN1oTl4BnZ4lY/ByqHj7eWnDMOArfz5roXGzVzbC9E=; b=IrSNnxFJk1mJnSn3PnnRkC9RlA8B9c/v2RZUcSVrI5BhJ8LyiE3Wotz6fYVw26zSwL Uk2LtlVTsu79RMbD5xbuxTebJmNqBK9x/33WjuXBBLVoNFGKRJoFuPVkqmfs0oqMQYs6 8nTPBKCPJDT9v4aYcUHwqLhEporAUM9/05sWWJ7l3ucrh1ItwtcgRuFkP1CWO7aHbdun B6A3bhcILlcLKgs4sSIywOl6JGbk07hrOk2+YwY4CcFdbeb1KCOV2k6eGj93eiXNdrsd ZS4N1FoEnPtHddGTVAHhAwWuZ0yAbiEflFR+EVq3aP50a4e4mDCq6Et4nSVw7SWos9VO +bOg==
X-Gm-Message-State: AA+aEWbxXtzZBDWUnaV2SeeSzxPxpEPNSBirpLszy08x9SgkEQ4iyabD udaNVCNsHL0YGIUA8ex6KXRtFXWMBak=
X-Google-Smtp-Source: AFSGD/UVfk4xXJlNVpnCecZTDsPW0Ba3FEM46KU03/cVJGoD2AwsrfFLjY+beB02EaJiOR7w71OOgg==
X-Received: by 2002:a17:902:aa0a:: with SMTP id be10mr11487544plb.266.1542899742846;  Thu, 22 Nov 2018 07:15:42 -0800 (PST)
Received: from [172.20.10.2] (mobile-166-137-176-240.mycingular.net. [166.137.176.240]) by smtp.gmail.com with ESMTPSA id g190sm51024294pgc.28.2018.11.22.07.15.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Nov 2018 07:15:42 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: joel jaeggli 
In-Reply-To: <794f077a-898a-b351-411b-6c1879c69ffd@cisco.com>
Date: Thu, 22 Nov 2018 07:15:39 -0800
Cc: Christian Hopps , draft-ietf-netmod-module-tags.authors@ietf.org, NETMOD Working Group 
Content-Transfer-Encoding: quoted-printable
Message-Id: <76EC5162-3365-4029-977A-B69D0E9C67A0@gmail.com>
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>   <96b1510e-2d12-32ba-4609-009b4e86d790@cisco.com>  <794f077a-898a-b351-411b-6c1879c69ffd@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: 
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2018 15:15:46 -0000

>=20
>=20
>>  I do not think the tail end of a WGLC is an appropriate time or =
place to start wondering out loud about whether it would be a good to =
have. I admit to being confused by this since I believe you were =
actively participating WRT this work when it had the yang library =
augmentation as well as after we removed it.
>=20
> My apologies, but I had intended to review this more thoroughly during =
the WG LC but ran out of time.  If was when I read Alex's comments that =
I thought that he was raising some valid points. The key one that struck =
a chord is that this document describes a solution but doesn't seem to =
clearly describe what problem it is solving (other than tags are good), =
or how it is intending to be used.  When I reviewed this document after =
reading Alex's comments, I was asking myself how this was going to be =
used, and the answer I came up with was that I didn't really know.  Or =
the case that I had in mind (YANG catalog filtering on module tag) =
doesn't seem to match the authors envisaged use cases.  Looking back at =
some of the previous comments on this work (not just Alex), others have =
also questioned what problem it is solving and how it will be used.
>=20

So the backup slides I had for the talk basically asked if more =
proscriptive text was required on their use. Which is a bit different =
then working how they are to be used.=20

The three cases of module tags, IETF, Vendor and User come from =
different sources. The IETF source comes with a demand for IETF =
consensus. The others do not.=20

Ultimately I can imagine all sorts of user classification schemes that =
might emerge so my general conclusion that that any description should =
come in the form of guidance rather than proscription.



From nobody Thu Nov 22 07:25:48 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D666412D84D; Thu, 22 Nov 2018 07:25:46 -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 5jnYhiMkiYxO; Thu, 22 Nov 2018 07:25:44 -0800 (PST)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 B90EC129A87; Thu, 22 Nov 2018 07:25:44 -0800 (PST)
Received: by mail-pg1-x529.google.com with SMTP id v28so1864691pgk.10; Thu, 22 Nov 2018 07:25:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XNyRX0ee9qN9B1jBJ533F4qWvWtJOyUCqb943xEOFds=; b=JlJXgrsK5L0xdiH3SF74rLQNmXUHgmmMQDNciYr4PCb3B8JJZGy/w0Ggo3W1h3Iqlf Lv5fV5t59JKbbL3io1mK8hnN21VJq1+1+WpkBzZuv3kh8fDe28/zE0XfU13YBpChLkLm dQdT2hS3I5HkmjzIuLswCRyCX0Jm3ybMnv4glhfNnW92J4NVUkTBoVptbCZoxyZv6oUy LpX5vVXbF7aAdsoxL3OuEbINqWQWdsepbpI57XQ4fWXRpuHRtAeNIMIJf6Y31TMJFN4d 6dNfDYPa76ZH6RLbM3LiQHt8aGWcJDXjj0qo6F+2dzl7wQ2JMf+4qhAATx5StHspZo3f 6f+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=XNyRX0ee9qN9B1jBJ533F4qWvWtJOyUCqb943xEOFds=; b=R+4frAUAOm3Vv3ekGHOyOfmAfuJPccETirMUXt3Cb30X1IWHs7xaN8hAtBmnVgtyUw xHvt0de0fr44YtyAOOVaUQm2Z+j2v9OKBhUbur57IZFdsZqYnmz2CgYbp/YKIhgvpGsi ABFrazlGATEUuxLuabheLLxvcs7MYD0UnKsO27BpwJIeRMAdnErTfIueNtIRfQyvizHk ZuYeWOgI5f6LOA3PwJi0K3vnUNJepEPX101fjoPlajk2XJwUdtU1Z2H7sri6wa76887R LHKn1X8jLMT/5aSm1dwRtppY3cqLpuEImnzv6EUGPHRVwgBIiV+mmD139lCwHWyGr5gz jksg==
X-Gm-Message-State: AGRZ1gIuEjyZub6Sv4qsxgv12qxYiWB11vV3swaFg8NEUnM5EJtfKCYy JlcuCPs3O/v8byCD8kuL6Sx1TROBdGE=
X-Google-Smtp-Source: AJdET5dmh9nk72Qtn7n1BEZ/Mo95WijAAX/nrldU+bFe6q5+jins2Sv3zk+g16XF4ivpK9QxHaSZkA==
X-Received: by 2002:a62:c42:: with SMTP id u63-v6mr12058004pfi.43.1542900343919;  Thu, 22 Nov 2018 07:25:43 -0800 (PST)
Received: from [172.20.10.2] (mobile-166-137-176-240.mycingular.net. [166.137.176.240]) by smtp.gmail.com with ESMTPSA id h124sm24847554pfg.143.2018.11.22.07.25.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Nov 2018 07:25:43 -0800 (PST)
From: joel jaeggli 
Message-Id: <59148A79-7C50-479C-8F53-0EDF3C426EC4@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2AD0A735-51A1-4E8A-B366-78836438CF9A"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Thu, 22 Nov 2018 07:25:40 -0800
In-Reply-To: 
Cc: Christian Hopps , draft-ietf-netmod-module-tags.authors@ietf.org, NETMOD Working Group 
To: Robert Wilton 
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>   <96b1510e-2d12-32ba-4609-009b4e86d790@cisco.com>  <794f077a-898a-b351-411b-6c1879c69ffd@cisco.com> <4EFB8243-F05B-404B-A638-CAD439D491FD@chopps.org> 
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: 
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2018 15:25:47 -0000

--Apple-Mail=_2AD0A735-51A1-4E8A-B366-78836438CF9A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


Something like the text below addresses the question of guidance. I =
think we get a better draft if we close off this discussion on the list.

I think the question about where the tags reside generally is settled.

Thanks
joel

> On Nov 14, 2018, at 09:26, Robert Wilton  wrote:
>=20
>=20
>>=20
>> The answer is:
>>=20
>> 1) B/c there's literally no where else they could be stored (no way =
for a vendor to add tags)
>> 2) There are other examples of servers storing things they don't use =
like comments, so "server not using what it stores" isn't a reason to =
not store them on the server in the first place.
>>=20
>> Regarding the rest. Maybe we should write a requirements draft and a =
use cases draft for the use of meta-data/tags for organizing things.
> That is not what I was suggesting.
>=20
> I was suggesting text something like this:
>=20
> Introduction:
>=20
> OLD:
>=20
>   The use of tags for classification and organization is fairly
>    ubiquitous not only within IETF protocols, but in the internet =
itself
>    (e.g., #hashtags).  Tags can be usefully standardized, but they can
>    also serve as a non-standardized mechanism available for users to
>    define themselves.  Our solution provides for both cases allowing =
for
>    the most flexibility.  In particular, tags may be standardized as
>    well as assigned during module definition; assigned by
>    implementations; or dynamically defined and set by users.
>=20
> NEW:
>=20
>   The use of tags for classification and organization is fairly
>    ubiquitous not only within IETF protocols, but in the internet =
itself
>    (e.g., #hashtags).  One benefit of using tags for organization
>    over a rigid structure is that it is more flexible and can more =
easily
>    adapt over time as technologies evolve.  Tags can be usefully
>    standardized, but they can also serve as a non-standardized =
mechanism
>    available for users to define themselves. This document provides a
>    mechanism to define tags and associate them with YANG modules in a
>    flexible manner.  In particular, tags may be standardized as
>    well as assigned during module definition; assigned by
>    implementations; or dynamically defined and set by users.
>=20
>=20
> NEW:
>   =20
> 1.1 Some example use cases of YANG module tags
>=20
>   Tags can be used to help filter different discrete categories of =
YANG
>   modules supported by a device.  E.g., if modules are suitably =
tagged,
>   then an XPath query can be used to list all of the vendor modules
>   supported by a device.
>=20
>   Tags can also be used to help coordination when multiple
>   semi-independent clients are interacting with the same devices.  =
E.g.,
>   one management client could mark that some modules should not be =
used
>   because they have not been verified to behave correctly, so that =
other
>   management clients avoid querying the data associated with those
>   modules.
>=20
>   Tag classification is useful for users searching module repositories
>   (e.g. YANG catalog).  A query restricted to the 'ietf:routing' =
module
>   tag could be used to return only the IETF YANG modules associated =
with
>   routing.  Without tags, a user would need to know the name of all
>   the IETF routing protocol YANG modules.
>=20
>   Future management protocol extensions could allow for filtering
>   queries of configuration or operational state on a server based on
>   tags.  E.g., return all operational state related to =
system-management.
>=20
>=20
> If you think that this text is helpful, and it allowed, then please =
add it, refining as required.  If you think that it detracts from the =
clarify of document, and is superfluous then leave it out, that is also =
fine with me ...=20
>=20
> Thanks,
> Rob
>=20
>=20




--Apple-Mail=_2AD0A735-51A1-4E8A-B366-78836438CF9A
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii


Something like the text below addresses the question of guidance. I think we get a better draft if we close off this discussion on the list.

I think the question about where the tags reside generally is settled.

Thanks
joel

On Nov 14, 2018, at 09:26, Robert Wilton <rwilton@cisco.com> wrote:


    

    

      
The answer is:

1) B/c there's literally no where else they could be stored (no way for a vendor to add tags)
2) There are other examples of servers storing things they don't use like comments, so "server not using what it stores" isn't a reason to not store them on the server in the first place.

Regarding the rest. Maybe we should write a requirements draft and a use cases draft for the use of meta-data/tags for organizing things.

    
That is not what I was suggesting.
I was suggesting text something like this:
Introduction:
OLD:
  The use of tags for classification and organization is fairly
   ubiquitous not only within IETF protocols, but in the internet itself
   (e.g., #hashtags).  Tags can be usefully standardized, but they can
   also serve as a non-standardized mechanism available for users to
   define themselves.  Our solution provides for both cases allowing for
   the most flexibility.  In particular, tags may be standardized as
   well as assigned during module definition; assigned by
   implementations; or dynamically defined and set by users.
NEW:

    
  The use of tags for classification and organization is fairly
   ubiquitous not only within IETF protocols, but in the internet itself
   (e.g., #hashtags).  One benefit of using tags for organization
   over a rigid structure is that it is more flexible and can more easily
   adapt over time as technologies evolve.  Tags can be usefully
   standardized, but they can also serve as a non-standardized mechanism
   available for users to define themselves. This document provides a
   mechanism to define tags and associate them with YANG modules in a
   flexible manner.  In particular, tags may be standardized as
   well as assigned during module definition; assigned by
   implementations; or dynamically defined and set by users.

NEW:
   
1.1 Some example use cases of YANG module tags
  Tags can be used to help filter different discrete categories of YANG
  modules supported by a device.  E.g., if modules are suitably tagged,
  then an XPath query can be used to list all of the vendor modules
  supported by a device.

  Tags can also be used to help coordination when multiple
  semi-independent clients are interacting with the same devices.  E.g.,
  one management client could mark that some modules should not be used
  because they have not been verified to behave correctly, so that other
  management clients avoid querying the data associated with those
  modules.

  Tag classification is useful for users searching module repositories
  (e.g. YANG catalog).  A query restricted to the 'ietf:routing' module
  tag could be used to return only the IETF YANG modules associated with
  routing.  Without tags, a user would need to know the name of all
  the IETF routing protocol YANG modules.

  Future management protocol extensions could allow for filtering
  queries of configuration or operational state on a server based on
  tags.  E.g., return all operational state related to system-management.


      If you think that this text is helpful, and it allowed, then
      please add it, refining as required.  If you think that it
      detracts from the clarify of document, and is superfluous then
      leave it out, that is also fine with me ... 

    
Thanks,

      Rob





--Apple-Mail=_2AD0A735-51A1-4E8A-B366-78836438CF9A--


From nobody Thu Nov 22 07:28: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 DACCD129533 for ; Thu, 22 Nov 2018 07:28:05 -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 232mKguQBTa0 for ; Thu, 22 Nov 2018 07:28:04 -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 AEAA31292AD for ; Thu, 22 Nov 2018 07:28:03 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 1CB9564311; Thu, 22 Nov 2018 16:28:02 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1542900482; bh=JflCC8+YdCqMxEV01U6vEcnqDGD+OSVU9QiGnEzqhCk=; h=From:To:Date; b=Kjmz0V4vTSDwawXtcJB4KppgPUStgqNRHJyPWeMbxrcEpWo+Q2Qxac0MUF1Wf3Hev JapY9jYRMao5egaxVwXiqOIP+Wp4fkqeZ5sSifxPYHIGudeu6EIK6F0o2EA0i9f7ta X/7TlFcY2kgyT47wOljfR/dlglp0A6NNcNZOQnWw=
Message-ID: 
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: andy@yumaworks.com, jason.sterne@nokia.com, netmod@ietf.org
Date: Thu, 22 Nov 2018 16:28:01 +0100
In-Reply-To: <20181122.161438.975515366125603770.mbj@tail-f.com>
References:  <20181122.150027.823800945772964674.mbj@tail-f.com>  <20181122.161438.975515366125603770.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2018 15:28:06 -0000

On Thu, 2018-11-22 at 16:14 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote:
> > > Andy Bierman  wrote:
> > > > On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund  wrote:
> > > > 
> > > > > Hi,
> > > > >
> > > > > Ladislav Lhotka  wrote:
> > > > > > Andy Bierman  writes:
> > > > > >
> > > > > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia - CA/Ottawa)
> <
> > > > > > > jason.sterne@nokia.com> wrote:
> > > > > > >
> > > > > > >> Hi all,
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> If we have a YANG model with a leaf:
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> MODEL VERSION 1:
> > > > > > >>
> > > > > > >> container my-model {
> > > > > > >>
> > > > > > >>     leaf a { type string; }
> > > > > > >>
> > > > > > >> }
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> And then later we produce another version of the model where that
> > > > > leaf is
> > > > > > >> placed into a choice construct:
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> MODEL VERSION 2:
> > > > > > >>
> > > > > > >> container my-model {
> > > > > > >>
> > > > > > >>     choice some-choice {
> > > > > > >>
> > > > > > >>         case x {
> > > > > > >>
> > > > > > >>             leaf a { type string; }
> > > > > > >>
> > > > > > >>         }
> > > > > > >>
> > > > > > >>     }
> > > > > > >>
> > > > > > >> }
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> Is that considered a non-backwards-compatible change?
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > > yes -- even though the data node /my-model/x did not change,
> > > > > > > the schema node /my-model/a changed to /my-model/some-choice/x/a.
> > > > > > > Any leafref path pointing at this leaf will break.
> > > > > >
> > > > > > This is not correct. A leafref path is a special XPath, and as such
> > > > > > includes only data nodes, i.e. NOT choice and case nodes.
> > > > > >
> > > > > > What does change are schema node identifier. This could be
> significant
> > > > > > in an augment statement, but not ini this example because a leaf
> cannot
> > > > > > be augmented anyway.
> > > > > >
> > > > > > I don't see anything else that could break, so Jason's change seems
> > > > > > backward compatible to me.
> > > > >
> > > > > Since it does change the schema tree, this is not legal according to
> > > > > 7950.  So in that sense it is not backwards compatible.  The rules in
> > > > > 7950 protect both clients and other modules that import the module.
> > > > >
> > > > >
> > > > This text is confusing wrt/ schema tree vs data tree:
> > > > 
> > > > 
> > > > 9.9 ;;.  The leafref
> > > > Built-In Type
> > > > 
> > > >    The leafref built-in type is restricted to the value space of some
> > > >    leaf or leaf-list node in the schema tree and optionally further
> > > >    restricted by corresponding instance nodes in the data tree.  The
> > > >    "path" substatement (Section 9.9.2
> > > > ;;) is used to
> > > > identify the referred
> > > >    leaf or leaf-list node in the schema tree.  The value space of the
> > > >    referring node is the value space of the referred node.
> > > 
> > > Yes, it should be "data tree" in both occurrences.
> > 
> > I tend to disagree. The values of a leafref are first restricted according
> to
> > the *schema*, i.e. even before any leaf instance exists in the data tree
> that
> > the leafref can point to. Consider this example:
> > 
> > list map {
> >   key name;
> >   leaf name {
> >     type string;
> >   }
> >   leaf value {
> >     type uint8;
> >   }
> > }
> > leaf link {
> >   type leafref {
> >     path "../map[name='quux']/value";
> >     default "foo";
> >   }
> > }
> > 
> > We had a long discussion about this, maybe I could find it, and the
> conclusion
> > was that a YANG parser should flag the default "foo" value as incorrect even
> > before any instance data are in sight.
> 
> Yes, this is correct.  The quoted text needs to be rewritten to make
> this more clear.  Altough the path refers to a (potential) node in the
> data tree, that node obviously has a node in the schema tree, and its
> value space restricts the value space of the leafref node.
> 
> > I wasn't exactly happy with this conclusion because it assumes that we can
> use
> > the XPath from the argument of "path" to locate the *schema node* and check
> its
> > type. Although it looks appealing (everybody sees what the type of "value"
> is,
> > right?), I think this is just another unfortunate example of mixing up the
> > schema and data instances.
> > 
> > Let me ask: can we expect a newcomer to understand what's going on if even
> > seasoned YANG doctors get confused?
> 
> Yes.
> 
> I've been told that people don't read documentation or specifications
> and just look at examples.

The problem with examples is that they have to stay at a trivial level where
everything looks obvious and nobody has to care about subtle details such as the
difference between XPath and schema node identifiers. Those who had to implement
the above logic for a general case will confirm that it is pretty tricky.

Lada

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


From nobody Thu Nov 22 07:31: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 26067129533 for ; Thu, 22 Nov 2018 07:31:48 -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, 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 rgtUjkn8M0Uc for ; Thu, 22 Nov 2018 07:31:45 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70124.outbound.protection.outlook.com [40.107.7.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FFE11292AD for ; Thu, 22 Nov 2018 07:31:44 -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=Njjs5LBLPJVB5MPyIyGyD+sOHNbVKKSrUBPMjUcdc9I=; b=SoRd+Y5P3ObLVRvc5O4uuBLLs2hSLAdFIs+yICFhAABjqx4fhP9MswEntI4j1y4Hj4JQ6r5VrNdDwXJV+JOBNommRP8hX9OwpQJ5QNbnDmLQ0byPofn31LGE12fDP9k1U30EvhqYKhomK3lmv5F8zoQ4Fh3LvgxmBrO9/0pZRSc=
Received: from DB7PR07MB3978.eurprd07.prod.outlook.com (52.134.100.23) by DB7PR07MB5321.eurprd07.prod.outlook.com (20.178.44.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.7; Thu, 22 Nov 2018 15:31:42 +0000
Received: from DB7PR07MB3978.eurprd07.prod.outlook.com ([fe80::d501:332:48c7:4d6c]) by DB7PR07MB3978.eurprd07.prod.outlook.com ([fe80::d501:332:48c7:4d6c%3]) with mapi id 15.20.1382.007; Thu, 22 Nov 2018 15:31:42 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" 
To: Ladislav Lhotka , Martin Bjorklund 
CC: "andy@yumaworks.com" , "netmod@ietf.org" 
Thread-Topic: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
Thread-Index: AdSARc1DsD04ldMzQTGmSlWVLz4VPQABCoCAAIeMyAAAACrqAAAAdPmAAABDp4AAAlncAAAAPWQAAAB3qIAAABKU4A==
Date: Thu, 22 Nov 2018 15:31:42 +0000
Message-ID: 
References:  <20181122.150027.823800945772964674.mbj@tail-f.com>  <20181122.161438.975515366125603770.mbj@tail-f.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com; 
x-originating-ip: [45.72.219.254]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB7PR07MB5321; 6:6Q7AaYQccmhmvssDKIKF+NnWDj3cYky5KFJeOSlTAJegr/VV/l1P+VxMhjMJbjt0BADxFT6oMVOut6FhTGS6IhGRSwlLYV1vMyctzx7Nmk4BEQX2rzDI829K9ygxi1P5EhQsY8DSEjyV1+G/sap70NX8Txo1HjThxl8xQYSR/9r3mRIWCYnw+0N+NqIF6fd4jWuAyn1tPiLGx5CU9JPAaF4Au5u+/IlQ/vcaYzk2KTY2bXn8b4HWtaWTjBjFhF/xwophZnP9vj8B9HNrjuDktIpYPmhDZwHQBVABOn7xO0hK8s+Q7dsSmBiezBE8Ki88WE3u1IEolGmXkBXsyjhZXO88cuBDIktc6bjIKxB/5rBwpzwdmV/rgBzbh+Tsy5hYgwQBm6bElNsY7e5ZTLvMPhTPEwJw3MUyhLBJy0chZjQXdkDnj/5Cv0mTJJg8FyOsXd5+YphfohREkGYMDtT3WQ==; 5:4eA9l9DyE6bSkhIdBGb28skQ8r6R8tiXaT1KYu9RLJfupsgu7/eo+xa0sndAhDDqOZYk8jFIVHRaYjpDfXNoftDI1gOyedRKgfu04gGT3MFSVTUzpgxXR5T3ViO4y/lYnS5aJ2c/YqWsA8gMI57JbC7VuSfkxBi5y0c0MOsf+RM=; 7:bVFCB2tHkthvwUviQFoj1/RY/Gv1/HCf0Pri3wDaa+z3HxqqJFmo/D/pMrg5XpwyDq8haZBOh4ogIWj/FgZrl+7dY4FOFSzcQxKRptHqzQsIzr0cuGedRjUHO+oAnA3NYDV83dUguQMATWgQ6rSbqQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: a173ce3a-3473-4f35-1668-08d6508f9a75
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)(7193020); SRVR:DB7PR07MB5321; 
x-ms-traffictypediagnostic: DB7PR07MB5321:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231442)(11241501184)(806099)(944501410)(52105112)(3002001)(10201501046)(6055026)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB5321; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB5321; 
x-forefront-prvs: 0864A36BBF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(136003)(366004)(39860400002)(53754006)(13464003)(189003)(199004)(102836004)(4001150100001)(114624004)(93886005)(6246003)(4326008)(105586002)(14444005)(256004)(316002)(14454004)(106356001)(26005)(186003)(6506007)(53546011)(53936002)(86362001)(6436002)(8936002)(229853002)(2900100001)(33656002)(446003)(7736002)(74316002)(54906003)(486006)(66066001)(9686003)(2906002)(6306002)(8676002)(81166006)(81156014)(55016002)(476003)(68736007)(25786009)(11346002)(110136005)(7696005)(71200400001)(71190400001)(76176011)(478600001)(5660300001)(305945005)(3846002)(6116002)(97736004)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB7PR07MB5321; H:DB7PR07MB3978.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: e2oh1OYG/FWZ7uVXhK5WDIU9LeyXFY/lCuj8IGco5PHx8AqbJUr1c+0/phpETtWQF545IvTSxWM9z49cu66FxbhYS8qNbld7vjof53wj8z3B+TnpLcYOB5o0PWfg+hM75Ts1gh+2PRypJgHBnA67zcQzGJmdRmrEIMllT7glK9eR2wphfbdgsbpfuKBLcfjD0uQcpPw3Zd+LRCPInd1RHdXsHf7nKh/stSJWzgTpryDYwbTB8vwXqq+cAdQCjCURr9La0FR5gIYu0poS8aJ3QwQ4DhX7SuzWDpAZ4Z5boh1KSFGruvKdFaHoqDTlV0za2jQR/5evx62t1LEP8+k8HyvBy06m+UisYcEj0acqWto=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a173ce3a-3473-4f35-1668-08d6508f9a75
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2018 15:31:42.0703 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5321
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2018 15:31:48 -0000

RnJvbSB3aGF0IEkgY2FuIHVuZGVyc3RhbmQgYmVsb3csIG5vbmUgb2YgdGhpcyBkZWJhdGUgYWZm
ZWN0cyB0aGUgY29uY2x1c2lvbiB0aGF0IGNob2ljZSAmIGNhc2UgaWRlbnRpZmllcnMgZG8gKm5v
dCogYXBwZWFyIGluOg0KLSBsZWFmcmVmIHBhdGhzDQotIG11c3Qgc3RhdGVtZW50cw0KLSB3aGVu
IHN0YXRlbWVudHMNCnJpZ2h0Pw0KDQoodGhleSAqZG8qIGFwcGVhciBpbiBhdWdtZW50IHBhdGhz
IHRob3VnaCBzaW5jZSB0aGF0IGRlZmluaXRlbHkgbmVlZHMgdG8gcmVmZXIgdG8gc2NoZW1hKQ0K
DQpKYXNvbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExhZGlzbGF2
IExob3RrYSA8bGhvdGthQG5pYy5jej4NCj4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDIyLCAy
MDE4IDEwOjI4IEFNDQo+IFRvOiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4NCj4g
Q2M6IGFuZHlAeXVtYXdvcmtzLmNvbTsgU3Rlcm5lLCBKYXNvbiAoTm9raWEgLSBDQS9PdHRhd2Ep
DQo+IDxqYXNvbi5zdGVybmVAbm9raWEuY29tPjsgbmV0bW9kQGlldGYub3JnDQo+IFN1YmplY3Q6
IFJlOiBbbmV0bW9kXSBBZGRpbmcgYSBwcmUtZXhpc3RpbmcgbGVhZiBpbnRvIGEgbmV3ICdjaG9p
Y2UnIC0gTkJDDQo+IGNoYW5nZT8NCj4gDQo+IE9uIFRodSwgMjAxOC0xMS0yMiBhdCAxNjoxNCAr
MDEwMCwgTWFydGluIEJqb3JrbHVuZCB3cm90ZToNCj4gPiBMYWRpc2xhdiBMaG90a2EgPGxob3Rr
YUBuaWMuY3o+IHdyb3RlOg0KPiA+ID4gT24gVGh1LCAyMDE4LTExLTIyIGF0IDE1OjAwICswMTAw
LCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPiA+ID4gPiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVt
YXdvcmtzLmNvbT4gd3JvdGU6DQo+ID4gPiA+ID4gT24gVGh1LCBOb3YgMjIsIDIwMTggYXQgNToz
OSBBTSBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4NCj4gd3JvdGU6DQo+ID4gPiA+
ID4NCj4gPiA+ID4gPiA+IEhpLA0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IExhZGlzbGF2IExo
b3RrYSA8bGhvdGthQG5pYy5jej4gd3JvdGU6DQo+ID4gPiA+ID4gPiA+IEFuZHkgQmllcm1hbiA8
YW5keUB5dW1hd29ya3MuY29tPiB3cml0ZXM6DQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+
ID4gT24gTW9uLCBOb3YgMTksIDIwMTggYXQgMTI6MzIgUE0gU3Rlcm5lLCBKYXNvbiAoTm9raWEg
LQ0KPiBDQS9PdHRhd2EpDQo+ID4gPA0KPiA+ID4gPiA+ID4gPiA+IGphc29uLnN0ZXJuZUBub2tp
YS5jb20+IHdyb3RlOg0KPiA+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+ID4+IEhpIGFsbCwN
Cj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPj4NCj4g
PiA+ID4gPiA+ID4gPj4gSWYgd2UgaGF2ZSBhIFlBTkcgbW9kZWwgd2l0aCBhIGxlYWY6DQo+ID4g
PiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+
ID4gPiA+ID4+IE1PREVMIFZFUlNJT04gMToNCj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+
ID4gPj4gY29udGFpbmVyIG15LW1vZGVsIHsNCj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+
ID4gPj4gICAgIGxlYWYgYSB7IHR5cGUgc3RyaW5nOyB9DQo+ID4gPiA+ID4gPiA+ID4+DQo+ID4g
PiA+ID4gPiA+ID4+IH0NCj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPj4NCj4gPiA+
ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+ID4gPj4gQW5kIHRoZW4gbGF0ZXIgd2UgcHJvZHVjZSBh
bm90aGVyIHZlcnNpb24gb2YgdGhlIG1vZGVsIHdoZXJlDQo+IHRoYXQNCj4gPiA+ID4gPiA+IGxl
YWYgaXMNCj4gPiA+ID4gPiA+ID4gPj4gcGxhY2VkIGludG8gYSBjaG9pY2UgY29uc3RydWN0Og0K
PiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+Pg0KPiA+
ID4gPiA+ID4gPiA+PiBNT0RFTCBWRVJTSU9OIDI6DQo+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+
ID4gPiA+ID4+IGNvbnRhaW5lciBteS1tb2RlbCB7DQo+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+
ID4gPiA+ID4+ICAgICBjaG9pY2Ugc29tZS1jaG9pY2Ugew0KPiA+ID4gPiA+ID4gPiA+Pg0KPiA+
ID4gPiA+ID4gPiA+PiAgICAgICAgIGNhc2UgeCB7DQo+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+
ID4gPiA+ID4+ICAgICAgICAgICAgIGxlYWYgYSB7IHR5cGUgc3RyaW5nOyB9DQo+ID4gPiA+ID4g
PiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4+ICAgICAgICAgfQ0KPiA+ID4gPiA+ID4gPiA+Pg0KPiA+
ID4gPiA+ID4gPiA+PiAgICAgfQ0KPiA+ID4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gPiA+PiB9
DQo+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4+DQo+
ID4gPiA+ID4gPiA+ID4+IElzIHRoYXQgY29uc2lkZXJlZCBhIG5vbi1iYWNrd2FyZHMtY29tcGF0
aWJsZSBjaGFuZ2U/DQo+ID4gPiA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiA+ID4NCj4gPiA+ID4g
PiA+ID4gPg0KPiA+ID4gPiA+ID4gPiA+IHllcyAtLSBldmVuIHRob3VnaCB0aGUgZGF0YSBub2Rl
IC9teS1tb2RlbC94IGRpZCBub3QgY2hhbmdlLA0KPiA+ID4gPiA+ID4gPiA+IHRoZSBzY2hlbWEg
bm9kZSAvbXktbW9kZWwvYSBjaGFuZ2VkIHRvIC9teS1tb2RlbC9zb21lLQ0KPiBjaG9pY2UveC9h
Lg0KPiA+ID4gPiA+ID4gPiA+IEFueSBsZWFmcmVmIHBhdGggcG9pbnRpbmcgYXQgdGhpcyBsZWFm
IHdpbGwgYnJlYWsuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IFRoaXMgaXMgbm90IGNv
cnJlY3QuIEEgbGVhZnJlZiBwYXRoIGlzIGEgc3BlY2lhbCBYUGF0aCwgYW5kIGFzIHN1Y2gNCj4g
PiA+ID4gPiA+ID4gaW5jbHVkZXMgb25seSBkYXRhIG5vZGVzLCBpLmUuIE5PVCBjaG9pY2UgYW5k
IGNhc2Ugbm9kZXMuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IFdoYXQgZG9lcyBjaGFu
Z2UgYXJlIHNjaGVtYSBub2RlIGlkZW50aWZpZXIuIFRoaXMgY291bGQgYmUNCj4gPiBzaWduaWZp
Y2FudA0KPiA+ID4gPiA+ID4gPiBpbiBhbiBhdWdtZW50IHN0YXRlbWVudCwgYnV0IG5vdCBpbmkg
dGhpcyBleGFtcGxlIGJlY2F1c2UgYSBsZWFmDQo+ID4gY2Fubm90DQo+ID4gPiA+ID4gPiA+IGJl
IGF1Z21lbnRlZCBhbnl3YXkuDQo+ID4gPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiA+IEkgZG9uJ3Qg
c2VlIGFueXRoaW5nIGVsc2UgdGhhdCBjb3VsZCBicmVhaywgc28gSmFzb24ncyBjaGFuZ2Ugc2Vl
bXMNCj4gPiA+ID4gPiA+ID4gYmFja3dhcmQgY29tcGF0aWJsZSB0byBtZS4NCj4gPiA+ID4gPiA+
DQo+ID4gPiA+ID4gPiBTaW5jZSBpdCBkb2VzIGNoYW5nZSB0aGUgc2NoZW1hIHRyZWUsIHRoaXMg
aXMgbm90IGxlZ2FsIGFjY29yZGluZyB0bw0KPiA+ID4gPiA+ID4gNzk1MC4gIFNvIGluIHRoYXQg
c2Vuc2UgaXQgaXMgbm90IGJhY2t3YXJkcyBjb21wYXRpYmxlLiAgVGhlIHJ1bGVzIGluDQo+ID4g
PiA+ID4gPiA3OTUwIHByb3RlY3QgYm90aCBjbGllbnRzIGFuZCBvdGhlciBtb2R1bGVzIHRoYXQg
aW1wb3J0IHRoZQ0KPiBtb2R1bGUuDQo+ID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4g
PiBUaGlzIHRleHQgaXMgY29uZnVzaW5nIHdydC8gc2NoZW1hIHRyZWUgdnMgZGF0YSB0cmVlOg0K
PiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiA5LjkgPGh0dHBzOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9yZmM3OTUwI3NlY3Rpb24tOS45Pjs7LiAgVGhlIGxlYWZyZWYNCj4gPiA+ID4gPiBC
dWlsdC1JbiBUeXBlDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAgICBUaGUgbGVhZnJlZiBidWlsdC1p
biB0eXBlIGlzIHJlc3RyaWN0ZWQgdG8gdGhlIHZhbHVlIHNwYWNlIG9mIHNvbWUNCj4gPiA+ID4g
PiAgICBsZWFmIG9yIGxlYWYtbGlzdCBub2RlIGluIHRoZSBzY2hlbWEgdHJlZSBhbmQgb3B0aW9u
YWxseSBmdXJ0aGVyDQo+ID4gPiA+ID4gICAgcmVzdHJpY3RlZCBieSBjb3JyZXNwb25kaW5nIGlu
c3RhbmNlIG5vZGVzIGluIHRoZSBkYXRhIHRyZWUuICBUaGUNCj4gPiA+ID4gPiAgICAicGF0aCIg
c3Vic3RhdGVtZW50IChTZWN0aW9uIDkuOS4yDQo+ID4gPiA+ID4gPGh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9yZmM3OTUwI3NlY3Rpb24tOS45LjI+OzspIGlzIHVzZWQgdG8NCj4gPiA+ID4g
PiBpZGVudGlmeSB0aGUgcmVmZXJyZWQNCj4gPiA+ID4gPiAgICBsZWFmIG9yIGxlYWYtbGlzdCBu
b2RlIGluIHRoZSBzY2hlbWEgdHJlZS4gIFRoZSB2YWx1ZSBzcGFjZSBvZiB0aGUNCj4gPiA+ID4g
PiAgICByZWZlcnJpbmcgbm9kZSBpcyB0aGUgdmFsdWUgc3BhY2Ugb2YgdGhlIHJlZmVycmVkIG5v
ZGUuDQo+ID4gPiA+DQo+ID4gPiA+IFllcywgaXQgc2hvdWxkIGJlICJkYXRhIHRyZWUiIGluIGJv
dGggb2NjdXJyZW5jZXMuDQo+ID4gPg0KPiA+ID4gSSB0ZW5kIHRvIGRpc2FncmVlLiBUaGUgdmFs
dWVzIG9mIGEgbGVhZnJlZiBhcmUgZmlyc3QgcmVzdHJpY3RlZCBhY2NvcmRpbmcNCj4gPiB0bw0K
PiA+ID4gdGhlICpzY2hlbWEqLCBpLmUuIGV2ZW4gYmVmb3JlIGFueSBsZWFmIGluc3RhbmNlIGV4
aXN0cyBpbiB0aGUgZGF0YSB0cmVlDQo+ID4gdGhhdA0KPiA+ID4gdGhlIGxlYWZyZWYgY2FuIHBv
aW50IHRvLiBDb25zaWRlciB0aGlzIGV4YW1wbGU6DQo+ID4gPg0KPiA+ID4gbGlzdCBtYXAgew0K
PiA+ID4gICBrZXkgbmFtZTsNCj4gPiA+ICAgbGVhZiBuYW1lIHsNCj4gPiA+ICAgICB0eXBlIHN0
cmluZzsNCj4gPiA+ICAgfQ0KPiA+ID4gICBsZWFmIHZhbHVlIHsNCj4gPiA+ICAgICB0eXBlIHVp
bnQ4Ow0KPiA+ID4gICB9DQo+ID4gPiB9DQo+ID4gPiBsZWFmIGxpbmsgew0KPiA+ID4gICB0eXBl
IGxlYWZyZWYgew0KPiA+ID4gICAgIHBhdGggIi4uL21hcFtuYW1lPSdxdXV4J10vdmFsdWUiOw0K
PiA+ID4gICAgIGRlZmF1bHQgImZvbyI7DQo+ID4gPiAgIH0NCj4gPiA+IH0NCj4gPiA+DQo+ID4g
PiBXZSBoYWQgYSBsb25nIGRpc2N1c3Npb24gYWJvdXQgdGhpcywgbWF5YmUgSSBjb3VsZCBmaW5k
IGl0LCBhbmQgdGhlDQo+ID4gY29uY2x1c2lvbg0KPiA+ID4gd2FzIHRoYXQgYSBZQU5HIHBhcnNl
ciBzaG91bGQgZmxhZyB0aGUgZGVmYXVsdCAiZm9vIiB2YWx1ZSBhcyBpbmNvcnJlY3QNCj4gZXZl
bg0KPiA+ID4gYmVmb3JlIGFueSBpbnN0YW5jZSBkYXRhIGFyZSBpbiBzaWdodC4NCj4gPg0KPiA+
IFllcywgdGhpcyBpcyBjb3JyZWN0LiAgVGhlIHF1b3RlZCB0ZXh0IG5lZWRzIHRvIGJlIHJld3Jp
dHRlbiB0byBtYWtlDQo+ID4gdGhpcyBtb3JlIGNsZWFyLiAgQWx0b3VnaCB0aGUgcGF0aCByZWZl
cnMgdG8gYSAocG90ZW50aWFsKSBub2RlIGluIHRoZQ0KPiA+IGRhdGEgdHJlZSwgdGhhdCBub2Rl
IG9idmlvdXNseSBoYXMgYSBub2RlIGluIHRoZSBzY2hlbWEgdHJlZSwgYW5kIGl0cw0KPiA+IHZh
bHVlIHNwYWNlIHJlc3RyaWN0cyB0aGUgdmFsdWUgc3BhY2Ugb2YgdGhlIGxlYWZyZWYgbm9kZS4N
Cj4gPg0KPiA+ID4gSSB3YXNuJ3QgZXhhY3RseSBoYXBweSB3aXRoIHRoaXMgY29uY2x1c2lvbiBi
ZWNhdXNlIGl0IGFzc3VtZXMgdGhhdCB3ZQ0KPiBjYW4NCj4gPiB1c2UNCj4gPiA+IHRoZSBYUGF0
aCBmcm9tIHRoZSBhcmd1bWVudCBvZiAicGF0aCIgdG8gbG9jYXRlIHRoZSAqc2NoZW1hIG5vZGUq
IGFuZA0KPiBjaGVjaw0KPiA+IGl0cw0KPiA+ID4gdHlwZS4gQWx0aG91Z2ggaXQgbG9va3MgYXBw
ZWFsaW5nIChldmVyeWJvZHkgc2VlcyB3aGF0IHRoZSB0eXBlIG9mDQo+ICJ2YWx1ZSINCj4gPiBp
cywNCj4gPiA+IHJpZ2h0PyksIEkgdGhpbmsgdGhpcyBpcyBqdXN0IGFub3RoZXIgdW5mb3J0dW5h
dGUgZXhhbXBsZSBvZiBtaXhpbmcgdXAgdGhlDQo+ID4gPiBzY2hlbWEgYW5kIGRhdGEgaW5zdGFu
Y2VzLg0KPiA+ID4NCj4gPiA+IExldCBtZSBhc2s6IGNhbiB3ZSBleHBlY3QgYSBuZXdjb21lciB0
byB1bmRlcnN0YW5kIHdoYXQncyBnb2luZyBvbiBpZg0KPiBldmVuDQo+ID4gPiBzZWFzb25lZCBZ
QU5HIGRvY3RvcnMgZ2V0IGNvbmZ1c2VkPw0KPiA+DQo+ID4gWWVzLg0KPiA+DQo+ID4gSSd2ZSBi
ZWVuIHRvbGQgdGhhdCBwZW9wbGUgZG9uJ3QgcmVhZCBkb2N1bWVudGF0aW9uIG9yIHNwZWNpZmlj
YXRpb25zDQo+ID4gYW5kIGp1c3QgbG9vayBhdCBleGFtcGxlcy4NCj4gDQo+IFRoZSBwcm9ibGVt
IHdpdGggZXhhbXBsZXMgaXMgdGhhdCB0aGV5IGhhdmUgdG8gc3RheSBhdCBhIHRyaXZpYWwgbGV2
ZWwgd2hlcmUNCj4gZXZlcnl0aGluZyBsb29rcyBvYnZpb3VzIGFuZCBub2JvZHkgaGFzIHRvIGNh
cmUgYWJvdXQgc3VidGxlIGRldGFpbHMgc3VjaCBhcw0KPiB0aGUNCj4gZGlmZmVyZW5jZSBiZXR3
ZWVuIFhQYXRoIGFuZCBzY2hlbWEgbm9kZSBpZGVudGlmaWVycy4gVGhvc2Ugd2hvIGhhZCB0bw0K
PiBpbXBsZW1lbnQNCj4gdGhlIGFib3ZlIGxvZ2ljIGZvciBhIGdlbmVyYWwgY2FzZSB3aWxsIGNv
bmZpcm0gdGhhdCBpdCBpcyBwcmV0dHkgdHJpY2t5Lg0KPiANCj4gTGFkYQ0KPiANCj4gPg0KPiA+
DQo+ID4NCj4gPiAvbWFydGluDQo+IC0tDQo+IExhZGlzbGF2IExob3RrYQ0KPiBIZWFkLCBDWi5O
SUMgTGFicw0KPiBQR1AgS2V5IElEOiAweEI4RjkyQjA4QTlGNzZDNjcNCg0K


From nobody Thu Nov 22 07:37:27 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C05A129A87 for ; Thu, 22 Nov 2018 07:37:25 -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 8KOjSC7zvGzs for ; Thu, 22 Nov 2018 07:37:23 -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 E3B441292AD for ; Thu, 22 Nov 2018 07:37:22 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 6544964209; Thu, 22 Nov 2018 16:37:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1542901041; bh=b31s33q5N7lW5nKKtWAPJCucv9VAWZYgD60UdYeQVuQ=; h=From:To:Date; b=mFJM6jH+F3SKdYfMcg2ObUAPqDzJ+uDnrIi9phcLRk8m0VC7dgouCQIJ7HPI0YvgI JIlOdTSLX78JQ1+nSNb3AjMuQ6UmzruUpW4IpD7M0JzCe3k8XBMwarbo18daQz0kKa Aw2bk0uTeLrFBJw0cqNIjzgdAdQFhpbhtv8pSYVY=
Message-ID: 
From: Ladislav Lhotka 
To: "Sterne, Jason (Nokia - CA/Ottawa)" , Martin Bjorklund 
Cc: "andy@yumaworks.com" , "netmod@ietf.org" 
Date: Thu, 22 Nov 2018 16:37:21 +0100
In-Reply-To: 
References:  <20181122.150027.823800945772964674.mbj@tail-f.com>  <20181122.161438.975515366125603770.mbj@tail-f.com>  
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2018 15:37:25 -0000

On Thu, 2018-11-22 at 15:31 +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote:
> From what I can understand below, none of this debate affects the conclusion
> that choice & case identifiers do *not* appear in:
> - leafref paths
> - must statements
> - when statements
> right?

Yup.

Lada

> 
> (they *do* appear in augment paths though since that definitely needs to refer
> to schema)
> 
> Jason
> 
> > -----Original Message-----
> > From: Ladislav Lhotka 
> > Sent: Thursday, November 22, 2018 10:28 AM
> > To: Martin Bjorklund 
> > Cc: andy@yumaworks.com; Sterne, Jason (Nokia - CA/Ottawa)
> > ; netmod@ietf.org
> > Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC
> > change?
> > 
> > On Thu, 2018-11-22 at 16:14 +0100, Martin Bjorklund wrote:
> > > Ladislav Lhotka  wrote:
> > > > On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote:
> > > > > Andy Bierman  wrote:
> > > > > > On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund 
> > wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > Ladislav Lhotka  wrote:
> > > > > > > > Andy Bierman  writes:
> > > > > > > > 
> > > > > > > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia -
> > CA/Ottawa)
> > > <
> > > > > > > > > jason.sterne@nokia.com> wrote:
> > > > > > > > > 
> > > > > > > > > > Hi all,
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > If we have a YANG model with a leaf:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > MODEL VERSION 1:
> > > > > > > > > > 
> > > > > > > > > > container my-model {
> > > > > > > > > > 
> > > > > > > > > >     leaf a { type string; }
> > > > > > > > > > 
> > > > > > > > > > }
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > And then later we produce another version of the model where
> > that
> > > > > > > leaf is
> > > > > > > > > > placed into a choice construct:
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > MODEL VERSION 2:
> > > > > > > > > > 
> > > > > > > > > > container my-model {
> > > > > > > > > > 
> > > > > > > > > >     choice some-choice {
> > > > > > > > > > 
> > > > > > > > > >         case x {
> > > > > > > > > > 
> > > > > > > > > >             leaf a { type string; }
> > > > > > > > > > 
> > > > > > > > > >         }
> > > > > > > > > > 
> > > > > > > > > >     }
> > > > > > > > > > 
> > > > > > > > > > }
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > Is that considered a non-backwards-compatible change?
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > yes -- even though the data node /my-model/x did not change,
> > > > > > > > > the schema node /my-model/a changed to /my-model/some-
> > choice/x/a.
> > > > > > > > > Any leafref path pointing at this leaf will break.
> > > > > > > > 
> > > > > > > > This is not correct. A leafref path is a special XPath, and as
> > > > > > > > such
> > > > > > > > includes only data nodes, i.e. NOT choice and case nodes.
> > > > > > > > 
> > > > > > > > What does change are schema node identifier. This could be
> > > significant
> > > > > > > > in an augment statement, but not ini this example because a leaf
> > > cannot
> > > > > > > > be augmented anyway.
> > > > > > > > 
> > > > > > > > I don't see anything else that could break, so Jason's change
> > > > > > > > seems
> > > > > > > > backward compatible to me.
> > > > > > > 
> > > > > > > Since it does change the schema tree, this is not legal according
> > > > > > > to
> > > > > > > 7950.  So in that sense it is not backwards compatible.  The rules
> > > > > > > in
> > > > > > > 7950 protect both clients and other modules that import the
> > module.
> > > > > > > 
> > > > > > This text is confusing wrt/ schema tree vs data tree:
> > > > > > 
> > > > > > 
> > > > > > 9.9 ;;;.  The
> > > > > > leafref
> > > > > > Built-In Type
> > > > > > 
> > > > > >    The leafref built-in type is restricted to the value space of
> > > > > > some
> > > > > >    leaf or leaf-list node in the schema tree and optionally further
> > > > > >    restricted by corresponding instance nodes in the data tree.  The
> > > > > >    "path" substatement (Section 9.9.2
> > > > > > ;;;) is used to
> > > > > > identify the referred
> > > > > >    leaf or leaf-list node in the schema tree.  The value space of
> > > > > > the
> > > > > >    referring node is the value space of the referred node.
> > > > > 
> > > > > Yes, it should be "data tree" in both occurrences.
> > > > 
> > > > I tend to disagree. The values of a leafref are first restricted
> > > > according
> > > to
> > > > the *schema*, i.e. even before any leaf instance exists in the data tree
> > > that
> > > > the leafref can point to. Consider this example:
> > > > 
> > > > list map {
> > > >   key name;
> > > >   leaf name {
> > > >     type string;
> > > >   }
> > > >   leaf value {
> > > >     type uint8;
> > > >   }
> > > > }
> > > > leaf link {
> > > >   type leafref {
> > > >     path "../map[name='quux']/value";
> > > >     default "foo";
> > > >   }
> > > > }
> > > > 
> > > > We had a long discussion about this, maybe I could find it, and the
> > > conclusion
> > > > was that a YANG parser should flag the default "foo" value as incorrect
> > even
> > > > before any instance data are in sight.
> > > 
> > > Yes, this is correct.  The quoted text needs to be rewritten to make
> > > this more clear.  Altough the path refers to a (potential) node in the
> > > data tree, that node obviously has a node in the schema tree, and its
> > > value space restricts the value space of the leafref node.
> > > 
> > > > I wasn't exactly happy with this conclusion because it assumes that we
> > can
> > > use
> > > > the XPath from the argument of "path" to locate the *schema node* and
> > check
> > > its
> > > > type. Although it looks appealing (everybody sees what the type of
> > "value"
> > > is,
> > > > right?), I think this is just another unfortunate example of mixing up
> > > > the
> > > > schema and data instances.
> > > > 
> > > > Let me ask: can we expect a newcomer to understand what's going on if
> > even
> > > > seasoned YANG doctors get confused?
> > > 
> > > Yes.
> > > 
> > > I've been told that people don't read documentation or specifications
> > > and just look at examples.
> > 
> > The problem with examples is that they have to stay at a trivial level where
> > everything looks obvious and nobody has to care about subtle details such as
> > the
> > difference between XPath and schema node identifiers. Those who had to
> > implement
> > the above logic for a general case will confirm that it is pretty tricky.
> > 
> > Lada
> > 
> > > 
> > > 
> > > /martin
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Thu Nov 22 08:04: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 667ED126C7E for ; Thu, 22 Nov 2018 08:04:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outbound.mailhop.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS6Z1yRCI2ri for ; Thu, 22 Nov 2018 08:04:05 -0800 (PST)
Received: from outbound1f.eu.mailhop.org (outbound1f.eu.mailhop.org [52.28.59.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43CE124BF6 for ; Thu, 22 Nov 2018 08:04:04 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1542902640; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=sSspBI+s5zptOlQuxVxfgRQQachhKxFYe8voGsdM+f82FnHyetLugS4v5zI7/YJs9hQ2jpGqoA0kZ xANv3vGro1Fl5BRvCNl8HkmaAZYxByvBsxiKBJSGNj5m1t5Lch6cdD59xXW3mQHjvFGiJ1WViAkdWP veHqHFYUKavfASZscm1Bol5XHAl76/z1kF26ZPDREVKdtke4Ct+6jld1GbLKzoNrzyv7vviGX4B4bn /nF5JR+5qUe8aQGklddTQojHu4YpxPLzp39RltLt+z3g0Z086CKVBHtLqxlQgOMSAeLzsYBa0Y3yZK PNAbeqqecEGJM6sH+dNk26eWvb17/vw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:dkim-signature:from; bh=YFXyuvEDcevLqwCa7Ni3nrjwpm6noEgBGsV3988eHHM=; b=Tt9sKp7SMaXLwhpYyxCt4nXG19hQCQCK/KlILZoultubjiEcNZYxBR6IpbTKRmTVE6/xJ4VfyJdUU ftVCfV8+4YG7wPtJ0Id+sLJ+w0NmLb6qcsHe2KhAFwBZaBBFLwZE61sTFWintDDQz/sW/4awYEr//N 2rLKxVhfzECBMUge8i9amPsVoUh8sTUG9W//xpHGrHTYKDl1UjyxWQ8wAwbQNhszYb5u6H8RIpttey REs2IjxTF7ODj3c3TzBNVN3cscDHx+E/SQ64IxJQR5qiraYh2zVBMaRbTacJiw1R1g74dBCBfK+ot1 WmOgxiFY0zGJ9NNgtmRESxLbbgvqyVw==
ARC-Authentication-Results: i=1; outbound2.eu.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.152.101; dmarc=none header.from=hedeland.org; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:from; bh=YFXyuvEDcevLqwCa7Ni3nrjwpm6noEgBGsV3988eHHM=; b=A7k9SRyu/y7+AxxFzlzfgKPb0b12xqNTWiCi/155U5c6UZX8ej39wANoih4ZrM0UOpdQM85/azuVD gOlD0i9W9KiVA3yZ2p2ACR7sa7mbZbCXmR3BzW1bcJvxP0SX1tHxBTblc8cG2UDlC8nxmQ5I3/iYW7 1OZD9PpApzDesuFkk1y5H5YjydiisHjrBryWIktrlfWrdbAeNJ4lDOwiwErpTCp/I+MJ7iznqLVc0P P2gmXLwOtkEiWzSfLMKqM8YeXwq9zDAqJnFe4xk/SESk8IjpSwAzG3+fQJ/ZOpGgiXw1iq5/bEWI+n WfxbwPYzR+crv/ayb5+aiC13DMoFswA==
X-MHO-RoutePath: cGVyaGVkZWxhbmQ=
X-MHO-User: 36985a54-ee70-11e8-a886-bd2f23b465e5
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 81.228.152.101
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from hedeland.org (unknown [81.228.152.101]) by outbound2.eu.mailhop.org (Halon) with ESMTPSA id 36985a54-ee70-11e8-a886-bd2f23b465e5; Thu, 22 Nov 2018 16:03:57 +0000 (UTC)
Received: from mars.tail-f.com ([173.38.220.34]) (authenticated bits=0) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPSA id wAMG3qKg054990 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 22 Nov 2018 17:03:54 +0100 (CET) (envelope-from per@hedeland.org)
X-Authentication-Warning: tellus.hedeland.org: Host [173.38.220.34] claimed to be mars.tail-f.com
To: Ladislav Lhotka , "Sterne, Jason (Nokia - CA/Ottawa)" 
Cc: Martin Bjorklund , "netmod@ietf.org" 
References:  <20181122.150027.823800945772964674.mbj@tail-f.com>  <20181122.161438.975515366125603770.mbj@tail-f.com>   
From: Per Hedeland 
Message-ID: <439a474f-55d4-c6a5-9043-e87d2b241d63@hedeland.org>
Date: Thu, 22 Nov 2018 17:03:47 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2018 16:04:08 -0000

On 2018-11-22 16:37, Ladislav Lhotka wrote:
> On Thu, 2018-11-22 at 15:31 +0000, Sterne, Jason (Nokia - CA/Ottawa) wrote:
>> From what I can understand below, none of this debate affects the conclusion
>> that choice & case identifiers do *not* appear in:
>> - leafref paths
>> - must statements
>> - when statements
>> right?
> 
> Yup.
> 
> Lada
> 
>>
>> (they *do* appear in augment paths though since that definitely needs to refer
>> to schema)

They also appear in 'deviation' and 'refine' paths, which unlike augment
paths can identify a leaf or leaf-list (although 'refine' is of course
only relevant for nodes in a (top-level) grouping).

--Per

>> Jason
>>
>>> -----Original Message-----
>>> From: Ladislav Lhotka 
>>> Sent: Thursday, November 22, 2018 10:28 AM
>>> To: Martin Bjorklund 
>>> Cc: andy@yumaworks.com; Sterne, Jason (Nokia - CA/Ottawa)
>>> ; netmod@ietf.org
>>> Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC
>>> change?
>>>
>>> On Thu, 2018-11-22 at 16:14 +0100, Martin Bjorklund wrote:
>>>> Ladislav Lhotka  wrote:
>>>>> On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote:
>>>>>> Andy Bierman  wrote:
>>>>>>> On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund 
>>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Ladislav Lhotka  wrote:
>>>>>>>>> Andy Bierman  writes:
>>>>>>>>>
>>>>>>>>>> On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia -
>>> CA/Ottawa)
>>>> <
>>>>>>>>>> jason.sterne@nokia.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If we have a YANG model with a leaf:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> MODEL VERSION 1:
>>>>>>>>>>>
>>>>>>>>>>> container my-model {
>>>>>>>>>>>
>>>>>>>>>>>     leaf a { type string; }
>>>>>>>>>>>
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> And then later we produce another version of the model where
>>> that
>>>>>>>> leaf is
>>>>>>>>>>> placed into a choice construct:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> MODEL VERSION 2:
>>>>>>>>>>>
>>>>>>>>>>> container my-model {
>>>>>>>>>>>
>>>>>>>>>>>     choice some-choice {
>>>>>>>>>>>
>>>>>>>>>>>         case x {
>>>>>>>>>>>
>>>>>>>>>>>             leaf a { type string; }
>>>>>>>>>>>
>>>>>>>>>>>         }
>>>>>>>>>>>
>>>>>>>>>>>     }
>>>>>>>>>>>
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Is that considered a non-backwards-compatible change?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> yes -- even though the data node /my-model/x did not change,
>>>>>>>>>> the schema node /my-model/a changed to /my-model/some-
>>> choice/x/a.
>>>>>>>>>> Any leafref path pointing at this leaf will break.
>>>>>>>>>
>>>>>>>>> This is not correct. A leafref path is a special XPath, and as
>>>>>>>>> such
>>>>>>>>> includes only data nodes, i.e. NOT choice and case nodes.
>>>>>>>>>
>>>>>>>>> What does change are schema node identifier. This could be
>>>> significant
>>>>>>>>> in an augment statement, but not ini this example because a leaf
>>>> cannot
>>>>>>>>> be augmented anyway.
>>>>>>>>>
>>>>>>>>> I don't see anything else that could break, so Jason's change
>>>>>>>>> seems
>>>>>>>>> backward compatible to me.
>>>>>>>>
>>>>>>>> Since it does change the schema tree, this is not legal according
>>>>>>>> to
>>>>>>>> 7950.  So in that sense it is not backwards compatible.  The rules
>>>>>>>> in
>>>>>>>> 7950 protect both clients and other modules that import the
>>> module.
>>>>>>>>
>>>>>>> This text is confusing wrt/ schema tree vs data tree:
>>>>>>>
>>>>>>>
>>>>>>> 9.9 ;;;.  The
>>>>>>> leafref
>>>>>>> Built-In Type
>>>>>>>
>>>>>>>    The leafref built-in type is restricted to the value space of
>>>>>>> some
>>>>>>>    leaf or leaf-list node in the schema tree and optionally further
>>>>>>>    restricted by corresponding instance nodes in the data tree.  The
>>>>>>>    "path" substatement (Section 9.9.2
>>>>>>> ;;;) is used to
>>>>>>> identify the referred
>>>>>>>    leaf or leaf-list node in the schema tree.  The value space of
>>>>>>> the
>>>>>>>    referring node is the value space of the referred node.
>>>>>>
>>>>>> Yes, it should be "data tree" in both occurrences.
>>>>>
>>>>> I tend to disagree. The values of a leafref are first restricted
>>>>> according
>>>> to
>>>>> the *schema*, i.e. even before any leaf instance exists in the data tree
>>>> that
>>>>> the leafref can point to. Consider this example:
>>>>>
>>>>> list map {
>>>>>   key name;
>>>>>   leaf name {
>>>>>     type string;
>>>>>   }
>>>>>   leaf value {
>>>>>     type uint8;
>>>>>   }
>>>>> }
>>>>> leaf link {
>>>>>   type leafref {
>>>>>     path "../map[name='quux']/value";
>>>>>     default "foo";
>>>>>   }
>>>>> }
>>>>>
>>>>> We had a long discussion about this, maybe I could find it, and the
>>>> conclusion
>>>>> was that a YANG parser should flag the default "foo" value as incorrect
>>> even
>>>>> before any instance data are in sight.
>>>>
>>>> Yes, this is correct.  The quoted text needs to be rewritten to make
>>>> this more clear.  Altough the path refers to a (potential) node in the
>>>> data tree, that node obviously has a node in the schema tree, and its
>>>> value space restricts the value space of the leafref node.
>>>>
>>>>> I wasn't exactly happy with this conclusion because it assumes that we
>>> can
>>>> use
>>>>> the XPath from the argument of "path" to locate the *schema node* and
>>> check
>>>> its
>>>>> type. Although it looks appealing (everybody sees what the type of
>>> "value"
>>>> is,
>>>>> right?), I think this is just another unfortunate example of mixing up
>>>>> the
>>>>> schema and data instances.
>>>>>
>>>>> Let me ask: can we expect a newcomer to understand what's going on if
>>> even
>>>>> seasoned YANG doctors get confused?
>>>>
>>>> Yes.
>>>>
>>>> I've been told that people don't read documentation or specifications
>>>> and just look at examples.
>>>
>>> The problem with examples is that they have to stay at a trivial level where
>>> everything looks obvious and nobody has to care about subtle details such as
>>> the
>>> difference between XPath and schema node identifiers. Those who had to
>>> implement
>>> the above logic for a general case will confirm that it is pretty tricky.
>>>
>>> Lada
>>>
>>>>
>>>>
>>>> /martin
>>> --
>>> Ladislav Lhotka
>>> Head, CZ.NIC Labs
>>> PGP Key ID: 0xB8F92B08A9F76C67


From nobody Thu Nov 22 08:10: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 46648126C7E for ; Thu, 22 Nov 2018 08:10:55 -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 2GoBJ6RxI0Lc for ; Thu, 22 Nov 2018 08:10:52 -0800 (PST)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224F8124BF6 for ; Thu, 22 Nov 2018 08:10:52 -0800 (PST)
Received: by mail-lj1-x236.google.com with SMTP id s5-v6so8393617ljd.12 for ; Thu, 22 Nov 2018 08:10:52 -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=gp5BNDL9Xr2XXMxWjnv8ZouKZQPh/iogRnOMDtQ7tRc=; b=vt50M5GrtdPMO83yEfXI3+nlAz+Lta60USmBkd+PXLujDox/B//ZnJr5rxVB3ygQC4 ngRCvp4KhvkqRI6APvHHZ/gp0V6AckcUF27Yeu5xkhetir/CQL1ggCwKeS/fh0ts+SWj gYcHZJncog7Fp88I/XyIGw8xUFgX7A6L24mzGN7tY1Ur2YnU+Teuk4n6KeH66voeEiwO F2QxlPKhtgMMw+9fU8gl+Twj0D4a/PkPhzwYImnHfSHfbvfh9Op+5aYxRBF1YEZMft5y yW+mkO7nL9dzME5AuCkK5meSInWsz4wpJizAnAd5BitWed30k8mCFR9EjK8zfwAOzM4Y EQyA==
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=gp5BNDL9Xr2XXMxWjnv8ZouKZQPh/iogRnOMDtQ7tRc=; b=pvx5B41pRmbN4+Mb1R1HY6TnLw8MYuQ2TbBtGCi5HI3tdCeijo95K15Go7QaqU+lEV gtqzD9sAAlme3SApHmXwKIe/hE12STCQ1yzP7mYLZr8E1zZSuk8qtmp01dJNcsUhS6UE NOVqptG3MvYGEqD2xFLhHIB1B48R1NdjWm7oCG8BqM/xiT4iB8kljpO7kYqq3VDfLSGd zeXbawGzoylTvswx15ZEdglFnTD+9MNnRQDZxRWRQIwzkYZTKraLP6RtDCzXhxIE9eB9 s3Zc+d22BMkk2Ptiz/80GgtTykxqfBT2Lh6sQ7NHdXHFRpNzfNli0j5efKbU9YHw1U+e 46Cw==
X-Gm-Message-State: AA+aEWYPxoDuUOv5p5hy0rXAzgjMbAItmh8LjX5TYH1qFT7eyfdisJlb whIj4C9x/fJNgM0oC/8RMYi12NkJMjuAKosRiXsWgg==
X-Google-Smtp-Source: AFSGD/W89hTuEtMSGMaTnmE0N8QFuAnpgm+FS/PscH3axGWX8vE9dpCtx+Zj3ZVB0vOTZtFhdnz8mpbYse6XtGl3vtc=
X-Received: by 2002:a2e:e02:: with SMTP id 2-v6mr6423330ljo.10.1542903050022;  Thu, 22 Nov 2018 08:10:50 -0800 (PST)
MIME-Version: 1.0
References:  <20181122.150027.823800945772964674.mbj@tail-f.com>  <20181122.161438.975515366125603770.mbj@tail-f.com> 
In-Reply-To: 
From: Andy Bierman 
Date: Thu, 22 Nov 2018 08:10:38 -0800
Message-ID: 
To: Ladislav Lhotka 
Cc: Martin Bjorklund , "Sterne, Jason (Nokia - CA)" , NetMod WG 
Content-Type: multipart/alternative; boundary="00000000000038473b057b431cdf"
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2018 16:10:55 -0000

--00000000000038473b057b431cdf
Content-Type: text/plain; charset="UTF-8"

On Thu, Nov 22, 2018 at 7:28 AM Ladislav Lhotka  wrote:

> On Thu, 2018-11-22 at 16:14 +0100, Martin Bjorklund wrote:
> > Ladislav Lhotka  wrote:
> > > On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote:
> > > > Andy Bierman  wrote:
> > > > > On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund 
> wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Ladislav Lhotka  wrote:
> > > > > > > Andy Bierman  writes:
> > > > > > >
> > > > > > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne, Jason (Nokia -
> CA/Ottawa)
> > <
> > > > > > > > jason.sterne@nokia.com> wrote:
> > > > > > > >
> > > > > > > >> Hi all,
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> If we have a YANG model with a leaf:
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> MODEL VERSION 1:
> > > > > > > >>
> > > > > > > >> container my-model {
> > > > > > > >>
> > > > > > > >>     leaf a { type string; }
> > > > > > > >>
> > > > > > > >> }
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> And then later we produce another version of the model
> where that
> > > > > > leaf is
> > > > > > > >> placed into a choice construct:
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> MODEL VERSION 2:
> > > > > > > >>
> > > > > > > >> container my-model {
> > > > > > > >>
> > > > > > > >>     choice some-choice {
> > > > > > > >>
> > > > > > > >>         case x {
> > > > > > > >>
> > > > > > > >>             leaf a { type string; }
> > > > > > > >>
> > > > > > > >>         }
> > > > > > > >>
> > > > > > > >>     }
> > > > > > > >>
> > > > > > > >> }
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> Is that considered a non-backwards-compatible change?
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > > yes -- even though the data node /my-model/x did not change,
> > > > > > > > the schema node /my-model/a changed to
> /my-model/some-choice/x/a.
> > > > > > > > Any leafref path pointing at this leaf will break.
> > > > > > >
> > > > > > > This is not correct. A leafref path is a special XPath, and as
> such
> > > > > > > includes only data nodes, i.e. NOT choice and case nodes.
> > > > > > >
> > > > > > > What does change are schema node identifier. This could be
> > significant
> > > > > > > in an augment statement, but not ini this example because a
> leaf
> > cannot
> > > > > > > be augmented anyway.
> > > > > > >
> > > > > > > I don't see anything else that could break, so Jason's change
> seems
> > > > > > > backward compatible to me.
> > > > > >
> > > > > > Since it does change the schema tree, this is not legal
> according to
> > > > > > 7950.  So in that sense it is not backwards compatible.  The
> rules in
> > > > > > 7950 protect both clients and other modules that import the
> module.
> > > > > >
> > > > > >
> > > > > This text is confusing wrt/ schema tree vs data tree:
> > > > >
> > > > >
> > > > > 9.9 ;;.  The
> leafref
> > > > > Built-In Type
> > > > >
> > > > >    The leafref built-in type is restricted to the value space of
> some
> > > > >    leaf or leaf-list node in the schema tree and optionally further
> > > > >    restricted by corresponding instance nodes in the data tree.
> The
> > > > >    "path" substatement (Section 9.9.2
> > > > > ;;) is used to
> > > > > identify the referred
> > > > >    leaf or leaf-list node in the schema tree.  The value space of
> the
> > > > >    referring node is the value space of the referred node.
> > > >
> > > > Yes, it should be "data tree" in both occurrences.
> > >
> > > I tend to disagree. The values of a leafref are first restricted
> according
> > to
> > > the *schema*, i.e. even before any leaf instance exists in the data
> tree
> > that
> > > the leafref can point to. Consider this example:
> > >
> > > list map {
> > >   key name;
> > >   leaf name {
> > >     type string;
> > >   }
> > >   leaf value {
> > >     type uint8;
> > >   }
> > > }
> > > leaf link {
> > >   type leafref {
> > >     path "../map[name='quux']/value";
> > >     default "foo";
> > >   }
> > > }
> > >
> > > We had a long discussion about this, maybe I could find it, and the
> > conclusion
> > > was that a YANG parser should flag the default "foo" value as
> incorrect even
> > > before any instance data are in sight.
> >
> > Yes, this is correct.  The quoted text needs to be rewritten to make
> > this more clear.  Altough the path refers to a (potential) node in the
> > data tree, that node obviously has a node in the schema tree, and its
> > value space restricts the value space of the leafref node.
> >
> > > I wasn't exactly happy with this conclusion because it assumes that we
> can
> > use
> > > the XPath from the argument of "path" to locate the *schema node* and
> check
> > its
> > > type. Although it looks appealing (everybody sees what the type of
> "value"
> > is,
> > > right?), I think this is just another unfortunate example of mixing up
> the
> > > schema and data instances.
> > >
> > > Let me ask: can we expect a newcomer to understand what's going on if
> even
> > > seasoned YANG doctors get confused?
> >
> > Yes.
> >
> > I've been told that people don't read documentation or specifications
> > and just look at examples.
>
> The problem with examples is that they have to stay at a trivial level
> where
> everything looks obvious and nobody has to care about subtle details such
> as the
> difference between XPath and schema node identifiers. Those who had to
> implement
> the above logic for a general case will confirm that it is pretty tricky.
>
>
I seemed to have known path-stmt was the data tree when I wrote my code ;-)
Our compiler (and pyang) complains if the choice and case nodes are given.

Because of the rule that choice and case names cannot clash with the first
real children
the schema tree expression will always identify the same node as the data
tree
(so including choice and case names is more verbose but otherwise correct)


Lada
>

Andy


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

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




On Thu=
, Nov 22, 2018 at 7:28 AM Ladislav Lhotka <lhotka@nic.cz> wrote:
On=
 Thu, 2018-11-22 at 16:14 +0100, Martin Bjorklund wrote:

> Ladislav Lhotka <lhotka@nic.cz> wrote:

> > On Thu, 2018-11-22 at 15:00 +0100, Martin Bjorklund wrote:

> > > Andy Bierman <andy@yumaworks.com> wrote:

> > > > On Thu, Nov 22, 2018 at 5:39 AM Martin Bjorklund <mbj@tail-f.com> wr=
ote:

> > > > 

> > > > > Hi,

> > > > >

> > > > > Ladislav Lhotka <lhotka@nic.cz> wrote:

> > > > > > Andy Bierman <andy@yumaworks.com> writes:

> > > > > >

> > > > > > > On Mon, Nov 19, 2018 at 12:32 PM Sterne,=
 Jason (Nokia - CA/Ottawa)

> <

> > > > > > > jason.sterne@nokia.com> wrote:

> > > > > > >

> > > > > > >> Hi all,

> > > > > > >>

> > > > > > >>

> > > > > > >>

> > > > > > >> If we have a YANG model with a leaf:=


> > > > > > >>

> > > > > > >>

> > > > > > >>

> > > > > > >> MODEL VERSION 1:

> > > > > > >>

> > > > > > >> container my-model {

> > > > > > >>

> > > > > > >>=C2=A0 =C2=A0 =C2=A0leaf a { type str=
ing; }

> > > > > > >>

> > > > > > >> }

> > > > > > >>

> > > > > > >>

> > > > > > >>

> > > > > > >> And then later we produce another ve=
rsion of the model where that

> > > > > leaf is

> > > > > > >> placed into a choice construct:

> > > > > > >>

> > > > > > >>

> > > > > > >>

> > > > > > >> MODEL VERSION 2:

> > > > > > >>

> > > > > > >> container my-model {

> > > > > > >>

> > > > > > >>=C2=A0 =C2=A0 =C2=A0choice some-choic=
e {

> > > > > > >>

> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cas=
e x {

> > > > > > >>

> > > > > > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0leaf a { type string; }

> > > > > > >>

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

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

> > > > > > >>

> > > > > > >> }

> > > > > > >>

> > > > > > >>

> > > > > > >>

> > > > > > >> Is that considered a non-backwards-c=
ompatible change?

> > > > > > >>

> > > > > > >

> > > > > > >

> > > > > > > yes -- even though the data node /my-mod=
el/x did not change,

> > > > > > > the schema node /my-model/a changed to /=
my-model/some-choice/x/a.

> > > > > > > Any leafref path pointing at this leaf w=
ill break.

> > > > > >

> > > > > > This is not correct. A leafref path is a spec=
ial XPath, and as such

> > > > > > includes only data nodes, i.e. NOT choice and=
 case nodes.

> > > > > >

> > > > > > What does change are schema node identifier. =
This could be

> significant

> > > > > > in an augment statement, but not ini this exa=
mple because a leaf

> cannot

> > > > > > be augmented anyway.

> > > > > >

> > > > > > I don't see anything else that could brea=
k, so Jason's change seems

> > > > > > backward compatible to me.

> > > > >

> > > > > Since it does change the schema tree, this is not =
legal according to

> > > > > 7950.=C2=A0 So in that sense it is not backwards c=
ompatible.=C2=A0 The rules in

> > > > > 7950 protect both clients and other modules that i=
mport the module.

> > > > >

> > > > >

> > > > This text is confusing wrt/ schema tree vs data tree:
> > > > 

> > > > 

> > > > 9.9 <https://tools.ietf.org/ht=
ml/rfc7950#section-9.9>;;.=C2=A0 The leafref

> > > > Built-In Type

> > > > 

> > > >=C2=A0 =C2=A0 The leafref built-in type is restricted to=
 the value space of some

> > > >=C2=A0 =C2=A0 leaf or leaf-list node in the schema tree =
and optionally further

> > > >=C2=A0 =C2=A0 restricted by corresponding instance nodes=
 in the data tree.=C2=A0 The

> > > >=C2=A0 =C2=A0 "path" substatement (Section 9.9=
.2

> > > > <https://tools.ietf.org/html=
/rfc7950#section-9.9.2>;;) is used to

> > > > identify the referred

> > > >=C2=A0 =C2=A0 leaf or leaf-list node in the schema tree.=
=C2=A0 The value space of the

> > > >=C2=A0 =C2=A0 referring node is the value space of the r=
eferred node.

> > > 

> > > Yes, it should be "data tree" in both occurrences.=


> > 

> > I tend to disagree. The values of a leafref are first restricted =
according

> to

> > the *schema*, i.e. even before any leaf instance exists in the da=
ta tree

> that

> > the leafref can point to. Consider this example:

> > 

> > list map {

> >=C2=A0 =C2=A0key name;

> >=C2=A0 =C2=A0leaf name {

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

> >=C2=A0 =C2=A0}

> >=C2=A0 =C2=A0leaf value {

> >=C2=A0 =C2=A0 =C2=A0type uint8;

> >=C2=A0 =C2=A0}

> > }

> > leaf link {

> >=C2=A0 =C2=A0type leafref {

> >=C2=A0 =C2=A0 =C2=A0path "../map[name=3D'quux']/value=
";

> >=C2=A0 =C2=A0 =C2=A0default "foo";

> >=C2=A0 =C2=A0}

> > }

> > 

> > We had a long discussion about this, maybe I could find it, and t=
he

> conclusion

> > was that a YANG parser should flag the default "foo" va=
lue as incorrect even

> > before any instance data are in sight.

> 

> Yes, this is correct.=C2=A0 The quoted text needs to be rewritten to m=
ake

> this more clear.=C2=A0 Altough the path refers to a (potential) node i=
n the

> data tree, that node obviously has a node in the schema tree, and its<=
br>
> value space restricts the value space of the leafref node.

> 

> > I wasn't exactly happy with this conclusion because it assume=
s that we can

> use

> > the XPath from the argument of "path" to locate the *sc=
hema node* and check

> its

> > type. Although it looks appealing (everybody sees what the type o=
f "value"

> is,

> > right?), I think this is just another unfortunate example of mixi=
ng up the

> > schema and data instances.

> > 

> > Let me ask: can we expect a newcomer to understand what's goi=
ng on if even

> > seasoned YANG doctors get confused?

> 

> Yes.

> 

> I've been told that people don't read documentation or specifi=
cations

> and just look at examples.



The problem with examples is that they have to stay at a trivial level wher=
e

everything looks obvious and nobody has to care about subtle details such a=
s the

difference between XPath and schema node identifiers. Those who had to impl=
ement

the above logic for a general case will confirm that it is pretty tricky.


I seemed to have known path-stmt was t=
he data tree when I wrote my code ;-)
Our compiler (and pyang) co=
mplains if the choice and case nodes are given.

Be=
cause of the rule that choice and case names cannot clash with the first re=
al children
the schema tree expression will always identify t=
he same node as the data tree
(so including choice and case names=
 is more verbose but otherwise correct)


=


Lada

Andy
=C2=A0



> 

> 

> 

> /martin

-- 

Ladislav Lhotka

Head, CZ.NIC Labs

PGP Key ID: 0xB8F92B08A9F76C67






--00000000000038473b057b431cdf--


From nobody Thu Nov 22 08:30: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 0A2AE130E46 for ; Thu, 22 Nov 2018 08:30: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, 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 25Le1RwExRGh for ; Thu, 22 Nov 2018 08:30: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 CE82F130DFD for ; Thu, 22 Nov 2018 08:30:49 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 84475E80; Thu, 22 Nov 2018 17:30: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 4nhXRtrqc5ko; Thu, 22 Nov 2018 17:30: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; Thu, 22 Nov 2018 17:30:48 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 470762003C; Thu, 22 Nov 2018 17:30: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 1eTPCF2vRp-o; Thu, 22 Nov 2018 17:30: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 CC11920037; Thu, 22 Nov 2018 17:30:47 +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, 22 Nov 2018 17:30:47 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 2649C30044740F; Thu, 22 Nov 2018 17:30:46 +0100 (CET)
Date: Thu, 22 Nov 2018 17:30:46 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
CC: , 
Message-ID: <20181122163046.bkzck2bmbrf3fzm7@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, netmod@ietf.org
References: <87wop5kzgb.fsf@nic.cz> <20181122.143948.1543843065251732639.mbj@tail-f.com>  <20181122.150027.823800945772964674.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20181122.150027.823800945772964674.mbj@tail-f.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Nov 2018 16:30:52 -0000

On Thu, Nov 22, 2018 at 03:00:27PM +0100, Martin Bjorklund wrote:
> Andy Bierman  wrote:
> > 
> > 9.9 .  The leafref
> > Built-In Type
> > 
> >    The leafref built-in type is restricted to the value space of some
> >    leaf or leaf-list node in the schema tree and optionally further
> >    restricted by corresponding instance nodes in the data tree.  The
> >    "path" substatement (Section 9.9.2
> > ) is used to
> > identify the referred
> >    leaf or leaf-list node in the schema tree.  The value space of the
> >    referring node is the value space of the referred node.
> 
> Yes, it should be "data tree" in both occurrences.

Time for an errata?

/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 Nov 23 01:22: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 893FE130DFA for ; Fri, 23 Nov 2018 01:22:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYQWJ6GoVcUr for ; Fri, 23 Nov 2018 01:22:24 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5B951130E30 for ; Fri, 23 Nov 2018 01:22:17 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 93CA9182113E; Fri, 23 Nov 2018 10:29:38 +0100 (CET)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 419921820056; Fri, 23 Nov 2018 10:29:35 +0100 (CET)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , Martin Bjorklund 
Cc: netmod@ietf.org
In-Reply-To: <20181122163046.bkzck2bmbrf3fzm7@anna.jacobs.jacobs-university.de>
References: <87wop5kzgb.fsf@nic.cz> <20181122.143948.1543843065251732639.mbj@tail-f.com>  <20181122.150027.823800945772964674.mbj@tail-f.com> <20181122163046.bkzck2bmbrf3fzm7@anna.jacobs.jacobs-university.de>
Mail-Followup-To: Juergen Schoenwaelder , Martin Bjorklund , netmod@ietf.org
Date: Fri, 23 Nov 2018 10:22:11 +0100
Message-ID: <87tvk85et8.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 09:22:28 -0000

Juergen Schoenwaelder  writes:

> On Thu, Nov 22, 2018 at 03:00:27PM +0100, Martin Bjorklund wrote:
>> Andy Bierman  wrote:
>> > 
>> > 9.9 .  The leafref
>> > Built-In Type
>> > 
>> >    The leafref built-in type is restricted to the value space of some
>> >    leaf or leaf-list node in the schema tree and optionally further
>> >    restricted by corresponding instance nodes in the data tree.  The
>> >    "path" substatement (Section 9.9.2
>> > ) is used to
>> > identify the referred
>> >    leaf or leaf-list node in the schema tree.  The value space of the
>> >    referring node is the value space of the referred node.
>> 
>> Yes, it should be "data tree" in both occurrences.
>
> Time for an errata?

Here is the old discussion thread:

https://www.ietf.org/mail-archive/web/netmod/current/msg15979.html

Everything relevant had been extensively discussed in it, and I am
sceptical that we can come up with anything significantly better - it
will only be more (or different) hand-waving. The problem is inherent in
the leafref design introduced in YANG 1.1. It won't go away no matter
how much we paper over it.

Lada

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

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


From nobody Fri Nov 23 01:38: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 D210B130DFC for ; Fri, 23 Nov 2018 01:38: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 yo59nI2q7Jjj for ; Fri, 23 Nov 2018 01:38: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 C03A312896A for ; Fri, 23 Nov 2018 01:38: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 3EF08E22; Fri, 23 Nov 2018 10:38:15 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id u0qOCkDSyR-E; Fri, 23 Nov 2018 10:38: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; Fri, 23 Nov 2018 10:38:15 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 294BD2003C; Fri, 23 Nov 2018 10:38:15 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id cv8f5KiCcHXp; Fri, 23 Nov 2018 10:38:14 +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 95AD520037; Fri, 23 Nov 2018 10:38:14 +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, 23 Nov 2018 10:38:14 +0100
Received: by anna.localdomain (Postfix, from userid 501) id E26CA300449A97; Fri, 23 Nov 2018 10:38:13 +0100 (CET)
Date: Fri, 23 Nov 2018 10:38:13 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund , 
Message-ID: <20181123093813.gpxrtanbxgadpwih@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References: <87wop5kzgb.fsf@nic.cz> <20181122.143948.1543843065251732639.mbj@tail-f.com>  <20181122.150027.823800945772964674.mbj@tail-f.com> <20181122163046.bkzck2bmbrf3fzm7@anna.jacobs.jacobs-university.de> <87tvk85et8.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87tvk85et8.fsf@nic.cz>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 09:38:21 -0000

On Fri, Nov 23, 2018 at 10:22:11AM +0100, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
> 
> > On Thu, Nov 22, 2018 at 03:00:27PM +0100, Martin Bjorklund wrote:
> >> Andy Bierman  wrote:
> >> > 
> >> > 9.9 .  The leafref
> >> > Built-In Type
> >> > 
> >> >    The leafref built-in type is restricted to the value space of some
> >> >    leaf or leaf-list node in the schema tree and optionally further
> >> >    restricted by corresponding instance nodes in the data tree.  The
> >> >    "path" substatement (Section 9.9.2
> >> > ) is used to
> >> > identify the referred
> >> >    leaf or leaf-list node in the schema tree.  The value space of the
> >> >    referring node is the value space of the referred node.
> >> 
> >> Yes, it should be "data tree" in both occurrences.
> >
> > Time for an errata?
> 
> Here is the old discussion thread:
> 
> https://www.ietf.org/mail-archive/web/netmod/current/msg15979.html
> 
> Everything relevant had been extensively discussed in it, and I am
> sceptical that we can come up with anything significantly better - it
> will only be more (or different) hand-waving. The problem is inherent in
> the leafref design introduced in YANG 1.1. It won't go away no matter
> how much we paper over it.
>

So you think the use of 'schema tree' in the text quoted above (is
used to identify the referred leaf or leaf-list node in the schema
tree) is correct??

I do not want to discuss whether you like the design of leafrefs or
not here - at this time we should focus on whether the text is correct
or not given the design we have. So again, you think that 'schema
tree' is correct in the statement?

/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 Nov 23 01:55:16 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42596130E0F for ; Fri, 23 Nov 2018 01:55:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuSFchPTQcYf for ; Fri, 23 Nov 2018 01:55:11 -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 87929130DFC for ; Fri, 23 Nov 2018 01:55:11 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id D3FA4642D7 for ; Fri, 23 Nov 2018 10:55:09 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1542966909; bh=sWAPdPIa51z86uJ6gI2AH8eHwCeCTSy7DZyJumAcajg=; h=From:To:Date; b=V0ddKfEjenaGXGuZulHS/Dl+eUY6E+hC51NAAyCY4pkiG1v39yci4flrLGW2HfQ0/ PczSHWK5axv9FjOxo3x+hqu1uP9+KpYvgJ7n3+Y/f05qCa28468qn5q26zp9WVLl4A Wj8S6ByYQ1SOjNsIaH/EBQgIKwzDkN9ZMDS1jUVU=
Message-ID: <70587074aed82edac5e4ab1cbf2479e14edca626.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Fri, 23 Nov 2018 10:55:09 +0100
In-Reply-To: <20181123093813.gpxrtanbxgadpwih@anna.jacobs.jacobs-university.de>
References: <87wop5kzgb.fsf@nic.cz> <20181122.143948.1543843065251732639.mbj@tail-f.com>  <20181122.150027.823800945772964674.mbj@tail-f.com> <20181122163046.bkzck2bmbrf3fzm7@anna.jacobs.jacobs-university.de> <87tvk85et8.fsf@nic.cz> <20181123093813.gpxrtanbxgadpwih@anna.jacobs.jacobs-university.de>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 09:55:14 -0000

On Fri, 2018-11-23 at 10:38 +0100, Juergen Schoenwaelder wrote:
> On Fri, Nov 23, 2018 at 10:22:11AM +0100, Ladislav Lhotka wrote:
> > Juergen Schoenwaelder  writes:
> > 
> > > On Thu, Nov 22, 2018 at 03:00:27PM +0100, Martin Bjorklund wrote:
> > > > Andy Bierman  wrote:
> > > > > 9.9 ;.  The leafref
> > > > > Built-In Type
> > > > > 
> > > > >    The leafref built-in type is restricted to the value space of some
> > > > >    leaf or leaf-list node in the schema tree and optionally further
> > > > >    restricted by corresponding instance nodes in the data tree.  The
> > > > >    "path" substatement (Section 9.9.2
> > > > > ;) is used to
> > > > > identify the referred
> > > > >    leaf or leaf-list node in the schema tree.  The value space of the
> > > > >    referring node is the value space of the referred node.
> > > > 
> > > > Yes, it should be "data tree" in both occurrences.
> > > 
> > > Time for an errata?
> > 
> > Here is the old discussion thread:
> > 
> > https://www.ietf.org/mail-archive/web/netmod/current/msg15979.html
> > 
> > Everything relevant had been extensively discussed in it, and I am
> > sceptical that we can come up with anything significantly better - it
> > will only be more (or different) hand-waving. The problem is inherent in
> > the leafref design introduced in YANG 1.1. It won't go away no matter
> > how much we paper over it.
> > 
> 
> So you think the use of 'schema tree' in the text quoted above (is
> used to identify the referred leaf or leaf-list node in the schema
> tree) is correct??

It is certainly more correct than "data tree". The assumption is that the "path"
statement (that by definition selects some instance nodes in the data tree) also
implicitly points to a leaf or leaf-list node iin the schema tree.

> 
> I do not want to discuss whether you like the design of leafrefs or
> not here - at this time we should focus on whether the text is correct
> or not given the design we have. So again, you think that 'schema
> tree' is correct in the statement?

There are two problems with it:

1. There may be no such schema node, because it can be possibly invalidated by a
"when" expression.

2. The term "value space" is not defined.

Lada

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


From nobody Fri Nov 23 02:05: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 2FD9A130E03 for ; Fri, 23 Nov 2018 02:05:52 -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 JUw-zuDLl78i for ; Fri, 23 Nov 2018 02:05: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 217E8130DFC for ; Fri, 23 Nov 2018 02:05:50 -0800 (PST)
Received: from localhost (h-39-108.A165.priv.bahnhof.se [213.136.39.108]) by mail.tail-f.com (Postfix) with ESMTPSA id C2AE71AE0187; Fri, 23 Nov 2018 11:05:48 +0100 (CET)
Date: Fri, 23 Nov 2018 11:05:48 +0100 (CET)
Message-Id: <20181123.110548.845126088727972359.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20181123093813.gpxrtanbxgadpwih@anna.jacobs.jacobs-university.de>
References: <20181122163046.bkzck2bmbrf3fzm7@anna.jacobs.jacobs-university.de> <87tvk85et8.fsf@nic.cz> <20181123093813.gpxrtanbxgadpwih@anna.jacobs.jacobs-university.de>
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] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 10:05:52 -0000

Juergen Schoenwaelder  wrote:
> On Fri, Nov 23, 2018 at 10:22:11AM +0100, Ladislav Lhotka wrote:
> > Juergen Schoenwaelder  writes:
> > 
> > > On Thu, Nov 22, 2018 at 03:00:27PM +0100, Martin Bjorklund wrote:
> > >> Andy Bierman  wrote:
> > >> > 
> > >> > 9.9 .  The leafref
> > >> > Built-In Type
> > >> > 
> > >> >    The leafref built-in type is restricted to the value space of some
> > >> >    leaf or leaf-list node in the schema tree and optionally further
> > >> >    restricted by corresponding instance nodes in the data tree.  The
> > >> >    "path" substatement (Section 9.9.2
> > >> > ) is used to
> > >> > identify the referred
> > >> >    leaf or leaf-list node in the schema tree.  The value space of the
> > >> >    referring node is the value space of the referred node.
> > >> 
> > >> Yes, it should be "data tree" in both occurrences.
> > >
> > > Time for an errata?
> > 
> > Here is the old discussion thread:
> > 
> > https://www.ietf.org/mail-archive/web/netmod/current/msg15979.html
> > 
> > Everything relevant had been extensively discussed in it, and I am
> > sceptical that we can come up with anything significantly better - it
> > will only be more (or different) hand-waving. The problem is inherent in
> > the leafref design introduced in YANG 1.1. It won't go away no matter
> > how much we paper over it.
> >
> 
> So you think the use of 'schema tree' in the text quoted above (is
> used to identify the referred leaf or leaf-list node in the schema
> tree) is correct??
> 
> I do not want to discuss whether you like the design of leafrefs or
> not here - at this time we should focus on whether the text is correct
> or not given the design we have. So again, you think that 'schema
> tree' is correct in the statement?

After reading the quoted thread and thinking some more, I think the
text in 9.9 is in fact correct.  As Lada wrote in that thread:
 
   2. It [path] also implicitly refers to a leaf node in the schema
      [...]

The problem is that this "implicit reference" isn't defined.  9.9
talks about reference to a schema node, and 9.9.2 talks about the data
tree, but there is no text that ties these together.


/martin


From nobody Fri Nov 23 02:27: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 4719E130E00 for ; Fri, 23 Nov 2018 02:27:10 -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 rFz_pxiqQtt8 for ; Fri, 23 Nov 2018 02:27:08 -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 DB3FE127332 for ; Fri, 23 Nov 2018 02:27:07 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 27BA964181; Fri, 23 Nov 2018 11:27:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1542968825; bh=NRgQf/t2J9XAJ/AD6XAM+MxKD1mKXYP5rY4HZQBCr/g=; h=From:To:Date; b=WX2654PiLcVBXGA8jNM9U8lPds17Zt+s+M/2sGnonUHVEapgpUiFCkFjZxvO11slW YxzeoTi6Vok5mfUPvVnjD461Z3e+acYzX6+80KNNuPPYZJEUe16lXbOROxvVR4fWUp tnm31ZiLdQERIkYwGfBgobjUI1oP25yS+08bvVqc=
Message-ID: 
From: Ladislav Lhotka 
To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de
Cc: netmod@ietf.org
Date: Fri, 23 Nov 2018 11:27:04 +0100
In-Reply-To: <20181123.110548.845126088727972359.mbj@tail-f.com>
References: <20181122163046.bkzck2bmbrf3fzm7@anna.jacobs.jacobs-university.de> <87tvk85et8.fsf@nic.cz> <20181123093813.gpxrtanbxgadpwih@anna.jacobs.jacobs-university.de> <20181123.110548.845126088727972359.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 10:27:10 -0000

On Fri, 2018-11-23 at 11:05 +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Fri, Nov 23, 2018 at 10:22:11AM +0100, Ladislav Lhotka wrote:
> > > Juergen Schoenwaelder  writes:
> > > 
> > > > On Thu, Nov 22, 2018 at 03:00:27PM +0100, Martin Bjorklund wrote:
> > > > > Andy Bierman  wrote:
> > > > > > 9.9 ;.  The leafref
> > > > > > Built-In Type
> > > > > > 
> > > > > >    The leafref built-in type is restricted to the value space of
> > > > > > some
> > > > > >    leaf or leaf-list node in the schema tree and optionally further
> > > > > >    restricted by corresponding instance nodes in the data tree.  The
> > > > > >    "path" substatement (Section 9.9.2
> > > > > > ;) is used to
> > > > > > identify the referred
> > > > > >    leaf or leaf-list node in the schema tree.  The value space of
> > > > > > the
> > > > > >    referring node is the value space of the referred node.
> > > > > 
> > > > > Yes, it should be "data tree" in both occurrences.
> > > > 
> > > > Time for an errata?
> > > 
> > > Here is the old discussion thread:
> > > 
> > > https://www.ietf.org/mail-archive/web/netmod/current/msg15979.html
> > > 
> > > Everything relevant had been extensively discussed in it, and I am
> > > sceptical that we can come up with anything significantly better - it
> > > will only be more (or different) hand-waving. The problem is inherent in
> > > the leafref design introduced in YANG 1.1. It won't go away no matter
> > > how much we paper over it.
> > > 
> > 
> > So you think the use of 'schema tree' in the text quoted above (is
> > used to identify the referred leaf or leaf-list node in the schema
> > tree) is correct??
> > 
> > I do not want to discuss whether you like the design of leafrefs or
> > not here - at this time we should focus on whether the text is correct
> > or not given the design we have. So again, you think that 'schema
> > tree' is correct in the statement?
> 
> After reading the quoted thread and thinking some more, I think the
> text in 9.9 is in fact correct.  As Lada wrote in that thread:
>  
>    2. It [path] also implicitly refers to a leaf node in the schema
>       [...]
> 
> The problem is that this "implicit reference" isn't defined.  9.9
> talks about reference to a schema node, and 9.9.2 talks about the data
> tree, but there is no text that ties these together.

Agreed. Lada

> 
> 
> /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 Nov 23 03:33: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 BCAC5130E27 for ; Fri, 23 Nov 2018 03:33:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WO6O_pXp_IM4 for ; Fri, 23 Nov 2018 03:33:45 -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 562C6130E1E for ; Fri, 23 Nov 2018 03:33:45 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id DF82540; Fri, 23 Nov 2018 12:33:43 +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 tRDJi0ndzwpW; Fri, 23 Nov 2018 12:33:43 +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, 23 Nov 2018 12:33:43 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA25620037; Fri, 23 Nov 2018 12:33:43 +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 n-F08TEFCqy5; Fri, 23 Nov 2018 12:33:43 +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 030CC2003C; Fri, 23 Nov 2018 12:33:42 +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, 23 Nov 2018 12:33:42 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 382F8300449FAC; Fri, 23 Nov 2018 12:33:41 +0100 (CET)
Date: Fri, 23 Nov 2018 12:33:41 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
CC: 
Message-ID: <20181123113341.br77pxmfhcwn6yck@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References: <20181122163046.bkzck2bmbrf3fzm7@anna.jacobs.jacobs-university.de> <87tvk85et8.fsf@nic.cz> <20181123093813.gpxrtanbxgadpwih@anna.jacobs.jacobs-university.de> <20181123.110548.845126088727972359.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20181123.110548.845126088727972359.mbj@tail-f.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB02.jacobs.jacobs-university.de (10.70.0.121) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 11:33:48 -0000

On Fri, Nov 23, 2018 at 11:05:48AM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Fri, Nov 23, 2018 at 10:22:11AM +0100, Ladislav Lhotka wrote:
> > > Juergen Schoenwaelder  writes:
> > > 
> > > > On Thu, Nov 22, 2018 at 03:00:27PM +0100, Martin Bjorklund wrote:
> > > >> Andy Bierman  wrote:
> > > >> > 
> > > >> > 9.9 .  The leafref
> > > >> > Built-In Type
> > > >> > 
> > > >> >    The leafref built-in type is restricted to the value space of some
> > > >> >    leaf or leaf-list node in the schema tree and optionally further
> > > >> >    restricted by corresponding instance nodes in the data tree.  The
> > > >> >    "path" substatement (Section 9.9.2
> > > >> > ) is used to
> > > >> > identify the referred
> > > >> >    leaf or leaf-list node in the schema tree.  The value space of the
> > > >> >    referring node is the value space of the referred node.
> > > >> 
> > > >> Yes, it should be "data tree" in both occurrences.
> > > >
> > > > Time for an errata?
> > > 
> > > Here is the old discussion thread:
> > > 
> > > https://www.ietf.org/mail-archive/web/netmod/current/msg15979.html
> > > 
> > > Everything relevant had been extensively discussed in it, and I am
> > > sceptical that we can come up with anything significantly better - it
> > > will only be more (or different) hand-waving. The problem is inherent in
> > > the leafref design introduced in YANG 1.1. It won't go away no matter
> > > how much we paper over it.
> > >
> > 
> > So you think the use of 'schema tree' in the text quoted above (is
> > used to identify the referred leaf or leaf-list node in the schema
> > tree) is correct??
> > 
> > I do not want to discuss whether you like the design of leafrefs or
> > not here - at this time we should focus on whether the text is correct
> > or not given the design we have. So again, you think that 'schema
> > tree' is correct in the statement?
> 
> After reading the quoted thread and thinking some more, I think the
> text in 9.9 is in fact correct.  As Lada wrote in that thread:
>  
>    2. It [path] also implicitly refers to a leaf node in the schema
>       [...]
> 
> The problem is that this "implicit reference" isn't defined.  9.9
> talks about reference to a schema node, and 9.9.2 talks about the data
> tree, but there is no text that ties these together.

Here is an attempt to rewrite things in a way according to how I
understand things works. It should be possible to describe what we
mean. If we can't do that, we have a bigger problem. (I have changed
only the last two sentences.)

OLD

   The leafref built-in type is restricted to the value space of some
   leaf or leaf-list node in the schema tree and optionally further
   restricted by corresponding instance nodes in the data tree.  The
   "path" substatement (Section 9.9.2) is used to identify the referred
   leaf or leaf-list node in the schema tree.  The value space of the
   referring node is the value space of the referred node.

NEW

   The leafref built-in type is restricted to the value space of some
   leaf or leaf-list node in the schema tree and optionally further
   restricted by corresponding instance nodes in the data tree.  The
   "path" substatement (Section 9.9.2) is used to identify a leaf or
   leaf-list node in the data tree. The value space of the leafref
   node is determined by the value space of the schema tree node
   definining the referenced data tree node.

This likely is not perfect yet but perhaps we manage to make it
perfect. ;-) What is not yet clearly described I think is what
'further restricted by corresponding instance nodes in the data tree'
means (and that I think depends on require-instance). Perhaps add
'(see Section 9.9.3)' to the end of the first sentence to handle this.

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


From nobody Fri Nov 23 04:02:12 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3332128B14 for ; Fri, 23 Nov 2018 04:02:11 -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 0Ls1rpNSYebB for ; Fri, 23 Nov 2018 04:02:07 -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 5A89C12870E for ; Fri, 23 Nov 2018 04:02:07 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 699DA642DE for ; Fri, 23 Nov 2018 13:02:04 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1542974524; bh=CUNUPnaBvjXKdqrPeov72A27rRmcXhkEnem4+4vpFPs=; h=From:To:Date; b=rLDDp3W3/wDxfSQfxkDlEqzfJ1fNLLVVCbTAsI0vGG32/Nay086zvMG8lfUbbn+rw SzADCTL5xqYVIAk5KR0cEHcUKc6KRqRcrGLDWYpb6miYdHeDXoxdSy1F3JU1we6ASr Z/UibGkDomHjSObPecwnSwwIMnfYmF6MLW01vK7c=
Message-ID: 
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Fri, 23 Nov 2018 13:02:03 +0100
In-Reply-To: <20181123113341.br77pxmfhcwn6yck@anna.jacobs.jacobs-university.de>
References: <20181122163046.bkzck2bmbrf3fzm7@anna.jacobs.jacobs-university.de> <87tvk85et8.fsf@nic.cz> <20181123093813.gpxrtanbxgadpwih@anna.jacobs.jacobs-university.de> <20181123.110548.845126088727972359.mbj@tail-f.com> <20181123113341.br77pxmfhcwn6yck@anna.jacobs.jacobs-university.de>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 12:02:12 -0000

On Fri, 2018-11-23 at 12:33 +0100, Juergen Schoenwaelder wrote:
> On Fri, Nov 23, 2018 at 11:05:48AM +0100, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Fri, Nov 23, 2018 at 10:22:11AM +0100, Ladislav Lhotka wrote:
> > > > Juergen Schoenwaelder  writes:
> > > > 
> > > > > On Thu, Nov 22, 2018 at 03:00:27PM +0100, Martin Bjorklund wrote:
> > > > > > Andy Bierman  wrote:
> > > > > > > 9.9 ;.  The
> > > > > > > leafref
> > > > > > > Built-In Type
> > > > > > > 
> > > > > > >    The leafref built-in type is restricted to the value space of
> > > > > > > some
> > > > > > >    leaf or leaf-list node in the schema tree and optionally
> > > > > > > further
> > > > > > >    restricted by corresponding instance nodes in the data
> > > > > > > tree.  The
> > > > > > >    "path" substatement (Section 9.9.2
> > > > > > > ;) is used to
> > > > > > > identify the referred
> > > > > > >    leaf or leaf-list node in the schema tree.  The value space of
> > > > > > > the
> > > > > > >    referring node is the value space of the referred node.
> > > > > > 
> > > > > > Yes, it should be "data tree" in both occurrences.
> > > > > 
> > > > > Time for an errata?
> > > > 
> > > > Here is the old discussion thread:
> > > > 
> > > > https://www.ietf.org/mail-archive/web/netmod/current/msg15979.html
> > > > 
> > > > Everything relevant had been extensively discussed in it, and I am
> > > > sceptical that we can come up with anything significantly better - it
> > > > will only be more (or different) hand-waving. The problem is inherent in
> > > > the leafref design introduced in YANG 1.1. It won't go away no matter
> > > > how much we paper over it.
> > > > 
> > > 
> > > So you think the use of 'schema tree' in the text quoted above (is
> > > used to identify the referred leaf or leaf-list node in the schema
> > > tree) is correct??
> > > 
> > > I do not want to discuss whether you like the design of leafrefs or
> > > not here - at this time we should focus on whether the text is correct
> > > or not given the design we have. So again, you think that 'schema
> > > tree' is correct in the statement?
> > 
> > After reading the quoted thread and thinking some more, I think the
> > text in 9.9 is in fact correct.  As Lada wrote in that thread:
> >  
> >    2. It [path] also implicitly refers to a leaf node in the schema
> >       [...]
> > 
> > The problem is that this "implicit reference" isn't defined.  9.9
> > talks about reference to a schema node, and 9.9.2 talks about the data
> > tree, but there is no text that ties these together.
> 
> Here is an attempt to rewrite things in a way according to how I
> understand things works. It should be possible to describe what we
> mean. If we can't do that, we have a bigger problem. (I have changed
> only the last two sentences.)
> 
> OLD
> 
>    The leafref built-in type is restricted to the value space of some
>    leaf or leaf-list node in the schema tree and optionally further
>    restricted by corresponding instance nodes in the data tree.  The
>    "path" substatement (Section 9.9.2) is used to identify the referred
>    leaf or leaf-list node in the schema tree.  The value space of the
>    referring node is the value space of the referred node.
> 
> NEW
> 
>    The leafref built-in type is restricted to the value space of some
>    leaf or leaf-list node in the schema tree and optionally further
>    restricted by corresponding instance nodes in the data tree.  The
>    "path" substatement (Section 9.9.2) is used to identify a leaf or
>    leaf-list node in the data tree. The value space of the leafref
>    node is determined by the value space of the schema tree node

The term "value space of a schema tree node" is not defined.


>    definining the referenced data tree node.

With require-instance=false there needn't be any referenced data tree node.

> 
> This likely is not perfect yet but perhaps we manage to make it
> perfect. ;-) What is not yet clearly described I think is what
> 'further restricted by corresponding instance nodes in the data tree'
> means (and that I think depends on require-instance). Perhaps add

Right. In this case it is not "further restricted" but rather there is a
discrete set of possible values.

Lada

> '(see Section 9.9.3)' to the end of the first sentence to handle this.
> 
> /js
>    
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Fri Nov 23 04:03:47 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFA2128B14 for ; Fri, 23 Nov 2018 04:03:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.738
X-Spam-Level: *
X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, 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 pzNj3cgp3Hjr for ; Fri, 23 Nov 2018 04:03:42 -0800 (PST)
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30111.outbound.protection.outlook.com [40.107.3.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DA4130E2D for ; Fri, 23 Nov 2018 04:03:34 -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=Sric8AsjyGcvH1/lMOhtKYagLSKVKpxeI3B1I9WOCWk=; b=Q4wA4RRRy/WPfAwJDlXyxUrsUmpzHk9o7mFit1RjEIg6fULlwroPpg5/QmMFcTqHkn9/FCZ+F6iCxCMy9PBtNFsXwoiiQD2UpqVs9dxlcVuPdlt7D2AFcQP9yDjYuwpqpnglQFviUFrl+EvJyipj65D1ip2mUcMafy8Io1dkQ0s=
Received: from VI1PR07MB5022.eurprd07.prod.outlook.com (20.177.202.206) by VI1PR07MB4141.eurprd07.prod.outlook.com (52.134.25.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.12; Fri, 23 Nov 2018 12:03:28 +0000
Received: from VI1PR07MB5022.eurprd07.prod.outlook.com ([fe80::929:bd11:beb6:b887]) by VI1PR07MB5022.eurprd07.prod.outlook.com ([fe80::929:bd11:beb6:b887%4]) with mapi id 15.20.1382.010; Fri, 23 Nov 2018 12:03:28 +0000
From: tom petch 
To: Ladislav Lhotka , "netmod@ietf.org" 
Thread-Topic: [netmod] Address Family versus Address Family
Thread-Index: AQHUgY5NMaELHgY0r0Cg02b5JWd9UQ==
Date: Fri, 23 Nov 2018 12:03:28 +0000
Message-ID: <019f01d48324$44356bc0$4001a8c0@gateway.2wire.net>
References: <033101d4818e$08689dc0$4001a8c0@gateway.2wire.net> <87wop6sk6k.fsf@nic.cz>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-clientproxiedby: CWXP265CA0023.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:2e::35) To VI1PR07MB5022.eurprd07.prod.outlook.com (2603:10a6:803:9b::14)
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; VI1PR07MB4141; 6:4oGhWIhm5q6Q2JfcdiOLBKECSMs7FvVIGm3rV4W448DXJgc71o/dZSa0+f8tP3mRyf4jI53eWCArXl11d3uPinwh73RZssmU2pmNW+zZkq2MJYtCaQcmHDhytBjjSord0TPAFXHUoxYm6Xgu4xpLY/RqprMa3SfkLFEYhCafi092C40K3pA2cxDqaaovkRoh17ZDOAkr8RP/pCPS2uuJHEQtTNctLbQ5J7wZnzZ7aH2XJauJg+XQgYHqrepsfvraFq1PJw9y05shKJkR6HqpJKOaosoqhw861T4XvwcUGa6whmICoCIXHkhxsxiyCWe2z9Dgke+MnnKsTdrRLRHTLtdu2h61m1NPfY4kcfLUwgdBqhBCWRuzXHxEaSAOqf0rAIFq2d0QpV1J3yB0L/UN482vbrhhf4WuEZlx/7UXuK7RsjNyTjVT0MZgPSRyGcM6lMWDwCawy/zikCNga1b3fA==; 5:TvLFalIrzer1NZ5QQppEu84Txi060XuQj1GOIDzp+YvWfTljIDZ+5bvPDPnktbutn9lYQAuGwg0UTtrDvpnKpH3VTACpSlgajOwUOFrcXRoA1wLAtnj2xS626MvyiiHxgJ4QEf4AH7pL4UUHFZNSEkIAFdJkpZP6HvOwQUTJOns=; 7:wIGDGa6Ev1bUzwZVlnPtnMLGUXG1y6cpJw1sJrrf/DzRNQ907wJphR/Dito4lghVpTuVkmETD7Upp7l1kXjV8lXYV6tNOHMaoPa5gWiWCujlvgLbb3gpRF/VWoS1QMwnjPVTpGz7MJH4+ub0rAG7hg==
x-ms-office365-filtering-correlation-id: f2946aa9-736d-4204-09bc-08d6513badeb
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7193020); SRVR:VI1PR07MB4141; 
x-ms-traffictypediagnostic: VI1PR07MB4141:
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231442)(944501410)(52105112)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB4141; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4141; 
x-forefront-prvs: 086597191B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(396003)(376002)(346002)(136003)(13464003)(199004)(189003)(486006)(305945005)(66066001)(256004)(14444005)(99286004)(14454004)(86152003)(7736002)(2900100001)(446003)(52116002)(25786009)(71190400001)(5660300001)(86362001)(97736004)(6306002)(476003)(6246003)(478600001)(68736007)(966005)(76176011)(102836004)(6506007)(386003)(316002)(105586002)(1556002)(2501003)(229853002)(3846002)(84392002)(33896004)(8676002)(53936002)(44736005)(71200400001)(114624004)(106356001)(2906002)(81166006)(6486002)(14496001)(81156014)(8936002)(26005)(6436002)(110136005)(6512007)(9686003)(186003)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB4141; H:VI1PR07MB5022.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: QgJwysTyZxego/EFr6RIcQm//3jP8NL4GPJKVXhnmPONYTC2q9vOTcACdyBcXTCx8ktxwhfLRxFoY+UsieG80dVxz+ZQTp+AaB5NUj3NJaROJ5P/m9w0qPKhgxR/8Ei5ATWJws7Amzj0WCnojzvY3ytncYwrOBuX311LAZK0wJosBDtGeVxMl2Z52//k7Jy0Ux+DuLaqAGVR2bTi02MNJhVBFIsdX3HZ5Wo83vDhgyYiWx5sNOgoet2BuofdymlD9RNDcd0KlfDM+qY4uBtbXl29dQy9LxHTgo3Ez8JLAhdjepEkoqGi7NYsRH9RWlYMiNi2IovQoKaEHNIS33SaWlGMcicDiXmXOzhF69uy6bE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <259A0CF7F6221148AB4E59830CE79953@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f2946aa9-736d-4204-09bc-08d6513badeb
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2018 12:03:28.4187 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4141
Archived-At: 
Subject: Re: [netmod] Address Family versus Address Family
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 12:03:46 -0000

----- Original Message -----
From: "Ladislav Lhotka" 
Sent: Wednesday, November 21, 2018 12:13 PM

> tom petch  writes:
>
> > I have always thought of Address Family as something that BGP
created
> > and that others have used.  In fact, I find that there is an IANA
> > registry of Address Families which RFC8294 has turned into a YANG
> > module, but one using enumeration and not identity, which would seem
to
> > limit its utility.
>
> In draft-lhotka-dnsop-iana-class-type-yang-00 we also use enumerations
> representing DNS classes and resource records types. However, in
> addition to the enumeration type that reflects the corresponding IANA
> registries, we also added a union type that allows for using either
the
> mnemonic name or assigned number:
>
> typedef rr-type {
>   type union {
>     type uint16;
>     type rr-type-name;
>   }
> }
>
> (and similarly for DNS classes). The numeric value corresponding to
each
> mnemonic name is given by the "value" statement inside each enum.
>
> Actually, this approach was suggested by RFC 3597 that introduced the
> general possibility of representing DNS classes and RR types
> numerically. For example, RR type "AAAA" can be equivalently
represented
> as "TYPE28".
>
> Perhaps this approach could be used for address families as well. In
> fact, the use of identities also has its share of problems.

Lada

As you say, both enumeration and identity have their issues and there is
just such a definition taking place now.

The softwires WG are creating an IANA-maintained YANG module for the
existing tunnel type IANA registry, such that when a new tunnel type is
registered, then entries will be added to the existing tunnel type MIB
and to the (new) YANG module.

The YANG module is purely identity, based on ift:tunnel.

Should they be being advised to take a more sophisticated approach?

Tom Petch


> Lada
>
> >
> > Indeed, while the lsr WG uses that module, I2RS does not with
> >  draft-ietf-i2rs-rib-data-model
> > defining
> >    identity address-family {description  "Base identity from which
all
> > RIB      address families are derived.";  }
> >
> > identity - good; RYO definition - um.
> >
> > BGP also goes its own way with
> >   identity AFI_SAFI_TYPE { description
> >          "Base identity type for AFI,SAFI tuples for BGP-4";
> >        reference "RFC4760 - multi-protocol extensions for BGP-4";  }
> >
> > And then there is RFC8349 with
> >   identity address-family {
> >     description  "Base identity from which identities describing
address
> >           families are derived.";      }
> > and which defines ipv4 and ipv6, and which ties the concept firmly
to a
> > RIB in a 1:1 correspondence.
> >
> > When I raised this on the rtgwg list, the response was that the
concept
> > of an address family is particular to a protocol, so there is no
reason
> > for ospf and BGP to share anything, which is how it seems.
> >
> > So, is there any reason for anyone to use the definition in RFC8349?
or
> > the IANA module?
> >
> > Tom Petch
> >
> >
> > _______________________________________________
> > 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 Nov 23 04:39:16 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403AF12E043 for ; Fri, 23 Nov 2018 04:39:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 E5vy4JyKZxJn for ; Fri, 23 Nov 2018 04:39:12 -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 6737012958B for ; Fri, 23 Nov 2018 04:39:11 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 52E36E16; Fri, 23 Nov 2018 13:39:09 +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 byQmrELZV4VB; Fri, 23 Nov 2018 13:39:09 +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, 23 Nov 2018 13:39:09 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D08D2003C; Fri, 23 Nov 2018 13:39:09 +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 SdU25Mh0_9U6; Fri, 23 Nov 2018 13:39:08 +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 AC53320037; Fri, 23 Nov 2018 13:39:08 +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, 23 Nov 2018 13:39:08 +0100
Received: by anna.localdomain (Postfix, from userid 501) id D6DCB30044A385; Fri, 23 Nov 2018 13:39:07 +0100 (CET)
Date: Fri, 23 Nov 2018 13:39:07 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
CC: 
Message-ID: <20181123123907.4wuuojmoikb7fegr@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org
References: <20181122163046.bkzck2bmbrf3fzm7@anna.jacobs.jacobs-university.de> <87tvk85et8.fsf@nic.cz> <20181123093813.gpxrtanbxgadpwih@anna.jacobs.jacobs-university.de> <20181123.110548.845126088727972359.mbj@tail-f.com> <20181123113341.br77pxmfhcwn6yck@anna.jacobs.jacobs-university.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB03.jacobs.jacobs-university.de (10.70.0.155) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 12:39:15 -0000

On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
> > 
> > Here is an attempt to rewrite things in a way according to how I
> > understand things works. It should be possible to describe what we
> > mean. If we can't do that, we have a bigger problem. (I have changed
> > only the last two sentences.)
> > 
> > OLD
> > 
> >    The leafref built-in type is restricted to the value space of some
> >    leaf or leaf-list node in the schema tree and optionally further
> >    restricted by corresponding instance nodes in the data tree.  The
> >    "path" substatement (Section 9.9.2) is used to identify the referred
> >    leaf or leaf-list node in the schema tree.  The value space of the
> >    referring node is the value space of the referred node.
> > 
> > NEW
> > 
> >    The leafref built-in type is restricted to the value space of some
> >    leaf or leaf-list node in the schema tree and optionally further
> >    restricted by corresponding instance nodes in the data tree.  The
> >    "path" substatement (Section 9.9.2) is used to identify a leaf or
> >    leaf-list node in the data tree. The value space of the leafref
> >    node is determined by the value space of the schema tree node
> 
> The term "value space of a schema tree node" is not defined.

OK. So we say 'the value space of the type of the schema tree node'.
 
> >    definining the referenced data tree node.
> 
> With require-instance=false there needn't be any referenced data tree node.

So we add "(irrespective whether the node exists or not).

> > This likely is not perfect yet but perhaps we manage to make it
> > perfect. ;-) What is not yet clearly described I think is what
> > 'further restricted by corresponding instance nodes in the data tree'
> > means (and that I think depends on require-instance). Perhaps add
> 
> Right. In this case it is not "further restricted" but rather there is a
> discrete set of possible values.

A discrete set of possible values is a restriction so I do not
understand your comment. So here is the next iteration:

NEW:

    The leafref built-in type is restricted to the value space of some
    leaf or leaf-list node in the schema tree and optionally further
    restricted by corresponding instance nodes in the data tree (see
    Section 9.9.3).  The "path" substatement (Section 9.9.2) is used
    to identify a leaf or leaf-list node in the data tree. The value
    space of the leafref node is determined by the value space of the
    type of the schema tree node definining the referenced data tree
    node (irrespective whether the referenced data tree node exists or
    not).

/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 Nov 23 04:48:49 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 271E412958B for ; Fri, 23 Nov 2018 04:48:47 -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=Rjy2K1Tu; dkim=pass (1024-bit key) header.d=ericsson.com header.b=UvSBwQfp
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6r29gJ05Wp5a for ; Fri, 23 Nov 2018 04:48:44 -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 04756124D68 for ; Fri, 23 Nov 2018 04:48:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1542977322; x=1545569322; 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=D/q1CEejpDBSqxmeUnNVR1vLAaXpQMamSZl4LgGZIyM=; b=Rjy2K1Tuxs2ybKbqSYmu+DfxT6Vzc3c0eRNIbp6XYVn0YrMcbASkZXTJSpEGK2FP AhSjH6+BnYZkWg/wLwD057HNl5+M00bz4oXepP2nYbahiRYkZC84awdpFge/hTNr KdAYt77eyWfMfXx1drO3nUGchy95F0+GtqV/ycrbskM=;
X-AuditID: c1b4fb30-f15ff700000043c4-99-5bf7f72a7805
Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D5.CE.17348.A27F7FB5; Fri, 23 Nov 2018 13:48:42 +0100 (CET)
Received: from ESESSMB503.ericsson.se (153.88.183.164) 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; Fri, 23 Nov 2018 13:48:41 +0100
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 23 Nov 2018 13:48:42 +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=Pb6R9fdCowA9DZFhilIs5/1Bf8qm8Et7UqTpuPeyngE=; b=UvSBwQfpY3aXf/EHhu8bwVS7/NtbvMT/U5WDtoR9tss3R+gcxvAav83bDYb4H4mrSOXS91asRcusm3Tqem5AhdvOm7vs40stM6fqMbkO5ve/VrIi/9ry80s/MEj6dgO2IgH3fKdSVCE7xvJjgGxwpj95VX6fGd5yZNpRt9gzrWQ=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1SPR00MB26.eurprd07.prod.outlook.com (10.172.255.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.14; Fri, 23 Nov 2018 12:48:40 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::70d1:cf80:392b:814b]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::70d1:cf80:392b:814b%4]) with mapi id 15.20.1382.007; Fri, 23 Nov 2018 12:48:40 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Joe Clarke , "netmod@ietf.org" 
Thread-Topic: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt
Thread-Index: AQHUdXYipV5hG5p2iUu/shgjxloKow==
Date: Fri, 23 Nov 2018 12:48:40 +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>
In-Reply-To: <2a796f78-41b7-376c-8f51-215d14cc4e2c@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [129.192.74.5]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
x-clientproxiedby: HE1PR06CA0155.eurprd06.prod.outlook.com (2603:10a6:7:16::42) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1SPR00MB26; 6:Zk9cCXY+iyyqlBWXh+XFnTzmvjrVfLqbjTS46IdMOHXK9jfSVrcbm9dZIS8nE12+BeE4GzaQCv+XxoMKFLwdhDneHVgxAhQIofD7K3ci449J2TvYCBcrhyThbrCp3kvnq7gVjrPjmjqU2oX628gj+XF/ohUeWfdIUGBIN0KcvbQa6jiykQeynQzT9hHE4qMGmymry6tJlAklBWG4oOb6izme5ErmQyh6+uUyzQziyT8PU8UYRZItnXm6V9BPR9uAEququJ5Rv/eCJcum1KYdT7bUrV62Aaz0vSZERii1NZPrzQt2ryGpJ52Bqnwnsvm9N7jWTcOeXv/l/LLOMIcLnJ6AxT+FlgzraVhP/88QTspkMlKDPFbsHaxzJeYLLjQnEMYShZ2joVidUmqqg2jQZRxdixDHkV0HRUlSHwTvhdYT2TffPQ4qmDXXguLjj6A5sz/YptjgSWMtWGfr7kcYaQ==; 5:+MiZKN0Bf5l/R2R3/DHF3qFP6DRYTH+J5TwnY08XQgFMiW25cs3E0Yts57hdOcg08jSRTg+rSZGDZv/qXD/zUaU960ZXd7fVxXfx8LlcmNaaZb3GQV2TqG/0X1hca5e3IlOg+33yoTcQAjKlW2I4pJrzqA0bTRYj0272tTB8idg=; 7:Dnzfu3YR+V4aTNtXDloaYGqcEShmFAZ2wGQC84WaHPeGAnFw8shpHa2UW1IKF+GOh87VjOAPvzu/dusdsTSH831f46P2t7b37pT0u+Br2kJAjc+TQ7p6NrgSq9gdhXR1+2p2rO7JDlX0gpRElbgFLA==
x-ms-office365-filtering-correlation-id: d44d7b97-d5a5-4754-65bf-08d65141fe5b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1SPR00MB26; 
x-ms-traffictypediagnostic: VI1SPR00MB26:
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)(93006095)(93001095)(3231442)(944501410)(4983020)(52105112)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1SPR00MB26; BCL:0; PCL:0; RULEID:; SRVR:VI1SPR00MB26; 
x-forefront-prvs: 086597191B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(366004)(136003)(346002)(376002)(199004)(189003)(252514010)(51914003)(51444003)(316002)(52116002)(58126008)(99286004)(110136005)(6486002)(446003)(345774005)(386003)(53546011)(102836004)(6506007)(86362001)(85182001)(31696002)(3846002)(6116002)(7736002)(486006)(11346002)(66574009)(68736007)(476003)(2616005)(229853002)(76176011)(186003)(65956001)(66066001)(65806001)(71190400001)(71200400001)(26005)(6436002)(15650500001)(99936001)(14454004)(2900100001)(53936002)(8676002)(8936002)(97736004)(81156014)(81166006)(6512007)(6246003)(36756003)(25786009)(3260700006)(106356001)(966005)(85202003)(2906002)(64126003)(2501003)(105586002)(65826007)(6306002)(256004)(31686004)(236005)(54896002)(478600001)(5660300001)(606006)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1SPR00MB26; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: yQIrEep+IB5iwN5M2CdK0paHKzDP8Kyyy+HPWw7C5MFa+HaWs15WIOI506lnVnzTaCRIfjmj1PFK5/SKU/GvRmMXD+qMNhTmOGeAcdoBtGFwubi4nkBjPiWphovN8aw55dhDWtxFRtCP0JKw2d1pysjN6YD7JONECJk/LZ1rFX/WJ1sJKswPKEB7jnGrkfxTCPV4d9U4YvEXF144FOtFVlkuEzcBCUVjUcv/Z/+4sLGxC5uyKqFB0oqvC05AHrfe75u03IG+TBRHCAPyoaHMG8iA8EqFCPXw1tpbC4Fx0znJxevlOHMiKtIbdGiRpBP0d4OQLwaFHBMRrLzNY9gWYJ3BBVJR6PTubdq44aAFY2s=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030704060609020204030206"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d44d7b97-d5a5-4754-65bf-08d65141fe5b
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2018 12:48:40.8306 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1SPR00MB26
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0iTURjGOd/37fNzNDotrTe7oCMrtcyyQLqYl1D/yYKITCtd9ZHmnLYt SQnSUssr5iV1OFy0DEwts9RITS0Fs8IKE60kL0xNM4V0eemy7Uyo/37v+zzvc857OBwt/iyw 4yLkKl4hl8okrJApCqpVbXE2GELcstRij8auBeRR8jZR4EUF5M1XCQJ0ulnqEBUs3HOGl0XE 8oqtnmHC8DuaEqsYTQa6eH8iESWgrPg0ZM0B3gEfqytQGhJyYvwCQeHIOEOKGQRVc4uKjoKp 4RnWVDA4m4bH9ZMUUfIpeK2rF5BCj6AzWc2aklm8H65NPKNMbIP9IaHhtrm/HMtA39HEkn4U pL8qtnhc4bt+0MrEDHaEgdKfyMQivA/a7nygyQE1CNpG0owmjrPGe6F9LMbkQXgFGF6Wm3No vBJ6h0oosp0N9L/tYAnbwujgbwFhe5jIbTX3bfEJKNBlmPcEfBPBp+lKhoSehPq+65bhzfC6 ewgRXgvvStItA10svNfU0UQ4ABVfBxki9CBYqLlrRQQnmNR8tlwpAlqejlpS10FZZj+TjdzU /9xcbZyncSqC1CcdtNr8BMugvWiIURu3pvEGKE2W/O83sQuU3hqjCe+GwrlmlrAD5KX3WxHe CWOtU4iwO5RW/mK1SFiGbJW88lTU2e3bXXlFxGmlMlruKudVD5HxozU/mnerQ6PD3i0Ic0iy RNQ5aQgRC6SxyrioFrTemDPw4F4nsmPk0XJeYiO64mCURWekcfG8IjpUcUHGK1vQao6RrBR5 BFYHi/FZqYqP5PkYXrGoUpy1XQKqLfDTFunTJjZo4/JffcnJavrDJLkUNbpFrll1/E2KxG+T 68YtfaDdeHC8xz9l3DH38KGojKDy0GDfZO+8gaTuTIV78+zzQXfHS96pl2OXftMPnagda8/x PB92dTKQn75x1Gmq7lyxpuZxoKr7mCzEN9fL54ePNr9hl0F1rrfA/kiVhFGGS7c50wql9C9m 8MyQcAMAAA==
Archived-At: 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 12:48:47 -0000

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


  
    
  
  
    
Thanks for the comments. Details below.

    
Balazs

    

    
On 2018. 11. 06. 4:25, Joe Clarke
      wrote:

    

    

      
On 11/5/18 21:54, Bal=C3=A1z=
s Lengyel wrote:


      

        
The first WG version of th=
e document is stored. It is the same as=C2=A0
draft-lengyel-netmod-yang-instance-data-05 except for the change of title=
=2E


      

      
Thanks, Balazs.  Here is an itemized review of this draft.  Thank you
for acknowledging my requirements around augmenting YANG data/structure.
 You will definitely need that when you start to document server
capabilities.

I agree with Lada and Rob that moving the use case examples to an
appendix would make it easier to get to the meat of the document.

    

    BALAZS: OK
    

      
In your terminology section,=
 you define an instance data set as
essentially a set of instance data.  I might incorporate the text from
your abstract to call instance data, data that is returned from a YANG
server.  This, too, isn't ideal, but I think it's worth being a bit more
descriptive here.

    

    

      
You use "YANG Based Instance=
 Data" as something that feels like a term
throughout the document, but you do not define this exactly.


    

    BALAZS: OK.

      yang _BASED_ instance data is removed as it led to confusion. I
      revert to the more simple "yang instance data".

      Added definition for Yang Instance data
    

      
Section 2.1.1

s/=EF=BB=BFCapbilites/Capabilities/

s/capabilites/capabilities/g

    

    BALAZS: OK
    

      
You say, "While it is good p=
ractice to allow a client to query these
capabilities from the live YANG server, that is often not enough."

"Not enough" doesn't sound right.  I would say, "that is sometimes not
possible."  You may mention examples like the server is not currently
available or the code driving the server is not publicly available, etc.<=
/pre>
    

    BALAZS: OK, changed
    

      
You say that, "Often when a =
network node is released an associated NMS
is released with it."

I don't know that this coupling happens "often."  I'd say that when new
network element code is released, operators want to understand the
capabilities that come within that new code.  Other NMS/OSS vendors want
to be able to understand the model provided by the new code so they can
adjust their client code.

You go on to say, "Network operators often build their own home-grown
NMS systems that needs to be integrated with a vendor's network node."

Again, the word "often" doesn't resonate with me.  I do agree that there
are NMS vendors that need to understand how to modify their NMS to
support other vendors' network elements and there are some operators
that are building their own NMS/OSS.

    

    BALAZS: If we think about independent NMS
      vendors they may release the NMS update after the new network node
      version is released.

      My point is that, many operators will not wait for the NMS to be
      developed over some time. They require the NMS on day 1.

      Anyway this is only an appendix now.
    
    

      
Section 2.1.2

s/configurationp/configuration/

    

    BALAZS: OK
    

      
Section 2.1.3

s/Dcomenting/Documenting/


    

    BALAZS: OK
    

      
Section 3

s/returmed/returned/

s/configuraton/configuration/

    

    BALAZS: OK
    

      
You say, "It SHOULD NOT be u=
sed if the file is stored in a version
control system (e.g. git) because the change of file names will break
the connection between the different revisions of the file."

I think you should drop this requirement.  I can use "git mv" or create
tags if I want to retain history.  I wouldn't try and legislate what
people do with their VCS.

    

    BALAZS: OK, although I still think it is
      better to avoid using the date.
    

      
You use "meta data" in a num=
ber of locations.  Might I suggest
"metadata."  I think that is a more common way to write that term.

    

    BALAZS: OK
    

      
Section 6

With your datastore leaf, if I pull this off of a running YANG server,
serialize it and share it with my customer, why wouldn't I have the
actual datastore from which I retrieved it?  What I'm saying is that
this element may be missing, but if it is, I don't think you can assume
the source datastore for config=3Dtrue nodes.

    

    BALAZS: This should be a default value.
      However as the default is a simple value, but 

      here it really depends on the config=3Dtrue/false and the existence=

      of writable-running 

      I put it into the description statement. If you need something
      else, like in your example, go ahead specify it.

      Reworded from imply to default.

    

      

s/dtastore/datastore/

s/thats/that's/

s/Formated/Formatted/

    

    BALAZS: OK
    

      
Section 8

Do you have to register the ".yid" file extension as well?

    

    BALAZS: Is there a registry for file
      extensions? I was not aware.
    

      
Thanks.

Joe



      

        
Balazs

-------- Forwarded Message --------
Subject: 	New Version Notification for
draft-ietf-netmod-yang-instance-file-format-00.txt
Date: 	Mon, 5 Nov 2018 18:12:04 -0800
From: 	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-00.txt
has been successfully submitted by Balazs Lengyel and posted to the
IETF repository.

Name: draft-ietf-netmod-yang-instance-file-format
Revision: 00
Title: YANG Instance Data File Format
Document date: 2018-11-04
Group: netmod
Pages: 14
URL:
https://www.ie=
tf.org/internet-drafts/draft-ietf-netmod-yang-instance-file-format-00.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-00
Htmlized:
https://datatracker.=
ietf.org/doc/html/draft-ietf-netmod-yang-instance-file-format


Abstract:
There is a need to document data defined in YANG models without the
need to fetch it from a live YANG server. Data is often needed
already in design time or needed by groups that do not have a live
running YANG server available. This document specifies a standard
file format for YANG Based Instance data, that is data that could be
stored in a datastore and whose syntax and semantics is defined by
YANG models. Most important use cases foreseen include documenting
server capabilities, factory-default settings, or vendor provided
default configurations.



Please note that it may take a couple of minutes from the time of submiss=
ion
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


_______________________________________________
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


  



--------------ms030704060609020204030206
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTEyMzEyNDgzNlow
LwYJKoZIhvcNAQkEMSIEIJ81wwoHEK9MFntebVWc2EYP/6iHm7J5K8/laNBcZPlyMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAH770eq9vF8igPPfOuxwOElrAm8zN4qniMlDWnldXfoGy+IF
N7PA42R2O2v7SO10AaX1DPLgaevgBzFlrffOQqu6mfBubbomtdXkSzGgI8fxaeAZ/6wX67ci
PWFEoZ8MqwIrWBdD28IvBJgnc6QeW2WNQ37UV24Uv/S7NPVtnTFupEvZl6ZE662pdCy/fTQb
SvXMcaPhyNz7qbuJqWKOY/nDia4Xu/QoaDCuIfU8Ve9iSNpNhVhfrNuXuLGIyJBC7kezbPpd
QiySiZmyFsFSHRZNATQpXFJwfH82oOa2N6uG3GKg8ShyZCluZzU0CB9Eq+WcPTE49SkjmFbk
x9yk8dEAAAAAAAA=

--------------ms030704060609020204030206--


From nobody Fri Nov 23 05:21:37 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54CD2128CFD for ; Fri, 23 Nov 2018 05:21:36 -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=dnoFwJ81; dkim=pass (1024-bit key) header.d=ericsson.com header.b=ErtWy6gf
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Pz71KOIHekE for ; Fri, 23 Nov 2018 05:21:33 -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 123AB127B92 for ; Fri, 23 Nov 2018 05:21:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1542979290; x=1545571290; 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=i21Z52KUYGunNdv+rQkbAFBS05Vf3S9xkp626YdtqW8=; b=dnoFwJ810RSfVbQh01h0Dy+hFFmbsuGm5NMoh1HhngYFUwokh9gTn5uDkkoX0Wux TD56Pnlv/8azpa5Zl1itAl5TVZ7jWqWfccQ0NQP6azMLErFbqOk0UyJkxBx/GQn1 jFJRrbmNIHP5cn8HfX5XNV/s55sPmb8ZlrJ1/VmTKVs=;
X-AuditID: c1b4fb25-a68609e00000191f-25-5bf7fedab35c
Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7E.E1.06431.ADEF7FB5; Fri, 23 Nov 2018 14:21:30 +0100 (CET)
Received: from ESESBMR505.ericsson.se (153.88.183.201) by ESESSMB505.ericsson.se (153.88.183.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 23 Nov 2018 14:21:25 +0100
Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESBMR505.ericsson.se (153.88.183.201) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 23 Nov 2018 14:21:25 +0100
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 23 Nov 2018 14:21:25 +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=TRp6E/FteXWN0ZQQNxGnqCKLLZhAMyH49BceVlXMWQQ=; b=ErtWy6gf+7kI8nhF5JDtKQ7eJGhIlL9sh71cV3UWk4Eq/5G9iVa9BYS9VLbrtl6GLuPSpoq9cI9zLcBWO8Ad56xb4iXsHtluD1qaTWTU5SH2Xd6TATiSBkx5cR/2igXW1mtQmeFvd1Vx2ed4S+VCOZPkWpkSdYEyyjeyKAZNh9U=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2814.eurprd07.prod.outlook.com (10.173.71.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.9; Fri, 23 Nov 2018 13:21:24 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::70d1:cf80:392b:814b]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::70d1:cf80:392b:814b%4]) with mapi id 15.20.1382.007; Fri, 23 Nov 2018 13:21:24 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Ladislav Lhotka , Martin Bjorklund 
CC: "netmod@ietf.org" 
Thread-Topic: Datastore leaf for yang instance data
Thread-Index: AQHUgy9uQuT8qLL6iU6nVdbyZztkVQ==
Date: Fri, 23 Nov 2018 13:21:23 +0000
Message-ID: <1f4103c1-4953-3df4-d50d-aed1961fbc50@ericsson.com>
References: <87y3a6izap.fsf@nic.cz> <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de> <58740c15bf3277e04329546476f60c1d12516594.camel@nic.cz> <20181106.104157.239419955739949818.mbj@tail-f.com> <866ff105cf8fda7eadbdce5b344f4cd734fd99b8.camel@nic.cz>
In-Reply-To: <866ff105cf8fda7eadbdce5b344f4cd734fd99b8.camel@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [129.192.74.5]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
x-clientproxiedby: HE1P191CA0011.EURP191.PROD.OUTLOOK.COM (2603:10a6:3:cf::21) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2814; 6:2FxPZI578MVkZcSq41szn5hPZVzoZRCyFVcmIcFU8NMSKIC9pN+U2DJpUJuZvwQxhbnoxpyfhH+J4tei7/4icTFz4zjWoWVgW85ZlhkgkrD5mmFWYkd/Pdj34SOCHnXm/5kK/AxbEhhLoFGbs3I+VbqIX8Veh4v2vy3ozAOW0G2it7j3mJdV9IVjoO/01vmdfiuu4AnayPWYuLZnM5PwsdFdgtrUaIj50cPeJaILxatsUEgUVKO5E1DRxlTx7GlHquNoYG2Xlvu6asKGxaW2THFZdRjjVXcs8vc6K7qwSG6IYrlM0sOU+SvvzFh1m+G39X4v0sMjMLl8ToE0v+cBjXM8PIts8t60nqurQNwXPU5V+cY0z66bDl1Wz4raKS42ZLmXDLfUz+zdNPqJpU7YGL258JCvdlsFiQg0VNcvFaEzDXUzHTv8T9Z0taU2xc/AQiRhuyuDCA3LCt2qcI7n3Q==; 5:Jie4Wl9GAQw25z4DGVKuyFd8bQ0gq6hG10CqX+0TYHFkhW8ox81UzHwVZtBX4fgoQzVXsE0g0ZMF3xSv+/PnQ6o0jPkVP3j1GUmc1FChBHCMJKByGTVyiPepPLyQb7xXjqTUVzgjRFSblMNlKJFzioRkDBocssdBsdWVqMomexA=; 7:w6akibPq1Kc62ZpqH5U0TRq2w8vWYcTFMz/MhPzL9TpEChQGPWcEOf7JuilgDyDhLyW60iKTP+xdIB4dFLj+lEeCiLtJLa6GBv4uObopzSEmM8NL0qUkZ06g8p5d8aqa5P+3szuqQmenHoBEHOM1EQ==
x-ms-office365-filtering-correlation-id: b2a894f2-f721-402c-309c-08d651469017
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2814; 
x-ms-traffictypediagnostic: VI1PR0701MB2814:
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)(3231442)(944501410)(4983020)(52105112)(3002001)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2814; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2814; 
x-forefront-prvs: 086597191B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(136003)(396003)(39860400002)(51444003)(189003)(199004)(252514010)(106356001)(66066001)(81166006)(8676002)(65806001)(65956001)(58126008)(81156014)(110136005)(65826007)(6506007)(97736004)(386003)(76176011)(105586002)(8936002)(99936001)(85182001)(7736002)(71200400001)(71190400001)(64126003)(5660300001)(68736007)(256004)(31686004)(14454004)(85202003)(4326008)(6436002)(6116002)(3846002)(476003)(36756003)(478600001)(26005)(6486002)(3260700006)(25786009)(2906002)(186003)(446003)(11346002)(2616005)(53936002)(236005)(102836004)(114624004)(966005)(52116002)(99286004)(6306002)(606006)(486006)(316002)(54896002)(31696002)(93886005)(6512007)(86362001)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2814; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 9gTICPM03ZaBqwj7XSTrgOmk8uE+z/D3D0nYQ6CUmc1Rw7tRDCaBqHnupjRl+q0SgGjp6OtgoZzVp8RY5DDQVwMuoASLnOnozwj8zk1HG+AEELU1SpupiZvgEWs1XGN25FANoHi9TIJMmkaJHgG3Bx0S9C7Ond/QxzLynmQdPvF5HQfHtUx9fcFiVoIZWKS1o9QG+nX9/HbPgL54j/Vlm5K92/JpMVedd4Lw0ybkT4/E3JwnwhI9X/I6yVSDuveWP2CAlhxyhFZ7TlEszt8s1JBbL0kP8w+/VdoopPUj+6ohBWgakOVc7L97v9Mmwiqzlwq7HJuKPwktTq7sHQ+BxZjHkbugF1QhsOumo6ikeas=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050408040505030308040407"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b2a894f2-f721-402c-309c-08d651469017
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2018 13:21:23.9324 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2814
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSfUhTURjGOffe3V1Xg5NpvkyCGmnRx6xMEooy0rRA6MMkrMyVtyXpjF2z tCCdiHMz8ivUZUxxmKhkrS+LTLTsQ0srE81GZU2zJlmjFBVXu94V9d/vOc/zvs85cBjSc1Ak YxLUKaxGrUyU0xKqbM+tUyv6neN7Vw6bVgY/r71IBxsMQ+Jg04tMUQgZYTZPEBGWbiuKuDpZ RW0nYyTr49nEhFRWE7AhTnIks+ux+FhP+smmrPAMZDqsRwwDeA10VizRIwnjiR8g0N1uIAQx hsD6Sif+K6aMDrcwE/Cpv4nmBYXzSehqcVCCc56Am8NatxhCcK95zLXNg6FxKOR8bZ5hL7wF eswXKZ5JvBis7R9pnudiBby7XOfOBML78jsigRVQ01iIeKawH7y+5CD4m0vxRmi3rxO6Cgm4 Yhsh+YyHq6uyoV7MM8LzYLy9nhC6fKDfZpphwF4w8KKDFtgbPn90igReAF+L2mbOvfF+KDHn Ib4AcBGC+8Z8WlgaC3ff6tzDy+FZrw0JPB9emgzugT4aeh9OkIIRCbppp1gwrAieNjrQn2lt eT6dj1Yb/7mh0ZUjcS6CvM5fBG9I8Rx4UmajjK5nk9gfqrPl/+d5XgbVlXZS4HVQOtlCC7wQ ig0DYoGDwN72HQkcCNWXp+kKJKlF3hzLHUxSrQ5UsJqEQxyXrFao2RQLcn24lutTfo2oe2RT K8IMks+W6r+P7/UUKVO5tKRWtMi158OVuudIRqmT1azcS6pd6LKl8cq0dFaTfEBzPJHlWpEv Q8l9pANrr8V4YpUyhT3KssdYzR+XYDxkGcj7QXSmdUqyrWCPsz57rnnZkze7o4IKasIqd9w8 sS8m7OXZXSU3LGEdobmKUt+42LrBb8WRuiiHdmdI6s8AVV8znbW7StUxyJ4Z6o06kDO82f54 zB7edG70XYN+MujM6NULp0Nl17f+sERGh8YSOYU3ZtX6D5fGObMfley0+ehlki9yijuiXLWU 1HDK36pIXCt4AwAA
Archived-At: 
Subject: [netmod] Datastore leaf for yang instance data
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 13:21:36 -0000

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


  
    
  
  
    
BALAZS: "Instance data associated with a datastore" may mean many
      things, that's why this relatively loose term is used. It may
      mean:

    

    
    
      
  • 
        Data was read from that datastore
    • 
      
  • 
        Data is intended to be fed into that datastore
    • 
      
  • 
        Something else ???
    • 
    

    


    

    
This can be useful if data is read from a datastore, but in a
      number of cases it is not useful:

    
    
      
  • Preloading configuration data: datastore may be running or
        candidate. 
    
      
    • 
      
  • Preloading mixed config and state data: We do have state data
        that is very stable and thus it is documented as instance data,
        and the instance data file is actually used to feed the state
        data into the SW. So datastore is: running, candidate +
        operational if NMDA is supported or state datastore (whatever
        that is) if NMDA is not supported
    • 
    

    
regards Balazs

    

    
=

      

    

    
On 2018. 11. 06. 11:03, Ladislav Lhotk=
a
      wrote:

    

    
=

      
On Tue, 2018-11-06 at 10:41 =
+0100, Martin Bjorklund wrote:


      

        
Ladislav Lhotka <lhotka@nic.cz&g=
t; wrote:


        

          
On Tue, 2018-11-06 at 07=
:36 +0100, Juergen Schoenwaelder wrote:


          

            
I agree that

        leaf datastore {
          type ds:datastore-ref;
          description  "The identity of the datastore for which
            the instance data is documented for config=3Dtrue data nodes.=

            The leaf MAY be absent in which case the running dtastore or
            if thats not writable, the candidate datastore is implied.

            For config=3Dfalse data nodes always the operational
            data store is implied.";
    }

is pretty confusing. It should be something like this:

        leaf datastore {
          type ds:datastore-ref;
          description  "The identity of the datastore holding
            the instance data. If the instance data is not associated


          

          
Or rather the datastore that the instance data was extracted from.


        

        
I prefer "associated with".  There are other uses cases than just
holding data "extracted from", e.g., data that is supposed to "be
inserted into" a datastore.  "associated with" is less resrictive.


      

      
It unclear what "associated with" means in this context.

Lada

    

    

    
=

      

      

        

        

          
After that,
the data exists on its own and the originating datastore may later be


        

        
holding


        

          
something else.



          

            
        with a datasto=
re, then this leaf MUST be absent.";


          

          
RFC 2119 language would make sense if there is anything that could break =
if


        

        
that


        

          
MUST isn't observed. But=
 we even didn't know what the data is going to be


        

        
used


        

          
for.

I would treat the "datastore" item as a purely optional information


        

        
I agree.


/martin





        

          
that, if
present, was provided for some reason. If it is false, what can we do?



          

            
    }

I am against merging data from different datastores together, which
the last sentence of the original text seems to imply.


          

          
Both config true and config false data may come from <operational>,=
 so it
doesn't necessarily mean any mixing of datastores. But then again, I thin=
k


        

        
that


        

          
the datastore informatio=
n isn't in most cases that interesting.

Lada



          

            
/js

On Tue, Nov 06, 2018 at 11:51:26AM +0700, Ladislav Lhotka wrote:


            

              
Joe Clarke <jclarke@cis=
co.com> writes:


              

                
=3D=3D=3D

Section 6

With your datastore leaf, if I pull this off of a running YANG server,
serialize it and share it with my customer, why wouldn't I have the
actual datastore from which I retrieved it?  What I'm saying is that
this element may be missing, but if it is, I don't think you can


              

            

          

        

        
assume


        

          

            

              

                
the source datasto=
re for config=3Dtrue nodes.



              

              
The description of the "datastore" leaf doesn't make much sense to
me. It says that for configuration data the default is "running" or
"candidate" if "running" isn't writable. Why should it matter whether
"running" is writable? It looks like it is assumed that the config data


            

          

        

        
will


        

          

            

              
eventually be fed in=
to the indicated datastore, but I don't see any
reason for such an assumption.

I can see that "datastore" can be occasionally useful as auxiliary
metadata but, in my view, this document addresses also instance data
that is not necessarily bound to any datastore.

Lada

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

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


            

          

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

_______________________________________________
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


  



--------------ms050408040505030308040407
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTEyMzEzMjExOVow
LwYJKoZIhvcNAQkEMSIEICQn7ZxXPfQjfcNiyQokt4vXrS7J91SPp+1dLbv//yftMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBALbwaObyDez+zxERoHdnNcADEeIdg7fv4vrljdvywYPaJFuS
QjMdcqz+ES131dYGGLAhaLVoH/WxgWSdSYtLZxki7xQwwpEQAEGV4gmXB5coJZpglzsx2hE9
Icj+EAYMUE4Iz7I+8ysTuWa7WOU4OA3H0TLjAk+mV4mCJ+0+2FaD1uojvW0GTuCiA4/7MGGy
FXYKgVXCyqfi+cbvmEBGf+c2HRhSLIAHpd9nI4X6Eakcc+nnCwvtVxT3aQEzYQEGvDItss0T
DeP+2Nq0OPSeGsWkEjnCSMOVF4DqMtJlty1Mfsw2VT8xAsdqp2aurRx7SoznA/W6hAGeZdXG
5q41ZOsAAAAAAAA=

--------------ms050408040505030308040407--


From nobody Fri Nov 23 05:29:27 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F9C12F1A2 for ; Fri, 23 Nov 2018 05:29:25 -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 F97OzffTvdsc for ; Fri, 23 Nov 2018 05:29:23 -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 EFA0312E043 for ; Fri, 23 Nov 2018 05:29:22 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 53B7864238; Fri, 23 Nov 2018 14:29:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1542979759; bh=tQdfAxtKp6Udbh80Sb+59BiGT8uZtzj5NjVnj58Mrjk=; h=From:To:Date; b=F6GilWo/l1CrDvXyKej5bYlxP/UdjnpI/bQe1xu/4ioYFu7PQ0crKwN5gaJPI/Qqn XQbKRQFgJ7TlK3niyISY2j26hwR7X/9QCuC3IuF2wTwqseuwFdNt6q9dQA+ZHyHIAd ruNDDQrm2IULN+5JtJ6N6117pQiLa56qJC8clBJA=
Message-ID: <3c8272ada8f28ed41c0d7fc447fdded62f42bf13.camel@nic.cz>
From: Ladislav Lhotka 
To: Juergen Schoenwaelder 
Cc: netmod@ietf.org
Date: Fri, 23 Nov 2018 14:29:18 +0100
In-Reply-To: <20181123123907.4wuuojmoikb7fegr@anna.jacobs.jacobs-university.de>
References: <20181122163046.bkzck2bmbrf3fzm7@anna.jacobs.jacobs-university.de> <87tvk85et8.fsf@nic.cz> <20181123093813.gpxrtanbxgadpwih@anna.jacobs.jacobs-university.de> <20181123.110548.845126088727972359.mbj@tail-f.com> <20181123113341.br77pxmfhcwn6yck@anna.jacobs.jacobs-university.de>  <20181123123907.4wuuojmoikb7fegr@anna.jacobs.jacobs-university.de>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 13:29:26 -0000

On Fri, 2018-11-23 at 13:39 +0100, Juergen Schoenwaelder wrote:
> On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
> > > Here is an attempt to rewrite things in a way according to how I
> > > understand things works. It should be possible to describe what we
> > > mean. If we can't do that, we have a bigger problem. (I have changed
> > > only the last two sentences.)
> > > 
> > > OLD
> > > 
> > >    The leafref built-in type is restricted to the value space of some
> > >    leaf or leaf-list node in the schema tree and optionally further
> > >    restricted by corresponding instance nodes in the data tree.  The
> > >    "path" substatement (Section 9.9.2) is used to identify the referred
> > >    leaf or leaf-list node in the schema tree.  The value space of the
> > >    referring node is the value space of the referred node.
> > > 
> > > NEW
> > > 
> > >    The leafref built-in type is restricted to the value space of some
> > >    leaf or leaf-list node in the schema tree and optionally further
> > >    restricted by corresponding instance nodes in the data tree.  The
> > >    "path" substatement (Section 9.9.2) is used to identify a leaf or
> > >    leaf-list node in the data tree. The value space of the leafref
> > >    node is determined by the value space of the schema tree node
> > 
> > The term "value space of a schema tree node" is not defined.
> 
> OK. So we say 'the value space of the type of the schema tree node'.

Yes, this is better. But what if the schema tree node is made invalid due to a
failed "when" expression? Does it still apply?

>  
> > >    definining the referenced data tree node.
> > 
> > With require-instance=false there needn't be any referenced data tree node.
> 
> So we add "(irrespective whether the node exists or not).

If the data tree node doesn't exist, we cannot refer to the schema tree node
that defines it.

> 
> > > This likely is not perfect yet but perhaps we manage to make it
> > > perfect. ;-) What is not yet clearly described I think is what
> > > 'further restricted by corresponding instance nodes in the data tree'
> > > means (and that I think depends on require-instance). Perhaps add
> > 
> > Right. In this case it is not "further restricted" but rather there is a
> > discrete set of possible values.
> 
> A discrete set of possible values is a restriction so I do not
> understand your comment. So here is the next iteration:

If required-instance is true, there is no need to care about all this tricky
stuff with schema tree nodes and their types. In other words:

1. if required-instance = true, the permitted values are obtained from the data
tree.

2. if required-instance = false, the corresponding schema node has to be
determined, and its type defines the permitted values of the leafref node.

It is an exclusive-or, #1 is not an "optional further restriction".

Lada

> 
> NEW:
> 
>     The leafref built-in type is restricted to the value space of some
>     leaf or leaf-list node in the schema tree and optionally further
>     restricted by corresponding instance nodes in the data tree (see
>     Section 9.9.3).  The "path" substatement (Section 9.9.2) is used
>     to identify a leaf or leaf-list node in the data tree. The value
>     space of the leafref node is determined by the value space of the
>     type of the schema tree node definining the referenced data tree
>     node (irrespective whether the referenced data tree node exists or
>     not).
> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Fri Nov 23 05:37: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 ACB15127B92 for ; Fri, 23 Nov 2018 05:37:39 -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 F-CDgMyHMBb0 for ; Fri, 23 Nov 2018 05:37:37 -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 43C861277D2 for ; Fri, 23 Nov 2018 05:37:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3911; q=dns/txt; s=iport; t=1542980257; x=1544189857; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=qEoiUHBRkG0eA7eSuegQhMEAHBs7C/OyqGA1m3u+txs=; b=T8Wd9ArF+HLe+kBj+t+XaJvHrK3FQmVd+x6N+6fDDgBMd0Sv0FIUGhZH tZS3CYvoFPUMi0VKCFfpFL4/hfMT3xvDoG4PoUYYOYr3pCNUK9PJ0bb4X K3CSLQgpx6eiRD0c0gs9mezasrexMWN1teKd3DLh41lrgVqu6jZr+MIVu g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAAHAvhb/xbLJq1ZChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVMCAQEBAQELAYNZEoQgiHeNAC2XO4F6DYRsAoQ3Ngc?= =?us-ascii?q?NAQMBAQIBAQJtKIU9AQUjFVELGAICJgICVwYBDAgBAYMdggKmf4EvhUCEWYE?= =?us-ascii?q?LixWBQD+BOIFtUC6EU4MvglcCiRmGQ4ECjyQJkSkGGIlhhyeCeI5XhmGBTQ0?= =?us-ascii?q?kgVUzGggbFTuCbZBZPwONWAEB?=
X-IronPort-AV: E=Sophos;i="5.56,270,1539648000";  d="scan'208";a="8306236"
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; 23 Nov 2018 13:37: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-4.cisco.com (8.15.2/8.15.2) with ESMTP id wANDbKYS002476; Fri, 23 Nov 2018 13:37:20 GMT
To: Ladislav Lhotka , Juergen Schoenwaelder , netmod@ietf.org
References: <20181122163046.bkzck2bmbrf3fzm7@anna.jacobs.jacobs-university.de> <87tvk85et8.fsf@nic.cz> <20181123093813.gpxrtanbxgadpwih@anna.jacobs.jacobs-university.de> <20181123.110548.845126088727972359.mbj@tail-f.com> <20181123113341.br77pxmfhcwn6yck@anna.jacobs.jacobs-university.de>  <20181123123907.4wuuojmoikb7fegr@anna.jacobs.jacobs-university.de> <3c8272ada8f28ed41c0d7fc447fdded62f42bf13.camel@nic.cz>
From: Robert Wilton 
Message-ID: <0467b647-1b3b-6b79-e568-8cb9526d1af3@cisco.com>
Date: Fri, 23 Nov 2018 13:37: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: <3c8272ada8f28ed41c0d7fc447fdded62f42bf13.camel@nic.cz>
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] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 13:37:40 -0000

On 23/11/2018 13:29, Ladislav Lhotka wrote:
> On Fri, 2018-11-23 at 13:39 +0100, Juergen Schoenwaelder wrote:
>> On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
>>>> Here is an attempt to rewrite things in a way according to how I
>>>> understand things works. It should be possible to describe what we
>>>> mean. If we can't do that, we have a bigger problem. (I have changed
>>>> only the last two sentences.)
>>>>
>>>> OLD
>>>>
>>>>     The leafref built-in type is restricted to the value space of some
>>>>     leaf or leaf-list node in the schema tree and optionally further
>>>>     restricted by corresponding instance nodes in the data tree.  The
>>>>     "path" substatement (Section 9.9.2) is used to identify the referred
>>>>     leaf or leaf-list node in the schema tree.  The value space of the
>>>>     referring node is the value space of the referred node.
>>>>
>>>> NEW
>>>>
>>>>     The leafref built-in type is restricted to the value space of some
>>>>     leaf or leaf-list node in the schema tree and optionally further
>>>>     restricted by corresponding instance nodes in the data tree.  The
>>>>     "path" substatement (Section 9.9.2) is used to identify a leaf or
>>>>     leaf-list node in the data tree. The value space of the leafref
>>>>     node is determined by the value space of the schema tree node
>>> The term "value space of a schema tree node" is not defined.
>> OK. So we say 'the value space of the type of the schema tree node'.
> Yes, this is better. But what if the schema tree node is made invalid due to a
> failed "when" expression? Does it still apply?

I might be being picky, but it isn't absolutely clear from the text 
which node "schema tree node" refers to.

Hence I wonder whether it might be better to say "...identify the 
referenced leaf or leaflist ..." and "value space of the referenced 
schema tree node".

Thanks,
Rob


>
>>   
>>>>     definining the referenced data tree node.
>>> With require-instance=false there needn't be any referenced data tree node.
>> So we add "(irrespective whether the node exists or not).
> If the data tree node doesn't exist, we cannot refer to the schema tree node
> that defines it.
>
>>>> This likely is not perfect yet but perhaps we manage to make it
>>>> perfect. ;-) What is not yet clearly described I think is what
>>>> 'further restricted by corresponding instance nodes in the data tree'
>>>> means (and that I think depends on require-instance). Perhaps add
>>> Right. In this case it is not "further restricted" but rather there is a
>>> discrete set of possible values.
>> A discrete set of possible values is a restriction so I do not
>> understand your comment. So here is the next iteration:
> If required-instance is true, there is no need to care about all this tricky
> stuff with schema tree nodes and their types. In other words:
>
> 1. if required-instance = true, the permitted values are obtained from the data
> tree.
>
> 2. if required-instance = false, the corresponding schema node has to be
> determined, and its type defines the permitted values of the leafref node.
>
> It is an exclusive-or, #1 is not an "optional further restriction".
>
> Lada
>
>> NEW:
>>
>>      The leafref built-in type is restricted to the value space of some
>>      leaf or leaf-list node in the schema tree and optionally further
>>      restricted by corresponding instance nodes in the data tree (see
>>      Section 9.9.3).  The "path" substatement (Section 9.9.2) is used
>>      to identify a leaf or leaf-list node in the data tree. The value
>>      space of the leafref node is determined by the value space of the
>>      type of the schema tree node definining the referenced data tree
>>      node (irrespective whether the referenced data tree node exists or
>>      not).
>>
>> /js
>>


From nobody Fri Nov 23 06:07:34 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70793130E00 for ; Fri, 23 Nov 2018 06:07:32 -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 t8ZsuSPzDsmn for ; Fri, 23 Nov 2018 06:07:29 -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 73A8F129AB8 for ; Fri, 23 Nov 2018 06:07:28 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 3F241642DE; Fri, 23 Nov 2018 15:07:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1542982046; bh=Ek6S5L1WOoYjZILSF0X6FCK/w9gvHkoLW4ycCdsHiTY=; h=From:To:Date; b=sU6K3FHtLu5vEchRvMGckOTm+wxYGDLmeUar5rqzL5l5OmUnhA/NbHOfx4CBxisC4 /9xqLXhFvnKiF0/3Ptp7SWHRFxegBV/iDzlvXUO+Rbx2D02H3jvxCvNTS2nbqUTS1d vOPuwG3w5ziCl2SveZtzsmWxzET1ZzFkK+sxz9AE=
Message-ID: 
From: Ladislav Lhotka 
To: tom petch , "netmod@ietf.org" 
Date: Fri, 23 Nov 2018 15:07:26 +0100
In-Reply-To: <019f01d48324$44356bc0$4001a8c0@gateway.2wire.net>
References: <033101d4818e$08689dc0$4001a8c0@gateway.2wire.net> <87wop6sk6k.fsf@nic.cz> <019f01d48324$44356bc0$4001a8c0@gateway.2wire.net>
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] Address Family versus Address Family
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 14:07:32 -0000

On Fri, 2018-11-23 at 12:03 +0000, tom petch wrote:
> ----- Original Message -----
> From: "Ladislav Lhotka" 
> Sent: Wednesday, November 21, 2018 12:13 PM
> 
> > tom petch  writes:
> > 
> > > I have always thought of Address Family as something that BGP
> created
> > > and that others have used.  In fact, I find that there is an IANA
> > > registry of Address Families which RFC8294 has turned into a YANG
> > > module, but one using enumeration and not identity, which would seem
> to
> > > limit its utility.
> > 
> > In draft-lhotka-dnsop-iana-class-type-yang-00 we also use enumerations
> > representing DNS classes and resource records types. However, in
> > addition to the enumeration type that reflects the corresponding IANA
> > registries, we also added a union type that allows for using either
> the
> > mnemonic name or assigned number:
> > 
> > typedef rr-type {
> >   type union {
> >     type uint16;
> >     type rr-type-name;
> >   }
> > }
> > 
> > (and similarly for DNS classes). The numeric value corresponding to
> each
> > mnemonic name is given by the "value" statement inside each enum.
> > 
> > Actually, this approach was suggested by RFC 3597 that introduced the
> > general possibility of representing DNS classes and RR types
> > numerically. For example, RR type "AAAA" can be equivalently
> represented
> > as "TYPE28".
> > 
> > Perhaps this approach could be used for address families as well. In
> > fact, the use of identities also has its share of problems.
> 
> Lada
> 
> As you say, both enumeration and identity have their issues and there is
> just such a definition taking place now.
> 
> The softwires WG are creating an IANA-maintained YANG module for the
> existing tunnel type IANA registry, such that when a new tunnel type is
> registered, then entries will be added to the existing tunnel type MIB
> and to the (new) YANG module.
> 
> The YANG module is purely identity, based on ift:tunnel.
> 
> Should they be being advised to take a more sophisticated approach?

I am not sure that the approach with enumeration + union types can be classified
as more sophisticated. It is true though that it helps in the two main cases
where the enumeration by itself may be limiting:

- the NETCONF/RESTCONF server uses an old revision of the registry-based YANG
module but the device already supports a new revision of the registry

- experimental entries that are not in the registry

In both cases the missing type can be referred to using a number.

I would say that a module that is designed as a 1:1 mapping of an IANA registry
could generally use this approach.

Identities would be clearly better if they are defined in a truly distributed
manner. In your case, a YANG module that defines configuration and state data
for a particular tunnel type would also define the identity for that type. The
advantage of this approach is that a "type" parameter is restricted to only
those values that the server really implements.

Lada

> 
> Tom Petch
> 
> 
> > Lada
> > 
> > > Indeed, while the lsr WG uses that module, I2RS does not with
> > >  draft-ietf-i2rs-rib-data-model
> > > defining
> > >    identity address-family {description  "Base identity from which
> all
> > > RIB      address families are derived.";  }
> > > 
> > > identity - good; RYO definition - um.
> > > 
> > > BGP also goes its own way with
> > >   identity AFI_SAFI_TYPE { description
> > >          "Base identity type for AFI,SAFI tuples for BGP-4";
> > >        reference "RFC4760 - multi-protocol extensions for BGP-4";  }
> > > 
> > > And then there is RFC8349 with
> > >   identity address-family {
> > >     description  "Base identity from which identities describing
> address
> > >           families are derived.";      }
> > > and which defines ipv4 and ipv6, and which ties the concept firmly
> to a
> > > RIB in a 1:1 correspondence.
> > > 
> > > When I raised this on the rtgwg list, the response was that the
> concept
> > > of an address family is particular to a protocol, so there is no
> reason
> > > for ospf and BGP to share anything, which is how it seems.
> > > 
> > > So, is there any reason for anyone to use the definition in RFC8349?
> or
> > > the IANA module?
> > > 
> > > Tom Petch
> > > 
> > > 
> > > _______________________________________________
> > > 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 Nov 23 06:09: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 2D976130E00 for ; Fri, 23 Nov 2018 06:09:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDiczTkrUsYe for ; Fri, 23 Nov 2018 06:09:25 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 081C0130E2F for ; Fri, 23 Nov 2018 06:09:25 -0800 (PST)
Received: from localhost (h-39-108.A165.priv.bahnhof.se [213.136.39.108]) by mail.tail-f.com (Postfix) with ESMTPSA id 16A861AE0187; Fri, 23 Nov 2018 15:09:24 +0100 (CET)
Date: Fri, 23 Nov 2018 15:09:23 +0100 (CET)
Message-Id: <20181123.150923.932933854491492133.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <3c8272ada8f28ed41c0d7fc447fdded62f42bf13.camel@nic.cz>
References:  <20181123123907.4wuuojmoikb7fegr@anna.jacobs.jacobs-university.de> <3c8272ada8f28ed41c0d7fc447fdded62f42bf13.camel@nic.cz>
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] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 14:09:28 -0000

Ladislav Lhotka  wrote:
> On Fri, 2018-11-23 at 13:39 +0100, Juergen Schoenwaelder wrote:
> > On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
> > > > Here is an attempt to rewrite things in a way according to how I
> > > > understand things works. It should be possible to describe what we
> > > > mean. If we can't do that, we have a bigger problem. (I have changed
> > > > only the last two sentences.)
> > > > 
> > > > OLD
> > > > 
> > > >    The leafref built-in type is restricted to the value space of some
> > > >    leaf or leaf-list node in the schema tree and optionally further
> > > >    restricted by corresponding instance nodes in the data tree.  The
> > > >    "path" substatement (Section 9.9.2) is used to identify the referred
> > > >    leaf or leaf-list node in the schema tree.  The value space of the
> > > >    referring node is the value space of the referred node.
> > > > 
> > > > NEW
> > > > 
> > > >    The leafref built-in type is restricted to the value space of some
> > > >    leaf or leaf-list node in the schema tree and optionally further
> > > >    restricted by corresponding instance nodes in the data tree.  The
> > > >    "path" substatement (Section 9.9.2) is used to identify a leaf or
> > > >    leaf-list node in the data tree. The value space of the leafref
> > > >    node is determined by the value space of the schema tree node
> > > 
> > > The term "value space of a schema tree node" is not defined.
> > 
> > OK. So we say 'the value space of the type of the schema tree node'.
> 
> Yes, this is better. But what if the schema tree node is made invalid due to a
> failed "when" expression? Does it still apply?

Yes.  I'm sure the text around "when" can be improved, but the idea is
that if the when expression is false, the schema node becomes
"invalid"; but it still exists.

> > > >    definining the referenced data tree node.
> > > 
> > > With require-instance=false there needn't be any referenced data tree node.
> > 
> > So we add "(irrespective whether the node exists or not).
> 
> If the data tree node doesn't exist, we cannot refer to the schema tree node
> that defines it.

It's pretty clear what the intention is, right?  So what are the right
words to explain it?


> > > > This likely is not perfect yet but perhaps we manage to make it
> > > > perfect. ;-) What is not yet clearly described I think is what
> > > > 'further restricted by corresponding instance nodes in the data tree'
> > > > means (and that I think depends on require-instance). Perhaps add
> > > 
> > > Right. In this case it is not "further restricted" but rather there is a
> > > discrete set of possible values.
> > 
> > A discrete set of possible values is a restriction so I do not
> > understand your comment. So here is the next iteration:
> 
> If required-instance is true, there is no need to care about all this tricky
> stuff with schema tree nodes and their types. In other words:
> 
> 1. if required-instance = true, the permitted values are obtained from the data
> tree.

Not true in the candidate.  See also the mail thread you quoted.


/martin


> 2. if required-instance = false, the corresponding schema node has to be
> determined, and its type defines the permitted values of the leafref node.
> 
> It is an exclusive-or, #1 is not an "optional further restriction".
> 
> Lada
> 
> > 
> > NEW:
> > 
> >     The leafref built-in type is restricted to the value space of some
> >     leaf or leaf-list node in the schema tree and optionally further
> >     restricted by corresponding instance nodes in the data tree (see
> >     Section 9.9.3).  The "path" substatement (Section 9.9.2) is used
> >     to identify a leaf or leaf-list node in the data tree. The value
> >     space of the leafref node is determined by the value space of the
> >     type of the schema tree node definining the referenced data tree
> >     node (irrespective whether the referenced data tree node exists or
> >     not).
> > 
> > /js
> > 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Fri Nov 23 06:33: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 7F226130E09 for ; Fri, 23 Nov 2018 06:33:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.782
X-Spam-Level: 
X-Spam-Status: No, score=-4.782 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=I+TqgmjB; dkim=pass (1024-bit key) header.d=ericsson.com header.b=cH654cxw
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXx2V8NYrl6H for ; Fri, 23 Nov 2018 06:33:41 -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 B0D50130DFF for ; Fri, 23 Nov 2018 06:33:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1542983618; x=1545575618; 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=5IR4QWaf/ICv2xAC8p8KcpAIt74Qx1ulemMoHgAIl+0=; b=I+TqgmjBTrCKvucEsBlACQoFi2nj8mYcfl7ZFp/cqmjCk7nH0k4OqUmA1cWfDMpB kI0JZLCzSRvgApRcn9O/tRg23OxsJspN+H0kOayscOEF+JYuqPgkGKGrUTpV8Fpz VeIaXg080NrfwcXn+iCfCvKRZYWInQI+GWLwTx69wIc=;
X-AuditID: c1b4fb2d-f49ff70000007af1-0e-5bf80fc2c9a7
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1D.82.31473.2CF08FB5; Fri, 23 Nov 2018 15:33:38 +0100 (CET)
Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 23 Nov 2018 15:33:37 +0100
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 23 Nov 2018 15:33:37 +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=VBB1sMipe5hP8woJSq4Iplrox9RcULoLnfHOOcu1ZTc=; b=cH654cxwTnYJNfC2HVMijyv/zgynPP+q6SG0Ldxbgx4Bw4uBYTKFoX7SZB7UZQCowNfTEREP8lqcbstaPnyz03Vel/773vl2TMoTeqE4K5ovzwjpav/bOGvkL+b+zBtWfl0LizMSRdFCK3krxc29CgYNC5wkPd9+yXOh0DqQq5A=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2173.eurprd07.prod.outlook.com (10.169.137.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.12; Fri, 23 Nov 2018 14:33:36 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::70d1:cf80:392b:814b]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::70d1:cf80:392b:814b%4]) with mapi id 15.20.1382.007; Fri, 23 Nov 2018 14:33:36 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: "netmod@ietf.org" 
Thread-Topic: How to specify the target modules for YANG instance data [was: Re: [netmod] validity of instance-data]
Thread-Index: AQHUgzmEPXqfl/f2XUmUBRzHbM8DUw==
Date: Fri, 23 Nov 2018 14:33:36 +0000
Message-ID: 
References: <87sh0eil1b.fsf@nic.cz>
In-Reply-To: <87sh0eil1b.fsf@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [129.192.74.5]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
x-clientproxiedby: HE1PR09CA0071.eurprd09.prod.outlook.com (2603:10a6:7:3d::15) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2173; 6:t33gI5yS7hZK77KFs7nDkDh3o4CZFo7MDYNcCPepUswTsxuSGEfSr53Pvb1Pct1XZZtvMlqPqbxzlbcf4gAoyENaTd7bQhYMjtI3zIXOMcqOjoTIwZ/+6i7T6W5sUuIXVi9+YTMiCibfXGS890182nyuOD86KXraEZo2p5xbh+nTR3K7FRV+b6MM+Dkskl2sKsyE2kazeyHAnXaY0QkVX5h8mx5AoTXXbQjc55XbZ+T9axIPm92JqzZ8uP4besRh1QZlltPSabuBVfkS8emGg3pUa3j3SN96XXrtO/3ILDdcKckfBxSWweQFoludRFQ96Ex8fMA3fc3bvD5no0wUfiotVar0CsOwlA+fv8fgJ/XmFfRkiEOHQKz0bGpkOV9SjaxyMc7HyVlfRzA7GEVZhemjD0jlJUC/H5V6Qy38ADBNqB1Kh74T3OJSwhiCmFmtwkuNqxgMhnptleorNbLeiw==; 5:MzdQ38Jha92NjAyogI3DDGjudQuYa8mBRbjI1/hnDBUnhm6g47C+cfGWn0O9Zxga1NIhzKBLBToKoU3DckgUiz/vu7zZ5NDKHthv7EPvKI8wpXEpUpvw8cNXzFHQI4Tvmy/Alr0wEkethKEyFF3kIee8318guP+0IZZwIsMJZW0=; 7:HDTJleHDk4vdI8vVkLvt7dDTSW7zhUD8W/DR3ln8wr076VEHyIVoVMM2tBKcakMNv5+3JF/x2USPapSQHz5RmS/PuDdwYlffvc+BjmZ3fYq2gkaHA7FqIA2G2pDSapLNptCSQ/7n8dbFsb+ej43qWw==
x-ms-office365-filtering-correlation-id: 93205e75-4205-4dea-2ffd-08d65150a695
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2173; 
x-ms-traffictypediagnostic: VI1PR0701MB2173:
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)(3002001)(3231442)(944501410)(4983020)(52105112)(93006095)(93001095)(10201501046)(148016)(149066)(150057)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2173; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2173; 
x-forefront-prvs: 086597191B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(396003)(376002)(39860400002)(366004)(199004)(189003)(252514010)(31686004)(64126003)(8676002)(106356001)(65806001)(256004)(476003)(478600001)(3846002)(6116002)(85202003)(2501003)(105586002)(2616005)(65826007)(66066001)(5660300001)(26005)(102836004)(316002)(386003)(65956001)(7736002)(97736004)(186003)(6506007)(3260700006)(76176011)(2900100001)(1730700003)(8936002)(81156014)(81166006)(85182001)(52116002)(6512007)(58126008)(486006)(71190400001)(71200400001)(6436002)(99286004)(86362001)(11346002)(68736007)(36756003)(2906002)(446003)(6486002)(5640700003)(53936002)(25786009)(99936001)(305945005)(6916009)(2351001)(14454004)(31696002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2173; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: bttuTo98KvOdQxj6TTr/+ewEMM8mFAbC5yhNKsg6AZ56xEPUxVDVyVS7Fmzv+kBhKdtpB7XXuMvxOGtTgeQnAK2VnWGWHhreoCHg8Xtvg+nHrhFXNqdG8L2XsANU2DRrMaYOwkpyJ7WQYyCHXSLzd3kGpLhwo/fFQu1K01eEPwyh65ZUKLlXJGs99I2DiGPXe887YFUKqL7DHhnyut01ZcMtY8N6r5685iATv2tME7aWDwrs9Fy9COPIs1hH2E8uvLJholO6sTEhPLli+NPSgBtEd6xT3eYsvJ0upgebNUh5Ryw0MjNpBpfun1timZF2r1nkxZlirIMolA8iOH9YJ3J+9jQxlgDGdDc6Ne2zYFo=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040302090903030208050208"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 93205e75-4205-4dea-2ffd-08d65150a695
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2018 14:33:36.5772 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2173
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSaUhUURTHuW/ePJ+jg7fR0ZNR6GgomZNrCdkGFlYIfkuUrFGfS+lo88zU CDWIXDLUzO2DS40WGrlbwpQoaWWlToFlruOGJSoh7mQ5cxXq2++c8///OedyWYFEK7Rmo5Tx nEqpiJYxIro44MUN5w6z1SCXwkpHrzJtmvAk8lWr1yh/FCjyDuOioxI41aHjl0WRr3P7jeJy /BPn8teZVKT1zUTGLGAPGJtbMMpEIlaC3yBYXMijSbGMoGlNi0ihpqD/XSWjL2icI4DypkWK TAopSG8hEwmeRjAxtkHpkxnsA3fn2wxsgR2guLWW0bM5vgYjmxlC0k+AgZ/d2xo5lDcWGDQ0 3g9Fvdm0nsX4BHQ9bTHoJdgO1mZatzQsa4zt4VFPoL6NsCWsdD8zxAiwFXyfLKPIcRag035g CEvhx8SmkLANzD/oNPSl+CIUqu8ZzgRcgGDqYxEiocGgGUnfNh+ET18nEeG98Lksa5u/MfBn 2oywH+Q2NtMkaAiBrrSX2jFr0uqNCMeC5sn9bd4H1dk6Oge5lPyzeMmWX4AzEMyNvGVKDA+w C94XT9JEdBhKG3UCwk5QVTEr+N+s56NQtN7OELaF/CydEWFPmO38hQi7Q9Xz30w5ElUjKc/x fEyEm7ucU0WF8nysUq7k4hvQ1udqb9pwfolqZk91IMwimal4ULQaJBEqEvikmA5kv5UzXlfT h6xpZaySk1mIb9uuBEnEYYqkZE4Ve0l1PZrjO9AelpZZieXVmkAJjlDEc1c5Lo5T7Uwp1tg6 FTl5mtj4Wr5auuNxzK8O7NxmHVKn0jQF53Y31hxpqw2xT6yJjIuvH0/sFkqHh8difLJdp73P ng1PSZG3PLyiDsZDDRMBkReWw0POfFGf15o3r+fZdPU1SZuVa4WmMzdvKUbTH9sOJsf0FVWM KidDAx0HvHqWvNNPm1RmTHgHU+1dMpqPVLgeEKh4xV+x+brIZAMAAA==
Archived-At: 
Subject: [netmod] How to specify the target modules for YANG instance data [was: Re: validity of instance-data]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 14:33:44 -0000

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

Hello Lada,

I like your idea idea, thanks. Adding some more details :

 =C2=A0=C2=A0=C2=A0 Metadata MUST include:

 =C2=A0=C2=A0 o=C2=A0 Name of the instance data set

 =C2=A0=C2=A0 o=C2=A0 target: Specifies the method and details by which t=
he target YANG
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 modules, supported features and deviation=
s are specified.=C2=A0 The
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 specified target only indicates the set o=
f modules that were used
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to define this YANG instance data set.=C2=
=A0 Whether the instance data
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 set is usable for a different real-life t=
arget YANG module set
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 depends on the compatibility between the =
specified target and the
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 real-life target YANG module set (conside=
ring revisios, features,
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 devaiations)

 =C2=A0=C2=A0 Metadata SHOULD include:

 =C2=A0=C2=A0 o=C2=A0 Revision date of the instance data set

 =C2=A0=C2=A0 o=C2=A0 Description of the instance data set.=C2=A0 The des=
cription SHOULD
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 contain information whether and how the d=
ata can change during the
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 lifetime of the YANG server.

 =C2=A0=C2=A0 Target SHALL use one of the following methods:

 =C2=A0=C2=A0 IN-LINE Method.=C2=A0 Target should bet set to:

 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 'inline:ietf-yang-library@' revision-date=
 '.yang'

 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 E.g. inline:ietf-yang-library@2016-06-21.=
yang

 =C2=A0=C2=A0 The revision date is mandatory, it specifies the revision o=
f the
 =C2=A0=C2=A0 ietf-yang-library used by the in-line method.=C2=A0 When us=
ing the in-line
 =C2=A0=C2=A0 method the first group of data inside the "anydata data" el=
ement MUST
 =C2=A0=C2=A0 be the instance data targeted at the ietf-yang-library.=C2=A0=
 This data
 =C2=A0=C2=A0 SHALL specify the target YANG modules, revisions, supported=
 features
 =C2=A0=C2=A0 and deviations for this and all the other target YANG modul=
es.

 =C2=A0=C2=A0 URI Method.=C2=A0 Target MUST bet set to a URI that referen=
ces another
 =C2=A0=C2=A0 YANG instance data file.=C2=A0 The first instance data file=
 will use the
 =C2=A0=C2=A0 same set of target YANG modules, revisions, supported featu=
res and
 =C2=A0=C2=A0 deviations as this other referenced YANG instance data file=
=2E=C2=A0 The
 =C2=A0=C2=A0 referenced YANG instance data file might use the in-line me=
thod or
 =C2=A0=C2=A0 might use the URI method to reference further instance data=
 file(s).
 =C2=A0=C2=A0 However at the end of this reference chain there MUST be an=
 instance
 =C2=A0=C2=A0 data file using the in-line method.=C2=A0 This last instanc=
e data file
 =C2=A0=C2=A0 MUST carry instance data for the ietf-yang-library, but oft=
en will
 =C2=A0=C2=A0 carry no other instance data.=C2=A0 If a referenced instanc=
e data file is
 =C2=A0=C2=A0 not available the revision data, supported features and dev=
aitions
 =C2=A0=C2=A0 for the target YANG modules are unknown.

 =C2=A0=C2=A0 TODO: extend example with target.

regards Balazs

On 2018. 11. 06. 10:59, Ladislav Lhotka wrote:
> Hi,
>
> the second bullet of Appendix A in
> draft-ietf-netmod-yang-instance-file-format-00 talks about
> validity. This would make sense if we have a complete schema - YANG
> modules, even with revisions, is not enough. The schema can be provided=

> off-line but it can also be specified as a part of the metadata.
>
> I would suggest to extend the metadata with the following two optional
> methods of specifying the schema:
>
> 1. the schema can be specified in-line, for example in the format of th=
e
>     new YANG library, i.e. as a list of module-sets
>
> 2. A URL specifying the location of the schema.
>
> Lada
>
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com



--------------ms040302090903030208050208
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTEyMzE0MzMzMlow
LwYJKoZIhvcNAQkEMSIEIOhU0ny72gWl0viWM9qV+/em5gbL2sX2Snl6laB+2Qb9MGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBACNRQftYqXXRkgjOx5f+aGQHIWjU5bxwh6G3iSFj5fRWbXZ7
UEYbO2k6rq8v6YPVHxyUzqJ71wv1qV/I2VOK/QA+tkJs1ScGRxkJk5Ru5PJzoIOXGEziz0H0
zRE2to90ivQJWTak0LHN594EGIvjXEKRJSPxZapEqHTgW1YAcPi05z9hNN2QFfKA5qncSL2B
vhjGGsI5ZilxxKN8AMfcM5wx3MZaFD687icKI/pcjiGSzP90vopT72bXr3e3/AmT/pgA7HB6
wEw/Po8q4ApRFl+T2uW0noAQ7PUvO7IjP1F9p56JKO8fyl8btAibrXDYGNAt8Q2q2OwVUT2p
Jt6BXsYAAAAAAAA=

--------------ms040302090903030208050208--


From nobody Fri Nov 23 06:40: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 558E0130E09 for ; Fri, 23 Nov 2018 06:40:50 -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 40AjkN4lacyG for ; Fri, 23 Nov 2018 06:40:48 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88EFA130DCE for ; Fri, 23 Nov 2018 06:40:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2120; q=dns/txt; s=iport; t=1542984048; x=1544193648; h=subject:references:to:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=IZYIJMmurxWTSgRx284iLfgOu9in3QlHxXz2WaEPEYY=; b=V1oTkkQxHImRT84hfry0qIClGa43kvjPir5yj+BeG7IbXWis2g9pQMCK ZbiKe10TG0PBW14piDaO41cMGbz1Rb1uPcR8Sb+gHSl0ClN9H+2bkdaW6 4zS5uxqQjgXZxwqCM8kgLaY7wgbq1coM08F3xJOLUW9gCgz3+5IKHwRCC w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAADcEPhb/5JdJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBggNmA38ng3mIGIwAgWAtlzuBeg0lgVK?= =?us-ascii?q?CdQKEGCI0CQ0BAwEBAgEBAm0cAQuFPAEGI1QSHAMBAgMCJgICTQIIBg0GAgE?= =?us-ascii?q?BF4MGAYIBD6cEgS+EMQIOQIUYgQuKfheBQD+BOIJrgxsBAQIBARaES4JXAoh?= =?us-ascii?q?/UIVKQzSPcgmGfIotBhiBWU2EPoJ9hyeJbYNWim2BRjiBVU0jFRqDDQmCR4h?= =?us-ascii?q?MhVwhAzABjScBAQ?=
X-IronPort-AV: E=Sophos;i="5.56,270,1539648000"; d="scan'208";a="484120483"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Nov 2018 14:40:47 +0000
Received: from [192.168.10.244] (rtp-jclarke-nitro4.cisco.com [10.118.87.85]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTP id wANEek2T009970 for ; Fri, 23 Nov 2018 14:40:47 GMT
References: <154298376084.9586.689454777090893394.idtracker@ietfa.amsl.com>
To: "netmod@ietf.org" 
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDo1cJ0RBADSZSmbmzdRr1CoRWWKmAyu0eaQimaLV1TsZEML/ksLyg6faXrKIA/MWc7M w4FmKkDjaZdFzobzabnKp2QwVadLqi1gYY2WsApKC0rSoqsPx5E847AmwNWXgjXiXORXmnZL mf5PZ2ECOEJC27sji5Nrh9GSw7OPp6c+EE20gMNVrwCgu3iK5vyGQfy0/wX/jcIvP0nHznUD /RvijiKomyaf6F5pibmouFNeuCDHc8lwx2giA/MCZl/nSkI2/UX27sULGNgvKNkVPu/AukXu zW3fIthsJgjQZUoi/BTe9kUP+RL3+RALXXuLv7b3xGRHJ8A1Rpy9H43fkjHZ945YNPrUvJlG LP5PNGBD1xC21X3EGAyywVynDskcA/4qgbJFkVzmPjFJUjq+RW1zw3UIb3bbkskl/wk5qd+M w2EhiSPTbEhJQAQUvqSGFWEGp2ANic7iYLdPXV/O6I1/guRRaY0eK77YkkCjz1snaKYnGSeI GHGwmHb6D+ZHzTqZqr6IssgEIUHjXfgOUTARQbL15nJTVRzDGUiT/65R3c0eSm9lIENsYXJr ZSA8amNsYXJrZUBjaXNjby5jb20+wl8EExECABcFAjyDqGQFCwcKAwQDFQMCAxYCAQIXgAAS CRDN7TXCWm4C3wdlR1BHAAEB5KkAn0kBda/9+uF6RfnDSFS7RExUU9DqAJ4knRckYiSASteC K03QVtEiXblL287ATQQ6NXCeEAQAhIURlK17jmIMdMIuScFU6xK+jkKgVVFrjlRH5vLV2spp jH/uQ57MMGuOcs7PckXCnPjBV8Tm32Tuw+fCyrbc2gt0ouiT/5WWj0EMeAfWew1zBXX2okGf LqS6gucVDS6tcEFN6PmJEmX+tWDcmiqx/xXiSfMVYiLMdlK+YDkMDDsAAwUD/3BWOyfdnBGH Kv28zx+5wq/2vhYnUYCAdVD2ZWCJizQTMbkcxEIKAwtAj6yqKq9ah82nt4VHl5ZejVe47jvR 2nXwJ5VQ9eITuTjTLDw+3qr9lN077VZ32hyb5ULJcW756j9Z3YB2FTANw6KHgChaSVVx9kYJ FlAggraU7mi39/wvwk4EGBECAAYFAjo1cJ4AEgkQze01wlpuAt8HZUdQRwABAQbdAJ9R8SzU Mluu9r93BMv6fAW9j6qTZgCfYcEAqOMJv+3Z+YxLiDtWcCY4Sfo=
Organization: Cisco
X-Forwarded-Message-Id: <154298376084.9586.689454777090893394.idtracker@ietfa.amsl.com>
Message-ID: 
Date: Fri, 23 Nov 2018 09:40:46 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <154298376084.9586.689454777090893394.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Outbound-SMTP-Client: 10.118.87.85, rtp-jclarke-nitro4.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: 
Subject: [netmod] Fwd: New Version Notification for draft-verdt-netmod-yang-versioning-reqs-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 14:40:50 -0000

A new revision of the YANG version requirements draft has been posted
based on feedback from IETF 103.  This revision includes the following:

* Revise requirement 1.4 text to remove mention of software release
versioning

* Simplify the requirement 3.2 text to avoid bias to a particular solution

* Remove the now-redundant requirement 4.4

* Acknowledge the inspiration around versioning from the OpenConfig group

With these changes, the design team is asking the chairs to request WG
adoption for this document.

Joe


-------- Forwarded Message --------
Subject: New Version Notification for
draft-verdt-netmod-yang-versioning-reqs-02.txt
Date: Fri, 23 Nov 2018 06:36:00 -0800
From: internet-drafts@ietf.org
To: Joe Clarke 


A new version of I-D, draft-verdt-netmod-yang-versioning-reqs-02.txt
has been successfully submitted by Joe Clarke and posted to the
IETF repository.

Name:		draft-verdt-netmod-yang-versioning-reqs
Revision:	02
Title:		YANG Module Versioning Requirements
Document date:	2018-11-23
Group:		Individual Submission
Pages:		12
URL:
https://www.ietf.org/internet-drafts/draft-verdt-netmod-yang-versioning-reqs-02.txt
Status:
https://datatracker.ietf.org/doc/draft-verdt-netmod-yang-versioning-reqs/
Htmlized:
https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02
Htmlized:
https://datatracker.ietf.org/doc/html/draft-verdt-netmod-yang-versioning-reqs
Diff:
https://www.ietf.org/rfcdiff?url2=draft-verdt-netmod-yang-versioning-reqs-02

Abstract:
   This document describes the problems that can arise because of the
   YANG language module update rules, that require all updates to YANG
   module preserve strict backwards compatibility.  It also defines the
   requirements on any solution designed to solve the stated problems.
   This document does not consider possible solutions, nor endorse any
   particular solution.




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

The IETF Secretariat


From nobody Fri Nov 23 07:24: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 08BE1130E34 for ; Fri, 23 Nov 2018 07:24: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 8V_EZ9VXr7Du for ; Fri, 23 Nov 2018 07:24:49 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E19F130E30 for ; Fri, 23 Nov 2018 07:24:48 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id DB3C363801; Fri, 23 Nov 2018 16:23:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1542986601; bh=45S5ri9RXrkJU6hgwmzjuIXDmt9WGcF0wc7Zd0gSwYM=; h=From:To:Date; b=iAthGPO4zLbr1KZdLJfUwiIA6QzXVGMU/IkQdS5zZbCwBaoIoXMbWSShCVZibh8fD x03ehy1iwvTcoSWRroZGOF1TD765F/ku7z/zMQL1qA/KvZier9KRSIwrkGDVTkTSrB Sote/7cyp2eIkMD+EmyDEg+WOo5JCJIWboGmhvgU=
Message-ID: 
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org
Date: Fri, 23 Nov 2018 16:23:21 +0100
In-Reply-To: <20181123.150923.932933854491492133.mbj@tail-f.com>
References:  <20181123123907.4wuuojmoikb7fegr@anna.jacobs.jacobs-university.de> <3c8272ada8f28ed41c0d7fc447fdded62f42bf13.camel@nic.cz> <20181123.150923.932933854491492133.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 15:24:53 -0000

On Fri, 2018-11-23 at 15:09 +0100, Martin Bjorklund wrote:
> Ladislav Lhotka  wrote:
> > On Fri, 2018-11-23 at 13:39 +0100, Juergen Schoenwaelder wrote:
> > > On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
> > > > > Here is an attempt to rewrite things in a way according to how I
> > > > > understand things works. It should be possible to describe what we
> > > > > mean. If we can't do that, we have a bigger problem. (I have changed
> > > > > only the last two sentences.)
> > > > > 
> > > > > OLD
> > > > > 
> > > > >    The leafref built-in type is restricted to the value space of some
> > > > >    leaf or leaf-list node in the schema tree and optionally further
> > > > >    restricted by corresponding instance nodes in the data tree.  The
> > > > >    "path" substatement (Section 9.9.2) is used to identify the
> referred
> > > > >    leaf or leaf-list node in the schema tree.  The value space of the
> > > > >    referring node is the value space of the referred node.
> > > > > 
> > > > > NEW
> > > > > 
> > > > >    The leafref built-in type is restricted to the value space of some
> > > > >    leaf or leaf-list node in the schema tree and optionally further
> > > > >    restricted by corresponding instance nodes in the data tree.  The
> > > > >    "path" substatement (Section 9.9.2) is used to identify a leaf or
> > > > >    leaf-list node in the data tree. The value space of the leafref
> > > > >    node is determined by the value space of the schema tree node
> > > > 
> > > > The term "value space of a schema tree node" is not defined.
> > > 
> > > OK. So we say 'the value space of the type of the schema tree node'.
> > 
> > Yes, this is better. But what if the schema tree node is made invalid due to
> a
> > failed "when" expression? Does it still apply?
> 
> Yes.  I'm sure the text around "when" can be improved, but the idea is
> that if the when expression is false, the schema node becomes
> "invalid"; but it still exists.

But then no referred-to leaf instance can exist, so does the leafref make sense
at all?

And what about if-feature: can I have an instance of a leafref pointing to a
leaf that depends on a feature, and the feature is not active?

> 
> > > > >    definining the referenced data tree node.
> > > > 
> > > > With require-instance=false there needn't be any referenced data tree
> node.
> > > 
> > > So we add "(irrespective whether the node exists or not).
> > 
> > If the data tree node doesn't exist, we cannot refer to the schema tree node
> > that defines it.
> 
> It's pretty clear what the intention is, right?  So what are the right
> words to explain it?

The right words have to avoid mentioning any data tree nodes because there may
be none. It is necessary to explain how the schema tree is traversed based on
the path expression. This basically means:

- ".." = ascend to the closest ancestor data node
- skip all predicates
- if there is an intervening choice in the schema, determine the right case and
descend to it

> 
> 
> > > > > This likely is not perfect yet but perhaps we manage to make it
> > > > > perfect. ;-) What is not yet clearly described I think is what
> > > > > 'further restricted by corresponding instance nodes in the data tree'
> > > > > means (and that I think depends on require-instance). Perhaps add
> > > > 
> > > > Right. In this case it is not "further restricted" but rather there is a
> > > > discrete set of possible values.
> > > 
> > > A discrete set of possible values is a restriction so I do not
> > > understand your comment. So here is the next iteration:
> > 
> > If required-instance is true, there is no need to care about all this tricky
> > stuff with schema tree nodes and their types. In other words:
> > 
> > 1. if required-instance = true, the permitted values are obtained from the
> data
> > tree.
> 
> Not true in the candidate.  See also the mail thread you quoted.

Hmm, so you are saying that in candidate require-instance is ignored but the
leafref's value must still be inside the value space defined by #2? This is IMO
not clear at all.

Lada

> 
> 
> /martin
> 
> 
> > 2. if required-instance = false, the corresponding schema node has to be
> > determined, and its type defines the permitted values of the leafref node.
> > 
> > It is an exclusive-or, #1 is not an "optional further restriction".
> > 
> > Lada
> > 
> > > 
> > > NEW:
> > > 
> > >     The leafref built-in type is restricted to the value space of some
> > >     leaf or leaf-list node in the schema tree and optionally further
> > >     restricted by corresponding instance nodes in the data tree (see
> > >     Section 9.9.3).  The "path" substatement (Section 9.9.2) is used
> > >     to identify a leaf or leaf-list node in the data tree. The value
> > >     space of the leafref node is determined by the value space of the
> > >     type of the schema tree node definining the referenced data tree
> > >     node (irrespective whether the referenced data tree node exists or
> > >     not).
> > > 
> > > /js
> > > 
> > -- 
> > 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 Fri Nov 23 07:50: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 3D5C8130DFF for ; Fri, 23 Nov 2018 07:49:58 -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 gzrCs52c15JH for ; Fri, 23 Nov 2018 07:49:55 -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 7262E130DCE for ; Fri, 23 Nov 2018 07:49:55 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 18189BBC; Fri, 23 Nov 2018 16:49:54 +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 ywatUrq-cQXk; Fri, 23 Nov 2018 16:49:54 +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, 23 Nov 2018 16:49:54 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0280A2003C; Fri, 23 Nov 2018 16:49:54 +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 IiLhzfHzigHk; Fri, 23 Nov 2018 16:49:53 +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 639F720037; Fri, 23 Nov 2018 16:49:53 +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, 23 Nov 2018 16:49:52 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 8B65130044A951; Fri, 23 Nov 2018 16:49:51 +0100 (CET)
Date: Fri, 23 Nov 2018 16:49:51 +0100
From: Juergen Schoenwaelder 
To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel 
CC: Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" 
Message-ID: <20181123154951.anviss5nllq6gwrn@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel ,  Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" 
References: <87y3a6izap.fsf@nic.cz> <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de> <58740c15bf3277e04329546476f60c1d12516594.camel@nic.cz> <20181106.104157.239419955739949818.mbj@tail-f.com> <866ff105cf8fda7eadbdce5b344f4cd734fd99b8.camel@nic.cz> <1f4103c1-4953-3df4-d50d-aed1961fbc50@ericsson.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: <1f4103c1-4953-3df4-d50d-aed1961fbc50@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] Datastore leaf for yang instance data
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 15:49:58 -0000

On Fri, Nov 23, 2018 at 01:21:23PM +0000, Balzs Lengyel wrote:
>    BALAZS: "Instance data associated with a datastore" may mean many things,
>    that's why this relatively loose term is used. It may mean:
> 
>      * Data was read from that datastore
>      * Data is intended to be fed into that datastore
>      * Something else ???
> 
>    This can be useful if data is read from a datastore, but in a number of
>    cases it is not useful:
> 
>      * Preloading configuration data: datastore may be running or candidate.
>      * Preloading mixed config and state data: We do have state data that is
>        very stable and thus it is documented as instance data, and the
>        instance data file is actually used to feed the state data into the
>        SW. So datastore is: running, candidate + operational if NMDA is
>        supported or state datastore (whatever that is) if NMDA is not
>        supported
> 
>    regards Balazs
>

I do not buy this story. Your software needs to decide somehow what
instance data means. A config true leaf in candidate means something
different than the same config true leaf in running and this yet again
means something different than the same config true leaf in operational.

/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 Nov 23 07:59: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 4967F130E34 for ; Fri, 23 Nov 2018 07:59:28 -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 HpRsYPfDBYNp for ; Fri, 23 Nov 2018 07:59: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 22A94130DFF for ; Fri, 23 Nov 2018 07:59: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 AFDAFCFF; Fri, 23 Nov 2018 16:59:24 +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 YjGCShWUSX5O; Fri, 23 Nov 2018 16:59:24 +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, 23 Nov 2018 16:59:24 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A9EB2003D; Fri, 23 Nov 2018 16:59:24 +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 VZmnOaXRrwJp; Fri, 23 Nov 2018 16:59:24 +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 0898120037; Fri, 23 Nov 2018 16:59: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; Fri, 23 Nov 2018 16:59:23 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 639F630044AA5A; Fri, 23 Nov 2018 16:59:22 +0100 (CET)
Date: Fri, 23 Nov 2018 16:59:22 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
CC: 
Message-ID: <20181123155922.gk4cpaowsoc33mqb@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org
References: <20181122163046.bkzck2bmbrf3fzm7@anna.jacobs.jacobs-university.de> <87tvk85et8.fsf@nic.cz> <20181123093813.gpxrtanbxgadpwih@anna.jacobs.jacobs-university.de> <20181123.110548.845126088727972359.mbj@tail-f.com> <20181123113341.br77pxmfhcwn6yck@anna.jacobs.jacobs-university.de>  <20181123123907.4wuuojmoikb7fegr@anna.jacobs.jacobs-university.de> <3c8272ada8f28ed41c0d7fc447fdded62f42bf13.camel@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3c8272ada8f28ed41c0d7fc447fdded62f42bf13.camel@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] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 15:59:28 -0000

On Fri, Nov 23, 2018 at 02:29:18PM +0100, Ladislav Lhotka wrote:
> On Fri, 2018-11-23 at 13:39 +0100, Juergen Schoenwaelder wrote:
> > On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
> > > > Here is an attempt to rewrite things in a way according to how I
> > > > understand things works. It should be possible to describe what we
> > > > mean. If we can't do that, we have a bigger problem. (I have changed
> > > > only the last two sentences.)
> > > > 
> > > > OLD
> > > > 
> > > >    The leafref built-in type is restricted to the value space of some
> > > >    leaf or leaf-list node in the schema tree and optionally further
> > > >    restricted by corresponding instance nodes in the data tree.  The
> > > >    "path" substatement (Section 9.9.2) is used to identify the referred
> > > >    leaf or leaf-list node in the schema tree.  The value space of the
> > > >    referring node is the value space of the referred node.
> > > > 
> > > > NEW
> > > > 
> > > >    The leafref built-in type is restricted to the value space of some
> > > >    leaf or leaf-list node in the schema tree and optionally further
> > > >    restricted by corresponding instance nodes in the data tree.  The
> > > >    "path" substatement (Section 9.9.2) is used to identify a leaf or
> > > >    leaf-list node in the data tree. The value space of the leafref
> > > >    node is determined by the value space of the schema tree node
> > > 
> > > The term "value space of a schema tree node" is not defined.
> > 
> > OK. So we say 'the value space of the type of the schema tree node'.
> 
> Yes, this is better. But what if the schema tree node is made invalid due to a
> failed "when" expression? Does it still apply?

Why do you think it would not?

> > > >    definining the referenced data tree node.
> > > 
> > > With require-instance=false there needn't be any referenced data tree node.
> > 
> > So we add "(irrespective whether the node exists or not).
> 
> If the data tree node doesn't exist, we cannot refer to the schema tree node
> that defines it.

What is the problem? There is a path on the instance data tree and it
seems decidable what the matching path in the schema tree is. Can you
construct an example where this is not decidable?

> If required-instance is true, there is no need to care about all this tricky
> stuff with schema tree nodes and their types. In other words:
> 
> 1. if required-instance = true, the permitted values are obtained from the data
> tree.
> 
> 2. if required-instance = false, the corresponding schema node has to be
> determined, and its type defines the permitted values of the leafref node.
> 
> It is an exclusive-or, #1 is not an "optional further restriction".

Since the data node values must comply to the data type of the schema
node, it is a further restriction. Anyway, you are welcome to propose
better wording or convince us that this can't be implemented. If it is
implementable, we should be able to describe how things work.

/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 Nov 23 09:23: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 7E88312DD85 for ; Fri, 23 Nov 2018 09:23:17 -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 e3-MJfPkhTz2 for ; Fri, 23 Nov 2018 09:23:15 -0800 (PST)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF3BE12D84D for ; Fri, 23 Nov 2018 09:23:14 -0800 (PST)
Received: by mail-lj1-x22e.google.com with SMTP id u6-v6so11261077ljd.1 for ; Fri, 23 Nov 2018 09:23:14 -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=ngT9sg0eCM751eW79XZRlamtutRH8xZK8MY0bxt7NTU=; b=t3S7P39sEPLR+KT6bJK1PmnZ84U3+nYrV6nDOwAppne/sriEt6TTTQrYzo7VkHOk/y oc14MrgonewcpKJo5vrYwk+90mKgmVSX0MdDcNrU7ELCjgMInsEFwgmKfhbvTpn/BXRi VlHWGLQDi7WOA9ItESlFf9uljwJRuSCKlX2fG1SvziPJ6wG9kotnZWsyCaCYAvZwDxkt gFiBo9pYWnrJ8E1ZhIRy8VTMCPGAnjib9aW5VG1BVoRvH+tWojKBKA5DS1XSgP2Vy1ni UkFrBeouIxTaXKFdqMaGbnnvv0FiIwmYpH2eL2oJEGaoYnYVDnWQrfdtuCRro+D2fEul yKJA==
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=ngT9sg0eCM751eW79XZRlamtutRH8xZK8MY0bxt7NTU=; b=E5Iu7HcU+GUbedzs3apgLRUswNLoWvsVNgON/+TiO/JTMG75gFqH5dx8i+g+W5Xyvz SJ1Xq/tsxz3iVvpyMXAAri+Gzo45tUsvwi1KHDr4wwiGVNiVzsJy0nNDoY7QAJVx07hJ WTT6SHkn4875xzmecWXDvWXnnyJZ0ZOEuUZGxjYB/nYYw0Hms2LlBO8AUi0++/zfgiFF e+s/LfdwQC61vLlNGP7De5SCodZj7GnNRW63HdK4pkEkwIA2QDylyBF1HryY+uqg/beF CkkVbcrFslpMt0O31XCGAv+mT5YzDrUClQ1nF/0pFBG198JUkBj3jMSbXLuxarxXQ9bv lK2w==
X-Gm-Message-State: AA+aEWZumCecHo6lJ1m1Wn9tOHZ2f15KFseba9nT+alN/CpjDbEhKUE5 /3geKHi2wTJ2qBUmZB81CCE9f1f7V9r/RlDikd46Zw==
X-Google-Smtp-Source: AFSGD/X3toHS/AAM0iAFmxpwJW3JzSr1X8kStV/k3f5D5+4RSiKkR1DiHVfhCvtiixAhIrGNIqQOxsCJ7PlIn6awQqI=
X-Received: by 2002:a2e:841:: with SMTP id g1-v6mr11350569ljd.21.1542993792817;  Fri, 23 Nov 2018 09:23:12 -0800 (PST)
MIME-Version: 1.0
References: <20181122163046.bkzck2bmbrf3fzm7@anna.jacobs.jacobs-university.de> <87tvk85et8.fsf@nic.cz> <20181123093813.gpxrtanbxgadpwih@anna.jacobs.jacobs-university.de> <20181123.110548.845126088727972359.mbj@tail-f.com> <20181123113341.br77pxmfhcwn6yck@anna.jacobs.jacobs-university.de>  <20181123123907.4wuuojmoikb7fegr@anna.jacobs.jacobs-university.de> <3c8272ada8f28ed41c0d7fc447fdded62f42bf13.camel@nic.cz> <0467b647-1b3b-6b79-e568-8cb9526d1af3@cisco.com>
In-Reply-To: <0467b647-1b3b-6b79-e568-8cb9526d1af3@cisco.com>
From: Andy Bierman 
Date: Fri, 23 Nov 2018 09:23:01 -0800
Message-ID: 
To: Robert Wilton 
Cc: Ladislav Lhotka ,  Juergen Schoenwaelder , NetMod WG 
Content-Type: multipart/alternative; boundary="000000000000e979e5057b583cfb"
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 17:23:17 -0000

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

On Fri, Nov 23, 2018 at 5:37 AM Robert Wilton  wrote:

>
> On 23/11/2018 13:29, Ladislav Lhotka wrote:
> > On Fri, 2018-11-23 at 13:39 +0100, Juergen Schoenwaelder wrote:
> >> On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
> >>>> Here is an attempt to rewrite things in a way according to how I
> >>>> understand things works. It should be possible to describe what we
> >>>> mean. If we can't do that, we have a bigger problem. (I have changed
> >>>> only the last two sentences.)
> >>>>
> >>>> OLD
> >>>>
> >>>>     The leafref built-in type is restricted to the value space of some
> >>>>     leaf or leaf-list node in the schema tree and optionally further
> >>>>     restricted by corresponding instance nodes in the data tree.  The
> >>>>     "path" substatement (Section 9.9.2) is used to identify the
> referred
> >>>>     leaf or leaf-list node in the schema tree.  The value space of the
> >>>>     referring node is the value space of the referred node.
> >>>>
> >>>> NEW
> >>>>
> >>>>     The leafref built-in type is restricted to the value space of some
> >>>>     leaf or leaf-list node in the schema tree and optionally further
> >>>>     restricted by corresponding instance nodes in the data tree.  The
> >>>>     "path" substatement (Section 9.9.2) is used to identify a leaf or
> >>>>     leaf-list node in the data tree. The value space of the leafref
> >>>>     node is determined by the value space of the schema tree node
> >>> The term "value space of a schema tree node" is not defined.
> >> OK. So we say 'the value space of the type of the schema tree node'.
> > Yes, this is better. But what if the schema tree node is made invalid
> due to a
> > failed "when" expression? Does it still apply?
>
> I might be being picky, but it isn't absolutely clear from the text
> which node "schema tree node" refers to.
>
> Hence I wonder whether it might be better to say "...identify the
> referenced leaf or leaflist ..." and "value space of the referenced
> schema tree node".
>
>

IMO the RFC has a lot of room for improvement in this area:

 - the term "data node" is never defined but used 47 times
 - the term "data node identifier" is not defined or used
 - the term "schema node identifier" is defined and used 14 times
   (defined in sec. 3 Terminology and again in sec. 6.5)
 - every statement that uses some sort of path identifier (e.g. 9.9.2)
needs to clearly specify
   whether the syntax is based on schema-node identifier or data-node
identifier



> Thanks,
> Rob
>
>

Andy



>
> >
> >>
> >>>>     definining the referenced data tree node.
> >>> With require-instance=false there needn't be any referenced data tree
> node.
> >> So we add "(irrespective whether the node exists or not).
> > If the data tree node doesn't exist, we cannot refer to the schema tree
> node
> > that defines it.
> >
> >>>> This likely is not perfect yet but perhaps we manage to make it
> >>>> perfect. ;-) What is not yet clearly described I think is what
> >>>> 'further restricted by corresponding instance nodes in the data tree'
> >>>> means (and that I think depends on require-instance). Perhaps add
> >>> Right. In this case it is not "further restricted" but rather there is
> a
> >>> discrete set of possible values.
> >> A discrete set of possible values is a restriction so I do not
> >> understand your comment. So here is the next iteration:
> > If required-instance is true, there is no need to care about all this
> tricky
> > stuff with schema tree nodes and their types. In other words:
> >
> > 1. if required-instance = true, the permitted values are obtained from
> the data
> > tree.
> >
> > 2. if required-instance = false, the corresponding schema node has to be
> > determined, and its type defines the permitted values of the leafref
> node.
> >
> > It is an exclusive-or, #1 is not an "optional further restriction".
> >
> > Lada
> >
> >> NEW:
> >>
> >>      The leafref built-in type is restricted to the value space of some
> >>      leaf or leaf-list node in the schema tree and optionally further
> >>      restricted by corresponding instance nodes in the data tree (see
> >>      Section 9.9.3).  The "path" substatement (Section 9.9.2) is used
> >>      to identify a leaf or leaf-list node in the data tree. The value
> >>      space of the leafref node is determined by the value space of the
> >>      type of the schema tree node definining the referenced data tree
> >>      node (irrespective whether the referenced data tree node exists or
> >>      not).
> >>
> >> /js
> >>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Fri=
, Nov 23, 2018 at 5:37 AM Robert Wilton <rwilton@cisco.com> wrote:


On 23/11/2018 13:29, Ladislav Lhotka wrote:

> On Fri, 2018-11-23 at 13:39 +0100, Juergen Schoenwaelder wrote:

>> On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
>>>> Here is an attempt to rewrite things in a way according to=
 how I

>>>> understand things works. It should be possible to describe=
 what we

>>>> mean. If we can't do that, we have a bigger problem. (=
I have changed

>>>> only the last two sentences.)

>>>>

>>>> OLD

>>>>

>>>>=C2=A0 =C2=A0 =C2=A0The leafref built-in type is restricted=
 to the value space of some

>>>>=C2=A0 =C2=A0 =C2=A0leaf or leaf-list node in the schema tr=
ee and optionally further

>>>>=C2=A0 =C2=A0 =C2=A0restricted by corresponding instance no=
des in the data tree.=C2=A0 The

>>>>=C2=A0 =C2=A0 =C2=A0"path" substatement (Section =
9.9.2) is used to identify the referred

>>>>=C2=A0 =C2=A0 =C2=A0leaf or leaf-list node in the schema tr=
ee.=C2=A0 The value space of the

>>>>=C2=A0 =C2=A0 =C2=A0referring node is the value space of th=
e referred node.

>>>>

>>>> NEW

>>>>

>>>>=C2=A0 =C2=A0 =C2=A0The leafref built-in type is restricted=
 to the value space of some

>>>>=C2=A0 =C2=A0 =C2=A0leaf or leaf-list node in the schema tr=
ee and optionally further

>>>>=C2=A0 =C2=A0 =C2=A0restricted by corresponding instance no=
des in the data tree.=C2=A0 The

>>>>=C2=A0 =C2=A0 =C2=A0"path" substatement (Section =
9.9.2) is used to identify a leaf or

>>>>=C2=A0 =C2=A0 =C2=A0leaf-list node in the data tree. The va=
lue space of the leafref

>>>>=C2=A0 =C2=A0 =C2=A0node is determined by the value space o=
f the schema tree node

>>> The term "value space of a schema tree node" is not =
defined.

>> OK. So we say 'the value space of the type of the schema tree =
node'.

> Yes, this is better. But what if the schema tree node is made invalid =
due to a

> failed "when" expression? Does it still apply?



I might be being picky, but it isn't absolutely clear from the text 
which node "schema tree node" refers to.



Hence I wonder whether it might be better to say "...identify the 

referenced leaf or leaflist ..." and "value space of the referenc=
ed 

schema tree node".




IMO the RFC has a lot o=
f room for improvement in this area:

=C2=A0- the t=
erm "data node" is never defined but used 47 times
=C2=
=A0- the term "data node identifier" is not defined or used
=

=C2=A0- the term "schema node identifier" is defined and use=
d 14 times
=C2=A0 =C2=A0(defined in sec. 3 Terminology and again =
in sec. 6.5)
=C2=A0- every statement that uses some sort of path =
identifier (e.g. 9.9.2) needs to clearly specify
=C2=A0 =C2=A0whe=
ther the syntax is based on schema-node identifier or data-node identifier<=
/div>

=C2=A0

Thanks,

Rob




Andy

=C2=A0



>

>>=C2=A0 =C2=A0

>>>>=C2=A0 =C2=A0 =C2=A0definining the referenced data tree nod=
e.

>>> With require-instance=3Dfalse there needn't be any referen=
ced data tree node.

>> So we add "(irrespective whether the node exists or not).

> If the data tree node doesn't exist, we cannot refer to the schema=
 tree node

> that defines it.

>

>>>> This likely is not perfect yet but perhaps we manage to ma=
ke it

>>>> perfect. ;-) What is not yet clearly described I think is =
what

>>>> 'further restricted by corresponding instance nodes in=
 the data tree'

>>>> means (and that I think depends on require-instance). Perh=
aps add

>>> Right. In this case it is not "further restricted" b=
ut rather there is a

>>> discrete set of possible values.

>> A discrete set of possible values is a restriction so I do not

>> understand your comment. So here is the next iteration:

> If required-instance is true, there is no need to care about all this =
tricky

> stuff with schema tree nodes and their types. In other words:

>

> 1. if required-instance =3D true, the permitted values are obtained fr=
om the data

> tree.

>

> 2. if required-instance =3D false, the corresponding schema node has t=
o be

> determined, and its type defines the permitted values of the leafref n=
ode.

>

> It is an exclusive-or, #1 is not an "optional further restriction=
".

>

> Lada

>

>> NEW:

>>

>>=C2=A0 =C2=A0 =C2=A0 The leafref built-in type is restricted to the=
 value space of some

>>=C2=A0 =C2=A0 =C2=A0 leaf or leaf-list node in the schema tree and =
optionally further

>>=C2=A0 =C2=A0 =C2=A0 restricted by corresponding instance nodes in =
the data tree (see

>>=C2=A0 =C2=A0 =C2=A0 Section 9.9.3).=C2=A0 The "path" sub=
statement (Section 9.9.2) is used

>>=C2=A0 =C2=A0 =C2=A0 to identify a leaf or leaf-list node in the da=
ta tree. The value

>>=C2=A0 =C2=A0 =C2=A0 space of the leafref node is determined by the=
 value space of the

>>=C2=A0 =C2=A0 =C2=A0 type of the schema tree node definining the re=
ferenced data tree

>>=C2=A0 =C2=A0 =C2=A0 node (irrespective whether the referenced data=
 tree node exists or

>>=C2=A0 =C2=A0 =C2=A0 not).

>>

>> /js

>>



_______________________________________________

netmod mailing list

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




--000000000000e979e5057b583cfb--


From nobody Fri Nov 23 13:00: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 C7EA1130E4C for ; Fri, 23 Nov 2018 13:00: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, 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 unU77yNKPLpA for ; Fri, 23 Nov 2018 13:00:49 -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 58BA6130E4B for ; Fri, 23 Nov 2018 13:00:49 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id F33D0DB2; Fri, 23 Nov 2018 22:00:47 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id sXixBEY4Zt5s; Fri, 23 Nov 2018 22:00:47 +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, 23 Nov 2018 22:00:47 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B23BE2003C; Fri, 23 Nov 2018 22:00:47 +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 cFogRHVa21wA; Fri, 23 Nov 2018 22:00:47 +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 4124D20037; Fri, 23 Nov 2018 22:00:47 +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, 23 Nov 2018 22:00:46 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 740A230044B39F; Fri, 23 Nov 2018 22:00:45 +0100 (CET)
Date: Fri, 23 Nov 2018 22:00:45 +0100
From: Juergen Schoenwaelder 
To: Andy Bierman 
CC: Robert Wilton , Ladislav Lhotka , NetMod WG 
Message-ID: <20181123210045.shd33zxiuzevnppk@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , Robert Wilton , Ladislav Lhotka , NetMod WG 
References: <20181122163046.bkzck2bmbrf3fzm7@anna.jacobs.jacobs-university.de> <87tvk85et8.fsf@nic.cz> <20181123093813.gpxrtanbxgadpwih@anna.jacobs.jacobs-university.de> <20181123.110548.845126088727972359.mbj@tail-f.com> <20181123113341.br77pxmfhcwn6yck@anna.jacobs.jacobs-university.de>  <20181123123907.4wuuojmoikb7fegr@anna.jacobs.jacobs-university.de> <3c8272ada8f28ed41c0d7fc447fdded62f42bf13.camel@nic.cz> <0467b647-1b3b-6b79-e568-8cb9526d1af3@cisco.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 21:00:52 -0000

On Fri, Nov 23, 2018 at 09:23:01AM -0800, Andy Bierman wrote:
> 
> IMO the RFC has a lot of room for improvement in this area:
> 
>  - the term "data node" is never defined but used 47 times
>  - the term "data node identifier" is not defined or used
>  - the term "schema node identifier" is defined and used 14 times
>    (defined in sec. 3 Terminology and again in sec. 6.5)
>  - every statement that uses some sort of path identifier (e.g. 9.9.2)
> needs to clearly specify
>    whether the syntax is based on schema-node identifier or data-node
> identifier
>

We either fix one thing at a time or we give up and hope for a better
future to arrive somehow.

/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 Nov 23 15:52: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 9E324128C65 for ; Fri, 23 Nov 2018 15:52:56 -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 tIQ96jOPi_YO for ; Fri, 23 Nov 2018 15:52:54 -0800 (PST)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD67128CB7 for ; Fri, 23 Nov 2018 15:52:54 -0800 (PST)
Received: by mail-lj1-x232.google.com with SMTP id v15-v6so11857571ljh.13 for ; Fri, 23 Nov 2018 15:52:54 -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=EY2ipjdL5RAYRFraqlcuTRD3oq5lOGVSB4AjmUDlTwI=; b=tv5GNaus7HuTtId3Jcryc9cyxgdHDVbCSNeritmpk2iJelMEBmRywYZ6Q7HORJBC1K 5qTAj8Mh8TP4l4+gAedh/l3rQ2peNprPxARhR+1j3mimYysp9X/hpqqSPWtdG0WxgI6A nJSOhV6hdCydBXHU3i/1bKUkUc/OfN8TfAcw3tT5JYUzqNwZ76r/Kf0Hxz6/ZCl6khje EokeVVp2Y8vnFQyAaFBB/xugBIP/wZHuhMMwsXT54SL2EJuedJ5Fi0m6ZhnJi7wRJppo e0JTQFN1TUtzT4HmKBRgL3pTswDhiuIoW3cX9VHkz9AOqLhKFeYcE19bU2jHTbsI5p0f KeQw==
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=EY2ipjdL5RAYRFraqlcuTRD3oq5lOGVSB4AjmUDlTwI=; b=g9EqQIOKEG+B0l2S+QdP/UesBOOu3HD4T/1hkHGOMbvS+J355cKsSlHwAT+A9/+EWi YzdNJbmvUk/Q7f9uK2az5QuxUx2KIkKF2Ya5KqpdcXcUgcCrtH+OR59ALmxxjZeyINtG BAYzM3OGsZWjsDLD4lhXknEKjQS3l1Z7zOJs8yYn8BdO63roobjtsCMdnQBkJoLVMZJV 6m3FK/+ba8S9sExj+OpeMlX/VGweVZq2F/+YKdsO41dPH+q5llK1KbxGHPAW1T/rtTn3 f2Wx9njLkzop1Klf7lWgv4kN8wuqlMWN2Pribm90WuG2YNZw6aBHxc8UTYf+s+9Joi2f syFA==
X-Gm-Message-State: AA+aEWaeywkalZ5yP6ttgUs3cfk9WhUCiAxAXYKKR+ZDoLIDhb0pkaQa Gcx+ytw+11SSQrTV7IXuXfDbCD51BPed84TsBUP9MQ==
X-Google-Smtp-Source: AFSGD/UMdTjj117gLQM4rER4PrZWnQH8ih6Qr9o7jrHythvey2nqJlq830+JzEEks8yDQIok28/qos+X/Lso/Hzotg4=
X-Received: by 2002:a2e:9556:: with SMTP id t22-v6mr5084759ljh.36.1543017172434;  Fri, 23 Nov 2018 15:52:52 -0800 (PST)
MIME-Version: 1.0
References: <20181122163046.bkzck2bmbrf3fzm7@anna.jacobs.jacobs-university.de> <87tvk85et8.fsf@nic.cz> <20181123093813.gpxrtanbxgadpwih@anna.jacobs.jacobs-university.de> <20181123.110548.845126088727972359.mbj@tail-f.com> <20181123113341.br77pxmfhcwn6yck@anna.jacobs.jacobs-university.de>  <20181123123907.4wuuojmoikb7fegr@anna.jacobs.jacobs-university.de> <3c8272ada8f28ed41c0d7fc447fdded62f42bf13.camel@nic.cz> <0467b647-1b3b-6b79-e568-8cb9526d1af3@cisco.com>  <20181123210045.shd33zxiuzevnppk@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181123210045.shd33zxiuzevnppk@anna.jacobs.jacobs-university.de>
From: Andy Bierman 
Date: Fri, 23 Nov 2018 15:52:40 -0800
Message-ID: 
To: Juergen Schoenwaelder , Robert Wilton ,  Ladislav Lhotka , NetMod WG 
Content-Type: multipart/alternative; boundary="0000000000007213f1057b5daec2"
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Nov 2018 23:52:57 -0000

--0000000000007213f1057b5daec2
Content-Type: text/plain; charset="UTF-8"

On Fri, Nov 23, 2018 at 1:00 PM Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Fri, Nov 23, 2018 at 09:23:01AM -0800, Andy Bierman wrote:
> >
> > IMO the RFC has a lot of room for improvement in this area:
> >
> >  - the term "data node" is never defined but used 47 times
> >  - the term "data node identifier" is not defined or used
> >  - the term "schema node identifier" is defined and used 14 times
> >    (defined in sec. 3 Terminology and again in sec. 6.5)
> >  - every statement that uses some sort of path identifier (e.g. 9.9.2)
> > needs to clearly specify
> >    whether the syntax is based on schema-node identifier or data-node
> > identifier
> >
>
> We either fix one thing at a time or we give up and hope for a better
> future to arrive somehow.
>
>
This is one thing : make it clear where the syntax includes choice/case
identifiers
and where it does not.  The solutions I have seen so far for clarifying
9.9.2
do not do that.



> /js
>


Andy


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

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




On Fri=
, Nov 23, 2018 at 1:00 PM Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de&g=
t; wrote:
On Fri, Nov 23, 2018 at 0=
9:23:01AM -0800, Andy Bierman wrote:

> 

> IMO the RFC has a lot of room for improvement in this area:

> 

>=C2=A0 - the term "data node" is never defined but used 47 ti=
mes

>=C2=A0 - the term "data node identifier" is not defined or us=
ed

>=C2=A0 - the term "schema node identifier" is defined and use=
d 14 times

>=C2=A0 =C2=A0 (defined in sec. 3 Terminology and again in sec. 6.5)

>=C2=A0 - every statement that uses some sort of path identifier (e.g. 9=
.9.2)

> needs to clearly specify

>=C2=A0 =C2=A0 whether the syntax is based on schema-node identifier or =
data-node

> identifier

>



We either fix one thing at a time or we give up and hope for a better

future to arrive somehow.



This is one thing : make it clear wher=
e the syntax includes choice/case identifiers
and where it does n=
ot.=C2=A0 The solutions I have seen so far for clarifying 9.9.2
d=
o not do that.

=C2=A0

/js


Andy
=C2=
=A0



-- 

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

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

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




--0000000000007213f1057b5daec2--


From nobody Tue Nov 27 04:52:27 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD732129385 for ; Tue, 27 Nov 2018 04:52:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.738
X-Spam-Level: *
X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, 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 aO8c6TzAPSwO for ; Tue, 27 Nov 2018 04:52:23 -0800 (PST)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130138.outbound.protection.outlook.com [40.107.13.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCEF2127598 for ; Tue, 27 Nov 2018 04:52:22 -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=wBspCqdMqhnZGTa/2xkON8dGz6TPH65GNCbEa/ukcKA=; b=Igk402lL7+gELfJMYZCcWtjMnUZsvx41r53f1h41rE63eSGvL7oWDWMGsxqx2iQ1xLAwWfzwUHpRDAQfTP+wiNUKv3xDNNMu858EWTqZdXRhv4Rb+jbX3opBh3vpjQmbfqMxodYbF8E+5Ea9E+xkdcR/0goWcYgL7GyctvhBW+0=
Received: from VI1PR07MB5022.eurprd07.prod.outlook.com (20.177.202.206) by VI1PR07MB5325.eurprd07.prod.outlook.com (20.178.11.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.13; Tue, 27 Nov 2018 12:52:20 +0000
Received: from VI1PR07MB5022.eurprd07.prod.outlook.com ([fe80::929:bd11:beb6:b887]) by VI1PR07MB5022.eurprd07.prod.outlook.com ([fe80::929:bd11:beb6:b887%4]) with mapi id 15.20.1382.012; Tue, 27 Nov 2018 12:52:20 +0000
From: tom petch 
To: "netmod@ietf.org" 
Thread-Topic: Routing and other things
Thread-Index: AQHUhlAIekQHzZ8QeE6stNjLBhaPXQ==
Date: Tue, 27 Nov 2018 12:52:20 +0000
Message-ID: <059201d4864f$bd5cc920$4001a8c0@gateway.2wire.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-clientproxiedby: LNXP265CA0009.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::21) To VI1PR07MB5022.eurprd07.prod.outlook.com (2603:10a6:803:9b::14)
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [86.139.215.184]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB5325; 6:ywqfJoKOCpEihqWa7tZbE5qsotjn2F5BTP1MreeAv00n2aVLjQWeTduxFoguOJbCEyNE54bJwMy9jjPIsxBtFH+IPxaTj3X4o6rxMhHCOXSABerEvb2t8F9el5XLkandXKZVhWcaDBnlzGzTu0Lr5BWaEorS5gg5LL/DKpQLhsoYK2bU16VwZfAperrsoKqkIwSJv7FMNINM97vO48E2eOJ7dx9kU/3KLbBrIHHRpt2wkB5aQvDM0gobXx8GOfibIt70d+s4/ZS09Gl9NIWQd76DLasG6T96G6nqGRwCQ+KJjsjZiN0jDAoDK10+QgoJiOgKvZt+WaakOkUwnReVTdniva8nDXMmbTu4AccLysmHi8EqcaWSTkkbw5BM6hgPHr45sP53sMYYatYrOubdSTOYDsEielON5HgLcz9iLE92D+PlX04ZCyzaf157rXdJjvbYX4blrV83W2QYBhGklA==; 5:dAxZaxwXpRxu6jaQkgO0rt6xI8IIna+P3QCW9VrDHhfsb31FKBizYpc0GYeCfz1yxjO2hS/F2GpujW8TpPMHgTIb3yHU6PBN7GsgvXF0thJhq+XwoEkctIA9m3uqRmdet5CFiYz62sPRL9k4LP2A+2begnKUWEcdyAcxFgM5gHs=; 7:haVqRlplxnTrnWPS8arlqXVhdTbrfg7EK4ac0JT5eOcRN0RgCbfR8zmmQ5wTI/u3wetiH89t3j9wA0s9HG6SOktS/GplHG6Mdw6VdL647q8DYr3Rq3HQDu7pUNbGO3XjjjBw/RrujUqVinDH4boNOA==
x-ms-office365-filtering-correlation-id: 61104e63-26e5-4f8d-ee04-08d654672aeb
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7193020); SRVR:VI1PR07MB5325; 
x-ms-traffictypediagnostic: VI1PR07MB5325:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
x-microsoft-antispam-prvs: 
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231443)(944501430)(52105112)(10201501046)(93006095)(93001095)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB5325; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB5325; 
x-forefront-prvs: 086943A159
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(39860400002)(376002)(366004)(396003)(199004)(189003)(97736004)(1556002)(6436002)(44736005)(5640700003)(71200400001)(6486002)(6916009)(68736007)(256004)(14454004)(1730700003)(476003)(305945005)(86152003)(6512007)(8676002)(53936002)(66066001)(486006)(7736002)(5660300001)(9686003)(81166006)(99286004)(186003)(3846002)(6116002)(84392002)(33896004)(14496001)(106356001)(8936002)(105586002)(52116002)(478600001)(2351001)(3480700005)(102836004)(26005)(386003)(6506007)(2501003)(86362001)(71190400001)(25786009)(316002)(81156014)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB5325; H:VI1PR07MB5022.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; 
received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: CQrePpnVAoyS6oJIq1LsWYGZ7zMc8OKOUu5sirywLTsfkK3cVw52m/yTaD05CDMgXisU+zoiuyfPtjlvlqWB1mVrgEzkAZU+XT3O+CNE7r1ZIpUB7LysOLpNKCz+1ZFidJMnO4oR2LLeohhD/tBWmV67aKKFvBCgem9mE0ET8wy1ESj7XwZaeGxojukGco916JdxUWUxxZFgmGD5ERWfjOnzruOPxPYjgaLw4Nm9XtmgYilJxsYIiAeUSy0wYGtSUBVhMhrDjBKEbrHkbdg7Fti8ozfKNIpa/JfPmEne8dmLNQn46KShx+QECMDfzRE/B51Boi0XKqfYSyyPHS6Ubn3UT4np9ue1dDkKuMerH4I=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <5D6056495CB2DD44A7657BC835D3A99D@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 61104e63-26e5-4f8d-ee04-08d654672aeb
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2018 12:52:20.0795 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5325
Archived-At: 
Subject: [netmod] Routing and other things
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Nov 2018 12:52:25 -0000

YANG modules for routing protocols and such like are appearing which
gives me these thoughts.

When interfaces is augmented for a protocol, should it be conditional
and if so on what?  I raised this for MPLS and the response was that
they expected all boxes to be MPLS. (Well, may be in the default free
zone, but not for the vast mass of routers on the edge).  AFAICT it does
no harm to be unconditional (is-is is another such).

Both the lsr protocols have a container for MPLS adding a traffic
engineering router id; this is conditional on a feature of the lsr
protocol but not on MPLS.  Should this be conditional on MPLS and if so
how?

This router id is the same, I think, as TEAS has defined as
 typedef te-node-id {
    type yang:dotted-quad;
so we are getting intersections of lsr, TEAS, MPLS .....

Tom Petch


From nobody Tue Nov 27 07:28: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 BEF9B130EB3 for ; Tue, 27 Nov 2018 07:28:12 -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 uQQXgRV9nEiZ for ; Tue, 27 Nov 2018 07:28:09 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 77729130E8B for ; Tue, 27 Nov 2018 07:28:09 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 767BE1820CC0; Tue, 27 Nov 2018 16:35:05 +0100 (CET)
Received: from localhost (084035065018.static.ipv4.infopact.nl [84.35.65.18]) by trail.lhotka.name (Postfix) with ESMTPSA id E318E1820CBA; Tue, 27 Nov 2018 16:35:02 +0100 (CET)
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: j.schoenwaelder@jacobs-university.de, netmod@ietf.org
In-Reply-To: <20181123.150923.932933854491492133.mbj@tail-f.com>
References:  <20181123123907.4wuuojmoikb7fegr@anna.jacobs.jacobs-university.de> <3c8272ada8f28ed41c0d7fc447fdded62f42bf13.camel@nic.cz> <20181123.150923.932933854491492133.mbj@tail-f.com>
Mail-Followup-To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de, netmod@ietf.org
Date: Tue, 27 Nov 2018 16:28:04 +0100
Message-ID: <87h8g2v8u3.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Adding a pre-existing leaf into a new 'choice' - NBC change?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Nov 2018 15:28:20 -0000

Martin Bjorklund  writes:

> Ladislav Lhotka  wrote:
>> On Fri, 2018-11-23 at 13:39 +0100, Juergen Schoenwaelder wrote:
>> > On Fri, Nov 23, 2018 at 01:02:03PM +0100, Ladislav Lhotka wrote:
>> > > > Here is an attempt to rewrite things in a way according to how I
>> > > > understand things works. It should be possible to describe what we
>> > > > mean. If we can't do that, we have a bigger problem. (I have changed
>> > > > only the last two sentences.)
>> > > > 
>> > > > OLD
>> > > > 
>> > > >    The leafref built-in type is restricted to the value space of some
>> > > >    leaf or leaf-list node in the schema tree and optionally further
>> > > >    restricted by corresponding instance nodes in the data tree.  The
>> > > >    "path" substatement (Section 9.9.2) is used to identify the referred
>> > > >    leaf or leaf-list node in the schema tree.  The value space of the
>> > > >    referring node is the value space of the referred node.
>> > > > 
>> > > > NEW
>> > > > 
>> > > >    The leafref built-in type is restricted to the value space of some
>> > > >    leaf or leaf-list node in the schema tree and optionally further
>> > > >    restricted by corresponding instance nodes in the data tree.  The
>> > > >    "path" substatement (Section 9.9.2) is used to identify a leaf or
>> > > >    leaf-list node in the data tree. The value space of the leafref
>> > > >    node is determined by the value space of the schema tree node
>> > > 
>> > > The term "value space of a schema tree node" is not defined.
>> > 
>> > OK. So we say 'the value space of the type of the schema tree node'.
>> 
>> Yes, this is better. But what if the schema tree node is made invalid due to a
>> failed "when" expression? Does it still apply?
>
> Yes.  I'm sure the text around "when" can be improved, but the idea is
> that if the when expression is false, the schema node becomes
> "invalid"; but it still exists.
>
>> > > >    definining the referenced data tree node.
>> > > 
>> > > With require-instance=false there needn't be any referenced data tree node.
>> > 
>> > So we add "(irrespective whether the node exists or not).
>> 
>> If the data tree node doesn't exist, we cannot refer to the schema tree node
>> that defines it.
>
> It's pretty clear what the intention is, right?  So what are the right
> words to explain it?
>
>
>> > > > This likely is not perfect yet but perhaps we manage to make it
>> > > > perfect. ;-) What is not yet clearly described I think is what
>> > > > 'further restricted by corresponding instance nodes in the data tree'
>> > > > means (and that I think depends on require-instance). Perhaps add
>> > > 
>> > > Right. In this case it is not "further restricted" but rather there is a
>> > > discrete set of possible values.
>> > 
>> > A discrete set of possible values is a restriction so I do not
>> > understand your comment. So here is the next iteration:
>> 
>> If required-instance is true, there is no need to care about all this tricky
>> stuff with schema tree nodes and their types. In other words:
>> 
>> 1. if required-instance = true, the permitted values are obtained from the data
>> tree.
>
> Not true in the candidate.  See also the mail thread you quoted.

This actually indicates that the text "optionally further restricted" is
fundamentally wrong because it seems to suggest that "require-instance
true" is just an additional restriction of leafref's type. But it is
apparently not the case:

- #2 is always used for determining the "inherited" type that has to be
  satisfied in all data trees

- #1 adds a semantic constraint that only has to be satisfied in a valid
  tree.

Lada

>
>
> /martin
>
>
>> 2. if required-instance = false, the corresponding schema node has to be
>> determined, and its type defines the permitted values of the leafref node.
>> 
>> It is an exclusive-or, #1 is not an "optional further restriction".
>> 
>> Lada
>> 
>> > 
>> > NEW:
>> > 
>> >     The leafref built-in type is restricted to the value space of some
>> >     leaf or leaf-list node in the schema tree and optionally further
>> >     restricted by corresponding instance nodes in the data tree (see
>> >     Section 9.9.3).  The "path" substatement (Section 9.9.2) is used
>> >     to identify a leaf or leaf-list node in the data tree. The value
>> >     space of the leafref node is determined by the value space of the
>> >     type of the schema tree node definining the referenced data tree
>> >     node (irrespective whether the referenced data tree node exists or
>> >     not).
>> > 
>> > /js
>> > 
>> -- 
>> Ladislav Lhotka
>> Head, CZ.NIC Labs
>> PGP Key ID: 0xB8F92B08A9F76C67
>> 
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>> 

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


From nobody Tue Nov 27 09:11:17 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104411292AD for ; Tue, 27 Nov 2018 09:11:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.782
X-Spam-Level: 
X-Spam-Status: No, score=-4.782 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Tvo3ftfm; dkim=pass (1024-bit key) header.d=ericsson.com header.b=cx/ua4vZ
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-DOwK7s_s22 for ; Tue, 27 Nov 2018 09:11:12 -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 2ABD9126BED for ; Tue, 27 Nov 2018 09:11:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1543338670; x=1545930670; 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=IamlENgEFDC9ECkC6QFUL4lHrYv9pLXbHadPQ3s2k+Q=; b=Tvo3ftfmASY8Wp+Vz2bipqxbLn0Ieb9nQ3hZz+Qkpa99i56oouQemslrIAvw6USL Wi7HK+lkZXLcDLtdvu1BLeWniY0zqE5K9fECU3VH/FrkpAkvEvqRFMJxnfG6sb4c 3LT2O2hInjiluWSr+EwcCDFRIMoQaAviKMenkfEX01o=;
X-AuditID: c1b4fb2d-f49ff70000007af1-0d-5bfd7aaea0a2
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7E.9F.31473.EAA7DFB5; Tue, 27 Nov 2018 18:11:10 +0100 (CET)
Received: from ESESSMR503.ericsson.se (153.88.183.112) by ESESSMB502.ericsson.se (153.88.183.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 27 Nov 2018 18:11:09 +0100
Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESSMR503.ericsson.se (153.88.183.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 27 Nov 2018 18:11:09 +0100
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) 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, 27 Nov 2018 18:11:09 +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=i0Oq4hWMoNFPVtph4g6RE3Y9iIWsvcWdOJAJ3pazNKQ=; b=cx/ua4vZEKuuHzaTx9rTsXJxIJwmjPo0J1FDjDpHVyO/ZXrAHia9w4LnJJXsRDQOEzxwAFWYTgKML0so4fY+4dZ2jKEbFjcZRhjsO9QO0ia7C5nlfMg6LzxE9wlVqPTSgsJvo2w3bE6Qf6Rnb/CO1F0F1eXGseQf9J9XJg09TyY=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2400.eurprd07.prod.outlook.com (10.168.138.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.8; Tue, 27 Nov 2018 17:11:08 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::70d1:cf80:392b:814b]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::70d1:cf80:392b:814b%4]) with mapi id 15.20.1382.012; Tue, 27 Nov 2018 17:11:08 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" 
Thread-Topic: [netmod] Datastore leaf for yang instance data
Thread-Index: AQHUgy9uQuT8qLL6iU6nVdbyZztkVQ==
Date: Tue, 27 Nov 2018 17:11:07 +0000
Message-ID: <598859f0-d6fe-9a9e-4b27-6249b05f86ca@ericsson.com>
References: <87y3a6izap.fsf@nic.cz> <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de> <58740c15bf3277e04329546476f60c1d12516594.camel@nic.cz> <20181106.104157.239419955739949818.mbj@tail-f.com> <866ff105cf8fda7eadbdce5b344f4cd734fd99b8.camel@nic.cz> <1f4103c1-4953-3df4-d50d-aed1961fbc50@ericsson.com> <20181123154951.anviss5nllq6gwrn@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181123154951.anviss5nllq6gwrn@anna.jacobs.jacobs-university.de>
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: HE1PR07CA0012.eurprd07.prod.outlook.com (2603:10a6:7:67::22) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2400; 6:vU0t1EcuMgUlXwWqASMJHPEOXKD8krN5xyI2kJnAR0iWs/+RXA7yoYyQRc2ZyJDSIRTvnqL1va1LilJ8Y+qZ80uj1WcX0RvE/d4nf2LQll87ZGKGZyf6z9xHjD2S+TdtWmexeJo3deLvkCArsGFONR3xFrEbXj5vYeO4sk9gk+QPt3BFDCgZ+lPHMaroD6Df6Phz4da+Uz8lZcKwQ4idda8Wqll1MlmZ4ZAJ7QyGvOi4PLXDZV+G7kRYFvFlBDAfjjrQRRuzudYtsRUz1sI225DYU3QEhaFrRgzYavQXhnA1u7lxgkoBI9eg1jwz99M1pnmbeqD3MFxTtoQ1ltT4E6TCOA9DrobIF2B7PRljYPhHUuy4zeke2SFrtxO36lc46ZKIHdiT4GOnanI12yJwuf8+faUAYSVpDQmxTS5PSASs/trXRkMr79HHqKaoHC6uD8dGUKVB41vrlHtoejMgtg==; 5:RqsC9nkMKzmk+PESIINIKPlSAqP+Ld9elJ7zJy/LsMcpsgxEMHO7Ck1sCIOYMw9IZMG0FlZVJpI/I+3cyXYdn269cnAb0Oba1tEzjc7gAUivzZWhc7xCX0KYo303rR4I/tICvs0UQYWEmK656XlFJ//TqEqc5VnbPEftxjTwd6E=; 7:iWkvSmhkfeXD6xqMBlQYUmoASboxcoa9TNFm+SP50ShyOPU4bfwffH8U+tmW8HtmS6J88a5Hlo9CbKfMIxchm19msnz8WM7o+6VD9DO2yWVcCgRpk1UUcVEKngv/M9BEbttiT3byV7PdB20MKcIIQQ==
x-ms-office365-filtering-correlation-id: a741d375-9e79-4894-e65f-08d6548b511b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2400; 
x-ms-traffictypediagnostic: VI1PR0701MB2400:
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)(3002001)(3231443)(944501430)(4983020)(52105112)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2400; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2400; 
x-forefront-prvs: 086943A159
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(136003)(376002)(396003)(39860400002)(189003)(199004)(252514010)(102836004)(6436002)(81156014)(99936001)(386003)(478600001)(76176011)(6506007)(52116002)(93886005)(14454004)(64126003)(256004)(8676002)(66066001)(65826007)(97736004)(81166006)(85182001)(65806001)(65956001)(7736002)(25786009)(3846002)(305945005)(6116002)(68736007)(26005)(5660300001)(486006)(476003)(2616005)(53936002)(71200400001)(6246003)(2501003)(86362001)(11346002)(6512007)(106356001)(85202003)(2906002)(31696002)(99286004)(58126008)(71190400001)(8936002)(316002)(31686004)(110136005)(229853002)(186003)(105586002)(6486002)(36756003)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2400; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: 3n9FKqbIfe/dB/ZOnFWIbtnbdItDdCiDktuAuN8fnAweuA+AybqsWWX/tWLhUTtm1OmA9xo/YCApxqFYaqACU5piPN2fbX1BNeAIYpoOVV+GGyPSv/4jFSpPTMskf2HnpyHGI1V+7IPG9lhbw/1GeSWf8JK06IkIgi4mcuQqJEnjUSYMxFUB4CA7yjeuDzx+6HCKyFDQyM5YREF+84xyzzvUzF6vCdt0qzbo7SqFjKFEDJarSksO+Fa623Kt4ou+k5QqJFb4duY1i8UTLFYrVVJ6+tnVanoV2UIJc7XRgBCf1YTB5lRdtHfB5cz8znrpG7V76rri/g1tQlc606j96cvqth6H4P/zo2me0HfU6wM=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020608040104080506020102"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a741d375-9e79-4894-e65f-08d6548b511b
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2018 17:11:07.8441 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2400
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTYRjG+3bO5nG4+DKXL9PIhoZorszyTlkW+E90oaCUylOeVNIpOyYq CU7IvCSMMC/L8i7eK1OcKdosLRNJLbrI0KY2TcXSYJah5XZW1H+/53ve573ARxG203wJFS1P YBRyOkYqEJJFZ9qSPJpSVsN2f5ng+Q7V3RX45uQYrHxLhpX8ICKksvIHL6T5tQ6FPFypII8T ocLACCYmOpFR7NofLoxavf6CiC/en6Tul6UhpV82sqYA7wW9QcPPRkLKFj9DMNO1xOOEEUFr 2i+eqcoshm/bcEYlDxq03YRJkFhFQMbzPsQ5BTxQjmdZhAGBMaORb8oL8GG4sdBt7mWHY2FG rSJNvBkHwGLmEsm9B8LK7IClRgY1mlvIxCR2gca0cvO7CB+Aj8ZCATcgl4Dh8TLzAGt8DPry WwgTI7wFll82mAMEtofRqRIed6od6IcHBByL4fPkGp9jKRTOjppZjM9BQeVN8wWA8xG8etNq CeyEwXdTiOOtMFKSYyl6L4D03HlLp6OgyTNYcYYOgar1K/k3/XgQceudh86xTEvXODAWN/BV yFP9z7bq9TyBsxA0LDwh1ea7N0F/0RTJFXnDvUd6gmN3qC6bI/4PmzgACle0Ao63Q16O3orj fTDXu4g49oLqplVBKRLWITHLsGxs5B4vGaOIvsSycXKZnEloRutfTtvy00OD6ucO9iBMIamN aD5yNcyWTyeyybE9yHm9z8SD+iEkIeVxckZqJ/Jn121RBJ2cwijiLiiuxjBsD3KgSKm9SFbX GWqLI+kE5grDxDOKPy6PspakoVo8c7lmOeBQqsxvx4ivRKxpW2sv92kPL5Usnz5Vm5n+diMd KHb95npC5zSZSo87fujqeFoVPK1y1Qf7k7psx2sb+vvcq5SdZ7UVvTploZd9uLeONjidTM2/ Qyld7gd1TLqtUPoWn4vGMY/uNp8jTtb6T5MOKc7bPEZjv5MRrlKSjaI93QgFS/8GfDK3AHoD AAA=
Archived-At: 
Subject: Re: [netmod] Datastore leaf for yang instance data
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Nov 2018 17:11:15 -0000

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

Hello Jurgen,

As we had many misunderstandings around the datastore parameter, and I=20
am still not clear what you would like, could you propose a description=20
text for the datastore parameter.

regards Balazs

On 2018. 11. 23. 16:49, Juergen Schoenwaelder wrote:
> On Fri, Nov 23, 2018 at 01:21:23PM +0000, Bal=C3=A1zs Lengyel wrote:
>>     BALAZS: "Instance data associated with a datastore" may mean many =
things,
>>     that's why this relatively loose term is used. It may mean:
>>
>>       * Data was read from that datastore
>>       * Data is intended to be fed into that datastore
>>       * Something else ???
>>
>>     This can be useful if data is read from a datastore, but in a numb=
er of
>>     cases it is not useful:
>>
>>       * Preloading configuration data: datastore may be running or can=
didate.
>>       * Preloading mixed config and state data: We do have state data =
that is
>>         very stable and thus it is documented as instance data, and th=
e
>>         instance data file is actually used to feed the state data int=
o the
>>         SW. So datastore is: running, candidate + operational if NMDA =
is
>>         supported or state datastore (whatever that is) if NMDA is not=

>>         supported
>>
>>     regards Balazs
>>
> I do not buy this story. Your software needs to decide somehow what
> instance data means. A config true leaf in candidate means something
> different than the same config true leaf in running and this yet again
> means something different than the same config true leaf in operational=
=2E
>
> /js
>
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com



--------------ms020608040104080506020102
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTEyNzE3MTEwM1ow
LwYJKoZIhvcNAQkEMSIEIOlTNRNlG/kG9cfvryUjGRcrtyaCewebfqIVmw5yROGEMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAFbNvfXxlTOhKRAU1x+GN6N/BnAmTsZIwSgbEc8YktNP4VxS
fNP7e6ndxnMOTUyfaXdYdRUl3/Cv3oBmBqRUXE+UL16gxlOjLsuWKtGv3mE3H1EF4XcaIo0S
FARrI95O+K5V0HJXUo2oh1BpM/ZYdiMH61lZew4QU9jwS20tNBk2aTFT6Iye45Brsfuxj9ph
gMX9Vmput4ELUMbtBwaKBmbDtilLQGZlRtLGdFpvd+pDICQDlsfY/hy+77UuZIkU8GeNm+g8
FKjBZ3paJiVsK3TehAFmxD9aS6U/5cUTgAIN9hfpfBL6TGi1daDjyMi8UZcTZ+Jyv4DS5pRo
9GYknGAAAAAAAAA=

--------------ms020608040104080506020102--


From nobody Wed Nov 28 01:41:19 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321981271FF for ; Wed, 28 Nov 2018 01:41:18 -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=LHjf6mR5; dkim=pass (1024-bit key) header.d=ericsson.com header.b=AgR5wmZg
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8iLnq0HCadi for ; Wed, 28 Nov 2018 01:41:16 -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 DCAFC124D68 for ; Wed, 28 Nov 2018 01:41:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1543398073; x=1545990073; 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=mQS7DTxZ01jEohoSnrJ9+C9LfpJWghNV8g44muVa8AE=; b=LHjf6mR5DFXyuv9UxFBTsA60GYYLLcnQVM0By0+c0UHWSON5DiWX0BI07ALL4R9E zQOZTPXC7utnUi9cez1M2k97jzeJH7oHWG3YhvBNkrYGg57ZHNDAiJfkgwoj0gwT 2Vtii4GcKcuTi0e0tsjBXO+GQaB6LQs/hUi9t0Hu86E=;
X-AuditID: c1b4fb25-a68609e00000191f-3c-5bfe62b96a63
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 52.59.06431.9B26EFB5; Wed, 28 Nov 2018 10:41:13 +0100 (CET)
Received: from ESESBMB504.ericsson.se (153.88.183.171) 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; Wed, 28 Nov 2018 10:41:13 +0100
Received: from EUR03-DB5-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; Wed, 28 Nov 2018 10:41:13 +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=PnZik4jcvzvQICvZYmh4GFcbSH4FAjPIpbZDe9tWcew=; b=AgR5wmZgOemFNJ6wGC3JEz26zb08OV9bySOAZpvesjDnE774fJbNIjwL/zcCYMoyZnh/9gSQFK0WLJay/lNT1inn3zYPOHKz8ib9pdese9K6h/6dg3AyfC3xLPDsHGCe5sI16jzXN8o9r39IIrKx1FEsTLbtOoZjT1tf2Y94/IU=
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com (10.173.80.148) by VI1PR0701MB2511.eurprd07.prod.outlook.com (10.168.139.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.14; Wed, 28 Nov 2018 09:41:12 +0000
Received: from VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::70d1:cf80:392b:814b]) by VI1PR0701MB2736.eurprd07.prod.outlook.com ([fe80::70d1:cf80:392b:814b%4]) with mapi id 15.20.1382.017; Wed, 28 Nov 2018 09:41:12 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" 
Thread-Topic: [netmod] Datastore leaf for yang instance data
Thread-Index: AQHUgy9uQuT8qLL6iU6nVdbyZztkVQ==
Date: Wed, 28 Nov 2018 09:41:12 +0000
Message-ID: 
References: <87y3a6izap.fsf@nic.cz> <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de> <58740c15bf3277e04329546476f60c1d12516594.camel@nic.cz> <20181106.104157.239419955739949818.mbj@tail-f.com> <866ff105cf8fda7eadbdce5b344f4cd734fd99b8.camel@nic.cz> <1f4103c1-4953-3df4-d50d-aed1961fbc50@ericsson.com> <20181123154951.anviss5nllq6gwrn@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181123154951.anviss5nllq6gwrn@anna.jacobs.jacobs-university.de>
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: AM6PR03CA0019.eurprd03.prod.outlook.com (2603:10a6:20b::32) To VI1PR0701MB2736.eurprd07.prod.outlook.com (2603:10a6:801:8::20)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2511; 6:y3xp61+qcKIh3voXrB+NxvVXS/IBTdknQ76Z0dGoTBpC0SjY0ftyab7iKKxvLHlYdnvc2EhH2go1T4dvYaijJg5mJaiOBrcaHcUM7Dm3hxXf6VBpknqK+uAUQnmOJhunVkjdpH98usm1Lca9xz92xMAhFAGyVzosCB8IjBOgInmVQ3A/egpHLuugKqEOIZyyW7RwmMDY85KS+DgIRgV9i3AP6wYORYC8OJ0Fgga6BKnlOx/WlILMfljlGsAc/yv8l96CpR5tvVrt1v762L579iJhgo7OXDfmy1AFxQyGXgfTGpzQzCiq3cCaoqMjsNVHqE+mY/sNkFwx9I0WqgOz83QdbsEO3UhLhVlPyBHiibYRmUSfhvOiweUVlLwvQ3YiydTKUo5WkE0A64g70QEN9mOUpHtd1h48FRYIWbxhDbNmzPeUSnoKnFxExlEsqiaQ2LL1oDnikGv5X6E+p1TreQ==; 5:NJ1VBxRqTSYK/IGfLNidpD4ESeMy2XA9yY70s8JDfIXErG1BEX3ImKLzugiONf8hGAchzUrY1aGnJ8u93Bjw6HBlas9yJwasj2p/33MX+sog9Xrz6+6cFSgB5WFEu6xdHAp9k9fBElUDZpQtaudLeAsV9ALQlywhYE/9UXXfgYI=; 7:12tBaC/HJmr7NKuwZgS+aukSz+HvQsNbh5LfOOMplTRQHJ0N+0fVppoM3C3kHmjJJrOyEtRBC/AJgefpOchFYM+LtjOQB2xz2FLPbrHeoSrFja6PJWDPjHX3wHtaWHQ0LgowlCSA5LlLAmedb1S1jg==
x-ms-office365-filtering-correlation-id: 591ab123-63ed-4c54-390d-08d65515a159
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:VI1PR0701MB2511; 
x-ms-traffictypediagnostic: VI1PR0701MB2511:
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)(93006095)(93001095)(3002001)(3231443)(999002)(944501436)(4983020)(52105112)(10201501046)(148016)(149066)(150057)(6041310)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR0701MB2511; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2511; 
x-forefront-prvs: 0870212862
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(39860400002)(346002)(366004)(136003)(252514010)(199004)(189003)(102836004)(81156014)(65826007)(81166006)(8936002)(186003)(93886005)(26005)(8676002)(68736007)(53936002)(14454004)(6512007)(65956001)(65806001)(66066001)(476003)(2616005)(446003)(31696002)(11346002)(71200400001)(478600001)(86362001)(256004)(71190400001)(6116002)(99286004)(105586002)(106356001)(2906002)(99936001)(85182001)(6486002)(64126003)(486006)(25786009)(85202003)(3846002)(6436002)(386003)(36756003)(5660300001)(6506007)(58126008)(6246003)(52116002)(97736004)(110136005)(316002)(229853002)(31686004)(7736002)(305945005)(2501003)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2511; H:VI1PR0701MB2736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: rh3N38iI+MCxHSMtEALjYDWzWmQ50iFPlkYVF0tOEroSQgYIFbn//lxwLIt804CzCR0ExC9WUnfPM8gOR1toQw4oVhYTYc+6WK5HU+YsBENc717yXaTi30mjYLRCWkOG93yKr1y0DHI5c9adgtsYgsDp+r/oLflEMODQYkLeR4iv/WstMLt7yPkvnRZ6g17luLzGCIBZUBKe88+Ny7YeWwzp5qUWPozTsgotBxTSO1d2vr/ZuLEOK879euZw03uyyGyeBNmb6R+6zi/cLJSx0iQ9864zSsDYu3PZ4l8aY3nRvYLVB4YpvOMykaY5rrizPI+P6DSObMW+WnEzO8PsvOaJLlJWV7ntyBtkRJS39gY=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070104020006030200030307"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 591ab123-63ed-4c54-390d-08d65515a159
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2018 09:41:12.3338 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2511
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTURzHObt31zlaHqfTH4qRIwnSpmWloahlgQVhEEQpWVteVNJNdtW0 /lHDtC3Nmqhb2BRNwuzhIx+hmWY+knxTaWYtzUwtsLTHSmnbnVD/fc7v+zg/DodHCKe5Lrw4 eRKtlEvjxRSf1B5rPLu1WbYa6XOvwM9/sKqE8lerZ2z89UMZ3BAirKLiFyesdmQChdUYy8nD RAQ/MJqOj0uhld5Bp/ixY9mNZOLs3tRvD4dQOhoPVCEeD/AO6L64XoX4PCHuRJDeMYxUyNZ0 +I6gpTKQFSo48KApizQLJM4nIMPozgrFHOgaKCDYwwyC5bxxi4vC+yD7SxvHzI44AWZ1+Za5 Aw6AxZyvJDsPBONcn9UjgVtN15B5JRJ7gErjYB4LcDA0aN/YsP25BAy9LeOaBVscDl2F9YSZ EXaCH8+qLT0Edobxab2FATuCYaiPYlkEn6ZWuSyLoXhu3MIifAKKKi4j8wWANQi0Y/PWsBc8 fzmNWHaDYb3aanpFwYeWZWvTIah5VGDDChMIDPVL1Fpa1bNMsetFQctkjnWugN5SlTW8Aapy DWQ+8tH9s7nO1EXgSwjalqpIneUN7KFXO02ypl1wo85AsOwJlWXzxP9hMwdAsbGdYtkdCtQG G5Z3wvzTRcSyL1TeXaFKEb8KiRiakSXEbPeV0Mq40wyjkEvkdFItMv239vrfHk1oZGFPB8I8 JF4neBG1GinkSlOYtIQOtMnU8/7+7UHkQsoVclrsKEgOMsmCaGnaOVqpOKlMjqeZDuTKI8XO AoNfXYQQx0iT6DM0nUgr11QOz9YlHSHt5lI7jVQ0ejX8fL4kWxgDYa5ZbnbBFwZvHvBo/uMd 6k1KckqWm/VFqerO7oH9uu7RnupMLTHQK2sVodeLeoKI2N0/deex+5HC69lTuarKo1c+h/6M Q5vsk/STeb79XjlZzMbgIKfMd10H+47XM8HShoSyjyuakHJP2ZOFVjHJxEq3bSGUjPQvQ6A6 wHcDAAA=
Archived-At: 
Subject: Re: [netmod] Datastore leaf for yang instance data
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2018 09:41:18 -0000

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


On 2018. 11. 23. 16:49, Juergen Schoenwaelder wrote:
> On Fri, Nov 23, 2018 at 01:21:23PM +0000, Bal=C3=A1zs Lengyel wrote:
>>     BALAZS: "Instance data associated with a datastore" may mean many =
things,
>>     that's why this relatively loose term is used. It may mean:
>>
>>       * Data was read from that datastore
>>       * Data is intended to be fed into that datastore
>>       * Something else ???
>>
>>     This can be useful if data is read from a datastore, but in a numb=
er of
>>     cases it is not useful:
>>
>>       * Preloading configuration data: datastore may be running or can=
didate.
>>       * Preloading mixed config and state data: We do have state data =
that is
>>         very stable and thus it is documented as instance data, and th=
e
>>         instance data file is actually used to feed the state data int=
o the
>>         SW. So datastore is: running, candidate + operational if NMDA =
is
>>         supported or state datastore (whatever that is) if NMDA is not=

>>         supported
>>
>>     regards Balazs
>>
> I do not buy this story. Your software needs to decide somehow what
> instance data means. A config true leaf in candidate means something
> different than the same config true leaf in running and this yet again
> means something different than the same config true leaf in operational=
=2E
>
> /js

BALAZS: As I understood the WG decided that this draft should only be=20
about the format of the yang instance data. What the SW does with it is=20
out of scope. So considerations whether instance data should be loaded=20
into running or candidate or not at all, are outside the scope.

I want to provide a datastore indicator, but how that should be used=20
(and thus what is exactly means) is out of scope.

Anyway in some cases it would be problematic to define a single=20
datastore parameter. E.g. the draft allows the real world use case of=20
putting config and state data in the same file. In this case state data=20
is associated with operational while config data is with=20
running/candidate. In the non-NMDA case I do not even know what the=20
correct daatastore is for state data.

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



--------------ms070104020006030200030307
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTEyODA5NDEwM1ow
LwYJKoZIhvcNAQkEMSIEIJ8/GMe0pSmediKRhvJKli+8dmLOr1dLsq51VT9P8oHzMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAIDhuI6fQQCNxkbVSdLWUNbD4tJPX6yYiJrWLAltwoaVjDIx
PuvQ+RxsX16IJ9tDJgdR3hB3J86Zsk8Cgn+w326tEarBMti7xa9PdD8NO6d0SgoIngoodoXS
H42sywFTiFHMf75MZQdnFoR86TMY78ysSCFkSM7cBI72NxvrX6SvOsxVapOcGedAM3jZhIvM
vnJxqqgAo431Ib7NU9mjV/PWiKWOwDbasQyMyN+8oYmOwa3iVgQDPQYpyVeRjjxc22hd6zgb
DiYNc7NweFVlNwgUow7bhEd0T43buRGOOuolPs5dNroBbdHdjB9253JmiRFhj5GzaVWY70kC
eAhwMcEAAAAAAAA=

--------------ms070104020006030200030307--


From nobody Wed Nov 28 02: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 8E84C130E95 for ; Wed, 28 Nov 2018 02:01:23 -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 ZwOet6YEY6gu for ; Wed, 28 Nov 2018 02:01: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 A59FE128C65 for ; Wed, 28 Nov 2018 02:01:19 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 419E5E94 for ; Wed, 28 Nov 2018 11:01: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 47OEPsJ3fsUw for ; Wed, 28 Nov 2018 11:01: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 for ; Wed, 28 Nov 2018 11:01:18 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C28920043 for ; Wed, 28 Nov 2018 11:01: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 dRmgFx05d5RD for ; Wed, 28 Nov 2018 11:01:17 +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 B1ECD2003F for ; Wed, 28 Nov 2018 11:01:17 +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, 28 Nov 2018 11:01:17 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 12742300457450; Wed, 28 Nov 2018 11:01:16 +0100 (CET)
Date: Wed, 28 Nov 2018 11:01:16 +0100
From: Juergen Schoenwaelder 
To: 
Message-ID: <20181128100116.c6awxlwkxnm42gfb@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: netmod@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
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: [netmod] instance file format and etags/timestamps, xml attributes
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2018 10:01:24 -0000

draft-ietf-netmod-yang-instance-file-format-00.txt says:

   The JSON format SHALL follow the format of the reply returmed for a
   RESTCONF GET request directed at the datastore resource:
   {+restconf}/data.  ETags and Timestamps SHOULD NOT be included, but
   if present SHOULD be ignored.

I assume that you mean the JSON content in the message-body of the
HTTP Response message for GET message. My understanding is that ETags
and Timestamps (what are these precisely?) are carried in the HTTP
header. So how could the ETag or 'Timestamps' be in the JSON data?  We
should not mess up the HTTP difference between header data and payload
data.

I also do not fully understand the text concerning the XML format.

   The XML format SHALL follow the format returned for a NETCONF GET
   operation.  The  anydata (which is not part of the real data
   itself) SHALL contain all data that would be inside the 
   wrapper element of a reply to the  operation.  XML attributes
   SHOULD NOT be present, however if a SW receiving a YANG Based
   Instance data file encounters XML attributes unknown to it, it MUST
   ignore them, allowing them to be used later for other purposes.

It is unclear what exactly is the instance data - the entire reponse?
Everything inside ? Everything inside and including ? I
assume the second sentence is trying to say the later but I do not
find it very clear not does it seem to be right. The examples show to
content of the NETCONF  inside a 
container that belongs to the instance data format (two times 
but in different namespaces).

It is also unclear to me why XML attributes are to be removed. Why is
that? If I snapshot , why should I remove important
information such origin annotations? And removing attributes is
actually plain wrong if you consider that attributes carry XML
namespaces.

/js

PS: I am also concerned about the revision being not fine grained
    enough to be useful. I would love to have a much more precise
    timestamp telling me when the instance data was recorded. I would
    probably replace 'revision' with simply a 'timestamp' or add next
    to a 'revision' a more fine grained 'timestamp'.

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


From nobody Wed Nov 28 02:20: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 0147C130EBE for ; Wed, 28 Nov 2018 02:20:56 -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 je_zuH6pd_yd for ; Wed, 28 Nov 2018 02:20:54 -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 3C8EE130E4F for ; Wed, 28 Nov 2018 02:20:54 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id BE88AEC0; Wed, 28 Nov 2018 11:20:52 +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 gkE3XaSE-KjO; Wed, 28 Nov 2018 11:20:52 +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, 28 Nov 2018 11:20:52 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id A7B6C2003F; Wed, 28 Nov 2018 11:20:52 +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 V_iW_pO-imzU; Wed, 28 Nov 2018 11:20:52 +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 00EDD20037; Wed, 28 Nov 2018 11:20:51 +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, 28 Nov 2018 11:20:51 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 3DEB330045766D; Wed, 28 Nov 2018 11:20:51 +0100 (CET)
Date: Wed, 28 Nov 2018 11:20:50 +0100
From: Juergen Schoenwaelder 
To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel 
CC: Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" 
Message-ID: <20181128102050.37iyrx2xhdohnepb@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel ,  Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" 
References: <87y3a6izap.fsf@nic.cz> <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de> <58740c15bf3277e04329546476f60c1d12516594.camel@nic.cz> <20181106.104157.239419955739949818.mbj@tail-f.com> <866ff105cf8fda7eadbdce5b344f4cd734fd99b8.camel@nic.cz> <1f4103c1-4953-3df4-d50d-aed1961fbc50@ericsson.com> <20181123154951.anviss5nllq6gwrn@anna.jacobs.jacobs-university.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Datastore leaf for yang instance data
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2018 10:20:56 -0000

On Wed, Nov 28, 2018 at 09:41:12AM +0000, Balzs Lengyel wrote:
> 
> > I do not buy this story. Your software needs to decide somehow what
> > instance data means. A config true leaf in candidate means something
> > different than the same config true leaf in running and this yet again
> > means something different than the same config true leaf in operational.
> > 
> > /js
> 
> BALAZS: As I understood the WG decided that this draft should only be about
> the format of the yang instance data. What the SW does with it is out of
> scope. So considerations whether instance data should be loaded into running
> or candidate or not at all, are outside the scope.

If you do not know what the instance data means, any attempt to use it
is kind of broken.
 
> I want to provide a datastore indicator, but how that should be used (and
> thus what is exactly means) is out of scope.

I disagree. The datastore indicator is needed to understand what the
data means, i.e., to do anything meaningful with it.

> Anyway in some cases it would be problematic to define a single datastore
> parameter. E.g. the draft allows the real world use case of putting config
> and state data in the same file. In this case state data is associated with
> operational while config data is with running/candidate. In the non-NMDA
> case I do not even know what the correct daatastore is for state data.

We created NMDA because mixing  with  is broken
in a number of cases. I am fine to accept that the datastore indicator
may be absent paired with a clear warning that in this case it is
undefined what the data means. (And I will hope that robust
implementations will avoid working with data that has unclear
semantics or at least generate warnings.)

/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 Nov 28 02:26:16 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284E4130E4F for ; Wed, 28 Nov 2018 02:26:15 -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 LokyEwrvq0E4 for ; Wed, 28 Nov 2018 02:26:13 -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 0C4EB130EA2 for ; Wed, 28 Nov 2018 02:26:12 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A41B4E0C; Wed, 28 Nov 2018 11:26:10 +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 IAufuhsiz-Rc; Wed, 28 Nov 2018 11:26:10 +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, 28 Nov 2018 11:26:10 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8369520037; Wed, 28 Nov 2018 11:26:10 +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 N0wUxmbl_9I8; Wed, 28 Nov 2018 11:26:10 +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 33E7F2003F; Wed, 28 Nov 2018 11:26:10 +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, 28 Nov 2018 11:26:09 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 7C3543004576FF; Wed, 28 Nov 2018 11:26:09 +0100 (CET)
Date: Wed, 28 Nov 2018 11:26:09 +0100
From: Juergen Schoenwaelder 
To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel 
CC: Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" 
Message-ID: <20181128102609.66wgusmxziponexj@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel ,  Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" 
References: <87y3a6izap.fsf@nic.cz> <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de> <58740c15bf3277e04329546476f60c1d12516594.camel@nic.cz> <20181106.104157.239419955739949818.mbj@tail-f.com> <866ff105cf8fda7eadbdce5b344f4cd734fd99b8.camel@nic.cz> <1f4103c1-4953-3df4-d50d-aed1961fbc50@ericsson.com> <20181123154951.anviss5nllq6gwrn@anna.jacobs.jacobs-university.de> <598859f0-d6fe-9a9e-4b27-6249b05f86ca@ericsson.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: <598859f0-d6fe-9a9e-4b27-6249b05f86ca@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] Datastore leaf for yang instance data
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2018 10:26:15 -0000

On Tue, Nov 27, 2018 at 05:11:07PM +0000, Balzs Lengyel wrote:
> Hello Jurgen,
> 
> As we had many misunderstandings around the datastore parameter, and I am
> still not clear what you would like, could you propose a description text
> for the datastore parameter.
>

Here is a start...

OLD

        leaf datastore {
          type ds:datastore-ref;
          description  "The identity of the datastore for which
            the instance data is documented for config=true data nodes.
            The leaf MAY be absent in which case the running dtastore or
            if thats not writable, the candidate datastore is implied.

            For config=false data nodes always the operational
            data store is implied.";
	}

NEW

        leaf datastore {
          type ds:datastore-ref;
          description  "The identity of the datastore to which
            the instance data belongs.

            If this leaf is absent, then the datastore to which the
	    instance data belongs is undefined. This means that in
	    particular the meaning of 'config true' data is not well
	    defined.";
	}

/js

PS: I am not a big fan of the indentation style but that is a minor
    issue.

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


From nobody Wed Nov 28 03:00: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 2B57A130EA2 for ; Wed, 28 Nov 2018 03:00:56 -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 8lGEUf2pcbE6 for ; Wed, 28 Nov 2018 03:00: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 C160F130E25 for ; Wed, 28 Nov 2018 03:00:49 -0800 (PST)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 30F4C1AE0385; Wed, 28 Nov 2018 12:00:45 +0100 (CET)
Date: Wed, 28 Nov 2018 12:00:44 +0100 (CET)
Message-Id: <20181128.120044.251389134047648732.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: balazs.lengyel@ericsson.com, lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20181128102609.66wgusmxziponexj@anna.jacobs.jacobs-university.de>
References: <20181123154951.anviss5nllq6gwrn@anna.jacobs.jacobs-university.de> <598859f0-d6fe-9a9e-4b27-6249b05f86ca@ericsson.com> <20181128102609.66wgusmxziponexj@anna.jacobs.jacobs-university.de>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Datastore leaf for yang instance data
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2018 11:00:56 -0000

Juergen Schoenwaelder  wrote:

[...]

> PS: I am not a big fan of the indentation style but that is a minor
>     issue.

Since the RFC editor will ensure that the indentation style is
consistent with other RFCs, it is better to fix this now.


/martin


From nobody Wed Nov 28 06:36: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 832B7130E4A for ; Wed, 28 Nov 2018 06:35:58 -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 p-lMs4anEJrG for ; Wed, 28 Nov 2018 06:35:57 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D385130DCE for ; Wed, 28 Nov 2018 06:35:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=409; q=dns/txt; s=iport; t=1543415757; x=1544625357; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=RpWgXVmCvs7uNgwA+wemsexuZnxvFnponc3WRxbmn0I=; b=LZsmR97qxXJtYjndtgfl9rTDPTP4X9W22KFjfe74NZOn6wlPzOICI0g0 L5GNEAodB9J+b2o/NsbeuunMN8VlaS7hKzRzQlKcolTU8X2rHLML+QbOk v1j2MyDpNvaB2OUZ5WDZuE1grqgpp6oo8ebYDFlE0MQ/eMrVtsk6r7gkP M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DaAAD9pv5b/5NdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZQKCAmlMM4QglCGBYC2ZPA2EYwkCgywiOBIBAwEBAgE?= =?us-ascii?q?BAm0oQgEMAYRtAQIDIw8BRBILGAICJgICVwYBDAgBAYMdggKmSIEvij2BC4s?= =?us-ascii?q?LF4FAP4E4gmuIBYI1IgKQG5AACZErBhiBSwGIHIctiHaPUoFdIYFVTSMVgyi?= =?us-ascii?q?CJhcSjikhA4MRi1kBAQ?=
X-IronPort-AV: E=Sophos;i="5.56,290,1539648000"; d="scan'208";a="205490534"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Nov 2018 14:35:56 +0000
Received: from [192.168.10.244] (rtp-jclarke-nitro4.cisco.com [10.118.87.85]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTP id wASEZtBx030149; Wed, 28 Nov 2018 14:35:56 GMT
To: =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= , "netmod@ietf.org" 
References: <154147032474.4217.10743411700898817061.idtracker@ietfa.amsl.com> <07b9bcea-72e3-9986-7d42-303c4797f13a@ericsson.com> <2a796f78-41b7-376c-8f51-215d14cc4e2c@cisco.com> 
From: Joe Clarke 
Openpgp: preference=signencrypt
Autocrypt: addr=jclarke@cisco.com; prefer-encrypt=mutual; keydata= xsDiBDo1cJ0RBADSZSmbmzdRr1CoRWWKmAyu0eaQimaLV1TsZEML/ksLyg6faXrKIA/MWc7M w4FmKkDjaZdFzobzabnKp2QwVadLqi1gYY2WsApKC0rSoqsPx5E847AmwNWXgjXiXORXmnZL mf5PZ2ECOEJC27sji5Nrh9GSw7OPp6c+EE20gMNVrwCgu3iK5vyGQfy0/wX/jcIvP0nHznUD /RvijiKomyaf6F5pibmouFNeuCDHc8lwx2giA/MCZl/nSkI2/UX27sULGNgvKNkVPu/AukXu zW3fIthsJgjQZUoi/BTe9kUP+RL3+RALXXuLv7b3xGRHJ8A1Rpy9H43fkjHZ945YNPrUvJlG LP5PNGBD1xC21X3EGAyywVynDskcA/4qgbJFkVzmPjFJUjq+RW1zw3UIb3bbkskl/wk5qd+M w2EhiSPTbEhJQAQUvqSGFWEGp2ANic7iYLdPXV/O6I1/guRRaY0eK77YkkCjz1snaKYnGSeI GHGwmHb6D+ZHzTqZqr6IssgEIUHjXfgOUTARQbL15nJTVRzDGUiT/65R3c0eSm9lIENsYXJr ZSA8amNsYXJrZUBjaXNjby5jb20+wl8EExECABcFAjyDqGQFCwcKAwQDFQMCAxYCAQIXgAAS CRDN7TXCWm4C3wdlR1BHAAEB5KkAn0kBda/9+uF6RfnDSFS7RExUU9DqAJ4knRckYiSASteC K03QVtEiXblL287ATQQ6NXCeEAQAhIURlK17jmIMdMIuScFU6xK+jkKgVVFrjlRH5vLV2spp jH/uQ57MMGuOcs7PckXCnPjBV8Tm32Tuw+fCyrbc2gt0ouiT/5WWj0EMeAfWew1zBXX2okGf LqS6gucVDS6tcEFN6PmJEmX+tWDcmiqx/xXiSfMVYiLMdlK+YDkMDDsAAwUD/3BWOyfdnBGH Kv28zx+5wq/2vhYnUYCAdVD2ZWCJizQTMbkcxEIKAwtAj6yqKq9ah82nt4VHl5ZejVe47jvR 2nXwJ5VQ9eITuTjTLDw+3qr9lN077VZ32hyb5ULJcW756j9Z3YB2FTANw6KHgChaSVVx9kYJ FlAggraU7mi39/wvwk4EGBECAAYFAjo1cJ4AEgkQze01wlpuAt8HZUdQRwABAQbdAJ9R8SzU Mluu9r93BMv6fAW9j6qTZgCfYcEAqOMJv+3Z+YxLiDtWcCY4Sfo=
Organization: Cisco
Message-ID: <1727baad-06a5-d3e8-dce5-48f211b45644@cisco.com>
Date: Wed, 28 Nov 2018 09:35:55 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Outbound-SMTP-Client: 10.118.87.85, rtp-jclarke-nitro4.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: 
Subject: Re: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2018 14:35:59 -0000

On 11/23/18 07:48, Balázs Lengyel wrote:
>> Do you have to register the ".yid" file extension as well?
> BALAZS: Is there a registry for file extensions? I was not aware.

RFC6020 section 14 registers media types that include file extensions
for .yin and .yang.  I am asking are you proposing to do the same and
registering something like application/yang-instance-data with a .yid
extension?

Joe


From nobody Wed Nov 28 06:48:16 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFD9130E4A for ; Wed, 28 Nov 2018 06:48:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EFUt-u1LGQ7g for ; Wed, 28 Nov 2018 06:48:11 -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 6BF8C12D4E6 for ; Wed, 28 Nov 2018 06:48:11 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 151BBED7; Wed, 28 Nov 2018 15:48:10 +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 HgVQ8Uzmvmz4; Wed, 28 Nov 2018 15:48:10 +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, 28 Nov 2018 15:48:10 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F34882003F; Wed, 28 Nov 2018 15:48:09 +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 OIR0dljzz7pi; Wed, 28 Nov 2018 15:48:09 +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 7BB3720037; Wed, 28 Nov 2018 15:48:09 +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, 28 Nov 2018 15:48:08 +0100
Received: by anna.localdomain (Postfix, from userid 501) id B5A0F3004585DC; Wed, 28 Nov 2018 15:48:08 +0100 (CET)
Date: Wed, 28 Nov 2018 15:48:08 +0100
From: Juergen Schoenwaelder 
To: Joe Clarke 
CC: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod@ietf.org" 
Message-ID: <20181128144808.s3cbepy6rw7sqoce@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Joe Clarke , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , "netmod@ietf.org" 
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>
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: <1727baad-06a5-d3e8-dce5-48f211b45644@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] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2018 14:48:15 -0000

On Wed, Nov 28, 2018 at 09:35:55AM -0500, Joe Clarke wrote:
> On 11/23/18 07:48, Balzs Lengyel wrote:
> >> Do you have to register the ".yid" file extension as well?
> > BALAZS: Is there a registry for file extensions? I was not aware.
> 
> RFC6020 section 14 registers media types that include file extensions
> for .yin and .yang.  I am asking are you proposing to do the same and
> registering something like application/yang-instance-data with a .yid
> extension?
>

Isn't this just json and xml? If we need specific media types, I think
it would be two.

In theory, it would be even nicer if the document would be written in
such a way that it works with any (future) encoding. The way things
are defined today, by referring to responses of specific protocol
operations, is a bit odd. Does it matter whether the XML is returned
by a NETCONF  or RESTCONF/HTTP GET? Ideally, the format of
the instance files would be coming out of the data encoding
specifications (plus the architectural framework of datastores).

/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 Nov 28 07:27: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 256BF130FBE for ; Wed, 28 Nov 2018 07:27:32 -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 lP9W4Bur4GiM for ; Wed, 28 Nov 2018 07:27:30 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D73D130F90 for ; Wed, 28 Nov 2018 07:27:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2569; q=dns/txt; s=iport; t=1543418850; x=1544628450; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=zoa802mwjgRl23pa+zeg0GxTzEGjH4YBPygfpff9O04=; b=faLouLsP/pgNJ9ceWn9kHyzqpIypYW0QWunQU1bK6Iu0tRScIxgYXm2h bPowoueYLQuNByvFuJPp40QNty9pcEd6b+6/ea7lJ03PQ/Oa360DbQk3m HnHVcfF/0X8wCwQ/JABvqH9Myzb7VnYJDrTfG/IOl+uvgsFylk5vZZ4nH c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACFsv5b/xbLJq1bCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYM4IRKEIIgYX40KLZdCgXoNgXeCdQK?= =?us-ascii?q?DTjQJDQEDAQECAQECbSiFPAEBAQECASMPAQVRCxgCAiYCAlcGAQwIAQGDHYF?= =?us-ascii?q?6CKZegS+FQIR8gQuLIoFAP4ERJ4I9LoRXgy6CVwKJBZcWCZErBhiJaIctiHa?= =?us-ascii?q?IboZkgUY4gVUzGggbFYMokFo/A45qAQE?=
X-IronPort-AV: E=Sophos;i="5.56,291,1539648000";  d="scan'208";a="8388663"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Nov 2018 15:27:28 +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 wASFRQMT007362; Wed, 28 Nov 2018 15:27:27 GMT
To: =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= , Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" 
References: <87y3a6izap.fsf@nic.cz> <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de> <58740c15bf3277e04329546476f60c1d12516594.camel@nic.cz> <20181106.104157.239419955739949818.mbj@tail-f.com> <866ff105cf8fda7eadbdce5b344f4cd734fd99b8.camel@nic.cz> <1f4103c1-4953-3df4-d50d-aed1961fbc50@ericsson.com> <20181123154951.anviss5nllq6gwrn@anna.jacobs.jacobs-university.de>  <20181128102050.37iyrx2xhdohnepb@anna.jacobs.jacobs-university.de>
From: Robert Wilton 
Message-ID: 
Date: Wed, 28 Nov 2018 15:27:26 +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: <20181128102050.37iyrx2xhdohnepb@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-4.cisco.com
Archived-At: 
Subject: Re: [netmod] Datastore leaf for yang instance data
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2018 15:27:41 -0000

On 28/11/2018 10:20, Juergen Schoenwaelder wrote:
> On Wed, Nov 28, 2018 at 09:41:12AM +0000, Balázs Lengyel wrote:
>>> I do not buy this story. Your software needs to decide somehow what
>>> instance data means. A config true leaf in candidate means something
>>> different than the same config true leaf in running and this yet again
>>> means something different than the same config true leaf in operational.
>>>
>>> /js
>> BALAZS: As I understood the WG decided that this draft should only be about
>> the format of the yang instance data. What the SW does with it is out of
>> scope. So considerations whether instance data should be loaded into running
>> or candidate or not at all, are outside the scope.
> If you do not know what the instance data means, any attempt to use it
> is kind of broken.
>   
>> I want to provide a datastore indicator, but how that should be used (and
>> thus what is exactly means) is out of scope.
> I disagree. The datastore indicator is needed to understand what the
> data means, i.e., to do anything meaningful with it.

I think that a datastore indicator is useful sometimes.  E.g. it might 
be helpful in some cases to know that the data was associated with a 
particular datastore.

But in the general case I think that this is just "data at rest", and 
probably the key thing to know is whether (i) the data relates to 
configuration, or (ii) the data relates to operational state.

This could potentially be inferred from a datastore leaf, or perhaps 
this distinction could more explicitly be made by a separate field, 
which I would make an enumeration or identity, since there might be 
other types of data in future, such as capability information or 
diagnostics.

Thanks,
Rob


>
>> Anyway in some cases it would be problematic to define a single datastore
>> parameter. E.g. the draft allows the real world use case of putting config
>> and state data in the same file. In this case state data is associated with
>> operational while config data is with running/candidate. In the non-NMDA
>> case I do not even know what the correct daatastore is for state data.
> We created NMDA because mixing  with  is broken
> in a number of cases. I am fine to accept that the datastore indicator
> may be absent paired with a clear warning that in this case it is
> undefined what the data means. (And I will hope that robust
> implementations will avoid working with data that has unclear
> semantics or at least generate warnings.)
>
> /js
>


From nobody Wed Nov 28 07:32:24 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDB8128CF3 for ; Wed, 28 Nov 2018 07:32:22 -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 5C1skv9GCdue for ; Wed, 28 Nov 2018 07:32: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 5BA07130E12 for ; Wed, 28 Nov 2018 07:32:18 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 0EBBBEBD; Wed, 28 Nov 2018 16:32:17 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 8nG74AmBMiSi; Wed, 28 Nov 2018 16:32:17 +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, 28 Nov 2018 16:32:17 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAF0E2003F; Wed, 28 Nov 2018 16:32:16 +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 ybbFUezsGKab; Wed, 28 Nov 2018 16:32:16 +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 5934F20037; Wed, 28 Nov 2018 16:32:16 +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, 28 Nov 2018 16:32:15 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 9004D3004588F5; Wed, 28 Nov 2018 16:32:15 +0100 (CET)
Date: Wed, 28 Nov 2018 16:32:15 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
CC: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" 
Message-ID: <20181128153215.og7yweannmux35ti@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" 
References: <87y3a6izap.fsf@nic.cz> <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de> <58740c15bf3277e04329546476f60c1d12516594.camel@nic.cz> <20181106.104157.239419955739949818.mbj@tail-f.com> <866ff105cf8fda7eadbdce5b344f4cd734fd99b8.camel@nic.cz> <1f4103c1-4953-3df4-d50d-aed1961fbc50@ericsson.com> <20181123154951.anviss5nllq6gwrn@anna.jacobs.jacobs-university.de>  <20181128102050.37iyrx2xhdohnepb@anna.jacobs.jacobs-university.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Datastore leaf for yang instance data
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2018 15:32:23 -0000

On Wed, Nov 28, 2018 at 03:27:26PM +0000, Robert Wilton wrote:
> 
> On 28/11/2018 10:20, Juergen Schoenwaelder wrote:
> > On Wed, Nov 28, 2018 at 09:41:12AM +0000, Balzs Lengyel wrote:
> > > > I do not buy this story. Your software needs to decide somehow what
> > > > instance data means. A config true leaf in candidate means something
> > > > different than the same config true leaf in running and this yet again
> > > > means something different than the same config true leaf in operational.
> > > > 
> > > > /js
> > > BALAZS: As I understood the WG decided that this draft should only be about
> > > the format of the yang instance data. What the SW does with it is out of
> > > scope. So considerations whether instance data should be loaded into running
> > > or candidate or not at all, are outside the scope.
> > If you do not know what the instance data means, any attempt to use it
> > is kind of broken.
> > > I want to provide a datastore indicator, but how that should be used (and
> > > thus what is exactly means) is out of scope.
> > I disagree. The datastore indicator is needed to understand what the
> > data means, i.e., to do anything meaningful with it.
> 
> I think that a datastore indicator is useful sometimes. E.g. it might be
> helpful in some cases to know that the data was associated with a particular
> datastore.
> 
> But in the general case I think that this is just "data at rest", and
> probably the key thing to know is whether (i) the data relates to
> configuration, or (ii) the data relates to operational state.
> 
> This could potentially be inferred from a datastore leaf, or perhaps this
> distinction could more explicitly be made by a separate field, which I would
> make an enumeration or identity, since there might be other types of data in
> future, such as capability information or diagnostics.
>

I do not understand why a datastore leaf is not sufficient and why we
need yet something new. If ever needed, NMDA does allow us to define
new datastores.

/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 Nov 28 07:43: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 57F5E12D4E6 for ; Wed, 28 Nov 2018 07:43:07 -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 GEop7c2quH2W for ; Wed, 28 Nov 2018 07:43:05 -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 58496128CF3 for ; Wed, 28 Nov 2018 07:43:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2717; q=dns/txt; s=iport; t=1543419785; x=1544629385; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=8/sWFS21+N5ZEq+3WEn8EBFci4lgO+g5DqW4jFPmtnY=; b=LHG5WP5oKlWh/2o39P8KYcKZIGN50qSn/CGcAbeBq4eZyO/PbicFylI8 3iMPOdkSrw1oTxghhlQRvcICF1rSYAnCDds2E5h+TFl2S127+HUofKPp3 oU3J3CjyIYw7T9w6ro7Y6b/ZdoITw3VkhYVeI74oNdZQpfqO3wlyGHxZH s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABAtv5b/xbLJq1bCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYM4IRKEIIgYX40KCCWXQoF6DYF3gnU?= =?us-ascii?q?Cg040CQ0BAwEBAgEBAm0ohT0BBSMPAQVRCxgCAiYCAlcGAQwIAQGDHYICpm6?= =?us-ascii?q?BL4VAhHyBC4sigUA/gREnDIIxLoRXgy6CVwKVRYpWCZErBhiJaIctiHaIboZ?= =?us-ascii?q?kgUY4gVUzGggbFYMokFo/A45qAQE?=
X-IronPort-AV: E=Sophos;i="5.56,291,1539648000";  d="scan'208";a="8449908"
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; 28 Nov 2018 15:43: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 wASFh1rF022341; Wed, 28 Nov 2018 15:43:02 GMT
To: =?UTF-8?Q?Bal=c3=a1zs_Lengyel?= , Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" 
References: <87y3a6izap.fsf@nic.cz> <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de> <58740c15bf3277e04329546476f60c1d12516594.camel@nic.cz> <20181106.104157.239419955739949818.mbj@tail-f.com> <866ff105cf8fda7eadbdce5b344f4cd734fd99b8.camel@nic.cz> <1f4103c1-4953-3df4-d50d-aed1961fbc50@ericsson.com> <20181123154951.anviss5nllq6gwrn@anna.jacobs.jacobs-university.de>  <20181128102050.37iyrx2xhdohnepb@anna.jacobs.jacobs-university.de>  <20181128153215.og7yweannmux35ti@anna.jacobs.jacobs-university.de>
From: Robert Wilton 
Message-ID: 
Date: Wed, 28 Nov 2018 15:43:01 +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: <20181128153215.og7yweannmux35ti@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-2.cisco.com
Archived-At: 
Subject: Re: [netmod] Datastore leaf for yang instance data
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2018 15:43:08 -0000

On 28/11/2018 15:32, Juergen Schoenwaelder wrote:
> On Wed, Nov 28, 2018 at 03:27:26PM +0000, Robert Wilton wrote:
>> On 28/11/2018 10:20, Juergen Schoenwaelder wrote:
>>> On Wed, Nov 28, 2018 at 09:41:12AM +0000, Balázs Lengyel wrote:
>>>>> I do not buy this story. Your software needs to decide somehow what
>>>>> instance data means. A config true leaf in candidate means something
>>>>> different than the same config true leaf in running and this yet again
>>>>> means something different than the same config true leaf in operational.
>>>>>
>>>>> /js
>>>> BALAZS: As I understood the WG decided that this draft should only be about
>>>> the format of the yang instance data. What the SW does with it is out of
>>>> scope. So considerations whether instance data should be loaded into running
>>>> or candidate or not at all, are outside the scope.
>>> If you do not know what the instance data means, any attempt to use it
>>> is kind of broken.
>>>> I want to provide a datastore indicator, but how that should be used (and
>>>> thus what is exactly means) is out of scope.
>>> I disagree. The datastore indicator is needed to understand what the
>>> data means, i.e., to do anything meaningful with it.
>> I think that a datastore indicator is useful sometimes.  E.g. it might be
>> helpful in some cases to know that the data was associated with a particular
>> datastore.
>>
>> But in the general case I think that this is just "data at rest", and
>> probably the key thing to know is whether (i) the data relates to
>> configuration, or (ii) the data relates to operational state.
>>
>> This could potentially be inferred from a datastore leaf, or perhaps this
>> distinction could more explicitly be made by a separate field, which I would
>> make an enumeration or identity, since there might be other types of data in
>> future, such as capability information or diagnostics.
>>
> I do not understand why a datastore leaf is not sufficient and why we
> need yet something new. If ever needed, NMDA does allow us to define
> new datastores.

Because a distinction between "candidate" vs "running" vs "intended" 
won't necessarily be that useful.  Although knowing "running" vs 
"intended" would allow the client to know whether it is pre/post 
template expansion and that might be useful.

The second reason is that I don't know whether things like capabilities 
and diagnostics will be new datastores or just part of operational.  I 
don't think that either of these two areas have really been properly 
worked out yet.  I presume that they will come over time, once more 
network management becomes more automated.

Thanks,
Rob


>
> /js
>


From nobody Wed Nov 28 08:03:44 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5783D130DCD for ; Wed, 28 Nov 2018 08:03:39 -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 SZ-CXGh9N2kC for ; Wed, 28 Nov 2018 08:03:35 -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 4BAAF130DCE for ; Wed, 28 Nov 2018 08:03:31 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id DF0E5ED7; Wed, 28 Nov 2018 17:03:29 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id lL434M2vQFoR; Wed, 28 Nov 2018 17:03:29 +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, 28 Nov 2018 17:03:29 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C710620037; Wed, 28 Nov 2018 17:03:29 +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 yJNcXu62GpZ7; Wed, 28 Nov 2018 17:03:29 +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 440E120044; Wed, 28 Nov 2018 17:03:29 +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, 28 Nov 2018 17:03:28 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 791BB300458B98; Wed, 28 Nov 2018 17:03:27 +0100 (CET)
Date: Wed, 28 Nov 2018 17:03:27 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
CC: =?utf-8?Q?Bal=C3=A1zs?= Lengyel , Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" 
Message-ID: <20181128160327.dd2f4ftjslnvwxad@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , =?utf-8?Q?Bal=C3=A1zs?= Lengyel , Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" 
References: <58740c15bf3277e04329546476f60c1d12516594.camel@nic.cz> <20181106.104157.239419955739949818.mbj@tail-f.com> <866ff105cf8fda7eadbdce5b344f4cd734fd99b8.camel@nic.cz> <1f4103c1-4953-3df4-d50d-aed1961fbc50@ericsson.com> <20181123154951.anviss5nllq6gwrn@anna.jacobs.jacobs-university.de>  <20181128102050.37iyrx2xhdohnepb@anna.jacobs.jacobs-university.de>  <20181128153215.og7yweannmux35ti@anna.jacobs.jacobs-university.de> 
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB01.jacobs.jacobs-university.de (10.70.0.120) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] Datastore leaf for yang instance data
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2018 16:03:40 -0000

On Wed, Nov 28, 2018 at 03:43:01PM +0000, Robert Wilton wrote:
> 
> > > 
> > I do not understand why a datastore leaf is not sufficient and why we
> > need yet something new. If ever needed, NMDA does allow us to define
> > new datastores.
> 
> Because a distinction between "candidate" vs "running" vs "intended" won't
> necessarily be that useful. Although knowing "running" vs "intended" would
> allow the client to know whether it is pre/post template expansion and that
> might be useful.

I think it is. I would also assume that the need to save 
instance data in a file is rare. So its likely  or 
and for some systems the difference is small, for others it may not be
small. My point is we have a way to distinguish things and we should
use that instead of creating something new that lumps things together
again.
 
> The second reason is that I don't know whether things like capabilities and
> diagnostics will be new datastores or just part of operational. I don't
> think that either of these two areas have really been properly worked out
> yet. I presume that they will come over time, once more network management
> becomes more automated.

By default this is all . The schema (aka YANG library)
exists in  already today. I do not know what your
definition of 'diagnostics' is but until we have something else, I
assume this is in . And yes, if systems have other
creative datastores, we have a way to deal with that as well. Its all
there and I am afraid that creating yet another way to classify data
just adds pain and brings back ambiguity.

/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 Nov 28 10:47:27 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1FDB128A6E; Wed, 28 Nov 2018 10:47:25 -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 9N16_HkjEjtI; Wed, 28 Nov 2018 10:47:23 -0800 (PST)
Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 9F422127B92; Wed, 28 Nov 2018 10:47:23 -0800 (PST)
Received: by mail-pf1-x42b.google.com with SMTP id q1so10606655pfi.5; Wed, 28 Nov 2018 10:47:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ydON4NP8uco80j5bR2Q1olgsATzmIL6mpXz6s250bPE=; b=uAMcGJyqm9GUQB19UJ66hmB81G6ZpsMEyPyuCbpLYRJ1cJh/39xRB/7IDlXapuxuP+ cFlSArGDjUsNSaHmwq6ngAY9eBFg+biWLUMvG37+NW0f1IHgqikeFnq385yIIEncn5tS mr2hJ67hRRUwKyM2M6O0Zc9ZD9eHEfysGUFYw+ChmiUNZZ1Vod8Ex1R9NMFzhM8dOSan jNCsq9RXgf6DSFogyltFoR0d5RvblkYQZPrMAgGT5RFGPR4N8wyxMSOMSBNQlBE7GnsU OTrW1tpxDhBzinAhiBKhtbFd/REU8wG9R1DLX0B4Zy4m4gFpikauiED0XfEzXJho4omH xwZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ydON4NP8uco80j5bR2Q1olgsATzmIL6mpXz6s250bPE=; b=NZFhE2DuHSlrvBy4vmKcQTotoSATJkhLsSXMbbSO7gwNBbXJjfuTQCJkfr4ugfI4Nx xQqaFTMz37m5jRx2NpMZF7utFgNBbMRWSxdlJ8VGy3xGqoqbHvOwP4g/84cUqav3bCu4 N3xHNQAjADX261Sfhf643nNicbrsLCmqobVlMaOua8qraY3XL/p3L5RyxJ8TxUxoZWUj d33ma4V8dLLghuEW2zDIO8UWFNIBkzjNWMdi6QMZAmxfBnlQf8COZ8I5cweHgQjkFQ3R +Rta4h+enXvZU4/6RfVh6GNiIQ8Ahs0E/ndReWW/Rdtq9c7LCaME8D8fRZlGCudvB3Ug hV6g==
X-Gm-Message-State: AA+aEWbHxsncL+dOfS8Tk8CecFrVYQS4hPTDnWku55OMV7K1yDzZHU8V l48cqDeeVUJuABVdwWQP+wg=
X-Google-Smtp-Source: AFSGD/WcK3JwUrG+KCKGHR6u18sVj+JY3qTMAv3QbJadcFN+C5JzCJX0xICUQrl+9NiPvcR71XM1Sw==
X-Received: by 2002:a63:de46:: with SMTP id y6mr34085805pgi.198.1543430842881;  Wed, 28 Nov 2018 10:47:22 -0800 (PST)
Received: from ?IPv6:2620:11a:c081:20:7c90:350:6a48:2cdd? ([2620:11a:c081:20:7c90:350:6a48:2cdd]) by smtp.gmail.com with ESMTPSA id e128sm9566391pfe.67.2018.11.28.10.47.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Nov 2018 10:47:22 -0800 (PST)
From: joel jaeggli 
Message-Id: <279221F5-F11A-449B-A99F-49008325FF7B@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7847B016-29FF-481A-A68D-943D6AA7AA07"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
Date: Wed, 28 Nov 2018 10:47:18 -0800
In-Reply-To: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>
Cc: NETMOD Working Group , draft-ietf-netmod-module-tags.authors@ietf.org
To: Joel Jaeggli 
References: <8C4CE813-D0D1-4F4F-B813-B451D9A8D8DF@gmail.com>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: 
Subject: Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Nov 2018 18:47:26 -0000

--Apple-Mail=_7847B016-29FF-481A-A68D-943D6AA7AA07
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

This confirms the completion of this period.

I think we can conclude the following:

The Question of whether better guidance for usage can be applied was =
raised and discussed. Robert Wilton proposed some text which seems both =
reasonable and which does not change the substance of the draft.

The Question of where tags reside was raised, it appears resolved.

=46rom the meeting, there remains the request for the addition of an =
example.

Kent - can we add an example

Chris - what format would you like it in.

Kent: xml/netconf or json/restconf is fine, just identify which is used.

On this basis I think we can do a writeup and forward a draft 04 to the =
IESG for review / IETF last call.

Thanks=20
Joel=20

> On Nov 12, 2018, at 08:46, joel jaeggli  wrote:
>=20
> During the Thursday nov 8 session of netmod, we asked if there were =
any objections to the publication of the Draft-03 version of =
draft-ietf-netmod-module-tags which addresses comments and concerns =
raised during the WGLC. In the meeting there were none. This commences a =
comment period to confirm that call. As this follows closely on the =
heels of the IETF 103 meeting we=E2=80=99ll let the call run through =
Monday the 26th of November.=20
>=20
> =
https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-module-tags-03.txt=

>=20
>=20
> Thanks
> Joel
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20


--Apple-Mail=_7847B016-29FF-481A-A68D-943D6AA7AA07
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

This =
confirms the completion of this period.

I think we can conclude the =
following:

The =
Question of whether better guidance for usage can be applied was raised =
and discussed. Robert Wilton proposed some text which seems both =
reasonable and which does not change the substance of the =
draft.

The =
Question of where tags reside was raised, it appears resolved.

=46rom the meeting, =
there remains the request for the addition of an example.

Kent - can we add an example

Chris - what format would you like it in.

Kent: xml/netconf or json/restconf is fine, just identify =
which is used.

On this basis I think we can do a =
writeup and forward a draft 04 to the IESG for review / IETF last =
call.

Thanks 
Joel 

On Nov 12, 2018, at 08:46, joel jaeggli <joelja@gmail.com> =
wrote:

During the Thursday nov 8 session of netmod, we asked if =
there were any objections to the publication of the Draft-03 version of =
draft-ietf-netmod-module-tags which addresses comments and concerns =
raised during the WGLC. In the meeting there were none. This commences a =
comment period to confirm that call. As this follows closely on the =
heels of the IETF 103 meeting we=E2=80=99ll let the call run through =
Monday the 26th of November. 

https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-module-=
tags-03.txt


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


=

--Apple-Mail=_7847B016-29FF-481A-A68D-943D6AA7AA07--


From nobody Wed Nov 28 17:53: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 B91D712D4F1 for ; Wed, 28 Nov 2018 17:53:52 -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 7uOcmzpl3kkG for ; Wed, 28 Nov 2018 17:53:50 -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 57C68129AB8 for ; Wed, 28 Nov 2018 17:53:50 -0800 (PST)
Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1923D22970069; Thu, 29 Nov 2018 01:53:46 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 29 Nov 2018 01:53:46 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.69]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0415.000; Thu, 29 Nov 2018 09:53:42 +0800
From: Qin Wu 
To: Joe Clarke , =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= , "netmod@ietf.org" 
Thread-Topic: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt
Thread-Index: AQHUdXYipV5hG5p2iUu/shgjxloKo6VCDTMA//+CaQCAG1UTAIAH+Z+AgAFCCyA=
Date: Thu, 29 Nov 2018 01:53:42 +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>
In-Reply-To: <1727baad-06a5-d3e8-dce5-48f211b45644@cisco.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] Fwd: New Version Notification for draft-ietf-netmod-yang-instance-file-format-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Nov 2018 01:53:53 -0000

VGhlIGFiYnJldmlhdGlvbiBvZiBZQU5HIGluc3RhbmNlIGRhdGEgeWlkIG1heSBjb25mdXNlIHdp
dGggWUFORyBpZGVudGl0aWZlciBzaG9ydCBuYW1lDQoiDQogICBZQU5HIElkZW50aWZpZXI6ICBO
dW1lcmljIG9iamVjdCBpZGVudGlmaWVyLCB3aGljaCBpcyBhIGZpeGVkLWxlbmd0aA0KICAgICAg
bnVtZXJpYyB2YWx1ZSB0aGF0IHJlcHJlc2VudHMgYSBwYXJ0aWN1bGFyIHNjaGVtYSBub2RlIHdp
dGhpbiBhDQogICAgICBZQU5HIG1vZHVsZSBzY2hlbWEgdHJlZS4gIFRoZSBsZW5ndGggYW5kIGZv
cm1hdCBvZiBhIFlBTkcNCiAgICAgIGlkZW50aWZpZXIgYXJlIGRlZmluZWQgaW4gdGhlIFlBTkcg
SWRlbnRpZmllciBSZWdpc3RyeS4gIEFsc28NCiAgICAgIGNhbGxlZCBhICJZSUQiLg0KIg0KSSBi
ZWxpZXZlIHRoZXkgYXJlIG5vdCBzYW1lIHRoaW5nLg0KDQotUWluDQotLS0tLemCruS7tuWOn+S7
ti0tLS0tDQrlj5Hku7bkuro6IG5ldG1vZCBbbWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3Jn
XSDku6PooaggSm9lIENsYXJrZQ0K5Y+R6YCB5pe26Ze0OiAyMDE45bm0MTHmnIgyOOaXpSAyMjoz
Ng0K5pS25Lu25Lq6OiBCYWzDoXpzIExlbmd5ZWw7IG5ldG1vZEBpZXRmLm9yZw0K5Li76aKYOiBS
ZTogW25ldG1vZF0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYt
bmV0bW9kLXlhbmctaW5zdGFuY2UtZmlsZS1mb3JtYXQtMDAudHh0DQoNCk9uIDExLzIzLzE4IDA3
OjQ4LCBCYWzDoXpzIExlbmd5ZWwgd3JvdGU6DQo+PiBEbyB5b3UgaGF2ZSB0byByZWdpc3RlciB0
aGUgIi55aWQiIGZpbGUgZXh0ZW5zaW9uIGFzIHdlbGw/DQo+IEJBTEFaUzogSXMgdGhlcmUgYSBy
ZWdpc3RyeSBmb3IgZmlsZSBleHRlbnNpb25zPyBJIHdhcyBub3QgYXdhcmUuDQoNClJGQzYwMjAg
c2VjdGlvbiAxNCByZWdpc3RlcnMgbWVkaWEgdHlwZXMgdGhhdCBpbmNsdWRlIGZpbGUgZXh0ZW5z
aW9ucyBmb3IgLnlpbiBhbmQgLnlhbmcuICBJIGFtIGFza2luZyBhcmUgeW91IHByb3Bvc2luZyB0
byBkbyB0aGUgc2FtZSBhbmQgcmVnaXN0ZXJpbmcgc29tZXRoaW5nIGxpa2UgYXBwbGljYXRpb24v
eWFuZy1pbnN0YW5jZS1kYXRhIHdpdGggYSAueWlkIGV4dGVuc2lvbj8NCg0KSm9lDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGlu
ZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vbmV0bW9kDQo=


From nobody Thu Nov 29 03:03: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 9A4271292F1 for ; Thu, 29 Nov 2018 03:03:50 -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 jFP8Vl_S7Pze for ; Thu, 29 Nov 2018 03:03:48 -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 2495F128C65 for ; Thu, 29 Nov 2018 03:03:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3157; q=dns/txt; s=iport; t=1543489428; x=1544699028; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=m+8ZRpFD4S8MmwfgskjU2Y+iYSx5LU5FbAGVQZTQ/RA=; b=NXtMxa9feQ0dyVfq7evEHuIOkCbQOf50zYDyj8aRbI0kdGI/vpKU9DE6 yQiK2hJft3rPi7lamdgLIPeJtpIASkTNElW+SQtge2LBIoaOt6/V2XSOl GYPQRR99KoYgsulDgYgKSKWlx6Q3hNHZY6djfqoBT/Cvr+CvVGhzVKgP5 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAAOx/9b/xbLJq1iAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYJpTzMng3mIGF+NCQgll0KBeg0YC4Q?= =?us-ascii?q?DRgKDUzQJDQEDAQECAQECbRwMhTwBAQEBAwEBIQ8BBTYZAgsQAQQBAQECAiY?= =?us-ascii?q?CAhsMKAgGAQwGAgEBgx0BggEPph+BL4VAhGgFBYEGiyKBQD+BEScMgl+DHgE?= =?us-ascii?q?BggImgj2CVwKgIwmRLAYYiWiHNIh4iHCGZIFGOIFVMxoIGxU7gmyGO4RhhT8?= =?us-ascii?q?/AzCOPwEB?=
X-IronPort-AV: E=Sophos;i="5.56,294,1539648000";  d="scan'208";a="8464094"
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; 29 Nov 2018 11:03:45 +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 wATB3joW015789; Thu, 29 Nov 2018 11:03:45 GMT
To: "j.schoenwaelder@jacobs-university.de" , netmod@ietf.org
References: <20181113140709.vwc4f3mqmmgjaluu@anna.jacobs.jacobs-university.de> <091DC7F4-0C17-4E64-85B8-8963EFBC208B@cisco.com> <1542152721437.91451@Aviatnet.com> <20181114.091024.1454093230497622054.mbj@tail-f.com> 
From: Robert Wilton 
Message-ID: 
Date: Thu, 29 Nov 2018 11:03:45 +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: 
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] 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: Thu, 29 Nov 2018 11:03:50 -0000

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


From nobody Thu Nov 29 08:35:12 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618C3130E52 for ; Thu, 29 Nov 2018 08:35:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 aQZTgYQK7hFp for ; Thu, 29 Nov 2018 08:35:02 -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 A7E9A130E4A for ; Thu, 29 Nov 2018 08:35:01 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 3C578F36; Thu, 29 Nov 2018 17:35:00 +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 Crmi4OavPUue; Thu, 29 Nov 2018 17:35:00 +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, 29 Nov 2018 17:35:00 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F18232003F; Thu, 29 Nov 2018 17:34: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 06iNmcRi08rh; Thu, 29 Nov 2018 17:34:59 +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 5ECD520037; Thu, 29 Nov 2018 17:34:59 +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, 29 Nov 2018 17:34:58 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 89AE0300487092; Thu, 29 Nov 2018 17:34:57 +0100 (CET)
Date: Thu, 29 Nov 2018 17:34:57 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
CC: 
Message-ID: <20181129163457.unituasc6srf5ayi@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , netmod@ietf.org
References: <20181113140709.vwc4f3mqmmgjaluu@anna.jacobs.jacobs-university.de> <091DC7F4-0C17-4E64-85B8-8963EFBC208B@cisco.com> <1542152721437.91451@Aviatnet.com> <20181114.091024.1454093230497622054.mbj@tail-f.com>  
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB02.jacobs.jacobs-university.de (10.70.0.121) 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: Thu, 29 Nov 2018 16:35:12 -0000

Rob,

I have added this to my list of things to look at. Whether we do this
or not may also depend on how the final date solution will look like
and whether people feel it is worth to move this out of rfc6991bis,
i.e., such a YANG revision-identifer is useful for modules that do
not want to depend on rfc6991bis.

/js

On Thu, Nov 29, 2018 at 11:03:45AM +0000, 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

-- 
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 Nov 29 08:43: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 02D79130DCD for ; Thu, 29 Nov 2018 08:43:07 -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 7ePQEx_keoU5 for ; Thu, 29 Nov 2018 08:43:04 -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 689C3129385 for ; Thu, 29 Nov 2018 08:43:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3890; q=dns/txt; s=iport; t=1543509784; x=1544719384; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=WOf679kdcSVJlX4HOlGOf0kSL4f+E443r5SFTmNhPw0=; b=cc2KGYOxtsZZ2aXbw9OaxYVAqyvhrpBRoDhM2TYE3IiME62E83m3Qyhu JCax6ejvYUZJCfl/UiKSlwCPoy+XBEEU3vv1JkS+3C9urWFfGIlE23DWh zFxqMn9if4HGaiOYw9nNx5x+Y5L69tJNA+v7IiBSAw7CFlKzsesrxPVEk 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADJFQBc/xbLJq1hAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYJpTzMng3mIGF+NCQgll0SBeg0YC4Q?= =?us-ascii?q?DRgKDVDQJDQEDAQECAQECbRwMhTwBAQEEAQEhDwEFNhkCCxABBAEBAQICJgI?= =?us-ascii?q?CGwwoCBMGAgEBF4MGAYIBD6Y8gS+FQIRmBQWBBosigUA/gREnDIJfgx4BAYI?= =?us-ascii?q?CJoI9glcCoCMJkSwGGIlohzSRaYZlgUY4gVUzGggbFTuCbIY7hGGFPz8DMI5?= =?us-ascii?q?BAQE?=
X-IronPort-AV: E=Sophos;i="5.56,295,1539648000";  d="scan'208";a="8471695"
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; 29 Nov 2018 16:43:02 +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 wATGh2TN002099 for ; Thu, 29 Nov 2018 16:43:02 GMT
To: netmod@ietf.org
References: <20181113140709.vwc4f3mqmmgjaluu@anna.jacobs.jacobs-university.de> <091DC7F4-0C17-4E64-85B8-8963EFBC208B@cisco.com> <1542152721437.91451@Aviatnet.com> <20181114.091024.1454093230497622054.mbj@tail-f.com>   <20181129163457.unituasc6srf5ayi@anna.jacobs.jacobs-university.de>
From: Robert Wilton 
Message-ID: 
Date: Thu, 29 Nov 2018 16:43:01 +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: <20181129163457.unituasc6srf5ayi@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-2.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: Thu, 29 Nov 2018 16:43:07 -0000

On 29/11/2018 16:34, Juergen Schoenwaelder wrote:
> Rob,
>
> I have added this to my list of things to look at. Whether we do this
> or not may also depend on how the final date solution will look like
> and whether people feel it is worth to move this out of rfc6991bis,
> i.e., such a YANG revision-identifer is useful for modules that do
> not want to depend on rfc6991bis.

Thanks.  Sounds sensible to me.

Rob


>
> /js
>
> On Thu, Nov 29, 2018 at 11:03:45AM +0000, 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


From nobody Thu Nov 29 17:30: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 75752124408 for ; Thu, 29 Nov 2018 17:29:57 -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 FpySxgoCSDmf for ; Thu, 29 Nov 2018 17:29:55 -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 5182812426E for ; Thu, 29 Nov 2018 17:29:55 -0800 (PST)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id C1472A5622CF0 for ; Fri, 30 Nov 2018 01:29:51 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 30 Nov 2018 01:29:53 +0000
Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.69]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0415.000; Fri, 30 Nov 2018 09:29:49 +0800
From: Qin Wu 
To: "netmod@ietf.org" 
Thread-Topic: I-D Action: draft-wu-netmod-factory-default-02.txt
Thread-Index: AQHUiEszvdPfdl5t8EKHWjPaEbC0LKVnhrqw
Date: Fri, 30 Nov 2018 01:29:49 +0000
Message-ID: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.33.244]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-wu-netmod-factory-default-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Nov 2018 01:29:58 -0000

T25lIG1pbm9yIGNoYW5nZXMgdG8gYWRkcmVzcyBjb21tZW50cyByZWNlaXZlZCBmcm9tIElFVEYg
MTAzIHNlc3Npb24gZGlzY3Vzc2lvbi4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j
L2RyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQvDQpXZSBhdXRob3JzIGJlbGlldmUgaXQg
aXMgcmVhZHkgZm9yIFdHIGFkb3B0aW9uIG5vdy4NCg0KLVFpbg0KLS0tLS3Tyrz+1K28/i0tLS0t
DQq3orz+yMs6IEktRC1Bbm5vdW5jZSBbbWFpbHRvOmktZC1hbm5vdW5jZS1ib3VuY2VzQGlldGYu
b3JnXSC0+rHtIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0Kt6LLzcqxvOQ6IDIwMTjE6jEx1MIz
MMjVIDk6MjINCsrVvP7IyzogaS1kLWFubm91bmNlQGlldGYub3JnDQrW98ziOiBJLUQgQWN0aW9u
OiBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0LTAyLnR4dA0KDQoNCkEgTmV3IEludGVy
bmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBk
aXJlY3Rvcmllcy4NCg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IEZhY3RvcnkgZGVmYXVs
dCBTZXR0aW5nDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IFFpbiBXdQ0KICAgICAgICAgICAg
ICAgICAgICAgICAgICBCYWxhenMgTGVuZ3llbA0KICAgICAgICAgICAgICAgICAgICAgICAgICBZ
ZSBOaXUNCglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1kZWZhdWx0
LTAyLnR4dA0KCVBhZ2VzICAgICAgICAgICA6IDEwDQoJRGF0ZSAgICAgICAgICAgIDogMjAxOC0x
MS0yOQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIG1ldGhvZCB0byBy
ZXNldCBhIFlBTkcgZGF0YXN0b3JlIHRvIGl0cw0KICAgZmFjdG9yeS1kZWZhdWx0IGNvbnRlbnQu
ICBUaGUgcmVzZXQgb3BlcmF0aW9uIG1heSBiZSB1c2VkIGUuZy4gZHVyaW5nDQogICBpbml0aWFs
IHplcm8tdG91Y2ggY29uZmlndXJhdGlvbiBvciB3aGVuIHRoZSBleGlzdGluZyBjb25maWd1cmF0
aW9uDQogICBoYXMgbWFqb3IgZXJyb3JzLCBzbyByZS1zdGFydGluZyB0aGUgY29uZmlndXJhdGlv
biBwcm9jZXNzIGZyb20NCiAgIHNjcmF0Y2ggaXMgdGhlIGJlc3Qgb3B0aW9uLg0KDQogICBBIG5l
dyByZXNldC1kYXRhc3RvcmUgUlBDIGlzIGRlZmluZWQuICBTZXZlcmFsIG1ldGhvZHMgb2YgZG9j
dW1lbnRpbmcNCiAgIHRoZSBmYWN0b3J5LWRlZmF1bHQgY29udGVudCBhcmUgc3BlY2lmaWVkLg0K
DQogICBPcHRpb25hbGx5IGEgbmV3ICJmYWN0b3J5LWRlZmF1bHQtcnVubmluZyIgcmVhZC1vbmx5
IGRhdGFzdG9yZSBpcw0KICAgZGVmaW5lZCwgdGhhdCBjb250YWlucyB0aGUgZGF0YSB0aGF0IHdp
bGwgYmUgY29waWVkIG92ZXIgdG8gdGhlDQogICBydW5uaW5nIGRhdGFzdG9yZSBhdCByZXNldC4N
Cg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoN
Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5
LWRlZmF1bHQvDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBh
dDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13dS1uZXRtb2QtZmFjdG9yeS1k
ZWZhdWx0LTAyDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXd1
LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDINCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZl
cnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwy
PWRyYWZ0LXd1LW5ldG1vZC1mYWN0b3J5LWRlZmF1bHQtMDINCg0KDQpQbGVhc2Ugbm90ZSB0aGF0
IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz
aW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg
dG9vbHMuaWV0Zi5vcmcuDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkg
YW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJLUQtQW5u
b3VuY2UgbWFpbGluZyBsaXN0DQpJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQpJbnRlcm5ldC1EcmFmdCBkaXJl
Y3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbCBvciBmdHA6Ly9mdHAuaWV0
Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K


From nobody Fri Nov 30 02:21:13 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F636128766 for ; Fri, 30 Nov 2018 02:21:11 -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=XSrKTH5k; dkim=pass (1024-bit key) header.d=ericsson.com header.b=jwtrUMeS
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6MQfjvDPlbA for ; Fri, 30 Nov 2018 02:21:04 -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 F06F2130DD2 for ; Fri, 30 Nov 2018 02:21:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1543573262; x=1546165262; 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=lKMG4zHCK5AcOmzSPjBm6yaxt0LmHJsRBzuSO3VhY2o=; b=XSrKTH5kcTlQuPM4kA9OS+CARe79W40H+AGLYm45+CMJFcEuEnn43GfWvieq8wbf s454taVcVMg8P3UAgFZNpTyjVq3yXxOv9kfsKtjgg+mVunwJtGsrK68XqwT0Uvv7 8aHEuUztab3tw5ir0P0hmcMiHWqtEJIq6bOP7flKEns=;
X-AuditID: c1b4fb2d-f49ff70000007af1-f6-5c010f0eeffa
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7D.47.31473.E0F010C5; Fri, 30 Nov 2018 11:21:02 +0100 (CET)
Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 30 Nov 2018 11:21:01 +0100
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 30 Nov 2018 11:21:01 +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=TQlAYYVkXEnMFtFMSZY58jAjdFB185euDoS4YiMOpsk=; b=jwtrUMeSgbe3QIYJmIz8mYcRvxYZnuPHzHUaiw17ORQWqGjwMBiNG9SEHGM49GIKpDLJ7BWrPSp+jCXvUZJj7nFqRiTtfvB4I/y4sqYk3hW6dc9ibk7WkU+rH7Sirde1AY6POLMInECGa6HO8H54ZCk+zgE955bB54Z2/VP5uHY=
Received: from DB7PR07MB4935.eurprd07.prod.outlook.com (20.177.192.212) by DB7PR07MB4540.eurprd07.prod.outlook.com (52.135.141.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.13; Fri, 30 Nov 2018 10:21:00 +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.1361.015; Fri, 30 Nov 2018 10:21:00 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Robert Wilton , "j.schoenwaelder@jacobs-university.de" , "netmod@ietf.org" 
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AQHUiJZj38b9X6XrhkqPIEUryT50Sg==
Date: Fri, 30 Nov 2018 10:21:00 +0000
Message-ID: <8aa6b9c7-7d08-9ceb-36be-a54234561667@ericsson.com>
References: <20181113140709.vwc4f3mqmmgjaluu@anna.jacobs.jacobs-university.de> <091DC7F4-0C17-4E64-85B8-8963EFBC208B@cisco.com> <1542152721437.91451@Aviatnet.com> <20181114.091024.1454093230497622054.mbj@tail-f.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [89.135.192.225]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
x-clientproxiedby: HE1PR0102CA0001.eurprd01.prod.exchangelabs.com (2603:10a6:7:14::14) 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; DB7PR07MB4540; 6:xp/yWQVdGX88DAYvde9gy2QHMO5ryIpAZ1aZ+n67YCNjrfRnMJgCdvsW3J4MeB9DKDPJfWkHKvraoaI3AqHQLMoNhWi9zaVYzLgsdVLM1zVpiw2jfvN5DCLh8JIH7rny3KoiMq+/gmxTHkTm5N6Dmcsy1MuCDt7iTrAxUc4rZa1tV79oaZoE3VIOEKWgsFOyjT7MH8BjFjCqB+svGY4526PPTvwy6AbG33kml1g0+Dz62HjiPDqMJCyjIbR5RE7I9FymKE8CBr9kelzbhZIVsqobxFKUkhXgLQ9QsM4LFgnOEomL10Rhh/++iv6AdJscBiqcZqMEqLkToncvhZim22dr0qW3VNe+Y8jxcHjTXxmWHm+fc4solt3Jyo7A9kRMNzAZ0EhvZfafTN5KoxHknG3adpz+zJFuOZ5NU7UpwALqo2bsgbpov7xPFtpfr9Xo9POaNuUDkGX09EeClJ6F6g==; 5:mZMSMJG2lV5/xok3o9Uy8kYYtY8jaTMJ19ApDiL6zZHFV8kdPwMbQCG9goSkmWLZr7vxOlyBHVINFXwN2XJCPvYwhRwY6mFoNhS19O8bLFzOi/389FJqbf4IrNCIBVBdp6dYxrJnG8ftseb1W5Y3XbLw2Fco8+41TzXAZ/Fj4QY=; 7:WZ8gRqvI7QE+78+FZXjw3t23RjWBQ1/tTmKPa8SyhUTtDUu0i3X+9ckihjkh/wluigW607uG+wGpVbo4EDr3WY06r2jY3cvBtJdKkc+t+JAZyopoxc6pgiYbGrez9wpfg/7tJ2wVS52FuTcRI4g+EQ==
x-ms-office365-filtering-correlation-id: dc084a6a-4f90-466e-68d3-08d656ad8526
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:DB7PR07MB4540; 
x-ms-traffictypediagnostic: DB7PR07MB4540:
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)(3231453)(999002)(944501410)(4983020)(52105112)(148016)(149066)(150057)(6041310)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB4540; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB4540; 
x-forefront-prvs: 087223B4DA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(136003)(346002)(39860400002)(376002)(252514010)(189003)(199004)(93886005)(31696002)(8676002)(85202003)(36756003)(52116002)(7736002)(97736004)(2501003)(256004)(486006)(236005)(6512007)(105586002)(4001150100001)(6246003)(106356001)(26005)(229853002)(606006)(446003)(476003)(2616005)(14454004)(99286004)(2201001)(66066001)(86362001)(85182001)(65806001)(25786009)(65956001)(31686004)(64126003)(11346002)(2906002)(71200400001)(6436002)(478600001)(99936001)(5660300001)(71190400001)(6116002)(966005)(6306002)(76176011)(54896002)(6506007)(386003)(58126008)(81156014)(81166006)(53936002)(186003)(53546011)(8936002)(65826007)(3846002)(68736007)(110136005)(6486002)(102836004)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB4540; 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: ZOMbb+3zfy5ASQJSm7uS4vtWOsOpoVSct5SGCRyCN/W38e8IhfYFtF/aSy2+wdwJPN1SQFWmVzTphDPmwIHDl/cJq4kE+6te/7BASNWl0h7fKERKQzk5HgxOaSZpA4P6mRGwFepaHsQzKs0esK/hejdN+EpW8lkieTVvdRlTq2CkFM/3QFJuFqw6yCNAkX+4tqqat4My1ApI5H1QDmfrx4i9WLs8aSgBZiJgKwiOKX1mfbpX1SZWDX/dfCwEHNRi/5ACusiDjdo/ZnMO8fEF/iLjLCo5Jv9iruHxWz5NTf9c4iBERHFa8xvlkuY4JX9EOsqG4jmA8klgO3p1r5WyOllYAIj1DtJR5am9S7Viuok=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010202080607010104060803"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: dc084a6a-4f90-466e-68d3-08d656ad8526
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2018 10:21:00.3006 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4540
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTURzHO/feXa+r6XFp/jAKXBn51jRY2UsQUyLo8U+FWUsvam6zdpeZ /ZEpOh8pIpI6Q62Gme9MWJbZlITylW/JyNqywKQkokIta3d3Qf33+fF9nN85HIaUvhd5MElq LatRK5QyWkxVHDNe9HdyRjFBhmJSPnFvEcmrR66K5M+Gish9ZFTp8j1RlMGwSES1mqIPkSfE u+JZZVIqqwncc1qcmKNbIM9Z0tJuWwapDNQWm48cGcCh0PlthshHYkaKnyKYmDKKhOE7gv6W DkoYDAToykwO/EDhYhLGmkpIQSklYHh80l5gQdD4ro7gm2kcAbrPT2yCK65EkDtdROcjhlmL /aG95RDvccUBUDcwS/3lQtOcLUthL2j+vULydgneCy01CUJ/HwF1RT9tfke8G268/uTAM8Lr 4Edfoy1LYneYnq0mhNu5gnmknxbYDeberYgElkH5x2kbu+GTUGa4hvgDgN+z0pRNC6Wx0DmT aw/7weDULBJ4A4xWF9gDkzTkDWdSgnAQKjqWKUGYRmB8U2EXfGC0a8l+dDKM1ers622E+kIz VYyC9P9srrfmSZyH4Obkd5IXJNgFnlfMUnrrc5B4C9Rmy/738+wLtTfnSYHDoHypmxbYE0oL zA4Cb4f53i9I4BCobf5F1yBxPXLjWI5TJWwLCWA1SXEcl6IOULPaNmT9cN3ty/4PUMN8eA/C DJKtkQTeWRUjFSlSuUuqHrTZ2mNpbRhGHpQ6Rc3KXCVDOVZZEq+4lM5qUk5pLihZrgetZyiZ uySgvvOEFCcotGwyy55jNX9VgnH0yEARS/LwNNWm8IzMHVsfrebUen1m9OqI4191A8e99h/2 uT/eGvijt8kYXH7UOUsbY1a9+pJhKenLifROD4tvctlJh946EzkfXBW+JcvX8UCzNNGD6cqa emk5kn/ZU+n9WFpV1HKWGHx75e5D511ljU5wfsH9bVxU8tT1iGyx+IXfhxAZxSUqgn1IDaf4 A0oxe9p4AwAA
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: Fri, 30 Nov 2018 10:21:12 -0000

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


  
    
  
  
    
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?

    
regards Balazs

    

    
On 2018. 11. 29. 12:03, Robert Wilton
      wrote:

    

    
Hi
      Juergen,
      

      

      YANG library currently defines the type "revision-identifer".=C2=A0=
 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 <Alex.Campbell@Aviatnet.com> wrote=
:
          

          
Does a percentage really need a singl=
e
            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 <netmod-bounces@ietf.org> on behalf =
of
            Acee Lindem (acee)
            

            <acee@cisco.com>
            

            Sent: Wednesday, 14 November 2018 5:03 a.m.
            

            To: Juergen Schoenwaelder; Bal=C3=A1zs Lengyel
            

            Cc: NETMOD WG
            

            Subject: Re: [netmod] for a future rfc6991bis
            

            

            =EF=BB=BFOn 11/13/18, 9:07 AM, "netmod on behalf of Juergen
            Schoenwaelder"
            

            <netmod-bounces@ietf.org on behalf of
            

            j.schoenwaelder@jacobs-university.de>=
; wrote:
            

            

            =C2=A0=C2=A0=C2=A0=C2=A0 On Tue, Nov 13, 2018 at 01:33:01PM +=
0000, Bal=C3=A1zs
            Lengyel wrote:
            

            =C2=A0=C2=A0=C2=A0=C2=A0 > Hello,
            

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

            =C2=A0=C2=A0=C2=A0=C2=A0 > In some cases I want a percenta=
ge without
            fractions. This could be
            

            =C2=A0=C2=A0=C2=A0=C2=A0 > defined
            

            =C2=A0=C2=A0=C2=A0=C2=A0 > using range, by specifying the =
numbers 0 | 1 | 2
            ... 99 | 100 in the
            

            =C2=A0=C2=A0=C2=A0=C2=A0 > range's
            

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

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

            =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0 typedef=
 percent-short {
            

            =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 type percent { range 0 | 1 | 2 ... 99 | 100;
            } // didn't type
            

            out
            

            =C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 all the 101 integer values :-)
            

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

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

            

            =C2=A0=C2=A0=C2=A0=C2=A0 I guess we need to settle on a small=
 number of
            percentage types that
            

            =C2=A0=C2=A0=C2=A0=C2=A0 people find useful and then module a=
uthors hopefully
            find what they
            

            =C2=A0=C2=A0=C2=A0=C2=A0 need. I am not sure that listing 101=
 numbers is a good
            pattern to use
            

            =C2=A0=C2=A0=C2=A0=C2=A0 (although it does achieve what you w=
ant). For
            percentages that have no
            

            =C2=A0=C2=A0=C2=A0=C2=A0 fraction, you likely want to derive =
from a base type
            that is efficient
            

            =C2=A0=C2=A0=C2=A0=C2=A0 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
            

            

            

            

            

            

            =C2=A0=C2=A0=C2=A0=C2=A0 /js
            

            

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

            =C2=A0=C2=A0=C2=A0=C2=A0 Juergen Schoenwaelder=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Jacobs University
            Bremen gGmbH
            

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

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

            

            =C2=A0=C2=A0=C2=A0=C2=A0 ____________________________________=
___________
            

            =C2=A0=C2=A0=C2=A0=C2=A0 netmod mailing list
            

            =C2=A0=C2=A0=C2=A0=C2=A0 netmod@ietf.org
            

            =C2=A0=C2=A0=C2=A0=C2=A0 https://www.ietf.org=
/mailman/listinfo/netmod
            

            

            

            _______________________________________________
            

            netmod mailing list
            

            netmod@ietf.org
            

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

            _______________________________________________
            

            netmod mailing list
            

            netmod@ietf.org
            

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

          

          _______________________________________________
          

          netmod mailing list
          

          netmod@ietf.org
          

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

        

      

      

      _______________________________________________
      

      netmod mailing list
      

      netmod@ietf.org
      

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

    

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


  



--------------ms010202080607010104060803
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTEzMDEwMjA1NFow
LwYJKoZIhvcNAQkEMSIEICFqiRcPGQCX5BAH1R9kqAhYQA8xNOWp4Zqhtzs2VcDcMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAM6EFbRwu0zRA4gToB+4KmB0quLqGQ677A8wiFm8nyAc95aA
96EJd06ZAEbwTQlRFYUAe7aRlvjVzEMdilkv34Ihw7bvERtoW6JpbFddkhd+G6tc/1D0h0Ag
K0eDrEU+ugi0OL3ZEHRDfO4WROCtkQf99yiPKd231pcJsCzuJkJsY0DeCrFXDiu3Eg71WV7o
Q8cZKlgNAnDkatBhSMwQAuaOqA0G3qSqKxdTyEOn65oyLFL37y2Jmze2KyTVBSTDaHTp5doj
JgaQN/a7EcIiDT6hDBFLtEHwlTqhg5Vii6P/bnWmsxslw6PytyBYIVuyvSSlBqDGztHURd+6
c5+KRwcAAAAAAAA=

--------------ms010202080607010104060803--


From nobody Fri Nov 30 02:25: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 289B4130DD5 for ; Fri, 30 Nov 2018 02:25:48 -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 WWdUerDsESg7 for ; Fri, 30 Nov 2018 02:25:46 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E96F612D84D for ; Fri, 30 Nov 2018 02:25:45 -0800 (PST)
Received: from localhost (h-39-108.A165.priv.bahnhof.se [213.136.39.108]) by mail.tail-f.com (Postfix) with ESMTPSA id 7286D1AE0386; Fri, 30 Nov 2018 11:25:44 +0100 (CET)
Date: Fri, 30 Nov 2018 11:25:44 +0100 (CET)
Message-Id: <20181130.112544.1021452038429209831.mbj@tail-f.com>
To: balazs.lengyel@ericsson.com
Cc: rwilton@cisco.com, j.schoenwaelder@jacobs-university.de, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <8aa6b9c7-7d08-9ceb-36be-a54234561667@ericsson.com>
References:   <8aa6b9c7-7d08-9ceb-36be-a54234561667@ericsson.com>
X-Mailer: Mew version 6.7 on Emacs 25.2 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
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: Fri, 30 Nov 2018 10:25:48 -0000

QmFsw6F6cyBMZW5neWVsIDxiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb20+IHdyb3RlOg0KPiBI
ZWxsbywNCj4gDQo+IEluIGEgc2ltaWxhciBtYW5uZXIgd2UgZm91bmQgbXVsdGlwbGUgdXNlcyBm
b3IgdGhlDQo+IGlldGYtbmV0Y29uZi1hY206bm9kZS1pbnN0YW5jZS1pZGVudGlmaWVyLiBXZQ0K
PiBpbXBvcnRlZCBuYWNtIGp1c3QgdG8gcmV1c2UgdGhpcyB0eXBlLg0KPiBBbnlvbmUgZWxzZSBp
bnRlcmVzdGVkPw0KDQpZZXMsIHRoaXMgaXMgYSB1c2VmdWwgdHlwZSB0aGF0IGlzIG5vdCBqdXN0
IE5BQ00tc3BlY2lmaWMuICBXZSBhbHNvDQp1c2UgaW4gdmFyaW91cyBwbGFjZXMuDQoNCg0KL21h
cnRpbg0KDQoNCj4gDQo+IHJlZ2FyZHMgQmFsYXpzDQo+IA0KPiBPbiAyMDE4LiAxMS4gMjkuIDEy
OjAzLCBSb2JlcnQgV2lsdG9uIHdyb3RlOg0KPiANCj4gIEhpIEp1ZXJnZW4sDQo+IA0KPiAgWUFO
RyBsaWJyYXJ5IGN1cnJlbnRseSBkZWZpbmVzIHRoZSB0eXBlICJyZXZpc2lvbi1pZGVudGlmZXIi
LiBJcyB0aGlzIGEgdHlwZWRlZiB0aGF0IHNob3VsZA0KPiAgbG9naWNhbGx5IG1pZ3JhdGUgdG8g
cmZjNjk5MWJpcz8NCj4gDQo+ICBUaGFua3MsDQo+ICBSb2INCj4gDQo+ICBPbiAxNC8xMS8yMDE4
IDA4OjE2LCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+IA0KPiAgT24gV2VkLCAyMDE4LTExLTE0
IGF0IDA5OjEwICswMTAwLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPiANCj4gIEhpLA0KPiAN
Cj4gIEFsZXggQ2FtcGJlbGwgPEFsZXguQ2FtcGJlbGxAQXZpYXRuZXQuY29tPiB3cm90ZToNCj4g
DQo+ICBEb2VzIGEgcGVyY2VudGFnZSByZWFsbHkgbmVlZCBhIHNpbmdsZSBzdGFuZGFyZCB0eXBl
IGluIHRoZSBmaXJzdA0KPiAgcGxhY2U/IEhvdyBhYm91dCAidW5pdHMgcGVyY2VudDsiPw0KPiAN
Cj4gIEF0IHRoaXMgcG9pbnQsIGFmdGVyIGhlYXJpbmcgYWJvdXQgaG93IGRpZmZlcmVudCBtb2R1
bGVzIGhhdmUNCj4gIGRpZmZlcmluZyByZXF1aXJlbWVudCBvbiB0aGlzIHR5cGUsIEkgdGVuZCB0
byBhZ3JlZS4NCj4gDQo+ICArMQ0KPiANCj4gIE9yIGV2ZW4gInVuaXRzICU7Ig0KPiANCj4gIExh
ZGENCj4gDQo+ICAvbWFydGluDQo+IA0KPiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPiAgRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24g
YmVoYWxmIG9mIEFjZWUgTGluZGVtIChhY2VlKQ0KPiAgPGFjZWVAY2lzY28uY29tPg0KPiAgU2Vu
dDogV2VkbmVzZGF5LCAxNCBOb3ZlbWJlciAyMDE4IDU6MDMgYS5tLg0KPiAgVG86IEp1ZXJnZW4g
U2Nob2Vud2FlbGRlcjsgQmFsw6F6cyBMZW5neWVsDQo+ICBDYzogTkVUTU9EIFdHDQo+ICBTdWJq
ZWN0OiBSZTogW25ldG1vZF0gZm9yIGEgZnV0dXJlIHJmYzY5OTFiaXMNCj4gDQo+ICDvu79PbiAx
MS8xMy8xOCwgOTowNyBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgSnVlcmdlbiBTY2hvZW53YWVs
ZGVyIg0KPiAgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZg0KPiAgai5zY2hv
ZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4gDQo+ICBPbiBUdWUsIE5v
diAxMywgMjAxOCBhdCAwMTozMzowMVBNICswMDAwLCBCYWzDoXpzIExlbmd5ZWwgd3JvdGU6DQo+
ICA+IEhlbGxvLA0KPiAgPg0KPiAgPiBJbiBzb21lIGNhc2VzIEkgd2FudCBhIHBlcmNlbnRhZ2Ug
d2l0aG91dCBmcmFjdGlvbnMuIFRoaXMgY291bGQgYmUNCj4gID4gZGVmaW5lZA0KPiAgPiB1c2lu
ZyByYW5nZSwgYnkgc3BlY2lmeWluZyB0aGUgbnVtYmVycyAwIHwgMSB8IDIgLi4uIDk5IHwgMTAw
IGluIHRoZQ0KPiAgPiByYW5nZSdzDQo+ICA+IGFyZ3VtZW50Lg0KPiAgPg0KPiAgPiB0eXBlZGVm
IHBlcmNlbnQtc2hvcnQgew0KPiAgPiB0eXBlIHBlcmNlbnQgeyByYW5nZSAwIHwgMSB8IDIgLi4u
IDk5IHwgMTAwOyB9IC8vIGRpZG4ndCB0eXBlDQo+ICBvdXQNCj4gID4gYWxsIHRoZSAxMDEgaW50
ZWdlciB2YWx1ZXMgOi0pDQo+ICA+IH0NCj4gID4NCj4gDQo+ICBJIGd1ZXNzIHdlIG5lZWQgdG8g
c2V0dGxlIG9uIGEgc21hbGwgbnVtYmVyIG9mIHBlcmNlbnRhZ2UgdHlwZXMgdGhhdA0KPiAgcGVv
cGxlIGZpbmQgdXNlZnVsIGFuZCB0aGVuIG1vZHVsZSBhdXRob3JzIGhvcGVmdWxseSBmaW5kIHdo
YXQgdGhleQ0KPiAgbmVlZC4gSSBhbSBub3Qgc3VyZSB0aGF0IGxpc3RpbmcgMTAxIG51bWJlcnMg
aXMgYSBnb29kIHBhdHRlcm4gdG8gdXNlDQo+ICAoYWx0aG91Z2ggaXQgZG9lcyBhY2hpZXZlIHdo
YXQgeW91IHdhbnQpLiBGb3IgcGVyY2VudGFnZXMgdGhhdCBoYXZlIG5vDQo+ICBmcmFjdGlvbiwg
eW91IGxpa2VseSB3YW50IHRvIGRlcml2ZSBmcm9tIGEgYmFzZSB0eXBlIHRoYXQgaXMgZWZmaWNp
ZW50DQo+ICB0byBlbmNvZGUgZm9yIGJpbmFyeSBlbmNvZGluZ3Mgc3VjaCBhcyBDQk9SLg0KPiAN
Cj4gIE9yIHNpbXBseSBkZWZpbmUgYSB0eXBlIHdpdGggYSBiYXNlIHR5cGUgb2YgdW5pdDggdHlw
ZSBhbmQgYSByYW5nZSBvZg0KPiAgMC0xMDAuDQo+IA0KPiAgQWNlZQ0KPiANCj4gIC9qcw0KPiAN
Cj4gIC0tDQo+ICBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVu
IGdHbWJIDQo+ICBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyBDYW1wdXMgUmluZyAxIHwgMjg3NTkg
QnJlbWVuIHwgR2VybWFueQ0KPiAgRmF4OiArNDkgNDIxIDIwMCAzMTAzIDxodHRwczovL3d3dy5q
YWNvYnMtdW5pdmVyc2l0eS5kZS8+DQo+IA0KPiAgX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj4gIG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gIG5ldG1vZEBp
ZXRmLm9yZw0KPiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QN
Cj4gDQo+ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
PiAgbmV0bW9kIG1haWxpbmcgbGlzdA0KPiAgbmV0bW9kQGlldGYub3JnDQo+ICBodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiAgX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gIG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4g
IG5ldG1vZEBpZXRmLm9yZw0KPiAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9uZXRtb2QNCj4gDQo+ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPiAgbmV0bW9kIG1haWxpbmcgbGlzdA0KPiAgbmV0bW9kQGlldGYub3JnDQo+ICBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiANCj4gIF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICBuZXRtb2QgbWFp
bGluZyBsaXN0DQo+ICBuZXRtb2RAaWV0Zi5vcmcNCj4gIGh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+IA0KPiAtLQ0KPiBCYWxhenMgTGVuZ3llbCAgICAgICAg
ICAgICAgICAgICAgICAgRXJpY3Nzb24gSHVuZ2FyeSBMdGQuDQo+IFNlbmlvciBTcGVjaWFsaXN0
DQo+IE1vYmlsZTogKzM2LTcwLTMzMC03OTA5ICAgICAgICAgICAgICBlbWFpbDogQmFsYXpzLkxl
bmd5ZWxAZXJpY3Nzb24uY29tDQo=


From nobody Fri Nov 30 03:56: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 B30EB130DDF for ; Fri, 30 Nov 2018 03:56:55 -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 iuGQp4mRnwUC for ; Fri, 30 Nov 2018 03:56:53 -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 0701C128766 for ; Fri, 30 Nov 2018 03:56:53 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 184E2ED7; Fri, 30 Nov 2018 12:56:51 +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 C6Bezmnt-mfy; Fri, 30 Nov 2018 12:56:51 +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, 30 Nov 2018 12:56:51 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id F3E8F2003F; Fri, 30 Nov 2018 12:56:50 +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 NyU7vA_SBEhr; Fri, 30 Nov 2018 12:56:50 +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 1E02620037; Fri, 30 Nov 2018 12:56:49 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Fri, 30 Nov 2018 12:56:49 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 009F6300488EE2; Fri, 30 Nov 2018 12:56:48 +0100 (CET)
Date: Fri, 30 Nov 2018 12:56:48 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
CC: , , 
Message-ID: <20181130115648.bho3ofouglhibgct@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , balazs.lengyel@ericsson.com, rwilton@cisco.com, netmod@ietf.org
References:   <8aa6b9c7-7d08-9ceb-36be-a54234561667@ericsson.com> <20181130.112544.1021452038429209831.mbj@tail-f.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: <20181130.112544.1021452038429209831.mbj@tail-f.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] 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: Fri, 30 Nov 2018 11:56:56 -0000

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         


From nobody Fri Nov 30 04:28: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 8532D130DD1 for ; Fri, 30 Nov 2018 04:28:23 -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=fghH1GnZ; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Bl+GwcfD
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qO7MxI_lUAeu for ; Fri, 30 Nov 2018 04:28:21 -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 98D701294D7 for ; Fri, 30 Nov 2018 04:28:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1543580898; x=1546172898; 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=RcvsJE1pBPc5cPrCJN9r2b8wzuuOBnr2SQz4YFneZ1g=; b=fghH1GnZO1KEgw0IBKFJsDiEmEAWczo+cxYdq0FbpvLFv7SjaqYLDPUWBjUfA1Q1 Ct11y6t60sGg51aypBjGhJp9gJ1Paz8+mwdVisUd4GOKQ+hAE90urbMh9duc48Z5 GH9hr/EBDUyr/E2zi8ElYHKkxmKbZTKBDBbFyxIrES8=;
X-AuditID: c1b4fb2d-3c7e09e000007af1-3d-5c012ce2df3b
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C7.92.31473.2EC210C5; Fri, 30 Nov 2018 13:28:18 +0100 (CET)
Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 30 Nov 2018 13:28:10 +0100
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 30 Nov 2018 13:28:10 +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=WzEy1IomLbGRPSOSZwr/MK+km8QjCS3QrQf2zNDC40Y=; b=Bl+GwcfDaCLmvHnGHRAINBTCXHAJz+hXZoP82UW221bDn/aBSa+3l3gV7uTOaIpOsQ68hueiOMZiACL3jCrv4TeoGGJ9+jX/GKmx4L0cu08kjetz80FNzRbAKLFS8QDREc7b/v2FtnKaD3AK7jXrLXybVr0uXkeLAZy33u/l1HI=
Received: from DB7PR07MB4935.eurprd07.prod.outlook.com (20.177.192.212) by DB7PR07MB4539.eurprd07.prod.outlook.com (52.135.140.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1361.13; Fri, 30 Nov 2018 12:28:10 +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.1361.015; Fri, 30 Nov 2018 12:28:10 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] instance file format and etags/timestamps, xml attributes
Thread-Index: AQHUiKgnZbr44aNptkqAXrtpRTs80w==
Date: Fri, 30 Nov 2018 12:28:09 +0000
Message-ID: <6c329ed9-efdd-19cb-a346-f90fa1e3cfed@ericsson.com>
References: <20181128100116.c6awxlwkxnm42gfb@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181128100116.c6awxlwkxnm42gfb@anna.jacobs.jacobs-university.de>
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: HE1PR0102CA0068.eurprd01.prod.exchangelabs.com (2603:10a6:7:7d::45) 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; DB7PR07MB4539; 6:rTvEzPsem1kUodUG/Lgp5gJtG/62XpL4Wkji5NYAc79hZP1UOsp1fMa4CRhykDT9Ygppe6vKzrLq7xktTymTBQ+0yEbiMQrLHR3DGNRggU99RnAQ7t/YtR2XpbO7CMZjIPJjudJBsA+E7NbBGZNzou4m4Eovnx/5undVHYJyuWCnMvgeZhLJtc1gxS6FEbuJyYBh1qdkrkPsdPIDI3j86P7M86mDqEQV8lg5CW6+5uGBinO9Xf5dr4zwXjUm37L0yC2uhVrKT9xr69PIo6M31qYbluME/AAatTkNWHEzWMRmBSq+LQwlqW9jfQOn3bC4kWh1Od/TGxIVIlzr7930P6s5Pr9HQV8E878+cgw/x9ZhYM3BcZrft69IB4xa9Yxs4lGOSLIYD4+1W3sxrYjGeV5bvbE/mB11OoqY3H7iEJ93KmdXbEdkvDMdUIy24O3GqDmBJLgHEsmyQ2ET1OqZ3A==; 5:NAze8Mju8/9uQuxnjDMv0pij9QM2ZON8uELf+6mWzjeGje55EEWV/WYnxRbvM6W/7W6UwnUlyLyIfP6HZx8tOfVTD02gJFHgnTjMhjPJPPxCdD8muF4NrqGo01B0OgdlNKrbnubGBDqRfaGnrHVLnyd3qGglr1fvYAS6WVzp31Q=; 7:Ex3oVEJXbCfBHBGwvlbyL4SqrZ0Vm/ZJuP8t8MKG7Qi2lnXk1Z9dBlrBbpQ1c7un5j5RcAZJl2v/6Vs2khbkOI6gV+O6taIrvlRfruKpvTHJ4B18XuWU6lnNgxqyP0Zw2RuwUnHdRHThXS2c5HBqYA==
x-ms-office365-filtering-correlation-id: 73938044-635e-4499-cd56-08d656bf48b0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:DB7PR07MB4539; 
x-ms-traffictypediagnostic: DB7PR07MB4539:
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)(93006095)(93001095)(3231453)(999002)(944501410)(4983020)(4982022)(52105112)(3002001)(10201501046)(148016)(149066)(150057)(6041310)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB4539; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB4539; 
x-forefront-prvs: 087223B4DA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39860400002)(136003)(346002)(376002)(51914003)(189003)(199004)(252514010)(11346002)(2616005)(446003)(52116002)(66066001)(65956001)(229853002)(54896002)(6916009)(5660300001)(2501003)(64126003)(256004)(14444005)(65806001)(8936002)(102836004)(6436002)(8676002)(386003)(81156014)(81166006)(1730700003)(65826007)(97736004)(186003)(85182001)(26005)(76176011)(6506007)(236005)(7736002)(5640700003)(6512007)(2906002)(478600001)(14454004)(85202003)(6486002)(3846002)(31686004)(106356001)(25786009)(6246003)(36756003)(86362001)(68736007)(105586002)(58126008)(53936002)(2351001)(99936001)(71190400001)(71200400001)(316002)(99286004)(486006)(476003)(31696002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB4539; 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: z3t/WUM2WcDVTvEDhFXaL21O1ShWL99kyvVHe/uT5Qymd4dqdRAcO0ryZQSD2rME2276OyO9VhRFx0yQtU5Rz38k9nYgttG5VctszalRJzDm7iWKud+BYvs8Nvsw390X09XjBq6wFsEMmhDM1pgjTIuUp0+3WUUKqKo97t7FfbRJ46apLdZc//pg/yfvlLoJQ9wKBlURNye9VaDCjoFdJw6RD895grRD3fqMnZEUZPZC/JVBm4YhXrk/U4LRCtLEa4awmIVHqvwJHih4JbxTAFfEiipLnetTL6/x5WVt6+f0WPlm7j5ZbPMJ5dAbHgsqHupQTVYyrvkJN6A5i72N8Mawb8RMZX5VnMs1tpZHCdc=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030201030308090206080602"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 73938044-635e-4499-cd56-08d656bf48b0
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2018 12:28:09.8667 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4539
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSWUwTURSGvZ3pUCrVawV7AnGhEYgIBQGFRKKSSGKioAIKYbXKCGVpcYZF eVETV5ZAlKUFYoFUIMWIEIwYV6oiiqCgQoIiiyUGakh8ALegdjo10bfv3P8//z335IoI6Uuh q0ilzqUZtTJLTolJXdytAt8pH5ToX/fCPUQ/eFq4A+0yGL4L9qF4cWgqnaXKpxm/bYfE6dqx BSrnferxTyWVglNoIrYIOYoAB4Gl3kQUIbFIih8jqJgZF/LFAoKnPRZ7YRDAHf0EyRUkLidg /Op9klcqBTA8O2S3TSFobOwluWQK74Tzcw8EHDtjL9DdbqM4Xon3Q1lLKypCIut5FOjmlvIW BdQV/7ZZSOwB56o6hBxL8HYYq6wlOLsUR8K9MyHcsSPeCwMPB2zpCK+Cr8+v2ZjAMhg16wX8 25xhcrCP4tkFZj7+EvIsB+3sqI1dcBJUG0oQNz7gWgTmqWYhH5oMdz9csDf7QP+IGfG8Gob0 xfaGYQqaqvvtQgSced1l51EEn9vDefaG8ZvD9pszoc3Y6cDzGjCWTpLlyL/mn8FrrLkEvojg yvQ8VWNbwAp4pjOTNdYFENgTms7K//dzvBGaGiwEz1tB+6Ob4tkdKoonHXjeDJYnXxDPgdB0 fZGqR2IjcmFpls1OCwhU0IzqCMtq1Ao1nduBrF+ru/OnbxdqtYSZEBYhuZPEr3lJolSozGdP ZJvQemvO1I3WV8iVVGvUtNxZMnDOKktSlScKaUaTwuRl0awJuYlIuUyiMN6Nl+I0ZS6dSdM5 NPNXFYgcXU+hLcHfT/oXfGspVETEvGXaDGNjGbqk8B6/de2y+ZH84GWxqmNBfRUTas+KDrcN Rq+qA95KKubD5Z5YrVOG5uilKH1ntKkxY1T8aG16Xm+aiwriPZiEa74JVe+UZZ4NsqGwxYUV 00nLzXEpkcTBoIg3e+Kjg2Z2q5NLA3pD3Q/P58hJNl25yZtgWOUfi39GAWIDAAA=
Archived-At: 
Subject: Re: [netmod] instance file format and etags/timestamps, xml attributes
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 30 Nov 2018 12:28:24 -0000

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


  
    
  
  
    
Hello Jurgen,

    
Thanks for the comments. See answers below=
=2E

    
regards Balazs

    

    
On 2018. 11. 28. 11:01, Juergen
      Schoenwaelder wrote:

    

    

      
draft-ietf-netmod-yang-insta=
nce-file-format-00.txt says:

   The JSON format SHALL follow the format of the reply returmed for a
   RESTCONF GET request directed at the datastore resource:
   {+restconf}/data.  ETags and Timestamps SHOULD NOT be included, but
   if present SHOULD be ignored.

I assume that you mean the JSON content in the message-body of the
HTTP Response message for GET message. My understanding is that ETags
and Timestamps (what are these precisely?) are carried in the HTTP
header. So how could the ETag or 'Timestamps' be in the JSON data?  We
should not mess up the HTTP difference between header data and payload
data.

    

    BALAZS: OK, I will correct it. Yes, it is the=

      payload that I want to include in the instance data. 

      I thought that lower level etags/timestamps are returned inside
      the get-response payload. On re-reading RFC8040 I see my mistake.

    

      

I also do not fully understand the text concerning the XML format.

   The XML format SHALL follow the format returned for a NETCONF GET
   operation.  The <data> anydata (which is not part of the real da=
ta
   itself) SHALL contain all data that would be inside the <data>
   wrapper element of a reply to the <get> operation.  XML attribut=
es
   SHOULD NOT be present, however if a SW receiving a YANG Based
   Instance data file encounters XML attributes unknown to it, it MUST
   ignore them, allowing them to be used later for other purposes.

It is unclear what exactly is the instance data - the entire reponse?
Everything inside <data>? Everything inside and including <data&=
gt;? I
assume the second sentence is trying to say the later but I do not
find it very clear not does it seem to be right. The examples show to
content of the NETCONF <rpc-reply><data/></rpc-reply> i=
nside a <data>
container that belongs to the instance data format (two times <data>=
;
but in different namespaces).

    

    
BALAZS: I will try to reword it to clarify=

        the issue. How about:

    
An instance data set is made up of header
        part and content-data. The content-data is all data inside the
        anydata data node. 

      

    
The header part is defined by the
        -ietf-instance-data module while the content-data is defined by
        the target YANG modules. The content-data=C2=A0 SHALL contain all=

        data that would be inside the <data> wrapper element of a
        reply to the <get> operation .=C2=A0=C2=A0 

      

    
I hope this conveys that content data
        excludes the <data> wrapper element from the get-reply.

    

    

      

It is also unclear to me why XML attributes are to be removed. Why is
that? If I snapshot <operational>, why should I remove important
information such origin annotations? And removing attributes is
actually plain wrong if you consider that attributes carry XML
namespaces.

    

    
BALAZS: You are right, although some
        attributes might be absent in some use cases.=C2=A0 E.g. namespac=
e as
        you pointed out is always needed. However e.g. origin may be
        present if the instance data is a snapshot of the operational
        datastore, but it may be absent if the instance data is used to
        document readOnly server capabilities.

      

    
So I propose to change the text to:=


    
Some XML attributes (e.g. metadata like =
origin) MAY be absent.=20
        SW handling YANG Instance data MUST ignore  =20
        XML attributes unknown to it, allowing them to be used=20
        later for other purposes.


    

      
/js

PS: I am also concerned about the revision being not fine grained
    enough to be useful. I would love to have a much more precise
    timestamp telling me when the instance data was recorded. I would
    probably replace 'revision' with simply a 'timestamp' or add next
    to a 'revision' a more fine grained 'timestamp'.

    

    
BALAZS: I agree that in some use cases a
        timestamp would be useful e.g. diagnostic data from a real live
        YANG server. 

        However in other use cases like documenting factory default,
        defining default configuration to be preloaded or documenting
        server capabilities I see no need for the timestamp. It is not
        interesting exactly at which hour/minute/second the server
        capabilities were documented.

        So while I would not like to add the timestamp in the draft, the
        draft documents, that additional metadata like a timestamp may
        be added to the instance data set.

    

    

      



    

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


  



--------------ms030201030308090206080602
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTEzMDEyMjgwNFow
LwYJKoZIhvcNAQkEMSIEIH6IoH4M7JbTAkaSZtkN37z5wABXjLz8mJKyFZL0ZlVEMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAHKhX/CxE8jkdXES57LB2M3699PDKjHo78t/bz6JR3M34kOY
ysEfRViNGA84Q3v068+OSdU539Aza6OQvflDLLhEl9bugTMIQTFN9vgcLrpQtJYsSkUltIOZ
x4p/Q+NXjkcTkm5TQwd20z98a/vYB1KLDMvlp7u4MrkjBqouPyxWP3ofrYSoscbbJMDp7kOy
5KK2j0ujCQ8OizegZq280z4x+3rSCEikM/hq68o69oaZwovtP0sxbKXPSHGTyUZYkVkmpviG
pyB3fEIfUCWZAeelDAXBEml76bUVqP1Vaa+/d39yuchorXWPZ/fB62n/bBYQZuMRb53Tsz4/
bszvxE8AAAAAAAA=

--------------ms030201030308090206080602--


From nobody Fri Nov 30 04:48: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 CAB6D1294D7 for ; Fri, 30 Nov 2018 04:48:06 -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 McWN6AkYP9JE for ; Fri, 30 Nov 2018 04:48:05 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1C3128AFB for ; Fri, 30 Nov 2018 04:48:05 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B88E4DC0; Fri, 30 Nov 2018 13:48:03 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Bx7NNIg38uqw; Fri, 30 Nov 2018 13:48:03 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 30 Nov 2018 13:48:03 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id A1B9F2003F; Fri, 30 Nov 2018 13:48:03 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Gtk6eo0BCmwg; Fri, 30 Nov 2018 13:48:02 +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 C1ACA20037; Fri, 30 Nov 2018 13:48:02 +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, 30 Nov 2018 13:48:02 +0100
Received: by anna.localdomain (Postfix, from userid 501) id E9F31300489248; Fri, 30 Nov 2018 13:48:01 +0100 (CET)
Date: Fri, 30 Nov 2018 13:48:01 +0100
From: Juergen Schoenwaelder 
To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel 
CC: "netmod@ietf.org" 
Message-ID: <20181130124801.i2yhzkw3e6ml4qnv@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel ,  "netmod@ietf.org" 
References: <20181128100116.c6awxlwkxnm42gfb@anna.jacobs.jacobs-university.de> <6c329ed9-efdd-19cb-a346-f90fa1e3cfed@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: <6c329ed9-efdd-19cb-a346-f90fa1e3cfed@ericsson.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] instance file format and etags/timestamps, xml attributes
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 30 Nov 2018 12:48:07 -0000

On Fri, Nov 30, 2018 at 12:28:09PM +0000, Balázs Lengyel wrote:
>    Hello Jurgen,
> 
>    Thanks for the comments. See answers below.
> 
>    regards Balazs
> 
>    On 2018. 11. 28. 11:01, Juergen Schoenwaelder wrote:
> 
>  draft-ietf-netmod-yang-instance-file-format-00.txt says:
> 
>     The JSON format SHALL follow the format of the reply returmed for a
>     RESTCONF GET request directed at the datastore resource:
>     {+restconf}/data.  ETags and Timestamps SHOULD NOT be included, but
>     if present SHOULD be ignored.
> 
>  I assume that you mean the JSON content in the message-body of the
>  HTTP Response message for GET message. My understanding is that ETags
>  and Timestamps (what are these precisely?) are carried in the HTTP
>  header. So how could the ETag or 'Timestamps' be in the JSON data?  We
>  should not mess up the HTTP difference between header data and payload
>  data.
> 
>    BALAZS: OK, I will correct it. Yes, it is the payload that I want to
>    include in the instance data.
>    I thought that lower level etags/timestamps are returned inside the
>    get-response payload. On re-reading RFC8040 I see my mistake.

The more I think of it, defining the format by refering to specific
protocol operations really seems to be broken and causing complex
maintenance problems in the future. If you fetch , you do
not do a GET on {+restconf}/data.

>  I also do not fully understand the text concerning the XML format.
> 
>     The XML format SHALL follow the format returned for a NETCONF GET
>     operation.  The  anydata (which is not part of the real data
>     itself) SHALL contain all data that would be inside the 
>     wrapper element of a reply to the  operation.  XML attributes
>     SHOULD NOT be present, however if a SW receiving a YANG Based
>     Instance data file encounters XML attributes unknown to it, it MUST
>     ignore them, allowing them to be used later for other purposes.
> 
>  It is unclear what exactly is the instance data - the entire reponse?
>  Everything inside ? Everything inside and including ? I
>  assume the second sentence is trying to say the later but I do not
>  find it very clear not does it seem to be right. The examples show to
>  content of the NETCONF  inside a 
>  container that belongs to the instance data format (two times 
>  but in different namespaces).
> 
>    BALAZS: I will try to reword it to clarify the issue. How about:
> 
>    An instance data set is made up of header part and content-data. The
>    content-data is all data inside the anydata data node.
> 
>    The header part is defined by the -ietf-instance-data module while the
>    content-data is defined by the target YANG modules. The content-data
>    SHALL contain all data that would be inside the  wrapper element of
>    a reply to the  operation . 
> 
>    I hope this conveys that content data excludes the  wrapper element
>    from the get-reply.

As explained above already, I meanwhile believe it is wrong to define
the format by refering to protocol operations. A NETCONF  (using
NETCONF writing style) is wrong for any NMDA datastore content. We
should define the instance data format by refering to the XML and JSON
YANG encoding rules and not by refering to specific protocol
operations.

>  It is also unclear to me why XML attributes are to be removed. Why is
>  that? If I snapshot , why should I remove important
>  information such origin annotations? And removing attributes is
>  actually plain wrong if you consider that attributes carry XML
>  namespaces.
> 
>    BALAZS: You are right, although some attributes might be absent in some
>    use cases. E.g. namespace as you pointed out is always needed. However
>    e.g. origin may be present if the instance data is a snapshot of the
>    operational datastore, but it may be absent if the instance data is used
>    to document readOnly server capabilities.
> 
>    So I propose to change the text to:
> 
>  Some XML attributes (e.g. metadata like origin) MAY be absent.
>          SW handling YANG Instance data MUST ignore
>          XML attributes unknown to it, allowing them to be used
>          later for other purposes.

I disagree and I would prefer to be silent. The YANG models and the
encoding rules define the content. The instance format document has no
right to mess around with that. Whether origin is there or not is well
defined elsewhere. It is not the job of this document to repeat or
even change what is said elsewhere.
 
>  /js
> 
>  PS: I am also concerned about the revision being not fine grained
>      enough to be useful. I would love to have a much more precise
>      timestamp telling me when the instance data was recorded. I would
>      probably replace 'revision' with simply a 'timestamp' or add next
>      to a 'revision' a more fine grained 'timestamp'.
> 
>    BALAZS: I agree that in some use cases a timestamp would be useful e.g.
>    diagnostic data from a real live YANG server.
>    However in other use cases like documenting factory default, defining
>    default configuration to be preloaded or documenting server capabilities I
>    see no need for the timestamp. It is not interesting exactly at which
>    hour/minute/second the server capabilities were documented.
>    So while I would not like to add the timestamp in the draft, the draft
>    documents, that additional metadata like a timestamp may be added to the
>    instance data set.
> 

Having an (optional) timestamp with proper granularity seems rather
basic for me and I fail to see why we would not define this.

/js

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


From nobody Fri Nov 30 04:49: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 07277130E7D for ; Fri, 30 Nov 2018 04:48:58 -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=ey7q9H85; dkim=pass (1024-bit key) header.d=ericsson.com header.b=j7dC5T4M
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgSenKFtMtos for ; Fri, 30 Nov 2018 04:48:55 -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 067FB130E11 for ; Fri, 30 Nov 2018 04:48:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1543582133; x=1546174133; 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=haJ3bPwu0T8SRIfwjhsoLehkWnvQRS+19voqqTktt88=; b=ey7q9H85fPhUup5789UFT94oBwZ4YQCgYU0FgZ7Bw4kPu+ICYG67daaDbZoKN1LU G46D8GlaJUbairDYgP2kioCTPyU6MyhQUzNBIhonNj44vaA+XNECibk/YxEubFHK Lo9i2UeMm5t6WFLsDAnGVN+ziZetvBBeXgd0ZcGDrPc=;
X-AuditID: c1b4fb3a-8d8849e000002747-5d-5c0131b548c9
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B1.77.10055.5B1310C5; Fri, 30 Nov 2018 13:48:53 +0100 (CET)
Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 30 Nov 2018 13:48:50 +0100
Received: from EUR01-DB5-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; Fri, 30 Nov 2018 13:48:50 +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=DTrqqDPZxdamf1E4X4CZ/Qw+LBslkYV9QDw5WsA+t6A=; b=j7dC5T4MNzJQR/JzcTIiLqnzFHoorMeO1uqq5dKJekHrg7gEyEk7QALdx4HwoQbTeGQv76iQgjj5fUzc7RCY8PeiWvHcQDT9+32YL+Ysd/iSM5AGT5cPeBLiXud2pOg7uB4uK37AX4uK+Rd4Wz1nXnxBKeGdc0FUjRp4/ogRDZg=
Received: from DB7PR07MB4935.eurprd07.prod.outlook.com (20.177.192.212) by DB7PR07MB3929.eurprd07.prod.outlook.com (52.134.100.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.7; Fri, 30 Nov 2018 12:48:49 +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.1361.015; Fri, 30 Nov 2018 12:48:49 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Joe Clarke , "netmod@ietf.org" 
Thread-Topic: yang-instance-file-format - do we need a special file extension ?
Thread-Index: AQHUiKsJHYhlKOcwMkaepessXCePfA==
Date: Fri, 30 Nov 2018 12:48:48 +0000
Message-ID: <9a6f2fd2-9f25-aa99-4681-912d34eecc87@ericsson.com>
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> <20181128144808.s3cbepy6rw7sqoce@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181128144808.s3cbepy6rw7sqoce@anna.jacobs.jacobs-university.de>
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: HE1PR07CA0008.eurprd07.prod.outlook.com (2603:10a6:7:67::18) 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; DB7PR07MB3929; 6:txINz0BldqFON7AihcwwPsEcMjALEOL1YbBr/AufyIX28UshUSzY+lK/JsufnzHRlT8PScz5+JCxKcL2RmTe+hmNEnFpSWaUjKZzuQym5S40aOWXj8PALg/UYXi2Zpoj/6Oj3yxc6tVmlYoWk3bhvtSg6jBTuxqNt6j//6g4KgawJC6vgSf1V1LgNfjhxIqENT55TF2Xb7ifhK+g69O4ngXkwetecuhl7/wJPaHl7cJW7A6JFei3umw/0d4QRPowIjrt0gDHBNMAWus3yF5JZP37gIB0yLio+PcNwI+WNNl5OoyxMlgWQePYCYim4utUaRDJ8tTjwhJDb3ohGYShjWAVKZeAu6E4TkWuIjYcuXhd8Zje4i9gdbJRhBvMxyWqjSqXoMYZwYN0Ygi1U/oKNIdSDu45Q6iAD2FDDsl0RXFbknoX/N6Wx90DU5erh9RblaVq8JHLzfILicjh0Ddhyg==; 5:H7+/kLtFObkNyto5K/dVmrZmoh675hXMlgkiYjthirNCt1uqzi6NbcSIFbeBP+Eo/i7bYh4hZyFaSF4RrC3E0aq0tgkwEsfb7jtjPqC0iA8uVp2f2MbdZl831TuOke46zwudLjn66Z/cZOw1TlNyWHQKoiUw/+YPAXHk7RToMzY=; 7:CVMqebsKdgJyYoQi4ZU37BuSEUGa1QLHSIsNpfVZMyzDH8C/IzpCA1Ro3S0wA5fXg2IzK+hEnymnqT5Apn/BkwFSKJkQGaRJ/Lfu/LCvXRWYsykmEG+ZAU+0rmLR8G3v6PLDcCcVZnBO0dzFrRZygQ==
x-ms-office365-filtering-correlation-id: d739a2da-3741-4f7a-e57f-08d656c22b84
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:DB7PR07MB3929; 
x-ms-traffictypediagnostic: DB7PR07MB3929:
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)(93006095)(93001095)(3231453)(999002)(944501410)(4983020)(4982022)(52105112)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB3929; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB3929; 
x-forefront-prvs: 087223B4DA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(346002)(39860400002)(366004)(136003)(199004)(189003)(252514010)(64126003)(5660300001)(6436002)(6486002)(316002)(99936001)(110136005)(85182001)(66066001)(65956001)(65806001)(58126008)(53936002)(7736002)(236005)(97736004)(6116002)(14454004)(31686004)(3846002)(54896002)(2906002)(2501003)(6512007)(93886005)(478600001)(85202003)(106356001)(99286004)(31696002)(76176011)(256004)(105586002)(52116002)(53546011)(68736007)(186003)(26005)(102836004)(25786009)(8936002)(81166006)(65826007)(86362001)(8676002)(81156014)(6506007)(386003)(11346002)(486006)(476003)(446003)(71190400001)(2616005)(71200400001)(36756003)(66574009)(23603002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB3929; 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: uJoRDMBAd1wiTIv92Ta5MB1KHxqb+7fACKMaptybcbhhFBcaaJ6vdFsqNhyeHvrNQHyjuCKrK2XPHVKiiffoWr+XDNNPp+GnkJpmmMEkfHmJTINFJ/KXw2W803J85SixRdRGZHpeNKZMCrW+Iu4rKCUy3Ur+0/q+2lgNtapoOfrQL8UjY62Hg6kXI1LYnwUeter0rtmQvkCyJTC4TJXzFlXHLN6shlX0JDtSvcAR/T14pPPAFhb1kj+JGnJECnnVD8TOh9YBJEUVI4boQT9k0yXNekfqK4lXw0p8Z0hfxfongGk28TvoXrQVuD9L1UnFpj0+FjX9bPae9V7L38bqvVDip8U8nTJiIZuzbr8fbIs=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010401090309030000000801"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d739a2da-3741-4f7a-e57f-08d656c22b84
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2018 12:48:49.0580 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB3929
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA2WSe0hTURzHO/fe3V1Xq+PU/GlkNHqQlq8MLUszJC3yBUJhyxx1U1Gn7JqZ Bi1Sm1pkuGyNSC3zGWJPe5g2qUhD0ygVo3w0i4qiwjLTNLezIOi/z/d8f7/vOb8fh6NlL0XO XKIqnVerlMlyVsKc3dGYueqGF1J43u9k/JpfTCK/0u4joo1UqG7iiii0omKciqRiJOv38smJ GbzaIyBOkjA4VU6ljYVkVleOiDXoaFABsuEA+0BOXSNTgCScDD9AMKJrsoofCD6dGrSKCgqm 84stgsFFNPRd+iYmTjEFF5pzEBHDCLSvTGJzMouD4djnFsrM9jgENPcusma2w1tBU10qIudR MG04SRcgbobdQfskwnzM4KXQoR9HZpbiQNDezaFIvomC7se3abNhgyOgrXHEwgjPh7H2y5a7 aOwI/aZSikxnD0PdT1jCDvD+zZSIsBz0H/ot7IB3wZmK45YBAOsQ1Py8g0hoLDS91lqbV0JH rwkRXgjPSgutDT0sND1ushaFgeFpC0WMfgSnnz2nieEKkx3nrUVJcG2yREzYBWpPDDFFyNPw z8sJ5yPQj0YbLCuwhbazJsYwsyUaL4PKXPn/5W5QWf6RJuwP+l9GlvBi0BUOiQmvgY8PvyLC q6Gy/jdbhiS1yEHgBSEl3tvbnVcn7hGEVJW7ik+/ima+mfH6xLpbyPguqBVhDsnnSDNWIYVM pMwQDqa0oiUzOcMNdV3ImVGlqni5vbQzb5ZCJt2rPJjFq1N3q/cn80IrWsAxckfppn1+MTIc r0znk3g+jVf/dSnOxlmDdm4TfLL1h9iiwInRlJuFNQq3PcHGgsHlCX2aBuy6RbfZ83vW2kVR se3NAbauTpkxnG8g7xXdanf1be6X4g0uef6RYbNbtClObQfiQsuiD2fdX+wRdM5/4l64b/Jz N1uqa8CZDa9a8Si6fl7cUK1fz3bjXJvsEtyuqOq174mLGHCUM0KC0suVVgvKP4ursFBuAwAA
Archived-At: 
Subject: [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: Fri, 30 Nov 2018 12:49:06 -0000

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


  
    
  
  
    
Hello, Joe, Jurgen,

    
RFC6020 doesn't really register=C2=A0 file extensions, but rather
      media types. I don't feel we need a new mediatype for this as we
      really use json and xml. However I see it useful to document in
      the file extension that this is not just any plain old XML; it is
      yang instance data in XML format.=C2=A0 Alternatives:

    
    
      
  1. Use the .yid file extension (my favorite)
    2. 
      
  2. Use 2 separate file extensions: .yidxml, .yidjson
    3. 
      
  3. just use .xml and .json
    4. 
    

    
What is the rule, do I need to register a file extension as a
      media-type? Is that optional? Is that needed?

    
regards Balazs

    

    
On 2018. 11. 28. 15:48, Juergen
      Schoenwaelder wrote:

    

    

      
On Wed, Nov 28, 2018 at 09:3=
5:55AM -0500, Joe Clarke wrote:


      

        
On 11/23/18 07:48, Bal=C3=A1=
zs Lengyel wrote:


        

          

            
Do you have to registe=
r the ".yid" file extension as well?


          

          
BALAZS: Is there a regis=
try for file extensions? I was not aware.


        

        
RFC6020 section 14 registers media types that include file extensions
for .yin and .yang.  I am asking are you proposing to do the same and
registering something like application/yang-instance-data with a .yid
extension?



      

      
Isn't this just json and xml? If we need specific media types, I think
it would be two.

In theory, it would be even nicer if the document would be written in
such a way that it works with any (future) encoding. The way things
are defined today, by referring to responses of specific protocol
operations, is a bit odd. Does it matter whether the XML is returned
by a NETCONF <get-data> or RESTCONF/HTTP GET? Ideally, the format o=
f
the instance files would be coming out of the data encoding
specifications (plus the architectural framework of datastores).

/js



    

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


  



--------------ms010401090309030000000801
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTEzMDEyNDg0NFow
LwYJKoZIhvcNAQkEMSIEIMnIA01YNsqdLWIbPKhQmZZUL+33IyVrw4IBumuzbbbmMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBALPReyOKhnBr9Bjc2+h+IAH/ZKSoGpVAoqX42ISVb3BT8Yl4
4r1b9NUYWZ9Au9CUpLE5HnOBI5AIVzozw431vlcNJulRpUCBA4qD3/e/Y2qNgBGi5ls60pZV
8TTnzZv5nm1GUc6QLfnIxrG0vGs+gxTaMa1qz7tZ+wmZlp5uREhtlODXhiyy3QAH8gppeDPu
aldTTCl3QCTgEjBRR385+fmmdoL9Em/zSVRTJPf3DPvHMycfJQAi9kZumvpQTIAFCFMX4ToA
t2l6b+kt9wY4hw9CeFKH3BE0Wkj0CoP07DVhcZbEWHmeKP4yqDA+EVXGWnyFiHmqZJvDUY/g
CouVY+cAAAAAAAA=

--------------ms010401090309030000000801--


From nobody Fri Nov 30 05:00:17 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510B31292AD for ; Fri, 30 Nov 2018 05:00:15 -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=c7htGeaQ; dkim=pass (1024-bit key) header.d=ericsson.com header.b=kJC+1ulY
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCeiA139L8v9 for ; Fri, 30 Nov 2018 05:00:08 -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 1719A127333 for ; Fri, 30 Nov 2018 05:00:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1543582806; x=1546174806; 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=spM+ElND/MH0JKALvayuJGLhO6FJROvXk6iCopwdo18=; b=c7htGeaQKst+6oKeckQVBqDb7N8NVI98Qg6m3BFBf8vURuTg5ojhl5nHDhCYBaJa AWH9Sekm/yawteey44+KK+L6sAUGwuWcDPCa0Wp54W4rOitnyvPZuhFkm7mE49wl WQxgo/2EkNUKACangyjbOte8K+UmYyO3EoBvGl8vHOw=;
X-AuditID: c1b4fb30-f15ff700000043c4-d4-5c01345680bd
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B8.50.17348.654310C5; Fri, 30 Nov 2018 14:00:06 +0100 (CET)
Received: from ESESBMR503.ericsson.se (153.88.183.135) by ESESSMB502.ericsson.se (153.88.183.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 30 Nov 2018 14:00:05 +0100
Received: from ESESBMB504.ericsson.se (153.88.183.171) 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; Fri, 30 Nov 2018 14:00:02 +0100
Received: from EUR03-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; Fri, 30 Nov 2018 14:00:02 +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=OFFGp+ImPTie93qGYkVs4rBzKM/WUnVfbOs77GKB0mk=; b=kJC+1ulY6GvnWPjOVsh7Of4u0hMtH5gjIZBRCjRh8UjarkrOCa90R5qzC0Sf4v2PxbX5HfdOZMNhkL1m/8q+KM8t+PT7CrusKExW/RLMjrWyUVBDWyotLbq+FauT1GObBYzsQx9OcqFNQam9vHMbre9eUjKjjlZ0R+F+a4cuP7I=
Received: from DB7PR07MB4935.eurprd07.prod.outlook.com (20.177.192.212) by DB7PR07MB4810.eurprd07.prod.outlook.com (20.178.40.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1404.8; Fri, 30 Nov 2018 13:00:01 +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.1361.015; Fri, 30 Nov 2018 13:00:01 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Qin Wu , Joe Clarke , "netmod@ietf.org" 
Thread-Topic: yang-instance-file-format - do we need a special file extension ?
Thread-Index: AQHUiKybmOBIAA1GMEOb21lg3naShQ==
Date: Fri, 30 Nov 2018 13:00:01 +0000
Message-ID: <4daec669-eae3-871f-d37b-f09be43f8795@ericsson.com>
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> 
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: AM5PR0701CA0021.eurprd07.prod.outlook.com (2603:10a6:203:51::31) 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; DB7PR07MB4810; 6:yuseJFK7TWeQi/AfweVepFvmgpnuF4OwT9mdoVrKFXzHVmLqRLopnzrBZPVJ4zaR/pGycb0Sa7IvohcddAnqutxSbvRpdzZNAwkfmy0LPD24G8TcwD6trWZySJsTnE2QolHKlkkRthN4LeowPNyWi8QsP7Jb5RkNiAZ94Xoqe2ItNd11YP388iyZiMw1UcmgrKhu5foBR/Lh0/tRvBu6TICEla22M0Ug4ptxbhWlBextsLpWKe8ycb6Qm+3VESLfTCUEcvPBTDkBaAUPbDmLsbh8kZklwy39ENa3au16UK+JbjhhMHCJm3LFXUmRzG7LfuzBnl7RtIzNIGUi2IfCft47kFRO0Fcyw7uQR/WvSxnKSmLutMjxByylYRDcbBUHX2w4wvSFBCnJnfA2YZv6BvQYfXMU5D4ecRuKbWHAZLVr7SAupP6NyU7x+NjNjh2PIsQMknDV8EUKhlqDnUAVJQ==; 5:nJOS9B3Ap3l1Sx9QkIqb8qHo0rnwDCBCxVi7ktJOlU3INRuzIKtRyRrmBFv9gekfGssBIW5gSG4BhKksDgpM5Kqmbd1JoK7nNclfsjJtU0l9mic6A1J4gxVr8vn3UEyVgyKlEXcW91xgapLhvSV8IY3lfMJxyrMlzJ8+i+HXJJk=; 7:tw93c512JFsBlCxV3HS0NU3+HcVeEkcdSWhWS5WpkelV1Z0l9v7i9MWtZLNq5MBgyfot36tC8d3zQfSw/tP0L5LI6R5QyJzA8poMT/NStesu3mtUY36Q9DMY6XeZWFtJeZkz+uGKX75TvuGVMLCatA==
x-ms-office365-filtering-correlation-id: 4036132c-7242-407e-e2a0-08d656c3bc6b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:DB7PR07MB4810; 
x-ms-traffictypediagnostic: DB7PR07MB4810:
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)(5005006)(8121501046)(3002001)(3231453)(999002)(944501466)(4983020)(52105112)(93006095)(93001095)(10201501046)(148016)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB4810; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB4810; 
x-forefront-prvs: 087223B4DA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(396003)(366004)(376002)(39860400002)(346002)(136003)(199004)(189003)(252514010)(53546011)(6506007)(386003)(66574009)(5660300001)(6306002)(6512007)(93886005)(110136005)(81166006)(68736007)(8936002)(64126003)(86362001)(31696002)(446003)(31686004)(105586002)(486006)(476003)(2616005)(6116002)(14454004)(65826007)(106356001)(25786009)(53936002)(85202003)(11346002)(316002)(58126008)(2501003)(26005)(99936001)(6486002)(99286004)(66066001)(65956001)(3846002)(52116002)(65806001)(102836004)(186003)(76176011)(7736002)(6436002)(71200400001)(256004)(14444005)(81156014)(85182001)(305945005)(8676002)(71190400001)(478600001)(966005)(36756003)(97736004)(2906002)(23603002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB4810; 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: 2wIvW5UIjT6eYyFm/+qjCdRhYbWjw3P5e9UNnF2VtXev/gotfpsky4e4ArPWmRvfuEVpno+t/+pTaX4migaoBzJED+IeXPBxg4CMIE5DnICvEACM3lZ/lRjEDlGVMT+EMql0RgAxMzz8Wagj2MgM5Zh/W0XlUweyvUqGM6qQ0f80l/bQXLfmm+STUEouJSyi+9j9x3RY6n8zFoeEShrOKRvp+jjAY6banVAX4gbJEKTfSWuRa/iwYm4BowB2MAag6CPgpjKlJU1YyGADRNu/tu48OWF3DQVQNPMAbnfrMOJVNgnYB6sN1i1oixVItn35mU3srMc1TQay3ssR+nzgy8eV9Y8GR1+pjiV+5k7EVXk=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090208050109040308050408"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4036132c-7242-407e-e2a0-08d656c3bc6b
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2018 13:00:01.7755 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4810
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0hTYRjHe3fO2Y7L4XF5eTACXfYhNe+lWWhWgkSaBUqIlSuPF5xTdkzU DzEvOPOeGulSp7g00kTTUDIK75kpWU1ByvJCZtOlFN3UattZUN9+z/v/P//neeAlMeF7wo5M kKbSMqlYIuLy8eqz3en7IrxRlPvod57vQm094ftIs4l8VZNZxBEsuHKjgwjOHVwlgtXqH5ww LJJ/OIaWJKTRMjf/aH78cG9cSoV/uqJ9iydH2oMFyIwEyhu2buh4BYhPCqlBBD1PZjkGQUh9 RaDLsmQFPa83rxJsoebAg9ZxzFDgVBkGNTcnTf3lHMhX5Jls8whqGj4QhjAudRwUusfGYCsq FmqzXyED76BOgPy2imDfT8NvZSnGsiuUaAb0flI/Yg+sr0kMzwIqANpae3E2X8uBZfWKMceM ioCaSYUxH1E28O1pq5ExyhZmFlUc9lIrmJsc47JsDcsLvwiWRVD1ccbI1tQ5uKEuQoYBQFUh mMn5wmNNLjA+vYhY3gUvVIUm0xQXKtaemSaEgGagwCTMIHizfs3U7QT1PSOm9c7Dw9l80xqJ MFgyyC1DHsp/tlXq+zHqKoLGrmxMabzbEkarF3HWdADqOucwlp2hqUGL/d9s4ENQ9bOPy7ID VBbO8VjeD9qhdcSyFzS1bXHrEf8OsmZo5mJSnKenKy1LuMQwyVJXKZ16D+l/XF/XhnsPWl4K 7EcUiUTmghAXFCUkxGlMRlI/ctTnzLe3PEd2uDRZSousBBN526KEghhxRiYtS74guyyhmX60 k8RFtgLf0M5IIRUnTqUTaTqFlv1VOaSZnRxlh9fWOh/V5Vo4n0wdWPNLsm0Lsg98far8ncgm vXq60VmxZOGTP6Tpuq7sbMaLSGKlxTEgaEIu2+sfnR3Id8s81uG9vcRcVRx+xeFMeODd4cjY OibaxyasT+IVb6mzfzkUKi8elrd+ChGW5vglvL0/Ombx2aE7zXr3SG7T1GbLLRHOxIs9nDAZ I/4DNHhWEHkDAAA=
Archived-At: 
Subject: [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: Fri, 30 Nov 2018 13:00:15 -0000

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

Hello Qin,

Do you have a better suggestion for the file extension?

regards Balazs

On 2018. 11. 29. 2:53, Qin Wu wrote:
> The abbreviation of YANG instance data yid may confuse with YANG identi=
tifer short name
> "
>     YANG Identifier:  Numeric object identifier, which is a fixed-lengt=
h
>        numeric value that represents a particular schema node within a
>        YANG module schema tree.  The length and format of a YANG
>        identifier are defined in the YANG Identifier Registry.  Also
>        called a "YID".
> "
> I believe they are not same thing.
>
> -Qin
> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
> =E5=8F=91=E4=BB=B6=E4=BA=BA: netmod [mailto:netmod-bounces@ietf.org] =E4=
=BB=A3=E8=A1=A8 Joe Clarke
> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2018=E5=B9=B411=E6=9C=8828=E6=97=A5=
 22:36
> =E6=94=B6=E4=BB=B6=E4=BA=BA: Bal=C3=A1zs Lengyel; netmod@ietf.org
> =E4=B8=BB=E9=A2=98: Re: [netmod] Fwd: New Version Notification for draf=
t-ietf-netmod-yang-instance-file-format-00.txt
>
> On 11/23/18 07:48, Bal=C3=A1zs Lengyel wrote:
>>> Do you have to register the ".yid" file extension as well?
>> BALAZS: Is there a registry for file extensions? I was not aware.
> RFC6020 section 14 registers media types that include file extensions f=
or .yin and .yang.  I am asking are you proposing to do the same and regi=
stering something like application/yang-instance-data with a .yid extensi=
on?
>
> Joe
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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



--------------ms090208050109040308050408
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTEzMDEyNTk1NVow
LwYJKoZIhvcNAQkEMSIEICbXh7SftRKHGBLFc7TL8bYVyx9aIxs8FnbJ+wfIXeTFMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAI8uWV7x0PbOx+s0eNxIVrw04CHH2a6dMBi0PNgfawK2KxLy
zAVUqOCZjEyj2WNx/pmdyVE4EA9T0t/+/XYMiPER3Qc2o5JapNeoHaBOW30BFRck7t23clwI
z/e/q+PlXUvf1ILIWQM0/Z/Hn+aid3igM7WZksKy/FyyAx+cVf2e1IqrNLRzQV7YWtBYfqhr
uSulV/odxgpITL7TjF3OKzC+W80zkhwtguLJMxAauDipWexwXSHv1B8vYAG8j80jY0ynNcI7
TX61wgeKjZM9eUUbBFZgNrUd1BBp4Mw5S6IiGs8yp2g312m4oZsaAP46p9Z0Gafs2H6Xefs5
YMVhAawAAAAAAAA=

--------------ms090208050109040308050408--


From nobody Fri Nov 30 07:17: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 63C011271FF for ; Fri, 30 Nov 2018 07:17:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bEd_TiekIap for ; Fri, 30 Nov 2018 07:17:52 -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 04DE1126CC7 for ; Fri, 30 Nov 2018 07:17:52 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A7EE1E89; Fri, 30 Nov 2018 16:17:50 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id bYK2sBRRNErz; Fri, 30 Nov 2018 16:17:50 +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, 30 Nov 2018 16:17:50 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 60CEE2003F; Fri, 30 Nov 2018 16:17:50 +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 lVtEUMlhf22U; Fri, 30 Nov 2018 16:17:50 +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 0BD3E20037; Fri, 30 Nov 2018 16:17:49 +0100 (CET)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1591.10; Fri, 30 Nov 2018 16:17:49 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 27780300489537; Fri, 30 Nov 2018 16:17:48 +0100 (CET)
Date: Fri, 30 Nov 2018 16:17:48 +0100
From: Juergen Schoenwaelder 
To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel 
CC: Joe Clarke , "netmod@ietf.org" 
Message-ID: <20181130151748.flgj7u2ifmxtp2ov@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: =?utf-8?Q?Bal=C3=A1zs?= Lengyel ,  Joe Clarke , "netmod@ietf.org" 
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> <20181128144808.s3cbepy6rw7sqoce@anna.jacobs.jacobs-university.de> <9a6f2fd2-9f25-aa99-4681-912d34eecc87@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: <9a6f2fd2-9f25-aa99-4681-912d34eecc87@ericsson.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB02.jacobs.jacobs-university.de (10.70.0.121) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
Archived-At: 
Subject: Re: [netmod] 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: Fri, 30 Nov 2018 15:17:54 -0000

On Fri, Nov 30, 2018 at 12:48:48PM +0000, Balázs Lengyel wrote:
>    Hello, Joe, Jurgen,
> 
>    RFC6020 doesn't really register file extensions, but rather media types.
>    I don't feel we need a new mediatype for this as we really use json and
>    xml. However I see it useful to document in the file extension that this
>    is not just any plain old XML; it is yang instance data in XML format.
>    Alternatives:
> 
>     1. Use the .yid file extension (my favorite)
>     2. Use 2 separate file extensions: .yidxml, .yidjson
>     3. just use .xml and .json
>

I would have used .json or .xml; the content of the file after all is
self-describing and tools like 'file' might learn how to recognize the
content. Extensions like .yidxml and .yidjson looks a bit horrible to
me and so far I never had any real problems using .json and .xml for
arbitrary json and xml files (and .json and .xml helps generic tools
so calling it .yid means that I have to go and teach tools that .yid
is either .json and .xml). Try loading .json and .xml in your
favourite editor and then load a .yid file. Big difference for my
editor. So from my perspective, do nothing (and then people and tools
will likely use option 3).

/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 Nov 30 07:55:05 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A8C1294D0 for ; Fri, 30 Nov 2018 07:55:03 -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=EPpCRsjE; dkim=pass (1024-bit key) header.d=ericsson.com header.b=jMSS0EUd
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5RpjqMOr2yF for ; Fri, 30 Nov 2018 07:55:01 -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 237591277BB for ; Fri, 30 Nov 2018 07:55:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1543593299; x=1546185299; 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=KxmtzFoW9QbF4HBnCDSJhnSdVEVXmNSs8ilAsWGhpF0=; b=EPpCRsjElIUIqGiGmZ4Gjf50XhLGRE2S+RJz1KrCIa3f3GNpyFCSJnCYhh7HkVEh Xs763mhLWa3vyibJy+Nj0sY4CvSb3yCRd/jzciy85pZkWmGeArAM3TKL871tVFjt 9Gqvfyrd79nU/o3CySIWpXVkbsNpgxMCxkOmCp6vYbk=;
X-AuditID: c1b4fb3a-45fff70000002747-ac-5c015d53facb
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A6.2D.10055.35D510C5; Fri, 30 Nov 2018 16:54:59 +0100 (CET)
Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 30 Nov 2018 16:54:58 +0100
Received: from EUR02-VE1-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; Fri, 30 Nov 2018 16:54:58 +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=z4QVMIS+WsjwICJ71YuFqL45xNq9OkRVSMSPKju2ojE=; b=jMSS0EUdrlbHcOXU8rWnWowcjIDam8n/gf2f351K26lN0zLnnfBAeKuJC/z2gnAv4qMpy6/mIQbP8Af8bxgVnaU/GoilAEFSC0W7Zl1c3sR4pBSFkmBPU7tMI0jIHEjfuQ9Vi/aDWZC/U4iVTZI4Xt1TTWaWCkbKKB4N96bhBmg=
Received: from DB7PR07MB4935.eurprd07.prod.outlook.com (20.177.192.212) by DB7PR07MB4732.eurprd07.prod.outlook.com (52.135.136.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.6; Fri, 30 Nov 2018 15:54:58 +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.1361.015; Fri, 30 Nov 2018 15:54:58 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Joe Clarke , "netmod@ietf.org" 
Thread-Topic: [netmod] yang-instance-file-format - do we need a special file extension ?
Thread-Index: AQHUiKsJHYhlKOcwMkaepessXCePfKVobl4AgAAKWwA=
Date: Fri, 30 Nov 2018 15:54:57 +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> <20181128144808.s3cbepy6rw7sqoce@anna.jacobs.jacobs-university.de> <9a6f2fd2-9f25-aa99-4681-912d34eecc87@ericsson.com> <20181130151748.flgj7u2ifmxtp2ov@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181130151748.flgj7u2ifmxtp2ov@anna.jacobs.jacobs-university.de>
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: HE1PR07CA0004.eurprd07.prod.outlook.com (2603:10a6:7:67::14) 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; DB7PR07MB4732; 6:3bL6nGnAQKLC+UD5CH8NNamKPI+moHsS8MZJuqXdq4csExdF6GA5YtODObDHqWSAutid6SORH9XD0/kumOchAUAT6VQLkJo1gV7OGDWCoohtP0Xkx5086a2BywehCTZ19uAAZ3NWK1t9mMoHL7HVjMuhSWBbLEVKeLcq6Gnes1CXk/ojCkPFneT7aYef1yP4Z+deoabkf0oTfgcIqTvtajuNbti6O/Nv2xEhMU0UmmY6UAFH2MNnwSy58u82ZPFOctJKUZeNXrUkMtNCJBuKRnJTxpSgXCOhYSYpAOS2AD91L+3baIMXwhjZGX9S+NpGf/bJiDdR1teurq0kBGeG83oPZSX9k+i3z9EYaFh93NVCTah8z3Xvjz708BnSBigNNU+RVb+sEex3J2Gpqw81UYc0bdQBiyzjOJVG+5mDLrhKcTfxdmzCDroR0huuiXuWp7OBavJqqL80YuuJiwWhGg==; 5:E2Q7opm7JoBt0+XoBLT60jANn8ygaYZ7bM4coQlzvHXR7b5LV9aG+Hz7HXtbwuJ2Q3ga+JMzmr/QqFpgcMJEq0EzsoRSJJjI6SUhJl1s3LjTB5eB7GtdMNCmtAXBA5rApDP+A9g/ZVDhfB0bxRCke1ZpSJHq4CDvWE63FdBfB2k=; 7:a/VsTqkLUuO5DDn870td/KVfJnq3F4ErXMpK5OMlUiY4dpJzIki8Qoge5khZ5FLO1g+0KqZRn+k/5auC0SS1c/SSCZyz9bVuYpCBZ+jK7QQN61OFs5cY+BZtbGHSkLoABlVOaEPFGKpGtbOOiNPvzw==
x-ms-office365-filtering-correlation-id: a591d427-a186-4e53-93c2-08d656dc2c77
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:DB7PR07MB4732; 
x-ms-traffictypediagnostic: DB7PR07MB4732:
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)(5005006)(8121501046)(3231453)(999002)(944501466)(4983020)(52105112)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB4732; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB4732; 
x-forefront-prvs: 087223B4DA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(366004)(346002)(136003)(396003)(252514010)(189003)(199004)(2906002)(8676002)(81156014)(186003)(58126008)(81166006)(14454004)(8936002)(6486002)(26005)(65806001)(102836004)(386003)(6506007)(36756003)(476003)(64126003)(486006)(2616005)(71190400001)(71200400001)(446003)(11346002)(6436002)(229853002)(66066001)(65956001)(2501003)(256004)(68736007)(76176011)(97736004)(65826007)(53936002)(31696002)(25786009)(99936001)(5660300001)(305945005)(99286004)(478600001)(52116002)(6246003)(7736002)(106356001)(85202003)(316002)(85182001)(86362001)(6116002)(31686004)(3846002)(105586002)(93886005)(110136005)(6512007)(23603002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB4732; 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: bLhzRh6y4YsjXbZOUzKC3NTYb6xEMlQUqtIf8GKPfosYqS0OdTo4dyGbTVKryevqH391Z/FDE6zZVZm/igntP4exaPMAG044kSZJjph4R3e9D84qUutWoNxGu9fDfBThMyT1GGTcKgqmb9GqQL/VZPxqhfmxT4SYSes28IT3lf9LxG2L6RLZ1XG2c8DiCvVrPCJhXG/ipbUckBGyQaCAUYTzIcCOGxpikG2DghwOjSVymuyLG0dUdGFinisw43WVTQs/SL2hjxdfOsQjPN3CGp7RPLxTQog2UtbKioP+00JOOA1jnIeViNOV+pI8xAznPU4H7V3DPFUUYV0ukSyCfxnKXfSB++EBLT/6WYqlwyc=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020905030103070303010301"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a591d427-a186-4e53-93c2-08d656dc2c77
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2018 15:54:57.8865 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4732
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDKsWRmVeSWpSXmKPExsUyM2J7uW5wLGOMwZtF/Bb7rv5htJh/sZHV gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4+Gg/Y8Flm4p18+eyNTB2WXQxcnJICJhI XHqygLmLkYtDSOAIo8SXrjZWCOcbo8TGyd3sEM4SJomFG7aDlbEITGCWOL1qLhtEZjKTxP93 H5kgnEeMEtM/9zKBTGYTcJFof7cfzBYRcJdo2LuYDcQWFoiU+PJgMhtEPEpiw60brBC2lUR7 7x8gmwNoharE07XsIGFeAXuJM0/mQ910n1mi6ctDZpAEp4C/xN4LM8DmMAqISXw/tQZsF7OA uMStJ/OZIL4TkXh48TQbhC0q8fLxP1YIW0lixqtbYLaoQKzE9CU9jCALJASmMEp8nvIbqkFH 4uz1J4wQtqzEpfndUEXX2CQ2rj/NApHwlTiwdA5U4hajxJnDb9ghEloS7Z8+QZ0XJ7HnXgfU 1GyJK7MmQE2Vk1jV+5BlAqPBLCSXQ9idjBLzJpjOAgeBoMTJmU9YIOJmEvM2P2SGsLUlli18 zYyp11pixq+DbBC2osSU7ofsELapxOujHxkhbGOJZev+si1g5FrFKFqcWlycm25kpJdalJlc XJyfp5eXWrKJEZjODm75bbWD8eBzx0OMAhyMSjy8bMGMMUKsiWXFlbmHGFWA5jzasPoCoxRL Xn5eqpII77k2hhgh3pTEyqrUovz4otKc1OJDjNIcLErivE5pFlFCAumJJanZqakFqUUwWSYO TqkGxloNvegH3kFS/tsi1vGsbTe4L/j+6zruZx97+fj6316Qe9W8+MNE5Q3zxe0XsMefOLT+ /L61j41st3x2P7Fj69usyJVW4v+en7xyfn+umNHeSLe/kWHcqzv5dqspb3bQu/JGg/ej0NVb LsVXt5arfmvlT/hpxvdXyMwtcpOv5/SX7C83beC53qPEUpyRaKjFXFScCABB3YsYbwMAAA==
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: Fri, 30 Nov 2018 15:55:03 -0000

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

OK, so lets go with option 3.
balazs

On 2018. 11. 30. 16:17, Juergen Schoenwaelder wrote:
> On Fri, Nov 30, 2018 at 12:48:48PM +0000, Bal=C3=A1zs Lengyel wrote:
>>     Hello, Joe, Jurgen,
>>
>>     RFC6020 doesn't really register=EF=BF=BD file extensions, but rath=
er media types.
>>     I don't feel we need a new mediatype for this as we really use jso=
n and
>>     xml. However I see it useful to document in the file extension tha=
t this
>>     is not just any plain old XML; it is yang instance data in XML for=
mat.=EF=BF=BD
>>     Alternatives:
>>
>>      1. Use the .yid file extension (my favorite)
>>      2. Use 2 separate file extensions: .yidxml, .yidjson
>>      3. just use .xml and .json
>>
> I would have used .json or .xml; the content of the file after all is
> self-describing and tools like 'file' might learn how to recognize the
> content. Extensions like .yidxml and .yidjson looks a bit horrible to
> me and so far I never had any real problems using .json and .xml for
> arbitrary json and xml files (and .json and .xml helps generic tools
> so calling it .yid means that I have to go and teach tools that .yid
> is either .json and .xml). Try loading .json and .xml in your
> favourite editor and then load a .yid file. Big difference for my
> editor. So from my perspective, do nothing (and then people and tools
> will likely use option 3).
>
> /js
>
--=20
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com



--------------ms020905030103070303010301
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTEzMDE1NTQ1Mlow
LwYJKoZIhvcNAQkEMSIEIC9D2t5VomFnePKCCJBA9gvqlqaVy03x5pVePpuoH29aMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAA3Ohm+f9uks6wgm7bo86ggbmYkRIlqKSbpiI4Acm8lxSoOK
ebz14/JqgBbNSiyRsgII4v8ptyLWDhoGrY+CgsZCKQPPWj37P7JAZUml5SturXEgGUSE59qC
6HEDwAcNk767f6kAvHKzFNAfZ5klrhJHgElPSQZI0v6rVBwpViRb+/CgpNjCF48fzCEW5aYo
lvpLyD1msgZNsWL8qDwZqCQDmh04UnVnr6oo9E4OzWeb4nkdNwUbo/ybBuVhRxYfuad8n+/E
yqjD54moGvsEOugic2w4MeMB1woiojvkJsw1b09o7CQUpea/IplJX3w7GTAb29MSaJ3aoWkl
ml07ojIAAAAAAAA=

--------------ms020905030103070303010301--


From nobody Fri Nov 30 08:06:30 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91D81128BCC for ; Fri, 30 Nov 2018 08:06:27 -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=LZL7QZAp; dkim=pass (1024-bit key) header.d=ericsson.com header.b=mvHMjMPr
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShqOmr1YDuwQ for ; Fri, 30 Nov 2018 08:06:25 -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 B4E5C1271FF for ; Fri, 30 Nov 2018 08:06:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1543593982; x=1546185982; 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=eTHUZs4vxkJsmlwcallbU656Xu7isIlalGdi9/V6taU=; b=LZL7QZApfFEiRfpJP0spoNzRrSfxhop4ICv+ptUu2CYFVms36QMhYHltgO5akbUA jZTQRA5bwJtnrPxE2EXbnFixRIaeqJlmq5chv+bQNCc6/SXIQ1uPmLWzKcf709LT XK77Kntmzg/gFT66AsgBNgLqNkjXoifZSEQV4KTOyoU=;
X-AuditID: c1b4fb2d-f61ff70000007af1-53-5c015ffee888
Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A5.6E.31473.EFF510C5; Fri, 30 Nov 2018 17:06:22 +0100 (CET)
Received: from ESESSMR505.ericsson.se (153.88.183.127) by ESESBMB503.ericsson.se (153.88.183.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 30 Nov 2018 17:06:22 +0100
Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMR505.ericsson.se (153.88.183.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 30 Nov 2018 17:06:22 +0100
Received: from EUR01-DB5-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; Fri, 30 Nov 2018 17:06:21 +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=3D0L1zHobXxgaFo8kwxX5Ih2RCAZB4DChsLkQMEU/ic=; b=mvHMjMPrn8sUN090OCGOHMdlmihK7UA+9sMw4KGayZ8ym7dzKLsDj3z6YNSMC90CMsMLREC+Rb3FlNz38Li08NgNsA8a5glPMdw1+njnn/nWIPQQCft72KkX7nwpkvxWu3ZO9tMo+r625r8jvgTJvYqzlEMJ8wstjEB7h1EFJng=
Received: from DB7PR07MB4935.eurprd07.prod.outlook.com (20.177.192.212) by DB7PR07MB4028.eurprd07.prod.outlook.com (52.134.100.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.6; Fri, 30 Nov 2018 16:06:18 +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.1361.015; Fri, 30 Nov 2018 16:06:18 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: Robert Wilton , Ladislav Lhotka , Martin Bjorklund , "netmod@ietf.org" 
Thread-Topic: [netmod] Datastore leaf for yang instance data
Thread-Index: AQHUgy9uQuT8qLL6iU6nVdbyZztkVQ==
Date: Fri, 30 Nov 2018 16:06:17 +0000
Message-ID: 
References: <87y3a6izap.fsf@nic.cz> <20181106063648.jjf2scqzoack5l3z@anna.jacobs.jacobs-university.de> <58740c15bf3277e04329546476f60c1d12516594.camel@nic.cz> <20181106.104157.239419955739949818.mbj@tail-f.com> <866ff105cf8fda7eadbdce5b344f4cd734fd99b8.camel@nic.cz> <1f4103c1-4953-3df4-d50d-aed1961fbc50@ericsson.com> <20181123154951.anviss5nllq6gwrn@anna.jacobs.jacobs-university.de>  <20181128102050.37iyrx2xhdohnepb@anna.jacobs.jacobs-university.de>  <20181128153215.og7yweannmux35ti@anna.jacobs.jacobs-university.de> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
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: AM5P190CA0003.EURP190.PROD.OUTLOOK.COM (2603:10a6:206:14::16) 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; DB7PR07MB4028; 6:aYPld59n/DqPSSzfN53NFzpN71FTltbhuN0v36GOdQnntXWAeexwhoajfj64Vj3JzvVE2diA8PPZYhautpc5sIY/Ermox5HpSudapXTIviRHUjUp1wvWCGE29cQ9QbpY1DyVJcfbFzgmHNE5bOOVxgK8sn35fNZVo7Amn3EUed717i4FIgxhiSwbzRnaRt8KlFO4p6xSb26K/3akO+lpaMY+ovMVpkf9VDUqS2XXgv+L3shtQLhEi8sKTwvTZvF16ovRbl0ekdlzuoDrhzO4oiGEGGc7Qnmksn7U5LCF7/LRQ6J/8BALUmgevp8gENeWBfE2vHjtwG6je0p8pN4pGa9ehIlF6VPT4cW89X82VqQvqdIuQiLWTTOnLKGq9VSiDIKy2rgDoM163oxZHzodzr9rsVBftmAV6dY4vOT4vrcm0u3vP9SCtWtj8+MwOn6jBjqpvoImDNbII5m43zaWQA==; 5:LaetSYyKW35cGVwpjw4ztECl45nQ9k4RxXB/A5Mv1VFAQC4fKSloRnM33f11sPmLA7IsryljBmqe4DI1g2svL4+EVekLySkZu7Yiewfq/k27Ztd21bFhCA7Q9ex+KfnR51DhKRh2AsAD5OSxagfLGx3VY5oa0AoG7I8ecYGXDxY=; 7:xfq7TPXmOd/680/UgQZvhoMeC+JEzX0BDZmGR9obNxWBQ9VjTrfQ8Uauzy74u0aqePxGyAELFVXvpGZzlQaIJyXXPha++dnvbFqSbEMDIbUgwyFQJbpqOyqVML58f8eIpomSnl9YmzkUvg9ulvZxvw==
x-ms-office365-filtering-correlation-id: 19ac5a6a-d133-44f3-0c80-08d656ddc21c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(49563074)(7193020); SRVR:DB7PR07MB4028; 
x-ms-traffictypediagnostic: DB7PR07MB4028:
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)(3231453)(999002)(944501466)(4983020)(52105112)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB4028; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB4028; 
x-forefront-prvs: 087223B4DA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(366004)(396003)(346002)(376002)(51444003)(199004)(189003)(252514010)(2616005)(97736004)(3846002)(71190400001)(6512007)(105586002)(6116002)(85202003)(106356001)(7736002)(305945005)(71200400001)(65826007)(5660300001)(8676002)(66574009)(2906002)(86362001)(53936002)(81156014)(81166006)(8936002)(36756003)(99286004)(31696002)(52116002)(99936001)(186003)(26005)(6436002)(76176011)(102836004)(53546011)(6506007)(386003)(229853002)(64126003)(66066001)(65956001)(65806001)(68736007)(31686004)(316002)(93886005)(85182001)(6486002)(58126008)(110136005)(6246003)(446003)(2501003)(478600001)(11346002)(486006)(25786009)(14454004)(476003)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB4028; 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: Aa2Jqkax98XuWOaRi3gsMqplPT/dQcH5Uc7CiC9jNJlbiYvbcJpK4J5qMi5sLpaL99BFrcrvJGpGCDwcyqAKNDPvlEmfrmNbJOt0dfN2OiwJlOqfbUqUOCB7/VRxqfxThL40Te91C+sv37FZxWeqLw30Hlr3g1SSrRLjuKZGoG/rVkMOGMeb/1zw/YMiprvZd/PSBgWW4rsoNYzz109iS+l5yD4QGVJi13z86W7KCl1UDT3+GZdyD3juSxfkrNI1XngJ+XuQscLSNyslVri96SVAxAaMtfuWU+WRBJuFRhnSkvvYw3QHoAyCO1Xa/N+urWTUIyLd7EwrAgZQ8vDmbvp9O3DMR2QgJRaIeUNfsgY=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000506020507080502030001"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 19ac5a6a-d133-44f3-0c80-08d656ddc21c
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2018 16:06:17.9293 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4028
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA2WSf0hTURTHu3tvb8/l4rZmHoyyhoqZztSSUfaLLEZklEFJ2I+RL5V0yt76 YSRYgTOVstBSQac0raZZaqQLs5w/SEVZZUlmkT8K1FRcWelw5fZWBP33+d7PueeeA5cmxBa+ Bx2v0jBqlTJBSgnJgqg6TYDtKIpee++dt9xsKKLkWVmfBXLdiwt8+fPuK8RWUpFrreYr9PoZ nqLmVT9SVM/eIveSh4RhMUxC/GlGHbj5mDDuxptrRPKT3Wd7rrYRaShvRyaiacDrwPxYnImE tBi3INA/uyzgwncElvFv6G9oSa9wGj0PrNpJyh5InEOAwTLD50wuD8pGO5xhEEG7uYyXiVxo CoeDduIpzy4kOAfBWH6BQyzBG2Eqw0LaWYLDYHa0k8exDO7UX0d2JrE3fBz5RdlZhLdA80+j 84VaPjRm33YIF7wJdF1mByO8FH50VDoaEdgd+oZ1DgYsgYEXnRTHbjAyZONzLIX80T4Hu+HD cFOf7VgbcB6CoYxiAVfkD129w4jj5fBSl+UsekNBvc3o7BQB99sKBZzoQ6C9UEpywg8aL2Uj brwj0PAhwznGSdD2lghyUFDhP9NyfBlBSVpMoWPtxdBeMExy56FQXDtAcLwGykvHiP/vboT8 2SaK41WQmzUg4Hg9jLVOIY5DoLxqjipBQgNyYxmWTYwNDpEx6vjjLJukkqkYTQ2a/31ND60B 9ahibJsJYRpJXUXHIlG0mK88zaYkmpDXfJ/BBxVm5EGqklSMVCLqTl8QLRbFKFPOMeqko+pT CQxrQstoUuoukhkaDolxrFLDnGSYZEb9x/JoF480tPKexZf3do9Xj+vkhs2aTUWfbMEdho6S gYuN4enTX3xsnZGmRYGhxn1hyfK7X1/vf9g/vf/9+e07e1IfmUJlpaM754JXVClj+lO0nv5L 8Oq4I2cq/ep9FAfYHcYVAn9fstzT2tw6FzEdUVc+nuHfqgszGydOSBaF77KkRi000daDUpKN Uwb5EWpW+RuPkDmShQMAAA==
Archived-At: 
Subject: Re: [netmod] Datastore leaf for yang instance data
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Nov 2018 16:06:28 -0000

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


On 2018. 11. 28. 16:43, Robert Wilton wrote:
>
> On 28/11/2018 15:32, Juergen Schoenwaelder wrote:
>> On Wed, Nov 28, 2018 at 03:27:26PM +0000, Robert Wilton wrote:
>>> On 28/11/2018 10:20, Juergen Schoenwaelder wrote:
>>>> On Wed, Nov 28, 2018 at 09:41:12AM +0000, Bal=C3=A1zs Lengyel wrote:=

>>>>>> I do not buy this story. Your software needs to decide somehow wha=
t
>>>>>> instance data means. A config true leaf in candidate means somethi=
ng
>>>>>> different than the same config true leaf in running and this yet=20
>>>>>> again
>>>>>> means something different than the same config true leaf in=20
>>>>>> operational.
>>>>>>
>>>>>> /js
>>>>> BALAZS: As I understood the WG decided that this draft should only =

>>>>> be about
>>>>> the format of the yang instance data. What the SW does with it is=20
>>>>> out of
>>>>> scope. So considerations whether instance data should be loaded=20
>>>>> into running
>>>>> or candidate or not at all, are outside the scope.
>>>> If you do not know what the instance data means, any attempt to use =
it
>>>> is kind of broken.
>>>>> I want to provide a datastore indicator, but how that should be=20
>>>>> used (and
>>>>> thus what is exactly means) is out of scope.
>>>> I disagree. The datastore indicator is needed to understand what the=

>>>> data means, i.e., to do anything meaningful with it.
>>> I think that a datastore indicator is useful sometimes.=C2=A0 E.g. it=
=20
>>> might be
>>> helpful in some cases to know that the data was associated with a=20
>>> particular
>>> datastore.
>>>
>>> But in the general case I think that this is just "data at rest", and=

>>> probably the key thing to know is whether (i) the data relates to
>>> configuration, or (ii) the data relates to operational state.
>>>
>>> This could potentially be inferred from a datastore leaf, or perhaps =

>>> this
>>> distinction could more explicitly be made by a separate field, which =

>>> I would
>>> make an enumeration or identity, since there might be other types of =

>>> data in
>>> future, such as capability information or diagnostics.
>>>
>> I do not understand why a datastore leaf is not sufficient and why we
>> need yet something new. If ever needed, NMDA does allow us to define
>> new datastores.
>
> Because a distinction between "candidate" vs "running" vs "intended"=20
> won't necessarily be that useful.=C2=A0 Although knowing "running" vs=20
> "intended" would allow the client to know whether it is pre/post=20
> template expansion and that might be useful.
>
> The second reason is that I don't know whether things like=20
> capabilities and diagnostics will be new datastores or just part of=20
> operational.=C2=A0 I don't think that either of these two areas have re=
ally=20
> been properly worked out yet.=C2=A0 I presume that they will come over =

> time, once more network management becomes more automated.
>
> Thanks,
> Rob

BALAZS: You are right, that these areas are not worked out. That is=20
exactly why they are out of scope. This is only about the format, and=20
not about the usage. As we already have about 10 use cases with=20
different needs, none of which are specified exactly, I want to avoid=20
defining specific metadata for use cases we don't fully understand.=20
Note: it is possible and documented that the metadata can be=20
extended/augmented.

regards balazs

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



--------------ms000506020507080502030001
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTEzMDE2MDYxNFow
LwYJKoZIhvcNAQkEMSIEIKga1y837M0I83mvOpDMACGxBxec1YPbeO3J5ik1xCjoMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBABgJcmJ23S5jNR0uU8ILUpfO8zKnGMeDhDdDodSB5H8GLH5J
nXgM0Z2BDXh8ZccjZ9EBEuJdRTpOi01g15su7vNL+cDzJSydJnSKS91uO65gDgBgaEwjXal2
wJ0KPV8ED8NFp/ALxmTpexuuecwUNAfhsrX6WJ+0HEGyT3zt2nnyGTrgEBH/QgFz4MJNkQGU
BCyvMAZICetP2FVJJfmbRCD8uvXFwA/zC6ZTcfJt1Wqnx5iY2iguBEwW0yTnRdrYL2XermCR
L+hUkJSMEr6Fzk7g+ir9UK72cZ8BDI0UIIXubNRYRGCvEAPoti9pFeZUvO8SsOm3iVUyNVl8
u0slHpkAAAAAAAA=

--------------ms000506020507080502030001--


From nobody Fri Nov 30 08:41:37 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032E312F295 for ; Fri, 30 Nov 2018 08:41:36 -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=YjSHDNuP; dkim=pass (1024-bit key) header.d=ericsson.com header.b=OGaCk+Zx
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laRCZchZWx0F for ; Fri, 30 Nov 2018 08:41:34 -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 89E5312E036 for ; Fri, 30 Nov 2018 08:41:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1543596091; x=1546188091; 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=3KvNrKALyT2l//eLV6SYWmz2EcO59XUgtwQfGRJr4fo=; b=YjSHDNuPC1jBr0WNVdSh3pDU8naW28Jbc4LswsYphZ2wABnvRQ7oOWwl+cYVSM2T U8e9+t+MFuC+ieqVtmz75SdIEtzdIYwh/mUkS+ge9PAzFr2X7rNdlZbxrKxye1Gz HVUaYiOKvT9rHQEFG/keW8ViKpFgr3kcfLwTZUv0H8c=;
X-AuditID: c1b4fb3a-45fff70000002747-2a-5c01683b5fd8
Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B5.74.10055.B38610C5; Fri, 30 Nov 2018 17:41:31 +0100 (CET)
Received: from ESESBMB504.ericsson.se (153.88.183.171) 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; Fri, 30 Nov 2018 17:41:31 +0100
Received: from EUR02-HE1-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; Fri, 30 Nov 2018 17:41: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=LrUIcSd28SXAKJDItm4zFCl4LsWGEgw403zE3PF1k1E=; b=OGaCk+ZxT9uuNVRVvaS0j34oDH5iSNdlmznFQTbC83sxdYROqF00HgFq+32PsJbCPWK0+/DuHf0NALCYzv5oLpjLOrJS1CvVbAqgN2AYSFQRGkUBu3P9CHZTP0J+b7gifoUZrJ+5pPLulQpcF0ypxtUaQrYiDpbHUFg4uf73yto=
Received: from DB7PR07MB4935.eurprd07.prod.outlook.com (20.177.192.212) by DB7PR07MB4091.eurprd07.prod.outlook.com (52.134.100.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1382.14; Fri, 30 Nov 2018 16:41: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.1361.015; Fri, 30 Nov 2018 16:41:30 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= 
To: "netmod@ietf.org" 
Thread-Topic: instance file format timestamp
Thread-Index: AQHUiMuLJP7tJgSmUE2w5u/wvRpi/A==
Date: Fri, 30 Nov 2018 16:41:30 +0000
Message-ID: 
References: <20181128100116.c6awxlwkxnm42gfb@anna.jacobs.jacobs-university.de> <6c329ed9-efdd-19cb-a346-f90fa1e3cfed@ericsson.com> <20181130124801.i2yhzkw3e6ml4qnv@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181130124801.i2yhzkw3e6ml4qnv@anna.jacobs.jacobs-university.de>
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: HE1PR05CA0268.eurprd05.prod.outlook.com (2603:10a6:3:fc::20) 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; DB7PR07MB4091; 6:KOJGS1t81sYxhYd8lgVRM+ydjie3PvvpbUqw7+IEHrJqXLsV6kw2O2o+Oetz5wZuwzCN4TfYjtvg8hvyAAbPgWGYk8J4ozPr7699dBs4SDaN3s/9JvUxSYMcQSB+JkM3v15tTUcBL4HTOcOnLD+i1dCoTeBbFASbpcQ+R4AZT+VxccGHc6zm1o01O6X5dmz+2Aqr/IYRRIsZ++daMZhiDhFkiHefBTrXuXHOxPyqj9Jh9u+2rG78MAAPQlcrpYP7tBGukaLa01JJtE1LKbD+vRJImBr1pIoyfZ4+JqiJ8EWddAJsVGEuoVoqGp7TF0JE4SqpDWDb63QIB1wIm6azdouOjuBtlc0ezyVkV2SLJC3wszmfhy4ybophjDaV2nXeVbci3t4fL10WgBNkvzBEyS92a4UruAszsbt2ZNpa7BJhj4Whn0TBwid5+3Bv7A2FqVf9f+j1Z5spLvEqdHaaiw==; 5:uQDlm+/A+xSmBNPQ+h4iZaCFZUEBc6C3vWhDMVi5HPMqh1pM3sgV9OKp1nSq4Oa7ofmcLzBG5ptV6/VwJHhg6WRXnsGVGJHxPAghcA7EQ7brHBE7y1idPQAnk9nvfL3jYgw+FlR/inAncJRgrkKZU8y2+jvF/xxaGR5cJp9bPJs=; 7:UPUK4Rz10ImyK+uNzLjCC5AYLLOflyg4HTBOAxSkpBNOvr9sh0lT7yIJmR/Jx/Dupw/+XZ0Tp0/H7pol9KZab4X9YDz9QRgB2S2/FwFK2KUOrc3JnW87vl52/a+78VMqf2s6Eqp+SQwaSKDfsA++pg==
x-ms-office365-filtering-correlation-id: 6816e71a-718c-4875-5cf0-08d656e2adf3
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390098)(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(49563074)(7193020); SRVR:DB7PR07MB4091; 
x-ms-traffictypediagnostic: DB7PR07MB4091:
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)(3002001)(93006095)(93001095)(3231453)(999002)(944501410)(4983020)(52105112)(10201501046)(148016)(149066)(150057)(6041310)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:DB7PR07MB4091; BCL:0; PCL:0; RULEID:; SRVR:DB7PR07MB4091; 
x-forefront-prvs: 087223B4DA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(366004)(376002)(39860400002)(136003)(199004)(189003)(252514010)(99286004)(36756003)(8936002)(2351001)(256004)(58126008)(14454004)(25786009)(2501003)(1730700003)(81156014)(85182001)(81166006)(8676002)(316002)(6116002)(3846002)(236005)(6512007)(54896002)(105586002)(14444005)(5640700003)(26005)(31686004)(102836004)(186003)(99936001)(52116002)(476003)(68736007)(53936002)(71200400001)(85202003)(106356001)(2906002)(386003)(6506007)(2616005)(6436002)(65826007)(446003)(6916009)(5660300001)(76176011)(6486002)(31696002)(64126003)(486006)(11346002)(3480700005)(97736004)(7736002)(86362001)(66066001)(65806001)(65956001)(478600001)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB4091; 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: zHMgbQpJI9TFxJcuvgEftma8zIM9bOGsLnrtaRPReo+stUtvVI7HLUJ0u7YvSWfkYFvcyAul1pxMzhkeqwe3Dtu1lZoKmfl77SCdT8hwAauxwYp1V+KAp9VdNG7SSy32ZqLGXe5si4mD9FMaSZfgzPzS4jpxkiOfIyo1r/k3SnRU3D3ZPObSu5X4BThhuHhq4OA/FBQlRTLchd2kMHNUTZ6w+epwwZ8TSg80nAJutn8a6K08Js45zwgq0OjTzLPOJNRPXxyH2AgxbxUa4ryfsc9gVUDNVXvIkUNCXBowA+5weyloQI6IUTbOYpmT0o+Fe+2ug3K4zsK6St2Pe/WLSE4MFU7GQ8okB0rVE3G5bp0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000607070206050903070107"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6816e71a-718c-4875-5cf0-08d656e2adf3
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2018 16:41:30.3350 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB4091
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSWUwTURSGvZ3pMG0sGct2RNDYKCZssmkImIriAy+KLyQEUWxgWAK0pIOV JUZARSjUYEJZGkMh1op1RQgqkCAFTRBl0VhDgwtbiCIqCCJI0bZTE337zn/++99zTy6JCYe4 nmSGNJeWSyVZIoKP18c/KAyITEeJQapvIeHakWJuFIrR6VY4R1ECf18KnZWhoOW7xSf56Rp9 XM5oVN6Q5TdRhAYilYhHAhUG86PfOUrEJ4VUHwKDconLFj8QvO4ocXR0HCgprkK2AqeqMFhQ nXfY1BywmFZwtphA0DfX4mRLJqhDcPFLN8fGrtQuqH90l7Cxi5WNlaU4q/tDY1c1pkSklQNh tTXCJuPUTig12WQeKaD2w4xK5RijH8Hj0XZka/CoWPhQW2ZnRLnD8rNb9rswygPMU1oO+zpX GB8ZIFh2g4+T61yWRVD3yWxnN+o41OoqEatXI2g1CdnME9D1rsxx1h9evJlyeLzhpbbCvgqg TAT0tnQ4TIdBu3gDZ9mMYG7Qk2VfKF1rcXgyQf32FcbyVjCoxvEqFKT5Z26NNRejyhFoDc1O GvsGNkF//RSusS4Jo3xAf0H0v9/GfqBvmsVYjoS61R6C5e1QXTHuxPIemH0yj1gOBf0dC9GI +AbkxtAMk50WEhJIyzOSGUYmDZTSufeR9Wv1tP2KeIh6Zg4YEUUi0UaBj/WbCbkSBZOfbUQ7 rDkT924OI09cKpPSIlfBYOmGRKEgRZJfQMtlSfJTWTRjRFtIXOQhOJganiCk0iS5dCZN59Dy v10OyfMsQpdD8yb71i3P9dymoHPBnbe3KSbPZqXKxPGy5DNrl7y//lRvvuox1Bs9W8cf26sl SENzfX5ngXtHg3NvQE6M2DlvuGy5MuHamr/7+ySv5SM6b0X69e4elwZDW29Cua/ftKSwoX1R MXo6emxhLEx9zOVzTc187JVF8XTcU7PJq2tJhDPpkmBfTM5I/gBVzXRhYgMAAA==
Archived-At: 
Subject: [netmod] instance file format timestamp
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 30 Nov 2018 16:41:36 -0000

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


  
    
  
  
    
On 2018. 11. 30. 13:48, Juergen
      Schoenwaelder wrote:

    

    

      

        
PS: I am also concerned ab=
out the revision being not fine grained
     enough to be useful. I would love to have a much more precise
     timestamp telling me when the instance data was recorded. I would
     probably replace 'revision' with simply a 'timestamp' or add next
     to a 'revision' a more fine grained 'timestamp'.

   BALAZS: I agree that in some use cases a timestamp would be useful e.g=
=2E
   diagnostic data from a real live YANG server.
   However in other use cases like documenting factory default, defining
   default configuration to be preloaded or documenting server capabiliti=
es I
   see no need for the timestamp. It is not interesting exactly at which
   hour/minute/second the server capabilities were documented.
   So while I would not like to add the timestamp in the draft, the draft=

   documents, that additional metadata like a timestamp may be added to t=
he
   instance data set.



      

      
Having an (optional) timesta=
mp with proper granularity seems rather
basic for me and I fail to see why we would not define this.

    

    
BALAZS: Don't really agree, but I will add the optional timestamp
      as you think its important.

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


  



--------------ms000607070206050903070107
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
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE4MTEzMDE2NDEyNlow
LwYJKoZIhvcNAQkEMSIEIOygy6ajo2XpzQl8Ac71mPhfl4+s+j9GXvo1ROjRPwzuMGsGCSsG
AQQBgjcQBDFeMFwwRzELMAkGA1UEBhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQD
DBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYzAhEA6b7XEWzAzOaLFTWM1P8xITBsBgkq
hkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMG0G
CyqGSIb3DQEJEAILMV6gXDBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAj
BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEQDpvtcRbMDM5osVNYzU/zEh
MA0GCSqGSIb3DQEBAQUABIIBAC7Wx8iwJWi1/pg6n7zAtRjcipBJ0YmHlBXk2FVdyZmTeBXC
3m74GXigNAwr9drQovFUfxp300YU2PmcxInW10Vjq7aUDPlF2L++obfUblPHVY4M5kZTNi5n
3G+99+DB7eh9jvagYgLivIs7VNdNM2QsG5twxlEOAMfdGT4bwR3inWZFZZSntZT0duU/wKQA
H9sq4kD01PEFhqs+MKMzL0z8bx76D+KkGLM8R7y7tYZh0v2MpAk+qlWkxwO/58hzz6WIfyyb
RtsmumelAHIDiIIy8dIByKuHYJwhUULpjWzNBkfw3iI7No6XcVBUWPQ4hciIwGWTSpvdOBTL
b0IUJckAAAAAAAA=

--------------ms000607070206050903070107--


From nobody Fri Nov 30 09:48: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 21590130EB3 for ; Fri, 30 Nov 2018 09:48:17 -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 tyUQQmlDn9yT for ; Fri, 30 Nov 2018 09:48:15 -0800 (PST)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D06D5130E9A for ; Fri, 30 Nov 2018 09:48:14 -0800 (PST)
Received: by mail-lj1-x232.google.com with SMTP id s5-v6so5709315ljd.12 for ; Fri, 30 Nov 2018 09:48:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=s+NNazOgyArlUWbkMi/9T/aQfuovrxw0J0bXbZvAeLk=; b=eUPAMIhXH0FMnl60dcs4IK9SE3WZsxv6/Mo+Mog243kQFp3oEDnUPFFY+kibb80OAP G4w6xDQGQPL4R8P4sw1+shAXFgtnL19hSGHmE54aMcyBMckdUJN/mUQKS3/ov1SS0dgJ PzkJdG6E5u4oiBRy703H7ai79kUoS/O8UuiVIhmnm1kmEWZGoAA+WZ8HDDIBxh4p2JrQ jiIrGEvCXsrhTIpzDMG0yDNU9ad5OK4SZfAQKeLjtIq+UNtMCY47uiM/jjmvRt++RiSo 4d+Autxnb+Z+/oe1WFjezqbe9plmxWD9DJ8QkUPknohlQB75qXom+h7D1XEu6MtMObYe 3pWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=s+NNazOgyArlUWbkMi/9T/aQfuovrxw0J0bXbZvAeLk=; b=jgSd/wCICejL8vJBYtzzWxhwTKkGT9b/J/DNmMi1yafJuSWLpmaEcYM/St2CY/HvdC UKydY7sT5ebHFQQmexMaQ45rOQIzFJyVELRFtP7CM6FOjk/a5Gd2jzJBllOu7eOEKkcZ cxRqebetLiLmMNrvgbjht00qzRp5MdBcwsD1A/xksjENVC6TeeAoFLIZjkM0nCcqKdRA Hf2H3WUse9wbUYhuhgTy+tpyiUIwGEuoFj6TNJJDENNfAzvap8GJOj1iQ0yViI6D2d2L ZWQj+PqokwH8WJ8lXDfwFu1DbhxW9ZQYXkBtGtkpiAz5xcSbmCl5Z/ne4NVCIlexa9Ax ZiLA==
X-Gm-Message-State: AA+aEWbcsjWVoPZ6r5neXwzY7Crh7Xqz7clrkWG7gNphKuaTfqIyfD+J sBWI1vuhiOjO6WP3g40gJapqNdUIq1Xg6I+BkFOWO2k5
X-Google-Smtp-Source: AFSGD/WbCPSnJy98Miyhjvkmhuy/dpt+dT6bbDnkn/nXW6zCyKLxUry1miM/jeSHI2SZLwTFBQv6nEHcOaHWCb0eYp0=
X-Received: by 2002:a2e:2019:: with SMTP id g25-v6mr4254098ljg.20.1543600092251;  Fri, 30 Nov 2018 09:48:12 -0800 (PST)
MIME-Version: 1.0
From: Andy Bierman 
Date: Fri, 30 Nov 2018 09:48:00 -0800
Message-ID: 
To: NetMod WG 
Content-Type: multipart/alternative; boundary="0000000000002ca183057be567b9"
Archived-At: 
Subject: [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: Fri, 30 Nov 2018 17:48:17 -0000

--0000000000002ca183057be567b9
Content-Type: text/plain; charset="UTF-8"

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

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


Hi,

I don't see much standards valu=
e 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 s=
ome out-of-scope non-standard manner.
This is what we already hav=
e 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 childre=
n
or the 'data' node?

Andy
=





--0000000000002ca183057be567b9--


From nobody Fri Nov 30 11:07:11 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBDFE130F33 for ; Fri, 30 Nov 2018 11:07:08 -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 i7PRSqGOk431 for ; Fri, 30 Nov 2018 11:07:07 -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 7749C130E5A for ; Fri, 30 Nov 2018 11:07:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3686; q=dns/txt; s=iport; t=1543604826; x=1544814426; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=M5obiQPTZVFCN8Tb2CooNPBP200qNYgM0lDJ1F2w0zc=; b=Biq8LJZApbchchCzl0/DRTWNYSyeQuhywgs8akY2x/obya+hBnBovD+/ fZ2Kwq8c6bUTs1BobjSliQqOLG3t9tFrSQoMeaEEBTGuSkdIOEBjP05Q9 kGmyS9u4sExtpSrTre0AB1W7uD2W0+EE6r6yV84oB1l4Uh6z+NZzBXvOr 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAABoiQFc/xbLJq1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBgmmBAieDeYh3jQstkXKFVoF6DRgBCoQ?= =?us-ascii?q?DRgKDVjUIDQEDAQECAQECbRwMhT0BAQQBASFLGwsEFCoCAicwBgEMBgIBAYM?= =?us-ascii?q?dAYIBD6ZpgS8fhSGEZgWMMYFAP4E4gmuDHgEBhGWCNSICiVuWWgmRMQYYiWm?= =?us-ascii?q?HNoh7iHqGaIFHATYngS4zGggbFTuCbIschT8/AzCORwEB?=
X-IronPort-AV: E=Sophos;i="5.56,299,1539648000"; d="scan'208,217";a="8443296"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Nov 2018 19:07:03 +0000
Received: from [10.61.98.244] (dhcp-10-61-98-244.cisco.com [10.61.98.244]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id wAUJ73wX025631; Fri, 30 Nov 2018 19:07:03 GMT
To: Andy Bierman , NetMod WG 
References: 
From: Robert Wilton 
Message-ID: 
Date: Fri, 30 Nov 2018 19:07:03 +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: 
Content-Type: multipart/alternative; boundary="------------69A02B736D89796745E7B16C"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.61.98.244, dhcp-10-61-98-244.cisco.com
X-Outbound-Node: aer-core-1.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: Fri, 30 Nov 2018 19:07:09 -0000

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

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

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


  
    
  
  
    
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


    

  


--------------69A02B736D89796745E7B16C--


From nobody Fri Nov 30 11:28: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 C24C2130F59 for ; Fri, 30 Nov 2018 11:28: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, 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 nomQHYTCHr9S for ; Fri, 30 Nov 2018 11:28:34 -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 E6D36130E73 for ; Fri, 30 Nov 2018 11:28:33 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A701EE4B; Fri, 30 Nov 2018 20:28:32 +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 aY1-a8CIugqO; Fri, 30 Nov 2018 20:28:32 +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, 30 Nov 2018 20:28:32 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 909822003F; Fri, 30 Nov 2018 20:28:32 +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 LEQJCh2wPpkt; Fri, 30 Nov 2018 20:28:32 +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 3330720037; Fri, 30 Nov 2018 20:28:32 +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, 30 Nov 2018 20:28:31 +0100
Received: by anna.localdomain (Postfix, from userid 501) id 4829D300489E9B; Fri, 30 Nov 2018 20:28:30 +0100 (CET)
Date: Fri, 30 Nov 2018 20:28:30 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
CC: Andy Bierman , NetMod WG 
Message-ID: <20181130192830.g2622izshwn4f55z@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Andy Bierman , NetMod WG 
References:  
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: 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: Fri, 30 Nov 2018 19:28:37 -0000

I doubt it makes sense to carry an entire yang library schema with the
instance data. The modules are actually known via the namespaces. If
you want to capture the schema, dump the relevant yang library into
another instance file.

/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


-- 
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 Nov 30 11:36:20 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C727E130F7C for ; Fri, 30 Nov 2018 11:36:19 -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 OFiCSHdddSQU for ; Fri, 30 Nov 2018 11:36:17 -0800 (PST)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 089F8130F74 for ; Fri, 30 Nov 2018 11:36:17 -0800 (PST)
Received: by mail-lj1-x236.google.com with SMTP id n18-v6so5991843lji.7 for ; Fri, 30 Nov 2018 11:36:16 -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=BhTM5d+3LE2cpReyxSWt3DVT2tZIBOiGwgfDQ7DM5cM=; b=jF7/BbWRSrzHBenUh2VR2xAgWk/zsSu8k9KrGV6dCGnucrZbkw6MHiTCBGsbtbHYGE ktRB4ddCZb+sb9TniBhgagMGXnS2zxfshWJGxEXUXomk4osg3jcyqbIkoae6Rq++DKP4 yM7FByMB16e3dvDoL0b6ygoMW2GALy1INIpXydEugGqky7w9bUYlBvXivA1MB1T2iWTU 8so+W91afz/faDnC7gP6/rMBFOCjOP9yqRGDWZcA0izoENi4nmOglBaxPJw/HvY7SVWi Z9EnZvaA9kn8quANh6JqWDUA/arz3AkRYvkwbCjJRwXmlNluYQwfbrZmEPOa/gpnXfeQ ADng==
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=BhTM5d+3LE2cpReyxSWt3DVT2tZIBOiGwgfDQ7DM5cM=; b=eTLa6P4uh+r2TBwAMtYDdtY7i7yyZEY5vSsaMjNXnA9TExcS7kVurZ68DHDQNk5iDF TPMuulmau9cXtCy8OZrfOeOEauZGqR2uSPkQMLZNj+qWH6SmdK3OmhszK67XEggDlxC8 vCfUZzWXaLq+ItHd2qb1C77uNdeHHJM4MVgaeLShaZ+R2J+qoHLDw4YJ8GkX24dhiDYI j3k/RAckmrit4kydrCr0wYvNpvfqqDZe9mPDLwTrhoQQhMOYF8qLY3Wj7evoLiDfd7Zz iBYDq/55fw03edQWgVrrzoQR+VwIbxw2V4auPZFYoENsx/DKZuIPgGTwyilaW+vTEBLj KPUg==
X-Gm-Message-State: AA+aEWYwpGADeQKV5PjddJpQuhZfIXZg1nPl36H8TZI5vpWAyUfsxfTo OdfJW2u3SfAuS23s5t6vsJ2xjQJphaiYyNCuIGOaBA==
X-Google-Smtp-Source: AFSGD/WoawjyErLhj1jrwbMIhtbUO4TB58NOHnZg7vJXTRr+RVuvPPUaMJz0NZlp430FdUbpyBhGoqIfghfLViIggcg=
X-Received: by 2002:a2e:458b:: with SMTP id s133-v6mr4548531lja.170.1543606574929;  Fri, 30 Nov 2018 11:36:14 -0800 (PST)
MIME-Version: 1.0
References:   <20181130192830.g2622izshwn4f55z@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181130192830.g2622izshwn4f55z@anna.jacobs.jacobs-university.de>
From: Andy Bierman 
Date: Fri, 30 Nov 2018 11:36:03 -0800
Message-ID: 
To: Juergen Schoenwaelder , Robert Wilton , NetMod WG 
Content-Type: multipart/alternative; boundary="00000000000092747c057be6e93e"
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: Fri, 30 Nov 2018 19:36:20 -0000

--00000000000092747c057be6e93e
Content-Type: text/plain; charset="UTF-8"

On Fri, Nov 30, 2018 at 11:28 AM Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> 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. If
> you want to capture the schema, dump the relevant yang library into
> another instance file.
>
>
The capability URIs used in NETCONF are not too verbose.
I agree that more efficient solutions are possible.

1) YANG library instance file
The instance-data-set includes a URL to the instance file for the YANG
library
used to generate the associated data node.

2) YANG catalog
 The instance-data-set includes a URL to the appropriate yangcatalog.org
info


/js
>

Andy


>
> 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
>
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

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




On Fri=
, Nov 30, 2018 at 11:28 AM Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de&=
gt; wrote:
I doubt it makes sense t=
o carry an entire yang library schema with the

instance data. The modules are actually known via the namespaces. If

you want to capture the schema, dump the relevant yang library into

another instance file.



The capability URIs used in NETCONF ar=
e not too verbose.
I agree that more efficient solutions are poss=
ible.

1) YANG library instance file
The =
instance-data-set includes a URL to the instance file for the YANG library<=
/div>
used to generate the associated data node.

2) YANG catalog
=C2=A0The instance-data-set includes a URL to =
the appropriate yangcatalog.org info=




/js

Andy
=C2=A0



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 indi=
cating

> which modules (and versions/revisions) the instance data applies to.
> 

> It can be optional, so producers that know it is not required can leav=
e it

> out.=C2=A0 But I think that it is required, at least for situations wh=
ere being

> able to programmatically consume the instance data in a robust way is<=
br>
> 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 in=
formation

> > for the instance file data in some out-of-scope non-standard mann=
er.

> > This is what we already have today just by naming the file in a s=
pecific

> > way.

> > 

> > Is the intent that the instance-data-set leafs will be used to de=
termine

> > the module revisions, features, and deviations used in the childr=
en

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




-- 

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




--00000000000092747c057be6e93e--