Subject: Re: [netmod] derived-from-or-self leads to circular import

From: Rob Shakir <[email-masked]>
Date: Mon, 1 Aug 2016 22:26:22 -0600

> On Jul 29, 2016, at 07:32, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> I think moving the definition of entity-physical-class into
> iana-entity makes sense. Perhaps this is generally a good pattern to
> follow for base identities for which IANA maintains derived
> identities.  The required import should not be a problem; the
> ENTITY-MIB also imports from IANA-ENTITY-MIB.

I would be supportive of changes that make IANA maintained registries self-contained. It seems to me that this would reduce overall overlap between modules.

For example, right now, iana-if-type uses ietf-interfaces to define interface-type. This means that third-party modules cannot exploit the IANA registry without also including the IETF module. This does not seem ideal if one simply wants to ensure that the registry can be used.

r.

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 26 Aug 2016 12:43:04 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> On Fri, Jul 29, 2016 at 12:50:13PM +0000, Bogaert, Bart (Nokia - BE) wrote:
> 
> [...]
>  
> > In order to correctly compile (using confdc) we also need to import
> > iana-entity for the identities defined in there.  However this is leading a
> > circular dependency:
> > 
> > 1.       Iana-entity imports ietf-entity (to 'resolve'
> > entity-physical-class)
> > 
> > 2.       Ietf-entity imports iana-entity (to obtain the indentities defined
> > in there)
> > 
> > One way to solve this is to move the definition of entity-physical-class
> > from ietf-entity to iana-entity which would resolve the fact that
> > iana-entity requires an import of ietf-entity (ietf-entity needs to import
> > iana-entity anyhow, so it can also pick the typedef from the same module
> > too).
> 
> iana-entity makes sense.

Ok.  It feels a bit backwards to me though, but I can see the value of
having the iana module self-contained.

/martin

> Perhaps this is generally a good pattern to

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 26 Aug 2016 14:22:29 +0200

> having the iana module self-contained.

Well, it may look backwards if people want to reuse the base identity
but none of the IANA assigned identities - but then it might be good
if people at least look at IANA assigned identities. Or are there other
reasons why you think this may be looking 'backwards'?

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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 26 Aug 2016 14:32:30 +0200 (CEST)

> reasons why you think this may be looking 'backwards'?

I makes ietf-entity dependent on iana-entity, since the base identity
is defined in iana-entity.

But OTOH, even if we solved that, ietf-entity is dependent on
iana-entity b/c of the value 'sensor'.

So in this case it is probably fine, but I'm not sure about the
general idea.

/martin

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 26 Aug 2016 14:24:45 -0700

Don’t we have something similar with iana-if-types importing ietf-interfaces? Not circular, but definitely odd.

The base identity of interface-type is defined in ietf-interfaces, but the interface-types are defined in iana-if-type.yang. For anyone, including openconfig-interfaces, wanting to use any of the interface-types has to not only import iana-if-types but ietf-interfaces also.

As a general rule, would it not be better to have the base identity and the different types of that identity in the same file?

> On Aug 26, 2016, at 5:32 AM, Martin Bjorklund <[email-masked]> wrote:
> 
> Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]>> wrote:
> _______________________________________________
> netmod mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
[email-masked]

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Mon, 29 Aug 2016 07:17:58 +0000

Just taking another approach on this: why do we have the restriction on
circular imports?  Is this really required?  If not then this may be solved
in another way too (but will take some time before it gets into the YANG
compilers I'm afraid).

Best regards - Vriendelijke groeten,
Bart Bogaert
Broadband-Access System Architect Data
Contact number +32 3 2408310 (+32 477 673952)

NOKIA
Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities Antwerp

<<
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law. If
you are not the intended recipient, you should delete this message. Any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited without the prior consent of its
author.

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: 26 August 2016 14:33
To: [email-masked]
Cc: Bogaert, Bart (Nokia - BE); [email-masked]
Subject: Re: [netmod] derived-from-or-self leads to circular import

Juergen Schoenwaelder <[email-masked]> wrote:
> > > > In order to correctly compile (using confdc) we also need to 
> > > > import iana-entity for the identities defined in there.  However 
> > > > this is leading a circular dependency:
> > > > 
> > > > One way to solve this is to move the definition of 
> > > > entity-physical-class from ietf-entity to iana-entity which 
> > > > would resolve the fact that iana-entity requires an import of 
> > > > ietf-entity (ietf-entity needs to import iana-entity anyhow, so 
> > > > it can also pick the typedef from the same module too).
> > > 
> > Ok.  It feels a bit backwards to me though, but I can see the value 
> > of having the iana module self-contained.
> >
> 
> if people at least look at IANA assigned identities. Or are there 
> other reasons why you think this may be looking 'backwards'?

I makes ietf-entity dependent on iana-entity, since the base identity is
defined in iana-entity.

But OTOH, even if we solved that, ietf-entity is dependent on iana-entity
b/c of the value 'sensor'.

So in this case it is probably fine, but I'm not sure about the general
idea.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 29 Aug 2016 09:27:00 +0200

I fail to see what this thread has to do with circular imports.

/js

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Mon, 29 Aug 2016 07:32:54 +0000

"Reorganization" of the modules as they are currently defined in IETF is
required in order to avoid the "circular import" error reported by the ConfD
compiler (e.g. confdc of TailF).  I guess that when we remove this
restriction (as far as I remember, a #include equivalent is possible in
C/C++) then at least the modules compile in its current form (that means
after correcting the calls to derived-from-or-self to having only parameters
instead of 3 as they are currently defined in the IETF modules).  I agree
that this is not related to the comment made whether re-organizing
iana-entities in such a way that it defines the identity (rather then
importing it from ietf-entity).

NOKIA

<<

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: 29 August 2016 09:27
To: Bogaert, Bart (Nokia - BE)
Cc: Martin Bjorklund; [email-masked]
Subject: Re: [netmod] derived-from-or-self leads to circular import

/js

On Mon, Aug 29, 2016 at 07:17:58AM +0000, Bogaert, Bart (Nokia - BE) wrote:
> Just taking another approach on this: why do we have the restriction 
> on circular imports?  Is this really required?  If not then this may 
> be solved in another way too (but will take some time before it gets 
> into the YANG compilers I'm afraid).
> 
> Broadband-Access System Architect Data Contact number +32 3 2408310 
> (+32 477 673952)
> 
> NOKIA
> Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE 
> 0404 621 642 Register of Legal Entities Antwerp
> 
> <<
> This message (including any attachments) contains confidential 
> information intended for a specific individual and purpose, and is 
> protected by law. If you are not the intended recipient, you should 
> delete this message. Any disclosure, copying, or distribution of this 
> message, or the taking of any action based on it, is strictly 
> prohibited without the prior consent of its author.
> >> 
> 
> 
> > > > On Fri, Jul 29, 2016 at 12:50:13PM +0000, Bogaert, Bart (Nokia - 
> > > > BE)
> wrote:
> > > > 
> > > > [...]
> > > >  
> > > > > import iana-entity for the identities defined in there.  
> > > > > However this is leading a circular dependency:
> > > > > 
> > > > > 2.       Ietf-entity imports iana-entity (to obtain the
indentities
> defined
> > > > > ietf-entity (ietf-entity needs to import iana-entity anyhow, 
> > > > > so it can also pick the typedef from the same module too).
> > > > 
> > > Ok.  It feels a bit backwards to me though, but I can see the 
> > > value of having the iana module self-contained.
> > >
> > 
> > Well, it may look backwards if people want to reuse the base 
> > identity but none of the IANA assigned identities - but then it 
> > might be good if people at least look at IANA assigned identities. 
> > Or are there other reasons why you think this may be looking
'backwards'?

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 29 Aug 2016 12:34:15 +0200

> On 29 Aug 2016, at 09:17, Bogaert, Bart (Nokia - BE) <[email-masked]> wrote:
> 

In fact, it isn't really needed. Unlike imports in programming languages such as Python, import in YANG doesn't incorporate the imported module contents, just gives access to objects in a foreign namespace.

Lada

> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: William Lupton <[email-masked]>
Date: Mon, 29 Aug 2016 11:42:03 +0100

Regardless of whether circular import is permitted, isn’t it best avoided from a layering point of view? In general I would think that a module should be importing things that (a) it needs, and (b) don’t need it. W.

> On 29 Aug 2016, at 11:34, Ladislav Lhotka <[email-masked]> wrote:
>

---

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Mon, 29 Aug 2016 11:07:51 +0000

> into the YANG compilers I'm afraid).

In fact, it isn't really needed. Unlike imports in programming languages
such as Python, import in YANG doesn't incorporate the imported module
contents, just gives access to objects in a foreign namespace.

[Bart Bogaert] This comes from RFC6020bis (and I guess it’s in RFC6020 too):
There MUST NOT be any circular chains of imports. For example, if
module "a" imports module "b", "b" cannot import "a".

If this restriction is not really needed then why do we have that
restriction stated as such in the RFC?  The ConfD compiler reports exactly
this failure when trying to compile the IETF entity model for YANG 1.1
(tried 6.2 Confd-basic which can be obtained freely).  iana-entity.yang
imports ietf-entity (for the entity-physical-class identity) and
ietf-entity.yang imports iana-entity for the sensor identity - well that is
after changing the ietf-entiy model to also fix the error that the
derived-from-or-self function only has 2 parameters instead of 3 as
currently in the YANG models (the call to derived-from-or-self checks the
class leaf for "ent:sensor").  Fact is that the way the IETF/IANA entity
model is now defined in YANG results in something that results in
compilation errors and we need something that compiles error-free, meaning
we have to modify the iana and ietf-entity YANG model in some way.

Bart

Lada

>>>>> entity-physical-class from ietf-entity to iana-entity which would 
>>>>> resolve the fact that iana-entity requires an import of 
>>>>> ietf-entity (ietf-entity needs to import iana-entity anyhow, so it 
>>>>> can also pick the typedef from the same module too).
>>>>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 29 Aug 2016 13:08:16 +0200

> On 29 Aug 2016, at 12:42, William Lupton <[email-masked]> wrote:
> 

If possible, yes. However, not everything is strictly layered, sometimes it might be useful to put definitions into separate modules even if they are coupled in both directions.

Where cyclic references would be really harmful (groupings, identities), YANG spec excludes them explicitly - because they are harmful within the same module, too.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 30 Aug 2016 12:38:27 +0200

"Bogaert, Bart (Nokia - BE)" <[email-masked]> writes:

> [ Unknown signature status ]
> [Bart Bogaert] This comes from RFC6020bis (and I guess its in RFC6020 too):

Yes, but it's way too late to change this in 6020bis. We could consider
removing this restriction in the next revision of YANG.

Lada

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 31 Aug 2016 10:02:05 +0200

Hello Bart,

A nice solution could be to separate ietf-entity into 2 yang
modules (YAMs). One handling only generic entity stuff and another
handling sensor related stuff. If  ietf-entity does not include
any entity-type specific stuff it does not need to import
iana-entity any more. This is how it works with ietf-interfaces
and iana-if-type. Ietf-interfaces does not include anything that
is if-type specific. Problem solved.

regards Balazs

On 2016-07-29 14:50, Bogaert, Bart
(Nokia - BE) wrote:

Hi,

The IETF draft entity model has added the
following:

container sensor-data {

when 'derived-from-or-self(../class,

"iana-entity", "sensor")' {

We already know that derived-from-or-self
actually only has 2 parameters so it is expected to become

container sensor-data {

when 'derived-from-or-self(../class,

"iana-entity:sensor")' {

In order to correctly compile (using
confdc) we also need to import iana-entity for the identities
defined in there.  However this is leading a circular
dependency:

1.       Iana-entity
imports ietf-entity (to ‘resolve’ entity-physical-class)

2.       Ietf-entity
imports iana-entity (to obtain the indentities defined in
there)

One way to solve this is to move the
definition of entity-physical-class from ietf-entity to
iana-entity which would resolve the fact that iana-entity
requires an import of ietf-entity (ietf-entity needs to import
iana-entity anyhow, so it can also pick the typedef from the
same module too).

Whatever solution is chosen, the circular
import needs to be resolved (or circular imports should be
allowed – after all: what has been imported can be “tracked”
removing the need to re-import something that was already
imported).

Bart Bogaert

Broadband-Access
System Architect Data

Contact
number +32 3 2408310 (+32 477 673952)

NOKIA

Fortis 220-0002334-42

<<

This message (including any attachments) contains
confidential information intended for a specific individual
and purpose, and is protected by law. If you are not the
intended recipient, you should delete this message. Any
disclosure, copying, or distribution of this message, or the
taking of any action based on it, is strictly prohibited
without the prior consent of its author.

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]