Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-list-pagination-03

[Kent Watsen <[e-mail]>]

Hi Lada!

Thank you for your YANG Doctor review.   You raise a very good point.  It is too bad that the WG missed it.   The authors will respond shortly. 

Kent  // co-author 


> On May 1, 2024, at 5:57 AM, Ladislav Lhotka via Datatracker <[e-mail]> wrote:
> 
> 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?
> 
> 
>