Skip to main content

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

Yes

(Alissa Cooper)
(Richard Barnes)

No Objection

(Adrian Farrel)
(Alia Atlas)
(Barry Leiba)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Stephen Farrell)
(Ted Lemon)

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

Alissa Cooper Former IESG member
Yes
Yes (for -08) Unknown

                            
Richard Barnes Former IESG member
Yes
Yes (for -08) Unknown

                            
Spencer Dawkins Former IESG member
Yes
Yes (2014-10-30 for -08) Unknown
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?
Adrian Farrel Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (2014-10-29 for -08) Unknown
Nits: Please run the nit-checker over this document to catch a few small issues (e.g., an obsoleted normative reference).
Brian Haberman Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2014-10-29 for -08) Unknown
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
Martin Stiemerling Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2014-10-29 for -08) Unknown
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.
Stephen Farrell Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Ted Lemon Former IESG member
No Objection
No Objection (for -08) Unknown