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. Thanks, Chris. > > Lou > >> /js >>
signature.asc
Description: PGP signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
