Stream Control Transmission Protocol
draft-ietf-tsvwg-2960bis-05

1. The header of the document on the front page should mention that this document obsoletes RFC 2960 and RFC 4460 when approved.

2. The Network Management Considerations section says:

  A MIB for SCTP is defined in [RFC3873].

As this document succeeds in time RFC3873 it would be useful replace this statment with: 

The MIB module for SCTP defined in [RFC3873] applies for the version of the protocol specified in this document.

  The suggested SCTP protocol parameter values defined in Section 15.
  Please add a forward pointer to Section 15 on the first occurrence
  of the use of a protocol parameter defined there.  It will help
  the reader find the default values for these parameters.

  Based on Gen-ART Review by Vijay K. Gurbani:

  In Section 1.3.1 consider replacing "against security attacks" with
  "against synchronization attacks".  The term "security" is too broad,
  and I believe that you are trying to prevent the likelihood of TCP SYN
  attacks in SCTP.

  Please consider putting Section 1.5 somewhere in the beginning.  Since
  the sub-sections that preceeded Section 1.5 use the abbreciations
  quite a bit, introducing the reader to the abbreviations early should
  help readability.
  
  In section 3.3.5, second paragraph, the text says that the parameter
  field contains an opaque data structure understood only by the sender.
  I think it will add more clarity to insert the following text at the
  end of the last paragraph in the section:

  OLD:
   The Sender-specific Heartbeat Info field should normally include
   information about the sender's current time when this HEARTBEAT
   chunk is sent and the destination transport address to which this
   HEARTBEAT is sent (see Section 8.3).

  NEW:
   The Sender-specific Heartbeat Info field should normally include
   information about the sender's current time when this HEARTBEAT
   chunk is sent and the destination transport address to which this
   HEARTBEAT is sent (see Section 8.3).  This information is simply
   reflected back by the receiver in the HEARTBEAT ACK message (see
   Section 3.3.6).

  In Section 11.2.2, it is stated that "A widely implemented BSD
  Sockets API extension exists for applications to request IP security
  services...".  Please provide a reference or drop the clause.

  Nit: S3, page 16: s/Section 6.10for/Section 6.10 for/

  Nit: S3.3.2.1, under the IPv6 address parameter figure:
  s/128 bit/128 bits/

  Nit: S4: s/description of all special cases should be found in the text/
  /description of all special cases are found in the text/

  Nit: S7.1, first bullet: s/layer otherwise/layer to do otherwise/

Section 11.3 on fraud seems to have no place in this document.  I
don't think it adds to the document and found it long-winded.  As an
individual I recommend removing it.