Subject: [netmod] Issue Y01: allow boolean if-feature

From: Andy Bierman <[email-masked]>
Date: Mon, 7 Apr 2014 16:02:19 -0700

Hi,

I think the proposed solution for this issue will lead to
too much cut-and-paste text.

I propose that new statements be used instead called
"feature-set" and "if-feature-set".

   feature foo;

   feature-set foo "expr";
      ... expr == some new syntax to define the boolean expression,
      ... like the 'expr' in the current solution.
      ... no nested feature-sets; only feature boolean logic.
   }

The feature-set-stmt would be ANDed with all the if-feature-smts.
The feature-set namespace would be new in YANG 1.1:

  leaf X {
     if-feature "foo";
     if-feature-set "foo";
     type int32;
  }

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Apr 2014 07:59:09 +0200

Andy, can you explain why the proposed text leads to "too much
cut-and-paste text" and why the new proposed statements does not
show this effect?

/js

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

-- 
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: Andy Bierman <[email-masked]>
Date: Mon, 7 Apr 2014 23:10:44 -0700

> cut-and-paste text" and why the new proposed statements does not
If complex combinations are used then the same complex expression has to be
repeated everywhere
the same set of conditions applies.

  if-feature-set foo {
      expr "if-feature X or if-feature Y or if-feature Z and if-feature W
or if-feature A or if-feature B or if-feature C";
  }

  leaf A {
     if-feature-set foo;
   }

If the same feature set applies to 100 leafs then the long expression will
be repeated 100 times.

/js
Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Apr 2014 08:22:31 +0200

Thanks. So your proposal is about introducing named feature
expressions. I did not see that initially.

But would this not be the same as:

  feature foo {
    if-feature X or if-feature Y or if-feature Z and if-feature W > or if-feature A or if-feature B or if-feature C;
  }

  leaf A {
    if-feature foo;
  }

That is, if we allow if-feature to take an expression, can you not
simply use the existing feature statement to give such an expression a
feature name? According to 7.18.1.1. feature can have an if-feature as
a substatement.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 08 Apr 2014 09:13:05 +0200 (CEST)

>     if-feature X or if-feature Y or if-feature Z and if-feature W > or if-feature A or if-feature B or if-feature C;

Or rather:

  feature foo {
    if-feature "X or Y or Z and W or A or B or C";
  }

?

> feature name? According to 7.18.1.1. feature can have an if-feature as

I think this works.

/martin

---

From: chong feng <[email-masked]>
Date: Tue, 8 Apr 2014 15:32:09 +0800

How about this?

feature foo {
    if-feature union {
         if-feature X;
         if-feature Y;
         if-feature Z;
    }
    if-feature union {
        if-feature W;
        if-feature A;
        if-feature B;
        if-feature C;
    }
}

2014-04-08 15:13 GMT+08:00 Martin Bjorklund <[email-masked]>:

> >     if-feature X or if-feature Y or if-feature Z and if-feature W > or
> if-feature A or if-feature B or if-feature C;
> >   }
>
> Or rather:
>
>   feature foo {

---

From: Jernej Tuljak <[email-masked]>
Date: Tue, 08 Apr 2014 09:45:49 +0200

>      if-feature "X or Y or Z and W or A or B or C";

+1

Why complicate things with named feature expressions?

Jernej

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Apr 2014 09:56:12 +0200

I do understand a boolean expression. I do not at all understand what
'union' means here and what a sequence of unions means.

/js

---

From: chong feng <[email-masked]>
Date: Tue, 8 Apr 2014 16:04:52 +0800

union means the sub statements'relation is 'OR'. Just like :
type union {
     type A;
     type B;
     type C;
}

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Apr 2014 11:14:36 +0200

I think Martin's proposal is way simpler and a logical extension of
what we have and it does not require to introduce any new keywords.

/js

---

From: chong feng <[email-masked]>
Date: Tue, 8 Apr 2014 17:41:09 +0800

martin's proposal also changed the meaning of 'if-feature', the argument
will be changed from 'feature's name' to 'logical expression'.
'union' can be treated as a special feature name, not a new keyword, just
like 'union' is 'type''s argument, not a keyword.

2014-04-08 17:14 GMT+08:00 Juergen Schoenwaelder <
[email-masked]>:

> > > > > >     if-feature X or if-feature Y or if-feature Z and if-feature
> W >
> > > or
> > > > > > simply use the existing feature statement to give such an
> expression
> > > a
> > > > > > feature name? According to 7.18.1.1. feature can have an
> if-feature
> > > as
> > > > > > a substatement.
> > > > >
> > > > > I think this works.
> > > > >
> > > > >
> > > > > /martin
> > > > >

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 8 Apr 2014 11:59:01 +0200

Yes but all 1.0 if-feature statements remain valid 1.1 if-feature
statements. There is a certain beauty to this. Compared to this,
introducing 'union' as a special feature name is ugly with not clear
benefit either.

/js

---

From: Jernej Tuljak <[email-masked]>
Date: Tue, 08 Apr 2014 11:59:20 +0200

Dne 8.4.2014 11:41, pis(e chong feng:
> martin's proposal also changed the meaning of 'if-feature', the 
> argument will be changed from 'feature's name' to 'logical expression'.
> 'union' can be treated as a special feature name, not a new keyword, 
> just like 'union' is 'type''s argument, not a keyword.
>
>

It doesn't change the meaning of if-feature any more than your own 
solution. Both require special treatment of the same keyword's argument 
syntax. With the exception of your proposal being backward incompatible. 
"union" is a valid feature identifier in 1.0...

Jernej

>
>
> 2014-04-08 17:14 GMT+08:00 Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>>:
>
>     > [email-masked]
>     <mailto:[email-masked]>>:
>     >
>     > > > 2014-04-08 15:13 GMT+08:00 Martin Bjorklund <[email-masked]
>     <mailto:[email-masked]>>:
>     > > >
>     > > > > Juergen Schoenwaelder
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > > > > >     if-feature X or if-feature Y or if-feature Z and
>     if-feature W >
>     > > or
>     > > > > > simply use the existing feature statement to give such
>     an expression
>     > > a
>     > > > > [email-masked] <mailto:[email-masked]>
>     > > Phone: +49 421 200 3587 <tel:%2B49%20421%20200%203587> Campus
>     Ring 1, 28759 Bremen, Germany
>     > > Fax: +49 421 200 3103 <tel:%2B49%20421%20200%203103>
>     <http://www.jacobs-university.de/>
>     > >
>
>     --
>     Phone: +49 421 200 3587 <tel:%2B49%20421%20200%203587> Campus Ring
>     1, 28759 Bremen, Germany
>     Fax: +49 421 200 3103 <tel:%2B49%20421%20200%203103>
>     <http://www.jacobs-university.de/>
>
>
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 8 Apr 2014 14:26:24 +0200

On 08 Apr 2014, at 11:59, Jernej Tuljak <[email-masked]> wrote:

> Dne 8.4.2014 11:41, piše chong feng:
>> martin's proposal also changed the meaning of 'if-feature', the argument will be changed from 'feature's name' to 'logical expression'.
>> 'union' can be treated as a special feature name, not a new keyword, just like 'union' is 'type''s argument, not a keyword.
>> 
>> 
> 
> It doesn't change the meaning of if-feature any more than your own solution. Both require special treatment of the same keyword's argument syntax. With the exception of your proposal being backward incompatible. "union" is a valid feature identifier in 1.0…

+1. I support Martin’s proposal.

Lada

> 
> Jernej
> 
>> 
>> 
>> 2014-04-08 17:14 GMT+08:00 Juergen Schoenwaelder <[email-masked]>:

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