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

[Andy Bierman <[e-mail]>]

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