Section 4.3.1

[lgrahl]

I don't fully understand the description of assoc_id in section 4.3.1.

This parameter is ignored for one-to-one style sockets. For one-to-many style sockets, this parameter indicates upon which association the user is performing an action.

So far so good.

The special sctp_assoc_t SCTP_FUTUREASSOC can also be used, it is an error to use SCTP{CURRENT|ALL}_ASSOC in assoc_id.

1. Why also if SCTP_CURRENT_ASSOC and SCTP_ALL_ASSOC are invalid? What does also refer to?
2. If everything but SCTP_FUTURE_ASSOC is invalid, why not just state exactly that?
3. The sentence could probably be split up into two.

(Let me know if I should write this on the mailing list.)

[lgrahl]

As a follow-up, section 2 states:

The protocol mechanisms described in this document allow the interleaving of user messages sent on different streams. They do not support the interleaving of multiple messages (ordered or unordered) sent on the same stream.

Fair enough. Now, section 4.3.1 repeats this but in a confusing way (to me at least):

Please note that it does not allow the interleaving of ordered and unordered user messages on the same stream.

IIRC, what you want to say is that interleaving of messages on the same stream is not possible in general, right? Whether these are ordered or unordered doesn't matter.

[tuexen]

Regarding your first message: When using 1-to-many style sockets, each association has an association ID. That ID we are referring to when writing

For one-to-many style sockets, this parameter indicates upon which association
the user is performing an action.

In addition to such a value, you can use the special value SCTP_FUTURE_ASSOC, but not SCTP_{CURRENT|ALL}_ASSOC. We have used this wording in a lot of cases, so I would like to keep it for consistency.

[tuexen]

Regarding your second message: You are correct in stating that it doesn't matter whether the messages are ordered or unordered. You could support, but we don't. This came up a couple of times so the wording was adopted based on comments. If you want to suggest a better wording, keeping the ordered/unordered stuff explicit, please do that on tsvwg@ietf.org, since the ID is currently in WG LC.

[lgrahl]

When using 1-to-many style sockets, each association has an association ID. That ID we are referring to [...]

Okay, that makes sense to me now.

If you want to suggest a better wording, keeping the ordered/unordered stuff explicit, please do that on tsvwg@ietf.org, since the ID is currently in WG LC.

Will do.

[tuexen]

Just as a note: The WG LC ends tomorrow (June, 12th)...

[lgrahl]

Err... okay, I don't know what WG LC stands for but if it means my suggestion is time-critical, then this would be my proposal:

Please note that it does not allow the interleaving of user messages (ordered or unordered) on the same stream.

This would keep the wording of section 2.

Can you propose this to the mailing list (if you agree with my wording)? I'd do it myself but I'm in the middle of preparing a presentation and would like to acquaint myself with the mailing list's rules 'n stuff before I write something.

[tuexen]

WG LC = working group last call. I'll integrate you suggestion.