RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (2)

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)

Errata ID: 1321
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 3.1, 3rd par says:

   In a scoped IPv4 BSM, the scope of the message is given by the first
   group range in the message, which can be any sub-range of 224/4.  [...]

It should say:

   In a scoped IPv4 BSM, the scope of the message is given by the first
|  group range in the message, which can be any sub-range of 224.0.0.0/4.
   [...]

Notes:

Location is 3rd paragraph of Section 3.1, on mid-page 9.
This correction also needs to be applied to "224/4" in the
7th paragraph of Section 3.3, on mid-page 19.
Rationale:
The basic "strategic" document for CIDR notation now is BCP 122,
RFC 4632, and that document clearly states (in section 3.1, at
the bottom of page 5):
vvvvvvv
| [...] In CIDR notation, a prefix is shown as a 4-octet
quantity, just like a traditional IPv4 address or network number,
followed by the "/" (slash) character, followed by a decimal value
between 0 and 32 that describes the number of significant bits.

As a Standards-Track document, RFC 5059 should follow this rule.

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.

Status: Held for Document Update (1)

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)

Errata ID: 1323
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2008-02-14
Held for Document Update by: Adrian Farrel
Date Held: 2011-08-05

Section 4.1, pg.28 says:

   BSR Address
        The address of the bootstrap router for the domain.  The format
        for this address is given in the Encoded-Unicast address in [1].

It should say:

   BSR Address
        The address of the bootstrap router for the domain.  The format
|       for this address is given in the Encoded-Unicast address format
|       defined in [1] and restated in Section 4.

Notes:

Note: This Erratum was updated by the AD from the original proposal. The original suggested replacing the reference to [1] with a reference to Section 4. The resolution includes both references.

The notes below were updated to be consistent with this change.

======

The above quotation is at the bottom of page 28.
Further instances of the same issue are enumerated at the end of these Notes.

Rationale:

In Section 4, on page 24, the RFC purposely restates the terms
"Encoded-Unicast format" and "Encoded-Group format" from [1] and
continues:

We repeat these here to aid readability.

---- End of Rationale ----

This issue recurs four more times, and similar changes
should be applied:

o on page 29, in the first item, "Group Address 1..n",

o on page 29, in the 4th item, "RP address 1..m"
(subject to preceding Erratum),

as well as in Section 4.2:

o on page 32, in the 3rd item, "RP Address", and

o on page 32, in the 4th item, "Group Address-1..n"
(Note that the hyphen above also should be a blank, for consistency.)

Report New Errata



Advanced Search