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 > > > new 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 > > > > > > > /martin > > > > > > > > > > regards Balazs > > > > > > > > > On 2017-11-15 16:53, Martin Bjorklund wrote: > > > > Exactly. With the current solution, the sever can still implement the > > > > deprecated or obsolete nodes in order to support old clients. > > > > > > > > With a MAJOR update in a semver world, it means that the old nodes are > > > > removed (or rather, possibly, that the old nodes have new syntax > > > > and/or semantics). > > > > > > > > > > > > > > > > > > -- > > > 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 > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
