Fwd: SCTP API document..

[Randall Stewart <[e-mail]>]

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 <[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)