Skip to main content

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

Yes

(Wesley Eddy)

No Objection

(Dan Romascanu)
(Gonzalo Camarillo)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)

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

(Wesley Eddy; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) (was Discuss) No Objection

No Objection (2011-10-04)
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.

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ()

                            

(Peter Saint-Andre; former steering group member) No Objection

No Objection (2011-10-05)
I agree that a normative reference to the POSIX specification (IEEE 1003.1) would be appropriate.

(Robert Sparks; former steering group member) No Objection

No Objection (2011-10-04)
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.

 

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2011-10-05)
- 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
databases.

- 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.

(Stewart Bryant; former steering group member) No Objection

No Objection ()