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

[Michael Tuexen <[e-mail]>]

On 04 Mar 2014, at 17:39, Magnus Westerlund <[e-mail]> wrote:

> On 2014-02-25 17:07, Michael Tuexen wrote:
>> 
>> On Feb 24, 2014, at 5:32 PM, Magnus Westerlund <[e-mail]> 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.
We don't define at this place what priority is. The only point is that both
sides use the same priority.
> 
>>> 
>>> 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.
So what about using:

when using <xref target='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
SCTP stream identifiers, the side acting as the DTLS server MUST use Streams
with odd SCTP stream identifiers.</t>

>>> 
>>> 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.
The text now reads:
<t hangText='Protocol: Variable Length (sequence of characters)'>
<vspace blankLines='0'/>
The sub-protocol for the channel as a UTF-8 encoded string.
If this is an empty string the protocol is unspecified.
If it is a non-empty string, it specifies an protocol registered in the
'WebSocket Subprotocol Name Registry' created in
<xref target='RFC6455'/>.</t>
> 
>>> 
>>> 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.
I see. Changed to:
<t>All Data Channel Establishment Protocol messages MUST be sent using
ordered delivery and reliable transmission.
> 
>> 
>>> 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.
OK. Any concrete suggestions what should be covered?
> 
>>> 
>>> 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.
It now reads:
A simple protocol for in-band negotiation is specified in [I-D.ietf-rtcweb-data-protocol].
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
> 
>