Eric, I did the suggested OpenDaylight (ODL)search, and yes there is a lot of activity there. There are a lot of trees in that forest.
The best overview I found seems to be here. https://wiki.opendaylight.org/view/OpenDaylight_Controller:_SAL_Architecture_Overview#Nested_Subsystems Mapping my words to ODL, My Sibling is the ODL Nested system. My Parent might be ODL Top-level Subsystem? Having had lunch to think about it, I don't think I should have picked NetConf as a place to choose what data to mount. I suspect it should be somewhere in the application, separate for both Yang and Netconf. ODL appears to use the Northbound Restconf interface to do this function <module xmlns="urn:opendaylight:params:xml:ns:yang:controller:config"> Stepping back, for this mounting stuff, there are at least 3 issues: 1) Specifying a where in the Parent schema to put the sibling schema. 2) Specifying the type of the sibling. 3) Specifying what sibling data instance to put at a specific parent node data instance. I think Yang would be a great place to do 1 and 2, but I think the application should handle 3. ODL appears to put 1) in Yang, I'm not sure about 2), and 3) in the application. Your proposed definition's mention of data-tree appears to put 3 into Yang with appears to conflict with ODL. Since you clearly don't want however Yang turns out to collide with ODL, but appear to be proposing something that collides, I must not understand? Another use case: ODL Yang device mounting is about grafting and removing whole, existing devices as branches in a single tree on a running system. For this, there may be some benefit in treating the grafted branch as a special sort of node in the tree. Having a special keyword like 'mount' might help this, or the application function that does 3) above could handle it. Another use case is simply making a big device model by grafting together smaller, whole, existing models. In this case, the benefit may be to make the grafted branch look like a non-special vanilla node in the tree. In this case, I don't see the benefit over a special keyword like 'mount' over an existing one like 'uses'. Regards, Stuart -----Original Message----- From: Eric Voit (evoit) [mailto:[email protected]] Sent: Wednesday, March 16, 2016 12:20 PM To: STUART VENTERS Cc: [email protected]; Martin Bjorklund (mbjorklu); 'Juergen Schoenwaelder' Subject: RE: [netmod] Differentiating the types of Mount > From: STUART VENTERS, March 16, 2016 12:58 PM > > Defining a schema-tree seems Yang's strong suite. > I'm not sure if the suite extends to defining what goes into a > data-tree governed by the schema-tree. Hi Stuart, Open Daylight has found Mounting YANG data from one device to another has proven central to their effort. Doing a quick Google search for "mount site:opendaylight.org" gives 800+ results. Based on that, I was hoping that being defining the variants of Mount across different constituencies would help us not collide as the technologies evolve. This includes a shared definition of "YANG Mount" which shows what is common across all efforts. Thanks, Eric > Perhaps: > > YANG Mount > ---------------- > Definition: An abstracted term for a YANG mechanism that grafts a > sibling schema-tree as a subtree of a parent schema-tree. > Purpose: Provides flexibility by enabling the growth of YANG models > via an explicit reference to other YANG models defined elsewhere. > > Given the ability to specify a combined schema-tree, maybe something > at the protocol level could specify what data to use to populate the grafted > tree. > This could provide a place to specify details like who has ownership > of the data, if it is RW, etc. > > NETCONF Mount > ------------------ > Definition: An abstracted term for a NETCONF mechanism to construct a > combined data-tree according to a schema defined with YANG mount. > Purpose: ... > > > > -----Original Message----- > From: netmod [mailto:[email protected]] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, March 16, 2016 6:23 AM > To: Eric Voit (evoit) > Cc: [email protected]; Martin Bjorklund (mbjorklu) > Subject: Re: [netmod] Differentiating the types of Mount > > On Wed, Mar 16, 2016 at 03:59:50AM +0000, Eric Voit (evoit) wrote: > > To help differentiate between concepts and drafts, below are > > strawman > definitions for the various types of Mount which we have been discussing over > the last year in Netmod. Thoughts/suggestions? > > > > YANG Mount > > ---------------- > > Definition: An abstracted term for a mechanism that a parent YANG > > model can > use to link in YANG information defined or located elsewhere. > > Purpose: Provides model flexibility by enabling the growth of YANG > > trees via > an explicit reference to other YANG information and structures. > > Trying to rewrite the definition to be more consistent with existing > terminology: > > The abstract concept of incorporating a YANG-defined data tree (the > mounted data tree) into a existing YANG-defined data tree (the > parent data tree). > > Well, this is not really correct, perhaps we have to just say 'tree' > instead of 'data tree' since a schema mount (as I understand it) seems > to incorporate a schema tree into another schema tree while the other > two mounts incorporate a data tree into a data tree. So perhaps the > general definition is something like this: > > The abstract concept of incorporating a YANG-defined data tree or > schema tree (the mounted data or schema tree) into a existing > YANG-defined data tree or schema tree (the parent data tree). > > The schema mount then essentially removes data tree and the other two > mounts remove the schema tree from this definition. > > Is your alias mount simply a special case of a peer mount where the > peer is local? Or is there more to it? In other words, would it be > reasonable to think of the terms in this way: > > +-> schema (tree) mount > | > mount -> | +-> local data tree (alias) mount > +-> data (tree) mount -> | > +-> remote data tree (peer) mount > > /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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
