Re: [netmod] Another comment/question on appendix B.2 of draft-ietf-netmod-yang-module-versioning-05

Scott Mansfield <scott.mansfield@ericsson.com> Fri, 03 June 2022 19:06 UTC

Return-Path: <scott.mansfield@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 31585C14F693; Fri, 3 Jun 2022 12:06:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.754
X-Spam-Level:
X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.745, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 182zmaF_wwnS; Fri, 3 Jun 2022 12:06:24 -0700 (PDT)
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on20606.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e8a::606]) (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 2B184C14F6E5; Fri, 3 Jun 2022 12:06:23 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=baPTVu5IKXn7Gf1QLfxUbsSTvkBXkOJp8EKy9Aa1xL4RHEmXfDvgsKfPjxyThzrn881hnkYBN5fQJgUVn/UsoutyZQS3t8hqzL+ro1e3T++zqp5HqFEVPCz9rIvzxyZd9UOsCqSjcdI227LdTd9AGNR0VJyTBzCm5SrbvzJINk1St/02+rTks6NDJRbAIJr4k+KYAIO4sbzghK/fzrhrsgHqDuwIU+VFtnA59c7V2r1fBgH3XR8u2VutuhWka8gTCvaT0zoOv/yZKaQpPACM8Vg/62babZzlkErwa+9lEqXYKm2ioxGklYaxqtvJVPP9sd39fSMkXmxlIVBkojHZnw==
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=OwQfugccUOfOOnLBHGyLTwMvQ4cAbQ9HUnYEk1Vcis8=; b=nzn1FZ21MyiFh1jjRGwoPzZXv+YmsuPRn8jg7eJphcB+XTaFJ8wXb1VD4Apyw1tG/Mbdgkld57cZtcMMXUhik7K47lPhyI3mRQUhrKoReGTAWLMr3UgjZscnWEIA+pA+1t7lB4uTC3S3PKIVkwSvNCdvNS7OCIRF7baNkDh7ZdtvXqElCo9cpXZFtoOAXXJ1tXI5p05cY/G1CahxXAGChTn9Oj1j1Mx4qkeizBr072ErMnaWPQQMTVzsc/XMCetfiqdC/IFdL/coVyAlSSkZZjTonaS6TIWLVyodKBZSeIaoBKlv33Uan4wFUX1SGiYKV0ieDX7vfPIEesqpXJCu1g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OwQfugccUOfOOnLBHGyLTwMvQ4cAbQ9HUnYEk1Vcis8=; b=pTlk6hwUwuwVir4hJXprV/ZwD4opEtRLpUQ9kDQx5s47yHxvBZ1hRSV8nyYLs/I0cqrxat/rGKWeKX5tTXxJSosXtoc/DHrCaO/IRMUcnWpXlhK/hPgaapoNYSsjfv8PYpAQ81YzZTNkmxzbIOpW1+VrCy3GwzpZQ53k1jpifRo=
Received: from BL0PR1501MB4130.namprd15.prod.outlook.com (2603:10b6:208:86::17) by MW2PR1501MB2091.namprd15.prod.outlook.com (2603:10b6:302:d::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5314.15; Fri, 3 Jun 2022 19:06:19 +0000
Received: from BL0PR1501MB4130.namprd15.prod.outlook.com ([fe80::e4d8:cf03:817f:207d]) by BL0PR1501MB4130.namprd15.prod.outlook.com ([fe80::e4d8:cf03:817f:207d%7]) with mapi id 15.20.5314.015; Fri, 3 Jun 2022 19:06:18 +0000
From: Scott Mansfield <scott.mansfield@ericsson.com>
To: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>, Italo Busi <Italo.Busi@huawei.com>, "netmod@ietf.org" <netmod@ietf.org>
CC: "'ccamp@ietf.org'" <ccamp@ietf.org>
Thread-Topic: Another comment/question on appendix B.2 of draft-ietf-netmod-yang-module-versioning-05
Thread-Index: Adh2AX6nfZwD+XITTPiHGgPWsoHa5gAwYxVgAC3h+6A=
Date: Fri, 3 Jun 2022 19:06:18 +0000
Message-ID: <BL0PR1501MB413004920467C521C461817B8BA19@BL0PR1501MB4130.namprd15.prod.outlook.com>
References: <49dffd7325274aa4a6327bdbb4798a71@huawei.com> <BN7PR08MB5073F864D99D58F9236EB88E9BDE9@BN7PR08MB5073.namprd08.prod.outlook.com>
In-Reply-To: <BN7PR08MB5073F864D99D58F9236EB88E9BDE9@BN7PR08MB5073.namprd08.prod.outlook.com>
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=ericsson.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 43ca46a4-1c3a-45d9-371e-08da459423fc
x-ms-traffictypediagnostic: MW2PR1501MB2091:EE_
x-microsoft-antispam-prvs: <MW2PR1501MB2091C244A60AF404154EB8AC8BA19@MW2PR1501MB2091.namprd15.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: QCg5aQqVIRYGYU+6yYj4SF63AdrS07eIn446FPYnziVz3ENp9AdHI5fLV4Xwfxyy6NhkQaQPvOXKY50B7au14eq2YON60AuX+B5T1ajBpv3hhRGAZ/HxyrDDS6ANSqtRansahzOr2RI+idlXKT1H8OZ1WLRhVsQrbRIJw9dFvTLPGE/VX11BqxbZjVO77q1FzoDLR89BqH18J0Y1w0CXTd+EhBUgsB1rV0dqvGZU2p3jsrg4lUb4XzfYWUwDdk9T+VxNdUG2dy6/TOh8blRBgiy73LTTO+APxBc0b9Pi1ynYDQAl4jtvs3EZOuSur4f4kYiq+Wn0Uw36FSNpoimk8FDpMFH9+osjek+my5tur8yX3AlE2BljzHCfENZSbUgV3QhRV/G9jFfZXssibX+wXqhgHB58M+vrIeACyf4b++8i+1fote8oBUavM+PEbfFVcEXk3xoY3Dh2SDzDfixJo1q+8hqC0cy18J90iQrlC0wptgf5gbW1L8NicWE/7igIIbHW68SuSyuFyx6I3PoKFXKqWaRtYuAnEZaO/YskRxZKrUHLg0L9H7Fi+Q2EhtLFOgvKQc8WtkZ4vxkv8SLQ2gKHh/TJ/9GHC9MTuyI/ojgYdhzmZePu/ysIgpbvn5976uragqPs4DMPfQ/pgbSBw9BJ6JlQZHR0bTop9IFg59mmyq/QQ20FZAE7yK+mS/wjSwECSS6+PPeo7URrtabYhESoZveg8xfV9rWzBL+vxHs6ZUZQbfCysGEo/N1lISuKBD1JyJtBi885i8HB8uePHfagAYaw2/D/3cwoVxCXTKY=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR1501MB4130.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(83380400001)(166002)(86362001)(186003)(33656002)(38100700002)(82960400001)(38070700005)(122000001)(26005)(6506007)(110136005)(7696005)(316002)(53546011)(71200400001)(508600001)(9686003)(966005)(296002)(2906002)(44832011)(4326008)(55016003)(66946007)(66556008)(66476007)(64756008)(76116006)(8676002)(66446008)(5660300002)(8936002)(52536014)(19627405001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?qRp4wn008N1L9FIOnmjBlXD4ak2Iz+boGyuBw32s8k6Cq1t8KlHhKovFyqSc?= =?us-ascii?Q?CKy+hj1aVj4ez5IuiF+TWgczSdiWMVDYLKaI4KQETkkgRhiXhtMTiKfNmSQp?= =?us-ascii?Q?IhFctSLLQ3B74JLdWBkcX6+k58nq3P6svDOwfhgBc5qYfHWWDP7lAfM3tQ+m?= =?us-ascii?Q?XKPUXgNlIcwRKipmB4y02HU0Ze+J/KkbixjDhfXQt3SGF9ctOr6wfT08TUQe?= =?us-ascii?Q?WOe20mrS46V2TBav9qeWc9ImDZnKKDtEAg4a4AD5s2YNEKLAuw6nXCh3oZZz?= =?us-ascii?Q?YguU1r9VuFVtm+fxgrdSmM/JnmUENlTKbNTzIS12lL/i6CBmPyiDPp0zLxwJ?= =?us-ascii?Q?Yod5GT9gKKitK4eyhop909OUuJr4B4DrokOfF1Qw8yKLZNlEsum76tMkiedt?= =?us-ascii?Q?UMUWDpkyQiGpz4YTz3WrQseo8+hw41+LZGqJZpiQ3naLQslZoR2ankn0kw+D?= =?us-ascii?Q?NuIIicUAzyoyW72DD4AIuuW4Z7CTyDDAJhYh4WKEmZIuc05+V+5uwRE/sSYi?= =?us-ascii?Q?ArItm1jverud6bwyuMQYrZZMzFylpJoyLQKqQePQRohsipvMoAcpLevs979e?= =?us-ascii?Q?4NSk0B2n+SW7q/9qHinXIZ/paF57YfZ2KzSRuUNfpElqz0f6Q7P/V8RiVakB?= =?us-ascii?Q?lLJRwTKyKi37VRIJz1mDOxL6b06p0mnGtMe9sBwpleW1/jUqILl6PqECPrLJ?= =?us-ascii?Q?5lUfFx9P8gdF0P81hR6KR+NmQ3zeAZkHOXhOFAEzHrpSJi2zC2kGwDDEf+Bz?= =?us-ascii?Q?qHv3AH4W0p1Wt2TRnG522HGSJC2UP8riqY4ie9cPvGFQpUWLqYhhcl31Rq4m?= =?us-ascii?Q?XoNPs7Lyj9mZ3l4FGb42XuHLDdocqXM5Dii9tAgUtp10RCIXzSGKTU7c52Ky?= =?us-ascii?Q?9D1WChBfabkQwhCf+HCwQzlYwMsCSU3/z5COLZPj7WJJdy3yHNrUafYbD3xd?= =?us-ascii?Q?mvD0l4m1iWA8+t1GrVpkIxsXXpHkoQYE1DkAN+MjdGhTE59hhrk5Mnfzdwut?= =?us-ascii?Q?uapiBPIq3+8+VHYywBdbLZqznzcDkHfqUUklw0vncqNrUSCkt1nPuCczg+4d?= =?us-ascii?Q?4AJ7sgcdWrtK+252U3esaTtGLl+Xw63IgDnlVz/lRGuz+I06NOs64AwRYEa4?= =?us-ascii?Q?1bNegEmjauvjcR9rJ+QA9kNsZJeTWoQSqkMefmbxpqEUngtaVVFoLQjGe6ze?= =?us-ascii?Q?IahQX9vyHHrO2sqlILP0bhelOVrWliIFizTOnrfD3uRfaBqqt2RBX8kgY4KK?= =?us-ascii?Q?DLcVwCMtSFUl1lQW28BzQgDFMvoOE4lygPistsI5sNN4c5KSqFn+OYrNKwtm?= =?us-ascii?Q?4YDnanpa88XpQAD1+glZy++21vJCvMkOXQ0cnObIYwL0d8lmpQQn/mlyvgM+?= =?us-ascii?Q?yoNoW+uOWI/HtgEL/H9aVn6EZYukgkOPnh59FOuSmwzvF+LnCQX3/czsc1QG?= =?us-ascii?Q?hxSxgNEhMM2cnasZ3DvxbywpDxr3ruzYDiuDxBOnZIsvUWUQTKw4WQKbi/FN?= =?us-ascii?Q?L4QYwb30AjTEvdFGkBUQUXXpmHhxEaTz2QsdJKM0DBEfDrGT88/h9YUU7mjQ?= =?us-ascii?Q?G8f90PW2ldBtjivxhY6Igna/0tcoqup7xLhfxiJCv5xYbWUiNIoqE46/4Ona?= =?us-ascii?Q?8OkvD2GWRDBigqkREsIX+Imf9OAVvoBR0PtQTBN+1QfnRE86CXOK5QmgBMT+?= =?us-ascii?Q?8DpIrly+a2inGtvTzB4EDfa3agdi/sqN6Krq2WgtPrz9sbd4/zaBjLe5Ifgq?= =?us-ascii?Q?w1CTvaEBy0gtL4FReu2DW7ifUKMgHYU=3D?=
Content-Type: multipart/alternative; boundary="_000_BL0PR1501MB413004920467C521C461817B8BA19BL0PR1501MB4130_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR1501MB4130.namprd15.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 43ca46a4-1c3a-45d9-371e-08da459423fc
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jun 2022 19:06:18.7242 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: vrJA9Zpv2Hd+Ps5e9R39Qb9OhZMfZAOqpv7jT7pHYxwes+/5MOS/OqWXMMlC/WMKgERMheZ1cEKGFu2Wzl+P8IEN+mISNbeqKjYe61HWL7E=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR1501MB2091
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/KJRnRrxZSNEsSOXUn8b_wZrt224>
Subject: Re: [netmod] Another comment/question on appendix B.2 of draft-ietf-netmod-yang-module-versioning-05
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: Fri, 03 Jun 2022 19:06:29 -0000

So basically, deprecating a leaf and adding a new leaf/container that replaces the deprecated leaf will always be NBC.

Still the guidance in B.2 has the least impact and is easy to explain, and has the added benefit that the tree doesn't change and existing (old schema) instance data will work with the new schema.

-scott.

From: CCAMP <ccamp-bounces@ietf.org> On Behalf Of Sterne, Jason (Nokia - CA/Ottawa)
Sent: Thursday, June 2, 2022 5:03 PM
To: Italo Busi <Italo.Busi=40huawei.com@dmarc.ietf.org>; netmod@ietf.org
Cc: 'ccamp@ietf.org' <ccamp@ietf.org>
Subject: Re: [CCAMP] Another comment/question on appendix B.2 of draft-ietf-netmod-yang-module-versioning-05

Hi Italo,

One problem I see with this change is that in the old data model, the leaf "mode" had to exist in the instance data. But with the new model, it is valid to have instance data with no "mode" leaf at all. That instance data would not validate against the old YANG model.

I do see your point that any valid data that could be generated using the old model is still accepted in the new model. But for the YANG versioning work we've been pretty hesitant to diverge far from RFC 7950 for the list of what is NBC vs BC (mainly just cleanup of the status deprecated & obsolete), and clarifying

There are other possible cases that might meet a definition of "any old config would be accepted by the new model" but we still don't label them as BC in our YANG versioning work, e.g.:
- moving a pre-existing leaf into a new choice along with new elements in other cases (like yours below but without any additional complications of "mandatory" statements)
- changing the type of a uint8 to a union of uint8 and other types

Jason

From: netmod <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org>> On Behalf Of Italo Busi
Sent: Wednesday, June 1, 2022 6:07 PM
To: netmod@ietf.org<mailto:netmod@ietf.org>
Cc: 'ccamp@ietf.org' <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: [netmod] Another comment/question on appendix B.2 of draft-ietf-netmod-yang-module-versioning-05

The example (in particular in point 3.1), assumes that it is possible to put the old deprecated leaf and the new leaf within a choice to ensure that the new node is not used when the old node is used

In the context of an update to RFC8561 (-00 I-D still under preparation) we have found a similar care where the choice could also be beneficial to express the requirement that the new node is mandatory when the old node is not used (in other words either the old node or the new node MUST be configured)

You can find a simplified example of the change we were considering here:

https://github.com/samans/testing-yang/tree/main/mw-option<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-dc62b26de858ae3b&q=1&e=885085f0-90e5-462d-827c-73bc1e45f9fc&u=https%3A%2F%2Fgithub.com%2Fsamans%2Ftesting-yang%2Ftree%2Fmain%2Fmw-option>

The original (using the old style mode) is in mw-option@2022-04-01.yang<mailto:mw-option@2022-04-01.yang>. the new version of mode (rlt-mode) is in mw-option@2022-05-26.yang<mailto:mw-option@2022-05-26.yang>

However, when we use pyang to check backward compatibility we get an error message (see the nbc.out file in github):


mw-option@2022-05-26.yang:47<mailto:mw-option@2022-05-26.yang:47>: error: the leaf 'mode', defined at mw-option@2022-04-01.yang:40<mailto:mw-option@2022-04-01.yang:40> is illegally removed
mw-option@2022-05-26.yang:50<mailto:mw-option@2022-05-26.yang:50>: error: the mandatory node mode-option is illegally added

However, we have checked that the xml file mw-option.xml, which uses the deprecated style of mode, works fine also with the new mw-option@2022-05-26.yang<mailto:mw-option@2022-05-26.yang>. We therefore think this type of change can be considered backward compatible since an old client would not break when trying to configure a new server which implements the deprecated node

We are therefore not sure whether this is a tooling issue or a specification issue

Reviewing clause 11 of RFC7950 and draft-ietf-netmod-yang-module-versioning-05, it seems that moving an existing leaf under a choice is not listed as a backward compatible change

We are wondering whether draft-ietf-netmod-yang-module-versioning-05 could clarify that this type of change can be considered backward compatible

We would appreciated any clarification by Netmod WG expert about whether this change can be considered backward compatible or not

Thanks, Italo (on behalf of co-authors working on a new I-D for updating RFC8561)