WebRTC Data Channel Establishment Protocol
draft-ietf-rtcweb-data-protocol-09

Note: This ballot was opened for revision 08 and is now closed.

(Richard Barnes) Yes

Alissa Cooper Yes

(Spencer Dawkins) Yes

Comment (2014-10-30 for -08)
No email
send info
This could have been a small Discuss - please consider it!

In this text: 8.2.2.  New Channel Type Registry

   Please note that if new Channel Types support ordered and unordered
   message delivery, the high order bit SHOULD be used to indicate
                                        ^^^^^^
   whether the message delivery is unordered or not.

I'm having a difficult time understanding why this is a SHOULD. If it's violated, that's still legal, so you can't actually be sure that the high order bit is meaningful. 

If this is going to matter, doesn't it need to be a MUST?

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Benoît Claise) No Objection

Comment (2014-10-29 for -08)
No email
send info
Nits: Please run the nit-checker over this document to catch a few small issues (e.g., an obsoleted normative reference).

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

Comment (2014-10-29 for -08)
No email
send info
Linking in the SecDir review, which had the same conclusion I did from reading this in that there were no additional security considerations to add. The draft looks good, thanks for your work on it.

http://www.ietf.org/mail-archive/web/secdir/current/msg05164.html

(Pete Resnick) No Objection

Comment (2014-10-29 for -08)
No email
send info
4 - I think you could clarify the following sentence:

OLD
   The side wanting to open a Data Channel selects a Stream Identifier
   for which the corresponding incoming and outgoing Streams are unused
   and sends a DATA_CHANNEL_OPEN message on the outgoing Stream.
NEW
   The peer that initiates opening a Data Channel selects a Stream
   Identifier for which the corresponding incoming and outgoing Streams
   are unused and sends a DATA_CHANNEL_OPEN message on the outgoing
   Stream.

On this one:

   Note: The opening side can send user messages before the
   DATA_CHANNEL_ACK is received.
   
s/can/MAY That's a protocol option, and one of which implementers should be made acutely aware.

Question: Regarding who gets evens and who gets odds, you say, "When using SCTP over DTLS...". That seems to imply that there might be an instance where you *wouldn't* use SCTP over DTLS. That's not true, is it? You already say in the intro that "the protocol uses the Stream Control Transmission Protocol (SCTP) [RFC4960] encapsulated in the Datagram Transport Layer Security (DTLS) [RFC4347] as described in [I-D.ietf-tsvwg-sctp-dtls-encaps]", so I take it as given. Assuming that's true, perhaps a better (and simplified) version of that paragraph might be:

   To avoid collisions where both sides try to open a Data Channel with
   the same Stream Identifiers, the side acting as the DTLS client in
   the underlying DTLS connection MUST use Streams with even Stream
   Identifiers, while the side acting as the DTLS server MUST use
   Streams with odd Stream Identifiers.
   
If you *do* mean to imply that there are other possible underlying protocols, you had better define how to avoid collisions that don't depend on DTLS.

6 -

Second paragraph: Re-word similar to section 4.

Third paragraph: s/can/MAY, as in section 4.

   After the DATA_CHANNEL_ACK or any other message has
   been received on the Data Channel, messages containing user data MUST
   be send ordered on ordered Data Channels and MUST be sent unordered
   on unordered Data Channels.

s/send/sent
   
But really, I don't understand what the above MUSTs mean. What does it mean to send unordered data on an ordered Data Channel, or vice versa? Doesn't the fact that it's an ordered Data Channel mean that, whatever data I send on it, it will arrive ordered? I don't get it.
   
   Therefore receiving a message containing
   user data on an unused Stream indicates an error.  The corresponding
   Data Channel MUST be closed as described in
   [I-D.ietf-rtcweb-data-channel].

Therefore? I don't follow.

Fourth and fifth paragraphs: Seems to me these belong *before* the third paragraph.

(Martin Stiemerling) No Objection