Re: [netmod] schema-mount pre09 branch

[Robert Wilton <[e-mail]>]

Hi Martin,


On 06/02/2018 14:00, Martin Bjorklund wrote:
> Hi,
>
> Thanks for your comments, see inline.
>
> Robert Wilton <[e-mail]> wrote:
>> Hi,
>>
>> Some comments on the pre-09 version, particularly the data model.
>>
>>
>> 1) I still don't get why this draft is called "YANG Schema Mount"
>> rather than "YANG Mount", since to me this implies that it *only* the
>> schema that is being made available, and by implication not the
>> instance data.  I.e. I can see what schema a VM is using, but I cannot
>> access the instance data of that VM.
>>
>> I understand the scope of the draft (and I'm not trying to change that
>> at all), and agree that it doesn't specify any protocol for how to
>> remotely mount data (e.g. peer mount).  But my understanding of the
>> solution here is that it doesn't just mount the schema.  I think that
>> it also always makes the mounted instance data available using the
>> regular NETCONF/RESTCONF operations right?  Which sounds like it is
>> doing more than just mounting the schema!
> Once you have a mounted schema, even in the inline case, a server
> might be just a single normal server with no extra VMs or anything;
> you just have a nested schema.  Such a server would allow you to use
> normal edit-config to add mounted data, and it would just affect that
> single server's database and instrumentation.
OK.  So, it is not just the schema that is available, but also the 
instance data associated with that schema.

> The point is that schema mount says nothing about *how* things are
> instantiated.
I agree.

But I think that is also consistent with how the term "mount" is used 
from its Unix heritage.

I.e. just because some data is mounted doesn't imply that it is remote.  
E.g. if I look at my Linux VM's /etc/mtab I see a dozen mount points, 
only one of which I would class as being remote (from the perspective of 
the VM).

Whereas, to me the term "schema mount" implies that it is only the 
schema that are being mounted.  Why would there be instance data 
available if the only thing that is being mounted is the schema?

>
> Peer mount, OTOH, attaches instance-specific meaning to its mount
> points - if you try to write to peer mounted data the server will act
> as a "proxy" and write to the remote server.  (ok, current peer mount
> is defined to be read-only, but you get my point).
Yes, OK.  But I don't think that the term "YANG Mount" implies "Peer mount".

Extending the filesystem analogy further, I think that YANG mount tell 
you the mounted path, whether it is read/write, and where to find the 
schema.  It doesn't specify what protocol is being used to access that 
data.  E.g. in future I could imagine that peer mount might want to 
augment the mount-point/inline to indicate further properties about the 
mount point.  But this would seem to be somewhat odd if what it is 
augmenting is a "YANG schema mount" rather than just a "YANG mount".

>
>> 2) Regarding the YANG Data Model:
>>
>> (i) Should "schema-mounts" just be "mounts", since it is already under
>> the "schema" container.
> I don't have a strong opinion on this.
>
>> (ii) Should "parent-references" be part of the "use-schema" container,
>> or should then be part of a schema directly.  E.g. should schema-mount
>> augment yanglib:schema with both a "mounts" container and a
>> "parent-reference" leaflist.
> This would mean the same parent-references for all mount points in a
> schema, as opposed to per-mount-point parent-references as we have
> today.  Lada, what's your opinion on this?
>
>> (iii) Do we definitely need the namespace list?  Shouldn't the
>> prefixes/namespaces be resolved against the implemented modules in the
>> referenced schema, or is this not sufficient?  If this is not
>> sufficient, I wonder if it would be helpful for the draft to describe
>> this.
> It is not sufficient b/c the only prefixes available from the
> implemented modules are the prefixes in the modules themselves, and
> they aren't necessarily unique.
OK.  So would another choice could be to rather than having the 
namespace map from  prefix to namespace, instead have it as a map from 
prefix to module name (which is resolved against the implemented modules 
in the parent schema(s))?

The URI would still be available form the module entry in the parent 
schema (if required).  I'm just wondering whether this would make the 
binding feel a bit less XML encoding specific.

Thanks,
Rob

>
>> (iv) I agree with Juergen that "inline" is a confusing term because it
>> is meaning that the mounted schema is available inline in the instance
>> data tree, not that it is inline in the schema tree.
>
>
> /martin
>
>
>
>> Thanks,
>> Rob
>>
>>
>> On 31/01/2018 21:36, Kent Watsen wrote:
>>> All,
>>>
>>> The authors created a "pre09" branch on GitHub a few weeks back.  On
>>> this branch, they completed a full update of the draft.  While waiting
>>> for details on how to proceed with regards to a SM-bis, we thought it
>>> would be helpful to make this text available now so that the technical
>>> parts can be discussed.  With this in mind, can folks please have a
>>> quick look and post any technical comments they have?
>>>
>>>
>>> The "txt" version of the draft:
>>> https://raw.githubusercontent.com/netmod-wg/schema-mount/pre09/draft-ietf-netmod-schema-mount-pre-09.txt
>>>
>>>
>>> rfcdiff against the current -08 draft:
>>> https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-schema-mount-08&url2=https://raw.githubusercontent.com/netmod-wg/schema-mount/pre09/draft-ietf-netmod-schema-mount-pre-09.txt
>>>
>>>
>>> Since rfc7895bis obsoletes RFC 7895, the
>>> server-must-implement-rfc7895bis requirement is no surprise, right?
>>>
>>> Thanks,
>>> Kent // shepherd
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> .
>>>
> .
>