Hi Bart,

I think that the best solution to problem is perhaps to avoid it altogether.  I.e. I don't think that the only-if-feature leaf should be marked mandatory.  Instead, it would be better to define a sensible default value/behaviour if the leaf is absent even when the feature is supported.


Alternatively, you can simulate something similar to an if-feature statement by using a when or must expression instead that is predicated on a leaf that the client must explicitly set to enable the feature, giving control back to the client.

E.g. something along the lines of ...

leaf enable-super-feature {
  if-feature test-feature;
  type boolean;
  default "false";
}

...

      leaf only-if-feature {

        when '/enable-super-feature = "true"';

        type string;

        mandatory true;

      }

It would be interesting if you have a concrete example where neither of the above suggestions would work or be appropriate.

Thanks,
Rob


On 05/03/2018 09:25, Bogaert, Bart (Nokia - BE/Antwerp) wrote:

Hi,

We have a question with respect to YANG models using features.  Assume that a part of the model is defined under a feature and that this feature-dependent part defines a leaf as mandatory.

module servers {

  namespace "http://www.example.com/servers";;

  prefix servers;

  import ietf-inet-types {

    prefix inet;

  }

  revision 2018-03-01 {

    description

       "Initial version.";

  }

  feature test-feature {

    description "testing feature";

  }

  container servers {

    list server {

      key name;

      max-elements 64;

      leaf name {

        type string;

      }

      leaf ip {

        type inet:ip-address;

        mandatory true;

      }

      leaf port {

        type inet:port-number;

        mandatory true;

      }

      leaf only-if-feature {

        if-feature test-feature;

        type string;

        mandatory true;

      }

    }

  }

}

Now assume that we have a device that implements the model step-wise by first not supporting this feature and in a sub-sequent release by supporting this feature (and uses a persistent running datastore).  The question arising now is how to deal with this mandatory leaf?  Normally this can only be configured by a client, meaning that without any “help”, the NC server will not be able to startup with the data contained in the device’s persistent datastore unless a value is set for the mandatory leaf that now becomes available as a result of supporting the feature.

When modeling as follows it seems the NC server can start with the model supporting the feature that was not supported before:

module servers {

  namespace "http://www.example.com/servers";;

  prefix servers;

  import ietf-inet-types {

    prefix inet;

  }

  revision 2018-03-01 {

    description

       "Initial version.";

  }

  feature test-feature {

    description "testing feature";

  }

  container servers {

    list server {

      key name;

      max-elements 64;

      leaf name {

        type string;

      }

      leaf ip {

        type inet:ip-address;

        mandatory true;

      }

      leaf port {

        type inet:port-number;

        mandatory true;

      }

      container only-if-feature {

        presence "see if this helps";

        if-feature test-feature;

        leaf only-if-feature {

          type string;

          mandatory true;

        }

      }

    }

  }

}

Are recommendations or guidelines in place to deal with this?

Regards, Bart



_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to