Re: [netmod] yang versioning solution complexity and alternative approaches

"Rob Wilton (rwilton)" <rwilton@cisco.com> Tue, 07 June 2022 12:55 UTC

Return-Path: <rwilton@cisco.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 3390FC13C2E0 for <netmod@ietfa.amsl.com>; Tue, 7 Jun 2022 05:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.605
X-Spam-Level:
X-Spam-Status: No, score=-9.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=aLJ5oaOv; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=s9JPsNEd
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxVCH87N9ebV for <netmod@ietfa.amsl.com>; Tue, 7 Jun 2022 05:55:11 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B303C13C2DE for <netmod@ietf.org>; Tue, 7 Jun 2022 05:54:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19258; q=dns/txt; s=iport; t=1654606474; x=1655816074; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=J26W+E6XeDNOROGcgzy/R3QSONyRRuo3cLbejLc6vjY=; b=aLJ5oaOvHPZm2qvsj2UME1fdjMJCvGjU9y9wqbj2Q+ccEAoNFavp0pew DnRJkOD5E1x80uStYa9bNnibWgGe2vIFJiAfQS2Q0taVEfKMla5F0fkp4 Xa7h4HX1LoT8Y/kwI6HlQUab/A3em5/1d+TJSmZ8Np4oauJ+n3J58ljFu k=;
X-IPAS-Result: =?us-ascii?q?A0BpAQBTSp9imJldJa1QBwOBCYFPgVJSfwJZEydEhE6DT?= =?us-ascii?q?AOFMYULgwIDmzqBLBSBEQNUCwEBAQ0BASwNCQQBAYIOgi9FAhaFMAIlNgcOA?= =?us-ascii?q?QIEAQEBAQMCAwEBAQEBAQMBAQUBAQECAQcEFAEBAQEBAQEBHQcGDAUOECeFa?= =?us-ascii?q?A2GQgEBAQECAQEBEBERDAEBLAQHAQsCAgIBCBABBAEBAwImAgICGQwLFQgIA?= =?us-ascii?q?gQOBQgTB4JbAYJlAw0jAwEOnxcBgT4Cih96gTGBAYIIAQEGBASFDRiCOAMGB?= =?us-ascii?q?YEMLIMUhC2GKnsnHIFJRIFYgWYvUj6CYgEBgTMEDwIaFQomgw83gi5jjgeDV?= =?us-ascii?q?YE1gzodOwNHNBKBIXEBCAYGBwoFMgYCDBgUBAITElMdAhIMChwOVBkMDwMSA?= =?us-ascii?q?xEBBwILEggVLAgDAgMIAwIDIwsCAxcJBwoDHQgKHBIQFAIEEx4LCAMZHywJA?= =?us-ascii?q?gQOA0MICwoDEQQDExgLFggQBAYDCS8NKAsDFA8BBgMGAgUFAQMgAxQDBScHA?= =?us-ascii?q?yEHCyYNDQQcBx0DAwUmAwICHAcCAgMCBhcGAgJxCiYNCAQIBBwdJRAFAgcxB?= =?us-ascii?q?QQvAh4EBQYRCQIWAgYEBQIEBBYCAhIIAggnGwcWNhkBBV0GCwkhHCkLBgUGF?= =?us-ascii?q?gMjcwVIDyk0ATY6FhoFBB8BG5N/hDQRFRktBgEBDQg0CRABAycIAxEQCRcmC?= =?us-ascii?q?QwgCgwHAyoVBCQCFSQLAi0DkWteA4Mcl0OSGYEwCoNOoCwVg3WMP4ogjgeWa?= =?us-ascii?q?aIxhFkCBAIEBQIOAQEGgWgLKIFbcBU7gmhRGQ+OLA0Jg1AzhGGFSnUCOQIGA?= =?us-ascii?q?QoBAQMJjSwCJgeCGQEB?=
IronPort-PHdr: A9a23:Xx61uhNuGi/juGu2TLEl6ncDWUAX0o4cdiYZ6Zsi3rRJdKnrv5HvJ 1fW6vgliljVFZ7a5PRJh6uz0ejgVGUM7IzHvCUEd5pBBBMAgN8dygonBsPNAEbnLfnsOio9G skKVFJs83yhd0ZPH8OrbFzJqXr05jkXSX3C
IronPort-Data: A9a23:vxlrFKnQOZCE2Gzw5WtiiRro5gytJkRdPkR7XQ2eYbSJt1+Wr1Gzt xIdDz3VaPfbZTf0c411Odux8xsPu8TQy4QyHAdoqC89FFtH+JHPbTi7wugcHM8zwunrFh8PA xA2M4GYRCwMZiaA4E/raNANlFEkvU2ybuKU5NXsZ2YgHGeIdA970Ug5w7Bh3dYx6TSEK1rlV e3a8pW31GCNg1aYAkpMg05UgEoy1BhakGpwUm0WPZinjneH/5UmJM53yZWKEpfNatI88thW6 Ar05OrREmvxp3/BAz4++1rxWhVirrX6ZWBihpfKMkSvqkAqm8A87ko0HMQuQ3lasS24pcEr8 9tkrr3uUFdzIJSZzYzxUzEAe81/FbdN9LmCKn+lvInJiUbHaHDrhf5pCSnaP6VBpb0xWj4Ip KdecW1WBvyAr7reLLaTUPZtgtgkKuHgPZgUvTdryjSx4fMOEcCcH/6UuoMEtNs2rsBRMcTcO 9AEUxFEfDPhZjR1FFISFo1ryY9EgVGmI2EH9zp5v5Ef5WXPyQt9+LngLNSTfcaFLe1X2F2Tp mXL+XvwDxUWOca3yzOO9Xi3w/LJnD32QpkTCKz++vMCvbGI7nYYBBtTXlyhrLzjzEW/QNlYb UcT/0LCsJTe6mSVfPPDUiegkUSV5CUScsFxTfRqsh+0n/+8DxmiOkAISTtIadoDvcAwRCA32 lLhoz8PLWEz2FFyYS/Bnop4vQ9eKgBOdz5eOnVsoR8tpoi9/9lp0XojW/45SMaIYsvJ9SYcK txghBI/jLUal8IQ0KPTEbvv3G/09sGhouLYGmzqso+N9Ah1YsuuYJalrAKd5vdbJ4HfRV6E1 JTlpyR8xL1eZX1uvHXQKAnoIF1Pz6zUWNE7qQU1d6TNDxz3pxaekXl4uVmS3ntBPMceYiPOa 0TOow5X75I7FCL0MPMqP9rrUJ9xnPaI+THZuhb8M4cmjn9ZKVHvwc2STRX4M53FyRJ1yvhvZ f93j+71ViZGYUiY8NZGb75NjeB0rszP7WjSXpv8hw+2yqaTYWX9dFv2GAXmUwzN14vd+F+92 48Gb6OikkwDOMWjM3K/2dNCcjgicyNhbbio8JM/SwJ2Clc8cI3XI6WNm+lJlk0Mt/k9q9okC VnnBh4Akgah3y2bQehIA1g6AI7SsV9EhSpTFUQR0ZyAgiBLjVqHhEvHS6YKQA==
IronPort-HdrOrdr: A9a23:SLzpWaAbug68jzflHejosseALOsnbusQ8zAXPh9KJyC9I/b2qy nxppgmPEfP+UossHFJo6HlBEDyewKiyXcT2/heAV7CZniohILMFuBfBOTZskXd8kHFh4xgPO JbAtVD4b7LfBlHZKTBkXKF+r8bqbHtms3J9ITjJjVWPHtXgspbnmBE43OgYzRLrX59dPwE/f Snl696jgvlXU5SQtWwB3EDUeSGjcbMjojabRkPAANiwBWSjBuzgYSKUySw71M7aXdi0L0i+W /Kn0jS/aO4qcy2zRfayiv684lWot380dFObfb8yfT9aw+cyDpAVr4RH4FqjwpF591HL2xa1u Ukli1QevibLUmhJ11d7yGdgzUImwxelUMKgWXo8EcL5/aJHw7Tz6F69N9kmtyz0Tt7gDg06t M640uJ85VQFh/OhyL7+pzBUAxrjFO9pT44nfcUlGE3a/pUVFZ9l/1XwKpuKuZJIMs60vFSLM B+SMXHoPpGe1KTaH7U+mFp3dy3R3w2WhOLWFILtMCZ2yVf2CkR9TpU+OUP2nMbsJ4tQZhN4O rJdqxuibFVV8cTKaZwHv0IT8e7AnHEBUqkChPfHX33UKUcf37doZ/+57s4oOmsZZwT1ZM33J DMSklRu2I+c1/nTceOwJpI+BbQR3jVZ0Wm9uhOo5xi/rHsTrviNiOODFgojsu7uv0aRtbWXv 6iUagmdcML7VGebrqh8zeOKaW6c0NuI/H9kuxLLm6zng==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.91,283,1647302400"; d="scan'208";a="887436744"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Jun 2022 12:54:17 +0000
Received: from mail.cisco.com (xfe-rcd-001.cisco.com [173.37.227.249]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 257CsH4P009409 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 7 Jun 2022 12:54:17 GMT
Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Tue, 7 Jun 2022 07:54:16 -0500
Received: from NAM04-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Tue, 7 Jun 2022 07:54:16 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W12ZXogR9bt2uZ2k6SjSoGp/dP98E70FbW1XzK2vq9Tfsc+B+OBgGpHqN62Bu8VxyE8xJR7CVonOwOTymuSoEKA65/neSnun0BZBlO07l8OomQfA2lbQ9d7pKp39hcXKf8iJxsuqSONHmHKTXs6RTYhzVOQrIte9OumSkXDtXAH675pseZd9dYiDW4MrklepyHVOWLms3naomIpJazgbvdZ6E8IVG/HPHI8ynGQOQgULYdBVsL6B7xzco+x8XH9y+TgU5VmEo9yINFD5w3cy7CnyzE0kG0tvhx3v9a8TkfsmwNyWPAD81mrwtXGy8ctaNMSQ0VwXq2X3+AtTJ24oSw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=J26W+E6XeDNOROGcgzy/R3QSONyRRuo3cLbejLc6vjY=; b=BbivFNzYV0jTcDwkN2ZTTeStInyuIJw7jWr041m7rM7HFWBDiR6vTg+VB2IMtpwKMADng5Y/fSZIIh/q+jTbYH5xKDaahUOJgPWxm6NcnqGxf3JQzxZ5Yvtum9ai/rkbzK9NC7a/aCRPdySNjSSO+rlk03VisMOieH5hVKUQj/JtKts1fPrEYrm1QwGL9PTBaXK1nLJRNUa2nVvkt64g2dU/G2ft5G2Vgnw/tXTvr/+jiNi2rQ7uMhQONaKjy4SzoUrSr5fFLmapNpuPAb2thLH7psiewpEdaGckG3UXmSXlls/Mv1MD2eegUeZOp81xrdhl9fpSe+uijb32muT/XQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J26W+E6XeDNOROGcgzy/R3QSONyRRuo3cLbejLc6vjY=; b=s9JPsNEdX5wc+nJJJMBseS4UqkyIawwAqtk0cdAq8s4hJjgF9ua0o4AO1QRZF87egEgDPKK8E27uVC/dGZST6F6s3jd5mmm1xYd21TuVabO68LtPlbbCoEbCctzKddcrSsj8a49RDWb5Y4qhAt5GRivFAUncK2rknZMXDeXQZp8=
Received: from BY5PR11MB4196.namprd11.prod.outlook.com (2603:10b6:a03:1ce::13) by CH2PR11MB4293.namprd11.prod.outlook.com (2603:10b6:610:40::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.15; Tue, 7 Jun 2022 12:54:15 +0000
Received: from BY5PR11MB4196.namprd11.prod.outlook.com ([fe80::3058:531e:853f:9e9d]) by BY5PR11MB4196.namprd11.prod.outlook.com ([fe80::3058:531e:853f:9e9d%6]) with mapi id 15.20.5314.019; Tue, 7 Jun 2022 12:54:15 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= <j.schoenwaelder@jacobs-university.de>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] yang versioning solution complexity and alternative approaches
Thread-Index: AQHYM57GGVfvLMjjO0eJSnXM6AEkRazAdKbg
Date: Tue, 7 Jun 2022 12:54:14 +0000
Message-ID: <BY5PR11MB41967D79E62D8D08CBEF6128B5A59@BY5PR11MB4196.namprd11.prod.outlook.com>
References: <20220309101609.d33knxlhyq62wejq@anna>
In-Reply-To: <20220309101609.d33knxlhyq62wejq@anna>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c8294de5-8f53-45b4-f0e0-08da4884d3a2
x-ms-traffictypediagnostic: CH2PR11MB4293:EE_
x-microsoft-antispam-prvs: <CH2PR11MB42935C1A886831B5FDC9D7D2B5A59@CH2PR11MB4293.namprd11.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: fSGwqGQWLgN6CDkPvAPUPRk95JHbkm8GGKIUpaVJ8kpigaW87boRuEn5xl8coXs+ibDeY+Vzt63dQwO6hV4Y9M0grK6X6i1oZEdEz/n0ywjn9+uPDUZ+EOTbux3ZjYqeQYXukMhgAQOpeTJFDxZRv6PwN5dkekUNEmyJtmq4wUDFBgoXY/WgMvWDDIwWgeqfV9EDMJoiD3TVuQO1ZNiO80A+AR8dUsg2aoss1DkDhvGNFZMcp6zltPzL3JYrFPYUaKAxWIyfTeqSS3tr6Rtj6AL/P0MYIQO4mVs/z/o34fPpQ+F08q9yDrvy4PSZUwGicXGplHQOCdPD3sMGM1FS4gtZY76wEna4wdYnZvXA7DlqCII/jaCmyHVhYsJ67vI5zdO53wqvUuE7VYk8QzPj9EnumFZXNWyoBlkMUtc8ihWDRiT+0AEBYm+tGl53I9f928qCeusavpgO4aJZZV6P6HkG4aNyvWwlCOuZQrkpdXD5ssjFE3ugA/34eXCOc4Du42tmvV6rIWWc6oLNTpYEv8RNtMhcY+pYS+ueESAEjBgoXItD+n7pXzTPC1W2s/GqHMiy2U43QDI21TgExalX4z9Cx0McBkgAeonfUbjLcDA8K0OHIG/CZz6totQpogy9VsE98gIIWVPBW7o9LL89tq5zsHSTJtw5DBAQqXUg8rBpNAKrTUdtp+HVOE5fOmntdK2iCpKTG80XBxv2ajt3vSfrnCSpBYGiiLVlXd45hBA53vn75C8Pv0g74ZTlJX2fs0wyPUeDmfw5NvoedwvOAL0EGkROvhJQG8wJJmbiYqOtdueC74q85eEtOxgcn9oS7y52VcBN+H02E4DLLAphzw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4196.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(30864003)(55016003)(64756008)(66446008)(38070700005)(2906002)(76116006)(7696005)(6506007)(316002)(122000001)(53546011)(9686003)(4326008)(66556008)(8676002)(66476007)(6916009)(40140700001)(66574015)(38100700002)(66946007)(83380400001)(186003)(86362001)(52536014)(508600001)(8936002)(71200400001)(33656002)(5660300002)(966005); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 2
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?S1Q0T2htb25sQnJ2dlIydVkrRmdQK1dsOEdQbm5aODc1b1p1WkdBSEZtMHho?= =?utf-8?B?czVad2M2QXZZSVQyazl2bHYxSXFaeWNWdXgveUh0cktDSmFqT0NTTkpIeUwy?= =?utf-8?B?bHRtb0w5ZHBldFM2WnBjZjErMUZKejk3a0lQNEdBUllBTzhpM1dFcGJTVkdF?= =?utf-8?B?V3Yzbm16NGo0WEU5eFk4cmdwSW5KYThWK0FQait4cFdqV3hDZ25uSjU1UHdP?= =?utf-8?B?QmE4WklCbEl0VytXaThvbFZQZ0t3VWhsdG94OVFGZUdiVFg0UzBsODk2Ym9F?= =?utf-8?B?VlNvYnM0dTlOZ0NnSG9mV3EwSlFTNDZpUG93eVA2OU1yNDNvNTVYMmsrdEl2?= =?utf-8?B?T2FNYnl3R1dXdUs3dlo5c29vanpENWxsVS9CbHd6bUR2NzIrL2JuTDFMZ3pq?= =?utf-8?B?c3c2M1VNc0VWK0hncm5OemduWXdQdTN5TVlrNExxM1RId1JJUExsUStxb3VN?= =?utf-8?B?akZoTUFvNnNBemRqVEVFMEthWHlkZVltY2pXVE9McnVXTEtBTHBzNkxydFk0?= =?utf-8?B?bzVsOUJSMFVzcnFFbytadFp4NStNK2FVNlg3Qnc0WC9ndVhIWjhjTDlTR29X?= =?utf-8?B?S1RhSEJzZ2QyMGNRbHlJRjNJM0RxNElzeUYyT0hkbURvSnBEYVd5WHd4Vk9r?= =?utf-8?B?ZnlnL0hLNE9kNjNrOTdrZVhQdVo2b2FTVUh6UkJ1VEJIc2Mydm8yUjg4cjFw?= =?utf-8?B?OVJWVWRjbC9KajRiOVFZRWVVS2pWaXk3TE9QOTlVWnRWNGU3SGtYSVVBUUFq?= =?utf-8?B?N25oK2YxUDBKSWZKeFdVRjJSR2poNlFoZUtJdjQvaFNsd2pXVklPdS9seTNp?= =?utf-8?B?OVBMT3llbXVxVm52Y2xyTXhtRmdqc05mNlRlMnFicndkUm90UU4zb0wwd1hF?= =?utf-8?B?QjhSb1oyeDhlODVhY1JVbkhoelJDd0NXWU1weDVoN2lzV0lJWDJ1Tjc4azkr?= =?utf-8?B?YW8zWUdaWlFWckNFWitGMmpUcTFRd1pQRTRYWE92ZTY5TzRwTnZqNlB1QW9C?= =?utf-8?B?bml3bjhWNG90MGVZU0J0WVFuM1ZuZjVpZkprdTcvS3pneWg3V1hBcXo1ajdC?= =?utf-8?B?TDEwYW5XWlZyTDF0akFMSG1JamNmb1ZJemZYUG9laEh4MWVjWXZSajBibDRr?= =?utf-8?B?SnZ3NmFGMFAzVVJ2aTFKay9FcTdvcThZaldXVldaeXFkcktVNVhGc2huSXU5?= =?utf-8?B?YzhGVkNqeUlPSmxEeCsrOHhUcXYvU2lkNW1WVEdWOHdSelJHdkhOZFcwVzMr?= =?utf-8?B?V1hZSGY4bllPdEhiRjFVRDI5OHVBK3A5VWRDM3U0UFU3OURBOWR0bnpGRXZq?= =?utf-8?B?SDUxTFp3VkkrcllSVmpjUnJPbXQ5SzVKTlFNSStPckxpNDFrT3dLZE1MNmx2?= =?utf-8?B?dEhIQ2h3b3RISlRlSHJ3WmhHSWlyMWZyZmNRRGJUTGxjTWZSdzZtNU5WQkc4?= =?utf-8?B?eW1vLzcrVlFjM1B5VjVTdzFaeUErZzh6VHM4VllTM3dUVjJuRXFheDIwVXBr?= =?utf-8?B?L1VXYXJ2NWh2STFHZWRYSVg3SUlQTEpxREVpYnJBQWhQMVo4dHgwY3FYTmRz?= =?utf-8?B?ZVd2VVZ2K3prZnFiVjNxSjBuaW9peEh0TUVzQUdMQjBwRnlaK1g5NEpXRmdj?= =?utf-8?B?M2crSk03YnpvcmgvdXlncFU5TzV3Y2RYMmVGZ241dGl6Z2o2MnJrelRTNzVJ?= =?utf-8?B?blNMU29PVTNuMmJzSXl0WEQ1KzJ4Rkp5VXBQTGswdGV2RVBXQUszTzhKODFm?= =?utf-8?B?aVFLSGxjOVI3UlBnQndId0tqbE9kbkJ5Z2JsZUQvZUY3K1pYdEpHN3R5Zm8z?= =?utf-8?B?Q1BvYUJ3YVM0bXdDWlpsdVVSZzJLOExQUDljVXVQajNZQU05TERtTDFaTXB0?= =?utf-8?B?WVUvWkJ0SWE3VnFCVUxFTTZlaFhkb1FGU3pMaVl3ZHZvNVhTQ21GbGdRbFpS?= =?utf-8?B?UGlEbTNGMjM4UlE5YVdxTzB1emNWb2JxQmdtUzFxM1RBSzNmQ2daVzYvNVBT?= =?utf-8?B?b3JmZ2VjdjRrZXhwRERGTWljT0J1c1hHKzhVZU5aUC9DSWpleXdCaXVheVFM?= =?utf-8?B?WDF0VDV5ZXlmOWxxZHpvZGZ5bVB1TjV5L1JudEJwa083UVg5ZXd2bE9YTFBU?= =?utf-8?B?TmxDV1VjWWozUmVseEJTbGlwZzIzVWJIZXd6ZklNY0xsSjltdGFHTmhBSU1F?= =?utf-8?B?ak11WS9ESFYwbW9DaWI1RUc3RHBMcUZzQzliT1VZWXpUNjFMendRODZlN09G?= =?utf-8?B?VWFBMGQxbzMrUFVib3RkYUxBclMxOVhPYVdSVkVqQUNKVmk4SXV0LzBVcFNU?= =?utf-8?B?UHkwRFVLd3RiWUNMNE5tb0VnZGxCYnhEU0lEeWgvQVBvUnFXNkFpdlNpUWh6?= =?utf-8?Q?uE5UfN2FQy0k7sgtHDXW7lA5yi5K5wlFSUZiIeE/VaPNH?=
x-ms-exchange-antispam-messagedata-1: BmrmDkem+uFoIA==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4196.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c8294de5-8f53-45b4-f0e0-08da4884d3a2
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2022 12:54:14.9275 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: P/581/8TI4ZuYFxsqGynMF5LvdUAmawOL+21YY7T7gvhbv5WYBikT8vEe5NlSMVOYelnlptbZ+wdfn8xCQEmpg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR11MB4293
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.227.249, xfe-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/L8vDNkRFr7PlUDl_FIY8qWa6UZg>
Subject: Re: [netmod] yang versioning solution complexity and alternative approaches
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 07 Jun 2022 12:55:15 -0000

Hi Jürgen,

Thank you for your feedback and apologies for the very delayed reply.  The versions authors have been discussing some of the points that you raised in a lot of detail and hence I was waiting for this discussion to converge before replying to you.


> -----Original Message-----
> From: netmod <netmod-bounces@ietf.org> On Behalf Of Jürgen
> Schönwälder
> Sent: 09 March 2022 10:16
> To: netmod@ietf.org
> Subject: [netmod] yang versioning solution complexity and alternative
> approaches
> 
> Hi,
> 
> the YANG versioning solution appears to be complex.

I think some aspects of the solution are complex, but I'm not sure whether they are really avoidable, or whether the complexity comes from wanting to solve a complex problem.

One aspect of additional complexity is because of a WG desire stated during adoption and previous discussions to support different version schemes (E.g., YANG Semver, Open Config's use of vanilla Semver, vendor versioning schemes).

I think that keeping this flexible is a reasonable choice. I also think that having some version indicator at the module level (or in the case of YANG packages, YANG schema level) is beneficial.  For example, if my client is designed to work with module x@2.0.0, then if the server has actually implemented x@2.5.2 then it is compatible, assuming that module x has been updated according to the rules.   x@3.0.0 might also be compatible depending on what has changed - but as a client I had better check to see what the changes are to determine what the incompatibility is (using tooling).  I.e., I still think that version numbers provide more useful guidance (and partial relationship) than say revision dates, particularly given that YANG modules are not always strictly evolved in chronological order.

It was also clear to me when considering versioning schemes there is no perfect one-size fits all solution.  The YANG Semver approach is meant to be a pragmatic compromise.  I.e., encourage linear development, encourage backwards-compatible changes, but allow for non-backwards-compatible changes to occur and allow bugfixes to older revisions if required.

Finally, the wider versioning solution is also aiming to solve multiple different problems (e.g., package/schema level versioning, differentiation between backwards-compatible and non-backwards-compatible changes, supporting some level of branching for bugfixes, improving import dependencies, etc) which I think naturally somewhat increases its complexity.  We have somewhat tried to put these into separate documents so that each document can focus on specific aspects.


> 
> - We introduce version numbers that smell a bit like SemVers but then
>   are not really SemVer.

Yes, and no.  I'm not sure that there is really a canonical industry agreed definition of what Semver is, and hence we wanted quite a tight specification of what it means in the context of YANG, whilst still aiming to be mostly compatible with the Semver 2.0.0 definition.

We created YANG Semver for the sole reason that regular Semver or revision-dates are not sufficient to support one of the key requirements.  Specifically, the need to allow bug fixes to older shipped modules without the luxury of forcing both client and server to always migrate to the latest version of the module (e.g., as an Open Source software project might be able to do).

It is also worth noting that module authors have the choice of never branching older versions, and only ever making updates to the latest version, in which case YANG Semver is identical to Semver 2.0.0.


> 
> - We have no solution to do meaningful things with these version
>   numbers, it does not even seem to be possible to decide whether
>   X.Y.Z derives from x.y.z or not.

The derivation is based solely on the revision history in the YANG module file.  If the previous revision exists in the module's revision history, then the revision is derived from it.

The intention is that the version numbers represent a partial ordering.  E.g., moving from version X.a.b to X.c.d, where c > a, or c == a and d > b is a backwards compatible change.  This relationship breaks down when the _compatible and _non_compatible modifiers are used, but I regard these as a practical compromise to allow a limited form of branching.

Even with regular Semver it is not possible to know if version X.Y.Z derives from x.y.z.  Even with semver 2.0.0, it seems (the spec is somewhat ambiguous) that you are allowed to chronologically create 1.2.1 then 2.0.0, then 1.3.1.  And in this case 2.0.0 will not necessarily contain the content that was added in 1.3.1.


 We still seem to believe that
>   having compatibility constraints embedded in module imports are a
>   workable solution even though we acknowledge future breaking
>   changes.

This is a point of confusion, which probably means that we need to improve the text, since this isn't our goal for the "import by revision-or-derived".   Note, we did consider a more complete, and hence complex, solution, but this seemed to be the right pragmatic compromise of improving what we have today vs embedding too much information.

The only goal is to specify a minimum import dependency that the author knows is required.  E.g., if you are using a new type defined in RFC 6991bis then it is useful to indicate the minimum module revision that is likely to be compatible.  Later versions are likely to be okay, but that obviously depends on whether any non-backwards compatible changes happen and what the nature of those changes are.

YANG packages allow compatibility to be indicated for exact module versions outside the module.  We did consider whether YANG packages could be extended to cover ranges of versions, but that was deemed to increase complexity and best left to future work.  We had an issue tracking this, but after discussion closed the issue.


> 
> - We push for a reasonably complex algorithm to calculate deltas of
>   YANG module revisions to let users of modules to determine the real
>   impact of module updates on their work.

Please can you clarify.  Are you saying that the algorithm to determine whether a change is a non-backwards-compatible change is complex?  Or the encoding of it into a semantic version number is complex?

For the former, most of these rules were also defined in RFC 7950 but extended to fix some corner cases.  For the latter, this is basically the standard Semver which is widely understood but with a minor extension.

In both cases, I think that tooling can flag most of these warnings and calculate (or check) what the new semantic version number should be.  I'm not sure that this algorithm really ends up being that complex in practice.


> 
> I wonder why we not consider the opposite approach, namely to have
> author making NBC changes to document them right where the changes
> are. If authors would write something like
> 
>       leaf foo {
> 	nbc-change "2022-03-01" {
>           description "changed type from int32 to string";
> 	};
> 	// ...
>       }

In the discussions with the other authors the consensus was that these sorts of annotations are useful in some places.  I.e., the original intention is that this would be covered by the 5th draft of the versioning set, i.e., https://www.ietf.org/archive/id/draft-ietf-netmod-yang-schema-comparison-01.txt, but on further discussion we now believe that it may be more appropriate to define this annotations are part of the module versioning draft instead (which we would be keen to hear wider WG thoughts on).

The consensus of the discussions from other authors was:

- Providing a module level indicator of the type of changes is required, even if we have per data-node annotations.
- Consumers will ultimately need to rely on tooling to do module and package schema comparisons to determine what has changed and the potential impact of those changes to catch the case where the changes have not been correctly labelled by the authors.
- Using annotations doesn't really work in the case that a definition has been removed from a module.  Even after a deprecation/obsoletion phase this could still break clients.
- We were concerned that these annotations would end up cluttering the module definition with a lot of extra history, the desire is that the modules can evolve and each module version provides a snapshot of the API at that point in time.

We believe that the greatest value of the annotations is to use them when a change cannot be robustly detected by tooling alone, e.g., for changes to pattern, must, when, regex statements or descriptions.  There was also a question as to what the tooling should default to, if it cannot calculate what type of change is being made. 


Hence, we discussed three proposals on how these tags could be used:

Proposal A:
We provide both nbc-change and bc-change marker extensions but they are only expected to be used when a tool cannot reasonably automatically determine if the change is bc or nbc.
Or, in more detail, I would expect the following steps:
(i) A tool is used to compare a new revision of a module to the previous revision in its revision-history to calculate what type of changes the module contains and validate (or calculate) the module's Semver version label.
(ii) bc-change and nbc-change markers would be used where the tool cannot automatically determine what the changes are for a given statement (e.g., pattern, must, when, regex, description statements).
(iii) The module versioning (or tooling) draft would define change defaults for the case that the tool cannot be expected to robustly check.  I.e., the proposal would be to assume that pattern, must, when, regex changes are all nbc-changes unless annotated with a bc-change marker.  Description (and other similar) statements would be assumed to be editorial changes unless marked with an nbc-change or bc-change marker.
(iv) bc-change and nbc-change markers would also be allowed to be added at the authors discretion (i.e., it is okay to explicitly mark changes that the tool would be expected to identify anyway).
 
Proposal B:
The second proposal is the same as Proposal A, except that the nbc-change marker is mandatory to include everywhere where there is an nbc-change, i.e., even if tooling would be expected to detect it as an NBC change.
- This approach probably prevents an author from ever deleting a node (because you can't annotate what isn't there), instead a "tombstone" obsolete entry would need to be retained.
- I'm also concerned that this approach assumes that every change is implicitly compatible unless marked otherwise, and hence I think that we would still need a bc-change marker extension to be used to suppress possibly false nbc warnings by a module/schema comparison tool.  E.g., a tool might not be able to see that a change to a pattern statement is backwards-compatible and hence would probably need a bc-change annotation to avoid it incorrectly flagging it as an non-backwards-compatible change.

Proposal C:
The third proposal is the observation that we don't have to take the same approach for all sources of YANG models.  E.g., we could allow YANG modules generally to follow proposal A, but then mandate that IETF modules follow the stricter approach of Proposal B.  I.e., all nbc-changes must be explicitly annotated, and data nodes cannot be removed from published modules.


Between the authors I think that the discussion was leaning was towards proposal A or C.  But we would be interested in hearing other views from the WG.


> 
> then tool and humans can easily figure out in which revision NBC
> changes occured and if they affect a certain usage of the module.

Without a module (or schema) level indication then I think that this is harder for humans, giving a module summary indication is I believe also helpful.  I was also assuming that module revision description should highlight any NBC changes - maybe we should add text for this.

E.g., if over time most updates to modules are backwards compatible then being able to see that the device package version number changed in a backwards-compatible way is much simpler (but both humans and tools) than having to check all changes in all modules trying to spot non-backwards-compatible differences. 


> 
> Instead of simply properly documenting the changes, we invent fuzzy
> version numbers and complex algorithms to reverse engineer the facts
> that could have easily been documented by whoever makes the change.
> 
> If the reason is that developers do not document their changes, then
> go and develop tools to force them to document their changes. I do not
> think it is fair to simply push the pain to the users of YANG modules.

Note, the aim here is not to push pain on the users of YANG modules, but actually to act as a warning to the user.  I.e., if it is a minor version change then they should be safe to use the updated module version, if not then they need to check the changes more closely, and I agree that annotations inline within the module may be helpful for this.

But in all cases, whether we are talking about a version number at the module level, or annotations on particular data nodes, it is still plausible that publishers will sometimes get this wrong and we need good tooling (alongside bc/nbc annotations) to check when a module is published that it is following the rules, and which can also be used by clients to check that any breaking changes have been properly described.

Regards,
Rob

// All as a contributor and with no hats.


>   
> /js
> 
> --
> Jürgen Schönwälder              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