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 |