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

On Thu, Mar 21, 2024 at 1:15 PM Jean Quilbeuf <jean.quilbeuf=
40huawei.com@dmarc.ietf.org> wrote:

> 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?
>
>
>

Changing the root from container to anydata does not remove any extra nodes.
The anydata node is a named node in the schema tree.

The problem is that YANG 1.1 defines anydata as a terminal node.
Within a configuration datastore, there are no accessible nodes within an
anydata node.
There are many cases where RPC or action input parameters are anydata and
the contents are
converted to real nodes when added to a datastore.  This is not the same as
full-include.

This draft proposes changes to YANG that are too severe and too important
to the core language
to be an optional extension.  The WG seems to prefer an ad-hoc set of
optional YANG extensions
to a mandatory set of language statements that all tools must support.

> Best,
>
> Jean
>

Andy

>
>
> *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
>
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>