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)" <[email protected]> wrote:
>
>
>On 2/3/16, 1:18 AM, "Ladislav Lhotka" <[email protected]> wrote:
>
>>
>>> On 03 Feb 2016, at 03:24, Kent Watsen <[email protected]> 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"
>>><[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
>>
>>--
>>Ladislav Lhotka, CZ.NIC Labs
>>PGP Key ID: E74E8C0C
>>
>>
>>
>>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
