Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)
RFC 6458

Note: This ballot was opened for revision 32 and is now closed.

(Wesley Eddy) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Adrian Farrel) (was Discuss) No Objection

Comment (2011-10-04)
No email
send info
idnits notes that RFC 1644 has been obsoleted by RFC 6247

This is also noted in the Shepherd write-up.
Please enter an RFC Editor note so the RFC Editor knows how to resolve this.

(Stephen Farrell) No Objection

Comment (2011-10-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
- In section 2, it'd be good to provide a (normative?) reference for
the Posix API. Also, you're specifying the 1997 version - is that
deliberate? (There seems to be a later version, but I'm not sure what
today's systems follow.)

- The security considerations might benefit from adding a generic
sentence about implementation security, e.g.  warning about buffer
overruns, or maybe telling developers to go check out the CVE

- I was surprised not to see a mention of RFC 6083 (DTLS over SCTP).
I'm not sure how DTLS would be implemented with this API. If its
analogous to TLS/TCP then it'd be above this API I guess, but that'd
be worth a mention, e.g. saying "If you want transport security, then
DTLS [RFC 6083] can be used, but is expected to be implemented above,
and not inside, this API." or something like that.

(Russ Housley) (was Discuss) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

Comment (2011-10-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I agree that a normative reference to the POSIX specification (IEEE 1003.1) would be appropriate.

(Robert Sparks) No Objection

Comment (2011-10-04 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
While addressing Adrian's discuss, please look for a way to capture that this _has been_ the api definition for some time (the document's been around for a decade) and that you are deprecating parts of the API previously documented here. Please make it clear that there is no other formal definition of the API elsewhere that this is obsoleting.


(Sean Turner) (was Discuss) No Objection