Subject: [rtcweb] Some final comments on draft-ietf-rtcweb-data-protocol-07

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Aug 2014 14:42:38 -0400

I just did another read-through of this draft, and identified a few 
things that I think need to be cleared up:

IIUC the data channel APIs expect that all channels, even those defined 
out of band, have a well defined set of properties. But those properties 
are defined in *this* draft that applies only to channels created using 
DCEP. OTOH, draft-ietf-rtcweb-data-channel-11 is much more vague about 
channel properties.

ISTM that most of the channel property specification should be moved to, 
or replicated in, draft-ietf-rtcweb-data-channel.

And this extends to the definitions for Channel Type, Priority, and 
Reliability since those also are intended to apply for the data channel 
API for channels defined out of band.

Alternatively, the data channel document could more extensively cross 
reference this document, or the two documents could be merged into one.

One more thing - section 4 says:

    Please note that
    there is also no attempt to resolve protocol glare.

I cannot figure out what this means. It is unambiguous which end is 
creating the channel, and that end is *declaring* the protocol to be 
used on it. There is no possibility of glare.

	Thanks,
	Paul

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 21 Aug 2014 21:57:40 +0200

On 11 Aug 2014, at 20:42, Paul Kyzivat <[email-masked]> wrote:

> I just did another read-through of this draft, and identified a few things that I think need to be cleared up:
Hi Paul,

thanks for bringing these points up. See my comments in-line.

Best regards
Michael
> 
> IIUC the data channel APIs expect that all channels, even those defined out of band, have a well defined set of properties. But those properties are defined in *this* draft that applies only to channels created using DCEP. OTOH, draft-ietf-rtcweb-data-channel-11 is much more vague about channel properties.
For out-of-band these properties don't have to be the same in both directions. That is why
this ID says:

   The Data Channel Establishment Protocol is a simple, low-overhead way
   to establish bidirectional Data Channels over an SCTP association
   with a consistent set of properties.

   The set of consistent properties includes:

For in-band the properties have to be the same in both directions.
> 
> ISTM that most of the channel property specification should be moved to, or replicated in, draft-ietf-rtcweb-data-channel.
I can list them there, if you think it is clearer. But they don't have to be the same in both
directions.
> 
> And this extends to the definitions for Channel Type, Priority, and Reliability since those also are intended to apply for the data channel API for channels defined out of band.
In draft-ietf-rtcweb-data-channel, Section 6.1, the reliability is described, in Section 6.4 the
priority is described. Maybe we should describe them all together in Section 6.4. Would that
address your issue?
> 
> Alternatively, the data channel document could more extensively cross reference this document, or the two documents could be merged into one.
> 
> I cannot figure out what this means. It is unambiguous which end is creating the channel, and that end is *declaring* the protocol to be used on it. There is no possibility of glare.
I changed the text to:

   To avoid collisions where both sides try to open a Data Channel with
   the same Stream Identifiers, each side MUST use Streams with either
   even or odd Stream Identifiers when sending a DATA_CHANNEL_OPEN
   message.  When using SCTP over DTLS
   [I-D.ietf-tsvwg-sctp-dtls-encaps], the method used to determine which
   side uses odd or even is based on the underlying DTLS connection
   role: the side acting as the DTLS client MUST use Streams with even
   Stream Identifiers, the side acting as the DTLS server MUST use
   Streams with odd Stream Identifiers.

   Note: There is no attempt to ensure uniqueness for the label; if both
   sides open a Data Channel labeled "x" at the same time, there will be
   two Data Channels labeled "x" - one on an even Stream pair, one on an
   odd pair.

   The protocol field is to ease cross-application interoperation
   ("federation") by identifying the user data being passed with an
   IANA-registered string ('WebSocket Subprotocol Name Registry' defined
   in [RFC6455]), and may be useful for homogeneous applications which
   may create more than one type of Data Channel.  Please note that
   there is also no attempt to ensure uniqueness for the protocol field.

Is this clearer?
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>