Search RFCs

RFC Editor

Found 3 records.

Status:Verified (3)

RFC 4340, "Datagram Congestion Control Protocol (DCCP)", March 2006

Note: This RFC has been updated byRFC 5595, RFC 5596, RFC 6335, RFC 6773

Errata ID:974
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eddie Kohler
Date Reported: 2006-07-11

Section 6.6.4 says:

[text below should be added to the end of the section]

It should say:

   FGSR and FGSS values always satisfy FGSR <= GSR and FGSS <= GSS,   where GSR and GSS are the Greatest Sequence Numbers Received by and   Sent from this endpoint.  These constraints MUST be enforced even   when GSR and GSS wrap, as they might in a long connection.   Implementations SHOULD thus check FGSR and FGSS after every packet   received or sent, as follows.  (Wmax is the maximum allowed value for   the Sequence Window feature; see Section 7.5.2.)         If FGSR > GSR, then FGSR := GSR - Wmax.         If FGSS > GSS, then FGSS := GSS - Wmax.   Alternate implementations that correctly handle sequence number   wrapping are also acceptable.

Notes:

One technical omission has been found concerning the FGSR and FGSS
variables used to detect reordering of feature negotiation options. We
suggest adding the above paragraph to the end of Section 6.6.4, on Page
42.

via Alfred Hoenes

from pending

Errata ID:1049
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sally Floyd
Date Reported: 2007-09-01

Section 6.6.8 says:

      The Ack      Ratio feature takes two-byte, non-zero integer values, so a      "Change L(Ack Ratio, 0)" option is never valid.

It should say:

      The Sequence Window feature takes six-byte, non-zero integer      values, with a minimum valid value of 32, so a "Change      L(Sequence Window, 0)" option is never valid.

Notes:

reported by Gerrit Renker

Errata ID:980
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Eddie Kohler
Date Reported: 2006-07-11

In Section 6.6.4, Page 41, it says:              (Change and/or Confirm).  This value is initialized to              ISR - 1.It should say:              (Change and/or Confirm).  This value is initialized to              ISR - 1, where ISR is the Initial Sequence Number Received              from the other endpoint.  (ISR and other sequence number              variables are defined in Section 7.1.)In Section 6.6.4, Page 41, it says:              reordering.  FGSS is initialized to ISS.It should say:              reordering.  FGSS is initialized to ISS, the Initial              Sequence Number Sent by this endpoint.In Section 7.5.2, Page 49, it says:    getting out sync after bursts of loss,It should say:    getting out of sync after bursts of loss,In Section 8.1.2, Page 60, it says:            intepreting the four-character result as a 32-bit big-endianIt should say:            interpreting the four-character result as a 32-bit big-endianIn Appendix A, Page 116, it says:    right to left.  The implementation maintains five variables, asideIt should say:    right to left.  The implementation maintains four variables, asideAnd it says:       acknowledged in the buffer.  This corresponds to the "head"It should say:       acknowledged in the buffer.  This corresponds to the "buf_head"On Page 117, it says:    Ack Vector, it remembers four variables:It should say:    Ack Vector, it remembers five variables:In Section A.3, Page 121, it says:    HC-Sender packet 3, so the HC-Sender has now received HC-Receiver'sIt should say:    HC-Sender packet 3, so the HC-Sender has now received the HC-Receiver'sIn Section A.4, Page 122, it says:    a single acknowledgement number tells HC-Receiver how much ackIt should say:    a single acknowledgement number tells the HC-Receiver how much ack

Notes:

via Alfred Hoenes

from pending

Report New Errata