> On 03 Feb 2016, at 03:24, Kent Watsen <kwat...@juniper.net> 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
Thursday at this time doesn't suit me very well, Monday till Wednesday of that week are OK. Lada > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
