search

netmod-wg / yang-next

Feature requests for future versions of YANG
6 stars 0 forks source link

Disallow if-feature statements where enabling the feature removes data nodes from the schema #98

Open rgwilton opened 4 years ago

rgwilton commented 4 years ago

The expressions for if-feature nodes should not be allowed to remove nodes from the tree when a feature is enabled because it makes conformance for clients very complex. E.g. if-feature "not foo-feature" should not be allowed, but possibly if-feature "bar and not foo" might be OK, or it might be better to deprecate with a view to removing the use of "not" altogether in if-feature expressions.

mbj4668 commented 4 years ago

Can you explain what you mean with "makes conformance for clients very complex"?

rgwilton commented 4 years ago

I think that a client should be able to code against a model without any features enabled, and then be able to expect to work with any implementation, regardless of what features are enabled. I.e. features should only be used to turn on optional functionality in the model, never to turn off functionality.

If a particular implementation wants to remove stuff from the schema then I think that it is cleaner to use deviate delete statements, which makes it clear to clients that normal functionality is being removed.

E.g. section 5.6.2. Optional Features of YANG 1.1 states:

   A module may declare any number of features, identified by simple
   strings, and may make portions of the module optional based on those
   features.  If the server supports a feature, then the corresponding
   portions of the module are valid for that server.  If the server
   doesn't support the feature, those parts of the module are not valid,
   and applications should behave accordingly.

But the last two sentences are not true if supporting a feature disables functionality rather than enabling it.

I also think that it also causes problems with NMDA, that states:

   The datastore schema for <operational> MUST be a superset of the
   combined datastore schema used in all configuration datastores,
   except that configuration data nodes supported in a configuration
   datastore MAY be omitted from <operational> if a server is not able
   to accurately report them.

It would be good if that superset schema can always be expressed as a combination of YANG modules + features. But if a feature can enabled some stuff in one module, and disable stuff in another module then that it would seem that is no longer possible, since the superset schema would be incomplete regardless of whether the feature is enabled or disabled ...

abierman commented 2 weeks ago

this restriction should not be added. the "not feature-foo" mechanism is useful when used carefully. It allows the boolean to work even if the set of features grows

abierman commented 1 week ago

This would be an NBC change taking away 'not' keyword. Complex to determine if nodes are actually taken away or not by false if-feature.

Close: complexity: high, bc: low, importance: low