Re: [netmod] Guideline on modeling including features and phased support by a device

[Robert Wilton <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod