Subject: [netconf] Arbitrarily complex XPath expression evaluation

From: Qin Wu <[email-masked]>
Date: Wed, 20 Oct 2021 04:58:01 +0000

Hi, Rob:
Sorry for late follow up for your comments on adaptive subscription draft.
In adaptive subscription draft, we use similar selection filter defined in
RFC8641 to express a standard XPath Evaluation criteria against targeted data object.
Such XPath Evaluation will strictly follow rules defined in section 6.4 of [RFC7950]
and section 3.4 of [XPATH1.0] and contains comparisons of datastore node
with its value to the specific threshold

One concern you raised in last IETF meeting is arbitrarily complex XPath expression,
we plan to add a new section in the new version to discuss
Arbitrary XPath Complexity Evaluation as follows:
"
3.  Arbitrary XPath Complexity Evaluation

   YANG-Push subscriptions [RFC8641] specifies selection filters to
   identify targeted YANG datastore nodes and/or datastore subtrees for
   which updates are to be pushed.  In addition, it specifies update
   policies that contain conditions that trigger the generation and
   pushing of new update records.  To support adaptive subscription defined
in this document, the trigger condition can also use similar selection
filter to express a standard XPath Evaluation criteria (section 6.4 of
[RFC7950]) against targeted data object.

   Similar to on change subscription, the adaptive subscription are
   particularly effective for data that changes infrequently with
better performance, the following complex design choices need to
be cautious, although these designs have already been well supported
by the section 3.4 of[XPATH1.0]:

   o  Support XPath Evaluation criteria against every data objects;

   o  Support any type of node set in the XPath Evaluation criteria,
      e.g., string,int64, uint64, and decimal64 types;

   o  Both objects in the XPath Evaluation criteria to be compared are
      node-sets;

   o  Two objects to be compared are in different data type, e.g., one
      is integer, the other is string

   As described in section 6.4 of RFC7950, Numbers in XPath 1.0 are IEEE
   754 [IEEE754-2008] double-precision floating-point values; some
   values of int64, uint64, and decimal64 types cannot be exactly
   represented in XPath expressions.

   If Two Objects to be compared are in different data type, conversion
   function is needed to convert different data type into numbers.

   In both objects in the XPath Evaluation criteria to be compared are
   node-sets, more computation resources are required which add
   complexity.

   To avoid these pitfalls, the following design principles are
   recommended:

   o  XPath Evaluation criteria against minimal set of data objects in
      the data model, these minimal set of data objects can be advertised
      using Notification capabilities model defined in [I-D.netconf-
      notification-capabilities].

   o  XPath Evaluation criteria only support condition expression that
      filter updates based on numbers.

   o  One object to be compared in the XPath Evaluation criteria MUST be
      nodeset.

   o  The other object to be compared in the XPath Evaluation criteria
      MUST be numbers data type.
"
Let us know this change address your comment, what else is needed?

-Qin (on behalf of authors)