I don't see how draft Clemm addresses our draft's use case. That said, if
alex thinks it does - let's hear about it.
Alex,
Can you look at the mail I sent the other day about our planned usage and
see what you think - and let us know what you find?
Thanks,
Lou
On February 3, 2016 2:27:44 PM Kent Watsen <kwat...@juniper.net> wrote:
I was led to believe that the current set of drafts subsume
draft-clemm-netmod-mount. If that’s not true, then absolutely there should
be a slot for that draft to be discussed as well. Please advise.
Kent
On 2/3/16, 9:07 AM, "Robert Wilton" <rwil...@cisco.com> wrote:
Hi Kent,
There is also another Yang Mount related draft: draft-clemm-netmod-mount-03
Now, this draft doesn't directly address the RTG DT Arch team use-case,
and seems to cover two more complex problem scenarios (remote mount and
alias mount), but these do appear to be a valid mount use cases (e.g. I
think that it is used by OpenDaylight SDN controller), and I know that
there is at least one implementation of this draft.
So, I want to echo Eric Voit's comments that it would be good if
whatever basic YANG mount draft we converge on is able to be cleanly
extended to cover the more complex mount scenarios.
As such, if Alex Clemm or Eric Voit are willing, I think that it would
be useful if one of them could comment on how feasible it is to extend
either netmod-structual-mount or netmod-ysdl to cover the remote mount
and alias mount scenarios described in draft-clemm-netmod-mount-03.
Hence, if they agree, do you think that you would be able to add a 15
min slot to the agenda to cover this please?
Thanks,
Rob
On 03/02/2016 02:24, Kent Watsen 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 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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
