RFC Errata
Found 6 records.
Status: Verified (4)
RFC 2453, "RIP Version 2", November 1998
Note: This RFC has been updated by RFC 4822
Source of RFC: ripv2 (rtg)
Errata ID: 2398
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Zdenek
Date Reported: 2010-07-29
Verifier Name: Adrian Farrel
Date Verified: 2010-08-21
Section 3.4 says:
A proof is given in [2] that this algorithm ....
It should say:
A proof is given in [5] that this algorithm....
Notes:
On page 8
Correct the reference.
Errata ID: 3437
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Bharat Joshi
Date Reported: 2012-12-26
Verifier Name: Adrian Farrel
Date Verified: 2013-05-06
Section 3.9.1 says:
There is one special case. If there is exactly one entry in the request, and it has an address family identifier of zero and a metric of infinity (i.e., 16), then this is a request to send the entire routing table.
It should say:
There is one special case. If there is exactly one entry in the request, (in addition to any authentication entry) and it has an address family identifier of zero and a metric of infinity (i.e., 16), then this is a request to send the entire routing table.
Notes:
Note that in RFC 2453 an authentication header is not considered to be an RTE.
There was obviously some confusion on this point and the additional parenthetic text clarifies that if an authentication entry is also present (as the first entry) then it is not included in the special case described in section 3.9.1.
Errata ID: 3996
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2014-05-22
Verifier Name: Adrian Farrel
Date Verified: 2014-05-29
Section 3.4.2 says:
Unfortunately, the question of how long convergence will take is not amenable to quite so simple an answer. Before going any further, it will be useful to look at an example (taken from [2]).
It should say:
Unfortunately, the question of how long convergence will take is not amenable to quite so simple an answer. Before going any further, it will be useful to look at an example (taken from [5]).
Notes:
Correct the reference.
Errata ID: 3999
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2014-05-25
Verifier Name: Alia Atlas
Date Verified: 2014-05-28
Section 3.4 says:
" 4.ne The method so far only has a way to lower the metric, as the existing metric is kept until a smaller one shows up. It is possible that the initial estimate might be too low."
It should say:
" The method so far only has a way to lower the metric, as the existing metric is kept until a smaller one shows up. It is possible that the initial estimate might be too low."
Notes:
Spurious text "4.ne"
Status: Held for Document Update (2)
RFC 2453, "RIP Version 2", November 1998
Note: This RFC has been updated by RFC 4822
Source of RFC: ripv2 (rtg)
Errata ID: 1054
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nataraja Kumar Kota
Date Reported: 2007-08-27
Held for Document Update by: Adrian Farrel
Date Held: 2010-08-21
Section 3.4.4 says:
RIP implementations must also limit the rate which of triggered updates may be trandmitted.
It should say:
RIP implementations must also limit the rate at which triggered updates may be transmitted.
Errata ID: 5197
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Vitaly Sinilin
Date Reported: 2017-12-05
Held for Document Update by: Alvaro Retana
Date Held: 2017-12-08
Section 3.8 says:
Every 30 seconds, the RIP process is awakened to send an unsolicited Response message containing the complete routing table (see section 3.9 on Split Horizon) to every neighboring router.
It should say:
Every 30 seconds, the RIP process is awakened to send an unsolicited Response message containing the complete routing table (see section 3.4.3 on Split Horizon) to every neighboring router.
Notes:
There are a few more invalid references to section 3.9 instead of section 3.4.3 in the text.