Skip to main content

WebRTC Data Channel Establishment Protocol
RFC 8832

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 steering group member) Yes

Yes (for -08)

                            

(Richard Barnes; former steering group member) Yes

Yes (for -08)

                            

(Spencer Dawkins; former steering group member) Yes

Yes (2014-10-30 for -08)
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 steering group member) No Objection

No Objection (for -08)

                            

(Alia Atlas; former steering group member) No Objection

No Objection (for -08)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (for -08)

                            

(Benoît Claise; former steering group member) No Objection

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

(Brian Haberman; former steering group member) No Objection

No Objection (for -08)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -08)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -08)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2014-10-29 for -08)
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 steering group member) No Objection

No Objection (for -08)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (2014-10-29 for -08)
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 steering group member) No Objection

No Objection (for -08)

                            

(Ted Lemon; former steering group member) No Objection

No Objection (for -08)