Re: [netmod] Deviating in circles

[Mahesh Jethanandani]

Hi Jan,

See inline

> On Mar 4, 2024, at 11:26 AM, Jan Lindblad (jlindbla) 
>  wrote:
> 
> 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?
>> 
>>  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.
>> 
>>  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.
> 

Please continue to have the discussion here, but suggest you create a new issue 
here , so the issue can be 
tracked.

Cheers.


> Best Regards,
> /jan
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


Mahesh Jethanandani
mjethanand...@gmail.com






___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Deviating in circles

[Jan Lindblad (jlindbla)]

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?

 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.

 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Deviating in circles

[Jason Sterne (Nokia)]

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  On Behalf Of Reshad Rahman
Sent: Wednesday, February 28, 2024 9:47 AM
To: netmod ; Jan Lindblad (jlindbla) 

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) 
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?

 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.

 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/tolerat

Re: [netmod] Deviating in circles

[Reshad Rahman]

 Hi Jan,
Does the same question arise with augments?
Inline.

On Tuesday, February 27, 2024, 03:39:37 AM EST, Jan Lindblad (jlindbla) 
 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?
 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.
 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
https://www.ietf.org/mailman/listinfo/netmod
  ___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Deviating in circles

[Jan Lindblad (jlindbla)]

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?

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.

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
https://www.ietf.org/mailman/listinfo/netmod