RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 11 records.

Status: Verified (3)

RFC 6458, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", December 2011

Source of RFC: tsvwg (tsv)

Errata ID: 6111
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Michael Tuexen
Date Reported: 2020-04-20
Verifier Name: Martin Duke
Date Verified: 2020-04-27

Throughout the document, when it says:

in Section 5.3.2

         SCTP_EOF:  Setting this flag invokes the SCTP graceful shutdown
            procedure on the specified association.  Graceful shutdown
            assures that all data queued by both endpoints is
            successfully transmitted before closing the association.

         SCTP_SENDALL:  This flag, if set, will cause a one-to-many
            style socket to send the message to all associations that
            are currently established on this socket.  For the one-to-
            one style socket, this flag has no effect.



in Section 5.3.4

      SCTP_EOF:  Setting this flag invokes the SCTP graceful shutdown
         procedures on the specified association.  Graceful shutdown
         assures that all data queued by both endpoints is successfully
         transmitted before closing the association.

      SCTP_SENDALL:  This flag, if set, will cause a one-to-many style
         socket to send the message to all associations that are
         currently established on this socket.  For the one-to-one style
         socket, this flag has no effect.



in Section 8.1.13

The sinfo_flags field is composed of a bitwise OR
of SCTP_UNORDERED, SCTP_EOF, and SCTP_SENDALL.



in Section 8.1.31

The snd_flags parameter is composed of a bitwise OR 
of SCTP_UNORDERED, SCTP_EOF, and SCTP_SENDALL.

It should say:

in Section 5.3.2

         SCTP_EOF:  Setting this flag invokes the SCTP graceful shutdown
            procedure on the specified association.  Graceful shutdown
            assures that all data queued by both endpoints is
            successfully transmitted before closing the association.

         SCTP_EOR: This flag, if set and explicit EOR marking (see
            Section 8.1.26) is enabled , indicates that the user data
            provided is the last part of a user message. If explicit
            EOR marking is disabled, this flag is not relevant, since the
            user data provided is a complete user message.

         SCTP_SENDALL:  This flag, if set, will cause a one-to-many
            style socket to send the message to all associations that
            are currently established on this socket.  For the one-to-
            one style socket, this flag has no effect.



in Section 5.3.4

      SCTP_EOF:  Setting this flag invokes the SCTP graceful shutdown
         procedures on the specified association.  Graceful shutdown
         assures that all data queued by both endpoints is successfully
         transmitted before closing the association.

      SCTP_EOR: This flag, if set and explicit EOR marking (see Section 8.1.26)
         is enabled , indicates that the user data provided is the last part of
         a user message. If explicit EOR marking is disabled, this flag is
         not relevant, since the user data provided is a complete user message.

      SCTP_SENDALL:  This flag, if set, will cause a one-to-many style
         socket to send the message to all associations that are
         currently established on this socket.  For the one-to-one style
         socket, this flag has no effect.



in Section 8.1.13

The sinfo_flags field is composed of a bitwise OR
of SCTP_UNORDERED, SCTP_EOF, SCTP_EOR, and SCTP_SENDALL.



in Section 8.1.31

The snd_flags parameter is composed of a bitwise OR
of SCTP_UNORDERED, SCTP_EOF, SCTP_EOR, and SCTP_SENDALL.

Notes:

The text is missing a description of how to use the SCTP_EOR flag in the Socket API. The problem was initially reported by wanglihe in https://www.rfc-editor.org/errata/eid6081

Errata ID: 6115
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Michael Tuexen
Date Reported: 2020-04-20
Verifier Name: Martin Duke
Date Verified: 2020-04-27

Section 8.2.1 says:

sstat_state:  This contains the association's current state, i.e.,
      one of the following values:

      *  SCTP_CLOSED

      *  SCTP_BOUND

      *  SCTP_LISTEN

      *  SCTP_COOKIE_WAIT

      *  SCTP_COOKIE_ECHOED

      *  SCTP_ESTABLISHED

      *  SCTP_SHUTDOWN_PENDING

      *  SCTP_SHUTDOWN_SENT

      *  SCTP_SHUTDOWN_RECEIVED

      *  SCTP_SHUTDOWN_ACK_SENT

It should say:

sstat_state:  This contains the association's current state, i.e.,
      one of the following values:

      *  SCTP_CLOSED

      *  SCTP_LISTEN

      *  SCTP_COOKIE_WAIT

      *  SCTP_COOKIE_ECHOED

      *  SCTP_ESTABLISHED

      *  SCTP_SHUTDOWN_PENDING

      *  SCTP_SHUTDOWN_SENT

      *  SCTP_SHUTDOWN_RECEIVED

      *  SCTP_SHUTDOWN_ACK_SENT

Notes:

SCTP_BOUND is not a state of an SCTP association, so it should not be part of this list.

Errata ID: 6112
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Michael Tuexen
Date Reported: 2020-04-20
Verifier Name: Martin Duke
Date Verified: 2020-04-27

Section 3.2 says:

The success or failure of sending the data message (with
possible SCTP_INITMSG ancillary data) will be signaled by the
SCTP_ASSOC_CHANGE event with SCTP_COMM_UP or SCTP_CANT_START_ASSOC.
If user data could not be sent (due to an SCTP_CANT_START_ASSOC),
the sender will also receive an SCTP_SEND_FAILED_EVENT event.

It should say:

The success or failure of sending the data message (with
possible SCTP_INITMSG ancillary data) will be signaled by the
SCTP_ASSOC_CHANGE event with SCTP_COMM_UP or SCTP_CANT_STR_ASSOC.
If user data could not be sent (due to an SCTP_CANT_STR_ASSOC),
the sender will also receive an SCTP_SEND_FAILED_EVENT event.

Notes:

The constant SCTP_CANT_START_ASSOC is not defined. The correct name is SCTP_CANT_STR_ASSOC.

Status: Held for Document Update (4)

RFC 6458, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", December 2011

Source of RFC: tsvwg (tsv)

Errata ID: 4921
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Jonathan Leighton
Date Reported: 2017-02-02
Held for Document Update by: Martin Duke
Date Held: 2020-04-27

Section 9.1 says:

If sd is an IPv4 socket, the addresses passed must be IPv4 addresses.
If the sd is an IPv6 socket, the addresses passed can either be IPv4
or IPv6 addresses.

It should say:

If sd is an IPv4 socket, the passed addresses must be IPv4 addresses.
If sd is an IPv6 socket, the passed addresses must be IPv6 addresses.
Use IPv4-mapped IPv6 addresses to bind an IPv6 socket to an IPv4
address. Note that some implementations optionally allow IPv4 addresses
to be passed in directly.

Notes:

The erratum is a subtle change in meaning that would be a useful clarification.

Errata ID: 6116
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Michael Tuexen
Date Reported: 2020-04-20
Held for Document Update by: Martin Duke
Date Held: 2020-04-27

Section 6.1.2 says:

   spc_state:  This field holds one of a number of values that
      communicate the event that happened to the address.  They include

      SCTP_ADDR_AVAILABLE:  This address is now reachable.  This
         notification is provided whenever an address becomes reachable.

      SCTP_ADDR_UNREACHABLE:  The address specified can no longer be
         reached.  Any data sent to this address is rerouted to an
         alternate until this address becomes reachable.  This
         notification is provided whenever an address becomes
         unreachable.

      SCTP_ADDR_REMOVED:  The address is no longer part of the
         association.

      SCTP_ADDR_ADDED:  The address is now part of the association.

      SCTP_ADDR_MADE_PRIM:  This address has now been made the primary
         destination address.  This notification is provided whenever an
         address is made primary.

It should say:

   spc_state:  This field holds one of a number of values that
      communicate the event that happened to the address.  They include

      SCTP_ADDR_CONFIRMED:  This address is now confirmed.  This
         notification is provided once an address transitions from
         the UNCONFIRMED state to the CONFIRMED state (see
         Section 5.4 of [RFC 4960]).

      SCTP_ADDR_AVAILABLE:  This address is now reachable.  This
         notification is provided whenever an address becomes reachable.

      SCTP_ADDR_UNREACHABLE:  The address specified can no longer be
         reached.  Any data sent to this address is rerouted to an
         alternate until this address becomes reachable.  This
         notification is provided whenever an address becomes
         unreachable.

      SCTP_ADDR_REMOVED:  The address is no longer part of the
         association.

      SCTP_ADDR_ADDED:  The address is now part of the association.

      SCTP_ADDR_MADE_PRIM:  This address has now been made the primary
         destination address.  This notification is provided whenever an
         address is made primary.

Notes:

A description of the handling of the path verification as specified in Section 5.4 of RFC 4960 was missing.

Errata ID: 6113
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Michael Tuexen
Date Reported: 2020-04-20
Held for Document Update by: Martin Duke
Date Held: 2020-04-27

Section 6.1.1 says:

sac_info:  If sac_state is SCTP_COMM_LOST and an ABORT chunk was
      received for this association, sac_info[] contains the complete
      ABORT chunk as defined in Section 3.3.7 of the SCTP specification
      [RFC4960].

It should say:

sac_info:  If sac_state is SCTP_COMM_LOST or SCTP_CANT_STR_ASSOC and
      an ABORT chunk was received for this association, sac_info[]
      contains the complete ABORT chunk as defined in Section 3.3.7
      of the SCTP specification [RFC4960].

Notes:

During association setup, SCTP_CANT_STR_ASSOC is signalled when an ABORT chunk is received. SCTP_COMM_LOST is used after the association has been established.

Errata ID: 6114
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Michael Tuexen
Date Reported: 2020-04-20
Held for Document Update by: Martin Duke
Date Held: 2020-04-27

Section 9.5 says:

If the id field is set to the value '0', then the locally bound
addresses are returned without regard to any particular association.

It should say:

If the id field is set to the value SCTP_FUTURE_ASSOC, then the locally bound
addresses are returned without regard to any particular association.

Notes:

Don't use a numeric constant, but the symbolic constant. Its numeric value is implementation specific.

Status: Rejected (4)

RFC 6458, "Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)", December 2011

Source of RFC: tsvwg (tsv)

Errata ID: 6081
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: wanglihe
Date Reported: 2020-04-09
Rejected by: Martin Duke
Date Rejected: 2020-04-27

Throughout the document, when it says:

8.1.26    must indicate that they are
   finished sending a particular record by including the SCTP_EOR flag.

but I can not find where to use SCTP_EOR flag.

because

5.1  The msg_flags are not used when sending a message with sendmsg().

3.1.4  flags:  No new flags are defined for SCTP at this level.  See
      Section 5 for SCTP-specific flags used in the msghdr structure.

4.1.8 same with 3.1.4

9.10, 9.12    flags:  The same flags as used by the sendmsg() call flags (e.g.,
      MSG_DONTROUTE).

9.7   flags:  The same as sinfo_flags (see Section 5.3.2).

5.3.2 sinfo_flags not mention about it  

It should say:

maybe msg_flags should be used.

Notes:

Another problem is that, I think it should be discuss about debfine a flag like SCTP_BOR for beginning(init chunk) of a Record, because a stream of this socket(assoc) can still be used after send a SCTP_EOR.

And between a init chunk and a STCP_EOR, if I change SCTP_EXPLICIT_EOR status, what the socket will send the message?
--VERIFIER NOTES--
6111 addresses the same problem and has a more actionable recommendation.

Errata ID: 6131
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: wanglihe
Date Reported: 2020-04-09
Rejected by: Martin Duke
Date Rejected: 2020-04-27

Throughout the document, when it says:

8.1.26    must indicate that they are
   finished sending a particular record by including the SCTP_EOR flag.

but I can not find where to use SCTP_EOR flag.

because

5.1  The msg_flags are not used when sending a message with sendmsg().

3.1.4  flags:  No new flags are defined for SCTP at this level.  See
      Section 5 for SCTP-specific flags used in the msghdr structure.

4.1.8 same with 3.1.4

9.10, 9.12    flags:  The same flags as used by the sendmsg() call flags (e.g.,
      MSG_DONTROUTE).

9.7   flags:  The same as sinfo_flags (see Section 5.3.2).

5.3.2 sinfo_flags not mention about it  

It should say:

maybe msg_flags should be used.

Notes:

Another problem is that, I think it should be discuss about debfine a flag like SCTP_BOR for beginning(init chunk) of a Record, because a stream of this socket(assoc) can still be used after send a SCTP_EOR.

And between a init chunk and a STCP_EOR, if I change SCTP_EXPLICIT_EOR status, what the socket will send the message?
--VERIFIER NOTES--
This is an accidental duplication; please disregard.

Errata ID: 6132
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: wanglihe
Date Reported: 2020-04-09
Rejected by: Martin Duke
Date Rejected: 2020-04-27

Throughout the document, when it says:

8.1.26    must indicate that they are
   finished sending a particular record by including the SCTP_EOR flag.

but I can not find where to use SCTP_EOR flag.

because

5.1  The msg_flags are not used when sending a message with sendmsg().

3.1.4  flags:  No new flags are defined for SCTP at this level.  See
      Section 5 for SCTP-specific flags used in the msghdr structure.

4.1.8 same with 3.1.4

9.10, 9.12    flags:  The same flags as used by the sendmsg() call flags (e.g.,
      MSG_DONTROUTE).

9.7   flags:  The same as sinfo_flags (see Section 5.3.2).

5.3.2 sinfo_flags not mention about it  

It should say:

maybe msg_flags should be used.

Notes:

Another problem is that, I think it should be discuss about debfine a flag like SCTP_BOR for beginning(init chunk) of a Record, because a stream of this socket(assoc) can still be used after send a SCTP_EOR.

And between a init chunk and a STCP_EOR, if I change SCTP_EXPLICIT_EOR status, what the socket will send the message?
--VERIFIER NOTES--
Accidental duplication; please disregard.

Errata ID: 6133
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: wanglihe
Date Reported: 2020-04-09
Rejected by: Martin Duke
Date Rejected: 2020-04-27

Throughout the document, when it says:

8.1.26    must indicate that they are
   finished sending a particular record by including the SCTP_EOR flag.

but I can not find where to use SCTP_EOR flag.

because

5.1  The msg_flags are not used when sending a message with sendmsg().

3.1.4  flags:  No new flags are defined for SCTP at this level.  See
      Section 5 for SCTP-specific flags used in the msghdr structure.

4.1.8 same with 3.1.4

9.10, 9.12    flags:  The same flags as used by the sendmsg() call flags (e.g.,
      MSG_DONTROUTE).

9.7   flags:  The same as sinfo_flags (see Section 5.3.2).

5.3.2 sinfo_flags not mention about it  

It should say:

maybe msg_flags should be used.

Notes:

Another problem is that, I think it should be discuss about debfine a flag like SCTP_BOR for beginning(init chunk) of a Record, because a stream of this socket(assoc) can still be used after send a SCTP_EOR.

And between a init chunk and a STCP_EOR, if I change SCTP_EXPLICIT_EOR status, what the socket will send the message?
--VERIFIER NOTES--
Accidental duplicate, please disregard.

Report New Errata