RFC 8364, "PIM Flooding Mechanism (PFM) and Source Discovery (SD)", March 2018

Note: This RFC has been updated by RFC 8736, RFC 9436

Errata ID: 8052
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: David 'equinox' Lamparter
Date Reported: 2024-07-27
Edited by: Gunter Van de Velde
Date Edited: 2024-07-30

Section 4.1 says:

       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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

       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 implementers 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.

The reporting was originally done as technical errata since the text does not specify the actual encoding, the diagram is the "source" of actual encoding definition, however the errata reported is the result of a editorial table alignment glitch

Report New Errata