Found 1 record.

Status: Reported (1)

RFC 7105, "Using Device-Provided Location-Related Measurements in Location Configuration Protocols", January 2014

Errata ID: 6553
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Andy Brezinsky
Date Reported: 2021-04-20

Section 5.1 says:

An example of an LLDP measurement is shown in Figure 4.  This shows
an adjacent node (chassis) that is identified by the IP address
192.0.2.45 (hexadecimal c000022d), and the port on that node is
numbered using an agent circuit ID [RFC3046] of 162 (hexadecimal a2).

  <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
        time="2008-04-29T14:33:58">
    <lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp">
      <chassis type="4">c000022d</chassis>
      <port type="6">a2</port>
    </lldp>
  </measurements>

It should say:

An example of an LLDP measurement is shown in Figure 4.  This shows
an adjacent node (chassis) that is identified by the IP address
192.0.2.45 (hexadecimal 01c000022d, with the leading octet set to the
IANA Address Family Numbers enumeration value for IPv4 [RFC1700]), and 
the port on that node is numbered using an agent circuit ID [RFC3046] of 
162 (hexadecimal a2).

  <measurements xmlns="urn:ietf:params:xml:ns:geopriv:lm"
        time="2008-04-29T14:33:58">
    <lldp xmlns="urn:ietf:params:xml:ns:geopriv:lm:lldp">
      <chassis type="5">01c000022d</chassis>
      <port type="6">a2</port>
    </lldp>
  </measurements>

Notes:

There are two issues identified with this example.

First, it wasn't clear what the original purpose of the 'type' field was. Upon further investigation, they were intended to carry the Chassis ID Subtype and Port ID Subtype of the respective elements. Given that, Chassis ID Subtype of '4' is the incorrect subtype for a Network Address. The correct Chassis ID Subtype defined in IEEE Std 802.1AB-2016 Table 8-2 ('chassis ID subtype enumeration') is '5'. The Port ID Subtype enumeration for Network Address is '4' and may be where the incorrect value was copied from.

Second, the example encoding of the IP Address 192.168.2.45 is missing the first octet designating the IANA Address Family Number. The example provided should be corrected to '01c000022d'.

IEEE Std 802.1AB-2016 Table 8-2 (a) notes: "networkAddress is an octet string that identifies a particular network address family and an associated network address that are encoded in network octet order. An IP address, for > example, would be encoded with the first octet containing the IANA Address Family Numbers enumeration value for the specific address type and octets 2 through n containing the > address value (for example, the encoding for C0-00-02-0A would indicate the IPv4 address 192.0.2.10)."

As it relates to the type of this erratum, Section 5.1 notes:

> Values are provided as hexadecimal sequences. The Device MUST report
> the values directly as they were provided by the adjacent node.
> Attempting to adjust or translate the type of identifier is likely to
> cause the measurement data to be useless.

Since clients already must hexadecimal encode the value that is reported without adjusting or translating it, only the example should be incorrect. However because people may have written their code to match the example directly, I'm leaving this as a technical type.

Report New Errata