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 <noreply@xxxxxxxx> 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? > > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
