Lou Berger <[email protected]> writes: > 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...
This is correct, both structural-mount and YSDL just define a compound schema/data model. The term "mount" is IMO more connected to combining data trees (as in NFS mount). YSDL also requires that all YANG modules be known/advertised locally through the local server's yang-library, so there are no extra security implications compared to the current situation where all modules are combined side-by-side. Lada > > 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
