Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February

From: Christian Groves <[email-masked]>
Date: Fri, 06 Feb 2015 11:58:02 +1100

Hello

In general the draft is pretty good. My comments:
------------
1. General: I-D.ejzak- mmusic-data-channel-sdpneg has been made a WG 
draft <draft-ietf-mmusic-data-channel-sdpneg-00>.

2. Section 3.2.1.1: Given that the general feeling is that UDP will be 
more common than TCP do we want to make a recommendation on what 
transport CLUE endpoint should support in order to maximise interop?

3. Section 3.2.2 Heading: dcpmap -> dcmap

4. Section 3.2.2: Perhaps we should explicitly mention the data channel 
type used from [I-D.ietf-rtcweb-data-protocol] e.g. DATA_CHANNEL_RELIABLE.
If it is only DATA_CHANNEL_RELIABLE then perhaps we should indicate in 
Table 2 that the ordered, max-retr and max-time are not used due to the 
use of a reliable channel.

5. Section 3.3.5: Therefor -> Therefore

6. Section 3.3.6: Change "... in order to close data channel, a SCTP 
reset message [RFC6525] is sent to close the SCTP stream associated with 
the data channel". It should read better without the "," and the second 
"in order".

7. Section 5.1/5.2: The registries that need to be used for DCMAP and 
the WebRTC sub-protocol registry need to be sorted out. I'm not sure why 
two registries would be needed for essentially the same thing.

8. General: I don't think we can ship this off to the IESG until we can 
be sure that draft-ietf-mmusic-data-channel-sdpneg is stable.

Regards, Christian

On 31/01/2015 3:10 AM, Daniel Burnett wrote:
> To all CLUE participants,
>
> Other than dependencies there do not seem to be any major outstanding 
> issues remaining for the data channel draft, so I am starting a WGLC 
> today.  The end of this WGLC will be end of the day (wherever you are) 
> on Friday February 13. That gives two full weeks from today.
>
> If all is in order this will be the last review of this document by 
> the WG before it goes to the ADs and the IESG.  Now is the time for 
> careful, thorough reviews of the full document. Thankfully, the 
> document is very short and easy to read since it largely references 
> other documents.  Familiarity with both MMUSIC work and WebRTC data 
> channels is a plus but not required.
>
> To help in planning, please respond to this message if you plan to 
> submit a review.  We can only move forward if we get reviews!
>
> And yes, I will be a doing a WGLC review of the draft myself :)
>
> -- dan
> (for all the chairs)
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Feb 2015 18:05:30 -0500

Here is my WGLC review of draft-ietf-clue-datachannel-07:

* Section 2:

    WebRTC Data Channel refers to a SCTPoDTLS association
    [I-D.ietf-tsvwg-sctp-dtls-encaps] that is used to transport non-media
    data between two entities, according to the procedures in
    [I-D.ietf-rtcweb-data-channel].

IMO the above is wrong! IIUC "WebRTC Data Channel" refers to a single 
channel, namely a pair of SCTP streams, over an SCTPoDTLS association. 
[I-D.ietf-rtcweb-data-channel] says:

    The realization of a data channel is a pair of one incoming stream
    and one outgoing SCTP stream having the same SCTP stream identifier.
    How these SCTP stream identifiers are selected is protocol and
    implementation dependent.  This allows a bidirectional communication.

So I suggest the following to replace the above:

    WebRTC Data Channel refers to a pair of SCTP streams over a
    SCTPoDTLS association that is used to transport non-media
    data between two entities, as defined in
    [I-D.ietf-rtcweb-data-channel].

At the end of the section is:

    [RFC4960] defines an SCTP stream as a unidirectional logical channel
    established from one to another associated SCTP endpoint, within
    which all user messages are delivered in sequence except for those
    submitted to the unordered delivery service.

    [RFC4960] defines an SCTP identifier as a unsigned integer, which
    identifies a SCTP stream.

I don't understand how to interpret these in context. The section is 
listing conventions. Does "[RFC4960]" name a convention? How about:

    SCTP stream is defined in [RFC4960] as a unidirectional logical
    channel established from one to another associated SCTP endpoint,
    within which all user messages are delivered in sequence except for
    those submitted to the unordered delivery service.

    SCTP identifier is defined in [RFC4960] as a unsigned integer, which
    identifies a SCTP stream.

* Section 3.2.1.2

I think it would be good to mention that each CLUE entity is free to 
choose the sctp-port value at which it receives messages. CLUE does not 
prescribe any particular value.

* Section 3.2.2

This starts with 'When the SDP-based "SCTP over DTLS" data channel 
negotiation mechanism is used ...'. This suggests that there may be some 
other way. How about:

    The SDP-based "SCTP over DTLS" data channel negotiation
    mechanism is used to establish a CLUE data channel.
    The values of the ...

I commented on the dcmap parameters in reply to another message.

* Section 3.3.1

I find table 3 to be confusing. In spite of the text to the contrary it 
seems to say that PPID 51 explicitly identifies CLUE. I suggest simply 
removing Table 3.

* Section 3.3.2

I suggest modifying the 2nd paragraph as follows:

    A CLUE entity MUST NOT use the partial reliability and limited
    retransmission extensions (defined in [RFC3758], enabled with
    the dcmap options 'max-retr' and 'max-time') for the CLUE
    data channel.

(Otherwise this might be read to forbid using these for other data 
channels.) Mark also commented on this.

* Section 3.3.3

I suggest revising this to read:

    A CLUE entity MUST use the ordered delivery SCTP service, as
    described in section 6.6 of [RFC4960]. This service is enabled
    either by omitting the 'ordered' option from the dcmap attribute, or
    by specifying 'ordered="1"' in the dcmap attribute.

But this also keys into the other discussion of ordered. So make this 
conditional on that.

* Section 3.3.6

I think this should say *both* streams making up the channel must be 
reset. When a reset is received on one stream, a reset MUST immediately 
be sent on the other stream of the channel. (Unless one has already been 
sent.)

* Section 5.2

I agree with others that the dcmap subprotocol value should utilize the 
same registry as used for DCEP.

	That's all,
	Paul

On 1/30/15 11:10 AM, Daniel Burnett wrote:
> If all is in order this will be the last review of this document by the
> WG before it goes to the ADs and the IESG.  Now is the time for careful,
> thorough reviews of the full document.  Thankfully, the document is very
> short and easy to read since it largely references other documents.
> Familiarity with both MMUSIC work and WebRTC data channels is a plus but
> not required.
>