Skip to main content

Last Call Review of draft-ietf-netconf-list-pagination-03
review-ietf-netconf-list-pagination-03-yangdoctors-lc-lhotka-2024-05-01-00

Request Review of draft-ietf-netconf-list-pagination
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team YANG Doctors (yangdoctors)
Deadline 2024-05-01
Requested 2024-04-06
Requested by Kent Watsen
Authors Kent Watsen , Qin Wu , Per Andersson , Olof Hagsand , Hongwei Li
I-D last updated 2024-05-01
Completed reviews Yangdoctors Last Call review of -03 by Ladislav Lhotka
Assignment Reviewer Ladislav Lhotka
State Completed
Request Last Call review on draft-ietf-netconf-list-pagination by YANG Doctors Assigned
Posted at https://mailarchive.ietf.org/arch/msg/yang-doctors/EGmM-o7kVIyOTvzWdf1ZIgpmFmg
Reviewed revision 03
Result On the Right Track
Completed 2024-05-01
review-ietf-netconf-list-pagination-03-yangdoctors-lc-lhotka-2024-05-01-00
**** General comments

- This document, together with companion I-Ds
draft-ietf-netconf-list-pagination-nc and
draft-ietf-netconf-list-pagination-rc, aims at providing a relatively
comprehensive functionality for paginating and sorting list and leaf-list
entries in NETCONF/RESTCONF server output. This is a much needed addition to
both protocols.

- I very much like the extensive set of examples in Appendix A that illustrates
a broad range of possible uses.

- The handling of "config false" lists brings about considerable complexity.
Also, it seems to cater for SQL database backends and I am not sure whether the
constraints on "config false" data can also be easily implemented with other
backend architectures that might be suitable for huge datasets, such as Xapian
or ElasticSearch. What I am missing here is a description of typical use cases
for "config false" data and a cost/benefit analysis. Perhaps it could make
sense to adopt a simpler and less flexible approach for "config false" data.

- My main concern is the use of XPath 1.0 for the "where" query parameter.
Firstly, the definition in sec. 3.1.1 does not specify the necessary context
for XPath evaluation. In particular, the "real" XPath 1.0 as defined by W3C has
no concept of default namespace, so the namespace has to be specified for every
data node in the "where" parameter - but then it is necessary to find a way for
specifying prefix bindings. Some of the examples in Appendix A also seem to use
references to XML attributes (for example,
"joined[starts-with(@timestamp,'2020')]"). I don't know if this means metadata
annotations [RFC 7952], but in any case using the attribute axis in XPath for
querying non-XML data is problematic.

**** Specific comments, nits

- sec. 3.3 paragraph 4
  s/However, arbitrary/However, translating abitrary/

- sec A.3.6.2 (and other places)
  Why "@email-address"? I think it should be "email-address" (though with
  namespace prefix, see above), because "email-address" is a normal YANG leaf
  represented as XML element in instance data. Or am I missing something?