Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-06.txt

["Ejzak, Richard P (Richard)" <[e-mail]>]

I have some comments/questions about draft-ietf-rtcweb-data-channel-06.

The last paragraph of section 6.4 is a little ambiguous, but also seems to contradict the decision that the same stream identifier will be used in both directions.  I assume that "number" and "stream value" in the paragraph both refer to SCTP "stream identifier"?  Shouldn't the paragraph say that while SCTP does not constrain allocation of the stream identifier in the two directions, a bidirectional data channel is defined as a pair of streams in opposite directions that use the same stream identifier?

The discussion in the 3rd paragraph of section 6.5, which describes some constraints on external negotiation, is a bit confusing to me.  I assume that "picks a Stream" is intended to mean "picks a Stream Identifier"?  For clarity I would prefer the latter, unless something else is intended.

In the same paragraph, DTLS role is used as a possible way of determining whether one side can select odd or even stream identifiers, but this is problematic.  It must be possible for the side requesting (offering) the peer connection to open a data channel before DTLS role can be determined.  How can the application know whether to request an odd or even stream identifier for a data channel if it doesn't know the DTLS role yet?  May I suggest that a better example would be to say that selection is based on which side sends the initial SDP offer creating the peer connection (e.g., the initial offerer picks even stream identifiers and the initial answerer picks odd stream identifiers).

In the same paragraph, the last sentence points out that the other side must inform the protocol to expect data using the stream identifier selected by the first side, but must also select parameters for use with data that it sends.  I assume that this text requires that the same stream identifier be used for the streams in both directions, but this is not stated clearly.  If not, do you assume that external negotiation establishes unidirectional channels only?  If the latter, are the sending parameters relevant to the other side?  Is something else intended?

Section 6.6 says that the "higher level" can override the default reliability options with per-message options.  I don't think this is allowed by the API, or did I miss something?  While I know that SCTP could potentially allow this with API support, it seems confusing to describe capabilities not available from the API without some clarifying text.

Thanks,
Richard