Okay, I set up a doodle poll to help us pick a time:
http://doodle.com/poll/dv68psxn33yt4ehf
Would the draft authors and other key participants please fill in their
availability?
Thanks,
Kent
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.
>
>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