No problem, I just created another poll for the following week: http://doodle.com/poll/byugp4umy2m4fwdz
The first poll is now deleted. For the couple of folks that put values there, please fill in your values again on this new poll. Kent On 2/3/16, 6:59 AM, "Acee Lindem (acee)" <a...@cisco.com> wrote: > > >On 2/3/16, 1:18 AM, "Ladislav Lhotka" <lho...@nic.cz> wrote: > >> >>> 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. > >I’m out the entire week of Feb 14th. > >Thanks, >Acee > > >> >>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