> On 04 Feb 2016, at 13:07, Lou Berger <[email protected]> wrote: > > Rob, > > > On February 4, 2016 4:57:24 AM Robert Wilton <[email protected]> wrote: > >> Hi, >> >> I wasn't actually suggesting that Alex's YANG mount draft be considered >> as a solution here. I think that this draft is probably sufficiently >> complex that it would require a lot WG discussion and hence take too >> long to standardize to meet the RTG DT requirements. >> >> Hence, I envisage that we'll end up with two drafts: >> 1) A basic mount draft - based on either Martin's Structural Mount or >> Lada's Ysdl drafts. >> 2) A revision of Alex's YANG mount draft that extends from the base >> mount draft (1) above to cover alias and peer mount. >> >> The meeting should focus on (1). >> >> But what I am suggesting is for either Alex or Eric to evaluate both >> Martin's Structural Mount and Lada's Ysdl to determine whether either of >> the drafts are particularly better/easier/cleaner to extend to cover the >> Alias and Peer mount use cases covered in Alex's YANG mount draft, since >> that might be useful to help identify which of (Martin's Structural >> Mount of Lada's Ysdl) should be chosen as a starting point as a WG solution. >> >> I hope this clarifies my previous request. >> > > Yes. Although to me a merging may be more appropriate/likely then picking > one.
I agree. Lada > > Lou > >> Rob >> >> >> On 04/02/2016 04:26, Lou Berger wrote: >>> Alex, >>> >>> >>> On February 3, 2016 8:35:54 PM "Alexander Clemm (alex)" >>> <[email protected]> wrote: >>> >>>> Hi Kent, >>>> >>>> I do think that we should have a slot for that draft as well. The >>>> structural mount case is a variation of the alias mount case; >>> >>> Insofar as much that Structural mount and YSDL both have a model that >>> is used to control their mount functions there is similarity, but >>> there is a fundamental difference that the other documents cover a >>> schema being mounted not a datastore. Scheme mount is really a better >>> term than structural mount... >>> >>> Also for our use case we don't want to use a different/ additional model. >>> >>> That said covering alias and remote mount if there is time in the >>> interim would be fine with me, but not at the expense of identifying a >>> preferred approach of enabling the same amount that we are making use >>> of in our draft. >>> >>> Lou >>> >>>> it is certainly possible to have a continuum of solutions that allows >>>> to incorporate structural mount as well as alias mount and peer mount >>>> (the latter possibly at a later point). >>>> >>>> At the core in each case is the “mountpoint” construct / YANG >>>> extension, which was first introduced in the peer-mount draft and >>>> which also appears in the structured-mount draft. In peer-mount, we >>>> also introduced two additional arguments/ extension in addition: the >>>> subtree (used for alias mount), and the target (for peer mount – >>>> building on top, for when it is required). In the discussions since, >>>> it became clear that there is also a use case where you don’t need an >>>> alias, where it is sufficient to just mount a module and instantiate >>>> it right under the mount point. This is the case that Martin put in >>>> his draft. So, there is really a continuum: a case of a mountpoint >>>> with no argument (structural mount - the new draft), with one >>>> argument (alias), and with two (peer) (the earlier draft). >>>> >>>> --- Alex >>>> >>>> >>>> -----Original Message----- >>>> From: Kent Watsen [mailto:[email protected]] >>>> Sent: Wednesday, February 03, 2016 11:27 AM >>>> To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) >>>> <[email protected]> >>>> Cc: Lou Berger <[email protected]>; netmod WG <[email protected]>; >>>> Alexander Clemm (alex) <[email protected]>; Eric Voit (evoit) >>>> <[email protected]> >>>> Subject: Re: [netmod] Yang mount / ysdl example use case >>>> >>>> >>>> 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
