RFC Errata
Found 9 records.
Status: Verified (4)
RFC 3973, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", January 2005
Note: This RFC has been updated by RFC 8736, RFC 9436
Source of RFC: pim (rtg)
Errata ID: 3271
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joseph Weinstein
Date Reported: 2012-06-28
Verifier Name: Adrian Farrel
Date Verified: 2012-08-22
Section 4.5.1 says:
if StateRefreshCapable(I) == TRUE
set PT(S,G) to largest active holdtime read from a Prune
message accepted on I;
It should say:
if StateRefreshCapable(I) == TRUE
set PT(S,G,I) to the Holdtime from an active Prune received on
interface I. The Holdtime used SHOULD be the largest active one
but MAY be the most recently received active Prune Holdtime.
Notes:
It is not clear what is meant by the "largest active holdtime", and in any event sec. 4.4.2.3 specifies a slightly different rule:
Send State Refresh(S,G) out interface I
The router has refreshed the Prune(S,G) state on interface I.
The router MUST reset the Prune Timer (PT(S,G,I)) to the Holdtime
from an active Prune received on interface I. The Holdtime used
SHOULD be the largest active one but MAY be the most recently
received active Prune Holdtime.
Additionally...
No macro PT(S,G) is defined anywhere in the RFC; the reference appears to be to P(S,G,I).
The concept of an "active Prune" is not defined in this RFC, but simply means those prunes which have not expired.
Errata ID: 967
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mark Doll
Date Reported: 2007-05-16
Verifier Name: Adrian Farrel
Date Verified: 2011-09-04
Section 4.6.1 says:
assert_metric
my_assert_metric(S,G,I) {
if (CouldAssert(S,G,I) == TRUE) {
return spt_assert_metric(S,G,I)
} else {
return infinite_assert_metric()
}
}
It should say:
assert_metric
my_assert_metric(S,G,I) {
if (CouldAssert(S,G,I) == TRUE) {
return spt_assert_metric(S,I)
} else {
return infinite_assert_metric()
}
}
Notes:
In Section 4.6.1, spt_assert_metric(S,I) is defined to have two
parameters, not three.
from pending [error in data transfer corrected 2/15/08.]
Errata ID: 968
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mark Doll
Date Reported: 2007-05-16
Verifier Name: Adrian Farrel
Date Verified: 2011-09-04
Section 4.6.1 says:
assert_metric
spt_assert_metric(S,I) {
return {0,MRIB.pref(S),MRIB.metric(S),my_addr(I)}
}
It should say:
assert_metric
spt_assert_metric(S,I) {
return {MRIB.pref(S),MRIB.metric(S),my_addr(I)}
}
Notes:
In Section 4.6.1, assert_metric is defined to be a 3-tuple, not a
4-tuple.
Errata ID: 969
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mark Doll
Date Reported: 2007-05-16
Verifier Name: Adrian Farrel
Date Verified: 2011-09-04
Section 4.6.1 says:
assert_metric
infinite_assert_metric() {
return {1,infinity,infinity,0}
}
It should say:
assert_metric
infinite_assert_metric() {
return {infinity,infinity,0}
}
Notes:
In Section 4.6.1, assert_metric is defined to be a 3-tuple, not a
4-tuple.
Status: Held for Document Update (2)
RFC 3973, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", January 2005
Note: This RFC has been updated by RFC 8736, RFC 9436
Source of RFC: pim (rtg)
Errata ID: 4635
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Rui Lin
Date Reported: 2016-03-08
Held for Document Update by: Alvaro Retana
Date Held: 2016-07-14
Section 4.1.2 says:
Upstream interface-specific:
Graft/Prune State:
State: One of {"NoInfo" (NI), "Pruned" (P), "Forwarding" (F),
"AckPending" (AP) }
It should say:
"NoInfo" (NI) is not defined as an upstream interface state in 4.4.1.
Notes:
Suggest to remove "NoInfo" (NI) here.
Errata ID: 5894
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ehsan Hemmati
Date Reported: 2019-11-06
Held for Document Update by: Alvaro Retana
Date Held: 2019-11-06
Section 4.4.1 says:
Forwarding (F)
This is the starting state of the Upsteam(S,G) state machine.
The state machine is in this state if it just started or if
oiflist(S,G) != NULL.
It should say:
Forwarding (F)
This is the starting state of the Upstream(S,G) state machine.
The state machine is in this state if it just started or if
oiflist(S,G) != NULL.
Notes:
Upsteam(S,G) is a typo and should be corrected as Upstream(S,G)
Status: Rejected (3)
RFC 3973, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", January 2005
Note: This RFC has been updated by RFC 8736, RFC 9436
Source of RFC: pim (rtg)
Errata ID: 970
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Doll
Date Reported: 2007-05-16
Rejected by: Adrian Farrel
Date Rejected: 2011-09-04
Remark: In Section 4.7.10 it says, the 4th value is "The Rendezvous Point Tree bit. Set to 0 for PIM-DM. Ignored upon receipt."
It should say:
[not submitted]
Notes:
from pending
--VERIFIER NOTES--
This Erratum is complaining that this RFC defines a bit, but then marks it as outside the scope of this document.
While this is bad practice, it does not break any rules and is not grounds for an Erratum. It might be justifiable e use of the bit if anyone is interested.
Furthermore, the Erratum does not make any specific point or propose and resolution.
Errata ID: 3270
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joseph Weinstein
Date Reported: 2012-06-28
Rejected by: Adrian Farrel
Date Rejected: 2012-08-22
Section 4.5.1 says:
if StateRefreshCapable(I) == TRUE
set PT(S,G) to largest active holdtime read from a Prune
message accepted on I;
It should say:
if StateRefreshCapable(I) == TRUE
set PT(S,G,I) to largest active holdtime read from a Prune
message accepted on I;
Notes:
No macro PT(S,G) is defined anywhere in the RFC; the reference appears to be to P(S,G,I).
--VERIFIER NOTES--
Rejected as a duplicate of http://www.rfc-editor.org/errata_search.php?eid=3271
Errata ID: 3286
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Joseph Weinstein
Date Reported: 2012-07-16
Rejected by: Adrian Farrel
Date Rejected: 2012-08-22
Section 4.5 says:
(Additional subection)
It should say:
4.5.3 Receiving State Refresh Messages When a State Refresh message is received, it may trigger state transitions to the upstream state machine and related actions, as described in Section 4.4. It is then forwarded in accordance with Section 4.5.1.
Notes:
For clarity and completeness, an additional subsection is required to 4.5 describing the actions to be taken when a state refresh message is received. Since these actions have already been specified in Sections 4.4 and 4.5.1, it should be sufficient to simply refer to these sections. Without this additional subsection, an implementer could easily miss an important step in the processing of received state refresh messages.
--VERIFIER NOTES--
This may be fine and useful, but it does not qualify as Errata because it is
introducing new text and material.
If the WG feels strongly about this, it can be brought forward as a small
Informational I-D or included in an update of this RFC.