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

[Balazs Lengyel]

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



-- 
Balazs Lengyel   Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com 

  


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

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

[Ladislav Lhotka]

"Bogaert, Bart (Nokia - BE)"  writes:

> [ Unknown signature status ]
>> On 29 Aug 2016, at 09:17, 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).
>
> 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".

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

>
> 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
>
>> 
>> 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:m...@tail-f.com]
>> Sent: 26 August 2016 14:33
>> To: j.schoenwael...@jacobs-university.de
>> Cc: Bogaert, Bart (Nokia - BE); netmod@ietf.org
>> Subject: Re: [netmod] derived-from-or-self leads to circular import
>> 
>> Juergen Schoenwaelder  wrote:
>>> On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
>>>> Juergen Schoenwaelder  wrote:
>>>>> On Fri, Jul 29, 2016 at 12:50:13PM +, 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).
>>>>> 
>>>>> I think moving the definition of entity-physical-class into 
>>>>> 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-con

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

[Ladislav Lhotka]

> On 29 Aug 2016, at 12:42, William Lupton  wrote:
> 
> 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.

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

> 
>> On 29 Aug 2016, at 11:34, Ladislav Lhotka  wrote:
>> 
>>> On 29 Aug 2016, at 09:17, 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).
>> 
>> 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.

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




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

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

[Bogaert, Bart (Nokia - BE)]

> On 29 Aug 2016, at 09:17, 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).

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

> 
> 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:m...@tail-f.com]
> Sent: 26 August 2016 14:33
> To: j.schoenwael...@jacobs-university.de
> Cc: Bogaert, Bart (Nokia - BE); netmod@ietf.org
> Subject: Re: [netmod] derived-from-or-self leads to circular import
> 
> Juergen Schoenwaelder  wrote:
>> On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
>>> Juergen Schoenwaelder  wrote:
>>>> On Fri, Jul 29, 2016 at 12:50:13PM +, 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).
>>>> 
>>>> I think moving the definition of entity-physical-class into 
>>>> 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.
>>> 
>> 
>> 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'?
> 
> 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
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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






smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[William Lupton]

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  wrote:
> 
>> On 29 Aug 2016, at 09:17, 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).
> 
> 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.

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

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

[Ladislav Lhotka]

> On 29 Aug 2016, at 09:17, 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).

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

> 
> 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:m...@tail-f.com]
> Sent: 26 August 2016 14:33
> To: j.schoenwael...@jacobs-university.de
> Cc: Bogaert, Bart (Nokia - BE); netmod@ietf.org
> Subject: Re: [netmod] derived-from-or-self leads to circular import
> 
> Juergen Schoenwaelder  wrote:
>> On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
>>> Juergen Schoenwaelder  wrote:
>>>> On Fri, Jul 29, 2016 at 12:50:13PM +, 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).
>>>> 
>>>> I think moving the definition of entity-physical-class into
>>>> 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.
>>> 
>> 
>> 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'?
> 
> 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
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Bogaert, Bart (Nokia - BE)]

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

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: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: 29 August 2016 09:27
To: Bogaert, Bart (Nokia - BE)
Cc: Martin Bjorklund; netmod@ietf.org
Subject: Re: [netmod] derived-from-or-self leads to circular import

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

/js

On Mon, Aug 29, 2016 at 07:17:58AM +, 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).
> 
> 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:m...@tail-f.com]
> Sent: 26 August 2016 14:33
> To: j.schoenwael...@jacobs-university.de
> Cc: Bogaert, Bart (Nokia - BE); netmod@ietf.org
> Subject: Re: [netmod] derived-from-or-self leads to circular import
> 
> Juergen Schoenwaelder  wrote:
> > On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  wrote:
> > > > On Fri, Jul 29, 2016 at 12:50:13PM +, 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).
> > > > 
> > > > I think moving the definition of entity-physical-class into 
> > > > 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.
> > >
> > 
> > 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 peo

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

[Juergen Schoenwaelder]

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

/js

On Mon, Aug 29, 2016 at 07:17:58AM +, 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).
> 
> 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:m...@tail-f.com] 
> Sent: 26 August 2016 14:33
> To: j.schoenwael...@jacobs-university.de
> Cc: Bogaert, Bart (Nokia - BE); netmod@ietf.org
> Subject: Re: [netmod] derived-from-or-self leads to circular import
> 
> Juergen Schoenwaelder  wrote:
> > On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  wrote:
> > > > On Fri, Jul 29, 2016 at 12:50:13PM +, 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).
> > > > 
> > > > I think moving the definition of entity-physical-class into 
> > > > 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.
> > >
> > 
> > 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'?
> 
> 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



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

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

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

[Bogaert, Bart (Nokia - BE)]

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:m...@tail-f.com] 
Sent: 26 August 2016 14:33
To: j.schoenwael...@jacobs-university.de
Cc: Bogaert, Bart (Nokia - BE); netmod@ietf.org
Subject: Re: [netmod] derived-from-or-self leads to circular import

Juergen Schoenwaelder  wrote:
> On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Fri, Jul 29, 2016 at 12:50:13PM +, 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).
> > > 
> > > I think moving the definition of entity-physical-class into 
> > > 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.
> >
> 
> 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'?

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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Mahesh Jethanandani]

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  wrote:
> 
> Juergen Schoenwaelder  > wrote:
>> On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
>>> Juergen Schoenwaelder  wrote:
 On Fri, Jul 29, 2016 at 12:50:13PM +, 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).
 
 I think moving the definition of entity-physical-class into
 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.
>>> 
>> 
>> 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'?
> 
> 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
> 
> ___
> 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] derived-from-or-self leads to circular import

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Fri, Jul 29, 2016 at 12:50:13PM +, 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).
> > > 
> > > I think moving the definition of entity-physical-class into
> > > 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.
> >
> 
> 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'?

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

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

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

[Juergen Schoenwaelder]

On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Fri, Jul 29, 2016 at 12:50:13PM +, 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).
> > 
> > I think moving the definition of entity-physical-class into
> > 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.
>

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 

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

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

[Martin Bjorklund]

Juergen Schoenwaelder  wrote:
> On Fri, Jul 29, 2016 at 12:50:13PM +, 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).
> 
> I think moving the definition of entity-physical-class into
> 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
> 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.

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

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

[Rob Shakir]

> On Jul 29, 2016, at 07:32, Juergen Schoenwaelder 
>  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.___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Bogaert, Bart (Nokia - BE)]

Thanks.

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

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: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
Sent: 29 July 2016 15:33
To: Bogaert, Bart (Nokia - BE)
Cc: netmod@ietf.org
Subject: Re: [netmod] derived-from-or-self leads to circular import

On Fri, Jul 29, 2016 at 12:50:13PM +, 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).

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


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Juergen Schoenwaelder]

On Fri, Jul 29, 2016 at 12:50:13PM +, 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).

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 

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