> On 29 Aug 2016, at 09:17, Bogaert, Bart (Nokia - BE) <bart.boga...@nokia.com> 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 <j.schoenwael...@jacobs-university.de> wrote: >> On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote: >>> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> 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). >>>> >>>> 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
