IETF Logo Mail Archive

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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 05 March 2014 10:47 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2767B1A0416 for <rtcweb@ietfa.amsl.com>; Wed, 5 Mar 2014 02:47:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXTxs6mOiZxe for <rtcweb@ietfa.amsl.com>; Wed, 5 Mar 2014 02:47:40 -0800 (PST)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 926D91A0415 for <rtcweb@ietf.org>; Wed, 5 Mar 2014 02:47:40 -0800 (PST)
Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta06.westchester.pa.mail.comcast.net with comcast id Zmlf1n0040xGWP856mndpb; Wed, 05 Mar 2014 10:47:37 +0000
Received: from dhcp-a663.meeting.ietf.org ([31.133.166.99]) by omta12.westchester.pa.mail.comcast.net with comcast id ZmlS1n00E2904qf3YmlUrm; Wed, 05 Mar 2014 10:45:35 +0000
Message-ID: <53170047.8070000@alum.mit.edu>
Date: Wed, 05 Mar 2014 10:45:27 +0000
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
References: <530B740E.4090707@ericsson.com> <B163D4A9-AC33-454B-8F93-CC619AFB7A6F@lurchi.franken.de> <5316135A.1010405@alum.mit.edu> <D29689D2-3EEB-44A0-ADBB-9F642D264022@lurchi.franken.de>
In-Reply-To: <D29689D2-3EEB-44A0-ADBB-9F642D264022@lurchi.franken.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1394016457; bh=E52iwHS0bt0NSHh1f6IR8ZNhKzNehUfWcG4OkAkfmmk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VuhMvPehr71JGuQZHYjaaySsflDTNcquoHjk+xes+ziD40bSzw3YtqlzuBQBuD1Ed 1ewbBjF+/t8TKyF7cR07SWXtoxfZ62PJe/t5W+wvmIlRaNYyrgfjRxu1ygfntohg6d PfikOzeu5OpCY9U6xZbiN7WkkdE7ViySzTzN32uP6zPX5kkqsGr4n64+4ABOTmlYVS 3q0uAq0SI7oClzBAoq+sNX6A/H2EhIKBcT8taTaTg4xJhFZ7upJP8BPSITYLt+VZk+ Qmd/rpJQRtMthxqd2R2uZlR98cH3EgCCbSIQ8jXcSkB/CPhh4LWQ3gG5r6oDKMFw07 WFf0v1xf00PEA==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/6gqby4Bd_GVnLpTLZ8IrLmeSbxo
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-data-protocol-03
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Mar 2014 10:47:42 -0000

On 3/4/14 6:28 PM, Michael Tuexen wrote:
> On 04 Mar 2014, at 17:54, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>
>> On 2/25/14 5:07 PM, Michael Tuexen 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.
>>
>> 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.

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.

>> 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.

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

> Best regards
> Michael
>>
>> 	Thanks,
>> 	Paul
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>

v2.14.0 | Report a Bug | By Email