Re: [rtcweb] Proxy browsing (Was: Open data channel issues)

Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Sun, 02 March 2014 22:14 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 170591A0B4E for <rtcweb@ietfa.amsl.com>; Sun, 2 Mar 2014 14:14:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] autolearn=ham
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 lguGkdsjPUh6 for <rtcweb@ietfa.amsl.com>; Sun, 2 Mar 2014 14:14:22 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE991A0B3B for <rtcweb@ietf.org>; Sun, 2 Mar 2014 14:14:21 -0800 (PST)
Received: from [IPv6:2001:67c:1232:12:c899:bf68:34b0:468] (unknown [IPv6:2001:67c:1232:12:c899:bf68:34b0:468]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3CED71C1042F6; Sun, 2 Mar 2014 23:14:17 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <CAOJ7v-1qYqsO0VOzwqMmZ5SP_DmrPbE_zm-tYgNT5r-Du5y5aQ@mail.gmail.com>
Date: Sun, 02 Mar 2014 22:14:15 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <19F59005-128A-426D-B169-7928C5096EAE@lurchi.franken.de>
References: <CAOJ7v-1qYqsO0VOzwqMmZ5SP_DmrPbE_zm-tYgNT5r-Du5y5aQ@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/das1sgLs2ulF4_A_Lz32lA6wZnk
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proxy browsing (Was: Open data channel issues)
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: Sun, 02 Mar 2014 22:14:25 -0000

On 02 Mar 2014, at 21:34, Justin Uberti <juberti@google.com> wrote:

> Can you explain more about the specific issue for "U-C 7: Proxy browsing"?  
> (http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-07#section-3.2)
Magnus said referring to U-C 7:

>>> Yes, this may be something that is possible, but to express it as a use
>>> cases intended to be supported might not be the best. We are after all
>>> likely talking about circumventing local security policies.

So keep U-C 7 and describe the consequences in the security section or remove it.

I responded yo his e-mail and voted for keeping the U-C.

Best regards
Michael
> 
> There are existing implementations that do this exact thing, so I don't know if anything needs to be done on our side to support this.
> 
> On Tue, Feb 25, 2014 at 3:44 PM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
> Dear all,
> 
> Magnus asked me to send a list of open issues regarding data channels
> to the list. Here is my current list:
> 
> 
> * Priority
>   The W3C hasn't defined it yet. Neither for the (S)RTP media nor for the
>   data channels. We agreed on using a non strict policy for the data channels
>   (some sort of wighted fair queueing). That is all.
> 
> * Protocol
>   It seems not to be clear what needs to be provided when registering a
>   (sub)-protocol at IANA. And the name of the registry is unclear...
> 
> * SCTP parameters.
>   There was discussed the issue how to set SCTP parameters, especially path.max.retrans
>   and association.max.retrans. Also HB.Interval might be of interest.
>   RFC 4060 recommends path.max.retrans=5, association.max.retrans=10, but has multihoming
>   in mind. To avoid the dormant state, path.max.retrans = association.max.retrans should be used.
>   I would suggest 10 for this value. Should HEARTBEATs be disabled?
> 
> * U-C 7: Proxy browsing
> 
> * Alternate CC for SCTP
>   Currently there is only the standard CC. However, in some places negotiation of CC is
>   mentioned.
> 
> I'm currently going through the backlog of comments regarding the data channels
> ID and I'll try to address the issues. If I find other issues, I send an update
> to the above list.
> 
> Best regards
> Michael
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>