[netconf] comments on pagination drafts

[Andy Bierman <[e-mail]>]

Hi,

I am trying to understand some of the pagination details and some
parts are unclear or problematic.

1) groupings

There are groupings for each parameter, then another using all of them.
Are the individual groupings used anywhere?  There are dependencies between
parameters so it is unclear what the intended reuse is here.

This has been mentioned but adding "-grouping" to most grouping names
is too verbose.

2) conformance

It looks like all parameters are MUST implement for NETCONF, but all
parameters
are optional in RESTCONF.  Why are capabilities needed in RESTCONF?

IMO the mandatory parameters should be implementable by streaming servers.
NETCONF devices are not application databases.

The following parameters can be supported by a streaming server:

- where
- offset
- cursor
- limit
- sublist-limit

The following parameters cannot be supported by a streaming server:
IMO these should have an if-feature.

- sort-by
- locale
- direction

3) document structure

IMO these 3 drafts should be combined so it is easier to read and there
are less inconsistencies between RFCs that are this tightly coupled.

The YANG model is missing some of the info in sec 3.1.
YANG automation tools do not see the ad-hoc text in sec 3.1.
This section should be removed or replaced with a short summary,
and the details put into the YANG module.

4) cursor

The text in 3.1.6 says:

    The allowed values are base64 encoded positions interpreted by the
server
    to index an element in the list,

The YANG module shows type 'string'.
So the values are anything a string supports.
Our experience has shown that exposing binary64 string to humans
is very error-prone and difficult to debug.
They are a great way to invite data injection attacks as well.

I guess a list with multiple keys is supposed to be encoded in some
proprietary way to pack N leafs into 1 leaf?
YANG has 'anydata' to avoid this bad practice.
IMO the cursor should be anydata, not a base64 string.

5) metadata

There are a lot of attributes mixed in with the data being returned.
This does not work well if the code handling the iteration control
is not the same as the code processing the list data.
IMO any data that needs to be returned should be proper YANG
objects. You can augment the output of those RPCs, not just the input.

6) leaf-list pagination

Nobody has ever asked us for this feature.
Are there any examples of leaf-lists so large that they need pagination?
Usually a client wants to retrieve all the leaf-list instances at once.


Andy