Subject: Re: WGLC for draft-ietf-tsvwg-sctpsocket-26 started

From: "Becke, Martin" <[email-masked]>
Date: Sat, 26 Feb 2011 19:40:15 +0000

Hello all,

IMO the Socket API document is important, needed and should be progressed.
I have implemented parts of the described API as co-author of the measurement tool netperfmeter and currently in a new library for video data transfer with a special focus on the Multi-Homing capability.

IMO this draft is ready for the next step....

However, here some minor Issues:

Section 3.2:

- Note that this can also be done using the sctp_send() call described in Section 9.10.

Perhaps it could also be noted that this is deprecated...

Section 3.3 
The fact that a one-to-many style socket can provide access to many  SCTP associations through a single socket descriptor has important implications for both application programmers and system programmers implementing this API.

->
This is hard to read.
I think a comma is missing...

If the reader stops reading, the sender queues messages in the socket layer until it uses all of its socket buffer space allocation creating a "stalled connection".  
->
For my feeling there is a word or separator missing...

Section 4.18 

The semantics is similar to those used in the one-to-many style (see Section 3.1.3),

-> 
should be Section 3.1.4

Section 5.1
In the msghdr structure, the usage of msg_name has been discussed in  previous sections (see Section 3.1.3 and Section 4.1.8).

->
Found no discussion in 3.1.3 -> I think that is the same as above

Section 5.3.9 and 5.3.10

What is  send_msg() in this context? Is this a typo?

Section 6.2.1

An example where an application would like to receive data io events and association events but no others would be as follows:
->
IMO there should be a comma after data...

Section 7.1

len:  the size of the message or the size of the buffer.

to:  one of the peer addresses of the association to be used to send the message.

-> 
Upper Case
The....
One...

Section 7.5

(see Section 3.1.3).
->
should be (see Section 3.1.4).

Section (8.2)

see Section 8.1.2 on spp_pathmaxrxt)

-> 
should be
...see Section 8.1.12 on spp_pathmaxrxt)

Section 8.14
Posix -> POSIX 

Section 8.1.12
spp_pathmaxrxt
->
Just a naming, but a would expect spp_pathmaxrtx (rtx)

Section 8.1.20

sctp_data_io_events 

-> IMO using plural of sctp_data_io_event  is not needed. 

Section 8.1.27
At most one socket being bound to  the same port may be listening.
->
Mmmh..I'm not sure what is behind this

Section 8.3.1

The order of the explanation of sspp_addr and  sspp_assoc_id should be switched

Section 8.3.2

Add a Chunk That Must Be Authenticated (SCTP_AUTH_CHUNK)

->
I'm not sure if this is the correct usage of upper and lower case.... (that must be)

Section 9.11
  addrs:  is an array of addresses.
->
  addrs:  Is an array of addresses.

->
I would switch the order of sctp_recvv() and sctp_sendv().
Most the used pattern is send/recv-like
->
Check the draft for  association id and   association ID.
The usage is not consistent.

Best regards
Martin 

=======================================================================
 Martin Becke

 University of Duisburg-Essen,                   Room 308a
 Inst. for Experimental Mathematics              Ellernstraße 29
 Computer Networking Technology Group            D-45326 Essen/Germany
-----------------------------------------------------------------------
 Phone :     +49-201-183-7667
 E-Mail:     [email-masked]
=======================================================================

On Dienstag 08 Februar 2011, James M. Polk wrote:
> TSVWG
> 
> I am starting the WGLC for
> 
> "Sockets API Extensions for Stream Control Transmission Protocol (SCTP)"
> http://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctpsocket/
> 
> this is a 2 week WGLC, ending February 22nd, 2011 or when the chairs 
> feel the WG has reviewed the draft and reached consensus to progress 
> towards the ADs with the goal of becoming a proposed standard (PS) RFC.
> 
> The chairs require substantive feedback from the WG regarding this 
> draft before consensus can be called.

---

From: Michael Tüxen <[email-masked]>
Date: Sun, 27 Feb 2011 14:17:07 +0100

> However, here some minor Issues:
Hi Martin,

thank you very much for the comments.
> Perhaps it could also be noted that this is deprecated...
I changed the reference to sctp_sendv().
> I think a comma is missing...
Inserted.
> For my feeling there is a word or separator missing...
Changed to
If the reader stops reading, the sender queues
messages in the socket layer until the send socket buffer is completely
filled. This results in a "stalled connection".
> The semantics is similar to those used in the one-to-many style (see Section 3.1.3),
Fixed.
> Found no discussion in 3.1.3 -> I think that is the same as above
Correct. Fixed.
> What is  send_msg() in this context? Is this a typo?
Typo: sendmsg() is correct.
> IMO there should be a comma after data...
No, I do not think so. I changed it to
An example where an application would like to receive
data_io_events and association_events but no others would be
as follows:
which should make it cleaner....
> to:  one of the peer addresses of the association to be used to send the message.
Fixed.
> should be (see Section 3.1.4).
Fixed.
> ...see Section 8.1.12 on spp_pathmaxrxt)
Fixed.
> Posix -> POSIX 
Fixed.
> Just a naming, but a would expect spp_pathmaxrtx (rtx)
I too. But you can call this a deployed typo... Linux, FreeBSD and
Solaris use this name. A similar on is sasoc_asocmaxrxt...
> -> IMO using plural of sctp_data_io_event  is not needed. 
Fixed.
> Mmmh..I'm not sure what is behind this
We only want a single listening socket on a port.
> The order of the explanation of sspp_addr and  sspp_assoc_id should be switched
Fixed.
> I'm not sure if this is the correct usage of upper and lower case.... (that must be)
Fixed.
>  addrs:  Is an array of addresses.
Fixed.
> Most the used pattern is send/recv-like
Fixed.
> The usage is not consistent.
Fixed. Using association identifier.