Hi Martin,
On 06/02/2018 14:00, Martin Bjorklund wrote:
Hi,
Thanks for your comments, see inline.
Robert Wilton <rwil...@cisco.com> 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
