Hi Andy, I just posted a new version of the draft, diff is here: https://author-tools.ietf.org/iddiff?url2=draft-jouqui-netmod-yang-full-include-02
I provide some answers in-line. Best, Jean From: netmod <[email protected]> On Behalf Of Andy Bierman Sent: Thursday, March 21, 2024 4:35 PM To: NetMod WG <[email protected]> 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. Yes, so the semantics is the same as for Schema Mount, what’s inside an embed cannot access the outside. All leafref, must, and XPath in general is as if the root / is the embedding point. Trying to ../../ your way out of the embedding point is not possible as the embedded module must be valid even if not embedded. 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. Here we are in the design-time, so we don’t have the requirements to have such a strong decoupling. We design the model to embed other existing model. That being said, I added a section about how to augment the YANG library to define the content of each embedding point. 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>. True, so we would list module that are embedded as imported in the YANG library. To a client unaware of the extension, there would be no expectation of finding data nodes of modules that are only embedded and not present at the root context. 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? Same as for schema mount, rpc become action and notification can be declared anywhere. 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. It seems that adding the simple rule “a module cannot embed itself” is sufficient to prevent a truly recursive schema. I added a pseudo-demonstration of that in the “Recursive embedding” section. IMO this is an interesting topic for yang-next. Andy
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
