Hi Lou, the original draft specified mounting a model that was already instantiated on a server. Your requirement #1 is a little different in that you want to instantiate a specific data model underneath another node in another model (without the same model already be instantiated elsewhere), as opposed to mounting a model that is already instantiated. So, you're not inserting a reference and creating an alternative path to an instance, but inserting the model definition itself. This is not the same, and not addressed by the original draft. That said, it is evidently possible to build on the mount-model and extend or vary it in such a way that supports your case, and Martin's draft proposes how this can be done. At the same time, there are other use cases (of alias-mount and peer-mount) which could be addressed with variations of the solution that build on each other.
--- Alex -----Original Message----- From: Lou Berger [mailto:[email protected]] Sent: Wednesday, February 03, 2016 12:48 PM To: Kent Watsen <[email protected]>; Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) <[email protected]> Cc: netmod WG <[email protected]>; Alexander Clemm (alex) <[email protected]>; Eric Voit (evoit) <[email protected]> Subject: Re: [netmod] Yang mount / ysdl example use case I don't see how draft Clemm addresses our draft's use case. That said, if alex thinks it does - let's hear about it. Alex, Can you look at the mail I sent the other day about our planned usage and see what you think - and let us know what you find? Thanks, Lou On February 3, 2016 2:27:44 PM Kent Watsen <[email protected]> wrote: > > I was led to believe that the current set of drafts subsume > draft-clemm-netmod-mount. If that’s not true, then absolutely there > should be a slot for that draft to be discussed as well. Please advise. > > Kent > > > > > > > On 2/3/16, 9:07 AM, "Robert Wilton" <[email protected]> wrote: > >>Hi Kent, >> >>There is also another Yang Mount related draft: >>draft-clemm-netmod-mount-03 >> >>Now, this draft doesn't directly address the RTG DT Arch team >>use-case, and seems to cover two more complex problem scenarios >>(remote mount and alias mount), but these do appear to be a valid >>mount use cases (e.g. I think that it is used by OpenDaylight SDN >>controller), and I know that there is at least one implementation of this >>draft. >> >>So, I want to echo Eric Voit's comments that it would be good if >>whatever basic YANG mount draft we converge on is able to be cleanly >>extended to cover the more complex mount scenarios. >> >>As such, if Alex Clemm or Eric Voit are willing, I think that it would >>be useful if one of them could comment on how feasible it is to extend >>either netmod-structual-mount or netmod-ysdl to cover the remote mount >>and alias mount scenarios described in draft-clemm-netmod-mount-03. >>Hence, if they agree, do you think that you would be able to add a 15 >>min slot to the agenda to cover this please? >> >>Thanks, >>Rob >> >> >>On 03/02/2016 02:24, Kent Watsen wrote: >>> [Chair hat on] >>> >>> Given the number of competing/complementing drafts involved, and the >>> general lack of discussion on any of them, a virtual interim meeting >>> might be an expedient way to proceed. In fairness, we know that >>> there has been some discussion, but it hasn’t been picked up yet in >>> a big way, and now Lou has an updated draft. >>> >>> The chairs discussed maybe scheduling one for a couple weeks from now, >>> perhaps Thursday Feb 18 starting at 10am EST? I'm thinking about this >>> slot only since it worked for us for previously. Is this a good time slot? >>> I assume to schedule for 2 hours, with a plan to end early if needed - >>> makes sense? We also need to put together a proper agenda, perhaps the >>> following? >>> >>> 10 min: RTG DT YANG Arch team use-case summary >>> 20 min: draft-rtgyangdt-rtgwg-device-model >>> 20 min: draft-lhotka-netmod-ysdl >>> 20 min: draft-bjorklund-netmod-structural-mount >>> 50 min: general discussion or end early >>> >>> >>> We hope to schedule the meeting itself tomorrow or the next day, so >>> please respond quickly to this email if possible. >>> >>> Thanks, >>> Kent and Tom >>> >>> >>> >>> >>> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger" >>> <[email protected] on behalf of [email protected]> wrote: >>> >>>> I thought it would be worth summarizing what we're looking for in >>>> our draft, draft-rtgyangdt-rtgwg-device-model-02 (note new version >>>> in case you missed it) with respect to the draft-lhotka-netmod-ysdl >>>> and draft-bjorklund-netmod-structural-mount drafts. This is just my >>>> view, so my co-authors may wish to chime in and correct me. >>>> >>>> I'd be interested in hearing from the authors of YSDL and >>>> structural-mount, or anyone else for that matter, on how they see >>>> to best meet these needs. >>>> >>>> Here's what I think our draft needs: >>>> >>>> 1. that there be a mechanism that allows the incorporation (or >>>> 'mounting') of the data model defined by one top-level module >>>> within another module. >>>> >>>> The implication here is that when information is instantiated >>>> for the parent model it is also instantiated for the >>>> incorporated/mounted model. In our case we expect to do this on >>>> list element creation. Both solutions drafts cover the path >>>> implications, so these are not repeated here. >>>> >>>> 2. that this mechanism allow identification of specific modules to >>>> be incorporated/mounted at time of module definition, i.e. that >>>> no additional module is needed to support 1. This doesn't >>>> preclude definition of such a module. >>>> >>>> 3. that this mechanism allow for a server to control (and >>>> identify) which modules are incorporated/mounted. (see Section >>>> 3 LNE in our draft for an envisioned usage.) >>>> >>>> 4. that all capabilities that exist with the mounted module are >>>> available e.g. RPC operations and notifications. >>>> >>>> 5. while our primary requirement is for 'mounting' of top level >>>> modules, mounting of submodules may also be useful. (DT not draft >>>> driven.) >>>> >>>> We make use of the above in sections 3 and 4 of rtgwg-device-model. >>>> We see having a solution as critical for the >>>> simplifications/flexibility represented in the -02 version of our >>>> draft vs the -03 rev. We don't see wither solution draft as >>>> significantly different and just hope for a standard solution as >>>> soon as possible. (a draft-ietf-netmod solutions draft on the >>>> topic by BA would be fantastic given the impact on routing area -- >>>> even if it had to document two variations / alternative solutions.) >>>> >>>> Again, this is just my opinion and my coauthors or others on the >>>> rtg area yang DT may choose to chime in. >>>> >>>> Lou >>>> >>>> >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/netmod >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
