RFC Errata
Found 8 records.
Status: Verified (2)
RFC 3376, "Internet Group Management Protocol, Version 3", October 2002
Source of RFC: idmr (rtg)
Errata ID: 1501
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Dave Thaler
Date Reported: 2008-09-08
Verifier Name: Adrian Farrel
Date Verified: 2013-05-11
The header says:
Network Working Group B. Cain
Request for Comments: 3376 Cereva Networks
Obsoletes: 2236 S. Deering
Category: Standards Track I. Kouvelas
Cisco Systems
B. Fenner
AT&T Labs - Research
A. Thyagarajan
Ericsson
October 2002
It should say:
Network Working Group B. Cain
Request for Comments: 3376 Cereva Networks
Updates: 2236 S. Deering
Category: Standards Track I. Kouvelas
Cisco Systems
B. Fenner
AT&T Labs - Research
A. Thyagarajan
Ericsson
October 2002
Notes:
RFC 3376 does not completely replace RFC 2236, so it should say "updates" instead of "obsoletes". Specifically, to have a compliant implementation of RFC 3376 section 4, one MUST understand and implement the "Version 2 Membership Report" and "Version 2 Leave Group" messages. This is why RFC 2236 is listed as a normative reference of RFC 3376.
Errata ID: 7339
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alvaro Retana
Date Reported: 2023-02-07
Verifier Name: John Scudder
Date Verified: 2023-02-08
Section Abstract says:
This document obsoletes RFC 2236.
It should say:
This document updates RFC 2236.
Notes:
Report EID 1501 has been Verified to update the information in the document's header: from Obsoletes to Updates.
This sentence in the abstract should be corrected for the same reason.
Status: Reported (1)
RFC 3376, "Internet Group Management Protocol, Version 3", October 2002
Source of RFC: idmr (rtg)
Errata ID: 7575
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Aymen Lahouel
Date Reported: 2023-07-26
Section 5.1 says:
If more changes to the same interface state entry occur before all the retransmissions of the State-Change Report for the first change have been completed, each such additional change triggers the immediate transmission of a new State-Change Report.
It should say:
If more changes to the same interface state entry occur before all the retransmissions of the State-Change Report for the first change have been completed, each such additional change triggers the immediate transmission of a new State-Change Report only if the new change is of the same type as the current change.
Notes:
Section 5.1 says: "If the interface reception-state change that triggers the new report is a filter-mode change, then the next [Robustness Variable] State-Change Reports will include a Filter-Mode-Change record. This applies even if any number of source-list changes occur in that period. The host has to maintain retransmission state for the group until the [Robustness Variable] State-Change reports have been sent.".
It is clearly stated that if a source-list changes occur before all the retransmissions of the State-Change Report for the filter-mode change have been completed, The host has to maintain retransmission state for the group until the [Robustness Variable] State-Change reports have been sent. Therefore, in this case it must not immediately send a new State-Change Report.
Status: Held for Document Update (3)
RFC 3376, "Internet Group Management Protocol, Version 3", October 2002
Source of RFC: idmr (rtg)
Errata ID: 4375
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Yechiel Rosengarten
Date Reported: 2015-05-26
Held for Document Update by: Alvaro Retana
Date Held: 2016-02-16
Section 8.13 says:
8.12. Older Version Querier Present Timeout The Older Version Querier Interval is the time-out for transitioning a host back to IGMPv3 mode once an older version query is heard. When an older version query is received, hosts set their Older Version Querier Present Timer to Older Version Querier Interval. This value MUST be ((the Robustness Variable) times (the Query Interval in the last Query received)) plus (one Query Response Interval).
It should say:
8.12. Older Version Querier Present Timeout The Older Version Querier Interval is the time-out for transitioning a host back to IGMPv3 mode once an older version query is heard. When an older version query is received, hosts set their Older Version Querier Present Timer to Older Version Querier Interval. This value MUST be ((the Robustness Variable) times (the Query Interval )) plus (one Query Response Interval in the last Query received).
Notes:
The last query received is older version query.
As such - it does not include query interval.
It looks like it should be operator responsibility to configure identical robustness variable and query interval values network-wide for supporting older versions.
=== Alvaro Retana ===
The pim WG was consulted on the proposed text of this errata, but no clear direction was determined. In fact, no significant discussion took place.
Given that this issue doesn't seem to be causing a problem that the WG wants to address wight away, I'm disposing of this errata as "Held for Document Update". If this RFC is updated the WG must then address the issue.
https://mailarchive.ietf.org/arch/msg/pim/s9dMx_O3cFUyn38CHj81yw4Wp2o
Errata ID: 6725
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Nasir Ahmed
Date Reported: 2021-10-27
Held for Document Update by: Alvaro Retana
Date Held: 2022-01-31
Section 8.4 says:
8.4. Group Membership Interval The Group Membership Interval is the amount of time that must pass before a multicast router decides there are no more members of a group or a particular source on a network. This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (one Query Response Interval).
It should say:
8.4. Group Membership Interval The Group Membership Interval is the amount of time that must pass before a multicast router decides there are no more members of a group or a particular source on a network. This value MUST be ((the Robustness Variable) times (the Query Interval)) plus (2 * Query Response Interval).
Notes:
A router resuming querier role (when current querier dies off) waits for other querier timer value to be expired. This value is ((the Robustness Variable) times (the Query Interval)) plus (one half of one Query Response Interval). This value by default comes as (2 * 125 + 10/2) = 255. Whereas GMI comes as (2 * 125 + 10) = 260. A group learnt with this value will have its group timer value set to expire from anywhere from 260 + 10 (min 260, max 270 due to random response from host in the interval of max response time delay after a query). Now a new router resuming a querier role will generate query after 255 sec. At this point of time the group timer left will be in the range of (260 - 255) 5sec to (270 - 255 ) 15sec. Since the query response can come anywhere between 10sec, Groups whose timer value is less will expire and will result in traffic drop. Therefore it is recommended to increase the default GMI value by one extra Query Response Interval. That is - ((the Robustness Variable) times (the Query
Interval)) plus (2 * Query Response Interval).
====
AD Notes:
I am changing the status of this report to Held for Document Update. The WG is discussing what the best way to address it is: https://mailarchive.ietf.org/arch/msg/pim/Im8go1fjyVad7jyhGg1bgnW93qM/
Errata ID: 5562
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Wim De Smet
Date Reported: 2018-11-26
Held for Document Update by: Alvaro Retana
Date Held: 2019-02-08
Section 6.2.1 says:
When a router filter-mode for a group is EXCLUDE, the source record list contains two types of sources. The first type is the set which represents conflicts in the desired reception state; this set must be forwarded by some router on the network. The second type is the set of sources which hosts have requested to not be forwarded. Appendix A describes the reasons for keeping this second set when in EXCLUDE mode.
It should say:
[see note]
Notes:
Appendix A.3 contains the following:
One of the ways to accomplish this is for routers to keep track of
all sources desired by hosts that are in INCLUDE mode even though the
router itself is in EXCLUDE mode.
Appendix A.3 makes clear that in EXCLUDE mode we need to keep track of the set of hosts that *are* desired (i.e. set A in section 6.4 or the "first type" in this paragraph). The second set (set B in section 6.4) is the set that will be reported to upstream routers, it is not the set which is needed for smooth switching to INCLUDE mode (the behavior described in appendix A). I believe that the intended description may have been "Appendix A describes the reasons for keeping two different sets when in EXCLUDE mode". At the very least, it appears to be set A (the "first set") which is intended in appendix A.
Status: Rejected (2)
RFC 3376, "Internet Group Management Protocol, Version 3", October 2002
Source of RFC: idmr (rtg)
Errata ID: 770
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Rajesh Garg
Date Reported: 2006-03-21
Rejected by: Adrian Farrel
Date Rejected: 2011-07-24
Section 5.2 says:
If new query is Group and Source Specific query and there is pending response for this group and recorded source list for the group is empty (i.e. previous query was Group Specific query)
It should say:
[see note]
Notes:
In section 5.2 of RFC 3376, 5 sequential steps are given to handle the
received query from the multicast router.
I feel the following case is not handled properly in these steps (see above)
In this case, source list will be cleared as per step 4 of section 5.2.
But I feel the source list should be recorded to generate the report
accordingly.
from pending
--VERIFIER NOTES--
The RFC is correct in saying that recorded source-list should be cleared if the newly received query is group-specific query.
Errata ID: 3092
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jon Hak Song
Date Reported: 2012-01-18
Rejected by: Adrian Farrel
Date Rejected: 2012-05-08
Section 6.6.3.1 says:
6.6.3.1. Building and Sending Group Specific Queries When a table action "Send Q(G)" is encountered, then the group timer must be lowered to LMQT. The router must then immediately send a group specific query as well as schedule [Last Member Query Count - 1] query retransmissions to be sent every [Last Member Query Interval] over [Last Member Query Time]. When transmitting a group specific query, if the group timer is larger than LMQT, the "Suppress Router-Side Processing" bit is set in the query message.
It should say:
6.6.3.1. Building and Sending Group Specific Queries When a table action "Send Q(G)" is encountered, then the group timer must be lowered to LMQT. The router must then immediately send a group specific query as well as schedule [Last Member Query Count - 1] query retransmissions to be sent every [Last Member Query Interval] over [Last Member Query Time]. When a group specific query is being transmitted, if the group timer is larger than LMQT, the "Suppress Router-Side Processing" bit is set in the query message.
Notes:
--VERIFIER NOTES--
I am rejecting this editorial erratum because the original English is perfectly comprehensible. (It is true that it is not very elegant, but the proposed replacement isn't too good either:-)