Reshad, Does the same question arise with augments?
No, I don't think so. Augments cannot modify existing namespaces, only add content in their own namespace, then graft that namespace onto some existing module. If that existing module imports the augmenting module, I would imagine all YANG compilers would catch the attempt to create an import loop. Inline. ... Is the construct in module d legal? RFC 7950 is not very clear on the subject, but it does say: After applying all deviations announced by a server, in any order, the resulting data model MUST still be valid. If "applying" means actually replacing the original module text with the deviated text, then I'm fairly sure module d would violate the rule against circular imports. If "applying" is something that happens on a more "global" or "logical" level, then maybe this should be allowed? <RR> I don't know what was the intention of the 7950 authors and not even sure what would be the "right thing". My guess would be it's more in the "logical" level. By allowing deviations of this kind, we might create a temptation for people to use deviations for their own modules in order to create YANG structures otherwise not possible. I find this problematic, since I don't like deviations much. On the other hand, allowing deviations of this kind increases the freedom of expression in the YANG world. I think many would regard a moratorium as another YANG CLR (crappy little rule). If we were to decide that this sort of deviation is allowed, wouldn't a logical conclusion be that we should drop the circular imports rule? Compilers could very well track which modules have already been imported (like in python), and not go into unbounded spin just because there is a circular reference loop. <RR> yang-next? We could of course clarify this or change the rules in yang-next once we know what we want (I'm split on this one), but I was interested in the opinion of the list whether this is allowed today. Best Regards, /jan
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
