Re: [clue] Draft new version: draft-holmberg-clue-data-channel-04

[Christer Holmberg <[e-mail]>]

Hi,

>>> Section 4.3:
>>>
>>> This section (and maybe others) refers to "the offerer". I don't think
>>> this is very clear. I think it would be helpful to define a new term
>>> (role) (e.g. Master) that identifies which end of the session is
>>> responsible for maintaining the association. It could be the end that
>>> sends the first offer that mentions the SCTP m-line in the clue group,
>>> or it could be more complicated. But regardless, it is defined in one
>>> place, and other places just reference that term, rather than something
>>> confusing like "offerer".
>>
>> Well, comedia also talks about the offer and the answerer, for TCP.
>
> Does it do so when referring to some past o/a? I know it talks about the
> *current* offerer and answerer. That is fine. Its when talking about the
> roles from some past O/A cycle (especially when it might not even be the
> prior one) that it gets confusing.

My understanding is that you are considered the offerer until another the other peer sends an offer. It may not be very clear in the spec, though.


>> HAVING SAID THAT, I actually think this section belongs in the sctp-sdp draft. Because, as there may be many data channels, with different protocols, running 
>> on the SCTP association, there needs to be a common way for handling SCTP association failures.
>
> Perhaps it does. But I think we need to have it in our stuff until it
> shows up in something we can reference. (There may be difficulty
> convincing others that this belongs in the sctp-sdp draft.)

We'll see - so far nobody has said that it does NOT belong there :)


-----------------


>>> Section 5.4:
>>>
>>>     In an offer, the offerer MUST NOT insert more than one "m=" line
>>>     describing an SCTPoDTLS association to be used to realize a CLUE Data
>>>     Channel.
>>>
>>> I think this is a little strong. I think we can say that the clue group
>>> must contain exactly one DTLS/SCTP m-line. Potentially there could be
>>> others that aren't in the clue group - they aren't our concern.
>>
>> What do you mean by "clue group"? Do you mean BUNDLE group?
>
> I mean the m-lines included in the a=group:clue (defined in the latest
> version of the signaling draft).

Aaah... ok... I didn't think of that.


>> Note that I am NOT saying one can only use one DTLS/SCTP m- line. I am saying that one can use one m- line for CLUE Data Channel purpose.
>>
>> But, when thinking about it, I don't think we need to say that. We already say that one can only use one CLUE Data Channel per CLUE session, so...
>
> But if there is more than one DTLS/SCTP m-line, then we do need to
> specify which one will be used for the clue channel.

I can add text regarding the group.


-----------------

>>> I think it would be helpful to discuss the use of a=setup and
>>> a=connection here. (and in 5.5.) These may also provide a basis for
>>> defining which end takes future responsibility for maintaining the
>>> association.
>>
>> I actually think that both 5.4 and 5.5 belong to the sctp-sdp draft. There needs to be a common way for establishing the SCTPoDTLS assocation, and there is nothing CLUE specific in the text.
>
> Agree. But if we somehow can't get it put in there, then I think we should include it in our stuff.

Section 6 of the sctp-sdp draft does talk about the setup and connection attributes (it basically referes to TCP), so we can reference that.

6.  The Setup and Connection Attributes and Association Management

   The use of the 'setup' and 'connection' attributes in the context of
   an SCTP association is identical to the use of these attributes in
   the context of a TCP connection.  That is, SCTP endpoints MUST follow
   the rules in Sections 4 and 5 of RFC 4145 [RFC4145] when it comes to
   the use of the 'setup' and 'connection' attributes in offer/answer
   [RFC3264] exchanges.

   The management of an SCTP association is identical to the management
   of a TCP connection.  That is, SCTP endpoints MUST follow the rules
   in Section 6 of RFC 4145 [RFC4145] to manage SCTP associations.
   Whether to use the SCTP ordered or unordered delivery service is up
   to the applications using the SCTP association.

If we have comments on that text we should take it to MMUSIC :)


Regards,

Christer