Reviewer: Ladislav Lhotka Review result: On the Right Track **** 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? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
