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.