Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <5373D254.50804@ericsson.com>
Date: Wed, 14 May 2014 22:45:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <73724F06-8B39-4DAE-AD7D-AF53E4FC7CE5@lurchi.franken.de>
References: <530B740E.4090707@ericsson.com>
 <B163D4A9-AC33-454B-8F93-CC619AFB7A6F@lurchi.franken.de>
 <53160FBB.4070401@ericsson.com>
 <1904CA30-1112-44D4-8C6F-F15F1EF1BF9B@lurchi.franken.de>
 <534D566B.3040905@ericsson.com>
 <FB076F4A-83D9-4109-9FDC-89A4A2712553@lurchi.franken.de>
 <537239AD.9040000@ericsson.com>
 <980A88B9-5DBB-4A96-8F3F-4F77D64BE22C@lurchi.franken.de>
 <5373D254.50804@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/WEPI4hYrZ8ISB3ZSfZmF0-grQk0
Cc: draft-ietf-rtcweb-data-protocol@tools.ietf.org,
 "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03
Precedence: list


On 14 May 2014, at 22:30, Magnus Westerlund =
<magnus.westerlund@ericsson.com> wrote:

> On 2014-05-13 17:51, Michael Tuexen wrote:
>> On 13 May 2014, at 17:26, Magnus Westerlund =
<magnus.westerlund@ericsson.com> wrote:
>=20
>>>>>=20
>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> 2. Section 4:
>>>>>>>>>=20
>>>>>>>>> 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.
>>>>>>>>>=20
>>>>>>>>> Isn't this unnecessary using the vague word of WebRTC instead =
of simply
>>>>>>>>> pointing to the DTLS roles of the established data channel?
>>>>>>>=20
>>>>>>>> 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.
>>>>>>>=20
>>>>>>> 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:
>>>>>>=20
>>>>>> when using <xref target=3D'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>
>>>>>=20
>>>>> I think that is fine for when using over DTLS. And to my =
understanding
>>>>> this do require DTLS? If not we need alternative text.
>>>=20
>>>> 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:
>>>>=20
>>>> <t>To avoid glare in opening Channels, each side MUST use Streams =
with=20
>>>> either even or odd SCTP stream identifiers when sending a =
DATA_CHANNEL_OPEN
>>>> message.
>>>> When using <xref target=3D'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>
>>>>=20
>>>> However, we can't provide a method in the general case...
>>>=20
>>> 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.
>=20
>> 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.
>>=20
>=20
> 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
>=20
> Cheers
>=20
> Magnus Westerlund
>=20
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> F=E4r=F6gatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>=20
>=20