Search RFCs
The Series
For Authors
Sponsor
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.