Callpoint filtering for deep get

YANG
1

Consider this example yang file:

container {
    list big-state {
      config false; 
      key "name";
      leaf name {
        type string;
      }
     uses expensive-state-a;   // some other container group
     uses state-b;             // some other container group
    } 
}

And this is my tailf yang file for the above yang:

tailf:annotate "/mod:big-state" {
    tailf:callpoint some-show;
}

The publisher/external agent of this data implements the confd callbacks for ‘get-next’, ‘get-next-object’ etc.

I want the publisher to suppress the deep get at the ‘big-state’ node - in order to avoid accessing the expensive ‘expensive-state-a’ node unless specifically called for. The nodes ‘expensive-state-a’ and/or ‘state-b’ can do deep gets as appropriate.

Is there a tail-f specific yang extention to achieve this OR any confd API which can be implemented in the publisher ?

Thanks in advance.

2

I’m not aware of any Tail-f YANG extensions or ConfD API that would allow you to do that.

To prevent the deep get from happening upon a NETCONF get rpc request, you can make use of the NETCONF subtree filtering feature as described in NETCONF RFC 6241: Subtree Filtering to retrieve only the “name” elements of your big-state list.

Another alternative is to specify an additional list in your container with only keys in it as follows:

container {
    list big-state {
      config false; 
      key "name";
      leaf name {
        type string;
      }
     uses expensive-state-a;   // some other container group
     uses state-b;             // some other container group
    } 
    list alternative-big-state {
      config false; 
      key "name";
      leaf name {
        type string;
      }
    } 
}

and query this alternate list instead when you want to avoid the deep get from happening. You can even use the same callpoint (or publisher) for both lists.

3

Thank you for your reply, Waitai.
We are not using CLI instead of NETCONF, so first option is not possible for us. I will try multiple callpoints with same name as you suggested.

Thanks.

4

Another option without modifying your YANG model is to make use of ConfD’s maapi interface and add custom commands to your CLI.

You can either use

the maapi command that is intended to be used from inside a CLI command or a NETCONF extension RPC with the --keys option and the keypath to display just the list of key elements in your big-state list

or

the maapi_get_next( ) and maapi_get_elem( ) APIs that are part of the confd_lib_maapi library to iterate and display just the key elements of your big-state list.