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

[Paul Kyzivat <[e-mail]>]

Christer,

This is really starting to shape up well. I do have comments on this 
version, but IMO they don't impact adoption - they can be addressed 
either before or after. I want to talk to mary before initiating adoption.

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

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.

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.

Section 4.1:

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

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.

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

Section 5.2:

Where did you get this proto value???

According to draft-ietf-mmusic-sctp-sdp-06 it should be DTLS/SCTP.

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.

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.

(BUT, these also apply to DTLS. draft-ietf-mmusic-sdp-mux-attributes-01 
says that these attributes must be the same across a bundle. This 
constrains things.)

	Thanks,
	Paul

On 3/13/14 7:04 AM, Christer Holmberg wrote:
> Hi,
>
> Based on the discussions in London, I’ve submitted a new version (-04)
> of draft-holmberg-clue-data-channel.
>
> The draft now assumes that we will use the WebRTC Data Channel (that’s
> what it’s called at the moment…), and DCEP. There is a note regarding
> the usage of Richard’s draft, depending on the progress of the draft in
> MMUSIC.
>
> In London we also agreed to WG adopt the draft, so this is the version I
> intend to submit as draft-ietf-clue-00, as soon as the chairs give me a
> go ahead :)
>
> Thanks to everyone that have given input and comments so far – both on
> the list and in the meetings! J
>
> Regards,
>
> Christer
>