[rtcweb] Comments on draft-ietf-rtcweb-data-protocol-01

Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 12 November 2013 13:44 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1229221E80D3 for <rtcweb@ietfa.amsl.com>; Tue, 12 Nov 2013 05:44:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.552
X-Spam-Level:
X-Spam-Status: No, score=-105.552 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-tehkLRRWAI for <rtcweb@ietfa.amsl.com>; Tue, 12 Nov 2013 05:44:45 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4593111E8140 for <rtcweb@ietf.org>; Tue, 12 Nov 2013 05:44:45 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-a0-528230cbdd98
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3E.07.23787.BC032825; Tue, 12 Nov 2013 14:44:44 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.2.328.9; Tue, 12 Nov 2013 14:44:43 +0100
Message-ID: <52823111.9010701@ericsson.com>
Date: Tue, 12 Nov 2013 14:45:53 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: draft-ietf-rtcweb-data-protocol@tools.ietf.org, "rtcweb@ietf.org" <rtcweb@ietf.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDJMWRmVeSWpSXmKPExsUyM+Jvre4Zg6Ygg2k7eSxWH97LZrH2Xzu7 A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJWxdMUkpoInChW3Gt+xNjDulexi5OSQEDCR 6Lt9lBHCFpO4cG89WxcjF4eQwCFGidXzDzBDOMsZJabd3skEUsUroC2x/cx/VhCbRUBV4sj7 O+wgNpuAhcTNH41sILaoQLDE+VeL2SHqBSVOznzCAmKLCERLvF33EqxGWMBcYs6NDUBzOIA2 i0v0NAaBhJkF9CSmXG1hhLDlJZq3zmYGsYWA1jY0dbBOYOSfhWTqLCQts5C0LGBkXsXInpuY mZNebriJERhiB7f81t3BeOqcyCFGaQ4WJXHeD2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFw SjUwmp8R/X47dENS3WfZk7s3//Trd14Y8lw46ofYwreTPKrPsgjsmu/edudp36rdH+QPLCha PUe3ttZMLFFXyvGYgcf2t/ZvpuySk10qMzn9lirz7ptv1eTfsBzlF7NeYL/5k5act4hV9hTr hqj1/N3fzYQm7267xxgkkyg5oeebVMiC7aKRtppGSizFGYmGWsxFxYkAo8ZY4P8BAAA=
Subject: [rtcweb] Comments on draft-ietf-rtcweb-data-protocol-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 12 Nov 2013 13:44:52 -0000

Hi,

I did review the Data Channel Protocol on my way to IETF, and here are
my comments.

1. Section 4:

   o  the outgoing SCTP stream.

What about incoming SCTP stream?

2. Section 4:
   The data channel protocol uses a two way handshake to open a data
   channel.  The side wanting to open a data channel selects an unused
   Stream and sends a DATA_CHANNEL_OPEN message.  The peer responds with
   a DATA_CHANNEL_ACK message.  Then the data channel is open.  Please
   note that the opening side can send user messages before the
   DATA_CHANNEL_ACK is received.  These data channel messages are sent
   on the same Stream as the user messages belonging to the data
   channel.  The demultiplexing is based on the SCTP payload protocol
   identifier.

I find this paragraph a bit confusing on the following things:

A. Is the DATA_CHANNEL_OPEN message sent on that selected stream?
B. Is the DATA_CHANNEL_ACK sent on the peers corresponding stream number
as the DATA_CHANNEL_OPEN was received on?
C. "These data channel messages" does this refer to
DATA_CHANNEL_OPEN/ACK, maybe be more explicit.
D. "The demultiplexing is based on the SCTP payload protocol
   identifier." Do you mean PPIDs here. And could you be more explicit
about of how this works. Am I wrong in the understanding that you have
have one PPID for this control protocol. But, you are not explicit about
if which PPID user messages could use.

3. Section 4:
   The protocol field is to ease cross-application interoperation
   ("federation") by identifying the data being passed with an IANA-
   registered string, and may be useful for homogenous applications
   which may create more than one type of Channel.

One more case where I think it is fuzzy what is refered to. Is the
"protocol field" an identifier for the PPID to use, or something else?
What type of IANA registered string is being used here? Which registry
and field value are referenced?

4. Section 5.1:
   Priority: 2 bytes (integer)
      The priority of the channel.

What is the definition of the priority field value?

5. Section 5.1:
   Reliability Parameter: 4 bytes

I would recommend that you make a table under this parameter where you
make clear the interpretation of the field under differetn channel types.

6. Section 5.1

   Protocol: Variable Length (sequence of characters)
      The protocol for the channel.  This may be an empty string.  If
      used, it is an IANA-registered protocol (see Section 8.4).

Can you please be explicit about which IANA registry that is relevant
here. What is the meaning of an empty string?

7. Section 6.
What PPID shall be used when sending the user data?

8. Section 6.
Therefore, receiving an
   SCTP stream reset request for a stream on which no DATA_CHANNEL_ACK
   message has been received indicates to the sender of the
   corresponding DATA_CHANNEL_OPEN message the failure of the data
   channel setup procedure.

What is allowed to do after having received the reset on a
DATA_CHANNEL_OPEN? Can one try to send a new OPEN?

9. Section 8.2:
               | Reserved          | 0x00      | [RFCXXXX] |
               | Reserved          | 0x01      | [RFCXXXX] |

Why is these values reserved, please include the motivation for this in
the description of the registry.

10. Section 8.4:
   IANA is requested to create a new registration table "Protocol
   Registry" for the data channel protocol to manage the "Protocol"
   field of type string in DATA_CHANNEL_OPEN messages (see Section 5.1).

"Protocol Registry" is a lousy name on a registry. Secondly, I think the
purpose of this registry needs to be better described.


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------