[Technical Errata Reported] RFC7105 (6553)

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[Technical Errata Reported] RFC7105 (6553)

rfc-editor
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 <[hidden email]>

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

_______________________________________________
Geopriv mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/geopriv
Reply | Threaded
Open this post in threaded view
|

Re: [Technical Errata Reported] RFC7105 (6553)

Martin Thomson-2
I can confirm this erratum.  I've been discussing this with Andy privately and I have confirmed that these changes are correct.

This is probably entirely my fault.  I just missed the cited text about address family in the original instance and likely confused the tables.

One thing to note here is that this adds a new informative reference to RFC 1700 as part of the corrected text.  That's a little unusual as part of an erratum and probably worth adding explicitly to the notes.

Cheers,
Martin

On Wed, Apr 21, 2021, at 01:18, RFC Errata System wrote:

> 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 <[hidden email]>
>
> 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
>
> _______________________________________________
> Geopriv mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/geopriv
>

_______________________________________________
Geopriv mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/geopriv