Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: Enum vs. Choice vs. Identity Ref. was RE: Information intended to be discussed on 2019-07-30 call



No worries.  I am just looking for consistency in application of the modeling.  The argument seems to be:  1) is the model useful if the entries map to numbers (use enum) and 2) if the model requires the selection between a number of options which can have more complicated structure (use choice).  Using choice as a replacement for enum doesn’t seem to be garnering much support/consensus.

 

I did a grep here à https://github.com/YangModels/yang/tree/master/standard/ieee/published/802.1  tsn-types can be found there.

 

Regards,

-scott.

 

From: Don Fedyk <dfedyk@xxxxxxxx>
Sent: Wednesday, July 31, 2019 11:29 AM
To: Scott Mansfield <scott.mansfield@xxxxxxxxxxxx>; 'Rodney Cummings' <rodney.cummings@xxxxxx>; STDS-802-3-YANG@xxxxxxxxxxxxxxxxx; STDS-802-YANG@xxxxxxxxxxxxxxxxx
Cc: Glenn Parsons <glenn.parsons@xxxxxxxxxxxx>; Janos Farkas <Janos.Farkas@xxxxxxxxxxxx>; 'John Messenger' <jmessenger@xxxxxxxxxxxxxxx>
Subject: Enum vs. Choice vs. Identity Ref. was RE: Information intended to be discussed on 2019-07-30 call

 

Hi Scott

 

Do you expect to review each one below? 

 

I looked at the first one ieee802-dot1q-bridge.yang:887:           

I’d say choice is the only option.   The choice statement allows the choice to have a block of sub-statements which it does in this case.  To code this with an enum would require additional references to the enum value for subsequent statements. In this case there is no enum value associated with any of the choices, instead is defines a frame format.  But even if there was an associated value required I think the choice statement could define a value in a sub-statement.  So the determining logic here is the choice statement allows easy definition of different sub-statements for each choice.

 

For the rest alas, I could not find ieee802-dot1q-tsn-types.yang

 

Cheers

Don

 

 

 

From: Scott Mansfield <scott.mansfield@xxxxxxxxxxxx>
Sent: Tuesday, July 30, 2019 5:56 PM
To: Don Fedyk <dfedyk@xxxxxxxx>; 'Rodney Cummings' <rodney.cummings@xxxxxx>; STDS-802-3-YANG@xxxxxxxxxxxxxxxxx; STDS-802-YANG@xxxxxxxxxxxxxxxxx
Cc: Glenn Parsons <glenn.parsons@xxxxxxxxxxxx>; Janos Farkas <Janos.Farkas@xxxxxxxxxxxx>; 'John Messenger' <jmessenger@xxxxxxxxxxxxxxx>
Subject: RE: Information intended to be discussed on 2019-07-30 call

 

Thanks for the feedback!

 

A good YANGsters topic is:

 

Enum vs. Choice vs. Identity Ref.

 

I’m interested in understanding the pros/cons of each modeling solution.  Reviewing a number of published IEEE models there are some uses of Choice…

ieee802-dot1q-bridge.yang:887:            choice frame-format {

ieee802-dot1q-tsn-types.yang:593:        (ieee802-vlan-tag choice).

ieee802-dot1q-tsn-types.yang:702:        choice config-value {

ieee802-dot1q-tsn-types.yang:704:            "One of the following choices is

ieee802-dot1q-tsn-types.yang:707:            for the choice.";

ieee802-dot1q-tsn-types.yang:951:      choice field {

ieee802-dot1q-tsn-types.yang:953:          "One of the following choices is provided

ieee802-dot1q-tsn-types.yang:956:          for the choice.";

ieee802-dot1q-types.yang:637:      choice map-type {

 

So, if you have an opinion on when to use enum/choice/identity-ref lets capture our collective thoughts.

 

From: Don Fedyk <dfedyk@xxxxxxxx>
Sent: Tuesday, July 30, 2019 4:56 PM
To: 'Rodney Cummings' <rodney.cummings@xxxxxx>; Scott Mansfield <scott.mansfield@xxxxxxxxxxxx>; STDS-802-3-YANG@xxxxxxxxxxxxxxxxx; STDS-802-YANG@xxxxxxxxxxxxxxxxx
Cc: Glenn Parsons <glenn.parsons@xxxxxxxxxxxx>; Janos Farkas <Janos.Farkas@xxxxxxxxxxxx>; 'John Messenger' <jmessenger@xxxxxxxxxxxxxxx>
Subject: RE: Information intended to be discussed on 2019-07-30 call

 

Hi Scott and Rodney

 

I agree with Rodney.

 

I do have a question though.  You mention instances.  Do we have a place where we document instances per yang module?  At what point in our process are instances used?

 

Also in the enum case since there is a text name associated with each enum value why wouldn’t an instance use the text name of the enum?  In other words identity is a text name without an associated value but enum is both a name and a value.  I guess I’m asking why one is presumed more readable.  

 

Cheers

Don

 

 

From: stds-802-yang@xxxxxxxx <stds-802-yang@xxxxxxxx> On Behalf Of Rodney Cummings
Sent: Tuesday, July 30, 2019 2:21 PM
To: Scott Mansfield <scott.mansfield@xxxxxxxxxxxx>; STDS-802-3-YANG@xxxxxxxxxxxxxxxxx; STDS-802-YANG@xxxxxxxxxxxxxxxxx
Cc: Glenn Parsons <glenn.parsons@xxxxxxxxxxxx>; Janos Farkas <Janos.Farkas@xxxxxxxxxxxx>; John Messenger <jmessenger@xxxxxxxxxxxxxxx>
Subject: RE: Information intended to be discussed on 2019-07-30 call

 

Hi Scott,

 

My opinion on "choice"... No... 802.1 will usually need "enum". I've heard similar arguments for "identity", and... No... 802.1 needs "enum".

 

I suspect this sort of suggestion comes from the fact that IETF YANG models are often the end-all-be-all, in that the YANG configures something that doesn't operate on-the-wire. For that sort of use case, I'd agree that choice/identity works well.

 

The problem with 802.1 YANG (and also 1588 YANG) is that we are configuring a protocol that operates on-the-wire. The on-the-wire protocol uses numeric values in its packets... not strings. It is okay for the YANG to configure that with a string, but... the device needs to know the associated number. A string alone doesn't sufficient information. In order to associate a string with a number, the only viable feature in YANG is enum.

 

Rodney

 

From: stds-802-yang@xxxxxxxx <stds-802-yang@xxxxxxxx> On Behalf Of Scott Mansfield
Sent: Tuesday, July 30, 2019 9:30 AM
To: STDS-802-3-YANG@xxxxxxxxxxxxxxxxx; STDS-802-YANG@xxxxxxxxxxxxxxxxx
Cc: Glenn Parsons <glenn.parsons@xxxxxxxxxxxx>; Janos Farkas <Janos.Farkas@xxxxxxxxxxxx>; John Messenger <jmessenger@xxxxxxxxxxxxxxx>
Subject: [EXTERNAL] Information intended to be discussed on 2019-07-30 call

 

Sorry for the missed called today.  I will work with Glenn and Janos to get a bridge that I can open for the YANGsters calls.  The issue was that my laptop browser lost it’s cookies so join.me didn’t recognize my machine and was asking me to enter a six digit verification code that (of course) went to Glenn’s email (not helpful for me).  Anyway, I will make sure the bridge works for the next YANGsters call.

 

Please find a pdf of the slides that would have been talked about today.

 

I was hoping to cover today, if anyone is modifying a “common” file and make sure the process we have laid out is working.  That process is that drafts of common files are worked on in the draft directory of the project modifying the file.

 

In addition to that, there was an item about the use of enum or choice in YANG modules.  One of the ABcu comments from the last ballot indicated that choice would be a better way to model some of the artifacts that are currently enums.

 

I would like opinions on when to use enum vs. when to use choice.

 

====== current definition of chassis-id-subtype-type ======

For example currently in the ABcu yang draft:

  typedef chassis-id-subtype-type {

    type enumeration {

      enum chassis-component {

        value 1;

        description

          "Represents a chassis identifier based on the value of

          entPhysicalAlias object (defined in IETF RFC 2737) for a

          chassis component (i.e., an entPhysicalClass value of

          chassis(3))";

      }

      enum interface-alias {

        value 2;

        description

          "Represents a chassis identifier based on the value of

          ifAlias object (defined in IETF RFC 2863) for an interface

          on the containing chassis.";

      }

      enum port-component {

        value 3;

        description

          "Represents a chassis identifier based on the value of

          entPhysicalAlias object (defined in IETF RFC 2737) for a

          port or backplane component (i.e., entPhysicalClass value of

          port(10) or backplane(4)), within the containing chassis.";

      }

      enum mac-address {

        value 4;

        description

          "Represents a chassis identifier based on the value of a

          unicast source address (encoded in network byte order and

          IEEE 802.3 canonical bit order), of a port on the containing

          chassis as defined in IEEE Std 802-2001.";

      }

      enum network-address {

        value 5;

        description

          "Represents a chassis identifier based on a network address,

          associated with a particular chassis.  The encoded address is

          actually composed of two fields.  The first field is a

          single octet, representing the IANA AddressFamilyNumbers

          value for the specific address type, and the second field is

          the network address value.";

      }

      enum interface-name {

        value 6;

        description

          "Represents a chassis identifier based on the value of

          ifName object (defined in IETF RFC 2863) for an interface

          on the containing chassis.";

      }

      enum local {

        value 7;

        description

          "Represents a chassis identifier based on a locally defined

          value.";

      }

    }

    description

      "The source of a chassis identifier.";

    reference

      "LLDP MIB 20050506";

  }

 

====== Example using choice ======

 

Could be replaced by:

 

    choice chassis-id-subtype {

      description

        "The source of a chassis identifier.";

      reference

        "LLDP MIB 20050506";

 

      leaf chassis-component {

        type empty;

        description

          "Represents a chassis identifier based on the value of

           entPhysicalAlias object (defined in IETF RFC 2737) for a

           chassis component (i.e., an entPhysicalClass value of

           chassis(3))";

      }

 

      leaf interface-alias {

        type empty;

        description

          "Represents a chassis identifier based on the value of

           ifAlias object (defined in IETF RFC 2863) for an interface

           on the containing chassis.";

      }

 

      leaf port-component {

        type empty;

        description

          "Represents a chassis identifier based on the value of

           entPhysicalAlias object (defined in IETF RFC 2737) for a

           port or backplane component (i.e., entPhysicalClass value of

           port(10) or backplane(4)), within the containing chassis.";

      }

 

      leaf mac-address {

        type empty;

        description

          "Represents a chassis identifier based on the value of a

           unicast source address (encoded in network byte order and

           IEEE 802.3 canonical bit order), of a port on the containing

           chassis as defined in IEEE Std 802‐2001.";

      }

 

      leaf network-address {

        type empty;

        description

          "Represents a chassis identifier based on a network address,

           associated with a particular chassis. The encoded address is

           actually composed of two fields. The first field is a

           single octet, representing the IANA AddressFamilyNumbers

           value for the specific address type, and the second field is

           the network address value.";

      }

 

      leaf interface-name {

        type empty;

        description

          "Represents a chassis identifier based on the value of

           ifName object (defined in IETF RFC 2863) for an interface

           on the containing chassis.";

      }

 

      leaf locally-assigned {

        type empty;

        description

          "Represents a chassis identifier based on a locally defined

           value.";

      }

    }

 

The benefit is that when encoding the instances, it is clear what “choice” has been made:

 

For example if the choice was interface-alias the instances would look like:

<chassis-id-subtype>

                <interface-alias/>

</chassis-id-subtype>

 

Regards,

-scott.


To unsubscribe from the STDS-802-YANG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-YANG&A=1


To unsubscribe from the STDS-802-YANG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-YANG&A=1


To unsubscribe from the STDS-802-YANG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-YANG&A=1

Attachment: smime.p7s
Description: S/MIME cryptographic signature