I would prefer if it status was inherited (as an errata to 6020, 7950).
It seems that when it comes to implementation that is what is going to
happen regardless. If a server chooses to not support a deprecated
node then any children nodes will also not be supported. Hence,
regardless of what the YANG module states, their real status is that
they are deprecated since they won't necessarily be present in all
servers that implement the module.
However, I do get Juergen's point about clarity. Given the lengthy
regex discussion, I suspect others may not agree, but this part could
potentially be solved via YANG Author Guidelines. I.e. something
roughly along the lines of "If a node is marked as deprecated/obsolete
in a YANG module then all descendant nodes SHOULD also be explicitly
marked as deprecated/obsolete".
Thanks,
Rob
On 06/09/2017 07:57, Juergen Schoenwaelder wrote:
On Wed, Sep 06, 2017 at 01:47:57AM +0000, heasley wrote:
Isn't this something that is fixed with display (human representation)
tools?
I often work with the original definitions. And if the original
definitions depend on context, I have to do another lookup (whether
this is inside the original definition or some tool generated human
representation does not matter). With the old /foo and /foo-state
approach this was really bad since you had often objects with the same
name and it was often not at all clear whether I have been looking at
the config true or the config false definition without an additional
search operation. Perhaps I could program my favourite editor to
generate explicit config statements and status statements on the fly
but I think we would be better off if readers would not have to
program editors or use special tools to easily understand what a
definition really means.
I still don't know what it means to define hierarchical data and say the
parent is deprecated but not the descendant nodes.
It is odd but can happen anyway. A current augmentation of something
that got deprecated likely stays current. I would hope that tools warn
if they see this but that's it.
How is anything ever expunged if parsing tools do not refuse to load
a module that depends on a deprecated node that it is attempting to
augment?
Expunged? Deprecating a definition does not expunge anything. Tools
that refuse to load a module that depends on deprecated nodes are in
my view broken. It was one of YANG's design goals to support
augmentations such that definitions and be augmented by independent
organizations. Hence, we must face reality that it is impossible to
determine how many augmentations of a definition are out there and
hence it is impossible to have them all updated at the same time.
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
