Re: SCTP API document..

[Randall Stewart <[e-mail]>]

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

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)