Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03

From: Magnus Westerlund <[email-masked]>
Date: Tue, 4 Mar 2014 17:39:07 +0000

On 2014-02-25 17:07, Michael Tuexen wrote:
> 
> On Feb 24, 2014, at 5:32 PM, Magnus Westerlund <[email-masked]> wrote:
> 
>> Hi,
>> (as individual)
> Hi Magnus,
> 
> thank you very much for the detailed review. Please see my comments in-line.
> 
> Best regards
> Michael
>>
>> I have reviewed the WebRTC Data Channel Establishment protocol
>> (draft-ietf-rtcweb-data-protocol-03) and have some comments:
>>
>> 1. Section 4:
>> Shouldn't this section discuss the priority field?
> I added in the list of consistent properties:
> 
> <t>the priority of the data Channel.</t>
> 
> and in the text below that enumeration:
> 
> ??????

Yes, text for this needs to be figured out.

>>
>> 2. Section 4:
>>
>> The method
>>   used to determine which side uses odd or even is based on the
>>   underlying DTLS connection role when used in WebRTC, with the side
>>   acting as the DTLS client using even stream identifiers.
>>
>> Isn't this unnecessary using the vague word of WebRTC instead of simply
>> pointing to the DTLS roles of the established data channel?

> The point is that in the WebRTC you use DCEP/SCTP/DTLS/UDP and therefore
> you can refer to the DTLS role. However, you could use DCEP/SCTP/IP
> or DCEP/SCTP/UDP/IP or DCEP/SCTP over something not involving DTLS.
> In that case DTLS is not used and you can not refer to the DTLS role.
> That is why the restriction is used.

Ok, if that concern then you still should be able to write a normative
specification under the condition that it is SCTP over DTLS. If not how
do you determine that? Are suggesting just to hand way or point to a
higher signaling layer.

>>
>> 3. Section 5.1:
>>      DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02):  The channel provides
>>         a partial reliable in-order bi-directional Communication
>>         channel.  User messages might not be transmitted or
>>         retransmitted after a specified life-time given in milli-
>>         seconds in the Reliability Parameter.  This life-time starts
>>         when providing the user message to the Javascript engine.
>>
>> I think the use of "Javascript engine" in the last sentence is unclear.
>> Can we provide a implementation neutral definition, like "This life-time
>> starts when requesting transmission of the user message."?

> This comment was already made on the list and I changed the text to
> 
> This life-time starts when providing the user message to the protocol stack.
> 
> OK?

Yes.

>>
>> 4. Section 5.1:
>>   Label: Variable Length (sequence of characters)
>>      The name of the channel.  This may be an empty string.
>>
>>   Protocol: Variable Length (sequence of characters)
>>      The protocol for the channel.  If this is an empty string the
>>      protocol us unspecified.  If it is an non-empty string, it
>>      specifies an IANA-registered protocol (see Section 8.4).
>>
>> Both of these fields are strings, shouldn't a particular encoding be
>> specified here? Like UTF-8. Secondly, what values are allowed, the full
>> set of Unicode?

> You are right. Any need for restrictions? We only need to be able to
> transform it to a DomString.
> So I changed it to:
> 
> <t hangText='Label: Variable Length (sequence of characters)'>
> <vspace blankLines='0'/>
> The name of the channel as a UTF-8 encoded string.
> This may be an empty string.</t>
> 
> <t hangText='Protocol: Variable Length (sequence of characters)'>
> <vspace blankLines='0'/>
> The protocol for the channel as a UTF-8 encoded string.
> If this is an empty string the protocol us unspecified.
> If it is an non-empty string, it specifies an IANA-registered protocol
> (see <xref target='iana_protocol'/>).</t>

I guess this is slightly overtaken by event. It have to be aligned with
what the websocket sub-protocol identifier.

>>
>> 5. Section 6:
>> All Data Channel Establishment Protocol messages MUST be sent
>>   requesting ordered delivery and using reliable transmission.
>>
>> I wonder of the use of requesting ordered delivery and using reliable
>> transmission, from an SCTP stream perspective, wouldn't using in both
>> places be appropriate? Or is how object which has been requested to be
>> transmitted unordered interact in SCTP with the ordered ones?

> I'm sorry, I don't understand what you are asking...

Sorry, it really is a language issue. The above sentence first states
"sent 'requesting' ordered" and later "and 'using' reliable".

This inconsistency is what I reacted to.

> 
>> 6. Section 7:
>>
>> I think this section can be beefed up a bit. First make clear that the
>> Data Channel's required usage of DTLS ensures that the message integrity
>> and possible source authentication as well as confidentiality. Then
>> going over any security risks with a malicous peer using this protocol.
>> Can a malicous side screw up the peer using this protocol? What are the
>> implications?

> Just to double check: Aren't the referenced documents the ones which
> discuss all security stuff in one place?

The security document do discuss system level important aspects. But,
from my perspective, details that are very specific to this protocol
should be discussed in this document.

I think this is highly relevant in this document as there are others
that are interested in using it.

>>
>> 7. Section 8.2:
>>
>> This registry reserves 0xff without any motivation, please add one.
> I added:
> 
> The value 0xff has been reserved for future extensibility.
> 

Ok

>>
>> 8. Section 8.3:
>> If I define a channel behavior that allows mixed ordered and unordered,
>> how would I register this?

> You can't. For SCTP properties like ordered/unordered delivery are
> on a per message base. In RTCWeb it was decided to make per channel
> base. So you can't have a data channel supporting a mixtures of
> ordered and unordered messages.

Ok, fine.

>>
>> 9. Section 8.4:
>>
>> I have a suggestion for this registries name, instead of "Protocol
>>   Registry" I propose  "DCEP Protocol Identification Registry"

> The problem I have with this definition is the following:
> Your name suggests that the use of this entity is restricted to
> DCEP. But isn't the protocol a property of a data channel, no matter
> whether negotiated by used DCEP or not?

As we now are going to point at the websocket one this is a mote point.

>>
>> 10. Section 8.4:
>>
>> There is missing any specification of what type of strings I may
>> register. Also, no length limitation, although the protocol allows at
>> maximum of 255 octets of encoded characters.

> I don't understand the limitation to 255 octets. The length field
> is 16 bit, so you can have up to 65535 octets. Therefore I changed:
> <t>A name for the protocol;</t>
> to
> <t>A name for the protocol which length is smaller than 65536 when using
> an UTF-8 encoding;</t>

Overtaken by events, limitations will be the ones of the Websocket
registry.

>>
>> 11. This comments concerns the relation to the Data Channel
>> specification. So my interpretation is that the WebRTC Data channel
>> draft has become both the base for this specification as well as the one
>> that specifies that the DCEP shall be implemented and supported. For
>> WebRTC I don't think this matters much, but if someone likes to re-use
>> the basic Data Channel specification, this structure makes it more
>> difficult and have no need for the bi-directional negotiated parameter
>> settings that the DCEP provides. In that case one have to sub-set the

> I think the data channel draft discusses the data channels independent
> how they are opened. This covers data parameters, user data transmission
> and closing of data channels. The data channel protocol draft discusses
> an in-band protocol for setting up data channels.

I think this was discussed today. And make it clear that DCEP
requirement shouldn't be from the Data Channel spec.

>> data channel specification. I wonder if it would be better to move some
>> normative statements around, so that the chain of implementation
>> requirement goes draft-ietf-rtcweb-transports ->
>> draft-ietf-rtcweb-data-protocol -> draft-ietf-rtcweb-data-channel thus
>> providing a cleaner and more modular build up of the protocols.
> I think you can implement draft-ietf-rtcweb-data-channel without
> draft-ietf-rtcweb-data-protocol, but not vice versa.
> 
> So you don't like the statement:
> 
>    A simple protocol for internal negotiation is specified in
>    [I-D.ietf-rtcweb-data-protocol] and MUST be supported.
> 
> from draft-ietf-rtcweb-data-channel. What would you suggest?

I think the high level requirement on DCEP might be in -rtcweb-transports.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Mar 2014 17:54:34 +0000

> That is why the restriction is used.

So data channels could work over SCTP/IP or SCTP/UDP/IP, but in fact 
can't solely because the choice of even/odd role is dependent on DTLS 
connection role?

Couldn't you find a way to choose the even/odd role based solely on the 
SCTP layer and the SDP? Then data channels could be used over those 
other stacks.

	Thanks,
	Paul

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 4 Mar 2014 18:28:21 +0000

On 04 Mar 2014, at 17:54, Paul Kyzivat <[email-masked]> wrote:

> So data channels could work over SCTP/IP or SCTP/UDP/IP, but in fact can't solely because the choice of even/odd role is dependent on DTLS connection role?
When not running over DTLS, you have not the security features provided by DTLS, of course.
> 
> Couldn't you find a way to choose the even/odd role based solely on the SCTP layer and the SDP? Then data channels could be used over those other stacks.
When running over UDP or IP you could define a client and server role and use a similar rule.

Best regards
Michael
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Tue, 4 Mar 2014 19:24:22 +0000

> SCTP layer and the SDP? Then data channels could be used over those
[Raju] 
+1
a=setup could be used to determine this, but the final determination is done only at SDP answer (which is same for DTLS).
For DTLS/SCTP case since both DTLS and SCTP layers use the same a=setup, both DTLS and SCTP client/servers roles match.
So, DCEP changing text to indicate role determination be done per SCTP client/server role instead of DTLS role may just work and is compatible with existing text.
[/Raju]

Best Regards
Raju

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Mar 2014 10:45:27 +0000

> When not running over DTLS, you have not the security features provided by DTLS, of course.

Of course.

One might argue that in the new world we shouldn't even define proto 
stacks that don't include security. But for the moment we are defining 
those protos. I see no reason why data channels should work over sctp, 
regardless of what is below that.

> When running over UDP or IP you could define a client and server role and use a similar rule.

Defining the rule differently for each proto stack is *possible* but 
unpleasant. IMO it would be far better to have a rule that works without 
regard for what is under sctp.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Mar 2014 19:47:04 +0000

+1

	Thanks,
	Paul