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

Italo Busi <Italo.Busi@huawei.com> Wed, 01 June 2022 22:06 UTC

Return-Path: <Italo.Busi@huawei.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2B855C14F6E7; Wed, 1 Jun 2022 15:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id UYNmjqi3YLhS; Wed, 1 Jun 2022 15:06:45 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3768C14F727; Wed, 1 Jun 2022 15:06:39 -0700 (PDT)
Received: from fraeml713-chm.china.huawei.com (unknown []) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LD35r5zstz67KPR; Thu, 2 Jun 2022 06:02:08 +0800 (CST)
Received: from fraeml715-chm.china.huawei.com ( by fraeml713-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Thu, 2 Jun 2022 00:06:35 +0200
Received: from fraeml715-chm.china.huawei.com ([]) by fraeml715-chm.china.huawei.com ([]) with mapi id 15.01.2375.024; Thu, 2 Jun 2022 00:06:35 +0200
From: Italo Busi <Italo.Busi@huawei.com>
To: "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+XITTPiHGgPWsoHa5g==
Date: Wed, 01 Jun 2022 22:06:34 +0000
Message-ID: <49dffd7325274aa4a6327bdbb4798a71@huawei.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_49dffd7325274aa4a6327bdbb4798a71huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/LbCC-vmhFBwBtY67VZiQ86oXtis>
Subject: [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: Wed, 01 Jun 2022 22:06:47 -0000

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:


The original (using the old style mode) is in 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: error: the leaf 'mode', defined at mw-option@2022-04-01.yang:40 is illegally removed
        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. 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)