Re: [netconf] restconf collections

[Qin Wu <[e-mail]>]

发件人: netconf [mailto:[e-mail]] 代表 Andy Bierman
发送时间: 2020年9月26日 1:22
收件人: Kent Watsen <[e-mail]>
抄送: [e-mail]
主题: Re: [netconf] restconf collections



On Fri, Sep 25, 2020 at 9:56 AM Kent Watsen <[e-mail]<mailto:[e-mail]>> wrote:
Hi Andy,



This has been discussed a few times by the WG.

Perhaps a testament to it being a real problem?



The co-authors never agreed on the set of bells and whistles that should be supported.

True, but it's more like we lost interest / time to work on it...at least that's my story!  ;)



There was an objection from Phil Shafer at the time that pagination was not needed
at all and handling large responses from the server was just a minor implementation detail.

Clearly Phil is in the rough, as many APIs support pagination for a reason.   Even if constraining the solution to networking gear, interfaces and logs may be numerous, and on-box cli/web UIs can only show a screen at a time...



Our customers agree with you.  Some of them only use our <get-bulk>, and stopped using <get> and <get-config>.
Since it is implemented as an RPC, all YANG-based protocols can use it.
Obviously you need XPath filtering (XSLT-style) to select the list entries of interest.
Count and depth and other parameters from <get> are also useful.

(My concern is that the IETF version will be too complex to implement or use as the feature list grows.)
[Qin]:That’s the issue we try to address in our customer’s scenarios. If the solution only focuses on list, the complexity is controllable. If the scope is not limited to list, XAPTH filtering and query actually provides a good solution to navigate from root node to leaf node.

IMO, it's okay if we don't support for CT-lists (i.e., interfaces).  As you write above, and I wrote in before, it seems like a nice-to-have.   FYI, I'm asking Per in a fork of this thread to justify if supporting CT-lists is a "must-have"...hopefully he'll come back with something compelling.


There is no extra complexity to support config vs. operational data.
I don't see the value in restricting the operation.


CF-lists, on the other hand, can be enormous...so much so that trying to return all could exhaust server and/or client resources.   I think supporting CF-lists is a must-have.



The most significant objection was that this is a RESTCONF-only solution and that
was not acceptable to ignore NETCONF (since <get> and GET end being the same
in the end, so the problem also exists for NETCONF)

True.  If we can find a way to extend support to NETCONF, all the better.   Of course, the solutions would be wildly different, much like how NMDA had separate solutions for NC and RC (RFCs 8526 and 8527, respectively).  Perhaps Per or Martin can clue us into if they have a NC-equivalent solution?


It is easy. Use RPC operations which map to RESTCONF POST automatically.

[Qin]: Agree, NETCONF fragment provide an example on what RPC operations look like
https://tools.ietf.org/html/draft-zheng-netconf-fragmentation-02
which is similar to getbulk operation.

However, if NC-support cannot be achieved, then I don't think it means we don't do it for RC.   Much like NC supports somethings RC doesn't (e.g., confirmed commit), each protocol plays into its strengths.   So mote it be.


Andy

K.



Andy