Juergen Schoenwaelder <[email protected]> writes:
> On Thu, Feb 04, 2016 at 11:46:47AM -0500, [email protected] wrote: >> >> Lou Berger <[email protected]> writes: >> >> > Juergen, >> > >> > see below >> > >> > On 2/4/2016 11:12 AM, Juergen Schoenwaelder wrote: >> >> On Thu, Feb 04, 2016 at 09:53:11AM -0500, Lou Berger wrote: >> >>> Juergen, >> >>> >> >>> see below. >> >>> >> >>> On 2/4/2016 9:12 AM, Juergen Schoenwaelder wrote: >> >>>> On Thu, Feb 04, 2016 at 08:02:26AM -0500, Lou Berger wrote: >> >>>>>> If more granular mounts are needed, then we should IMHO _not_ bundle >> >>>>>> this with the notion of YANG submodules. Perhaps you meant submodules >> >>>>>> in a more generic way, but then perhaps: >> >>>>>> >> >>>>>> s/of submodules/of parts of modules/ >> >>>>> yes. >> >>>> OK - so I will read submodules as 'parts of modules'. >> >>>> >> >>>>>> Reading the other text again, I am not sure what is meant by the >> >>>>>> phrase "incorporation of the data model defined by one top-level >> >>>>>> module". What exactly is a 'top-level module' (and does it matter, >> >>>>> interfaces. >> >>>> An example does not define the term. >> >>> 100% agree - at least in drafts. >> >>> >> >>>> Please define 'top-level module' >> >>> any module that defines a top-level node, or if you prefer a module that >> >>> defines nodes at the XPath root node. >> >>> >> >>>> so we can actually understand what we are talking about. >> >>> If you don't like either formation, I suspect at this point you know >> >>> what I mean, so please propose alternate language that works for you and >> >>> I'll confirm that/if it works for me. >> >> Cool. So if I mount ietf-interfaces (a top-level module) into some >> >> other place, what happens to all the data models that augment >> >> ietf-interfaces with interface specific objects, like the ietf-ip >> >> module (a non-top-level module)? >> > >> > they are allowed/supported in the same way that they would be today, >> > just with the modifications/rewrite of their base models. >> > >> >> >> >> I fail to see why this distinction between top-level modules and >> >> non-top-level modules is useful. >> > >> > I'm describing a single use case, which only requires top-level support, >> > not all desirable capabilities or a solution. >> >> Hi Juergen, >> >> The top-level modules would carry the mounts of the non-top-level >> modules that are attached within them. I don't see this making sense any >> other way. The idea here is to support a parent device being able to >> mount a contained child device's modules and modify them external to the >> child devices normal management mechanism (e.g., not having to log into >> the child's netconf server). >> >> Given that, what's the use of talking about mounting "inner" modules? >> You have to mount the "outer" (or containing) module to be able to >> access them, and by mounting the containing module you gain access to the >> contained modules. >> >> At least that's how I picture this working. >> > > But even then, why do we need new terms? If you mount a path, then you > mount a path in a datastore. Modules that do not define paths obviously > then can't be mounted. How about this: > > module top-level-module { > container top; > } > > module non-top-level-module { > import "top-level-module" { prefix top; } > > augment "/top:top/" { > container second; > } > } > > Can I mount /top/second? Why would a solution be simpler if I make > this impossible? So your saying the parent can the second without the first on the /top/second path? If so then it should be the same with the "child" (or mount point) as well. The intent is not to try and add restrictions here. I think maybe the whole top-level thing is unintentionally confusing. Thanks, Chris. > > /js
signature.asc
Description: PGP signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
