Subject: Re: [Tsvwg] Association is PR-SCTP enabled?

From: Michael Tüxen <[email-masked]>
Date: Mon, 3 Nov 2008 21:58:18 +0100

Hi Vlad,

I have added:

<t hangText="sac_info:">
If the sac_state is SCTP_COMM_LOST and an ABORT chunk was received for  
this
association, sac_info[] contains the complete ABORT chunk as defined
in the SCTP specification <xref target='RFC4960'/> section 3.3.7.
If the sac_state is SCTP_COMM_UP or SCTP_RESTART, sac_info may contain
an array of features that the current association supports. Features  
include
<list style='hanging'>
<t hangText="SCTP_PR:">
The both endpoints support the protocol extension described in
<xref target='RFC3758'/>.</t>
<t hangText="SCTP_AUTH:">
The both endpoints support the protocol extension described in
<xref target='RFC4895'/>.</t>
<t hangText="SCTP_ASCONF:">
The both endpoints support the protocol extension described in
<xref target='RFC5061'/>.</t>
</list></t>

I have not added SCTP_MULTIBUF and SCTP_NOCONNECT since both
are not related to a specific association.

Best regards
Michael

On Sep 23, 2008, at 8:11 PM, Vlad Yasevich wrote:

> Michael Tüxen wrote:
>> Hi Vlad,
>>
>> can you propose text?
>>
>
>
> Ok  how about:
>
>
>   sac_info: variable
>
>   If the sac_state is SCTP_COMM_LOST and an ABORT chunk was received
>   for this association, sac_info[] contains the complete ABORT chunk  
> as
>   defined in the SCTP specification [RFC4960] section 3.3.7.
>
>   If the sac_state is SCTP_COMM_UP or SCTP_RESTART, sac_info may  
> contain
>   an array of features that the current association supports.  See  
> Section
>   X.Y.Z for information about features defined in this document.
>   Additional features may be defined in separate specifications  
> detailing
>   specific extensions.
>
>
> This allows us to simply look at the length of the notification  
> returned to see
> if sac_info contains any information.  The information is encoded as  
> a simple
> array of bytes.  It doesn't matter what the values.  We just need to  
> document
> the names.
>
> The names reference in the document are:
> 	HAVE_SCTP_MULTIBUF
> 	HAVE_SCTP_NOCONNECT
>
> I think we can drop the HAVE_ prefix.
>
> Additionally, we can define the following:
>
> SCTP_PR
> SCTP_AUTH
> SCTP_ASCONF
>
> may be SCTP_PAD.
>
> Anything else, would include a symbol in he draft specifying the  
> feature.
>
> Applications simply test for the existence of the feature they are  
> interested in.
>
> -vlad
>

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 03 Nov 2008 16:17:21 -0500

Michael Tüxen wrote:
> Hi Vlad,
> 
> I have added:
> 
> <t hangText="sac_info:">
> If the sac_state is SCTP_COMM_LOST and an ABORT chunk was received for this

I would say "may include" or "MAY include".

> are not related to a specific association.

They might.  MULTIBUF is dependent on implementations.  One could
implement it as the ability to enable/disable this feature.
Additionally, application may want to know if a given implementation
supports MULTIBUF and returning it with association features would
make sense.

It also helps address all the other MULTIBUF text in the api id.

-vlad

>>   for this association, sac_info[] contains the complete ABORT chunk as
>>   Additional features may be defined in separate specifications detailing
>>   specific extensions.
>>
>>
>> if sac_info contains any information.  The information is encoded as a
>> simple
>> Anything else, would include a symbol in he draft specifying the feature.
>>

---

From: Michael Tüxen <[email-masked]>
Date: Mon, 3 Nov 2008 22:38:55 +0100

On Nov 3, 2008, at 10:17 PM, Vlad Yasevich wrote:

>> for this
I have committed "may include"...
> implement it as the ability to enable/disable this feature.
OK. I have added:
<t hangText="SCTP_MULTIBUF:">
For an one-to-many style socket, the local endpoints uses separate
send and/or receive buffers for each SCTP association.</t>
OK?

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 03 Nov 2008 17:17:32 -0500

> send and/or receive buffers for each SCTP association.</t>

Works for me

-vlad

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 4 Nov 2008 08:25:49 +0100

>> send and/or receive buffers for each SCTP association.</t>
OK. Committed to CVS (and there in the next rev of the ID).