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 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
