Balazs Lengyel <[email protected]> writes: > On 2017-11-15 21:20, Martin Bjorklund wrote: > > 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: Actually this exactly one of my problems. See other letter for > my 3 problems. This is one cause of 2)
Thank you, Balazs, I was getting confused. ;-) > > > > 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 > > BALAZS: You still need at leaast deprecated: my proposal > 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." But is this really necessary? As long as the new (incompatible) version doesn't get pulled in automatically, implementors needn't care too much. And if they decide to upgrade to the new version, they have to check the differences anyway - as you said, they may not be in the schema. Lada > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: [email protected] -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 -------------------- End of forwarded message -------------------- -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
