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