[Geopriv] [Technical Errata Reported] RFC7105 (6553)

[RFC Errata System <[e-mail]>]

The following errata report has been submitted for RFC7105,
"Using Device-Provided Location-Related Measurements in Location Configuration Protocols".

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6553

--------------------------------------
Type: Technical
Reported by: Andy Brezinsky <[e-mail]>

Section: 5.1

Original Text
-------------
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>

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

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7105 (draft-ietf-geopriv-held-measurements-09)
--------------------------------------
Title               : Using Device-Provided Location-Related Measurements in Location Configuration Protocols
Publication Date    : January 2014
Author(s)           : M. Thomson, J. Winterbottom
Category            : PROPOSED STANDARD
Source              : Geographic Location/Privacy
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG