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

[Michael Tuexen <[e-mail]>]

On 14 May 2014, at 22:30, Magnus Westerlund <[e-mail]> wrote:

> On 2014-05-13 17:51, Michael Tuexen wrote:
>> On 13 May 2014, at 17:26, Magnus Westerlund <[e-mail]> wrote:
> 
>>>>> 
>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 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>
>>>>> 
>>>>> I think that is fine for when using over DTLS. And to my understanding
>>>>> this do require DTLS? If not we need alternative text.
>>> 
>>>> Our current use-case is for SCTP/DTLS. But we don't need DTLS except for
>>>> its security properties. However, if someone doesn't use DTLS, he has to
>>>> figure out how to determine the even/odd. This is covered by:
>>>> 
>>>> <t>To avoid glare in opening Channels, each side MUST use Streams with 
>>>> either even or odd SCTP stream identifiers when sending a DATA_CHANNEL_OPEN
>>>> message.
>>>> 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>
>>>> 
>>>> However, we can't provide a method in the general case...
>>> 
>>> Yes, as long as you use DTLS it is well specified. The issue I am trying
>>> to get my head around is if this specification and the data channel is
>>> possible to use without DTLS. This is one of the few (only?) things that
>>> requires it beyond the security features. Thus, should this be
>>> explicitly noted as saying, if you don't use DTLS you will be required
>>> to find an alternative solution to the roles.
> 
>> Isn't this be said by the first sentence of the paragraph? It states
>> the requirement of having a rule and provides on the second sentence
>> such a rule for the case where DTLS is used.
>> 
> 
> Yes, it does. And I see no risk of this being misunderstood in the
> context of WebRTC usage. So I will accept this, but note that this may
> be one of these cases where some poor guy will swear over this
> specification not being clearer on how to apply it in other contexts.
I'm happy to integrate any text you sent...

Should I resubmit the ID? I think it is pretty much done...

Best regards
Michael
> 
> 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]
> ----------------------------------------------------------------------
> 
>