Re: [netmod] 'status' statement needed on every node

[Robert Wilton <[e-mail]>]

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
>