RFC Errata
Found 7 records.
Status: Verified (2)
RFC 5303, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", October 2008
Source of RFC: isis (rtg)
Errata ID: 2587
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohammad Fahad Imteyaz
Date Reported: 2010-10-29
Verifier Name: Stewart Bryant
Date Verified: 2011-01-28
Section 3.2 says:
Add a clause e) to the end of "Sending point-to-point IIH PDUs" (section 8.2.3 of [ISIS]):
It should say:
Add a clause e) to the end of "Sending point-to-point IIH PDUs" (section 8.2.4 of [ISIS]):
Notes:
Though the ISIS reference name in "Normative References" have been updated to "International Standard 10589:2002, Second Edition, 2002" , the section reference was still to first edition of ISO/IEC 10589
Errata ID: 2588
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohammad Fahad Imteyaz
Date Reported: 2010-10-29
Verifier Name: Stewart Bryant
Date Verified: 2011-01-28
Section 3.2 says:
The current three-way state of the adjacency with its neighbor on the link (as defined in new section 8.2.4.1.1 introduced later in the document) SHALL be reported in the Adjacency Three-Way State field.
It should say:
The current three-way state of the adjacency with its neighbor on the link (as defined in new section 8.2.5.1.1 introduced later in the document) SHALL be reported in the Adjacency Three-Way State field.
Notes:
Though the ISIS reference name in "Normative References" have been updated to "International Standard 10589:2002, Second Edition, 2002" , the section reference was still to first edition of ISO/IEC 10589.
Status: Held for Document Update (5)
RFC 5303, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", October 2008
Source of RFC: isis (rtg)
Errata ID: 2589
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohammad Fahad Imteyaz
Date Reported: 2010-10-29
Held for Document Update by: Adrian Farrel
Date Held: 2012-08-09
Section 3.2 says:
Add a section 8.2.4.1.1, "Three-Way Handshake", immediately prior to "IIH PDU Processing" (section 8.2.4.2 of [ISIS]):
It should say:
Add a section 8.2.5.1.1, "Three-Way Handshake", immediately prior to "IIH PDU Processing" (section 8.2.5.2 of [ISIS]):
Notes:
Though the ISIS reference name in "Normative References" have been updated to "International Standard 10589:2002, Second Edition, 2002" , the section reference was still to first edition of ISO 10589.
Errata ID: 2590
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohammad Fahad Imteyaz
Date Reported: 2010-10-29
Held for Document Update by: Adrian Farrel
Date Held: 2012-08-09
Section 3.2 says:
A received Point-to-Point IIH PDU may or may not contain the
Point-to-Point Three-Way Adjacency option. If it does not, the
link is assumed to be functional in both directions, and the
procedures described in section 8.2.4.2 are followed.
It should say:
A received Point-to-Point IIH PDU may or may not contain the
Point-to-Point Three-Way Adjacency option. If it does not, the
link is assumed to be functional in both directions, and the
procedures described in section 8.2.5.2 are followed.
Notes:
Though the ISIS reference name in "Normative References" have been updated to "International Standard 10589:2002, Second Edition, 2002" , the section reference was still to first edition of ISO 10589.
Errata ID: 2591
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohammad Fahad Imteyaz
Date Reported: 2010-10-29
Held for Document Update by: Adrian Farrel
Date Held: 2012-08-09
Section 3.2 says:
If the Neighbor System ID and Neighbor Extended Local Circuit ID
fields match those of the local system, or are not present, the
procedures described in section 8.2.4.2 are followed with the
following changes:
It should say:
If the Neighbor System ID and Neighbor Extended Local Circuit ID
fields match those of the local system, or are not present, the
procedures described in section 8.2.5.2 are followed with the
following changes:
Notes:
Though the ISIS reference name in "Normative References" have been updated to "International Standard 10589:2002, Second Edition, 2002" , the section reference was still to first edition of ISO 10589.
Errata ID: 2593
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohammad Fahad Imteyaz
Date Reported: 2010-10-29
Held for Document Update by: Adrian Farrel
Date Held: 2012-08-09
Section 3.2 says:
a) In section 8.2.4.2 a and b, the action "Up" from state tables
5, 6, 7, and 8 may create a new adjacency but the three-way
state of the adjacency SHALL be Down.
b) If the action taken from section 8.2.4.2 a or b is "Up" or
"Accept", the IS SHALL perform the action indicated by the new
adjacency three-way state table below, based on the current
adjacency three-way state and the received Adjacency Three-Way
State value from the option. (Note that the procedure works
properly if neither field is ever included. This provides
backward compatibility to an earlier version of this option.)
Received Adjacency Three-Way State
Down Initializing Up
--------------------------------------
Down | Initialize Up Down
|
Adj. Initializing | Initialize Up Up
Three- |
Way Up | Initialize Accept Accept
State |
|
Adjacency Three-Way State Table
If the new action is "Down", an adjacencyStateChange(Down)
event is generated with the reason "Neighbor restarted" and the
adjacency SHALL be deleted.
If the new action is "Initialize", no event is generated and
the adjacency three-way state SHALL be set to "Initializing".
If the new action is "Up", an adjacencyStateChange(Up) event is
generated.
c) Skip section 8.2.4.2 c and d.
d) If the new action is "Initialize", "Up", or "Accept", follow
section 8.2.4.2 e.
It should say:
a) In section 8.2.5.2 a and b, the action "Up" from state tables
5, 6, 7, and 8 may create a new adjacency but the three-way
state of the adjacency SHALL be Down.
b) If the action taken from section 8.2.5.2 a or b is "Up" or
"Accept", the IS SHALL perform the action indicated by the new
adjacency three-way state table below, based on the current
adjacency three-way state and the received Adjacency Three-Way
State value from the option. (Note that the procedure works
properly if neither field is ever included. This provides
backward compatibility to an earlier version of this option.)
Received Adjacency Three-Way State
Down Initializing Up
--------------------------------------
Down | Initialize Up Down
|
Adj. Initializing | Initialize Up Up
Three- |
Way Up | Initialize Accept Accept
State |
|
Adjacency Three-Way State Table
If the new action is "Down", an adjacencyStateChange(Down)
event is generated with the reason "Neighbor restarted" and the
adjacency SHALL be deleted.
If the new action is "Initialize", no event is generated and
the adjacency three-way state SHALL be set to "Initializing".
If the new action is "Up", an adjacencyStateChange(Up) event is
generated.
c) Skip section 8.2.5.2 c and d.
d) If the new action is "Initialize", "Up", or "Accept", follow
section 8.2.5.2 e.
Notes:
Though the ISIS reference name in "Normative References" have been updated to "International Standard 10589:2002, Second Edition, 2002" , the section reference was still to first edition of ISO 10589. (replace 8.2.4.2 with 8.2.5.2 in the orignal text.
Errata ID: 2594
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohammad Fahad Imteyaz
Date Reported: 2010-10-29
Held for Document Update by: Stewart Bryant
Date Held: 2011-01-28
Section 6 says:
This document is a minor edit of [RFC3373] with the intent of advancing it from Informational to Standards Track. It also updates the ISP 10589 reference to refer to the current "2002" version.
It should say:
This document is a minor edit of [RFC3373] with the intent of advancing it from Informational to Standards Track. It also updates the ISO/IEC 10589 reference to refer to the current "2002" version.