Re: SCTP API document..

[Michael Tüxen <[e-mail]>]

On Mar 8, 2011, at 11:19 AM, Randall Stewart wrote:
> 
> On Mar 8, 2011, at 4:08 AM, Michael Tüxen wrote:
> 
>> On Mar 7, 2011, at 11:34 PM, Randall Stewart wrote:
>> 
>>> 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.
>> 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.
> 
> 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
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
> 
> R
> 
> 
>> 
>> Best regards
>> Michael
>>> 
>>> R
>>> 
>>> Begin forwarded message:
>>> 
>>>> From: Kirk McKusick
>>>> Date: March 7, 2011 4:40:05 PM EST
>>>> To: Randall Stewart <[e-mail]>
>>>> Subject: Re: SCTP API document.. 
>>>> 
>>>>> From: Randall Stewart <[e-mail]>
>>>>> Subject: Re: SCTP API document.. 
>>>>> Date: Mon, 28 Feb 2011 06:00:06 -0500
>>>>> To: Kirk McKusick <[e-mail]>
>>>>> 
>>>>> 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)
>>> 
>>> 
>> 
> 
> ------------------------------
> Randall Stewart
> 803-317-4952 (cell)
> 
>