config=false node when mandatory

I have a Yang model which defines a config=false node which is mandatory too. Should I return that node as an empty XML node in get rpc response, even when my app does not support it?

Ideally my app is supposed to support it, but due to limitations we cannot implement the required support. So what should be the right way to handle such cases? Should we emit/represent it in get rpc response as an empty XML node? I guess if we ignore such nodes, the external controller may fail the get rpc response.

-Ram

Solution

If your server implementation does not support a specific node in the original model, you should create a deviation YANG module, which expresses this limitation. This way clients are informed about it and everyone is happy - you of course advertise your deviation module along with the deviated one.

For example:

module target {
  yang-version 1.1;
  namespace "target:uri";
  prefix "tgt";

  container state {
    config false;
    leaf some-counter {
      type uint64;
      mandatory true;
    }
  }
}

Let's say your device cannot support some-counter leaf above. You then create create a deviation module, which describes how your implementation differs from a compliant implementation.

module target-dev {
  yang-version 1.1;
  namespace "target-dev:uri";
  prefix "tgtd";

  import target {
    prefix tgt;
  }

  deviation "/tgt:state/tgt:some-counter" {
    deviate not-supported;
  }
}

When a get request comes, you return nothing for that leaf, since it does not exist in your implementation's world.

The details of deviation and deviate statements may be found in RFC7950:

You should be very careful when relying on this mechanism! Always create a separate module, which contains only the deviations, possibly deviating a single target module. There is a guidelines document you should read just in case.