RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 5059, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", January 2008

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

Source of RFC: pim (rtg)
See Also: RFC 5059 w/ inline errata

Errata ID: 1322
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2008-02-14
Verifier Name: Adrian Farrel
Date Verified: 2011-08-18

Section 4.1, pg.29 says:

   Frag RP Cnt 1..m

It should say:

   Frag RP Cnt 1..n

Notes:

This is a legacy issue inherited from RFC 2362.

In section 4.1, 'n' is used for the number of group range blocks
in the Bootstrap Message,
'm' is used for the number of RP Address sub-blocks within each
group range block.

'Frag RP Cnt' is a group range block level parameter and hence
needs indexing in the range 1..n .

Further, the reader should be cautious regarding the use of 'm':
In the diagram of the Bootstrap Message 'fragment' on pg. 27-28,
'm' is used in two contexts, but these are independent instances,
which better had been named differently, or indexed with the
group range block index i = 1..n ; on page 27, 'm' is the value of
the 'Frg RP Cnt 1' field and might better be designated as 'm_1',
while on page 28, 'm' is the value of the 'Frg RP Cnt n' field
and accordingly might better have been designated as 'm_n'.
In the corresponding field explanations on page 29, the remaining
3 instances of 'm' should better be replaced by 'm_i' for clarity:

RP address 1..m --> RP address 1..m_i

RP1..m Holdtime --> RP 1..m_i Holdtime

RP1..m Priority --> RP 1..m_i Priority

Purists would perhaps insist on having the additional (major)
index 'i' prepended to the running index '1..m_i' in all these
field names, as well.

Report New Errata



Advanced Search