search

netmod-wg / yang-next

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

Clarify YANG "status" keyword usage (e.g., hierarchical) #27

Open rgwilton opened 7 years ago

rgwilton commented 7 years ago
  1. Should YANG status be hierarchical? Or should every node is marked as deprecated for clarity?
  2. Are you allowed to have a "current" node below a "deprecated" node? Or a "current" or "obsolete" node below a "deprecated" node?
  3. What about references to a "deprecated" or "obsolete" node in the same or different module?
  4. What about groupings and "uses" statements, since refine doesn't allow status to be modified?
  5. Should deviate be allowed to change "status"? (I think that it should be yes).
  6. How much of this should be solved via tooling?
  7. Do we need to clarify how "status obsolete" (or status deprecated if not implemented) interplays with "mandatory true"?
abierman commented 6 years ago

Also need to clarify child nodes different status than parent Following example passes 100% with pyang. Even examples from RFC are allowed

yang11-bad-status.yang.txt

abierman commented 6 years ago

RFC 7950, sec. 7.21.2 needs to be rewritten to address all issues listed above. Need to add some clarification if imported identifiers change from current to deprecated or obsolete.

BalazsLengyel commented 6 years ago

IMHO there is a hierarchy current/deprecated/obsolete.

If a parent node (in the containment hierarchy) is obsolete, all child nodes are effectively obsolete even if they have a status current statement. If a container is not implemented because its obsolete there is no way to implement a contained "current" leaf .

If a parent node (in the containment hierarchy) is deprecated all child nodes are effectively either deprecated or obsolete. If I tell you that a container is deprecated meaning it might be obsolete soon thus its implementation will be removed, that also means that any contained leaf's implementation will also be removed at the same time. So current is not feasible for any child objects.

mbj4668 commented 6 years ago

I agree that this should be clarified.

llhotka commented 5 years ago

I would also suggest to align the definitions of the status terms with IANA, see my message.

rgwilton commented 5 years ago

Example of interplay between status and mandatory:

On Wed, Feb 27, 2019 at 01:08:49PM +0000, Balázs Lengyel wrote:

leaf myTimer { mandatory true; config true; status obsolete; type string; }

So should I configure myTimer or not? Today whatever I do, it might come back with an error. IMHO YANG should make it possible to write a correct config.

I know this is not the most important point for semver, so we might skip it, but it is not correct. Maybe keep it as an open issue.

regards Balazs

BalazsLengyel commented 5 years ago

A slightly different problem for Example of interplay between status and mandatory feature oldFeature { status obsolete; }

leaf myTimer { if-feature oldFeature ; mandatory true; config true; status current; type string; }

So should I configure myTimer or not? Here the question is: What does it mean if a feature is obsolete? If a feature is obsolete what does that mean for nodes controlled by that feature? Does it mean that these nodes are also obsolete? Considering that myTimer can be controlled by multiple features there might not be a simple algorithmic answer. Maybe we should state that the designer must explicitly change the model to indicate the result.

BalazsLengyel commented 5 years ago

If a grouping is deprecated does it mean that all the nodes created by using the grouping are also deprecated? What does it mean it is deprecated?

Yes because the grouping is deprecated. No because even if the grouping is deprecated (it is not recommended for reuse), the leafs created with it are still usable and there are no plans to remove them.

Same question for obsolete. Same question for typedef.

mbj4668 commented 5 years ago

So should I configure myTimer or not?

If the server advertises 'oldFeature' then you must configure 'myTimer'.

Here the question is: What does it mean if a feature is obsolete? If a feature is obsolete what does that mean for nodes controlled by that feature? Does it mean that these nodes are also obsolete?

No.

Considering that myTimer can be controlled by multiple features there might not be a simple algorithmic answer. Maybe we should state that the designer must explicitly change the model to indicate the result.

Right; this is an argument for explicit status statements.

mbj4668 commented 5 years ago

If a grouping is deprecated does it mean that all the nodes created by using the grouping are also deprecated?

No

What does it mean it is deprecated?

It means that new models should not use that grouping.

Yes because the grouping is deprecated. No because even if the grouping is deprecated (it is not recommended for reuse), the leafs created with it are still usable and there are no plans to remove them.

Same question for obsolete.

Maybe we should say that if a defintiion is obsolete in revision X, and the server advertises X, then it must not implement the obsolete definitions. I.e., obsolete would work exactly as if the definition has been removed. (Maybe it can even be removed in revision X+1)

Same question for typedef.

Same answer.