leafref validitation by NC Server

[robbynet]

With v2.1.42, improvements regarding leafref validity has been observed. Now with v2.1.49, it appears that leafref in Yang below does not lead to any error into NC Server while the path of the leafref is not set in the Datastore. Yang extract is the following :

list transceiver-objects {
         key measurement-object;
         description "list of transceiver objects";
         leaf measurement-object {
           type leafref {
             path "/performance-measurement-objects/transceiver-measurement-objects/measurement-object";
           }
           description "a measurement object";
         }
       }

With full tree view

module: 
  +--rw performance-measurement-objects
     +--ro measurement-capabilitites
     |  +--ro transceiver-objects* [measurement-object]
     |  |  +--ro measurement-object    -> /performance-measurement-objects/transceiver-measurement-objects/measurement-object
 ....
     +--rw transceiver-measurement-objects* [measurement-object]
     |  +--rw measurement-object                enumeration
     |  +--rw active?                           boolean
     |  +--rw report-info*                      enumeration
     |  +--rw object-unit                       enumeration
     |  +--rw function?                         enumeration
     |  +--rw bin-count?                        uint16
     |  +--rw lower-bound?                      decimal64
     |  +--rw upper-bound?                      decimal64

And result is correct into the CLI while path /performance-measurement-objects/transceiver-measurement-objects/measurement-object does not exist in the datastore ! Wonder if NC Server should not prevent/refuse to share list transceiver-objects when corresponding path is not set in Datastore ?

> get --filter-xpath /o-ran-performance-management:performance-measurement-objects
DATA
<data xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <performance-measurement-objects xmlns="urn:o-ran:performance-management:1.0">
    <measurement-capabilitites>
      <transceiver-objects>
        <measurement-object>RX_POWER</measurement-object>
      </transceiver-objects>
      <transceiver-objects>
        <measurement-object>RX_POWER_LANE_2</measurement-object>
      </transceiver-objects>
    </measurement-capabilitites>
    <max-bin-count>10</max-bin-count>
  </performance-measurement-objects>
</data>

[michalvasko]

So I wanted to improve this but it turns out it is really challenging if not impossible. Based on the nature of operational datastore (in sysrepo) the datastore is changing very often and (when using oper get subscriptions) even without sysrepo knowledge. Meaning it is possible to determine whether the operational datastore is valid at a given moment but not in general.

You can use the validate RPC to check the immediate validity of it and there is nothing else we can really do. But update sysrepo first, proper operational datastore validation has been added (it allows for broken YANG semantic constraints when libyang generates only warnings).

[robbynet]

Thanks for the sharing