|
On 2017-11-15 21:20, Martin Bjorklund
wrote:
BALAZS: Actually this exactly one of my problems. See other letter for my 3 problems. This is one cause of 2)Ladislav Lhotka <[email protected]> wrote:On Wed, 2017-11-15 at 12:17 +0100, Martin Bjorklund wrote:Balazs Lengyel <[email protected]> wrote:The server MAY implement obsoleted nodes or MAY NOT. This may or may not is not good enough as a contract for the management client. My problem is that the current solution is just not good enough. IMHO we need to change it.Note that if a server implements version 1 of a module, and then the module doesn't change, but the server in the next sw version drops support for the module, the client will also be unhappy. We (the IETF) can't have rules for these kinds of things.If the server drops support for a module, then that module has to disappear from YANG library, so it is a priori known that it happened. With deprecated/obsolete nodes, a server may drop their support without any notice, within the same module&revision.I agree that *that* is a problem, but that's not what Balazs asked about./martin BALAZS: You still need at leaast deprecated: my proposalnew stuff with a new name, although that might not be the common practice. Which is a good thing, as I believe it is sometimes better to correct existing definitions then to replace them.But you still want to require servers to implement even obsolete nodes?I think with semver support there will be no need for the "status" statement - the nodes just get removed and version number bumped. Lada o "deprecated" schema nodes MUST still work as defined by the YANG module.
The deprecated status serves only as a a warning that the schema node
will be removed or obsoleted in the future."
-- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: [email protected] |
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
