Re: [netmod] Yang mount / ysdl example use case

[Juergen Schoenwaelder]

On Tue, Feb 02, 2016 at 02:04:12PM -0500, Lou Berger wrote:
> 
> 5. while our primary requirement is for 'mounting' of top level
>modules, mounting of submodules may also be useful. (DT not draft
>driven.)
>

A YANG submodule is by definition incomplete. For example, a submodule
does not have a defined namespace. I think we should not waste effort
to expose submodules beyond what they were designed to be used for -
to break a really large module into pieces that can be edited more
easily independently.

If more granular mounts are needed, then we should IMHO _not_ bundle
this with the notion of YANG submodules. Perhaps you meant submodules
in a more generic way, but then perhaps:

s/of submodules/of parts of modules/

Reading the other text again, I am not sure what is meant by the
phrase "incorporation of the data model defined by one top-level
module". What exactly is a 'top-level module' (and does it matter, why
can I not mount a non-top-level module)? And does 'incorporation of
the data model' imply 'incorporation of the complete data model'?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Yang mount / ysdl example use case

[Ladislav Lhotka]

> On 04 Feb 2016, at 13:07, Lou Berger <lber...@labn.net> wrote:
> 
> Rob,
> 
> 
> On February 4, 2016 4:57:24 AM Robert Wilton <rwil...@cisco.com> wrote:
> 
>> Hi,
>> 
>> I wasn't actually suggesting that Alex's YANG mount draft be considered
>> as a solution here.  I think that this draft is probably sufficiently
>> complex that it would require a lot WG discussion and hence take too
>> long to standardize to meet the RTG DT requirements.
>> 
>> Hence, I envisage that we'll end up with two drafts:
>>  1) A basic mount draft - based on either Martin's Structural Mount or
>> Lada's Ysdl drafts.
>>  2) A revision of Alex's YANG mount draft that extends from the base
>> mount draft (1) above to cover alias and peer mount.
>> 
>> The meeting should focus on (1).
>> 
>> But what I am suggesting is for either Alex or Eric to evaluate both
>> Martin's Structural Mount and Lada's Ysdl to determine whether either of
>> the drafts are particularly better/easier/cleaner to extend to cover the
>> Alias and Peer mount use cases covered in Alex's YANG mount draft, since
>> that might be useful to help identify which of (Martin's Structural
>> Mount of Lada's Ysdl) should be chosen as a starting point as a WG solution.
>> 
>> I hope this clarifies my previous request.
>> 
> 
> Yes.  Although to me a merging may be more appropriate/likely then picking 
> one.

I agree.

Lada

> 
> Lou
> 
>> Rob
>> 
>> 
>> On 04/02/2016 04:26, Lou Berger wrote:
>>> Alex,
>>> 
>>> 
>>> On February 3, 2016 8:35:54 PM "Alexander Clemm (alex)"
>>> <a...@cisco.com> wrote:
>>> 
>>>> Hi Kent,
>>>> 
>>>> I do think that we should have a slot for that draft as well. The
>>>> structural mount case is a variation of the alias mount case;
>>> 
>>> Insofar as much that Structural mount and YSDL both have a model that
>>> is used to control their mount functions there is similarity, but
>>> there is a fundamental difference that the other documents cover a
>>> schema being mounted not a datastore. Scheme mount is really a better
>>> term than structural mount...
>>> 
>>> Also for our use case we don't want to use a different/ additional model.
>>> 
>>> That said covering alias and remote mount if there is time in the
>>> interim would be fine with me, but not at the expense of identifying a
>>> preferred approach of enabling the same amount that we are making use
>>> of in our draft.
>>> 
>>> Lou
>>> 
>>>> it is certainly possible to have a continuum of solutions that allows
>>>> to incorporate structural mount as well as alias mount and peer mount
>>>> (the latter possibly at a later point).
>>>> 
>>>> At the core in each case is the “mountpoint” construct / YANG
>>>> extension, which was first introduced in the peer-mount draft and
>>>> which also appears in the structured-mount draft.  In peer-mount, we
>>>> also introduced two additional arguments/ extension in addition:  the
>>>> subtree (used for alias mount), and the target (for peer mount –
>>>> building on top, for when it is required).  In the discussions since,
>>>> it became clear that there is also a use case where you don’t need an
>>>> alias, where it is sufficient to just mount a module and instantiate
>>>> it right under the mount point.  This is the case that Martin put in
>>>> his draft.  So, there is really a continuum: a case of a mountpoint
>>>> with no argument (structural mount - the new draft), with one
>>>> argument (alias),  and with two (peer) (the earlier draft).
>>>> 
>>>> --- Alex
>>>> 
>>>> 
>>>> -Original Message-
>>>> From: Kent Watsen [mailto:kwat...@juniper.net]
>>>> Sent: Wednesday, February 03, 2016 11:27 AM
>>>> To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)
>>>> <rwil...@cisco.com>
>>>> Cc: Lou Berger <lber...@labn.net>; netmod WG <netmod@ietf.org>;
>>>> Alexander Clemm (alex) <a...@cisco.com>; Eric Voit (evoit)
>>>> <ev...@cisco.com>
>>>> Subject: Re: [netmod] Yang mount / ysdl example use case
>>>> 
>>>> 
>>>> I was led to believe that the current set of drafts subsume
>>>> draft-clemm-netmod-mount.  If that’s not true, then absolute

Re: [netmod] Yang mount / ysdl example use case

[Lou Berger]

Lada,
Thank you for the response.  See below.


On February 4, 2016 6:39:11 AM Ladislav Lhotka  wrote:


Hi Lou,

Lou Berger  writes:


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.


Both structural-mount and YSDL satisfy this.



Agree on the 1st paragraph but not the second. I think that like 2, neither 
support the second paragraph.




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.


If I understand this correctly, then I believe that neither
structural-mount nor YSDL support it. This would require new built-in
statements in YANG, extensions aren't applicable here.



Agreed.



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.)


Both structural-mount and YSDL satisfy this.



Great.



4. that all capabilities that exist with the mounted module are
   available e.g. RPC operations and notifications.


Currently only structural-mount addresses this, YSDL can be extended
along the same lines.



Makes sense.



5. while our primary requirement is for 'mounting' of top level
   modules, mounting of submodules may also be useful. (DT not draft
   driven.)


I don't think this is possible as long as both structural-mount and YSDL
take the information about available modules from yang-library.

A solution to this could be to allow the "include" statement to appear
anywhere in the schema tree, but this is again YANG 2 stuff.


Fair enough. This a longer term item and not critical for our draft.

Thanks again,
Lou



Lada



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





--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Yang mount / ysdl example use case

[Robert Varga]

On 02/04/2016 12:51 PM, Ladislav Lhotka wrote:

This is correct, both structural-mount and YSDL just define a compound
schema/data model. The term "mount" is IMO more connected to combining data
trees (as in NFS mount).


There are actually two aspects to this, which are related. Sorry to dump 
a bunch of UNIX specifics on you, but that was the best analogy I could 
find and that's how the term 'mount' got used for this area.


The central idea is that a file system implementation living under a 
particular mount point not only abstracts where the data actually lives 
(as is the case for NFS mount and draft-clemm-netmod-mount), but it also 
allows for different types of objects and operations on them: VFAT does 
not support device special files and Ext4 supports a host of 
ext4-specific ioctl(2)s on its files. This difference in capabilities 
maps to the problem being solved by 
draft-bjorklund-netmod-structural-mount (and ysdl, but I have not read 
that yet).


Bye,
Robert

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Yang mount / ysdl example use case

[Lou Berger]

Robert,

Thanks for pointer, nested subsystems look really close to what we're 
looking for and we could make do with a standardized form of it. (We were 
thinking nested modules, but given the definition of the server chooses we 
could make due.) Now we just need someone to write it up and submit as an ID.)


Lou


On February 4, 2016 6:55:30 AM Robert Varga  wrote:


On 02/03/2016 03:07 PM, Robert Wilton 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.


I would like to clarify here. OpenDaylight has the equivalent of
draft-bjorklund-netmod-structural-mount as its core concept, somewhat
described in
https://wiki.opendaylight.org/view/OpenDaylight_Controller:_SAL_Architecture_Overview#Nested_Subsystems.
The term 'mount' originates from there and deals exclusively with the
problem of nesting/rehoming YANG models.

draft-clemm-netmod-mount describes particular use cases of how such a
nested subsystem may be realized and deals with actual data movement. As
such, these are considered non-core plugins in OpenDaylight.

Bye,
Robert

___
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

Re: [netmod] Yang mount / ysdl example use case

[Ladislav Lhotka]

Hi Lou,

Lou Berger  writes:

> 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.

Both structural-mount and YSDL satisfy this.

>
> 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.

If I understand this correctly, then I believe that neither
structural-mount nor YSDL support it. This would require new built-in
statements in YANG, extensions aren't applicable here. 

>
> 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.)

Both structural-mount and YSDL satisfy this.

>
> 4. that all capabilities that exist with the mounted module are
>available e.g. RPC operations and notifications.

Currently only structural-mount addresses this, YSDL can be extended
along the same lines.

>
> 5. while our primary requirement is for 'mounting' of top level
>modules, mounting of submodules may also be useful. (DT not draft
>driven.)

I don't think this is possible as long as both structural-mount and YSDL
take the information about available modules from yang-library.

A solution to this could be to allow the "include" statement to appear
anywhere in the schema tree, but this is again YANG 2 stuff.

Lada

>
> 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
>
>
>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Yang mount / ysdl example use case

[Robert Wilton]

Hi,

I wasn't actually suggesting that Alex's YANG mount draft be considered 
as a solution here.  I think that this draft is probably sufficiently 
complex that it would require a lot WG discussion and hence take too 
long to standardize to meet the RTG DT requirements.


Hence, I envisage that we'll end up with two drafts:
 1) A basic mount draft - based on either Martin's Structural Mount or 
Lada's Ysdl drafts.
 2) A revision of Alex's YANG mount draft that extends from the base 
mount draft (1) above to cover alias and peer mount.


The meeting should focus on (1).

But what I am suggesting is for either Alex or Eric to evaluate both 
Martin's Structural Mount and Lada's Ysdl to determine whether either of 
the drafts are particularly better/easier/cleaner to extend to cover the 
Alias and Peer mount use cases covered in Alex's YANG mount draft, since 
that might be useful to help identify which of (Martin's Structural 
Mount of Lada's Ysdl) should be chosen as a starting point as a WG solution.


I hope this clarifies my previous request.

Rob


On 04/02/2016 04:26, Lou Berger wrote:

Alex,


On February 3, 2016 8:35:54 PM "Alexander Clemm (alex)" 
<a...@cisco.com> wrote:



Hi Kent,

I do think that we should have a slot for that draft as well. The 
structural mount case is a variation of the alias mount case;


Insofar as much that Structural mount and YSDL both have a model that 
is used to control their mount functions there is similarity, but 
there is a fundamental difference that the other documents cover a 
schema being mounted not a datastore. Scheme mount is really a better 
term than structural mount...


Also for our use case we don't want to use a different/ additional model.

That said covering alias and remote mount if there is time in the 
interim would be fine with me, but not at the expense of identifying a 
preferred approach of enabling the same amount that we are making use 
of in our draft.


Lou

it is certainly possible to have a continuum of solutions that allows 
to incorporate structural mount as well as alias mount and peer mount 
(the latter possibly at a later point).


At the core in each case is the “mountpoint” construct / YANG 
extension, which was first introduced in the peer-mount draft and 
which also appears in the structured-mount draft.  In peer-mount, we 
also introduced two additional arguments/ extension in addition:  the 
subtree (used for alias mount), and the target (for peer mount – 
building on top, for when it is required).  In the discussions since, 
it became clear that there is also a use case where you don’t need an 
alias, where it is sufficient to just mount a module and instantiate 
it right under the mount point.  This is the case that Martin put in 
his draft.  So, there is really a continuum: a case of a mountpoint 
with no argument (structural mount - the new draft), with one 
argument (alias),  and with two (peer) (the earlier draft).


--- Alex


-Original Message-
From: Kent Watsen [mailto:kwat...@juniper.net]
Sent: Wednesday, February 03, 2016 11:27 AM
To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) 
<rwil...@cisco.com>
Cc: Lou Berger <lber...@labn.net>; netmod WG <netmod@ietf.org>; 
Alexander Clemm (alex) <a...@cisco.com>; Eric Voit (evoit) 
<ev...@cisco.com>

Subject: Re: [netmod] Yang mount / ysdl example use case


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 
tha

Re: [netmod] Yang mount / ysdl example use case

[chopps]

Juergen Schoenwaelder  writes:

> On Thu, Feb 04, 2016 at 11:46:47AM -0500, cho...@chopps.org wrote:
>>
>> Lou Berger  writes:
>>
>> > Juergen,
>> >
>> > see below
>> >
>> > On 2/4/2016 11:12 AM, Juergen Schoenwaelder wrote:
>> >> On Thu, Feb 04, 2016 at 09:53:11AM -0500, Lou Berger wrote:
>> >>> Juergen,
>> >>>
>> >>> see below.
>> >>>
>> >>> On 2/4/2016 9:12 AM, Juergen Schoenwaelder wrote:
>>  On Thu, Feb 04, 2016 at 08:02:26AM -0500, Lou Berger wrote:
>> >> If more granular mounts are needed, then we should IMHO _not_ bundle
>> >> this with the notion of YANG submodules. Perhaps you meant submodules
>> >> in a more generic way, but then perhaps:
>> >>
>> >> s/of submodules/of parts of modules/
>> > yes.
>>  OK - so I will read submodules as 'parts of modules'.
>> 
>> >> Reading the other text again, I am not sure what is meant by the
>> >> phrase "incorporation of the data model defined by one top-level
>> >> module". What exactly is a 'top-level module' (and does it matter,
>> > interfaces.
>>  An example does not define the term.
>> >>> 100% agree - at least in drafts.
>> >>>
>>  Please define 'top-level module'
>> >>> any module that defines a top-level node, or if you prefer a module that
>> >>> defines nodes at the XPath root node.
>> >>>
>>  so we can actually understand what we are talking about.
>> >>> If you don't like either formation, I suspect at this point you know
>> >>> what I mean, so please propose alternate language that works for you and
>> >>> I'll confirm that/if it works for me.
>> >> Cool. So if I mount ietf-interfaces (a top-level module) into some
>> >> other place, what happens to all the data models that augment
>> >> ietf-interfaces with interface specific objects, like the ietf-ip
>> >> module (a non-top-level module)?
>> >
>> > they are allowed/supported in the same way that they would be today,
>> > just with the modifications/rewrite of their base models.
>> >
>> >>
>> >> I fail to see why this distinction between top-level modules and
>> >> non-top-level modules is useful.
>> >
>> > I'm describing a single use case, which only requires top-level support,
>> > not all desirable capabilities or a solution.
>>
>> Hi Juergen,
>>
>> The top-level modules would carry the mounts of the non-top-level
>> modules that are attached within them. I don't see this making sense any
>> other way. The idea here is to support a parent device being able to
>> mount a contained child device's modules and modify them external to the
>> child devices normal management mechanism (e.g., not having to log into
>> the child's netconf server).
>>
>> Given that, what's the use of talking about mounting "inner" modules?
>> You have to mount the "outer" (or containing) module to be able to
>> access them, and by mounting the containing module you gain access to the
>> contained modules.
>>
>> At least that's how I picture this working.
>>
>
> But even then, why do we need new terms? If you mount a path, then you
> mount a path in a datastore. Modules that do not define paths obviously
> then can't be mounted. How about this:
>
> module top-level-module {
>   container top;
> }
>
> module non-top-level-module {
>   import "top-level-module" { prefix top; }
>
>   augment "/top:top/" {
> container second;
>   }
> }
>
> Can I mount /top/second? Why would a solution be simpler if I make
> this impossible?


So your saying the parent can the second without the first on the
/top/second path? If so then it should be the same with the "child" (or mount
point) as well. The intent is not to try and add restrictions here.

I think maybe the whole top-level thing is unintentionally confusing.

Thanks,
Chris.

>
> /js



signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Yang mount / ysdl example use case

[Lou Berger]

Juergen,

see below.

On 2/4/2016 9:12 AM, Juergen Schoenwaelder wrote:
> On Thu, Feb 04, 2016 at 08:02:26AM -0500, Lou Berger wrote:
>>> If more granular mounts are needed, then we should IMHO _not_ bundle
>>> this with the notion of YANG submodules. Perhaps you meant submodules
>>> in a more generic way, but then perhaps:
>>>
>>> s/of submodules/of parts of modules/
>> yes.
> OK - so I will read submodules as 'parts of modules'.
>
>>> Reading the other text again, I am not sure what is meant by the
>>> phrase "incorporation of the data model defined by one top-level
>>> module". What exactly is a 'top-level module' (and does it matter, 
>> interfaces.
> An example does not define the term. 
100% agree - at least in drafts.

> Please define 'top-level module'
any module that defines a top-level node, or if you prefer a module that
defines nodes at the XPath root node.

> so we can actually understand what we are talking about.

If you don't like either formation, I suspect at this point you know
what I mean, so please propose alternate language that works for you and
I'll confirm that/if it works for me.

Thanks,

Lou

>
>>> why
>>> can I not mount a non-top-level module)? 
>> Good question.  This should be added to 5, i.e., a good capability, but
>> not used by our draft.
> I can't tell until I am told what a 'top-level module' is and what a
> 'non-top-level module' is.
>
>>> And does 'incorporation of
>>> the data model' imply 'incorporation of the complete data model'?
>> to me these two are the same, so yes -- unless you are implying
>> something I'm missing ;-)
> I am trying to understand and I am trying to avoid discussions where
> people talk past each other because of different interpretations of
> the words they use.
>
> /js
>


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Yang mount / ysdl example use case

[Ladislav Lhotka]

> On 04 Feb 2016, at 13:46, Lou Berger  wrote:
> 
> Lada,
> Thank you for the response.  See below.
> 
> 
> On February 4, 2016 6:39:11 AM Ladislav Lhotka  wrote:
> 
>> Hi Lou,
>> 
>> Lou Berger  writes:
>> 
>>> 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.
>> 
>> Both structural-mount and YSDL satisfy this.
>> 
> 
> Agree on the 1st paragraph but not the second. I think that like 2, neither 
> support the second paragraph.

It depends on what you mean by instantiating. In YSDL, the schema is known in 
advance and doesn't depend on any instances (except for "when" statements, but 
this is no different from the current situation).

Lada

> 
>>> 
>>> 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.
>> 
>> If I understand this correctly, then I believe that neither
>> structural-mount nor YSDL support it. This would require new built-in
>> statements in YANG, extensions aren't applicable here.
>> 
> 
> Agreed.
> 
>>> 
>>> 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.)
>> 
>> Both structural-mount and YSDL satisfy this.
>> 
> 
> Great.
> 
>>> 
>>> 4. that all capabilities that exist with the mounted module are
>>>   available e.g. RPC operations and notifications.
>> 
>> Currently only structural-mount addresses this, YSDL can be extended
>> along the same lines.
>> 
> 
> Makes sense.
> 
>>> 
>>> 5. while our primary requirement is for 'mounting' of top level
>>>   modules, mounting of submodules may also be useful. (DT not draft
>>>   driven.)
>> 
>> I don't think this is possible as long as both structural-mount and YSDL
>> take the information about available modules from yang-library.
>> 
>> A solution to this could be to allow the "include" statement to appear
>> anywhere in the schema tree, but this is again YANG 2 stuff.
> 
> Fair enough. This a longer term item and not critical for our draft.
> 
> Thanks again,
> Lou
> 
>> 
>> Lada
>> 
>>> 
>>> 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
>>> 
>>> 
>>> 
>> 
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>> 
> 
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Yang mount / ysdl example use case

[Juergen Schoenwaelder]

On Thu, Feb 04, 2016 at 08:02:26AM -0500, Lou Berger wrote:
> >
> > If more granular mounts are needed, then we should IMHO _not_ bundle
> > this with the notion of YANG submodules. Perhaps you meant submodules
> > in a more generic way, but then perhaps:
> >
> > s/of submodules/of parts of modules/
> yes.

OK - so I will read submodules as 'parts of modules'.

> > Reading the other text again, I am not sure what is meant by the
> > phrase "incorporation of the data model defined by one top-level
> > module". What exactly is a 'top-level module' (and does it matter, 
> interfaces.

An example does not define the term. Please define 'top-level module'
so we can actually understand what we are talking about.

> > why
> > can I not mount a non-top-level module)? 
> Good question.  This should be added to 5, i.e., a good capability, but
> not used by our draft.

I can't tell until I am told what a 'top-level module' is and what a
'non-top-level module' is.

> > And does 'incorporation of
> > the data model' imply 'incorporation of the complete data model'?
> to me these two are the same, so yes -- unless you are implying
> something I'm missing ;-)

I am trying to understand and I am trying to avoid discussions where
people talk past each other because of different interpretations of
the words they use.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Yang mount / ysdl example use case

[Juergen Schoenwaelder]

On Thu, Feb 04, 2016 at 12:07:32PM -0500, Lou Berger wrote:
> 
> 
> On 2/4/2016 12:02 PM, Juergen Schoenwaelder wrote:
> > Can I mount /top/second? 
> yes. But in our use case, we wouldn't explicitly do a mount here. but we
> would allow a server may choose to support it.
> 
> > Why would a solution be simpler if I make
> > this impossible?
> 
> We're not suggest this.  We're stating what we require, not what we
> preclude.  So a solution that supports non-top-level is just fine too.
>

So is the outcome of this discussion that you wanted to express that
it is sufficient for your use case to be able to mount nodes located
directly below the root? In other words, you would mount /system out
of ietf-system but you would never consider to mount, say, /system/ntp
or /system/radius.

If this is the outcome, then the text describing your use case
requirement probably can be improved (the distinction between
top-level module and non-top-level module is misleading since all you
require is mount of top-level nodes).

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Yang mount / ysdl example use case

[Lou Berger]

Juergen,

On 2/4/2016 2:13 PM, Juergen Schoenwaelder wrote:
> On Thu, Feb 04, 2016 at 12:07:32PM -0500, Lou Berger wrote:
>>
>> On 2/4/2016 12:02 PM, Juergen Schoenwaelder wrote:
>>> Can I mount /top/second? 
>> yes. But in our use case, we wouldn't explicitly do a mount here. but we
>> would allow a server may choose to support it.
>>
>>> Why would a solution be simpler if I make
>>> this impossible?
>> We're not suggest this.  We're stating what we require, not what we
>> preclude.  So a solution that supports non-top-level is just fine too.
>>
> So is the outcome of this discussion that you wanted to express that
> it is sufficient for your use case to be able to mount nodes located
> directly below the root? In other words, you would mount /system out
> of ietf-system but you would never consider to mount, say, /system/ntp
> or /system/radius.
never is a strong word.  it's more accurate to say we don't currently
need in draft-...


> If this is the outcome, then the text describing your use case
> requirement probably can be improved (the distinction between
> top-level module and non-top-level module is misleading since all you
> require is mount of top-level nodes).

The mail said it wasn't need by the document.

Lou

> /js
>


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Yang mount / ysdl example use case

[Lou Berger]

Juergen,

see below

On 2/4/2016 11:12 AM, Juergen Schoenwaelder wrote:
> On Thu, Feb 04, 2016 at 09:53:11AM -0500, Lou Berger wrote:
>> Juergen,
>>
>> see below.
>>
>> On 2/4/2016 9:12 AM, Juergen Schoenwaelder wrote:
>>> On Thu, Feb 04, 2016 at 08:02:26AM -0500, Lou Berger wrote:
> If more granular mounts are needed, then we should IMHO _not_ bundle
> this with the notion of YANG submodules. Perhaps you meant submodules
> in a more generic way, but then perhaps:
>
> s/of submodules/of parts of modules/
 yes.
>>> OK - so I will read submodules as 'parts of modules'.
>>>
> Reading the other text again, I am not sure what is meant by the
> phrase "incorporation of the data model defined by one top-level
> module". What exactly is a 'top-level module' (and does it matter, 
 interfaces.
>>> An example does not define the term. 
>> 100% agree - at least in drafts.
>>
>>> Please define 'top-level module'
>> any module that defines a top-level node, or if you prefer a module that
>> defines nodes at the XPath root node.
>>
>>> so we can actually understand what we are talking about.
>> If you don't like either formation, I suspect at this point you know
>> what I mean, so please propose alternate language that works for you and
>> I'll confirm that/if it works for me.
> Cool. So if I mount ietf-interfaces (a top-level module) into some
> other place, what happens to all the data models that augment
> ietf-interfaces with interface specific objects, like the ietf-ip
> module (a non-top-level module)?

they are allowed/supported in the same way that they would be today,
just with the modifications/rewrite of their base models.

>
> I fail to see why this distinction between top-level modules and
> non-top-level modules is useful.

I'm describing a single use case, which only requires top-level support,
not all desirable capabilities or a solution. 

Lou

> /js
>


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Yang mount / ysdl example use case

[chopps]

Lou Berger  writes:

> Juergen,
>
> see below
>
> On 2/4/2016 11:12 AM, Juergen Schoenwaelder wrote:
>> On Thu, Feb 04, 2016 at 09:53:11AM -0500, Lou Berger wrote:
>>> Juergen,
>>>
>>> see below.
>>>
>>> On 2/4/2016 9:12 AM, Juergen Schoenwaelder wrote:
 On Thu, Feb 04, 2016 at 08:02:26AM -0500, Lou Berger wrote:
>> If more granular mounts are needed, then we should IMHO _not_ bundle
>> this with the notion of YANG submodules. Perhaps you meant submodules
>> in a more generic way, but then perhaps:
>>
>> s/of submodules/of parts of modules/
> yes.
 OK - so I will read submodules as 'parts of modules'.

>> Reading the other text again, I am not sure what is meant by the
>> phrase "incorporation of the data model defined by one top-level
>> module". What exactly is a 'top-level module' (and does it matter,
> interfaces.
 An example does not define the term.
>>> 100% agree - at least in drafts.
>>>
 Please define 'top-level module'
>>> any module that defines a top-level node, or if you prefer a module that
>>> defines nodes at the XPath root node.
>>>
 so we can actually understand what we are talking about.
>>> If you don't like either formation, I suspect at this point you know
>>> what I mean, so please propose alternate language that works for you and
>>> I'll confirm that/if it works for me.
>> Cool. So if I mount ietf-interfaces (a top-level module) into some
>> other place, what happens to all the data models that augment
>> ietf-interfaces with interface specific objects, like the ietf-ip
>> module (a non-top-level module)?
>
> they are allowed/supported in the same way that they would be today,
> just with the modifications/rewrite of their base models.
>
>>
>> I fail to see why this distinction between top-level modules and
>> non-top-level modules is useful.
>
> I'm describing a single use case, which only requires top-level support,
> not all desirable capabilities or a solution.

Hi Juergen,

The top-level modules would carry the mounts of the non-top-level
modules that are attached within them. I don't see this making sense any
other way. The idea here is to support a parent device being able to
mount a contained child device's modules and modify them external to the
child devices normal management mechanism (e.g., not having to log into
the child's netconf server).

Given that, what's the use of talking about mounting "inner" modules?
You have to mount the "outer" (or containing) module to be able to
access them, and by mounting the containing module you gain access to the
contained modules.

At least that's how I picture this working.

Thanks,
Chris.


>
> Lou
>
>> /js
>>



signature.asc
Description: PGP signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Yang mount / ysdl example use case

[Juergen Schoenwaelder]

On Thu, Feb 04, 2016 at 11:33:12AM -0500, Lou Berger wrote:
> Juergen,
> 
> see below
> 
> On 2/4/2016 11:12 AM, Juergen Schoenwaelder wrote:
> > On Thu, Feb 04, 2016 at 09:53:11AM -0500, Lou Berger wrote:
> >> Juergen,
> >>
> >> see below.
> >>
> >> On 2/4/2016 9:12 AM, Juergen Schoenwaelder wrote:
> >>> On Thu, Feb 04, 2016 at 08:02:26AM -0500, Lou Berger wrote:
> > If more granular mounts are needed, then we should IMHO _not_ bundle
> > this with the notion of YANG submodules. Perhaps you meant submodules
> > in a more generic way, but then perhaps:
> >
> > s/of submodules/of parts of modules/
>  yes.
> >>> OK - so I will read submodules as 'parts of modules'.
> >>>
> > Reading the other text again, I am not sure what is meant by the
> > phrase "incorporation of the data model defined by one top-level
> > module". What exactly is a 'top-level module' (and does it matter, 
>  interfaces.
> >>> An example does not define the term. 
> >> 100% agree - at least in drafts.
> >>
> >>> Please define 'top-level module'
> >> any module that defines a top-level node, or if you prefer a module that
> >> defines nodes at the XPath root node.
> >>
> >>> so we can actually understand what we are talking about.
> >> If you don't like either formation, I suspect at this point you know
> >> what I mean, so please propose alternate language that works for you and
> >> I'll confirm that/if it works for me.
> > Cool. So if I mount ietf-interfaces (a top-level module) into some
> > other place, what happens to all the data models that augment
> > ietf-interfaces with interface specific objects, like the ietf-ip
> > module (a non-top-level module)?
> 
> they are allowed/supported in the same way that they would be today,
> just with the modifications/rewrite of their base models.

I thought you answered to "can I not mount a non-top-level module?"
with "a good capability, but not used by our draft".

> > I fail to see why this distinction between top-level modules and
> > non-top-level modules is useful.
> 
> I'm describing a single use case, which only requires top-level support,
> not all desirable capabilities or a solution.

So how does ietf-ip then work? I guess you assume that a mount of
ietf-ip is implicit, that is by mounting ietf-interfaces you allow (or
expect?) that some (or all?) augmentations of /if:interfaces etc. are
mounted as well.

Again, the I fail to see the value of classifying modules into
top-level modules and non-top-level modules. I also think that
thinking about mounts as all or nothing (you mount a complete module
or nothing) is a questionable concept since we have modules with
multiple "roots" and sometimes the bundling of "trees" into modules is
subject to non-technical constraints (e.g., you will have modules that
augment stuff but also create new roots and even more interesting is
that we will see this to change over time, a module that was a
non-top-level module may become a top-level module in a revision).

I think we should try to avoid solutions that work only with certain
classes of modules but not for others.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Yang mount / ysdl example use case

[Lou Berger]

Martin,

On 2/4/2016 3:22 PM, Martin Bjorklund wrote:
> The way I understand the requirement from Lou et. al, which is also
> what structural mount supports, is a way to mount (or "relocate") a
> set of modules under a certain path.  Currently the complete subtrees
> defined by this module set is mounted.  This includes any augments.
> So for example, if you mount ietf-interfaces and ietf-ip under /x:foo,
> the result would be:
>
>/x:foo/if:interfaces/if:interface/ip:ipv4/... 
>/x:foo/if:interfaces/if:interface/ip:ipv6/...
>
> etc.
>
> Structural mount does not currently support mounting of specific
> subtrees.
>
> I agree with Juergen that the term "top-level module" maybe is
> misleading.  (In fact, I thought that this term refered to something
> else - once you have mounted ietf-interfaces in the module "x" as
> above, I thought that "x" was the top-level module, and ietf-interface
> was the non-top-level module).

So what's a better way of referring to the type of mounted module?

Lou


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Yang mount / ysdl example use case

[Kent Watsen]

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"  wrote:

>
>> On 03 Feb 2016, at 03: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
>
>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" 
>>  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

Re: [netmod] Yang mount / ysdl example use case

[Acee Lindem (acee)]

On 2/3/16, 1:18 AM, "Ladislav Lhotka"  wrote:

>
>> On 03 Feb 2016, at 03: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
>
>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"
>> 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

Re: [netmod] Yang mount / ysdl example use case

[Acee Lindem (acee)]

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"  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)"  wrote:
>
>>
>>
>>On 2/3/16, 1:18 AM, "Ladislav Lhotka"  wrote:
>>
>>>
 On 03 Feb 2016, at 03: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
>>>
>>>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"
 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

Re: [netmod] Yang mount / ysdl example use case

[Robert Wilton]

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"  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

Re: [netmod] Yang mount / ysdl example use case

[Alexander Clemm (alex)]

Hi Kent,

I do think that we should have a slot for that draft as well.  The structural 
mount case is a variation of the alias mount case; it is certainly possible to 
have a continuum of solutions that allows to incorporate structural mount as 
well as alias mount and peer mount (the latter possibly at a later point).  

At the core in each case is the “mountpoint” construct / YANG extension, which 
was first introduced in the peer-mount draft and which also appears in the 
structured-mount draft.  In peer-mount, we also introduced two additional 
arguments/ extension in addition:  the subtree (used for alias mount), and the 
target (for peer mount – building on top, for when it is required).  In the 
discussions since, it became clear that there is also a use case where you 
don’t need an alias, where it is sufficient to just mount a module and 
instantiate it right under the mount point.  This is the case that Martin put 
in his draft.  So, there is really a continuum: a case of a mountpoint with no 
argument (structural mount - the new draft), with one argument (alias),  and 
with two (peer) (the earlier draft).  

--- Alex


-Original Message-
From: Kent Watsen [mailto:kwat...@juniper.net] 
Sent: Wednesday, February 03, 2016 11:27 AM
To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) <rwil...@cisco.com>
Cc: Lou Berger <lber...@labn.net>; netmod WG <netmod@ietf.org>; Alexander Clemm 
(alex) <a...@cisco.com>; Eric Voit (evoit) <ev...@cisco.com>
Subject: Re: [netmod] Yang mount / ysdl example use case


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.
>>>
>>&

Re: [netmod] Yang mount / ysdl example use case

[Lou Berger]

Alex,


On February 3, 2016 8:35:54 PM "Alexander Clemm (alex)" <a...@cisco.com> wrote:


Hi Kent,

I do think that we should have a slot for that draft as well.  The 
structural mount case is a variation of the alias mount case;


Insofar as much that Structural mount and YSDL both have a model that is 
used to control their mount functions there is similarity, but there is a 
fundamental difference that the other documents  cover a schema being 
mounted not a datastore. Scheme mount is really a better term than 
structural mount...


Also for our use case we don't want to use a different/ additional model.

That said covering alias and remote mount if there is time in the interim 
would be fine with me, but not at the expense of identifying a preferred 
approach of enabling the same amount that we are making use of in our draft.


Lou

it is certainly possible to have a continuum of solutions that allows to 
incorporate structural mount as well as alias mount and peer mount (the 
latter possibly at a later point).


At the core in each case is the “mountpoint” construct / YANG extension, 
which was first introduced in the peer-mount draft and which also appears 
in the structured-mount draft.  In peer-mount, we also introduced two 
additional arguments/ extension in addition:  the subtree (used for alias 
mount), and the target (for peer mount – building on top, for when it is 
required).  In the discussions since, it became clear that there is also a 
use case where you don’t need an alias, where it is sufficient to just 
mount a module and instantiate it right under the mount point.  This is the 
case that Martin put in his draft.  So, there is really a continuum: a case 
of a mountpoint with no argument (structural mount - the new draft), with 
one argument (alias),  and with two (peer) (the earlier draft).


--- Alex


-Original Message-
From: Kent Watsen [mailto:kwat...@juniper.net]
Sent: Wednesday, February 03, 2016 11:27 AM
To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) <rwil...@cisco.com>
Cc: Lou Berger <lber...@labn.net>; netmod WG <netmod@ietf.org>; Alexander 
Clemm (alex) <a...@cisco.com>; Eric Voit (evoit) <ev...@cisco.com>

Subject: Re: [netmod] Yang mount / ysdl example use case


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-rtgyang

Re: [netmod] Yang mount / ysdl example use case

[Kent Watsen]

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)"  wrote:

>
>
>On 2/3/16, 1:18 AM, "Ladislav Lhotka"  wrote:
>
>>
>>> On 03 Feb 2016, at 03: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
>>
>>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"
>>> 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

[netmod] Yang mount / ysdl example use case

[Lou Berger]

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

Re: [netmod] Yang mount / ysdl example use case

[Ladislav Lhotka]

> On 03 Feb 2016, at 03: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

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"  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

Re: [netmod] Yang mount / ysdl example use case

[Kent Watsen]

[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"  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