XPath Key Extraction Is Algorithmically Undefined for the General Case (RFC 8641 §3.6)

[ahassany]

RFC 8641 §3.6 refers to XPath as a full query language (referencing the W3C XPath specification). The draft shows one example XPath filter: ietf-interface:interfaces/interface[type='ianaift:ethernetCsmacd'] and states that the absolute-schema-nodeid is interfaces/interface. This extraction is correct only because the XPath happens to be a simple downward path with a single predicate. No general algorithm is provided. Valid XPath expressions in YANG-Push subscriptions can include:

• Union expressions: //interfaces/interface | //routing/ribs — produces two disjoint schema paths, not one.
• Descendant-or-self axis: //interface — the schema location depends on the full tree context.
• Predicates with functions: interface[starts-with(name,'eth')] — the path extraction is clear, but the list key value derivation is not.
• Compound predicates filtering non-key leaves: interface[oper-status='up'] — no list key is present in the predicate at all; the key cannot be extracted from the filter expression.

The draft provides no algorithm for stripping predicates, handling axes, or resolving union expressions intoabsolute-schema-nodeid values. For the compound predicate case — which is very common in operational use — the draft's stated approach of deriving the key from the XPath filter is simply not possible without examining actual data at runtime, which is a fundamentally different and more expensive operation than filter parsing.

The draft MUST either specify a complete parsing algorithm covering XPath's expressible subset relevant to YANG-Push, or
restrict its scope to simple path-with-key-predicate expressions and state this normatively.