I would support the idea of dropping the “no circular imports” rule. It can lead to gymnastics in sets of modules that are probably unnecessary (i.e. having to rearrange definitions, re-layer things, etc simply to avoid violating that rule). It isn’t that hard for compilers/tools to detect that a module is already imported.
Somewhat related to this is the fact that pyang was never updated for the full YANG 1.1 submodule scoping rules (i.e. all submodules have access to all definitions in all other submodules). So the combination of that missing support and the circular import rule leads to a bunch of scenarios where parts of a module set don’t easily just have access to definitions from other parts that they need (without major restructuring of the schema amongst modules, augmentations, etc). Jason From: netmod <netmod-boun...@ietf.org> On Behalf Of Reshad Rahman Sent: Wednesday, February 28, 2024 9:47 AM To: netmod <netmod@ietf.org>; Jan Lindblad (jlindbla) <jlindbla=40cisco....@dmarc.ietf.org> Subject: Re: [netmod] Deviating in circles You don't often get email from reshad=40yahoo....@dmarc.ietf.org<mailto:reshad=40yahoo....@dmarc.ietf.org>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information. Hi Jan, Does the same question arise with augments? Inline. On Tuesday, February 27, 2024, 03:39:37 AM EST, Jan Lindblad (jlindbla) <jlindbla=40cisco....@dmarc.ietf.org<mailto:jlindbla=40cisco....@dmarc.ietf.org>> wrote: Dear NETMODers, I'm on site at the annual EANTC interop-event in Berlin, and came across an interesting case relating to import and deviations that I'd like the views of the list on. According to RFC 7950: There MUST NOT be any circular chains of imports. For example, if module "a" imports module "b", "b" cannot import "a". This is clear and I believe most people find this reasonable enough. With this rule in mind, I can make two modules a and b, where a imports b. Module b does not and cannot import a. module a { yang-version 1.1; namespace "http://example.com/ns/a"; prefix a; import b { prefix b; } typedef A { type uint32; } leaf aa { type A; } leaf ab { type b:B; } } module b { yang-version 1.1; namespace "http://example.com/ns/b"; prefix b; typedef B { type uint32; } leaf bb { type B; } } Now let's add a deviation in a separate module d. The deviation module can import both a and b (since neither a or b imports d), and it changes the structure so that module b now refers to a type in module a. module d { yang-version 1.1; namespace "http://example.com/ns/d"; prefix d; import a { prefix a; } import b { prefix b; } deviation /b:bb { deviate replace { type a:A; } } } As far as I can tell, this follows all the explicit YANG rules regarding deviations and imports. Still, it would not have been possible to create this YANG structure without a deviation. Module b cannot refer to types or objects in module a without an outside intervention. 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? Regards, Reshad. As a side note, recent versions of the OpenConfig model have fallen into this YANG-module reference trap. Some OC modules violate RFC 7950 rules because their authors were not able to plan ahead and divide their modules properly into layers. They have skipped importing modules that they are using because their compiler errors out if they do the import, but the compiler they use misses/tolerates the illegal reference without the needed import. If modules could mutually import each other, this problem would be easily solved. Several major vendors of YANG-based servers have navigated around this problem by essentially using a single module (namespace) for most of their functionality. Then there are no restrictions for what part of the model can reference what else, but everything ends up in a single (rather huge) namespace. Thoughts? Best Regards, /jan _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod