IETF Logo Mail Archive

Re: [netmod] comments on draft-jouqui-netmod-yang-full-include

Jean Quilbeuf <jean.quilbeuf@huawei.com> Thu, 21 March 2024 20:15 UTC

Return-Path: <jean.quilbeuf@huawei.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 132E4C1CAF52 for <netmod@ietfa.amsl.com>; Thu, 21 Mar 2024 13:15:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNsj4059YbZm for <netmod@ietfa.amsl.com>; Thu, 21 Mar 2024 13:15:42 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90FA1C1D4A8C for <netmod@ietf.org>; Thu, 21 Mar 2024 13:15:42 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4V0xX72P4Kz6896B for <netmod@ietf.org>; Fri, 22 Mar 2024 04:15:03 +0800 (CST)
Received: from frapeml100001.china.huawei.com (unknown [7.182.85.63]) by mail.maildlp.com (Postfix) with ESMTPS id 8AC3E140A9C for <netmod@ietf.org>; Fri, 22 Mar 2024 04:15:39 +0800 (CST)
Received: from frapeml500001.china.huawei.com (7.182.85.94) by frapeml100001.china.huawei.com (7.182.85.63) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Thu, 21 Mar 2024 21:15:39 +0100
Received: from frapeml500001.china.huawei.com ([7.182.85.94]) by frapeml500001.china.huawei.com ([7.182.85.94]) with mapi id 15.01.2507.035; Thu, 21 Mar 2024 21:15:39 +0100
From: Jean Quilbeuf <jean.quilbeuf@huawei.com>
To: NetMod WG <netmod@ietf.org>
Thread-Topic: [netmod] comments on draft-jouqui-netmod-yang-full-include
Thread-Index: AQHae636VkmWvOClm06PVPtrXRbi07FCnJow
Date: Thu, 21 Mar 2024 20:15:39 +0000
Message-ID: <c631bf99beb44f2780ffcb781f7cd64a@huawei.com>
References: <CABCOCHR09_9hAKK_m1pBgQK2Ca0Jo70tKNgULW-4GNq_Y4NDAw@mail.gmail.com>
In-Reply-To: <CABCOCHR09_9hAKK_m1pBgQK2Ca0Jo70tKNgULW-4GNq_Y4NDAw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.206.138.136]
Content-Type: multipart/alternative; boundary="_000_c631bf99beb44f2780ffcb781f7cd64ahuaweicom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/m0cby5DNM-3o-cQb6ZJ2v2s57RY>
Subject: Re: [netmod] comments on draft-jouqui-netmod-yang-full-include
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: Thu, 21 Mar 2024 20:15:47 -0000

Hi Andy,

Many thanks for your comments, they make a lot of sense. We will work on it and propose a new version of the draft.

Regarding point 5), can you elaborate on the problems caused by the anydata node. As I see it, it is inconvenient to have this extra node which does not have any real meaning. Is there any other issue with this anydata node?

Best,
Jean

From: netmod <netmod-bounces@ietf.org> On Behalf Of Andy Bierman
Sent: Thursday, March 21, 2024 4:35 PM
To: NetMod WG <netmod@ietf.org>
Subject: [netmod] comments on draft-jouqui-netmod-yang-full-include

Hi,

The presentation yesterday helped me understand the motivation for this work.
Seems simple enough, but rife with unintended consequences.
RFC 8528 does a good job of dealing with most of these issues, but it is not a design-time
modification like this draft is proposing.

I would like to see this work as part of yang-next, but not thrown in with YANG 1.1.

Just some of the major issues to solve:

1) XPath
The issue of leafrefs was raised but of course this also applies to must/when statements.

2) Shared yanglib
This draft shares the top yanglib.
Schema Mount implementations allow completely separate YANG libraries
that are decoupled from the top yanglib and other mount points.  This allows
deviations, features, etc.


3) No way to include data nodes only at the mount point.
To a YANG 1.1 tool, if a module is listed in the yanglib then all its
implemented top-level objects are part of <running>.

4) Not clear what is included and scoped at the mount point
There are lots of top-level YANG statements that are not data-def-stmts.
Are these ignored? What exactly is included?  What changes to identifier scope resolution
are being made?

5) anydata as root
This causes more problems than it is supposed to solve.
IMO Schema Mount got this right, keeping it a container or list.

6) Recursion and Loops
This adds significant complexity to the implementation.

IMO this is an interesting topic for yang-next.

Andy

v2.23.0 | Report a Bug | By Email