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

From: Lou Berger <[email-masked]>
Date: Tue, 2 Feb 2016 14:04:12 -0500

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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 3 Feb 2016 02:24:54 +0000

[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" <[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 3 Feb 2016 07:18:10 +0100

> On 03 Feb 2016, at 03:24, Kent Watsen <[email-masked]> wrote:
> 
> 
> [Chair hat on]
> 
> 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?
> 

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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 3 Feb 2016 10:42:24 +0000

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 3 Feb 2016 11:59:06 +0000

On 2/3/16, 1:18 AM, "Ladislav Lhotka" <[email-masked]> wrote:

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

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?
>> 
>> We hope to schedule the meeting itself tomorrow or the next day, so
>>please respond quickly to this email if possible.
>> 
>> Thanks,
>> Kent and Tom
>> 
>> 
>> 
>> 
>> On 2/2/16, 2:04 PM, "netmod on behalf of Lou Berger"
>><[email-masked] on behalf of [email-masked]> wrote:
>> 
>>>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 3 Feb 2016 13:50:55 +0000

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

---

From: Robert Wilton <[email-masked]>
Date: Wed, 3 Feb 2016 14:07:53 +0000

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 3 Feb 2016 14:48:04 +0000

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" <[email-masked]> wrote:

>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
>
>
>
>
>
>>>Thursday at this time doesn't suit me very well, Monday till Wednesday
>>>of
>>>that week are OK.
>>
>>>>> see wither solution draft as significantly different and just hope
>>>>>for
>>>>>a

---

From: Kent Watsen <[email-masked]>
Date: Wed, 3 Feb 2016 14:57:06 +0000

Yes, the meeting times are in timezone EST.   Doodle should display the timezone and let you set your own.  

Kent

> On Feb 3, 2016, at 9:48 AM, Acee Lindem (acee) <[email-masked]> wrote:
>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 3 Feb 2016 19:27:20 +0000

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

---

From: Lou Berger <[email-masked]>
Date: Wed, 03 Feb 2016 15:48:08 -0500

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 <[email-masked]> 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
>
>
>
>
>
>
>>> 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.
>>>
>>> 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?
>>>
>>> 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
>>>
>>>
>>>
>>>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 03 Feb 2016 21:58:32 +0100 (CET)

Hi,

Kent Watsen <[email-masked]> wrote:
> draft-clemm-netmod-mount.

The mechanism in draft-clemm-netmod-mount primarily mounts remote
datastores into a datastore.

Structural mount focuses on combining *schemas*.  This approach can
support different implementation strategies, where remote mounting
could be one.  However, the structural mount draft does not specify
any such implementation strategies; the idea was that such strategies
could be defined in separate documents (that would reference the
structural mount doc).

/martin
 
> If that’s not true, then absolutely there
> should be a slot for that draft to be discussed as well.  Please
> advise.
> 
> Kent
> 
> 
> 
> 
> 
> 
> >> has been some discussion, but it hasn’t been picked up yet in a big
> >> way, and now Lou has an updated draft.
> >>
> >> 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?
> >>

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Thu, 4 Feb 2016 01:35:26 +0000

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:[email-masked]] 
Sent: Wednesday, February 03, 2016 11:27 AM
To: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) <[email-masked]>
Cc: Lou Berger <[email-masked]>; netmod WG <[email-masked]>; Alexander Clemm (alex) <[email-masked]>; Eric Voit (evoit) <[email-masked]>
Subject: Re: [netmod] Yang mount / ysdl example use case

Kent

On 2/3/16, 9:07 AM, "Robert Wilton" <[email-masked]> 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.
>>>
>>> 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.)
>>>

---

From: Lou Berger <[email-masked]>
Date: Wed, 03 Feb 2016 23:26:39 -0500

Alex,

On February 3, 2016 8:35:54 PM "Alexander Clemm (alex)" <[email-masked]> 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
>
>
> Cc: Lou Berger <[email-masked]>; netmod WG <[email-masked]>; Alexander 
> Clemm (alex) <[email-masked]>; Eric Voit (evoit) <[email-masked]>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 4 Feb 2016 09:56:59 +0000

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:
> 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...
>
> 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
>>
>>
>> Cc: Lou Berger <[email-masked]>; netmod WG <[email-masked]>; 
>> Alexander Clemm (alex) <[email-masked]>; Eric Voit (evoit) 
>> <[email-masked]>
>> 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
>>
>>
>>
>>
>>
>>
>>>> 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?
>>>>
> .

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 04 Feb 2016 12:38:45 +0100

Hi Lou,

>    implications, so these are not repeated here.

Both structural-mount and YSDL satisfy this.

>    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 LNE in our draft for an envisioned usage.)

Both structural-mount and YSDL satisfy this.

>    available e.g. RPC operations and notifications.

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

>    modules, mounting of submodules may also be useful. (DT not draft

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 04 Feb 2016 12:51:31 +0100

> mounted not a datastore. Scheme mount is really a better term than 

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

YSDL also requires that all YANG modules be known/advertised locally
through the local server's yang-library, so there are no extra security
implications compared to the current situation where all modules are
combined side-by-side.

Lada

---

From: Robert Varga <[email-masked]>
Date: Thu, 4 Feb 2016 12:54:57 +0100

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Feb 2016 13:00:28 +0100

>    modules, mounting of submodules may also be useful. (DT not draft

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         <http://www.jacobs-university.de/>

---

From: Lou Berger <[email-masked]>
Date: Thu, 04 Feb 2016 07:06:01 -0500

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

---

From: Robert Varga <[email-masked]>
Date: Thu, 4 Feb 2016 13:06:21 +0100

> schema/data model. The term "mount" is IMO more connected to combining data

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

---

From: Lou Berger <[email-masked]>
Date: Thu, 04 Feb 2016 07:07:50 -0500

Rob,

> I hope this clarifies my previous request.

Yes.  Although to me a merging may be more appropriate/likely then picking one.

Lou

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 4 Feb 2016 13:11:30 +0100

> On 04 Feb 2016, at 13:07, Lou Berger <[email-masked]> wrote:
> 
> Rob,
> 
> 

I agree.

Lada

---

From: Lou Berger <[email-masked]>
Date: Thu, 04 Feb 2016 07:46:39 -0500

Lada,
Thank you for the response.  See below.

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

> statements in YANG, extensions aren't applicable here.

Agreed.

> Both structural-mount and YSDL satisfy this.

Great.

> Currently only structural-mount addresses this, YSDL can be extended

Makes sense.

> 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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 4 Feb 2016 14:02:59 +0100

> On 04 Feb 2016, at 13:46, Lou Berger <[email-masked]> wrote:
> 
> Lada,
> 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

---

From: Lou Berger <[email-masked]>
Date: Thu, 4 Feb 2016 08:02:26 -0500

Juergen,
    See below.

> s/of submodules/of parts of modules/
yes.
> module". What exactly is a 'top-level module' (and does it matter, 
interfaces.
> 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.

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

Cheers,
Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Feb 2016 15:12:09 +0100

> > s/of submodules/of parts of modules/

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

> > module". What exactly is a 'top-level module' (and does it matter, 

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

> Good question.  This should be added to 5, i.e., a good capability, but

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

> 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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Feb 2016 15:19:48 +0100 (CET)

Hi,

> neither support the second paragraph.

I think that both structural-mount and ysdl satistfy this, in the
sense that they support the schema defintion for this use case.  The
instantiation is something that happens in the implementation.

/martin

---

From: Lou Berger <[email-masked]>
Date: Thu, 4 Feb 2016 09:53:11 -0500

Juergen,

see below.

On 2/4/2016 9:12 AM, Juergen Schoenwaelder wrote:
> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Feb 2016 17:12:31 +0100

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

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

/js

---

From: Lou Berger <[email-masked]>
Date: Thu, 4 Feb 2016 11:33:12 -0500

Juergen,

see below

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

> 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

---

From: <[email-masked]>
Date: Thu, 04 Feb 2016 11:46:47 -0500

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Feb 2016 17:55:51 +0100

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

> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Feb 2016 18:02:49 +0100

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

/js

---

From: Lou Berger <[email-masked]>
Date: Thu, 4 Feb 2016 12:07:32 -0500

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.

Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 4 Feb 2016 20:13:37 +0100

> 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

---

From: Lou Berger <[email-masked]>
Date: Thu, 4 Feb 2016 14:30:46 -0500

Juergen,

> of ietf-system but you would never consider to mount, say, /system/ntp
never is a strong word.  it's more accurate to say we don't currently
need in draft-...

> require is mount of top-level nodes).

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

Lou

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Feb 2016 21:22:51 +0100 (CET)

> require is mount of top-level nodes).

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

/martin

---

From: Lou Berger <[email-masked]>
Date: Thu, 4 Feb 2016 15:34:40 -0500

Martin,

> was the non-top-level module).

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

Lou

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 04 Feb 2016 21:51:38 +0100 (CET)

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

In my view, any module can be mounted.

Your original email had:

I think the word "top-level" can simply be removed from this
sentence.

/martin

---

From: <[email-masked]>
Date: Thu, 04 Feb 2016 17:17:49 -0500

> Can I mount /top/second? Why would a solution be simpler if I make

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.

---

From: "Alexander Clemm (alex)" <[email-masked]>
Date: Fri, 5 Feb 2016 02:43:18 +0000

Hi Lou,

the original draft specified mounting a model that was already instantiated on a server.  Your requirement #1 is a little different in that you want to instantiate a specific data model underneath another node in another model (without the same model already be instantiated elsewhere), as opposed to mounting a model that is already instantiated.  So, you're not inserting a reference and creating an alternative path to an instance, but inserting the model definition itself.  This is not the same, and not addressed by the original draft.  That said, it is evidently possible to build on the mount-model and extend or vary it in such a way that supports your case, and Martin's draft proposes how this can be done.  At the same time, there are other use cases (of alias-mount and peer-mount) which could be addressed with variations of the solution that build on each other.  

--- Alex

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, February 03, 2016 12:48 PM
To: Kent Watsen <[email-masked]>; Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco) <[email-masked]>
Cc: netmod WG <[email-masked]>; Alexander Clemm (alex) <[email-masked]>; Eric Voit (evoit) <[email-masked]>
Subject: Re: [netmod] Yang mount / ysdl example use case

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 <[email-masked]> wrote:

>>controller), and I know that there is at least one implementation of this draft.
>>
>>> 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.
>>>
>>>> structural-mount, or anyone else for that matter, on how they see 
>>>> to best meet these needs.
>>>>
>>>> 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
>>>>
>>>>
>>>>