On 22/12/2016 10:49, Martin Bjorklund wrote:
Robert Wilton <[email protected]> wrote:
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?
I think that within a module, if a parent is obsolete, then all its
child should also be obsolete (*). But I do think that the status
should be explicitly stated.
OK. I assume that this statement applies to deprecated as well. I
don't feel particularly strongly on this point. If you mark something
as obsolete/deprecated, then explicitly having to find and mark all
references/children doesn't seem like a bad thing because it makes the
full impact obvious (if pyang is enhanced to check for this).
But marking definition as obsolete in one module cannot automatically
make definitions in *other* modules obsolete.
I'm not so sure.
It seems to me that in practice, they are directly equivalent as if they
were marked as obsolete. I.e. clients cannot rely on them being
available because the obsolete parent may not be implemented.
If the augmenting module wants to keep those nodes, then their only
choice seems to be to explicitly mark them as obsolete, and make a copy
of the nodes augmenting somewhere else in the schema tree.
(*) _maybe_ 7950 can be interpreted in this way when it says:
If a definition is "current", it MUST NOT reference a "deprecated" or
"obsolete" definition within the same module
If you're in a good mood, you could argue that a child always
"references" its parent.
Would it not be better to add some sort of explicit statement as an
errata to 7950 (once there is agreement on what it should say)? Or is
this beyond the scope of what an errata is allowed to do?
Rob
/martin
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
