a minimal useful profile of List Pagination

[flycoolman]

(1) p 0, sec
This document defines a model for list pagination that can be
implemented by YANG-driven management protocols such as NETCONF and
RESTCONF. The model supports paging over optionally filtered and/or
sorted entries. The solution additionally enables servers to
constrain query expressions on some "config false" lists or leaf-
lists.
We are considering implementing parts of this specification.
My main comment is that I think that this solution has a risk of being a
bit like YANG Push. I.e., there is some basic functionality here which
should be reasonably implementable by most devices (since the required
functionality is needed to support basic GET requests). The other more
complex functionality, that is nice to have, but for some implementations
would be resource intensive to implement. Specifically, some methods of
storing the data allow for these queries to be performed efficiently, but
others do not, and hence would probably require all the data to be stored
in a temporary structure before returning sub-sections of that data.
I would like to see this solution define a "minimal viable" version of
list pagination that covers the core requirements of efficiently returning
subsets of the paged data, separately for the more advanced
sorting/filtering. This would give more flexibility in implementation,
rather than implementing all or nothing.
Hence, I would suggest that a minimal useful profile of List Pagination
supports the following:

1. limit
2. cursor (next only), noting that the cursor could just encode an index
   for index based data structures.
3. sublist-limit (probably)
   The above 3 features should be sufficient for any client to efficiently
   page through list data, and which most server implementations should be
   able to handle. I.e., it gives a step change improvement in client
   capability without too much cost/complexity on servers.