Relax rules on usage of deprecated or obsolete identifiers
Opened this issue · 7 comments
sec 7.21.2
If a definition is "current", it MUST NOT reference a "deprecated" or
"obsolete" definition within the same module.
If a definition is "deprecated", it MUST NOT reference an "obsolete"
definition within the same module.
Issue 1) these MUST requirements make a YANG module brittle and hard to change
Issue 2) "deprecated" status should be treated as MUST implement, so "current" using "deprecated" is just a warning
Issue 3) "obsolete" status should be treated as MUST NOT implement, but it actually is SHOULD NOT implement.
Issue 4) use of "obsolete" status should be a warning not a fatal error
I agree with Issues (2) and (3) and think that those should be fixed in the next version of YANG (whatever that is), but I'm not sure about (4).
For (4), I think that it should be handled identically as if the reference was to a definition that simple does not exist. Whether this check needs to be performed when checking an individual module rather than when compiling and validating a schema-set of modules is a different question.
Issue 4 is still open
Since deprecated will mean MUST implement, any current referencing deprecated is just a warning.
IMO since obsolete still mean SHOULD NOT implement, it is also a warning
Summary of changes:
- current ref deprecated: warning
- current ref obsolete: error (no change)
- deprecated ref obsolete: warning
Regarding obsolete, Andy says here to remove it so it will cause object errors.
At least a warning should remain.
Clarifying what deprecated and obsolete mean would be good. IMHO the original SNMP derived definitions are unclear.
An error if the deprecated node is no longer supported, a warning if the deprecated node is still supported. Either case, a server may suggest a replacement (if exists).
Preference for SemVer's interpretation.
Should SerVer be rolled-into YANG-next? (Andy: yes, already said elsewhere)