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