WebRTC Data Channels
RFC 8831
Yes
No Objection
Note: This ballot was opened for revision 12 and is now closed.
(Alissa Cooper; former steering group member) Yes
= General comment =
I'm assuming Sections 3 and 4 are included here because data channels can be used outside the context of WebRTC or when no media is being exchanged. It would help to make that clear and only enumerate the use cases and requirements that are not already covered in draft-ietf-rtcweb-use-cases-and-requirements.
= Section 5 =
s/WebRTP/WebRTC/
= Section 6.1 =
OLD:
The dynamic address reconfiguration extension defined in [RFC5061]
MUST be used to signal the support of the stream reset extension
defined in [RFC6525], other features of [RFC5061] are not REQUIRED
to be implemented.
NEW:
The dynamic address reconfiguration extension defined in [RFC5061]
MUST be used to signal the support of the stream reset extension
defined in [RFC6525]. Other features of [RFC5061] are OPTIONAL.
("not REQUIRED" does not make sense)
= Section 6.4 =
OLD:
One strong wish is for the application-level API to be close to the
API for WebSockets, which implies bidirectional streams of data and a
textual field called 'label' used to identify the meaning of the data
channel.
NEW:
Data channels are defined such that their accompanying application-level API can closely mirror the API for WebSockets, which implies bidirectional streams of data and a
textual field called 'label' used to identify the meaning of the data
channel.
(I didn't understand "One strong wish".)
(Richard Barnes; former steering group member) Yes
(Spencer Dawkins; former steering group member) Yes
I'm a Yes on this one, but there are a few things I'd like the authors to look at. In particular, the 6.6 comment may require a bit of additional text.
In this text: 6.4. Data Channel Definition
One strong wish is for the application-level API to be close to the
^^^^^^^^^^^^^^^
API for WebSockets, which implies bidirectional streams of data and a
textual field called 'label' used to identify the meaning of the data
channel.
The realization of a data channel is a pair of one incoming stream
and one outgoing SCTP stream having the same SCTP stream identifier.
How these SCTP stream identifiers are selected is protocol and
implementation dependent. This allows a bidirectional communication.
I wonder how this will sound after this RFC and the WebRTC API have been published. Could this be a bit more concrete? Perhaps something like
The realization of a data channel is a pair of one incoming stream
and one outgoing SCTP stream having the same SCTP stream identifier.
How these SCTP stream identifiers are selected is protocol and
implementation dependent. This allows a bidirectional communication,
and allows the application-level API to be close to the API for
WebSockets, which provides bidirectional streams of data and a
textual field called 'label' used to identify the meaning of the data
channel.
In this text: 6.5. Opening a Data Channel
When one side wants to open a channel using out-of-band negotiation,
it picks a stream. Unless otherwise defined or negotiated, the
streams are picked based on the DTLS role (the client picks even
stream identifiers, the server odd stream identifiers). However, the
application is responsible for avoiding collisions with existing
streams. If it attempts to re-use a stream which is part of an
existing data channel, the addition SHOULD fail.
^^^^^^
My understanding of SHOULD says that if the addition doesn't fail, that's discouraged but legal under this specification. Is that OK? Or ought this be a MUST?
In this text: 6.6. Transferring User Data on a Data Channel
No more than one message should be put into an SCTP user message.
This statement doesn't use uppercase 2119 language, and the Conventions section doesn't say anything about whether lowercase 2119 wording is to be interpreted,
so at least some implementers will say that The spec doesn't prohibit it.
If a sender puts more than one message into an SCTP user message, is that OK? If the sender does that, what does the receiver do?
It would be helpful to include a sentence about why this restriction is included. The specification has a nice explanation of why non-interleaved connections should be limited to 16-Kb maximum message sizes. That's the level of detail I'm asking about here.
In this text: 7. Security Considerations
I should be noted that a receiver must be prepared that the sender
^
tries to send arbitrary large messages.
is likely "It".
(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) (was Discuss) No Objection
Thanks for addressing my DISCUSS.
(Brian Haberman; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
The draft looks good, thanks for your work on it. There is a tiny nit in the security considerations section that would likely be caught anyway: Last sentence should start with "It" instead of "I". I should be noted that a receiver must be prepared that the sender tries to send arbitrary large messages.
(Martin Stiemerling; former steering group member) No Objection
A few comments/nits: - Section 1, page 3, 1st paragraph reads: "source authentication, and integrity protected transfers. This data transport service operates in parallel to the SRTP media transports, and all of them can eventually share a single transport-layer port number." It is not not clear for me, what transport-layer the port refers to? SCTP or UDP or both? - Section 5, page 6, reads in one sentence: "SCTP association. In the WebRTP context, the PPID is used to" This should for sure read WebRTC instead of WebRTP, isn’t it? - Section 5, page 8, reads: " In general, the lower layer interface of an SCTP implementation SHOULD be adapted to address the differences between IPv4 and IPv6 (being connection-less) or DTLS (being connection-oriented)." The SHOULD here isn’t looking right, as this is not about protocol interworking, but advice for the implementers. Better to say "should be adapted to".
(Pete Resnick; former steering group member) No Objection
[Sorry for the resend; forgot to cut/paste one bit into my ballot.] 3/4: I don't understand what the point of putting these two sections into the document. They don't add anything to the discussion of the protocol, AFAICT, and are referring to a document that is still in IESG Evaluation and IMO has some serious problems. Please delete these sections. 6.5 - If it attempts to re-use a stream which is part of an existing data channel, the addition SHOULD fail. What does an implementation do if it *doesn't* fail? That is, why is this a SHOULD, and under what circumstances would you ignore the SHOULD? In addition to choosing a stream, the application SHOULD also determine the options to use for sending messages. The application MUST ensure in an application-specific manner that the application at the peer will also know the selected stream to be used, and the options for sending data from that side. I don't understand what the SHOULD and MUST here mean. Don't you just mean "will" in both cases? 6.6 - OLD The following PPIDs MUST be used (see Section 8): NEW Only the following PPIDs MUST be used (see Section 8): or better yet: This specification uses the following four PPIDs (see Section 8). Other PPIDs MUST NOT be used for WebRTC data channels. 6.7 - s/MUST/is 8 - Why are you re-using (and renaming) previously registered values instead of creating new ones, given that this is a FCFS registry?
(Stephen Farrell; former steering group member) No Objection
These are not DISCUSSes because I'm betting they get answered in some other document, but be good to have answers here too maybe. - In 6.2, what does "typically" mean for DTLS state shared between SCTP streams or SCTP associations or data channels or PeerConnections? Don't you need to use some 2119 terms and be more specific about that? Maybe that's just me not being so familiar with BUNDLE though, and what equivalent is meant here? - Where do I find text that will show me that it's not possible to cut'n'paste anything from one SCTP stream to any other anywhere?
(Ted Lemon; former steering group member) No Objection