Re: [netconf] restconf collections

[Andy Bierman <[e-mail]>]

Hi,

This has been discussed a few times by the WG.
The co-authors never agreed on the set of bells and whistles that should be
supported.
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.
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)


Andy


On Fri, Sep 25, 2020 at 4:03 AM Kent Watsen <[e-mail]> wrote:

>
> The restconf-collections draft [1] expired long ago, and yet the problem
> remains.
>
> What is the problem?  In my opinion, the problem is more narrow in scope
> than before.  Specifically, I feel that it is limited to just "config
> false" lists, which tend to contain an enormous number entries.  Classic
> examples include "audit logs" and "device logs".
>
> I do not feel that "config true" lists are a problem because 1) if it's
> possible for the client to configure a list, then it should be no problem
> for the client to handle getting it back and 2) clearly this is what
> everyone is doing today, unless using proprietary solutions, as RFC 8040
> offers no option.
>
> It's understood that supporting "config true" lists could improve
> performance some, but this seems more like a "nice to have" compared to
> supporting "config false" lists, where returning all list entries in a
> single response risks exhausting internal memory buffers resulting in
> failures, and thus solving this problem seems more of a "must have".  Not
> to mention, handling "ordered-by user" lists would be very difficult.
>
> [As an aside, how are people handling large "config false" lists today?
> Is each list-entry streamed out as a "notification"?  Isn't there still
> always a need to have at least the most-recent list entries, which could
> still be a lot, on the server?]
>
> The net-net is that I'm thinking we should brushoff the
> restconf-collections draft, and I'm wondering to what extent the WG agrees.
>
> Anyone?
>
>
> Regarding solution, I suggest a two-fold approach:
>
>   1) only support query parameters (e.g., offset, limit, sort, where) if a
> "config false" list is queried directly.  E.g., GET
> {+restconf}/ds/ietf-datastores:operational/example-module:widgets/widget?offset=20?limit=50.
> Note that RESTCONF does not allow the list itself to be a resource target
> is exactly why this makes sense.
>
>   2) any "config false" list that is a descendent of the resource target
> returns a placeholder response, rather than its contents.  Specifically, a
> top-level query on <operational> would NOT return any "config false" list
> entries.  As for the placeholder response, perhaps it could return
> metadata, something like: { "example-module:widgets": { "widget": [ { "@":
> { "ietf-collections:redacted": [None] } } ] } }.  To be
> backwards-compatible, it could be this list "entry" is only returned if the
> client sends a special query parameter (e.g., ?collections-supported) or,
> alternately, the server implicitly always only returns at most one
> list-entry (e.g., as if ?limit=1 was passed).
>
>
> Comments?
>
> K.
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf-collection
> _______________________________________________
> netconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>