Subject: [netmod] Y10 clarification

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Nov 2015 19:38:08 +0100 (CET)

Hi,

I implemented most of the 1.1 features that affect the compiler in
pyang on the flight back from Yokohama.  (if you have 1.1 modules, I'd
appreciate if you could try it out).

In doing this, I realized that I forgot one part of Y10 - "allow
restrictions on enumerations".  If we allow:

    typedef foo2 {
      type enumeration {
        enum a;
        enum b;
      }
    }
    typedef bar2 {
      type foo2 {
        enum a;
      }
    }

we should also allow:

    typedef foo2 {
      type bits {
        bit a;
        bit b;
      }
    }
    typedef bar2 {
      type foo2 {
        bit a;
      }
    }

It is briefly mentioned in the description of Y10.

Comments?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Nov 2015 11:24:08 -0800

> It is briefly mentioned in the description of Y10.
Yet more complexity without any real use-cases?
How does auto-numbering work in both cases?

    typedef foo2 {
      type enumeration {
        enum a;
        enum b;
      }
    }

    typedef foo3 {
      type foo2 {
        enum b;
      }
    }

    typedef bar1 {
      type enumeration {
        enum b;
      }
    }

What is the auto-numbering of enum 'b' in type foo3?
What value does type foo3 have over bar1?

> /martin

Andy

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Nov 2015 22:11:10 +0100 (CET)

> Yet more complexity without any real use-cases?

It is a matter of removing CLRs and inconsistencies.

> What is the auto-numbering of enum 'b' in type foo3?

There is none.  The text says:

  When an existing enumeration type is restricted, the "value"
  statement MUST either have the same value as in the base type or not
  be present, in which case the value is the same as in the base type.

> What value does type foo3 have over bar1?

Unless the type has some semantics, there is none.   But when the type
has some semantics, the possibility to restrict an existing type is
useful.  If it not useful for enumerations and bits, why should we
have it for strings and ints, for example.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 9 Nov 2015 13:21:16 -0800

>   be present, in which case the value is the same as in the base type.

good

Is the refinement allowed to add, remove, or change if-feature-stmts?
I don't remember seeing any text on that.

> have it for strings and ints, for example.

so the reason to do this would be to restrict the value set but
maintain the value and position assignments.  OK

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Nov 2015 08:40:58 +0100 (CET)

> I don't remember seeing any text on that.

The refine statement cannot address individual enums/bits (it can only
address structure) so the answer is that it is not possible to change
if-feature on enums/bits in refinements.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Tue, 10 Nov 2015 11:50:49 +0000

Hi Martin,

> appreciate if you could try it out).

Against, my interfaces-common module using your latest yang-1.1 branch I 
only have the "augment with mandatory" error remaining:

sjc-ads-5101:ddmi$ pyang --ietf  interfaces/interfaces-common.yang
interfaces/interfaces-common.yang:370: error: cannot augment with 
mandatory node parent-interface

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Nov 2015 09:09:17 -0800

> if-feature on enums/bits in refinements.

It looks like it is --

   9.6.3.  Restrictions

      An enumeration can be restricted with the "enum" (Section 9.6.4)
      statement.

                 +--------------+---------+-------------+
                 | substatement | section | cardinality |
                 +--------------+---------+-------------+
                 | description  | 7.21.3  | 0..1        |
                 | if-feature   | 7.20.2  | 0..n        |
                 | reference    | 7.21.4  | 0..1        |
                 | status       | 7.21.2  | 0..1        |
                 | value        | 9.6.4.2 | 0..1        |
                 +--------------+---------+-------------+

Sec 9.6.3 says any sub-statement of enum-stmt is allowed

All of the derived sub-statements from the refined enum are brought over I
asume

   typedef foo4 {
     enumeration {
       enum A1 {
         if-feature foo;
       }
       enum A2;
     }
   }

    typedef foo5 {
        type foo4 {
          enum A1;
        }
    }

Is enum A1 conditional on the foo feature in both foo4 and foo5 typedefs?

   typedef foo6 {
        type foo4 {
          enum A2 {
            if-feature bar;
        }
    }

According to the spec, adding if-feature in foo6 is also allowed.

   typedef foo7 {
        type foo4 {
          enum A1 {
            if-feature bar;
        }
    }

Is the A1 enum in foo7 conditional on feature foo and bar, or just bar?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 10 Nov 2015 21:32:14 +0100 (CET)

>       An enumeration can be restricted with the "enum" (Section 9.6.4)

Aha, ok, I thought you meant the "refine" statement.

Since it is ok to add if-feature to a node when a grouoing is used
(with "refine"), I think it should be ok to add "if-feature" to an
enum/bit when the type is restricted.

Yes.

> According to the spec, adding if-feature in foo6 is also allowed.

Yes.

> Is the A1 enum in foo7 conditional on feature foo and bar, or just bar?

Both IMO - again compare w/ nodes in groupings.

We probably need text to clarify these situations.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 10 Nov 2015 13:38:09 -0800

On Tue, Nov 10, 2015 at 12:32 PM, Martin Bjorklund <[email-masked]> wrote:

> > > > > > On Mon, Nov 9, 2015 at 10:38 AM, Martin Bjorklund <
> [email-masked]>
> > > > > wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > pyang on the flight back from Yokohama.  (if you have 1.1
> modules,
> > > I'd

Yes -- it is OK to make a node more conditional but not less conditional.
You cannot take away an if-feature that is defined in the original typedef.
This is easier to say than to enforce since if-feature syntax has been
expanded.

   typedef foo8 {
     type foo4 {
       enum A1 {
         if-feature "bar and not foo";
       }
      }
   }

Is foo8 an error?  IMO, no. It can be very difficult to detect conflicts.
It is easy to just apply all the logic, which may produce an
expression that is always false.

Andy