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

From: Justin Uberti <[email-masked]>
Date: Sun, 2 Mar 2014 13:34:02 -0800

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)

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 <
[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 2 Mar 2014 22:14:15 +0000

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 <[email-masked]> wrote:
> Dear all,
> 
>   data channels. We agreed on using a non strict policy for the data channels
>   There was discussed the issue how to set SCTP parameters, especially path.max.retrans
>   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.
>   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
> 
>