| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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> 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> 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> 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 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 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