[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" <netmod-boun...@ietf.org on behalf of lber...@labn.net> 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 >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
