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

[Christer Holmberg <[e-mail]>]

Hi Paul,

> Section 3.2:
>
> I think this section could be weakened, to make DCEP the mechanism of
> last resort to establish the CLUE data channel, while *allowing* some
> other (currently unspecified) mechanism to preempt that.
>
> For instance:
>
>    In the absence of some other mechanism, a CLUE entity MUST use the
>    Data Channel Establishment Protocol (DCEP) [I-D.ietf-rtcweb-
>    data-channel], in order to open a CLUE Data Channel.
>
>    (This document does not define any other mechanism for establishing
>    the CLUE channel, but one may be defined in the future.)

Ok.

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

> Section 3.3.2:
>
>    The usage of SCTP for the CLUE Data Channel ensures reliable
>    transport of CLUE protocol [I-D.presta-clue-protocol] messages.
>
>    NOTE: [I-D.ietf-rtcweb-data-channel] requires the support of the
>    partial reliability extension defined in [RFC3758].  This is not
>    needed for a CLUE Data Channel, as messages are required to always be
>    sent reliably.  [I-D.ietf-rtcweb-data-channel] also mandates support
>    of the limited retransmission policy defined in
>    [I-D.tuexen-tsvwg-sctp-prpolicies].
>
> I think you need to be stronger here, and say that the parital
> reliability and limited retransmission policies MUST NOT be used.

Ok.

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

> And when using DCEP, this is governed by the DCEP OPEN message
> parameters. I when opening the CLUE channel the Channel Type MUST be
> DATA_CHANNEL_RELIABLE. But this probably belongs in section 4.1.

Ok.

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

> Section 4.1:
>
> I wonder if we want to include a version number in the protool name,
> just as another level of future-proofing.

I can add it as an open issue.

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

> Section 4.2:
>
> This is a little vague about which of the pair of streams is reset.
>
> Section 7.2 of draft-jesup-rtcweb-data-protocol-04 says more about this.
> (Though it has some editorial issues.) ISTM that should either be
> referenced or copied here.

Ok.

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

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

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.

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

> Section 5.2:
>
> Where did you get this proto value???
>
> According to draft-ietf-mmusic-sctp-sdp-06 it should be DTLS/SCTP.

Sorry, copy/paste error. I'll fix it :)

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

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

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

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

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

(Then, if we adopt Richard's draft at some point, we obviously need to describe the CLUE specific offer/answer procedures associated with that mechanism.)


Thanks for the comments!


Regards,

Christer