Subject: [netmod] if-feature

From: Andy Bierman <[email-masked]>
Date: Tue, 02 Dec 2008 12:12:37 -0800

Hi,

I've been waiting for others to implement this, so I can let
them ask these questions, but too late...

pg 97, last para in 7.18.1:

    The "if-feature" statement can be used in many places within the YANG
    syntax.  Definitions tagged with "if-feature" are ignored when the
    device does not support that feature.

We need a much more precise definition of 'ignored'.
The portion of the data model tagged conditional is
not ignored within all the compile-time YANG validation.
In fact, if-feature is ignored then because the compiler
cannot know which features will be enables at runtime.

pg 98, sec. 7.18.2

This section looks rather cut-and-pasted.
It never actually mentions what it means for a feature
to exist only if these other features exist.  It does
not mean what the text says, but rather is intended to
indicate the dependencies for a feature.

    feature foo;

    feature bar {
      if-feature foo;
    }

Since feature 'bar' does not actually exist anywhere
except a tiny substring within a capability URI,
the draft needs to specify what this construct means.
I assume it means "an implementation MUST support 'foo'
if it supports 'bar'.

You also need the same 'anti-loop text' here as for identity.

    feature foo {
      if-feature baz;
    }

    feature bar {
      if-feature foo;
    }

    feature baz {
      if-feature bar;
    }

Is this sort of loop legal or not?

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 02 Dec 2008 21:31:29 +0100 (CET)

> We need a much more precise definition of 'ignored'.

Ok.  What we want to say is that if the device does not the feature,
it behaves as if the definition (which was tagged with if-feature) was
not there at all.

> cannot know which features will be enables at runtime.

This is an implementation detail.  Some compilers might require the
feature list at compile time, and others at run time.

> not mean what the text says

I don't understand which text you refer to?

>, but rather is intended to

Yes.  This follows from the fact that if the device does not implement
'foo', then the 'feature bar' statement is ignored.

> You also need the same 'anti-loop text' here as for identity.

Yep, I added it just after publishing -02 ;-)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 02 Dec 2008 16:50:33 -0800

> feature list at compile time, and others at run time.

This needs to be specified in the draft, which way it works.
I do not agree that the feature list should be given at compile-time.
For only 4 features, a developer would need to compile the same file
16 times to check all the combinations.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 03 Dec 2008 08:36:34 +0100 (CET)

> 16 times to check all the combinations.

Sorry, I misunderstood what you meant.  A decent YANG validator should
of course not require the designer to run the thing 16 times.  But a
code generator might generate code for just the features supported on
the box, as specified by the developer at compile/implementation time.

/martin