[netmod] comments on YANG mount requirements draft

[Andy Bierman <[e-mail]>]

Hi,

I was reading the requirements draft to see if that
offered any insight wrt/ why I should like any of the solution drafts.


https://tools.ietf.org/html/draft-voit-netmod-yang-mount-requirements-00


sec 1)  I do not really agree that the priority should be to make the
client as simple as possible.  There is no mention of the overall system
impact if the complexity is moved to the managed devices
(where resources are more expensive than a workstation or laptop)

I do not agree Alias Mount is needed at all.
This is a local presentation issue.  The client software
can map /foo/bar/baz to /top/acme-objects/orange
if they want.  It is a client-side presentation issue.
I do not understand why the client tool does not
just use the object paths derived from the YANG modules.

The only part of this problem space I support
is the ability for a controller to provide a nested root,
representing the document root of the mounted device.
This allows the YANG to be mapped correctly and predictably.

E.g,

OK (mount from root)

   /mounts/mount/server1/interfaces/interface/mtu

NOT OK (mount from arbitrary subtree)

   /mounts/mount/server1/interface/mtu


All cases in which the YANG paths are supposed to be ignored
because the relocated YANG is broken should not be allowed.

I do not see why we need YANG Mount and YANG Push and Pub/Sub.
Seems like they all do the same thing.  The client needs
push updates instead of polling the server.  What the client
does with the pushed data is an implementation detail.


Andy