Hi -
On 12/21/2016 3:55 PM, Andy Bierman wrote:
On Wed, Dec 21, 2016 at 3:41 PM, Juergen Schoenwaelder
<[email protected]
<mailto:[email protected]>> wrote:
...
Perhaps I am blinded by the way @deprecate or __attribute__
((deprecated)) or [[deprecated]] work in various programming
languages. All these annotations do not deprecate my code, they just
cause the generation of warnings so that I get aware of the issue and
can do my homework.
There are no protocols that let you manage orphaned data nodes
without any parent. No way to represent it in XML or JSON either.
No way to specify a RESTCONF target resource that leaves out
some intermediate data nodes.
Deprecating (or obsoleting) a definition does not orphan data nodes.
Perhaps I'm blinded by the way SNMP works, but it seems to me that
a robust client will need to be able to process data corresponding
to deprecated (or obsolete) definitions. Likewise, developers
of server-side software may find themselves in situations where
supporting obsolete definitions is a commercial necessity. Things
certainly played out that way in the SNMP world. I agree with Juergen
that tool-generated warnings seem to be the correct way to go.
It seems obvious that the deprecated warning (this node may go away)
also applies to all descendant nodes. Once the node is changed from
deprecated to obsolete, all the descendant nodes are gone as well,
No, they're not *gone*. The *advisability* of implementing them has
changed, but the definitions still exist, and implementer judgement
is still needed. The change in status only means that a client is
less able to rely on the assumption that those definitions will be
supported by a given system - but there's very little that it can
rely on being implemented anyway, so it doesn't really change much
for a robust client.
so ignoring the warning because YANG says the default is current seems
unwise.
I do agree with this bit of conclusion, but sometimes after looking
at a warning and considering the larger context, ignoring the
warning *is* the right thing to do.
Randy
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
