Subject: [yang-doctors] Conditional import -possible ?

From: Balazs Lengyel <[email-masked]>
Date: Mon, 6 Feb 2017 12:50:24 +0100

Hello,
I have two modules:

module modA{
    prefix modA;
    
    leaf leafA {}
}

module modB {
    import modA;

    feature modA-support{}

    leaf refToA {
       if-feature modA-support;
       type leafref { path /modA:leafA ; }
} }

What I would like to achieve is that IF  my YANG server supports module 
modA then modB should have a strongly typed reference to a specific node 
in modA. If modA is not supported as indicated by a feature, then I 
don't want that reference. The if-feature on the leaf works fine, 
however I can not put an if-feature on the import, so even if my 
YANG-server does not support modA it must use it during checking and 
possibly SW build.

What is the reason that import can not have an if-feature substatement?

Is there another way to achieve this effect?

regards Balazs

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Feb 2017 12:55:05 +0100

On Mon, Feb 06, 2017 at 12:50:24PM +0100, Balazs Lengyel wrote:
> What I would like to achieve is that IF  my YANG server supports module modA
> then modB should have a strongly typed reference to a specific node in modA.
> If modA is not supported as indicated by a feature, then I don't want that
> reference. The if-feature on the leaf works fine, however I can not put an
> if-feature on the import, so even if my YANG-server does not support modA it
> must use it during checking and possibly SW build.
>

Is this not a tooling issue? A tool could determine that the import is
not used if feature modA-support is not enabled since there is nothing
left referencing modA.

/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: Ladislav Lhotka <[email-masked]>
Date: Mon, 06 Feb 2017 14:18:26 +0100

> Is there another way to achieve this effect?

 I'd say the server should in this case include modA in YANG library with
 conformance-type "import" - the import in modB should then work and modA
 needn't be implemented.

 Lada

> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors

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

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 6 Feb 2017 14:44:48 +0100

Sorry, but adding a module to a product that we explicitly do not 
support it is misleading, even if it is for import only. People will 
start asking questions: if you don't support it why is it there? People 
responsible for product packaging in my company already rejected that.

You can do hacks like creating a dummy modA, but they are hacks.

regards Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 6 Feb 2017 15:16:48 +0100

> On 6 Feb 2017, at 14:44, Balazs Lengyel <[email-masked]> wrote:
> 
> Sorry, but adding a module to a product that we explicitly do not support it is misleading, even if it is for import only. People will start asking questions: if you don't support it why is it there? People responsible for product packaging in my company already rejected that.

It is somewhat unfortunate that the "import" is overloaded with several different functions. What is needed here is just a mapping of a namespace prefix to a module name - no import is involved. Leafref paths could have been defined to use module names instead of prefixes and then no import would be needed.

Clever tools could probably figure this out, as Juergen suggests, although RFC 7950 says in sec. 6.4:

The XPath expressions MUST be syntactically correct, and all prefixes used MUST be present in the XPath context.

Lada

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 6 Feb 2017 16:36:17 +0100

I agree that clever tools could and SHOULD ignore unused imports, but 
will they? Will you ever modify PYANG ? Will my unnamed SW provider 
modify xxx? (Was that a rethorical question, maybe)

regards Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 6 Feb 2017 16:50:09 +0100

> On 6 Feb 2017, at 16:36, Balazs Lengyel <[email-masked]> wrote:
> 
> I agree that clever tools could and SHOULD ignore unused imports, but will they? Will you ever modify PYANG ? Will my unnamed SW provider modify xxx? (Was that a rethorical question, maybe)
> 

I share your concern, in fact the import *is* used in modB. There is no indication in 7950 that contents of statements that happen to be disabled via "if-feature" can be syntactically incorrect.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Feb 2017 17:19:00 +0100

> I share your concern, in fact the import *is* used in modB. There is no indication in 7950 that contents of statements that happen to be disabled via "if-feature" can be syntactically incorrect.

Perhaps there is confusion between _parsing_ and _implementing_:

 - To _parse_ modB, you need to be able to resolve import modA since
   there is YANG syntax that only makes sense if information from modA
   is available. It should not matter to a generic parser whether
   certain features are enabled or not.

 - To _implement_ modB without the features that require modA, you are
   fine to do so without implementing modA. (In this case, the import of
   modA starts to look like an unused import.)

What exactly is the problem with this?

/js

PS: If we allow if-feature on import statements, someone would have to
    code YANG parsers to enable them to validate conditional imports
    for any possible combination of features to ensure that the
    imports work out in all possible cases.

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 6 Feb 2017 17:43:33 +0100

If I have a product that does not support modA (actually does not even 
want to know it exists), as I understand the product still has to

- have the modA yang module available to run PYANG     - bad, but acceptable
- have the modA on the network node / yang-server itself, to be able to 
run my YANG/Netconf SW stack, which will result in the unsupported modA 
showing up in ietf-netconf-monitoring and ietf-yang-library (although 
only as an import).     - not acceptable

So while this maybe a question best solved by tooling, if you can think 
about any other design pattern to achieve this more cleanly I would be 
grateful

regards Balazs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Feb 2017 17:58:40 +0100

> - have the modA on the network node / yang-server itself, to be able to run
> my YANG/Netconf SW stack, which will result in the unsupported modA showing
> up in ietf-netconf-monitoring and ietf-yang-library (although only as an
> import).     - not acceptable

Balasz,

even if we would make the import of modA 'if-feature conditional', you
would still have to list modA for import in the YANG library since a
client's YANG parser still needs modA to do its work. There is nothing
in the YANG specifications that says you can conditionally parse a
module and skip over YANG definitions if you believe a certain feature
does not matter.

Perhaps a proper explanation for your customers what 'for import'
means in ietf-netconf-monitoring and ietf-yang-library is the
solution. The other alternative is to talk to the module author to
split the module into smaller pieces.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 6 Feb 2017 17:58:46 +0100

> On 6 Feb 2017, at 17:43, Balazs Lengyel <[email-masked]> wrote:
> 
> If I have a product that does not support modA (actually does not even want to know it exists), as I understand the product still has to
> 
> - have the modA on the network node / yang-server itself, to be able to run my YANG/Netconf SW stack, which will result in the unsupported modA showing up in ietf-netconf-monitoring and ietf-yang-library (although only as an import).     - not acceptable

It depends on implementation but, strictly speaking, it is not necessary that modA be present on the server. It should suffice to include it in YANG library, as I suggested. It is then up to the client to get modA if needed. I don't think it is a big problem.

In YANG 1.0 it wasn't even clear whether modules that are imported but not implemented have to be included in hello.

Lada

> 
> So while this maybe a question best solved by tooling, if you can think about any other design pattern to achieve this more cleanly I would be grateful
> 
> regards Balazs
> 
> 
>

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 6 Feb 2017 18:13:25 +0100

Thanks, for the help.

My ideal solution would be to have if-feature on imports,
and for the tools not check anything that is excluded by if-feature;
as if it was not even there.

My practical solution will probably be to refactor the modules and
move such conditional imports and references into separate modules
that will augment in whatever is needed.
This way if I don't need modA, I will just remove both modA and
modB-refAugmenter.
Nice for the customer, somewhat ugly for the designer.

module modA {
     prefix modA;
          leaf leafA {}
}

module modB {

    container base {
	...
    }
}

module modB-refAugmenter {
    import modA;
    import modB;

    augment /modB:base {
     leaf refToA {

regards Balazs