I think that it should be a error to have a current node under a
deprecated node in the same module, and similarly for
deprecated/obsolete. I.e. to be consistent with the following text from
7950 sec 7.21.2:
'If a definition is "current", it MUST NOT reference a "deprecated"
or"obsolete" definition within the same module.'
I agree that it is useful if tools generate warnings if a module
augments (or references) a deprecated or obsolete node (as per Juergen's
comments below).
I don't have an issue with explicitly marking the child nodes as
deprecated/obsolete, but intuitively I would have expected this to
inherit like the config statement.
Rob
On 20/12/2016 20:15, Juergen Schoenwaelder wrote:
On Tue, Dec 20, 2016 at 09:03:35PM +0100, Martin Bjorklund wrote:
However, we could have said that a current node under a deprecated
node (etc) in the same module is an error, in order to force people
(through the useage of YANG validators) to detect and fix this.
Is it an error or just something that deserves a warning and the
author's attention? I am asking since we also have augmentations and
if I mark a container as deprecated, this will not immediately cause
an module augmenting the containter to get updated, hence I end up
with definitions marked current in a deprecated container. And there
are other situations where definitions may not be of the same status,
i.e., a module (without import by revision) uses a type or grouping
that in later revisions got marked deprecated. I think all of these
status mismatches are things tools should warn about but I am not sure
these are hard errors, in particular for 'deprecated'. Things may lead
to stronger warnings for definitions marked 'obsolete'.
/js
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
