Hi, Kent Watsen <[email protected]> wrote: > > I was led to believe that the current set of drafts subsume > draft-clemm-netmod-mount.
The mechanism in draft-clemm-netmod-mount primarily mounts remote datastores into a datastore. Structural mount focuses on combining *schemas*. This approach can support different implementation strategies, where remote mounting could be one. However, the structural mount draft does not specify any such implementation strategies; the idea was that such strategies could be defined in separate documents (that would reference the structural mount doc). /martin > 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
