errata logo graphic

Found 7 records.

Status: Verified (5)

RFC4960, "Stream Control Transmission Protocol", September 2007

Source of RFC: tsvwg (tsv)

Errata ID: 3788

Status: Verified
Type: Technical

Reported By: Karen Nielsen
Date Reported: 2013-11-06
Verifier Name: Martin Stiemerling
Date Verified: 2014-01-13

Section 8.1 says:

   An endpoint shall keep a counter on the total number of consecutive
   retransmissions to its peer (this includes retransmissions to all the
   destination transport addresses of the peer if it is multi-homed),
   including unacknowledged HEARTBEAT chunks.  

It should say:

An endpoint shall keep a counter on the total number of consecutive
retransmissions to its peer (this includes data retransmissions 
to all the destination transport addresses of the peer if it is 
multi-homed),including the number of unacknowledged HEARTBEAT 
chunks observed on the path which currently is used for data 
transfer. Unacknowledged HEARTBEAT chunks observed on paths 
different from the path currently used for data transfer shall 
not increment the association error counter, as this could lead 
to association closure even if the path which 
currently is used for data transfer is available (but idle). 

Notes:

RFC4960 Endpoint Failure detection mechanism is deficient in that
HB failures on some failing paths may take the association down, even
if other paths are working perfectly, but simply at the time no data
or HBs are being sent on the working paths.

The situation occurs when the association is idle
(no data is being transmitted) and the HBI settings on
the failing paths are much more aggressive than the HBI
set on the working paths. RFC6458 allows for specification
of the HBI on a per destination address whereby
such in-homogeneous setting of the HBI can occur.

The solution proposed to the issue is to demand that
HB failures observed on paths different from the path
currently used for data transfer do
not contribute to the association error counter.
HB failures observed on the path currently used for
data transfer, when this path is idle,
shall contribute to the association error counter.
Thereby supporting Endpoint Failure detection when the
association is idle. When the association is transmitting data,
the fate of the data transmissions and retransmissions
will serve to instantiate Endpoint Failure detection.


Errata ID: 1440

Status: Verified
Type: Technical

Reported By: Michael Tüxen
Date Reported: 2008-06-12
Verifier Name: Lars Eggert
Date Verified: 2008-07-16

Section 8.3 says:

   When the value of this counter reaches the protocol parameter
   'Path.Max.Retrans', the endpoint should mark the corresponding
   destination address as inactive if it is not so marked, and may also
   optionally report to the upper layer the change of reachability of
   this destination address.  After this, the endpoint should continue
   HEARTBEAT on this destination address but should stop increasing the
   counter.

It should say:

   When the value of this counter exceeds the protocol parameter
   'Path.Max.Retrans', the endpoint should mark the corresponding
   destination address as inactive if it is not so marked, and may also
   optionally report to the upper layer the change of reachability of
   this destination address.  After this, the endpoint should continue
   HEARTBEAT on this destination address but should stop increasing the
   counter.

Notes:

The path should be considered inactive, when the error counter exceeds
the threshold. This is stated correctly in 8.2.


Errata ID: 3423

Status: Verified
Type: Technical

Reported By: Pontus Andersson
Date Reported: 2012-12-01
Verifier Name: Martin Stiemerling
Date Verified: 2013-03-06

Section B says:

   unsigned long
   generate_crc32c(unsigned char *buffer, unsigned int length)
   {
     unsigned int i;
     unsigned long crc32 = ~0L;

It should say:

   unsigned long
   generate_crc32c(unsigned char *buffer, unsigned int length)
   {
     unsigned int i;
     unsigned long crc32 = 0xffffffffL;

Notes:

The remainder register (crc32) should be initialized to 0xffffffffL rather than ~0L, for correct operation on platforms where unisigned long is longer than 32 bits. I.e., 64-bit platforms.


Errata ID: 1574

Status: Verified
Type: Editorial

Reported By: Randall Stewart
Date Reported: 2008-10-14
Verifier Name: Magnus Westerlund
Date Verified: 2009-04-03

Section 9.2 says:

Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT
 send a SHUTDOWN in response to a ULP request, and should discard
 subsequent SHUTDOWN chunks.

It should say:

Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT
 send a SHUTDOWN in response to a ULP request, and should discard
 subsequent ULP shutdown requests.

Notes:

The text never intended the SCTP endpoint to ignore SHUTDOWN
chunks from its peer. If it did the endpoints could never gracefully
terminate a associations in some cases.


Errata ID: 2592

Status: Verified
Type: Editorial

Reported By: tom petch
Date Reported: 2010-10-29
Verifier Name: Lars Eggert
Date Verified: 2010-10-31

Section 14.1 says:

14.1.  IETF-Defined Chunk Extension

   The assignment of new chunk parameter type codes is done through an
   IETF Consensus action, as defined in [RFC2434].  Documentation of the
   chunk parameter MUST contain the following information:

It should say:

14.1.  IETF-Defined Chunk Extension

   The assignment of new chunk type codes is done through an
IETF Consensus action, as defined in [RFC2434].  Documentation of the
chunk type MUST contain the following information:

Notes:

The OLD text relates to parameter types, and not chunk types, and already appears, correctly, in section 14.2. Section 14.1 is about chunk types,as the NEW text says.


Status: Reported (1)

RFC4960, "Stream Control Transmission Protocol", September 2007

Source of RFC: tsvwg (tsv)

Errata ID: 3804

Status: Reported
Type: Technical

Reported By: Stephen Galvan Jr
Date Reported: 2013-11-16

Section 3.3.2 says:


Notes:

something was placed in the ending line that made it almost unreadable.


Status: Held for Document Update (1)

RFC4960, "Stream Control Transmission Protocol", September 2007

Source of RFC: tsvwg (tsv)

Errata ID: 3291

Status: Held for Document Update
Type: Editorial

Reported By: Eric W. Biederman
Date Reported: 2012-07-21
Held for Document Update by: Martin Stiemerling

Section 3.3.2 says:

          Variable Parameters                  Status     Type Value
          -------------------------------------------------------------
          IPv4 Address (Note 1)               Optional    5 IPv6 Address
          (Note 1)               Optional    6 Cookie Preservative
          Optional    9 Reserved for ECN Capable (Note 2)   Optional
          32768 (0x8000) Host Name Address (Note 3)          Optional
          11 Supported Address Types (Note 4)    Optional    12

It should say:

          Variable Parameters                  Status     Type Value
          -------------------------------------------------------------
          IPv4 Address (Note 1)               Optional    5 
          IPv6 Address (Note 1)               Optional    6
          Cookie Preservative                 Optional    9
          Reserved for ECN Capable (Note 2)   Optional    32768 (0x8000)
          Host Name Address (Note 3)          Optional    11
          Supported Address Types (Note 4)    Optional    12

Notes:

Something placed the line ending in the wrong place making the table nearly
unreadable.


Report New Errata