Search RFCs
The Series
For Authors
Sponsor
RFC Errata
Found 3 records.
Status:Verified (1)
RFC 5384, "The Protocol Independent Multicast (PIM) Join Attribute Format", November 2008
Note: This RFC has been updated byRFC 7887
Source of RFC: pim (rtg)Errata ID:1597
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-17
Verifier Name: Adrian Farrel
Date Verified: 2012-05-08
Section 4, last para says:
- The encoding type 1 has been allocated, defined as "native encoding| for the address family, but with zero or more PIM Join Attributes present", and this document is the reference.
It should say:
- The encoding type 1 has been allocated, defined as "native encoding| for the address family, but with one or more PIM Join Attributes present", and this document is the reference.
Notes:
Rationale:
Section 3.1 of this RFC says (3rd para):
A type 1 Encoded-Source Address MUST contain at least one Join
Attribute. The way to specify that there are no Join Attributes for
a particular tree is to use the type 0 Encoded-Source Address.
Hence, having *zero* attributes in encoding type 1 is explicitely
forbidden.
Please alse have the IANA registry entry be corrected.
Status:Held for Document Update (2)
RFC 5384, "The Protocol Independent Multicast (PIM) Join Attribute Format", November 2008
Note: This RFC has been updated byRFC 7887
Source of RFC: pim (rtg)Errata ID:1598
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-17
Held for Document Update by: Adrian Farrel
Date Held: 2013-01-16
Section 3.4.2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | OptionType = 26 | OptionLength = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | OptionType = 26 | OptionLength = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
The notes when raised read:
> Misplaced field separator (vertical bar).
>
> Erratum is considered 'Technical' because the text of the RFC
> does not contain text that could guide the reader in
> disambiguating the figure.
Moving this to editorial with the note that PIM Option formats are well known.
Errata ID:1599
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2008-11-17
Held for Document Update by: Adrian Farrel
Section 3.2,1st para says:
To ensure that a type 1 Encoded-Source Address is not sent to a PIM neighbor that does not understand this encoding, a new PIM Hello option, the "Join Attribute" option, is defined. This option MUST be included in the PIM Hellos of any PIM router that is willing to| receive type 1 Encoded-Source Address. A PIM router MUST NOT send a ^ type 1 Encoded-Source Address out any interface on which there is a PIM neighbor that has not included this option in its Hellos. (Even| a router that is not the upstream neighbor must be able parse the ^ packet in order to do Join suppression or overriding.)
It should say:
To ensure that a type 1 Encoded-Source Address is not sent to a PIM neighbor that does not understand this encoding, a new PIM Hello option, the "Join Attribute" option, is defined. This option MUST be included in the PIM Hellos of any PIM router that is willing to| receive type 1 Encoded-Source Addresses. A PIM router MUST NOT send ^^^ a type 1 Encoded-Source Address out any interface on which there is a PIM neighbor that has not included this option in its Hellos. (Even| a router that is not the upstream neighbor must be able to parse the ^^^^ packet in order to do Join suppression or overriding.)
Notes:
Rationale: Grammar flawed.