Hi Jan,
Does the same question arise with augments?
Inline.
On Tuesday, February 27, 2024, 03:39:37 AM EST, Jan Lindblad (jlindbla)
<[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
