Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02

Balazs Lengyel <balazs.lengyel@ericsson.com> Wed, 15 November 2017 03:33 UTC

Return-Path: <balazs.lengyel@ericsson.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765DF1275AB for <netmod@ietfa.amsl.com>; Tue, 14 Nov 2017 19:33:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.11
X-Spam-Level:
X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TO60ChTl34ev for <netmod@ietfa.amsl.com>; Tue, 14 Nov 2017 19:33:47 -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 B299E126CE8 for <netmod@ietf.org>; Tue, 14 Nov 2017 19:33:46 -0800 (PST)
X-AuditID: c1b4fb2d-f23ff70000001e3d-5f-5a0bb5964990
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 7B.5B.07741.695BB0A5; Wed, 15 Nov 2017 04:33:43 +0100 (CET)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.48) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 15 Nov 2017 04:33:41 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aV0Xakxvqi/bnL6f/kmlFrCxdqO9DF4IkP9mRmQcDmM=; b=KUibqoPgd2eaP4ND/lJrqXwYCnjQ9PsB2XiPPrLGb2pL1+99sk+JpTujNxU0+Nbg0FFhr1i7mqRpeRMRV+tu6oQY1O1PNwQKpzCRZ88b+MUDUGiDImRA4jrp0MI8YGrQaivurHWBxCGA6YT5DG7GVAUhQg0x/7MAvsnopAfyfN0=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com;
Received: from [IPv6:2001:67c:370:128:c03b:3d1c:2e9e:f59c] (2001:67c:370:128:c03b:3d1c:2e9e:f59c) by VI1PR07MB3438.eurprd07.prod.outlook.com (2603:10a6:802:24::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.239.4; Wed, 15 Nov 2017 03:33:40 +0000
To: "netmod@ietf.org" <netmod@ietf.org>
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local>
From: Balazs Lengyel <balazs.lengyel@ericsson.com>
Message-ID: <66e88c5b-41fc-7607-e1a9-ebe76eded836@ericsson.com>
Date: Wed, 15 Nov 2017 11:33:18 +0800
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171114212210.7b2g3t3nqzrhcgrs@elstar.local>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: [2001:67c:370:128:c03b:3d1c:2e9e:f59c]
X-ClientProxiedBy: SG2PR01CA0107.apcprd01.prod.exchangelabs.com (2603:1096:3:15::33) To VI1PR07MB3438.eurprd07.prod.outlook.com (2603:10a6:802:24::12)
X-MS-Office365-Filtering-Correlation-Id: 48ff4466-92d8-487c-e7f4-08d52bd9aa83
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:VI1PR07MB3438;
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3438; 3:YoKDidJhWFNJI15NWi276GIeyDRj94vUs1/pw3RJTrWaS/lobLL6Pv4HPMfA2eUMbXPQ6qNRD5SdeYoC6HUPqoNB6YSkz+p9kgmn90d1V6HXoEIgUjIvQuo1NDmrRHgzsu0Oab7k40dwelT5o3ijwpPxkR3OsQpiIvoN/hoNhbHxxN3ZVtNi4thAUHE4RgqTRqN4YGIgbTgZY+0bP57euo3bqu0pWlkj1isW3tdoxk4+TOcAwWowvTpUbpi25L8v; 25:T3jSv83HMVZSDMujXBzo+dxCmTSLc2Z/lfOfs3CZyB3k83ESY2RjRQJzNPj1NraVzKqsp3CoBmO1oL0hAJ+3bs531K6rQAmPTU2Z8u9LE/ENISCremkIfWXBDyLUKVvXyfRjXsRIpo+M23eg6wxmB35+/ZcV2mfKLDPtisMu38wD9ztJYzdh7Z085gZrnxohX1jhv/0OPdKTBTTfW3py4DvzWCj3kEzPATtvKymETsws5vqO4zkXjvlBF+R0cGqx8n7MdfIGuTZAYVeq8wiKqUTVfoXItWk+0FNMWVS45wHFvsh+btcbK4xyOM9OoHSos0vu0eL7Ozpr5E3y0PCCyQ==; 31:TLLbkIahyi3LPYT7OyGp7JG7yN+hRtMqWI15bE3vIjj9DECzSrjTzSQvWDuucaPr+9ifL5ylVeB9JXElvAZm+NnOX6PqNEUhMKuechktIIk+rpQyBnRFUmNdueShiRhqwFHeiuKgTfnMMN4JRQtQvbTaAcs3DXGcQmovn2p1QCyOyz0OfKc/wupBzPvKU3VNB1kqF6dNWriDX0/UolIYClz/dByM3zVqwb+1cuu9aZQ=
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: VI1PR07MB3438:
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3438; 20:werKf9XtA2uSbDtvPz2HnJpRZLd7dZ7FfKIKTAIyoo+NlrKrynSXykUJ9bq0bI9tvAWAeGuMRNpNzu1BYFRPFra+EiYmfzNqfoztUHOqeXYcYzIu7WRJOaUnBQeFpIvhkxbVyd4uebAkJMB2abN6WkbQdgDzhqrYno7x0BA7vMQi87rqVEkYHulROQqSs1R5NrotrD2sHlWN/dq+/6/ivDxlo7gCHy+FfLznrgXcKatNPjqjtG/zAcNn3bOelpV7TAPZUC0VWcSVHahgmxOG2BSX3UI+Is1dS3c3C0zuj2AWDmWU/wmNh8Cs6UAEBadSA7zu8jCTcRwaQHItSo31f/mjGiF5e4VuhWQUdvjLQ0tKrIe7obKYwp1aa0N7sh8DdcAfXvfpqvd77AfXV7oK/KiXlkpfiuT51j19zmbtnK56RU+Ds2FJJlWui4cv5y7huRkEPeLxijdMImYsbNB517W4XcRi0WcEpJ0Std2Onh57kBeC1mg3/h2ZqOl0TUq9; 4:Yw+bgJ59XbFhGXa4zdbriBB7c3XtAn5gAJtk7xKagZu/n3PJ5umfPJhsDE4t6obXT8hTEs4pUpBQV4zu3KwHPailY1V3uERLkwsCanpfaJ1vYOOQvLvkF2pG6H0pkAzKeyLGFez4zhClBc/VmElJq7hgAUiEtfv8OH6VUQvqFy2Pc8bTa/ipBWNgfkQ3Dyzsx5OSg11Lviv73v67YiSzuX+86/aZJKrsdSJ2834xlurPwpzTou+nTf8PO5uqQy9rR3b0lrBce+V+cV1tIti56HJsnRiVMS7xmn9Klq5YWg8h4uGgo/OhK02j11rDXArm
X-Microsoft-Antispam-PRVS: <VI1PR07MB3438A8C9B34DD1EA36B58CB6F0290@VI1PR07MB3438.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(3231022)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB3438; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB3438;
X-Forefront-PRVS: 0492FD61DD
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(45074003)(24454002)(189002)(377424004)(252514010)(199003)(2501003)(23676003)(2906002)(101416001)(67846002)(86362001)(1730700003)(83506002)(105586002)(316002)(81166006)(305945005)(81156014)(58126008)(6116002)(76176999)(53936002)(230783001)(50986999)(6246003)(36756003)(54356999)(50466002)(5640700003)(1706002)(4001150100001)(15650500001)(189998001)(7736002)(31696002)(97736004)(8676002)(2870700001)(25786009)(478600001)(33646002)(65956001)(31686004)(53546010)(47776003)(65806001)(68736007)(2351001)(64126003)(5660300001)(8936002)(65826007)(6486002)(2950100002)(6916009)(6666003)(229853002)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3438; H:[IPv6:2001:67c:370:128:c03b:3d1c:2e9e:f59c]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1;VI1PR07MB3438;23:gOb6d/0Pqj8l0MqxUjh5WdTrO3b9fdKNXtpKVLPmVes47/kW4qsb2KzpetgkVkc4RxSrIp3e7Dkh69SHGf2GW7jFU8Pt5HLTZWjj2xG+lZlSG6fKqaRDTkYunumC+41cVMmHvC6rltdffJabzhmeddGc/zdkupodZhNSihmgKGenXFzKMFEe2Kc8YvPIwAhN3Uvrzu/h/e8AH5IagSlaDHbH1qx/xXY3QEVaUvSTS9J0OqgC3j6HIb8aZG/T9f5Ut/dTUM/Mi3K/ojQ2B/uI+v4iaWXGRTFybHJG/cFkftf3YO3ZyP1YOisVOmWy48wxbU/xyrR3EtAOyXfjkSN23RoEl/MJ/Z7A/x+2qRtnoCam9nN6PnXKr6EYEyv2Zi6WspXzE/C9skfz+0p2KvLvbRyWydeu5YTUAJrHLInnbI7CEKwZuYnyrrMnf9QWmIjYXRwbnwl9PhxUBDccibq03yxtree3si3jd+1ega9hcZkEg519LLm3tOhm02aidDpRNyHHiev1jA4Ol9T8cpnR3qzEMyLSkv+LcxfzNI1Af1S8Z/6tT1op2Jgpv2JKMGCOlyE1DsGMqQj5iD6A0P1pXxKSxAG2ZW1dB7BlvhE0xp5GF4YHmX6Ux0VPSBtpWoW8mAQlkJe/1Yi6P0tMzKRmWylc5wD+aM79R+abPaSzqY4kVC1HsLEyzlzUGQeqYqNC5cIFos7ROBX7SRnFVvv723Oi7M0b480rO+ZVYG3ytvjqMq2wW1wHof/dIg/5Qyd7KSDyFkeJK8c4MatUT2cwTW0iPSDQaJoZkvg6rsK6hk9usUXoNJE/1xOvC9feVfJBI6VmLDjEk+4M7SFGzG6agjDvSsSGaWrwMzVvTAXzdTVxsiHRCm1MjDYs+Qdky2/UmtXRm8OoPiaLapIoS1l1CeBXveGGHOSXJ6m8uZj3+R39kQ67oKv7QEqlzKzv1rRYRqjd7VM6pX9c3ZLNowjUNcDudx1RMFBRMulsu14QyslD7vgFwsjvlkUikzJTSTWIFIJKq1/PkAfkdZkqI920zERMLqfmU/JeYSp63J42059vgi24qJ49t+aepScxu5C1rp9nqbONiLrpD0hOa31wM/eCff/THsOr/NAgXbK3zprD2lcX61YS5X0PeJwKpKeNMZJElQHffGlZV6sxG2NVIoOgTV6ambLKfz1pxfFfWOTxvZJlAyeZLYVJVyEvQd02pQB7B6s6wjrBRIufxxC4nnXkQ2eS/ITuh0L5f9uPRh+XzgiU+A40pafaU3eK5YVIRO59XN8bDNLg39W4VyTH4PSeH7VaC4ww3++h/D64kAqyc8JxKI0SuL8elc/mvKc3v9QUldvo2Cdwn4pJEd8iGg90vKaUxAYsB+A12rWmSMxho6EKZ85xjcLJc1HaLn6V+PIw8M67kOiAMA+CmD223PCOXxrHQLtny74DH5XwMEvvl37MeIDmmE++FzaoV/QuhdAH2dMWYf2lUwxkwgtDKw==
X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB3438; 6:rcpu//nPOjuiZbJbcBrMQZ+TLXf+jGHaA77hIbxyiGNCcTt//AsDMaqMCsPWycSixuelWXDB8ZVP/cxMBlKSnQU+IW2p/qRVwnpno5X2k1p6p6gK+0wG3BJQ5QeRCVkCnRJj2Ni0puKHp+2xcHMt6nzydEN5awdsmreSwq44pwTyaVJgmQfaspp152HLhnA4M9fNltsynbg0I29WAY1RsdY3KFbFg48am6xFLTz7znLec2oiL1YRLGO57q0R0o6fyvnYmO4i7gpz5q/svJU4zBxuhWvT50+W5yUGyWdWCHjjjuHFFqPllxpSS8w6gKjCiuWGQFh8X21DsbWVOIX/71EGeZDtUNuU0kq7KV1m9/U=; 5:XS5dgGuAvnQtFN2TvuQDEKg1C1RA0jetyPvgzc83xwcP0bzGN1SgruGv2xt3UiHiYv5gPphhNyXwD4NDrPUq9hu0vFC3aIZBu9bUrYf2X5QBtXuce04bGRnvmVVh3DZLmTM7o3fLlqTcKAaKbsXc/qw/GfE9XHE/iatO5OA2reU=; 24:6tZ6/OEO2NGx6AnKvE6+OCwYJZiOwIMeOpnu1yUjwtiqnDNqCDxgx6p5jER5iyQ6OAwFAce7nv+9LtUKIDNjQWbWq4MsFXmuDpko0LuLKV8=; 7:ijkQXZ9CzOmd624KHawF911HJIU3p2eviD3iU7DPTgxU8rhsp46cL8jfOxcuCpKTQlzscxzpDPPV3VxD68xRkhs7WHpNku8ke6vYkcLUdoSLyqrDEHCVJ2kZg9Vq68Dxrq5uKdGdtquPQXBdfXr7czZ/Yb3RdGWwYaZy1XFOmDM7s1vVlwL+uBauVlCD2aAludT1+ORHnbGxf9pnpRHImFMv3Zb5qYnfjSD5Uu3GC3wt26OnQ37yIVV5FWtRWZpZ
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2017 03:33:40.5680 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 48ff4466-92d8-487c-e7f4-08d52bd9aa83
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3438
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUyM2K7ge70rdxRBh8PM1nMv9jI6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujI4rm9gLJvhVrJzRztTAeNq2i5GTQ0LAROJb7y3mLkYuDiGB w4wSPW/Xs0M4Jxglbj9bxgZSxSLQyyxx9bUMiM0oECexc81CVoiiPUwS/5quMYEkhAU8JfZ1 /mEFsUUE1CVm7lwP1iwkUCCx5tBhRhCbTcBIYmr/eRYQm1fAXmLTx39AvRxAC1QlTjxXAQmL CsRITHxwkRGiRFDi5MwnYOWcAtYSDbv+s4PYzAIWEjPnn2eEsOUlmrfOZoawxSVuPZkPNlIC qOZAow/ImRICsxglNty7wA5xjobEwwt/WSG+95X4/nQbE0TRTEaJJWcXsUM4DewS79vfsUFU yUocPTuHBcLWkjg/9xojhP2DTeLYK04IO1vi+ZLzUFOtJF7/+s4IMegKq8TH44+YIBIyEidv 7IVq3sMmMWdW3QRG7VlIPp2F5LtZSL6bheS7BYwsqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJL NjECU8TBLb91dzCufu14iFGAg1GJh9drAneUEGtiWXFl7iFGCQ5mJRHe5H6gEG9KYmVValF+ fFFpTmrxIUZpDhYlcV4PEaCUQHpiSWp2ampBahFMlomDU6qBcdI+M54N7qULGZ9/PxKvKTLb 2Edg8dzH7+IttHbyaO9jnfLgRgfLt7sX19n5mbk7WswKuvXlycewhA7N5FPuPnZLnY0TdkyI c+gttla/zau7dtmkwmmeZjsX2ebz7Q9I/B6zJP90rM7xegYezVyORfZ1xqeaPnE0fm8/Kf7i uXlE+cxwm5RLSizFGYmGWsxFxYkAOFkTeA0DAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/d_k9i42Tm6ifUcuc3KDZTueZA8w>
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2017 03:33:51 -0000

See bellow!


On 2017-11-15 05:22, Juergen Schoenwaelder wrote:
> On Wed, Nov 15, 2017 at 12:51:22AM +0800, Balazs Lengyel wrote:
>>     Whenever a client OSS implements some higher level logic for a network
>>     function, something that can not be implemented in a purely model driven
>>     way, it is always dependent on a specific version of the Yang Module
>>     (YAM). If the client finds that the module has been updated on the network
>>     node, it has to decide if it tries to handle it as it did the previous
>>     version of the model or if it just stops to avoid problems. To make this
>>     decision the client needs to know if the module was updated in a backward
>>     compatible way or not. This is not addressed with the current versioning.
> The current rules aim at guaranteeing that definitions (with status
> current) remain backwards compatible. Do you have an example what the
> current rules fail to achieve this? Definitions with status deprecated
> or obsolete may not be present. But if they are present, they have the
> same semantics. This is the promise made to a client. (Note also that
> objects may be absent for reasons document in deviations or simply not
> accessible due to access control.)
BALAZS: My point is that I do not want to check the full YAM (Yang 
Module) for status commands to understand compatibility. That is not 
better then doing a full analysis of the module. The goal that the 
module name is still the same but it can become incompatible due to 
deprecation is not good enough.
>
>>     While having PYANG based checks for backward compatibility is a very good
>>     idea, a  comparison based check will never be a complete check. It is
>>     quite possible to change just the behavior of an rpc/action/etc.  without
>>     changing the YANG definition.  This will only show up as a change of the
>>     description statement that can not be analyzed by PYANG.
> The problem is to decide whether a change can break client
> expectations or not. Even 'bug fixes' can cause a client written to
> expect the old 'buggy' behaviour to fail. Also tricky are situations
> where behaviour was not clearly enough described and this is 'fixed'
> in a module update.
>
> Semantic versioning assumes that one always can clearly distinguish
> between incompatible updates and compatible updates. This may not be
> so clearly cut in practice, see above. (But then, we have the same
> judgement call at the end with today's update rules.)
BALAZS: Semantic versioning gives the editor the possibility to indicate 
that a change is non backward compatible(NBC). Even if the Yang Model 
type/restrictions/valuespace/etc. does not change, but I, the human 
model designer, know that the expected behavior of the SW implementing 
the model changes, I can still indicate that the model is changing in an 
NBC way. That's one reason I like, I need semantic versioning.
>
>>     When upgrading a network node we might introduce non-backward compatible
>>     (NBC) changes. Today we need to introduce a new module for this. That
>>     means during the upgrade process the node must convert stored
>>     configuration instance data from ietf-routing to ietf-routing-2 format.
>>     Instead of solving this data transformation/transfer problem just for a
>>     few NBC data nodes, we will have to do it for the full model. This is
>>     complicated. In many cases the transformation of a few NBC leafs can be
>>     handled by good defaults or with a small script. Transferring the full
>>     data set is more complicated. If we allow NBC updates in some cases this
>>     problem is avoided.
> In XML land, this is mostly a change of the namespace (not of the
> prefix) if one keeps the same structure, no? In JSON land, the change
> of the module name more directly becomes visible in instance data; but
> this is all encoding details.
BALAZS: Even in XMLland we store the prefix as part of any leaf with 
type instance-identifier or identityref and potentially CLI scripts.
>
>>     If we update the module from ietf-routing to ietf-routing-2 ? Do we keep
>>     the prefix?
> I guess you mean the namespace, not the prefix. You can use any prefix
> you like.
BALAZS: No, I mean the prefix. Prefix is part of the instance data (see 
above), potentially part of CLI scripts etc. It is also part of human 
communication. In email we never refer to
urn:ietf:params:xml:ns:yang:ietf-yang-library:/modules-state instead we 
just write yanglib:/modules/state.
>
>>     In one sense it should be kept as it is the same module
>>     "logically"; we also might have stored data including the prefix
>>     (identityrefs, instance-identifiers). On the other hand having multiple
>>     modules with the same prefix is a problem. The only good solution is to
>>     allow incompatible updates in some cases.
> If we move towards allowing incompabile updates, then we need to have
> a mechanism to tell which versions of modules can work together and
> which combinations are affected by an incompatible update. We probably
> need to require strict import by revision or at least 'import by
> compatible revision' (whatever this means at the end).
BALAZS: We already  have this problem today. We allow incompatible 
updates for deprecated/obsolete. When you import a module, the importing 
module will not check for status statements. For "augment" or "must" 
referencing a deprecated and thus removed part will already today cause 
problems.
>
>>     CH 1)
>>
>>     You write
>>     "The YANG data modeling language [RFC7950] specifies strict rules for
>>     updating..."
>>     and again
>>     "When the same YANG module name is kept, the new YANG module  revision
>>     must always be updated in a backward-compatible way."
>>
>>     I strongly disagree. While we have strict rules about even small
>>     modifications to existing schema, but you are allowed to
>>     deprecate/obsolete big parts of the model, thereby possibly deleting
>>     complete subtrees from the schema. That is anything but strict backward
>>     compatibility.
>>     I find this aspect of YANG inconsistent to the level that it would need an
>>     errata.
> Marking something deprecated / obsolete means you can not be sure this
> is implemented. But then, even definitions with status current may not
> be implemented (see deviations) or they may not be accessible to a
> client due to access control. However, if implemented and accessible,
> the guarantee today is that the semantics stay the same and don't
> change unexpectedly.
BALAZS: Access control can be set by the operator, deviations are at 
least viewable, checkable in design time. However something (possibly) 
removed due to status just disappears. In my view the current status 
deprecated  is similar to deviation not-supported .
>
>>     So practically the current rules allow backward incompatible changes that
>>     can only be detected by a line by line comparison of the yang modules. In
>>     a system with semantic versioning, you could determine backward
>>     compatibility just by reading the version numbers.
> I do not see why you need a line by line comparison. With semantic
> versioning, you _hope_ the semantic version number is a good enough
> indicator. It might also be that your client is only using a subset
> that did not really change even though the semantic version number
> changed. Or the semantic version number indicates only minor changes
> that sill break your client.
BALAZS: Line by line comparison is needed, because today anywhere in the 
model you might find a new status deprecated statement. You are forced 
to do the line by line comparison and even that is no guarantee of 
compatibility due to behavior changes.
Yes you might set the semantic version incorrectly, but that's a bug. 
You might use other parts of YANG incorrectly too.
>
>>     CH 2.3)
>>     As we need to create a new Yang Module (YAM) even for the smallest
>>     incompatible modification, this increases the number of modules.
> So it seems to boil down to the question whether foo and foo2 is
> significantly more expensive than foo { semver 1.x.y } and foo {
> semver 2.x.y }. The main argument seems to be that the later keeps
> references that involve module names or namespaces unchanged (but
> they may or may not mean different things).
BALAZS: For SMALL NBC changes, I propose to keep the original module 
name. Now while agree it is possible to misuse this, and that SMALL is 
subjective, however we already have this situation. Removing stuff by 
deprecation is not much  better then just deleting the same.
In ericsson our internal definition of deprecation follows what e.g. 
JAVA does:
"Deprecated schema nodes MUST still work as defined by the YAM. The 
deprecated status serves only as a a warning that the schema node will 
be removed or obsoleted in the future."
This allows continued compatible usage while still warning the client, 
that the marked parts will go away soon.
>
>>     IMHO YANG package definition should be a separate issue, left out of this
>>     document. Andy has already provided some very good ideas about this topic.
> I think it is necessary to think about how the semantic version
> numbers are used. See my remark above about imports. If we allow
> incompatible changes, than this has side effects and I think we are
> not done by just adding a semantic version number without going
> working throught the implications.
BALAZS: I don't object, although I would prefer to handle them separately.
I do object to the word "if". Due to YANG's current rules for status we 
already allow incompatible changes.
>
> /js
>

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