WebRTC Data Channels
draft-ietf-rtcweb-data-channel-13

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

(Richard Barnes) Yes

Alissa Cooper Yes

Comment (2014-10-29 for -12)
No email
send info
= 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".)

(Spencer Dawkins) Yes

Comment (2014-10-30 for -12)
No email
send info
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".

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Benoît Claise) (was Discuss) No Objection

Comment (2015-01-05)
No email
send info
Thanks for addressing my DISCUSS.

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2014-10-29 for -12)
No email
send info
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?

(Brian Haberman) No Objection

Barry Leiba No Objection

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

Comment (2014-10-29 for -12)
No email
send info
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.

(Pete Resnick) No Objection

Comment (2014-10-28 for -12)
No email
send info
[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?

(Martin Stiemerling) No Objection

Comment (2014-10-29 for -12)
No email
send info
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".