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

Reply via email to