[Sorry, fat-fingered the send button]
Here's how the paths might be altered:
- ../../../../../explicit-paths/explicit-path/name
+ /explicit-paths/explicit-path/name
Back to your question, I guess that something could be done, but I'm unsure if
how important it would be relative to other work going on in the NETCONF WG.
It will be interesting to see what other opinions are.
K. // contributor
On 10/6/17, 5:11 PM, "netmod on behalf of Xufeng Liu" <netmod-boun...@ietf.org
on behalf of xufeng.liu.i...@gmail.com> wrote:
During the design team discussion for TE and MPLS YANG modeling, we have
received a request from implementers: How to minimize the number of
NETCONF/RESTCONF RPCs to improve operation efficiency? Especially for the case
when the operator or client software needs to retrieve the object contents
pointed by a leafref.
For example, given the following simplified TE tunnel model,
+--rw te
+--rw explicit-paths
| +--rw explicit-path* [name]
| +--rw name string
| +--rw explicit-route-object* [index]
| +--rw index uint32
| +--rw explicit-route-usage? identityref
+--rw tunnels
| +--rw tunnel* [name]
| | +--rw name string
| | +--rw paths
| | | +--rw path* [name]
| | | +--rw explicit-path? ->
../../../../../explicit-paths/explicit-path/name
when the client tries to retrieve a tunnel’s information based on the tunnel
name, the “get” operation returns a list of leafref’s pointing to the paths of
the tunnel. The client needs to issue at least one more “get” operation to
retrieve the path information about the given tunnel. The request is to combine
these two operations into one.
In the RDBMS SQL world, “join” can be used when SQL “select” is performed, but
NETCONF/YANG currently does not have this capability.
We’d like to ask whether such a request is considered reasonable.
If the request is reasonable, the next question is how to proceed. This seems
to be a protocol issue rather than YANG modeling issue. Is it acceptable to add
a new operation to achieve such a <get-data> operation with expanded leafref’s?
Comments and suggestions are appreciated.
Thanks,
- Xufeng
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
