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

From: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Fri, 29 Jul 2016 12:50:13 +0000

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

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.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Jul 2016 15:32:57 +0200

On Fri, Jul 29, 2016 at 12:50:13PM +0000, Bogaert, Bart (Nokia - BE) wrote:

[...]
 
> iana-entity anyhow, so it can also pick the typedef from the same module

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.

/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: "Bogaert, Bart (Nokia - BE)" <[email-masked]>
Date: Fri, 29 Jul 2016 13:47:26 +0000

Thanks.

Guess this need to be brought to IETF level as this requires an update of
the 'base IETF' YANG modules?

NOKIA

<<

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: 29 July 2016 15:33
To: Bogaert, Bart (Nokia - BE)
Cc: [email-masked]
Subject: Re: [netmod] derived-from-or-self leads to circular 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).

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.

/js