Re: SCTP API document..

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

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.

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