Do we need RESTCONF depth/fields filters?

[cabo]

(Andy Bierman, https://mailarchive.ietf.org/arch/msg/core/XLv4ZusZubBrJPC5aW7UqqeHrxw)

The client must know all of the key values in advance
before being able to use the SID of a data node
in a FETCH request. It is difficult and expensive
to retrieve the entire datastore contents at once,
just to discover the key values in use for the YANG list
entries within the datastore.

RESTCONF has the 'depth' and 'fields' filter parameters
to address this issue. NETCONF has subtree and XPath filtering.
NETCONF servers can generally support selection of 1 value or all
values, for each key.

Perhaps CORECONF will need the 'depth' filter parameter.

[abierman]

Follow up: OK to defer to future

• The client does not need to know all the keys in advance to get all the list entries, by getting an ancestor of the list
• The amount of data retrieved depends on the YANG modules used. It is possible to design containers with limited
  child nodes and depth. It is possible to limit the maximum number of list instances, or expect a small number of entries by design,
• The 'depth' parameter is not likely to help in CoMI because the data trees will not be as complex or deep as NETCONF
• These filtering query parameters are optional in RESTCONF

The likely problem is that the list is too wide, not too deep.
Even a simple list with 4 leafs in it is a lot of data if there are 10000 entries in the list.
If needed, a list pagination mechanism could be added in the future.
NETCONF WG has work-in-progress: https://datatracker.ietf.org/doc/draft-ietf-netconf-list-pagination/

[lemikev]

For now, getting indexes, pagination, and other approaches can be implemented using RPCs. This can be sufficient even for the long term. Michel From: Andy Bierman ***@***.***> Sent: July 24, 2025 3:48 PM To: core-wg/comi ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [core-wg/comi] Do we need RESTCONF depth/fields filters? (Issue #15) External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints [https://avatars.githubusercontent.com/u/1810575?s=20&v=4]abierman left a comment (core-wg/comi#15)<#15 (comment)> Follow up: OK to defer to future * The client does not need to know all the keys in advance to get all the list entries, by getting an ancestor of the list * The amount of data retrieved depends on the YANG modules used. It is possible to design containers with limited child nodes and depth. It is possible to limit the maximum number of list instances, or expect a small number of entries by design, * The 'depth' parameter is not likely to help in CoMI because the data trees will not be as complex or deep as NETCONF * These filtering query parameters are optional in RESTCONF The likely problem is that the list is too wide, not too deep. Even a simple list with 4 leafs in it is a lot of data if there are 10000 entries in the list. If needed, a list pagination mechanism could be added in the future. NETCONF WG has work-in-progress: https://datatracker.ietf.org/doc/draft-ietf-netconf-list-pagination/ - Reply to this email directly, view it on GitHub<#15 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADZVLN7KPCBIBQZ5EI3IYCL3KE2AZAVCNFSM6AAAAACCJZH3A2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCMJUG4ZDMNZXGI>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>