Lou Berger <[email protected]> wrote: > Martin, > > On 1/17/2017 7:29 AM, Martin Bjorklund wrote: > > Hi, > > > > Currently, the schema mount draft says that the "mount-point" > > extension only can be defined in an "anydata" node. However, this > > doesn't really work, since RFC 7950 says: > > > > An anydata node is treated as an opaque chunk of data. This data > > can be modified in its entirety only. > > > > But the idea with schema mount is to build a composite model that can > > be manipulated just like a normal model, or a model that is > > augmented. If we mount models in an "anydata" node, clients would > > have to replace the enitire mounted subtree in order to change e.g. a > > single leaf. > > > > For this reason, I propose that we go back to the previous model where > > "mount-point" would be allowed in "container" and "list". Note that a > > client that doesn't know anything about these mounts would see some > > nodes in some unknown namespace; just like in the case that there is > > an augment that the client doesn't know about. > > would it be better to have the schema mount draft updates 7950 to allow > for sub-tree changes under anydata? It "feels" cleaner and I'd expect > to have no real impact on servers as this would only impact servers > supporting the draft. I'm unsure about client impact though...
Actually, this would have bigger impact on servers, than on clients; a client could still treat the entire thing as an opaque blob - but that's not what we want. I prefer a solution that doesn't change the core YANG semantics. The text in 7950 is pretty clear, e.g.,: Any "operation" attributes present on subelements of an anydata node are ignored by the NETCONF server. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
