RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata



Advanced Search