On Fri, Jul 5, 2024 at 6:42 AM Jean Quilbeuf <[email protected]> wrote:
> 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. > > > I don't really see any improvement over Schema Mount. SM is complex to implement in a server because it creates a "nested" schema tree, which is extremely implementation-specific. IMO it is not difficult to use in the client. It seems like it would be harder to use if the YANG library details were left out. It is not clear to me why a mount point with a static yanglib specified at design-time is needed. How will the vendor augment it, set features, or apply deviations and annotations? Even if there is an important use-case, the yang-next work would be the appropriate way to add it. Best, > > Jean > Andy > > > *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]
