Requested revision
Standard: | IEEE 802.1CS-2020 | Clause: | 13.5.1 and 13.5.3 |
Clause title: | LRP Textual conventions MIB and LLDPv2 LRP extension MIB |
Rationale for revision
RFC 4001 states in the introduction, that "A generic Internet address consists of two objects: one whose syntax is InetAddressType, and another whose syntax is InetAddress. The value of the first object determines how the value of the second is encoded.". This makes it clear that an InetAddress object can not exist on its own because then it would be unclear how its contents have to be interpreted. IEEE Std 802.1CS-2020 uses InetAddress without the accompanying InetAddressType. Instead, in the LLDP-V2-LRP-EXT-MIB, an accompanying AddressInfo object of type "LrpInetAddressInfo" is provided for each respective inetAddress object, to provide the missing context. This textual convention is most likely used to introduce an additional value that is required by 802.1CS-2020 ("notPresent(256)") but not available in inetAddressType. The issue with this approach is that it goes against RFC 4001, thus generating a compiler warning, and that it will render standard tools incapable of correctly interpreting the value in the InetAddress-object.
Proposed text
Create a new textual convention, defining something like "LrpInetAddress" (or some other fitting name) that would be identical to the definition of "InetAddress" in RFC 4001, changing the description to state that it uses the accompanying "LrpInetAddressInfo" object as context for how it has to be interpreted. Then use this new textual convention as SYNTAX for the four objects currently of type "InetAddress". This would take care of the compiler warnings and also make the MIB compliant to RFC 4001 since InetAddress is no longer used without the accompanying InetAddressType. Unfortunately, this would not address the topic of standard tools being unable to correctly interpret the format, unless they are being updated to recognize the textual conventions introduced by 802.1CS and this suggested remedy.
Impact on existing networks
None, as the SYNTAX of the textual convention suggested in the fix is
identical ("OCTET STRING (SIZE (0..255))") to the SYNTAX of the
currently used InetAddress.
Originator
Name: | Stephan Kehrer | Email: | stephan.kehrer.committees@gmail.com |
Affiliation: | Hirschmann Automation and Control GmbH/Belden | ||
Submitted: | 2024-04-05 |