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
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
