On Thu, Feb 04, 2016 at 11:46:47AM -0500, cho...@chopps.org wrote:
>
> Lou Berger <lber...@labn.net> 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?
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
