[rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 24 February 2014 16:32 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E181A0111 for <rtcweb@ietfa.amsl.com>; Mon, 24 Feb 2014 08:32:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.151
X-Spam-Level:
X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ho_a7FXppSA5 for <rtcweb@ietfa.amsl.com>; Mon, 24 Feb 2014 08:32:16 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 66F521A00FD for <rtcweb@ietf.org>; Mon, 24 Feb 2014 08:32:16 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-45-530b740fa030
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 07.24.10875.F047B035; Mon, 24 Feb 2014 17:32:15 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.2.347.0; Mon, 24 Feb 2014 17:32:14 +0100
Message-ID: <530B740E.4090707@ericsson.com>
Date: Mon, 24 Feb 2014 17:32:14 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>, <draft-ietf-rtcweb-data-protocol@tools.ietf.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDJMWRmVeSWpSXmKPExsUyM+JvjS5/CXewwcp2cYvVh/eyWaz9187u wOSxZMlPJo8vlz+zBTBFcdmkpOZklqUW6dslcGV86ZrJWnBbpWLz3ItsDYw7ZbsYOTkkBEwk jnw6zgZhi0lcuLceyObiEBI4xChx6+w+JghnOaPEp99HmEGqeAW0JfbM62YFsVkEVCXmHVrF CGKzCVhI3PzRCDZJVCBYYueB34wQ9YISJ2c+YQGxRQSiJXa+7GAHsYUF7CQ+r58DZHMAbRaX 6GkMAgkzC+hJTLnawghhy0s0b50NtlYIaG1DUwfrBEb+WUimzkLSMgtJywJG5lWM7LmJmTnp 5YabGIEhdnDLb90djKfOiRxilOZgURLn/fDWOUhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD 4+zK3Wk2r3YdMuz00zuy+t2zL8/b9UX2lJxR/Bwk2yvxUNd2/eG8lUfObzp5hHuCdvXa9pob C3bN315r7aKaEe/8RcOJhe/7Hefbv9fYd3adXjrV9lfx/e3cLR6VRoWz3qzeGBLqsiwo2vam cchOj50dPi1z+LJKd8b+E+hIeqxV++7kTd2MaUosxRmJhlrMRcWJAHWlY8z/AQAA
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/hLFiWQY5Hj8N-PSzik9fyDQO8HA
Subject: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2014 16:32:18 -0000

Hi,
(as individual)

I have reviewed the WebRTC Data Channel Establishment protocol
(draft-ietf-rtcweb-data-protocol-03) and have some comments:

1. Section 4:
Shouldn't this section discuss the priority field?

2. Section 4:

The method
   used to determine which side uses odd or even is based on the
   underlying DTLS connection role when used in WebRTC, with the side
   acting as the DTLS client using even stream identifiers.

Isn't this unnecessary using the vague word of WebRTC instead of simply
pointing to the DTLS roles of the established data channel?

3. Section 5.1:
      DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02):  The channel provides
         a partial reliable in-order bi-directional Communication
         channel.  User messages might not be transmitted or
         retransmitted after a specified life-time given in milli-
         seconds in the Reliability Parameter.  This life-time starts
         when providing the user message to the Javascript engine.

I think the use of "Javascript engine" in the last sentence is unclear.
Can we provide a implementation neutral definition, like "This life-time
starts when requesting transmission of the user message."?

4. Section 5.1:
   Label: Variable Length (sequence of characters)
      The name of the channel.  This may be an empty string.

   Protocol: Variable Length (sequence of characters)
      The protocol for the channel.  If this is an empty string the
      protocol us unspecified.  If it is an non-empty string, it
      specifies an IANA-registered protocol (see Section 8.4).

Both of these fields are strings, shouldn't a particular encoding be
specified here? Like UTF-8. Secondly, what values are allowed, the full
set of Unicode?

5. Section 6:
All Data Channel Establishment Protocol messages MUST be sent
   requesting ordered delivery and using reliable transmission.

I wonder of the use of requesting ordered delivery and using reliable
transmission, from an SCTP stream perspective, wouldn't using in both
places be appropriate? Or is how object which has been requested to be
transmitted unordered interact in SCTP with the ordered ones?

6. Section 7:

I think this section can be beefed up a bit. First make clear that the
Data Channel's required usage of DTLS ensures that the message integrity
and possible source authentication as well as confidentiality. Then
going over any security risks with a malicous peer using this protocol.
Can a malicous side screw up the peer using this protocol? What are the
implications?

7. Section 8.2:

This registry reserves 0xff without any motivation, please add one.

8. Section 8.3:
If I define a channel behavior that allows mixed ordered and unordered,
how would I register this?

9. Section 8.4:

I have a suggestion for this registries name, instead of "Protocol
   Registry" I propose  "DCEP Protocol Identification Registry"

10. Section 8.4:

There is missing any specification of what type of strings I may
register. Also, no length limitation, although the protocol allows at
maximum of 255 octets of encoded characters.

11. This comments concerns the relation to the Data Channel
specification. So my interpretation is that the WebRTC Data channel
draft has become both the base for this specification as well as the one
that specifies that the DCEP shall be implemented and supported. For
WebRTC I don't think this matters much, but if someone likes to re-use
the basic Data Channel specification, this structure makes it more
difficult and have no need for the bi-directional negotiated parameter
settings that the DCEP provides. In that case one have to sub-set the
data channel specification. I wonder if it would be better to move some
normative statements around, so that the chain of implementation
requirement goes draft-ietf-rtcweb-transports ->
draft-ietf-rtcweb-data-protocol -> draft-ietf-rtcweb-data-channel thus
providing a cleaner and more modular build up of the protocols.

This a suggestion based on that it looks like others, like CLUE is going
to use the Data Channel specification, but I am uncertain if they want
DCEP or not.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------