WebRTC Data Channel Establishment Protocol
RFC 8832
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
(Alissa Cooper; former steering group member) Yes
(Richard Barnes; former steering group member) Yes
(Spencer Dawkins; former steering group member) Yes
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
(Alia Atlas; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Benoît Claise; former steering group member) No Objection
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
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
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
(Pete Resnick; former steering group member) No Objection
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
(Ted Lemon; former steering group member) No Objection