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
