On Thu, 2017-11-16 at 12:59 +0800, Balazs Lengyel wrote: > Hello Lada, > Yes it is necessary. Just have a look at how Java uses it. It is formulated: > XXX deprecated, use YYY instead.
But the data, at the end of the day, have to correspond to what is implemented in the device. So even if an IETF WG decides to roll out a shiny new version of module X, a vendor may still want to keep the old version, possibly forever, and then the deprecated status information from the old version of X may be false alarm. It would seem more appropriate for the vendor to do this kind of signalling before a new release is coming. On the other hand, it would IMO be too much to require that a node can be removed only after being deprecated. Lada > We want to give client OSS implementers an advance warning that XXX will be > removed, they better start planing to use YYY instead. This revision is still > compatible, it still supports XXX, but the next one won't. This way for OSS > the migration from XXX to YYY is less painful. > regards Balazs > > On 2017-11-16 10:04, Ladislav Lhotka wrote: > > > 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 > > > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
