Hi Rob,

I agree but the fact is that some of the BBF models have constructions like 
that and we were wondering whether this should not be mentioned in the 
guildelines document.  Normally a server can't set config true leafs if there 
is no default available in the model.  That is the reason we reached out to 
NETMOD.  Your suggestions can work but require adaptation of the current model.

Regards, Bart

From: Robert Wilton [mailto:rwil...@cisco.com]
Sent: Tuesday, March 6, 2018 10:38 AM
To: Bogaert, Bart (Nokia - BE/Antwerp) <bart.boga...@nokia.com>; netmod@ietf.org
Subject: Re: [netmod] Guideline on modeling including features and phased 
support by a device


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<mailto: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