On 22/12/2016 10:22, Martin Bjorklund wrote:
Robert Wilton <[email protected]> wrote:
On 22/12/2016 10:00, Andy Bierman wrote:
On Wed, Dec 21, 2016 at 11:49 PM, Ladislav Lhotka <[email protected]
<mailto:[email protected]>> wrote:
> On 22 Dec 2016, at 07:22, Randy Presuhn
<[email protected]
<mailto:[email protected]>> wrote:
>
> 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]>
>> <mailto:[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.
I agree that making a node deprecated or obsolete doesn't mean
that its descendants are orphaned, it just means they cannot be
current, and then "current" shouldn't be the default status for
them - also because the descendants may come from other modules
(via groupings and augments) that cannot be changed.
Even if the default status is inherited, tools can still generate
warnings. A data modeller can decide whether and where it makes
sense to have the "status" statement explicitly, but isn't forced
to do it everywhere.
NETCONF and RESTCONF have no mechanisms for accessing data other than
top-down from the top-level YANG data node to the target node.
Removing an ancestor node from the server implementation effectively
removes
the entire subtree from the implementation. (The value of the YANG
status-stmt
of the descendant nodes has nothing to do with it)
I agree that this certainly seems to be the case if a node is marked
as obsolete. It seems that it implicitly forces all child nodes to be
obsolete as well regardless of which module they were defined in.
No I don't think this is correct. If module B augment X in module A,
and X is obsolete, it does NOT mean that the augmented nodes in B are
automatically obsolete. However, in an implementation that doesn't
implement X, the augmented nodes from B are obviously also not
implemented.
I can get where you are coming from, but if you had a GUI viewer that
was looking at the combined schema tree, I think that you would to see
those descendant children nodes marked in some way to indicate that
implementations may validly not return them. Reporting them as current
when one of their parent nodes was obsolete would seem to be deceptive.
Is it that you are trying to differentiate between being explicitly
obsolete vs 'implicitly obsolete' through parentage?
Rob
/martin
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
