Igor Bryskin <igor.brys...@huawei.com> wrote: > > Hi Per, > > Basically, what we need is a way for a client to request something > like this: > > get <XPath> joint with <XPath1, XPath2, ..., XPathn>
... which is what Per's expression does! Note that "|" in XPath means "union". But as Per explained, it only works in some cases (when the leafref acts a "single pointer"). > with a server interpreting the request as follows: > if a node pointed by XPath contains a pointer (e.g. key leafref) > matching one of the XPath from the "joint with" list, then the server > must provide the entire body of the node pointed by the pointer, > otherwise, just the pointer (as it happens today, that is, when no > "joint with" list specified). > > We think that this would allow for the client to optimize the number > of request-response iterations depending on application/use case. > > Regards, > Igor /martin > > > > > > > -----Original Message----- > From: Per Hedeland [mailto:p...@tail-f.com] > Sent: Monday, October 09, 2017 12:06 PM > To: Xufeng Liu > Cc: Igor Bryskin; netc...@ietf.org; netmod@ietf.org > Subject: Re: [Netconf] [netmod] Retrieving Information Pointed by > leafref > > I understand your use case, but a leaf of type leafref does not in > general identify a single node in the data tree - the leafref path > could > be for a non-key leaf, and/or the path could traverse list nodes, > and/or > the "target" list could have multiple keys and thus multiple > leafref-leafs be required to identify a specific list entry. > > Thus it seems to me that your use case is not a reasonable basis for a > new protocol operation. My XPath foo isn't very good either, but I do > believe Robert's suggestion of using an XPath filter could be a way > forward. I *think* the filter expression would be something along the > lines of > > /te/tunnels/tunnel[name='foo'] | > > /te/explicit-paths/explicit-path[name=/te/tunnels/tunnel[name='foo']/paths/path/explicit-path] > > --Per > > On 2017-10-09 15:42, Xufeng Liu wrote: > > Hi Per, > > > > > > > > *From:* Igor Bryskin [mailto:igor.brys...@huawei.com] > > *Sent:* Sunday, October 8, 2017 7:04 PM > > *To:* Igor Bryskin <igor.brys...@huawei.com>; p...@tail-f.com; > > *xufeng.liu.i...@gmail.com > > *Cc:* netc...@ietf.org; netmod@ietf.org > > *Subject:* Re: [Netconf] [netmod] Retrieving Information Pointed by > > *leafref > > > > > > > > > > Hi Joel, > > > > Thanks, I think I didnt explain our problem correctly. > > > > In our case we have a leafref pointing to a te tunnel name, which > > happens to be a key to lookup the (axilary) tunnel. We need a way to > > include the entire tunnel body (not just a name) into the get > > response. This is to optimize the number of iterations between the > > client and the server. As Xufeng put it something similar to SQL join, > > > > Igor > > > > *From:*Igor Bryskin > > > > *To:*p...@tail-f.com,xufeng.liu.i...@gmail.com, > > > > *Cc:*netc...@ietf.org,netmod@ietf.org, > > > > *Date:*2017-10-08 17:36:47 > > > > *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by > > *leafref > > > > > > > > Hi Per, > > > > In a nutshell we would lika for a netconf client to have a way to > > instruct the server on whether in response to the get request the > > server needs to provide the entire body of a datastore node pointed > > to by a leafref or just a pointer to said node, so that the node's > > body could be retrieved by a subsequent separate request. This is > > requested by implementors who want to optimise rhe number of > > interactions between a client and its server. > > > > Cheers, > > Igor > > > > *From:*Per Hedeland > > > > *To:*Xufeng Liu, > > > > *Cc:*netc...@ietf.org,'NetMod WG', > > > > *Date:*2017-10-08 14:01:27 > > > > *Subject:*Re: [Netconf] [netmod] Retrieving Information Pointed by > > *leafref > > > > > > > > On 2017-10-06 23:11, Xufeng Liu 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 tunnels information based on the > >> tunnel name, the get operation returns a list of leafrefs pointing > >> to the paths of the tunnel. > > > > Sorry, I'm afraid I don't follow. Can you explain exactly what your > > "get" request is (protocol and payload), and where the "list of > > leafref's" (whatever that may be) occurs in the reply? > > > > */[Xufeng] The get operation is the NETCONF/RESTCON <get> protocol > > *operation, or the <get-data> operation described in > > *https://tools.ietf.org/html/draft-dsdt-nmda-netconf-01 and the GET > > *operations > > on {+restconf}/ds/<datastore> described in > > https://tools.ietf.org/html/draft-ietf-netconf-nmda-restconf-00./* > > > > */ /* > > > > */We have a list of leafref values because in this example model, each > > *tunnel contains a list of paths, each of them contains a leafref. The > > *get returns a value for each instance of such a leafref, > > which (as a string value) will be used as a constraint (foreign key) > > to retrieve the instance of an explicit-path in the model above./* > > > > > > > > JFYI, in case there is some fundamental misunderstanding here: a leaf > > of > > type leafref has a single value - *one* of those that satisfy the > > leafref > > constraint, in case there are multiple "candidates". > > > > --Per > > > >> 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. > >> > >> Wed 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 leafrefs? > >> > >> Comments and suggestions are appreciated. > >> > >> Thanks, > >> > >> - Xufeng > >> > >> > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org <mailto:netmod@ietf.org> > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > > > _______________________________________________ > > Netconf mailing list > > netc...@ietf.org <mailto:netc...@ietf.org> > > https://www.ietf.org/mailman/listinfo/netconf > > > > _______________________________________________ > Netconf mailing list > netc...@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod