Yes, the meeting times are in timezone EST. Doodle should display the timezone and let you set your own.
Kent > On Feb 3, 2016, at 9:48 AM, Acee Lindem (acee) <a...@cisco.com> wrote: > > Kent - I’m assuming the poll is EST given that is where you are located. > Thanks, > Acee > >> On 2/3/16, 8:50 AM, "Kent Watsen" <kwat...@juniper.net> wrote: >> >> >> 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
