> On 21 Dec 2016, at 14:47, Robert Wilton <[email protected]> wrote: > > 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.
+1 If everybody agrees that "current" under "deprecated"/"obsolete" is an error, then "current" shouldn't be the default in such situations. Lada > > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
