Subject: [clue] Fwd: [rtcweb] AD review of draft-ietf-rtcweb-data-channel

From: Mary Barnes <[email-masked]>
Date: Fri, 8 Aug 2014 16:07:51 -0500

Ditto my message on the rtcweb data-protocol document.

Mary

---------- Forwarded message ----------
From: Richard Barnes <[email-masked]>
Date: Fri, Aug 8, 2014 at 3:27 PM
Subject: [rtcweb] AD review of draft-ietf-rtcweb-data-channel
To: "[email-masked]" <[email-masked]>,
[email-masked]

I have reviewed this document in preparation for IETF Last Call.  I have
gone ahead and requested last call, but there are some comments below that
I would like to be addressed before the document goes to the IESG.
--Richard

MAJOR:

Section 6.2.
I'm very concerned about interoperability of data channels given that,
e.g., (1) DCEP [draft-ietf-rtcweb-data-protocol] is not required, and (2)
DCEP only works if it is used by both endpoints (it resets any streams that
are used without DCEP negotiation).  In order to avoid interoperability
failure of this type, whatever mechanism is used to establish an SCTP
association that is used for data channels must also negotiate the
mechanism(s) that will be used to establish data channels over that
association.  That could be directly (by negotiating some data channels at
the same time as the association), or indirectly (by indicating that DCEP
or some other protocol will be used), but either way, the endpoints of the
association need to know how data channels will be negotiated before they
can create any data channels.  This section needs to state this requirement
so that applications using data channels can know that they need to meet it.

Section 6.4.
This section lists in passing several properties of a data channel, but
doesn't give a full definition of all the things that need to be defined in
order to define a data channel.  Fortunately, such a list is given in
draft-ietf-rtcweb-data-protocol (Section 4); I would suggest moving that
here.

MINOR / EDITORIAL:

Figures 1 and 2 list ICE as a separate layer.  That seems incorrect, since
ICE isn't actually involved once the connection is set up.

Section 6.4. "... in-sequence, out-of-sequence, reliable and unreliable as
properties of channels"
"... (as opposed to SCTP, which applies these concepts to messages)"

Section 6.4. "... and waiting for onopen to fire ... meaning of the streams"
This sentence doesn't really parse, and it's not clear why these API-level
considerations are relevant here.

Section 6.4. "stream SCTP identifier" -> "SCTP stream identifier" ?

Section 6.6. "The sender SHOULD disable the Nagle algorithm..."
A reference to RFC 1122 would be helpful here.

_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb