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

From: Magnus Westerlund <[email-masked]>
Date: Tue, 12 Nov 2013 14:45:53 +0100

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: [email-masked]
----------------------------------------------------------------------