Subject: Fwd: SCTP API document..

From: Randall Stewart <[email-masked]>
Date: Mon, 7 Mar 2011 17:34:15 -0500

All:

A bit late but Kirk did finally reply..

I answered his query about the deprecated features... I am not sure
if we can do anything about the way bindx works...

The non-mention of the replacement for the deprecated interface is probably
an easy fix.

R

Begin forwarded message:

> From: Kirk McKusick
> Date: March 7, 2011 4:40:05 PM EST
> To: Randall Stewart <[email-masked]>
> Subject: Re: SCTP API document.. 
> 
>> From: Randall Stewart <[email-masked]>
>> Subject: Re: SCTP API document.. 
>> Date: Mon, 28 Feb 2011 06:00:06 -0500
>> To: Kirk McKusick <[email-masked]>
>> 
>> Kirk:
>> 
>> Your input would be appreciated... You might want to just
>> scan the document.. its pretty large ;-0
>> 
>> http://www.ietf.org/id/draft-ietf-tsvwg-sctpsocket-26.txt
>> 
>> The above link is the last version.. There were some minor english
>> comments just discussed on the list (Michael T prompted a few people
>> as well and one of them did a detailed review)...
>> 
>> I understand your time crunch... it would be nice if you
>> make a couple of comments though ;-)
>> 
>> R
> 
> Finally got around to looking at this document (well version 27
> actually :) It was the first time that I had dived down into the
> details of SCTP. You have done a good job of integrating it into
> the historic sockets interface. As this was my first time looking
> at SCTP I cannot be much help in finding bugs. So my comments are
> limited to things that I found confusing.
> 
> The 6.2.1. SCTP_EVENTS option is DEPRECATED. Most of the DEPRECATED
> interfaces start with a note pointing to what should be used in its
> place. This interface lacks that pointer (though the replacement
> does follow immediately).
> 
> Also, I am curious why a new standard documents already deprecated
> interfaces? Is it that existing implementations have them?
> 
> In 9.1. sctp_bindx() if one of several addresses fails the whole
> thing fails with no indication of which address caused the problem.
> This is reminicent of IBM JCL days when a single mistype in a
> 50-card deck caused the whole thing to be rejected with no
> indication of what was wrong. The only solution was to go through
> card-by-card to find the problem. That is the suggested solution 
> here. One would hope that in fifty years we could do better. In
> reading this interface my take was never to specify more than one
> address per call.
> 
> 	~Kirk
> 

------------------------------
Randall Stewart
803-317-4952 (cell)

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 8 Mar 2011 10:08:39 +0100

> The non-mention of the replacement for the deprecated interface is probably
I'll add such a sentence and we can include this in the next
rev (assuming there is one based on the comments we get from the IETF LC).

Regarding the sctp_bindx() comment: We state this in the last paragraph
of the sctp_bindx() section, were we state that it might be a good idea
to use a single address only.

Best regards
Michael

---

From: Randall Stewart <[email-masked]>
Date: Tue, 8 Mar 2011 05:19:58 -0500

> to use a single address only.

Yeah, I know.. and I think thats Kirk's comment... basically it
would be nice if you did NOT have to do that...

But I do not see an easy alternative ;-0

R

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 8 Mar 2011 11:47:52 +0100

> But I do not see an easy alternative ;-0
I think for sctp_bindx() we have to keep it. But MPTCP is
another protocol providing support for multihoming.

For binding multiple addresses they refer to sctp_bindx().
But I think sctp_bindx() should be SCTP specific, and
we possibly should define a bindx(), or whatever you
would name it, call which support SCTP and MPTCP, which
only accepts one address. This is pretty much what Kacheong
suggested years ago... I still have to send comments regarding
the MPTCP API ID...

Best regards
Michael

---

From: Randall Stewart <[email-masked]>
Date: Tue, 8 Mar 2011 07:10:00 -0500

> suggested years ago... I still have to send comments regarding

Ahh, I did not know they had one.. I will have to look at it.

R