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.
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
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
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