Subject: [rtcweb] WGLC for data channel drafts

From: Ted Hardie <[email-masked]>
Date: Tue, 10 Jun 2014 11:52:53 -0700

Dear WG,

This starts a working group last call for our core Data Channel drafts:

draft-ietf-rtcweb-data-protocol-06.txt
draft-ietf-rtcweb-data-channel-10.txt

Please review them in detail, especially for areas which may be of concern
to the broader IETF community.  This WGLC will end on June 27, 2014.

Ted, Sean, Cullen

---

From: Christian Groves <[email-masked]>
Date: Tue, 24 Jun 2014 23:51:09 +1000

Some comments:

draft-ietf-rtcweb-data-channel talks about unreliable use cases. 
Draft-ietf-rtcweb-data-protocol-06 in clause 4 also mentions "reliable 
or unreliable message transmission". However there is no channel type 
for "unreliable" only "DATA_CHANNEL_RELIABLE_xxx" and 
"DATA_CHANNEL_PARTIAL_RELIABLE_xxx". Are the "unreliable" use cases/text 
actually "partial reliable"? The requirements suggest that unreliable 
transport is needed but the solution offered is for reliable and partial 
reliability.

draft-ietf-rtcweb-data-channel-10
---------------------------------
Cl. 6.1 bullet 1: Would "stream reconfiguration" be a better term than 
"stream reset"? RFC6525 allows reset and addition of streams.
Cl. 6.1 bullet 2: "dynamic address reconfiguration" is the name of the 
RFC 5061. Is the part that Data Channel supports only the "Supported 
Extensions" parameter (cl.4.2.7/RFC5061)?

Regards, Christian

On 11/06/2014 4:52 AM, Ted Hardie wrote:
> Please review them in detail, especially for areas which may be of 
> concern to the broader IETF community.  This WGLC will end on June 27, 
> 2014.
>
> Ted, Sean, Cullen
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Ted Hardie <[email-masked]>
Date: Tue, 24 Jun 2014 11:03:16 -0700

Howdy,

Please note that this working group last call ends in 3 days, and we have
very little in the way or responses.  Please review the current drafts if
you have not done so.

thanks,

Ted

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 27 Jun 2014 15:00:20 +0200

> concern to the broader IETF community.  This WGLC will end on June 27, 

This is my Last Call review of these two drafts.

First of all: The drafts are ready for IETF Last Call.
Second: There are a number of details that should be fixed. Whether that 
happens before IETF Last Call or not is not of great concern to me.

draft-ietf-rtcweb-data-channel-10
----------------------------------------------
Abstract

Ten years from now, the RFC will exist, but the RTCWEB WG will not. I 
suggest replacing "The Real-Time Communication in Web browsers working 
group is charged to" with "The WebRTC framework specifies".

1. Introduction

It's a little abrupt. Some more words of introduction may be needed 
here. Something like this:

In the WebRTC framework, communication between the parties consists of 
media (for example audio and video) and non-media data. Media is sent 
using SRTP, and is not specified further here. Non-media data is handled 
by...."

I suggest a global replace of "non-SRTP media data" with "non-media 
data" (3 occurences total). "non-SRTP media data" can be parsed as 
"media data that is not carried over SRTP", which is not the intended 
meaning.

4. Requirements

Suggest striking "and that the WebRTC PeerConnection as a whole is fair 
with competing traffic such as TCP". The RMCAT discussions have proved 
how difficult it is just to define that, far less achieve it.
If we want to say something in relation to TCP, I would suggest "and 
that the WebRTC PeerConnection does not cause excessive problems when 
run in parallel with TCP connections".

5. SCTP over DTLS over UDP Considerations

In the paragraph on SCTP multihoming, I suggest using "the DTLS layer" 
instead of "the lower layer". There are multiple lower layers, 
identifying which one is mentioned here improves clarity.

The term "user-land" is used here, while Req. 10 uses "user application 
space". I suggest using "user application space" in both places.

The paragraph "When using DTLS as the lower layer..." repeats the info 
that SCTP multihoming is not used. It may be enough to say this once.

"The partial reliability extension MUST support policies..." - this 
paragraph would be more implementable if specific policies, specified in 
an I-D or RFC, were referenced.

The split between section 5 and section 6 seems odd. In particular, the 
section "This SCTP stack and its upper layer...." down to "exactly once 
and delivered in the order received." seems to belong to section 6 not 
section 5.

6.1 SCTP Protocol Considerations

I think the -ndata messsage interleaving MUST be implemented, according 
to previous consensus.
"SHOULD be used" seems both meaningless and unneccssary.

6.2 Association setup

Nit: "that can negotiated" -> "that can be negotiated"

6.4 Channel definition

The title should probably be "WebRTC Data Channel Definition".

As part of getting the WGs out of the document, the first sentence 
should be "The  WebRTC DataChannels are bidirectional."
"Among other things" is a bad term to have in a document at Last Call 
time. Can we remove it?

The SHOULD for -ndata- interleaving should be MUST implement and MUST 
offer. If it is not successfully negotiated at association setup time 
(is that how it works?), the "SHOULD limit" clause is appropriate.

6.7 Closing a channel

Nit: "available to reuse" -> "available for reuse"
Nit: "before resetting the stream" -> "before the stream is reset"

7 Security considerations

Is there a security worry with an attacker sending over-long messages in 
an attempt to cause OOM situations?

draft-ietf-rtcweb-data-protocol-06
---------------------------------------------
Abstract: Same worry about WG reference.

3. Terminology

Stream is defined in terms of stream, which is unhealthy. A reference to 
a section of a relevant SCTP document would be better.

The term "SCTP stream" occurs at least 18 times in the document (out of 
approx 41 occurences of "stream" overall). We should either use "SCTP 
stream" consistently" or stick to "Stream" consistently.

The term "SCTP stream identifier" (or "stream identifier") should be 
called out in the terminology.

The term "data channel" occurs 36 times. Consider standardizing on 
either Channel or Data Channel, and either capitalizing it or not.

6 Procedures
Nit: "the sender of it can start" -> "the sender of the 
DATA_CHANNEL_OPEN can start"

"If a DATA_CHANNEL_OPEN message is received .... the stream identifier 
corresponds to the role of the peer" - is there a reason to insist that 
the protocol machine enforce the odd/even rule?`(actually the next 
paragraph does not cover the odd/even rule violation case, which is 
probably just an unintentional mistake - I prefer writing this kind of 
thing in "IF <condition> ... ELSE .... - because if one writes it as "IF 
<condition>; IF <opposite condition>", the risk of losing some edge 
cases is high.

An alternative formulation for the second paragraph is "If the 
DATA_CHANNEL_OPEN message doesn't satisfy the conditions above, for 
instance if..."

7 Security Considerations

The "When using..." paragraph sounds a bit off. What about saying

This protocol does not provide privacy, integrity or authentication. It 
needs to be used as part of a protocol suite that contains all these 
things. Such a protocol suite is specified in [-dtls-encaps].

Dependency worries
---------------------------
-protocol- depends normatively on these non-WG documents:

draft-ietf-tsvwg-sctp-ndata ("I-D exists")
draft-ietf-tsvwg-sctp-dtls-encaps ("AD is watching")
draft-ietf-tsvwg-sctp-prpolicies ("I-D exists")
draft-ietf-mmusic-sctp-sdp ("I-D exists")

None of these are in the IESG queue. Are we confident of their speed of 
progress?

This concludes my review. I think the protocol definition is ready, and 
needs no changes.