On Thu, Feb 04, 2016 at 11:33:12AM -0500, Lou Berger wrote: > 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 thought you answered to "can I not mount a non-top-level module?" with "a good capability, but not used by our draft". > > 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. So how does ietf-ip then work? I guess you assume that a mount of ietf-ip is implicit, that is by mounting ietf-interfaces you allow (or expect?) that some (or all?) augmentations of /if:interfaces etc. are mounted as well. Again, the I fail to see the value of classifying modules into top-level modules and non-top-level modules. I also think that thinking about mounts as all or nothing (you mount a complete module or nothing) is a questionable concept since we have modules with multiple "roots" and sometimes the bundling of "trees" into modules is subject to non-technical constraints (e.g., you will have modules that augment stuff but also create new roots and even more interesting is that we will see this to change over time, a module that was a non-top-level module may become a top-level module in a revision). I think we should try to avoid solutions that work only with certain classes of modules but not for others. /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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
