[pim] [Technical Errata Reported] RFC8364 (8052)

RFC Errata System <rfc-editor@rfc-editor.org> Sat, 27 July 2024 03:08 UTC

To: ice@cisco.com, stig@cisco.com, michael.brig@mda.mil, anders@jomac.se, james.n.guichard@futurewei.com, jgs@juniper.net, gunter.van_de_velde@nokia.com, stig@cisco.com, mmcbride7@gmail.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20240727030823.324553B873@rfcpa.rfc-editor.org>
Message-ID-Hash: KO5VIGQMQXQ4BBGVLI5L7IZ562I4E2IL
CC: pim@ietf.org, rfc-editor@rfc-editor.org
Precedence: list
Subject: [pim] [Technical Errata Reported] RFC8364 (8052)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/0tI3LSOaaQquXZkeCMZdTfYkdTQ>
Date: Sat, 27 Jul 2024 03:08:24 -0000

The following errata report has been submitted for RFC8364,
"PIM Flooding Mechanism (PFM) and Source Discovery (SD)".

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

--------------------------------------
Type: Technical
Reported by: David 'equinox' Lamparter <equinox@diac24.net>

Section: 4.1

Original Text
-------------
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|         Type = 1              |          Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Corrected Text
--------------
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|         Type = 1            |           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes
-----
The field boundary is off by one bit in the first row of the diagram for Group Source Holdtime TLV. The bar between the Type and Length fields is supposed to be 1 bit further left, matching the 3rd row in the diagram in section 3.1.

The fact that this 1-bit-off boundary makes the type field very oddly bit-aligned will likely cause implementors to double check the two diagrams against each other and also conclude the one in 3.1 is correct.  The IANA table in section 7 also has Type as a 15-bit field going up to 32767; the shift in boundary would make it a 16-bit field.

(Reporting as technical errata since the text does not specify the actual encoding, the diagram is the "source" of actual encoding definition.)

Instructions:
-------------
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8364 (draft-ietf-pim-source-discovery-bsr-12)
--------------------------------------
Title               : PIM Flooding Mechanism (PFM) and Source Discovery (SD)
Publication Date    : March 2018
Author(s)           : IJ. Wijnands, S. Venaas, M. Brig, A. Jonasson
Category            : EXPERIMENTAL
Source              : Protocols for IP Multicast
Stream              : IETF
Verifying Party     : IESG

[pim] [Technical Errata Reported] RFC8364 (8052) RFC Errata System